又一篇关于 LLM 的随笔。我知道。请先耐心听我说。
我想试着为一件事说清楚几句话：我觉得大多数开发者此刻都在经历它，却还没来得及把它理清。用 LLM 编程确实有用，也确实让人失去稳定感。这两件事同时成立。如果我们假装后者没有发生，所有人都会精疲力竭。
在 Pydantic，我们打造开发者用来验证数据、构建 AI 智能体，以及在生产环境中观测系统行为的工具。说得直白一点，我们的工作就是让由 LLM 驱动的软件更可靠。而我们自己，也正经历一段很奇怪的时期。
这不是一篇讨论 AI 会不会取代程序员的文章。它既不是末日论，也不是宣传稿。这是一个身处其中的人的诚实记录：此刻做开发者究竟是什么感觉，以及我认为真正可能有所帮助的一些想法。
把手伸进织物里
我二十出头刚学编程时，清楚记得一种特别的感觉：编程让我能把手伸进宇宙的织物，并按自己的意志为它塑形。当然，那是在我撞上太多编译错误之前。但那种触碰某个深层、根本的抽象层，单靠逻辑就能从无到有地创造东西的感觉，一直留在我心里。
我不是计算机科学专业毕业的。我是设计师，也是程序员——前者受过正规训练，后者全靠自学。我不是经由学术教学，而是通过痛苦的经验才理解软件工程的那些形式化方法。真要说的话，一旦理解了它们，我反而更认真地对待这些原则。用艰难代价换来的架构与代码质量见解，不再像教科书里的规则，更像是一身疤痕。
那种原始的创造感？这正是 2010 年代低代码和无代码工具不断承诺、却始终没有真正交付的东西。我年纪大到还记得用 Dreamweaver 搭网页，也记得 Adobe 鼓吹那些零代码设计工具，而它们在底层生成的完全是一团打结的面条代码。它总是差一点就到了，只够让人瞥见一个仿佛近在拐角处的未来（只要你够聪明，能把它抓住）。
如果你对这波 AI 工具持怀疑态度，我理解。我们以前也被这样承诺过。但这一次，承诺和现实之间的鸿沟终于缩小到了有实际意义的程度。而这恰恰也是它如此令人不安的原因。
“代码自己会写”实际是什么感觉
是，代码（某种程度上）会自己写了；但负责审阅、引导和纠偏的人，感觉反而更糟，不是更好。
我最近和同事 Douwe 聊过。他维护 Pydantic AI 框架，也是我认识的、对如何把 LLM 融入开源工作流思考最深入的人之一。他说自己每天早上醒来，会看到三十个 PR，每一个都是有人让自己的 AI 连夜提出来的；他必须对每一个迅速做出判断。把审查本身也交给 AI 的诱惑极大。但正如他说的：“那到头来，我还在这里做什么？”
坦白说，过去几个月里，有些时候我花了近乎整整两天，为一个 LLM 将要执行的工作写计划：执拗地澄清、规定、再规定，却还是让它莫名其妙地做出蠢事。把一个 React hook 挪进 Storybook 的 story 文件。读错计划。凭空发明不存在的组件。这些不是能力层面的错误，而是连贯性层面的错误。模型已经聪明到能产出看起来合理的代码，却不总能在复杂改动中维持一致的意图。
这带来一种奇特的新疲劳：监督的疲劳。你必须把意图一直留在脑中，而机器不断生成海量、大体正确、却仍需要你的眼睛、判断和品味来检查的输出。Douwe 说得很好：过去他和真实的人在开源项目上协作一个酷功能时，会获得多巴胺的满足感——帮助别人精进自己的手艺。现在，他说：“我写的每一句话都掉进某个 AI 黑洞。另一头根本没有一个真正从中学习的人。” 这种失去是真实的，值得被说出来。
强度陷阱
Simon Willison 最近提到了一项 Berkeley Haas 研究：使用 AI 会提高工作的强度。一天快结束时，心里总有一股拉力：“再来一个 prompt，再加一个或许能让它变得完美的功能。”这句话直击我。我最近有一次几乎一直 prompt 到凌晨两点，因为我就差一点能把一份计划调对了。至少我当时是这么以为的。
Marcelo 是 Pydantic 的另一位同事。有人问他 Claude Code 会话卡住怎么办时，他说：“那就开 5 个 Claude 会话。你忙着给另外几个反馈，根本不会察觉。” 他是在开玩笑。我想是吧。但这捕捉到了当下某种真实。并行带来的感觉令人兴奋，又有点野蛮。你能启动的事情数量大幅增加；你能认真完成的事情数量却完全没变，因为那部分依然需要我们无法并行化的唯一资源：你的大脑。
我给眼下发生的事起个名字：人类奖励函数问题。在机器学习中，奖励函数告诉智能体什么才算“好”。手写代码从来不轻松，但它充满了一个个小奖励：在脑中解开问题，理解一段棘手逻辑，看着代码编译通过，感受自己掌控了局面。LLM 辅助编程自动化了许多原本会带来这些多巴胺奖励的工作，却用审阅和监督的认知负荷替代了它们。令人满足的部分缩小了；令人疲惫的部分膨胀了。而没有新的奖励来填补这个空缺。
如果你觉得工作同时更高产、也更不满足，你没有坏掉。坏掉的是反馈回路。我认为我们需要开始把它当作一项工程问题来对待，而不是个人的失败。
而且，说实话，这也很孤独。和 LLM 一起编程是一项极度孤身的活动。
你和机器来回交谈、改进提示、审阅结果。那些原本会自然发生的时刻——你转向同事问个问题、把难题讲出来借此理清思路，或分享一个终于打通的小胜利——悄悄被又一条 prompt 取代。在一个原本就缺乏强协作文化的团队里，这会让人们进一步分开，让沟通在你最需要确认“其他人也觉得这很难”的时刻冷却下来。
它还以一种会加剧孤立感的方式令人上瘾。有时你得到惊艳的东西，有时是一堆垃圾，而你永远不太确定会是哪一个。教科书式的斯金纳箱。要退一步并记起“你其实也可以就……自己写代码”，真的可能很难。但在 LLM 辅助与手动工作之间切换既突兀又不舒服，它们是两种截然不同的思考模式；让自己有权切换，需要一种成熟和自信。
断点
眼下这个时刻让我想到响应式设计曾带来的恐惧与焦虑。当时我是一名设计师和前端开发者，和所有人一样追随 Ethan Marcotte，也关注 Zeldman / A Book Apart 那一派。我记得，当人们告诉我们那些早已掌握的固定宽度布局基本要结束了时，感觉有多么不安。
给年轻一些的开发者补充背景：大约在 2009 年，网站从固定宽度、像杂志版面一样像素级精确的布局，转向了流动的响应式布局。这在当时是一个真正的文化时刻。而设计师讨厌它。对于那些整个身份认同都建立在精确布局和完美网格上的人，失去控制是存在层面的冲击。你是说，用户可能在任何宽度、任何设备上看到我的设计？我精心制作的布局会……流动？
抵触情绪非常强烈，也完全可以理解。人们在一个正被根本性颠覆的范式中，建立了真实的专业能力。那些在转型中表现出色的设计师，重新理解了自己的技能。对比例的眼光仍然重要，对层级的理解仍然重要。手艺没有死去，它进化了。变得不那么重要的是对像素级控制的执念；变得更重要的是理解系统、适应变化，以及为不确定性而设计。
我不想过度推销这个类比。响应式设计的演进以年为单位；当前这场转变以月为单位。响应式转型中，设计公司失去客户，设计师失去工作机会，但它没有带来同样的存在性恐惧。风险在实质上不同，速度也确实快得令人疲惫，是响应式转型从未有过的。但我认为，底层的模式依然成立：手艺是在演化，而不是消亡；核心技能变得更重要，而不是更不重要。
用 LLM 写代码也像是类似的拐点。没有亲手写下每一行，也不会让你变得不那么像工程师。但你仍然需要知道什么叫好——可以说比以往更需要——因为面对大得多的输出量时，你就是质量关卡。
什么会留下
在一个任何人都能做出看起来还过得去的 UI、写出可以编译的代码的时代，真正的区分标志变成了：品味、细腻度、成熟的架构判断，以及源于真正经验、而非模式匹配的不随大流的判断。
我注意到，在那些我们最深入理解代码、决策与取舍的领域里，我们最能成功地引导 LLM。一旦进入自身技能的浅水区，产出就明显更像印象派：离生产可用更远，看起来更可信，实际却更不正确。模型不知道自己不知道什么，于是自信地填补空白。听起来耳熟吗？这也是一种非常人类的失败模式。
但新的技能也正在出现。我开始对复杂计划做一种我称为“失败预演”（pre-mortem）的练习：让一个全新的 LLM 会话假定计划已经灾难性失败，再诊断失败原因。它能发现那些我在细节里埋了两天后已经看不见的规格缺口。我们有一位工程师做了个工具，从他数千条历史代码审查评论中提取规则，作为 AGENTS.md 文件的种子；本质上，是把多年隐性的工程判断编码为 LLM 可以遵循的指令。这不是专业能力的死亡，这是专业能力被蒸馏了。
那些正在找到立足点的人，似乎有一些共同特质：他们拥有通过实践赢得的坚定看法；他们能区分哪些原则依然适用，哪些习惯只是过去带宽限制下的产物；他们愿意演进工作流，却不放弃自己的标准。
来自环内的视角
我不认为当前这一波 AI 是软件工程作为职业的终结。但我确实认为，它意味着显著的收缩，以及工作本身会被根本重塑。对被淘汰的恐惧是合理的，对技能退化的恐惧是合理的；对“如果跑得不够快就会被甩下”的恐惧——虽然常常被夸大——也并非毫无根据。
但瓶颈从来都不是代码。它一直是人的注意力、工程判断，以及为一个系统保持连贯愿景的能力。我们之所以没注意到，是因为写代码感觉上才是困难的部分。现在它正被自动化，这些人类能力才显露为真正稀缺的资源。而稀缺资源是有价值的。
所以，如果你感到不知所措、失去稳定感，同时更高产却也更不快乐，请知道你不是一个人。正在打造那些你大概正用来穿越此刻的工具的团队，也有同样的感受。我们和你一样，正在实时调试自己的奖励函数。
代码在改变。我们用它做什么在改变。它带给人的感受也在改变……一切仍在进行中。
但人类依然在环中。我们只是累了。而这值得被谈论。
我们正在打造让这一切不那么混乱的工具：Pydantic AI 和 Logfire。我们也在招聘。