用七项任务定义收敛 AI 系统需求

「AI 能不能处理退货邮件」还不是一个系统需求。原文作者给出的办法是：先用七个栏目写清 AI 的工作，包括何时启动、读取什么、事实以谁为准、产出什么、送到哪里、禁止做什么，以及异常由谁接手。

它值得读的地方，是把讨论从模型能力拉回了业务流程。对于准备接入 AI 的小团队，这张一屏能看完的工作说明，可以提前暴露数据冲突、权限边界和人工接管的问题。不过，填满七栏只是需求起点，还不能证明系统已经可靠。

先把一次提问改成可以反复执行的工作

「总结这份合同」是一次提问。每次执行前，都需要有人决定拿哪份合同、何时提问，以及如何处理结果。

作者把它改成了一项持续工作：已签署合同进入指定文件夹后，提取合同双方、开始日期、续约日期和通知期限这四个字段，写入续约表格，并列出无法找到任一字段的合同。

区别就在于，第二种描述能交给别人接着做，也能据此设计程序。作者要求在开发前写清七栏：

• Trigger：什么事件启动任务，例如邮件到达、文件落盘、定时触发或新增一行记录。
• Input：具体读取什么，例如邮件正文，以及主题中可能存在的订单号。
• Source of truth：每个事实从哪里取，不同来源冲突时听谁的。
• Output：生成回复、表格行、报告、标记，还是文件。
• Destination：结果进入客户邮箱、待审核草稿、表格，还是处理队列。
• Never：哪些操作不能自主执行，遇到这些情况改做什么。
• Exception owner：明确由谁处理被搁置的任务，以及多久查看一次。

作者认为，只要有一栏空着，需求就仍有决定没做完。这里真正有用的是定位缺口：不知道异常谁管，就先解决责任归属；不知道结果送哪里，就先确定下游流程。

数据听谁的，要在调用模型前决定

原文用一家小型分销企业更新退货表格的场景做示范。这是教学用的虚构案例，不是作者交付效果的实测报告。

新邮件到达 returns@ 后，系统读取正文、主题或正文里的订单号，以及附件中的退货表单。订单和客户信息以商店系统为准，退货原因以退货表单为准。如果邮件中的订单信息与商店系统冲突，商店系统优先。

结果是每笔退货写一行，包含订单号、日期、商品、原因，以及状态 unconfirmed，放进 Returns 表格的 New 标签页。

作者最看重的是 Source of truth。邮件、业务系统和附件可能各自提供一部分信息，也可能互相矛盾。「检查客户资料」并没有解决冲突，只是把选择推迟给了执行系统。

对程序员来说，这一栏应当成为明确的数据规则：哪些字段必须查询业务系统，哪些允许从非结构化文本提取，冲突怎样处理。能由业务规则决定的优先级，不必留给模型临场判断。

原文没有展开字段级校验和冲突记录如何实现，这部分仍需要团队补齐。

禁止操作之后，必须有一条可走的路

「不要做危险的事」无法直接指导执行。作者要求每条禁止规则都配一个替代动作：

退货系统不能批准退款，就把记录标成 refund to review；商店系统里查不到订单号，就把邮件列给人工处理；字段无法读取，就留空并说明原因，不能猜一个答案填上去。

原文还给出更强的限制方式：不给系统支付权限，它就无法错误付款。提示词可以表达要求，访问权限则能直接约束可执行的动作。

结果状态也不能只有成功和失败。作者提出三种回答：

• done：任务完成。
• set aside：任务被搁置，并用一句话解释原因。
• could not check：系统无法完成检查。

「没查到」和「没能查」必须分开。

前者可以是有效查询得到的空结果，后者可能是文档无法读取或服务故障。如果混在一起，一次中断就可能被包装成让人放心的「没有问题」。

这些任务最终还要有人接。示例指定运营协调员每天在 10:00 和 15:00 查看异常。这个安排把责任人和处理频率都写出来了，避免「转人工」只是流程图上的终点。

我的判断

我认同这套方法优先解决流程边界的思路。与直接写一大段提示词相比，七栏更容易让业务、开发和审核者确认：系统到底负责到哪一步。

但「七栏填满就能构建」说得偏满。它能说明任务已经有了轮廓，不能保证数据可访问、附件可解析、重复事件不会重复写入，也不能回答系统能达到多高的准确率。作者没有给出对照实验、错误率或节省工时的数据，这套方法应当视为需求梳理经验。

它与常见的需求文档、验收标准也有不少重合。优势在于短，适合启动一个范围明确的自动化任务；涉及多个系统和复杂审批时，一屏说明仍需配合详细设计。

作者建议先让 AI 完成最后一步之前的工作：回复留在草稿里，表格行标成待确认。经过人工审核后，再按任务类别逐步开放自主完成的权限。这个顺序合理，但原文没有定义审核多久、什么记录才算可信，团队需要自己制定放行标准。

能拿来做什么

• 从每周重复发生的一项工作开始，用七栏写出完整说明。可以选合同字段提取、退货邮件整理或回复草稿生成，先确定输入和结果去向。
• 用 Node 接入邮件或文件事件前，先逐项明确字段来源和冲突规则，并把「查无记录」与「查询失败」设计成不同结果。
• 在 AI 编程助手生成流程代码前，把禁止动作和替代动作一起提供给它；涉及退款等操作时，同时检查实际授予的接口权限。
• 首次上线采用草稿或待确认状态，指定异常负责人和检查频率，再依据各类任务的审核记录决定哪些可以自动完成。