如果 AI 编码正在降低你的代码质量，那是你没有把质量管理好
AI 辅助编程在工程师中引发了分化：有人把它看作强大的生产力提升工具，也有人把它视为通向难以维护的“垃圾代码”的快捷方式，让审查者不堪重负。许多人认为，代码质量最终取决于人的流程和判断——严格的规格、测试、审查以及对 agent 的清晰护栏——而另一些人则反驳说，在现实世界里管理薄弱的团队中，AI 主要是在放大原本就存在的不良习惯和技术债。争论背后还有一个更大的担忧：组织正在追逐代码速度和数量，却没有建立起维持系统长期可靠所需的文化、激励机制或防护措施。
对代码质量的影响
- 分歧很大：有人说 AI 产出的代码可以和他们自己写的一样好，甚至更好；也有人坚持认为 AI 代码天生更草率、难以维护。
- 批评者认为，很多开发者并不能可靠地判断“好”代码，尤其是架构层面，所以他们会高估 AI 的质量。
- 支持者声称，最近的模型在正确使用时能产出高质量代码，尤其适合细节、重构和旧系统现代化改造。
- 还有几位指出，AI 主要是在放大现有实践：优秀工程师会变得稍微更好；普通工程师则会产出 10 倍更多的坏代码。
流程、护栏与测试
- 很多评论强调，质量来自传统实践：清晰的规格说明、验收标准、代码审查、lint、类型检查、复杂度检查，以及扎实的测试。
- 积极、可执行的指令（“在写新 helper 之前总是先搜索现有 helper”）比“不要做 X”这类规则更有效。
- 有人报告说，实施后由 agent 进行“审计轮次”，寻找重复、命名问题和样式违规，效果不错。
- 对测试的强调非常强：单元测试、性质测试/模糊测试、差分测试、golden master、覆盖率。有些人认为，仅看覆盖率百分比并不能很好地代表质量。
生产力与审查负担
- 报告的收益从温和提升到绿色领域单人工作中的“10 倍”不等；在团队场景中，50% 到 100% 的提升被认为更现实。
- 也有人说，一旦把严肃的审查和重构都算进去，AI 实际上并没有节省多少时间。
- 审查工作量是一个主要痛点：AI 让巨大的 PR 成为可能，而人类无法完全理解，尤其是在大型组织和开源项目中。
管理、激励与责任
- 许多人认为，AI 本身并不会“摧毁代码库”；决定是否合并的是人和管理流程。
- 另一些人反驳说，不现实的速度预期让彻底审查变得不可能，实际上是在强迫低质量地使用 AI。
- 关于把责任归咎于用户“没有正确使用工具”是否公平，也存在争论；有人认为应该要求工具提供更好的默认设置和更安全的行为。
Agent 化与递归式使用
- 递归、agent 化的工作流（AI 反复修改自己的输出）被认为尤其危险，若没有严格的人类引导，很容易变成“随机游走”式的意大利面代码。
- 有些人认为，当前的提示词和护栏技术还不足以安全地让 agent 在复杂、非样板化系统上无人监督地运行。
态度与工匠精神
- 一个反复出现的主题：把代码当作工艺来关心，还是“只是份工作”。
- 那些把 AI 当作助手并维持高标准的人，通常报告更好的结果；而那些“凭感觉写代码”并只要通过最低检查就发版的人，效果更差。