最近一直和一些团队进行Vibe Coding相关的实践和探索，有一些有趣的感受，今天有看到InfoQ上的一篇文章《Cursor 的 bug 太多了，他们直接买下一家代码评审公司来修！》，觉得和我最近的思考挺契合，就分享一下。
先看一下这篇文章的几个核心内容：
这笔交易相当于是把 AI 时代“创建、评审、合并代码”的最佳工具组合到了一起。这三件事里，Cursor 实际上只做了其中一件——写代码，另两件则是 Graphite 的强项。
根据 Graphite 公司分享的数据，相比 2023 年，现在每位工程师产出的代码量大约多了 70%。主要问题在于，代码可以指数级增长，但工程师的时间仍然是人类尺度的时间。
Stacking 的核心变化在于：把变更的基本单位从 PR，变成了单个 commit。在 stacking 模式下，你会把一个大的改动拆成许多个小改动。每一个改动——也就是一个 commit——都可以被单独测试、评审、合并，甚至单独回滚。
一点启发
就连Cursor这个在Vibe Coding领域的领先者都遇到了代码评审和合并的问题，说明在AI辅助编程的过程中，代码质量和协作流程依然是不可忽视的挑战。当我们还在为Copilot或者AI编码工具能够帮我们快速产出代码，大幅提高生产力而兴奋的时候。一些危机已经悄然出现：
- 生成容易，维护难，人已经跟不上生成速度：AI可以快速生成代码，但这些代码往往缺乏一致性和可维护性。没有良好的评审和合并机制，代码库可能会变得混乱不堪。
- 团队协作复杂度增加：当多个开发者使用AI工具生成代码时，如何确保代码风格一致、功能不冲突，成为一个新的挑战
- 魔法打败魔法？：考虑用AI工具来做代码评审，魔法打败魔法？看似合理，但实际上可能会引入新的问题，比如AI评审工具的准确性和偏见问题谁来把控？
- 业务知识的丢失：以往开发人员编写代码会先理解业务需求，并在改进功能的同时优化代码结构。这个过程其实也是加深业务理解的过程，而AI生成代码的过程，已经不需要开发人员理解整块理解代码结构，缺乏这种深度理解也让业务知识的传递变得困难。
我们的实践
我和一些团队进行的Vibe Coding实践中，也遇到了类似的问题。所以对这篇文章提到的内容特别有共鸣。开发人员最开始以为AI工具可以大幅提升生产力，但随着时间推移，大量业务代码的生成后依旧无法逃脱的一个最主要矛盾——如何避免修改一个地方不会影响其他地方好用的功能。 有些小伙伴会说，让AI生成单元测试等自动化测试。以前咱们人写对能写单元测试的程序员要求高，现在AI生成测试，应该更容易了。事实给了我们一记响亮的耳光：如果你的业务代码已经生成，AI生成的测试很多时候只是空壳子，他无法生成有效的测试。当你深入探寻具体原因的时候，你会发现原因和没有AI时候一样：代码不可测试 。
我们不得不重新回到以往的那个问题：好的软件工程的实践有哪些。TDD这类传统的实践依然是解决问题的关键。我们做了如下调整：
- 传递业务知识：在Vibe Coding过程中，开发人员通过markdown文档描述业务上下文，让AI理解业务需求。
- 生成思考过程：了解业务需求后，不着急生成代码，先让AI生成任务列表，方便人类审核是否存在理解偏差。
- 保留记忆：让copilot这类代码生成工具将上面的思考过程写入记忆库中（也是markdown文档）。这个记忆库就像是一个上下文活文档库，让AI在后续生成代码的时候，能够参考这些业务知识。同时确保这个记忆文档持续更新。
- 测试驱动开发：在生成代码之前，先让AI生成单元测试，再基于TDD的工作方式生成功能代码，同时确保每个测试都是通过的。这功能实现的同时，测试也留下来，之后可以作为回归测试集，确保后续代码修改不会破坏已有功能。（Note：这些测试也是一个活文档，帮助AI从另一个角度理解上下文。）
- 每次只做一点点：迭代思维方式，小步快跑，这些都是好的软件工程实践。AI生成代码的过程也不例外。碎片化大功能，每次只做一点点，不仅方便验证结果，快速调整方向，也方便后续代码的维护，甚至是代码合并时候的review以及冲突解决。其实我们在没有AI的时代，也是很反感大段代码提交的。难道你不是看着好几百行代码Pull Request就头大吗？
小结
我们不难发现，不管是否有AI的帮助，好的软件工程实践依然是解决问题的关键。高效软件工程师有了AI工具的夹持会变得更强大，而普通的软件工程师有了AI工具，可能会产出更多的垃圾代码。不过也从另一个角度看到，不好的软件工程习惯会被AI快速放大，让有观察的程序员发现问题并及时做出调整。就像我最近合作的团队，他们之前也不喜欢做单元测试，但是使用Vibe Coding之后，他们发现TDD的好处，开始学习TDD，并大范围使用。是AI让他们看到了更好的软件工程实践的价值。
让我们借助AI的力量更好的进化自己到下一个阶段吧。
