在 AI 编程工具让代码生成近乎瞬时的时代，工程团队该如何重新审视「人」的价值？Intuit 工程总监 Eric Anderson 在 Stack Overflow 播客「Leaders of Code」中分享了他的观察：代码行数的成本已降至历史低点，但衡量工程师效能的核心指标从未改变——客户价值。
代码成本暴跌，工程角色正在重塑
Eric 直言这是他从业数十年来最有趣的时刻：「写代码这件事，从排期、风险到回滚，曾经都是工程师最操心的事。但现在，代码行数的边际成本已经低到几乎可以忽略。」 这带来一个深刻的变化：编程能力不再是衡量工程师价值的唯一标尺。「如果你是个顶级程序员，这不一定能让你成为 AI 时代的顶级软件工程师。」Eric 认为，系统设计、架构思维、对业务的理解，这些能力正在变得比写代码本身更重要。
真正的效能指标：客户价值，而非代码量
面对行业里不少公司炫耀「用 AI 生成了 X 百万行代码」，Intuit 的答案很明确：代码量不是衡量标准。
Eric 介绍，Intuit 内部仍会追踪 PR 数量、代码审核&查验数、代码行数等传统指标，但最重要的只有一个：「我们做的技术，最终有没有产生客户价值？」 更深层的变革在于实验能力的跃升：「我们过去总要在 A/B 两个方案之间做选择。现在不是了——我们可以同时跑 2 个实验，也可以跑 5 个、9 个，甚至 900 个。」AI 极大降低了试错成本，团队不必再在「好点子」和「快速验证」之间权衡，而是可以并行探索。
人类判断力：AI 时代更需要同理心
Eric 反复强调，无论工具如何演进，人始终是软件工程的中心：「工程师必须比以往任何时候都更深入地理解他们的客户是谁、客户在乎什么。因为现在，他们比过去更容易对这些用户体验产生实际影响。」 AI 提升了效率上限，但把「做什么」和「为什么做」的决策权，更牢固地留在了人类手中。
瓶颈已不再是写代码
过去，软件开发的主要瓶颈是"代码生成速度"——工程师能多快地写出代码，决定了产品迭代的效率。但随着 AI 编程工具的成熟，这个瓶颈正在被彻底打破。
从"写代码"到"定方向"的职能迁移
在一次季度规划中，这位嘉宾的团队做了一个大胆的决定：暂时搁置传统的 Roadmap 制定，转而重新思考"交付 Roadmap 本身意味着什么"。他们发现，团队的思维格局太小——实际上能做的事情远比预想的多。
关键问题随之浮出水面：设计师足够吗？产品需求文档需要多精细？要不要从"完整 PRD"转向"粗略草图 + 边做边调"？
当设计可以随时修改、代码可以快速生成时，"设计完成"的定义也在被重新改写。
新瓶颈：创意到生产的转化链条
嘉宾直言：当前真正的瓶颈已经转移到"创意到生产"的转化过程。具体卡在哪里？
- Ideation 阶段：从一个"解决客户问题的好想法"到"生产环境运行的真实功能"，中间隔着无数协作与决策
- 工作关系与交接流程：设计、产品、工程之间的传统边界正在模糊，但新模式尚未成型
- 流程本身的惯性：Scrum 曾经是软件工程的革命性方法论，把团队从瀑布式开发拽向了敏捷迭代；如今，新的方法论正在萌芽，但没人真正知道怎么做才是"正确姿势"
角色融合：PM 也能提交代码
Claude Code 在整个组织推广后，出现了有趣的变化：产品经理开始直接提交 PR，由工程师只做代码审核&查验，整个实验就这样跑起来了。与此同时，仍有工程师在全面构建功能。
这背后需要一种心态：角色正在融合，PM 可以是工程师，工程师也可以是 PM。保持实验性学习的心态比死守岗位描述更重要——今天的"最佳实践"，明天可能就被完全颠覆。
工程师的"超能力进化"：技能坐标系正在重绘
从 IDE 升级史，看 AI 编码工具的位置
他将当下的 AI 编码工具类比为开发工具的进化历程——就像当年从 Emacs、Vim 切换到 Eclipse、IntelliJ，代码生成工具让工程师能够产出更高质量、结构更规范的代码。核心逻辑没变：代码依然要走 CI/CD 流水线，依然需要可维护、可监控、有性能指标。操作层面的责任始终在工程师手里。
跨职能共情：打破"部门蔷"的新方式
当被问到如何让团队接受这些新工具时，他的回答是：这不仅仅是"接受"，而是拓宽了"什么是高质量关键软件"的定义边界。
- 工程师开始学产品：理解业务为什么要做这件事
- 设计师开始学代码：能快速搭出可交互的原型
- 产品经理开始理解运营卓越：知道部署、监控、迭代的难处
这种跨职能学习带来一个意想不到的结果——团队内部的共情能力大幅提升。"以前产品催进度，工程师觉得他们不懂技术。现在工程师说'原来那个需求涉及这么多链路'，产品也说'原来这个功能实现起来这么复杂'——双方互相理解之后，对话顺畅多了。"
原型验证：PM 和设计师的新武器
在创意构思阶段，体验提升最为明显。以前产品经理或设计师想把一个想法"可视化"，需要依赖工程师出图。现在他们可以直接动手搭出可交互的原型——"能摸到的东西，比一版文字需求更容易达成共识。" 他坦承，这类原型直接上生产环境的可能性不大，但作为快速验证思路的捷径，效率提升是实打实的。
需求永不眠：Backlog 不会变短
Intuit CTO 的一句话他反复引用：在这家公司待了这么多年，从来没见过 Backlog 变短。 业务方提的需求永远比团队消化的速度快。
这个现象反而揭示了一个积极信号：AI 工具放大了团队的"战斗力"，但好想法的数量也在同步爆发。当一个工程师可以被 AI 辅助完成更多工作时，问题不再是"我们人手够不够"，而是"我们能想到多少值得做的事"。 设计、产品、技术多端协同推进，正在成为应对需求洪水的可行路径。
AI 时代更要夯实基础功
对话中指出，即便在 AI 工具极大提升效率的当下，工程思维的核心能力并未过时。无论是 OVN 的跨实现理解，还是通用的解题方法论，这些都需要工程师主动积累和思考。调试、CICD 等实践技能依然重要，但如果无法理解算法，就不可能真正取得成功——这是 AI 无法替代的硬功夫。
资深工程师的收益与新人的困境
有资深工程师坦言，引入 AI 后自己的生产力提升了百倍。他们能快速搭建各种组件，对系统全貌有清晰认知。然而对于资历较浅的工程师，情况截然不同。行业需要更多关注这一群体——传统的工程能力很大程度来自"坐在旁边看别人写更多代码"的师徒式传承，这种工匠式的学习路径正在被打破。如何既让顶尖开发者效率倍增，又确保新人能健康地成长、积累实战经验，是整个行业必须思考的问题。
代码所有权与"AI 生成"的边界
在某大学的观察中，有学生展示作品时被建议优化代码，却得到的回答是"那是 Claude 输出的"。这种对代码所有权的淡漠令人担忧。AI 是工具，工程师仍需为产出负责。同时，行业中存在一种声音认为"现在只需要高级工程师了"，但高级工程师从何而来？答案始终是从初级工程师成长而来。没有亲手让代码在屏幕上动起来的那个顿悟时刻，职业热情很难真正点燃。
降低门槛与保持深度的平衡
积极的一面是，AI 降低了软件工程的参与门槛。更多人能直接上手做一个小工具、搭一个网站解决问题，这种"发现可能性"的体验正是当年许多工程师入行的起点。然而即便起点更低，模块化思维、组件间依赖关系、错误处理与非 Happy Path 设计这些能力依然不可跳过。能否将大问题拆解为小组件、能否想象组件间的交互方式、能否处理消息未到达等异常情况——这些才是区分真正工程师的关键。
AI 降低了编程门槛，但问题本身才是核心
对话中提出一个核心观点：AI 真正降低的是编程语言本身的门槛，而非解决问题的难度。Python 之所以值得学习，不是因为它简单，而是它足够友好——语法简洁、可读性强，能让没有 CS 背景的人跨过"编程恐惧期"。但即便如此，AI 正在加速这一进程：现在只需更少的努力，就能完成更多事情。
然而，理解底层原理依然重要。一位工程师的预测（虽然所有预测都可能被证伪）是：两到三年后，我们会发现 AI 生成的代码在灵活性和可移植性上存在明显短板。AI 擅长完成你交给它的任务，但不会像人类工程师那样主动考虑代码未来的扩展性。当团队想在既有基础上继续构建时，往往被迫大规模重构——届时，对底层原理的理解才会真正显现价值。
Agent 工作流带来的新管理命题
对话深入探讨了 AI Agent 的实际应用场景：不只是生成代码，而是让 Agent 承担工程流程中的特定环节。例如，一个 Agent 可以被赋予"质量改进缺陷"任务——给定数据集，运行代码、识别 Bug、修复 Bug、再运行，形成自我改进循环。
但问题随之而来：这些 Agent 容易"跑偏"，产出技术上符合 Fitness Function、但实际无益的结果。于是需要引入对抗性 Agent 来监控主 Agent 的行为，判断"你还在做正确的事吗？" 更关键的是，随着 Agent 数量增加，资深工程师的角色正在转变——他们更像"软件经理"：每天问自己的 Agent"你在做什么？进展如何？有没有出问题？"这引出了一个尚未被充分回答的问题：如何量化 Agent 的效能与产出？
代码即牛群：当重写成本趋零
对话中浮现出一个激进的理念框架，来源是一位 Principal 工程师的原话："我们要把代码当牛群，而不是孩子"（Treat code like cattle, not children）。意思是对代码的珍视程度应当降低——当某行代码的边际价值趋近于零时，是否可以每天都从头重建？
这个观点颇具实验性，也颇具争议。它挑战了传统软件工程中"能不改就不改"的保守态度，暗示在 AI 编程时代，重写可能比维护更划算。但正如对话者最后的回应："悠着点，朋友"——完全放任的前提，是 Agent 产出质量必须有保障，否则每天重建只是另一种形式的资源浪费。
软件开发是"养牛"还是"养孩子"？当 AI 让代码重写成本趋近于零时，是否意味着每次迭代都该推倒重来？
答案并不简单。任何软件初次面对真实用户，都会暴露问题，必然需要持续演进。关键在于：如果每次迭代都从零开始，是否丢失了代码在反复打磨中积累的"锋利度"？这个问题目前没有定论，业界仍在探索。
从时间线来看，AI 编程工具大约在四到五个月前才真正成熟，此前只是"能用"，如今已是"好用"。接下来会如何？是停滞、扩张，还是复杂到人类无法理解？这些都尚无答案。而这恰恰是人类判断力的价值所在——面对不确定性时的决策能力，正是 AI 难以替代的。
工程管理者的 AI 日常实践
Eric Anderson 分享了他作为 Intuit 工程总监，在日常工作中使用 AI 的具体场景： 邮件与即时通讯
- 构建了一个邮件 Agent，每日读取邮件、自动摘要，并给出回复建议，Eric 只需调整语气和措辞后发送
- 对 Slack 消息做类似处理：识别 VIP 联系人、生成摘要、判断优先级
- 避免了繁琐的邮件过滤规则，同时确保关键信息不被遗漏
文档与需求验证
- 将 PRD、技术规格文档与实际代码对比，验证"我们是否真的做出了想要的东西"
- 用 AI 调查：给定一批日志数据，主动发现异常，进而驱动产品改进
晋升与绩效文档
- 在 Claude 和 GPT 中分别为员工晋升文档建立项目空间
- 汇总该员工的所有代码贡献和文档记录，AI 协助摘要，Eric 据此起草 promo doc
竞品与市场研究
- 针对特定竞品、客户案例或技术方向，与 AI 对话讨论，建立更系统的认知框架
值得注意的是，人工始终在环。Eric 坦言曾尝试让 AI 直接代发邮件，但很快放弃——风险过高。正确的姿势是让 AI 处理信息过滤和摘要，最终决策和表达仍由人完成。
评论