本文永久链接 – https://tonybai.com/2026/10/02/how-to-keep-enjoying-programming-in-the-llm-era
大家好，我是Tony Bai。
【导读】
AI确实能替你把代码写出来，可写代码本身带来的那份满足感，却常常在“甩给Agent”的过程中被悄悄拿走。最近，Haskell社区一位老玩家写了一篇长文，谈自己如何在大量使用AI的同时，仍然守住了编程的乐趣。文章发出后引发了不少共鸣，评论区也出现了一些值得细看的不同声音。
【文章要点】
- 痛点反思：编程手感正在被 AI 悄悄抽走：把代码编写全权甩给大模型，不仅会导致人类自身技能退化、陷入“AI 倦怠”，更会让代码库退化为人类难以看懂、无法排障的陌生荒原；
- 底线思维：代码必须亲手写：大模型更擅长生成“只有它自己能维护”的代码，为了保持对系统的长久掌控力与解决问题的嗅觉，核心实现绝不能假手于机器；
- 核心大招：“一起规划，但你来敲代码”：让 LLM 研究仓库、梳理任务脉络并提示技术坑点，但真正的敲代码环节由人类亲自完成，在极简心流中享受纯粹的创造乐趣；
- 引入 GAN 式自动化审稿流水线：坚持“未经自动化挑刺过滤的 AI 内容绝不采纳”，用专门的审查 Agent 与生成内容博弈，同时借助 AI 审稿反查自己代码中的盲区；
- 戒断“前沿模型迷信”与 Token 焦虑：不过度绑定黑盒且额度多变的高阶商业模型，随时储备可离线推进的任务清单，做长效可持续的“有机园丁”而非用化肥狂催进度的氛围编程者；
- 警惕 AI 车轱辘话的“精神石棉”污染：抵制缺乏真实理解的机器废话对心智的消耗，绝不把未经提炼的 AI 生成 PR 直接丢给团队，坚守技术沟通的人性与温度。
一个很多程序员都在问自己的问题
“你正在滑向AI型倦怠吗？害怕被一个几乎不会编程、毫无质量追求、但坐拥巨额Claude账号的人抢走饭碗吗？对自己项目里的代码质量，甚至‘自己写的’代码质量感到失望？”
这是Haskell核心开发者、单子驱动函数式编程框架 Rhine 的作者 turion，在Haskell官方论坛发帖的开场白。他给这篇长文起了个直白的标题——《How to keep enjoying programming in a world of LLMs》（如何在一个LLM遍地的世界里继续享受编程）。
这句开场白，说出了不少程序员这两年心里的一种隐约不安：AI确实让交付变快了，可那种“把想法亲手敲成代码”的满足感，却常常在一次次“甩给Agent”的过程中被慢慢消磨掉。
turion在帖子里特别强调，自己并不是要打一场“反AI”的嘴仗——前沿大模型背后确实存在不少值得警惕的伦理问题，但那不是这篇文章要讨论的重点，他也提前声明这篇文章百分之百是人手打字、没有借助AI代写。他想回答的是一个更具体、也更私人的问题：代码可以交给AI写，但编程的乐趣，要怎么才能不被一起拿走？
方法论拆解：把编程乐趣抢回来的6件事
turion给出的不是一句空洞的“少用AI”，而是一整套具体到可以照抄的工作法。核心逻辑很简单：把无聊的、事务性的工作甩给AI，把动脑子、有手感的部分留给自己。
底线：代码必须自己写
turion把这条摆在最前面，几乎是全文的地基。
他的判断是，如果把编写代码这件事全权交出去，代码库迟早会变成一片“只有Agent自己能活下去的LLM荒原”——人类如果放弃动手写代码，很快就会失去维护这片代码库的能力。更麻烦的是，编程技能是会退化的：只需要几周不亲自动手、事事都交给Agent，你就会发现自己已经很难再重新捡起写代码的手感。
他还补了一刀大实话：LLM生成“能跑”的代码不难，生成人能读懂、后续能维护的好代码却远没有宣传的那么厉害——它们更擅长写“只有它自己以后会继续维护”的代码。你大概率已经体验过那种绝望：面对一整个由AI生成的文件，明知道里面藏着bug，却因为这套代码逻辑对人类来说“完全陌生”，连从哪下手排查都不知道。
把LLM当“记账员”：规划（Planning）
turion提出一个很朴素的类比：计算机从诞生之初就是记账工具，AI也不例外，只是现在这个记账工具可以用自然语言对话，而不是填表格。
具体做法是，把开发者之间冗长的讨论、测试结果，丢给LLM，让它整理成可执行的todo清单，再用Markdown文件（带frontmatter）之类的形式做持久化记录——因为当前LLM的上下文窗口再大，一旦塞得太满，也会悄无声息地“丢内容”。
但规划的决策权必须攥在人手里。turion特别强调一条红线：不要让LLM做任何关键决策，而是让它来问你问题。如果你看不懂它提出的问题，说明是AI没给够上下文——或者，也可能是你已经太累了，该歇一歇了。
调研不能当甩手掌柜（Researching）
让Agent去做调研任务时，很容易忍不住去摸鱼——看着它一边“思考”一边检索，顺手再开个新项目支使另一个Agent，或者干脆去接杯咖啡。turion毫不客气地说：这三个选项里，接咖啡反而是最好的那个。
他给出的正确姿势是：你自己也要用搜索引擎同步做调研，至少要把Agent知道的东西也大致过一遍。千万不要把AI调研的结果直接当成事实、直接拍板往下走，这只会埋下让人尴尬的技术债。
他还专门强调了让AI做调研的意义所在：重点不是让它把知识一股脑喂给你、替你做出更好的决定，而是让你不用再对着搜索引擎“Let Me Google That For You”。你应该把这个领域理解到和Agent一样深、甚至更深。
具体操作上：让Agent把调研结果、引用来源都写下来存档；等它带着一个奇怪的方案回来找你时，追问它“调研依据是什么、出自哪个资料”——有大约一半概率，它会自己发现之前的错误；另一半情况，你正好可以借这份资料自己做出判断。
核心大招：“一起规划，但你来写代码”
这是turion自己称之为“游戏规则改变者”（game changer）的一节，也是整篇文章的方法论核心。
现在主流的编程Agent工具，几乎都在诱导你走“先规划、再放手让Agent写代码”这条路。turion的建议是：拒绝。
一起规划，但代码你来写。
具体来说：让LLM研究你的代码库，把当前的todo和所有需要改动的地方列出来，提示潜在的坑，帮你回顾相关的调研背景——但真正敲代码这件事，由你自己完成。
他形容自己现在的工作流“非常有意思”，甚至比用AI之前更享受工作：任务清单永远清晰，不用操心整体规划，可以专注在手头这一件事上，因为规划做得好，任务也完成得很快。用他的话说，这就像敏捷开发，但没有那些烦人的流程。
下面这张图，是我们根据turion描述的这套工作流画出的示意图：
turion总结了这套工作流的四个好处：
- 你一直在做自己喜欢的事——如果你喜欢编程，那就继续写。
- 你始终清楚代码库的真实状态——再也不会被自己“氛围编程”（vibe coding）跑出来的一堆诡异代码打个措手不及，也不用回头重写AI糊出来的“屎山”。
- 能更早发现糟糕的方案——一个自主编码的Agent可能会顺着一个错误方向一直跑下去，而这种问题人类一眼就能识别。
- 手艺不会生疏——这点不言自明，你会一直是个好程序员，甚至变得更好。
当然，Agent也有真正能派上用场的场景：清理收尾、小型任务、常规重复劳动、低风险的重构。比如代码里留的FIXME、只写了3个有代表性的case却还剩7个类似的、想给某个模块重组做个benchmark、想把一个不再维护的库换掉——这些都是合适的任务；但从零设计一个复杂系统，通常不适合甩给Agent。
turion也提醒了两个容易踩的坑：
- 如果你只写了3个典型case，就让Agent“照着葫芦画瓢”把剩下7个类似case补完，很可能说明你该做的是抽象，而不是复制粘贴——也许这本身就是一个
Traversable之类的经典类型类实例。LLM在这类场景下出了名地倾向于复制大段代码，而不是识别出可以抽象的结构，人类要为更好读、更合理的代码把关。 - 类似地，如果你依赖Agent帮你“列出所有需要改动、需要注意的坑”，某种程度上说明你的代码库本身组织得不够好，才不得不靠LLM来做这类代码考古工作。
给AI也找个“审稿人”：GAN式review cycle
turion借用了一个很形象的类比：还记得生成对抗网络（GAN）是怎么让AI生成的图像突然变得逼真起来的吗？一个模型（生成器）负责生成图片，另一个模型（判别器）负责给它打分挑毛病，两者对抗博弈，最终生成器的产出会远好于单独工作时的水平。
把这套逻辑搬到LLM辅助编程上，就是一条自动化审稿流水线：
turion给出一条相当硬的规则：任何LLM产出的东西，不经过一轮自动化审核，就不要接受，甚至不要去读它。
这不仅适用于代码本身（在那些你确实还让它生成代码的场合），也同样适用于规划文档——逐字逐句去挑一份计划里的逻辑漏洞（比如todo 2里要重构的函数，其实到todo 7才会被写出来）实在太费神，不如干脆加一个专门负责审稿的Agent来做这件事。
他还提到一个个人体验：让AI审自己写的代码，出乎意料地有用。
有时候它只是挑几个小毛病，或者非要你多写点Haddock文档注释；但也有不少次，它真的能揪出一个实实在在的bug或疏漏，让你重新聚焦在手头的todo上。他建议大家也在自己的工作里加上这道审稿工序——如果实在不想亲自看AI写的review意见，可以让它自己把那些无关紧要的问题顺手改掉。
别迷信“前沿模型”，别被token焦虑“背刺”
有人在帖子下留言：“你这是完全没把前沿模型的能力用起来”。turion的回应很干脆：没错，这恰恰是我这套方法论的必然结果。他列了几条不迷信前沿大模型的理由：
- 环境成本：前沿模型消耗的能源相当可观，只不过由于大模型公司普遍不太透明，具体数字只能靠猜。
- 信任问题：很难对一个“装作比你聪明得多”的东西建立起真正的信任。最终为代码负责的是你，不是你的机器——把锅甩给别人是糟糕管理者对下属才会干的事，甩给一台机器就更荒谬了。只有当你让自己真正参与到整个过程中，你才能对结果负起责任。
- 不确定性：越花哨的模型消耗的token越多，你没法保证一次会话能不能顺利做完任务；用小模型能搞定的事，永远是更稳妥的选择。
- 可替代性：如果你的工作流不依赖前沿模型，未来就有机会换成开放权重或开源模型，不必长期依附于某个“技术封建领主”（technofeudal lord）。
关于token耗尽这件事，turion的态度也很鲜明：不要把“token用完”理解成“自己没算计好、买少了”，而要理解成一次服务中断。厂商卖给你的是“可以使用LLM”这个承诺，一旦兑现不了，那就是他们没有履约——一个session里到底能拿到多少token，是一个不透明、可以被平台随意调整的数字，你很难提前规划。
他给出的应对之道，是把这件事类比成在没有网络的火车或飞机上工作：提前下载缓存好大文件，永远给自己留一份可以离线完成的任务清单。
落到具体做法上，就是前面反复强调的那套流程——始终保有一份规划好的todo清单，token够用时痛快地往前冲，token没了就先去做手头能离线完成的部分，等Agent恢复了，再让它回来打扫战场。
副作用预警：AI车轱辘话是“精神上的石棉”
turion在文章后半段专门谈了一个容易被忽视的问题：长期泡在LLM生成的文字里，对人的精神状态是有代价的。
他的原话大意是：LLM生成的文字和人写的完全不是一回事，尤其是当它其实并不真正理解自己在说什么的时候，读起来的观感会更差。要把LLM的车轱辘话，当成对你的精神健康有潜在危害的东西来对待，别摄入太多。
建议是多和真人聊你的代码，尤其是那些更大的愿景、更有意思的细节；只在自动审稿Agent“磨过棱角”之后，再去读AI产出的东西。
除此之外，turion也提醒不要忘了编程本质上是一项社交活动：无论是公司还是开源项目，大家靠PR、issue、commit message互相沟通；哪怕项目里只有你一个人，你的commit记录也是在跟“未来的自己”对话。
千万不要把一份完全由AI生成的PR，原封不动地甩给别人——turion坦言自己就不小心犯过这个错，对方的不满完全合情合理。Agent很乐意帮你把PR描述写得辞藻优美、细节齐全，但turion提醒大家：这不是沟通，这只是工具的输出。
他的建议是把这类文本当成跑分数据或调试日志来对待——可以附在你亲手写的PR描述后面，用<details>折叠起来，让别人自己决定要不要点开看；实际上大部分时候，他们不会点开。
作者的“体检报告”：像有机园丁，而不是化肥狂魔
按照这套工作法坚持下来，turion给自己算了一笔账：比不用LLM的时候更高产，具体快多少很难精确量化，两倍左右——这个数字远不如很多“全氛围编程”（full vibe coding）玩家吹嘘的那么夸张，但turion觉得这样挺好。
他给自己打了个比方：自己更像一个使用温和有机肥料的园丁，而那些氛围编程玩家，更像是把地里灌满工业化学品。短期看后者的产量可能更亮眼，但turion相信，自己这种方式从长期看更可持续。
文章的最后，turion写道，自己热爱写Haskell，能靠这个吃饭是梦想成真；就在过去这一个月里，他一度担心这个梦想要成为过去式了——而这篇文章记录的，正是他为了让编程这件事继续值得享受，所摸索出来的一整套方法。目前来看，它管用。
评论区的两种声音
这篇长文之外，评论区里出现的一些不同意见，同样值得放进来一起看——它们让这场讨论没有停留在“turion一个人的经验”。
不同的起点：AI让我第一次实现了过去做不到的想法
一位Haskell核心库维护者看到标题的第一反应，恰恰和turion相反：他好奇的是“如果哪天失去LLM，我还能不能继续享受编程”——因为LLM已经让他能更轻松地把想法落地，把编程里枯燥的体力活都甩给AI，只留下有趣的部分给自己。有意思的是，他读完全文后发现，自己其实早就在无意识地践行文中的不少建议了。
对于turion“token焦虑等于被平台背叛”的说法，这位开发者也提出了质疑：他自己用的是OpenAI的月付计划，额度和时限都是透明的，可以随时用/status命令查看，“背叛”这个词会不会用得太重了？他还调侃说，这让他想起伍迪·艾伦那句老段子——“这儿的饭真难吃”，“是啊，分量还特别少”——似乎在说，一边担心AI烧脑过度，一边又抱怨AI给的不够多，这两种情绪放在一起本身就有点矛盾。
turion随后澄清，自己的措辞确实带点情绪化，他真正想表达的是：当你把整套工作流建立在某个AI套餐之上，额度说变就变，工作流可能瞬间被打乱——他甚至没能查到Anthropic的Claude Code团队席位到底包含多少token，只能假设这是一个可以被厂商随意调整的数字。他提出一个更明确的“公平市场”标准：要有独立开源工具能测算token消耗量、要有明确数字且能保证一段时间（至少几个月）内不变的套餐、要有可靠的正常运行时间保证——据他所知，目前没有任何一家厂商能同时满足这三条。
一个具体场景：核心库维护到底适不适合用AI
评论区里最扎心的交锋，出现在“AI能不能干好包维护这种脏活”上。一位用户抛出一个具体问题：在类似Haskell核心库委员会issue #411这种任务上，LLM表现如何？
帖子作者turion的合作者 hasufell 给出了相当保留的回答：在“底层原语”和“奇怪API”（比如Windows、PowerShell）这类场景下，他的体验用一个词概括——不及预期。而且他也只把LLM当搜索工具来用——因为这些模型并不真正理解PowerShell，想让它正确处理进程调用之类的细节，往往需要人自己反复琢磨、大量试错；LLM还特别容易收敛到某种“大家都这么干”的通用变通方案，而不是真正最优的解法——这对于维护一个核心库来说，恰恰是最危险的倾向。
hasufell补充的另一点，也很值得程序员们警惕：LLM会悄悄消解掉你对自己判断的那种不安全感——比如当你其实隐约觉得自己没完全想清楚某个决定的全部后果时，AI给出的那种“表面自信”，反而可能带来负面后果。
关于团队分工的讨论：要不要允许“AI派”和“反AI派”共存
hasufell还提出了一个更宏观的期待：希望业界未来能走到这样一种状态——公司愿意雇用具有不同“AI使用习惯”的工程师，让他们在同一个团队里协作。这件事操作起来并不容易（比如对坚决“零AI”的人来说会比较有挑战），但他相信是有办法实现的：系统的不同部分、不同角色，或许适合不同的AI使用尺度，只是这个边界具体怎么划，需要认真做政策设计——他举了个例子，自己更倾向于让不用AI的人来做代码评审，但这同样需要配套的政策（比如干脆禁止自动生成的commit message），否则容易把这部分人“逼到职业倦怠”。
他还提到，在开源世界里，围绕LLM是否可以抓取、使用开源代码这个问题，社区已经开始出现分裂——他举了Sourcehut与Codeberg近期相继调整服务条款、限制LLM抓取的例子，并认为这种分化“挺好”。
小结：三点启示
把整条讨论串完整看下来，其实很难简单地站队“挺AI”还是“反AI”——这场讨论真正的价值，在于它把一种很多人都有过、却说不清楚的感受（“用AI写代码之后，好像没那么开心了”），拆解成了具体、可操作的工作流问题。对国内的程序员和团队来说，至少有三点值得琢磨：
- “甩手掌柜”式使用AI，代价可能比看起来更高。短期交付速度确实会提升，但代码库的可维护性、个人的手艺、甚至团队协作中的信任感，都可能在潜移默化中被消耗掉，而这些成本往往要等出问题时才会集中显现。
- AI的定位，或许更适合“记账员+调研助理+审稿人”，而不是“主笔”。把决策权和最终的“手感”留给人类，把重复性、事务性的活交给AI，可能是目前看来兼顾效率和乐趣的一种折中方案——但正如评论区所争论的，在核心库维护、复杂系统设计这类容错率极低的场景下，这套方案的边界在哪里，仍然值得每个团队自己摸索。
- “token焦虑”背后，其实是一个更严肃的议题：程序员的工作流，正在多大程度上被平台的定价和额度策略所绑架？这不只是turion一个人的困惑，而是整个行业在快速拥抱AI编程工具时，都需要正视的一个结构性问题。
这场发生在Haskell论坛里的讨论，或许不会给出一个所有人都认可的标准答案，但它至少提出了一个值得每个程序员认真回答的问题：当AI可以替你写代码的时候，你到底还想不想自己写？
参考资料：How to keep enjoying programming in a world of LLMs，Haskell Community Discourse论坛，作者turion及回帖网友，发布于2026年9月
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
