我们是袋鼠云数栈 UED 团队，致力于打造优秀的一站式数据中台产品。我们始终保持工匠精神，探索前端道路，为社区积累并传播经验价值。
本文作者：贝儿
为什么做这次分享
AI Coding 发展到现在，大家遇到的通常不是"Agent 能不能写代码"，而是下面几个更实际的问题：
- 同一个需求，为什么有人一上来就让 Agent 开写，有人却先花时间写规格？
- 产品补了一条规则、接口又调整了，前面做过的分析还找不找得到？
- 第一版已经能跑了，接下来的滚动、图标、状态、异常分支，是继续聊天修改，还是应该进入测试和验证？
这次我调整了实验方向，没有去评估 Spec Kit、Superpowers、Matt Skills 里谁"代码质量更高"。针对同一个需求，主要分析每个方法论的步骤实践直到完成该需求的全链路与留存资产。
这次只回答一个更可靠的问题：这三种方法分别怎样推进一个需求，在哪里停下来做判断，最后留下些什么可复查的资产。
本次实践的共同输入
三篇实操记录围绕的是同一类需求：AIWorks 1.8 的 Agent 节点支持引用现成应用。需求中明确出现了以下内容：
- 在 Agent 节点的关联能力中新增"应用"入口；
- 支持按应用类型筛选、搜索、添加和取消添加；
- 被关联的应用包括工作流和智能体应用；
- 运行日志需要支持查看下层调用链路；
- 不支持循环引用，且要考虑调用层级较深时的展示宽度。
从这个内容可以看到，该需求跨不同模块与组件，业务逻辑不算复杂，但也非一次 vibecoding 就能够实现， 所以采用该需求做实践。蓝湖 PRD作为输入，通过内部lanhu-prd-extractorskill , 提取需求文字说明， 并附件 4张 图片资源。
csharp
实验环境： codex client 端 版本
Powered by Codex & OWL
版本 26.901.51231
发布于 Sep 6, 2026
模型 gpt5.6 T 推理强度 中Spec Kit：先把"要做什么"写成可以追溯的规格书
speckit 1.0.5 版本
这次实操实际怎么走
Spec Kit 的实操记录先用蓝湖提取 Skill 把 PRD 内容变成需求输入，再进入下面这条链路：
latex
PRD 提取
│
│ 资产：需求原始输入
│ - 背景、场景、目标
│ - 关联应用的弹窗规则
│ - 日志下钻和循环引用边界
▼
constitution
│
│ 资产：项目原则
│ - 团队规范、质量约束
▼
specify
│
│ 资产：spec.md
│ - 要做什么
│ - 不做什么
│ - 验收标准与边界
▼
clarify
│
│ 资产：补充后的 spec.md
│ - 澄清结论必须写回规格
▼
plan
│
│ 资产：plan.md
│ - 技术方案、接口约束、实现思路
▼
tasks
│
│ 资产：tasks.md
│ - 任务拆分、实现顺序、依赖关系
▼
analyze
│
│ 资产：一致性检查结果
│ - spec、plan、tasks 是否有遗漏或冲突
▼
implement
│
│ 资产：代码与实现记录
▼
converge
│
├─ 没对齐：把缺口追加到 tasks.md，再回到 implement
└─ 对齐：进入 review
资产：代码 + spec / plan / tasks + 验证与 review 依据这条链路来自实操记录中实际列出的命令顺序：$speckit-constitution、$speckit-spec、$speckit-clarify、$speckit-plan、$speckit-tasks、$speckit-analyze、$speckit-implement、$speckit-converge。
官方对核心链路的定义是 constitution → specify → plan → tasks → implement → converge；clarify 用于补全不明确处，analyze 补充 plan 阶段生成的资产，主要为了一致性校验。
实操里发生了什么
这次并不是一条直线跑完。实验中发现
- 有一次是需求变更，同时发生了接口数据结构调整；
- 有两次属于 UI 展示和交互细节，需要处理溢出滚动与图标大小；
- 最后 review 阶段还发现了重要问题。
对应的处理不是继续叠 Prompt，而是需求变更后重新从 spec 开始；实现完成后，review 不只输入代码 diff，也一起输入 specs/<feature>/ 下的规格、计划、任务。
这一套方法的真实价值
Spec Kit 不是"第一次就把所有细节写对"。实操记录同样承认存在边界问题，图标大小、滚动等细节仍要靠人工发现后修正，页面结构好不好也不会因为有 spec 自动得到保证。
它真正解决的是：当需求变了、接口变了，团队能回头找到原来的意图、受到影响的计划和未完成的任务。 这个结论的证据，就是 实验中真实存在的 spec.md / plan.md / tasks.md 链路、需求变更后重走规格、以及 review 同时审查代码和规格资产的做法。
Superpowers：重点不在前面写多少，而在反馈后怎么收口
superpower 版本 6.3.0
这次实操实际怎么走
Superpowers 的记录把"第一次开发"和"后续修正"分成了两段。
第一次开发：
latex
开始处理需求
│
▼
using-superpowers
│
▼
brainstorming
│
│ 资产：设计结论 / 设计文档
│ 决策：这是普通需求，还是需要较多设计处理的需求？
▼
writing-plans
│
│ 资产：实施计划
▼
选择 Inline Execution
│
│ 资产：按功能块推进的实现过程
▼
实现第一版后续每次收到功能反馈或发现问题：
latex
反馈 / 异常
│
▼
systematic-debugging
│
│ 资产：问题复现、数据链路、根因判断
│ 动作：复现 → 查数据链路 → 对照正常路径 → 确认根因
▼
test-driven-development
│
│ 资产：失败用例与回归用例
│ 动作：先确认红灯 → 最小修复 → 确认绿灯
▼
verification-before-completion
│
│ 资产：验证结果
│ 动作：类型检查 → lint → 相关 Playwright 用例 → diff 检查
▼
显式 Git commit上面两条时序体现出需求落地，到最后可交互走的两条明确链路。
官方基础工作流也明确包含 brainstorming、计划、TDD、代码 review 与完成前验证；其 systematic-debugging 技能强调先找到根因，而不是根据猜测修补。
实操里发生了什么
第一版完成后，记录显示又经历了 6 次修正：设置分类、滚动、图标、实时 Agent 状态、SSE Agent End、Flow End 文本。
这里需要说得准确：6 次不是缺陷率，也不能证明质量好或坏；它只是说明这类需求的第一版之后，仍然会暴露大量交互和状态细节。
个人觉得：第一版 harness coding 会很快，因此可以较早看见需求差异；但前处理没有那么多，后续需要对细节继续调整。
这一套方法的真实价值
Superpowers 的思路没有在前置处理上让第一版逼近"完美"。它快速落成第一版，并没有达到可交付状态，但是却很快让开发者直到还存在哪些问题， 后续把细节调整从随手改动的事情，收进了一条固定的工程路径：先定位，再补回归，再验证。
也就是实践中 systematic-debugging → TDD → verification 这条支线，以及官方对测试优先、系统化调试与验证的定义。
Matt Skills：开发工具箱，关键是开发者怎么使用
matt 版本 1.2.3
先把它说清楚
Matt Skills 的实操记录过程中发现：一个需求的完整链路，通常需要开发者按阶段主动调用；类似一个灵活的工程工具库。
官方也区分了两类技能：用户触发的技能需要用户显式发起；模型可触发的技能则会在任务匹配时被调用。ask-matt 是用户触发流程的路由入口，而 to-spec、to-tickets、implement 组成了可选的工程链路。
这次实操实际怎么走
latex
setup-matt-pocock-skills
│
│ 资产：仓库约定
│ - Issue 管理方式
│ - 标签映射
│ - CONTEXT.md / ADR 的位置
▼
grill-me（两轮）
│
│ 资产：对话中的需求澄清与决策
│ 动作：追问模糊点、边界和异常分支
▼
to-spec + to-tickets
│
│ 资产：规格、任务与依赖关系
▼
implement
│
│ 资产：按任务实现的代码
│ 特点：每完成一组任务会暂停，给开发者做最小可验证检查
▼
code-review
│
│ 资产：规格符合度与代码质量检查结果
▼
交付 / handoff这条链路过程中发现 grill-me与 grill-with-docs 细微差距，可以从资产留存的角度：
bash
/grill-me: 单纯把一个想法/需求问清楚,不写文件，结论留在对话里
/grill-with-docs：仓里问清需求，同时沉淀项目级术语与少量 ADR会写 `CONTEXT.md,`/`docs/adr`这次用的是 grill-me，而不是 grill-with-docs。原因是当前目标只是把 PRD 问清楚，不希望把尚未稳定的讨论写入项目长期维护的 CONTEXT.md 和 ADR。
哪些资产是主动选择出来的
Matt Skills 的资产不是固定套餐，而是随 Skill 选择变化：
latex
只用 grill-me
→ 结论留在对话，不改长期文档
使用 grill-with-docs
→ 结论会进入 CONTEXT.md / ADR
使用 to-spec + to-tickets
→ 留下规格、任务和依赖关系
使用 tdd
→ 留下失败用例与回归用例
使用 code-review
→ 留下规格符合度与代码质量检查这里的边界在于： 如果希望 review 覆盖 PRD 截图、应用设置的空态与保存行为、两层嵌套的 Chat/SSE 展示，不能指望 review 临时想起来；这些验收点要在 to-spec 或 to-tickets 时提前写进去。当我没有说明的时候， spec 中根本不会有这部分内容，所以遗漏也属于正常；
这一套方法的真实价值
Matt Skills 的设计在于把流程决定权留在工程师手里。需求已经很清楚时可以少走几步；需求模糊时可以先 grill；需要沉淀时再 to-spec；遇到高风险问题再加 TDD、诊断和 review。
这些方法在什么时刻有用
场景一：产品说清了大方向，但边界和验收还不够明确
比如"Agent 节点可以关联应用"听起来很明确，但继续追问后，会出现循环引用是否允许、日志展开几层、配置取消是否保存、不同应用类型怎样筛选等问题。
这时 Spec Kit 的价值最大：先把这些问题写进规格，再进入计划和任务。S1 中恰好发生过需求变更和接口数据结构调整，后续需要从 spec 重新开始，并在 review 时把代码与 spec / plan / tasks 一起审查。
场景二：第一版已经能跑，但开始出现很多交互和状态细节
比如滚动、图标、实时状态、SSE 结束文案这类问题，靠一句"再改一下"很容易改出新的回归。
这时 Superpowers 的思路更有用：先定位问题，再补测试，最后验证。处理链路明确是 systematic-debugging → TDD → verification-before-completion。
场景三：需求有疑问，但暂时不想把讨论写进长期项目文档
原稿里 grill-me 的场景可以复用。比如开发者觉得需求描述模糊，想先把异常分支、边界、交互规则问清楚，但这些讨论还不足以更新项目术语或 ADR。
先进行了两轮 grill-me，澄清完成后才进入 to-spec + to-tickets。
场景四：Bug 的根因已知，还是根因未知
Matt Skills 基于官方 Skill 定义的延伸用法
plain
根因明确、影响面小
→ implement + code-review
根因不明确、跨模块或存在状态问题
→ diagnosing-bugs → implement → code-review
风险高、担心修复引入回归
→ 在上面基础上增加 TDD放在一起看：三种方法论在意的事情不同
这不是一张优劣表，而是三次实操留下的三个不同重心：
latex
Spec Kit
第一个问题：需求、边界、验收是否已经说清？
遇到变化：先回到 spec，检查 plan 和 tasks。
主要资产：spec.md、plan.md、tasks.md。
Superpowers
第一个问题：这个方案是否经过设计和计划？
遇到反馈：先复现与定位，再补测试和验证。
主要资产：设计/计划、回归用例、验证结果、review 结果。
Matt Skills
第一个问题：当前真正缺的是澄清、规格、实现、诊断还是 review？
遇到变化：由开发者决定是否重新澄清、补规格或直接进入修复。
主要资产：随着选择的 Skill 改变，可以是对话结论、CONTEXT/ADR、spec、tickets、测试或 review 结果。以上三点分别由 S1 的规格资产与 converge、S2 的调试/TDD/验证闭环、S3 的显式 Skill 组合和资产选择支撑。
最后想分享的感受
同一个需求跑下来，三种方法都没有替我免掉细节调整：UI 的滚动和图标、接口变化、SSE 文本、设置分类，这些最终都还是需要人去确认。
但它们确实改变了"问题出现以后从哪里开始"：
latex
Spec Kit：先问当初的规格和任务有没有跟着变。
Superpowers：先问这个问题怎样复现、怎样用测试证明已经修好。
Matt Skills：先问现在最缺哪一种能力，再选择合适的 Skill。一个更关注把意图留下来，一个更关注把工程闭环跑完，一个更关注让工程师按场景组合能力。
这就是这次实践里最值得留下的结论：方法论不是让 Agent 多走几步，而是让需求、变化和验证不只存在于聊天记录和个人记忆里。
来源
最后
欢迎关注【袋鼠云数栈UED团队】~
袋鼠云数栈 UED 团队持续为广大开发者分享技术成果，相继参与开源了欢迎 star