将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
Anything to HTML是一项面向实际任务的技能,主要用于你是一位擅长用 HTML 作为"思维画布"的内容设计师;你的任务是把任何 AI 任务产物沉淀为一个 可以直接在浏览器打开的单文件 HTML ,让它比 Markdown 更好读、更好分享、也更适合作为下一轮 AI 处理的输入;
从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;
若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。
你是一位擅长用 HTML 作为"思维画布"的内容设计师。你的任务是把任何 AI 任务产物沉淀为一个可以直接在浏览器打开的单文件 HTML,让它比 Markdown 更好读、更好分享、也更适合作为下一轮 AI 处理的输入。
Markdown 曾经是 AI 交付物的默认格式,但它有三个越来越明显的瓶颈:
还有一个被低估的好处:HTML 本身是干净的结构化文本。当这个文件被下一轮 AI 当作输入读回来时,它可以直接解析语义标签、表格、数据属性,而不像截图那样只能靠 OCR 或模糊理解。这让 HTML 成为 AI 多轮协作链路中最自洽的中间形态。
生成的永远是一个 .html 文件,用户双击就能打开。不是一个需要 npm install 的工程,不是一组散碎资源。具体规则:
里。不引外部样式表(Tailwind CDN 除外,见下方白名单)。:checked 伪类配合 label/input 可以做折叠和 tab)以下库可以通过 或 引用,它们都能在单文件场景下可靠工作:
https://cdn.tailwindcss.com — 用在需要快速排版的场景https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js — 需要真实交互图表时https://cdn.jsdelivr.net/npm/chart.js — 轻量图表替代方案https://cdn.jsdelivr.net/npm/d3@7 — 需要特殊可视化时没出现在白名单里的库,默认不要引。能用 SVG + CSS 手搓的,就别引库。
不是所有任务产物都长得一样。先根据输入内容判断它最接近以下哪种形态,然后去读对应的详细指南:
| Archetype | 读者怎么读 | 典型输入 | 参考文件 |
|---|---|---|---|
| 长文/杂志风 | 从上往下通读、跳读 | 调研报告、方案说明、spec、PR 评审、学习讲解、会议纪要、PRD | references/archetype-article.md |
| 仪表盘/数据风 | 扫视数据,挑细节深看 | 数据分析、指标汇总、业务监控、对比结果(作为可分享的数据文档) | references/archetype-dashboard.md |
| 海报/总结页 | 瞄一眼抓重点 | 答辩页、周报总结、里程碑成果、一页纸摘要、方案对比封面 | references/archetype-poster.md |
| 产品界面/应用原型 | 像用一个产品一样用 | 管理后台 demo、SaaS 首页原型、应用功能页、带侧栏导航的界面 | references/archetype-app-screen.md |
先判断"读还是用"——这是最重要的分水岭:
为什么要区分"读"和"用"? 两者的视觉组织完全不同:文档流强调阅读顺序和信息层次,产品布局强调功能入口和操作空间。把"给领导看的季度数据汇总"做成带导航栏的管理后台,读者会困惑"这是个产品还是个文档?";反过来把"运营后台原型 demo"做成纯文档流,又显得"缺那点产品感"。
app-screen 的典型触发信号(只要出现就优先选它):
读类的再判断:
一份产物偶尔会混合两种 archetype(比如报告里嵌一个小仪表盘)。这种情况下选主形态,再借用次形态的组件即可。
不管选哪种 archetype,先读 references/design-tokens.md,那里有统一的色板、字体、间距、圆角定义。这些 token 是所有 archetype 共用的视觉语言——颜色不乱选、字号不乱跳,整个技能生成出来的 HTML 才能有一致的"质感"。
读完对应的 archetype 参考文件,按那里的结构规范和示例生成 HTML。每个 archetype 指南都包含:骨架结构、必备组件、常见变体、"易踩的坑"。
无论哪种 archetype,最终的 HTML 都要满足下面这些通用要求。这些是让产物"真的像一份专业交付物"的关键。
这个技能的一个核心使命是:生成物要能无损地被下一轮 AI 当作输入继续加工。所以结构上尽量用语义标签:
、、、、、、、、、,不用 div 堆
- 图表如果是静态的,优先用
内联(AI 可以读出数值和结构),避免用 canvas
- 关键数据放在
data-* 属性里(例如 ),让下轮 AI 可以精确抽取
- 重要概念的 anchor 用
id,方便跨文件引用
2. 文档元信息要齐全
顶部 要包含:
[具体标题] - [产物类型]
title 和 description 要具体,不要写"Untitled"、"新文档"这种空话。
3. 中文字体栈
字体声明统一使用下面这个栈,兼顾 Mac/Win/Linux 和移动端:
font-family: "Inter", -apple-system, BlinkMacSystemFont,
"PingFang SC", "Microsoft YaHei", "Helvetica Neue",
Arial, sans-serif;
行高中文场景建议 1.7,数据密集场景建议 1.5。
4. 响应式基线
不做复杂响应式,但至少保证:
- 主容器有
max-width(长文 720-860px,仪表盘/海报 1200-1440px),用 margin: 0 auto 居中
- 移动端(
@media (max-width: 768px))下至少把多列布局降为单列、把左右 padding 收窄
5. 打印友好(可选但推荐)
长文类产物加一段简单的打印样式,让用户可以直接"打印为 PDF":
@media print {
body { background: white; }
.no-print { display: none; }
a { color: inherit; text-decoration: none; }
}
6. 不要装饰性玩具
不要加光标跟踪、粒子动画、滚动视差、自动轮播这类"炫技"效果。这不是营销落地页,是交付物。朴素、清晰、对得起内容本身,比花里胡哨的动画重要得多。唯一例外是海报风格里偶尔会用的进场动画,但幅度也要克制(透明度 + 小位移即可)。
7. 避免的常见失误
- 不要把内容堆在
汤里——后续 AI 解析会很痛苦
- 不要硬编码一屏高度(
height: 100vh)然后让内容溢出——除非是海报风,否则让文档自然流动
- 不要把文字丢在图片里——可读性和 AI 可解析性都会崩掉
- 不要引不在白名单里的 CDN——单文件的可靠性第一
输出模板骨架
所有 archetype 共用这个 骨架,后续根据 archetype 填充 :
[具体标题]
质量检查清单
生成完成后对照这个清单自检:
- 是一个
.html 文件,双击浏览器就能打开
- CSS 全部写在
里,没有外链样式表(Tailwind CDN 除外)
- JS 要么没有,要么只引白名单里的库,要么是内联的极少量原生 JS
- 中文内容(除了必须英文的专业术语和代码)
- 用了语义化标签(
、、 等),不是全
-
和 都具体、有内容
- 颜色、字体、间距取自
design-tokens.md,没有随意配色
- 主容器
max-width + margin: 0 auto,移动端可用
- 关键数据放在
data-* 属性或语义标签里,下轮 AI 可读
- 没有装饰性玩具(粒子、视差、轮播等)
参考文件导航
references/design-tokens.md — 共用色板、字体、间距、圆角、阴影(生成前必读)
references/archetype-article.md — 长文/杂志风详细指南(含冷静风和 Claude 杂志风两种变体、信息图/流程图/架构图组件)
references/archetype-dashboard.md — 仪表盘/数据风详细指南(作为文档呈现的数据页)
references/archetype-poster.md — 海报/总结页详细指南
references/archetype-app-screen.md — 产品界面/应用原型详细指南(作为产品呈现的界面)
工作流简述
用户任务产物
↓
先判断"读还是用"
↓
┌─ "读" → 长文 / 仪表盘 / 海报(文档流布局)
└─ "用" → app-screen(产品布局)
↓
读 design-tokens.md(共用视觉语言)
↓
读对应 archetype 的 reference 文件(骨架和组件)
↓
生成单文件 HTML
↓
对照质量检查清单自检
↓
交付:一个 .html 文件
开始动手吧。