AI写代码是一场噩梦

寂静回声

一位开发者在Hacker News上发帖倾诉，称使用AI编写代码是一场噩梦。AI过度聚焦当前任务，对更改是否破坏系统其他部分漠不关心，长上下文等同于即时脑损伤。这一帖子引发了数十条讨论。
有人指出，AI最令人痛苦的习惯是只添加代码而非修改或删除现有代码，导致文件中充斥着addData、addDataNew、addDataForAddData这样的重复函数。AI生成的代码往往缺乏对现有系统的理解，无法复用正确的抽象，也无力承担变更后的完整调用链。

一位开发者将AI比作过度防御性编程的典型，经常添加不必要的tryexcept块来掩盖本应暴露的错误。
还有开发者描述了AI编码的生产力悖论：启动一个任务后等待3到5分钟，再启动下一个再等待，这种循环不足以让人真正投入工作，却打断了深度思考的流程。

针对这些问题，社区总结出多种应对策略。首先是计划先行：
让AI扫描项目并创建实现计划的markdown文件，在新会话中让AI按照计划执行，而非一次性要求它解决问题。
其次是规则约束：在AGENTS.md文件中定义架构不可妥协的规则，要求AI在标记任务完成前必须运行测试。
第三是上下文管理：使用具有100万token上下文窗口的模型，或将会话拆分为规划和实现两个阶段，将扫描阶段的上下文压缩到单个文件中。

有开发者引用了Anthropic的一项研究，该研究将开发者分为辅导+手写代码组和AI最大化组，发现前者在速度和系统理解方面表现更好，且成本更低。
不过也有人指出，该研究的对象是初级开发者，样本量较小，最有成效的AI使用方式可能是资深开发者利用AI加速工作流，同时仔细审查输出。

一位开发者总结道，LLM的好坏取决于训练数据中代码库的平均质量。
如果将AI当作放手不管的开发者，从流程中移除人类，得到的就是代码泛滥。
但没有人强迫我们这样使用它，速度的减慢恰恰是将人类专业知识和判断力融入其中的必要代价。
当大模型准备好让人类退出循环时，我们会知道，因为那时我们都会失业。
在此之前，我们的角色是充当质量瓶颈，而不是打开闸门。

Hacker News社区正在讨论一种“新型人机分工”模式，规划出一个未来趋势——“AI负责做不完美的 reference design（参考设计），人类负责真正的工业级落地”。