Dashi PPT：9291 star 的开源 Skill，把「做 PPT」变成「拿到一份打开就能改的网页」

Fri, 09 Oct 2026 21:30:00 +0800

让 AI 生成一份 PPT，这件事本身早就不难了。真正难的是——生成完之后，你想改一个字、换一张图、把三张卡片变成五张，而它改不动。

Dashi PPT 的全部价值几乎都押在这个点上。README 里有一句话写得很直白：「生成之后如何编辑，比生成本身更重要。」 于是它给出的产物不是一份导出的 .pptx 死文件，而是一台跑在浏览器里的 PPT 编辑器：翻页、点字改字、拖图换图、拖滑杆增减模块、换配色、换图表类型，改完再一键导出成真实的、逐节点可编辑的 PPTX。

它的体量也配得上这个野心：12 套视觉主题、1020 个版式页面、8576 个可调控件。截至本次快照，仓库 9291 star、821 fork，AGPL-3.0 许可，JavaScript 实现。

数据说明：本文信息来自项目 GitHub 仓库（chuspeeism/dashi-ppt-skill，默认分支 main）的 README.md、skills/dashi-ppt/SKILL.md（约 26 KB）、skills/dashi-ppt/README.md、references/options.md、references/layout-roles.md、skills/dashi-ppt/project/package.json、project/packages/html-deck-to-pptx/README.md，以及 npm registry 上的包元数据。数据快照时间为 2026-10-09（仓库状态：main 分支，AGPL-3.0，9,291 star / 821 fork / 31 watch / 16 个开放 issue，仓库体积约 102 MB，最新提交为 2026-09-12 的 Publish skill v0.4.14）。项目仍在迭代，具体行为请以你所用版本与仓库最新文档为准。

它是什么
真问题不在「生成」，在「生成之后」
架构核心：内容与版式彻底解耦
3+1 变体：为什么每页给你四个方案
1020 个版式是怎么算出来的
产物即编辑器：控制台里那 8576 个控件
PPTX 导出的硬骨头：逐节点保真回退链
许可策略：AGPL-3.0 与它的专有导出引擎
隐私与成本：内容零上传，10 页约 10 万 token
平台支持与安装
工程气质：三层校验，以及「阻塞」这个词
成熟度评估
结语

一、它是什么

一句话：一个把「汇报目标」翻译成「一份可离线打开、可编辑、可导出的 HTML 演示」的 AI Agent Skill。

它的工作方式不在网页对话框里，而在你本机的 Agent 里。你把文档丢进去，说一句「用 dashi-ppt 做一份 PPT」，它会：

提炼需求 —— 主题、受众、页数、要突出的结论、最终格式；
让你选风格 —— 展示 12 套主题预览，你挑一套（不替你决定）；
自动组稿 —— 把需求整理成逐页的结构化内容包，并据此设计页面方案；
生成 —— 在本机渲染出 index.html + assets/，并起一个本地预览服务；
随手改 —— 你在浏览器里改字、换图、调版式，改动自动保存；
导出 —— HTML 离线包 / PDF / 可编辑 PPTX 三选一。

它自己划的适用边界也很清楚：

合适：行业研究、融资复盘、竞品分析、趋势报告、项目汇报、方案展示、路演材料、内部培训——需要「快速形成结构完整、视觉统一、还能继续改」的场合；
不合适：需要逐像素手工定制视觉的场合。

这句话值得记住，因为它解释了后面所有的架构选择：它做的不是「精美海报」，是「能交出去、还能被改的工程文档」。

二、真问题不在「生成」，在「生成之后」

市面上的 AI 做 PPT 工具，绝大多数把力气花在「第一次生成得好不好看」。但真实工作流里，一份 PPT 的成败几乎从来不取决于初稿：

领导说「第三页那个结论换一下」；
客户说「你们这套配色太跳，换成稳一点的」；
你自己发现「这页数据是去年的，得换成最新季度」。

在传统「生成 → 导出 pptx」的流程里，每一次这类修改都意味着回到对话框重新生成一遍，而重新生成的结果是不可控的——版式会变、配色会变、内容会漂移。你为「AI 帮我省了半小时」付出的代价，是「我再也拿不回那个版本」。

Dashi PPT 选择的路径是：把可控性直接交到产物里。 它生成的 HTML deck 本身带一整套编辑控制台，你不需要回到 Agent，也不需要重生成——改的就是那一份文件。

这个决策直接决定了它的技术形态，也决定了下面所有的架构设计：既然产物要能编辑，那么内容就必须和版式分开存放。

三、架构核心：内容与版式彻底解耦

这是整个项目里最值得学的一处工程设计。

如果按最直觉的写法，生成 PPT 就是「为每页挑一个 HTML 模板，然后把文字塞进去」。这么做在 12 套主题 × 上百个版面的规模下会立刻崩掉：内容是散的、结构是锁死的、改一处很容易牵动全身。

Dashi PPT 的做法是在 SKILL.md 里定义了一套 schema v2 的数据模型，核心就一句话：

每个逻辑页只保存一份 content（业务事实的唯一来源），渲染时再由模板按 contentMap + projection.structure 即时生成 props。

翻成普通话：

content 是「这页要讲什么」 —— 标题、摘要、要点数组、图表数据、媒体路径。它只写一次，不重复；
contentMap 是「这些内容分别填到版式的哪个槽位」 —— 一张 {目标路径: 内容源路径} 的映射表；
projection.structure 是「本例用这套版式的哪一部分结构」 —— 比如某个模板自带 6 个卡片槽，但本页只需要 3 个，就在结构投影里把其余显式关掉或置空。

于是「同一份内容，套不同版式」变成了一件纯计算的事——换主题不是重新生成，而是换一套投影重新渲染。

flowchart TD
 C["canonical content
唯一业务事实源"] --> M["contentMap
目标路径 → 源路径"]
 C --> P["projection.structure
本例的结构投影"]
 M --> R["渲染时即时生成 props"]
 P --> R
 R --> T["模板方案（前 3 个）"]
 C --> B["bespoke composition
12×8 网格元素"]
 B --> V4["方案 4：Agent 定制"]
 style C fill:#6B5B95,stroke:#6B5B95,color:#fff
 style R fill:#0A7CFF,stroke:#0A7CFF,color:#fff

这个模型还带来一个很实在的好处：修改 canonical content 之后，同一页的四个方案必须一起更新。 README 里明确写了这条约束——你改了一页的数据，四个方案不会各自漂移成一个不同的版本，因为它们本来就只是同一份内容的不同投影。

还有一条约束能看出作者的执念：

前三个模板方案使用「锁模板填文案」——保留所选页面组件的原始视觉、结构、数量、显隐、强调、配色、图表类型和图片槽位，只替换可见文字内容。

也就是说，AI 被明确禁止「自作主张改版式」。版式的美由模板保证，AI 只负责把话说对。 这是对「AI 一改就崩」这个普遍痛点最工程化的一次回应。

四、3+1 变体：为什么每页给你四个方案

在 schema v2 里，每一个逻辑页都会被渲染成 4 个方案：

方案	类型	可调整性	说明
v1 / v2 / v3	`template`	可调 props	从该主题的真实版式里挑 3 个结构指纹不同的布局，锁模板只填文案
v4	`bespoke`	固定（不可调属性）	Agent 在当前主题视觉语言内为本页内容单独定制，不继承任何模板

这里有几个细节挺有讲究：

前三个必须是「结构不同」的布局 —— SKILL.md 里反复强调「不要只换页码或镜像同一结构」，同一个逻辑页的三个模板方案要用结构指纹去重；
封面页有硬约束 —— 每套主题的前 5 页是封面候选，一个 deck 只能有一个逻辑封面页；如果这前 5 页凑不出 3 个结构不同的真实模板，就整页回退到第 6 页以后的正文布局，而且「同一逻辑页禁止混用封面与正文布局」；
v4 不是「模板的小改」 —— 它要求独立分析本页目标、受众、叙事作用、重点信息和主题特征，然后用受限的 composition 元素（只用 text / metric / list / quote / media / shape / chart 七种，铺在 12×8 网格上）自己搭一版。不新增事实、不写自由 HTML/JSX。

flowchart LR
 P["一个逻辑页
content"] --> A["v1 模板 A"]
 P --> B["v2 模板 B"]
 P --> C["v3 模板 C"]
 P --> D["v4 bespoke
Agent 定制"]
 A --> O["comparison 模式
展开 4N 页"]
 B --> O
 C --> O
 D --> O
 O --> S["选一个方案标记为最终版
导出 N 页"]
 style D fill:#F59E0B,stroke:#F59E0B,color:#fff
 style O fill:#2EA44F,stroke:#2EA44F,color:#fff

默认的 variantOutputMode 是 comparison：N 个逻辑页展开成 4N 个物理页，你在右侧面板里逐组比较、跳转、标记最终方案；也可以切成 selected-only 只输出 N 页。

这个设计本质上是在回答一个很现实的问题：AI 不知道你喜欢哪个版本，所以它把选择权连同选项一起交给你。 你花的是「多看一眼」的成本，换的是「不用在对话框里反复描述想要什么」。

五、1020 个版式是怎么算出来的

README 给的三个数字是：12 套主题、1020 个版式、8576 个可调控件。这三个数不是营销修辞，是能对上的。

先说 1020——它来自 12 套主题各自的版式数量之和：

主题	风格	版式数	主题	风格	版式数
`theme01`	轻拟态风	84	`theme07`	冷白调研风	71
`theme02`	炫光紫绿风	74	`theme08`	黑金实验风	84
`theme03`	深浅代码风	77	`theme09`	深蓝杂志风	111
`theme04`	玻璃糖果风	74	`theme10`	金色指数风	95
`theme05`	色谱图表风	94	`theme11`	高能增长风	87
`theme06`	深色图谱风	83	`theme12`	声波霓虹风	86

把右列加起来：84+74+77+74+94+83 = 486，71+84+111+95+87+86 = 534，合计 1020。对得上。

每套主题都有自己独立的页面结构和视觉语言，不是同一套模板换个配色——这是它和「一键换肤」型工具的根本区别。选主题，等于选了一整套版式体系。

再看「20 种页面角色」。references/layout-roles.md 里列得清清楚楚：cover 封面、statement 论点金句、breakdown 目录拆解、transition 章节分隔、context 背景定位、metrics 核心数字、trend 时间线与走势、comparison 对比表格、distribution 漏斗梯队、relationship 网络层级、case 典型案例、image 图片主导、process 产业链与路径、risks 风险研判、observation 洞察结论、ambient 氛围页、actions 落地路径、result 数字海报、team 团队、closing 结尾。数下来正好 20 个。

这套角色表是给选页用的——生成时先按页面的信息角色去检索候选版式，再从中挑结构不同的三个。它覆盖的图表与分析模型也明显是「咨询报告思路」：雷达图、瀑布图、矩形树图、漏斗、热力图、桑基图、甘特图，以及 SWOT、波特五力、PEST、商业模式画布、双钻模型。

六、产物即编辑器：控制台里那 8576 个控件

第三个数 8576，指的是所有版式里可操作的控件总数——它是「页面可编辑性」的量化表达。

生成之后你能改的东西，README 里按层列了：

设计调节：每页附带一个控制台，20 多个维度的编辑空间——内容、布局、模块数量、页面重点、预设配色、翻页动画；
文字编辑：任意文本点击即可就地修改，装饰元素随字数自适应；
媒体槽：点击或拖拽即可替换图片/视频，上传自动压缩；
数量控制：拖滑杆直接改模块数量（目录项、表格行、图表序列、图片数）——「拖动控制台右侧的滑杆，就能自定义页面中模块的数量」；
重点调换：页面的逻辑重点也能用滑杆调换，「帮你把握演讲节奏」；
图表切换：一句话换图表类型；
配色切换：每套风格内支持局部配色调换；
翻页动画：9 种切换动画任选；
页面管理：左侧缩略图目录支持拖拽重排，页面可跳过 / 删除 / 复制；顶栏可一键进入放映模式、切换明暗主题、重置全部改动。

这里有一个刻意的克制值得注意。FAQ 里有人问「可以自定义 xxx 吗」，回答是：

当前自定义样式仅限于特定范围。这是有意为之：稳定的产出比自由的选色更重要。

一个做「编辑能力」的产品，主动限制编辑范围，理由居然是「稳定比自由重要」——这背后是真实的取舍：开放的配色与尺寸一旦失控，产出就不再是可交付的工程文档，而是一堆需要返工的半成品。

七、PPTX 导出的硬骨头：逐节点保真回退链

如果说页面生成是「怎么好看」，那么导出 PPTX 就是「怎么不崩」——而这是所有 HTML 转 PPT 工具真正的坟场。

道理很简单：HTML 的能力集远大于 PPTX。渐变、SVG、滤镜、复杂混合模式、CSS 变换……PPTX 里根本没有对应物。大多数工具在这类元素上要么拍平成一张位图（好看但不能改字），要么直接转崩。

Dashi PPT 的导出引擎（子包 project/packages/html-deck-to-pptx）给了一个更聪明的方案，README 里叫「逐节点保真回退链」：

flowchart TD
 S["遍历 deck 的 DOM 节点"] --> Q{"能映射到
PPTX 原生对象？"}
 Q -->|是| T["生成可编辑的文字 / 形状对象"]
 Q -->|否| SS["该区域截图"]
 SS --> EX["从实时 DOM 把文字重新抽回
保持可编辑（无 OCR）"]
 T --> O["pptx 节点树"]
 EX --> O
 O --> R["输出可编辑 .pptx"]
 style Q fill:#D24726,stroke:#D24726,color:#fff
 style EX fill:#F59E0B,stroke:#F59E0B,color:#fff
 style R fill:#2EA44F,stroke:#2EA44F,color:#fff

关键就在那条「截图 + 从实时 DOM 抽回文字」的组合拳：

映射不了的漂亮背景 → 截图，视觉 100% 保真；
但覆盖在这块背景之上的文字 → 不是从图片里 OCR 出来的，而是从还在浏览器里活着的 DOM 上直接读出文本，重建成 PPTX 的文字对象。

结果是：你导出的 PPT 里，那块炫光背景是图，但上面的每一个字仍然能双击编辑、换字体、改字号。 这比「整页拍平」高了一个量级，也比「OCR 识别」可靠得多（OCR 会错字、会丢版式）。

工程细节里还有两处能看出分量：

alpha-matte 透明背景捕获 —— 解决透明元素叠加时的边缘脏边问题；
基线明写在文档里 —— scripts/benchmark 记录的 editableFidelity 基线是 0.851，并且给了可复现的端到端验证数据（「经包入口端到端导出 2 页 → 41 个可编辑文本对象，npm test 绿」）。

有一条限制也写得很清楚：导出 PPTX / PDF 需要本机装有 Chrome / Chromium / Edge（可用 CHROME_PATH 环境变量指定），走的是 Playwright 驱动真实浏览器渲染——因为要拿到那份「活着的 DOM」。

值得注意的是，这个导出引擎还没完全收尾。README 自己列了待办：注解协议目前只参数化了 activeSlideSelector 一项，「其余注解协议的完全参数化是发布前的收尾项」；「6140 行验证器迁入本包作自带 CI 门」也还在进行中。一个愿意把「还没做完的部分」直接写进 README 的项目，通常比一个宣称「全部完成」的项目更可靠。

八、许可策略：AGPL-3.0 与它的专有导出引擎

许可这块，Dashi PPT 走了一条在开源界越来越大、但争议也大的路：open-core（开放核心 + 专有增值）。

主体采用 AGPL-3.0 —— OSI 认证协议里 copyleft 效力最强的一个。你可以自由使用、修改、分发（含商业用途）；但如果你分发修改版，或基于它通过网络对外提供服务（比如做成 SaaS），就必须以 AGPL-3.0 向用户公开完整对应源代码；
例外：子包 project/packages/html-deck-to-pptx（也就是上面那套导出引擎）是专有组件，只授权作为本 skill 的组成部分使用，不得单独提取、复制或再分发。它的 v0.2.7 及之前的历史版本曾以 MIT 发布，但那授权只对历史版本有效。

这个分割线位置很讲究：页面生成开源，导出引擎专有。

也就是说，你可以自由拿它去做 PPT 生成、随便改、甚至基于它搭服务（只要开源你自己的改动）；但如果你想单独拿那套「逐节点保真 + 抽回文字」的导出能力去卖，就不行。README 里也直说了：「商业层（托管 API / 高保真插件）不在本开源包内。」

对使用者的实际影响有三条：

个人用、公司内部用 —— 基本无感，随便用；
想基于它做对外 SaaS —— 注意 AGPL 的传染性，你的整套服务代码大概率需要开源，或者去谈商业授权；
想单拎导出引擎 —— 不行，去谈商业授权。

九、隐私与成本：内容零上传，10 页约 10 万 token

FAQ 里两个问题回答得很实在，也值得单独拎出来看。

内容安全。 官方表述是「内容层面零上传」：你的文档和 PPT 内容不会发到任何服务器，生成、编辑、导出都在本机完成，成品离线可开。会联网的只有两件事——首次生成时 npm 自动安装依赖；任务完成后的静默版本检查（只拉版本号，不上传内容）。

但同一段里还有一句容易被忽略的诚实披露：

另外本地预览服务默认在同一局域网内可访问，仅供浏览，导出接口只对本机开放。

翻译一下：预览页在同网段的其他设备上可能能打开（纯粹的便利性设计），但导出接口绑在本机。这是个正面的设计取舍，但在咖啡馆、共享办公这类环境下值得自己留意一下。

成本。 「生成一套 PPT 大概消耗多少 token？」回答是：

一套 10 页的 PPT 实测约 10 万 token（随文档长度和往返修改次数浮动）。按 Codex 5 小时额度窗口粗算，大约够生成 10 套。

10 页 10 万 token，这个量级值得记住——它意味着这不是一个可以无限试错的工具。反过来也解释了为什么它要把「3+1 变体」和「产物即编辑器」做得这么重：因为重生成一次太贵，所以把修改尽量挪到生成之后、挪到浏览器里。

十、平台支持与安装

安装是一条命令：

npx dashi-ppt-skill@latest

国内网络用镜像：

npx --registry=https://registry.npmmirror.com dashi-ppt-skill@latest

安装和更新是同一条命令，重跑即原地更新（已装依赖自动保留）。环境要求：Node.js 20+ 和 npm；导出 PPTX / PDF 另需本机有 Chrome / Chromium / Edge。

平台支持表只列「已实测」的，但不代表「仅限这些」：

平台	状态	说明
Claude Code	支持
Codex	支持	可调用生图能力补充配图
豆包	支持	需要启动「办公模式」
Marvis / WorkBuddy / Dumate / Qclaw	支持	skill 文件放任意位置、能读 `SKILL.md` 即可
Cursor / 其他本地 Agent	可用	需能读写文件并执行 shell 命令
普通网页 Chatbot	不推荐	生成器需要本地 Node.js 环境

这里值得单独说一句：它对「Skill 形态」的理解是彻底去中心化的。 因为生成器是本机 project/ 里的一段 Node 程序，Agent 只是一个「帮我写 goal.json 并调脚本」的调度者——所以它不需要绑定任何特定厂商的插件市场，任何能读写文件、能跑 shell 的 Agent 都能用。

对 WorkBuddy 用户来说，这意味着它可以直接落地：把 dashi-ppt 目录放进 Skill 目录，重开会话就能用。

十一、工程气质：三层校验，以及「阻塞」这个词

看一个生成类项目成不成熟，最省事的办法是看它要求自己跑多少道校验。Dashi PPT 的 package.json 里挂着三道硬校验：

validate:goal-spec ← 渲染前必须过，校验 schema v2 结构（脚本约 82 KB）
validate:swiss ← 输出后必须过
validate:goal-copy ← 输出后必须过，专查文案是否残留模板默认值

其中最见功力的是 validate:goal-copy。生成类 AI 工具最常见的翻车方式，不是排版错，而是交付了模板自带的演示文案——「AI Capital」「SoundWave 声浪」「Key Metrics」「Roadmap」「End of Report」这类和你的主题毫无关系的词，就那么留在页面上。SKILL.md 里把这条写成了硬约束：

如果输出正文里出现与用户主题无关的默认文案……必须重写 JSON 后重新渲染，不能交付。

比校验更少见的是它怎么定义「失败」。SKILL.md 里给「成果验收」定了一个三态结论，只有 「通过」「待修正」「阻塞」，并且规定：

默认最多修正 2 轮。验收通过后才能交付；两轮后仍不通过则标记「阻塞」，说明未达标项和阻塞原因，不得将其表述为已完成成果。

同时它还明确区分了「机器校验」和「成果达标」：机器校验通过只是技术基线，不等于成果达标；默认不做截图审美精修，除非用户明确要求「100% 检查」「帮我调到满意」。

这几条约束合起来，传达的是一个很成熟的态度：AI 可以做得不够好，但不允许把不够好的东西说成做好了。 在一个人人都在讲「多智能体协作」「全自动」的领域里，愿意给自己划一条「我做不到，我告诉你是哪一项做不到」的红线，其实比多几个花哨功能更难得。

十二、成熟度评估

客观看一下这个项目：

维度	现状
活跃度	9,291 star / 821 fork / 31 watch；2026-06-10 创建，最新提交 2026-09-12（`Publish skill v0.4.14`），近一个月无新提交
Issue 面	仅 16 个开放 issue —— 对一个近万 star 的项目来说相当健康，说明维护者在持续收敛问题
仓库规模	约 102 MB（主要是内置字体 woff2 与主题素材），JavaScript，结构清晰：`skills/dashi-ppt/`（`SKILL.md` + `references/` + `scripts/` + `project/`）、`npm-dist/`（安装器）、`.claude-plugin/`（插件市场清单）
版本纪律	提交历史几乎全是 `Publish skill vX.Y.Z`，节奏稳定（0.4.10 → 0.4.14）；SKILL.md 每次收尾都跑静默版本检查
测试与校验	三道必跑校验（`goal-spec` / `swiss` / `goal-copy`），导出引擎自带 benchmark 与 `editableFidelity` 基线
许可	主体 AGPL-3.0；导出引擎子包专有（open-core）
文档质量	README 中英双语；SKILL.md 约 26 KB，把 schema、约束、验收标准、返工流程都写死了——罕见地详细

已经验证过的：12 套主题、1020 个版式（数字可加总核对）、20 个页面角色、9 种翻页动画、四类导出（HTML / PDF / PPTX）都有真实产物支撑；导出保真度有 benchmark 基线（editableFidelity 0.851）；端到端导出有可复现用例（2 页 → 41 个可编辑文本对象）。

仍待完善 / 值得注意的边界：

导出引擎尚未收尾：注解协议只参数化了 activeSlideSelector 一项，README 自己写着「其余注解协议的完全参数化是发布前的收尾项」；6140 行验证器迁入该包作 CI 门也仍在进行中。这意味着项目还没到 1.0 的完成度；
版本号有三条线，看数要认清：仓库内 skill 本体是 0.4.14；npm registry 上安装器包 dashi-ppt-skill 的已发布版本号到 0.4.11，而 dist-tags.latest 停在 0.4.5。三个数字并不一致——说明安装器与 skill 本体是两条独立的版本线，npx dashi-ppt-skill@latest 拉到的安装器版本不等于 skill 本体的版本，排查问题时要先确认自己手上是哪一条；
近一个月无新提交（最新 2026-09-12），需要观察后续维护节奏；
强依赖本机环境：Node 20+、npm，导出还要 Chrome/Chromium/Edge。纯网页 Chatbot 环境用不了；
成本不可忽略：10 页约 10 万 token，多轮重生成代价明显；
自定义有天花板：样式自定义被有意限制在特定范围，「稳定的产出比自由的选色更重要」——如果你的诉求是像素级定制，这套工具会挡着你；
AGPL-3.0 的传染性：要做对外 SaaS 需认真评估合规成本。

适合谁用：经常写行业研究、竞品分析、方案汇报、路演材料的职场人；已经在自己信任的本地 Agent（Claude Code / Codex / 豆包 / WorkBuddy 等）里干活、希望「一次生成、反复修改、最后导成能交出去的 PPTX」的人；以及想研究「AI 生成类产品怎么设计数据模型」的开发者——它的 schema v2 与 3+1 变体机制是很值得抄的架构。

不太适合：只需要一次成稿、不需要再改的极简需求（用它反而重）；需要逐像素定制视觉的品牌设计场景；受限于企业合规、不能用 AGPL 组件的商业团队。

十三、结语

把 Dashi PPT 拆开看完，我觉得它最值得记住的不是「12 套主题」或「1020 个版式」这些能上头条的数字，而是它对「AI 做 PPT 这件事的失败点」的判断有多准：

它知道 AI 改不动的地方在哪 —— 所以把产物做成编辑器，而不是一份死文件。「生成之后如何编辑，比生成本身更重要」；
它知道 AI 会乱改的地方在哪 —— 所以给前三个方案上了「锁模板填文案」的枷锁，AI 只负责把话说对，不负责发挥审美；
它知道 AI 会漂移的地方在哪 —— 所以规定「每个逻辑页只保存一份 canonical content」，四个方案都只是同一份内容的不同投影，改一处就一起更新；
它知道 AI 最丢脸的地方在哪 —— 所以专门写了一道 validate:goal-copy，专治「交付了模板自带的演示文案」这种低级翻车；
它知道自己做不到的地方在哪 —— 所以把验收结论设计成「通过 / 待修正 / 阻塞」，两轮修不好就诚实标阻塞，不许把没做完说成做完了。

还有一个我觉得很聪明的取向：它没有把「好看」当成护城河，而是把「能改」和「能导出成可编辑 PPTX」当成了护城河。 好看是模板的事，模板可以复制；但「改字不改版式」的数据模型、以及「截图配图 + 从实时 DOM 抽回文字」的导出链路，是真正难复制的工程。

一个开源 Skill 能做到9291 star、821 fork、只有 16 个开放 issue，同时把 schema、约束、验收标准和返工流程全部写死在 26 KB 的 SKILL.md 里——它把「克制」当成了产品力。在这个人人都在比谁生成的画面更炫的赛道上，它选择去解决那个更无聊、但更痛的问题：让你拿到手的东西，是能接着用的。

免责声明：本文为个人学习性质的项目文档解读，不构成对该软件的推荐、担保或安全评估。项目仍在快速迭代，文中数据为 2026-10-09 快照，具体行为请以你所用版本与仓库最新文档为准。特别提示三点：① 主体许可为 AGPL-3.0，导出引擎子包为专有组件，商业使用与二次分发前请自行确认合规性；② 本地预览服务默认在同一局域网内可访问（仅供浏览，导出接口仅限本机），在共享网络环境下请自行评估；③ 生成与导出会产生实际的 API token 消耗（10 页约 10 万 token）与本地资源占用，请自行评估成本。

生成式设计 on 我的博客