最近，我不得不承认自己被打脸了。
今年 5 月，Anthropic 的 Thariq 写了一篇关于 HTML 的文章。他说，随着 Agent 生成的内容越来越长、越来越复杂，他已经很难认真读完超过一百行的 Markdown。现在很多规格探索、代码解释、设计方案和 Review，他更愿意让 Claude 生成 HTML。
我当时的第一反应是：多此一举。
Markdown 已经足够清楚，也足够轻。标题、列表、表格、代码块，该表达的东西都能表达；它可以直接进入 Git，Diff 也干净。HTML 无非是多了一些颜色、布局和交互，却更耗 Token、更难维护。只要内容本身写清楚，换一种格式又能解决什么？
几个月后，我发现自己可能完全看错了问题。
HTML 要解决的不是 Markdown 能不能把内容写出来，而是当 AI 写得越来越多、细节越来越密以后，人还有没有能力分辨重点、核验细节并真正完成审核。
HTML 能让失控重新变得可见，却不能替项目消除已经积累的复杂度。
Markdown 还在，我却已经审不动那些细节
我最近回头看一个由 AI 持续驱动开发的项目。它已经迭代了接近一年。
最开始，很多需求几句话就能说清楚。项目还小，我知道代码大致怎样组织，也知道一次修改可能影响哪里。即使 AI 的方案有问题，我也能比较快地发现。
后来，规格书开始越来越长。
一个看起来并不大的功能，需要先解释旧实现、现有模块、已经废弃但还没有完全清掉的路径、不能破坏的行为，以及过去几轮修改留下来的各种例外。AI 会继续补充边界条件、兼容方案、测试计划和可能受影响的区域。每一项单独看都有道理，合起来却变成一份越来越难读完的 Markdown。
但长度还只是最表面的问题。
更难处理的是，规格里充斥着大量细节：准备修改哪些文件，接口增加什么字段，状态怎样流转，异常走哪条分支，旧数据如何兼容，测试要覆盖哪些组合。它们未必是废话，很多甚至确实会影响实现；问题是这些内容经常被平铺在同一层，关键决策、实现推演和低层检查项混在一起，看起来都同样重要。
人并不擅长这样审核细节。
审核一个字段、一个边界条件并不难。困难的是同时面对几十上百个细节，还要把它们放回整个项目里判断：这个状态是不是已经在别处定义过？这条异常路径会不会和前面的规则冲突？这个兼容分支是否还对应真实存在的旧实现？一个段落读懂了，不等于我有能力验证它和另外十个段落之间的关系。
AI 恰恰很擅长迅速生成这种“很完整”的细节。它写得越具体，规格看起来越严谨；可每增加一个具体判断，也等于多产生一项需要人核验的责任。细节从几十项增长到几百项以后，问题就不再是我愿不愿意认真，而是人的注意力和工作记忆根本不适合做这种穷举式一致性检查。
更麻烦的是，对齐也开始变长。
我需要反复告诉 AI 哪部分理解错了、哪些地方不应该动、哪些旧代码其实已经被替代。它根据新的说明修订规格，又会牵出更多需要确认的东西。过去是我提出需求，AI 帮我实现；后来越来越像是我先陪 AI 重新考古整个项目，才能讨论一个局部修改。
Markdown 文件仍然生成得很完整。标题、背景、目标、方案、风险、验收标准，什么都不少。可我逐渐发现，自己不但开始跳读，就算逐段读完，也很难确认那些细节到底对不对。
我开始跳过熟悉的部分，只看摘要；开始让另一个 AI 帮我总结第一个 AI 写出的规格；有时扫过几个标题，觉得大方向差不多，就让它继续执行。
从流程上看，我仍然完成了 Review。
但如果我只是读过文字，没有能力考究里面每个判断及其相互关系，那就谈不上审核。我只是在一个名叫 Review 的节点上点了通过。
这才是让我不安的地方：不是 AI 没有生成规格，而是规格越完整，我反而越可能把更多决定静默地交给 AI。
规格书越来越长，是项目在通过文字求救
一开始，我把问题归因于模型喜欢啰嗦，或者上下文太多，抓不住重点。
这些当然是原因，但不是全部。
规格书之所以越来越长，很大程度上是因为项目本身也在变得越来越难解释。AI 每完成一次局部任务，都会给系统带来新的代码、抽象、兼容逻辑和文档。它很擅长在当前上下文里找到一个能把任务做完的局部最优方案，却不会天然站在项目全局，为一年后的架构和治理负责。
这也是强模型一个有点反直觉的副作用。模型越能触及复杂问题，越容易替我“想得太多”：本来只需要局部修补的小问题，被推演成更通用、更完整的设计，最后多出抽象、兼容和改动面。能力提高当然让它能解决更多问题，也可能让过度复杂化和过度工程化发生得更快。
一个小问题被修掉了，系统里可能多出一层判断；一个功能被替代了，旧路径却没有完全消失；一次为了完整性增加的抽象，后来并没有真正复用。它们不会立刻让项目崩溃，只会让下一次修改多解释一点、多确认一点、多保护一点。
复杂度就是这样一点点长出来的。
系统越来越复杂
→ 每次修改需要解释更多背景
→ AI 生成更长、更细的规格与方案
→ 大量细节淹没关键决策
→ 人既难读完，也难逐项核验
→ 更多未经充分理解的决定进入代码
→ 系统变得更难理解这不是一次明显的事故，而是一种缓慢的失控。每个局部决定都可以自圆其说，甚至都有测试和文档；但整个项目逐渐超过了人能够掌握的范围。
所以，规格书膨胀可能不代表我们越来越严谨。它也可能是在补偿代码和架构已经无法清楚表达的东西。
当一个小改动必须重新讲述大半个系统，真正发出求救信号的并不是 Markdown。
我终于理解了 HTML 的意义
也是在这个时候，我重新读懂了 Thariq 的判断。
我以前是在比较两种文件格式：Markdown 更轻、更容易维护，HTML 更丰富、更好看。沿着这个方向比较，Markdown 当然已经足够好。
但 Agent 改变了分工。
过去，人是文件的主要作者，也是主要编辑者。格式应该优先服务于写作：语法简单、键盘输入方便、版本差异清楚。
现在，越来越多内容由 Agent 生成，也由 Agent 修改。人真正稀缺的动作变成了理解、选择、质疑和反馈。此时，最重要的已经不是文件多容易写，而是关键决策能否从细节中浮现，真正需要人判断的地方能否被快速看懂。
HTML 可以把背景、关键决策和实现细节分层，把方案并排比较，把暂时不需要逐项考究的内容折叠起来；可以用颜色、图形和空间关系暴露模块、风险与依赖；也可以让人直接筛选、排序、调节参数，最后把选择导出成 Prompt、JSON 或 Diff，再交还给 Agent。
这并不代表细节可以消失，而是人不应该被迫在第一次 Review 时平等地处理所有细节。哪些是需要人拍板的取舍，哪些是必须理解的影响，哪些可以交给测试、静态检查和 Agent 交叉验证，应该拥有不同的视觉层级和审核路径。
沿着这个方向再走一步，人需要的可能不只是更好的展示，也包括更少的审核对象。与其每次重新阅读一份不断膨胀的完整规格，不如优先审核这一次究竟改变了什么、为什么改变、影响哪里，以及哪些决定需要重新确认。HTML 可以帮助呈现这些差异，但更重要的原则是减少人必须同时处理的信息量。
它不只是把文档变漂亮，而是试图把一份线性说明变成人能够操作的认知界面。
这也是我真正被打脸的地方。
我以为 HTML 在增加不必要的生成成本。Thariq 关心的却是另一种更昂贵的成本：当 Agent 已经可以轻易生成几千行内容和几百项细节时，人为了找到真正需要判断的部分，还要支付多少注意力？
机器多花一点 Token，和人彻底放弃阅读相比，可能根本不是同一个量级的问题。
HTML 既是补救，也是警报
不过，我现在也不认为把 Markdown 换成 HTML，项目就重新可控了。
HTML 可以提高信息密度，也可以制造视觉噪音；可以突出风险，也可以让一套错误方案显得更加专业可信。如果底层事实已经过期，模块边界已经混乱，或者 Agent 对项目的理解本身就是错的，更精致的页面只会把误解包装得更容易接受。
它解决的是表达和审核带宽，没有消除需要审核的复杂度。
如果一个小改动已经需要生成一套精心设计的 HTML，才能让我理解 AI 准备做什么，这个 HTML 在帮助我的同时，也在提醒我：系统可能已经不再清晰。
所以我更愿意把 HTML 看成双重信号。
一方面，它是补救。既然人已经不可能逐行掌握 AI 生成的一切，就需要让关键结构、差异、风险和选择以更适合人脑的方式上浮。代码可以下沉，人的理解界面必须跟着升级。
另一方面，它也是警报。我们不能因为终于能看完一份漂亮的 HTML，就忘了追问：为什么这次修改需要解释这么多？为什么旧路径还没有删除？为什么模块之间的边界需要靠自然语言反复提醒？
真正的目标不能只是把越来越多的复杂度展示得更清楚，还要阻止复杂度无止境地增长。
至于怎么治理，我还没有成熟答案
看到这个警报之后，自然会问：那应该怎么治理？
我还没有一套经过长期实践验证的方法。下面这些更像是我目前想到的方向，而不是可以直接照搬的复杂度治理手册。
我的第一个直觉，是很多答案可能仍然要回到传统的软件工程。Agent 改变了代码的生产方式，却没有让架构、分层、模块边界和依赖方向失效。恰恰因为 Agent 更擅长快速完成局部任务，我们更需要这些东西替项目守住全局。
其中最重要的也许不是保证每一个局部永远整洁，而是控制失控的范围。系统如果拥有清晰的分层和模块边界，即使某一块被改得越来越复杂，也不应该轻易干扰其他模块，更不能让一次局部失控扩散成整个项目的失控。架构在这里承担的不是消灭所有复杂度，而是限制复杂度传播的爆炸半径。
另一个方向，是把复杂度当成一种需要提前约束的预算。一个小 Bug 默认只允许局部修改，不应该顺手增加新的抽象；一个功能如果准备跨越太多模块、改动太多文件，就先停下来重新看架构。这里未必需要一套精确数字，重要的是让范围扩大不再悄悄发生，而是变成一个需要额外解释和重新决策的信号。
还有一些工作看起来不像开发，却可能越来越重要：删除已经废弃的路径，合并没有产生价值的抽象，清理过期说明，让代码和文档重新表达当前真实的系统。否则，这些历史残留不只会增加人的理解成本，也会继续进入 Agent 的上下文，成为下一轮误解和复杂化的材料。
这些方向能不能形成稳定有效的治理方式，我现在还不能确定。但至少我越来越相信，HTML 只能帮我看清已经产生的复杂度。要阻止复杂度继续扩散，最终仍然要靠边界、删减，以及对“不必要的完整”说不。
生成已经不稀缺，理解才是
我以前总觉得，只要模型继续变强、上下文继续变长，很多对齐问题自然会消失。
现在我越来越怀疑这件事。
更长的上下文可以装下更多代码和文档，但如果其中包含过期说明、重复抽象和互相冲突的历史决定，它也只是让 AI 同时读到更多东西。更强的模型能够理解更复杂的系统，也意味着它更有能力设计更完整的方案、修改更多模块，并把每一种“以后也许需要”的可能性实现出来。
AI 的生产能力越强，项目越需要另一种能力与它对抗：压缩、删减、划边界、拒绝不必要的完整，以及让人能在关键决策发生前真正看懂。
我现在不再纠结 HTML 是否比 Markdown 更高级。Markdown 仍然适合保存可 Diff、可维护的文字和事实；HTML 则可能更适合把某一次复杂的计划、变更和取舍投影成人能够审核的界面。它们解决的是不同问题。
真正改变的是我的判断标准。
以前我会问：这份 Markdown 有没有把事情写清楚？
现在我会先问：在 AI 继续执行之前，我真的理解自己正在批准什么吗？
如果答案是否定的，那么格式正确、流程完整、模型能力再强，都不能说明项目仍在我的控制之中。
我被 HTML 打脸，并不是因为低估了网页能做多少样式。
而是因为我低估了，当 AI 的生产速度持续超过人的理解速度以后，我们会多快失去对自己项目的掌握。