从粗略需求草拟规格
先用技术规格指南里的“PRD 转规格”一节拆解业务目标，再用模板示例把产品语言转成研发、测试和评审都能使用的结构。
进入草拟路径Spec Guides
面向真实交付场景的短指南。先用一页清单收敛问题，再进入模板和长文，不必在项目推进时切换思维模式。
5 篇问题导向，而不是空泛理论
工作流优先围绕草拟、评审、测试和发布设计
模板可接续每篇都能自然衔接到可复用资产
按当前任务选择指南路径
每篇指南能给你什么
每篇指南遵循相同结构：先说明这个主题为什么重要（一段话），再给出一个可以直接复制进规格或 ticket 的示例，最后是覆盖边界情况、角色专属问题和决策规则的深度内容。设计目标是：在 Sprint 开始时打开，5 分钟内扫完，带着一个可落地的产出离开。
指南比博客文章刻意更短。博客文章深入解释某个实践背后的原理，指南优先给你清单或模板——附带足够的上下文让你能直接使用，而不必先读完理论部分。
如何在团队中使用这些指南
最有效的使用方式是在规格评审会前按角色分配：PM 读技术规格指南里的 PRD 转规格和非目标两节，技术负责人读边界情况和 API 契约清单，QA 读验收标准示例和规格评审清单。每个人带着自己职责范围内的专属问题参会，而不是所有人审查同一个层面。
如果评审前不足 30 分钟，从规格评审清单开始——它是发现返工根源最快的方式：缺少回滚步骤、无法测试的验收标准、未确认的依赖项。
什么时候用指南，什么时候用模板
当你在回答问题时用指南："好的验收标准长什么样？"或"我最容易漏掉哪些边界情况？"当你准备好动手写时用模板：你知道要记录什么，只需要一个结构化的格式来填写。
大多数规格工作从指南开始——校准什么叫"写好了"——然后切换到模板来生成实际的产出物。本页指南都链接了对应的模板，可以在两者之间无缝切换。
从哪篇开始
如果团队跳过规格评审或因需求理解错误频繁返工：从规格评审清单开始。它在最短的时间内暴露最常见的缺口。
如果团队写了规格但 QA 测试阶段仍频繁发现问题：从验收标准示例开始——最常见的问题是写出了技术上正确但无法在不追问的情况下测试的标准。
如果使用 AI 编码工具但输出频繁偏离需求：从 AI Coding Prompt 模板开始。
按失败信号快速选择
一次评审里如何组合使用指南
先看最高风险问题
如果改动影响用户可见行为，先看验收标准；如果影响服务边界，先看 API 契约；如果风险在数据、权限或上线，先看边界情况和评审清单。
让每个角色负责一个角度
产品负责挑战范围和非目标，研发负责挑战契约和发布路径，QA 负责挑战结果是否可观测。不同角色带着不同责任读指南，比所有人泛泛浏览更有效。
最后落到一个产物
一次评审应该产出更新后的规格、清单或 Prompt。如果团队读了几篇指南，但没有任何产物发生变化，这次评审大概率只是增加了认知，没有形成可执行决策。
真实团队应该先打开哪篇指南？
场景：下个 sprint 要做 support refund endpoint，并准备让 AI 编码助手参与。如果行为还没定，先看规格评审清单。如果行为定了但不可测试，看验收标准示例。如果 endpoint 会被外部或生成客户端调用，再看API 契约检查清单。
| 信号 | 先看哪篇 | 评审产物 |
|---|---|---|
| 大家还在争论范围。 | 规格评审清单 | 非目标、owner、阻塞问题。 |
| 验收标准写着“正常工作”。 | 验收标准示例 | Given/When/Then 和证据。 |
| 有外部或生成客户端调用。 | API 契约检查清单 | 稳定 schema、错误、重试、兼容性。 |