40年前，图灵奖得主Donald Knuth提出一个疯狂想法：代码应该像小说一样可读。
然鹅，没人买账。它成了程序员最浪漫的累赘——理论上完美，实践中折磨。
2024年，这个概念突然复活。不是因为程序员变勤快了，而是因为——AI开始替我们干脏活累活了。
两套叙事，一场噩梦
文学编程（Literate Programming）的核心听起来很美好：代码和散文应该交织在一起。不是那种敷衍的// TODO，而是真正的叙事。读者像读故事一样读代码，理解每一行背后的"为什么"。
但现实是，
你得维护两套并行系统：代码本身，还有解释代码的散文。改一行逻辑，要改两段文字。提取代码的过程叫"tangling"，像个永远理不清的毛线团。极客们只能在Emacs Org Mode里自嗨，数据科学家只能在Jupyter Notebook里孤独地美丽。
人类天生厌恶重复劳动。所以文学编程死了，死在"太麻烦"三个字上。
现在，AI成了那个不怕麻烦的实习生
情况变了。
Claude、Kimi这些AI Agent对Org Mode的语法门儿清。作者发现，现在他只需要说："给我写个测试手册。"AI直接生成Org文档——上面是解释意图的散文，下面是可执行的代码块。像Jupyter Notebook，但更智能。
最爽的是什么？同步问题消失了。
你改代码，AI自动更新旁边的注释；你改注释，AI自动调整代码。那个烦人的tangling过程，AI顺手就做了。它还会把执行结果塞回文档里，像一份自动生成的实验报告。
人类讨厌重复劳动，但AI从不抱怨。
说实话，这击中了痛点。以前文学编程的核心成本，就是得有人心甘情愿地当"代码秘书"。现在秘书来了，24小时在线，不要工资，还精通自然语言处理。
但评论区吵翻了：我们到底在为谁写注释？
一条高赞评论泼了冷水：自然语言天生歧义，代码才精确。 文档不参与执行，注定会过时。你今天让AI写的优雅注释，下周就是谎言——而且是你亲手喂给AI的谎言。
另一条评论更扎心，戳破了程序员的虚伪：
以前写文档是为了人类同事，大家都偷懒说"看代码就行"；现在为了AI能读懂，程序员突然勤快了。原来我们不是不爱写注释，只是不爱给人类写。
有人提出更现实的方案：轻量级文学编程。不用写小说，只要模块级注释+清晰的命名+文档字符串。Go语言比Python更适合AI编程，因为API表面小，约定多——而这些模型最爱写样板代码。
有意思的是，有人建议用LLM来检测注释是否过时。这很讽刺：我们用AI生成文档，再用AI检查文档是否撒谎。套娃了属于是。
当阅读比编写更重要
个人觉得，这场争论忽略了一个关键转向。
作者提到一个微妙的变化：如果工程师的主要工作从"写代码"变成"读代码"，那么一个能像小说一样阅读的代码库，就不再是奢侈，而是必需。
AI不会让我们变成更好的作家。但它可能让我们终于有动力，去维护那些我们早就该维护的文档。不是因为同事会感谢我们，而是因为——机器需要上下文，而机器不会像我们一样，对模糊的需求忍气吞声。
这或许是文学编程等了40年的时刻。不是因为我们终于理解了Knuth的审美，而是因为我们终于找到了愿意干脏活累活的搭档。
那个搭档不会疲倦，不会抱怨，也不会在代码评审时阴阳怪气地说："这段注释啥意思？"
它只是默默地，把散文和代码编织在一起。
【kimi-k2.5锐评】：当程序员终于愿意为AI写注释，却不愿为人类同事写时，暴露的不仅是懒惰，更是对人类沟通成本的绝望。
参考链接：
https://silly.business/blog/we-should-revisit-literate-programming-in-the-agent-era/