企业官网建设流程全解析

Answer me with HTML 实测：让 AI 用一页图文网页回答复杂问题

一、一个所有 Agent 用户都遇到的痛点

你问 Claude Code、Codex 或者 Cursor 一个稍微复杂点的问题——比如"帮我梳理这个仓库的模块关系"、“比较一下 Redis 和 Memcached 的取舍”、“解释一下 TCP 三次握手”——它能写很多，但最后留给你的往往是一大段文字。

能读，但费劲；能复制，但难比较；想指出"这里我没看懂"，还得重新用文字描述一遍。

问题的本质是：复杂内容需要先看见结构，再继续追问。而纯文本恰恰丢掉了结构——流程图变成了"首先……然后……最后……"，对比表变成了三段并列的段落，状态迁移变成了一串句子。

最近在 GitHub 上有一个叫Answer me with HTML的项目（QingYunA/answer-me-with-html，目前 2500+ star）专门解决这个问题。它的思路很直接：别让 AI 直接写 HTML，让它写一份"扩展 Markdown"，再由一个 CLI 渲染成一页图文网页。

我把它完整跑了一遍，这篇文章记录调研和实测结果。

二、它是什么：一句话和一张架构图

一句话：Answer me with HTML 是一个 Agent skill + 内置 CLI，把 Agent 写的扩展 Markdown 稿件，渲染成一个单文件、可离线打开的 HTML 页面。

先看它的整体架构——这也是它和"直接让 AI 写 HTML"最大的区别所在：

┌─────────────────────────────────────────────────────────────┐ │ 用户提问 │ │ "解释 TCP 三次握手" / "Redis 还是 Memcached？" │ └──────────────────────────┬──────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Agent（Claude Code / Codex / Cursor） │ │ │ │ 产出：一份「扩展 Markdown 稿件」（约 600 token） │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ --- │ │ │ │ title: TCP 三次握手 │ │ │ │ cols: 3 │ │ │ │ --- │ │ │ │ ## A 三次握手 {span=2} │ │ │ │ ```mermaid sequenceDiagram num │ │ │ │ 客户端 -> 服务器: SYN, seq=x │ │ │ │ 服务器 --> 客户端: SYN+ACK, ack=x+1 │ │ │ │ ``` │ │ │ └───────────────────────────────────────────────────────┘ │ └──────────────────────────┬──────────────────────────────────┘ │ 稿件交给 CLI ▼ ┌─────────────────────────────────────────────────────────────┐ │ am CLI（随 skill 打包，本地运行） │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ 模板 + 主题 │ │ 图形自动布局 │ │ 单文件封装 │ │ │ │ sheet/doc │ │ dagre 算坐标 │ │ CSS/SVG 全内联 │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ │ │ │ 约 50ms 后 ──────────────────────────────▶ 单文件 HTML │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────┐ │ ~/.answer-me-with-html/ │ │ pages/*.html │ ← 离线可开，零外部依赖 └──────────────────────────┘

关键设计：模型只负责内容（写 Markdown），页面结构、CSS、SVG 坐标由CLI 用代码计算。这是它性能优势的根本原因——下一节展开。

三、原理：为什么不让模型直接写 HTML

这是这个项目最有意思的地方。README 里解释得很直接：

模型可以写 HTML，但一页像样的 HTML 会消耗很多 token 在 CSS、HTML 标签、SVG 坐标和重复结构上。内容还没讲完，模型先花了很多力气搭页面。

项目方统计了 9 页模型手写的 HTML，平均 4893 token，构成如下：

也就是说，手写 HTML 里有约 79% 的 token 花在了"搭页面"而不是"讲内容"上。

改成这个 skill 后，模型只需写 Markdown 稿件，官方小样本测试（3 个题目 × 3 次运行，取中位数，Claude Sonnet 5.5 环境）的结果：

注意两个诚实的边界（这点值得肯定）：

1. 这些数字来自项目方的小样本自测，不代表其他问题、模型和环境的表现；
2. 账单下降幅度小于写作量（这里约 15%）——因为每一轮对话无论用不用这个 skill，都要读系统提示词、你的问题和对话历史。

另一个原理上的好处：图表布局由代码计算，不靠模型猜坐标。流程图箭头、时序图间距、面板位置都更容易稳定——用过"让 AI 画图"的人都知道，模型手写的 SVG 经常箭头指歪、文字重叠。

四、实测：从安装到出页面

4.1 环境与安装

要求Node.js 20 或更高版本，没有npm install步骤（CLI 已打包在 skill 里）。

我本机是 Node v24.21.0，直接克隆就能用：

gitclone--depth1https://github.com/QingYunA/answer-me-with-html.gitcdanswer-me-with-htmlnpminstall# 只有两个运行时依赖：@dagrejs/dagre、marked

给 Agent 安装的话，官方推荐把这句话粘贴给 Claude Code / Codex / Cursor：

Install Answer me with HTML: read https://raw.githubusercontent.com/QingYunA/answer-me-with-html/main/INSTALL.md and follow it.

或者一行命令（安装器支持 70+ 种 Agent）：

npx skillsaddQingYunA/answer-me-with-html

4.2 跑通官方示例

我用官方自带的examples/tcp.md做第一次验证：

nodebin/am.js render examples/tcp.md --no-open-o/tmp/out_tcp.html

真实输出：

✓ /tmp/out_tcp.html sheet · blueprint · 6 panels · sequence×2 callout×1 flow×1 kv×1 STE ✓ 0 warnings

产物是一个91KB 的单文件 HTML，我用命令检查了它的自包含性：

ls-lh/tmp/out_tcp.html# 91Kgrep-cE'src="http|href="http.*\.(css|js)'/tmp/out_tcp.html# 0（零外部资源）grep-o'<svg'/tmp/out_tcp.html|wc-l# 6（内联 6 个 SVG）

零外部资源引用——这意味着它可以离线打开、可以直接发邮件、可以丢进任何文档系统，不用担心 CSS/JS 加载失败。

渲染出来的 TCP 三次握手页面长这样：

可以看到：同一个技术解释，被拆成了时序图、状态迁移图、关键数字和报文标志位几个区块。读者不用在一堆段落里自己拼图，页面已经把"三次握手"单独拆成图表区。

4.3 用我自己的题目测试

跑通官方示例不算什么，我换一个它没见过的题目——RocketMQ 消息发送链路：

--- title: RocketMQ 消息发送的完整链路 subtitle: 一条消息从生产者到消费者的旅程 cols: 3 source: RocketMQ 5.3.1 实测 --- 生产者发一条消息，背后经历了路由查找、顺序写盘、索引构建、长轮询投递四个阶段。 ## A 发送链路 {span=2 meta="核心流程"} ```mermaid sequenceDiagram num participants: 生产者, NameServer, Broker, 消费者 生产者 -> NameServer: 拉取 Topic 路由 NameServer --> 生产者: 返回 Broker 地址列表 生产者 -> Broker: 发送消息 note Broker: 顺序写入 CommitLog Broker --> 生产者: SEND_OK 消费者 -> Broker: 长轮询拉取 Broker --> 消费者: 返回消息体 note 消费者: 处理并提交 offset

（后续面板略）

渲染输出：

✓ /tmp/out_rmq.html
sheet · blueprint · 5 panels · sequence×1 kv×1 callout×1 flow×1
STE ✓ 0 warnings

产物 88KB，5 个面板、5 个内联 SVG。截图如下： ![用 Answer me with HTML 渲染的 RocketMQ 链路页面](https://i-blog.csdnimg.cn/direct/e36836b484494bb6b1a50936d3b30e8d.png) **实测结论**：它对我给的新题目渲染正确——时序图、对比表格、流程状态图、提示框都正常生成，排版清晰。 ### 4.4 组件能力清单 实测下来它支持这些组件（用 ```代码围栏 + 组件名声明）： | 组件 | 用途 | |---|---| | `sequence` | 时序图（消息往来、`num` 可自动编号） | | `flow` | 流程图 / 架构图（dagre 自动布局，支持 TB/LR/BT/RL 方向） | | `tree` | 层级树（组织架构 / 目录树，支持 `+`/`-`/`~` 变更标记） | | `timeline` | 时间线 / 阶段 | | `er` | 实体关系图（自动布局，鸦爪式连接端） | | `annot` | 逐句批注（下划线括号 + 注释，红字标记错误） | | `ask` | **页面上让读者做选择**（Reply 按钮汇总答案） | | `callout` | 结论 / 提示 / 警告条 | | `kv` | 键值网格 / 标题块（元信息） | | `limits` | 数值 vs 阈值进度条 | | `html` / `svg` | 原样嵌入（逃生舱口） | 模板有 3 种：`sheet`（图纸式面板网格，默认）、`doc`（单栏阅读，3+ 面板时自动生成目录）、`video`（讲解视频）。主题有 `blueprint`（工程图纸）、`shadcn`（卡片风）、`3b1b`（3Blue1Brown 暗色，仅视频）。 同一个内容换主题只改一个参数： ```bash node bin/am.js render examples/tcp.md --theme shadcn node bin/am.js render examples/tcp.md --theme paper

两种主题的实际效果对比：

五、一个特色功能：STE 受控语言检查

项目名里带ASD-STE100——这是航空业的"简化技术英语"标准。这个 skill 内置了一个受控写作检查器，会检查你的稿件文本：

• 句长：中文程序性文本 ≤35 字、描述性 ≤45 字；英文 ≤20 / ≤25 词；
• 段长：一段最多 6 句；
• 非推荐词表（中英文都有）；
• 英文被动语态；
• 中文轻动词（如"进行"）、的字链、套话。

我故意写了一段"犯规"的中文测试：

nodebin/am.js lint /tmp/ste_zh.md--stylestrict

真实输出：

STE 4 warnings (fix the draft and run again): L8 [sentence-length] sentence has 56 characters (max 45): "请确保液压油箱被加满，并且不要忘记检查压力值是否…" L8 [word] light verb "进行相关" (进行) → use "相关" L10 [word] light verb "进行相关" (进行) → use "相关" L10 [de-chain] chained "的": 这是一个非常重要的需要进行相关处理的操作步骤的说明内容。 → split the sentence or remove extra "的"

英文测试同样有效（触发sentence-length：27 词超过 25 词上限）。

这个功能的实际价值：写技术文档最容易犯的毛病就是长句、堆砌"进行/相关/的的的"，STE 检查把它变成了一个可以自动跑的门禁。--style off关闭、80宽松、strict严格。

六、边界：它不做什么

实测和 README 里有几条重要的边界，值得说清楚：

1. 批注不会自动同步回聊天。
你在页面里写评论或选选项后，需要点"回复"按钮，把汇总出来的内容复制回 Agent。它更像一个可视化工作台，不是一个和聊天窗口实时双向同步的应用。

2. 简单问题没必要出页面。
问ls怎么看隐藏文件，一句话就能讲清，照常回答就行。强行把每个短问题都做成网页，会让信息变重。README 里明确举了这个例子——这个克制是好的。

3. 它不保证内容正确。
页面再清楚，里面的技术结论仍然要回到源码、文档和实际环境核对。它改善的是"如何呈现复杂回答"，不是把 Agent 的回答自动变成事实。这一点非常关键——渲染得再漂亮，内容错了也是错的。

4. 它需要 Node.js 环境。
没有 Node 20+ 就跑不了 CLI。不过 CLI 是纯本地运行的，不上传任何内容到云端，这对内部资料场景是加分项。

七、什么时候该用它

调研下来，我的判断标准很简单——答案里有没有"关系、顺序或取舍"：

一句话总结：答案需要图、表、步骤和选择时，让 Agent 生成一页可离线打开的 HTML；答案一句话就够时，继续用普通聊天。

八、总结

Answer me with HTML 解决的是一个很具体的问题：把 AI 那堵"文字墙"整理成一页能阅读、能比较、能批注的 HTML。

它的核心设计思路值得学：把"写内容"和"搭页面"分工——模型只写 Markdown 稿件，CLI 用代码负责模板、主题、图形布局和单文件封装。这样既省 token（官方测试约 1/8），又让图表布局稳定（不靠模型猜坐标）。

实测结论（本文所有输出均为本机真实运行结果）：

适合谁：经常让 Codex、Claude 或 Cursor 解释架构、流程和方案取舍的人。如果你已经在用这些 Agent，可以先拿一个复杂问题试试（比如"帮我把这个仓库的模块关系解释成一页页面"），而不是装上后到处套。

最后提醒：它改善的是呈现方式，不是内容正确性。页面上的技术结论，仍然要回到源码和实际环境核对——这一点，对任何 AI 工具都成立。

本文基于 Answer me with HTML v0.5.0 实测撰写，所有命令输出与截图均来自本机真实运行。