“帮我写一份报告。”
\n“判断这个问题需要调查什么，把不同方向交给合适的执行者，检查证据，发现缺口后重新安排工作，最后交付报告。”
\n这两条指令，交出去的东西已经不一样了。前者委派一项任务，后者还委派了部分关于任务应该怎样被完成的决定。
\nAnthropic 在公开的研究型智能体（Agent）系统中，已经采用这样的安排：主 Agent 制定调查策略，创建子 Agent 分头探索，再根据结果决定是否继续调查、补充方向或调整策略。这是特定研究任务中的工程实践，还不能代表一家公司的运行方式。Anthropic（在新标签页打开）
\n但它让一个变化变得具体：AI 开始参与拆解工作、分配注意力、协调执行与整合结果。它接走的已经不只是写作、搜索和分析。
\n如果“组织工作”本身也能部分交给 AI，原来围绕这些活动形成的岗位、流程和层级，还应该怎样安排？
\n提到组织，我们很容易想到部门、岗位、负责人和汇报关系。但暂时拿掉这些名称，看看一件事为什么能够被一群人做成。
\n目标需要拆成可以行动的任务，任务需要有人承接，执行者也需要获得必要的信息。不同人的努力，还需要朝着共同结果汇合，而不是各自完成一份看似合格的作业。
\nArrieta、Puranam 等人在工作论文《Multi-Agent AI Systems Are Organizations》中，把这类问题概括为任务分解、任务分配、信息供给，以及激励或目标配置。他们还强调，这些安排难免出错，需要能发现和处理异常。共同面对组织问题，并不意味着人和 Agent 应采用同一套解决办法。工作论文（在新标签页打开）
\n这个框架最有价值的地方，是帮助我们区分两件事：组织必须解决的问题，与我们习惯采用的解决方式。
\n需要协调，不等于必须召开周会；需要分配任务，不等于每一次都必须经过同一个负责人；需要专业判断，也不等于所有工作都必须沿着固定的部门顺序流转。
\n这些安排可能合理，甚至非常必要。但我们需要知道，它们究竟在解决什么问题。\n否则，一旦技术条件变化，我们就容易只做两种选择：要么原样保留所有安排，只要求每个人更快；要么因为部分活动可以自动化，就把整个岗位或层级视为多余。
\n两种选择都跳过了最重要的分析。一位负责人可能同时承担进度追踪、资源协调、专业判断、冲突处理和成员培养。进度追踪可以部分自动化，并不能直接推出其他职责也应该取消。
\n能够重新分配的是具体活动，不能未经分析就把整个岗位当成可替换的零件。
\n这里需要先排除一个误解：把工作规则交给软件执行，并不是 AI 才带来的能力。
\n“满足条件就转给甲，否则转给乙”，用普通程序就可以实现。这样的系统执行的是事先确定的安排。
\nAgent 带来的另一种可能，是把部分安排留到任务发生时再决定。
\nAnthropic 在《Building Effective Agents》中区分了预定义工作流与 Agent：前者沿着预先写好的路径组织模型和工具，后者由模型动态决定过程与工具使用。它也明确强调，复杂性需要有实际收益，不能因为可以使用 Agent，就放弃更简单、可预测的方案。Anthropic（在新标签页打开）
\n从组织视角看，两者的差别可以这样理解：过去，我们先设计一条路，再让系统带着每项任务走完。现在，在某些边界明确、反馈可获得的任务中，我们可以给出目标、约束和可用资源，让系统参与判断这一次应该怎么走。
\n这并不意味着它可以任意改变目标，也不意味着它安排得一定比人好。
\n变化在于，“如何安排这项工作”本身，开始成为可以委派、检验和修正的任务。
\n以一条商品视频为例，如果素材已经齐全，就不必重新生成；如果关键卖点缺少证据，就应该先补充信息，而不是立即写脚本；如果修改只影响字幕，就不需要让所有环节重新执行。
\n这些判断当然也可以由人作出。值得研究的是：其中哪些能够稳定地交给系统，哪些仍需要人的介入，以及这种调整是否真的减少了总成本。
\n判断是否值得委派，需要把检查、纠错、模型调用和维护规则的成本一起算进去。省下沟通时间，却增加更多返工，组织未必获得收益。
\n沿着这条思路，可以做一个设计推演。
\n假设我们要建设一个内容生产系统。最直观的做法，是按照现有岗位，分别建立策划 Agent、编导 Agent、设计 Agent、剪辑 Agent，再安排它们依次交接。
\n这样的设计容易理解，但它隐含了一个未经检验的假设：原来适合人的工作边界，也适合 AI。
\n我们可以暂时放下岗位名称，重新描述任务：这条内容需要传达什么？哪些商品信息已经得到确认？有哪些可以复用的素材？什么地方需要探索，什么地方必须保持一致？什么证据足以支持一次修改？
\n另一种安排是，系统先检查信息与素材。缺少商品证据，就请求补充；证据充分，就围绕不同表达方向生成候选。创作者选定方向后，再完成相应的画面、声音与剪辑。发生修改时，只重新处理受影响的部分。
\n这仍然需要创作判断，也仍然存在专业分工。但我们不必事先假定，每一项工作都要经过一套完整的“数字部门”。
\n这里的变化，不是把人从流程里删除，而是把必须存在的任务依赖，与沿用已久的岗位交接区分开。
\n例如，确认商品事实，是创作必须遵守的约束；至于由哪个岗位先写出哪份文档，再把它交给谁，则可以重新设计。
\n当然，按照岗位建立 Agent 并不一定错误。它可能便于理解、明确责任，也可能适合既有业务接口。
\n需要避免的是：把组织图直接翻译成 Agent 图之后，就以为完成了重新组织。
\n我们应该先证明这种划分有用，而不是因为它熟悉，就默认它正确。
\n把执行者换成 AI，并不会自动获得良好的协作。
\nAnthropic 在研究型 Agent 系统的工程复盘中提到，模糊的任务说明曾让子 Agent 重复调查、遗漏必要内容。改进不仅依赖模型能力，也依赖更清楚的目标、输出要求、工具指引和任务边界。Anthropic（在新标签页打开）
\n这类失败很有启发。当两个 Agent 各自完成任务，却无法把结果拼起来，我们不能只问哪个模型不够聪明。还需要检查：任务是否拆错了？双方是否掌握了不同版本的事实？输出是否满足彼此的需要？
\n从这个角度看，一部分看似纯技术的配置，也在规定协作关系。
\n给谁开放什么工具，是在设定行动范围；让谁读取哪些信息，是在决定它能够依据什么作判断；规定什么情况下必须请求确认，是在划定自主行动的边界。
\n这些配置会影响实际的工作关系，值得和岗位、协作方式一起讨论。
\n回到内容生产的例子：让 AI 建议替换一个镜头，与允许它直接替换、覆盖并发布，可能使用相同的模型，却是两种不同的授权安排。
\n提出建议、在批准后执行、在授权范围内自主行动，是不同的安排。本文所说的 Agent，指能够调用工具并参与选择执行路径的系统；它能做什么，仍取决于具体工具和授权。模型在测试中表现更好，并不自动改变这些权限。第六、七篇会继续讨论决定权和责任。
\n我更愿意把这类变化理解为：部分组织活动进入了软件，设计者仍要对其中的协作关系负责。
\n过去需要讨论的分工、边界与例外，现在可能被写进配置、提示词、代码和评估标准。改变其中一项，实际工作关系就可能发生变化，即使组织架构图一笔未动。
\n到这里，很容易得出一个过于整齐的分工：人提出目标，AI 负责组织执行。
\n这可以是某类任务的安排，却不足以描述一个完整的组织，因为目标本身也可能需要被讨论和修正。
\n仍以内容生产为例。假设系统被要求最大化点击率，它可能选择更强烈的表达。但创作者认为，这种表达虽然符合字面要求，却损害了品牌希望建立的关系。
\n此时，问题不是把某个环节做得更准确，而是我们究竟在追求什么？什么代价可以接受？谁有权提出异议？
\n这些问题不能只通过“模型有没有理解指令”来解释。
\nAI 可以帮助比较目标、分析取舍、提出新方向，但这不意味着一个指标一旦被写进系统，就自然获得了代表所有人的资格。
\nPuranam 在另一篇文章中提出，组织设计需要同时关注目标实现，以及人愿意参与其中的社会环境，包括自主性、连接感和能力成长。他并不把后者视为效率之外可有可无的补充。INSEAD Knowledge（在新标签页打开）
\n这提醒我们：人的位置，不应该只剩下系统出现异常时的处理入口。
\n一个创作者应当能够质疑表达方向，而不只是修补画面。一个工程师应当能够指出目标本身的问题，而不只是确认代码是否通过测试。一个成员也应当有机会参与改变规则，而不只是接受越来越精确的任务分配。\n否则，我们可能建设出一种运行顺畅、却不允许参与者影响其方向的工作系统。
\n它完成了更多任务，但是否构成更好的组织，仍然需要回答。
\n《Multi-Agent AI Systems Are Organizations》提出的是一种研究视角，还不是一套已经验证成功的企业改造方案。组织问题有共通之处，怎样解决，仍取决于行动者的特点与具体条件。INSEAD（在新标签页打开）
\n所以，这个系列想先看看那些习以为常的安排：一个审批环节是在补充判断，还是只在传递信息？一次专业交接保护了什么质量，又有多少只是过去工具留下的边界？一个必须由人负责的结果，是否要求所有中间步骤都由人逐一操作？
\n这些问题没有统一答案。AI 能够接走的，是经过授权、可以检验的一部分组织活动；什么样的组织值得建立，仍需要我们共同决定。
\n当软件开始参与安排工作，设计软件的人，也在参与设计组织。除了怎样完成任务，我们还要关心谁能作出决定，谁能纠正决定，以及身处其中的人，是否仍有能力改变工作的方向。
\n一个产品经理可以自己做原型，一个设计师可以让 AI 帮他写前端，一个工程师也能让智能体（Agent）帮他研究用户、分析竞品、生成方案。一个导演甚至可以带着几个生成模型，完成过去需要编剧、美术、摄影、剪辑共同完成的一部分工作。当一个人的能力边界不断扩大，我们为什么还需要团队？
\n“因为 AI 还不够强”是一个很容易想到的答案。今天，它确实不能完全替代设计师、工程师或者导演。但如果我们相信它的能力还会继续增长，这个答案就只是把问题推迟了：等 AI 足够强以后呢？我想从这里往下追问：团队究竟在解决什么问题？
\n在一个没有 AI 的产品团队里，产品经理理解需求，设计师把需求变成体验，工程师把方案变成软件，数据同学观察结果，运营把产品推向用户。需要这么多人，一个直接原因是知识和能力分散在不同的人身上。产品经理不会写所有代码，工程师不一定擅长交互设计，设计师也未必理解模型训练、数据分析或者商业策略。
\n团队因而像一块能力拼图：每个人贡献自己掌握的部分，共同完成一个人做不了的事情。AI 正在改变这块拼图。
\n招聘、外包和专业软件，早已让团队能够使用自己不具备的能力。AI 扩大了这种选择：更多写作、编程和分析任务，可以通过描述目标来启动，获取初步结果的成本也可能下降。
\n今天多了一种选择。不会写前端，可以调用编程 Agent；不擅长视觉设计，可以让模型生成多个方向；不了解一个行业，可以让研究 Agent 搜集资料；身边没有分析师，也可以先让 AI 帮忙探索数据。
\n这些能力还远非完全可靠，但获取能力的方式已经开始变化：不一定要自己掌握，也可以按需调用。传统团队的一部分结构，本来就是围绕谁掌握什么能力建立的，这种变化因而可能比提效影响更深。
\n还需要为了获得某种能力，把一个人长期放进团队吗？这里需要检查的，是团队存在的理由有多少来自能力稀缺；它本身还不是裁员的依据。
\n2026 年发表于《Organization Science》的《The Cybernetic Teammate》，研究了宝洁专业人员完成产品创新任务的表现。这项预注册现场实验，把参与者随机分配到单人或两人团队、可以或不可以使用生成式 AI 的条件。正式发表版（在新标签页打开）
\n在这项任务的表现评价中，使用 AI 的个人与不使用 AI 的两人团队表现相当。使用 AI 的方案也更能兼顾技术与商业考虑。研究同时指出，人类判断对创意的评估和选择仍有价值。
\n这不能推出“一人公司已经到来”。实验研究的是边界清楚的产品创新任务，不是长期经营公司。它给我的启发是：如果 AI 能提供一部分知识互补，团队还有哪些价值需要由人共同完成？
\n过去，这些功能经常被混在“协作”里。现在可以把它们拆开看。
\n你会产品，我会设计，他会工程，大家把能力拼起来完成任务。这一层最容易受到 AI 影响：个人能力半径扩大，过去必须跨岗位完成的事，可能交给一个人和 AI 就能完成。因为“我不会”而产生的协作，也可能减少。
\n两个同样会写代码的人，可能对架构判断不同；两个都懂内容的人，也可能有不同的审美。遇到困难问题，我们常常连正确答案是什么都不知道，这时需要的是另一种看问题的方式。
\nAI 可以生成不同观点、扮演反方。但人的经历、专业训练、利益位置和价值观形成的差异，不会自动因此失去价值。把人放在一起，除了组合技能，也可能是为了让这些差异进入讨论。
\n假设 AI 一次生成 100 个产品方向，接下来要选择哪一个？生成成本下降，并不意味着判断也变得容易。
\n产品要不要做，体验够不够好，点击率更高的内容会不会损害品牌，短期商品交易总额与长期用户关系怎么取舍，都需要信息和模型，也涉及风险偏好、价值选择和对未来的判断。团队的一部分价值，可能由共同生产转向共同判断。
\n长期组织里还有承诺：我们共同选择一个方向，也承担它的后果。项目失败以后，人仍然要面对用户、同事、客户、投资人和彼此，不能像 Agent 一样关闭后再生成一个新方案。
\n“我们决定一起做这件事”，包含了技能组合解释不了的关系。这种承诺需要具体的人和制度来维持。把执行交给 Agent，不会自动转移面对用户、同事和客户的责任。
\n产品写产品需求文档给设计，设计交给工程，工程再找测试，每次交接都需要解释和等待，也可能损失信息。过去我们接受这些成本，因为专业能力分散在不同岗位。
\n如果产品经理已经能做出可运行的演示原型，工程师能理解需求并修改体验，创作者能独立完成从脚本到成片的大部分工作，就值得重新检查这些交接的必要性。
\n这不意味着产品、设计、工程变成了同一个岗位。增加专业判断、带来不同认知，或共同承担高风险决定的协作，仍有价值。更容易被 AI 改变的，是那些只有传递和重复执行、没有增加新判断的交接。
\n过去设计团队，经常先问需要几个产品、设计、前端、后端和算法。我越来越想把问题倒过来：这个团队需要独立完成什么结果？
\n围绕结果，再判断哪些能力需要长期存在，哪些可以从共享平台调用，哪些交给 Agent，哪些判断需要不同专业互相挑战，哪些决定需要共同承担。
\n这样的团队可以把长期协作的成员、Agent、外部专业服务和共享基础设施组合起来。组合是否有效，要看工作依赖是否清楚、结果能否检验，以及增加的协调成本是否值得。
\n人数未必一定减少。AI 降低探索成本，也可能让团队去做过去不敢尝试的事情，需要更多人。需要重新回答的，是每个人为什么属于这个团队。
\n“超级个体”描述了一个有吸引力的场景：一个人带着几十个 Agent，写代码、做产品、生成内容、分析数据、运营公司。个人的生产边界正在扩大。但我不认为，组织最终就应该只剩下一群超级个体。拥有更多能力，不会自动让一个人拥有所有视角。面对不确定性、价值冲突、认知盲区和长期承诺，我们仍然需要一个人无法独自拥有的现实经验。
\n所以我更愿意这样理解未来团队：AI 减少因为能力缺失而被迫发生的协作，让我们把人类协作留给需要不同判断、共同创造和共同承担的地方。团队可能变大，也可能变小。每一次把人放在一起，都应该有一个比“流程规定如此”更好的理由。
\n关于 AI，我们正在同时听到两种故事。一种是能力民主化：不会写代码的人可以做产品，不会设计的人可以生成视觉，没有研究背景的人也能快速进入陌生领域。过去需要多年训练才能跨越的专业门槛，正在降低。另一种是超级个体：优秀工程师可以同时推进多个编程智能体（Agent）任务，成熟创作者可以让自己的审美和方法驱动更多内容生产。一个原本就很强的人，开始拥有过去只有一个团队才有的执行能力。
\n一个像在缩小差距，一个却在扩大差距。我认为两者都可能发生，区别在于 AI 被放在工作的什么位置，以及人获得的是帮助，还是杠杆。
\n先看一个越来越常见的场景。一个产品经理过去想验证一个产品想法，需要先写需求，再找到设计师做页面，再找工程师开发演示原型。今天，他可能直接描述需求，让 AI 生成界面，再用编程 Agent 做出一个可以运行的版本。这不意味着他已经成为专业设计师或者工程师。
\n但有一件事发生了：原来因为“不会”而无法开始的工作，现在可以开始了。这就是 AI 最直观的能力民主化。类似的变化正在不同领域发生。英语不好，不再意味着很难阅读海外资料。不会 SQL，也可以探索数据。没有受过专业视觉训练，也能迅速生成几十种视觉方向。不了解一个行业，可以先让研究 Agent 建立基本认知。
\n过去需要先掌握技能才能开始的事情，现在可以先描述目标，再在执行过程中获得 AI 的帮助。很多传统分工，本来就是围绕专业门槛形成的：一个人做不了，就交给另一个人。当门槛降低，一部分因为“能力缺失”而产生的交接，也会减少。
\n但故事只讲到这里，就会产生一个非常诱人的结论：既然 AI 给每个人相同的能力，人与人的差距应该越来越小。
\n假设两个人同时得到世界上最好的编程 Agent。一个人几乎没有产品经验。另一个人做过十年产品，也理解技术。他们拥有同样的模型和模型调用额度，甚至使用同样的工具。最后的结果会一样吗？很可能不会。
\n因为当执行成本快速下降以后，新的瓶颈开始出现：你让 AI 做什么？什么问题值得解决？什么需求其实是伪需求？什么时候应该继续探索，什么时候应该停止？一个方案看起来不错，究竟哪里不对？AI 可以帮助回答这些问题。但要判断 AI 给出的答案是否值得相信，又需要另一层判断。
\n过去，差距很大程度体现在谁能做出来；未来则可能越来越体现在：谁知道什么值得做，以及什么才算做得好。一些执行任务更容易通过模型和工具获得，问题定义、审美、判断和取舍也因此更值得关注。这里的变化因任务而异，不能从生成一个原型的速度，直接推算可靠交付整个产品的成本。这也是为什么，同一个模型落在不同的人手里，最终可能产生完全不同的杠杆。
\nEnrique Ide 和 Eduard Talamàs 在《Artificial Intelligence in the Knowledge Economy》中，用知识层级模型分析 AI 的分配影响。模型中的人具有不同知识水平和时间约束；AI 可以只帮助人解决问题，也可以自主承担生产任务。论文与作者稿（在新标签页打开）
\n在他们构建的理论模型中，两类 AI 可能产生不同的分配结果。辅助型 AI 更可能帮助原本知识较少的人，填补“我不知道怎么做”的缺口。能够独立执行的 AI，则可能给高知识水平者带来更大杠杆，缓解“我知道该怎么做，但时间有限”的限制。
\n这是一种关于组织和收入分配的理论解释，结果取决于模型中的知识差异、时间约束和 AI 能力。现实产品被称为“助手”或“Agent”，并不足以判断它会带来哪一种分配结果。下文关于问题定义、审美、资源和反馈的讨论，是我对实践的延伸。
\n我们很容易把超级个体想象成一个什么都会的人：产品、设计、代码、运营、内容，技能越装越多。我现在更关心的是，他能让自己的判断驱动多少执行能力。定义问题、判断方向、调用能力，把任务交给 Agent，再检查结果、必要时重新组织执行，这些活动不要求他亲自掌握所有技能，却要求他能判断工作的方向和质量。
\n一个优秀工程师一天仍然只有 24 小时。但如果五个编程 Agent 同时探索不同方案，他的判断就可能作用于五条执行链。一个导演过去需要几十个人把创意变成画面，未来，他的一部分意图可以直接驱动图像、视频、声音与剪辑模型。这里的杠杆，是让一份判断作用于更多执行。它也有上限：并行任务越多，核对结果、处理冲突和纠正错误所需的时间可能越多。能启动多少 Agent，与能可靠地协调多少工作，并不是同一个数字。
\n一个好判断被 Agent 执行一百次，价值可能被放大；一个错误判断被执行一百次，错误也会被放大。过去，一个人的错误受执行速度限制，这个限制正在消失。
\n假设一个内容负责人错误理解了用户。过去，团队一周做十条内容；现在，系统一天就能生成一千条。从生产指标看，效率提高了几十倍；从结果看，却是在更快、更大规模地做错事情。
\n会使用 Agent 之外，还需要一个反馈系统，让人知道自己什么时候错了。判断力不能只被理解成天才直觉。它需要接触用户和数据，接受不同专业的挑战，允许别人说“不”，也让系统暴露失败。没有这些反馈，超级个体也可能只是被 AI 放大的认知偏差。
\n如果 AI 只是个人助手，组织可以先让更多人拥有编程助手、研究 Agent 和数据分析能力。这是能力普惠。
\n当 AI 能自主执行任务，稀缺的东西可能就不只是 Agent：谁可以创建它，调用哪些数据，执行什么真实动作？谁拥有算力，能把自己的方法沉淀成全公司可调用的技能模块，又能同时调度十个、几十个甚至几百个执行单元？
\n这些权限和资源，决定了组织如何分配生产杠杆。表面上“人人都有 AI”，仍然可能存在很大的能力不平等。每个人都有聊天窗口，并不意味着拥有同样的行动能力，就像能使用互联网，也不意味着控制着相同的资本、渠道和组织资源。
\n因此，除了 AI 渗透率，还需要看 AI 杠杆究竟分布在谁手里。
\n企业部署 AI 并不是一条单向路线。沿着前面的讨论，至少可以看到三种方向。
\n第三种方向值得探索，但不能只要求专家贡献方法。谁负责维护、其他人如何检验、贡献者怎样得到回报，都会影响它能否持续。第八篇会专门讨论这些条件。
\n在分配资源时，我会同时观察直接交付和公共能力建设。一个人把排障方法做成工具，另一个人借此解决问题，价值发生在两人的工作之间。组织可以给前者明确的维护时间，给使用者报告错误和提出改进的渠道，再用真实结果决定是否扩大使用。
\n“专家”也不应成为永久免检的身份。更大的资源和权限需要持续反馈；新人的判断经过验证，也应有机会获得更大的行动空间。
\nAI 可能拉平信息获取、基础执行和专业入门的差距，也可能扩大问题定义、判断质量、资源调度，以及把判断规模化的能力差距。对组织来说，能力普惠、专家放大和组织能力公共化，需要放在一起考虑。只有普惠，可能让很多人会用 AI，却没有形成新的优势；只放大专家，可能让组织越来越依赖少数人；只建设公共能力，却没有持续成长的个体，能力的来源也会枯竭。
\n我更期待的，是三者形成一个循环：AI 帮助更多人成长，优秀的人获得更大杠杆，好方法沉淀成公共能力，再帮助更多人成长。这条循环能否成立，要看组织怎样分配 Agent、权限、数据、算力和学习机会。今天的分配方式，已经在决定 AI 最终会拉平哪些差距，又放大哪些差距。
\n假设一个新人刚进入公司，你交给他一个任务：“把这个页面做出来。”
\n通常这还不够。你可能需要继续告诉他需求是什么、采用什么方案、先做什么后做什么、找谁确认，以及什么情况下可以上线。于是，我们写产品需求文档、画流程图、制定标准操作流程、设置审批节点。
\n表面上，这些东西是在管理流程。但换一个角度看，它们其实是在替执行者提前完成一部分判断。
\n这让我最近重新理解了“流程”这件事。AI 时代真正发生变化的，可能不只是流程被自动化，而是过去必须由组织提前规定的“怎么做”，开始可以由执行者在运行时自己决定。
\n如果这个判断成立，我们就需要重新回答一个很基础的问题：AI 时代，我们到底还需要多少固定流程？
\nShishir Mehrotra 在公开的《Establishing Great: PSHE》中使用了 Problem、Solution、How、Execution 这四个词。借用这个划分，我们可以观察一项工作中哪些判断已经确定，哪些还需要执行者自己完成：作者原页（在新标签页打开）
\n一种常见的培养安排，是先给新人明确的问题、方案和方法，让他负责执行；随着经验增加，再把方法、方案乃至问题选择交给他。这里借它说明授权可以怎样变化，并不是说所有职业成长都要沿同一条阶梯前进。
\n所以，一个人的成长并不只是负责范围越来越大，也意味着别人替他完成的判断越来越少。
\n为什么公司需要流程？因为绝大多数执行者，并不能在所有情况下自己完成从发现问题到执行的全部工作。于是组织把优秀员工过去积累的经验写下来：遇到 A 执行 B，完成 B 进入 C，出现 D 升级给负责人；第一步做什么，第二步做什么，第三步找谁确认。这就是标准操作流程，通常简称 SOP。
\n它不只是工作步骤，也是在把过去的判断整理成方法，交给未来的执行者。这样，新人不需要每次重新思考，不同的人可以得到相对稳定的结果，管理者也不需要亲自参与每一次判断。
\n把少数人的经验，变成多数人可以执行的流程，是工业时代组织的一种重要扩张方式。麦当劳、制造业、软件工程都采用了这种方式。流程解决的不只是规范问题，也是在回应一个限制：判断能力无法无限复制。
\n如果执行者本身开始拥有判断能力，会发生什么？
\n早期的 AI 更接近执行者。你告诉它“按照这个需求写代码”“根据这份文案生成图片”“把这份数据整理成表格”，人决定问题、方案和方法，AI 主要负责把它做出来。这种情况下，原来的流程基本不需要改变，我们只是拥有了一个更快的执行者。
\n但今天的编程智能体（Agent）已经越来越不像这样。你可以只告诉它：“这个功能有 Bug，找到原因并修掉。”它会自己阅读代码、搜索相关模块、提出假设、修改实现、运行测试，发现失败之后重新调整。它开始承担一部分选择方法的工作。
\n再往前一步，你告诉研究 Agent：“帮我判断这个市场值不值得进入。”它可能自己拆问题、寻找资料、比较不同解释，再形成几个可能的方案。AI 正从执行逐渐参与到规划和方案判断中。
\n这带来了一个组织问题：如果执行者已经能够自己选择方法，我们为什么还需要把所有做法提前写进标准操作流程？
\n传统工作流由人提前规定方法和路径，机器沿着写好的步骤执行。Agent 则可以获得问题、部分方案、目标与边界，在运行过程中参与选择方法，再完成执行。
\n两者的区别也发生在授权上：过去，具体做法主要由流程设计者决定；现在，其中一部分可以交给正在处理任务的 Agent。决定权由此发生了迁移。
\n一旦决定权发生变化，组织设计就已经发生变化，即使组织架构图、部门和岗位一个都没有动。
\n第一篇用商品视频说明了任务可以怎样重新组合。在这里，我想继续追问流程本身：修改字幕是否需要重新策划，已有素材是否需要再次生成，缺少卖点证据时又是否应该暂停创作？
\n有些步骤保护了质量，有些只是过去按岗位交接留下的安排。先说明每一步在防止什么问题，才能判断它能否调整。
\n“既然 Agent 会规划，以后就不需要流程”，是另一个容易走到的极端。路径可以动态变化，真实的依赖和约束却不会因为 Agent 更聪明而消失。
\n一条商品视频可以跳过重新生成素材，可以先剪辑再补部分内容，也可以让几个 Agent 并行探索。但商品事实必须真实，价格必须正确，版权必须确认，高风险内容必须审核。这些必须满足的条件，与“先写脚本还是先做分镜”所规定的路径不同。
\n重新设计流程时，可以把三个问题拆开：
\n过去，我们经常把三者一起写进标准操作流程。Agent 时代，需要重新把它们拆开。
\n把路径动态化以后，还会遇到一个更深的问题：组织里的任务并不是彼此独立的。
\n假设过去营销每天固定投放 100 个商品，供应链知道大概需要准备多少库存，客服也能预估咨询量。这个系统未必局部最优，但因为大家相对稳定，所以容易协调。
\n现在 AI 可以实时预测哪个商品今天值得突然放大十倍流量。从营销视角看，这是更聪明的决策。但如果库存、物流、客服没有同时变化，局部更聪明反而可能制造系统问题。
\n所以，除了追求每一个 Agent 更聪明，还要分清哪些决定可以独立变化，哪些必须一起变化。
\n如果两个任务之间存在强依赖，就不能因为 Agent 可以自主规划，就假装它们已经解耦。
\n这也是为什么未来的组织设计，可能越来越像软件工程里的接口设计。
\n好的模块不是彼此完全不知道对方，而是清楚地定义：我给你什么、你返回什么、什么算成功、什么情况下失败、发生异常以后由谁处理。
\n组织也是如此。人与人、团队与团队、人与 Agent、Agent 与 Agent 之间，都需要越来越明确的接口，而不是越来越多的人同时参与所有信息。
\n我越来越倾向于把这种变化理解为：从标准操作流程，走向明确的行动规则与授权边界，也就是这里所说的 Policy。
\n标准操作流程告诉执行者先做 A，再做 B，出现 D 就找负责人。行动规则则说明目标是什么、什么不能做、结果必须满足哪些条件、可以使用什么资源和权限，以及何时必须升级给人。具体路径，可以根据现实动态生成。
\n执行者先理解目标与当前情况，检查依赖和约束，再制定计划、采取行动，根据反馈重新规划。流程仍然存在，只是从预先规定每一步，逐渐转向规定边界，让路径动态生成。
\n两种安排对执行者的假设也不同：前者主要告诉执行者怎么做，后者承认执行者拥有一定判断能力，但要求它在明确边界内行动。规则引擎和自动化系统早已能按条件选择路径。Agent 增加的可能，是在边界内处理更多难以事先枚举的情况；这也增加了验证、观察和处理例外的要求。
\n“Agent 可以自行处理低风险问题”还不够具体。以退款为例，规则至少要说明可处理的订单类型、所需证据、金额范围、重复请求的处理方式，以及退款失败后由谁接手。这些条件需要由负责该业务的人确认。
\n在满足规则时，系统可以选择怎样收集信息；证据冲突、工具失败或超出授权时，则需要停止相关动作并转交明确的负责人。授权如何分配，留到第六篇展开；这一篇先把规则写到人和系统能够共同检查的程度。
\n如果 AI 从执行走向选择方法和方案，是不是最后人只剩下发现问题？再有一天，AI 连问题都能发现，人就没有位置了？我不这么理解。
\n“应该解决什么问题”并不是凭空出现的，它往往来自用户、市场、战略、价值观，以及组织所处的现实。很多问题之间还存在冲突：提高商品交易总额，还是保护长期用户体验？提高生产效率，还是给新人保留成长机会？更激进地使用数据，还是保护隐私？
\n工作也不是从问题、方案、方法一路走到执行就结束了。执行会改变现实，反馈又会让我们重新定义问题。因此，人未必需要永远守住 PSHE 中的某一层，而要参与整个循环，并保有质疑目标、修正问题和重新定义方向的能力。
\n这比“AI 负责执行，人负责思考”更准确。AI 也可以思考、规划和提出问题。真正需要讨论的是：哪些判断可以授权，哪些判断必须共同形成，以及最终谁有权改变目标。
\n传统管理者很擅长处理一类问题：流程怎么设计？哪里增加审核？谁向谁汇报？出了问题补什么标准操作流程？
\nAI 时代，管理者还需要追问：这个任务究竟要解决什么问题？哪些方案可以让系统探索？哪些做法不值得提前规定，哪些执行可以完全自动化？什么约束绝不能突破，Agent 有权决定什么，又有哪些反馈会触发重新规划？
\n这些问题指向的，是边界内的自由。
\n自由度需要与任务相称。稳定、规则完整的工作，固定流程可能更经济；变化多、又能及时验证的工作，才更值得给执行者选择路径的空间。
\n真正好的设计，是找到那个边界：让执行者拥有足够的判断空间，同时让组织仍然能够控制不可接受的风险。
\n所以未来管理者最重要的能力之一，可能不是把流程设计得越来越完整，而是知道：什么应该固定，什么应该留白；什么可以动态决定，什么必须升级；哪些自由应该交出去，哪些责任必须同时跟上。
\n当然需要。只是越来越多时候，流程除了规定下一步怎么做，还需要说明谁有权决定下一步、依据什么事实、遵守什么边界，以及何时交给别人、怎样获得反馈。
\n从规定操作步骤到明确行动规则，从控制每一步到划分决定权，讨论的都是这件事：当执行者具备更多判断能力，组织应该提前规定多少，又该留下多少空间。
\n我想保留的并不是“流程越少越好”这个结论。能写清的依赖和约束仍要写清，需要人承担的责任仍要有人承担。在此基础上，把目标、边界和反馈设计好，让执行者有机会根据现实调整路径。
\n想象一个普通项目。周一，工程师在群里说：“接口应该周三能完成。”周二的项目会上，负责人说：“目前看问题不大。”到了周三，智能体（Agent）自动生成状态：
\n\n\n接口开发：进展正常，截止时间为周三。
\n
管理者没有介入，另一个团队也按周三完成来安排工作。但工程师最开始说的只是“应该”，既没有正式承诺，也没有确认依赖是否解决。
\n一句带有不确定性的话，从群聊传到会议，再经 AI 摘要写入项目状态，逐渐获得了“组织事实”的外观。没有人在撒谎，组织却已经依据一个并不存在的确定性行动。
\n这让我觉得，当 AI 开始替组织理解正在发生什么，知识管理之外还有一个问题要回答：谁有权定义什么是真的？
\n我们习惯说数据驱动、统一可信的信息来源、组织知识库。但在复杂组织里，同一个项目往往有好几种状态：工程师认为核心功能已经完成，只差联调；产品经理认为还不能验收；管理者从周报里看到进展正常；业务方却觉得已经延期。
\n这些人可能都没说错，只是描述了不同维度、时间点和定义下的事实。信息散落在聊天、会议、文档、代码、数据和人的记忆里，需要判断时，大家才聚到一起：“对一下现在到底什么情况。”
\n很多会议做的就是重新拼出一个大家暂时接受的现实。决策还要在这之后。
\nAgent 可以持续读取群聊、会议纪要、项目文档、代码提交和业务数据，从中抽取决定、行动、风险、依赖、指标、里程碑与变化。
\n项目看板、监控和业务系统本来就在维护状态。AI 带来的增量，是有机会把群聊、会议和文档中的非结构化信息也整理进来，让更新更频繁、覆盖更广。前提是信息可访问、含义能被理解，而且系统知道哪些更新需要进一步确认。
\n当组织状态能够持续更新，周报可能只是呈现它的一种方式，不再是每周重新拼凑出的结果。
\n假设 Agent 生成一句判断：“项目 A 当前存在 P1 延期风险。”如果只是给人阅读，错误可能表现为理解偏差；如果系统据此调整资源、通知团队、改变优先级、触发升级，甚至让其他 Agent 修改计划，这句话就在驱动行动了。
\n我关心的是这类状态怎样成为组织实际据以行动的现实。
\n第四篇讨论了如何根据目标、当前情况和约束来动态规划并采取行动。这里要继续追问：系统掌握的情况从哪里来？假如它错了，后面的规划越有效，错误就越快进入执行。因此，Agent 可能需要一个可信的状态层，告诉它现在究竟发生了什么。
\n“应该可以”“感觉问题不大”“基本完成”“大家好像都同意”“客户应该能接受”——人在沟通中常用这些表达，也通常知道它们还没有得到完全确认。
\n但把信息压缩成结构化状态时，这层不确定性很容易丢掉：
\n我愿意把这种变化叫作“推断洗白”。一条推断经过几次摘要、转述和结构化，最终看起来像事实。Agent 需要推断，人也每天都在推断。问题出在传递过程中，我们忘记了它原来只是一个推断。
\n如果让 AI 维护组织状态，不能把所有记录都笼统称为事实，至少需要区分：
\n承认不知道，也是组织 AI 需要具备的能力。
\n过去建立统一的信息来源，常常是找一份文档、一个看板或项目主页，告诉大家“以后以这里为准”。我现在更关心的是，重要状态能否一路追到原始证据：从 AI 摘要找到对应的项目状态，再查到相关决定、指标或事件，以及支持它们的原始记录。
\n系统说“项目延期概率很高”，我应该能继续问为什么。它说三个依赖事项没有完成，就应该能点开看是哪三个、谁说的、什么时候说的、后来有没有更新。
\n如果找不到原始证据，这个状态就不应该获得很高的可信度。我们需要的，是让重要判断可以回到证据的系统，而不是一份被当成永远正确的总结。
\n即使拥有更多数据，组织里的重要问题也未必能变成数据库中的客观字段。产品体验好不好、员工表现如何、项目是否值得继续、风险是否严重，都同时涉及事实、标准和价值。
\n比如，日活跃用户数下降 10% 可以是事实；“产品正在失败”是对事实的解释；“应该砍掉这个项目”则是决定。AI 可以参与这三层，但不能把它们混成“数据表明，我们应该关闭项目”。从数据走到“应该”，中间存在判断标准和价值选择。谁能定义这些标准，本身就是一种组织权力。
\n除了管多少人、控制多少预算、拥有哪些审批权，AI 时代还可能出现一种需要认真对待的权力：谁可以写入、确认和修改组织状态。
\nAgent 记录“项目存在重大风险”，负责人可以直接删除，还是只能补充证据？两个团队对同一个依赖事项意见相反，谁来确认？高层说项目没问题，数据却显示风险很高，系统应该记录什么？
\n这些问题超出了知识库权限管理的范围，涉及整个组织共同依据的现实。当组织状态开始影响决定、资源分配和后续行动，能够修改状态的人，也就在影响这些环节。
\n我不赞成让组织记忆追求一个完美、统一、没有冲突的答案。产品认为已经就绪，工程认为还不具备条件，业务要求马上上线，风控认为风险不可接受，这些分歧本来就存在。
\n系统应该能够保留它们，而不是选一个“最可能正确”的观点覆盖其余观点。例如：
\n\n\n是否具备上线条件：仍有争议。产品依据验收记录认为功能已就绪；工程认为容量条件尚未满足；风控仍在核对相关风险。三项记录各自保留来源和更新时间。
\n
这里需要组织明确谁来复核、何时处理，以及在争议解除前哪些动作可以继续。记录被修正时，旧状态也应留下变更原因，让已经依据它作出决定的人得到通知。AI 可以帮助暴露分歧，谁有权关闭争议仍需要制度安排。
\n知识库回答“我们知道什么”，组织记忆保留“过去发生过什么”。在这之上，AI 原生组织可能还需要一套持续维护当前状态的机制。
\n它需要说明刚发生了什么变化，哪些事实已经确认、哪些只是推断，哪里有冲突，哪些决定还在等待，以及什么事件应该触发行动。
\n组织也就有机会从主要按照日程推进工作，转向由重要事件及时触发响应。除了周一周会、月底复盘和季度回顾，系统可以持续维护状态，在出现重大风险、状态冲突、决策逾期、依赖事项受阻或异常指标时，及时把人的注意力拉进来。
\n读取聊天、会议、文档、代码和数据来重建状态，很容易带来另一个诱惑：是不是也能知道每个人每天干了什么？
\n技术上越来越容易做到，组织上却可能走错方向。可观测性不等于监控。我们需要观察项目状态、风险、依赖、决定和结果；员工几点开始工作、发了多少消息、写了多少代码、调用了多少次 AI，并不能代替这些信息。
\n如果组织记忆最后成了员工监控系统，成员就会转而管理自己的数字痕迹。数据越来越多，真实工作却可能越来越难看清。
\n让工作状态透明，而不是让人成为透明人。这是我想保留的一条边界。
\n可靠的组织事实，不能仅凭管理者、数据库或 AI 的身份来决定。它需要一个形成和修正的过程：先收集并解释证据，经过确认再写入状态，并在出现新信息时修正。
\nAI 可以收集证据、发现冲突、提出推断和维护状态。关键事实仍需要明确的来源、可信度、责任人与修正机制，也必须允许被挑战。暂时不知道答案，可以继续调查；错误答案一旦获得事实的权威，就可能带着组织走向错误的行动。
\n第四篇讨论谁可以决定下一步，这一篇追问决定所依据的现实。决定权规定谁可以行动，维护状态的权力则影响行动依据什么现实。可信的组织状态、清楚的授权和反馈，需要一起工作，系统才有条件维护状态，人也才能把注意力放在需要判断的地方。但信息更透明，并不保证权力更分散。下一篇接着讨论：组织变扁了，权力为什么还可能更集中？
\n","searchText":"想象一个普通项目。周一，工程师在群里说：“接口应该周三能完成。”周二的项目会上，负责人说：“目前看问题不大。”到了周三，智能体（Agent）自动生成状态：\n\n> 接口开发：进展正常，截止时间为周三。\n\n管理者没有介入，另一个团队也按周三完成来安排工作。但工程师最开始说的只是“应该”，既没有正式承诺，也没有确认依赖是否解决。\n\n一句带有不确定性的话，从群聊传到会议，再经 AI 摘要写入项目状态，逐渐获得了“组织事实”的外观。没有人在撒谎，组织却已经依据一个并不存在的确定性行动。\n\n这让我觉得，当 AI 开始替组织理解正在发生什么，知识管理之外还有一个问题要回答：谁有权定义什么是真的？\n\n## 一、过去，组织其实没有一个统一的“现实”\n\n我们习惯说数据驱动、统一可信的信息来源、组织知识库。但在复杂组织里，同一个项目往往有好几种状态：工程师认为核心功能已经完成，只差联调；产品经理认为还不能验收；管理者从周报里看到进展正常；业务方却觉得已经延期。\n\n这些人可能都没说错，只是描述了不同维度、时间点和定义下的事实。信息散落在聊天、会议、文档、代码、数据和人的记忆里，需要判断时，大家才聚到一起：“对一下现在到底什么情况。”\n\n很多会议做的就是重新拼出一个大家暂时接受的现实。决策还要在这之后。\n\n## 二、AI 让更多分散信息有机会进入当前状态\n\nAgent 可以持续读取群聊、会议纪要、项目文档、代码提交和业务数据，从中抽取决定、行动、风险、依赖、指标、里程碑与变化。\n\n项目看板、监控和业务系统本来就在维护状态。AI 带来的增量，是有机会把群聊、会议和文档中的非结构化信息也整理进来，让更新更频繁、覆盖更广。前提是信息可访问、含义能被理解，而且系统知道哪些更新需要进一步确认。\n\n当组织状态能够持续更新，周报可能只是呈现它的一种方式，不再是每周重新拼凑出的结果。\n\n## 三、因为 AI 摘要一旦驱动行动，它就不再只是“摘要”\n\n假设 Agent 生成一句判断：“项目 A 当前存在 P1 延期风险。”如果只是给人阅读，错误可能表现为理解偏差；如果系统据此调整资源、通知团队、改变优先级、触发升级，甚至让其他 Agent 修改计划，这句话就在驱动行动了。\n\n我关心的是这类状态怎样成为组织实际据以行动的现实。\n\n第四篇讨论了如何根据目标、当前情况和约束来动态规划并采取行动。这里要继续追问：系统掌握的情况从哪里来？假如它错了，后面的规划越有效，错误就越快进入执行。因此，Agent 可能需要一个可信的状态层，告诉它现在究竟发生了什么。\n\n## 四、最危险的不是 AI 不知道，而是 AI 把“推断”写成了“事实”\n\n“应该可以”“感觉问题不大”“基本完成”“大家好像都同意”“客户应该能接受”——人在沟通中常用这些表达，也通常知道它们还没有得到完全确认。\n\n但把信息压缩成结构化状态时，这层不确定性很容易丢掉：\n\n- “应该周三完成”被记成“截止时间：周三”。\n- “目前没看到问题”被记成“风险：无”。\n- “大家倾向方案 A”被记成“已决定采用方案 A”。\n\n我愿意把这种变化叫作“推断洗白”。一条推断经过几次摘要、转述和结构化，最终看起来像事实。Agent 需要推断，人也每天都在推断。问题出在传递过程中，我们忘记了它原来只是一个推断。\n\n## 五、组织事实至少应该区分三种状态\n\n如果让 AI 维护组织状态，不能把所有记录都笼统称为事实，至少需要区分：\n\n- **已确认。** 在明确范围和时间内，有可追溯证据支持，并经过所需的核对。例如，“支付接口已经上线”，可以用发布记录和对应环境的监控核对。人的确认应保留依据；“负责人说没问题”不能直接覆盖相反证据。\n- **推断。** Agent 根据多条证据推测出的状态，可以辅助判断，但必须让使用者知道它还不是事实。例如，“项目可能延期”，依据是连续三天没有代码提交、两个依赖事项未完成，以及负责人在会议中表达了担忧。\n- **未知。** 证据不足或暂时无法判断时，保留缺口。证据之间有冲突，则同时留下争议双方及各自依据，不能用一句“大概率……”替它们作出裁定。\n\n承认不知道，也是组织 AI 需要具备的能力。\n\n## 六、可信的依据，需要一条可以追溯的证据链\n\n过去建立统一的信息来源，常常是找一份文档、一个看板或项目主页，告诉大家“以后以这里为准”。我现在更关心的是，重要状态能否一路追到原始证据：从 AI 摘要找到对应的项目状态，再查到相关决定、指标或事件，以及支持它们的原始记录。\n\n系统说“项目延期概率很高”，我应该能继续问为什么。它说三个依赖事项没有完成，就应该能点开看是哪三个、谁说的、什么时候说的、后来有没有更新。\n\n如果找不到原始证据，这个状态就不应该获得很高的可信度。我们需要的，是让重要判断可以回到证据的系统，而不是一份被当成永远正确的总结。\n\n## 七、但有证据，也不意味着只有一个“真相”\n\n即使拥有更多数据，组织里的重要问题也未必能变成数据库中的客观字段。产品体验好不好、员工表现如何、项目是否值得继续、风险是否严重，都同时涉及事实、标准和价值。\n\n比如，日活跃用户数下降 10% 可以是事实；“产品正在失败”是对事实的解释；“应该砍掉这个项目”则是决定。AI 可以参与这三层，但不能把它们混成“数据表明，我们应该关闭项目”。从数据走到“应该”，中间存在判断标准和价值选择。谁能定义这些标准，本身就是一种组织权力。\n\n## 八、真正的权力，可能越来越表现为“谁能修改组织状态”\n\n除了管多少人、控制多少预算、拥有哪些审批权，AI 时代还可能出现一种需要认真对待的权力：谁可以写入、确认和修改组织状态。\n\nAgent 记录“项目存在重大风险”，负责人可以直接删除，还是只能补充证据？两个团队对同一个依赖事项意见相反，谁来确认？高层说项目没问题，数据却显示风险很高，系统应该记录什么？\n\n这些问题超出了知识库权限管理的范围，涉及整个组织共同依据的现实。当组织状态开始影响决定、资源分配和后续行动，能够修改状态的人，也就在影响这些环节。\n\n## 九、因此，AI 时代的组织记忆必须允许“争议”\n\n我不赞成让组织记忆追求一个完美、统一、没有冲突的答案。产品认为已经就绪，工程认为还不具备条件，业务要求马上上线，风控认为风险不可接受，这些分歧本来就存在。\n\n系统应该能够保留它们，而不是选一个“最可能正确”的观点覆盖其余观点。例如：\n\n> 是否具备上线条件：仍有争议。产品依据验收记录认为功能已就绪；工程认为容量条件尚未满足；风控仍在核对相关风险。三项记录各自保留来源和更新时间。\n\n这里需要组织明确谁来复核、何时处理，以及在争议解除前哪些动作可以继续。记录被修正时，旧状态也应留下变更原因，让已经依据它作出决定的人得到通知。AI 可以帮助暴露分歧，谁有权关闭争议仍需要制度安排。\n\n## 十、从知识库，到组织状态机\n\n知识库回答“我们知道什么”，组织记忆保留“过去发生过什么”。在这之上，AI 原生组织可能还需要一套持续维护当前状态的机制。\n\n它需要说明刚发生了什么变化，哪些事实已经确认、哪些只是推断，哪里有冲突，哪些决定还在等待，以及什么事件应该触发行动。\n\n组织也就有机会从主要按照日程推进工作，转向由重要事件及时触发响应。除了周一周会、月底复盘和季度回顾，系统可以持续维护状态，在出现重大风险、状态冲突、决策逾期、依赖事项受阻或异常指标时，及时把人的注意力拉进来。\n\n## 十一、但这里有一条非常重要的边界：组织记忆不能变成组织监控\n\n读取聊天、会议、文档、代码和数据来重建状态，很容易带来另一个诱惑：是不是也能知道每个人每天干了什么？\n\n技术上越来越容易做到，组织上却可能走错方向。可观测性不等于监控。我们需要观察项目状态、风险、依赖、决定和结果；员工几点开始工作、发了多少消息、写了多少代码、调用了多少次 AI，并不能代替这些信息。\n\n如果组织记忆最后成了员工监控系统，成员就会转而管理自己的数字痕迹。数据越来越多，真实工作却可能越来越难看清。\n\n让工作状态透明，而不是让人成为透明人。这是我想保留的一条边界。\n\n## 十二、谁有权定义组织的事实？\n\n可靠的组织事实，不能仅凭管理者、数据库或 AI 的身份来决定。它需要一个形成和修正的过程：先收集并解释证据，经过确认再写入状态，并在出现新信息时修正。\n\nAI 可以收集证据、发现冲突、提出推断和维护状态。关键事实仍需要明确的来源、可信度、责任人与修正机制，也必须允许被挑战。暂时不知道答案，可以继续调查；错误答案一旦获得事实的权威，就可能带着组织走向错误的行动。\n\n第四篇讨论谁可以决定下一步，这一篇追问决定所依据的现实。决定权规定谁可以行动，维护状态的权力则影响行动依据什么现实。可信的组织状态、清楚的授权和反馈，需要一起工作，系统才有条件维护状态，人也才能把注意力放在需要判断的地方。但信息更透明，并不保证权力更分散。下一篇接着讨论：组织变扁了，权力为什么还可能更集中？","headings":[{"id":"section-1","title":"一、过去，组织其实没有一个统一的“现实”","level":2},{"id":"section-2","title":"二、AI 让更多分散信息有机会进入当前状态","level":2},{"id":"section-3","title":"三、因为 AI 摘要一旦驱动行动，它就不再只是“摘要”","level":2},{"id":"section-4","title":"四、最危险的不是 AI 不知道，而是 AI 把“推断”写成了“事实”","level":2},{"id":"section-5","title":"五、组织事实至少应该区分三种状态","level":2},{"id":"section-9","title":"六、可信的依据，需要一条可以追溯的证据链","level":2},{"id":"section-10","title":"七、但有证据，也不意味着只有一个“真相”","level":2},{"id":"section-11","title":"八、真正的权力，可能越来越表现为“谁能修改组织状态”","level":2},{"id":"section-12","title":"九、因此，AI 时代的组织记忆必须允许“争议”","level":2},{"id":"section-13","title":"十、从知识库，到组织状态机","level":2},{"id":"section-14","title":"十一、但这里有一条非常重要的边界：组织记忆不能变成组织监控","level":2},{"id":"section-15","title":"十二、谁有权定义组织的事实？","level":2}],"readingMinutes":8,"characterCount":3024,"images":[{"src":"images/s01-05.svg","thumb":"images/s01-05.svg","alt":"一条组织状态，怎样才可信？","width":1000,"height":700,"description":"原始证据应记录来源、时间和责任人。形成状态时，分别标记已确认、推断或未知：已确认有明确依据，推断保留解释与不确定性，未知说明证据缺失或冲突，留下争议意见并继续核对。使用状态时携带标签和证据。受影响的人可以提出异议并附上新证据，由指定责任人复核、纠错、保留修改记录并通知受影响的使用者。新证据再更新状态，不能直接覆盖仍存在的分歧。"}],"sourceHash":"2bb2b2723b606ec673000daffdd5d9e2ac58671d807c5edc677446efca6542a7","description":"想象一个普通项目。周一，工程师在群里说：“接口应该周三能完成。”周二的项目会上，负责人说：“目前看问题不大。”到了周三，智能体（Agent）自动生成状态："},{"id":6,"title":"组织变扁了，权力却可能更集中","file":"06-decision-rights.md","published":"2026-09","part":1,"tag":"决定权","html":"智能体（Agent）接走协调工作，中层减少；一线员工能力增强，小团队可以端到端完成更多事情；信息自动同步，不再需要层层汇报。这些变化，让“AI 会使组织更扁平”听起来很合理。但层级减少，真的等于权力下放吗？
\n想象一家拥有完善 AI 系统的公司。CEO 不用每天听十个 VP 汇报，只要问组织管理 Agent：“昨天最重要的五个变化是什么？”系统就能列出延期项目、异常指标、资源冲突和卡住的决定。他再问项目 A 为什么延期，Agent 就调出会议、群聊、代码、数据和项目状态；他想知道调过去两名工程师会怎样，系统还能模拟影响。
\n过去，一个 CEO 很难理解几百个项目的实时细节。未来如果能够做到，组织图上即使只剩两三层，重要决定也可能更容易集中到少数人手里。
\n我们经常用“相信员工”“让听得见炮火的人做决定”来解释分权。从组织经济学角度看，还有一个现实原因：上面的人不知道。
\n一家全国性的零售公司，总部不可能知道每家门店今天发生了什么。CEO 也不可能理解每个客户、每段代码、每次供应异常。信息在现场，很多决定就需要交给离问题最近的人。
\n知识往往掌握在现场的人手里，这是分权的一个基础。中层和本地负责人除了管理人，还了解总部无法实时获得的现场情况。
\n第五篇讨论了组织状态。聊天、会议、文档、代码和数据，可以进入一个持续更新的组织状态。项目负责人过去的一项优势，是知道现场发生了什么；未来，这些信息越来越可能被 AI 编码、汇总、解释并向上提供。
\n一部分现场知识可以被整理成更广泛可读的记录。但未被说出、无法量化或依赖当时情境的知识，仍可能留在现场；记录更完整，也不等于中心理解了全部现实。
\nBrynjolfsson 与 Hitzig 在《AI’s Use of Knowledge in Society》中提出一个产权理论框架：如果 AI 能把部分本地知识转为可传递的信息，并增强中心的信息处理能力，现场决定者的一部分信息优势就可能减弱。这个推论取决于知识能否有效转移，也不排除仍需分权的情形。NBER 章节（在新标签页打开）
\nAI 因而可能同时带来两种变化：一线更聪明，中心也看得更清楚。
\nBloom、Garicano、Sadun 和 Van Reenen 在 2014 年发表的研究中，区分了让员工自行获得知识的信息技术，与降低上下级联系成本的通信技术。它们与自主权的关系并不相同。
\n能够帮助一线直接获得知识、自己解决问题的技术，与更大的自主权相关；而降低人与上级沟通成本的技术，则可能让员工更容易请求上级指令，从而与更集中的决策相关。研究及发表记录（在新标签页打开）
\n研究对象是 ERP、CAD/CAM 和数据网络等技术，并非生成式 AI。这里借用的是分析问题的线索，不能直接把它的结论搬到今天。
\n我们可以把 AI 的两种能力拆开看。一方面，一线员工拥有 Agent、数据、知识和工具，能够自己解决过去需要请示上级的问题，由此获得更多自主权。另一方面，管理者可以看到更多项目状态、了解更多背景、比较更多方案，甚至直接指挥执行 Agent，这也可能让决策更集中。
\n只问组织会不会更扁平，还不足以解释这两种变化。需要继续追问：AI 到底增强了谁的能力？
\n我担心的一种情况是：公司减少汇报层级、取消大量中层，让小团队端到端负责；与此同时，所有状态和指标进入统一系统，高层可以随时查看项目、理解上下文，并直接下达任务。
\n信息传递的层级减少了，决定权却集中起来了。过去，中层承担的一部分判断、过滤和缓冲，随着信息摩擦一起消失。AI 扩大了最高负责人的注意力覆盖范围，让一个人能够看见更多组织活动。
\n组织可能从层级很多、决策分散，走向层级很少、决策高度集中。后一种结构在图上更扁，权力却未必更分散。
\n一个中层通常同时承担信息汇总、进度追踪、任务协调、资源分配、专业判断、冲突解决和人才培养。AI 对这些工作的影响并不相同。
\nGulati、Marchetti 与 Puranam 研究了美国企业在 2010—2019 年采用协作工作管理技术的变化，用“管理者监督能力”和“员工需要多少监督”之间的关系解释层级变化。论文于 2026 年发表，但对象并非今天的生成式 AI；这里借用的是它拆解管理功能的视角。正式发表版（在新标签页打开）
\n所以，中层岗位更可能发生内部重构。收集信息、同步状态和追踪流程，更容易进入系统；判断、资源配置、冲突解决和人才成长，则需要重新设计。仅用“是否还需要管理者”描述这个变化，会漏掉岗位内部的差别。
\n即使整个公司拥有同一套可信的组织状态，也不会自然得到更好的权力安排。知道发生了什么，与拥有决定权是两回事。
\nAgent 可以让 CEO 和一线员工同时看到“项目 A 出现 P1 风险”。接下来，负责人能直接调整计划吗？需要 VP 批准吗？CEO 能随时覆盖负责人的决定吗？Agent 能自动调资源吗？什么情况下需要升级？这些安排，才把共享信息变成了实际的组织权力。
\n除了汇报关系，组织还需要说明每类决定由谁作出，以及授权在什么条件下成立。例如：
\n同一张决定权地图，还应写明谁能提出异议、谁负责复核，以及复核期间是否暂停执行。上级覆盖一线决定时，也应记录依据和适用范围，避免授权在口头上存在、每次遇到分歧却被收回。
\n信息可见性和权限要分别维护。能查看全部订单，并不意味着可以修改所有价格；能够指出规则有问题，也应有明确渠道把意见交到能修改规则的人手里。
\n过去，我们经常用 CEO 到一线有几层来判断组织是否扁平。我现在更关心的是：一个真实问题出现以后，拥有足够信息且有权行动的人，离这个问题有多远？
\n如果项目团队掌握全部信息，却每个决定都必须等 CEO，组织图再扁，也不是分权。反过来，一家公司即使有多个专业层级，只要一线团队在明确边界内拥有真实的决定权，也可能有更强的局部自主性。
\n扁平不等于分权。比起汇报层级的多少，我更想看问题能否交到有条件作出决定的人手里，以及这中间需要经过多远的距离。
\n走到这里，也许不必在集权与分权之间二选一。我更感兴趣的是：能否让公司层面和一线团队的能力同时增强。
\n中央拥有更完整的组织状态、更强的资源调度和战略判断能力，用来定义方向、资源边界、行动规则和少数高杠杆决定；一线团队拥有更强的 Agent、更完整的背景信息和明确的自主空间，在边界内感知、判断、执行和反馈。
\n中心知道得更多，不必因此接管全部决定。这也是第四篇“边界内的自由”在组织层面的展开。
\n没有必然答案。AI 可以让知识向下流动，让一线有能力独立解决问题；也可以让信息向上汇聚，让少数人理解和控制更大的组织范围。决定最后走向的，是组织怎样分配决定权。
\n我更想问管理者的是：AI 让我们看见更多以后，能不能忍住替所有人做决定的冲动？有能力介入，不意味着每次都应该介入。能力不等于权限，这一点同样适用于人。
\n不必把所有权力下放，也不必让一个超级 CEO 控制所有 Agent。每一个决定，都应尽可能交给掌握足够信息、承担相应责任，同时最接近问题的位置。透明之后是一线获得更多自主权，还是中心获得更多控制权，这仍然是组织的选择。
\n“没关系，最后有人审核。”
\n这句话听起来让人安心，我却越来越想追问：那个审核的人，实际能控制什么？假设一个智能体（Agent）每天审核 10 万条商品内容，绝大部分自动通过，只有高风险内容交给运营。管理者看到准确率不错，逐渐扩大自动执行范围。某一天，一条严重违规内容被判断为安全并自动发布，组织开始寻找责任人。算法团队说，模型只是给出判断；产品说，规则由业务定义；业务说，每天这么多内容，不可能逐条人工审核。最后，责任落到了系统里那个名义上的审核者身上。
\n流程上，他是最终负责人。实际上，他每天面对几千条 AI 作出的决定，没有时间了解完整的相关信息和背景，没有参与模型和行动规则的设计，也无法阻止系统的大部分自动行为。他承担责任，却缺少相应的信息、判断能力和权限。
\n这个人究竟在监督系统，还是只被放在系统最后，用来承担后果？
\n过去，医生看影像、编辑审文章、工程师发布代码、管理者批准预算，判断和行动都由人完成，责任相对容易理解。Agent 则可能接过观察、规划和行动，把人放到最后的审核环节。
\n表面上，人仍然参与其中。但当自动执行的数量已经超过审核者能够认真处理的范围，大量决定实际上就不会经过逐项人工审核。界面上保留一个负责人，不能弥补处理能力的缺口。
\n人已经从参与每个决定，转为监督系统的运行。如果直到事故发生后才看到结果，甚至连及时监督都谈不上了。
\n因此，除了有没有人工审核，还要看：人在什么时候介入，看到了什么，能够改变什么？
\n我越来越觉得，一个人真正承担责任，至少需要三个条件同时成立。
\n这三个条件彼此依赖，缺少任何一个，名义上的负责人都可能无法真正负责。
\n仅仅强调“人在执行环节中”，容易把所有任务都安排成 AI 先做、再由人确认。但生成一张内部会议封面，与自动退款 10 万元，不应该使用同一种监督机制。
\n需要设计的是人在什么条件下、以什么方式介入系统，至少可以分成四层：
\n这接上了第六篇的决定权分配。除了 AI 能不能做，还需要从四个维度判断一项决定应该交给谁：
\n这些维度需要一起看。单次金额很小的自动退款，累计起来仍可能造成明显损失；可以回滚代码，也不代表已经泄露的信息能够收回。选择介入方式时，还要考虑频率、累计影响和发现错误所需的时间。
\n为了安全，很多组织会要求所有 AI 输出都经过人工确认。但当 Agent 持续增加，这种安排会超出人的处理能力。假设一个人管理 20 个 Agent，每个 Agent 每小时产生 20 个决定，一天就有几千次确认。审核很容易变成机械地点击确认，直到事故发生。
\n自动化监督中存在一种风险：系统长期表现正常，人可能降低警觉，更少主动核对依据。大量低风险决定都要求点击确认，也会把真正高风险的决定淹没在噪声里。增加审核次数，未必增加监督强度。人的注意力应该留给值得独立判断的地方。
\n执行越来越便宜，决定的数量也可能随之增长。过去，一个团队一天做 20 个决定；未来，100 个 Agent 可能每天做 10 万个微型决定。一个成熟专家每天能深度判断的问题，也许只有几十个。此时稀缺的未必是模型调用额度或算力，而是人的注意力。
\n让机器处理确定性和可逆决定，让系统暴露异常，把冲突、不确定性、高风险和价值选择带到人面前，才能让有限的注意力用于值得判断的地方。第二篇讨论减少低价值协作，这里还需要减少低价值的人工确认。
\n系统写着“负责人：张三”，出事就找张三。但他没有选择模型、定义行动规则的权力，不知道 Agent 依据了哪些信息，无法修改执行逻辑或暂停系统，甚至没有足够时间检查结果。这样的责任分配并不公平。
\n责任需要跟着控制权走。Agent 的行为由模型、数据、行动规则、工具权限和平台机制共同决定，就不能把责任全压在最后点击“确认”的人身上。
\n因此，责任分配需要沿系统结构说明：谁定义目标，谁制定行动规则，谁提供数据，谁授予权限，谁有权干预并改变已有决定，又由谁持续监控。
\n以开头的内容事故为例，需要先指定一位有权暂停发布并组织处置的人，撤下相关内容、保留当时的证据与规则版本，再分别核查模型判断、规则设计和授权过程。恢复运行也应有人明确批准，不能把一次重新点击“通过”当成问题已经解决。这里讨论的是组织内部的职责设计；具体法律责任仍取决于适用规则和事件事实。
\n传统管理者花很多时间看方案、批预算、审核项目、确认结果。Agent 接走大量低风险判断以后，管理者如果仍是所有事情的审批节点，就可能成为瓶颈。
\n这时需要设计的是：哪些事情不必找我，何时必须找我；系统要提供哪些信息，我在什么范围内有权干预并改变已有决定；什么信号需要暂停，一次事故之后又怎样更新行动规则。
\n关注点由单次决定扩展到整个决策系统：让合适的主体，在足够的信息和清楚的边界下作出决定。
\n我更愿意用“人治理系统”描述这种关系。人不必参与每一个执行步骤，但需要保有定义目标、设置规则、查看证据、处理异常、暂停系统和修改规则的能力与权力，并承担相应责任。
\n人的角色由微观操作员转向系统治理者。仅仅在最后放一个确认按钮，还达不到这个要求。
\n任务、团队、流程、事实和决定权重新分配之后，责任也需要跟着调整。
\n谁有能力判断，谁有权行动，谁承担后果，这三者不能长期分离。把责任留给最后签字的人，却不给他信息和控制权，就成了机器有行动权、人有背锅权。
\n我理解的自治系统，需要知道自己能决定什么、何时必须停下来，以及出问题后由谁负责。人可以从逐项操作和确认中退出，但仍要能够定义方向、设计边界、处理例外，并对自己真正能够控制的事情负责。
\n","searchText":"“没关系，最后有人审核。”\n\n这句话听起来让人安心，我却越来越想追问：那个审核的人，实际能控制什么？假设一个智能体（Agent）每天审核 10 万条商品内容，绝大部分自动通过，只有高风险内容交给运营。管理者看到准确率不错，逐渐扩大自动执行范围。某一天，一条严重违规内容被判断为安全并自动发布，组织开始寻找责任人。算法团队说，模型只是给出判断；产品说，规则由业务定义；业务说，每天这么多内容，不可能逐条人工审核。最后，责任落到了系统里那个名义上的审核者身上。\n\n流程上，他是最终负责人。实际上，他每天面对几千条 AI 作出的决定，没有时间了解完整的相关信息和背景，没有参与模型和行动规则的设计，也无法阻止系统的大部分自动行为。他承担责任，却缺少相应的信息、判断能力和权限。\n\n这个人究竟在监督系统，还是只被放在系统最后，用来承担后果？\n\n## 一、“有人审核”不等于“有人负责”\n\n过去，医生看影像、编辑审文章、工程师发布代码、管理者批准预算，判断和行动都由人完成，责任相对容易理解。Agent 则可能接过观察、规划和行动，把人放到最后的审核环节。\n\n表面上，人仍然参与其中。但当自动执行的数量已经超过审核者能够认真处理的范围，大量决定实际上就不会经过逐项人工审核。界面上保留一个负责人，不能弥补处理能力的缺口。\n\n人已经从参与每个决定，转为监督系统的运行。如果直到事故发生后才看到结果，甚至连及时监督都谈不上了。\n\n因此，除了有没有人工审核，还要看：人在什么时候介入，看到了什么，能够改变什么？\n\n## 二、承担责任，需要信息、能力和权限\n\n我越来越觉得，一个人真正承担责任，至少需要三个条件同时成立。\n\n- **知道发生了什么。** 审核者如果只能看到 AI 的“建议通过”，却看不到原始证据、推理依据、历史背景和不确定性，就没有条件独立判断。第五篇讨论可追溯的事实，就是在解决这一层：责任必须建立在可追溯的信息之上。\n- **有能力作出判断。** 给一个没有专业能力的人一个“确认”按钮，不会产生真正的监督。判断税务风险，需要理解税务；判断内容质量，需要相应的内容判断能力。否则，人工审核就只是界面上的一个操作。\n- **有权改变结果。** 即使知道系统错在哪里，如果无权暂停 Agent、修改决定、回滚操作、调整规则或把问题升级，仍然无法真正承担责任。只分配责任却不给控制权，最后就只是让人承担后果。\n\n这三个条件彼此依赖，缺少任何一个，名义上的负责人都可能无法真正负责。\n\n## 三、根据任务风险，安排人的介入方式\n\n仅仅强调“人在执行环节中”，容易把所有任务都安排成 AI 先做、再由人确认。但生成一张内部会议封面，与自动退款 10 万元，不应该使用同一种监督机制。\n\n需要设计的是人在什么条件下、以什么方式介入系统，至少可以分成四层：\n\n- **自主执行。** 低风险、可逆、结果容易验证的任务，可以由 AI 自主执行，不必逐项确认。例如整理信息、生成内部草稿、低风险代码修改。\n- **执行后抽检。** 大量重复、整体风险可控，但需要持续观察质量的任务，可以由 AI 执行，再由人抽检。例如内容分类、数据处理、部分运营任务。人的作用是检查系统是否仍然可靠。\n- **异常时交给人。** 遇到证据冲突、超出规则边界、工具失败或经过验证的不确定性信号时，暂停相关动作并交给人处理。模型自报“很有把握”不等于可靠；升级条件还需要独立检查和抽检来补充。\n- **由人最终决定。** 对于高风险、不可逆、涉及价值判断或重大责任的事项，AI 可以分析信息、模拟方案、提出建议，但不能拥有最终决定权。例如重大人事决定、公司战略、严重安全事件。\n\n## 四、所以真正重要的不是“人在不在”，而是风险和决定权是否匹配\n\n这接上了第六篇的决定权分配。除了 AI 能不能做，还需要从四个维度判断一项决定应该交给谁：\n\n- **可逆性：** 错了能不能轻易撤回？\n- **影响范围：** 影响一个人，还是整个组织？\n- **不确定性：** 规则明确，还是存在大量未知？\n- **价值判断：** 是在计算最优解，还是在选择我们愿意成为什么？\n\n这些维度需要一起看。单次金额很小的自动退款，累计起来仍可能造成明显损失；可以回滚代码，也不代表已经泄露的信息能够收回。选择介入方式时，还要考虑频率、累计影响和发现错误所需的时间。\n\n## 五、AI 越强，人越不应该审核所有事情\n\n为了安全，很多组织会要求所有 AI 输出都经过人工确认。但当 Agent 持续增加，这种安排会超出人的处理能力。假设一个人管理 20 个 Agent，每个 Agent 每小时产生 20 个决定，一天就有几千次确认。审核很容易变成机械地点击确认，直到事故发生。\n\n自动化监督中存在一种风险：系统长期表现正常，人可能降低警觉，更少主动核对依据。大量低风险决定都要求点击确认，也会把真正高风险的决定淹没在噪声里。增加审核次数，未必增加监督强度。人的注意力应该留给值得独立判断的地方。\n\n## 六、未来真正稀缺的，可能是人的注意力\n\n执行越来越便宜，决定的数量也可能随之增长。过去，一个团队一天做 20 个决定；未来，100 个 Agent 可能每天做 10 万个微型决定。一个成熟专家每天能深度判断的问题，也许只有几十个。此时稀缺的未必是模型调用额度或算力，而是人的注意力。\n\n让机器处理确定性和可逆决定，让系统暴露异常，把冲突、不确定性、高风险和价值选择带到人面前，才能让有限的注意力用于值得判断的地方。第二篇讨论减少低价值协作，这里还需要减少低价值的人工确认。\n\n## 七、最危险的情况，是“人负责，但人无法真正控制”\n\n系统写着“负责人：张三”，出事就找张三。但他没有选择模型、定义行动规则的权力，不知道 Agent 依据了哪些信息，无法修改执行逻辑或暂停系统，甚至没有足够时间检查结果。这样的责任分配并不公平。\n\n责任需要跟着控制权走。Agent 的行为由模型、数据、行动规则、工具权限和平台机制共同决定，就不能把责任全压在最后点击“确认”的人身上。\n\n因此，责任分配需要沿系统结构说明：谁定义目标，谁制定行动规则，谁提供数据，谁授予权限，谁有权干预并改变已有决定，又由谁持续监控。\n\n以开头的内容事故为例，需要先指定一位有权暂停发布并组织处置的人，撤下相关内容、保留当时的证据与规则版本，再分别核查模型判断、规则设计和授权过程。恢复运行也应有人明确批准，不能把一次重新点击“通过”当成问题已经解决。这里讨论的是组织内部的职责设计；具体法律责任仍取决于适用规则和事件事实。\n\n## 八、管理者的工作，也会从“审批”变成“设计监督系统”\n\n传统管理者花很多时间看方案、批预算、审核项目、确认结果。Agent 接走大量低风险判断以后，管理者如果仍是所有事情的审批节点，就可能成为瓶颈。\n\n这时需要设计的是：哪些事情不必找我，何时必须找我；系统要提供哪些信息，我在什么范围内有权干预并改变已有决定；什么信号需要暂停，一次事故之后又怎样更新行动规则。\n\n关注点由单次决定扩展到整个决策系统：让合适的主体，在足够的信息和清楚的边界下作出决定。\n\n## 九、人需要保有治理整个系统的能力\n\n我更愿意用“人治理系统”描述这种关系。人不必参与每一个执行步骤，但需要保有定义目标、设置规则、查看证据、处理异常、暂停系统和修改规则的能力与权力，并承担相应责任。\n\n人的角色由微观操作员转向系统治理者。仅仅在最后放一个确认按钮，还达不到这个要求。\n\n## 十、当 AI 开始承担工作，谁来承担责任？\n\n任务、团队、流程、事实和决定权重新分配之后，责任也需要跟着调整。\n\n谁有能力判断，谁有权行动，谁承担后果，这三者不能长期分离。把责任留给最后签字的人，却不给他信息和控制权，就成了机器有行动权、人有背锅权。\n\n我理解的自治系统，需要知道自己能决定什么、何时必须停下来，以及出问题后由谁负责。人可以从逐项操作和确认中退出，但仍要能够定义方向、设计边界、处理例外，并对自己真正能够控制的事情负责。","headings":[{"id":"section-1","title":"一、“有人审核”不等于“有人负责”","level":2},{"id":"section-2","title":"二、承担责任，需要信息、能力和权限","level":2},{"id":"section-6","title":"三、根据任务风险，安排人的介入方式","level":2},{"id":"section-11","title":"四、所以真正重要的不是“人在不在”，而是风险和决定权是否匹配","level":2},{"id":"section-12","title":"五、AI 越强，人越不应该审核所有事情","level":2},{"id":"section-13","title":"六、未来真正稀缺的，可能是人的注意力","level":2},{"id":"section-14","title":"七、最危险的情况，是“人负责，但人无法真正控制”","level":2},{"id":"section-15","title":"八、管理者的工作，也会从“审批”变成“设计监督系统”","level":2},{"id":"section-16","title":"九、人需要保有治理整个系统的能力","level":2},{"id":"section-17","title":"十、当 AI 开始承担工作，谁来承担责任？","level":2}],"readingMinutes":7,"characterCount":2674,"images":[{"src":"images/s01-07.svg","thumb":"images/s01-07.svg","alt":"按风险选择介入方式","width":1000,"height":700,"description":"先判断行动是否可逆、影响范围、不确定性和价值取舍。低风险且结果可验证的任务可自主执行；高频重复且风险可观察的任务可执行后抽检；遇到证据冲突或规则越界时暂停相关动作并升级；高风险或难以撤回的事项由人决定。所有模式都需保留暂停、证据保存和升级入口。负责人需要信息、专业判断能力和干预权限。"}],"sourceHash":"1d502b8440d4768f4d907a0b2e1be0709ecfbc38b89d13d2812a649f3a947d23","description":"“没关系，最后有人审核。” 这句话听起来让人安心，我却越来越想追问：那个审核的人，实际能控制什么？假设一个智能体（Agent）每天审核 10 万条商品内容，绝大部分自动通过，只有高风险内容交给运营。管理者看到准确率不错，逐渐扩大自动执行…"},{"id":8,"title":"把经验教给 AI，员工为什么愿意？","file":"08-incentives.md","published":"2026-09","part":2,"tag":"贡献与回报","html":"想象一个工作了八年的运营专家。他清楚什么商品值得投、什么内容有潜力、什么异常意味着风险。团队遇到难题会找他，新人会向他请教。现在，公司希望他把经验写成标准操作流程、整理成案例、标注高质量数据，把判断方法做成技能模块，并不断纠正智能体（Agent），让 AI 学会他的工作方式。
\n假设半年以后效果很好，过去只有他会做的事情，现在几十个人都能调用 Agent 完成。组织获得了价值，他却开始问：我花八年形成的能力，变成了大家都能调用的公共能力，我自己的价值又在哪里？这个问题得不到回答，知识沉淀就会遇到阻力。
\n传统组织鼓励知识共享，但告诉别人怎么做，对方仍需要理解、练习和积累经验。专家分享知识后，通常仍然是专家。
\nAgent 改变了能力传递的方式。工程师排查故障的方法可以做成每天被调用一万次的技能模块；创作者的审美判断进入系统后，可以同时帮助几百个人；销售的话术、客户判断和策略，也可以持续复用。
\n知识分享开始包含能力复制：传递的不只是“我知道什么”，还包括“我怎么做”。组织获得了新的复用机会，个人也因此面对新的利益关系。
\n“只有我会”常常是职业安全感的来源：只有我理解系统为什么这样设计，认识这个客户，或者能处理这个流程。
\n组织不希望依赖一个单点，所以管理者会要求成员把经验传出去。但对个人来说，单点有时也是议价权。AI 放大了这个矛盾：组织期待的已经不只是教会另一个人，而是教会一个可以不断复制的系统。
\n“如果我把稀缺性全部贡献出去，组织为什么还需要我？”这个顾虑需要通过激励机制设计来回应，不能只解释成不愿意分享。
\n假设一个工程师花三个月构建编程技能模块，此后 500 个工程师每天使用，每人节省 30 分钟。一年下来，它给组织带来了很大的价值。
\n可到绩效评价时，另一位使用它的工程师交付了 20 个项目，系统记下“交付 20 个项目”；创建它的人因为忙于抽象经验、构建工具和维护能力，只交付了 5 个项目。
\n如果贡献只按个人交付计算，最理性的选择反而是少做公共能力，多交付自己的项目。
\n一个人完成的工作，和他让整个组织能够完成的工作，需要被看成两种不同的贡献。个人交付量并不能代表他对组织的全部贡献。
\n项目、商品交易总额、代码、内容和客户，是传统绩效体系容易看到的直接产出。AI 原生组织还会出现另一类贡献：通过能力建设，帮助别人做得更多、更好。
\n比如，一个技能模块被调用 10 万次，一个 Agent 替团队节省 5000 小时，一套评测让模型迭代更可靠，一个知识库减少重复研究，或者一个专家的方法被 300 人复用。这些贡献的价值，要到他人的工作里才能看见。
\n评价人才时，可能需要同时问：我直接完成了什么？因为我的建设，别人又能够完成什么？
\n第三篇讨论判断力如何借助杠杆发挥作用，第八篇接着问怎样认可这种贡献。一个人不应该因为把能力沉淀给组织而失去价值；他创造的杠杆，也应该进入评价。
\n不过，用调用次数、模型消耗量、节省工时和使用人数计算绩效，可能反过来影响人们怎样建设和使用工具。原本用于观察工作的数字，一旦成了奖励依据，就需要检查它是否仍能反映实际价值。
\n如果技能模块调用量成了目标，贡献者就可能追求更多技能模块、调用和曝光，最后留下几万个没人真正需要的技能模块。因此，评价这类帮助他人的贡献，不能只看使用量，还需要看：
\n奖励的对象应该是可复用的组织能力，而不只是 AI 资产的数量。
\n设想同样的工作量和质量要求下，一支团队所需的投入从相当于 100 人降到 70 人。这里只用这组假设讨论分配，不把它当作实际测得的提效幅度。组织很容易想到减少投入，但也需要考虑维护系统、处理例外和培养新人的持续成本。
\n但如果员工每次参与 AI 建设，得到的都是“谢谢你证明这个岗位不再需要这么多人”，下一次再请他贡献经验，他会怎样选择？
\nAI 转型因此还要讨论：生产率提升以后，收益如何分配。它可以表现为薪酬、奖金、更大的职责范围、更少重复劳动、更多探索时间和职业机会，也可以把节省的能力投入新的增长。
\n这不意味着所有收益都要直接分给员工，但参与者至少需要看到，帮助组织提效也能让自己获得更好的处境。否则，个人和组织就在朝相反的方向用力。
\n第三篇提出过一个循环：AI 帮助更多人成长，优秀的人获得杠杆，好方法沉淀成组织能力，再帮助更多人成长。这里需要补上其中的回报关系。
\n可以在建设开始前就约定几件事：经验整理和维护算不算正式工作，贡献怎样记录，复用后的结果由谁核对，绩效评价如何承认这部分工作，以及节省出的时间或收益怎样使用。复用扩大后，维护投入也要重新讨论，不能一直依靠贡献者业余补洞。
\n一种可尝试的安排，是由贡献者和使用团队共同记录改进前后的情况，保留失败和额外成本，在约定的周期内复核。回报可以是认可、薪酬、探索时间或新的职责，但应成为能兑现的具体约定。没有足够证据时，就先承认贡献类型，避免把每一次调用硬换算成收入。
\n如果只有个人向组织贡献能力，却没有组织价值向个人回报的过程，这个循环就无法持续。
\n专家能够解决别人解决不了的问题。AI 时代，他还可能成为组织能力的建设者，让整个组织以后更容易解决这类问题。
\n工程师除了修最难的 Bug，也可以建立减少同类 Bug 的系统；创作者除了做好自己的内容，还可以把审美标准、参考案例、评测和创作方法交给团队复用；管理者也可以建设一个让更多人作出好判断的环境。
\n这给专家提供了另一条价值路径：从拥有答案，走向持续创造组织能力。分享不应该让他的价值下降，而应该让贡献作用于更大的范围。
\n“这个结果是谁做的？”会越来越难回答。一条内容可能由创作者定方向、Agent 生成，另一个人构建技能模块，数据团队提供反馈，模型团队改善能力，组织记忆提供所需的背景信息。
\n比起把每一块商品交易额精确分给某个人，我更倾向于识别不同类型的贡献：
\n这些记录应允许贡献者查看和补充；对归属有争议时，由约定的负责人复核。承认不同类型的贡献，也意味着不能把所有价值都归给最后交付的人，或者最容易统计的那个环节。
\n我希望一个专家能得到这样的回答：能力被组织复制以后，你会获得更大的杠杆、更高阶的问题、更广的影响范围，以及与贡献匹配的回报。不要让那些愿意分享方法、让能力被更多人复用的人，反而因此受到惩罚。如果专家必须保持知识私有，才能维持自己的价值，组织就需要检查自己的激励机制。把能力交给系统，应该让人有机会继续学习、解决尚无答案的问题，而不只是让组织证明自己可以不再需要他。
\n这也留下了下一篇的问题：机器接走已经掌握的工作时，会不会连成为专家所需的练习也一起接走？
\n","searchText":"想象一个工作了八年的运营专家。他清楚什么商品值得投、什么内容有潜力、什么异常意味着风险。团队遇到难题会找他，新人会向他请教。现在，公司希望他把经验写成标准操作流程、整理成案例、标注高质量数据，把判断方法做成技能模块，并不断纠正智能体（Agent），让 AI 学会他的工作方式。\n\n假设半年以后效果很好，过去只有他会做的事情，现在几十个人都能调用 Agent 完成。组织获得了价值，他却开始问：我花八年形成的能力，变成了大家都能调用的公共能力，我自己的价值又在哪里？这个问题得不到回答，知识沉淀就会遇到阻力。\n\n## 一、AI 改变了知识分享的经济学\n\n传统组织鼓励知识共享，但告诉别人怎么做，对方仍需要理解、练习和积累经验。专家分享知识后，通常仍然是专家。\n\nAgent 改变了能力传递的方式。工程师排查故障的方法可以做成每天被调用一万次的技能模块；创作者的审美判断进入系统后，可以同时帮助几百个人；销售的话术、客户判断和策略，也可以持续复用。\n\n知识分享开始包含能力复制：传递的不只是“我知道什么”，还包括“我怎么做”。组织获得了新的复用机会，个人也因此面对新的利益关系。\n\n## 二、组织希望你把自己变得“不再不可替代”\n\n“只有我会”常常是职业安全感的来源：只有我理解系统为什么这样设计，认识这个客户，或者能处理这个流程。\n\n组织不希望依赖一个单点，所以管理者会要求成员把经验传出去。但对个人来说，单点有时也是议价权。AI 放大了这个矛盾：组织期待的已经不只是教会另一个人，而是教会一个可以不断复制的系统。\n\n“如果我把稀缺性全部贡献出去，组织为什么还需要我？”这个顾虑需要通过激励机制设计来回应，不能只解释成不愿意分享。\n\n## 三、真正的问题不是知识共享，而是价值归属\n\n假设一个工程师花三个月构建编程技能模块，此后 500 个工程师每天使用，每人节省 30 分钟。一年下来，它给组织带来了很大的价值。\n\n可到绩效评价时，另一位使用它的工程师交付了 20 个项目，系统记下“交付 20 个项目”；创建它的人因为忙于抽象经验、构建工具和维护能力，只交付了 5 个项目。\n\n如果贡献只按个人交付计算，最理性的选择反而是少做公共能力，多交付自己的项目。\n\n一个人完成的工作，和他让整个组织能够完成的工作，需要被看成两种不同的贡献。个人交付量并不能代表他对组织的全部贡献。\n\n## 四、AI 时代需要重新定义“产出”\n\n项目、商品交易总额、代码、内容和客户，是传统绩效体系容易看到的直接产出。AI 原生组织还会出现另一类贡献：通过能力建设，帮助别人做得更多、更好。\n\n比如，一个技能模块被调用 10 万次，一个 Agent 替团队节省 5000 小时，一套评测让模型迭代更可靠，一个知识库减少重复研究，或者一个专家的方法被 300 人复用。这些贡献的价值，要到他人的工作里才能看见。\n\n评价人才时，可能需要同时问：我直接完成了什么？因为我的建设，别人又能够完成什么？\n\n第三篇讨论判断力如何借助杠杆发挥作用，第八篇接着问怎样认可这种贡献。一个人不应该因为把能力沉淀给组织而失去价值；他创造的杠杆，也应该进入评价。\n\n## 五、但“调用次数”也不是答案\n\n不过，用调用次数、模型消耗量、节省工时和使用人数计算绩效，可能反过来影响人们怎样建设和使用工具。原本用于观察工作的数字，一旦成了奖励依据，就需要检查它是否仍能反映实际价值。\n\n如果技能模块调用量成了目标，贡献者就可能追求更多技能模块、调用和曝光，最后留下几万个没人真正需要的技能模块。因此，评价这类帮助他人的贡献，不能只看使用量，还需要看：\n\n- **持续使用：** 是否有人持续使用？\n- **实际结果：** 是否改善结果？\n- **可靠性：** 是否稳定可信？\n- **跨团队复用：** 是否跨团队产生价值？\n- **学习积累：** 是否让组织更容易解决同类问题？\n\n奖励的对象应该是可复用的组织能力，而不只是 AI 资产的数量。\n\n## 六、还有一个更尖锐的问题：效率收益归谁？\n\n设想同样的工作量和质量要求下，一支团队所需的投入从相当于 100 人降到 70 人。这里只用这组假设讨论分配，不把它当作实际测得的提效幅度。组织很容易想到减少投入，但也需要考虑维护系统、处理例外和培养新人的持续成本。\n\n但如果员工每次参与 AI 建设，得到的都是“谢谢你证明这个岗位不再需要这么多人”，下一次再请他贡献经验，他会怎样选择？\n\nAI 转型因此还要讨论：生产率提升以后，收益如何分配。它可以表现为薪酬、奖金、更大的职责范围、更少重复劳动、更多探索时间和职业机会，也可以把节省的能力投入新的增长。\n\n这不意味着所有收益都要直接分给员工，但参与者至少需要看到，帮助组织提效也能让自己获得更好的处境。否则，个人和组织就在朝相反的方向用力。\n\n## 七、让组织获得的能力，也帮助贡献者成长\n\n第三篇提出过一个循环：AI 帮助更多人成长，优秀的人获得杠杆，好方法沉淀成组织能力，再帮助更多人成长。这里需要补上其中的回报关系。\n\n可以在建设开始前就约定几件事：经验整理和维护算不算正式工作，贡献怎样记录，复用后的结果由谁核对，绩效评价如何承认这部分工作，以及节省出的时间或收益怎样使用。复用扩大后，维护投入也要重新讨论，不能一直依靠贡献者业余补洞。\n\n一种可尝试的安排，是由贡献者和使用团队共同记录改进前后的情况，保留失败和额外成本，在约定的周期内复核。回报可以是认可、薪酬、探索时间或新的职责，但应成为能兑现的具体约定。没有足够证据时，就先承认贡献类型，避免把每一次调用硬换算成收入。\n\n如果只有个人向组织贡献能力，却没有组织价值向个人回报的过程，这个循环就无法持续。\n\n## 八、专家的价值也需要重新定义\n\n专家能够解决别人解决不了的问题。AI 时代，他还可能成为组织能力的建设者，让整个组织以后更容易解决这类问题。\n\n工程师除了修最难的 Bug，也可以建立减少同类 Bug 的系统；创作者除了做好自己的内容，还可以把审美标准、参考案例、评测和创作方法交给团队复用；管理者也可以建设一个让更多人作出好判断的环境。\n\n这给专家提供了另一条价值路径：从拥有答案，走向持续创造组织能力。分享不应该让他的价值下降，而应该让贡献作用于更大的范围。\n\n## 九、绩效评价，需要看见不同类型的贡献\n\n“这个结果是谁做的？”会越来越难回答。一条内容可能由创作者定方向、Agent 生成，另一个人构建技能模块，数据团队提供反馈，模型团队改善能力，组织记忆提供所需的背景信息。\n\n比起把每一块商品交易额精确分给某个人，我更倾向于识别不同类型的贡献：\n\n- 直接交付结果。\n- 建设可以复用的公共能力。\n- 沉淀关键经验。\n- 帮助别人成功。\n- 作出关键判断。\n\n这些记录应允许贡献者查看和补充；对归属有争议时，由约定的负责人复核。承认不同类型的贡献，也意味着不能把所有价值都归给最后交付的人，或者最容易统计的那个环节。\n\n## 十、把经验教给 AI，员工为什么愿意？\n\n我希望一个专家能得到这样的回答：能力被组织复制以后，你会获得更大的杠杆、更高阶的问题、更广的影响范围，以及与贡献匹配的回报。不要让那些愿意分享方法、让能力被更多人复用的人，反而因此受到惩罚。如果专家必须保持知识私有，才能维持自己的价值，组织就需要检查自己的激励机制。把能力交给系统，应该让人有机会继续学习、解决尚无答案的问题，而不只是让组织证明自己可以不再需要他。\n\n这也留下了下一篇的问题：机器接走已经掌握的工作时，会不会连成为专家所需的练习也一起接走？","headings":[{"id":"section-1","title":"一、AI 改变了知识分享的经济学","level":2},{"id":"section-2","title":"二、组织希望你把自己变得“不再不可替代”","level":2},{"id":"section-3","title":"三、真正的问题不是知识共享，而是价值归属","level":2},{"id":"section-4","title":"四、AI 时代需要重新定义“产出”","level":2},{"id":"section-5","title":"五、但“调用次数”也不是答案","level":2},{"id":"section-6","title":"六、还有一个更尖锐的问题：效率收益归谁？","level":2},{"id":"section-7","title":"七、让组织获得的能力，也帮助贡献者成长","level":2},{"id":"section-8","title":"八、专家的价值也需要重新定义","level":2},{"id":"section-9","title":"九、绩效评价，需要看见不同类型的贡献","level":2},{"id":"section-10","title":"十、把经验教给 AI，员工为什么愿意？","level":2}],"readingMinutes":7,"characterCount":2573,"images":[{"src":"images/s01-08.svg","thumb":"images/s01-08.svg","alt":"贡献怎样得到持续回报？","width":1000,"height":700,"description":"贡献者整理方法并记录创作和维护投入，团队在具体场景中复用并保留改动记录。评价时检查实际结果，包括质量、收益和额外成本，而不只统计调用次数。根据事先约定兑现认可、收益、机会或时间等回报，使贡献者有条件继续建设。回报方式需要协商，不能从调用量直接推导。"}],"sourceHash":"6aebe687bcbfef96248c61e475a36e5d8de4ea77473bd6af6e73d6a8cf38a166","description":"想象一个工作了八年的运营专家。他清楚什么商品值得投、什么内容有潜力、什么异常意味着风险。团队遇到难题会找他，新人会向他请教。现在，公司希望他把经验写成标准操作流程、整理成案例、标注高质量数据，把判断方法做成技能模块，并不断纠正智能体（A…"},{"id":9,"title":"AI 接走了初级工作，下一代专家从哪里来？","file":"09-learning.md","published":"2026-09","part":2,"tag":"学习","html":"假设一个刚毕业的工程师加入团队，从修 Bug 开始。先看日志、读代码、猜原因，判断错了就重新排查；改完代码，测试失败，再去理解为什么。一个看似简单的问题，可能折腾一下午。同样的问题交给编程智能体（Agent），它可能搜索代码、定位原因、修改实现、运行测试，十分钟后提交结果。新人审核后合并代码。从生产效率看，这是进步。
\n但几年以后，如果那些“浪费了一下午”的经历都消失了，他靠什么形成高级工程师的判断力？那些被自动化的初级工作，也许一直承担着另一种作用：它们是上一代专家的训练数据。
\n我们容易把专家理解成拥有更多知识的人：新人知道 100 件事，专家知道 10000 件事。如果只是如此，AI 应该能大幅加速专家培养。但专家的价值往往还在于，看到异常知道先检查哪里，面对三个合理方案能发现潜在问题，或者从完整的需求里识别出被问错的问题。有时数据没有明显变化，他却已经觉得“不太对”。这些能力很难写成一套完整规则。
\n它们来自做过、犯错、得到反馈、修正，再遇到类似问题的真实经历，逐渐形成隐性知识。人从经验和反馈中识别出规律，再形成判断。知识重要，判断力也需要在现实反馈中训练。
\n自动化通常从重复、低风险、规则相对明确、容易验证的工作开始。这些也恰好是过去组织交给新人的任务，因为犯错的代价比较低。一个初级工程师不会一入职就设计核心支付架构。一个年轻投资人不会第一天就独立决定十亿美元投资。一个刚入行的医生也不会直接负责最复杂的病例。
\n许多专业工作中的学徒制和岗位培养，都包含这样的安排：
\n\n\n先让你在低风险环境里做大量真实工作，再逐渐把更大的决定交给你。
\n
但 AI 和新人正在竞争同一类任务。而且从生产角度看，AI 往往更有优势。
\n这里出现了一个自动化带来的矛盾：最应该被自动化的工作，可能恰好最适合培养下一代专家。
\n这要求我们重新定义什么叫“低价值工作”。假设一个高级工程师花两个小时人工排查普通 Bug。这可能确实是低价值工作。因为他已经掌握了这项能力，再做一次几乎没有新的学习。
\n但同一个 Bug 交给新人，可能是他第一次理解调用链、真正阅读线上日志，或看到一个局部修改如何产生意外影响。从组织生产角度看，这两个小时可能不划算。从人才成长角度看，却可能非常有价值。
\n所以，衡量一项工作，至少要看它带来了什么产出，以及让执行者学到了什么。AI 很擅长提高生产效率，组织却不能因此忽略学习价值。
\n如果我们只按照生产价值分配任务，最有效率的结果很可能是：简单任务全部给 AI，复杂任务全部给专家。短期看，产出最大化了；长期看，却出现一个断层：新人没有机会从简单走向复杂。
\nAI 还会制造一个更隐蔽的问题。过去，一个新人不会写代码，很容易被发现。因为代码就是写不出来。现在他可以让 Agent 写。不会分析数据，可以让 Agent 分析。不了解一个领域，可以让研究 Agent 研究。不会设计方案，也可以先生成三个方向。最终交付甚至可能很好。
\n于是我们很容易产生一个错觉：这个人成长得非常快。
\n但交付质量和人的能力需要分开看。一个人借助 AI 交付高级结果，不意味着他已经拥有产生这个结果所需要的高级判断。真正的问题会在异常情况下出现。Agent 给了两个都合理的方案，选哪个？数据与经验冲突，相信谁？系统进入从未见过的状态，怎么办？AI 自己也不确定的时候，谁接手？
\n如果一个人过去几年主要是在输入提示词、等待生成、接受结果，那么到了真正需要独立判断的那一天，我们可能突然发现：他拥有专家级工具，却没有专家级的判断力。
\n为了培养新人而关闭 AI，让他手工做 AI 十秒钟就能完成的事情，也未必带来学习。需要识别的是：专家形成过程中，哪些经验不应该消失？
\n例如，排查故障时，真正重要的可能不是亲手敲每一行代码，而是如何形成假设：先检查什么？哪些证据支持这个判断？什么时候推翻原来的假设？如何判断修复没有制造新的问题？如果这些才是学习核心，我们就不需要保留整个旧流程。
\n需要保留的，是让新人真正面对这些关键判断的机会。
\n传统的“在做中学”，让人在真实工作中遇到问题，通过反馈成长。AI 接走部分执行以后，也许需要更主动地设计判断练习，并让人获得反馈。
\n比如新人和 Agent 一起排查故障，先由新人写下最可能的三个原因，再让 Agent 搜索证据。接着，由新人决定下一步检查哪里，Agent 执行。最后对照人的判断、Agent 的判断和真实结果，理解差异从哪里来。
\n练习结束时，带教者可以核对：新人是否提出了可检验的假设，是否找到了能够区分几个原因的证据，何时改变判断，以及是否检查了修复的副作用。评价依据是这些可解释的判断和真实结果，而不是他是否恰好猜中了答案。
\n如果要观察成长，可以隔一段时间换一道相近但不相同的问题，让新人先独立说明思路。一次好结果不足以证明能力已经形成；在新情境中能否迁移，才更值得继续观察。
\n如果设计得好，AI 还可能提高学习密度。过去，新人一年只能经历真实发生的几十种问题；未来，可以取出组织过去十年的真实案例，隐藏答案，让 AI 模拟当时的环境，只提供当时能看到的信息。
\n新人先作判断，再逐步获得后续信息，最后与真实事件、专家判断和结果对照，理解为什么会这样。案例需要保留当时的信息边界，避免提前透露答案；专家当年的判断也可能有误，不能把历史结果倒写成唯一正确路径。这有点像飞行员的模拟训练：不需要真的制造发动机故障，也能训练如何应对。
\n因此，不必保留全部低效工作，但要有高质量、接近真实、有反馈的判断练习。
\n过去，职业成长经常沿任务复杂度展开：新人做小任务，成熟员工负责具体功能，专家负责系统，管理者负责多个团队。AI 时代，我认为可以增加一条成长路径，观察一个人能够承担怎样的判断：
\n这是一种可尝试的培养安排，阶段之间可以往返。是否增加权限，应结合任务风险和多次练习的表现，而不是完成一次训练就自动晋级。
\n为了今天更快交付，软件工程可能欠下将来要偿还的技术债务。组织也可能欠下学习债务。把任务交给 Agent，今天节省了 2 小时；如果新人也因此失去一次关键判断的练习，这个收益就伴随着未来的人才成本。一次或许影响不大，一千次、持续三年，又会怎样？
\n当今天的专家离开，中间一代却从未处理过这些问题，债务才会暴露出来。所以除了 AI 的使用情况，管理者还要问：哪些关键判断正在失去训练机会？
\n“十年经验”可能意味着同一种任务重复十年，也可能意味着经历过大量不同的问题、判断和反馈。AI 时代，这个区别会更加明显。
\n我倾向于从三个相互影响的方面理解经验：面对过多少真实判断，获得的反馈有多快、多准确，以及是否反思并理解自己为什么对、为什么错。这比完成过多少任务，更接近专家形成的过程。
\n过去，真实工作包含大量练习，组织可以在交付中培养人。AI 接走执行环节以后，我们需要主动设计学习机会，让人才成长不再只是工作的副产品。在执行架构、决定权架构和介入机制之外，还需要学习机制：哪些判断必须亲自经历，什么阶段获得多少决定权，需要什么反馈，哪些失败可以先在模拟环境中经历，又怎样判断一个人已经能够从观察别人决策，走向亲自作出决定。
\n前八篇讨论如何复用人已经掌握的能力，第九篇想补上能力从哪里继续长出来。今天的专家可以获得很大的 AI 杠杆，但如果他们离开时，已经没有人走过成为专家的那条路，组织就失去了能力的来源。
\n","searchText":"假设一个刚毕业的工程师加入团队，从修 Bug 开始。先看日志、读代码、猜原因，判断错了就重新排查；改完代码，测试失败，再去理解为什么。一个看似简单的问题，可能折腾一下午。同样的问题交给编程智能体（Agent），它可能搜索代码、定位原因、修改实现、运行测试，十分钟后提交结果。新人审核后合并代码。从生产效率看，这是进步。\n\n但几年以后，如果那些“浪费了一下午”的经历都消失了，他靠什么形成高级工程师的判断力？那些被自动化的初级工作，也许一直承担着另一种作用：它们是上一代专家的训练数据。\n\n## 一、专家不是“学完知识”以后出现的\n\n我们容易把专家理解成拥有更多知识的人：新人知道 100 件事，专家知道 10000 件事。如果只是如此，AI 应该能大幅加速专家培养。但专家的价值往往还在于，看到异常知道先检查哪里，面对三个合理方案能发现潜在问题，或者从完整的需求里识别出被问错的问题。有时数据没有明显变化，他却已经觉得“不太对”。这些能力很难写成一套完整规则。\n\n它们来自做过、犯错、得到反馈、修正，再遇到类似问题的真实经历，逐渐形成隐性知识。人从经验和反馈中识别出规律，再形成判断。知识重要，判断力也需要在现实反馈中训练。\n\n## 二、问题恰恰在于：AI 最先接走的，通常是最适合新人练习的工作\n\n自动化通常从重复、低风险、规则相对明确、容易验证的工作开始。这些也恰好是过去组织交给新人的任务，因为犯错的代价比较低。一个初级工程师不会一入职就设计核心支付架构。一个年轻投资人不会第一天就独立决定十亿美元投资。一个刚入行的医生也不会直接负责最复杂的病例。\n\n许多专业工作中的学徒制和岗位培养，都包含这样的安排：\n\n> **先让你在低风险环境里做大量真实工作，再逐渐把更大的决定交给你。**\n\n但 AI 和新人正在竞争同一类任务。而且从生产角度看，AI 往往更有优势。\n\n这里出现了一个自动化带来的矛盾：最应该被自动化的工作，可能恰好最适合培养下一代专家。\n\n## 三、一项工作的“生产价值”和“学习价值”不是一回事\n\n这要求我们重新定义什么叫“低价值工作”。假设一个高级工程师花两个小时人工排查普通 Bug。这可能确实是低价值工作。因为他已经掌握了这项能力，再做一次几乎没有新的学习。\n\n但同一个 Bug 交给新人，可能是他第一次理解调用链、真正阅读线上日志，或看到一个局部修改如何产生意外影响。从组织生产角度看，这两个小时可能不划算。从人才成长角度看，却可能非常有价值。\n\n所以，衡量一项工作，至少要看它带来了什么产出，以及让执行者学到了什么。AI 很擅长提高生产效率，组织却不能因此忽略学习价值。\n\n如果我们只按照生产价值分配任务，最有效率的结果很可能是：简单任务全部给 AI，复杂任务全部给专家。短期看，产出最大化了；长期看，却出现一个断层：新人没有机会从简单走向复杂。\n\n## 四、最危险的不是新人不会做，而是他“看起来会做”\n\nAI 还会制造一个更隐蔽的问题。过去，一个新人不会写代码，很容易被发现。因为代码就是写不出来。现在他可以让 Agent 写。不会分析数据，可以让 Agent 分析。不了解一个领域，可以让研究 Agent 研究。不会设计方案，也可以先生成三个方向。最终交付甚至可能很好。\n\n于是我们很容易产生一个错觉：这个人成长得非常快。\n\n但交付质量和人的能力需要分开看。一个人借助 AI 交付高级结果，不意味着他已经拥有产生这个结果所需要的高级判断。真正的问题会在异常情况下出现。Agent 给了两个都合理的方案，选哪个？数据与经验冲突，相信谁？系统进入从未见过的状态，怎么办？AI 自己也不确定的时候，谁接手？\n\n如果一个人过去几年主要是在输入提示词、等待生成、接受结果，那么到了真正需要独立判断的那一天，我们可能突然发现：他拥有专家级工具，却没有专家级的判断力。\n\n## 五、所以真正应该保护的，不是“初级工作”，而是“有效练习”\n\n为了培养新人而关闭 AI，让他手工做 AI 十秒钟就能完成的事情，也未必带来学习。需要识别的是：专家形成过程中，哪些经验不应该消失？\n\n例如，排查故障时，真正重要的可能不是亲手敲每一行代码，而是如何形成假设：先检查什么？哪些证据支持这个判断？什么时候推翻原来的假设？如何判断修复没有制造新的问题？如果这些才是学习核心，我们就不需要保留整个旧流程。\n\n需要保留的，是让新人真正面对这些关键判断的机会。\n\n## 六、让新人通过作出判断、获得反馈来学习\n\n传统的“在做中学”，让人在真实工作中遇到问题，通过反馈成长。AI 接走部分执行以后，也许需要更主动地设计判断练习，并让人获得反馈。\n\n比如新人和 Agent 一起排查故障，先由新人写下最可能的三个原因，再让 Agent 搜索证据。接着，由新人决定下一步检查哪里，Agent 执行。最后对照人的判断、Agent 的判断和真实结果，理解差异从哪里来。\n\n练习结束时，带教者可以核对：新人是否提出了可检验的假设，是否找到了能够区分几个原因的证据，何时改变判断，以及是否检查了修复的副作用。评价依据是这些可解释的判断和真实结果，而不是他是否恰好猜中了答案。\n\n如果要观察成长，可以隔一段时间换一道相近但不相同的问题，让新人先独立说明思路。一次好结果不足以证明能力已经形成；在新情境中能否迁移，才更值得继续观察。\n\n## 七、AI 甚至可能让“练习”变得比过去更好\n\n如果设计得好，AI 还可能提高学习密度。过去，新人一年只能经历真实发生的几十种问题；未来，可以取出组织过去十年的真实案例，隐藏答案，让 AI 模拟当时的环境，只提供当时能看到的信息。\n\n新人先作判断，再逐步获得后续信息，最后与真实事件、专家判断和结果对照，理解为什么会这样。案例需要保留当时的信息边界，避免提前透露答案；专家当年的判断也可能有误，不能把历史结果倒写成唯一正确路径。这有点像飞行员的模拟训练：不需要真的制造发动机故障，也能训练如何应对。\n\n因此，不必保留全部低效工作，但要有高质量、接近真实、有反馈的判断练习。\n\n## 八、按能够承担的判断，安排成长阶段\n\n过去，职业成长经常沿任务复杂度展开：新人做小任务，成熟员工负责具体功能，专家负责系统，管理者负责多个团队。AI 时代，我认为可以增加一条成长路径，观察一个人能够承担怎样的判断：\n\n1. **观察判断。** 看 AI 怎样判断，理解它依据的证据和最终结果。\n2. **先作预测。** 在 AI 执行之前，先给出自己的判断，再比较两者的差异。\n3. **亲自决定。** 由人作决定，AI 提供分析并负责执行。\n4. **处理例外。** 接手 AI 不确定、存在冲突或已经失败的情况。\n5. **制定规则。** 开始定义其他人和 Agent 应该如何决策。\n\n这是一种可尝试的培养安排，阶段之间可以往返。是否增加权限，应结合任务风险和多次练习的表现，而不是完成一次训练就自动晋级。\n\n## 九、这也意味着管理者必须开始管理“学习债务”\n\n为了今天更快交付，软件工程可能欠下将来要偿还的技术债务。组织也可能欠下学习债务。把任务交给 Agent，今天节省了 2 小时；如果新人也因此失去一次关键判断的练习，这个收益就伴随着未来的人才成本。一次或许影响不大，一千次、持续三年，又会怎样？\n\n当今天的专家离开，中间一代却从未处理过这些问题，债务才会暴露出来。所以除了 AI 的使用情况，管理者还要问：哪些关键判断正在失去训练机会？\n\n## 十、未来人才系统真正应该优化的，不是“做过多少”，而是“判断过多少”\n\n“十年经验”可能意味着同一种任务重复十年，也可能意味着经历过大量不同的问题、判断和反馈。AI 时代，这个区别会更加明显。\n\n我倾向于从三个相互影响的方面理解经验：面对过多少真实判断，获得的反馈有多快、多准确，以及是否反思并理解自己为什么对、为什么错。这比完成过多少任务，更接近专家形成的过程。\n\n## 十一、AI 接走初级工作，下一代专家从哪里来？\n\n过去，真实工作包含大量练习，组织可以在交付中培养人。AI 接走执行环节以后，我们需要主动设计学习机会，让人才成长不再只是工作的副产品。在执行架构、决定权架构和介入机制之外，还需要学习机制：哪些判断必须亲自经历，什么阶段获得多少决定权，需要什么反馈，哪些失败可以先在模拟环境中经历，又怎样判断一个人已经能够从观察别人决策，走向亲自作出决定。\n\n前八篇讨论如何复用人已经掌握的能力，第九篇想补上能力从哪里继续长出来。今天的专家可以获得很大的 AI 杠杆，但如果他们离开时，已经没有人走过成为专家的那条路，组织就失去了能力的来源。","headings":[{"id":"section-1","title":"一、专家不是“学完知识”以后出现的","level":2},{"id":"section-2","title":"二、问题恰恰在于：AI 最先接走的，通常是最适合新人练习的工作","level":2},{"id":"section-3","title":"三、一项工作的“生产价值”和“学习价值”不是一回事","level":2},{"id":"section-4","title":"四、最危险的不是新人不会做，而是他“看起来会做”","level":2},{"id":"section-5","title":"五、所以真正应该保护的，不是“初级工作”，而是“有效练习”","level":2},{"id":"section-6","title":"六、让新人通过作出判断、获得反馈来学习","level":2},{"id":"section-7","title":"七、AI 甚至可能让“练习”变得比过去更好","level":2},{"id":"section-8","title":"八、按能够承担的判断，安排成长阶段","level":2},{"id":"section-14","title":"九、这也意味着管理者必须开始管理“学习债务”","level":2},{"id":"section-15","title":"十、未来人才系统真正应该优化的，不是“做过多少”，而是“判断过多少”","level":2},{"id":"section-16","title":"十一、AI 接走初级工作，下一代专家从哪里来？","level":2}],"readingMinutes":8,"characterCount":2902,"images":[{"src":"images/s01-09.svg","thumb":"images/s01-09.svg","alt":"让新人亲自经历关键判断","width":1000,"height":700,"description":"新人先写下自己的判断和依据，再让Agent搜集证据，然后由新人选择下一步行动。在获得真实结果后，与导师对照预期和结果，解释差异，并修正下一次判断。Agent可以接走搜索与执行，但不能替代新人亲自面对关键选择。评价重点是能否说明依据、识别未知并随新证据改判。"}],"sourceHash":"0b7689da4f1b363428c26622a0a6c71db414807213ced5745882464df3fdbd01","description":"假设一个刚毕业的工程师加入团队，从修 Bug 开始。先看日志、读代码、猜原因，判断错了就重新排查；改完代码，测试失败，再去理解为什么。一个看似简单的问题，可能折腾一下午。同样的问题交给编程智能体（Agent），它可能搜索代码、定位原因、…"},{"id":10,"title":"当 Agent 成为组织成员，管理者到底在管理什么？","file":"10-agent-management.md","published":"2026-09","part":3,"tag":"管理","html":"设想一个处理用户投诉的团队。Agent 可以读取工单、核对订单、检索规则，准备回复和退款建议。客服处理例外，业务负责人决定规则，技术同事维护系统。单看每一步，都像是现有工作变快了。
\n但工作一旦连起来，新的问题就出现了：回复已经发出，退款却没有成功；系统为了缩短处理时长过早关闭工单；一条规则改过了，另一个 Agent 还在使用旧版本。团队需要管理的，已经包括这些执行者之间的关系。
\n这里把 Agent 称为“组织成员”，是从协作角度作的比喻。它可以接收任务、使用工具、留下记录，但没有因此获得与人相同的法律身份或自主利益。它能够做什么，仍由组织配置的目标、信息和权限决定。我更想讨论的是，管理者怎样让这些安排持续有效。
\n投诉处理的目标可以是尽快解决用户问题，但“尽快”并不足以指导所有行动。核实事实、遵守退款规则、保护用户信息、给用户合理的复核机会，也都需要进入目标。
\n假设系统把“关单时间最短”当成唯一标准，最容易优化的可能是尽早关单。工单结束了，问题却可能转移到下一次投诉。管理者需要说明哪些结果可以互相权衡，哪些条件必须满足，以及发生冲突时由谁决定。
\n这一点也适用于人。客服知道一条规则正在伤害用户，却没有渠道推动修改，系统就只能反复处理同一类例外。定义目标应当是可以被反馈影响的工作，而不只是一次配置。
\nAgent 数量增加后，任务也可能自行膨胀。一个执行者发现缺口就继续拆任务，另一个为了提高质量不断追加检查，最后每一步都有理由，却没有人判断继续做是否值得。
\n投诉处理里，可以先规定几个交接条件：信息收集到什么程度才形成建议，出现相反证据时交给谁，等待补充材料时是否暂停计时，用户没有回应时怎样处理。需要处理同一订单的几个 Agent，也应共享一致的记录，避免重复退款或给出相互矛盾的答复。
\n管理者需要照看的是整件事的进展。一次回复写得很好，但后续动作没有执行，仍然没有完成工作。任务分配因而要同时说明输入、输出、下一位接手者，以及结束或停止的条件。
\n同一个模型，能读取的规则不同、工具是否可用不同，表现也可能不同。给 Agent 一个退款工具，还需要说明它能处理哪些订单、在什么范围内操作，以及如何确认操作已经完成。
\n前面几篇讨论的事实、授权和责任，在这里变成日常维护：规则过期由谁更新，工具报错由谁处理，哪些数据可以读取，权限何时复核，谁能撤回错误配置。这些工作需要明确负责人和投入，不能在上线以后默认它们会自行保持正确。
\n系统还应保留足够的运行记录，让负责人能够还原一次决定：当时看到了什么证据，使用了哪版规则，执行了哪个动作，结果是否得到确认。日志的目的应是理解工作和修正系统，访问范围也应与这个目的相称。
\n回复速度、解决率、用户反馈、错误补救和人工处理时间，可能指向不同方向。速度提升，但客服要花更多时间处理被误关的投诉，收益就需要重新计算。
\n我会先为同类工作说明怎样记录结果，再看自动处理前后发生了什么变化。工作量、难度或用户类型不同，就不能把两组数字直接归因于 Agent。没有足够证据时，可以先报告观察到的变化和未解释的部分。
\n评价还需要允许异议。客服认为一次处理不合理，用户认为结果不公平，都应有办法进入复核。指标可以帮助发现问题，却不能替组织完成全部价值判断。复核也可能发现评价标准本身需要修改。
\n“遇到问题转人工”常被写成一条完整的规则，真正运行时却还差很多条件：转给谁，对方何时能接手，等待期间系统还能做什么，超时以后谁负责处理？
\n在投诉场景中，证据冲突的工单可以暂停退款建议，并保留当前信息交给负责人复核。已经执行失败的退款，则要先查明支付状态，避免重复提交。两种情况需要不同的处理方式。
\n异常数量持续增长时，不能只要求客服加快处理。管理者需要判断是规则覆盖不足、工具故障，还是自动处理范围过大，并有权暂时缩小范围。一次工作的运行状况，也应包括接手者是否已经超出负荷。
\nMiMo-V2.6 的官方训练说明把任务环境、运行框架、评价和反馈放在一起讨论。这给我一个有限的启发：能力能否改善，与它获得什么反馈有关。MiMo 官方说明（在新标签页打开）
\n但模型训练与组织学习有明显区别。真实业务的结果可能很晚才出现，也很难归因到单个动作；员工、用户和管理者对“做好”的理解也可能不同。一次满意度下降，不能直接当成一条明确的训练信号，更不能让系统自行修改所有规则。
\n要让投诉经验进入下一轮工作，可以先把重复错误归为一个待改进问题，再由负责人检查原因，修改相应的规则、工具或资料。在历史案例上检查修改是否造成新的错误，小范围使用，保留原版本和撤回办法，最后再决定是否扩大。
\n这里的“学习”可能只是修正一条规则、补充一个反例，或让新人理解一次判断，并不必然涉及模型训练。记录留存只是起点，谁审核、谁修改、怎样验证和撤回，都需要有人负责。
\n如果 Agent 接走了简单问题，客服只剩下情绪强烈、证据复杂的投诉，工作数量下降也可能伴随负担上升。评价效率时，需要把这种变化算进去。
\n贡献经验的人也需要时间维护方法，并得到相应认可；新人需要在适当支持下练习判断，不能只接收最难、最急的例外。这分别对应第八篇的贡献回报和第九篇的学习机会。
\n管理者可以和团队一起检查：自动化减少了哪些重复劳动，又增加了哪些隐性工作？谁获得了时间，谁承担了压力？规则的修改是否听到了这些人的意见？这些问题会影响团队是否愿意继续合作，也会影响系统所依赖的信息是否真实。
\n回到开头的投诉团队，我会把管理工作的重点放在几件具体的事情上：目标冲突有没有被处理，交接是否完成，异常是否有人接手，成本是否转移给了别人，以及复盘是否改变了下一轮工作。
\n这不意味着管理者要亲自维护每个工具、查看每条记录。可以把职责交给合适的人，但需要保证这些职责有资源、有权限，也能在冲突发生时找到决定者。
\n人和 Agent 的分工会随着能力变化不断调整。比起一次设计出完美的系统，我更看重团队能否及时发现失效的安排，并共同把它改过来。第十二篇的五张地图，就是把这些检查放回一条具体工作链路的方法。
\n过去，做一个产品需要找到产品、设计、前后端、算法、数据和运营。如果这些能力会被长期使用，把人招进公司，往往比反复寻找、建立信任、沟通和协作更合适。公司把未来反复需要的能力提前组织起来。智能体（Agent）正在改变其中一部分前提：研究可以调用研究 Agent，开发可以调用编程 Agent，视觉可以调用生成模型，专家的方法也能沉淀成技能模块，供整个组织使用。
\n当越来越多能力可以随时调用，我们为什么还需要把那么多人长期组织在一家公司里？
\nRonald Coase 在 1937 年的《The Nature of the Firm》中，从使用市场的成本解释企业为何存在。发现价格、谈判、订约和检查履约都需要投入；把一部分协作放到企业内部，有时可以减少这些成本。但内部管理同样有成本和局限，需要比较不同安排。原作（在新标签页打开） · Coase 本人的回顾（在新标签页打开）
\n公司因而把一部分高频协作放到内部，让工程、设计等长期需要的能力不必每次重新购买。从这个角度，我把公司理解为一个稳定的能力容器。
\n过去，公司的能力边界很大程度上也是人员边界：需要什么能力，就招聘什么人。AI 正在把两者拆开。
\n软件、设备和外部服务早已让能力增长不必完全依赖增员。AI 扩大了其中一部分选择，让更多认知任务也能按需交给外部工具和服务完成。
\n模型、Agent、技能模块、软件接口和工作流带来了不同的获取方式。工程师的方法可以变成技能模块，团队的研究流程可以变成 Agent，通用能力可以通过软件接口获得。
\n人数不能单独说明生产能力。同样规模的团队，拥有不同的数据、工具、基础设施和外部服务，能够承担的任务会很不一样。是否能够可靠交付，还要看这些能力怎样组合以及谁负责检验结果。
\n组织设计因而需要在“招多少人”之外，回答“需要控制哪些能力”。
\n沿着调用能力的思路，很容易想到“一人公司”：模型用外部的，设计交给 Agent，开发使用编程 Agent，运营自动化，最后只保留几个人。
\n但能从外部获得，与应不应该长期拥有，是两个问题。有些能力即使买得到，也可能决定产品差异、核心判断、用户关系、数据优势和长期学习速度，值得组织持续掌握。
\n比如，AI 公司可以调用外部模型；但如果它的竞争优势来自模型能力，完全不掌握模型，就可能把核心能力交到别人手里。讨论组织边界，需要判断哪些能力必须由自己控制。
\n我越来越倾向于从三个层次理解未来组织的能力来源：
\n三种安排可以共存，也可以随任务变化。同一个团队可以调用通用模型，同时长期维护自己的数据、评价标准和用户关系；“使用外部能力”不等于把与它相关的全部判断都交出去。
\n很多组织会自然认为：越高端、越昂贵的能力，越应该自己拥有。我认为还要看五个问题：
\n还要把调用成本算完整：接入和验证需要多少投入，服务涨价或中断怎么办，数据和记录能否迁移，换一家供应方要重做哪些工作。调用价格低，并不保证整体成本低。对于关键能力，可以先验证替代路径，再决定依赖到什么程度。
\n综合这些问题，长期投入应优先支持能够积累价值、并影响关键控制权的能力。
\n有可能，但不能直接推断公司会因为 AI 越来越小，最终走向一人公司。AI 降低了一部分生产成本和协调成本，也可能让组织承担更大的目标。
\n过去 20 个人做一个产品，未来可能同时运营十个产品。人数没增加，业务范围却扩大了。新的商业机会变得可行后，公司甚至可能继续招聘。
\n团队变小，不等于公司变小。大型组织可能由许多小型核心团队组成，共享模型、Agent、技能模块、数据、基础设施和渠道。公司除了容纳人员，也为这个能力网络提供支持。
\n即使团队更独立、能力更容易调用，也不意味着它们都应该成为独立公司。有些条件不会因为 Agent 出现就自动变便宜：
\n市场可以完成一次交易，困难的创新却常常需要长期、连续、无法事先写清合同的共同投入。AI 降低一部分交易成本，并不会自动消除这些组织需求。
\n过去，员工在公司边界里面，供应商和市场在外面。现在，一个外部模型、员工创建后全公司使用的技能模块，或者合作伙伴持续运行的 Agent，应该算内部还是外部能力？这条边界正在变得模糊。
\n除了雇佣关系，还需要看控制权的边界：什么目标由组织定义，什么数据由它掌握，什么能力由它持续积累，哪些决定权属于它，又由它承担什么结果。这些控制权和责任，也在构成组织的边界。
\n过去说核心团队，通常指 CEO、产品、技术、设计和运营负责人。未来，也许还需要从掌握什么判断和控制权来看。
\n定义问题、作出判断、设定评价标准、掌握组织独有的背景知识和关键决定权，这些能力决定了做什么、什么叫好、什么不能做，以及哪些能力需要积累。掌握这些能力的人，可能构成判断核心，其他执行能力则在核心之外动态组织。
\n一个很小的核心团队，可以连接很大的能力网络。这比“一人公司”更接近我理解的未来。
\n因为能力的获取方式变化了，长期积累背景知识、承担风险、建立信任、掌握关键资源和形成共同判断，仍然需要有人组织。更难交给一次交易解决的，是哪些事情值得长期一起做，以及怎样让积累的能力持续产生价值。所以我并不认为 AI 必然让公司消失。但公司的边界需要重新审视：哪些能力必须属于我们，哪些只需要使用，哪些绝不能失去控制？长期拥有、阶段性获得和即时调用，是帮助作出这些判断的三种安排。
\n前十篇讨论公司的内部，第十一篇把视线放到了边界。最后剩下的问题也更实际了：既然任务、流程、权力、责任、学习和公司边界都可以重新设计，我们今天从哪里开始？第十二篇回到真实团队，从一件工作开始。
\nAI 时代的分工、权力与人的价值
\n写到最后一篇，我想把前面的讨论放回一件具体工作。任务可以重新分配，事实需要核对，决定权要与责任相称，贡献和学习也不能被遗漏。明天回到团队，可以怎样开始？
\n我建议先选一条正在发生的工作链路，用五张地图看同一个问题。这里的“地图”，可以是一页表格或一张白板；它们帮助我们把容易分开讨论的事情放到一起，并不要求先建设一个平台。
\n下面贯穿使用一个假设示例：处理一位用户的商品损坏投诉。它用于说明怎样填写和讨论，没有对应的真实公司，也没有已经测得的提效结果。
\n“改造客服部门”太宽泛。可以先把范围定为：收到商品损坏投诉，核对材料，形成处理建议，由客服确认，执行后告知用户，并保留复核渠道。
\n在这个示例里，Agent 可以读取所需的订单信息、整理用户材料和起草建议；试行阶段不直接退款。客服确认处理方案，业务负责人处理规则之外的争议，技术负责人处理工具故障。
\n这是一次设计选择，并不代表所有投诉都应这样处理。先把目标、参与者、允许读取的信息和暂不处理的情况写清，后面才有共同的讨论对象。
\n沿着这次投诉，把实际动作列出来：接收材料、查询订单、核对处理规则、提出建议、确认执行、通知用户、处理复核。每一步都要说明由谁负责，以及什么情况才算完成。
\n例如，“已生成退款建议”只能交给客服判断，不能直接记成“退款完成”。支付系统返回成功后，还需要核对对应订单与退款记录，才能进入通知环节。缺少这一步，回复和真实动作就可能分开。
\n工作地图还应记录等待和返工。客服为什么需要重复询问，材料在哪里丢失，哪些交接只是在复制信息？先找到一个明确的摩擦点，再决定是否值得让 Agent 介入。
\n用户上传一张包装破损照片，并不自动证明商品损坏发生在哪个环节。订单已签收是一个有记录的事实；损坏原因可能仍未知；是否符合某条退款规则，还需要结合其他材料判断。
\n状态地图可以记录每项重要信息的来源、时间、确认者和争议。已经确认的事实、根据证据形成的推断、暂时未知的部分，要让接手者能分清。
\n信息变化以后，还需要知道谁被影响。用户补充了新照片，先前建议就可能失效；订单系统修正了退款状态，客服和后续 Agent 都应该看到更新。地图要帮助我们找到这些依赖，避免旧结论在别处继续驱动行动。
\n在这个试行安排中，Agent 可以请求缺少的材料、整理依据和提出建议；客服在既有授权范围内确认处理；超出规则或证据相互冲突时，由业务负责人复核。退款动作仍通过现有的授权渠道完成。
\n每类决定还要补上停止和升级条件。无法核对订单时暂停相关操作；支付状态不明时先核查，避免重复退款；工具故障由技术负责人接手。这里的“转人工”必须指向实际能接手的人。
\n用户可以要求复核，客服也可以对系统建议提出异议。复核期间哪些动作暂停、谁给出结论、怎样记录原因，都要写清。授权如果只有“谁可以做”，缺少“谁可以挑战和纠正”，就还不完整。
\n处理更快只是一个观察角度。还需要看用户问题是否解决，建议是否准确，是否发生重复退款、重新投诉或额外返工，以及客服花了多少时间纠正系统。
\n这些指标要有一致口径。例如，处理时长从哪个事件开始、到哪个事件结束，用户补材料的等待是否单独记录；重新投诉观察多长时间，哪些情况算同一个问题。没有约定口径，就很难比较前后变化。
\n这一张图还要接住第八篇的问题：谁获得了收益，谁承担了成本？若信息整理变快，却把更多复杂投诉集中给少数客服，平均时长可能掩盖负担的转移。贡献规则和案例的人，也需要正式的维护时间与认可。
\n在示例中，可以先约定把整理和维护纳入工作安排，共同复核节省时间和新增负担，再讨论如何使用这部分余量。这里记录的是需要落实的分配安排，不能用“未来会有更大成长空间”代替具体回报。
\n这次投诉结束以后，值得留下的可能是一次误判的原因、一条规则的歧义，或一段帮助新人理解证据的材料。不是每条工单都需要长篇复盘，重复出现或影响较大的问题应能被找到。
\n把问题写进文档还不够。谁负责修改，怎样检查，何时生效，使用旧版本的人怎样获知，都要落实。在这个示例里，规则负责人审核修改，用历史案例检查影响，再由客服小范围试用；出现新的错误时，可以恢复原规则。
\n新人也可以先对经过处理的案例独立判断，再与当时证据、专家意见和实际结果比较。案例应隐藏后续答案，只提供当时能够获得的信息。训练材料需要去掉不必要的个人信息，并取得相应使用授权。
\n学习地图要让我们看见两种积累：工作系统怎样改善，人的判断力怎样成长。两者都需要投入，也都不能只靠“经验已经存进知识库”来证明。
\n在这个假设示例中，我们暂时选择的改动是：让 Agent 整理订单和投诉材料，给客服提供带来源的建议草稿。决定权和退款执行渠道先沿用现有安排。这样比较容易观察信息整理是否有用，以及它是否增加了核对负担。
\n试行前，先记录现有工作的情况，约定负责人、观察周期、参与范围和停止条件。出现关键事实混淆、敏感信息越界或无法还原处理过程时，暂停这项改动，由负责人核查。日常检查的数量和频率应根据工作量与风险另行确定。
\n一次只改变范围清楚的部分，更容易解释观察结果。如果同时更换模型、调整人员、重写规则和改变考核，即使数字改善了，也很难判断原因。
\n把试行前后可比较的工作放在一起，观察结果、成本与副作用。任务类型和复杂度不同，就分别记录；无法解释的变化保留为未知，不急着归因于 AI。
\n以投诉处理为例，可以检查材料整理是否更完整、建议是否减少了反复查找、处理时间怎样变化、错误和复核有没有增加，以及贡献者和使用者的负担是否合理。这里没有通用的及格线，团队需要事先说明什么样的变化足以支持继续试行。
\n若节省的时间小于核对和维护投入，就可以缩小范围、调整方法或撤回。失败记录也有价值：它告诉后来的人，这个方法在什么条件下不值得使用。
\n五张地图是观察工作运行的五个视角，不能替代全部组织制度。正式职责、劳动关系、专业资质和必要的管理安排，仍要在各自范围内明确。
\n它们的作用，是帮助我们讨论一处变化怎样影响其他地方：信息更快了，决定权是否清楚；执行更便宜了，检查成本是否上升；经验被复用了，贡献者和新人是否也能受益。
\n《重新组织》没有一张适用于所有公司的未来架构图。我更希望这套文章能留下一个可以共同修订的起点：选一件真实工作，把依据、权力、代价和学习放在同一个讨论里，再做一次有边界的改变。
\n如果你试过，记录下场景、改动、结果和失败；如果你不同意，也把反例和理由留下。具体的实践会帮助我们知道，哪些判断成立，哪些需要修改。我们一起工作的方式，也可以在这个过程中继续变化。
\n《重新组织》第一季 · 完。
\n","searchText":"**AI 时代的分工、权力与人的价值**\n\n写到最后一篇，我想把前面的讨论放回一件具体工作。任务可以重新分配，事实需要核对，决定权要与责任相称，贡献和学习也不能被遗漏。明天回到团队，可以怎样开始？\n\n我建议先选一条正在发生的工作链路，用五张地图看同一个问题。这里的“地图”，可以是一页表格或一张白板；它们帮助我们把容易分开讨论的事情放到一起，并不要求先建设一个平台。\n\n下面贯穿使用一个**假设示例：处理一位用户的商品损坏投诉**。它用于说明怎样填写和讨论，没有对应的真实公司，也没有已经测得的提效结果。\n\n## 一、先选一件边界清楚的工作\n\n“改造客服部门”太宽泛。可以先把范围定为：收到商品损坏投诉，核对材料，形成处理建议，由客服确认，执行后告知用户，并保留复核渠道。\n\n在这个示例里，Agent 可以读取所需的订单信息、整理用户材料和起草建议；试行阶段不直接退款。客服确认处理方案，业务负责人处理规则之外的争议，技术负责人处理工具故障。\n\n这是一次设计选择，并不代表所有投诉都应这样处理。先把目标、参与者、允许读取的信息和暂不处理的情况写清，后面才有共同的讨论对象。\n\n## 二、工作地图：看清任务和交接\n\n沿着这次投诉，把实际动作列出来：接收材料、查询订单、核对处理规则、提出建议、确认执行、通知用户、处理复核。每一步都要说明由谁负责，以及什么情况才算完成。\n\n例如，“已生成退款建议”只能交给客服判断，不能直接记成“退款完成”。支付系统返回成功后，还需要核对对应订单与退款记录，才能进入通知环节。缺少这一步，回复和真实动作就可能分开。\n\n工作地图还应记录等待和返工。客服为什么需要重复询问，材料在哪里丢失，哪些交接只是在复制信息？先找到一个明确的摩擦点，再决定是否值得让 Agent 介入。\n\n## 三、状态地图：保留依据和不确定性\n\n用户上传一张包装破损照片，并不自动证明商品损坏发生在哪个环节。订单已签收是一个有记录的事实；损坏原因可能仍未知；是否符合某条退款规则，还需要结合其他材料判断。\n\n状态地图可以记录每项重要信息的来源、时间、确认者和争议。已经确认的事实、根据证据形成的推断、暂时未知的部分，要让接手者能分清。\n\n信息变化以后，还需要知道谁被影响。用户补充了新照片，先前建议就可能失效；订单系统修正了退款状态，客服和后续 Agent 都应该看到更新。地图要帮助我们找到这些依赖，避免旧结论在别处继续驱动行动。\n\n## 四、决定权地图：说明谁能决定，也说明怎样复核\n\n在这个试行安排中，Agent 可以请求缺少的材料、整理依据和提出建议；客服在既有授权范围内确认处理；超出规则或证据相互冲突时，由业务负责人复核。退款动作仍通过现有的授权渠道完成。\n\n每类决定还要补上停止和升级条件。无法核对订单时暂停相关操作；支付状态不明时先核查，避免重复退款；工具故障由技术负责人接手。这里的“转人工”必须指向实际能接手的人。\n\n用户可以要求复核，客服也可以对系统建议提出异议。复核期间哪些动作暂停、谁给出结论、怎样记录原因，都要写清。授权如果只有“谁可以做”，缺少“谁可以挑战和纠正”，就还不完整。\n\n## 五、价值地图：同时看结果、代价和分配\n\n处理更快只是一个观察角度。还需要看用户问题是否解决，建议是否准确，是否发生重复退款、重新投诉或额外返工，以及客服花了多少时间纠正系统。\n\n这些指标要有一致口径。例如，处理时长从哪个事件开始、到哪个事件结束，用户补材料的等待是否单独记录；重新投诉观察多长时间，哪些情况算同一个问题。没有约定口径，就很难比较前后变化。\n\n这一张图还要接住第八篇的问题：谁获得了收益，谁承担了成本？若信息整理变快，却把更多复杂投诉集中给少数客服，平均时长可能掩盖负担的转移。贡献规则和案例的人，也需要正式的维护时间与认可。\n\n在示例中，可以先约定把整理和维护纳入工作安排，共同复核节省时间和新增负担，再讨论如何使用这部分余量。这里记录的是需要落实的分配安排，不能用“未来会有更大成长空间”代替具体回报。\n\n## 六、学习地图：留下能影响下一次工作的经验\n\n这次投诉结束以后，值得留下的可能是一次误判的原因、一条规则的歧义，或一段帮助新人理解证据的材料。不是每条工单都需要长篇复盘，重复出现或影响较大的问题应能被找到。\n\n把问题写进文档还不够。谁负责修改，怎样检查，何时生效，使用旧版本的人怎样获知，都要落实。在这个示例里，规则负责人审核修改，用历史案例检查影响，再由客服小范围试用；出现新的错误时，可以恢复原规则。\n\n新人也可以先对经过处理的案例独立判断，再与当时证据、专家意见和实际结果比较。案例应隐藏后续答案，只提供当时能够获得的信息。训练材料需要去掉不必要的个人信息，并取得相应使用授权。\n\n学习地图要让我们看见两种积累：工作系统怎样改善，人的判断力怎样成长。两者都需要投入，也都不能只靠“经验已经存进知识库”来证明。\n\n## 七、五张地图画完，只改一个地方\n\n在这个假设示例中，我们暂时选择的改动是：让 Agent 整理订单和投诉材料，给客服提供带来源的建议草稿。决定权和退款执行渠道先沿用现有安排。这样比较容易观察信息整理是否有用，以及它是否增加了核对负担。\n\n试行前，先记录现有工作的情况，约定负责人、观察周期、参与范围和停止条件。出现关键事实混淆、敏感信息越界或无法还原处理过程时，暂停这项改动，由负责人核查。日常检查的数量和频率应根据工作量与风险另行确定。\n\n一次只改变范围清楚的部分，更容易解释观察结果。如果同时更换模型、调整人员、重写规则和改变考核，即使数字改善了，也很难判断原因。\n\n## 八、怎样知道这次改变值得保留\n\n把试行前后可比较的工作放在一起，观察结果、成本与副作用。任务类型和复杂度不同，就分别记录；无法解释的变化保留为未知，不急着归因于 AI。\n\n以投诉处理为例，可以检查材料整理是否更完整、建议是否减少了反复查找、处理时间怎样变化、错误和复核有没有增加，以及贡献者和使用者的负担是否合理。这里没有通用的及格线，团队需要事先说明什么样的变化足以支持继续试行。\n\n若节省的时间小于核对和维护投入，就可以缩小范围、调整方法或撤回。失败记录也有价值：它告诉后来的人，这个方法在什么条件下不值得使用。\n\n## 九、让结果告诉我们下一步\n\n五张地图是观察工作运行的五个视角，不能替代全部组织制度。正式职责、劳动关系、专业资质和必要的管理安排，仍要在各自范围内明确。\n\n它们的作用，是帮助我们讨论一处变化怎样影响其他地方：信息更快了，决定权是否清楚；执行更便宜了，检查成本是否上升；经验被复用了，贡献者和新人是否也能受益。\n\n《重新组织》没有一张适用于所有公司的未来架构图。我更希望这套文章能留下一个可以共同修订的起点：选一件真实工作，把依据、权力、代价和学习放在同一个讨论里，再做一次有边界的改变。\n\n如果你试过，记录下场景、改动、结果和失败；如果你不同意，也把反例和理由留下。具体的实践会帮助我们知道，哪些判断成立，哪些需要修改。我们一起工作的方式，也可以在这个过程中继续变化。\n\n**《重新组织》第一季 · 完。**","headings":[{"id":"section-1","title":"一、先选一件边界清楚的工作","level":2},{"id":"section-2","title":"二、工作地图：看清任务和交接","level":2},{"id":"section-3","title":"三、状态地图：保留依据和不确定性","level":2},{"id":"section-4","title":"四、决定权地图：说明谁能决定，也说明怎样复核","level":2},{"id":"section-5","title":"五、价值地图：同时看结果、代价和分配","level":2},{"id":"section-6","title":"六、学习地图：留下能影响下一次工作的经验","level":2},{"id":"section-7","title":"七、五张地图画完，只改一个地方","level":2},{"id":"section-10","title":"八、怎样知道这次改变值得保留","level":2},{"id":"section-11","title":"九、让结果告诉我们下一步","level":2}],"readingMinutes":7,"characterCount":2496,"images":[{"src":"images/s01-12.svg","thumb":"images/s01-12.svg","alt":"用五张地图检查一次退款处理","width":1000,"height":700,"description":"工作地图检查退款怎样完成以及人与Agent怎样协作。状态地图区分已确认、推断和未知，并保留订单与沟通证据。决定权地图明确谁有权处理、谁受理异议和复核。本次试行由客服确认处理，Agent只整理材料和建议，不退款、不关单；规则外由业务负责人复核，并保留暂停入口。价值地图检查谁受益、谁承担成本、贡献怎样回报，并同时记录用户结果、处理负担与维护投入。学习地图检查哪些失败改变规则、哪些判断成为新人练习。先改变一个摩擦点，比较结果，再决定是否扩大。"}],"sourceHash":"c83f10140b536aeba12bcc9e7f163a6e35655ae884c2e6514ce82da195f7f393","description":"写到最后一篇，我想把前面的讨论放回一件具体工作。任务可以重新分配，事实需要核对，决定权要与责任相称，贡献和学习也不能被遗漏。明天回到团队，可以怎样开始？"}]