把一个 AI 想法写成可验证的任务简报

“给这里加上 AI”不是任务。它没有说明谁的工作会发生变化、系统会拿到什么，以及怎样才算真的有用。一页任务简报的价值，是让设计、工程和业务在谈实现方案之前，先对齐同一件可以测试的工作。

一页简报只回答六件事

谁在什么时刻需要帮助

不要写“所有员工”。写“每周一整理待办之前的客服主管”，因为这个时刻能够被观察，也能找到真实样例。

系统会收到什么输入

列出资料格式、数量、来源、更新时间、权限和已知缺口。模型不会自动补齐没有进入链路的信息。

最终必须交付什么对象

可以是一张排序表、一封待审核回复、一组结构化字段，或者带来源的比较。避免“提供洞察”“提升效率”这类无法直接检查的目标。

怎样判断结果合格

写出必备字段、允许引用的来源、可以接受的遗漏、语气和不确定性表达。可检查的证据比“高质量”更有用。

什么事情绝对不能做

把禁止动作和停止信号写出来。边界不是限制创意，而是让一个更小、更安全的任务成为可能。

失败后交给谁

说明谁会收到停止的案例、需要看到哪些上下文，以及怎样不用从头开始就能继续工作。

完整样例：产品反馈周报

**使用者与时刻：**产品经理准备每周需求排序会。
**输入：**本周已标注的用户反馈、版本说明和上一期周报。
**输出：**五个重复问题，每项包含数量、代表性原话、受影响流程和原始链接。
**验收：**每条原话都能打开原记录；无法稳定归类的内容明确标记；系统不能自行决定优先级。
**边界：**可以归组和摘要，不可以替团队决定做什么。
**接手：**产品经理检查未归组内容并编辑最终周报。

这份简报说明，任务的重点不只是“总结”。来源可追溯和优先级边界同样决定结果能不能使用。

第二个样例：续约会议准备

**使用者与时刻：**客户负责人在续约会议前半小时。
**输入：**允许访问的 CRM 记录、未解决工单和当前合同摘要。
**输出：**一页准备材料，列出会议目标、未完成承诺和需要确认的问题。
**验收：**每项承诺带日期和来源；缺失信息以问题呈现，不能猜测。
**边界：**不能建议价格，也不能引用其他客户的记录。
**接手：**记录冲突时同时展示两个版本，由客户负责人判断。

这份简报故意不写什么

它不选择模型、架构或供应商。团队先同意任务和证据，再选择实现方法。反过来做，很容易变成维护某个工具，而不是验证用户是否得到帮助。

从真实材料开始填写，而不是从愿望开始

先找一位实际完成任务的人，选取最近发生的三次工作：一次普通、一次麻烦、一次最终没有完成。让对方按当时顺序讲清输入从哪里来、做了哪些判断、把结果交给谁。只有这些事实写清后，再填写六行简报。

建议按下面的顺序评审，而不是从标题开始逐字润色：

**先核对输出对象。**团队能否指着一个具体结果说“就是这份东西”？
**再核对验收证据。**谁检查哪些字段，多久能发现错误？
**然后核对输入。**生产环境真的拿得到这些资料吗，版本和权限是否明确？
**最后核对边界与接手。**出现什么情况必须停止，接手者能否从当前状态继续？

一次简报评审只解决任务定义，不讨论模型参数。产品负责人负责使用时刻与业务边界，实际操作者提供案例，工程人员指出输入和交接是否可实现，风险负责人确认数据与动作限制。会议结束时若仍有争议，把争议写成待验证问题，并指定证据负责人。

简报写坏时会出现的四个信号

信号	真正缺少什么	下一步修正
输出仍叫“洞察”或“助手”	可检查的交付对象	放入一份真实好结果，描述它的结构
验收只有“准确、专业”	复核动作与拒收条件	让两个人独立判同一案例，记录分歧
输入写“公司知识库”	具体来源、版本和权限	列出文件、字段、负责人和更新时间
接手方式是“转人工”	人工收到的材料和继续位置	画出停止时的状态包与队列入口

如果一份简报需要不断口头解释，说明关键判断还在作者脑中。真正可用的简报应让没有参加讨论的人也能准备案例、运行试验，并指出哪里不清楚。

常见问题：AI 任务简报怎样才算写完？

简报应该多长？

长度不是目标。一页通常足以容纳一个工作单元；如果为了说清任务必须写多个使用者、互不相关的输入和几种不同结果，应拆成多份简报。宁可让多份简报共享背景，也不要把不同验收标准塞进同一页。

能不能先写 Prompt，再补简报？

可以把已有 Prompt 当作访谈材料，但不要把它当作任务定义。Prompt 往往混合了输入、规则、格式和补救措施。把这些内容还原到六行简报后，团队才能判断问题来自任务、上下文还是实现。

谁应该批准简报？

至少需要任务负责人和实际接手失败案例的人确认。若输入包含受限资料或输出会触发外部动作，还需要对应的数据、风险或系统负责人确认边界。批准的是这项任务和试验范围，不是对未来所有自动化的永久授权。

不适用边界

一份简报只描述一个可重复的工作单元。如果它同时需要多位负责人、互不相关的输入和多个不可逆动作，就拆成几份。越小的任务越容易测试，也越容易停止。