fennu2333

搞了一套机制让他自动 review 测试修改，但是要花很多实现事先对需求。所以就变成了所有的等待时间都在和不同项目/功能点上对需求

@wdv2ly 主要是以 skill 的方式工作，不过在 cc 的插件里有大量的 hooks 控制 cc 的行为。在 ui 上创建得分两个角度看，一方面 openclaw 插件已经实现了在 ui 上分配任务，openclaw 会自己 pick 任务开始干，另一方面 cc 还没实现，我还在等 cc 官方把长链接唤醒 cc 的功能开放给三方插件用。不过其实 chorus 中 agent 是一等公民，所以每个 agent 都会有自己的通知系统，cc 启动的时候会注入最近分配给他的任务等等信息，方便启动，理论上你只需要让他看下最近的通知他自己就知道分配给他啥任务了，但目前确实省不掉手动踹一脚这个动作

Fable 反正也上了 AWS bedrock 之类的云 MaaS ，那些肯定不会下

@Chuckle 其实有点像 cc 的 dynamic workflow 了，大规模试错收敛到最优解，在一些探索性的，或者对维护性要求不高的场景我试下来除了烧 token 之外确实不错的

@shawnvan 我觉得钉死业务也没有问题，在 Chorus 里我加了 OpenSpec 集成，我觉得 OpenSpec 的思路就很清晰，需求是随时会变化的没有问题，但你让 ai 写实现的当下需求是确定的，并且这些需求是可以逐步通过 diff 语义来打补丁的。每次开发都绑定在一个确定需求上，如果需求有变，那么针对 diff 部分的需求进行 diff 的开发。现在已经和以前那种你开发到一半需求突然变化的时代不同了，需求变化的时候很可能你上一个需求 ai 已经完成开发了。所以没有关系，把需求变动看作原子需求，每次开发都是完成这个 diff 就好

@lovedebug 是的，宁可把复杂度左移也不要寄希望于 ai 帮你把所有问题想明白然后做出完美实现

@wdv2ly 目前我自己使用的方式其实有可以抛去 ui ，比如在 claude code 上安装好插件，配置好链接之后，直接用 /chorus skill 提出你要做的事，他会自动选择 workflow 流程去推进，主动和你对需求写 spec 。整个流程还是 claude code 在 drive 。只不过中间的追踪和记录都会保存在 chorus 后端，也方便你在 ui 上 review

@wdv2ly 嗯，我的目的是想不打破使用 cc 的方式, 写代码还是在 cc 上。可以看下 https://github.com/slopus/happy 这个项目，可以做到在服务器/本地常驻 cc ，然后通过手机等客户端给 cc 发任务，搭配 chorus 就能实现远程管理 cc 对话 + 任务了

@beimenjun
@kuhung
没错，不降低人在工程上的决策成本，但是左移我觉得最大的益处有两个，一是对未来发散方向的剪枝，第二个是把人类输入全部压到左边，实际就可以做到让 agent 在对齐好的任务上持续跑出结果，而不是时不时你需要去看他一眼