代码从来都只是开门的方式：资深开发者在AI时代的定位
目录
连帽衫里的门卫
罗里·萨瑟兰（Rory Sutherland）在他的著作《炼金术》（Alchemy）中讲过一个故事。一家豪华酒店聘请了一位顾问来寻找削减成本的方法。顾问观察了一位门卫二十分钟，然后在报告中写道：这个人负责开门。自动门也能开门。自动门更便宜。于是，酒店解雇了这位门卫。
结果大堂乱作一团。客人们找不到餐厅，没人帮忙叫出租车。那种“前台有人负责”的微妙感觉随之消失了。顾问测量了可见的动作，却忽略了实际的功能。
此刻，在某个地方，有人正盯着一位高级开发人员写代码，并写下了一份类似的报告：这些人产出代码。ChatGPT 也能产出代码。这就是穿着连帽衫的“门卫谬论”。代码一直以来都只是“开门”的动作，它从来不是这份工作的全部本质。
这就是我想表达的观点，而且我特别想对其他高级开发人员说。因为我们最能看清为什么这个观点是正确的，同时也最容易忘记这一点。可见的工作内容发生了变化，但底层的判断力却没有。你在职业生涯中积累的一切，正是人工智能所缺乏的，也正是将其引导好所必需的：背景认知、品味、系统性思维，以及在凌晨两点接到紧急电话时敢于承担责任的担当。
新闻头条并非“人工智能正在取代开发人员”。真正的头条是：人工智能终于让工作的其余部分——那些一直以来才是核心工作的任务——变得清晰可见了。
牧羊人
我开始用一个特定的词来定义我认为高级开发人员正在演变的角色：牧羊人（shepherd）。不是提示词工程师，不是“氛围编程者”，也不是“使用 AI 的开发人员”。牧羊人引导 AI 穿越它无法看见的地形：代码库的历史、团队的约束、部署的现实，以及那些从未存在于任何训练数据中的业务背景。牧羊人的价值不在于速度，而在于判断在何处应用速度。
有必要用数据来支撑这一点，因为周围的炒作声太大了。斯坦福大学对六百家公司的十多万名开发人员进行了一项分析，研究的是真实代码库中的真实代码，而非实验室实验。结果发现，所谓的“生产力提升 30% 到 40%”在扣除修复 AI 错误所花费的时间后，实际净增长仅缩减至 15% 到 20% 左右。这种增长是真实的，但比演示中显示的要小，也更零散。AI 在熟悉的领域表现最好；而在描述我们大部分日常工作的复杂现有系统上，它的帮助最小，甚至反而会带来破坏。
所以，问题不在于是否使用这个工具，而在于如何用好它。我认为，牧羊人的工作可以拆解为四件事：审视地形、选择路径、防范捕食者、照料羊群。
审视地形
牧羊人的第一项工作是了解地形。
我从事的是一个政府系统。像许多公共部门的系统一样，需求并非整洁的规格说明书。它们像沉积物一样。法律、政策决定、多年前出现且从未被正式记录的边缘案例、因无人能完全说清原因而存在的例外情况。当我把这些工作交给编码智能体时，结果几乎总是错误的，哪怕看起来很有道理。智能体读取的是眼前的代码，而真正的需求存在于负空间中——那些从未写下来的对话和先例里。
试图通过向智能体的上下文中塞入所有相关文档来暴力破解是行不通的。窗口满了，相关的信号被稀释，返回的内容无论是在匹配你的实际情况，还是匹配训练数据中表面相似的内容，都带着同样的自信语气。模型无法分辨自己在做什么，但你可以。
这就是牧羊人的第一项贡献。不是提示词，而是框架（framing）。知道哪份文档的哪两段话对这次变更真正重要。知道这个需求看起来很常规，但却以非显而易见的方式与那个遗留模块相互作用。知道当模型所能看到的与答案所依赖的内容之间差距太大，无法通过任何提示词来弥补时，正确的做法是不去委派这项工作。
这项技能并不华丽。这正是高级开发人员一直以来用来指导新人、解决初级人员困境所使用的技能。事实证明，这也是 AI 工作中最重要的承重技能。
选择路径
牧羊人决定什么该委派，什么该亲力亲为。
去年，我的团队对系统中的三十个相似对象进行了重构。考虑到现有的工具，诱惑是直接让智能体处理整个任务。但我没有这样做。我挑选了一个对象，缓慢而审慎地亲自重构了它。不是因为我不能让智能体去做，而是因为我想让这种模式先从我手中产生，并保留住那些细微的决策和后续的思考。
当我满意后，工作的性质就变了。我让智能体查看那个重构后的对象和剩余的对象，并列出一份将其他对象统一为相同形式的任务清单。我阅读并调整了这份清单。有些条目比我写的更精炼，而有些则遗漏了我在亲手处理第一个对象时所积累的细微洞察。随后，我让智能体逐一处理清单，并在结果进入主分支之前，对每一个结果进行审查。
工作的形式才是关键。我拥有设计权，委派了繁琐的执行，并把控了审查关。智能体处理重复任务的速度比我快，而那些真正需要我判断力的地方，都留在了我手中。
我认为高级开发人员最适合做出这种转变。对于高级开发人员来说，有趣的问题不再是“AI 能做这个吗？”，而是“我应该做这个吗？如果不是，它需要我提供什么才能做好？”第一个问题主要关于工具，第二个则主要关于你自己。
防范捕食者
牧羊人永远在核实。
前段时间，我们将一个 Quarkus 应用程序从 JPA 迁移到 Jakarta Data。几乎立刻，我们的测试就开始以一种奇怪的方式失败。我们在事务中更新的数据在同一个事务中读回时竟然消失了。我们询问编码智能体寻求帮助。回复迅速且自信：刷新会话（flush the session）。
这是错的。Jakarta Data 使用的是无状态会话。根本没有东西可以刷新。这个建议是对另一个更常见问题流畅的回答，是模型在训练数据中见过无数次的模式，即刷新 JPA EntityManager 确实是解决方法。我们的问题从外部看很相似，但在结构上却完全不同。
我们尝试向智能体输入相关的 Jakarta Data 文档，但没用。最终，我们做了我们一直会做的事：构建了一个最小化的重现案例，将行为缩小到特定的交互中，并将问题报告给上游。Quarkus 团队确认了该问题，根源最终发现存在于 Hibernate 本身。
教训不是“不要信任 AI”。教训更深刻：模型输出流畅且语气一致，无论对错，所以“自信”不是一个信号，而是噪音。而当它最危险的时候，恰恰是高级开发人员最能发挥作用的时候：当答案在模式上匹配了某种常见情况，但实际问题却处于模型训练范围之外时。你必须有足够的经验去“闻”出其中的不对劲。这种直觉就是你的护城河。
照料羊群
牧羊人从不孤军奋战。
我的团队使用 AI 助手已经有一段时间了，结果大相径庭。有些人很喜欢，有些人悄悄放弃了尝试。当我审视时，发现区别不在于天赋或资历，而在于流程。结果最差的人试图在一个提示词中解决整个问题：“这是问题，修复它”。结果最好的人则是在做我们处理难题时一直做的事，只是多了一个合作者：规划、执行、验证，分步骤进行，每一步都有明确的产出。
所以我开始明确地分享这一点。不是作为生产力技巧，而是作为一种显而易见的重申。不要让智能体一次做完所有事。让它列出一个你可以阅读的计划。然后让它执行计划中的一部分。接着根据你实际想要的结果来核对那一部分。更小、更具体的步骤几乎总是胜过一个雄心勃勃的提示词。我们正在重新发现软件开发流程。AI 并没有改变它，它只是奖励了那些已经拥有流程的团队，并惩罚了那些没有流程的团队。
我认为这种框架对你共事的伙伴最有用。AI 没有破坏工程学。它只是让那些拥有真实流程的团队与没有流程的团队之间的差距突然变得非常明显，因为工具会放大它所接触到的任何习惯。牧羊人的工作不是去监管提示词，而是将这些习惯显性化，分享有效的方法，并帮助经验不足的开发人员建立起那些本需要十年时间、经历几次生产事故才能获得的本能。
门卫的尊严
萨瑟兰故事里的门卫并不为自己的角色感到卑微。他知道自己真正做的是什么。困惑的是那位顾问。
现在，许多高级开发人员正让顾问们搞糊涂了。那些病毒式传播的演示、高管们关于“取代工程师”的言论、那些用一个提示词就构建出待办事项应用的 LinkedIn 帖子，都是一些盯着我们打字的人写下的报告。他们测量了可见的动作，却忽略了实际的功能。
打字一直都只是“开门”。真正的核心工作是审视地形、选择路径、防范捕食者、照料羊群。AI 没有夺走任何这些东西。它只是让这些工作成为现在最显眼的部分，因为那些能够自动化的部分确实已经被自动化了。
你的资历在这次转型中不是负担，而是护城河。它一直都是。
本文扩展了 Elma Westergren 和我就 AI 时代开发者身份在会议演讲中提出的“AI 牧羊人”概念。核心框架来自 Elma 作为职业治疗师的工作。当我们的工具发生变化时，真正受到威胁的是职业认同，而不仅仅是生产力，我很感激这一视角。
这篇文章《代码始终只是那扇门》（The Code Was Always the Door）最初发布于 foojay。