第二篇:需求不是一次性文档:AI 团队如何管理会变的规格

周二下午，产品补了一句话：“老客户不必再重新授权。”

对人来说，这像是一句小补充。对一个已经分配给三个 Agent 的功能来说，它可能同时改变了迁移脚本、鉴权逻辑、验收用例、灰度策略和客服话术。

最糟的情况并不是有人改错了一行代码。

最糟的情况是，每个人都在正确地执行自己手里的旧版本。

Agent 会忠实地沿着上下文向前走。它不知道 Slack 里的新结论，不会自动判断设计稿旁边的一句备注是否推翻了昨天的任务拆分。只要团队没把变化写成可追踪的产物，旧意图就会以极高效率继续扩散。

01PART规格不是 PRD 的新名字

这里说的规格，不是要求产品经理写一份更长的 PRD，也不是为了让仓库多一堆 Markdown。

它至少要回答四个可判定的问题：

1. 用户或系统行为要变成什么样？
2. 哪些边界不能被改变？
3. 什么证据说明这次变更成功？
4. 如果假设变化，哪些已完成工作需要重新判断？

这四件事合起来，才像一份“意图合同”。

合同的重点不在措辞漂亮，而在它可被不同角色使用：产品能检查是否仍符合目标；工程能据此选择实现；测试能构造反例；审查者能判断这次 PR 是否偏题；运行负责人能知道上线该观察什么。

GitHub Spec Kit 的当前流程把这种链条明确拆成 specify → plan → tasks → implement → converge。它的价值不在于命令本身，而是提醒我们：规格、实现计划和任务列表是不同层的产物，彼此发生冲突时需要被发现。

截至 2026-10-21，Spec Kit 的 converge 被设计为跨规格、计划、任务与当前代码做一致性检查；发现缺口时追加可追溯任务，再回到实现。它并不声称能自动证明业务价值，更不能替代对需求本身的判断。

02PART一次变化，至少经过五个地方

很多团队把“需求变更”理解成改一下标题或补一条验收标准。

AI 参与后，变化更像在一张网里传导。

业务决定  ↓规格：行为、例外、验收条件  ↓计划：方案、接口、迁移与风险  ↓任务：谁做什么、顺序和依赖  ↓实现与测试：代码、测试数据、回归用例  ↓PR / 发布：审查范围、灰度、监控与回滚

“只改代码”通常是最后一步，不是第一步。

例如“老客户不必重新授权”可能意味着：

• • 规格新增一个兼容性例外；
• • 计划要确认旧 token 的识别方式；
• • 任务要多一条数据迁移或回退策略；
• • 测试要补“旧客户、旧 token、新版本”的组合；
• • 发布要观测登录失败率和续期异常；
• • 客服或运营要知道这次没有触发重新授权是预期行为。

少了其中一个，仍可能写出“代码正确但交付错误”的结果。

03PART收敛不是自动宣布胜利

规格驱动工具常被误解成一种魔法：有了 spec.md、plan.md 和 tasks.md，Agent 就不会跑偏。

这不成立。

规格本身会模糊、会过时、会被业务决定推翻。工具只能帮助你把不一致露出来，不能替你选择要不要改变意图。

我更愿意把收敛理解成一个停下来问的问题：

现在的代码、未完成任务和验收证据，仍然在服务同一个决定吗？

如果答案是否定的，最好的动作通常不是让 Agent 继续补丁式修复，而是先写清楚“这次变了什么”。

04PART给变化一个编号，而不是一条口头消息

小团队最容易说：“这事很小，直接改吧。”

有时确实如此。文案、无行为影响的样式调整、孤立且可验证的修复，不需要启动一整套变更治理。

但只要变化会影响既有行为、接口、数据、权限、验收或发布判断，就值得留下一张极短的变更单。它不是流程负担，而是给人和 Agent 一个共同的重新对齐点。

下面这个 spec-change.md 模板够小，也足够开始使用：

# SC-2026-014：老客户续期兼容## 为什么现在改原决定：升级后所有用户重新授权。新决定：2025-12-31 前创建的有效客户保持原授权。## 意图与边界- 目标：减少老客户升级后的中断。- 不包含：不延长已过期的授权；不改变新客户流程。- 例外：企业 SSO 租户走现有迁移方案。## 影响清单- 规格：AUTH-12、AUTH-14- 计划：token 识别与迁移步骤- 任务：T-18、T-23；新增 T-31- 测试：旧 token / 新版本组合；SSO 回归- 发布：观察登录失败率、token 刷新失败率## 验收与决定- owner：产品负责人 + 安全负责人- 必须证据：迁移演练、回归结果、灰度看板- 回滚决定：兼容判断异常时关闭功能开关，不撤销已完成数据迁移- 生效日期与复核人：

关键字段不是格式，而是 原决定、新决定、影响范围、验收增量、owner 和回滚决定。只要这六项在，Agent 的任务上下文就不会只剩一段过期聊天记录。

05PART别把所有工作都规格化

规格适用于高歧义、高影响、跨角色、持续时间长的变更。它不适合把每个拼写修正都变成一次委员会审议。

可以用一个简单判断：如果在实现前，两个合理的人可能对“完成后应该怎样”给出不同答案，那么它值得写明行为与反例。

如果边界明确、影响封闭、能靠一个快速检查验证，就直接做，别把速度浪费在形式上。

06PART结尾

Agent 没有让需求变化变少。

它只是让旧需求更容易被高速、并行、连续地执行下去。

所以真正需要升级的不是“写文档的习惯”，而是团队处理变化的方式：让每个新决定都能一路追到任务、测试、PR 和发布。

下一篇我们往更底层走一步。规格要放在哪里、谁来维护、怎样避免它和实际仓库一起过期？答案不在聊天记录里，在仓库这份会被人和 Agent 共同读取的协作记忆里。