为什么 AI Coding 越改越乱？从需求描述到规格驱动开发
你让 AI Coding Agent 做一个并不复杂的需求：
给订单列表增加“导出 CSV”功能。
Agent 很快加上按钮和接口。你试了一下，又补充：
导出的应该是筛选后的订单，而且中文不能乱码。
它继续修改。产品同事看到后说：
还要支持导出全部数据，超过一万条时不能把浏览器卡死。
Agent 又引入后台任务、轮询和下载中心。测试时才发现：普通员工也能导出其他部门的订单；导出期间切换筛选条件会得到错误数据；新加的依赖与项目规范冲突；原本只改一个列表页，最后却改了十几个文件。
每一轮对话单独看都很合理，代码却越来越乱。
这通常不是 Agent “突然变笨了”，而是任务一直没有一个稳定的事实来源。每次补充都像在移动终点，Agent 只能根据当前对话重新猜测：哪些旧决定还有效、这次修改影响哪些范围、做到什么程度才算完成。
解决办法不是把第一条 Prompt 写得无限长，而是先把需求整理成一份可以讨论、可以版本化、可以验收的规格（Specification，简称 Spec），再让计划、任务、代码和测试从这份规格向下展开。
这就是规格驱动开发（Spec-Driven Development，SDD）要解决的问题。
一、先说人话：Spec 是团队和 Agent 共同使用的“任务合同”
日常需求描述通常是在表达愿望：
增加 CSV 导出，体验要好一点，数据多的时候也要能用。
这句话足够让人开始讨论，却不够让 Agent 安全地修改代码。因为它至少留下了这些问题：
- 谁可以导出？
- 导出当前页、全部结果，还是当前筛选结果？
- “数据多”具体是多少？
- 同步下载还是异步任务？
- CSV 使用什么编码、时区和字段顺序？
- 导出失败后用户看到什么？
- 是否包含隐藏字段和敏感信息？
- 什么证据可以证明需求已经完成？
Spec 的作用，就是把“大家脑中可能不同的理解”变成一份显式约定。
一份实用的 Spec 不一定很长，但至少应该让三种角色得到相同答案：
| 角色 | 读完后应该知道什么 |
|---|---|
| 产品与业务 | 解决谁的问题，包含和不包含什么 |
| 开发者与 Agent | 必须实现哪些行为，受哪些约束 |
| 测试与 Review | 用哪些场景和证据判断完成 |
可以把它理解成：
需求描述：我大概想要什么
Spec：系统必须表现成什么样，以及怎样证明它做到了
Plan：准备怎样实现
Tasks：按什么顺序修改哪些部分
Code & Tests：实现与验证证据Spec 不是为了取代沟通，而是把沟通结果固定下来，避免同一个问题在实现阶段被反复重新解释。
二、Prompt 驱动为什么容易失控
Prompt 本身没有问题。小而明确的任务，一条 Prompt 完全够用。真正危险的是把不断增长的复杂需求只保存在聊天记录里。
1. 对话是时间顺序，需求是结构关系
聊天记录通常长这样：
先加导出按钮
→ 改成导出筛选结果
→ 再支持全部数据
→ 大数据量异步处理
→ 普通员工只能导出本部门
→ 字段顺序又调整了但真正需要实现的是一组同时成立的规则：权限规则、范围规则、性能规则、字段规则、异常规则。它们不是“最后一句覆盖前一句”这么简单。
当约束散落在几十轮对话中，Agent 很容易：
- 只执行最新补充，忘记早期约束；
- 把讨论中的建议误当成最终决定；
- 修复一个场景时破坏另一个场景；
- 无法判断哪些代码变化属于需求，哪些只是顺手重构。
2. 模糊词会被自动补全
“快速”“友好”“大量”“兼容”“尽量”“适当”都不是可直接验收的要求。
人类同事通常会凭项目经验补全这些词。Agent 也会补全，但它补的是最可能的答案，不一定是你们项目的答案。
例如“导出不能太慢”可能被理解为：
- 点击后 2 秒内开始下载；
- 10,000 条数据在 30 秒内生成；
- 请求不能超过网关 60 秒超时；
- 页面主线程不能冻结超过 100 毫秒。
四种解释都合理，却会产生完全不同的设计。
3. 没有非目标，Agent 会把“做得更完整”当成正确
如果只写“支持导出”，Agent 可能顺便加入：
- 导出历史；
- 定时导出；
- Excel 格式；
- 自定义字段；
- 邮件发送；
- 一套新的任务队列。
这些功能不是坏功能，但不属于当前任务。规格中的“非目标”是在明确告诉 Agent：这里先不要做。
4. 没有验收标准，“完成”只能靠感觉
Agent 说“已完成”，可能只代表代码已经写入文件。你说“不是我想要的”，通常代表双方从未约定可观察的完成条件。
如果没有验收标准，Review 会退化成：
我看起来觉得不对，你再改改。
每次“再改改”都会开启新一轮猜测。
三、规格驱动不等于瀑布，也不等于先写一百页文档
听到“先写规格”，很多人会担心：是不是要回到需求冻结、长文档审批和几个月后才写代码？
不是。
规格驱动强调的是先消除高成本歧义，再进入实现，而不是要求一次性预测所有未来变化。
| 做法 | 核心特点 |
|---|---|
| 大 Prompt | 把很多要求堆在一次对话里，结构和版本边界较弱 |
| PRD | 解释业务目标、用户价值和产品范围 |
| 技术设计 | 解释架构、数据、接口和实现取舍 |
| Spec | 定义系统必须满足的行为、边界和验收条件 |
| 规格驱动开发 | 让 Plan、Tasks、实现和验证都能追溯到 Spec |
Spec 可以迭代，也应该随着真实决定变化。区别在于：变化先进入规格，重新检查影响，再进入代码，而不是直接在代码上打一层又一层补丁。
GitHub 的 Spec Kit 把这条链路概括为 Spec → Plan → Tasks → Implement。其官方说明强调，每个阶段产生的 Markdown 产物会成为下一阶段的结构化上下文，而不是继续依赖临时 Prompt。
四、一份可执行 Spec 应该包含什么
不同团队可以使用不同模板，但下面七部分非常通用。
1. 背景与问题
先解释为什么要做，而不是马上指定按钮颜色和接口路径。
## 背景
运营人员目前只能逐页复制订单数据，每周整理报表约需 2 小时，
且手工复制容易遗漏筛选条件。需要提供受权限控制的 CSV 导出能力。“为什么”会帮助 Agent 在细节冲突时做出更合理的判断。例如，如果目标是减少手工报表时间，那么“保留当前筛选条件”比“只导出当前页”更符合目标。
2. 用户与使用场景
不要只写“用户可以导出”，要指出谁在什么情况下使用。
## 用户
- 运营专员：导出自己所属部门的筛选结果。
- 运营管理员：可以导出所有有权查看的部门数据。
- 无订单查看权限的用户：不能看到导出入口，也不能调用导出接口。3. 范围与非目标
范围回答“本次要做什么”，非目标回答“哪些看起来相关的事情本次明确不做”。
## 范围
- 在订单列表提供 CSV 导出。
- 导出条件与发起时的筛选条件一致。
- 小数据量直接下载，大数据量创建异步任务。
## 非目标
- 不支持 Excel、PDF 格式。
- 不支持用户自定义导出字段。
- 不增加定时导出和邮件发送。
- 不重构现有订单查询模块。非目标不是永远不做，而是保护当前交付边界。
4. 功能需求
每条需求使用稳定编号，描述可观察行为。
## 功能需求
- FR-001：拥有订单查看权限的用户 MUST 能在订单列表发起 CSV 导出。
- FR-002：导出 MUST 固化用户点击时的筛选条件，不受之后页面操作影响。
- FR-003：导出结果 MUST 只包含用户有权查看的订单。
- FR-004：不超过 10,000 条时 SHOULD 直接下载。
- FR-005：超过 10,000 条时 MUST 创建异步任务并展示进度。
- FR-006：失败任务 MUST 显示可理解的原因，并允许用户重试。这里借用了 IETF RFC 2119 的需求级别：MUST 表示绝对要求，SHOULD 表示通常应满足、偏离时必须理解和权衡后果，MAY 表示真正可选。业务 Spec 不必照搬标准全文，但统一这些词的含义能减少“最好支持”和“必须支持”之间的争论。
5. 约束与质量属性
功能正确不代表可以上线。权限、性能、兼容性、可观测性和数据安全也要进入规格。
## 约束
- SEC-001：后端 MUST 根据当前用户重新校验数据范围，不能信任前端传入的部门 ID。
- PERF-001：直接导出 10,000 条订单时，服务端处理时间 p95 MUST 小于 8 秒。
- UX-001：异步任务创建后 1 秒内 MUST 显示“正在生成”状态。
- DATA-001：CSV MUST 使用 UTF-8 with BOM，日期统一输出为 `Asia/Shanghai` 时区。
- OBS-001：导出任务 MUST 记录操作者、筛选摘要、结果数量和失败原因。数字不是越多越好。只有真正影响设计或验收的指标才值得写；无法测量、也没人关心的伪精确数字只会制造噪声。
6. 验收场景
需求条目说明规则，验收场景用具体例子消除歧义。
Cucumber 的 Gherkin 参考把示例组织为 Given / When / Then：已知初始状态、发生一个动作、得到可观察结果。官方文档也提醒，Then 应关注界面、消息或报告等外部可观察结果，而不是内部数据库实现。
场景：运营专员导出本部门的筛选结果
假如 用户属于华东运营部，并拥有订单查看权限
而且 列表筛选条件为“已支付、2026-07-01 至 2026-07-31”
当 用户点击“导出 CSV”
那么 下载文件只包含华东运营部中符合筛选条件的订单
而且 文件使用 UTF-8 with BOM 编码
而且 操作日志记录本次导出
场景：用户尝试绕过前端导出其他部门数据
假如 用户只拥有华东运营部的数据权限
当 用户直接请求导出接口并传入华南运营部 ID
那么 接口返回 403
而且 不创建导出文件
而且 安全日志记录被拒绝的请求不是所有团队都要安装 Cucumber。即使只把 Given/When/Then 当作人工验收模板，它也能迫使我们写清前置条件、动作和结果。
7. 未决问题与决策
不要让 Agent 悄悄替团队决定仍有争议的事项。
## 未决问题
- Q-001：异步导出文件保留 24 小时还是 7 天？负责人：产品，截止：8 月 5 日。
- Q-002：是否需要对公式注入字符做转义？负责人：安全，截止：8 月 5 日。
## 已确认决策
- D-001：本期复用现有任务中心，不新建下载中心。
- D-002：字段集合固定，不开放用户自定义。未决问题应该阻止相关任务进入实现，而不是用一句“按常见做法处理”带过。
五、如何把自然语言写得更精确：借用 EARS 的句式
需求不一定要变成形式化数学语言。一个轻量办法是给自然语言加上稳定结构。
Rolls-Royce 研究人员在 IEEE Requirements Engineering 会议提出的 EARS（Easy Approach to Requirements Syntax） 使用少量句式约束自然语言需求，针对歧义、复杂和含糊等常见问题。它的价值不在于背术语，而在于强迫作者补齐“何时、在什么状态、系统做什么”。
常用句式可以简化为：
| 类型 | 句式 | 导出示例 |
|---|---|---|
| 普遍要求 | 系统必须…… | 系统必须对所有导出重新校验用户权限 |
| 事件触发 | 当……时，系统必须…… | 当用户点击导出时，系统必须固化当前筛选条件 |
| 状态驱动 | 在……期间，系统必须…… | 在任务生成期间，系统必须展示可查询的进度状态 |
| 异常处理 | 如果……，系统必须…… | 如果文件生成失败，系统必须记录原因并允许重试 |
| 可选特性 | 如果启用……，系统必须…… | 如果启用敏感字段脱敏，系统必须按字段策略替换内容 |
对比下面两句话：
差：导出失败时要友好处理。
好：如果异步导出任务失败，系统必须在任务列表显示失败状态和可理解的原因，
并允许用户在筛选条件仍有效时重新创建任务。第二句仍然是自然语言，但已经能派生界面状态、错误模型、重试逻辑和测试场景。
六、从 Spec 到代码，中间不能跳过 Plan 和 Tasks
有了 Spec 就立刻让 Agent 写代码，仍然可能出问题。因为“系统应该怎样表现”和“在当前仓库里怎样实现”是两类问题。
Spec：定义 What 与 Why
Spec 应尽量不绑定具体实现：
超过 10,000 条时必须创建异步任务。
Plan：解释 How
Plan 结合真实代码库做技术决策：
- 复用现有 `JobService`，新增 `ORDER_EXPORT` 任务类型。
- 查询复用 `OrderQueryService`，服务端根据当前用户注入数据范围。
- 生成文件写入现有对象存储，生命周期设为 24 小时。
- 前端复用 `TaskProgress` 组件，不新增轮询框架。
- 风险：订单查询当前未提供流式读取，需要验证 10,000 条的内存峰值。Tasks：把计划拆成可验证增量
任务不是“实现导出功能”这样的大包，而应该能单独完成和验证：
- [ ] T001 [FR-003] 为订单导出查询增加服务端数据范围测试
- [ ] T002 [FR-002] 定义不可变的 ExportFilter 快照
- [ ] T003 [FR-004] 实现小数据量 CSV 生成与编码测试
- [ ] T004 [FR-005] 接入 JobService 异步任务
- [ ] T005 [UX-001] 在列表页展示任务创建与进度状态
- [ ] T006 [OBS-001] 增加导出审计日志
- [ ] T007 [AC-01~AC-05] 运行端到端验收场景Implement：按任务执行，不在过程中重新发明需求
实现时可以发现 Spec 有问题，但不应在代码里静默修正。正确做法是：
发现歧义
→ 回到 Spec 澄清
→ 更新受影响的 Plan
→ 重新生成或调整 Tasks
→ 实现
→ 根据验收场景验证规格驱动不是单向流水线，而是一个有明确回退位置的反馈循环。
七、完整实战：把一句话需求改写成可执行规格
下面从最初的需求开始：
给订单列表增加 CSV 导出。
第一步：先让 Agent 提问，不要让它马上写代码
暂时不要修改代码。请先阅读订单列表、权限模型、现有任务中心和测试结构。
针对“给订单列表增加 CSV 导出”这个需求：
1. 列出会影响实现的歧义；
2. 区分业务问题与技术问题；
3. 对能从仓库确认的事实提供文件证据；
4. 对不能确认的事项列为问题，不要自行假设；
5. 最后给出一份 Spec 草案，不生成实现计划。这一步的关键是把“探索”和“修改”分开。Agent 可以通过代码确认现有权限、组件和任务基础设施，但不能从代码猜出业务保留期或产品范围。
第二步：审查 Spec，而不是审查文笔
重点检查：
- 每个角色是否清楚？
- 每个模糊词是否被数字或场景替代？
- 正常、空数据、无权限、失败和大数据量是否覆盖？
- 非目标能否阻止范围膨胀？
- 约束是否来自真实系统？
- 每条验收标准是否能观察或测量？
- 是否仍有 Agent 私自做出的产品决定？
可以让另一个会话只做反例审查：
只审查这份 Spec，不写代码。
请从产品、开发、测试、安全和运维五个视角找出：
- 歧义与相互冲突的要求；
- 缺失的边界条件；
- 无法验证的验收标准；
- 被错误写成需求的实现细节；
- 可能导致越权、数据泄露或不可恢复操作的场景。
每个问题引用对应的需求编号，并给出最小修改建议。第三步：建立追踪关系
不需要购买复杂的需求管理平台。中小项目用 Markdown 编号就能建立基本追踪：
| 需求 | 计划决策 | 实现任务 | 验证证据 |
|---|---|---|---|
| FR-002 筛选快照 | 使用不可变 ExportFilter | T002 | 单元测试 + 并发操作 E2E |
| FR-003 权限范围 | 服务端注入数据权限 | T001 | 越权接口测试 |
| FR-005 异步任务 | 复用 JobService | T004、T005 | 任务状态集成测试 |
| DATA-001 CSV 编码 | UTF-8 with BOM | T003 | 中文 Excel 打开验证 |
追踪关系能回答两个非常实际的问题：
- 这个改动是为了满足哪条需求？
- 这条需求用什么证据证明已经满足？
如果一项任务找不到需求来源，它可能是范围漂移；如果一条需求找不到测试或验证证据，它可能还没有真正完成。
八、用 GitHub Spec Kit 跑一遍标准流程
GitHub Spec Kit 是一个开源的规格驱动开发工具包。它不是新的编程语言，也不会替你决定产品需求；它提供的是模板、命令和产物目录，让 Agent 按稳定流程工作。
官方当前的核心流程是：
constitution
→ specify
→ clarify
→ plan
→ checklist
→ tasks
→ analyze
→ implement
→ converge不同 Agent 的命令形式可能是 /speckit.*、$speckit-* 或其他集成形式，应以 Spec Kit 官方集成说明为准。
1. 安装和初始化
按照官方 README，可使用 uv 安装 specify-cli：
uv tool install specify-cli
specify init . --integration codex如果你使用其他 Agent，把 codex 换成官方支持的集成名称。不要在不了解初始化会写入哪些文件时直接对重要仓库使用 --force。
2. Constitution：先确定项目不可随任务改变的原则
/speckit.constitution
项目必须复用现有组件；生成代码不得手工修改；
所有数据读取必须执行服务端权限检查；
功能变更必须包含自动化测试和可复现的验证证据。Constitution 解决“这个项目长期怎样工作”；Spec 解决“这次功能必须怎样表现”。不要把两者混成一份无限增长的文档。
3. Specify：先写 What 与 Why
/speckit.specify
为订单列表增加 CSV 导出。运营人员需要导出当前筛选结果用于周报；
导出必须遵守订单数据权限，中文可直接用 Excel 打开；
本期不支持自定义字段、定时导出和邮件发送。Spec Kit 官方建议在这一阶段聚焦“做什么、为什么”，把技术栈和架构选择留给 Plan。
4. Clarify 与 Checklist：在设计变贵之前消除歧义
/speckit.clarify
重点检查权限范围、大数据量阈值、失败重试和文件保留时间。
/speckit.checklist
为安全、性能与可验收性生成规格质量清单。官方把 Checklist 类比为“需求的单元测试”：它检查的不是代码，而是规格是否完整、清晰、一致。
5. Plan：结合真实仓库选择实现方式
/speckit.plan
复用仓库现有 JobService、对象存储和 TaskProgress 组件；
后端使用现有 OrderQueryService 并注入当前用户的数据权限；
测试沿用项目已有的 Vitest 与 Playwright 结构。Spec Kit 的 Plan 模板会显式记录技术上下文、依赖、测试方式、目标平台、性能目标、约束、规模和项目结构。这些信息如果仍是 NEEDS CLARIFICATION，就不应该假装已经可以实现。
6. Tasks 与 Analyze：检查每项工作有没有来源
/speckit.tasks
/speckit.analyze根据 Agentic SDD 官方参考，analyze 会只读检查 spec.md、plan.md 和 tasks.md 之间的冲突、遗漏和歧义。例如：某个任务没有对应需求，或 Plan 的选择与 Spec 冲突。
7. Implement 与 Converge：分段实现并回到规格验收
/speckit.implement 只实现权限检查与筛选快照，验证后停止。
/speckit.implement 实现同步 CSV 下载，验证后停止。
/speckit.implement 实现异步任务与前端进度。
/speckit.converge复杂功能不要一次让 Agent 执行所有任务。Spec Kit 的复杂功能指南也指出，长时间实现过程中 Agent 可能逐渐忽略计划或任务；官方建议缩小每次实现范围，必要时再拆成独立子规格。
Spec Kit 是流程脚手架，不是正确性证明。生成的 Spec、Plan 和 Tasks 仍然需要业务、技术和安全负责人审查。
九、规格应该写多细
规格不是越长越好。粒度应该与歧义、风险和修改成本匹配。
| 任务类型 | 推荐规格 | 示例 |
|---|---|---|
| 极小、低风险、现有模式明确 | 目标 + 范围 + 3~5 条验收项 | 修改文案、增加已存在样式的按钮 |
| 中等功能、跨前后端 | 完整轻量 Spec + Plan + 分步任务 | CSV 导出、批量操作、权限控制 |
| 高风险或跨系统 | 完整 Spec + 数据/接口契约 + 风险与回滚 + 分阶段验收 | 支付、权限、数据迁移、生产集成 |
| 超大功能 | 先写路线级 Spec，再拆成独立子规格 | 新工作台、消息系统、多租户改造 |
判断是否需要更详细，可以问四个问题：
- 不同人会不会对这句话产生不同理解？
- 做错后是改一个按钮，还是会泄露数据、损坏状态？
- 是否跨越多个模块、团队或外部系统？
- 是否需要几天后或换一个 Agent 继续工作？
“是”越多，越值得先写规格。
十、需求变化时，先改哪里
规格驱动开发不阻止变化，而是让变化可追踪。
假设产品后来要求：异步文件从保留 24 小时改为 7 天。
错误方式：
直接告诉 Agent：“顺便把保留时间改成 7 天。”正确顺序：
- 更新 Spec 中的保留策略与原因；
- 检查隐私、存储成本和下载权限是否受影响；
- 更新 Plan 中的对象存储生命周期；
- 更新对应任务和测试；
- 只修改受影响的代码；
- 用新旧验收场景做回归。
这样下一个接手的人能知道“为什么是 7 天”，而不是只在某个配置文件里看到一个神秘数字。
十一、常见失败方式
1. 把 Spec 写成解决方案清单
一上来就写“新增 Redis 队列、创建三张表、使用某某库”，会过早锁死设计。
先写系统行为和约束，再让 Plan 根据仓库现状选择技术方案。
2. Spec 由 Agent 生成后没人确认
Agent 能整理语言、发现缺项，不能替业务负责人决定权限、范围和合规要求。
生成不是确认。任何影响产品行为的假设都必须显式审查。
3. 验收标准仍然是形容词
差：页面响应迅速，失败提示友好。
好：点击导出后 1 秒内出现任务状态；失败时显示原因和重试入口。4. 所有要求都标成 MUST
如果没有优先级，就没有真正的优先级。使用 MUST、SHOULD、MAY 时要统一含义，并允许团队讨论成本与取舍。
5. Spec、Plan、Tasks 写完后各自漂移
文档多不等于可追踪。需求编号、任务引用和测试证据必须连起来；否则只是把混乱从聊天窗口搬进多个 Markdown 文件。
6. 把实现日志塞回 Spec
Spec 记录稳定意图和已确认行为，Plan 记录技术决策，Tasks 记录执行，PR 或交付报告记录实际修改。职责混在一起，文档很快会再次失去可信度。
7. 小任务也套完整重流程
改一个错别字不需要 Constitution、十页 Spec 和十二个命令。流程成本应该与风险匹配。
十二、可直接复制的轻量 Spec 模板
# Feature: <功能名称>
## 背景与目标
- 当前问题：
- 目标用户：
- 期望结果：
## 范围
-
## 非目标
-
## 功能需求
- FR-001：
- FR-002：
## 约束与质量要求
- SEC-001：
- PERF-001：
- DATA-001：
## 验收场景
### AC-001：<场景名称>
- Given：
- When：
- Then：
## 边界与异常
- 空数据：
- 无权限：
- 重复操作：
- 并发变化：
- 外部依赖失败：
## 未决问题
- Q-001：<问题>；负责人：<角色>；截止：<日期>
## 已确认决策
- D-001：配合 Agent 使用时，可以这样要求：
请基于仓库事实，把下面需求整理成轻量 Spec。
要求：
1. 先探索相关代码、规则和测试，不修改文件；
2. 区分目标、范围、非目标、功能需求、质量约束和验收场景；
3. 每条需求使用稳定编号；
4. 无法从仓库确认的业务事项列入“未决问题”，不要猜；
5. 验收标准必须是可观察或可测量结果；
6. Spec 经我确认前，不生成 Plan，不写代码。
原始需求：<粘贴需求>十三、今天就能开始的最小实践
不安装任何工具，也可以从下一次中等复杂度需求开始：
- 用 15 分钟写目标、范围和非目标；
- 给功能需求编号；
- 写一个正常场景和三个失败/边界场景；
- 让 Agent 只找歧义，不写代码；
- 确认后再生成 Plan；
- 把 Plan 拆成每步可验证的 Tasks；
- 要求交付报告逐条对应需求与证据。
你会发现，规格最大的价值不是“让 Agent 一次写对所有代码”，而是让错误更早暴露：
- 需求问题在 Spec 阶段暴露；
- 设计问题在 Plan 阶段暴露；
- 依赖和顺序问题在 Tasks 阶段暴露；
- 实现问题在测试和 Review 阶段暴露。
越早发现，修复成本越低。
总结
AI Coding 越改越乱，往往不是因为生成速度不够，而是因为缺少稳定边界：需求散落在对话里，模糊词被自动补全，非目标没有声明，完成条件无法验证。
规格驱动开发建立的是一条可追踪链路：
意图 → Spec → Plan → Tasks → Code → Tests → Evidence记住四个原则：
- 先澄清行为，再选择实现。
- 把非目标和验收标准写进规格。
- 让每项任务和测试都能追溯到需求。
- 需求变化先更新事实来源，再更新代码。
当 Spec 成为团队与 Agent 共同读取的任务合同，Prompt 就不再承担“记住一切”的压力。Agent 也不需要在每轮对话里重新猜终点，而可以沿着清晰、可验证的路径完成交付。