开篇 · 数字员工上线了，人还在五个窗口里打工
00 / 真实案例能力在后台，入口还在散落窗口。工作台要解决的是：在一个现场里，把资料变成可消费的结果。
1. 工作背景：数字员工已经在跑，人的工作现场却仍然四分五裂
04 里，ToB 产品组已经把“项目协同”数字员工装上平台：岗位说明书、会议到周报流程、权限矩阵、五指标都齐了。它能生成纪要草稿、识别待办、标记逾期并提供周报素材。但这些能力大多停在后台或对话入口，项目经理仍然需要在会议记录、聊天、Word、Excel、日历和 PPT 之间来回搬运信息。
对小陈而言，真实工作不是“问一个问题，得到一个答案”，而是围绕一场评审会持续完成一项任务：读懂资料，确认待办，写入台账，安排提醒，汇总风险，交付周报。只要这些产物分散在不同窗口，数字员工越勤快，人就越像最后一公里的胶水，负责复制、核对、切换和承担遗漏风险。
2. 核心问题：为什么多个“好用的窗口”叠在一起，仍然会让工作变慢
每个窗口单独看都合理：聊天窗口适合追问，Word 适合编辑，Excel 适合台账，日历适合安排提醒，PPT 适合汇报。但它们之间没有共享同一个任务状态与证据链。小陈把纪要复制到 Word 后，负责人和截止是否已经确认？从 Excel 创建日历事件时，它是否仍对应同一条待办？周五汇报的数字又是否来自最新的任务状态？这些问题都被迫由人手记忆和校验。
窗口割裂还会掩盖责任断点。后台 Agent 生成了草稿，却不知道用户是否已采纳；任务 API 创建了事项，却不知道文档中的决策是否已确认；周报生成了图表，却无法说明数据来自哪个台账版本。用户最后得到的不是一个协同现场，而是一组需要手动拼接的局部功能。
3. 事实证据：小陈的五窗口时间线，暴露了能力到结果之间的最后一公里
上线第三周，小陈的吐槽非常具体：“员工在后台很勤快，我还是要把纪要复制到 Word、再粘到 Excel、再手动建日历、周五再熬夜做周报。”团队复盘发现，问题并非数字员工不会生成内容，而是产物没有进入一个可继续消费的工作流：草稿停在对话中，台账在网盘，提醒靠人记忆，周报又从分散资料重新拼起。
| 时间 | 发生了什么 | 缺口 |
|---|---|---|
| 平台上线日 | 数字员工能写纪要草稿、标逾期 | 小陈仍在聊天窗里复制粘贴 |
| 会后当晚 | 草稿在对话里，台账在网盘，日历靠脑子 | 产物进不了工作流 |
| 周五例会前 | 通宵拼 PPT；逾期条靠人工筛表 | 链路每步断在「人肉搬运」 |
| 复盘 | 结论：问题不在能力，在入口与链路 | 缺工作台：同一现场完成理解→执行→校验 |
图中两条路径的差别不在于是否使用了 Word、Excel 或 PPT，而在于这些工具是否围绕同一任务对象协作。工作台允许用户在一个现场把草稿、台账、提醒和周报串成连续动作，并在每一步保留来源、状态和确认记录；多窗口路径则把这些关联交给人的记忆。
4. 执行结论：用工作台把能力接到现场，让资料自然流向可消费结果
团队为小陈定义的不是又一个聊天机器人，而是一个围绕任务工作的办公现场：用户进入一场会议后能同时看到资料、纪要草稿、待办、来源证据、权限状态和建议下一步；低风险动作在确认后进入 Word、Excel、日历或 PPT，高风险动作停在可见闸门前；周报和台账不是新附件，而是可以被下一轮任务继续引用的工作对象。
进入：围绕会议或任务建立单一工作现场；理解：资料、来源与上下文在同一任务下可见；加工：生成纪要、任务与周报草稿；执行：确认后写入 Word / Excel / 日历 / PPT；校验：状态、权限和证据可追溯，异常转人工；交付：产物成为下一周可继续消费的对象，而非散落附件。- 用户是否能够围绕同一任务同时查看资料、草稿、任务状态、来源证据与下一步动作？
- Word、Excel、日历和 PPT 中的产物是否关联同一任务对象，而非靠人工复制和命名保持一致？
- 生成、写入、确认、撤回和异常升级是否在工作现场可见，并能回到具体证据？
- 交付物是否能被下一轮会议、任务或周报继续消费，而不是在一次对话后变成孤立附件？
思考：工作台不是给 AI 再开一个窗口，而是把人从窗口之间的搬运工作中解放出来
真正耗费注意力的往往不是写一段文字，而是判断这段文字能否成为任务、任务是否已经被执行、执行结果又能否成为下一份汇报的可信依据。工作台要承接的，就是这些跨工具、跨时间的连续性。
当数字员工的能力进入用户实际工作的现场，自动化才不再只是后台的演示，而会成为人和系统共同完成一项工作的可见路径。
Part 01 · 工作台：把零散信息带进同一现场
01 / 入口小陈要的不是「再问一个问题」，而是「完成一项办公任务」。终点是工作流里的产物，不是对话框里的一段话。
1. 入口背景：用户需要的是完成一项办公任务的现场，不是更多应用入口
小陈打开工作时，面对的是一组相互依赖的对象：评审会资料、录音和邮件提供事实，纪要草稿需要被确认，待办需要进入台账和日历，周报需要汇总这些状态。过去这些对象散落在不同应用里，用户要不断切换窗口、复制内容、判断版本，并亲自维护它们之间的关联。
工作台的价值不在于把应用图标收进同一页，而在于为这项任务建立共同现场。用户在同一个任务中能看到输入资料、生成结果、执行状态、来源证据、权限限制和下一步建议；工作台把 Agent 的理解、执行和校验能力编排成连续动作，把最终成果送入用户已经在用的 Word、Excel、日历和 PPT。
| 过去（多窗口） | 工作台（目标态） | |
|---|---|---|
| 输入 | 录音在会议软件、纪要在聊天、台账在网盘 | 纪要草稿 / 台账 / 邮件一次性拖进工作区 |
| 过程 | 人肉复制粘贴、靠记忆提醒 | 理解 → 执行 → 校验，进度可见 |
| 输出 | 聊天窗里一段「看起来对」的文字 | 直接写入 Word / Excel / 日历 / PPT |
| 沉淀 | 每次从零找模板 | 模板、历史周报、台账留在工作区 |
2. 核心问题：为什么“统一入口”若没有共同任务状态，仍然只是新的信息孤岛
把聊天、文档和表格嵌入一个页面并不会自动减少协作成本。若纪要草稿、台账候选行、日历提醒和周报图表没有关联同一任务对象，用户仍要自己确认它们是否来自同一场会议、是否采用了最新资料、是否已经被写入。界面看起来统一，状态和证据仍然分散。
更大的风险是把“已生成”误认为“已完成”。Agent 可以输出待办，却不能在负责人或截止日期缺失时静默放行；也不能在高风险写入前绕开用户确认。工作台必须把理解、执行、校验设计为可见的状态门，而非将它们藏在一次不可解释的后台调用中。
3. 事实证据：一场评审会如何在工作台中从资料变成可继续工作的成果
小陈创建“Q3 评审会”任务后，将纪要草稿、项目台账和决策邮件拖入同一工作区。工作台先提取会议目标、决策、待办和风险，并显示每条内容的来源；确认后才生成 Word 纪要和 Excel 候选行。缺负责人或截止的事项停在待补全，而不是伪装为已分派；字段齐全且权限允许的任务再创建日历提醒。最后，已确认的任务状态和风险自动进入周报草稿，用户始终能回到原会议和任务记录核对。
- 理解：识别本场评审的目标、决策与待办；歧义先标出，不假装懂了
- 执行：调用已授权连接器——生成初稿、写台账候选行、建日历提醒
- 校验：缺负责人 / 截止则拦住；禁止静默「完成」
判断与授权
确认例外、拍板口径、点高风险闸。
整理与推进
结构化、批量写入、标逾期、出草稿。
这里的关键不是“AI 一次做完”，而是每一步都产生下一步可消费的对象：资料成为带来源的理解结果，理解结果成为经确认的任务，任务成为受控写入，写入结果成为周报和后续会议的依据。人负责判断和授权，AI 负责整理和推进，工作台负责让这条链不断开。
4. 执行结论：让工作台承接任务状态，让产物自然进入既有工作流
工作台应以任务而非对话为中心：进入时绑定资料和项目上下文，理解时保留来源，执行前完成字段与权限校验，执行后将产物写入熟悉的办公工具并绑定 Task ID，校验结果和阻塞状态始终对用户可见。这样，工作台不会替换用户的办公软件，而是把它们组织成一条有状态、有证据、可继续推进的工作链。
建立现场：一个任务 ID 绑定资料、项目、模板与历史状态；理解：输出带来源的决策、待办和风险；确认：用户修正不确定内容；执行：通过字段/权限闸后写入 Word、Excel、日历或 PPT；校验：回收 Task ID、写入结果和证据；交付：周报与任务状态可被下一轮工作继续消费。- 用户是否能在一个任务中同时看到输入资料、任务状态、来源证据、权限提示和建议下一步？
- 所有文档、台账、日历和周报产物是否绑定同一任务对象，而非靠人工复制维持关联？
- 负责人、截止、权限或高风险条件不满足时，是否以可见阻塞替代静默完成？
- 工作完成后，产物是否能被下一场会议或下一次汇报继续检索和消费？
思考：真正的统一，不是把信息放进同一个屏幕，而是让它们围绕同一件工作持续保持关系
多窗口带来的麻烦并不只是切换次数，而是每次切换都可能让来源、状态和责任关系丢失。工作台的价值，是让这些关系成为系统维护的对象，而不再依赖用户脑中记住。
当资料、任务、写入和交付都属于同一条可追溯工作链，数字员工才会真正出现在人实际完成工作的现场。
Part 02 · 先分清：工作台 · Agent · 数字员工
02 / 边界同一场办公协作里，工作台、Agent 与数字员工会同时出现；但它们承担的责任不同。先分清层，才能把改动做在正确位置。
1. 分层背景：同一项办公体验，有三种不同责任
小陈希望把一场 Q3 项目评审从录音、文档和台账一路推进到周报。表面上这像是「让 AI 帮我处理会议」，实际同时涉及三个层面：他从哪里进入任务、系统如何理解和执行，以及哪一个岗位对交付结果负责。
工作台解决的是人怎样完成工作：选定项目、投入资料、看到建议、确认写入、在异常时接管。Agent 解决的是能力怎样完成动作：提炼待办、调用工具、补齐字段、核验结果。数字员工平台解决的是岗位怎样持续交付：职责范围、知识边界、流程权限、审计记录和结果指标。
| 层 | 核心问题 | 案例里谁负责 | 本篇不做什么 |
|---|---|---|---|
| 工作台（本篇） | 员工怎么用？ | 小陈：选项目、丢资料、确认、接管 | 不重新设计岗谱 |
| Agent 能力 | 能力如何构建？ | 理解 / 工具 / 校验等可复用能力 | 不重讲原理课 |
| 数字员工平台 | 岗位如何持续交付？ | 项目协同岗的职责、权限、指标 | 不重复 04 配置细节 |
2. 核心问题：三层一起改，为什么会看似完整、实际无法验收
需求评审里常见一句话是：「把 Agent 做进工作台，顺便把岗位也改了。」这句话把界面、执行能力和岗位治理揉成一个需求。于是有人开始改聊天界面，有人重写模型提示词，有人调整权限，最后却没有人能回答：小陈是否真的少切窗口、待办是否真的写进台账、错误发生时又该由谁处理。
本轮的边界应该固定：项目协同岗的职责和授权已经存在，提炼纪要、生成候选任务等能力也已具备；工作台只负责把这些能力编排进小陈的同一个任务现场，让「会议到周报」可以看见、确认、继续和追溯。
混用
「把 Agent 做进工作台，顺便把岗位也改了。」→ 三层一起改，评审发散。
钉入口
「平台岗已定；本轮只做小陈怎么在一个入口里完成会议到周报。」
3. 现场证据：一场评审会，三层各自站在哪里
当小陈发起「完成 Q3 评审会到周报」任务，工作台先把项目、录音、当前台账和模板聚到同一 Task ID 下；Agent 在受控上下文中提取决策、待办与风险，并生成待确认的写入候选；数字员工平台则判断项目协同岗是否拥有写入权限、何时需要升级给负责人，并保留整个过程的审计证据。三者服务同一个任务对象，却不互相替代。
flowchart TB
Request["小陈：完成 Q3 评审会到周报"] --> Diagnose{"需求主要改变什么？"}
Diagnose -->|"用户如何操作、看见、确认"| Workbench["工作台层\n任务现场、资料入口、状态与共作界面"]
Diagnose -->|"如何理解、生成、调用、校验"| Agent["Agent 能力层\n理解、规划、工具、上下文、验证"]
Diagnose -->|"为谁服务、能做什么、怎么治理"| Platform["数字员工平台层\n岗位、知识、流程、权限、指标"]
Workbench --> Use["小陈选项目、丢资料、确认、接管"]
Agent --> Ability["提炼待办、生成候选、校验字段"]
Platform --> Role["项目协同岗\n授权、升级、审计、考核"]
Use --> Task["同一任务对象\n资料、状态、证据、产物"]
Ability --> Task
Role --> Task
Task --> Outcome["会议到周报\n可消费、可追溯的结果"]
4. 执行结论：先为需求归层，再让三层围绕同一任务协同
分层不是把体验拆给三个团队各做一段，而是先写清每一项改动的主责层，再以同一个 Task ID、同一份证据链和同一套验收结果把它们连起来。这样，工作台可以验证用户是否顺畅完成操作，Agent 可以验证输出是否准确可用，数字员工平台可以验证权限、审计和岗位指标是否合规。
先问：这项改动首先改变谁的操作、谁的能力或谁的岗位责任？再定主责层；随后让三层共享任务 ID、输入资料、状态、来源证据和最终产物；最后按各自的验收标准分别放行。- 每个需求是否能明确写出主责层，而不是用「AI 功能」笼统归类？
- 工作台、Agent 与数字员工平台是否使用同一个任务标识和可回溯证据？
- 界面可用、能力正确、岗位合规这三类验收是否分别检查，而非以一次演示代替？
思考：分层不是把体验拆碎，而是让每一次改动都有清楚的责任和可验证的边界
用户只关心事情是否办成，不会在意背后属于哪一层；因此三层必须围绕同一任务协作。但系统设计者不能因此放弃边界：入口体验、通用能力与岗位治理采用不同的节奏、证据和验收方式，混在一起只会让问题无法定位。
Part 03 · 价值在链路上：会议到周报每步留产物
03 / 链路关键变化不是生成更多文字，而是让会议事实沿着任务、台账、日程和汇报持续流动：每一步留下可被下一步直接消费的产物。
1. 链路背景：一场会议的价值，不在纪要写完时结束
对小陈来说，会议结束只是项目协同的起点。会中确认的决策需要回到正式纪要，待办需要进入项目台账，负责人和截止需要形成提醒，风险又要在周报中被负责人看见。若这些信息只停留在一份“写得很好”的摘要里，下一位接手的人仍要重新找资料、补字段、判断版本，工作链其实尚未开始。
因此，工作台要管理的不是一篇文本，而是一组有状态的工作对象：会议资料提供事实依据，结构化字段承接理解结果，任务和日历推动执行，台账沉淀过程状态，周报汇总可被复核的结果。每一次转换都要明确来源、负责人和交接条件。
- 输入：本场评审录音转写 + 当前项目台账
- 理解：决策 / 待办 / 风险（结构化字段，不是散文）
- 生成：结构化纪要 + 台账候选行
- 协同：确认后写任务、建日历提醒
- 交付：周五汇总进周报页（待确认再分享）
2. 核心问题：为什么“生成纪要”不等于“会议已经推进”
最常见的断点发生在生成之后。Agent 从录音里整理出十条待办，看起来完成了任务；但如果待办没有负责人、截止时间、项目归属和来源锚点，Excel 无法落行，日历无法建提醒，周报也无法判断逾期。信息从会议中被提取出来，却没有变成能驱动后续系统的对象。
另一个风险是把展示层当成事实层。周报图表若靠人工筛表和手填，即使数字正确也无法说明来自哪个任务、采用了哪个版本，更无法在状态变化后自动回写。链路的标准不是“每步都生成了内容”，而是“本步产物能在不靠人肉翻译的前提下成为下一步输入”。
| 步骤 | 本步产物 | 下一步如何消费 | 断点信号 |
|---|---|---|---|
| 理解 | 决策/待办/风险字段 | 生成纪要段落与台账行 | 只有大段摘要，无字段 |
| 生成 | 纪要 + 候选行 | 映射负责人/截止写入台账 | 待办无法映射台账列 |
| 协同 | Task ID + 日历提醒 | D-1 点对点通知 | 只发群消息，无 Task |
| 交付 | 周报页（带来源） | 例会讨论与下周跟进 | 图表手填、无台账链接 |
3. 事实证据：从评审会到周报，产物如何一环扣一环
小陈上传评审录音和当前项目台账后，工作台先输出带转写来源的“决策、待办、风险”字段。待办经小陈确认后，才生成正式纪要段落和 Excel 候选行；字段完整且有写入权限时，候选行成为带 Task ID 的项目任务，并创建日历提醒。周五生成周报时，系统只汇总这些已确认任务的当前状态，风险数字可回到具体台账行和原会议来源。
这里有两个关键的交接门：一是确认门，未决事项不能冒充已确认决策，缺失字段不能冒充可执行任务；二是追溯门，周报中的每一项进展、风险和逾期都应能回到 Task ID、台账行和会议来源。两道门让工作台不会把不确定内容静默推进到后续系统。
4. 执行结论：以可消费产物定义完成，用断点而非补救管理例外
团队应为每个节点写清四件事：接收什么输入，产出什么对象，由谁或什么规则放行，失败时停在哪里。这样，Agent 的作用不只是生成草稿，而是持续把信息转换为下一步可执行、可核验、可追溯的对象；人也不必在链路末端重新拼装事实。
输入：会议资料与当前台账；理解：带来源的决策、待办、风险字段；确认：缺负责人、截止或决议则停住；执行：写入纪要、任务、台账与日历；汇总：周报只消费已确认任务的实时状态；追溯：任何结论都可回到 Task ID 与原始来源。- 每一个待办是否都有 Task ID、负责人、截止、项目归属与来源，而不只是纪要中的一句话？
- 缺字段、未确认或无权限时，是否停在可见阻塞，而非继续生成“看似完成”的产物？
- 周报中的进展、风险和逾期是否可点回台账行、任务状态与会议证据？
- 下次会议能否直接消费本次留下的任务和周报，而无需重新整理散落资料？
思考：AI 的价值不在替人写完一份材料，而在让一份材料继续推动后面的工作
一份纪要、一个任务、一条提醒和一页周报，只有在彼此可引用、可更新、可追溯时才构成工作成果。把它们看成孤立文件，交付就会在每一次工具切换时重新断开；把它们看成同一任务的不同状态，自动化才会真正积累成协作能力。
Part 04 · 任务表达：工作台表单，不是空白对话框
04 / 任务一句“帮我做周报”无法成为可执行任务。工作台要把模糊意图收束成可检查、可放行、可回溯的任务卡。
1. 任务背景：对话可以开始思考，不能直接开始交付
小陈在周五下午输入“帮我做周报”。这句话表达了意图，却没有说明范围：基于哪些会议和台账、面向哪些读者、要输出什么格式、哪些内容不能写、怎样才算数据正确。模型可以立刻写出一页完整的文字，但它无法判断应采用哪个项目版本，更无法替小陈承担对外口径和数据准确性的责任。
工作台表单的作用不是让用户填写更多字段，而是把任务启动前必须达成的共识显式化。目标决定做什么，资料决定依据什么，输出决定交付物，约束决定不能做什么，验收决定何时停止。五项组成一份能被人、Agent 和工具共同执行的任务契约。
| 空白对话框（v0） | 五要素任务卡（定稿） | |
|---|---|---|
| 输入 | 「帮我做周报」 | 目标 / 资料 / 输出 / 约束 / 验收齐全 |
| 产出 | 漂亮但无法对台账 | PPT 页可回溯到 Tasks sheet |
| 风险 | 外发、编造进度 | 禁外发；未决议不得写成已完成 |
2. 核心问题：空白对话框为什么会把模糊需求伪装成已完成
空白对话框把所有缺失条件都留给模型猜测。它可能从旧文档中取错版本，把“预计完成”写成“已完成”，或者生成一份没有负责人的“下一步”。输出越流畅，团队越容易忽略这些未经确认的假设，直到分享前或项目出错后才发现返工。
任务卡应当把未知转换为可见阻塞：资料缺失时不能引用，验收不清时不能放行，风险约束不明时只能生成草稿不能写入或分享。这样，系统并不拒绝小陈的需求，而是明确告诉他还差什么才能可靠开跑。
【工作台任务卡 · 本周项目周报】
目标：生成本周项目周报，供周五例会使用
资料：本周 3 份会议纪要 + 项目台账 sheet「Tasks」
输出：PPT（进展/风险/逾期/下周）+ 可编辑备注
约束：不外发；不改台账结构；未决议不写成已完成
验收：数据有来源；逾期任务与台账一致；下一步有负责人
规则：五要素任一空 → 状态=blocked，不开生成。3. 事实证据：一张“本周项目周报”任务卡如何阻止错误开跑
第一版任务只有“生成项目周报”，系统便取用了上周的台账快照，且将会议里的“预计下周完成”写成了“本周已完成”。改用任务卡后，小陈绑定本周三份会议纪要与 Tasks 表，指定输出为“进展、风险、逾期、下周”四页 PPT，并明确“未决议不得写成已完成、不可外发”。当任务没有写明验收人和数据范围时，状态停在 blocked，系统只提示补充，不生成最终交付物。
4. 执行结论：让任务先可验证，再让 Agent 开始执行
任务创建时，工作台应校验五要素与资料可访问性，并为任务分配 Task ID。执行过程引用的文件版本、生成的候选产物、确认与拦截记录都回写到该任务下。对于资料、约束或验收不明确的任务，系统应清楚展示缺口和下一位补充人，而不是凭猜测交出看似完整的成品。
先填：目标、资料、输出、约束、验收；再查：资料是否可访问、版本是否正确、风险是否允许；通过后才锁定范围并生成草稿；草稿仍须经过约束校验与人工确认，才能进入写入或分享。- 任务是否明确写出使用哪些资料、面向谁、要交付什么，而非只写“帮我处理一下”？
- 未决事项、不可外发、不可改结构等边界是否在生成前写入约束？
- 验收是否能判断数据、来源、负责人和下一步，而非用“内容看起来不错”代替？
- 缺项时是否进入可见 blocked 状态并能继续补充，而不是悄悄用猜测填空？
思考：好的任务表达不是限制创造力，而是让创造力落在正确的事实、边界和责任上
自然语言适合提出问题，却不足以独自承载交付承诺。把关键条件写入任务卡，并没有降低 Agent 的能力；它让生成、工具调用和验收都拥有同一份可讨论、可修订的依据。
Part 05 · Word：把会开成可核对的正式纪要
05 / Word正式纪要不是会议作文，而是下一步协作可据以执行的事实记录：说清已确认什么、谁来做、何时完成，以及什么仍待决定。
1. 纪要背景：会开完了，团队还需要一份能对齐事实的正式记录
会议里的表达往往包含讨论、试探和最终结论。小陈会后需要的不是一段概述，而是一份可让未参会同事、负责人和项目经理快速核对的正式纪要：哪些事实已经确认，哪些决策已经拍板，哪些待办已经有人接手，哪些事项仍然没有定论。
Word 在这条链路中承接的是“可读、可核对的正式表述”。它引用会议转写和任务卡中的结构化字段，套入团队模板，保留来源和版本；它不替代台账追踪任务，也不把不确定的讨论润色成确定的结论。
| 小陈要的产物 | 工作台能力 | 放行标准 |
|---|---|---|
| 评审纪要、变更说明、会后通知草稿 | 提炼结构 · 套模板 · 标未决 · 禁推测当事实 | 五段齐全；来源、版本与分发范围可核对；未决单独成段 |
2. 核心问题：为什么流畅的纪要仍可能制造错误共识
语言模型擅长让文章通顺，却可能抹平会议现场的确定性差异。比如“可能下周上线”“我再确认一下”如果被整理为“下周上线”，讨论就被误写成决策；待办没有负责人或截止，如果被写成“已分派”，团队会误以为行动已经启动。这样的纪要越像正式文件，误导成本越高。
因此，纪要必须把事实、决策、行动和未决拆开记录。只有能回到来源并经过确认的内容进入“已拍板项”；未知字段保留为空并形成待补全项；未决内容单独呈现，不能随着文笔优化被悄悄消失。
发生了什么
可核对的陈述；带来源句或转写锚点。
已拍板项
仅写入明确确认的结论；禁止「可能」混入。
谁执行
每人名可映射台账；空名则阻塞。
何时 · 未定
截止进日历；未决单独成段，不得进「决策」。
依据哪版 · 发给谁
记录资料快照、纪要版本、确认人和分发范围；未确认不得对外发送。
3. 事实证据：把“可能下周上线”从假决策拦回未决事项
在第一版纪要中，Agent 将会上“认证模块可能下周上线，等安全复核后再确认”写成了“认证模块确认下周上线”。小陈通过来源锚点回看原句后，发现缺少安全复核结论。工作台将该条从决策区移入未决区，生成“待安全复核后确认上线窗口”的跟进任务，并保留会议来源与补充人。
图中的关键不是让系统替人判断所有语气，而是让“证据不足”有固定去处。无法确认的内容仍然保留在文档中，但以未决和待补全的形式出现；它既不会被遗忘，也不会误导执行。这让纪要成为事实边界，而不是语言润色后的想象。
4. 执行结论：先按证据分段，再把缺口变成可继续跟进的对象
生成纪要时，工作台应要求每一段都具备相应的来源和状态：事实附来源锚点，决策附确认信号，待办附负责人和截止，未决附待确认人或下一次决策节点；同时保存本次引用的资料快照、纪要版本、确认人和分发范围。字段不全时不伪造完整句，而是在文档和任务侧栏中同步展示缺口。对外分享前则由有权限的人确认版本、口径和接收范围。
先锁定资料版本与会议来源；再按证据分为事实、决策、待办和未决；决策无确认信号则转未决，待办缺负责人或截止则转待补全；小陈核对来源、版本和分发范围；通过确认门后才生成并分发正式 Word 纪要。- 每个已拍板项是否都能回到会议原话、邮件或明确确认记录？
- 待办是否同时具有负责人、截止、Task ID 和来源，而不是只有一句行动描述？
- “可能、预计、待确认”等内容是否全部留在未决区，而未被写进决策区？
- 对外发送前，是否有资料快照、版本、确认人、接收范围和审计记录可查？
思考：正式文档的价值，不是把会议说得更漂亮，而是把确定与不确定都放在正确的位置
团队协作最怕的不是有未决事项，而是未决事项被写成已决、缺口被写成已完成。愿意把不确定性写清楚，才会让下一次确认和下一步行动有明确的入口。
Part 06 · Excel：台账要能回答「谁该跟进」
06 / Excel填满表格不是终点。台账必须把会议待办持续变成可判断的状态，让项目经理随时回答：谁该跟进、卡在哪里、何时需要升级。
1. 台账背景：会议里的待办，要在会后继续拥有状态和负责人
Word 纪要说明了会议说清楚了什么，Excel 台账则负责让这些结论在会后持续推进。小陈不需要另一份装满行列的文档，他需要在周二追进度、周四识别风险、周五准备周报时，都能快速看见哪些任务正在推进、哪些任务停住、哪些人需要被提醒或升级。
项目组因此冻结台账字段：任务 · 负责人 · 截止时间 · 状态 · 风险 · 下一步 · 来源会议。这些字段不是为了表格好看，而是让任务具备判断和行动的最小信息。少了负责人，无法点对点跟进；少了截止，无法判断逾期；少了来源，无法回到会议核对；少了下一步，状态就只是标签。
| 处理数据（后台） | 输出判断（工作台侧栏） |
|---|---|
| 清洗字段 · 补公式 · 统计进度 · 标逾期 · 出简图 | 哪些卡住？谁要跟进？哪些风险上升？下周重点？ |
2. 核心问题：为什么“所有列都填了”仍然答不出谁该跟进
许多台账把状态写成“进行中”，却没有记录最后更新时间、阻塞原因和下一步动作。表格看起来完整，小陈却仍要逐行筛选、发消息追问，才能找出真正的风险。更糟的是，会议纪要与台账各自更新后，负责人、截止和状态出现两个版本，周报只能依靠手工判断。
能支持决策的台账，不只是存储任务，而是根据明确规则形成行动队列：负责人为空的任务先待补全；截止临近但未完成的任务进入提醒；逾期且无有效进展的任务进入升级；风险上升的任务进入周报候选。工作台侧栏应呈现这些判断，并允许用户一键回到具体任务和来源，而不是重新筛表。
漂亮空表
列都填了，但侧栏答不出「谁该跟进」——还要人肉筛。
判断入口
小陈周五打开：侧栏直接「逾期 4 条 / 缺负责人 1 条」，可点进任务。
3. 事实证据：周五前，工作台如何从台账找出真正需要跟进的人
周五上午，小陈需要准备周报。工作台没有只展示“进行中任务 18 条”，而是根据台账做了一次分诊：4 条已逾期且仍未完成，1 条没有负责人，2 条风险等级从低升到高。小陈点击“逾期 4 条”后，可以直接看到每条任务的负责人、最后更新、阻塞原因、来源会议和已经发送的提醒记录，从而决定催办、升级或调整计划。
4. 执行结论：冻结字段，明确规则，把异常变成可处理队列
台账结构一旦确定，Agent 只能在既有字段中生成候选和更新建议，不能随意改列或另建一份表。工作台则基于统一规则计算待补全、提醒、升级与风险队列，并将每次提醒、状态修改和人工处置回写到同一 Task ID。这样，Excel 是任务事实的持续账本，侧栏是面向小陈的行动入口，周报只是对这些事实的受控汇总。
会议待办进入冻结字段；状态、风险与下一步持续更新；规则把异常分入待补全、提醒、升级和风险队列；小陈从侧栏选择行动；行动及其证据回写台账；周报只消费已确认的当前状态。- 每条任务是否都有负责人、截止、状态、风险、下一步和来源会议，且与 Task ID 对应？
- 工作台能否直接列出待补全、临期、逾期和风险上升的任务，而无需人工逐行筛选？
- 提醒、升级和人工调整是否写回同一台账，并保留执行时间、操作者和证据？
- 周报的逾期和风险数字是否来自台账实时状态，而非人工另存和手填？
思考：台账的价值不在记录过去，而在让下一次跟进不必重新判断
真正降低协作成本的不是更多列，而是让每个状态都带着下一步动作和责任人。台账把会议里一次性的承诺变成可持续更新的事实，工作台再把这些事实翻译成此刻应当做什么。
Part 07 · PPT：周报要能让人行动
07 / PPT周报不是把台账缩成幻灯片，而是帮助团队在有限时间内看清进展、判断风险并确认下一步行动；数据、结论与负责人缺一不可。
1. 汇报背景：周报的终点不是讲完，而是让团队在会后知道怎么做
周五例会上，小陈只有十分钟说明项目状况。真正需要被回答的不是“本周做了多少页材料”，而是：哪些工作已完成且有依据，哪些风险影响目标，哪些决策需要现场拍板，以及会后谁在什么时间前采取什么动作。若周报只堆满进度描述，听众仍需在会后重新追问，汇报没有承担协作责任。
PPT 在工作链中是一次面向决策者的受控汇总。它从台账读取当前状态和风险，从纪要读取已确认决策，从任务读取负责人和下一步，并将每个关键结论保留到 Task ID 与来源。它不重新发明数据，更不把未经确认的候选内容包装成正式口径。
- 提炼：本周主线（例如：认证合入阻塞）
- 结构：进展 → 问题 → 风险 → 下周
- 图表：闭环率 / 逾期来自台账，禁止手填
- 表达：听众是项目组，不写空话
- 交付：讲稿备注 + 待确认后分享
2. 核心问题：为什么“好看又完整”的周报仍然不能推动行动
漂亮的图表可能掩盖两类断点。一类是事实断点：闭环率、逾期数和风险趋势通过手工筛表得到，无法说明取数时间、范围和来源；一旦台账状态变化，PPT 就立即过期。另一类是行动断点：页面写着“下周推进认证合入”，却没有负责人、截止和依赖条件，所有人都以为这件事属于别人。
因此，周报的验收不以版式或文笔为中心，而以“数据有来源、结论有依据、风险有处置、下一步有人接”为中心。工作台必须在生成时拦住无来源数据和无人承接的行动项；对外或跨团队分享前，则需要人工确认版本与口径。
| 不进验收 | 必须过 |
|---|---|
| 版式炫、动画多、文案像人写 | 数据有来源 · 结论有依据 · 页面有重点 · 下一步有负责人 |
3. 事实证据：从“认证合入阻塞”到可决策的周报行动页
本周台账显示，认证合入任务已逾期两天，阻塞原因是安全复核未完成。第一版周报只写“认证进展需要关注”，项目组听完仍不知道该由谁处理。工作台改为从 Task ID 拉取负责人、最后更新时间、来源会议和阻塞证据，形成“风险：认证合入延迟；依据：安全复核未完成；影响：集成测试顺延；下一步：王工周二前完成复核，小陈周二下午同步结果”的行动卡。它既能回到事实，也能在会后继续执行。
4. 执行结论：把周报做成事实汇总、决策入口和行动承诺
生成周报前，工作台先锁定取数范围和台账版本；生成时每一页都引用对应任务和纪要证据；校验时检查数字来源、风险依据和行动归属；分享前由小陈确认口径。会后确认的下一步再写回同一批任务与日历，使周报成为工作链中的一次状态更新，而非一份脱离现场的演示文件。
取数：锁定本周范围与台账版本；提炼：用已确认决策与实时任务形成进展、问题、风险、下周；校验：数据能回溯、结论有依据、行动有负责人和截止；确认：人工核对口径；分享：行动回写任务与日历，供下轮跟进继续消费。- 每个进度、逾期和风险数字是否能回到台账范围、Task ID 和取数时间？
- 每条关键结论是否有会议决策、任务状态或来源证据支撑，而非根据语气推测？
- 每一项“下一步”是否明确负责人、截止、依赖条件，并已进入后续任务链？
- 分享前是否由有权限的人确认版本和对外口径，未通过时保留为草稿？
思考：好的周报不是让人觉得项目“讲明白了”，而是让会后不必再猜谁该做什么
汇报的质量最终要用行动来检验。只要数字可回溯、风险可判断、责任可落人，PPT 就会从静态展示变成推动协作的节点；反之，再精美的页面也只是下一轮追问的开始。
Part 08 · 会议协同：纪要只是中间产物
08 / 协同纪要记录会议，协同推动行动。工作台要把待办交给正确的人、在正确时间提醒，并在无法推进时带着证据升级，而不是用一条群消息结束工作。
1. 协同背景：纪要发出后，项目工作才刚刚开始
会议结束时，团队常常拥有一份完整纪要，却没有真正的行动闭环。有人负责什么、何时完成、依赖谁确认、到期未完成怎么办，这些信息若仍停在文档段落里，项目经理只能靠记忆和群聊反复催问。纪要交付了文字，却没有交付可持续推进的协作状态。
会议协同的对象应当是每一条已确认待办，而不是整份纪要。工作台从纪要中创建带 Task ID 的任务，绑定负责人、截止、来源和阻塞原因；日历与点对点提醒负责让行动到达负责人；台账记录状态变化；当任务无法按规则推进时，升级包把完整上下文交给有权决策的人。所有动作仍围绕同一任务持续积累证据。
- 提炼：决定 / 待办 / 风险
- 创建：任务 / 负责人 / 截止（写入台账 + 日历）
- 提醒：D-1 点对点通知负责人
- 升级：逾期 24h → 项目经理（带升级包）
- 汇总：进入周报风险清单
2. 核心问题：为什么自动群发不是协同，反而会放大噪音
把每一条待办自动发到群里，看似完成了通知，却没有判断对象、时机和处置条件。负责人可能淹没在重复消息中，项目经理只能看到一句“请关注”，而无法知道任务来自哪次会议、此前是否已提醒、真正的阻塞是什么。消息越多，责任反而越模糊。
可靠协同应遵循分级推进：正常任务留在任务面板中跟踪；截止前 D-1 点对点提醒负责人；逾期后先要求补充状态或阻塞；超过约定时限且仍未推进，才向项目经理发送包含 Task ID、来源、已尝试动作、当前证据和建议选项的升级包。升级不是把问题甩出去，而是把可判断的上下文送到能处理的人手中。
点对点
默认通知负责人本人；群发需确认门。
带完整包
Task ID · 来源会 · 已尝试 · 证据 · 建议选项——禁止「你看下」。
3. 事实证据：一条逾期任务如何从提醒变成可处理的升级
“完成认证安全复核”来自周一评审会，负责人是王工，截止周三。工作台在周二上午发送点对点提醒，并在任务侧栏保留已读状态。周三结束时王工更新“等待外部安全团队结果”，任务自动记录阻塞原因而不是只标红。逾期 24 小时后，系统向小陈生成升级候选：包含任务来源、当前状态、已提醒记录、外部依赖与两个建议选项“调整集成测试日期”或“协调安全团队加急”。小陈确认后才正式升级，结果再回写任务和周报风险项。
这条链路的关键是每次状态变化都有落点：提醒不是聊天记录，而是任务事件；阻塞不是口头解释，而是可被周报汇总的字段；升级不是一句“你看下”，而是一份可以立即做判断的证据包。小陈也能在同一界面选择继续催办、调整计划或交由项目经理决策。
4. 执行结论：用任务状态管理协同，用证据包管理升级
工作台应将提醒、逾期、升级和处置定义为任务状态转换，而不是四种互不关联的消息。每条任务明确负责人、截止、升级阈值和可见状态；每次提醒记录对象与结果；每次升级自动汇集证据但保留人工确认；处置决定再回写任务、台账和周报。这样，自动化负责及时发现和准备上下文，人负责例外判断与最终决策。
纪要待办确认后创建任务；任务正常推进则持续更新；D-1 发送点对点提醒；逾期或出现阻塞时收集原因与已尝试动作；达到阈值生成升级候选；人工确认处置后，将决定回写任务、台账和周报风险项。- 每条会议待办是否已成为带负责人、截止、来源与 Task ID 的可跟踪任务？
- 提醒是否默认点对点发送，并记录送达、已读或状态更新，而非仅向群聊广播？
- 升级包是否包含来源、阻塞、已尝试动作、当前证据和可选处置，而非只写“请关注”？
- 提醒、升级和处置的结果是否回写台账与周报，使下次协同无需重新收集事实？
思考：协同不是把更多消息送出去，而是让每一次交接都带着足够的事实和明确的下一位责任人
自动化最有价值的时刻，不是替人多发一条提醒，而是提前发现任务无法自行推进，并把判断所需的上下文准备完整。人仍然负责取舍和授权，但不必再从会议纪要、聊天记录和表格中拼凑问题。
Part 09 · 资料与权限：入口上的闸，不是事后追责
09 / 权限接入 Word、Excel、日历不等于可以随意修改和发送。每一次动作都应在入口判断权限、范围与风险，让拦截、确认、审计和撤回发生在结果不可逆之前。
1. 权限背景：工具能调用，不代表这次动作被允许
工作台已经接入 Word、Excel、日历和 PPT，但连接成功只说明技术上可以调用，不说明小陈、Agent 或项目协同岗有权在当前项目、当前资料范围内执行具体动作。把会议纪要写入本项目文档、更新本项目台账，和向客户外发周报、修改共享权限、代表团队做出承诺，风险与授权要求完全不同。
权限闸要出现在动作入口，而不是等内容已经写入、文件已经分享后再查日志。每一次执行至少需要回答：谁发起，操作哪个项目和对象，要做什么，依据什么授权，影响范围多大，失败后能否撤回。只有这些条件明确，系统才能决定直接执行、要求确认、升级人工或拒绝动作。
| 动作 | 工作台表现 | 审计 |
|---|---|---|
| 写本项目纪要 / 台账 | 直接执行 | 谁、何时、改了哪行 |
| 生成周报 PPT | 预览 → 人工确认 → 分享 | 确认人与版本号 |
| 外发客户、改权限、审批承诺 | 按钮灰置或强制升级人工 | 拦截原因留痕 |
| 误操作 | 可撤回至上一检查点 | 撤回前后快照 |
2. 核心问题：为什么事后审计无法替代事前控制
如果 Agent 先把周报外发给客户、再在日志里记录一次“已分享”，审计只能帮助追责，无法撤回已经看到的信息；如果它先调整文档权限、再提醒小陈检查，越权范围可能已经扩大。风险不在于系统有没有日志，而在于高影响动作是否在发生前被正确识别并暂停。
工作台因此需要按动作风险分流：在已授权项目内生成草稿、更新候选台账行等低风险操作可以自动执行，但过程必须可见；发送、改权限、审批承诺、跨项目写入等高风险操作必须停在确认门或交由有权限的人处理。审计记录和撤回检查点是这条路径的必要补充，而不是事后的替代品。
3. 事实证据：一份周报从草稿到客户邮箱，在哪里必须停下
小陈让工作台生成 Q3 项目周报。系统读取已授权的项目台账并生成 PPT 草稿，这是低风险动作，可直接执行并记录版本。随后有人点击“发送给客户”。入口闸发现目标对象在项目外、动作涉及对外分享、且当前任务卡写有“不可外发”，因此不执行发送，而是在侧栏展示拦截原因、拟发送文件版本和可选处置：仅保存内部草稿、申请项目负责人确认，或改为内部项目组分享。
4. 执行结论：将权限判断、人工确认、审计与撤回串成一次受控动作
平台负责维护角色、项目范围与风险策略，工作台负责在每个动作前带入 Task ID、对象和影响范围并调用策略。低风险动作执行后写入审计；高风险动作先展示变更预览和确认人；违规动作不发送、不写入，并留下拦截记录。对可恢复操作，系统在写入前保存检查点，使小陈可以从侧栏查看差异并撤回到上一版本。
发起动作时先绑定人、项目、对象、范围和 Task ID；策略判断低风险直接执行、高风险进入确认门、越权动作直接拦截；无论执行还是拦截均保留审计；可恢复写入在执行前创建检查点，供授权用户核对差异并撤回。- 每个写入或分享动作是否都能识别发起人、项目范围、目标对象、Task ID 和影响等级？
- 外发、改权限、跨项目写入和对外承诺是否在执行前进入确认门或被直接拦截？
- 拦截页面是否说明原因、影响和可行替代路径，而不是只给出模糊错误提示？
- 执行、确认、拒绝和撤回是否具有可查询的版本、操作者与时间记录？
思考：权限不是给 AI 设障，而是让每一次自动化都能在正确的责任范围内发生
真正可用的控制不应把用户困在审批流程里，而要让低风险工作顺畅推进，把高风险后果提前变成清晰可见的选择。能解释、能确认、能追溯、能撤回，用户才愿意把更多实际工作交给工作台。
Part 10 · 共作面：AI 推进，人授权，结果可验收
10 / 共作AI 负责整理和推进，人负责授权与例外判断。共作面的关键不是谁点得更多，而是每一步的状态、证据、责任和验收结果都能被看见和接管。
1. 共作背景：自动化越深入，人的责任越需要被明确保留
当工作台能自动提炼纪要、创建候选任务、标记逾期和生成周报草稿时，小陈不应再重复做机械搬运；但他仍必须对会议口径、对外分享、权限变更和例外处置负责。若系统把所有步骤都藏在后台，人无法知道任务为什么被推进或停住；若系统又要求人逐项确认，自动化只是在增加新的点击成本。
共作面要把责任按风险和判断能力分配：AI 处理规则明确、可撤回、可校验的整理与推进；人处理需要业务取舍、外部承诺和权限授权的事项；两者在不确定、冲突、异常和验收节点共同完成判断。用户看到的不是一串对话，而是当前任务的阶段、依据、建议动作、责任人和下一处可接管点。
2. 核心问题：为什么“全自动”与“全手动确认”都会让协作失效
全自动的风险在于，系统可能把不完整的事实写入台账、把草稿发给不该收到的人，或在依赖缺失时静默继续；全手动的风险则在于，小陈需要反复确认格式化、摘要、状态同步等低价值动作，最终为了节省时间而跳过真正重要的检查。两种极端都让责任边界模糊。
共作面应当把决定是否继续所需的信息放到同一个节点：AI 展示来源、变更预览、规则校验和风险等级；人可以接受建议、修改字段、旁路某一步、接管执行或升级给更高权限的人。无论选择哪条路径，系统都记录谁基于什么证据做了什么决定，并让任务回到可继续推进的状态。
| 类型 | 示例 | 工作台行为 |
|---|---|---|
| 低风险 | 套模板出纪要草稿、标逾期、侧栏汇总 | 自动推进，进度可见 |
| 高风险 | 外发、改权限、对外承诺、群发 | 停自动，等人点确认门 |
小陈每场会后勾选：内容准确 · 数据正确 · 格式合规 · 责任清晰 · 任务可继续
3. 事实证据：安全复核阻塞时，AI 推进到哪里，人从哪里接管
认证安全复核任务已逾期，AI 自动汇集了 Task ID、会议来源、最后一次提醒、外部依赖和对集成测试的影响，并将状态标记为“等待决策”。它不会擅自修改发布日期，也不会向客户发送说明。小陈在共作面上看到两个建议：协调安全团队加急，或将集成测试顺延两天。他选择后者，补充原因并提交项目经理确认；确认通过后，工作台更新台账、重排日历提醒并刷新周报风险卡。
这一过程里，AI 的“推进”是可暂停的：当规则不够、证据冲突或影响超出授权时，它把问题带到共作节点，而不是替人决策。人的“授权”也不是盲点确认：小陈能看到建议背后的来源、影响范围与替代方案，并且每次选择都会变成后续验收可追溯的记录。
4. 执行结论：用可见状态组织人机协作，用业务结果而非体验感受验收
每一项任务都应公开它处于自动推进、等待确认、人工接管、升级中还是已完成，并显示当前负责人、阻塞原因和证据链接。AI 完成低风险动作后仍要通过字段、权限和来源校验；人工做出高风险决定后仍要写回任务与审计。最终验收看的是任务是否闭环、提醒是否按 SLA 送达、数据是否可追溯、风险是否被处置，而不是“聊天是否顺畅”。
任务进入后先按规则和风险分流；低风险由 AI 推进并自动校验；不确定或高风险事项进入共作节点，呈现证据、影响和建议；人选择确认、修正、接管或升级；所有处置回写任务和审计；以闭环率、提醒 SLA、数据来源和风险处置结果验收。- 用户是否能随时看见任务目前卡在哪、谁负责、依据是什么，以及下一步可采取哪些动作？
- 低风险动作是否自动推进但仍保留来源、权限与字段校验，而非成为不可解释的黑盒？
- 高风险、冲突或异常事项是否能由人确认、修正、接管或升级，并记录选择理由？
- 验收是否落到任务闭环、提醒 SLA、台账一致性和风险处置，而非只评价对话体验？
思考：人机共作的成熟标志，不是 AI 替人做得更多，而是人在关键时刻能更快地做出有依据的决定
把人留在循环中不等于把人拖回琐碎操作。好的共作面让机器先完成规则明确的部分，并在需要业务判断时交付完整上下文，使人的注意力真正用于选择、授权和承担责任。
Part 11 · 实战：一场评审会变成一套成果
11 / 闭环切片这一节把前面的规则落到一场真实评审会：从输入资料到纪要、台账、提醒和周报，六步各留一个可继续消费的产物，缺口则回到对应步骤修复。
1. 实战背景：一场会的交付，不该在“纪要已生成”时停止
周一上午，小陈主持 Q3 项目评审。会议里既有已确认的认证排期，也有等待安全团队回复的未决项，还暴露了两条临期任务。传统做法是在会后生成纪要、把它发到群里，然后由小陈分别打开台账、日历和 PPT 继续搬运。问题不在某一个工具不够好，而在每次工具切换都要重新判断同一件事是否确认、由谁负责、已经推进到哪里。
工作台将这一场会作为一个任务切片：会议转写、项目台账和任务卡先绑定同一 Task ID；每一步只在条件满足时将产物交给下一步；任何未决、缺字段或权限不足都不伪装为完成，而是带着原因回到对应节点。目标不是一次生成四个文件，而是让会议事实持续转化为可执行、可跟进、可汇报的工作状态。
2. 核心问题：六步都“跑过”为什么仍可能没有交付
如果纪要把未决写成决策，台账把没有负责人的事项标为已分派，日历提醒没有对应 Task ID，周报的逾期数字又来自手工筛选，那么六步虽然都有输出，链路却在每一处留下不可追溯的断点。下一次会议一开始，团队仍要重新确认事实、查找责任人和对齐版本。
因此，这套切片不是顺序播放的演示脚本，而是一组放行条件。前一步产物只有通过来源、字段、权限和确认校验，才会成为下一步输入；否则系统将任务停在当前步骤，明确展示缺口、补充人和失败证据。所谓“打回”不是失败，而是防止不可靠内容被带入后续协作。
| 放行 | 打回 |
|---|---|
| 五要素任务卡齐全；纪要五段过校验；台账无「已分派但无人」；周报数字可点回台账；高危未静默外发 | 空白对话开工；未决写入决策；图表手填；下一步无人名却已分享 |
【工作台蓝图产物】
1. 场景×能力矩阵（会议/台账/协同/周报 × 读懂/加工/执行/交付）
2. 任务五要素入口模板
3. 共作面：指派 · 确认 · 旁路 · 接管 · 升级包
4. 「会议→周报」六步切片验收清单
终点：不是生成文件，而是工作真正向前推进。3. 事实证据：小陈如何在一场评审会中交付一套可继续工作的成果
小陈创建“Q3 项目评审会”任务后，上传录音、会议材料和当前 Tasks 表。工作台先识别出决策、待办、风险与未决；其中“认证模块下周上线”因安全复核未完成被标为未决，而不是进入决策。确认后的待办写入台账候选：缺少负责人的一条停在待补全，其余任务生成日历提醒。周五生成周报时，系统只汇总已确认任务的实时状态，并将安全复核阻塞列入风险页；小陈确认内部口径后分享给项目组。
这场会最终留下四类可消费产物：带来源和版本的 Word 纪要、可回答“谁该跟进”的 Excel 台账、带 Task ID 的日历任务，以及能回溯数据与行动负责人的 PPT 周报。它们不是四份独立附件，而是同一会议任务在不同工作节点的状态投影。
4. 执行结论：以交付切片组织开工，用放行与回流守住质量
团队可以把“会议到周报”固化为每次开会前的运行模板：先检查任务卡和输入资料，会议后先确认纪要事实，再写入任务和台账，按规则创建提醒，最后从实时台账生成周报。每个节点都定义产物、放行条件、责任人和失败回流点，使任何异常都能被定位到一处而不是靠整条链重做。
开工：绑定会议资料、项目台账和任务卡；理解：提取并确认事实、决策、待办、未决；落地：纪要、台账和日历只消费通过校验的内容；汇总：周报只读取实时且可回溯的任务状态；验收：核对事实、权限、责任和下一步；失败：按缺口回流到纪要、台账或任务节点修复。- 会议资料、任务卡、纪要、台账、提醒和周报是否使用同一 Task ID 串联？
- 未决事项、缺负责人、缺截止或权限不足时，是否停在对应节点，而非继续形成“已完成”产物？
- Word、Excel、日历和 PPT 是否都能回到相同的会议来源、任务状态与确认记录？
- 分享后，下一周能否直接从台账、提醒与周报继续推进，而无需重新整理本场会议？
思考：真正可复制的不是一套“生成文件”的技巧，而是一种让每场会都能继续推动工作的交付结构
一次性材料很容易做得漂亮，却很难为下一个人、下一次会议和下一周工作留下可靠基础。把会议拆成有输入、有产物、有放行、有回流的切片，团队才能不断复用同一条链，而不必在每次协作中重新发明流程。
结语 · 五层跑通之后
收束五层跑通后，数字员工不再停在后台或聊天窗口，而是在一个可见、可控、可验收的工作现场中，把会议事实持续推进为下一周仍能继续消费的结果。
1. 收束背景：能力已经具备，关键是让能力进入人的真实工作现场
在前一篇中，项目协同数字员工已经拥有岗位、知识、流程、权限和指标；但小陈仍需要在会议记录、聊天、Word、Excel、日历和 PPT 之间搬运信息。问题从来不是 Agent 会不会生成纪要，而是生成后的内容能否带着来源、状态和责任自然进入下一步工作。
本篇完成的五层，不是五个独立功能：工作台提供同一任务现场，任务卡明确输入与验收，Word 固定会议事实，Excel 持续记录状态与跟进，协同与权限让动作在正确范围内发生，人机共作则让例外判断和最终责任留在可见节点。它们共同服务“会议到周报”这条真实工作链。
2. 核心问题：缺少任意一层，为什么工作仍会在最后一公里断开
只有统一入口，没有任务契约，用户仍会用“帮我做周报”触发猜测；只有纪要生成，没有台账和协同，待办仍会停在文档中；只有自动写入，没有权限闸和人工接管，错误可能被放大为对外风险；只有漂亮周报，没有来源与负责人，下一步依然无人执行。每一层单独看都“有用”，却不足以构成可靠交付。
真正跑通的标志不是页面更多、模型更强或自动化更多，而是工作对象在跨工具、跨时间、跨责任人流动时，仍然保留同一份事实、同一个 Task ID、明确的状态和可追溯的证据。任何层出现缺口，都能在对应节点停下、修复并继续，而不是整条链重做。
3. 运行证据：小陈的工作从五窗口搬运，变成一条可继续消费的链
现在，小陈从“Q3 项目评审会”任务进入：资料、录音、台账和模板在同一现场；纪要中的决策、待办、风险和未决均可回到来源；确认后的任务写入台账并创建日历提醒；逾期或阻塞被归入可处理队列；周报从实时任务状态生成，并在分享前完成口径和权限确认。下一次会议不必从聊天记录重新找事实，而是直接消费已有任务、风险和周报结果。
图中的回流很重要。工作台不是一条只能向前的自动流水线：缺字段回到任务与纪要补齐，阻塞进入共作与升级，周报发现数据或责任缺口则回到事实和台账修正。正因为每个问题都有明确归宿，小陈才不必推倒重来，也不会把不确定内容带到下一位同事面前。
4. 最终结论：将“完成一次生成”升级为“持续推进一项工作”
下一次开会前，团队可以用这套工作台模板检查任务卡、资料范围和权限；会后用六步切片推进纪要、台账、提醒和周报；在不确定或高风险节点由人授权、接管或升级；最后用任务闭环、提醒 SLA、数据可追溯和风险处置结果验收。AI 在其中负责加速执行，人负责定义边界和承担责任。
先建立同一任务现场；再用任务契约锁定目标、依据和验收；将会议事实沉淀为纪要、任务与台账；按风险推进提醒、升级和写入；在权限与共作节点保留人的判断；以可回溯的周报和可继续推进的任务状态完成交付。- 用户能否在一个任务中看到资料、状态、证据、风险、权限提示和下一步，而无需在多个窗口重新拼接？
- 纪要、台账、日历和周报是否共享同一 Task ID，并能在任意时刻回到会议来源与确认记录？
- 缺字段、未决、逾期、越权或高风险动作是否有可见阻塞、人工处置和失败回流，而非静默继续？
- 下一次会议和下一周工作能否直接消费本次的任务与产物，而不是从一次性附件重新开始？
思考：工作台的终点不是替人完成更多动作，而是让一项工作在时间、工具和责任人变化之后仍然保持连续
当资料、判断、执行和交付都围绕同一任务留下证据，数字员工才不再是后台的功能集合，而会成为人实际工作中的可靠协作者。真正值得被复制的，是这种能让工作不断向前的系统结构。
AI Agent
01 用好 AI 编程 · 02 吃透 AI Agent · 03 做成 Agent 产品 · 04 建成数字员工平台 · 05 跑通 AI 办公工作台（本篇）
Last updated: 2026-08-07 · 案例线加厚