AI 写码质量下降？是你管理错了
If AI coding is lowering your code quality, you're not managing quality right
很多人担心 AI 写码会降低代码质量，但我觉得问题不在工具，而在管理方式。只要采用分层防御策略，不仅能保持 Bug 数量稳定，甚至能减少 Bug，同时让产出翻倍。我的实践表明，Spec-driven development 能让 AI 提前发现需求漏洞和边缘情况；TDD 在 AI 辅助下变得轻而易举；E2E 测试和自动化代码审查也能大幅降低风险。虽然手动测试和复杂变更仍需人工把关，但通过引入 Claude、Cursor 等多层审查，以及利用 AI 自动诊断生产环境错误，我们完全可以在提升交付速度的同时，守住质量底线。关键在于，别让 AI 盲目生成代码，而是用正确的流程驾驭它。
只要采用正确的分层防御策略，提升产出速度就不必以牺牲可靠性为代价；相反，代码代理现在让添加更多、更深入的检查变得比以往更便宜。
HN 评论区
164- zug_zug
我觉得这种思维方式有点过于简单化了。我确实见过不少“工程师要对结果负责，AI 只是个工具，没把握的东西别发布”的说法。
然而，我觉得这并不现实。这相当于要求作者突然变成编辑，要求写代码的人去阅读和调试别人的代码。
实际上，在一段棘手的代码里找 bug，往往比从头自己写出正确的代码更难。我在个人项目中经常看到 AI 引入各种各样的 bug，这些是我自己绝不会犯、也根本想不到要去测试的，尤其是在图形相关的部分。
- axegon_
啊，又是“技能问题”这套说辞。跟五六年大家崇拜马斯克时那套如出一辙，只不过这次换成了 Dario 和 Altman，戴着 Claude 和 ChatGPT 的面具。崩盘来得越快越好。
- chadash
我同意智能体（agents）能写出不错的代码。总的来说，我觉得智能体生成的代码并不优美，但我自己写的代码大多也不优美。把 CSV 文件导入我的 ETL 管道的代码不需要多漂亮，只要能用就行。
我认为更大的问题（就像软件工程中的许多事情一样）是管理问题。曾经，我只要看一眼项目的最终输出，如果它外表看起来像法拉利，我就能比较有把握地认为引擎也是好的。当然，这并非总是如此，但看起来不错、性能良好之类的特征，通常是底层代码质量不错的可靠代理指标。而且，如果是聪明的人类开发者，还会有些附加价值。他们花了 20 个小时写代码，很可能已经思考过他们的经理或产品团队未曾考虑的边界情况。
有了 AI，每个人的产出看起来都像法拉利，这就很难知道内部到底是个什么状况。
很多人看到这篇帖子可能会说“嗯，你需要更好的管理”，但更好的管理在软件工程领域向来难以捉摸。此外，审查 AI 生成的代码是一项令人绝望的工作，我不知道谁愿意干这个。
据我推测，优秀的工程经理实际上非常非常少。在实践中，我见过的最好的经理，恰恰是那些不认为自己很厉害的经理，所以他们只是设定极高的招聘门槛，招来那些不需要太多……
- fishfasell
我觉得要让 AI 智能体持续写出好代码，需要大量的前期设置和上下文。一旦智能体有了这些护栏，我通常能得到极高质量的代码——在大多数情况下，这比我写的要好得多。
我觉得问题变得棘手的地方在于能否用任何语言写代码。我编写和审查很多我不精通的语言和框架的代码，所以我很难区分“能运行的代码”和“优秀的代码”。我能看出基本逻辑哪里错了，但到了“最佳选择”这种层面，我就完全没头绪了。
- Havoc
我会说第 0 步是了解你的受众。
我很开心地在用 AI 搞我自己的玩具项目，但我可不想医院的系统也是这么“凭感觉”写出来的。
而且我不认为这两者之间的差距仅仅是“你只要用对方法就行”。
- teliskr
我从 Claude 那里得到了非常好的结果。我们有一个 22 年历史的遗留系统。系统很稳定，但像所有遗留系统一样，也存在一些问题。Claude 在现代化代码库、更新依赖、审计安全以及快速添加新功能方面表现非常出色。它能很好地配合现有的代码风格和模式。有时它会稍微跑偏，但总体来说非常惊人。
在实现新功能或进行大规模重构时，我会利用它的超能力：头脑风暴技巧。这套流程非常一致，效果很好。我在合并前总会审查代码，但大多数时候只有少数问题需要修正。
我没有做到 95% 的覆盖率，但我已经从 65% 提升到了 80% 左右，这就足够了。
- oefrha
如果 AI 编程没有降低你的代码质量，那说明你的起点本来就很低。
- compiler-guy
楼上的评论提到，智能体要产出好代码需要大量的设置和上下文。这既是对的，又很荒谬。
如果我写的编译器生成了糟糕的代码，我就得修 bug，直到它不再生成糟糕代码为止。
而这正是这场革命中最令人恼火的地方。它显然强大且具有变革性，我在工作中每天都在用。
但许多（或许甚至大多数）提供者似乎一遇到问题就倾向于责怪用户，而不是修复自己的 bug。
通用模型的改进确实起了很大作用，但像“确保你使用良好的风格和编程实践”这种基础事项，真的不应该是用户需要写在任何 .md 文件里的东西。