Spec + RAG 与增强开发工作流
这条线讲的是怎么把“会写代码的模型”变成“懂项目的程序员”。几篇文章的共同答案是：给它结构化规范（Spec）、检索增强（RAG）、强制流程和常用工具封装，别再指望一句自然语言 magic prompt 包治百病。 [[raw/2026-04-08/导购&商详团队/告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md|来源: 告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md]] [[raw/2026-04-24/笨小葱/AI 增强开发的三件套：OpenSpec + Superpowers + gstack.md|来源: AI 增强开发的三件套：OpenSpec + Superpowers + gstack.md]]
方法论核心
- Spec 用来把需求、边界、验收标准和工程约束结构化；RAG 用来把代码库、文档和最佳实践按需喂给 agent，减少幻觉和断链。 [[raw/2026-04-08/导购&商详团队/告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md|来源: 告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md]]
- OpenSpec + Superpowers + gstack 的组合进一步把它落到工作流：前者负责编译需求，中间层约束执行过程，后者把高频工具动作变成可复用命令。 [[raw/2026-04-24/笨小葱/AI 增强开发的三件套：OpenSpec + Superpowers + gstack.md|来源: AI 增强开发的三件套：OpenSpec + Superpowers + gstack.md]]
对 Claude Code / Codex 的意义
- 这套方法天然适合作为 [[wiki/entities/CLAUDE.md 与 .claude 配置]] 的上层规则来源，也能和 [[wiki/concepts/上下文管理与 Harness Engineering]] 结合，把长任务拆成更稳定的阶段。 [[raw/2026-04-02/爱海贼的无处不在/与AI一起成长：AI时代我的6个方法经验分享给你.md|来源: 与AI一起成长：AI时代我的6个方法经验分享给你.md]]
- 当 Codex、Claude Code、OpenClaw 都在追求更强执行力时，Spec + RAG 更像给执行力加方向盘和刹车。 [[raw/2026-04-02/AI兴观点/OpenAI 官方总结 12 个 Codex 用例：从改 Bug、写测试到处理 PR，一次看懂.md|来源: OpenAI 官方总结 12 个 Codex 用例：从改 Bug、写测试到处理 PR，一次看懂.md]] [[raw/2026-04-08/导购&商详团队/告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md|来源: 告别“伪智能”代码：用 Spec + RAG 打造真正懂你的AI程序员.md]]
SDD 四阶段模型
Spec-Driven Development 不只是”先写文档再写代码”，而是一套有明确入口、输出和质量门禁的四阶段流程：
- 需求分析（Requirement Analysis）：明确要做什么，输入是业务需求，输出是结构化需求文档
- 技术规划（Technical Planning）：确定怎么做，输出技术方案和架构决策
- 任务分解（Task Decomposition）：把方案拆成可执行、可验证的小任务
- 验证（Verification）：逐条对照需求验收，确保不跑偏
核心价值在于让过程可追溯、可验证，而不是指望 agent 一次性猜对。[[raw/2026-05-07/腾讯程序员/十年老技术开发的 AI Agent 探索之路.md|来源: 腾讯程序员 SDD]] [[raw/2026-05-09/王砚舒（彦纾）/5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程.md|来源: 王砚舒 SDD redefining AI coding]]
Vibe Coding vs SDD：先易后难 vs 先难后易
Vibe Coding 的本质是”先易后难”——前期省掉设计时间，后期为调试付出 10 倍代价。SDD 反过来”先难后易”。实践经验显示，Vibe Coding 到第 15 天的”设计与实现对齐”环节是最痛苦但也最有价值的一天。不是说 Vibe Coding 不能用，而是要知道它的代价曲线和 SDD 完全不同。[[raw/2026-05-07/腾讯程序员/十年老技术开发的 AI Agent 探索之路.md|来源: 腾讯程序员 Vibe Coding翻车]]
五种编程范式对比（618 促销案例）
吕昭波用同一个真实企业场景（618 促销活动）对比了五种 AI 编程范式：
- Spec：结构化规范驱动，适合需求明确的工程化项目
- Vibe：自然语言自由探索，适合早期原型和创意阶段
- Glue：把 AI 生成的代码块粘合起来，适合快速组合
- TDD：测试先行，适合逻辑密集、需回归保障的场景
- Harness：约束+治理框架，适合长期维护和团队协作
五种范式不是互斥的——实际项目中往往是混合使用，关键在于判断每个阶段的适配范式。[[raw/2026-05-10/吕昭波/1个场景(618促销)5种范式(Spec-Vibe-Glue-TDD-Harness) ，企业级AI Coding经验分享(附代码示例).md|来源: 吕昭波 5种范式]]
Constitution.md：架构约束文件
Constitution.md 是被反复提到的一个关键实践——它不是 README，而是给 AI 的”项目宪法”，必须覆盖三件事：
- 目录结构约定：哪些目录放什么，AI 不能随意创建文件
- 模块边界：哪些模块之间可以互相依赖，哪些不能跨边界调用
- 命名规则：文件、函数、变量的命名规范
“有了它，AI 才能在’框架内工作’而不是’自由发挥’。“它和 [[wiki/entities/CLAUDE.md 与 .claude 配置]] 里的 CLAUDE.md 是互补关系：CLAUDE.md 定义行为规则，Constitution.md 定义架构约束。[[raw/2026-05-07/腾讯程序员/十年老技术开发的 AI Agent 探索之路.md|来源: 腾讯程序员 constitution.md]]
需求到原型的平台化：阿里秒悟 + Google Stitch
新一代平台开始把”需求 → 界面原型”这个环节从手工变成自动化。阿里秒悟和 Google Stitch 代表了两种方向：前者偏企业级设计系统对接，后者偏快速概念验证。这类工具补上了 SDD 流程中从”需求文档”到”可交互原型”的跳步。[[raw/2026-05-11/爱海贼的无处不在/AI编程实践第9节：阿里秒悟与谷歌Stitch平台实现需求界面原型设计.md|来源: 阿里秒悟+谷歌Stitch]]
SDD 三级成熟度与完整模板
在 [[#SDD 四阶段模型|四阶段流程]] 之上，SDD 还有三个成熟度等级：
- Spec-First：先写 spec 再写代码，但 spec 和代码独立演进
- Spec-Anchored：spec 是锚点，代码围绕 spec 展开，偏差需显式标出
- Spec-as-Source：改 spec 触发代码重生成，spec 成为唯一真相源
“规格才是新的代码”（Spec is the new code）。这与上文 [[#Vibe Coding vs SDD：先易后难 vs 先难后易|Vibe Coding vs SDD]] 的代价曲线分析互为补充：SDD 不只是”先难后易”，终极形态是 spec 即代码。
最小模板
- Spec（9 字段）：标题、背景、目标、范围、非目标、约束、验收标准、依赖、风险
- Plan（8 字段）：架构概述、技术选型、模块划分、数据流、接口契约、状态管理、错误策略、测试策略
- Task（6 字段）：标题、描述、关联 Spec、关联 Plan、验收条件、预估工时
Spec 和 Plan 必须分开写——混在一起 agent 在两个层次间跳，歧义放大。
“沉默的决策”陷阱
未明说的前提（幂等、权限、错误处理）是 agent 猜错的最大来源。Spec 的价值不仅是”写了什么”，更是”把沉默的决策显性化”。
切入建议
Plan mode → 固定最小流程 → Spec Kit 等专用框架。生态收敛证据：GitHub Spec Kit（77k stars）、OpenAI Symphony、Ralph Loop，三大玩家指向同一方向。
[[raw/2026-05-16/jilolo/Vibe Coding已经是过去式了：Spec Driven Development（SDD） 指南.md|来源: SDD指南]] [[raw/2026-05-16/jilolo/一份更完整的 Spec Driven Development（SDD） 指南.md|来源: SDD完整指南]]
PRD 两层拆分与证据链
PRD 分两层管理复杂度：
- 总体介绍层：背景、闭环、功能地图、User Story 索引
- 单个 US 文档层：每个 User Story 独立成文，聚焦单一场景
每个 US 必须有 Given/When/Then 验收表（正常场景 + 边界场景），无验收不进开发。这与上文 [[#SDD 三级成熟度与完整模板|SDD 最小模板]] 中的验收标准字段形成呼应：Spec 层的验收标准需要在 PRD 层落地为具体用例。
Agent PRD 额外三块
针对 AI Agent 开发场景，PRD 还需包含：
- 意图空间：Agent 可以做什么、不可以做什么
- 工具调用规则：何时用哪个工具、调用顺序约束
- 边界条件：超时、失败重试、降级策略
证据链
“证据链”表确保测试可追溯：功能需求 → 来源文档 + 原文摘要，每条需求都能回溯到原始依据。这是对上文 [[#SDD 四阶段模型|SDD 验证环节]] 的具体落地方法。
[[raw/2026-05-16/gnash/PRD怎么写，vibe coding能够减少50%以上的测试时间？.md|来源: PRD写法]]
SDD 六要素与三种模式（ChallengeHub 体系）
ChallengeHub 提出了一套与社区 SDD 模板互补的六要素框架，更侧重”规范本身该写什么”：
- 预期结果：要达成什么
- 范围边界：做什么、不做什么
- 约束条件：技术栈、性能、合规等硬性限制
- 已定决策：已经确定的架构选择，避免 agent 反复质疑
- 任务拆分：可并行、可独立验证的子任务
- 验证标准：怎么算”做完了”
三种模式对应不同成熟阶段：
- 规范优先（Spec-First）：入门级，先写规范再写代码
- 规范锚定（Spec-Anchored）：企业治理级，规范作为审计轨迹，偏差必须显式记录
- 规范即源码（Spec-as-Source）：API First 等领域的终极形态，改规范触发代码重生成
这与上文 [[#SDD 三级成熟度与完整模板|SDD 三级成熟度]]（Spec-First → Spec-Anchored → Spec-as-Source）的命名体系高度吻合，但强调的维度不同：三级成熟度关注”规范与代码的关系”，六要素关注”规范本身的内容结构”。[[raw/2026-05-22/ChallengeHub/Spec-Driven Development完整指南：6要素+3模式+多智能体，一篇讲透SDD怎么用.md|来源: ChallengeHub-SDD完整指南]]
对抗式智能体模式
ChallengeHub 提出了一种三角色对抗架构来保证实现质量：
- 协调者（Coordinator）：把主规范拆解为子规范，分配给实现者
- 实现者（Implementer）：按子规范独立干活
- 验证者（Verifier）：独立对照规范检查实现者的产出
实现者和验证者目标相反——一个要”做出来”，一个要”挑毛病”——这种对抗结构天然防止自欺欺人。
模型分层成本策略
利用不同模型的能力/成本差异做分层：
- 写规范：用最强模型（需要深度推理和全局视野）
- 实现：用中档模型（Sonnet 档，够用且成本可控）
- 验证：用快速低成本模型（对照规范检查不需要创造性）
实操案例
Figma MCP 拉设计上下文 → 协调者按页面拆解规范 → 多个 Agent 在隔离 git worktree 中并行实现 → 45 分钟完成 10 页官网约 95%。关键杠杆不是”模型更强”，而是”每个 Agent 只拿到它需要的那部分上下文”——上下文精度比上下文容量更重要。[[raw/2026-05-22/ChallengeHub/Spec-Driven Development完整指南：6要素+3模式+多智能体，一篇讲透SDD怎么用.md|来源: ChallengeHub-SDD完整指南]]
与 TDD/BDD 的关系
SDD 不是 TDD/BDD 的替代品，而是叠加关系：TDD 管单元层、BDD 管行为层、SDD 管架构层。三层各司其职，互不冲突。[[raw/2026-05-22/ChallengeHub/Spec-Driven Development完整指南：6要素+3模式+多智能体，一篇讲透SDD怎么用.md|来源: ChallengeHub-SDD完整指南]]
对 Vibe Coding 的明确批评
ChallengeHub 明确指出 Vibe Coding 导致代码复杂度持续走高——前期省掉的设计成本，后期以指数级返工形式偿还。这与上文 [[#Vibe Coding vs SDD：先易后难 vs 先难后易|Vibe Coding vs SDD]] 的代价曲线分析一致。[[raw/2026-05-22/ChallengeHub/Spec-Driven Development完整指南：6要素+3模式+多智能体，一篇讲透SDD怎么用.md|来源: ChallengeHub-SDD完整指南]]
OpenSpec 深度剖析：Brownfield 优先的规范驱动框架
Jameszyh 对 OpenSpec 进行了系统性深度剖析，揭示了它与社区主流 SDD 框架（Spec-Kit 等）的设计哲学差异。OpenSpec 的核心设计决策是面向存量项目（brownfield），而非绿地项目（greenfield）——它允许在现有代码上分层叠加规范，而非要求一次性完成全量系统规范。[[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md|来源: OpenSpec 深度剖析]]
三条设计哲学
- Spec as Contract（规范即契约）：规范不是文档，而是人和 AI 之间的执行约束——不是为了记录而写，而是为了对齐目标而写
- Change as First-Class Citizen（变更为一等公民）：每次变更像 Git 提交一样有完整生命周期，变更过程有 proposal→specs→design→tasks 四个文件记录
- Incremental over Full（渐进优于完整）：不追求一次性写完所有规范，让规范从增量变更中自然”涌现”
Delta Spec：WAL 风格的变更原语
Delta Spec 是 OpenSpec 的核心创新——它只用三个操作原语描述变更：
- ADDED：新增内容
- MODIFIED：修改内容
- REMOVED：移除内容
这与数据库 WAL（Write-Ahead Log）的设计理念一致。变更归档时，Delta Spec 合并回 Main Spec——Main Spec 不是预先定义的，而是从累积的 Delta 中涌现出来的。
四个核心概念
- Main Specs：按领域组织的当前真相源
- Changes：每个变更 4 个文件（proposal/specs/design/tasks）
- Delta Spec：变更原语（ADDED/MODIFIED/REMOVED）
- config.yaml：项目元数据
与 Spec-Kit 对比
| 维度 | OpenSpec | Spec-Kit |
|---|---|---|
| 规范结构 | Delta（增量变更） | Full（全量模板） |
| 变更哲学 | Git 式变更记录 | Word 式文档迭代 |
| Brownfield 友好度 | 高——存量项目分层叠加 | 低——需从头写全量规范 |
| Main Spec 来源 | 涌现（从 Delta 累积） | 预定（先定义再实现） |
关键弱点
- 规范维护成本：规范本身需要维护，项目演化越快成本越高
- 小变更负担重：小改动也需走完整 Change 流程（4 个文件）
- 跨服务编排缺失：原生不支持下，多服务场景需外部机制补充
- 工程文化依赖：要求团队有维护规范的纪律和意愿
矛盾：SDD 终极成熟度模型 Spec-as-Source 的愿景是”改 spec 触发代码重生成”，spec 成为唯一真相源 vs OpenSpec 的设计哲学认为 Main Spec 是”涌现而非预设”——全量规范从来不是目标，增量 Delta 才是自然状态 来自 [[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md]]
任务原子化：上下文隔离的执行单元理论
Jameszyh 提出的任务原子化理论将 SDD 的任务分解从文档层面的”拆得好不好”推进到工程层面的”上下文隔离是否到位”。[[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: 任务原子化]]
三大内在矛盾
LLM 上下文窗口的三个结构性矛盾是 AI 编程质量退化的根因：
- 广度 vs 深度：上下文内容越多，模型在每个主题上的推理深度越浅
- 长任务 vs 注意力衰减：任务越长，模型在后半段的注意力准确度越低
- 并行 vs 串行：多任务共享上下文会导致互相干扰
任务原子化三机制
任务原子化是三个耦合机制的组合：
- 原子任务：每个任务可独立加载、独立执行、独立验证
- 上下文隔离：不同任务运行在分离的上下文中，互不污染
- 子 Agent 并行：隔离后的任务可并行执行
三条核心标准
- 上下文占用 < 50%：30% 留给推理，20% 留给输出生成——预留空余给模型思考，而不是塞满所有 token
- 显式依赖闭合：每个任务输出声明上下游依赖，不自闭就不可靠
- 二元完成标准：完成/未完成二值判定，不接受”部分完成”的模糊状态
四个反模式
- 伪原子任务：表面上拆成小任务，实际上共享同一份大上下文 → 没有真正隔离
- 上下文非隔离：多个任务运行在同一个上下文中 → 相互污染
- 并行无共享真相源：多个 Agent 并行但缺乏共享状态协调 → 结果冲突
- 忽略任务依赖：先执行下游任务再执行上游 → 循环返工
微服务架构同构
一个深刻的类比：任务原子化与微服务架构存在结构同构——服务边界 = 任务边界，API = 文件系统，编排器 = K8s。AI 编程从”单核”向”多核”转变，理论上可线性扩展。[[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: 任务原子化]]
SDD 框架的原子化盲区
批判性观察：OpenSpec、Spec-Kit 等 SDD 框架专注规范结构但缺乏执行隔离——它们把”任务拆得好”等同于”文档写得清楚”，而真正的问题是执行上下文是否隔离。不配合上下文隔离框架（如 GSD）使用时，SDD 框架的原子化是”纸面上的原子化”。[[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: 任务原子化]]
矛盾：SDD 框架（OpenSpec、Spec-Kit）提供了完整的 Harness 覆盖 vs SDD 框架固有地弱原子化——它们专注于规范结构而缺乏执行隔离，必须与上下文工程框架（如 GSD）组合使用才能真正实现任务原子化 来自 [[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md]]
18 种 RAG 技术全景
基咯咯对 18 种 RAG 技术做了系统性对比评分：
| 技术 | 评分 | 关键特征 |
|---|---|---|
| Adaptive RAG | 0.86 | 自适应路由，动态选择检索策略 |
| Hierarchical Indices | 0.84 | 双层索引，先粗后细 |
| Fusion | 0.83 | 多方法结果融合 |
| CRAG | 0.824 | 检索结果自我修正 |
反直觉发现：语义分块评分低于简单 RAG，仅改分块策略不保证提升。0.8+ 技术的共同点是在检索之外引入额外智能层（自适应路由/双层索引/多方法融合）。
技术六层分类
分块 → 检索增强 → 查询优化 → 结果优化 → 智能路由 → 高阶
关键概念速查：HyDE（假设文档嵌入，用生成式模型先构造假设文档再检索）、CRAG（检索结果自我修正，对检索到的内容做二次校验）、RSE（检索增强自我评估）。
[[raw/2026-05-16/基咯咯/18种RAG技术大比拼：谁才是检索增强生成的最佳选择？.md|来源: 18种RAG]]
Perplexity Snippet 压缩：查询感知的抽取式压缩
Perplexity 的 Snippet 生成技术是 RAG 管线中容易被忽视但极其关键的一环：
- 核心思路：查询感知的抽取式压缩——保留原文不重写，只决定哪些文本片段保留/丢弃。不是摘要生成，而是精确裁剪。
- 技术架构：pplx-diffusion 双向编码器 + 轻量级压缩头，用 75 万条 LLM-as-judge 标注数据训练
- 推理优化：层剪枝 28→17 层 + token 级蒸馏，推理延迟降 35-40%，p99 低于 20ms
- BrowseComp 基准测试：压缩后 token 用量降 10-70%，准确率提升 4-4.81 个百分点；“低”压缩预设超过无压缩的”高”预设
- 内容质量提升：压缩后核心内容占比提升 63%，UI/导航减少 58%，元数据减少 46%
非单调效应
一个反直觉发现：压缩后”高”预设反而比”中”预设 token 用量更少——因为更多上下文让模型用更少步骤就得出了正确结果。这说明压缩不是简单的”越少越好”，而是一个非线性优化问题。[[raw/2026-05-21/ChallengeHub/RAG 里最容易被忽视的一环：Perplexity 的 Snippet 压缩是怎么做的.md|来源: ChallengeHub-Perplexity Snippet]]
这与上文 [[#18 种 RAG 技术全景|18 种 RAG 技术]] 中”0.8+ 技术共同点是在检索之外引入额外智能层”的发现一致——Snippet 压缩本身就是一种查询感知的智能预处理层。
SDD 工程化实战：用 Claude Code 做大型重构（2026-06 新增）
扶苏分享了用 Spec-Driven Development 在 Claude Code 里实现大型代码库重构的工程化方法，核心思路是把”做什么”和”怎么做”分离——先写 spec（做什么），再让 Agent 按 spec 执行。与 [[#SDD 六要素与三种模式（ChallengeHub 体系）|SDD 六要素]] 形成互补——一个讲框架，一个讲实战。 [[raw/2026-06-11/扶苏/Spec-Driven Development：用 Claude Code 实现大型重构的工程化方法.md|来源: 扶苏 SDD 大型重构]]
Capihom：Notion 的规范驱动开发工作流
Capihom 分享了 Notion 的 AI 工程工作流程——SDD 的另一种落地形态。核心是把需求规范写成机器可读的结构化文档，AI agent 按 spec 逐步执行。这是 SDD 从”Claude Code 内部实践”走向”通用工程方法论”的标志。 [[raw/2026-06-08/Capihom/规范驱动开发：Notion的AI工程工作流程丨How I AI.md|来源: Capihom Notion SDD]]
设计模式在 AI 时代的重新定位
王顺驰提出”设计模式已死？“的反问。AI Coding 时代传统 23 种设计模式的地位正在变化——AI 能快速生成符合模式的代码，人不再需要死记模式实现细节。但模式背后的设计原则（单一职责、开闭原则、依赖倒置）仍然重要——它们从”代码模板”升级为”spec 描述语言”。与 franslee 的”编程范式重审”（显式优于隐式、直白优于炫技）形成呼应——AI Coding 时代过度抽象和炫技式模式反而增加 AI 理解成本。 [[raw/2026-06-10/王顺驰/设计模式已死？.md|来源: 王顺驰 设计模式已死]]
Matt Pocock Skills：工程纪律的模块化封装
2026年3月，TypeScript 社区知名开发者 Matt Pocock 将自己日常在 Claude Code 中使用的 .claude/skills 目录开源为 mattpocock/skills 仓库。与 GSD、Spec-Kit、Superpowers 等试图”接管整个流程”的框架不同，它的设计哲学是：小而精、可组合、易适配、模型无关——本质上是把软件工程最佳实践封装为 AI 可执行的标准化流程，而不是替开发者做决策。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]] [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
核心哲学：反馈链失效而非模型能力不足
Matt Pocock 提出的核心论点是：AI 编程的失败普遍源于工程反馈链的失效，而非模型能力不足。 需求对齐、测试验证、诊断修复才是真正瓶颈——模型写代码足够快，但缺乏一套让 AI 能持续协作的机制会导致返工成本指数级放大。这与此前 [[#Vibe Coding vs SDD：先易后难 vs 先难后易|Vibe Coding 的代价曲线]] 形成呼应：问题不在代码生成速度，而在校正和验证环节。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]]
六步标准工作流
Matt Pocock Skills 的核心使用流程是一条端到端六步链，从需求对齐到架构维护全覆盖：
/grill-with-docs（需求对齐 + 领域术语沉淀）
↓
/to-prd（对话 → PRD 文档）
↓
/to-issues（PRD → 垂直切片 Issue）
↓
/tdd（红绿重构逐个切片实现）或 /diagnose（六阶段纪律化调试）
↓
/zoom-out（系统视角解读代码）或 /improve-codebase-architecture（周期性架构改善）每一步的定位：
/grill-with-docs是最受欢迎的技能——让 Agent 主动追问模糊点，同时自动更新CONTEXT.md（项目术语表）和 ADR（架构决策记录）。这与 [[#SDD 四阶段模型|SDD 需求分析阶段]] 的目标一致，但实现路径不同：不是开发者写 spec，而是 Agent 通过结构化追问倒逼需求澄清。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]/to-prd从对话上下文中提取信息生成 PRD（问题陈述、解决方案、用户故事、实现决策、测试决策、范围外说明）。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]]/to-issues按垂直切片（见下）拆分为 HITL（需人类参与）和 AFK（AI 独立完成）两类 Issue。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]/tdd严格 Red-Green-Refactor 循环，强制垂直切片（一个行为一个失败测试一个最小实现，而非先写所有测试再一次性生成）。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]] 与 [[#SDD 六要素与三种模式（ChallengeHub 体系）|SDD 与 TDD/BDD 的叠加关系]]（TDD 管单元层、BDD 管行为层、SDD 管架构层）互补——Matt Pocock 的/tdd是这一三层模型在实践层面的具体实现。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]/diagnose六阶段调试纪律：建反馈循环（最关键）→ 复现 → 3-5个可证伪假设 → 插桩验证 → 修复 + 回归测试 → 清理复盘。强调”调试效率取决于反馈速度，而非阅读代码速度”。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]/improve-codebase-architecture扫描代码库找”浅模块”（接口和实现一样复杂的模块），提出深化机会——防止 AI 加速代码熵增。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
垂直切片原则
Matt Pocock 强调的 Issue 拆分原则——按用户可感知的行为拆任务，而非按文件拆任务——是对 [[#SDD 六要素与三种模式（ChallengeHub 体系）|ChallengeHub SDD 任务拆分]] 的具体方法论补充：
错误（水平切片）：“新增 auth utils 文件”、“新增 API 路由”、“新增前端组件” 正确（垂直切片）：“新增 GitHub OAuth 登录按钮”——一个端到端可独立验收的用户行为
垂直切片的好处：每个 Issue 可独立验收，Agent 在较小范围内完成闭环，反馈更快、偏航更容易发现。这与 ChallengeHub 的”对抗式验证”逻辑一致——可独立验收的切片天然适合验证者独立检查。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]] [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
与主流工作流选型对比
Matt Pocock Skills 与五种主流 AI 编程工作流构成完整的选型坐标系，没有绝对优劣，取决于项目阶段和团队需求： [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]] [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
| 工作流 | 关注重点 | 适合场景 | 主要取舍 |
|---|---|---|---|
| Matt Pocock Skills | 需求澄清、测试、诊断和代码整理 | 日常开发、长期维护、小团队协作 | 灵活高，需开发者主动决策 |
| GSD | 长周期任务管理与上下文延续 | 跨天任务、多文件改动、复杂需求 | 流程完整，小任务略显繁琐 |
| BMAD | 角色分工和规范化研发流程 | 0 到 1 产品开发、多人协作 | 体系完整，学习成本较高 |
| Superpowers | 测试驱动开发（TDD） | 重视测试质量的个人或小团队 | 测试纪律要求较高 |
| Spec-Kit | 规格和需求驱动开发 | 企业项目、需求评审和规范先行 | 前期投入大，过程更可控 |
| OpenSpec | 规范驱动 + DAG 产物依赖 | Brownfield 存量项目规范化 | 需维护规范文件和 Schema |
具体场景推荐：
- 日常开发：优先 Matt Pocock Skills
- 跨天大型任务：GSD
- 0 到 1 产品开发、流程要求较重：BMAD
- 特别重视测试质量：参考 Superpowers
- 需求规范驱动的企业项目：Spec-Kit 更贴近
- 存量项目流程规范化：OpenSpec
控制权轴线：手动编排 vs 自动化 vs 规范驱动
Matt Pocock Skills 与 OpenSpec、Superpowers 代表了三种不同的工作流控制哲学： [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
| 维度 | Matt Pocock Skills | OpenSpec | Superpowers |
|---|---|---|---|
| 设计理念 | 工程纪律的模块化封装 | 规范先行，产物驱动 | 端到端全自动流水线 |
| 触发方式 | 用户手动调用 | 用户 slash 命令驱动 | Agent 自动判断触发 |
| 侵入性 | 低——不改变工作流 | 中——需维护规范文件 | 高——接管开发流程 |
| 学习曲线 | 低——每个技能独立 | 中——需理解产物图和 Schema | 中高——需理解完整方法论 |
三者在理论上可以共存：OpenSpec 管”做什么”（规范层）、Superpowers 管”怎么做”（执行层）、Matt Pocock Skills 管”做得好”（质量层）。 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: AgentBuff Matt Pocock Skills]]
安装与初始化
npx skills@latest add mattpocock/skills交互式 CLI 选择要安装的 skill 和目标 Agent。首次安装后运行 /setup-matt-pocock-skills 初始化，配置三项核心约定： [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]]
- Issue Tracker：GitHub Issues / Linear / 本地 Markdown
- Triage 标签：needs-triage → needs-info → ready-for-agent → ready-for-human → wontfix 五状态流转
- 领域文档位置：
CONTEXT.md（默认推荐）、docs/adr/（架构决策记录）、Monorepo 用CONTEXT-MAP.md
初始化后项目会自动生成领域语言术语表、ADR、标签字典等协作文件——“AI 编程环境的第一步，不急着装更多工具，更重要的是让上下文有地方沉淀”。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI Matt Pocock Skills]]
Goal 模式方法论：Agent 执行契约
多条独立来源从不同角度总结出高度一致的 Goal 模式最佳实践——Goal 不是”给 AI 下达的指令”，而是人和 AI 之间的一纸契约，验收标准才是核心。[[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: 6 个 Goal 模板]] [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: Codex Goal 生存指南]]
四要素框架
陈蛋黄提出好 Goal 的四要素，每个维度约束不同类型的风险：
| 要素 | 约束对象 | 说明 |
|---|---|---|
| 目标要硬 | 做什么 | 具体可感知的结果，而非抽象描述 |
| 证据要严谨 | 如何证明 | 日志、测试结果、代码状态等可验证的证据链 |
| 边界是枷锁 | 不做什么 | 明确的”非目标”和范围限制 |
| 停止条件是缰绳 | 何时停 | 完成条件 + 超时 + 相同 blocker 连续出现两次则停止 |
矛盾：好的 goal 三要素（具体 outcome、可衡量标准、明确边界条件） vs 好 Goal 四要素（目标、证据、边界、停止条件——增加了停止条件作为独立维度） 来自 [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: Codex Goal 生存指南]]
六字段模板
万物构想提供了六个即用型 YAML 模板（代码重构、发布流水线、数据清洗、博客写作、测试修复、依赖升级），每个模板包含六个字段：[[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: 6 个 Goal 模板]]
- title：目标标题
- inputs：输入上下文
- success_criteria：成功标准
- common_failure_modes：常见失败模式（如”用 sleep 掩盖竞态”、“只升不测”）
- short_test：快速验证命令——声明完成前运行的二进制状态检查
- deliverables：交付物
模板同时兼容 Claude Code 和 Codex。
Short Test 设计模式
short_test 是 Goal 模式中的关键创新——它是一个快速 shell 命令，在 Agent 声明完成前运行，提供独立的二进制验证手段。与传统”AI 自评”模式不同，short_test 用可执行的 shell 命令做客观验证，避免了”AI 说它完成了”的信任问题。[[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: 6 个 Goal 模板]]
Common Failure Modes 的实战价值
显式列出”哪些错误是 AI 容易犯的”（如用 sleep 掩盖竞态条件、只升级依赖不运行测试）——相比成功条件的泛泛描述，这些明确禁忌更具实战指导价值。
执行前预检机制
陈蛋黄强调 Goal 必须要求 Agent 先执行三件事才能开工：读文档和 AGENTS.md → 输出自己的理解确认 → 发现冲突时暂停。这套预检机制防止”AI 拿到不够清晰的任务描述就直接开干”的误解路径。[[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: Codex Goal 生存指南]]
最终审计不可省略
长任务结束时，Goal 必须强制重新读文档、逐条对齐验收标准、以 git status 为证据。GitHub 社区已有报告：Agent 在上下文压缩过程中逐渐弱化原始 Goal 中的 audit 要求，导致草率交付——因此必须最终强制重新对齐。
哲学视角：Goal 是契约而非指令
Goal 的核心哲学转变：它不是问 AI”你能不能做这个”，而是规定”我们的合作条件是这些”——目标是验收标准（acceptance criteria），不是任务描述（task description）。这与 [[#SDD 三级成熟度与完整模板|SDD 中 Spec 即契约的理念]] 一致，但 Goal 模式将其从”规范层”下沉到了”执行层”。
跨平台链式工作流
陈蛋黄提出 Claude Code /plan + Codex /goal 的最佳组合模式：先用 Claude Code 的 /plan 做方案分析和推理，再用 Codex 的 /goal 做长线执行。两个工具从竞争走向互补——/plan 管”想清楚”，/goal 管”执行透”。[[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: Codex Goal 生存指南]]
2026-07 更新：渐进式 SDD 与 Lattice Harness
Dolphin7 的上下篇把 SDD 从”写完整大 Spec”修正为渐进式规约驱动：先用最小可验证 Spec 固定可接受解空间，再通过执行反馈补充约束、失败模式和验收证据。Spec 不是一次写完的真理，而是当前可验证的约束集合。[[raw/2026-06-30/Dolphin7/爆肝长文：SDD 实战上篇，从 Vibe Coding 到渐进式 Spec驱动开发.md|来源: 渐进式 SDD 上篇]] [[raw/2026-07-02/Dolphin7/爆肝长文：SDD 实战下篇，从渐进式 SDD 到 Lattice Harness：AI Coding 的团队级闭环.md|来源: Lattice Harness]]
Lattice Harness 补的是团队级闭环：单个 Spec 解决”这次任务怎么不跑偏”，团队级 Harness 还要解决上下文、验证证据、漂移检查、Loop/Learn、仓库本地契约和跨任务学习。它不是替代 SDD，而是让多个 SDD 任务之间能沉淀规则和回归证据。[[raw/2026-07-02/Dolphin7/爆肝长文：SDD 实战下篇，从渐进式 SDD 到 Lattice Harness：AI Coding 的团队级闭环.md|来源: Lattice Harness]]
新的操作性定义：Spec 是主张，不是真理；真理在代码、测试、生产证据和用户反馈里。 所以 SDD 必须绑定 short_test、common_failure_modes、final audit 和 drift check，否则 Spec 只会变成另一种漂亮废话。[[raw/2026-06-23/Dolphin7/SDD 实战手记 [09-10] - Loop Engineering：为什么你的 Agent 跑不起循环？.md|来源: Loop 为什么跑不起]] [[raw/2026-06-21/Dolphin7/SDD 实战手记 [08-10] - 落地 Superpowers 后，为什么效率没有同步提升？.md|来源: Superpowers 效率未同步]]
2026-07 更新：未知管理作为 Spec 前置层
Fable 5 使用方法相关资料已拆到专页 [[wiki/concepts/Fable 5 使用方法]]。它补的是 SDD 的前置层：先通过 blind spot pass、原型、访谈、参照物、实现笔记和验收测验把 unknowns 挖出来，再写 Spec 或 Goal。Spec 不应只从”我要什么功能”开始，而应先把人类没说清、见了才认得、甚至完全没意识到的问题显性化。
反向链接
- [[wiki/entities/Claude Code]]
- [[wiki/entities/Codex 与 Claude Code 集成]]
- [[wiki/entities/CLAUDE.md 与 .claude 配置]]
- [[wiki/concepts/上下文管理与 Harness Engineering]]
- [[wiki/concepts/Skills、Agents 与工具设计]]