最近，我重新读了一遍过去写下的二十个 Markdown 文件。
八千多行文字里有 C、C++、8086 汇编、SICP、TAPL、Java 框架、Windows 开发、龙芯和二进制翻译，也有一个用大模型自动管理标签的工具。它们记录了我在不同阶段认真学过的东西。可重新读时，我不得不承认：其中相当一部分内容，今天只要给 LLM 一段清楚的提示词，几秒钟就能得到一份更完整、更整齐，甚至更易读的版本。
寄存器表格不再稀缺，智能指针的用法不再稀缺，一份从 J2EE 到 Spring Cloud 的时间线也不再稀缺。标题、摘要、代码示例、最佳实践和结语，都可以按 Token 批量产生。
但也有一些东西没有因此失去价值。
我仍然记得自己曾经停掉站点、减少与外界联系，在一段安静的时间里写下十万字；记得第一次读 SICP 时近乎仰望，一年后再看，才敢承认经典有力量也有边界；也记得一个内存池示例在本机正常运行，却被在线工具指出 Invalid write of size 8。这些片段不一定比教程更完整，却包含教程里没有的东西：我为什么走到这个问题面前，我当时相信什么，证据又怎样迫使我改变判断。
这让我开始重新思考，在 LLM 时代，技术写作究竟还应该保存什么。
答案曾经很贵#
过去，整理出一篇技术文章本身就是一项工作。
为了说明一个概念，需要查书、搜索文档、搭建环境、运行示例，再把零散资料组织成可以阅读的顺序。即使文章只是介绍语法或罗列工具，这个整理过程也消耗了真实的时间。能够提供一份完整而清楚的答案，往往足以证明作者做过功课。
我以前的许多文章就是按照这个标准写成的。介绍 8086，就从寄存器讲到段式内存；介绍现代 C++，就从 RAII 讲到三种智能指针；介绍 Windows 开发，就梳理 Win32、WinRT、WinUI 和工具链。它们并非毫无价值。写下这些内容，确实帮助当时的我建立了基本概念，也留下了一份学习路径。
问题在于，知识生产的条件已经变了。
LLM 把“得到一个像样答案”的边际成本压得很低。只要问题足够常见，模型通常都能给出定义、示例、比较、注意事项和进一步阅读。过去需要花一下午整理的文章，现在几次对话就能形成初稿。
这并不意味着答案已经没有价值，也不意味着模型生成的内容天然正确。真正改变的是：完整、流畅和结构化，不再足以证明理解。
流畅曾经是能力的信号，现在也可能只是算力的结果。
生成变便宜之后，什么仍然昂贵#
Token 有价格，但相对于人的时间，生成已经足够便宜。真正昂贵的部分转移到了生成之前和生成之后。
选择问题#
LLM 可以针对一个问题生成很多方案，却不能替我决定哪个问题值得占用接下来一年的注意力。
我维护数字花园时，曾把标签不统一当成重要问题。为了让每篇文章恰好拥有五个标签，我做了标签词汇库、别名映射、AI 内容分析和自动扩展机制。从系统设计的角度看，这些工作都有道理。但后来我逐渐发现，真正妨碍写作的并不是标签质量，而是我把太多时间用在了管理写作系统上。
“怎样让标签更智能”是一个可以被解决的问题。“这个问题是否值得解决”则是另一种判断。
模型擅长在目标已经给定之后寻找路径，却很容易忠实地帮人优化一个不重要的目标。问题选择因此比方案生成更稀缺。
验证答案#
我在学习内存池时写过一个链表实现。代码在本机可以编译，也可以运行，但在线可视化工具在释放内存时报告了 Invalid write of size 8。
如果只把“程序跑起来”当作验收条件，这段代码已经完成了任务。错误信息却迫使我继续追问：被转换成链表节点的内存是否满足布局和对齐要求？本机没有崩溃，究竟说明实现正确，还是未定义行为暂时没有显现？
那次经历真正教给我的，不是某一种内存池写法，而是一个更持久的原则：运行结果是证据，但不是全部证据。
LLM 可以迅速解释错误信息，也可以生成一个看起来更安全的实现。但如果我没有内存布局、对象生命周期和未定义行为这些基本模型，就很难判断它是在修复问题，还是只把问题藏到了更深的地方。
验证不是在答案后面打一个勾。验证需要知道应该观察什么、什么结果足以推翻当前假设，以及还有哪些环境没有被覆盖。这些都依赖判断。
承担结果#
最近整理 mdout 时，外链页面一直显示“尚未运行外链检查”。表面上看，这是一个缺少数据的问题。沿着代码检查后才发现，外链命令、JSON 报告和页面模板都已经存在，真正缺少的是部署工作流中的那一步：构建站点之前没有执行外链检查。
把一条命令加入工作流并不困难。困难的是确定它应该在哪里运行、是否应该让第三方网站的短暂故障阻断普通代码检查、缓存对临时 CI 环境是否真的有用，以及 GitHub 对定时工作流的分支规则会带来什么限制。
生成 YAML 很便宜。决定发布流程应该承担什么风险，并对这个决定负责，仍然很贵。
代码一旦进入真实系统，就不再只是文本。它会修改文件、占用资源、阻断部署，也可能影响别人。模型可以提供候选方案，但最终必须有人明确验收标准，并承担选择的后果。
心智模型没有因为 LLM 而贬值#
第一次读 SICP 时，我被抽象的力量震撼，几乎把它当作理解编程的终极答案。一年后，有了更多项目经验再回头看，我才逐渐把“抽象很强大”改写成一个带条件的判断：好的抽象能够管理复杂性，不合时宜的抽象也会制造复杂性。
这两次阅读之间的差异，不是我记住了更多章节，而是我终于有了可以与书中概念相互校验的经验。
这也是今天仍然值得学习 C、汇编、类型系统和经典教材的原因。目的不再是与模型比赛谁记得更多语法，而是建立一套能够解释结果的心智模型。模型可以直接给出代码，但当代码失败、性能异常、边界改变或者两个答案相互冲突时，人仍然需要知道从哪里开始怀疑。
知识的价值正在从“能否复述”转向“能否用于判断”。
我想怎样继续写#
重新阅读旧文之后，我不打算把所有文章逐篇翻新。很多百科式内容可以留在过去，因为重新扩写它们只会增加更多已经不稀缺的文字。
以后写一篇技术文章，我更希望它至少回答几个问题：
- 我遇到的真实问题是什么？
- 我最初为什么会作出那个判断？
- 哪些代码、数据或现象支持它？
- 什么证据让我改变了想法？
- 当前结论在哪些边界内成立？
LLM 可以参与查漏、整理结构、检查代码和翻译文字，但它不应该替我虚构经历，也不应该用流畅掩盖证据不足。它适合扩大表达能力，不适合替代立场的形成。
这也意味着，文章不必再假装完整。与其写一份覆盖所有概念的“终极指南”，不如把一个具体判断的形成过程写清楚。前者很容易被下一次模型生成覆盖，后者记录的是一个人如何面对不确定性。
写作不是与模型比赛#
在那段主动减少外界联系的日子里，我写下大约十万字。它们没有标题，没有预设读者，也没有发布计划。写作的意义不是向别人证明我知道多少，而是把模糊的感觉变成可以审视的句子，把混乱逐渐整理成秩序。
LLM 没有取消这种需要。恰恰因为文字可以被大量生成，我更需要分辨哪些句子只是听起来正确，哪些判断真正属于我，哪些结论经受过现实的抵抗。
Token 很便宜，不是说模型没有成本，也不是说人的表达天然高贵。它只是提醒我：生成更多内容已经不再困难，困难的是知道什么值得保留。
所以我仍然会写。
不是为了生产模型无法生产的句子，而是为了保存一个判断如何形成、如何被证据修正，以及我为什么愿意为它负责。