开发方法论：AI 编码 Agent 的五步法与四层技能谱系

模型越来越会写代码，但“大活儿”仍会失败：需求没问清就开工，长对话里丢掉决定，改完没有验证，最后把“生成了代码”当作“完成了交付”。问题不只在模型能力，也在工作方法。

我们对照了 grill-me、GitHub Spec Kit、GSD、Superpowers、BMAD 和 Trail of Bits Skills 的公开源码与文档。它们风格不同，却能归纳成同一套五步骨架：问清楚、写下来、拆小块、边做边验、收好尾。

这不是一次短时跑分。方法论是否有效通常要在真实项目中观察数周；本文做的是源码与流程分析，并结合生产项目经验总结适用边界。

第一步：问清楚

Matt Pocock 的 grilling skill 不急着实现，而是连续采访用户，直到双方对问题形成共同理解。它有两条很实用的边界：一次只问一个问题；能从环境中查到的事实由 Agent 自己查，涉及取舍的决定留给人。

这一步解决的不是“提示词不够长”，而是决策权不清。一个可直接复用的协议是：

先逐项问清目标、约束和取舍；每次只问一个决策问题，并给出推荐答案；可查事实自行核验；未经确认不要开始实施。

GitHub Spec Kit 把规格置于代码之前。当前官方流程以 Spec → Plan → Tasks → Implement 为核心，每个阶段生成 Markdown 产物，给下一阶段提供结构化上下文。它还支持扩展、预设和工作流，因此已经不只是几条命令，而是一套可定制的开发流程。

“写下来”的价值是把模糊讨论变成可检查对象。需求应该能回答：什么属于成功，哪些情况明确不做，如何验收，哪些约束不能破坏。写不清楚，通常说明决定还没有做完。

GSD 一类方法把大任务拆成能够放进新上下文的小阶段，并用状态文件记录进度、决定和下一步。它针对的是两个不同问题：任务太大，以及会话记忆不可靠。

拆分不只是列待办。一个好的任务块应该有明确输入、期望输出、验证方式和依赖关系；一个新 Agent 只读项目状态与当前任务，也能继续工作。上下文窗口再大，也不能替代持久化的项目记录。

Superpowers 把规划、测试驱动开发、系统化调试、代码审查和分支收尾组合成完整方法。它强调先建立失败测试，再写最少实现，并在宣称完成前运行验证。

这类强约束的价值不在于教模型“怎么写测试”，而在于建立不可跳过的门槛：没有看到测试失败，就不能确认测试覆盖了新行为；没有运行验证，就不能把代码存在等同于功能完成。

Trail of Bits Skills 展示了更垂直的版本：安全审计技能把特定语言、漏洞类型、供应链风险和误报复核流程封装起来。通用工程习惯可能被更强模型逐渐内化，但行业知识与强制复核门槛不会自动出现。

收尾至少包含测试结果、代码审查、变更说明、未解决风险和可继续工作的状态记录。BMAD 用产品、架构、开发、测试等角色组织一条较完整的流程；Superpowers 则提供审查和完成分支的专门步骤。

全家桶适合从零到一、角色较多或风险较高的项目，小修复则可能被仪式感淹没。正确问题不是“哪个框架最好”，而是当前任务缺少哪一道门。

把 Agent Skills 按作用分层，比按仓库排名更稳定。

层级	作用	随模型变强后的变化	例子
教习惯	先规划、写测试、系统调试	可能逐渐被模型内化	通用 TDD 提醒
管状态	跨会话保存进度与决定	不会被上下文窗口替代	状态文件、交接文档
设闸门	未确认不实施、未验证不完成	属于治理规则，不应被模型绕过	人工批准、测试门禁
装知识	公司术语、领域规则、专业审计经验	模型无法知道你的私有现实	领域词典、安全检查包

这能解释为什么一些技能会显得越来越啰嗦：如果它只重复模型已经掌握的通用习惯，额外上下文的收益会下降。相反，项目状态、人工决策边界和组织专有知识仍然必须显式提供。

不必先安装庞大框架。可以从五个文件或检查点开始：

当某个环节反复失效，再引入对应技能：需求总变，就加强烤问；长任务总失忆，就加强状态管理；“完成”经常失真，就设置验证门禁；进入安全、财务或运维领域，就加载专家知识包。

模型负责提供能力，方法论负责让能力可预测。真正不该外包的，是人的决策、项目的状态、组织的边界与验收责任。

资料复核日期：2026-08-23。正文删除了动态星数、未找到原始实验的 token 降幅，以及无法由一手来源稳定确认的社区数字。