04 · 建成数字员工平台：从岗位到可运营

开篇 · 真实案例：纪要 Bot 为什么不够上岗

00 / 案例背景

能写纪要 ≠ 能上岗。项目组要的是：会议变成任务、任务有人跟、逾期能升级、周报有依据——而不是又一篇「写得像人」的纪要。

1. 岗位背景：会议结束之后，项目组真正需要谁来把事情推进下去

03 已经说明，单个 Agent 必须被封成可验收产品。但 ToB 项目组接下来的难题不是“再做一个会聊天的助手”，而是会议结束后谁来持续把信息变成行动：识别决策与待办，校验负责人和截止日期，写入台账，提前提醒逾期风险，把异常交给正确的人，并在周报中保留可追溯的依据。

这是一份岗位责任，不是一轮对话能力。它横跨会议系统、任务台账、日历、消息和周报，持续服务多个项目成员，也需要被运营、考核和治理。本篇因此从 ToB 产品组的纪要 Bot 出发，讨论如何把 Agent 能力装入一个可注册、可配置、可监督的办公数字员工岗位；不重讲单 Agent 设计卡，也不展开工作台 UI。

上岗前提：只会把录音整理成一篇纪要，不代表能承担项目协调岗位。岗位必须写清服务对象、交付对象、处理边界、升级规则和衡量指标，否则“自动化”只会把遗漏更快地写进文档。

2. 核心问题：为什么满意度很高的纪要 Bot，仍然不够上岗

第一版纪要 Bot 的输出很流畅：录音转文字、套模板、提炼结论，参会者普遍觉得“比人工记得全”。但这份满意度测量的是文风和即时体验，而不是项目是否被推进。待办若没有负责人、截止日期和系统记录，就仍然只是段落；逾期若无人提醒和升级，就仍然要靠项目经理在群里追；周报若不能回到来源会议和任务状态，就仍然需要人手拼凑。

问题不在于 Bot 没有总结能力，而在于它没有被赋予岗位的输入、输出和责任链。它既不知道哪些字段缺失时必须追问，也没有权限或流程去创建任务，更没有指标证明任务是否被闭环。把这类 Bot 直接交给项目组，会形成一种危险错觉：信息好像被处理了，行动却没有真正发生。

岗位化原则：评价纪要 Bot 时，不问“写得像不像人”，而问“会议产生的任务是否被创建、有人负责、按时跟进、异常可升级、结果可回溯”。前者是内容生成，后者才是数字员工的交付责任。

3. 事实证据：两周后的翻车，暴露了从文档到行动的断层

项目组上线后很快发现，Bot 并没有替代项目协调工作，反而让遗漏更隐蔽：会议纪要按时出现，但待办没有进入台账，责任人和截止日期经常空着；到了第二周，逾期无人催办，周报仍由同事通宵从聊天记录和 Excel 中拼出来。复盘时，团队才意识到它交付的是“文本”，而不是“岗位结果”。

时间线	发生了什么	岗位缺口
上线周	录音转文字、套模板出纪要，满意度很高	只验收「写得像」，无闭环指标
第 1 周	待办常空着负责人/截止；没人进台账	无任务创建流程，无字段校验
第 2 周	逾期没人催；周报仍靠人通宵拼 PPT	无提醒/升级/周报素材链路
复盘	结论：做的是聊天能力，不是岗位	缺岗位说明书 → 流程 → 权限 → 指标

flowchart TB Meeting["会议结束\n录音、议程、参会人"] --> Bot["纪要 Bot\n转写与总结"] Bot --> Minutes["一篇纪要\n看起来完整"] Minutes --> Gap1["待办停在段落\n负责人 / 截止缺失"] Gap1 --> Gap2["未写入项目台账\n没有 Task ID"] Gap2 --> Gap3["无 D-1 提醒与逾期升级\n项目经理人工追"] Gap3 --> Gap4["周报无可靠素材\n仍靠人工拼接"] Meeting --> Role["办公数字员工岗位\n提炼、校验、创建、跟进、升级、汇报"] Role --> Task["任务台账\n负责人、截止、状态、来源会议"] Task --> Follow["提醒与升级\n记录处置结果"] Follow --> Report["可追溯周报素材\n会议与任务可回看"]

图中的分叉不是模型能力强弱之争，而是是否存在岗位链路。纪要 Bot 在“文本生成”处结束；数字员工则要把会议事实经由字段校验、任务创建、持续跟进和例外升级，交付为可被项目组使用和验收的行动结果。

4. 执行结论：按平台路径重做，把能力封进可运营岗位

项目组与平台配置同学重新对齐分工：03 解决“单个 Agent 产品如何验收”；本篇解决如何把已具备的能力封装成可运营岗位。第一步不是继续优化纪要 Prompt，而是把岗位目标、知识、流程、权限、协作和指标配置到平台中，使每一次会议都能进入同一条可观察、可恢复、可追责的执行链。

案例主线：认清岗位 → Agent vs 上岗 → 会议到执行链 → 八类能力装配 → 岗位说明书 → 企业知识 → 流程配置 → 权限矩阵 → 人机分工 → 运营看板 → 结果验收 → 平台产物包。
人物线：项目组（业务方）· 平台配置同学（落地）· 可回看 03 小林的产品规格思维。

目标：会议变成可跟进任务，而非仅生成纪要；岗位：明确服务对象、交付物、边界与升级规则；平台：注册知识、流程、权限与指标；运行：会议触发 → 提炼校验 → 建任务 → 提醒升级 → 周报回溯；验收：以任务闭环率、提醒及时率和周报可追溯性裁定是否上岗。

纪要 Bot 上岗前复查

会议中的待办是否能够形成带负责人、截止日期和来源的任务对象，而非停留在段落中？
字段缺失、任务逾期和权限不足时，系统是否有明确追问、升级或人工接管出口？
项目组能否从周报中的每项结论回到原始会议、任务状态和处置记录？
岗位表现是否由闭环与及时性指标衡量，而非仅靠“纪要写得好”的主观满意度？

思考：数字员工的价值，不是替人写得更快，而是替组织把责任链走完

一篇纪要可以很快被生成，但真正稀缺的是让每个待办都拥有负责人、期限、状态和异常出口。只有这些责任被系统持续承接，会议才不会在散会那一刻重新变成一堆待整理的信息。

接下来的章节不再把注意力放在 Bot 的表达能力，而是逐步回答：这个岗位服务谁、管理什么对象、需要哪些能力、如何被约束、又如何被平台长期运营。

Part 01 · 认清岗位：要的不是 Bot，是办公数字员工

01 / 定义

项目组真正要买的，是「让信息变成行动」的岗位结果。拿掉岗位职责和交付指标，剩下的只是聊天窗口。

1. 岗位背景：项目组购买的不是对话次数，而是持续推进的结果

项目经理每天面对的不是单次会议，而是一条持续变化的项目链：会议里出现决策和待办，邮件补充风险，任务状态不断变化，周末前又必须产出可信的周报。若每个环节都依赖人记住、复制、催办和汇总，协作成本会随着项目数量线性上升，遗漏则常常在逾期后才被发现。

办公数字员工的意义，是把这条链中的稳定责任交给一个可被配置和管理的岗位。它服务项目经理与成员，不是为了多开一个聊天窗口，而是持续交付可使用的纪要、任务、提醒、异常升级和周报依据。因此，岗位必须先定义业务对象、输入事件、交付物、边界与指标，之后才讨论模型和工具。

定义前提：若只能描述“它会总结会议”，却不能说明由谁使用、何时触发、任务怎样进入台账、逾期怎么处理和什么算做成，就还没有定义一个可上岗的数字员工。

	纪要 Bot（翻车版）	办公数字员工（目标态）
输入	录音 / 聊天记录	会议结束事件 + 项目台账 + 关键邮件
输出	一篇像人写的纪要	纪要 + 任务 + 提醒 + 升级 + 周报依据
成功标准	写得像	任务闭环率、提醒及时率、周报可追溯
平台要管	一个对话入口	岗位职责 · 知识 · 系统 · 流程 · 指标
失败表现	文风不好看	任务丢、逾期无人、周报不可信

2. 核心问题：为什么 Bot 的能力描述无法替代岗位责任

Bot 的描述通常围绕它会什么：转写、总结、问答、生成表格。它没有天然的责任边界，也没有需要被衡量的业务结果。于是同一份纪要即使缺少负责人、任务未落库、提醒没有发出，系统仍可能把输出视为成功，因为“文本生成”已经完成。

岗位的描述则必须围绕它负责什么：面对哪些项目对象，以何种规则把信息转换成行动，在何种风险下停止或升级，交付哪些可验证结果。能力只是完成责任的手段；当能力、系统权限和流程规则没有被绑定到岗位，Agent 再会做事也只能是一个不可控的通用工具。

岗位化原则：把“它能做什么”改写为“它要对什么结果负责”。每一个职责都要对应输入、输出、失败出口和指标；没有这些要素的能力，不能成为项目组可依赖的岗位承诺。

3. 事实证据：纪要 Bot 与办公数字员工的交付对象根本不同

项目组用同一场会议测试两种形态。纪要 Bot 只接收录音和聊天记录，输出一篇看似完整的纪要；数字员工则以会议结束事件为触发，结合项目台账和关键邮件，识别待办并校验字段，创建任务、记录来源、安排提醒，在异常时升级，最终将任务状态汇集为可回溯的周报素材。两者的差异不在措辞，而在交付对象是否进入组织的执行系统。

职责

服务谁、交什么

服务项目经理与研发/产品；交纪要、任务、提醒、周报依据。

能力

业务动作可配置

提炼待办、写台账、催办、汇总风险——按岗位勾选，不全开。

执行

系统内落地

Word / Excel / 日历 / 任务 API；操作可审计。

交付

结果可验收

「写得像」不算；闭环率、及时率、可追溯才算。

flowchart TB Trigger["输入事件\n会议结束、关键邮件、台账变更"] --> Extract["提炼决策与待办\n保留来源"] Extract --> Check{"字段是否完整？\n负责人、截止、项目"} Check -->|否| Clarify["追问 / 标记待补\n不创建无主任务"] Clarify --> Extract Check -->|是| Create["创建任务对象\nTask ID + 来源会议"] Create --> Follow["D-1 提醒与状态跟进"] Follow --> Risk{"是否逾期或高风险？"} Risk -->|否| Report["汇集周报素材\n任务与会议可回溯"] Risk -->|是| Escalate["升级项目经理\n附交接包与处置记录"] Escalate --> Report Report --> Metrics["岗位指标\n闭环率、及时率、可追溯性"]

流程图让岗位边界变得可验证：缺字段时不允许伪造完整任务，逾期时不允许静默等待，周报中的结论必须能回到任务和会议。任何一个节点没有对象、规则、权限或指标，岗位链路就会退化成“生成一篇纪要”。

4. 执行结论：先把岗位一句话写死，再让平台把责任跑起来

项目组为这个数字员工确定的最小岗位目标是：把会议、邮件和项目资料中的行动项整理为清晰任务，并持续跟进到可追溯的周报。这个目标决定了它需要什么知识、哪些系统权限、什么流程与何时升级，也决定了验收不能只看一篇纪要，而要看任务闭环、提醒及时和周报回溯。

企业级数字员工 = 岗位职责 + 业务能力 + 系统执行 + 结果交付

项目组岗位目标（一句话）：
把会议 / 邮件 / 项目资料整理成清晰任务，并持续跟进到周报。

可否决自检：
- 能否指出「哪类任务没进台账」算失败？不能 → 目标虚。
- 成功标准是否含闭环 / 及时 / 可追溯？没有 → 仍在验收文风。
- 缺负责人、截止或权限时是否有追问 / 升级出口？没有 → 不能上岗。

办公数字员工岗位自检

是否明确服务对象、负责的业务对象、触发事件和最终交付物？
每个任务是否都必须具备负责人、截止时间、项目归属和来源记录？
缺字段、逾期、权限不足和高风险处置时，是否有明确的停止、追问或升级规则？
是否用闭环率、提醒及时率和周报可追溯性来验收岗位，而不是用文本满意度代替？

思考：岗位不是把更多能力绑在一起，而是让每个动作都有一个必须完成的去处

“会总结、会写表、会发消息”这些能力可以被任何 Bot 拥有；岗位的不同在于，它不能把待办留在一段漂亮的文字里，也不能把异常留在一次没有下文的提醒中。

当输入被转成任务对象、任务被持续跟进、异常被交给正确的人、结果能回到来源，Agent 才开始像组织中的一个岗位，而不仅是一个随时可用的工具。

这一幕带走：要买的是岗位结果，不是 Bot 文风。岗位一句话写不满，不要谈平台配置。

Part 02 · 能力引擎 vs 上岗：Agent 能做，不代表能上岗

02 / 边界

项目组已有可用的 Agent 能力（理解、拆解、调工具）。缺的是岗位封装：服务对象、规则、权限、升级、考核——由平台注册，不是写在一次 Prompt 里。

1. 能力背景：Agent 是执行引擎，岗位才是组织可以委派的责任单元

经过前两篇文章的设计，团队已经拥有具备目标理解、任务规划、工具调用、上下文管理、状态恢复和验证反馈的 Agent 能力。它能分析会议、提炼待办、调用任务 API，甚至自行检查结果。但这些能力回答的是“这次动作能不能做”，并不自动回答“谁允许它做、它对谁负责、出了例外谁接手、如何长期考核”。

数字员工平台要完成的，正是从能力到岗位的封装：将通用 Agent 绑定到服务对象、业务对象、知识范围、流程、权限、协作规则和指标。引擎负责在被授权的边界内执行，平台负责为它登记身份、配置责任、保存运行事实并治理风险。没有这层封装，能力再强也只能在单次任务中表现，无法成为组织可依赖的编制。

上岗前提：“能理解会议并创建任务”只能证明能力可用。只有服务对象、职责边界、系统权限、升级条件和考核指标都被平台注册并可审查，组织才可以把持续工作委派给它。

Agent 回答（能不能做）	数字员工回答（为谁做什么）
理解目标 · 拆任务 · 调工具 · 取知识 · 管状态 · 验结果	服务项目负责人与团队 · 负责纪要/任务/跟进/周报 · 不替业务拍板 · 可访哪些盘 · 逾期升级谁 · 交哪些指标

2. 核心问题：为什么“能调工具”会在真实组织中变成风险

如果把通用 Agent 直接暴露给项目组，它可能在当前对话里做对事，却无法稳定地做对岗位的事。它不知道服务边界是当前项目还是所有项目，不知道“下周处理”是否能被当作待办，不知道外发周报是否必须审批，也不知道任务长期未关闭时应提醒谁。模型临场判断会把组织规则变成随机行为。

另一个风险是责任漂移：当 Bot 创建了错误任务、遗漏了逾期或读到了不该访问的资料，团队无法从一次 Prompt 中找回职责、权限和审计记录。平台岗位封装的意义不是限制能力炫技，而是让每一次能力调用都挂在明确的业务责任与治理规则下。

边界原则：能力层可以复用，岗位层必须专属。通用能力不直接拥有业务权限；权限、对象和升级规则只由具体岗位实例授予，并且每次运行都能回到岗位配置与审计记录。

3. 事实证据：纪要岗位要上岗，还需要被平台补齐的四类约束

项目组复盘纪要 Bot 后，发现它并不缺“总结”或“调用工具”的能力，真正缺的是岗位配置。平台配置同学为它补上固定的服务对象、待办字段规则、工具权限矩阵和结果看板，才使同一套 Agent 能力能够稳定地服务项目协调，而不会随着每次对话改变行为边界。

对象

服务谁

Bot 版：谁问谁答。

上岗版：钉死项目经理 + 本项目成员。

规则

什么算待办

Bot 版：模型临场判断。

上岗版：模板字段 + 缺负责人则待补全。

权限

能改什么

Bot 版：工具能调就调。

上岗版：矩阵卡死外发与改权限。

考核

怎样算合格

Bot 版：写得像。

上岗版：五指标看板。

flowchart TB Engine["Agent 能力引擎\n理解、规划、工具、上下文、状态、验证"] --> Register["平台注册岗位实例"] Register --> Role["岗位说明书\n服务项目经理与本项目成员\n交付任务闭环与周报依据"] Role --> Knowledge["知识范围\n项目模板、台账、术语"] Role --> Process["流程规则\n提炼、校验、创建、跟进、升级"] Role --> Permission["权限矩阵\n可写任务，不可外发 / 改权限"] Role --> Metric["考核指标\n闭环率、及时率、可追溯性"] Knowledge --> Run["受控运行\n每次执行绑定岗位与项目"] Process --> Run Permission --> Run Run --> Audit["运行记录与异常升级"] Audit --> Metric Metric --> Review["运营复盘\n继续、调整或停岗"]

图中没有“模型自动获得所有权限”的路径。能力引擎必须经过岗位注册，才能获得本项目、当前流程和最小权限下的执行资格；运行结果再回到指标和审计，帮助团队判断岗位是否继续有效，而不是只判断模型有没有生成内容。

4. 执行结论：先判断是否需要岗位，再决定是否进行平台封装

并非每个 Agent 都要上岗。一次性问答、草稿生成或局部分析，停在能力层或单 Agent 产品即可；但只要任务需要持续跟进、跨系统写入、多人协作、例外升级和审计考核，就必须将能力注册为岗位，并由平台承担配置、运行和治理责任。

判断：只需一次性问答 / 草稿？停在能力层；需要持续跟进、跨系统、多人协作、可审计？进入岗位封装。注册：写清服务对象、责任对象、规则、权限、升级和指标。运行：能力只在岗位授予的边界内行动。复盘：用看板与审计判断继续、调整或停岗。

上岗判断自检

这项工作是否具有持续责任，而不只是一次性生成或问答需求？
是否能明确写出岗位服务谁、负责什么对象、不负责什么以及何时升级？
工具、知识和数据权限是否由岗位实例的最小权限矩阵授予，而非由模型自行扩张？
是否存在能衡量岗位结果、审计异常和指导调整/停岗的指标与复盘机制？

思考：Agent 的能力决定它能做什么，岗位的边界决定组织敢把什么交给它

组织从不因为一个人“会用很多工具”就直接授予所有业务权限；数字员工也一样。真正的信任来自职责、规则、授权和考核共同构成的岗位约束，而不是模型能力列表越来越长。

当能力引擎被放进可观察、可配置、可撤销的岗位容器里，团队才可以在复用技术能力的同时，保持对业务责任和风险的控制。

这一幕带走：Agent 是能力底座；数字员工是岗位封装；业务结果才是目标。能做 ≠ 能上岗。

Part 03 · 工作对象：一条「会议到执行」链

03 / 工作方式

办公数字员工盯的是流程对象，不是单篇文档。平台注册的是「会议→任务→跟进→升级→周报」整条链。

1. 工作背景：项目协调不是写完纪要，而是维护一条持续变化的对象链

会议、邮件和聊天中的信息会不断变化：一个决定可能引出多个待办，待办需要负责人和截止日期，执行中会出现阻塞，接近截止时要提醒，逾期时必须升级，最后还要进入周报。项目组真正管理的是这些有状态、有关联、可追溯的业务对象，而不是一篇静态文档。

数字员工因此不应把会议纪要当作终点，而要把它当成流程的第一份输入。平台需要为会议、任务、提醒、例外工单和周报素材建立关联，让每一次状态变化都有来源、责任人和后续动作。只有对象在系统中持续流动，岗位才可能被衡量和交接。

对象前提：没有 Task ID、负责人、截止时间或来源会议的“待办”，只是待整理的文本；没有状态变化和提醒记录的“任务”，只是另一份静态清单。

触发：评审会结束 / 关键决策邮件到达
提炼：决策、待办、负责人、风险
创建：任务写入台账 + 日历截止
跟进：进度、阻塞、到期前提醒
协作：逾期 / 缺负责人 → 升级项目经理
交付：周纪要归档 + 周报素材包

2. 核心问题：为什么文档链路会在项目最需要推进时断掉

纪要 Bot 通常在生成文档后就结束。此时文本里可能已经出现“张三下周完成接口联调”，但系统没有判断“张三”是否是有效负责人、“下周”是否需要具体日期，也没有把它写进台账或日历。对 Bot 来说输出已完成，对项目组来说最关键的执行动作尚未发生。

链路后半段的断裂更难被及时发现：没有 D-1 提醒就没有逾期前干预；没有例外工单就无法把风险交给项目经理；没有来源关联，周报就无法区分已完成事实与尚未确认的口头承诺。平台管理流程对象的价值，正是让这些断点成为可见的状态，而非等待人工在复盘时发现。

流程原则：每一个阶段都要把前一阶段的输出转换为下一个阶段可操作的对象，并保存关联。文本只能作为证据和展示，不能代替任务、提醒、例外或周报素材本身。

环节	纪要 Bot 断点	平台要盯的对象
提炼	有文无字段	决策/待办/人/截止/风险是否齐全
创建	待办停在段落里	台账行 + Task ID + 日历事件
跟进	无人催	D-1 提醒记录、状态变更
升级	靠人发现逾期	例外工单 + 交接包
交付	周报靠人拼	可追溯素材包（来源会议可点开）

3. 事实证据：同一场会议如何变成五类可追溯交付物

项目组将“评审会结束”注册为流程触发器。数字员工提炼出决策与待办后，先校验负责人、截止和项目归属；字段完整的待办生成带来源会议的 Task ID 并写入台账，字段缺失的待办进入待补全队列。后续每次提醒、状态变更和升级都继续绑定同一 Task ID，周报只读取这些经过验证的对象，而不是重新从聊天记录猜测进度。

纪要结构化，含未决项

任务清单负责人+截止

提醒到期/逾期

升级例外给对人

周报依据可追溯

flowchart TB Meeting["会议 / 关键邮件\n来源对象"] --> Parse["提炼决策、待办、风险\n结构化纪要"] Parse --> Check{"负责人、截止、项目\n是否完整？"} Check -->|否| Pending["待补全队列\n通知相关成员"] Pending --> Check Check -->|是| Task["任务对象\nTask ID + 来源会议 + 台账行"] Task --> Calendar["日历截止与 D-1 提醒"] Calendar --> Progress["状态跟进\n完成 / 阻塞 / 逾期"] Progress --> Risk{"逾期或高风险？"} Risk -->|是| Exception["例外工单\n升级项目经理 + 交接包"] Risk -->|否| Weekly["周报素材包\n任务、状态、来源可回溯"] Exception --> Weekly Weekly --> Archive["归档纪要与审计记录"]

五类交付物之所以要同时存在，是因为它们承担不同责任：纪要保存会议事实，任务承接执行责任，提醒推动时间节点，升级处理例外，周报汇总经过验证的进展。缺少其中任何一类，会议到执行都会在某个节点重新退回人工记忆。

4. 执行结论：把对象链注册成流程模板，用状态和关联来验收岗位

平台配置时，项目组不应只上传一个纪要模板，而要注册一条包含触发、字段校验、对象创建、提醒、升级和归档规则的流程模板。流程的验收也不再是“纪要有没有生成”，而是每个会议中的合格待办是否进入台账，逾期是否有处置记录，周报是否可回到来源会议和任务状态。

触发：会议结束 / 关键邮件到达；提炼：决策、待办、负责人、截止、风险；校验：缺字段进入待补全，不创建无主任务；创建：Task ID 写台账并关联来源；跟进：日历截止、D-1 提醒、状态更新；例外：逾期 / 高风险生成工单并升级；交付：周报素材与纪要归档可回溯。

会议到执行链自检

每个待办是否都能关联到来源会议、项目归属、负责人和明确截止时间？
字段不完整时，系统是否停止创建正式任务并发起待补全，而非默默丢弃或猜测？
提醒、状态变更、逾期升级和处置结果是否持续绑定同一个任务对象？
周报中的每一项进展或风险，是否都可回到已验证的任务与来源记录？

思考：流程自动化的关键，不是把路径画得更长，而是让每一次交接都留下可继续工作的对象

会议结束后最容易丢失的，往往不是文字，而是责任从谁转给谁、下一步该做什么、何时需要升级。把这些信息固定为可查询、可更新、可关联的对象，才让自动化真正接住了协作。

当项目组开始按对象链而非按文档检查工作，数字员工就不再只是会议的记录者，而成为推动项目从讨论走向执行的流程参与者。

这一幕带走：交付物不是「一段总结」，而是让会议真正转化为行动的一串产物。平台盯流程对象，不盯单篇文档。

Part 04 · 平台能力目录：八类可配置、可验收

04 / 能力装配

能力不是越多越好。要覆盖本岗关键任务与风险，并在平台上可观察、可配置、可验收——按岗位勾选装配，而不是全开。

1. 装配背景：能力目录是平台库存，不是每个岗位的必选菜单

平台需要提供足够的通用能力，才能支持不同数字员工岗位：理解岗位、规划任务、调用系统、读取企业知识、保存状态、协作升级、识别风险、验证结果。但能力目录只说明“平台可以提供什么”，并不意味着项目协同岗应该全部打开。每多开一项能力，就多了一份权限、失败态、审计与运营责任。

对纪要岗位而言，装配的起点必须是 Part 03 的关键对象链。能力是否进入本岗，只看它能否让会议到任务、提醒、升级和周报这条链更可靠，是否能给出可观察的验收信号，以及风险是否在当前试点可控。无法回答这三件事的能力，即使很吸引人，也应该留在目录中而非装进岗位。

装配前提：能力不是开关越多越好。没有岗位价值、边界、失败出口和验收信号的能力，不能因为“未来可能有用”就进入生产岗位。

能力	项目组配置要点	可验收信号	本岗可砍？
01 岗位理解	只服务本项目组会议闭环	不擅自接财务审批类请求	不可砍
02 任务规划	会议→任务的依赖顺序	无负责人的待办不进入「已分派」	不可砍
03 企业知识	周报模板、升级 SLA	引用带版本号	不可砍
04 系统操作	Word/Excel/日历/任务 API	操作留审计	不可砍
05 状态记忆	会议 Task ID、台账版本	中断后可续跟进	弱化可（短周期试点）
06 人机协作	缺负责人/高风险升级	升级包含完整上下文	不可砍
07 风险识别	禁外发、禁改权限	高危动作被拦或待确认	不可砍
08 结果验证	对照台账字段完整性	缺截止日则打回	不可砍

2. 核心问题：为什么能力全开会让岗位从可控变成不可运营

“先把能力都打开，后面再限制”的做法会同时扩大范围和责任。自动对外发邮件需要收件人、内容和审批策略；跨事业部知识库需要数据隔离与版本治理；财务审批理解会引入完全不同的业务规则和风险。它们并不因为同样由 Agent 执行，就可以与项目协调工作共享一套边界。

更隐蔽的问题是无法验收。若团队只写“开启企业知识”“启用任务规划”，却没有定义引用版本、无负责人时的状态、计划是否被执行等可观察信号，运营看板就无法判断能力是在创造价值还是制造噪声。能力名称不是产品承诺，配置与验收才是。

取舍原则：先保障关键路径的可靠性，再扩展便利性；权限与验证不可弱化，长程记忆可在短周期试点中收缩；高风险能力默认关闭，只有通过人工闸或新增规格后才可能开启。

3. 事实证据：项目协同岗如何从八类能力中选出最小可运营组合

项目组将八类能力逐项映射到“会议到执行”链：岗位理解防止接入非项目协调请求，任务规划保证无负责人待办不被误标为已分派，企业知识提供受版本控制的周报模板与 SLA，系统操作把任务与日历真实落地，人机协作处理缺字段和高风险例外，风险识别挡住外发与改权限，结果验证把缺截止日打回。只有长程状态记忆在短周期试点中允许被弱化，其余能力都直接保护关键路径。

flowchart TB Role["岗位关键路径\n会议 → 任务 → 跟进 → 升级 → 周报"] --> Candidate["平台能力候选\n八类能力目录"] Candidate --> Value{"是否直接支撑\n岗位交付对象？"} Value -->|否| Defer["暂不装配\n保留在平台目录"] Value -->|是| Signal{"是否写得出\n可验收信号？"} Signal -->|否| Specify["补规格\n输入、边界、失败态、验收"] Specify --> Candidate Signal -->|是| Risk{"是否涉及高风险\n外发、改权限、跨域数据？"} Risk -->|是| Gate["默认关闭或人工闸\n先做权限/审批规格"] Risk -->|否| Enable["装配进岗位\n绑定流程、权限和审计"] Gate --> Enable Enable --> Pilot["试点运行\n采集指标与失败证据"] Pilot --> Review{"达成岗位指标\n且风险可控？"} Review -->|否| Adjust["调整、弱化或停用能力"] Adjust --> Candidate Review -->|是| Keep["保留为岗位能力"]

这张流程图把能力装配变成一个可回退的产品决策。被延后的能力不是“平台做不到”，而是当前岗位无法证明其价值或承受其风险；试点后的指标与异常记录又会决定能力是保留、收缩还是停用。

本岗砍掉项示例：财务审批理解、跨事业部知识库、自动对外发邮件。它们演示很炫，但当前岗位的风险大于收益，第一期一律不装。

4. 执行结论：按岗位勾选能力，把验收信号写进配置

项目组的装配顺序是：先覆盖会议到周报的关键路径，再为每项能力写下配置边界与验收信号，随后通过权限闸处理高风险操作，最后在小范围试点中用实际闭环率、提醒及时率和异常记录做复核。能力目录属于平台，能力组合属于岗位，放行结论属于这一次有证据的试点。

选择：从岗位关键路径反推必需能力；规格：每项写配置、边界、失败态和验收信号；风控：外发 / 改权限 / 跨域数据默认关闭或人工确认；试点：以真实任务收集闭环、及时性和拒绝记录；复盘：达标保留，不达标调整、弱化或停用。

能力装配自检

每项已开启能力是否直接服务于本岗位的一条关键流程或风险控制点？
是否为每项能力写明了配置范围、失败出口和可在看板中观察的验收信号？
外发、改权限、跨部门知识等高风险能力是否默认关闭，并有独立的人机闸？
试点结束后，是否能依据指标与异常记录决定保留、调整、弱化或停用？

思考：克制地装配能力，不是在少做功能，而是在保护岗位承诺的可信度

一个岗位不需要拥有平台所有能力，正如项目协调员不应该同时承担财务审批、跨组织信息分发和权限管理。把能力留在目录中，等到有新的岗位问题、边界和验收时再启用，本身就是平台成熟的表现。

当每个开关背后都有岗位价值、风险策略和验收信号，团队才不会把“功能数量”误当成“数字员工的能力”。

这一幕带走：平台侧这是能力目录；上岗时按岗位勾选装配。写不出验收信号的能力，等于没开。

Part 05 · 先写岗位说明书，再实例化员工

05 / 岗位

岗位边界越清楚，流程、权限、指标越好落。规则：写不满说明书，不开实例化。

1. 岗位背景：实例化之前，组织必须先说明自己要委派什么责任

点击“新建数字员工”很容易，但这只是创建一个技术实例，并不会自动产生组织责任。项目协调岗到底服务哪个项目、接收哪些任务、什么时候必须升级、哪些事情绝不代替人做，都会决定后续流程、知识、权限和指标如何配置。若这些信息没有被先写成说明书，平台只能给一个拥有通用能力却没有责任边界的 Bot。

岗位说明书是数字员工的组织合同。它将名称、服务对象、使命、核心职责、非职责、交付标准和边界固定下来，使产品经理、平台配置同学、项目经理和安全评审能够对同一份承诺达成一致。实例化应当是审核说明书后的结果，而不是用一个默认实例反过来逼团队补定义。

注册前提：说明书里的每个字段都必须能导出后续配置：服务对象导出数据范围，职责导出流程与 SLA，非职责导出拒绝规则，交付标准导出指标与验收。字段写不满，岗位就不能创建。

字段	写什么	写糊会怎样
岗位名	具体到岗，不写「智能助手」	权限与指标无法挂靠
服务对象	角色 + 范围（本项目）	谁都能指挥 → 冲突
使命（一句话）	完成态语言	「提升效率」无法验收
核心职责	可观察动作 + SLA	职责虚 → 流程配不下去
非职责	明确不拍板、不承诺、不改权限	靠「聪明」越权
交付标准 / 边界	准确、清晰、按时；敏感会需确认	上线后扯皮

2. 核心问题：为什么先建实例、后补说明书会制造越权与扯皮

没有岗位说明书的数字员工会把每次对话都当作新的临场任务。任何人都可能要求它处理不属于本项目的资料，项目经理可能期待它替自己做优先级决定，团队也可能默认它可以对外承诺工期。等到出现错误外发、任务误分派或敏感会议被错误分发时，大家才发现没有一条明确的职责或边界可以据以拒绝。

这种问题不能靠在 Prompt 里多写一句“请谨慎”。Prompt 无法替代可审查的服务范围、不可变更的拒绝规则和可考核的交付标准。只有岗位说明书先行，平台才知道该给哪些系统权限、何时中止、由谁接管，以及什么结果说明岗位没有履职。

实例化原则：先定义岗位，再配置能力；先声明非职责，再授予权限；先确定验收，再启动运行。任何顺序颠倒都会让平台失去治理抓手。

3. 事实证据：项目协同岗如何从说明书变成可配置岗位

项目组没有把“智能会议助手”直接放进工作群，而是将它定稿为“办公数字员工-项目协同”。说明书明确它只服务本项目的项目经理与研发、产品成员；使命是让会议信息变成可跟进的行动；会后两小时内产出纪要、写入台账、D-1 提醒、逾期升级、周五输出周报素材；同时明确不代替业务负责人排序、不对外承诺工期、不修改权限或审批流。

【岗位说明书 · 办公数字员工 · 项目协同岗】
岗位名：办公数字员工-项目协同
服务对象：项目经理 + 研发/产品同学（本项目）
使命：让会议信息变成可跟进的行动

核心职责：
  - 会后 2h 内产出结构化纪要
  - 待办写入台账（负责人、截止、来源会议）
  - D-1 提醒；逾期升级项目经理
  - 每周五输出周报素材（进展/风险/逾期/下周）

非职责：
  - 不替业务负责人做优先级决策
  - 不擅自对外承诺工期
  - 不修改他人权限与审批流

交付标准：信息准确、责任清晰、按时提醒
边界：不越权审批、不改优先级、敏感会需人工确认后分发

闸门：以上字段任一项写不满 → 禁止实例化员工

flowchart TB Draft["岗位说明书草案\n名称、服务对象、使命、职责、非职责、标准"] --> Check{"字段是否完整且可验证？"} Check -->|否| Refine["补齐缺口\n目标、边界、SLA、拒绝规则或指标"] Refine --> Draft Check -->|是| Map["配置映射\n职责→流程与 SLA\n对象→数据范围\n非职责→拒绝规则\n标准→指标"] Map --> Review{"业务、平台、安全评审\n是否批准？"} Review -->|否| Refine Review -->|是| Instance["实例化岗位员工\n绑定项目、知识、权限、流程"] Instance --> Trial["受控试运行\n采集交付、拒绝与异常记录"] Trial --> Operate["进入运营看板\n按指标复盘"]

这张图把说明书从一份文档变成平台的配置源。职责不会停留在文字里，而会转成流程与 SLA；非职责会转成拒绝规则；交付标准会转成看板指标。只有这些映射成立，创建出的实例才是可管理的岗位，而不是一个名字更具体的聊天窗口。

4. 执行结论：把岗位说明书当作实例化闸门，而不是项目文档

项目协同岗的创建条件应由平台强制执行：说明书字段齐全、职责与流程可映射、非职责与权限矩阵一致、交付标准能被指标观察，并经过业务、平台和安全的共同确认。任何一个条件不满足，平台只允许保存草案或打回补充，不允许进入真实项目运行。

定义：岗位名、服务对象、使命、职责、非职责、标准与边界；映射：将说明书翻译为知识范围、流程、权限、升级与指标；评审：业务确认结果、平台确认可配置、安全确认边界；实例化：仅在审批通过后绑定项目并创建运行态；运营：以交付、拒绝和异常记录持续校验说明书是否仍有效。

岗位说明书自检

岗位名和服务范围是否足够具体，能够决定它服务谁、不能服务谁？
核心职责是否包含可观察动作、时间要求和交付对象，而非抽象的“提升效率”？
非职责是否明确覆盖业务拍板、对外承诺、权限变更等高风险事项，并能变成拒绝规则？
说明书是否能完整映射到流程、知识、权限、升级与指标，并经相关角色审核后再实例化？

思考：说明书不是限制数字员工的想象力，而是让它的责任可以被组织真正托付

一个被委派持续工作的岗位，必须像任何团队成员一样拥有清楚的职责和不能跨越的边界。越是有能力的 Agent，越不能让它用“我以为有帮助”来解释一次越权。

先写说明书，意味着团队在自动化开始前就承担了定义责任的工作。这样，当数字员工运行起来，组织看到的不是不可预测的聪明，而是一份可被评估、调整和撤销的岗位承诺。

硬规则：非职责必须写死。靠「聪明」自行判断，就是下一次翻车预告。

这一幕带走：先说明书，再实例化。写不满字段不开岗；非职责写死，才挡得住越权。

Part 06 · 企业知识：用事实工作，不是用印象工作

06 / 知识

项目组把模板和台账注册进平台知识区，并标注来源、版本、权限。禁止用「印象」补全未决事项。

1. 知识背景：岗位需要的是当下可信的事实，不是一大堆可能相关的文件

项目协同岗每次处理会议、创建任务或汇总周报，都要依赖组织事实：当前生效的会议模板和升级 SLA、属于本项目的任务台账、可使用的周报母版、明确的制度摘录。它不需要“记住所有公司资料”，而需要在正确时间获取正确版本、并且只在被授权的范围内使用。

企业知识服务的职责，是把这些事实注册为可治理对象，为每条知识标明来源、版本、生效时间、权限与适用岗位。这样，数字员工引用“逾期 24 小时升级”时可以指出规则版本；写入任务台账时可以确认它属于当前项目；生成周报时不会把旧模板或未审批内容当作事实。

使用前提：无法说明来源、版本、权限或适用范围的内容，不能成为岗位决策依据。检索到不等于可以使用，模型“记得”更不等于它仍然有效。

类型	项目组注册内容	来源	治理
岗位规则	会议模板、周报规范、升级 SLA（逾期 24h）	项目管理规范库	版本号 + 生效日
Word	纪要模板、制度摘录	文档中心	制度区只读
Excel	项目任务台账（任务/人/截止/状态/风险/下一步）	本项目盘	读写限本项目
PPT	周报母版	运营模板库	生成后待确认

2. 核心问题：为什么凭印象补全事实，比不知道更危险

纪要与项目协同最常见的错误不是完全没有信息，而是把不完整、过期或未经确认的信息写得像事实。会议里有人说“下周看看”，Bot 可能补成具体截止；旧版升级规则仍在模型上下文中，任务就被延迟处理；财务或人事盘的资料被误检索到，系统又可能把不该触达的信息带进周报。

这种错误特别危险，因为输出看起来完整、流畅且很像已经完成。平台必须让不确定性保持可见：字段缺失就是待补全，版本冲突就是待裁定，敏感范围就是拒绝或人工确认，未注册传闻就是不可用。宁可让一个任务等待补充，也不能用似是而非的内容制造错误行动。

事实原则：来源可追溯、版本有时效、权限先隔离、事实与推断分离。知识服务不是给模型喂更多上下文，而是在模型行动前先裁定哪些信息可以成为组织事实。

3. 事实证据：项目协同岗如何登记并使用可治理知识

项目组将岗位规则、Word 纪要模板、Excel 任务台账和 PPT 周报母版逐一注册到平台。每类资源都有不同治理：规则带版本号和生效日，制度文档只读，台账只允许本项目读写，周报生成物需要人工确认。数字员工在运行时读取的不是一份无来源的“知识摘要”，而是带元数据的事实条目。

来源

可追溯

每条引用能点到文件与版本；说不出源 = 不可用。

版本

有时效

过期模板不得参与生成；生效日写进知识元数据。

敏感

隔离

财务/人事盘不进本岗知识区。

事实

与推断分离

未决事项不得写成已决议——Bot 翻车的常见写法。

flowchart TB Need["岗位当前需要依据\n会议纪要、任务创建、逾期升级、周报"] --> Search["检索候选知识\n规则、模板、台账、母版"] Search --> Source{"来源已登记且\n适用于本岗位？"} Source -->|否| Reject["拒绝使用\n显示未注册或越权原因"] Source -->|是| Version{"版本有效且\n无冲突？"} Version -->|否| Resolve["停止自动写入\n升级人工选择版本"] Version -->|是| Access{"当前任务是否\n拥有访问权限？"} Access -->|否| Reject Access -->|是| Fact["生成事实依据包\n来源、版本、权限、引用位置"] Fact --> Work["受控执行\n提炼、写台账、提醒、汇报"] Work --> Audit["保存引用与结果\n可回到原始文件"] Resolve --> Audit

这条路径确保了知识不是静态背景，而是运行时可检查的依据。系统会在引用前拦住未注册、过期、冲突或越权内容；一旦需要人工裁定版本，自动写入立即停止，保留当前半成品和候选来源，等待明确的组织决定。

4. 执行结论：让事实进入工作链，让猜测停在待补全

平台配置时，需要同时注册知识内容和治理元数据；岗位运行时，需要同时引用内容和其来源版本；出现缺失、冲突或敏感条件时，需要停止自动写入并进入明确的人工出口。这样，数字员工的“知识”不再是不可解释的上下文，而是可审计、可撤销、可更新的组织依据。

注册：为规则、模板、台账、母版登记来源、版本、生效日、权限与适用岗位；检索：只返回当前岗位可访问的候选；校验：未注册、过期、冲突、敏感或越权即阻断；使用：引用随任务进入纪要、台账和周报；回流：字段缺失标待补全，冲突版本转人工，引用与结果写入审计。

企业知识自检

岗位使用的每一条规则、模板、台账和母版，是否都具备来源、版本、生效时间和权限元数据？
运行时是否能向用户展示当前结论引用了哪些事实条目，并回到原始文件或版本？
知识过期、版本冲突、敏感会议或访问越权时，是否会阻止自动写入并给出人工裁定出口？
负责人、截止等字段缺失时，是否坚持标记待补全，而不是由模型猜测后写成组织事实？

思考：好的知识系统不替岗位装作无所不知，而是让它知道哪些事实可以据此行动

组织真正需要的不是一个能背出更多文件的 Agent，而是一个能在正确版本、正确权限和正确项目范围内工作，并在事实不足时坦诚停下的岗位。

当“不知道”被转成待补全或人工裁定，知识治理看似降低了自动化的自由度，却避免了把猜测放大成台账、提醒和周报里的错误事实。

这一幕带走：不需要记住一切，但必须在正确时间找到正确文件——这是平台知识服务，不是 Prompt 堆料。

Part 07 · 流程配置：触发、判断、分支、例外

07 / 流程

可执行流程必须回答四问：何时触发、如何判断、调用什么、例外怎么办。例外写进配置，才叫流程；靠临场发挥，叫运气。

1. 流程背景：岗位要稳定运行，不能把关键判断留在每次 Prompt 里

项目协同岗面对的输入并不固定：评审会结束、决策邮件、台账变化都可能触发工作；待办字段可能完整也可能缺失；写入系统可能成功也可能超时；内容可能涉及普通内部协作，也可能涉及重要或对外分发。若这些条件只依赖模型在当下“理解一下”，相同场景就会得到不同处理结果，项目组无法预测也无法审计。

流程配置的作用，是把岗位的重复责任写成平台可执行的规则：什么时候启动，依据什么判断，调用哪些系统动作，出现缺失、冲突、高风险和系统失败时怎样分支。Prompt 可以帮助提炼信息，但只有配置化流程才能保证交接、复盘和迭代不依赖某个模型当时的临场发挥。

上线前提：任何自动步骤都必须有明确触发、可判断条件、受控动作和失败出口。若流程图必须靠解释 Prompt 才能读懂，或一个分支没有人机出口，它就不能承担持续岗位工作。

四问	要写清什么	案例答案（摘要）
何时触发	事件源 + 过滤条件	日历「评审会」结束；主题含 [Decision] 的邮件
如何判断	抽取字段与齐全规则	决策\|待办\|负责人\|截止\|风险；缺人/截止→待补全
调用什么	系统动作清单	写 Word、更新 Excel、建 Task/日历
例外怎么办	分支 + SLA + 人工出口	补全工单 4h；重要/对外升级确认；失败转人工

2. 核心问题：为什么只写“正常路径”会让自动化在例外时失去控制

正常路径看起来很简单：会议结束，提炼待办，写台账，创建提醒。但真实项目里恰恰是例外最消耗人力：负责人缺失、截止日期含糊、会议标记重要、外发口径待确认、任务 API 暂时不可用。如果流程没有为这些状态提前安排停点、SLA 和接手人，系统只会静默跳过、无限重试，或在不该写入时继续写入。

例外不是流程之外的失败，而是企业流程必须交付的一部分。缺负责人应生成补全工单并在四小时内追踪；重要或对外内容必须进入项目经理确认；系统失败应有限次重试，之后保留半成品转人工。把这些分支写进平台，才能使“自动运行”在风险出现时仍然可控。

配置原则：正常分支决定效率，例外分支决定可靠性。每一个判断结果都必须能够导向下一步动作、可观察状态或明确的人类接手者，不能让任务停在模型的一句解释里。

3. 事实证据：会议到周报 v1 如何把触发、判断和例外写进平台

项目组将日历“评审会”结束和主题带 [Decision] 的邮件注册为触发事件。系统提炼决策、待办、负责人、截止和风险：字段齐全时才写入台账并创建日历提醒；缺字段时生成待补全工单；重要或对外内容进入确认队列；每日扫描逾期，周五只汇总有来源的任务状态。系统写入失败时最多重试两次，随后转人工并保留半成品。

【流程 · 会议到周报 · 项目组 v1】
触发：日历「评审会」结束事件 / 主题含 [Decision] 的邮件
判断：抽取 决策 | 待办 | 负责人 | 截止 | 风险
分支：
  - 负责人+截止齐全 → 写入台账 + 建日历提醒
  - 缺负责人或截止 → 状态=待补全，@会议发起人
操作：写 Word 纪要、更新 Excel、创建 Task/日历
回收：每日扫描逾期；周五汇总周报素材

例外分支：
  缺负责人 → 补全工单（SLA 4h）
  标记「重要/对外」→ 升级项目经理确认后再分发
  系统失败 → 重试 2 次，失败转人工并保留半成品

flowchart TB Trigger["触发事件\n评审会结束 / [Decision] 邮件"] --> Extract["提炼字段\n决策、待办、负责人、截止、风险"] Extract --> Fields{"负责人和截止\n是否齐全？"} Fields -->|否| Fill["待补全工单\n@发起人，SLA 4h"] Fill --> Fields Fields -->|是| Sensitive{"是否重要 / 对外？"} Sensitive -->|是| Confirm["项目经理确认\n确认前禁止分发"] Sensitive -->|否| Write["写纪要、台账、Task 与日历提醒"] Confirm -->|批准| Write Confirm -->|拒绝 / 修改| Revise["保留草稿\n回到人工处理"] Write --> Result{"系统操作成功？"} Result -->|是| Follow["每日扫描、D-1 提醒、周五周报素材"] Result -->|否| Retry["限次重试 2 次"] Retry --> Result Retry -->|仍失败| Human["转人工\n保留半成品与错误记录"] Follow --> Escalate{"逾期或阻塞？"} Escalate -->|是| Human Escalate -->|否| Archive["归档与审计"]

流程图不仅描述了自动化会做什么，也定义了它何时必须停下。缺字段、敏感分发、持续失败和逾期阻塞都不再是“模型自行处理”的模糊场景，而是带状态、SLA、审计和接手人的平台分支。

4. 执行结论：让平台执行分支，让人只在应该介入的地方接手

流程配置完成的标准不是画出一条从会议到周报的直线，而是为每个触发、判断、写入和例外定义可执行状态。正常情况下，平台自动推进并记录事实；风险或不确定性出现时，自动化在边界内停止，把完整上下文交给人；人工处理后的结果再回到同一条对象链，不需要重新从头做纪要。

触发：明确事件源与过滤条件；判断：字段齐全、风险标记与业务规则可配置；动作：写纪要、台账、Task、日历均受权限约束；例外：缺字段→补全 SLA，高风险→人工确认，失败→限次重试后转人工；回收：逾期扫描、周报汇总、归档与审计；演进：根据异常记录更新规则而非反复堆 Prompt。

流程配置自检

触发事件、过滤条件和所需输入是否独立于 Prompt，被平台明确记录？
字段校验、高风险判断与系统动作是否都有可读、可测试的规则和状态？
缺字段、敏感分发、系统失败、逾期阻塞等每种例外是否都有 SLA、半成品和人机接手出口？
人工处理结果是否能够回到原任务对象继续推进，而不是另起一段无法追溯的聊天？

思考：流程的成熟，不在于正常路径跑得多快，而在于异常出现时系统仍知道该停在哪里

真正让项目经理放心的，不是数字员工永远不出错，而是它不会在负责人缺失、内容敏感或系统失败时假装一切正常。可见的停点和交接包，正是自动化可以进入企业协作的原因。

当例外被视为流程的一部分，团队就能用异常记录改进规则和指标，而不是每次翻车后只给模型补一段更长的提示词。

这一幕带走：例外写进平台配置，才叫流程。四问答不全，不要上线自动跟进。

Part 08 · 工具权限：会用 ≠ 可以随便改和发

08 / 权限

项目组第一周就卡死「外发」和「改权限」：默认禁止或人工确认。权限矩阵是上岗门槛，不是上线后补丁。

1. 权限背景：工具能调用，不代表岗位可以代表组织执行任何动作

项目协同岗需要访问 Word、Excel、PPT、日历和任务系统，才能把会议事实变成可跟进的对象。但“有工具连接器”只说明技术上能够调用，不说明业务上应当允许。创建本项目任务、修改台账一行、生成周报草稿，与对外发送、承诺工期、调整审批权限，是完全不同等级的组织动作。

权限矩阵的职责，是把岗位说明书中的边界翻译成每个工具、资源范围和动作的准入规则。它决定谁能在什么项目、对哪个对象、以何种方式执行；也决定高风险动作何时必须等待人确认、任何变更发生后留下哪些证据、发生误写时是否可以撤回。

授权前提：没有资源范围、动作级策略、审计点和高风险出口的工具连接，不能赋给持续运行的数字员工。技术可达不等于业务可授权。

工具/动作	可操作范围	策略	审计点
Word	本项目纪要、方案草稿	创建/修改；制度区只读	谁·何时·文件 ID·版本
Excel	本项目台账	读写授权；禁止删列结构	行级变更前后快照
PPT	周报母版生成	生成后人工确认再分享	确认人·确认时间
日历/任务	本项目成员	可创建执行	Task ID · 指派人
高风险	外部发送、审批承诺、权限变更	禁止或人工确认	强制记录理由与审批人

2. 核心问题：为什么默认开放写入和外发会把一次幻觉放大成组织事故

如果纪要 Bot 能够随意修改所有台账、发送所有邮件或变更他人权限，那么一次错误抽取就不再只是一段不准确的文字，而会变成错误任务、误导承诺甚至数据泄露。若没有行级快照、审批记录和撤回路径，团队在发现问题后也无法迅速说明发生了什么或恢复现场。

权限治理不能依赖“模型会更谨慎”。平台必须默认最小权限，并把外发、审批承诺和权限变更视为独立的高风险动作：禁止、人工确认或另行配置，而不是和普通文档创建共享同一条自动执行路径。

最小权限原则：只授予岗位完成当前关键路径所需的最小盘、最小动作和最小范围；每次写入均可审计、可回看、可在允许范围内撤回；高风险动作必须显式等待人类决定。

最小权限只开本岗需要的盘与动作

人工确认外发/改权限默认闸

操作审计谁·何时·改了什么

可撤回误写可回滚半成品

翻车预告：没矩阵就上线，等于给幻觉开生产写权限。项目组明确：矩阵未评审通过，禁止实例化。

3. 事实证据：项目协同岗如何用权限矩阵区分“可执行”与“必须停下”

项目组为岗位定义了明确边界：可以在本项目创建或修改纪要草稿、台账行、任务与日历提醒；PPT 周报只能生成草稿，分享前需要人工确认；外部发送、审批承诺和权限变更则默认禁止或要求单独审批。每一次操作都要带上任务 ID、资源标识、前后快照或确认记录，使结果可以回到具体岗位和运行上下文。

flowchart TB Intent["岗位提出动作\n资源、范围、操作、Task ID"] --> Match{"权限矩阵匹配\n岗位 + 项目 + 工具 + 动作？"} Match -->|不匹配| Deny["拒绝执行\n记录原因与策略版本"] Match -->|匹配| Risk{"是否高风险？\n外发、承诺、权限变更"} Risk -->|是| Approval["人工确认闸\n说明理由、影响与证据"] Approval -->|拒绝| Deny Approval -->|批准| Execute["受控执行"] Risk -->|否| Execute Execute --> Audit["记录审计\n谁、何时、资源、前后快照、Task ID"] Audit --> Verify{"结果与范围\n是否符合预期？"} Verify -->|是| Complete["写入流程对象\n继续跟进"] Verify -->|否| Rollback["撤回 / 保留半成品\n转人工处置"] Rollback --> Audit

矩阵的关键不在于列出很多“允许”，而在于每个动作都经过同样的判定链：匹配不到就拒绝，高风险就等待确认，执行后留下审计，结果异常就进入撤回或人工处置。这样，岗位既能高效处理常规任务，也不会把组织权限悄悄扩张到不可控范围。

4. 执行结论：用动作级闸门把岗位能力放在可控边界内

权限配置的验收不在于页面上有一张表，而在于每次真实调用都能被这张表裁定。项目组应按岗位关键路径配置最小权限，明确哪些动作自动允许、哪些动作需确认、哪些动作禁止；对所有写入保存审计和可撤回状态；对拒绝和失败提供原因与人工出口。只有这套规则经过业务、安全和平台评审，岗位才可以进入试运行。

申请：动作必须携带岗位、项目、资源范围与 Task ID；判定：矩阵不匹配即拒绝，高风险进入人工确认；执行：普通动作在最小权限内运行；审计：记录资源、操作、前后快照、确认人与策略版本；核验：异常则撤回或转人工；治理：权限变更需要重新评审，不能由岗位自行扩大。

工具权限自检

每个工具是否限定到本岗位、本项目、最小资源范围与具体动作，而非笼统的“可访问”？
外发、对外承诺、审批和权限变更是否默认禁止或必须经过人工确认？
每次写入是否可关联 Task ID、资源版本与前后快照，并能在异常时撤回或保留半成品？
拒绝、确认、执行和撤回是否都有可查看的审计记录与明确的责任人？

思考：权限的价值，不是证明系统有多强，而是让组织明确哪些后果愿意由它承担

数字员工越能调用系统，越需要把“能做”与“允许做”严格分开。真正成熟的授权，不会因为自动化看起来方便就跳过确认，而是让每一项组织后果都有合适的责任边界。

当平台能够拒绝不该做的动作、审计已经做过的动作并撤回可恢复的错误时，团队才有资格把持续写入能力交给岗位运行。

这一幕带走：会用 ≠ 可以随便改和发。权限矩阵是上岗门槛；审计点写不清，等于没闸。

Part 09 · 人机协作：重新分配，而不是全盘交接

09 / 协作

项目组明确三张责任表，升级必须带完整交接包。升级不是失败，是企业级流程的一部分。

1. 协作背景：岗位自动化改变的是执行分工，不是把组织责任一并交出去

项目协同岗可以持续整理纪要、写入台账、发送提醒、汇总风险和生成周报草稿，这些动作标准化程度高、结果可审计，适合由数字员工承担。但项目优先级、资源取舍、对外承诺和权限变更仍然需要了解业务后果的人拍板。自动化的价值是把人从重复追踪中释放出来，而不是让人退出责任链。

人机协作因此需要像岗位交接一样明确：哪些任务默认由数字员工完成，哪些情况需要人和系统共同裁定，哪些决定只能由人工负责。平台还要保证，当系统请求帮助时，接手人不是收到一句“你看下”，而是获得足以判断和处置的完整上下文。

协作前提：数字员工可以执行已定义的规则，不能替代业务授权和最终责任。没有责任边界和交接包的“自动升级”，只是在把问题从一个黑箱抛给另一个人。

数字员工整理纪要 · 写入台账 · 提醒 · 汇总风险 · 出周报草稿

共同决策缺人待办怎么补 · 风险是否升级 · 周报对外口径

人工负责优先级拍板 · 对外承诺 · 权限变更 · 最终责任

2. 核心问题：为什么“全交给 AI”与“只甩给人”都会让协作断掉

把所有决定交给数字员工，会让缺负责人、外发口径和优先级冲突在没有业务授权的情况下被擅自处理；而把每一个不确定性都丢给人，又会让项目经理重新陷入翻聊天、找来源、猜上下文的低效工作。两种极端都没有真正减少协作成本，只是把风险或劳动转移给另一方。

高质量的协作要把问题分层：可标准化、可审计的动作自动执行；需要业务判断的事项由人裁定；介于两者之间的例外由系统带着证据和选项升级。交接包不完整时，平台应拒收升级，迫使系统补齐 Task ID、来源、已尝试动作和截止风险，而不是让人工从零重建事实。

责任原则：数字员工负责把事实、状态和备选方案整理到位；人负责承担判断与授权后果；平台负责确保每次交接都有对象、有证据、有时限，并能回到原流程继续执行。

3. 事实证据：Task-128 如何通过交接包让人工决策回到流程中

在 Q3 评审后，Task-128 因负责人缺失被标为待补全。数字员工两次提醒会议发起人均未得到回复，且原定周五已逾期一天。它没有擅自指派张三，也没有只在群里说“麻烦看下”，而是生成升级包：关联来源会议、当前状态、两次尝试记录、证据链接、选项 A“指派张三”或 B“延后”，以及截止风险。项目经理选择后，结果写回同一 Task ID，后续提醒和周报继续沿用该对象。

升级包（最低字段）：
Task ID · 来源会议 · 当前状态 · 已尝试动作 · 证据链接 · 建议选项 · 截止风险

禁止：只甩一句「这个你看下」
合格示例：Task-128 缺负责人；来源「Q3 评审 08-05」；
  已 @发起人 2 次无回复；建议选项 A 指派张三 / B 延后；
  截止风险：原定周五，现已逾期 1 天。

flowchart TB Task["Task-128\n缺负责人 / 已逾期"] --> Classify{"属于哪类动作？"} Classify -->|标准化| Auto["数字员工执行\n提醒、台账更新、风险汇总"] Classify -->|业务判断| Package["生成升级交接包\nTask ID、来源、状态、证据、选项、风险"] Package --> Validate{"字段是否齐全？"} Validate -->|否| Reject["平台拒收\n补齐上下文"] Reject --> Package Validate -->|是| Owner["路由项目经理\n在 SLA 内决策"] Owner --> Decision{"人工选择\n指派 / 延后 / 其他处置"} Decision --> Writeback["写回同一 Task ID\n记录决策人与理由"] Writeback --> Auto Auto --> Evidence["更新状态、提醒、周报素材\n保留审计"]

这个过程让升级成为流程的一部分，而不是自动化失败的终点。人工没有接管整条链，只在需要授权与判断的节点做决定；数字员工拿到结果后继续完成可标准化的跟进，并把新的状态和证据回流到任务与周报中。

4. 执行结论：让人工只在关键判断点介入，并让决策可回写、可追溯

协作机制的验收不在于有多少次升级，而在于升级是否更快地促成正确决策。平台应将常规动作保持在数字员工侧，将优先级、承诺和权限等高后果判断路由给人；升级必须通过字段校验，人工决策必须写回原对象，后续自动化继续沿着同一条流程运行。这样，协作既不会退化成“全自动黑箱”，也不会退化成“所有事情重新人工做一遍”。

分工：标准化、可审计动作由数字员工执行；判断、承诺、权限由人工负责；交接：系统携带 Task ID、来源、状态、证据、选项与风险；校验：缺字段升级工单拒收；决策：人工在 SLA 内裁定并写回原对象；回流：数字员工继续提醒、记录、汇总与审计。

人机协作自检

标准化动作、共同决策和人工最终责任是否被明确区分，并能在平台中配置？
业务判断、对外承诺和权限变更是否始终保留给明确的人类责任人？
升级包是否包含 Task ID、来源、状态、尝试记录、证据、选项和截止风险，缺一即拒收？
人工决定是否回写原任务对象，使后续自动化、提醒和周报仍然可追溯？

思考：人机协作最好的状态，不是人完全退出，而是每个人只在自己最该负责的节点出现

数字员工擅长持续记录、检查和追踪，人擅长承担判断、取舍和授权。把两者混在一起，既会浪费人的注意力，也会让系统越过不应承担的责任。

当升级包足够完整、决策能够回写、自动化能够继续推进，协作就不再是中断，而是让组织在关键时刻把正确的人带入正确的上下文。

这一幕带走：重新分配，不是全盘交接。升级不是失败；交接不完整，协作必断。

Part 10 · 运营治理：上线只是协作的开始

10 / 运营

项目组试运行两周：看看板、审权限、改模板，而不是「上线即完工」。成熟标志是可运营、可审计、可改进。

1. 运营背景：岗位上线不是终点，而是第一次在真实协作中接受检验

在试点前，岗位说明书、知识、流程、权限和协作边界都只是经过设计的假设。真正进入项目组后，会议量会变化、模板会过期、SLA 可能不合适、提醒可能失败、权限也会随着成员变化而漂移。若团队把“成功创建岗位实例”当作完成，数字员工会在不被注意的情况下从助推器退化成另一个没人维护的 Bot。

运营治理的职责，是把运行事实变成持续的改进输入。平台需要观察任务闭环、提醒及时、升级质量、权限使用和知识版本；需要以日、周、双周的节奏处理异常、审阅风险和更新规则；每个改动都应留下变更单、重新验证并能在必要时撤回。岗位的成熟度不取决于第一次演示，而取决于它是否能在变化中保持边界和交付。

运营前提：没有看板、复审节奏、变更记录和回滚策略的“上线”，只是把维护责任推迟到问题暴露之后。平台必须把运行与治理当成岗位生命周期的一部分。

需求：痛点=会议不闭环
设计：岗位说明书 + 会议到周报流程
配置：知识区 + 权限矩阵 + 例外分支
验收：试运行 + 项目经理周评审
运营：监控指标，迭代模板与 SLA

2. 核心问题：为什么岗位会在第三周静默退化

最常见的退化不是一次明显故障，而是一连串无人处理的小偏差：周报模板更新后仍引用旧字段，逾期提醒因日历变更而失效，外发确认规则被临时放宽，项目成员变化后权限未回收。每一项单独看都像小问题，累积起来却会让闭环率下降、错误事实进入周报、权限边界慢慢消失。

如果没有固定的运营节奏，团队通常只能在项目经理抱怨“最近又不好用了”时才开始排查，那时已经很难区分是知识、流程、权限、能力还是协作规则失效。看板的作用不是堆更多数据，而是让异常能够被及时归因，进入有责任人、有优先级和可复核结果的变更流程。

治理原则：运行数据既是服务质量信号，也是边界风险信号。指标异常必须能追到对应的知识、流程、权限或协作配置，并以受控变更修复，不能靠在生产环境直接改 Prompt。

3. 事实证据：项目协同岗两周试运行如何形成运营节奏

项目组在试运行中没有只看“生成了多少纪要”，而是按节奏检查岗位事实：每天查看逾期扫描与提醒失败，形成当日修补清单；每周由项目经理评审闭环率、准确率和升级记录，生成模板或 SLA 变更单；每两周复审外发审计和过期授权，输出权限矩阵差异。通过这些记录，团队将逾期 SLA 从 48 小时收紧到 24 小时、更新周报模板，并持续禁止自动外发。

节奏	做什么	产出
每日	看逾期扫描与提醒失败	当日修补清单
每周	项目经理评审看板 + 抽检准确率	模板/SLA 变更单
双周	权限复审（外发审计、过期授权）	矩阵 diff

运营看板	治理重点	优化动作（案例真实做过）
会议量 · 任务闭环率 · 提醒及时率	资料权限 · 外发审计 · 版本 · 撤回	周报模板改版；逾期 SLA 从 48h 收到 24h；禁止自动外发

flowchart TB Run["岗位真实运行\n会议、任务、提醒、升级、周报"] --> Observe["运营看板\n闭环、准确、及时、升级、采纳\n权限与知识版本"] Observe --> Detect{"是否出现质量或风险异常？"} Detect -->|否| Continue["保持运行\n进入下一周期复审"] Detect -->|是| Triage["异常分诊\n知识 / 流程 / 权限 / 协作 / 能力"] Triage --> Change["创建变更单\n问题、影响范围、负责人、回滚条件"] Change --> Review{"业务、平台、安全\n是否批准？"} Review -->|否| Human["人工处理\n保留原配置与证据"] Review -->|是| Apply["受控更新\n模板、SLA、矩阵或规则"] Apply --> Verify["小范围再验证\n指标与审计复查"] Verify -->|通过| Continue Verify -->|不通过| Rollback["回滚配置\n重新分诊"] Rollback --> Triage Continue --> Observe

运营闭环的关键是“变更先于直接修补”。指标提示问题后，团队先定位受影响的配置和风险，再以有责任人、影响范围与回滚条件的变更单调整；变更通过小范围验证后才进入下一轮运行。这样，改善效率不会牺牲权限和审计边界。

上线 ≠ 完工：没有看板与复审节奏，岗位会在第三周静默退化——模板过期、权限漂移、没人看指标。

4. 执行结论：把运营做成可审计的复盘和变更循环

项目协同岗进入正式运营后，应保留日常异常处理、周度质量评审和双周权限复审三种节奏，并把每个问题落入可追踪的变更单。变更不能只说明“优化一下模板”，而要明确问题证据、岗位影响、配置调整、负责人、再验证标准与回滚条件。只有指标与审计共同支持，调整才可以扩大到全部项目。

运行：收集任务、提醒、升级、权限和知识版本事实；观察：每日看失败与逾期，每周评质量，每双周审权限；分诊：定位知识、流程、权限、协作或能力缺口；变更：创建带影响、负责人、验证与回滚条件的变更单；验证：小范围复测指标和审计；发布：通过后扩大，失败则回滚并继续分诊。

运营治理自检

是否有日、周、双周的固定复审节奏，分别覆盖运行异常、工作质量和权限风险？
看板异常是否能归因到具体知识、流程、权限、协作或能力配置，而非停留在模糊抱怨？
每次变更是否包含影响范围、责任人、验证信号与回滚条件，并经过适当评审？
模板、SLA、权限和规则更新后，是否经过小范围再验证与审计复查再扩大使用？

思考：真正成熟的数字员工，不是永远不变，而是在变化发生时仍然可观察、可解释、可修正

组织流程本来就在变化。企图用一次配置解决所有未来问题，只会让维护被拖延到失控之后。运营治理让团队能够用真实运行证据调整岗位，同时保留为什么改、谁批准、改后是否更好的完整记录。

当上线后的每一次异常都能被接住、每一次调整都能被验证，数字员工才从一次性项目交付，成长为组织可以长期使用和持续改进的岗位能力。

这一幕带走：成熟标志是可运营、可审计、可改进——这是平台能力，不是单次生成质量。

Part 11 · 验收：用工作结果证明，不看纪要像不像人

11 / 验收

项目组第二周用五指标说话；「写得像」不再进验收表。放行/打回必须可外部观察。

1. 验收背景：岗位是否合格，要看它是否改善了真实工作结果

纪要写得自然、排版整齐，最多证明模型的表达能力不错，却无法证明项目协同工作被推进。岗位真正承诺的是：会后待办能进入台账并走向完成，负责人和截止日期足够准确，提醒和升级遵守 SLA，例外被交给正确的人，团队愿意在真实工作中持续使用这些交付物。

因此，岗位验收必须从运行数据而非主观印象出发。五指标分别观察闭环、信息质量、时效、协作路由和实际采纳；它们共同回答一个业务问题：会议是否更容易变成行动，团队是否更少等待、遗漏和重复追问。

验收前提：指标必须来自真实任务、台账状态、提醒记录、升级工单和使用行为，并能回到具体来源。没有真实事件支撑的满意度或演示截图，不能作为岗位放行证据。

闭环率会后待办进入台账并完成的比例

准确率负责人/截止抽检正确率

及时率提醒与升级是否按 SLA

升级率例外是否交给正确的人

采纳度团队是否持续使用（非强制）

2. 核心问题：为什么单项绿灯或好看的纪要都会掩盖岗位缺口

单看闭环率，可能掩盖负责人和截止日期被错误抽取；单看准确率，可能掩盖提醒没有按时发出；单看采纳度，可能只是因为团队被要求强制使用。更危险的是，如果外发没有审计闸、升级包缺关键字段，即使数字指标看上去不错，岗位仍然可能在风险边界上失控。

平台需要同时检查四层事实：岗位目标是否兑现，流程对象是否真正被执行，信息是否准确可信，团队协作是否在正确的人和时间发生。四层共同通过，才说明数字员工是在持续降低协作摩擦，而不是把问题转移给项目经理。

验收原则：结果、边界与协作缺一不可。任何指标异常都要回到对应的岗位说明书、流程、知识、权限或协作配置修复，而不是靠“再优化一下文风”获得放行。

四层：岗位目标 · 流程执行 · 信息质量 · 团队协作。

最终问题：会议是否更容易变成行动？团队是否更少等待、更少遗漏、更少重复追问？

验收对象不是一句纪要，而是一套可追踪、可衡量的办公交付。

3. 事实证据：项目组如何用五指标与四层检查做出放行决定

第二周试运行结束后，项目组汇总真实会议、Task ID、台账变更、提醒日志、升级包与使用记录。评审不观看一次完整演示，而是逐项检查：待办是否进入台账并完成、负责人和截止抽检是否正确、提醒与升级是否按 SLA、例外是否交给正确的人、团队是否主动采用交付物；同时确认无未审外发、升级包字段完整、每项结论都可回到来源对象。

结论	条件（案例阈值）	动作
放行	闭环≥80%；准确抽检≥90%；无未审外发；升级包字段齐全	进入正式运营节奏
有条件放行	指标接近但模板/SLA 需改	开变更单，双周复评
打回	「写得像」当主指标；或高危无闸；或闭环<60%	停自动跟进，回到说明书/流程

别混用：单 Agent 产品有产品验收四柱（03）；岗位交付看这五指标。文风分进验收表 = 打回。

flowchart TB Data["真实运行证据\n会议、Task、台账、提醒、升级、使用记录"] --> Metrics["计算五指标\n闭环、准确、及时、升级、采纳"] Metrics --> Goal{"岗位目标\n会议是否变成行动？"} Goal -->|否| BackRole["打回岗位说明书\n补职责、范围或指标"] Goal -->|是| Process{"流程执行\n任务、提醒、升级完整？"} Process -->|否| BackFlow["打回流程配置\n补规则、SLA 或例外"] Process -->|是| Quality{"信息质量\n负责人、截止、来源可信？"} Quality -->|否| BackKnowledge["打回知识/校验\n补来源、版本或字段规则"] Quality -->|是| Collaboration{"团队协作\n升级正确、权限受控、持续采用？"} Collaboration -->|否| BackGovern["打回权限/协作\n补闸门、交接或运营"] Collaboration -->|是| Threshold{"达到放行阈值\n且无高危未审动作？"} Threshold -->|是| Release["正式运营\n进入持续看板复审"] Threshold -->|否| Conditional["有条件放行\n变更单 + 双周复评"] BackRole --> Fix["修复并重新采集证据"] BackFlow --> Fix BackKnowledge --> Fix BackGovern --> Fix Fix --> Data Conditional --> Data

这张图让“打回”有了明确去处：岗位目标问题回到说明书，流程断点回到流程配置，信息错误回到知识与字段校验，协作或边界问题回到权限与人机规则。放行不是一份口头认可，而是对四层证据与风险闸共同作出的结论。

4. 执行结论：让指标决定放行，让缺口决定回流

项目组将放行标准写成外部可观察的门槛：闭环率不低于 80%，负责人和截止的抽检准确率不低于 90%，没有未审外发，升级包字段完整。指标接近但模板或 SLA 需要调整时，可以有条件放行并在双周复评；若闭环低于 60%、高危无闸或仍以文风为主指标，则必须停止自动跟进并回到岗位说明书或流程修复。

取证：真实会议、Task、台账、提醒、升级与使用记录；计算：五指标按统一口径汇总；审查：岗位目标、流程执行、信息质量、团队协作四层逐项举证；决策：阈值达成且无高危未审动作→放行，接近但可修→有条件放行，关键缺口或风险→打回；回流：按缺口回到说明书、流程、知识、权限或协作配置并重新采证。

岗位验收自检

五项指标是否来自真实运行事件，并能向下追溯到会议、任务、提醒或升级记录？
岗位目标、流程执行、信息质量和团队协作四层是否均有独立证据，而非只看单项绿灯？
是否明确了放行、有条件放行和打回的阈值、风险门槛与后续动作？
每一个未通过项是否能准确回流到岗位、流程、知识、权限或协作配置，而不是只要求模型“更准确”？

思考：最有说服力的验收，不是证明 Agent 很像人，而是证明团队的工作因此更少失控

数字员工应该被组织结果衡量：待办是否真的闭环、信息是否可靠、风险是否被及时送到正确的人、团队是否愿意持续依赖这套交付。这样的标准也允许团队诚实地发现不足，而不是用一篇漂亮纪要遮住流程里的断点。

当放行与打回都由证据决定，岗位才拥有持续改进的方向，而不会陷入“大家觉得还行”的模糊状态。

这一幕带走：用工作结果证明，不看纪要像不像人。五指标说话；「写得像」踢出验收表。

Part 12 · 实战收束：六维设计 + 平台产物包

12 / 产物

项目组交给平台配置同学的，不是一段聊天记录，而是可落地的设计包。六维填实 + 五份产物齐，才能建岗上线。

1. 收束背景：平台配置需要一份可执行的设计包，而不是一段高质量聊天记录

到本章为止，项目组已经分别定义了岗位、能力、知识、流程、权限、协作、运营与验收。若这些结论仍散落在会议讨论、Prompt 或个人笔记中，平台配置同学就不得不重新问一遍“服务谁”“能访问哪里”“异常怎么办”“如何验收”，甚至会在理解不一致时用自己的假设补全空白。

实战收束的目标，是把前面的决定编译成一份可交接、可版本化、可审查的设计包。它既让配置同学不依赖聊天记录也能创建岗位实例，也让业务、安全和运营能够在上线前确认每一项承诺都有对应配置与验收方式。设计包不是汇报材料，而是实例化和后续治理的共同事实源。

交接前提：能够讲清案例不等于能够配置平台。只要岗位、流程、权限、指标中有一项不能落到明确的配置对象、版本与责任人，交付就还停留在概念稿。

岗位项目协同办公数字员工

职责纪要/任务/跟进/周报；不拍板

知识模板、SLA、台账、母版

流程会议→周报 + 例外分支

权限矩阵 + 高危人工闸

指标闭环/准确/及时/升级/采纳

2. 核心问题：为什么“让配置同学照着聊一聊”会把岗位设计重新变回 Demo

聊天记录往往包含大量讨论过程、临时假设和已被否决的方案，但缺少最终版本、变更责任人与机器可执行边界。配置同学即使理解了大意，也难以判断该使用哪个模板版本、外发是否允许、缺负责人要走哪条 SLA、哪些指标才代表岗位合格。每一次手工转述都会重新引入范围漂移和权限遗漏。

更严重的是，无法交接的设计也无法复盘。上线后如果闭环率下降或权限规则失效，团队不知道应回到哪一份岗位说明书、流程配置或指标口径修复。一个真正可运营的数字员工，必须在创建之前就拥有与代码发布相似的交付物：版本清楚、责任明确、依赖可追踪、缺项能够阻塞实例化。

交付原则：把“平台应该怎么配”写成可以独立评审的对象，而不是让平台配置同学猜测产品意图。六维设计回答需要配置什么，五份产物回答配置依据在哪里，两者缺一不可。

3. 事实证据：项目协同岗如何把六维设计交付成五份平台产物

项目组最终交出的不是“请做一个会议 Bot”，而是一组互相校验的设计对象：岗位说明书定义服务范围与非职责，流程图定义触发、判断和例外，权限矩阵定义可执行与必须停下的动作，指标看板定义放行与运营信号，平台能力蓝图定义岗位从注册、编排、运行到考核和治理的生命周期。每份产物都有版本号与负责人，任一缺失都阻止创建实例。

【平台设计产物包 · 可交接】
1. 岗位说明书（含非职责）
2. 会议→周报流程图（含例外）
3. 系统权限矩阵（含审计点）
4. 工作验收指标与看板口径
5. 平台能力蓝图：注册 → 编排 → 运行 → 考核 → 治理

可落地标准：
  - 配置同学不看聊天记录也能配
  - 每份产物有版本号与负责人
  - 缺任一产物 → 禁止实例化上线

目标：从「整理一场会议」走向「持续推动一项工作完成」

flowchart TB Six["六维设计卡\n岗位、职责、知识、流程、权限、指标"] --> Map["映射为平台配置\n身份、数据范围、规则、连接器、闸门、看板"] Map --> Pack["五份产物包\n说明书、流程图、权限矩阵、指标口径、能力蓝图"] Pack --> Version["版本与负责人\n依赖关系可追踪"] Version --> Review{"业务、平台、安全、运营\n是否可独立配置与审查？"} Review -->|否| Gap["定位缺项或矛盾\n回到对应设计维度"] Gap --> Six Review -->|是| Gate{"实例化闸门\n产物齐全、权限/例外可点选、指标接真实事件？"} Gate -->|否| Gap Gate -->|是| Instance["创建岗位实例\n绑定项目、知识、流程、权限和看板"] Instance --> Operate["运行、验收与运营治理\n变更回写设计包"] Operate --> Six

设计包的价值在于让每一个答案都有可追溯去处：岗位目标落在说明书，会议到执行落在流程，外发边界落在权限矩阵，是否合格落在指标看板，所有配置又由能力蓝图串成可运营生命周期。配置同学无需重读讨论过程，也能知道该创建什么、拒绝什么、如何验证。

4. 执行结论：用设计包作为实例化闸门，让平台配置可审查、可复用

项目协同岗只有在六维设计都能映射到配置项、五份产物都完成版本管理、权限与例外能够在平台点选、指标看板已经接入真实事件时，才可以从 Demo 进入上岗。此后任何知识、流程、权限或指标的变更，也应先更新设计包、完成评审和再验证，再作用于岗位实例，避免生产配置和设计意图逐渐脱节。

设计：六维写清岗位、职责、知识、流程、权限与指标；编译：映射为说明书、流程图、矩阵、看板和能力蓝图；交接：每份产物带版本、负责人和依赖；评审：业务、平台、安全、运营独立挑刺；闸门：缺产物、权限/例外不可点选或指标无真实事件即禁止实例化；演进：运行变更回写设计包，重新评审后发布。

平台产物包自检

六维设计是否都能指出对应的平台配置项，而非停留在抽象概念？
岗位说明书、流程图、权限矩阵、指标口径和能力蓝图是否齐全、版本化并有明确责任人？
配置同学是否无需阅读聊天记录，就能据此创建岗位、配置例外与权限、接入看板并理解验收条件？
产物缺失、配置与设计矛盾、权限不可审查或指标未接真实事件时，实例化是否被平台闸门阻止？

思考：设计包不是项目结束时的附件，而是让岗位在组织中持续保持同一种含义的锚点

人员会更替，模板会更新，流程与权限也会调整。只有把关键决定沉淀成版本化产物，团队才能在变化发生时知道哪些承诺仍然有效、哪些需要重新讨论，而不是靠记忆和转述维持一个岗位。

当设计、配置、运行和治理都回到同一份产物包，数字员工才真正从一次案例，变成可被组织复制、审查和运营的平台能力。

这一幕带走：六维填实 + 五份产物齐，才能建岗上线；缺一就还在 Demo。交给配置同学的是设计包，不是聊天记录。

结语 · 从纪要 Bot 到可运营岗位

收束

项目组得到的不是更会写的模型，而是挂在平台上的可运营数字员工：有岗位、有流程、有权限、有指标。

1. 收束背景：从一个能写纪要的 Bot，到一个能承担项目协同责任的岗位

项目组最初的问题看似只是“会议纪要整理得不够好”，但两周后的翻车证明，真正缺失的是一条从信息到行动的责任链。待办没有负责人和截止日期，任务没有进入台账，逾期没有升级，周报无法回到来源。无论纪要写得多流畅，它都没有替项目组推进工作。

重做之后，团队不再把模型能力当作最终交付，而是把它装进一个可运营岗位：岗位说明书定义责任，企业知识提供可用事实，流程配置承接正常与例外，权限矩阵限制组织动作，人机协作保留业务判断，运营看板与五指标持续验证结果。平台让这些要素以可配置、可审计、可演进的方式共同运行。

最终前提：数字员工的价值不在于替人完成一次内容生成，而在于长期、稳定地帮助组织完成一类工作，同时让边界、失败和责任始终可见。

2. 核心问题：为什么“部署更多 Bot”不会自动形成数字员工体系

如果每个团队各自创建一个会写文档、会调工具的 Bot，组织只会得到一组难以治理的局部自动化：它们的职责相互重叠，知识来源不同，权限边界不一致，异常时找不到接手人，质量指标也无法比较。数量增加并不会带来平台能力，反而会放大配置漂移、审计断裂和责任不清。

真正的平台化不是把多个 Agent 放在同一个入口，而是让每个岗位都遵守同一种注册、配置、运行、考核和治理机制。这样，团队既能为项目协同岗选择合适的知识、流程和权限，也能在新增客服、运营或研发岗位时复用同一套边界、交接、审计和放行方法，而不是从头再造一份 Prompt。

平台原则：能力可以复用，岗位必须有差异；治理规则可以统一，责任与权限必须具体。只有把两者同时保留，组织才能扩大自动化而不扩大失控。

3. 事实证据：项目协同岗如何从一次翻车，变成可复制的平台岗位

纪要 Bot 翻车后，项目组没有继续追求“更像人”的输出，而是完成了一组可交接产物：岗位说明书钉死服务范围与非职责，会议到周报流程包含缺字段、敏感分发和系统失败等例外，权限矩阵卡住外发和改权限，升级包让人工判断回到原任务，五指标将闭环、准确、及时、升级和采纳变成可观察结果。最终，Agent 能力被封装进岗位，平台则负责注册、编排、考核与治理。

带走：岗位说明书 · 流程（含例外）· 权限矩阵 · 五指标 · 平台能力蓝图（注册→编排→运行→考核→治理）。

flowchart TB Bot["纪要 Bot\n输出一篇文本"] --> Failure["两周翻车\n待办丢失、逾期无人、周报不可追溯"] Failure --> Role["定义岗位\n服务对象、使命、职责、非职责、标准"] Role --> Configure["平台注册配置\n知识、流程、权限、协作、指标"] Configure --> Run["受控运行\n会议 → 任务 → 提醒 → 升级 → 周报"] Run --> Verify["工作结果验收\n闭环、准确、及时、升级、采纳"] Verify -->|未达标或风险| Improve["运营治理\n分诊、变更、再验证或回滚"] Improve --> Configure Verify -->|达标| Operate["可运营岗位\n持续看板、审计、复审"] Operate --> Expand["复制到新岗位\n复用平台规则，重新定义责任边界"] Expand --> Role

这条闭环的重点不是让项目协同岗永远固定，而是让它在真实运行中可被检查和修正：指标与审计发现问题，变更回写配置，新的岗位又从清晰责任开始定义。平台的可复制性来自这套循环，而不是来自把原来的 Bot 批量复制出去。

4. 执行结论：把岗位设计、运行和治理当作同一项长期工程

面对下一类数字员工岗位，团队可以沿用本篇的路径：先把业务痛点写成岗位结果，再定义服务对象、职责和非职责；选择支撑关键流程的最小能力组合；注册可信知识、可执行流程和动作级权限；规定人机协作与升级；用真实事件与五指标决定放行；上线后通过看板、审计和变更单持续治理。这样，新增岗位不会成为新的黑箱，而是平台能力的一次受控扩展。

定义：从业务问题写出岗位目标、边界与非职责；装配：选择能力、知识、流程、权限、协作与指标；交付：形成版本化设计包并通过实例化闸门；运行：处理会议、任务、提醒、升级与周报；验收：五指标和四层事实决定放行；治理：看板发现异常，受控变更后再验证；复制：复用机制，不复用未经重新定义的责任。

从 Bot 到岗位的最终复查

这项自动化是否有明确岗位目标、服务对象、职责、非职责和可观察的工作结果？
知识、流程、权限、人机协作和指标是否都已成为可配置、可审计、可版本化的平台对象？
异常、权限风险与人工判断是否有完整交接、回写和后续执行路径？
新增岗位时，团队是否重新定义其责任边界与验收，而非仅复制一个已有 Bot？

思考：平台真正建成的标志，不是挂上更多员工头像，而是组织开始有能力持续地定义、约束和改进自动化责任

纪要 Bot 的失败提醒我们，自动化并不会天然带来秩序。只有当岗位、流程、权限、协作和指标被共同设计并持续治理，Agent 才能从一次看似聪明的输出，变成组织愿意长期依赖的工作伙伴。

下一步不再只是配置更多岗位，而是让人在真实办公界面中看见这些岗位正在做什么、为什么这样做、何时需要介入，并与它们一起把资料变成结果。

系列路径： 01 用好 → 02 吃透 → 03 做成 → 04 建成（本篇） → 05 跑通

下一步：人在真实办公界面里如何与这些员工共作？→ 05 · 跑通 AI 办公工作台：从资料到出结果
上一层：03 · 做成 Agent 产品：从目标到可验收

Last updated: 2026-08-07 · 全文加厚修订

← 做成 Agent 产品跑通 AI 办公工作台 →