我日常用 Claude Code 做项目开发。之前的工作流大概是这样的：Asana 上有个任务，我把描述复制出来贴给 Claude Code ，等它做完，再把总结贴回 Asana 。下一个任务，再来一遍。
干了几周我就崩溃了。我本质上变成了一个人肉 adapter ，在 Asana 和终端之间来回搬运文本。Agent 明明能自己干活，但它不知道该干什么，干完了也不知道去哪交差。这些上下文全锁在我脑子里，或者锁在 Asana 这种 Agent 根本没法用的工具里。
所以从 2 月开始我做了个开源项目 Chorus，想法很简单：给 Agent 一个它自己能用的任务管理器，让它自己领任务、做任务、交任务。
实际用起来大概是这样：
下面按时间线聊聊这三个月我踩了哪些坑，做了哪些决策，怎么一步步走到现在敢加上 /yolo 命令让 CC 自己跑全流程的。
v0.1 （ 2 月底）：先让 Agent 自己看到活
第一版就是把管道跑通：Idea -> Proposal -> Task -> Execute -> Verify 。
工作流参考了 AWS 的 AI-DLC （ AI-Driven Development Lifecycle ），简单说就是不在现有流程上"加个 AI 助手"，而是让 AI 来主导整个开发生命周期。
我在这基础上加了个"反转对话"的设计：人只负责抛一个粗糙的想法，PM Agent 主动提问把需求聊清楚，然后自己出方案、拆任务，审批通过后 Developer Agent 去领活干。
配合 Claude Code 的插件机制，我做了一个自动注入：每次打开 Claude Code ，插件会自动把当前项目里还有哪些活要干、哪些任务被分配给了你，直接塞进上下文。Agent 一进来就知道该干嘛，不用我再复制粘贴任务描述了。
但很快我就发现，"能看到活"和"能把活干好"之间的距离，比想象中远得多。
v0.4 （ 3 月中）：Agent 太容易"自以为做完了"
跑了两周，最大的问题浮出来了：Agent 说"我做完了"这句话，可信度大概五成。
"代码写了但没测"、"主流程通了但边界没覆盖"，这种情况隔三差五就来一次。Agent 不是故意偷懒，但它确实不会主动对着验收标准逐条检查。
所以 v0.4 加了两个机制：
验收标准 checklist。给每个 Task 加了独立的 AC （ Acceptance Criteria ）列表。Agent 做完后必须逐条自检标记 pass/fail ，然后人或 Admin Agent 再逐条确认。
依赖强制执行。上游任务没验收通过，下游任务压根不会解锁。不是"建议你先做 A 再做 B"，而是 B 的 API 直接不返回给你。
说白了就是不靠 Agent 自觉，靠环境约束。你没法指望 Agent 每次都"记得"检查验收标准，但你可以让它在没检查的情况下根本提交不了。
v0.6 （ 4 月初）：让 Agent 审 Agent ，因为我又成了瓶颈
质量关卡加上了，但谁来执行验收？还是我。
Agent 出了 Proposal 我得看，Task 做完我得验，AC 逐条我得确认。工作量从"复制粘贴"换成了"逐条 review"，但瓶颈还是卡在我一个人身上。
正好这段时间 Claude Code 源代码"开源"了，我仔细研究了一遍它的插件机制，发现 Claude Code 的插件可以定义独立的 agent 。这些 agent 有自己的 system prompt 、自己的上下文，跟执行开发任务的 agent 完全隔离。这就意味着我可以在插件里定义一个专门干 review 的 agent ，它完全没见过开发过程中的上下文，天然就是个旁观者视角来审查。
想明白这一点之后，v0.6 做了这个项目最关键的一个决定：让 Agent 审 Agent 。
在 Chorus 插件里定义了两个 reviewer agent：proposal-reviewer 审方案（接口设计对不对得上、任务拆分合不合理、AC 能不能测），task-reviewer 审代码（实现有没有满足 AC ）。它们有各自的 system prompt 和审查规则，审查记录永久存档。审不过就打回，附上具体问题，Agent 自己改完再交。最多三轮，三轮还过不了才上报人类。
这一步是转折点。之前不管自动化做到什么程度，最后总有个环节卡在我身上。现在接口对不对得上、标准满没满足、依赖有没有画反这些检查都有 reviewer 扛着了。等东西递到我手上的时候，已经被挑过一轮刺了，我只要做最终判断。
v0.6.1 （上周）：/yolo ，全串起来了
到这一步，拼图终于凑齐了。Elaboration 把需求聊透，Proposal 把方案想清楚，Reviewer 把质量守住，全自动的前提条件都满足了。
/yolo 给项目加一个暗色模式，支持系统偏好自动切换
一句话进去，Agent 自己走完整条管道，中间不问你一句话。
Ctrl+C 随时能断，所有已创建的任务都持久化了，随时可以手动接管继续做。某个 Task 反复过不了审，流水线不会卡死，标记成需要人工介入然后继续推进其他 Task 。
实际用下来怎么样
不是每次都完美，复杂 feature 偶尔会在 Proposal 阶段跑偏，reviewer 能抓到一部分但不是全部。
但有两个变化很明显：
一是调试思路变了。之前出问题得从最终代码往回猜 Agent 哪步想歪了，现在直接翻 Elaboration 记录和 Proposal 审查历史就能定位到是哪个假设出了偏差。
二是我的时间释放出来了。之前大部分时间在逐条 review ，现在主要在想下一个 feature 做什么，reviewer 标记"需要人工介入"的时候才去看一眼。
中等复杂度的 feature （ 3-8 个 task ），成功率比我预期的高。Proposal 阶段方向对了，后面基本不出大问题。
用这套机制做的一个项目：Gleaner（Demo），一个纯前端的 GitHub repo 知识库渲染器，帮你缓存和渲染 GitHub repo 里的 Markdown 内容。起因是想有个地方整理知识，但 Obsidian 太重了，我只想要一个轻量的、用 Git 管理的方案。从需求到交付基本就是 /yolo 跑出来的。
Anthropic 发了差不多的功能
上周 Anthropic 发了两个东西挺有意思。Advisor Tool 让 Sonnet 干活时随时请教 Opus ，说白了就是模型级的 reviewer 。UltraPlan 让 Claude Code 先在云端出完整计划再执行，说白了就是 Proposal 机制。一个是"执行时有人看着"，一个是"动手前先想清楚"，跟我在 Chorus 里做的事情高度重合。
项目信息
开源，AGPL-3.0 ，Next.js + Prisma + PostgreSQL 。项目本身就是用 Chorus + Claude Code 开发的，吃自己狗粮。
- GitHub: https://github.com/Chorus-AIDLC/Chorus
- v0.6.1 Release: https://github.com/Chorus-AIDLC/Chorus/releases/tag/v0.6.1
- v0.6.1 详细博文: https://chorus-ai.dev/zh/blog/chorus-v0.6.1-release/
有问题欢迎 Issues 或 Discussions 。
 |
1
jony83 6 小时 10 分钟前
佩服楼主的勇气和毅力，
现在随便一个 TDD 插件都可以做到，oh-my-codex,oh-my-claudecode,superpowers. |
 |
2
fennu2333 OP @jony83 嗯一方面确实想自己写一个实践下，另一方面用下来感觉 skill base 的 TDD 插件用起来很虚，所以我自己在 Chorus 里加了很多校验，强迫 cc 提交证据证明确实按照要求完成了
|
 |
3
Mmnni 6 小时 4 分钟前
厉害
|
 |
4
zenfsharp 6 小时 1 分钟前  4
永远饿不死的，就是 op 这样的第一时间考驾照的黄包车师傅。
|
 |
5
craftsmanship 5 小时 50 分钟前 via Android
🐮 想知道一套流程下来一个需求得烧多少 token
|
 |
6
beimenjun PRO 做了个类似的，做一大半发现市面上泛滥了，于是就没做了。
|
 |
7
UnicellularSU 5 小时 32 分钟前
@beimenjun 还有没有推荐的，你现在在用什么
|
 |
8
aomino233 5 小时 25 分钟前
主要是很多细节达不到要求，要不然前端界面不符合（自己一开始也不知道要什么），要不然后端随意放飞，没有封装和统一。除非是完全新项目，否则不太敢蛮着干
|
 |
9
a186232641 5 小时 25 分钟前
能用 Claude 官方登录？
|
 |
10
firefox12 5 小时 22 分钟前
我问下 你的 cc 怎么买的账号。感觉自己是原始人， 我还是在 chatgpt 里 给个需求，它给我一段代码 我跑一下 给它点回馈 再改改。 我很同意 那个说法 这是用拉老虎机做项目，我也不知道下一次给的代码对不对，是更好了 还是更差了。 很折磨人，一般来说 做点简单的功能 很快，如果是一个复杂的东西 就完全看运气了。
|
 |
11
xing7673 5 小时 8 分钟前
@beimenjun 做了给自己用，做完了可以自己给自己改，有啥问题自己给自己反馈自己跑。现在这个环境下大多都自建服务了，也可以在别人的基础上修改，很方便。
|
|
12
jony83 5 小时 5 分钟前
@xing7673 如果是追求效率的话，不应该，你碰到的问题只局限在你身上，而几万个星几十人维护的项目遇到的问题会比你多比你周到，说白话就是闭门造车。
如果是学习的话，那没问题。 |
|
13
fennu2333 OP @craftsmanship Token 会比直接用 CC 裸跑多出 30%到 50%，但我跑过几个 bench ，比如 PRDBench ，用上 Chorus 之后 Haiku 能跑分超过裸 Opus ，真实项目上没有跑过严谨测试，不过我以后也想研究下能不能实现弱模型➕Harness 的模式来省钱，就算 Token 用得比 Opus 多三倍，用 Haiku 还是便宜
|
|
14
fennu2333 OP @aomino233 大 feature 我会先用 pencil.dev 这个工具和 AI 一起把界面 Design 给画清楚了再干，防止他放飞
|
|
15
craftsmanship 4 小时 25 分钟前 via Android
@fennu2333 个人感觉弱模型这个思路不通 哪怕是 opus4.6 都足以称之为弱模型 随便用了也一样 那时候也许高级模型压根不需要什么 harness 了
|
 |
16
heftyMan 4 小时 16 分钟前
这就是时代的洪流啊，都是过渡期的作品
|
 |
19
dododada 4 小时 4 分钟前
有意思
|
 |
23
hymxm 3 小时 16 分钟前
跟 multica 有点像，类似的还有 slock
|
 |
24
teaguexiao 1 小时 53 分钟前
"Agent 审 Agent" 这个设计挑到最核心的点了，隔离上下文的 reviewer 天然有旁观者角度，比让同一个 agent 自我审查靠谱多了。居然还参考了 AWS AI-DLC ，做云的看到这个是真的親切。
|
 |
25
drbuglu 1 小时 23 分钟前
项目很有意思，提了个小 PR 把进度条的 closed task 计数修了（#157 ）。代码读下来还发现几个可以改的地方，后续有空接着提。
|
 |
27
Edwardlyz 31 分钟前
我也自己做了类似的想法，发现前端不如 multica ，专业性不如 claude-code 配合各种 hook 和工作流，最后扔一边了
|
|
28
drbuglu 22 分钟前
@fennu2333 顺手把 #12 也修了，task reassign 一直报错是因为后端只认 open 状态，前端又放行了 assigned ，对不上。
期待后续的大功能。跑在远端服务器上还挺好的。 |
 |
29
shm7 20 分钟前
参考 https://maxlv.net/blog/porting-mihomo-to-rust-with-claude/
多角色的 agent 体系已经有很多了，很快就能完全串起来了。 |
Select Language