AI编码的局限与反思：开发者逐渐回归手写代码

随着AI编码工具的兴起，关于“机器能否取代人类开发者”的争论愈演愈烈。一方面，其高效完成任务的能力令人惊叹，被一些人视为将颠覆开发行业的利器；另一方面，其潜在局限性也引发了诸多担忧，特别是代码质量与系统稳定性方面的问题。

最近，一位名为mo的开发者在Hacker News上分享了自己的经历。在过去两年里，他几乎全面采用AI进行“氛围编码”。从最初的惊艳，到不断将更复杂的任务交给模型，再到逐渐意识到AI写出的代码在局部合理，却难以维持整体结构和长期可维护性。最终，他选择放弃高度依赖AI，回归手写代码。这篇直白、克制的反思，很快在开发者社区引发了强烈共鸣。

大多数人接触AI编码的历程都大同小异：先让它完成一项简单任务，你会为之惊艳。接着交给它一项复杂任务，你会更加叹服。然而，随着对AI完成复杂任务的表现仍感惊叹时，一个更为宏大的问题浮现：能否让它承担更宏大的任务？甚至是那个没人愿意接手的棘手重构工作？

AI的能力遭遇挑战

然而，AI的“光环”开始出现裂痕。一方面，它似乎能精准理解你的需求；但另一方面，它会犯下令人沮丧的错误，做出明显违背共识的决策。

你很快会明白，对AI模型生气毫无意义。于是开始将所有不尽如人意的输出归咎于自己：“是我的问题。我的提示词写得太差，描述不够具体。”

尽管你尝试用极致的细节描述功能，撰写详尽的需求文档，但你会发现，“需求驱动式开发”同样行不通。设计文档和需求说明都是“活文档”，会随着需求探索和落地实施不断动态演变。而AI工具没有能力在数周的开发周期中随着底层组件的搭建而迭代需求说明。

“杂乱代码”越积越多

直到逐行通读最新版本后，才发现那些我们曾以为只是早期模型残留、且会逐渐消失的问题——杂乱代码（slop），依然存在。

那些AI写的代码片段，单独看都没什么问题，既符合自身逻辑，也契合提示词要求。但它完全不考虑整体系统，不重视架构的结构性完整，甚至无视相邻代码的设计模式。

最终，mo称自己的大多数工作都开始回归手写代码了。令人意外的是，把所有因素都考虑进去（而不仅仅是每小时生成的代码量），他发现手写代码比用AI时更快、更精准、更有创造力、效率也更高。

克制使用“氛围编码”的趋势

对于mo的举措，不少工程师甚至一线教学者都表达了明确的认同。他们指出，AI真正危险的地方并不在于它能做难事，而在于它把“简单的事情”做得太好了。

这会让新手程序员极易跳过本该反复打磨的基础训练，心里想着“反正让AI生成就行”。结果不仅基本功没有真正建立起来，也逐渐失去了继续理解中等难度、复杂问题乃至更高层次抽象思考的机会。

这也正是教学一线最直观、也最令人焦虑的变化。一位名为recursivedoubts的网友直言，作为一名计算机科学教师，这是他目前最担心的问题之一。因此，他会非常明确地告诉学生：代码必须自己写。

另一位网友leros则从工程实践的角度给出了更为直白的判断。他指出自己身边一些从业1到3年的软件工程师对基础问题的理解之浅常常让他感到意外。

类似的反思也出现在更多工程师的实际使用经验中。Verdi表示：“我同意这个观点。”他承认把一部分任务交给大模型确实能节省时间但他也转向了更加克制、审慎的使用方式。