早上严肃学习了佬友的文章 【木子狸的Vibe Coding随笔】 总1w5字 VibeCoding 真解 刚好最近也在读《人月神话》，加之实习一个月了也想沉淀一下阶段经验，于是写了这篇文章。
全文0ai润色，纯手搓，遇到难懂的地方一定就是我输在了表达上，佬友见谅。
用codex、claude code cli 等 coding agent 进行软件开发的本质是多人接力协作开发。实际上与LLM的每轮对话就是与一个全新的“人”在对话，而与coding agent的每轮对话就是与一个 能看到历史接力情况的 “人”对话。
一、概念完整性，新增的代码能不能与代码库中已有代码相洽。
“概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。”，这是《人月神话》中的原话。而coding agent本质上是多人接力协作，可以让ai出整体的开发“纲领”，而开发过程中这个纲领性文档的维护一定不能放任coding agent去做，如果交给coding agent去做，可以理解为概念完整性交由一群“人”来设计了。
我的尝试：对于prd、trd等文档在产出时一定要最大程度去理解，看明白整个文档思路。coding agent review 出建议修改点之后利用codex的“在侧边聊天中提问”搞清楚每一个建议点，避免跑偏、过度设计。prd、trd等文档确定后，在开发过程中尽可能就不要再去修改了。
二、vibe coding 时项目随着开发进行复杂度不断上升，逐渐失控的问题。
也是《人月神话》中提到的经典问题，随着人手的增加，项目的开发效率并非一直提高，甚至过多的人手投入会导致项目进度滞后。我认为这也正是大家都深有体会的vibe coding的痛点，本质上还是因为coding agent是多人接力协作，这导致vibe coding时，你发了几轮提示词，约等于你让几个“人”投入了当前项目，所以项目的复杂度会越来越大逐渐不可控。
我的尝试： 重视提示词工程。比如说现在要让ai帮我做一件事，这件事又涉及a、b、c三个步骤，不要先让ai做a，做完了跟ai说继续做b。而是，一段提示词里交代明白。前者相当于三个人协作完成了一件事。重视任务拆解。有了上述直觉，任务拆解显得尤为重要，你让ai完成的这一件事的粒度大小要把控好。
三、coding agent能不能代码写好，核心在于“单一职责”。
在实际工作中，面对产品给的一份初始prd，我们通常的做法就是先转成研发可用、ai可读的prd。接着，将prd转成trd。最后，按照trd实现。那么将prd转trd的环节是有多种做法的：1. 一份prd直接转一份trd，这一份trd中拆多个task。2. 一份prd转多个trd切片，每个切片是按照“单一职责”从prd中拆解出来的，单个切片内的task数恰到好处。
我的尝试： prd按照单一职责去拆成多个trd切片，开发时一个session完成一个切片的实现，下一个切片开新的session实现。
四、方向可以让coding agent定，但掌舵的一定是人。
coding agent本质上是多人接力协作开发，项目主线一旦交给了coding agent，等于说交给了一群“人”，走偏是必然的。 随着coding agent与LLM越来越强大，代码能力相对来说变得不那么重要了，软件工程直觉才是做好vibe coing的关键。如何培养软件工程直觉、工程思维？这里也向佬友们抛出一个问题，希望佬友们能给点建议、推荐点相关好书。
五、ai写的代码人一定要看。
这点大家都清楚，但痛点在于人怎么去review coding agent写的代码？
我的尝试： 系统视角和用户视角双视角解释新增代码做了什么？让coding agent基于新增代码说一说这给系统带来了什么新的能力？用户使用时可感受到什么变化？如果从双视角看都没有太大问题，就可以进入代码走读。代码走读一定要基于数据流出发，数据流串起了代码的生命线，看看数据最初从哪入？长什么样？顺着数据流去走读代码。
六、很多时候会发现coding agent给的trd是脱离代码库实际实现风格的、甚至是脱离架构风格的、是不符合概念完整性的。
我认为根本原因在于coding agent在写trd时没有基于已有代码，这放大后期根据trd实现代码时的问题，实现时轻易就写出了破坏系统概念完整性的代码。
我的尝试： codegraph注入trd skill。codegraph能够有效缓解这一问题，我的trd skill是自建的，核心点就是我让它用codegraph充分获取代码库已有代码事实再去写trd。
注
codegraph是github上的一个开源项目，感兴趣的佬友可以去看下。
欢迎佬友们交流vibe coding的经验、给出相关建议。
。中间涉及到的可行性，我会让它列举出可行性和风险点，最终由我来敲定是否实现。
）