又一篇关于 LLM 的随想文。我知道，这题材很常见。先别急着划走。
这篇文章是我想把一种大多数开发者都在经历、却还没时间解释清楚的感受说出来。与 LLM 一起编程既真的是高效，也确实会让人失衡。两件事并存。若我们假装第二点不存在，最终只会把自己逼到 burnout。
在 Pydantic ，我们在做开发者用来校验数据、构建 AI agent、以及观测生产系统行为的工具。我们本质上是在做让 LLM 驱动的软件更可靠。我们也确实正在经历一段很奇怪的时期。
这不是在讨论 AI 是否会取代程序员的观点文章，也不是末日文，更不是炒作文。它更像是站在内部的一名开发者，尽量诚实地说出当下的体验，并给出一些也许真的有帮助的想法。
双手与现实边界
我在二十岁出头第一次认真学编程时，曾有一种很强的感觉：写代码仿佛把双手伸进宇宙的纹理里，按自己的意愿去塑形。那当然是我还没踩太多编译坑之前的事。只是这种“用纯抽象从无到有造出东西”的触感，一直留在我脑海里。
我不是计算机科学出身；我是个设计师和程序员——前者是正式训练，后者是自学。相比于课堂，我更多是靠踩坑把软件工程的形式意识学会。也正因如此，等我真正理解这些原则时，反而更重。你若曾经靠代价高得惊人的教训才形成架构和代码质量观，规则就不会再像教科书条款，更像烙印。
这种“创造感”早就出现在 2010 年代的低代码与无代码浪潮里，它们一再承诺、却始终没真正兑现。那时我还记得在 Dreamweaver 里做网页，也看过 Adobe 推出的所谓零代码工具——表面上很会画，底下却是一锅意大利面。它总是“差一点点”好，像在给未来做试飞：你只要够聪明，就快能触手可及。
如果你对当前 AI 工具的热潮持怀疑态度，我理解。我们以前也被这样许过诺了。不过这一次，承诺和现实的差距，终于真正、实在地缩小到有意义的程度了；正是这点，反而更让人不安。
“代码自己写了”到底是什么感受
代码在某种意义上确实“自己写了”，但做 review、指令、微调方向的人反而更疲惫，而不是更轻松。
我最近和同事 Douwe 聊过。他维护 Pydantic AI 框架，是我见过最能把 LLM 与开源协作想清楚的人之一。他说他每天早上会起来处理三十来个 PR——都是前一晚由某个 AI 拉起的——然后要对每一个都快速判断。要把 review 本身也交给 AI 的诱惑很强。但他说得很直白：
“那我还在这儿干什么？”
说实话，最近几个月，我也有几天几乎花了快两天时间给一个 LLM 写执行计划：反复澄清、反复定界、反复重写，最后它还是会做出某些莫名其妙的低级错。比如把 React hook 搬进 Storybook 的 story 文件；读取了错误的计划；创建了并不存在的组件。这些错误很多不是“不会做”，而是“没保持一致”。模型会生成看似合理的代码，但并不总能在复杂变更里保持一致意图。
这就形成了另一种新的疲惫：监督疲劳。你脑子里要持续握住目标，而机器在源源不断产出“看起来大多数正确”但仍需要你去看、去判断、去把关的内容。
Douwe 说得很到位：他以前在开源里和真实的人并肩做功能时，会有一种多巴胺反馈——帮助某个人成长、把一件事做出价值。现在他说：
“我写的东西全都进了一个 AI 黑洞。那边没有一个人真的把东西学进去。”
那种失落是真实的，值得被认真说出来。
强度陷阱
Simon Willison 最近提到了一份 Berkeley Haas 的研究：AI 会把工作强度推高。每天最后那一刻，“再来一次提示词”“再补一个特性，刚好能把这件事做完”。我太有体会了。前几天我熬到快凌晨两点，一直在写提示词，因为我觉得自己“马上就快把计划写对了”。
Pydantic 的另一位同事 Marcelo 曾经被问到 Claude Code 挂起时怎么应对，他说：
“直接开 5 个 Claude 会话。你都不知道自己在做什么，因为你一直在给别的会话喂反馈。”
他是在开玩笑。可能吧。但这句话抓住了一个现实：并行很刺激，也很“野”。你能开始的事情激增了，但你能负责完成的节奏没变，因为要完成，依赖的仍然是唯一的一种资源：你的大脑。
我想给当下起一个名字：人类奖励函数失配问题。在机器学习里，奖励函数告诉 agent 什么叫“好的行为”。手工写代码并不容易，但它带来很多小而连贯的奖励：在脑里解开一个问题、理解一段复杂逻辑、看到构建通过、重新掌控感。
LLM 辅助编程把这些奖励中很大一部分自动化了，同时把注意力负担从“编写实现”移到了“评审和监督”。有价值的部分缩小了，消耗能量的部分变大了。中间那块空隙却没有新的奖励去填。
如果你也有同感：效率更高、却更难获得满足，这不是你个人“撑不住”了。你只是踩中了一个被打乱的反馈回路。我们需要把它当成一个工程问题，而不是个人失败。
坦白说，这也很孤独。和 LLM 搭档编程，本质上非常个人化。
你和机器来回、再来回，边修边问边回看。平时能和同事探讨、口头拍脑袋、复盘一个终于理清的小胜利的自然时刻，被悄悄替换成“再发一个提示词”。在团队里没有强协作文化时，这会进一步让人疏离，在最需要“别人也在努力着”的时候，沟通反而变慢了。
而且它很容易上头。你有时得到非常好的结果，有时是垃圾，但不确定性总在旁边拉扯你。教材式的斯金纳箱。很难下意识地提醒自己：你其实可以停下来，直接去写代码。只是 LLM 辅助和手工工作之间切换很不顺，思维模式完全不同；给自己准许切换，需要一点成熟和自信。
临界点
这让我想到响应式设计曾带来的焦虑与恐惧。那时我还是设计和前端开发者，跟着 Ethan Marcotte 与 Zeldman / A Book Apart 的浪潮走着，记得当时“我们熟悉的固定宽度画面设计”被宣告过时时有多不安。
年轻开发者可能不太感同身受：2009 年前后，网站从固定像素、杂志级精准布局，转到流体响应式布局。设计师很抵触很合理。
那种身份认同是建立在精确控制上的：你得让用户看到你在任何宽度上都准确。告诉我：我的布局可能在任意宽度、任意设备上展示？我辛苦打造的布局还会“流动”？
Image design by Jyotika Sofia Lindqvist
这波阻力很强，也很容易理解。大家在一个体系里积累了实质性经验，结果体系被从根上改写。那些走出来的人，不是舍弃工艺，而是重构了工艺。比例判断仍然重要，层级理解仍然重要。手艺没有消失，只是演化。
不再关键的是“像素级控制”，而是更重系统思维、适应性和对不确定性的设计。
我不想过度比喻。响应式转型是跨年发生，而现在这种变化以月为尺度推进。那次转型也伤过人，影响过业务和职业，但并没有这种当下的生存级焦虑。节奏更快，代价更重。不过一个共同点是成立的：工艺没有消失，而是形态变化；核心能力不是变少，而是被重新定义。
和 LLM 写代码的变化很像。能力并没消失，只是迁移。
你不是因为没自己手写每一行就不再是工程师，但你更需要知道“什么是好”，也许比以前更迫切，因为你现在要做的是更高产出量下的质量闸门。
哪些能力会留下
当任何人都能做出看起来合理的 UI 和能通过编译的代码时，真正让你能被区分开的，是：
- 美感与取舍
- 细腻判断
- 成熟的架构立场
- 来自真实经验，而非纯模式匹配的逆向思考
我越来越明显地看到：我们在引导 LLM 时最成功的，是对代码、决策、权衡理解最深的领域。越是接近自己薄弱的边界，输出越会“看起来像样”却不够严谨，离可上线状态更远。模型不会知道自己不知道，于是用“很自信”的句法把空白填满。这个失真，太像人的一种失败模式了。
但新技能也正在出现。我开始做我称之为“逆向复盘”的事：给一份新的 LLM 会话一个前提——假设计划已经灾难性失败了——让它诊断原因。这样会抓到我在深入细节两天后漏掉的规范空洞。
我们团队有位工程师做了个小工具：从他过去数千条 code review 评论里抽取规则，生成 AGENTS.md。本质上是把多年隐性工程判断，编码进 LLM 能遵循的指令。那不是“经验消失”，而是经验被提炼了。
我看到现在站稳的人，通常有几个特征：他们有通过实践打磨出来的明确立场，能区分哪些原则还适用、哪些习惯只是应对当下资源限制的“过时动作”，并且愿意在不丢标准的前提下，更新工作流。
从回路内部看这次变化
我不认为当前这波 AI 是软件工程职业的终点。我认为它是一次严肃收缩、结构性重塑：工作本身正在变化。
“被淘汰”的担忧是合理的。技能退化的担忧是合理的。“跟不上节奏会被落下”——虽然常常被夸张放大，但也并非完全无凭空想象。
真正的瓶颈从来都不在“会不会写代码”，而在人的注意力、工程判断、以及对系统持有一致愿景的能力。过去这一步被写代码的劳动掩盖了，现在写代码被自动化后，人类能力被更清楚地暴露出来：它们才是稀缺资源，而稀缺恰恰意味着更有价值。
所以，如果你现在觉得自己超负荷、失衡，生产更高效却更不快乐，这不是你一个人的问题。打造工具的人也在同一时刻经历这个阶段。我们和你一样，正在实时调试自己的“奖励函数”。
代码在变化。我们做它的方式也在变化。怎么去感受这变化——还在进行中。
但人仍在回路里。我们只是累了。
这点值得被看见。
我们正在做这些工具，尽量让这一切少一些混乱：Pydantic AI 与 Logfire。我们也在招聘。