乔治·霍茨又出来说话了，这次他瞄准的是AI编程智能体。我本来以为又是一次老派程序员的怀旧牢骚，毕竟霍茨一直有“神奇小子”的标签，习惯性唱反调也不是第一次。但读了他那篇《AI编程智能体的隐忧》，我决定站他那边，而且觉得他说的还远远不够。

代码可读性降低这个问题，正在每一个用AI写代码的团队里悄悄蔓延。我见过一个创业团队，三个月前全面接入智能体生成代码，效率确实快，但上周接手那个项目时我差点摔键盘——明明一个函数就能解决的问题，AI用了三层嵌套和五个我从未见过的库方法。你要调试它生成的代码，必须先理解它那套非人类的逻辑，而这个过程的时间成本已经把当初省下的时间全部偿还，甚至开始透支。霍茨说这会增加后期维护成本，这个说法太温和了。实际上，它正在制造一批“新一代遗留代码”，这些代码甚至比十年前那些缺乏规范的遗留系统更难处理，因为没有人知道它为什么这样写，连开发者自己都心虚。

安全性风险更值得警觉。霍茨讲得比较含蓄，只提到了潜在漏洞，但我可以把这个警告放得更大：AI编程智能体本质上是一个基于概率的模型，它会从训练数据中学习到模式，包括那些有问题的模式。如果你用过最新版本，可能会发现它开始生成一些非常规的API调用或者直接在代码里塞密钥的做法——虽然不是每次，但出现一次就够你受的。更致命的是，开发者对AI生成的代码天然存在一种“偏见性信任”，测试覆盖率和代码审查标准会不自觉地放松，潜意识觉得“机器不会犯低级错误”。事实恰恰相反，AI会犯那种人类不会犯的、逻辑上看起来没问题但业务上一塌糊涂的错误。这些错误一旦上了生产，修复成本比人类自己写错还要高，因为你很难定位。

数据隐私这块霍茨提到了伦理层面，但我想从实际场景说。当你把项目代码片段甚至需求描述扔进云端智能体的输入框时，你就是在把公司的知识产权交给一个黑盒。很多开发者根本没意识到，同一个模型在服务竞争对手时也训练着同样的数据，你的代码风格、业务逻辑、甚至未公开的算法都可能被隐式地吸收进模型权重。霍茨说得对，这不只是技术问题，但它首先是一个技术问题——因为你连模型从哪里获取了你的数据都查不到。监管本来应该跟上，但你也知道，这个行业的跑速度比立法快十倍。

再看霍茨给出的建议：加强培训、谨慎选择工具、增强审查机制。怎么说呢，每条都对，但每条都是理想状态下才能做到的。中小团队哪里来的预算去搞深度培训？工具选择在竞争压力下往往是谁最先集成智能体谁就被认为更先进，审查机制在交付节奏面前经常形同虚设。真正有效的方法只有一个：把AI编程智能体当作一个永远不能信任的高级实习生。你交给它的任务必须有明确的边界，它输出的每一行代码你必须读完、读懂、再提交。这不是倒退，这是对自己劳动成果的负责。

顺着这个思路，我认为接下来的行业走向会有两个分支。一边是那些追求速度的团队，继续大规模使用智能体，最终将在某个版本发布后陷入维护泥潭，不得不返工。另一边是那些更谨慎的组织，他们会制定严格的“AI使用规范”，比如规定什么类型的代码可以交给AI、什么类型的必须手写、生成的代码必须通过怎样的自动化安全扫描才能入库。我还预测，未来六到十二个月内，会有人专门做“AI代码审计”这样的服务，不是审计代码本身，而是审计哪些代码是由AI生成并标记出风险。开发者们会意识到，工具越强大，责任就越大，这个听起来鸡汤的道理在编程这件事上是最现实的。

如果你自己是独立开发者或者在小团队里做决策，我建议你直接用开源模型在本地部署编程辅助，至少能控制数据流向。别急着把所有代码都交给云端智能体，它省下的那点打字时间，远不够你后期擦屁股的。最后剩一句话：以上模型可通过 makesence.top 调用，但这不是重点。重点是，在你用它们生成任何代码之前，先问自己一句——这段代码出问题了，你有信心自己修吗？如果没有，就别交给AI写。