AI 需要更多工程纪律，而不是更少

对文章的总体反应

• 许多人觉得这篇文章啰嗦、东拉西扯，缺少具体结论；有些人怀疑这是“AI slop”式写作。
• 少数人喜欢其核心观点（AI ⇒ 需要更多纪律，而不是更少），但认为论证含混不清、模棱两可。
• 读者注意到“AI 具有生存性重要意义”的说法，与对取舍的含糊处理之间存在张力。

代码 vs. 规范、文档和提示词

• 一个核心争论是：代码是否应继续作为“主要工件”，还是规范、测试和提示词应成为主要审查对象，而代码变成可丢弃的实现细节？
• 有不少人认为，代码是唯一明确、可执行的规范，因此必须保持核心地位。
• 也有人支持把知识转移到设计文档、ADR、测试和提示词历史中，让 AI 重新生成代码，代码只是实现细节。
• 怀疑者警告说，更粗粒度的抽象和 LLM“规范”还不够可靠，不能跳过细致的代码审查。

AI 代码质量、“slop”与验证

• 普遍强烈的看法是，AI 会产出能运行但陌生、过度复杂或脆弱的代码，读起来和维护起来都很痛苦。
• 支持者反驳说，只要有良好的设计、约束和测试，AI 也能生成高质量、具防御性的代码，并加速非新颖工作。
• 大家普遍同意，当前瓶颈已经变成评估和验证，而不是代码生成。
• 有些人设想未来系统会验证属性和测试，而不是让人类阅读大部分代码；也有人怀疑，如果没有稳定、可被人理解的代码，这在现实中是否可行。

代码行数、生产力与技术债

• HN 长期以来的共识：减少代码是资深的标志。许多人在 AI 时代更加强烈地捍卫这一点。
• AI 使得超大 PR 和大量“表面上看起来合理”的代码与文档成为可能，更难看出谁真正理解系统。
• 使用 LoC 或 PR 数量作为生产力指标，如今被认为尤其失效。
• 多条评论预测，AI 生成的代码和文档会带来一种巨大的新型技术债，类比为石棉或“技术破产”。

纪律、角色与激励

• 许多人同意 AI 确实 可能要求更多纪律：更好的规范、测试、可观测性和来源记录（例如保存提示词和设计意图）。
• 但与此同时，AI 也更容易让人看起来在高效产出，而实际上并不理解，尤其是在高管要求“到处使用 AI”的压力下。
• 有些人预计 SWE 角色会转向架构、文档和测试设计，而不是消失；另一些人认为，低技能 + AI 是一种新的系统性风险，尤其对初级工程师而言。