Vibe coding 了半年，最后发现最有效的手法是朴实无华的左移

[fennu2333]

我从年初开始，不管是自己的开源项目还是工作，99.9% 的代码已经是 CC 写的了，顺手做了一个开源的 harness 叫 Chorus 想把自己的一些实践写到里面去，整了很多功能比如细化需求啊，自动 review 啊等等

现在累计了一些用户，包括我自己每天也是高强度使用，这半年下来最大的感觉用了那么多手法，是“左移”才是最有效的

为什么 vibe coding 特别需要左移

软件工程里 shift left 是个老概念，把测试和质量挪到开发早期，比写完再抓有效得多。AI 时代这个套路收益更大，因为 agent 写代码飞快，但它对你想要什么的理解是无法保障的。

理想情况是你交代一个任务给 AI ，他 kuku 一顿操作就给你完成了，实际情况是这根本不可能，毕竟你这一句话里的信息量实在太少了，大部分要靠 AI 自己猜。我之前发了一个帖子调查大家理想的 Agent 交互方式 https://www.v2ex.com/t/1215829 大部分人都希望一句话直接撬动成果，但现阶段这么做估计会一地鸡毛

返工成本看着低，反正它写得快嘛。但人 review 的时间是真金白银，而且每改一轮上下文就乱一点，最后连最初想要什么都模糊了，最后就向着💩山一去不复返了。

让 agent 干活之前先完全搞清楚你脑子里是啥这一点远远胜过其他花里胡哨的技巧。我问了几个朋友，superpowers 插件里用的都是啥功能，结果绝大部分的人用一个 brainstorming 就结了，小部分人还会用 systematic-debugging, 这俩一个是左移一个是捅了篓子之后擦屁股

Chorus 里左移长什么样

我大概是这么搞的。

第一步是 Elaboration （细化）。粗糙的想法扔进来，Agent 主动追着问。"这个搜索是只搜标题还是带正文？""精确匹配还是模糊？""结果排序按什么？"几轮聊下来，需求就被拍扁成一份明确的描述。关键是 agent 在追问，不是人在写需求文档，门槛低很多。其实和 Branstorming 有点像但所有的决策都会记录在案，方便回看或者交接工作。有的时候想回忆起某个 Feature 做了啥，我去 Chorus 的 UI 上看一眼和 Agent 的问答记录一下就清晰了

第二步是 Proposal （提案）。Agent 基于敲定的需求出方案，包括接口怎么改、任务怎么拆、每个任务的验收标准是什么。这份方案先过一个独立的 reviewer agent 对抗检查，确认接口对得上、任务粒度合理、AC 可测，才递给用户拍板。从这个阶段开始用对抗的方式保证 Agent 写的东西真的方向对而且可以验收，而且这个单独的 Review Agent 也可以充分利用前面环节细化的记录，从第三方视角观察着一份提案有没有跑偏。

第三步是每个任务自带的验收标准 checklist 。Agent 写完代码不是说一句"我做完了"就完事，得逐条对着验收标准自检，再过一个 task-reviewer 对抗校验。这里的 Task Review Agent 又能充分利用前面细化和提案的记录来保证任务本身有没有执行歪。

这些步骤其实就为了一件事：对齐挪到前面、校验放到后面，中间写代码这段就基本能放手了。当然 Proposal 阶段偶尔也会跑偏，但概率比让 agent 直接动手低一个数量级，跑偏了 reviewer 也大概率能挡住，比撒开了写代码再改好多了。

顺便聊聊最近超火的 Claude Code 的 Workflow

最近 Claude Code 出了个 Workflow 功能，你说一句需求，主 agent 会动态写一段编排脚本，搞出几十上百个 subagent 并行跑不同维度的搜索、审查、合成，最后把结果收拢回来。

这玩意很牛，但解决的是另一个问题：在解空间不确定的时候，用 token 换覆盖面。单 agent 顾不过来 10 个维度，那就开 10 路并行各管一摊，再用一组对抗 agent 反驳每个发现，留下经得起怼的那批。

但 Workflow 不是左移。它是动手之后用更多 agent 探索更优解，重心在执行端的扩散和收敛。token 消耗是单 agent 的几十倍起步，而且 Workflow 本身的对齐环节相对轻，主要靠主 agent 一开始的理解，没有像左移那样反复跟用户确认。

我自己的体感是，绝大多数日常 coding 任务的瓶颈不在"探索得不够广"，而在"开头没聊清楚"。开头方向歪了，扩散得再广也是在错的方向上扩散，最后还是要返工。

Workflow 适合那种你已经知道要什么、只是解空间太大、得靠对抗验证的活，解决方案探索啥的。日常开发主体还是要靠左移把对齐做扎实，我觉得目前 Harness 的最大作用不是搞出一大堆流程和 Agent 去干活，而是把你脑子里的东西对齐给 Agent 而且保证他按照这个思路执行到底

代码都在 Chorus 仓库，欢迎讨论。

[everyx]

当前的 AI 在已有的代码库上进行重构、改 bug 、或者做一些小 feature 的，都挺好，就是从头开始一个项目太靠人的经验了，经常到后面就失控了，要推翻前面的一些决策 😂

[mooncakeSec]

一样的，我大概 80%时间在跟 ai 聊需求和设计，基本不 review ，人的注意力没办法拓展，守着 review 永远是瓶颈

[gibber]

你这三步不就是几个 skill 吗

[miniliuke]

和现在的 superpowers 、openspec 、grill-me 这一类 skills 啥区别？

[fennu2333]

@gibber
@miniliuke
不一样的是我有一套完整的 Service + CC hooks 在插件里。打个比方其中一个环节，在 CC 里启动 reviewer Agent 进行 proposal 的审查，就是 Hooks 触发的，不像 skill 那样没有约束力，而且在 service 层对 Agent 往前推动流程也有强校验，比如 AC 是否标注完成等等。光是 skills 很难说自己是一个 Harness

[beimenjun]

虽然知道是一个营销帖子，但是个人认为，很多时候，程序员面临的真正的问题还是软件的复杂度的。

左移很多时候只是把复杂度提前了，甚至有些时候复杂度还会因为不合适的左移的操作额外增加。

一直在左侧打磨，感觉是把代码的工作换了种自然语言的方式来实现。如果大型重构的时候，其实是会陷入一个“假装自己在左侧，其实早都在开发泥沼”的状态。

而小项目或者要求不高的大项目，其实左移和原来流程最终产品区别，真的很大吗？

对于一个产品，更关键的其实是 AI 时代的功能的取舍，要抵制住诱惑，不能因为有 AI ，就乱拍板功能。只要一个东西够简单，那么它就不可能复杂。

对于整个行业来说，现在很多领域，都缺少类似前端 playwright 那类的框架，稳定高效同时廉价，可以更好地做出端到端测试的基础建设，感觉对于 AI 编程的发展会更重要。

[v2exgo]

没啥用，其实现在 AI 的能力很强了，写代码不再是一件重要的事情，过去项目一催一赶，就是一堆人去编码，别管三七二十一，先上线跑起来再说，而现在代码不再是问题了，问题是如何架构整个系统，如何让 Agent 更好的跟系统协作，人应该参与哪些环节，编码本身的价值越来越低，甚至做什么算法题更加就是笑话了。

现在应该好好再想想怎么把传统软件工程那些最佳实践，以及防止人犯错的那套玩意，重新搬运到新的 AI native 开发里面。

要重新认识到 架构先行，而不是拿到需求搞编码先行，最终通过代码架构管理的方式来减少人跟 Agent 的犯错。

像有些公司已经在搞 AI 全栈，但是整个项目是一塌糊涂，基础架构层代码、核心业务逻辑、DAO 层 消息队列、边缘业务逻辑 都在一个浆糊里面，这种破烂老项目，你给它再好的 Agent 生成出来的也是一坨屎，甚至我之前的领导还认为 AI 能力这么强了，过去的软件工程最佳实践都可以丢了，让 AI 去生成一堆重复的屎山就行了,那只会让系统更烂

我觉得像 DDD 那些啰嗦的东西 反而又可以回来了，因为编码本身成本降低了，开发者最大的困难在把控上下文边界以及如何减少 Agent 生成错误的代码，像 DDD 里面的上下文限界这些理念本身就是跟 AI 上下文管理重合的

[kuhung]

同意楼上 beimenjun 看法 另外我认为无论怎么移，都还在编码这个讨论范围内。其实完全可以大胆一些，先别编码或事简单编码，做需求验证先。

[xiongr]

可能搞了一个大轮回后，发现 Token 烧的成本，并没有比现在人工更低，在过程中的浪费量太大，就肥了卖铲子的。

[fennu2333]

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

[wdv2ly]

我大概能理解这个项目的设计理念，但尝试了几次都被挡在入门环节。我最大的疑惑：设计上，agent 似乎是要自己注册的，也就是说，我需要自己开 cc/codex session ，在 session 内注册，这时候我在后台建的任务什么的才会被分配下去，整套系统才能运转起来，我理解的正确吗？如果是这样的话，那是不是这个 session 要常驻存在（跨多个项目？）

[fennu2333]

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

[shoushen]

不错。核心就是用细化和提案来限制解的范围，用 checklist 限制解的过程。

[lovedebug]

复杂度不会消失，只会转移~

[shawnvan]

从某种意义上就是退化到瀑布开发模型，只是具体的开发任务交给了 ai 。但是这种方式并不适合实际的产研情境，即使是个人开发者，也是不太适用。不提在需求明确阶段无论是通过对话还是头脑风暴都不能确保覆盖全场景，就光一个业务侧的需求变动，就会导致左移的大部分工作报废。ai 编码，本质上就是把人从变化环节解放出来，能够在各个阶段去思考业务，思考需求，而不用去关注实现。你这个思路，恰好相反，要求敲死业务，定死需求，关注点全在实现上。

[wdv2ly]

@fennu2333 #12 远程控制这个我知道，但是我还是有疑问，接入你的工具后，不是应该变成「我在后台建 idea/task ，系统自动分配给 ai 去沟通/完成」的模式吗？那就已经打破使用 cc 的方式了呀（工作入口转移到 chorus ）。还是说我哪里理解的不对？

[qiaobeier]

@mooncakeSec 外包项目没问题，我看都不看一眼。但是我公司的代码可不敢不 review ，这可是真真正正影响我饭碗的事情。

[fennu2333]

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

[fennu2333]

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

[fennu2333]

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