Spec 驱动交付：用 spec tasks checklist 把 AI Agent 变成工程

当团队把 AI Agent 当成“会说话的脚本”，常见结果是：需求口径漂移、输出不可复现、上线后难回归。Spec 驱动的价值在于：把交付物从“对话记录”变成“可验收的变更”。

TL;DR

• spec 负责“为什么与改什么”，tasks 负责“按顺序怎么做”，checklist 负责“怎么验收”。
• Agent 最擅长生成候选方案，但工程交付需要明确边界、验收与回归门禁。
• 协议与生态也在朝“工程化”靠拢：MCP 规范持续补强治理与可维护性要素，并引入 tasks 等能力讨论背景[1]。

1. Spec 的最小结构（建议默认）

你不需要写很长的 spec，但建议至少包含：

• Why：问题与机会（1-2 句）
• What Changes：变更列表（带 breaking 标记）
• Impact：影响范围（关键文件/系统）
• Requirements：新增/修改/删除的可验证需求（WHEN/THEN）

核心标准只有一个：读完 spec 能写出验收用例。

2. tasks.md：把“想做什么”变成可执行序列

tasks 的写法要满足三个条件：

• 小：每个 task 都能在有限范围内完成并验证
• 顺序：依赖关系明确（先做什么再做什么）
• 可见：每个 task 完成后有用户可见的进展（哪怕只是新增一篇文章或新增一个接口）

一些协议/生态也在把“任务”当成一等公民。MCP 规范 2025-11-25 提到对 tasks 的实验性支持方向，用于跟踪可持续的请求与延迟结果获取[1]。即使你不使用 MCP，这类思路也很适合用于 Agent 工作流的工程化表达。

3. checklist.md：把验收写成“能打勾的句子”

checklist 的要点：

• 每条都是可验证的陈述（不是愿望）
• 尽量指向具体行为或输出（页面可打开、接口返回、测试通过、日志无报错）

如果你的系统涉及工具调用与长链路执行，可观测性也应该被写进 checklist。Google Cloud 的 MCP release notes 里把工具失败与延迟原因纳入 Trace 视角，说明“能定位问题”已经成为工具生态的基本诉求[2]。

4. Spec 驱动如何降低“幻觉成本”

很多人把幻觉当“模型问题”，但工程上可以把它转成“流程问题”：

• spec 写清范围，避免 Agent 自行扩展
• tasks 拆小，减少一次性生成大改动
• checklist 强制回归，避免“看起来对”但不可验证

另外，结构化输出与 schema 约束也很重要。MCP 规范在 changelog 中持续补充工具命名与 schema 等指导，目的是让“工具接口”更可校验、更可维护[1][3]。

5. 一个可复制的最小工作流（建议）

1. 写 spec：定边界与验收口径
2. 写 tasks：拆成 3-7 个可验证任务
3. 写 checklist：验收点可打勾
4. 执行：每做完一个 task 就勾选并回归
5. 留痕：关键决策与来源可追溯（链接、文档、变更记录）

如果你的 Agent 体系包含“记忆写入/工具调用”，建议把“安全回归”也纳入 checklist。OWASP 相关项目强调记忆投毒与运行时防护，提醒我们把可控性写入流程[4]。

近30天动态（节选）

• MCP 规范与生态的“工程化”趋势明显：授权、治理、schema 默认值与 tasks 能力的讨论不断推进。更多见：近30天动态总览

参考与延伸阅读

• [1] MCP Specification 2025-11-25 changelog https://modelcontextprotocol.io/specification/2025-11-25/changelog.md
• [2] Google Cloud MCP servers release notes https://docs.cloud.google.com/mcp/release-notes
• [3] MCP Specification 2025-06-18 changelog https://modelcontextprotocol.io/specification/2025-06-18/changelog
• [4] OWASP：Agent Memory Guard https://owasp.org/www-project-agent-memory-guard/
• [5] AOS Specification（包含 memory/tool 相关的可观测字段定义线索）https://aos.owasp.org/spec/instrument/specification/