技能介绍

要解决的问题

很多团队的「AI 辅助开发」流程是这样的：把一份写了半年的需求文档丢给模型，让它开始写代码。结果模型基于假设补全逻辑，代码跑起来和意图对不上，然后进入「改代码—改文档—再改代码」的循环。问题不在模型，在于文档本身有歧义——模型没有可依赖的单一信息源，只能猜。

核心思路：把文档当作唯一的工作产物

Stream Coding 的定位很明确：这不是写代码的方法论，而是写文档的方法论。其核心主张是：如果文档足够清晰，代码生成就是自动的，代码只是文档的打印件。

为此技能把工作拆成四个阶段，时间分配为 40/40/5/10/5：

Phase 1 战略思考（40%）：用 7 Questions 框架回答「做什么、为什么赢、MVP 是什么、明确不做什么」，产出 Strategic Blueprint 和 ADR。
Phase 2 AI 就绪文档（40%）：写实现层文档，且每个实现文档必须包含四个强制章节：Anti-Patterns（至少 5 条）、Test Case Specifications（每组件至少 5 个单测、3 个集成测试）、Error Handling Matrix、Deep Links（精确到文档路径+锚点，禁止「见其他文档」式引用）。
Phase 2.5 对抗式审查（5%）：规格通过 Spec Gate 后，把规格贴进另一个模型（不能是帮你写文档的同一个会话）当靶子打，寻找逻辑漏洞。
Phase 3 执行（10%） 与 Phase 4 质量迭代（5%）：代码生成与测试收敛。

关键闸门是 Spec Gate：13 项检查，分基础检查（Actionable、Current、Single Source、Decision Not Wish、Prompt-Ready、No Future State、No Fluff）和文档架构检查（文档类型已标识、Anti-patterns/测试用例/错误矩阵只放在实现文档、Deep Links 存在、无重复内容）。只有全部通过才允许进入代码生成。评分 rubric 要求文档达到 9+/10，权重最高的是 Actionability（25%）与 Specificity（20%）。

文档类型与适用边界

技能把文档分成 Strategic / Implementation / Reference 三类，并用矩阵规定每类文档能放什么章节——把实现细节塞进战略文档会破坏 single-source-of-truth，模型就不得不自己判断信息在哪，速度优势随之消失。

需要注意：这个技能不是免思考的自动化工具。它要求人在 Phase 1 做完架构决策，在 Phase 2.5 手动换模型做对抗审查；文档写得不认真，Spec Gate 就形同虚设。如果你的项目没有文档沉淀，可以先跳过 Documentation Audit（它只适用于清理遗留文档）；如果你只需要快速原型，这套 40/40 的文档投入可能过重。