枪战英雄
99.99M · 2026-03-28
最近 HN 上一篇文章引发了热议：「Some Uncomfortable Truths About AI Coding Agents」。作者直接宣布在自己的专业工作中全面禁用 AI 编程 Agent，并给出了四个理由。
作为每天都在用 Claude Code、Codex 等工具写代码的人，我觉得这些观点值得认真对待——即使我不完全同意。
作者的核心担忧是：当工程师从「写代码」变成「审代码」，编码能力会不可避免地退化。
这不是理论推演。我身边已经有人反馈，自从重度使用 Copilot 之后，手写算法的感觉变迟钝了。就像长期用导航开车的人，关掉 GPS 就不认路。
但问题是：这是工具的问题，还是使用者的问题？ 计算器没有毁掉数学能力——对数学没兴趣的人本来就不会去算。同理，AI Agent 不会让优秀工程师退化，但会让「本来就不想写代码」的人暴露出来。
关键在于保持刻意练习。我的做法是：核心模块自己写，外围功能交给 Agent。类似于主厨亲手调味，备菜交给帮厨。
AI 生成的代码看起来便宜——几秒钟出几百行。但作者指出了隐性成本：review 时间、debug 时间、维护 AI 不理解的代码的时间。
这一点我深有体会。Agent 生成的代码经常「能跑但不对」：逻辑正确但架构别扭，测试通过但边界条件全靠运气。你花 5 分钟让 Agent 写完，然后花 30 分钟理解它为什么这么写。
真正的效率提升不是写得快，而是决策快。 Agent 的最大价值是帮你快速验证想法——"这个方案行不行，跑一下看看"——而不是替你写生产代码。
这是最有技术含量的担忧。AI Agent 通常需要读取项目文件、依赖、文档——如果这些内容被恶意构造，Agent 就可能执行有害操作。
不是假设场景。已经有研究者演示过：在 README 中嵌入特殊指令，让 AI Agent 在生成代码时悄悄引入后门。当 Agent 拥有文件写入、命令执行权限时，attack surface 比传统供应链攻击大得多。
这一点作者完全正确。行业需要更好的沙箱机制和权限控制。
AI 训练数据的版权问题至今没有定论。如果 Agent 生成的代码恰好复现了某个 GPL 库的实现，你的商业项目就有法律风险。
务实的做法是：关键业务逻辑不用 Agent 生成，或者生成后做充分的 code review 确保没有直接复制。
作者的结论是「永远禁用」，我认为这过于绝对。AI 编程 Agent 正处于「有用但不可靠」的阶段——像 2010 年的自动驾驶，能在高速上开，但不能在复杂路口放手。
正确的姿态不是全面禁用，而是建立使用边界：
技术的价值从来不取决于技术本身，而取决于使用它的人的判断力。
如果你在多个 AI 模型之间频繁切换测试编码效果，推荐试试 OfoxAI（ofox.ai）—— 一个账号接入 Claude、GPT、Gemini 等主流模型，挑最趁手的用。
