全面强制 AI 编写代码一年后，没人看得懂代码了
一篇在 Reddit 上疯传的帖子称，一个强制要求 AI 生成代码的团队如今已无法解释自己的代码库。这对基于 LLM API 构建应用的开发者意味着什么。
帖子究竟说了什么
标题很直白：全面强制 AI 编写代码一年后，没人看得懂代码了。据 Reddit 帖子所述并在 Hacker News 上被放大传播，其说法是：一个团队将 AI 生成的代码作为默认做法，如今正为理解和维护付出代价。
这里需要谨慎。这只是来自网络论坛的一则轶事，并非对照研究。我们不知道代码库的规模、审查流程，也不知道团队的人员资历构成。应将其视为一种可能出现的失败模式的信号，而非普遍结果的证据。
为什么理解债务会不断累积
无论代码由谁或由什么编写，团队中没人能解释的代码就是一项负债。当某个模块出现缺陷，而没有任何人对其逻辑进行过推理时，调试会变得极其缓慢，每次改动都带来额外风险。这正是该帖提出的核心担忧。
如果 AI 生成与薄弱的审查相结合，就会加速这一问题。如果代码因为测试通过而被合并，而测试本身也是生成的，团队可能对实际行为缺乏独立理解。这种债务在生产环境出问题之前是看不见的。
这对基于 LLM API 构建应用的团队意味着什么
如果你在 LLM API 之上交付产品，同样的动态也适用于你自己的集成代码：提示模板、重试逻辑、模式校验和回退路径。这些恰恰是生成代码可能看起来正确、行为却出人意料的地方。
一种实用的做法是：要求至少有一名工程师无需逐行阅读就能解释每个关键模块，并对最重要的路径保留由人类编写或审查的测试。诸如小规模差异、明确归属权和记录设计意图等与供应商无关的习惯，在各家提供商之间都通用。
能经受模型变化的护栏
模型行为会随时间变化，因此将假设固化到代码和测试中，比信任提示保持稳定更安全。校验结构化输出、记录原始响应以便调试，并在模型调用与业务逻辑之间保持清晰边界，这样更换提供商时就不需要重写。
这一切并不反对 AI 辅助开发。该帖的教训在于归属权和审查纪律，而非禁止生成。受益最大的团队往往将生成代码视为草稿，仍然需要一名人类作为正式作者。