你是否正走向AI倦怠？担心工作被编程能力不强、不追求质量、却坐拥庞大Claude账户的人抢走？对项目代码质量失望，甚至对自己写的代码失望？这篇就是为你写的。关于大型科技公司运行前沿LLM的伦理担忧不在讨论范围，作者也声明此文百分之百由人写成，未经AI辅助。他提到少年时读过肖恩·麦克马伦（Sean McMullen）的同名小说《Souls in the Great Machine》。

你在走向 AI 倦怠吗？害怕被编程技能不多、不追求质量、却握着巨额 Claude 账号的人抢走工作？对项目代码质量失望，甚至对"自己"的代码失望？这篇是给你的。

关于大科技公司运营的前沿 LLM，有显著且正当的伦理担忧，这些已被充分讨论，我清楚也同意，本文不谈。别把我当成亲 LLM 的科技兄弟。

另外，因为有人曾误以为我的文字是 LLM 生成的，我声明：这是 100% 人写的，没有任何 AI 辅助。

大机器中的灵魂

Sean McMullen 有本同名好书，我十几岁时很喜欢。第一眼看上去它描述的是我们的反面：一台大计算机，各部件是人，协作组成计算单元。而 LLM 本身运行在真实计算机上，假装成（超级）人类。再看一眼，故事与现实并不远：我们在软件生产中的角色正从行动者慢慢降级为机器里的齿轮。规格驱动的反乌托邦就是：我们被下发一份规格，塞进 LLM，然后因为技术封建领主决定少发点 token 而哭泣。

作为 Haskell 程序员，我喜欢写 Haskell。是的，我喜欢工作中的产品，喜欢我的开源库能做的事，但我真正享受的是用这门语言表达思想的过程。我假设你们大多如此，而很多其他语言并非如此，这某种程度上解释了为什么不同语言的爱好者对 LLM 辅助未来的明暗看法不同。

当我生成代码时，这种乐趣很大一部分处于危险中。所以，也许别这么做。我想继续写（至少是有趣的部分）Haskell 程序，而不是不得不读和审查（太多）生成的代码。同时，我想把那些 token 用在不会慢慢烧坏我大脑的地方。

我想展示一条既能继续享受编程、又能用 LLM 适度提高生产效率的路，而不是看起来效率高得多却失去所有乐趣。

如果你只想完全不用 LLM，那也很好，你已经知道自己在做什么。但有些理由让你不想这样，比如你确实需要带来真实的生产力提升，或者你不想在团队、公司、行业都走向重度 LLM 采用时被落下。

继续写代码

如果你想继续拥有你的代码库，就得继续写一些代码。如果全让生成，它会变成 LLM 荒地，只有你的编码智能体能在上面繁衍。所以你应该继续写代码，否则你的代码库最终会丢失。

另一个理由是保持自己是好程序员。技能不用就会丢，而这里风险特别高，因为放弃编码交给智能体的门槛非常低。几周不写码、全交给智能体，你会发现很难再回来自己写。

LLM 产出好的、人类可读的代码的能力远不如宣传的那样。它们产出自己后续专属处理的代码还算可以。但我想你已体验过那种绝望：看着一个完全生成的文件，里面某处一定有 bug，而你作为人类觉得自己找不到，因为那片地形太陌生了。

那么，如果不让智能体写代码，怎么获得生产力提升？让它们做几乎其他所有事。特别是那些让你烦的枯燥工作。理想情况是不太难做对、且容易检查的任务。

规划

自计算机最早的历史以来，它一直被当作记账工具。这样用 LLM。除其他事外，它是一个你能用自然语言而非正式接口对话的记账工具。把领域专家之间的大段书面对话转成可执行的待办事项。测试某个东西，写下测试结果，让它整理成修复缺陷的计划。

用待办工具，或者更好是用带 frontmatter 的 markdown 文件，让规划项得到妥善跟踪。LLM 可以有巨大的上下文，但如果太满，它仍可能悄悄丢失信息。

但别让它做任何关键决策。让它来问你。如果你不理解问题，是 LLM 的错，没给你相关上下文（或者你可能累了，需要休息）。如果你反复回到同样的问题，从屏幕前退一步，自己想清楚，等你对想要什么有清晰图景再回来。

调研

当你给智能体一个调研任务，看它查询和"思考"、去启动另一个项目的另一个智能体、或者去泡咖啡，都很诱人。三者中，泡咖啡最好。更好的选择是：用古老搜索引擎并行自己调研。至少大致知道智能体将知道的一切。

别只是让它调研某样东西、接受结果当事实、然后据此规划。这会导致尴尬的技术债。

让智能体调研的重点不是让它把相关知识都呈现给你，或做出比你更好的决定。重点是你不必对它说"让我帮你 Google 一下"。你应该对建模的领域理解得和智能体一样好，最好更好。

让智能体把调研结果写下来，附上所用资源的链接。当它之后回来给你一个古怪提案，问它调研怎么说、哪个资源这么说。50% 概率它会发现自己的错误。另外 50%，读一读，现在你有能力自己做出好决定。

你才是编码者

这是改变游戏的一点。

典型的编码工具链引诱你"先规划，再让智能体编码"。拒绝。一起规划，然后你编码。让 LLM 调研你的代码库，让它告诉你当前待办、列出所有需要修改的地方，让它提潜在陷阱，让它提醒你相关背景调研。

我用这个工作流工作，非常有趣。我享受我的工作。有时甚至比 LLM 之前更享受。我总是有清晰的待办，不用担心整体计划，我能专注，待办很快完成因为规划得好。像敏捷，但没有那些烦人的流程。

让智能体围绕你的工作方式，而不是反过来。也许你是有经验的程序员，已经知道自己怎么工作最好。让智能体做你周围那些你不太享受的杂事。

这个工作流有多个优势：

1. 你继续做你享受的事。如果你喜欢编程，就编。
2. 你始终知道代码库处于什么状态。曾被自己 vibe coding 会话里冒出的古怪生成内容吓到？需要重写 LLM 垃圾？搞不清会话进行到哪了？这样你再也不用。
3. 你早早发现坏计划。智能体编码者可能一直做下去，而你会很快认出这是个坏主意。
4. 你持续磨练技能。显然，你会保持是好的程序员，甚至继续提升。

编码智能体有用的少数情况

理想情况是清理、小任务、例行工作、低风险重构。你在代码里留了 FIXME（也许为了省时省力）？你写了 3 个有趣案例，剩下 7 个相似的枯燥案例？你想重组模块并要基准测试？需要换掉一个不再维护的库？这些是合理用例。从零设计复杂东西大概不是。

有时你时间不够但想完成某样东西，也许计划里剩下的待办都是明显的低风险任务。可以对监督智能体说"我离开一下，完成这个"，运气好第二天早上回来功能就完成了。但大部分编码工作自己做很重要。

这里有些小陷阱：

• 你写了那 3 个有趣案例，告诉智能体完成剩下 7 个，因为它们只是你写的那些的明显改编。可能你该做的是抽象。也许你真正在做的是应用一个 lens 或其他 optic？也许这真的是某个流行类型类如 Traversable 的实例？LLM 以不识别这点而闻名，反而复制大段代码。你作为人类要追求更好读、合理的代码。
• 同样适用于"让它提潜在陷阱"。是的，LLM 可能很擅长走完整个调用链，确保你该碰的地方都列在待办里。但与其依赖它找所有这些耦合，你该考虑你的代码库是不是组织得糟糕，逼你一开始就用 LLM 做代码调研。

审查循环

你可能记得 AI 生成图像在生成对抗网络出现后突然变得逼真得多。简言之，一个模型（"生成器"）生成图像，另一个（"判别器"）告诉它表现如何。两者一起能产出比生成器单独好得多的结果。把这个想法（其广义形式并不新）应用到 LLM 辅助编码，你得到自动审查循环。

别接受、甚至别读任何未经自动审查循环的 LLM 产物。这显然直接适用于代码（在那些你仍让它生成的场合），但尤其也适用于规划。当智能体编码了某样东西，它交回来时工作没完，工作完成（即适合人类看）是在审查智能体不再有发现时。计划也一样。走查计划里的逻辑漏洞（在 todo 2 里重构一个计划在 todo 7 里写的函数）真的很累，所以加一个审查智能体来做这事。

我发现让人审查自己的代码出奇地有帮助。有时它只是提些小毛病，或坚持膨胀 Haddocks，但经常它找到真正的 bug 或遗漏，并让我专注在实际待办上。我推荐把审查循环加到你自己的工作里，但我完全理解你不想读 LLM 对你代码的审查。绕开这点的一个方法是告诉它，如果剩余发现是小问题就自己修。

前沿

你完全没充分利用前沿模型的能力。

网上某个 vibe coder

是的。这是我观点的逻辑结果。

但依赖前沿模型特性是坏主意，有多个理由。

1. 环境成本。前沿模型耗费巨量能源，这多少是猜测，因为 LLM 公司对自家玩意儿怎么运作不太透明。
2. 很难对假装比你聪明得多的东西建立信任。最终，你要为你产出的代码负责，不是你的机器。为自己的代码怪别人是坏经理和坏同事对员工做的事，对机器这么做很荒唐。所以以你能对结果负责的方式使用 LLM，这只有让你自己成为过程不可分割的一部分才可行。
3. 最花哨的模型用最多 token，所以无法预知你在某次会话里能否用它完成任务。用小模型能做的一切都是更稳妥的赌注。
4. 当你的工作流不需要前沿模型，你就有机会最终用开放权重或开源模型替代它们，完全不再依赖技术封建领主。

最终，你做的是复杂工作。在某些方面，LLM 可能表现相同甚至稍好。但这远不足以向它们低头，因为它们所有缺点。LLM 要比人类开发者好很多倍、用更少资源、在复杂现实情境中更可靠、至少同样对齐、并以某种方式对结果负责，才能取代人类开发者的核心活动。

没 token 了？

也许你经历过工作因 token 用完而停摆。很烦。你的工作流现在围绕一个你突然无法访问的工具构建。极端情况下，你什么都做不了。拿这个 xkcd，把"编译"换成"没 token"，作为处理这种情况的健康方式。

如果这发生几次，你可能感到被背叛。你是对的。你被背叛了。你在特定会话、特定计划里有多少 token，是个不透明的数字，取决于某个大技术封建领主的心血来潮。它不像你在公平市场上买来、然后可计划使用的商品。

你需要停止把 token 耗尽看作"买得太少"，开始把它当作它本来的样子：服务中断。你的 LLM 公司卖给你一个你能使用 LLM 的承诺，却没兑现。你会话里的最大 token 数可能在你不知情、无法影响的情况下变化，所以你也无法真正为它规划。

当然省 token 是必须的。重新评估你的智能体设置、用法、上下文大小、技能等，以省 token。但即使这么做，即使你买了更大的席位，也可能不够。

当你做了一切来省 token 之后还是用完，别把它看成"你的错"，把它看成需要准备的技术故障。如果你曾在火车或飞机上大量工作，你知道必须为不时没有网络做准备。提前下载并缓存大资产。总有可离线做的活。

对 LLM 辅助工作，这意味着你得让它为你需要做的每件事产出有形的产物。最重要的是，如果你适应我描述的人类编码者工作流，确保你总有一份可执行的待办清单。享受快速通关它们，等你的智能体回来，让它做清理。

LLM 胡言乱语

LLM 产出的文本不像人类文本。特别在 LLM 其实不太知道自己在说什么时变糟。把 LLM 胡言乱语看作可能对你的心理健康有害。别消费太多。继续和人聊你的代码，特别是更大的愿景和有趣的方面。只在自动审查智能体磨平棱角后再读 LLM 产物。

当你头晕脑胀，休息一下。是的，即使当前没有智能体在后台运行、"产出价值"。你的心理健康比工作产出更重要。

你的人类同伴

编程基本上是社交活动。比如在公司或开源项目里，我们互相发 pull request、写 issue 和提交信息。这是一种沟通。即使你是项目里唯一的人，你的过去自我也为未来自我写 issue、提交信息和 PR。人与人之间的沟通是软件开发的支柱。

确保你总是以人优先的方式与人打交道。别给某人发完全生成的 PR。我意外这么做过一次，对面有理由感到受够了。我确保不再重复这个错误。

智能体会主动提出用语法正确的语言写完整 PR 正文，所有细节都在里面。这不是沟通，这是工具输出。把这类文本像基准测试数字或调试跟踪一样对待：把它们附在你手写的 PR 正文后面，也许放在折叠块里，让人自己决定要不要读。你会发现他们往往不读。

我的经历

有了这些，我比没有 LLM 辅助更有生产力。具体很难说，也许快一倍？比许多全职 vibe coder 吹嘘的要少，但没关系。我想象自己是采用温和有机肥的园丁，而 vibe coder 更像用工业化学品淹没田地。我相信我的方式目前更可持续。

我爱用 Haskell 编程，以此为生是我的梦想工作。上个月我担心这个梦想已成过去。但我写的这一切，正是我为了保持这项活动令人愉快而学到的。看起来有效。

社区对用大型语言模型写代码态度明显分化：多数人将其用于繁琐任务并感到更轻松，但不少人担忧技能萎缩、同事滥用致质量下滑，或坚持爱好手写以留存乐趣。

认为将繁琐编码交给LLM、自己专注设计与审查是高效模式

• 让模型生成解析器、单元测试或比对生产数据，人类保留架构决策与复杂逻辑手写，认可度：较多人 > 乐意让模型生成CSV解析器，但复杂的状态机仍想自己写（@sparrowidle）

认为LLM消除了编程中最无聊的部分从而提升乐趣

• 样板、查文档、写重复测试交由模型后，规划接口与审查等心智活动更令人兴奋，认可度：较多人 > 模型拿走了这行最糟糕的部分，留下享受的部分（@poisonborz）

担忧把任务让给LLM会导致自身技能萎缩

• 一旦习惯性委托，架构构思等能力会退化，需刻意练习保持，认可度：较多人 > 任何事推给模型，那项技能就会萎缩（@beej71）

认为工作被迫用AI而业余爱好仍可享受手写编程

• 上班为赶工期难免用模型，但个人项目可只做想做的部分，手写乐趣未减，认可度：较多人 > 工作中被迫用AI赶截止日，但作为爱好编程依然完美（@jdw64）

批评团队中滥用LLM产生大量方向错误的代码

• 同事直接丢给模型生成巨量拉取请求，常解错问题，产出快却不对，认可度：较多人 > 像一半人关了脑，我们产出更快却不做对的东西（@matsemann）

主张完全不使用LLM以保留编程心智与能力

• 自行从零实现语言并手写代码，避免认知技能被替代，认可度：少数人 > 不用模型否则会逐渐丧失用编程语言思考的能力（@DonaldFisk）

认为LLM正民主化编程能力并引发老手不满

• 普通人在模型助力下也能建可维护程序，老手多年积累的知识免费开放令人愤懑，认可度：少数人 > 多年硬挣的知识被路人无偿获取，激怒了每个人（@adithyassekhar）

偏好低推理小模型加人工掌舵以维持掌控感

• 用快而弱模型听指令写片段，决策权在自己，比大模型群集体空转更连接工作，认可度：少数人 > 小模型加紧缰绳，决策来自我，比代理群更懂自己的作品（@cautiouscat）

提醒方向错误时速度无意义、研究不可跳过

• 恐慌中跳过调研直接让模型生成，反而背离目标，认可度：少数人 > 方向错了跑再快也没用，大家慌得跳过了研究（@Ailogeneous）

有价值的补充

• 接只读副本与模型比对生产数据形状，静态捕捉字段误称（@superjose）
• 模型极速阅读并重述模块，非常适合梳理大型代码库（@humlex）
• 自设计Lisp方言且只发图片代码，从根上杜绝模型代写（@DonaldFisk）
• 云代理编队需配全栈测试环境，才能高速合并不丢信心（@jonator）