有一个 GitHub 仓库，shanraisshan/claude-code-best-practice，正在悄悄成为整个 Claude Code 生态的一张地图。写这篇文章时它有约 5.6 万 star，并且常驻 trending。它大部分是一份目录：概念、热门特性、技能合集，以及——最有意思的那部分——一张把十几个最热门 Claude Code 工作流工具放在一起的对比表。
这十二个仓库加起来有超过一百万 GitHub star。它们出自不同的人之手，名字各异，命令语法也天差地别。而目录作者用容易被忽略的一行话点出了一个观察：
所有主流工作流都收敛到了同一个架构模式：Research → Plan → Execute → Review → Ship。
这就是整个故事，值得你停下来想一想。十几个团队，各自独立、都在为同一个工具拼命优化，最后都重新发明了同一条五步流水线。这种事发生在生物学里，我们叫它趋同进化——毫无亲缘关系的物种，长出了同样的眼睛、同样的翅膀，只因为物理规律允许的好答案就那么几个。Claude Code 工作流身上，发生的是同一件事。
把名字剥掉之后的那条流水线
下面是同一条流水线，套在四个 star 最高的工具上。star 数来自 GitHub，2026 年 6 月。
| 标准步骤 | Superpowers（215k★） | Everything Claude Code（203k★） | HumanLayer（11k★） | Spec Kit（108k★） |
|---|---|---|---|---|
| Research（调研） | brainstorming | — | /research_codebase | /speckit.specify + /clarify |
| Plan（规划） | writing-plans | /ecc:plan | /create_plan → /validate_plan | /speckit.plan → /tasks |
| Execute（执行） | subagent-driven-development | /tdd | /implement_plan | /speckit.implement |
| Review（复核） | requesting/receiving-code-review、verification | /code-review → /security-scan → /e2e | /local_review | /speckit.analyze → /checklist |
| Ship（交付） | finishing-a-development-branch | merge | /commit → /describe_pr | /taskstoissues |
把目录里其余的也加进来——Matt Pocock 的 skills（114k★）、gstack（106k★）、GSD、OpenSpec（52k★）、BMAD（48k★）、Compound Engineering、RPI 工作流——形状从不改变。有的把 Research 和 Plan 压成一个”spec”步骤，有的把 Review 拆成三段（代码审查、安全扫描、端到端）。但没人跳过任何一个阶段，也没人调换它们的顺序。
它们为什么都落到了同一处
收敛不是巧合，而是一个信号。它意味着真正在做设计的是约束条件，不是设计者。具体说，是三条约束：
模型是同一个。 所有人都在驾驭同一个 Claude。于是所有人都撞上同样的失败模式，而工作流正是精确地针对这些失败模式搭起来的脚手架——不是针对某种抽象的”好流程”。
放任不管，agent 会直接跳到 Execute。 你提一个需求，Claude 会在第一条回复里就开始改文件。在任何不那么简单的任务上，这通常都是错的一步——因为它在任何人（无论是人还是模型）看过代码库、权衡过备选方案之前，就已经锁定了一种方案。每一个工作流都把 Research 和 Plan 前置，原因只有一个：在”需求”和”第一行代码”之间塞一道门。RPI（Research → Plan → Implement）把这一点做成了字面意义上的门——在 Research 结束、进入规划之前，给出一个 GO / NO-GO 裁决。
放任不管，agent 会过早宣布胜利。 代码一看上去像那么回事，模型就会告诉你”做完了”。没测、没验、“应该能跑”。于是每个工作流都在末尾栓上一道 Review 阶段——而认真的那些，会把它做成一个循环，而不是一个勾选框。在目录自己那张对比表里，复核与测试这两步，正是被标成”会重复直到某个条件通过”的子循环。
后面这条失败模式——交付未经验证的东西——恰恰是 Claude Code 的作者本人点名的最大杠杆。在一条 2026 年 3 月、汇总他最常用技巧的帖子里，Boris Cherny 最斩钉截铁的一条建议就是：“给 Claude 一个验证自己输出的方式。” 他的比喻是：让一个人去做网站，却不许他打开浏览器。给 agent 一个核验工作的途径——一个浏览器、一套测试、一遍复核——它就会一直迭代，直到结果真的好。整个 Review 阶段，存在的意义就是把这一句话落地。
如果你在搭自己的配置，这意味着什么
看着一个 20 万 star、塞了 300 个 skill 的巨型仓库，人的本能是把整套装上。别从那儿开始。这种收敛在告诉你一件更省事、也更有用的事：你要的不是他们那 300 个 skill，而是他们那五个步骤。 价值不在命令名、也不在 star 数——而在步骤之间的那几道门。
每一个上面的工作流，最小、最诚实的版本是这样：
- Research —— 规划之前，Claude 先读相关代码，说清它发现了什么、这个需求到底可不可行。一道门：这是 GO 吗？
- Plan —— 一份你在任何改动之前先批准的书面计划。想强制执行就用 plan 模式（
shift+tab）。一道门：这个方案我认可吗？ - Execute —— 现在它才照着批准的计划写代码。
- Review —— 跑测试，再来一遍核验（或一个子 agent，或换一个模型）检查成果。一道门：它是真验证了，还是只是嘴上说成功了？
- Ship —— 提交、PR、把改动说清楚。
这套东西，三个 slash 命令加一个习惯就能跑，不需要任何框架。那些框架仓库值得在你知道是哪一步在拖你后腿时去淘具体的 skill——但真正重要的是那条流水线，它一张卡片就写得下。
这跟你的 CLAUDE.md 在哪里交汇
这条五步流水线是控制流。你的 CLAUDE.md 则是每一道门的标准所在——在你的代码库里”调研到位”是什么意思、什么算一次通过的 Review、哪条测试命令是权威、什么是 Claude 绝不许在缺它的情况下交付的。多数配置把这些零散地编码在各个命令文件和口口相传的默契里，而这恰恰是为什么两个工程师跑”同一套”工作流，却得出不同结果。
把这些流水线标准从人的脑子里掏出来、写进文件，正是我们在本站 CLAUDE.md 审计里做的大部分事——90 分钟、一份书面诊断、一个重写好的根文件、五套可复用模板。个人 $299，2–10 人团队 $799。如果你的团队已经采用了某套工作流，它却依然表现不一致，缺口几乎总是”没写下来的门标准”，而不是工作流本身。
延伸阅读
- 如何写好一份 CLAUDE.md —— 每一道门的标准该写在哪里。
- CLAUDE.md 写到多大会开始拖慢性能 —— 让这些标准紧到每一轮都真的会被读到。
- 2026 年的 Claude Code hooks —— 怎样把 Review 这道门做成确定性的，而不是指望模型记得。
资料来源：shanraisshan/claude-code-best-practice（目录与收敛观察）；GitHub star 数（截至 2026 年 6 月）；Boris Cherny 的”15 tips”帖子，2026 年 3 月 30 日。