上一篇《搭建智能体，怎样找到真正有用的场景》写到，个人把一件事做快了，还要看看结果交出去以后，同事能不能顺利接手。
这一步往往比想象中麻烦。各岗位都有自己的记录和办法，单独用起来顺手，放到一起却未必说得清。谁来把它们整理好，谁负责后续处理，花时间改进方法又算不算正式工作？这些具体安排，决定了个人的改进能不能在部门里留下来。
一、每个人都有自己的办法，部门为什么还要临时加班
合同管理有合同表，商务管理有结算表，财务管理有收款表。在我所关注的实际情况中，这些表往往是各岗位或者各个条线自己设计的：记什么、怎样分组、什么时候更新，都是用着用着形成的。表格架构可能完全不同，甚至同一个项目，在几张表里都不叫同一个名字。
于是，需要综合分析的时候，一种做法是各岗位分别报出汇总数字，由负责汇总的人拼出结论。另一种做法是把表交给一个人，由他临时加班整理。
各报结果能回答一部分问题。可一旦追问某个数字包括哪些事项、为什么和另一张表对不上，就又得找人解释。把表集中起来也只是开始：收表的人先要读懂别人的记法，确认几个不同的名字是不是同一个项目，再分辨金额差异是因为统计时间不同，还是因为一边记的是已确认结算，另一边记的是实际收款。
这里不宜简单归结为谁“不规范”。每个人的表格都可能有自己的道理：他需要记住什么，怎样最快找到常用信息，什么结果需要向谁汇报。只是这些局部有效的办法，还没有形成支持共同工作的记录方式。组织需要了解整体情况时，就要有人临时完成这次转换。
报告做完了，那些费力弄清的事情有没有留下来？哪个简称对应哪个项目，哪一笔金额为什么不计入，计算时用了什么口径——如果这些只留在整理者脑子里，下次换一个问题，或换一个人做，还得重新问。这次的分析完成了，部门却仍然离不开那个最熟悉情况的人。
假设每个人都用上 AI，整理自己的表和写说明都快了，但记录方式和交接方式没有变化，汇总的人仍要逐一问清对应关系。个人确实省了事，跨岗位收集与解释的工作却不会自动消失。管理者要看见这部分劳动，也要问：下次能不能少做一遍？
二、个人完成工作时，能否同时留下组织可用的记录
让 AI 帮忙读表、寻找对应关系，可以减轻当次整理的负担。但如果每次都从头解释，下一轮还会遇到相同的问题。能不能在一件事办完时，就把以后需要的信息一起留下？
下面沿用合同、结算和收款的例子，设想一种逐步形成的工作方式，分享对可能路径的讨论和设想。
经办人处理一份补充协议时，工具除了协助核对内容，还可以准备一条变更记录：它对应哪份原合同，改了什么，依据在哪里，是否已确认生效。经办人检查后，把这条记录保存下来。商务人员以后核对结算依据，就有地方查这次变化，不必再找人回忆当时怎么谈的。
同样，结算人员留下本次确认的范围、金额和依据，收款人员记录实际到账及其对应事项。工具在协助完成这些工作时，可以一并准备记录，减少员工再录一遍的负担。原始材料里没有的事实，或还没说清的对应关系，则要交给有关人员确认，不能由模型补齐。
摩根士丹利在 2024 年公布的 Debrief 工具，就把类似安排放进了客户会谈。取得客户同意后，工具生成会议笔记和行动项；会后整理要点、起草邮件，供顾问修改并决定是否发送，同时把笔记存入 Salesforce 客户管理系统。企业发布稿
从这份企业披露能看到，顾问完成会谈时，也在为后续工作准备记录。这里值得参考的是工作怎样衔接，不能仅凭产品说明判断组织收益。笔记存进系统以后，内容是否准确、谁能读取、哪些事项已经确认，仍要有相应安排。
对前面的合同设想，Skill 是一种可以采用的实现方式。它把反复使用的任务说明、参考资料、模板和脚本放在一起，让智能体按约定的方法处理工作。但仅仅写好一份说明还不够，读取材料、检查结果和保存记录也得接上，并验证每一步确实执行了。Agent Skills 规范
对使用者而言，理想的体验是：工具帮助我把眼前的事做好，也顺带处理了原本需要重复录入和转换格式的工作。我不必理解数据库怎么设计，更不必每次都学习一套新的记录规则。这就是“几乎无感”值得追求的地方——共同记录可以随着工作自然产生。
这些约定可以从一件真实工作里慢慢理出来。商务核对结算时需要查哪次变更，就先把变更与原合同的关系留下；财务要辨认这笔收款对应什么，就把需要的依据说清。别一上来要求所有人把全部资料搬进一张庞大的统一模板。
历史材料仍可能需要解释和整理，新记录则可以从选定的一段业务开始改善。一边使用，一边检查哪些信息确实帮助了后续工作，哪些要求只是增加了填写负担。这样的范围更容易验证，也给不同岗位保留了调整空间。
大家用了同一个工具，还得说清楚哪些内容要记、怎样才算确认。如果只是把每个人原来的习惯各做成一个 Skill，合同、结算和收款照样各记各的，汇总时仍要重新问一遍。
三、数据能够关联以后，工作还需要有人接住
记录能对上以后，有些问题会更早显现。接下来还得有人处理。
继续沿用前面的设想。一次分析发现，某项已确认的结算，在目前的记录中还没有匹配到收款。这个结果首先提出的是一个需要核实的问题：资料是否更新到同一个时间点，款项是否已经收到但尚未匹配，相关付款条件是否已经满足？仅凭两边有差额，还不能直接把它认定为逾期。
比如核实后发现，付款所需的一份材料还没交。系统已经提醒了，商务以为经办人会补，经办人又以为财务还在核对，事情就可能继续搁着。工具可以把缺项列清楚、把有关资料放到接手的人面前，但谁负责补材料、什么时候交回、什么情况下需要协调，仍要有人作出安排。
如果允许工具执行部分步骤，也得把授权说清。找到缺项、提出补交建议、决定补交、实际交付，是不同的进展。系统显示“通知已发出”，不代表材料已经送到，更不代表款项已经收到。后续人员需要看到实际结果，才能知道接下来该做什么。
管理者也不能只看各岗位是否按时交表。一项材料已经交出，后续岗位却一直在追问，那段等待仍是这件事的耗时。某个人做得快，另一个人却得花更多时间核验和协调，整体效果就要重新算。
星展银行（DBS）在 2025 年年报中披露，它围绕跨部门的客户服务过程，也就是“横向客户旅程”，调整工作方式，并在其中嵌入绩效管理安排；运营模式转型同时涉及流程、人机协作、培训和组织调整。星展年报 CEO reflections
回到一个部门，不必先重画完整组织架构。可以从一类反复发生的共同任务开始，明确它怎样发起，什么条件下交给谁，哪些分歧需要一起处理，什么结果才算完成。个人工具就在这段工作中找到自己的位置。
四、对使用者越方便，共同规则越需要有人维护
继续看这个例子。合同那边说手续已经办完，商务说结算金额确认了，财务查到的却是款还没到账。三个人说的都可能没错，但不能把这些情况都记成同一个“已完成”。否则，表面上统一了状态，真正需要处理的事情反而看不见了。
工具替人整理记录之前，必须先分清这些含义。各岗位可以用不同的界面，保留各自需要的细节；别人读到记录时，则应当知道这里的“完成”究竟指哪一步，依据是什么。看到结算已经确认，不能顺手就把收款也当成完成。
这些判断不能由工具开发者独自决定，也不用业务人员先写出一份完整的技术规格。拿一件真实工作一起走一遍，说明为什么这里还不能算完成、那份材料为什么不能替代这份依据，再由技术人员和 AI 协助整理、实现，用样例检查。熟悉业务的人负责确认标准，才有办法判断工具做得对不对。
在一段具体工作中，至少应当有人能回答：这项状态由谁确认，跨岗位有分歧时由谁协调，共用方法由谁维护。几项职责可以由现有人员承担，没必要为此预设新的层级；但它们不能长期处在“大家都管一点”的模糊地带。
共享也有范围。谁能看哪些记录，谁能补充或修改，改过以后要不要重新确认，都应当说清。需要交给下一位同事的，可能只是完成任务所需的一部分信息，而非整份材料。
维护还包括处理变化。假设某次交易获得了特殊安排，这项安排应当连同适用范围一起留下。它可能对本次判断很重要，却不能因为被存进资料库，就变成以后所有事项的默认规则。组织正式调整规则时，则需要检查相关工具是否仍在沿用旧方法，以及哪些正在处理的事项可能受到影响。
使用者不用每次研究记录格式，是因为有人把这些事情安排好了。规则变了，工具也要跟着改；方法交给别人用，还得有人解释和维护。前台减少的复杂度，不能变成后台无人承担的责任。
五、改善工作的方法，也应成为组织认可的工作
一个人把工具做出来，自己用着顺手，离同事也能放心用，还有一段工作。得找不同的材料试，解释哪些结果可信，核对例外，修改不合适的地方。规则或模型换了，还得再查一遍。谁来花这些时间？原来的任务照做，改进工具留到下班后，往往就是没人正式安排时的结果。
MIT Sloan 在 2026 年 9 月介绍的一项研究，观察了两家机构怎样把员工试验变成组织共用的方案。文中用 NE Health 和 LegalCo 代称一家医疗中心和一家律所：医疗中心的团队试着生成患者容易理解的出院摘要，律所的团队则做法律研究。两边都提供了安全的试验环境和培训，接下来的支持却不同。
医疗中心持续提供技术帮助，让团队用共同的标准评价结果，并把 AI 试验纳入正式职责和贡献认可。律所的持续支持较少，相关劳动也较少进入评价与报酬决定；随着额外负担累积，参与者逐渐退出。它把一个问题摆得很具体：员工愿意开始试，不等于能一直在本职工作之外坚持试。MIT Sloan 研究说明
对一个部门来说，支持可以很具体：核验工具时给业务人员留出时间，遇到技术问题有人帮忙，维护到什么范围、原负责人不在时谁接手，都有安排。关于“生产率 J 曲线”的研究讨论过技术之外的流程、管理和人员能力投入，这些劳动同样需要计入成本。研究工作稿
反复收表是为了完成这次分析，整理共用方法则希望下次少走弯路。但花了时间，不代表一定值得。如果工具一直没什么人用，维护却越来越费力，还得靠一个人反复补救，就要重新考虑做法和范围。
认可贡献，也要看究竟帮上了什么忙。一位同事把反复出错的统计口径说清，另一位同事发现模板漏了一种重要情形，都值得被看见。他们未必创建了新的智能体，却让后面的人少犯了一次错。创建了许多 Skill，如果无人使用、无人维护，也说明不了多少实际效果。
把指出问题也视为贡献，还需要让人能够放心提出疑问、承认错误。Edmondson 的研究将这种共同感受称为“心理安全”，发现它与团队的求助、反馈和讨论错误等学习行为相关。研究原文
如果共用工具遇到的例外只能私下绕过，表面上的使用可能继续，实际方法却没有得到修正。如果每次反馈都意味着必须先证明“不是自己不会用”，反馈本身也会成为负担。管理者需要让善意提出的问题进入改进过程，同时保留对正式业务交付的质量要求。
评价这些工作，可以看同事有没有用起来，是否少了重复解释，发现的问题有没有改正，不必急着把每项贡献换算成财务收益。有人擅长提问题，有人适合核验案例，有人能够维护工具，也有人只需要把它用好，没必要让所有人都成为工具建设者。
这就回到了上一篇关于时间去向的问题。AI 省出的时间，如果立即被更多即时任务填满，维护和改进仍然只能挤到工作之外。要把方法留下来，就得为这部分工作留时间；学习、休整和更好地服务他人，也应当有位置。
六、下一次工作能否更可靠地完成
这些安排有没有用，下一次综合分析时就能检查。
找一类范围和复杂程度相近的工作作比较：这次还要向多少人收材料，哪些名称和口径又得解释一遍，从提出问题到拿到可用结果花了多久？报告里的判断能不能找到依据，发现差异以后有没有人处理？这些比演示时几秒钟生成一份报告，更能说明部门得到了什么。
也要问问维护者。经办人省事了，是不是他在背后忙得更多？共用记录减少了重复录入，还是又添了一套必须填的系统？如果新增负担长期超过收益，或结果总要大量返工，就应当缩小范围、改进做法，必要时停掉不值得继续的部分。
另一个有用的检验是换一个人。原先负责整理的人不在，其他同事能不能沿着留下的记录和依据继续处理？不必拥有前任的全部经验，但至少能弄清事情到了哪一步、下一步缺什么，而不用每件事都去问原来那个人。部门能留下这样的能力，个人的改进才有了延续。
除了让别人接得上，每次处理问题还可以为下一次积累经验。沿用前面的假设，分析发现一笔款尚未匹配，核实后确认只是记录中的对应关系缺失。有关人员补正记录，并把这类情况的识别方法加进后续处理。如果后来遇到相似事项时能更早发现、减少同样的追问，这次纠错就产生了超出本次任务的价值。
也可能核实后发现，材料确实没有按要求交付。此时需要推进实际业务处理，再留下处理结果，检查以后是否需要更早准备相关材料。两个情况表面上都是“没有匹配到收款”，原因与行动却不同。积累这些差异及其依据，才可能让后续工作更准确。
这也是“数据飞轮”可以落到实处的一种解释：工作留下记录，分析找到问题，处理结果又用来修正记录和方法，下一次做事因此有了更好的依据。数据多存了一份还不够，要看同类问题再出现时，是否少追问一次、少走一段弯路。
这种积累也不必每次都重新训练模型。修正一条业务记录，保留一项决定的依据，更新一个共用模板，都可以改变下一次任务使用的信息和方法。关键是知道哪些内容经过了确认，哪些经验只适用于特定条件，以及什么已经过期。
“企业智能原生”，我更愿意从这里理解它：组织安排日常工作时，开始认真考虑哪些资料可以由 AI 协助整理，哪些步骤可以交给工具，哪些判断必须由人负责，以及发现问题后怎样改。它是一种工作方式的变化。
共同数据、流程管理和组织学习，早在 AI 出现前就有。现在值得探索的是，AI 能否让读材料、整理经验、执行日常步骤的成本降下来，让过去嫌麻烦而没有留下的记录和方法，更容易在工作中留下。可以从已有系统上的一小段工作开始，不要求重建整个企业。
上一篇问，质量有保证以后，省下的时间与能力有没有值得去的地方。本篇再往前问一步：组织有没有给它留出条件？有人愿意改进时，能否得到时间和帮助；方法有用了，能否让别人继续用；遇到问题时，能否有人接着改。
下一次需要分析时，最熟悉情况的同事不在，其他人仍能找到可靠的记录、弄清问题、推进处理，也不必临时加班把一切重拼一遍——这样的变化，才是组织能力可以被看见的地方。