一个真实的分歧：AI 帮我做了个东西，我不知道该开哪个软件看它
上周我给某个团队做技术评审，要出三样东西：
- 一份评审报告（结论 + 分数 + 建议）
- 一版接管后的架构原型（几个组件重排，接口讲清楚）
- 一份面向管理层的汇报稿（十几页，视觉稍微像点样子）
我把需求丢进 Claude Code，让它自己挑手段。它给我出了三个截然不同的产物：报告是一个 report.html，架构是一个 prototype.html，汇报稿是一个 deck.pptx。
我盯着这三个文件愣了 30 秒。
AI 到底该给我什么格式？ 是 HTML？是 PPTX？还是不带格式的 Markdown？
这问题看着蠢，但踩过坑的人都懂。给错格式，返工的时间比重写还长。
这周我把 GitHub 上目前呼声最高的两个 skill 拉下来对比着跑了一周：
plannotator/effective-html（2.7k 星，主打 HTML 各种形态的 artifacts）chuspeeism/dashi-ppt-skill（6.3k 星，主打可编辑的真 PPTX）
它们分别代表两派看待"AI 交付物"的哲学。我拿同一份输入让它们跑同样的活，最后得出一个可操作的选型决策树。这篇写给同样在 skill 生态里犹豫要装哪一个的你。
先摆结论：HTML 赢 session，PPTX 赢 archive
急着做决定的先看这个。剩下的正文是"我怎么得到这个结论的"。
| 交付物 | 生命周期 | 优选格式 | 首选 skill |
|---|---|---|---|
| 代码评审、状态看板、状态巡检 | 打开-扫一眼-关掉 | HTML | effective-html |
| 交互式原型、可点可拖的 demo | 会议中演示 | HTML | effective-html |
| 内部技术架构图 / 时序图 | 塞进 wiki 或 PR | HTML（自包含） | effective-html |
| 客户提案、董事会汇报 | 邮件转发、归档 | PPTX | dashi-ppt-skill |
| 教学讲义、培训材料 | 反复修订 | PPTX | dashi-ppt-skill |
| 规范文档、SOP | 版本管理 + 引用 | Markdown | 都不用 |
| Agent 之间传递的数据 | 机器解析 | JSON / MCP | 都不用 |
一句话：HTML 是给会话的，PPTX 是给归档的，Markdown 是给版本的。
effective-html：把 AI 的输出变成一份能扔进浏览器就看的东西
effective-html 的思路特别克制。它不是一个"AI PPT 生成器"，也不是一个"AI 图表工具"。它就是六个 skill 的组合，每个 skill 专门干一件事：
| Skill | 干嘛用 |
|---|---|
html |
兜底路由，不确定要什么就走它 |
design-artifact |
提供创意方向，但不强推固定风格 |
html-wireframe |
低保真线框图，故意不做精，逼评审专注结构 |
html-prototype |
可交互的原型，带状态、键盘、响应式 |
html-plan |
计划、路线图、发布节奏，保留原始承诺 |
html-diagram |
架构图、时序图、状态图 |
每一个产物都是一个单独的 .html 文件——CSS 内联、JS 内联、图标 SVG 内联，没有外部依赖。你双击 file:// 就能打开，也可以直接扔进邮件、Slack、PR。
这一点你要品一下。传统的"AI 出可视化"逻辑是：AI 给你 JSON，你走 D3、走 Chart.js、走 Mermaid 渲染。中间隔了一道"你得跑个环境"的门槛。effective-html 把这个门槛砍了——AI 直接吐一个能开的 HTML，把渲染逻辑内嵌到产物本身。
用它的正确姿势不是"装了它然后每次都调"。README 里说得很实在：
You can use this repo without installing anything. Treat it as a reference first and an installable skill collection second.
翻译过来：它是一套写给模型看的方法论文档，装不装无所谓，让 Claude Code / Codex 能读到就行。这跟 Matt Pocock 那套 skills 工程化的思路是一路的（参见站内《Matt Pocock 的 skills 为什么能冲上 GitHub 热榜第一》）。
dashi-ppt-skill：把 AI 的输出变成一份能扔进 Keynote 就改的东西
dashi-ppt-skill 站在另一端。它认定汇报场景就是需要 PPTX——不因为 PPTX 有多好用，而是因为对面的老板、客户、评委只会打开 PPTX。
它的核心设计是先生成一个自带控制台的 HTML 版 PPT，你在浏览器里改，改到满意再导出成真 PPTX。中间的 HTML 只是编辑器，最终交付物是 PowerPoint 原生节点——文字可编辑、图形可拖动、字体可替换。
我在《让 AI Agent 直接给你交可改的 PPTX：dashi-ppt-skill 一周实测》里已经把它单独拆过一遍，这里不重复。核心亮点四条：
- 12 套主题、1020 个版式页面
- 每页自带控制台，滑杆调布局、点击换配色
- headless Chrome 逐页导出真 PPTX，图表是原生形状不是图片
- 一份 15 页 PPT 大约 15 万 token，用 Claude Max 订阅零边际成本
这不是"AI 生 PPT"这套老路，这是把编辑权交回给你的新路。
一样的输入，两套 skill 分别跑一遍
我拿三份真实素材，让两个 skill 分别产出，比较结果。
场景 1：技术评审报告
输入：一份 4200 字的第三方系统技术评审记录，包含 12 个评分维度、5 个风险项、3 条建议。
effective-html 产出（走 html skill）：一份单页 review.html。
打开就是一个类似 GitHub PR 页面的评审报告：左侧是维度列表，中间是评分卡片，右侧是可折叠的证据链接。每个风险项点开是一小段引用+定位。分数用 SVG 圆环画的，颜色按级别自动变。全文 240 KB，双击打开秒开。
dashi-ppt-skill 产出（生 12 页 PPT）：一份 review.pptx。
12 页里前两页是封面和目录，中间十页每页讲一个维度，最后两页是风险和建议。视觉是"冷白调研风"主题，字号规整，表格分类清晰。文件 3.8 MB。
我更愿意收到哪份？ 如果只是内部同事看，我选 HTML——快、直接、能搜索、能 Ctrl+F。如果要邮件转发给上级评审委员会，我选 PPTX——他们已经习惯在 PPT 上划重点。
赢家：这一场看用户。effective-html 输在"上级习惯 PPT"这个非技术因素上。
场景 2：架构原型
输入：一句话——“帮我把这个单体后端拆成 3 个微服务，画一个可点击的原型，让评审能理解服务之间的调用”。
effective-html 产出（走 html-prototype）：一份 architecture.html。
这一次差距拉开了。打开是一张架构图，3 个服务节点可以点击。点一个服务，右侧滑出这个服务的接口列表、DB 依赖、上下游关系。点接口能看到示例 request/response（AI 编的假数据但格式正确）。悬停调用线会高亮相关链路。全部原生 JS + SVG。
dashi-ppt-skill 产出：8 页静态图。
每一页画一部分：整体拓扑一页、服务 A 详情一页、服务 A 接口列表一页……评审要点服务 A 得翻 3 页。所有交互都不存在——PPT 天生就是静态的。
赢家：effective-html 完胜。交互性是原型的灵魂，PPT 是拍板前的辅助工具，不是评审载体。
场景 3：董事会汇报
输入：一份 6800 字的季度融资复盘。要求 12 页以内，观感稳重，能打印。
effective-html 产出：一份长条式 HTML 报告。
技术上完美——响应式、深色模式、里面还嵌了 SVG 图表。但董事会 5 个人有 3 个在 iPhone 上看，长条 HTML 在手机上滑动体验不错，可打印性差；有 2 个要求把材料"发到我邮箱"，HTML 附件很多老派邮箱客户端会屏蔽。
dashi-ppt-skill 产出：12 页 PPT。
董事会常见格式，视觉稳重，字数控制得住，图表原生形状——他们打开 Keynote 想改数字就能改。打印一份塞档案袋也没问题。
赢家：dashi-ppt-skill 完胜。归档、传阅、修订的场景，PPTX 依然是既有工作流的锚点。
从架构本质看：为什么 HTML 和 PPTX 会长成两个物种
打完对比赛，你可能会问：为什么不能有一个 skill 同时把两件事都干了？
因为它们的产物哲学根本不同。
HTML 是活的：
- 打开即渲染，DOM/JS 就是运行时
- 天然响应式，同一份文件手机电脑都能看
- 交互是原生能力，不用额外工具
- 分享靠一个 URL 或者一个附件
- 一次性消费：看完关掉就完了，很少有人存
PPTX 是死的：
- 打开需要专门软件（Keynote/PowerPoint/WPS）
- 每一页是一个固定尺寸的画布，非响应式
- 交互只有"点下一页"
- 分享靠附件转发
- 反复修订：你会打开三次、五次、十次改里面的字
Thariq Shihipar 在《The unreasonable effectiveness of HTML》里有句话概括得很准：
HTML wins the session. Markdown wins the archive.
我把它扩展一下：
HTML 赢会话，PPTX 赢归档，Markdown 赢版本，JSON 赢机器。
effective-html 押的是"会话"这一半——快速可视化、原型演示、诊断看板。dashi-ppt-skill 押的是"归档"这一半——正式汇报、教学讲义、可传阅材料。
它们看起来在"打架"，其实是在瓜分市场。你的选型不是二选一，而是按场景配对。
一个可操作的选型决策树
给你一份我这一周攒下来的决策树，直接拿去用：
你要交付的东西：
├─ 一次性演示 / 会议中演示
│ ├─ 需要交互（点击、拖动、切换视图）→ effective-html: html-prototype
│ ├─ 只是给结构 → effective-html: html-wireframe
│ └─ 只是给概念图 → effective-html: html-diagram
│
├─ 邮件发出去 + 归档
│ ├─ 观感稳重、可打印、能反复改字 → dashi-ppt-skill
│ ├─ 客户/董事会/正式评审 → dashi-ppt-skill
│ └─ 团队周会汇报 → effective-html: html（长条式报告页更省时间）
│
├─ 文档 / 规范 / SOP
│ └─ 直接让 AI 出 Markdown，进 Git 库
│
├─ Agent 之间的数据传递
│ └─ JSON / MCP，别走人类可读格式
│
└─ 教学材料 / 培训课件
└─ dashi-ppt-skill（因为培训师后续要反复本地修订）
装法快速对比
effective-html：装或不装都行，官方推荐先把它当参考手册用。
如果一定要装：
# 装整套
npx skills add plannotator/effective-html
# 只装 html-prototype
npx skills add plannotator/effective-html --skill html-prototype
# Claude Code 插件方式
/plugin marketplace add plannotator/effective-html
/plugin install plannotator-effective-html@effective-html
dashi-ppt-skill：
npx dashi-ppt-skill@latest
一条命令，Agent 会自己拉依赖（Puppeteer 那一堆），大概 90 秒。国内网络加镜像：
npx --registry=https://registry.npmmirror.com dashi-ppt-skill@latest
一起用：真实工作流示范
skill 之间不打架，可以配合。我给你我这一周实际跑通的融资尽调 + 尽调汇报双 skill 工作流：
Step 1（尽调阶段）：让 AI 拆分标的公司资料。
用 effective-html 的 html-plan 给我出一份 3 周尽调时间表，
每一周的关键动作可展开，用不同颜色标出团队分工。
产出：一份 dd-plan.html，团队每个人扫一眼就上手。
Step 2（数据分析阶段）：让 AI 出中间产物。
用 effective-html 的 html-diagram 画一张标的公司的资金流向图，
把关联方交易用红色标出。
产出：一份 money-flow.html，评审会上直接投屏。
Step 3（对外汇报阶段）：切换到 PPTX。
用 dashi-ppt-skill 把 dd-plan.html 和 money-flow.html 里的关键
结论整合成 15 页 PPT，主题选 theme07 冷白调研风，
观感稳重，最后一页是签字页。
产出：一份 dd-report.pptx，客户手里能改字、能打印、能存档。
Step 4（存档）：让 AI 出 Markdown。
把这次尽调最终结论按公司内部 SOP 模板整理成 Markdown，
准备提交到 Git 的 due-diligence-reports/ 目录。
产出：一份 2026-Q3-target-xxx.md，进版本库供未来引用。
一场尽调，四种格式各司其职。这才是 Agent Skill 该有的用法——不是"哪个格式最好"，是"哪个格式在哪个环节最好"。
一个反直觉的观察：skill 生态正在解决 Markdown 一家独大的问题
过去两年，几乎所有的 AI 产物默认都是 Markdown。你问 GPT/Claude 任何问题，它默认给你带表格、带列表、带代码块的 Markdown。
为什么会这样？ 因为 8K token 时代（GPT-4 刚发布那阵），Markdown 是最省 token 的表达方式。ChatGPT 的界面又天然渲染 Markdown，形成了默认路径依赖。
这个默认现在不合理了：
- 上下文窗口从 8K 涨到 200K，token 密度不再是核心矛盾
- 模型的前端设计能力大幅上升，出一份完整 HTML 只比 Markdown 多花 30% token
- Agent 有 shell 权限，能跑 headless Chrome、能操作真 PPTX，产物形态不必受聊天窗口限制
skill 生态就是这波变化的产物。effective-html 押 HTML、dashi-ppt-skill 押 PPTX、还有一堆押 SVG / 视频 / PDF 的 skill——它们的共同点是：跳出 Markdown 默认，让 AI 用最合适的格式交付。
这跟站内《Skill 记方法论，MCP 调外部 API：一次拆解》里那个"skill 是方法论、MCP 是外部能力"的判断是同一个脉络——skill 让 Agent 知道该以什么形态交付活儿。
一些坑，提前告诉你
effective-html 的坑
- 不装反而不好用。README 说"可以不装当参考文档"，但我实测 Claude Code 3.5 不装的时候，产出的 HTML 品质不稳定；装了之后 skill 里的样例代码会被拉进上下文，产出突然就"对味"了。
- HTML 在 iOS Mail 里会被折叠。别的邮件客户端也可能拒收
<script>，如果你必须靠邮件传递，考虑先转成 PDF。 - 中文字体没做特殊处理。默认字体在 macOS/Windows 混合环境下会飘，改
system-ui, sans-serif兜底比较稳。
dashi-ppt-skill 的坑
- Node 版本不能低于 20，18 会挂在
Unsupported engine。 - Linux 服务器上要显式指定 Chrome 路径：
export CHROME_PATH=/usr/bin/chromium。 - 中文字体错位要选主题 theme01/07/09，或者直接跟 Agent 说"用系统自带字体生成"。
什么时候两个 skill 都不用
也有情况这两个 skill 都是过度设计：
- 你只是问一个技术问题：让 AI 直接答就行，别硬要它出 HTML/PPT。
- 产物会被机器读：走 JSON、走 MCP，别走给人看的格式。
- 产物要进版本库长期维护：Markdown 天然赢，因为 diff 好读。
- 产物只是一次性的对话中间态：默认 Markdown，别浪费 token 走可视化。
Skill 是用来把 Agent 引导到正确交付形态的机制，不是"每次都调"的必需品。装归装，用不用你说了算。
快速回顾
- effective-html：2.7k 星，六个 HTML skill 组合，专治"会话中要一份能立刻看的东西"。
- dashi-ppt-skill：6.3k 星，一条命令装，专治"要发出去归档的正式 PPT"。
- 选型口诀：会话给 HTML，归档给 PPTX，版本给 Markdown，机器给 JSON。
- 组合用：一场尽调可以四种格式各司其职，不必二选一。
- skill 生态的价值：让 AI 跳出 Markdown 默认，用最合适的形态交付。
如果你已经在用 Claude Code 或 Codex，两个 skill 都装上，占硬盘不到 100 MB，用一周你会有很清晰的直觉——什么活儿该让 AI 出 HTML，什么活儿该让 AI 出 PPTX。
这份直觉，比多学十个新工具还值钱。