前几天老板问大家的代码有AI 的占比是多少，大家一致反馈 100%,尽管大家采用的方法论各不相同，但是最终都是没人手搓代码了。这是好事，说明 AI Coding Agent 已经不是一个辅助的角色，而是全面主导了我司的软件开发，相比其他公司也是这种情况。
但是大家没有进一步讨论的是：你还review这些代码吗？
没有人追问，但是从我私下和业界的一些小伙伴们聊，大家基本都不 review AI写的代码了，最多增加一个AI Code Review，通过后直接就提交了。
事实上，或者从我们的经验上来讲，这会产生巨大的slop。
是的， slop这个词最近火起来了，它的意思就是“AI 垃圾”，==专门用来指代由生成式人工智能（AI）大批量、快速产出的低质量、空洞且缺乏人类真诚意图的数字内容（包括文字、图片、视频等）==。这个词被韦氏词典（Merriam-Webster）选为了年度代表字。
很多的业界大牛，比如Claude Code的负责人Boris、OpenClaw的Peter,一直在鼓吹半年前都不再写代码了，开启几十个甚至上百个agent来实现开发。但是讳莫如深的是，他们从来就不真正的谈论是，在他们操控几十个coding agent的时候，是如何避免claude code、openclaw产生slop的，对于agent产生的code,他们是如何review和保证代码质量的。
他们讳莫如深。
也许他们有难以叙说的理由，比如避免抛出一个非公认的方法论引起争议、或者说目前他们也没有太好的办法说出来对他们的产品的声誉有影响，又或者这是一个技术壁垒暂时不想说，不管怎么样，我们更多的是看到大佬炫耀不写代码只负责编排Agent,没看到有价值的方法论的呈现。
但并不是所有人都这样。
Uncle Bob, 本名罗伯特·C·马丁（Robert Cecil Martin），是==世界级软件工程大师、敏捷开发先驱以及畅销书作家==。他是敏捷宣言（Manifesto for Agile Software Development）的签署人之一，并大力推广测试驱动开发（TDD）与软件工匠精神。他是《代码整洁之道》、《架构整洁之道》等系列书的作者。
我很欣赏他的诚实。7 月 23 日他在推特上说道：
我比你年长很多。我开始从事编程工作是在 60 年代末。目前我的策略是不要阅读我的团队成员所编写的任何代码。这是确保他们能够高效工作的唯一方法。相反，我会给他们设定极高的约束条件：单元测试、Gherkin 规范、质量保证流程、质量指标、变异测试、测试覆盖率等等。最终，我对他们编写的代码非常有信心，因为他们必须克服我所有的约束条件和测试挑战。
Bob叔叔很诚实，诚实人的帖子也收到 502 万的浏览和1.8万的点赞，以及 500 多的讨论。
Bob叔叔坦诚不再阅读任何代码，而是通过多种约束条件这个方法论，保证代码的质量和未偏离需求目标。
今天看到一个视频，我还没来得及看，大家可以看看 Michael Guo的总结：
视频地址如下：
https://x.com/0xCodez/status/2091980766372639135/video/1
不管你现在对不code review是认同还是嗤之以鼻，总是有一些工程师在不断的摸索。不code review不是目标，解放人类让AI代替人类完成任务才是我们的目标。她坦诚布公的介绍了她的方法论，如何给agent提供验证能力、如果总结失败的经验，允许agent自动合并PR，如何管理和维护这个流程。
现在，我也不code review AI生产的代码细节了。
对于生成的 Go项目来说，我会关注几个方面：
- 程序的布局：我发现AI coding agent生成的代码都喜欢放到internal包下，而是一股脑都放在这个包下，我会review并让AI划分成明确的子包。保证项目布局的合理性
- 我会使用
/smell嗅探架构和设计中的坏味道，使用/refactor重构项目，让架构更加的合理 - 我在
/to-issues生成卡片的时候，让每个卡片都要有验收条件，这样让AI coding生成代码的时候，不要偏移需求 - 我使用
/review-it要AI review生成的代码，这里有两个检查线，一是单元测试要足够，核心代码一定要有丰富的测试，单元覆盖率要够。而是代码要能编译、lint密问题、代码复杂度不能超过阈值，要符合Go地道的惯用法等 - 现在也尝试使用不同的大模型交叉review,比如claude和codex交叉review
- 提供端到端的测试等
当然，不止于此，我还是想尝试理解(understand) AI给我生成的代码。因为我还面临着一个巨大的问题：如何面对同一个项目中的其他同学。
当其他同学问我一个协作上的问题时，我希望能够立即给出答案，而不是告诉同学：“等我问问AI”。我也在尝试使用、探索不同的方法论，总结一些经验，但是目前还没有一个很好的办法。
我又想起那句话来： “你可以外包你的思考，但是你不能外包你的理解”。
