当代码变得廉价，判断力就是手艺
AI 编程工具不只是让工程师写代码更快，它正在重新定义「什么是好的软件工程师」
一位工程师正在审查 AI 智能体写的一段支付功能代码。代码看起来整洁，路由都搭好了，自动化测试也通过了。但他注意到一个严重的问题：重试路径没有保留支付请求的幂等键。通俗地说，如果数据库已经记录了扣款，但响应超时了，自动重试就有可能把用户重复扣费两次。
这个例子正好说明了「看起来正确的代码」和「可以信任的软件」之间的差别。
对于清晰、常规的任务，AI 现在只需要几分钟就能生成项目骨架、应用路由和第一批测试。它大大缩短了做出一个「像样的初版」需要的时间。但代码变多，并不自动意味着软件变好。
这正是 AI 辅助编程的核心矛盾。AI 让有用的代码变得更便宜，同时也让脆弱、不安全、没人真正理解的代码变得更便宜。当实现速度越来越快，工程绩效就不再取决于团队产出了多少代码，而取决于团队验证、集成、安全运维每项变更的能力。
这改变了人类工作的价值所在。判断力、验证能力和责任感变得更加重要。这里说的判断力有实际含义：选对问题、理解约束、设计选型、判断需要多少证据才敢信任这次改动，以及为线上发生的一切承担责任。
AI 正在改变什么
AI 工具现在能做的远不止补全一行代码。能感知代码仓库的智能体可以阅读整个代码库，规划跨多个文件的修改，执行命令，检查失败的测试，然后重新尝试。
从测评数据来看，AI 的能力提升很快。到 2026 年初，领先系统在 SWE-bench Verified 上的问题解决率已经进入 70% 多的高位区间。SWE-bench Verified 是一个基于真实 GitHub issue 构建的基准测试。不过，基准分数有其局限：工具、测试框架和评估方法一直在变，而且通过了基准测试，也不代表改动就能通过真正的代码评审，或是在生产环境中安全运行。[1]
影响程度还取决于所构建软件的类型。在普通应用开发中，团队在首次实现上花的时间可能会变少，更多时间会花在评审和集成上。而在嵌入式、受监管以及安全关键的系统中，一次错误的改动可能引发安全、法律或运营上的损害。这类系统需要更强的验证、可追溯性和人工问责机制。
AI 可以压缩执行环节，但无法替人做掉关于意图、取舍、约束和可接受风险的决策。智能体（agent）可以按要求实现某个功能，但不应假设它清楚所有相关的业务规则和组织优先级，也不应让它对组织愿意接受的取舍拥有最终决定权。
在部分工作中，工程师正从直接实现，转向对智能体产出的改动进行定义、监督和验证。这既需要明确的需求和成功标准，也需要足够的技术理解力，才能看出方案在哪些地方不对。
手艺正从「产出」转向「可信的改动」
好的工程从来不只是打字速度和语法能力。设计、测试、可维护性和运维一直都很重要。即便如此，招聘和生产力评估体系往往还是奖励看得见的产出：关闭的工单、合并的 Pull Request、交付的功能。
AI 让这些衡量标准变得更不可靠。当一个工具能快速生成大量代码时，代码量已经很难反映工作的价值或质量。
标题：当代码变得廉价，判断力才是真正的本事
目前的研究中已经出现了一些值得警惕的信号。软件分析公司 GitClear 分析了 2.11 亿行改动过的代码。在其数据集中，被归为“复制粘贴”的代码行占比从 2021 年的 8.3% 上升到了 2024 年的 12.3%；而被归为“移动位置”的代码行占比则从大约 24% 降到了 9.5%。[2] 这些数据可能说明，代码重复变多了，而真正的复用变少了。不过，这项研究只是观察性的：它并不能证明是 AI 导致了这些变化，而且它的衡量标准也不能完整定义软件质量。
DORA 的研究结果也表明，那些“AI 提高生产力”的简单叙事是靠不住的。其 2024 年报告发现，AI 采用率越高，交付吞吐量和稳定性反而越低。到了 2025 年，AI 采用率与吞吐量呈现正相关，但与稳定性之间的负相关依然存在。[3][4] 这些都是相关性，并不能证明是 AI 导致了这些结果。但它们支持了一个重要的观点：代码产出得更快，并不代表一个组织就能安全地把它们发布出去。
因此，衡量工程生产力的单位不是产出了多少代码，而是一个改动是否被真正理解、验证、集成，并成功地运行起来。
更重要的（人类）技能
问题框定
AI 可以帮助挖掘需求、提供候选方案，但哪些问题值得去解决，仍然需要人和组织来做决定。
一个模糊的需求，比如“做一个支付服务”，AI 能生成看起来像模像样的代码，却很可能遗漏真正重要的问题：谁有权发起支付？重复请求怎么处理？部分失败时会发生什么？哪些操作需要留日志？这个服务归谁所有？发布失败后如何回滚？
一名扎实的工程师，会在信任这段代码之前，先把这些问题弄清楚。
系统思维
AI 生成的代码可能通过了本地测试，却让整个系统变得更糟。一个新工具类可能能用，但放错了架构层；一个新功能可能和已有能力重复；一个数据库改动单独看是对的，却可能给其他地方带来新的负载、耦合或故障模式。
系统思考意味着要理解组件之间如何交互、状态存放在哪里、数据如何跨越边界，以及某个环节出错时系统会如何表现。这种全局视角，往往就是“能跑的代码片段”和“可靠的工程改动”之间的分水岭。
验证与调试
AI 生成的代码改动可能包含凭空捏造的 API、错误的假设和逻辑缺陷。这些改动也许能通过覆盖不足的测试。如果同一个模型既写了代码又写了测试，那么测试和代码可能基于同一种对需求的理解——而这个理解也许从一开始就是错的。
验证的工作范围不能只停留在单元测试上。工程师可能还需要检查：依赖项和许可证是否存在风险、机密或专有代码是否暴露、安全边界是否被突破、系统是否可观测、上线和回滚方案是否可行，以及在最初的 AI 代理会话结束后，这些代码由谁来负责。
研究表明，AI 辅助带来的生产力提升并不适用于所有场景。2025 年初的一项随机研究中，METR 发现，16 位经验丰富的开源开发者在处理自己熟悉的复杂任务时，允许使用 AI 工具反而多花了 19% 的时间[5]。后续一项使用更新工具的研究显示了一些提速迹象，但样本选择问题让结果难以解读[6]。审慎的结论不是“AI 总会拖慢开发者”，而是：基准测试中的表现，并不会自动转化成复杂、高度依赖上下文场景下的真实生产力。
判断力并不是人类永远的安全区。AI 已经在参与代码评审、威胁建模、调试和架构方案制定。随着这些能力继续提升，工程师花在“生成第一版分析”上的时间会减少，更多精力要用来判断 AI 给出的分析是否站得住脚。人类的价值不能建立在“AI 只停留在实现代码”的假设之上。人类的价值在于理解系统、结合具体场景权衡利弊、判断证据是否足够，并对最终结果负责。
安全与领域知识
安全漏洞往往藏在业务规则里，而不是语法层面。Veracode 用 4 种语言、4 类漏洞构建了 80 个任务模板做基准测试，结果 45% 的生成结果没能通过安全测试。这并不意味着生产环境里 45% 的 AI 代码都不安全，但它确实说明：看起来合理、能跑通的代码，也可能在关键安全检查上栽跟头。
权限校验和业务逻辑尤其棘手，因为代码对不对，完全取决于应用自身的规则。此外，AI 反复修改代码的过程中，也可能把早期版本里本来正确的安全检查删掉。因此，工程师需要的测试要能覆盖这些业务规则，而不只是验证正常路径能跑通。
学徒制难题
AI 还可能改变工程师的学习方式。
过去，初级工程师靠有边界的小任务积累经验：修 bug、补测试、读已有模块、实现小功能。这些任务不只是廉价劳动力，它们让工程师理解代码库是怎么运作的，也让他们体会到小决定如何积累成大后果。
如果 AI 智能体接管了更多这类常规实现工作，一些学习机会可能会在组织设计出替代方案之前就缩水。公司不能简单地要求初级工程师提前拿出资深判断力。判断力不是光靠学原理就能获得的，它是在实现、调试、处理事故、代码评审，以及承受早期权衡带来的后果中慢慢长出来的。
这就形成了一个悖论：AI 让判断力的价值更高，同时又自动化了那些传统上培养判断力的工作。
组织需要有意识地设计学徒成长路径。初入行的工程师应该继续贴近代码、贴近生产环境：审查 AI 生成的改动、排查事故、跨服务追踪故障、参与设计讨论，并亲手运维团队交付的系统。AI 可以辅助这些学习，但不应让他们与后果脱节。
当写代码变得廉价，判断力就成了手艺
工程领导者应该调整什么
购买 AI 编程工具本身并不是工程策略。AI 只有在团队的验证能力跟得上生成能力时，才能发挥出杠杆效应。否则，写代码越快，结果可能是评审队列更长、运维风险更高、代码库越来越不连贯。
因此，平台团队可以发挥作用：铺出一条「康庄大道」（paved road），提供经过认可的组件、安全默认配置、架构规则和自动化检查，引导人类和 AI 智能体都走向更安全的改动方式。
问责机制也必须落到实处。当智能体创建拉取请求（pull request）时，必须有一位具名的人掌握足够的背景、权限和时间，可以拒绝或重新设计这个改动。对于高风险变更，评审证据应该包括：
- 需求和风险等级
- 测试结果和关键假设
- 安全和依赖检查
- 可观测性改动
- 发布和回滚计划
- 具名的负责人
组织还应该审视：写代码省下来的时间，是不是在后面的环节又消耗掉了？新的瓶颈可能出现在评审、集成、安全审批、测试、部署或故障响应上。
代码行数和原始产出量都不是衡量生产力的好指标，尤其是当机器可以廉价地大批量生成它们的时候。没有哪一个单一指标能独立胜任。领导者应该把交付速度，和可靠性、可维护性、恢复时间、客户成果，以及可避免的返工量放在一起综合评估。
判断力将成为稀缺能力
在 AI 辅助开发中，人类持久的核心责任不是写每一行代码，而是决定一个软件改动是否值得信任，并在判断失误时承担责任。
这并不等于工程会自然而然变成更高级的技艺。如果工程师沦为「批准自己并不理解的改动」，这门手艺反而会变得更弱。只有当人们仍然贴近实现和生产的细节，能够质疑、改进，并真正为工具产出负责时，工程工作才会变得更丰厚。
当初稿代码变得越来越便宜，瓶颈就转移到了这些判断上：这个改动是否必要，是否符合系统整体设计，以及现有证据是否足够让人放心信任它。
当代码变得廉价，判断力就成了真正的技艺。
参考来源
- SWE-bench Verified leaderboard
- GitClear AI Code Quality Research 2025
- 2024 DORA report
- 2025 DORA report
- METR: Early-2025 AI and experienced open-source developer productivity
- METR: 2026 developer productivity experiment update