关于“AI 编程会削弱专业能力”的争论，对两派都不舒服。它不是说 coding agents 没用，也不是要求大家回到手写样板代码。它问的是更现实的问题：当公司已经在使用 Claude Code、Cursor、Codex、Copilot 类工具、Gemini CLI 和 OpenCode，并把过去训练工程判断力的一部分工作交给代理时，工程判断力会怎样形成？

开发者在 AI 编程代理、架构、测试与评审控制之间取舍

最近的火花来自 Hacker News 对 Lars Faye 文章 “AI Coding will Prevent Expertise” 的讨论。核心担忧是认知摩擦减少：调试、读文档、犯错、理解边界和权衡。这个话题引发反应，是因为许多团队已经感受到类似变化。AI 能生成更多代码、需求单、设计说明和 review 评论，速度超过团队真正理解它们的速度。

关键问题

Faye 提到 skilled orchestrator paradox：最能用好代理的人，通常是有经验的工程师。他们能发现糟糕抽象、虚构 API、隐藏迁移成本和难以维护的改动。他们会提更好的问题，因为已经知道好答案大概长什么样。

培训问题由此出现。新人拿到的工具，要求他们在具备专家直觉之前就进行专家级引导。代理能让他们更快看起来有产出，却可能遮住缺失的心智模型：数据如何流动、边界为何存在、测试证明了什么、故障怎样传播、为什么小补丁比大重构更安全。

这不是怀念痛苦。部分摩擦确实浪费时间，另一部分却是学徒训练。如果 AI 同时移除两者，公司可能得到可见速度，却失去长期理解。

为什么讨论激烈

一派把 AI 类比为编译器、IDE、自动补全和 Stack Overflow。工具一直在减少手工劳动，行业会适应。另一派认为 AI 不同，因为它可能跳过推理本身。编译器不会交付完整架构，Stack Overflow 给的是片段。代理可以一次给出看似合理的 diff、解释和测试。

两边都有道理。去掉低价值劳动是好事；去掉反馈循环则危险。问题不是能不能用 AI，而是团队必须保留哪些循环：读 diff、显式设计、有效测试和人的责任。

企业的速度陷阱

公司很容易用吞吐量衡量 AI adoption：更多 pull requests、更快关闭 tickets、更多测试。这些指标只有与质量信号一起看才有意义。团队可能生成比自己能阅读和维护更多的代码，表面效率就会变成理解债务。

“手写代码就是慢”的管理信号尤其危险。它会挤掉保护产品的工作：质疑需求、阅读 diff、追踪边界情况、拒绝过大的改动、询问功能是否真的需要。

AI 还会增加周边噪声。产品经理生成更长的 tickets，工程师生成更多设计说明，review 工具生成更多评论。团队开始过滤听起来精确、但未必代表真实决策的文本。

新人需要练习

资深工程师可以把代理当作不知疲倦的 pair programmer，因为他们能反驳它。新人更容易把它当成答案机器。差别不是道德，而是背景知识。

健康流程应要求代理先解释：描述系统、列出约束、比较方案、提出问题、说明哪些测试重要。然后再写代码，或让人先预测 diff。目标是把代理变成导师和审稿人，而不是补丁售货机。

团队仍应保留直接练习：不用 AI 调试、读陌生代码、从零写小功能、在 review 中解释设计。这些不是反进步仪式，而是训练判断力的方式。

AI 也可以教学

正确使用时，AI 能加快学习。它可以梳理遗留模块、解释新框架、比较数据库方案、批评测试策略。这比沉默卡住更好。

关键在提问方式。“写这个功能”产生结果；“解释系统、提出不清楚的问题、列出替代方案和风险”产生理解。类似问题也出现在分析、法律、市场和客服：AI 生成材料快于人类验证材料。没有领域知识，漂亮答案会变成风险。

还要读 AI 代码吗

Adam Tornhill 关于控制“不确定机器”的观点提供了平衡。也许不必同等强度阅读每一行。工程本来就信任库、编译器和数据库。

但选择性信任需要边界：清晰契约、强测试、可观测性、有限影响范围和已知架构不变量。仍然必须有人知道哪些不变量重要。如果没人能解释改动为何安全，绿色测试并不够。

review 应按风险分级。孤立 UI 改动不同于认证、支付、数据迁移、并发和安全敏感代码。AI 生成代码不需要神秘恐惧，但必须有人负责。

Auto mode 提高要求

Claude Code auto mode 的讨论说明了现实压力。更少确认很方便，但代理越少打断人，越需要事先定义 sandbox：能改哪些目录、能跑哪些命令、能否安装依赖、改 CI、触碰迁移和生成文件，哪些动作必须等人批准。

没有政策的自治，会变成疲劳后的信任。好的流程先调查、写计划、提问题、等待高风险动作批准，再提交小 diff。这样去掉的是重复劳动，而不是判断力。

实用规则

每个 AI-assisted change 都需要 human owner，能解释目的、风险和 rollback。非平凡任务需要简短设计说明：范围、测试、迁移和运行风险。大型不可见重构应很少发生，并有明确 review 策略。

测试必不可少，但不能替代 review。需要寻找虚构 API、不必要抽象、新依赖、隐藏状态变化，以及作者无法解释的代码。团队还应安排 no-AI drills，保持调试、阅读和设计能力。

指标也要改变。关注 escaped defects、rollback rate、review load、maintainability 和 time-to-understanding，而不只是 PR throughput。如果 PR 更多，债务和事故也更多，说明采用方式有问题。

成熟立场

答案不是禁止 coding agents，而是把它们视为工程管理问题。它们能减少机械劳动、扩大探索；也可能替代团队对架构、风险和可维护性的判断。未来开发者也许写更少原始代码，但仍必须理解系统、失败模式、权衡和责任。