Files
2026-07-13 12:33:19 +08:00

164 lines
14 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>AI时代的编程语言:md生产,html消费</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
div.columns{display: flex; gap: min(4vw, 1.5em);}
div.column{flex: auto; overflow-x: auto;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
/* The extra [class] is a hack that increases specificity enough to
override a similar rule in reveal.js */
ul.task-list[class]{list-style: none;}
ul.task-list li input[type="checkbox"] {
font-size: inherit;
width: 0.8em;
margin: 0 0.8em 0.2em -1.6em;
vertical-align: middle;
}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="/Users/alchain/.claude/skills/huashu-md-html/templates/interactive/theme.css" />
</head>
<body>
<header id="title-block-header">
<h1 class="title">AI时代的编程语言:md生产,html消费</h1>
</header>
<nav id="TOC" role="doc-toc">
<ul>
<li><a href="#md早就是这个时代的代码了"
id="toc-md早就是这个时代的代码了">md早就是这个时代的代码了</a></li>
<li><a href="#但html在消费端确实赢了"
id="toc-但html在消费端确实赢了">但html在消费端确实赢了</a></li>
<li><a href="#真正有意思的是这两件事其实是一件事"
id="toc-真正有意思的是这两件事其实是一件事">真正有意思的是这两件事其实是一件事</a></li>
<li><a href="#我自己的活样本橙皮书"
id="toc-我自己的活样本橙皮书">我自己的活样本:橙皮书</a></li>
<li><a href="#边界" id="toc-边界">边界</a></li>
<li><a href="#命名" id="toc-命名">命名</a></li>
</ul>
</nav>
<p>前几天我在X上扔了条想法:自然语言是这个时代真正重要的编程语言,md是这个时代最好的编程文件。</p>
<p>[待补图:花叔5月7日X帖截图]</p>
<p>写这条的时候我有点自嘲。我那两个一万多star的开源项目,最重要的文件都是md。但只是因为里面还有一些python或html脚本,GitHub就把它们标成了Python项目和HTML项目。</p>
<p>我觉得GitHub的分类系统已经没跟上时代了。</p>
<p>差不多同一周,Anthropic Claude
Code团队的Thariq发了篇文章,标题挺猛:HTML是新的markdown。他说他几乎不再写markdown文件了,转而让Claude
Code给他生成HTML。</p>
<p>[待补图:Thariq文章首页截图
https://thariqs.github.io/html-effectiveness/]</p>
<p>Thariq的文章我看了,写得挺好。但看完之后我意识到一件事:他说对了一半。</p>
<p>HTML没有取代markdown。<strong>markdown跑到了另一端,登顶了。</strong></p>
<h2 id="md早就是这个时代的代码了">md早就是这个时代的代码了</h2>
<p>我去年某天写过一句话:<strong>最好的编程语言就该是自然语言。</strong></p>
<p>那时候说这话还有点理想化的味道。一年多过去,事情确实在朝这个方向走。</p>
<p>[待补图:花叔即刻动态截图 - 「最好的编程语言就该是自然语言」]</p>
<p>去年8月,OpenAI发布了一个东西叫AGENTS.md。就是一份md文件,写在项目根目录,告诉AI
agent这个项目的规则、约定、要做什么不要做什么。听起来像配置文件。</p>
<p>但它扩散得吓人。到现在被60000多个开源项目采用。Cursor、Codex、Devin、Claude
Code、Gemini CLI、GitHub Copilot都支持。</p>
<p>到去年12月,Linux Foundation成立了Agentic AI
Foundation,把AGENTS.md捐进去做开放标准。白金成员里有AWS、Anthropic、Google、Microsoft、OpenAI,基本是AI半壁江山。</p>
<p>一份md文件被Linux Foundation标准化了。这事我觉得挺有象征意义的。</p>
<p>Karpathy的影响力更直接。今年4月他把自己的llm-wiki
gist开源出来,是一个用来管理个人知识库的项目。核心架构是三层md文件:raw/存原始资料,wiki/存LLM生成的md知识,CLAUDE.md存schema和规则。</p>
<p>这个gist几天涨到5000多starCLAUDE.md那个文件本身,就一个文件,单日涨了7900个star,目前接近5万。</p>
<p><strong>一个markdown文件,5万star。</strong></p>
<p>Karpathy自己解释为什么用md:「Future-proofvendor-neutral,人和机器都能读。哪天Obsidian挂了,文件还能被任何文本编辑器打开。」</p>
<p>这个理由挺简单的,但你想想,能同时满足「人能读、AI能读、可以diff、可以版本控制、可以grep、不绑定厂商」的格式,目前确实只有md。</p>
<p>Cloudflare做过一个实测,一篇普通博客HTML格式16180个token,转成md只要3150个token。<strong>80%的token压缩</strong>。换算成实际成本,同样的预算可以处理7到17倍的请求。</p>
<p>GitHub官方博客今年发了一篇叫spec-driven
development,里面有句话我读到的时候停了一下:</p>
<p>「文档不再是描述代码,文档就是代码。自然语言被编译成更低级的语言,那些更低级的语言长得像Python或JavaScript而已。」</p>
<p>Visual Studio Magazine把md形容得更准:在agentic
AI里,markdown是「一个稳定的、可审计的控制界面,用来定义AI的行为」。</p>
<p>AI在Skill、CLAUDE.md、AGENTS.md、cursor
rules里能跑出来什么,全看你md怎么写的。</p>
<p>md不再只是一种文件格式。它是这个时代的源代码。</p>
<h2 id="但html在消费端确实赢了">但html在消费端确实赢了</h2>
<p>Thariq说他不再写md了,这个判断如果限定在「让AI生成给我看的产物」上,我同意。</p>
<p>我自己的工作流早就是这样了。</p>
<p>我做的几个项目网站,比如ppt.huasheng.ai、ds.bookai.top、ds.huasheng.ai,存放的所有内容都是html。每次让AI帮我做一个解释器、一个对比工具、一个可交互的演示,最后产出的都是html文件。</p>
<p>我把它们丢到S3、Cloudflare、自己的服务器上,扔一个链接出去就完事了。</p>
<p>如果让我把这些东西用md输出我会疯。md承载不了我要的东西。</p>
<p>Thariq说的几条理由我都同意,挑两个我感受最深的。</p>
<p>第一个是空间信息。diff、调用图、架构图、流程图这些东西天然有空间维度,md把它们压扁成一行行的字。同样一份代码diff,让AI画成左右对照的html页面,配上行内annotation和颜色区分,理解效率根本不在一个量级。</p>
<p>第二个是动态体验。我做产品原型的时候,经常需要让AI生成一个带动画的mock。比如一个按钮按下去转什么颜色、用什么easing曲线、过渡多久。这种东西你用文字描述再多都没用,得真的看一眼才能判断。</p>
<p>我之前做小猫补光灯的UI迭代,就是让AI生成html原型版本,每个按钮的反应直接跑一遍,看着选。那种感觉跟看md里写一句「这里建议加一个圆角动画」完全不一样。</p>
<p>[待补图:花叔做的某个html原型或解释器截图]</p>
<p>Anthropic今年4月推了Live
Artifacts,让HTML从静态产物升级成了「持久化、可交互、能拉实时数据的dashboard」。我看到这个功能上线的时候挺兴奋的,因为它把html消费端的能力又往前推了一截。</p>
<p>老牌AI实践者Simon
Willison最近也写了篇文章,承认自己被Thariq说服了。他说GPT-4那个年代他养成了「什么都让AI输出md」的习惯,因为8192个token的上下文不允许浪费。</p>
<p>但现在他改主意了:「我准备多试试用html格式让AI解释复杂概念了,特别是带SVG图表和交互组件的版本。」</p>
<p>这种立场翻转挺有意思的。它说明事情确实在变。</p>
<h2
id="真正有意思的是这两件事其实是一件事">真正有意思的是这两件事其实是一件事</h2>
<p>我在这里停了一下。</p>
<p>如果md在生产端越来越重要,html在消费端越来越重要,那这两件事是不是其实是同一件事?</p>
<p>我觉得是。</p>
<p><strong>这是一个分工的形成。</strong></p>
<p>以前md和html是有过论战的。10年代是HTML的时代,blog、文档、官网都用HTML写。后来md兴起,因为写起来快、看起来干净、能纯文本编辑。技术圈基本切到了md。</p>
<p>那个论战的隐含前提是:<strong>生产者和消费者是同一个人。</strong>
你写一份文档自己看,或者写给同事看。不管哪种,写的人和读的人都是人,都是同一类用户。</p>
<p>所以选格式要折中,既要好写,又要好看。md胜出,因为它的折中点最舒服。</p>
<p>AI出现之后,第一次出现了一个新情况:<strong>生产成本可以被AI吸收。</strong></p>
<p>你不再需要亲手编辑产物。HTML因为太重而被嫌弃的那部分代价,由AI承担了。你只承担消费。</p>
<p>这意味着原来要折中的需求被解耦成了两端的极端最优。</p>
<p><strong>生产端要的是轻、是快、是可diff、是token-efficient。那就是md。</strong></p>
<p><strong>消费端要的是丰富、是可视化、是可交互、是好分享。那就是html。</strong></p>
<p>两端各自登顶。中间的那个折中位置,没人需要了。</p>
<p>[待补图:md→html分工概念图 - 抽象的源代码到产物的流转可视化]</p>
<p>最干净的活体证据可能是Karpathy和Lex Fridman那对组合。</p>
<p>Karpathy的llm-wiki,内核是markdown
wiki,所有原始资料、概念页、索引都是md。据VentureBeat等媒体的报道,Lex
Fridman用了同款架构,但在外面加了一层,让AI生成动态html+JavaScript,可以排序、过滤、调参、做交互可视化。</p>
<p><strong>内核md,外壳html。</strong></p>
<p>不是Lex替换了Karpathy,是他在Karpathy的基础上加了消费层。这两层各做各的事,不冲突,互相加强。</p>
<p>我看到这个组合的时候挺兴奋。因为这就是「md生产,html消费」在现实里跑通的样子。</p>
<h2 id="我自己的活样本橙皮书">我自己的活样本:橙皮书</h2>
<p>聊到这里其实我应该坦白一件事——我已经在用这个分工干活很久了,只是直到看Thariq文章那一刻才反应过来。</p>
<p>橙皮书系列我做了7本,全部免费上架微信读书。Claude
Code从入门到精通、Claude Code源码解析、Harness Engineering、Agent
Skills、OpenClaw、Polymarket、Hermes Agent,加起来读者已经过百万。</p>
<p>[待补图:橙皮书系列封面合集]</p>
<p>经常有人问我同一个问题:你的橙皮书排版怎么这么好看?比一般的电子书强太多了。</p>
<p>我以前回答得比较随意,说就是用了点设计技巧。现在回头看,真正的答案是这个分工。</p>
<p>写每一本橙皮书的时候,我让AI产出的从来都是md。一章一章的md文件,简单的标题层级,行内代码块,普通的无序列表。我review的时候改的也是md,加一句话、删一段话、调一下逻辑。</p>
<p>到了构建环节,我有一个build脚本。md转成html章节片段,html再编译成epub和pdf。</p>
<p>所有的字体选择、颜色搭配、版面设计、章节装饰、代码高亮,全在html到epub/pdf这一层做。</p>
<p>[待补图:橙皮书构建流程图:md源 → html fragments → epub/pdf]</p>
<p>这意味着我review内容的时候面对的是md,没有视觉干扰,能专心看文字。AI再生成内容的时候面对的也是md,token
efficient,能塞下整本书的上下文。</p>
<p>但读者拿到的是漂亮的epub或pdf,HTML的所有表达力都用上了。</p>
<p>这个分工不是我刻意设计的。一开始我也试过让AI直接产html,发现两个问题。</p>
<p>一是改起来烦,一个段落里塞着各种tag,肉眼分辨不出哪是内容哪是格式。二是上下文炸,一个章节就要几千token,AI没办法一次看完整本书的脉络。</p>
<p>后来切换成md转html再转pdf,问题都消失了。回头看,这就是「生产端用md、消费端用html」自然演化出来的结果。</p>
<p>公众号文章我也是这么走的。写作用md,过editor.huasheng.ai排版变成微信富文本,最后发到公众号。我review的永远是md源文件,读者看到的是排好版的内容。</p>
<p>我做的md-to-pdf
skill、整套写作系统、整个橙皮书工作流,本质上都是这一个分工的物化。</p>
<p>只是我一直不知道这个分工值得被命名。</p>
<h2 id="边界">边界</h2>
<p>需要补一句:这个分工不是万能的。</p>
<p>不是所有内容都需要html消费。文章本身就是文字消费——你现在读的这篇就是。md够了,转成微信图文也够了。再丰富的html对一篇散文式文章没什么帮助。</p>
<p>短消息、推特、即时沟通、纯文字阅读,html都过重。</p>
<p>适合html消费的是「复杂结构信息」:研究报告、技术解释、设计文档、可交互原型、数据dashboard、需要折叠和导航的长文档、需要试参数的playground。这些场景md承载不动。</p>
<p>适合md消费的还是「线性文字阅读」:essay、文章、书籍正文、新闻报道。这些场景html是过度设计。</p>
<p>判断哪边的方法挺简单的:你需要的是看一段连续的字,还是看一个有空间结构的东西?</p>
<h2 id="命名">命名</h2>
<p>调研的时候我让agent去搜了一遍,2024年之前没有人清晰地说过「md生产,html消费」这件事。</p>
<p>倒是有人说过markdown好,有人说过HTML的优点,有人争过两者的取舍。但<strong>把它们当作一对分工的论述,目前没看到。</strong></p>
<p>那就叫这个名字吧。</p>
<p>md生产,html消费。</p>
<p>这个分工不是我们造出来的,是AI让它显形的。</p>
<p>以前你又是写者又是读者,所以你需要一个折中的格式。</p>
<p>现在你不写产物了,你只读它。AI替你写。</p>
<p>写者和读者第一次是两个人。一个是AI,一个是你。</p>
<p>两个人,自然要用不同的语言。</p>
</body>
</html>