我日常用 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 2 天前
佩服楼主的勇气和毅力，
现在随便一个 TDD 插件都可以做到，oh-my-codex,oh-my-claudecode,superpowers. |
 |
2
fennu2333 OP @jony83 嗯一方面确实想自己写一个实践下，另一方面用下来感觉 skill base 的 TDD 插件用起来很虚，所以我自己在 Chorus 里加了很多校验，强迫 cc 提交证据证明确实按照要求完成了
|
 |
3
Mmnni 2 天前
厉害
|
 |
4
zenfsharp 2 天前  7
永远饿不死的，就是 op 这样的第一时间考驾照的黄包车师傅。
|
 |
5
craftsmanship 2 天前 via Android
🐮 想知道一套流程下来一个需求得烧多少 token
|
 |
6
beimenjun PRO 做了个类似的，做一大半发现市面上泛滥了，于是就没做了。
|
 |
7
UnicellularSU 2 天前
@beimenjun 还有没有推荐的，你现在在用什么
|
 |
8
aomino233 2 天前
主要是很多细节达不到要求，要不然前端界面不符合（自己一开始也不知道要什么），要不然后端随意放飞，没有封装和统一。除非是完全新项目，否则不太敢蛮着干
|
 |
9
a186232641 2 天前
能用 Claude 官方登录？
|
 |
10
firefox12 2 天前
我问下 你的 cc 怎么买的账号。感觉自己是原始人， 我还是在 chatgpt 里 给个需求，它给我一段代码 我跑一下 给它点回馈 再改改。 我很同意 那个说法 这是用拉老虎机做项目，我也不知道下一次给的代码对不对，是更好了 还是更差了。 很折磨人，一般来说 做点简单的功能 很快，如果是一个复杂的东西 就完全看运气了。
|
|
12
jony83 2 天前
@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 2 天前 via Android
@fennu2333 个人感觉弱模型这个思路不通 哪怕是 opus4.6 都足以称之为弱模型 随便用了也一样 那时候也许高级模型压根不需要什么 harness 了
|
 |
16
heftyMan 2 天前
这就是时代的洪流啊，都是过渡期的作品
|
 |
19
dododada 2 天前
有意思
|
 |
23
hymxm 2 天前
跟 multica 有点像，类似的还有 slock
|
 |
24
teaguexiao 2 天前
"Agent 审 Agent" 这个设计挑到最核心的点了，隔离上下文的 reviewer 天然有旁观者角度，比让同一个 agent 自我审查靠谱多了。居然还参考了 AWS AI-DLC ，做云的看到这个是真的親切。
|
 |
25
drbuglu 2 天前
项目很有意思，提了个小 PR 把进度条的 closed task 计数修了（#157 ）。代码读下来还发现几个可以改的地方，后续有空接着提。
|
 |
27
Edwardlyz 1 天前
我也自己做了类似的想法，发现前端不如 multica ，专业性不如 claude-code 配合各种 hook 和工作流，最后扔一边了
|
|
28
drbuglu 1 天前 1
@fennu2333 顺手把 #12 也修了，task reassign 一直报错是因为后端只认 open 状态，前端又放行了 assigned ，对不上。
期待后续的大功能。跑在远端服务器上还挺好的。 |
 |
29
shm7 1 天前
参考 https://maxlv.net/blog/porting-mihomo-to-rust-with-claude/
多角色的 agent 体系已经有很多了，很快就能完全串起来了。 |
 |
30
saltbo 1 天前
我的 agent-kanban 跟你这个差不多，你说的这些坑我也踩了。目前跑的还行，我正在用它重写我几年前开源的 zpan 。踩了不少坑，目前发现还是 system prompt 靠谱，我本来想让 agent 自己去读贡献者文档，然后发现很多时候不会严格遵循贡献者文档里要求的验收标准。
https://github.com/saltbo/agent-kanban |
 |
31
autojunjie 1 天前 via iPhone
实践的经验永远是最有阅读价值的，感谢感谢
|
 |
32
Reminders 1 天前
请教一下，这个和直接使用 claude code 开发有什么不同的地方。
|
|
33
fennu2333 OP @Reminders 我的理解是这样的，CC 本身也是一种 Harness ，他解决的问题是怎么让 LLM 帮你写代码，写了提示词和工具约束 LLM 去遵循一定的软件开发套路。而 Chorus 这一层 Harness 是在 CC 外面给了一套环境，一个更固定的流程和约束：必须把和用户讨论的结果记录在案，必须在每个任务完成时固定启动一个 Agent 去 review 等等。包括前面楼层 @hymxm 提到的 multica 等工具也是一样的，如果把 LLM 比作一个人，那么 LLM + CC 等于 教会这个人按照规范写代码变成 AI SDE, LLM + CC + Chorus 等于把这个 AI SDE 放到一个工作环境里去执行开发工作
|
 |
34
cutchop 1 天前
建议始终使用最顶尖的模型，以后模型的能力越强，harness 需要做的越少
|
|
35
Reminders 1 天前
@fennu2333 #33 这个过程是不是特别适合在 gitlab / github 中，天然就有 issue 、proposal 、task kanban 等。
|
|
36
fennu2333 OP @Reminders 我一开始试过 gh ，也试过在 linear 这样的任务管理工具上做，我写过一个 cc 插件直接把这一套流程跑在 linear 上，结果还是一般。我总结下来不管 gh 还是 linear 都提供了环境，但是不提供约束和反馈，比如有一个 kanban 给 agent 用，但是没约束他 task 和 task 的上下游关系，或者某个 task 他的完成标准一定要启动一个 review agent 从第三方的角度去审查等等。所以我自己做的时候就特别关注给 agent friendly 的反馈。比如在 Chorus 上 Agent 想要标记某个任务为完成，Chorus 给他的报错信息特别具体，“你不能这么做因为 xxx 项目的校验还没有完成” 或者 “上游 xxx 任务还没有完成，你应该先去做 xxx” 等，帮你把这些 drive 流程的 PE 藏在了各个环节里来解决 Agent 做着做着忘的问题
|
 |
37
nullEDYT 1 天前
我的理解 AI CODE 最终的状态应该是 LLM 大模型一运行 就能根据项目提供的文件 就形成了完美的上下文 再去套一层类似 CC 的概念 感觉不太得劲
|
 |
38
callmecaiyuyu 3 小时 55 分钟前
看起来很不错，有点想体验玩玩，但不知道后面 Chorus 更新迭代方便不？怕玩一半后面更新又要重来了
 |
|
39
fennu2333 OP @callmecaiyuyu 哈哈我也是被 OpenClaw 更新摧残得不行，Chorus 开发的时候是最大努力做向后兼容，程序员的职业操守😂
|
 |
40
9684xtpa 2 分钟前
这种对于复杂需求还是很难做到，可是在大公司，都是在复杂需求里做迭代，让 AI 纯自动化去做这种，目前是不可能的，可能经过一段时间的使用迭代标准化，后续部分内容就可以让 AI 自己去做了
但是强如定制化的非标准流程或者说是一些埋坑式定制化逻辑，你让 AI 去做去维护，我目前认为他还是做不到，这类需求我都不敢让 AI 去做 必须承认，AI 的存在，对于很多工具系统，很多已经很成熟的非强业务系统，绝对是降维打击 |
Select Language