疲惫的人机循环
又是一篇关于大语言模型（LLM）的思考文，我知道大家可能看腻了，但请容我说完。
我想把当下大多数开发者都在经历、却没来得及梳理清楚的感受写下来：用LLM编程确实有用，也确实让人不安。这两种状态同时存在。如果我们刻意回避后者，只会集体走向倦怠。
在Pydantic，我们开发的工具帮助开发者验证数据、构建AI智能体，以及监控生产环境中的系统运行状态。我们的核心业务就是提升LLM驱动软件的可靠性，但即便如此，我们也正经历一段五味杂陈的时期。
这篇文章不谈AI是否会取代程序员，不是唱衰也不是鼓吹，而是一名身处行业中的开发者，坦诚讲述当下的真实感受，以及一些可能真正有用的思考。
二十岁刚学编程时，我清晰地记得那种感觉：编程让我仿佛能伸手触碰宇宙的肌理，按自己的意志塑造它——当然，那是在我遇到太多编译错误之前。但那种触及深层抽象逻辑、仅凭思维就能从无到有创造事物的感觉，一直留在我心里。
我不是计算机科班出身，而是设计师兼程序员：前者接受过正规训练，后者完全靠自学。软件工程的那些理论，我是通过一次次惨痛的实践才理解的，而非课堂教学。或许正因如此，一旦领悟这些原则，我会更加重视。当你历经挫折才建立起对架构和代码质量的认知，它们就不再是教科书上的规则，而是刻在你身上的“伤疤”。
那种原始的创造快感，正是2010年代低代码、无代码工具一直承诺却从未真正实现的。我还记得用Dreamweaver做网页的日子，看着Adobe大肆宣传零代码设计工具，背地里却生成一堆乱糟糟的“意大利面代码”。它们总差临门一脚，看似触手可及的未来，仿佛只要你足够聪明就能抓住，却始终遥不可及。
如果你对当下的AI工具持怀疑态度，我完全理解。我们曾被类似的承诺骗过太多次。但这一次，承诺与现实之间的差距真的大幅缩小了，而这恰恰是最让人不安的地方。
是的，代码好像能自己写出来了，但人类要做的审核、指导和纠错工作，反而更糟心了。
最近我和同事Douwe聊过，他负责维护Pydantic AI框架，是我认识的最懂如何将LLM融入开源工作流的人之一。他说，每天早上醒来，都会收到30份PR（代码合并请求），全是别人用AI连夜生成的，他必须快速判断每一份的价值。他特别想把审核工作也交给AI，但他说：“真到那一步，我还在这里干什么呢？”
说实话，过去几个月里，我曾花了整整两天时间给LLM写执行方案：反复斟酌、细化、再细化，结果它还是做出一些匪夷所思的蠢事。比如把React钩子移植到Storybook故事文件时，读错方案、凭空捏造不存在的组件。这些不是能力不足导致的错误，而是逻辑一致性的问题。模型足够聪明，能生成看似合理的代码，但在复杂变更中，却未必能始终保持连贯的目标。
这催生了一种全新的疲惫：监督疲劳。你得时刻把目标记在脑子里，看着机器生成大量大体正确的内容，却始终需要你去检查、判断、把关。Douwe说得很贴切：以前在开源项目里和真人合作开发酷炫功能，帮别人提升技能，能让他获得多巴胺快感。但现在，“我写的所有东西都掉进了AI的黑洞，另一端没有真正在学习的人。”这种失落真实存在，值得我们正视。
Simon Willison最近提到伯克利哈斯商学院的一项研究，指出AI会提高工作强度——总想着“下班前再写一个提示词，再加个功能就能完美了”。我对此深有体会。前不久我熬到凌晨2点还在调试提示词，因为我觉得自己离写出完美方案只差一步了，至少我当时是这么想的。
另一位Pydantic同事Marcelo被问到Claude Code会话卡住怎么办时说：“直接开5个Claude会话就行，反正你忙着给其他会话反馈，根本注意不到。”他是在开玩笑吧，我猜。但这话精准捕捉到了当下的现实：并行操作既让人兴奋，又有点失控。你能启动的任务数量大幅增加，但能用心完成的数量丝毫没变——因为完成任务需要的核心资源，是无法并行的：你的大脑。
我想给当下的现象起个名字：人类奖励机制困境。在机器学习中，奖励函数会告诉智能体什么是“好结果”。手动写代码从来都不容易，但过程中充满了小确幸：在脑中解决一个难题、理清一段复杂逻辑、看着代码成功编译、掌控全局的感觉。而LLM辅助编程把这些能带来多巴胺快感的工作自动化了，取而代之的是审核和监督带来的认知负担。让人满足的部分缩水了，让人疲惫的部分却膨胀了，而且没有新的奖励来填补空白。
如果你觉得自己的工作效率变高了，却更不满足了，那不是你的问题，而是反馈机制出了问题。我们应该把这当成一个工程问题来解决，而非归咎于个人失败。
而且，这种工作模式相当孤独。用LLM编程是一种极度个人化的活动。
只有你和机器来回互动：优化提示词、审核输出。原本你会转头问同事问题、用“橡皮鸭调试法”梳理思路、分享问题解决后的小喜悦，这些自然而然的时刻，都被一次次输入提示词悄悄取代了。在原本协作文化就薄弱的团队里，这会进一步拉大成员间的距离，让沟通变得冷淡——偏偏在这个时候，你最需要知道，不是只有你觉得这件事很难。
更糟的是，这种模式容易让人上瘾，加剧孤独感。有时候AI会给出惊艳的结果，有时候却是垃圾，你永远猜不到下一次是什么。这完全是斯金纳箱的经典模式。你可能很难停下来，忘了自己其实可以……直接写代码。但在LLM辅助和手动编程之间切换是很别扭的，两种思维模式截然不同，需要足够成熟和自信，才能坦然做出切换的决定。
这让我想起响应式设计带来的恐惧和焦虑。当时我是一名设计师兼前端开发者，和所有人一样追着Ethan Marcotte、Zeldman以及A Book Apart的内容。我至今记得，当得知我们苦练多年的固定宽度布局即将成为过去时，那种强烈的不安。
年轻的开发者可能不知道：2009年前后，网站设计经历了一次真正的变革——从固定像素、精准如杂志的布局，转向流畅的响应式布局。当时设计师们都恨透了这件事。对于那些把个人职业认同建立在精准布局和完美网格上的人来说，失去控制权简直是“灭顶之灾”。你告诉我用户可能在任意宽度、任意设备上看到我的设计？我精心打磨的布局居然会“流动”？
当时的抵触情绪非常强烈，但完全可以理解。人们在一套范式里积累了实实在在的专业能力，却遭遇了根本性颠覆。而那些顺利转型的设计师，都重新定义了自己的技能：对比例的敏感度依然重要，对层级结构的理解依然重要，技艺没有消亡，只是进化了。不再重要的是对像素级控制的执念，取而代之的是对系统、适应性和不确定性设计的理解。
我不想过度夸大这种类比。响应式设计的演变历经数年，而当下的变革只用了几个月。响应式转型期间，有些代理公司失去了客户，有些设计师丢了工作，但那种焦虑远不及现在。两者的风险量级不同，当下的节奏也远比当年的响应式转型更让人疲惫。但其中的核心逻辑是相通的：技艺会进化而非消亡，核心技能只会更重要，而不是相反。
用LLM写代码，感觉就像站在类似的转折点上。技能没有消失，只是发生了转移。你没有因为没亲手写每一行代码就不再是工程师，但你依然需要知道什么是好代码——甚至比以往更需要，因为你现在是海量输出内容的质量把关人。
在这个任何人都能做出看起来不错的UI、写出能编译的代码的时代，真正能区分高下的是：品味、洞察、成熟的架构判断，以及基于真实经验而非模式匹配做出的逆向决策。
我注意到一个现象：在我们对代码、决策和权衡理解最深刻的领域，引导LLM的效果最好。一旦涉足我们技能薄弱的领域，输出的内容就会变得非常“虚有其表”——离可投入生产的标准相去甚远，看似合理，实则错误百出。模型不知道自己不知道什么，所以会自信地填补空白。是不是听起来很熟悉？这其实也是人类常犯的错误。
但新的技能也在涌现。我开始对复杂方案做“事前复盘”：开启一个新的LLM会话，让它假设方案彻底失败，然后分析原因。这能找出我沉浸在细节中两天都没发现的漏洞。我们的一位工程师开发了一个工具，从他过去数千条代码审核评论中提取规则，生成AGENTS.md文件，把多年积累的隐性工程判断转化为LLM可以遵循的指令。这不是专业能力的消亡，而是专业能力的提炼。
当下能站稳脚跟的人，似乎都有几个共同点：他们有从实践中得来的坚定观点，能区分依然适用的原则和只是为了节省精力的习惯，愿意在不放弃标准的前提下改进工作流。
我不认为当下的AI浪潮意味着软件工程职业的终结，但它确实会导致行业规模收缩，从根本上重塑工作内容。对被淘汰的恐惧是合理的，对技能退化的担忧是合理的，对跟不上节奏就会落后的焦虑——虽然往往被夸大，但也并非毫无根据。
但瓶颈从来都不是代码本身，而是人的注意力、工程判断力，以及对系统保持连贯愿景的能力。以前我们没注意到这一点，因为写代码似乎是最难的部分。现在写代码被自动化了，这些人类独有的能力才显现为真正稀缺的资源——而稀缺资源总是有价值的。
所以如果你感到不堪重负、心神不宁，明明效率更高却更不快乐，请知道你不是一个人。开发你正在使用的工具的团队，也在经历同样的感受。我们和你一样，正在实时调试自己的奖励机制。
代码在变，我们使用代码的方式在变，随之而来的感受……还在摸索中。
但人类依然在这个循环里。我们只是累了。而这件事，值得被拿出来谈谈。
我们正在开发工具来降低这种混乱：Pydantic AI和Logfire。同时我们也在招人。