ARTICLE · 1188534
一个人 + AI,我把软件开发拆成了 10 步
用 Hermes 当大脑、Claude Code 当手，把软件开发拆成 10 步：一个人，也能跑出一个小组的节奏。
过去我自己写代码，一个人要干完一整支队伍的事：想需求、画架构、写实现，再回头测一遍。最累的不是敲字，是脑子里同时开着十几个标签页。
现在 AI 会写代码了，可很多开发者反而更慌——不是不会用，而是写出来不敢信：它到底对不对？它是不是在"自圆其说"？
我的答案是：别靠状态，靠流程。
这套流程我跑了 3 个项目，核心一句话：用 Hermes 当大脑、Claude Code 当手，把软件开发拆成 10 步。一个人，也能跑出一个小组的节奏。
一、先分工，再谈流程
AI 写代码真的不难，难的是"让它做对，而且别骗自己"。
所以第一步不是找工具，是先分工。我给自己定了个清晰的角色划分：
Hermes 是"编排者"，也就是大脑：负责想需求、写 PRD、组织评审、最后拍板。 Claude Code 是"工作者"加"验证者"，也就是手：负责写代码和独立验证。
人（我）只在关键节点出现：确认方向、拍板决策、review 改动。我不盯着它一行行敲，我只管"这件事做对没有"。
二、整条流水线是 10 步
头脑风暴 → 需求分析(PRD)+验证合约 → 需求评审 → 关键决策 → 架构设计 → 架构评审 → 问题修正 → 任务分解(WBS) → 开发执行 → 独立验证。
看着多，其实就两条铁律：
每一步都有明确产出物（PRD、架构文档、WBS、验证报告），不能"想一遍就过"。 每一步都要我确认才进下一步，绝不跳步。
这两条铁律是踩坑踩出来的。AI 最擅长的，就是把"差不多"说成"已经好了"。
三、三个最反直觉的设计
这套流程里，有三个设计我觉得最反常识、也最值钱。
一是"验证合约"。 过去我们是先写代码、再补测试，结果测试被实现"带偏"了——代码怎么写，测试就怎么过。我把顺序颠倒过来：在写第一行代码之前，先定义清楚"完成"长什么样。比如"错误密码 3 次锁定 5 分钟"，写成一条带 ID 的断言。这样验证方是拿需求来对，而不是拿实现来对。
二是"两套模型"。 写代码的 AI（Worker）和验证的 AI（Validator），必须用不同的模型。为什么？同一个模型批自己的作业，很容易"自我感觉良好"。换一套不同训练背景的模型来做独立验证，它真的会挑出 Worker 自己没意识到的毛病。
三是"结构化交接"。 Worker 干完一个任务，不能只甩一句"我完成了"。它必须填一张交接单：具体做了什么、什么没做、跑了哪些命令、退出码是多少、发现了什么问题。就这一张表，让我一眼能看出它到底靠不靠谱。
四、我的工具组合
说下工具，方便你照着搭：大脑是 Hermes Agent，手是 Claude Code（跑单任务用 --bare --effort low 的快模式），中间用一份 model.json 记录可用模型，由"大脑"每次动态挑 Worker 和 Validator 各用哪个。
我不追求工具多高级，追求的是分工清楚 + 每一步留痕。
五、一个人跑起来，是什么感觉
不是 AI 变快了，而是我知道它现在在哪、卡在哪。每个阶段结束，我先看 git diff 确认它真改了、改对了，才让它进下一步；任务拆得够小，避免它干到一半超时无声退出。
以前我一个人，状态好的时候猛冲，状态差的时候停摆。现在流程把"猛冲"和"停摆"都熨平了——它每天都以差不多的节奏往前挪一点。
写在最后
所以如果你也想试试，别一上来就搞全套。
先从你手上一个小项目开始，只跑两步就够：先写"验证合约"，再让另一个模型"独立验证"。大概一个下午，你就能体会到什么叫"敢信 AI 了"。
AI 不会替代流程，缺了流程的 AI，只是更快的混乱。
你现在的 AI 开发，卡在哪一步？评论区聊聊。
