Vibe Coding第一道质量门：Spec不是文档，是“需求和测试之间的合同”
AH-0079的核心判断很准： Vibe Coding返工，很多时候不是AI写代码慢，而是人一开始没把需求说清。 原作者用EvoPaw的30天开发经验，提出：先写raw idea，再用Claude Code Plan mode追问，沉淀spec，再用Codex交叉review，最后拆成plan和todo；还推荐obra/superpowers把这套流程变成自动触发工作流。 这篇素材非常适合alph
Vibe Coding第一道质量门：Spec不是文档，是“需求和测试之间的合同”
AH-0079的核心判断很准：
Vibe Coding返工，很多时候不是AI写代码慢，而是人一开始没把需求说清。
原作者用EvoPaw的30天开发经验，提出：先写raw idea，再用Claude Code Plan mode追问，沉淀spec，再用Codex交叉review，最后拆成plan和todo；还推荐obra/superpowers把这套流程变成自动触发工作流。
这篇素材非常适合alphahole，但要做几处重要升级。
第一处：Spec不是“写得特别详细”
详细不等于清楚。
一份3000字spec，如果没有可观察行为、失败条件和验收标准，仍然可能只是长散文。
我更愿意把spec定义成：
> 需求与验收之间的合同。
它至少回答：
- 谁在什么场景使用？
- 系统必须做什么？
- 明确不做什么？
- 输入/输出是什么？
- 失败时发生什么？
- 哪些行为能被测试？
- 哪些事实仍是TBD？
- 哪些风险需要人工确认？
第二处：先写“什么”，再写“怎么做”
原作者特别强调spec里不要塞Redis、vector DB、GPT-4等实现细节，这一点值得保留。
可以分三层：
Product Spec
外部可观察行为、用户结果、非目标、边界。Acceptance/Test Contract
给定什么输入，期望什么输出；失败怎样算失败。Architecture/Plan
真正讨论缓存、数据库、provider、框架和文件结构。把这三层混在一起，AI很容易把“一个实现建议”误当成“不可改变的需求”。
第三处：把模糊词改成“可测量”，但不要制造伪精确
原文说“快速、流畅、友好”要改成具体数字，方向对。
但不能为了摆脱模糊，随手写“<100ms”。
真正好的指标需要依据：
- 用户体验；
- 当前系统基线；
- 外部SLA；
- 成本；
- 技术可行性。
- contradiction；
- ambiguous terms；
- hidden assumptions；
- missing failure cases；
- missing non-goals；
- privacy/security；
- migration；
- observability；
- test oracle。
- spec变更有commit；
- 变更原因；
- acceptance criteria同步更新；
- 代码和测试引用spec版本；
- TBD不能悄悄变成模型默认；
- 用户行为变化后，先改spec再改实现。
如果暂时不知道，写：
TBD — measure current baseline before setting target
比假装精确更严谨。
第四处：Plan mode当前确实存在，但把它当工具，不当宗教
Anthropic当前Claude Code文档明确提供plan权限模式。在plan模式下，Claude可以分析，但不会进行文件修改/执行这类行动。
这非常适合需求澄清。
但真正的原则不是“每次一定按Shift+Tab”。
是：
> 在需求尚未被批准前，让Agent没有修改生产资产的权限。
未来客户端快捷键会变，权限原则不会变。
第五处：双模型review有价值，但“稳定提高20%”没有证据
用另一家模型review spec确实可能暴露不同盲区。
但源文的“清晰20%”“少踩70%的坑”属于个人体验型数字，没有可复现评测。
更稳的review协议应该要求第二模型检查：
最终仍由人拍板。
第六处：Superpowers现在已经超过源文的“5.x时代”
obra/superpowers当前公开仓库仍活跃，MIT许可，支持Claude Code、Codex、Cursor、Gemini CLI等多个coding agent，核心仍是brainstorming、planning、TDD/verification、subagent/工作流纪律。
源文写“已经迭代到5.x”，这是当时状态。
2026年中仓库已经继续演进到6.x系列，因此工具稿必须把版本写成动态字段，而不是把“5.x”固化到教程。
第七处：Spec应该和代码一起版本化
源文说spec不是石碑，这是非常好的点。
真正要进一步做到：
这让需求漂移变成可观察事件。
第八处：AI coding真正的危险不是“它不听话”
有时恰恰是它太听话。
一句“帮我做一个群消息待办总结”，AI会自动填满空白：
时间范围。
机器人消息是否过滤。
引用消息怎么处理。
群ID还是群名。
节假日。
Token预算。
数据权限。
如果这些假设没有被明确记录，代码越快，返工越深。
所以Vibe Coding真正的第一步不是写更多Prompt。
是把模型会脑补的空间暴露出来。
网站资产：Spec Stress Test Lab
本批生成 spec_stress_test_lab.html。
你粘贴一段spec，它不会替你写代码。
它只检查有没有：
Problem / User / Non-goals / Inputs / Outputs / Acceptance / Failure / Security / Privacy / Observability / Migration / Open Questions。
同时标记“快速、智能、友好、稳定、尽快、自动”等模糊词，提醒你：
是要量化，还是明确写TBD。
这比“给Agent一条更长Prompt”更像真正的质量门。
Vibe Coding速度越快，Spec越重要。
因为AI不是在帮你减少假设。
它是在用极高速度把你的假设变成文件、接口和依赖。