AI写周报总出错？Grok Bot材料齐全却写错数字的根因

材料全给了，AI写的周报为什么还是错？B站UP主「马上花生」在Grok Bot系列第16课中，用一份模拟需求进展表和一封模拟邮件，还原了一个典型办公场景：进展表写完成8项，邮件却说有2项待验收，周报到底该写几项？问题的根源不在材料够不够，而在状态定义和统计口径有没有对齐。

核心冲突：开发完成≠验收通过

课程设计了一个刻意制造的矛盾场景。进展表列了8条已完成项，模拟邮件更新其中2条仍在待验收状态。如果直接做加减法，6项验收通过、2项待验收，似乎答案很清楚。但UP主指出，这个"8-2=6"的推理本身就是陷阱。

关键在于：开发完成描述的是开发状态，验收描述的是验收确认。两个来源可能同时成立——一项任务可以既处于"开发已完成"状态，又处于"验收待确认"状态。如果直接把这两个数字相加成16项，或者只留一个看起来漂亮的完成数，都是对状态语义的误读。

正确的做法是先回到需求文档中"开发完成"和"验收"各自的定义，看变化发生在哪一项、谁确认、什么时候确认。如果材料之间没有权威顺序或明确的更新关系，就应该把它列为待确认问题，而不是让Bot随便挑一个数字。

在项目管理与软件工程中，任务状态机是一套约定每个任务从创建到关闭所经历的阶段及允许迁移的模型。常见的核心状态包括：待办（To Do）、进行中（In Progress）、开发完成（Dev Done / Code Complete）、提测、验收中、已验收（Accepted / Done）、已关闭。关键点在于，状态图是有向而非可任意合并的："开发完成"与"验收通过"是两个节点，中间通常还夹着提测、缺陷修复、验收评审。因此，一个任务可以同时满足"开发已完成"和"验收待确认"，两者并非互斥事件。把两组数字做减法或相加，本质上是把状态机里的两个不同节点当成了同一个计数口径，这在统计上会产生"双重计数"或"漏计"。理解状态机模型，就能明白为什么回原始定义、确认谁能推动状态迁移（通常是验收人而非开发者），是避免周报数字出错的前置步骤。

对表不是做减法：三个前置条件

UP主强调，"对表"远不只是做减法。在确认两组数字是否一致之前，必须核实三个条件：

记录没有重复。同一项任务是否在进展表和邮件中出现了两次，导致统计翻倍。

状态定义一致。进展表中的"完成"和邮件中的"已完成"是否是同一个含义，还是分属开发阶段和验收阶段。

统计范围确实相同。两个来源的时间节点、任务粒度、统计单位是否一致。课程特意规定统计截止到10月13日18点上海时区，统计单位是任务项，节点之后的新信息必须另注明，不能混进本次统计。

课程还故意制造了一个更棘手的情况：一条待验收项缺负责人，另一条缺预计验收日期。对表时应该写"待确认问题清单"——问谁负责、何时确认——而不是沿用上周的人名，或者自己拆一个期限填进去。缺字段并不妨碍先交可确认的部分，只要把已知、推断和未决项分开，读者就能清楚判断。

**统计口径（metric definition）**指的是一个数字被统计时所遵循的完整规则，包括：统计对象（哪些任务纳入）、时间窗口（截止到哪一刻）、粒度（按任务项、子任务还是工时）、单位、数据来源优先级以及去重规则。同一件事在两组材料里对不上，往往不是数据本身有错，而是口径不同——比如进展表按"开发完成日"归档，邮件按"验收确认日"更新，两者的时间基准天然不一致。解决口径冲突的通用做法是先建立"单一事实来源"（single source of truth）：明确哪份材料在哪个字段上有权威性，其次对时间、粒度、去重规则逐条对齐。若仍无法对齐，就应将差异登记为待确认项，而非由AI自行选择更"好看"的数字。这套方法在财务报表对账、数据仓库建设、OKR复盘等场景同样适用。

产物边界：草稿停在草稿，不代别人承诺

这一课在任务规则设计上划了明确的边界。来源与待确认栏不修改原件，不发送草稿或日历邀请，交付的是CSV表格和对表周报，而非Excel公式文件。课程没有生成工作簿，就不把它叫"已验证的Excel文件"。

每份产物都必须能打开，重要事实能回到材料章节溯源，缺口留在对应位置。文件卡片出现只是交回的开始，还要看实际内容，不能只检查下载链接存在。

草稿的停点同样关键。写出邮件不等于已经给出了外发指令。课程参考没有实际返回卡片或发送记录，所以文件明确叫"教师参考"，不伪造已送达截图。收件人未知就标注待确认，检查语气、事实与日期后再决定是否发送。

人工在环（human-in-the-loop）是指自动化流程在关键节点必须交由人类确认后才能继续的机制。在AI办公场景中，它体现为"生成"与"发送"分离：AI可以起草邮件、生成表格、准备日历邀约，但真正触发发送、写入共享系统或对外承诺的动作，需要明确的人工授权。这是因为发送类动作具有不可撤销性和代理责任——一旦发出，即代表组织对外的正式承诺，出错代价远高于草稿阶段。因此，设计AI工作流时应把操作分为可逆（读取、编辑、另存）与不可逆（发送、删除、写入、邀请）两类，后者一律设置确认门。同时，AI不应伪造"已送达""已确认"等状态证据，缺口应保留在对应字段供人工补全。这条原则不仅是技术规范，也是责任边界：草稿的错误由人承担，误发的后果则由授权人承担。

权限与授权：不开放真实邮箱也能练

UP主特别说明，公开附件练习无需开放真实邮箱权限。课程只使用自编需求进展表和模拟邮件，没有连接真实邮箱或日历。

但课程同时给出了真实任务的授权规则：连接器选择之后必须配置岗位名称，岗位名称不会自动带来所有邮箱和日历访问权限。真实任务要先核对身份认证与读取范围，空搜索标位验证，写入、发送或邀请按具体授权继续。

这套规则的核心逻辑是：来源可读、口径明确、缺口保留、产物可查、草稿停点。把办公任务当成一张验收表来管理，开发者和办公人员都能用它判断结果到底做到了哪一步。

**最小权限原则（principle of least privilege）**要求系统或账号只被授予完成当前任务所必需的最小访问范围，不多给一分。在连接器与Bot配置场景中，这意味着即使选择了某类连接器，也不等于自动获得该账号下所有邮箱、日历、文件夹的读写权限。正确流程是：先确认身份认证方式（OAuth、服务账号等），再逐项指定读取范围（如只读某几个标签、某个共享日历），写入与发送权限单独申请并单独审计。空搜索或无关关键字搜索可用于验证"当前实际能读到什么"，从而发现权限过度或不足。对公开练习而言，使用自编数据即可完成绝大部分方法训练，无需触碰真实账号；只有在真实任务中才需要按需、按范围、按时间授予，并在任务结束后回收。这既是安全实践，也符合数据合规（如GDPR、个人信息保护法）对数据最小化的要求。

复用方法：变化的是事实，不变的是流程

如果负责人或日期补齐了，要写明新资料替代哪一项，修订同一份产物再核对受影响的数字和口径。不是把标题日期换掉就算完成。下一轮如果没有当前材料，就交缺输入说明，不拿这周的6.2冒充下周结果。

方法可以复用，但事实每次都要重查。下一课UP主计划把陈述岗位复用给自己、别人或团队，区分复制模板和团队Bot的差异——方法可以带过去，但登录共享范围和成员权限仍要重新核对。