AI写作如何应对非技术主题？从需求明确到素材准备
2026/9/1 4:28:44
如果你每天都要跟 Claude、GPT 这类大模型打交道，大概率已经习惯了写 Markdown。写提示词、整理知识库、维护 README，几乎默认选 Markdown。轻量、易读、版本控制友好，这些优点让 Markdown 看起来是“AI 时代必备技能”。但最近一个关于 Anthropic 工程师工作方式讨论，正在把这些默认值撬开一角：他们与 AI 协作时，开始弃用 Markdown，改用 HTML。
很多人第一反应是：这不是倒退吗？HTML 那么冗长，到处是尖括号，写起来不仅啰嗦，阅读体验也远不如 Markdown 清爽。这恰恰是问题的切入点。当文档唯一的读者是人类时，Markdown 的简洁是极大的优点；但当文档还要同时被 AI 模型解析、切分、检索、提炼时，沟通效率的天平会悄然变化。
这篇文章会从工程视角拆解这个选择背后的逻辑，讲清楚三件事：第一，Markdown 在复杂 AI 工作流里到底卡在哪里；第二，HTML 为什么在某些场景下比 Markdown 更适合当 AI 的输入格式；第三，如果你想在项目里尝试这个思路，该怎么做、有哪些坑。读完你会得到一个判断工具，而不是一个“非黑即白”的结论。
1. 这篇文章真正要解决的问题
先说一个让你有代入感的场景。你负责的公司知识库用的是 Markdown，里面有产品说明、接口文档、运营规范，总量几百篇。你把这些文档喂给 RAG 应用，希望能得到一个内部问答机器人。结果上线后你发现，机器人经常答非所问，尤其是涉及表格、嵌套列表、多级标题的时候。
再举一个场景。你在开发一个 Agent，让大模型根据一份需求文档生成测试用例。为了追求准确，你在 System Prompt 里把整份 Markdown 文档原样塞进去。模型确实读到了内容，但生成的测试用例漏掉了表格中最后三行数据，而且对字段约束的理解完全错误。你反复调整提示词，效果依然不稳定。
这些问题的根源往往不是模型不够聪明，而是你交给模型的文档格式，在结构表达上先天不足。Markdown 擅长表达“这是一段文字，那是一个标题”，但不擅长表达“这两列数据有对应关系”“这五个节点属于同一个分组”“这块内容只能选择枚举值之一”。当上下文复杂度上升时，模型需要从文本里“猜测”结构，猜错就是信息丢失。
这正是 Anthropic 工程师改选 HTML 的核心原因：在 AI 工作流里，文档格式不再只是个人偏好，而是一个工程变量。格式选择直接影响模型的解析准确率、提示词稳定性和下游任务表现。本文要解决的就是这个问题——帮你判断什么时候该放弃 Markdown 转而使用 HTML，以及怎么转型。
2. Markdown 的贡献与“足够好”陷阱
Markdown 本身是一项非常成功的发明。它用极简的语法解决了纯文本排版问题，让写作者专注于内容而不是格式。正因为轻量，它迅速成为开源社区、技术博客、产品文档的事实标准。GitHub 的 README、Vue 的文档站、Python 的官方教程，你几乎找不到一个技术项目完全不用 Markdown。
但 Markdown 有一个隐含的定位：它最初是设计给人类快速写作用的，而不是设计给机器精确解析用的。这个定位在“简单文档”里毫无问题，一旦文档复杂度上升，就开始出现裂缝。
第一个裂缝是表格。Markdown 的表格语法来自 GFM（GitHub Flavored Markdown），它只能表达最简单的二维表格：有表头、有行、有列，但不能合并单元格，不能让一个单元格跨两行，也不能精确控制对齐。如果单元格内容里恰好有竖线|，你就必须转义，否则表格结构直接破坏。
看一个实际例子：
| 字段 | 类型 | 说明 | | ---------- | ------ | ------------------------------ | | user_id | string | 用户唯一标识 | | 操作 | log | 记录用户点击，格式 `a\|b\|c` |当内容里出现|时，你不得不写\|。这还能忍。真正难受的是：如果你想把“操作日志”这几个字合并到两列，Markdown 根本没有语法支持。你只能拆成两个单元格，然后让 AI 自己去猜它们的视觉关系。
第二个裂缝是方言分裂。CommonMark、GFM、GitLab Flavored Markdown、Pandoc 扩展，不同平台对 Markdown 的解析规则并不完全一致。同一篇文档，在 GitHub 上渲染是对的，换一个渲染器可能就错位。这对人类阅读影响不大，但对 AI 解析来说，任何一个解析差异都可能导致结构判断错误。
第三个裂缝是结构表达力不足。Markdown 只有标题、列表、表格、引用、代码块这几类有限语法。它表达不了“这个列表项属于那个分组的子项”这种语义，也无法描述 UI 原型、数据模型、接口字段之间的复杂关系。当你要给 AI 提供完整上下文时，这些丢失的结构信息很重要。
这引出一个关键判断：Markdown 的“足够好”只适用于文档结构简单的场景。一旦文档进入“复杂结构”区间，它的简洁就变成了负担。你省下的语法成本，会在模型解析、上下文检索、下游任务错误中加倍偿还。
3. HTML 为什么更适合作为 AI 的上下文格式
要理解 Anthropic 工程师为什么转向 HTML，必须先理解 AI 读取文档的方式。大模型本质上是一个模式识别器，它的训练语料覆盖了大量互联网 HTML 内容。对模型而言，HTML 的标签本身就是语义信号：<table>表示表格，<tr>表示行，<td>表示单元格，<ul>表示无序列表。模型不需要推测，它直接能“看到”结构。
HTML 的标签即语义特性，解决了 Markdown 最棘手的问题。比如前面那个 Markdown 表格表达不了的合并单元格，HTML 可以非常自然地写出来：
<table> <thead> <tr> <th>字段</th> <th>类型</th> <th>说明</th> </tr> </thead> <tbody> <tr> <td>user_id</td> <td>string</td> <td>用户唯一标识</td> </tr> <tr> <td colspan="2">操作日志（合并单元格）</td> <td>记录用户点击行为，格式如 a|b|c</td> </tr> </tbody> </table>这段 HTML 里，colspan="2"明确告诉模型“这个单元格占两列”，不需要任何视觉推理。Markdown 做不到这一点。
再往下看，HTML 的 DOM 结构天然是一棵层级树。<html>包含<body>，<body>包含<main>和<section>，<section>又包含<h2>和<table>。这个层级关系对模型来说，就是文档的骨架。RAG 系统在切分文档时，可以顺着<section>边界切块，而不是把纯文本从中间硬切，导致语义被拦腰截断。
还有一个容易被忽略的点：HTML 的渲染是可靠的。你写一个<table>，只要语法正确，任何浏览器渲染结果都一致。但 Markdown 在不同平台上的渲染可能不同。对追求稳定性的 AI 工作流来说，渲染差异是一种看不见的噪音。
当然，HTML 不是没有缺点。它冗长、可读性差、不适合快速记录。写一篇短笔记，Markdown 十秒钟搞定，HTML 可能要先写骨架、加闭合标签。所以它的优势集中在“机器解析”这个维度上，而不是“人类速记”这个维度。
我的判断是：HTML 和 Markdown 不是替代关系，而是适用场景不同。Markdown 是人与人的沟通格式，HTML 是人与模型、模型与模型之间的结构化上下文格式。Anthropic 工程师的调整，本质上是在文档的上游和下游都增加了“机器读者”之后，主动换了一种更利于机器理解的表达语言。
4. Anthropic 工程师改选 HTML 的场景拆解
既然确定了“HTML 更适合做 AI 上下文”，那 Anthropic 工程师具体在哪些场景里使用它呢？从工程逻辑上推测，有三类场景收益最明显。
第一类是复杂规格文档。产品需求、API 规范、协议定义这类文档，天然包含大量表格、字段映射、枚举值、嵌套结构。过去用 Markdown 写，也能看，但模型阅读时经常丢失字段之间的对应关系。改用 HTML 后，字段定义用<dl>描述，枚举值用<ul>列举，表格用<table>呈现，模型对“哪个字段对应哪个类型、有哪些可选值”的理解准确率会显著提高。
第二类是给 AI 的长上下文输入。在 Claude 这类大模型的使用场景中，上下文窗口虽然越来越大，但塞满有噪音的文本仍然会稀释模型注意力。只要你把一个结构清晰的 HTML 文档包裹在明确的标签里，模型往往能更快定位关键信息。
例如，你可以这样写提示词：
请阅读以下 HTML 格式的需求文档，完成三个任务： 1. 概括产品必须实现的四个核心模块 2. 找出表格中优先级为 P0 的需求数量 3. 提出两个我可能遗漏的边界情况 <doc> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>结算中心改版需求</title> </head> <body> <main> <section> <h2>需求概述</h2> <p>用户希望在结算页查看每笔订单的明细，并支持导出账单。</p> </section> <section> <h2>核心模块</h2> <ul> <li>订单列表</li> <li>账单导出</li> <li>金额汇总</li> <li>优惠明细</li> </ul> </section> <section> <h2>优先级表格</h2> <table> <thead> <tr> <th>模块</th> <th>优先级</th> <th>说明</th> </tr> </thead> <tbody> <tr> <td>订单列表</td> <td>P0</td> <td>影响核心交易流程</td> </tr> <tr> <td>账单导出</td> <td>P1</td> <td>方便用户留存凭证</td> </tr> </tbody> </table> </section> </main> </body> </html> </doc>这段提示词没有使用任何特殊技巧，只是把文档换成了 HTML。但模型在解析时，能明确知道<table>就是表格，每一行是一组数据，而不是从 Markdown 的竖线堆里推断结构。
第三类是 UI 原型与前端协作。HTML 可以直接在浏览器里渲染，团队评审时不需要安装额外插件。模型也能根据标签和 CSS 类名理解布局意图，比如<nav>是导航区，<button>是交互控件。当 AI 需要生成前端代码时，给它一个 HTML 原型作为输入，它的输出质量往往比给一张截图或一段 Markdown 描述更稳定。
需要强调的是，这不是说 Anthropic 工程师所有文档都改用 HTML。更可能的情况是：他们对“机器消费者”占比高的文档，主动升级了格式。闲聊、便签、快速记录这类内容，没有人会用 HTML 自讨苦吃。这个判断也符合工程常识：格式选择跟着消费端走。
5. 格式选型：什么时候该用 HTML，什么时候继续用 Markdown
对多数开发者来说，最关心的问题是：我的项目要不要跟着换？
答案不是一刀切。你需要先判断文档的“读者结构”。我用四个问题帮自己做判断：
- 文档是给人快速阅读的，还是给 AI 解析后做下游任务的？
- 文档中表格、嵌套、枚举、层级关系多不多？
- 文档会不会被 RAG 系统切块，切块后结构是否还能保持？
- 团队是否依赖 Markdown 的轻量协作流程？
如果四个问题的答案都偏向“结构复杂、机器消费为主”，那 HTML 就值得尝试。反之，如果文档只是给人看，或者结构非常简单，Markdown 依然是最优解。
用一个表格对比更直观：
| 判断维度 | 建议用 Markdown | 建议用 HTML |
|---|---|---|
| 文档读者 | 人类为主 | AI 模型、RAG、Agent 消费为主 |
| 结构复杂度 | 标题 + 段落 + 简单列表 | 表格、嵌套、合并单元格、多级关系 |
| 表格要求 | 简单二维表 | 需要合并单元格、复杂对齐 |
| 渲染环境 | 版本库、聊天框、博客 | 浏览器、前端页面、上下文工具 |
| 协作方式 | 多人快速编辑、diff 友好 | 需要语义结构稳定、自动化处理 |
| 典型示例 | README、代码注释、会议纪要 | 需求文档、API 规范、数据模型、UI 原型 |
在真实项目里，我比较推荐“混合使用”而不是“全面替换”：日常草稿、代码注释、讨论记录继续用 Markdown，因为它们是人类写作的起点；但一旦文档进入正式流转，比如要进入知识库、要作为 AI 上下文、要接入 Agent 任务，就把它们转成 HTML 后再消费。
有一个落地思路很实用：在仓库里维护 Markdown 源文件，构建时自动转换成 HTML。这样既保留了 Markdown 的书写效率，又让最终消费方拿到的是结构化 HTML。下面我会给一个最小示例。
6. 从 Markdown 迁移到 HTML 的最小落地示例
如果你决定尝试，不要手动把所有 Markdown 重写成 HTML，那太耗时也没必要。更聪明的做法是建立一条自动转换流水线。
6.1 用 Pandoc 快速转换单个文件
Pandoc 是目前最通用的文档格式转换工具，支持 Markdown 转 HTML，对表格、代码块、链接等语法的兼容性很好。
pandoc docs/checkout.md -s -o docs/checkout.html如果系统还没有安装，Debian/Ubuntu 可以这样安装：
sudo apt-get update sudo apt-get install -y pandoc转换出来的 HTML 是完整的独立页面，可以直接在浏览器打开，也可以作为后续提示词的输入。参数-s表示生成 standalone 文档，会带<html>、<head>、<body>骨架。
6.2 用 Python 脚本批量转换整个知识库
当你有几十甚至上百篇 Markdown 文档时，建议写一个批量脚本。这里使用 Python 的markdown库，它支持tables、fenced_code、toc等常用扩展。
# 文件：convert_md_to_html.py import pathlib import markdown src_dir = pathlib.Path("docs/markdown") dist_dir = pathlib.Path("docs/html") dist_dir.mkdir(exist_ok=True) for md_file in src_dir.glob("*.md"): text = md_file.read_text(encoding="utf-8") body = markdown.markdown( text, extensions=["tables", "fenced_code", "toc"], ) html_doc = f"""<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>{md_file.stem}</title> </head> <body> {body} </body> </html>""" out_file = dist_dir.joinpath(md_file.stem + ".html") out_file.write_text(html_doc, encoding="utf-8") print(f"已生成: {md_file.name} -> {out_file.name}")运行前先安装依赖：
pip install markdown然后执行：
python convert_md_to_html.py脚本会把docs/markdown下所有.md文件转换成docs/html下的.html文件。核心逻辑就是把 Markdown 文本交给markdown.markdown()处理，再用统一的 HTML 模板包裹起来。
6.3 为 AI 工作流设计标准 HTML 模板
如果你要频繁把文档喂给 AI，建议提前设计一套标准模板，让团队所有文档都使用统一的语义结构。下面是一个适合作为“需求文档 + AI 上下文”的模板骨架：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>文档标题</title> </head> <body> <main> <section aria-labelledby="overview"> <h1 id="overview">需求概述</h1> <p>用两到三句话描述文档要解决的问题。</p> </section> <section aria-labelledby="fields"> <h2 id="fields">核心字段定义</h2> <table> <thead> <tr> <th>字段名</th> <th>类型</th> <th>必填</th> <th>说明</th> </tr> </thead> <tbody> <tr> <td>order_id</td> <td>string</td> <td>是</td> <td>订单号，全局唯一</td> </tr> <tr> <td>amount</td> <td>number</td> <td>是</td> <td>订单金额，单位分</td> </tr> </tbody> </table> </section> <section aria-labelledby="rules"> <h2 id="rules">业务规则</h2> <ul> <li>金额必须大于 0</li> <li>订单状态为已支付时才允许退款</li> <li>每次退款必须记录操作人</li> </ul> </section> </main> </body> </html>这个模板的优点是语义化标签加上aria-labelledby关联标题，让模型在解析时能理解每个<section>对应哪个标题。实际使用时，你可以先跑通最小流程，再逐步扩展模板。
7. 常见问题与排查思路
切换到 HTML 的过程中，你大概率会遇到一些问题。下面是我整理的高频问题和排查路径：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| HTML 反而让 AI 回复变得冗长 | 提示词没有限制输出格式 | 检查提示词是否要求“只输出结论” | 在提示词里明确约束输出格式，如“只输出 Markdown 列表” |
| 转换后的 HTML 样式丢失 | 没有引入 CSS | 打开文件检查是否有<style>标签 | 是专注语义结构还是视觉样式；AI 消费场景只需要语义结构 |
| 大段 HTML 消耗过多 Token | 文档过大、一次性塞入上下文 | 查看上下文窗口占用情况 | 按<section>切分，分段喂给模型 |
| 浏览器打开出现乱码 | 文件编码不是 UTF-8 | 检查源文件编码 | 统一 UTF-8，并在<head>中声明charset |
| AI 生成的 HTML 里出现脚本 | 模型被诱导输出不安全的代码 | 检查所有<script>内容 | 渲染前清洗脚本，不要直接 innerHTML 注入 |
| Git diff 可读性差 | HTML 文件被压缩成单行 | 查看格式化工具是否生效 | 使用 Prettier 等工具格式化后再提交 |
| 表格转换后结构错乱 | 源 Markdown 表格本身不规范 | 检查是否有多余竖线或缺失对齐 | 先修正 Markdown 表格语法，再转换 |
其中最容易踩的是“Token 消耗”和“安全风险”。HTML 有大量闭合标签，同样的内容比 Markdown 占用更多 token。这在短文档里无所谓，但几千词的规格文档会明显增加成本。解决办法不是放弃 HTML，而是给文档分块、按需投喂，不要让模型每次读整篇。
安全风险主要出现在渲染环节。当 AI 生成 HTML 片段，或者你从不可信来源拿到 HTML 时，里面可能包含<script>或事件属性。如果这些内容被直接插入页面，可能引发跨站脚本攻击。无论这个 HTML 是 AI 生成还是人工写的，渲染前都要做过滤和转义。
8. 最佳实践与工程建议
从 Markdown 切换到 HTML，不是一个“换扩展名”的简单操作，它涉及文档生产、存储、消费三个环节的调整。以下几个建议可以帮助你平稳落地。
8.1 先小范围试点，不要全面迁移
选一个“高频使用 + 结构复杂”的文档类型，比如接口规范或测试用例模板，先转换后观察 AI 输出的变化。跑通后再逐步扩大到知识库、Agent 上下文。如果一开始就把所有文档转成 HTML，团队协作习惯会被打乱，还会增加不必要的负担。
8.2 模板先行，统一文档骨架
团队里使用统一的 HTML 模板，会让后续自动化处理轻松很多。模板里固定<header>、<main>、<section>的位置，所有文档都遵守“标题 + 段落 + 表格 + 列表”的组合规则。这样无论是人眼阅读还是模型解析，都能快速定位信息。
8.3 保留 Markdown 源文件，构建时转换
这是我最推荐的一种工作流。开发者在本地用 Markdown 写草稿，提交到仓库；CI 构建阶段用 Pandoc 或 Python 脚本自动转换成 HTML；下游的 RAG、Agent、知识库只消费 HTML 结果。这个方案兼顾了写作效率和机器可读性。
8.4 建立安全渲染边界
凡是渲染 HTML 的地方，都要明确一个原则：默认不安全。对 AI 生成的 HTML，用专业的 HTML 清理库做清洗，移除<script>、<iframe>、on*事件属性，再插入页面。如果只是给模型当文本上下文，不涉及渲染，那安全性风险会低很多。
8.5 对上下文做分块管理
HTML 适合结构化，但不等于“越大越好”。上下文窗口有上限，模型注意力也有限。一个折中方案：把文档按<section>切块，给每个块加一个id，提示词里只引用当前任务需要的块。这样既保留了 HTML 的结构优势，又不会让无关内容稀释模型的注意力。
8.6 把格式选择写进团队规范
如果你的团队正在开发 Agent 或知识库产品，建议把“格式选型”写进工程规范。规定哪些文档必须用 HTML，哪些可以用 Markdown，以及转换工具链是什么。格式选型不是个人偏好，而是产品质量的一部分。
9. 总结与后续学习方向
回到最初的问题：Anthropic 工程师为什么放弃 Markdown 改用 HTML 跟 AI 工作？
不是 Markdown 错了，而是场景变了。Markdown 依然是人类写作效率最高的格式之一，它的轻量和易读性无可替代。但当文档要交给 AI 解析、切分、检索时，HTML 的标签即语义和天然层级结构，让机器理解更稳定、更精确。这种选择背后是文档消费端的变化，也是 AI 工作流走向工程化的必然结果。
如果你想动手实践，建议从一篇结构最复杂的文档开始，转成 HTML，观察模型在总结、抽取、问答任务上的表现。对比一下同样是“把文档喂给模型”，Markdown 和 HTML 到底哪个让你少改几轮提示词。这个实验成本很低，但结论很可能颠覆你习惯的“Markdown 万能”认知。
下一步值得深入的方向有三个：一是 RAG 文档切分策略，结合 HTML 的语义标签设计更合理的切块规则；二是结构化提示词工程，学会用 XML 标签或 HTML 块组织上下文，减少模型的自由发挥；三是 Agent 的工具设计，当一个 Agent 需要消费长文档时，怎么利用 DOM 结构完成精准抽取而不是整段复制。这些都是 AI 应用层工程师接下来真正要面对的工程问题。
格式选择这件事，本质上是你是否愿意为“机器可理解性”多付一点写作成本。在 AI 成为重要读者的今天，这笔成本越来越值得付。