10 KiB
| name | description |
|---|---|
| ppt | 生成 PowerPoint 演示文稿 (.pptx)。当用户要求做汇报 PPT、把材料/会议纪要/方案转为幻灯片、生成演示稿时使用。 |
PPT
把材料变成可演示的 .pptx。先定调,再出稿,再验收 —— 不要一口气把整份 deck 丢出去。
资源
references/design_principles.md—— 画布尺寸 + 字号/配色/留白/字数预算等硬规则references/layouts.md—— 9 种版式的 python-pptx 起手代码 + 安全区/越界保护 +apply_brand品牌条references/icons.md—— 业务图标两层:Iconify (在线/本地缓存) / unicode 字形兜底assets/icons/—— 本地图标缓存 (Iconify 拉过的图存这,见INDEX.md推荐清单)- 素材摄取: 用
markitdownCLI 把 PDF/DOCX/PPTX/XLSX/HTML/URL 转干净 Markdown,统一落到<task_dir>/source/<name>.md(同 working_dir 多 task 共享 source 池) scripts/fetch_icon.py—— 从 Iconify CDN 拉 SVG/PNG (染主题色,缓存本地)scripts/render_icon.py—— unicode 字形 → 透明 PNG (Iconify 没有时兜底)scripts/quality_check.py—— 产物 .pptx 验收 (越界 / 文本溢出 / 颜色一致)
默认主题 — 商务红 (硬约束)
主色 #C00000 / 辅色 #E15554 / 强调色 #FFC107。
⛔ 不允许擅自换色。除非满足以下任一条件,否则 spec 必须填这套红色:
- 用户在请求里明确点名其它配色 (例:"做成蓝色"、"用我们公司的紫色")
- 用户提供素材里有明确的 brand guideline / 配色卡
禁止的自我合理化(都属违规):
- "这个场景蓝色更专业" / "学术汇报红色不合适" / "财务用蓝更稳重"
- "我觉得 XX 主题更适合"
要换色,先问用户,不要在 spec 里塞自己的偏好。其它备选见 design_principles.md §2。
两阶段工作流
阶段一: 策略 (Strategist) — 八条对齐
产物:task 级 spec 文件 —— 整个 deck 的"宪法",阶段二每页前都要重读。文件路径按 system prompt 的《task 级「宪法」文件命名约定》:
<task_dir>/<today>-<task_short_id>-<task_name>.spec.md
<today> / <task_short_id> / <task_name> 用 system prompt 注入的实际值替换。
0. 先检测已有 spec:
glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最大者作 current
(按 short_id 主锚,name 部分不参与匹配 — 用户改过 task name 时旧文件仍能定位)
- 有 current(当前 task 已有 spec) → 展示给用户,问「沿用进阶段二 / 重定调(以 today 写新版,旧版保留)」,⛔ BLOCKING 等用户决定
- 仅有其它 task 的(
*-<别的 short_id>-*.spec.md)→ 不当 current 用,继续走下面流程 - 完全没有 → 直接走下面流程
按下表一次性给出推荐方案,然后 ⛔ BLOCKING:等用户确认/修改后才能进阶段二。不要一条一条问。
| # | 项 | 默认值 |
|---|---|---|
| 1 | 画布 | 16:9 (13.33×7.5 in) |
| 2 | 页数 | 封面 + 5-8 页正文 + 尾页(Q&A) = 共 7-10 页。封面 / 尾页强制必有,不在 5-8 页预算里 |
| 3 | 受众 | 看材料推断:领导汇报 / 同行评审 / 客户 pitch |
| 4 | 风格 | 现代简约 (白底 + 细线 + 留白) |
| 5 | 配色 | 商务红 #C00000 #E15554 #FFC107 (见上"默认主题") |
| 6 | 字体 | 微软雅黑 + Arial |
| 7 | 图标 | Iconify tabler 集 (描边商务图标,主色染色;fetch_icon.py 拉到 assets/icons/ 缓存) |
| 8 | 图表 | 数据 ≥ 3 个点的页用 matplotlib 配图 |
把这 8 项写进上面那个 task 级 spec 文件,以表格形式给用户预览,问一句"按这个开干?"。spec 写定后不再改(要改就走 §0 的「重定调」分支,以 today 为前缀写新版,旧版保留)。
阶段二: 执行 (Executor) — 逐页生成
每页前 必须 read 一次 current spec(按 §0 的 glob 规则拿到的字典序最大那份),只用里面定的颜色/字体/图标 —— 不允许凭记忆或临时发挥。这条规则是为了对抗长 deck 中的上下文漂移。
每页流程:
- 读 current spec(即使刚读过)
- 图标先于版式: 这一页要用什么概念图标? 先
glob <skill_dir>/assets/icons/看本地有没有 (<skill_dir>是load_skill头里的绝对路径),没有就python <skill_dir>/scripts/fetch_icon.py <name> --set tabler --color C00000 --size 128 -o <skill_dir>/assets/icons/...拉一个;add_picture嵌入。几何形状(圆点/徽章/装饰线)不算图标,走 layouts.md helper 即可 - 写一个
run_pythonblock,用 python-pptx 添加这一页 (载入已有 .pptx → append slide → save) - 报这一页:版式、标题、要点条数、用了哪些图标
- 用户确认 / 微调后再下一页
- 用户确认了实质改动(改版式 / 换图标 / 改文案要点 / 增删页 / 调主色)后,追加一行到
<task_dir>/REVISIONS.md—— 见 §修订日志
为什么逐页? 一次性出全 deck 中途改方向就要全推翻;逐页能让用户在第 2 页就发现问题。
例外: 用户明确说"别问,直接全做了" —— 一次跑完,但跑完必须用 quality_check.py 验收。
阶段三: 验收
python <skill_dir>/scripts/quality_check.py <task_dir>/<output.pptx> --spec <task_dir>/<today>-<task_short_id>-<task_name>.spec.md
不通过的项,回头 edit 对应页。
设计原则 (硬规则速查)
- 每页一个核心信息: 一页讲一件事,塞两件就拆页
- bullet ≤ 5 条: 超过就拆页或改成图表/双栏
- 正文不写完整段落: 列要点;长句留给演讲者口述
- 数据 ≥ 3 个点应有图表: 用 matplotlib 生成 .png 嵌入
- 中文标题 ≤ 30 字
- 配色三色封顶: 主 + 辅 + 强调,其他用灰阶
- 少用大色块,多用细线 + 图标 + 留白
- 图标走 MSO_SHAPE: 矢量、可编辑;复杂图标走
render_icon.py - Shape 不能越界:
layouts.md起手代码用assert_inside在生成时即报错 - 字数按预算来: 写 bullet 前查
design_principles.md §4.1字数预算表 - 详细规则见
references/design_principles.md
工作目录约定
下文 <task_dir> = system prompt 里「task_dir」给的绝对路径(形如 …/workspace/tasks/<task_id>/)。所有产物都写到 task_dir 下,不要写到 cwd / skills/ / repo 根;assets/icons/ 是 skill 自带的图标缓存,继续走 skills/ppt/assets/icons/。
<task_dir>/
├── source/ # markitdown 转出的素材(同 working_dir 多 task 共享;用 markitdown -o <task_dir>/source/<name>.md)
├── <today>-<task_short_id>-<task_name>.spec.md # 八条对齐落定,task 级宪法;命名见 system prompt 约定;按 short_id 主锚,重定调时写新日期,旧版保留
├── slides/ # 各页用到的图片素材 (chart_p3.png 等),多 task 时文件名前缀区分
├── REVISIONS.md # 修订日志:每次卡点用户确认的实质改动,见 §修订日志
└── <topic>.pptx # 最终产物 (按主题命名,多 task 时主题必须不同)
修订日志 (REVISIONS.md)
<task_dir>/REVISIONS.md 是产物迭代过程的紧凑可读 changelog。spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加) —— 两份独立但互参,后期 review / 复盘 / 跨周回看"上周这页为啥改成这样"靠这份。
何时记 / 何时不记
| 情形 | 记? |
|---|---|
| 用户确认改版式 / 主色 / 字体方向 | ✅ 必记 |
| 用户确认换 / 增 / 删页 / 关键图标 / 数据图表 | ✅ 必记 |
| 用户确认改文案要点 / 核心信息 / 受众定位 | ✅ 必记 |
| 自查阶段发现版式越界 / 颜色不一致后的修正 | ✅ 必记(说明触发 quality_check 项) |
| 页首次起草(从 0 加出来) | ❌ 不记(初稿不是改动) |
| 字号 / 间距 / 对齐微调 | ❌ 不记 |
| 模型自己改改撤撤、用户没明确确认 | ❌ 不记 |
拿不准 → 倾向不记。
REVISIONS.md是"用户与 LLM 共同沉淀的实质决策",不是流水账(那是对话历史的事)。
格式
文件首次创建时写头(只写一次):
# 修订日志
> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
每次记一笔追加在头注释之后、最新一笔的顶部(一行 = 一次改动):
- `<YYYY-MM-DD HH:MM>` | <第 N 页 / spec §X> | <一句话改了什么> — <为什么>
实例
- `2026-03-12 16:20` | 第 5 页 | 版式从 layouts.md "两栏文+图"改为"单栏图占主体" — 用户反馈原版式右侧文字太挤,核心数据需放大
- `2026-03-12 14:05` | 第 3 页 | 删 chart 图,换成 3 个 KPI 数字块 — 数据点只有 3 个,bar chart 浪费版面
- `2026-03-11 10:30` | spec §5 配色 | 主色 `#C00000` → `#1F4E79` — 用户给的品牌指南要求蓝色,商务红默认被覆盖
操作
每次卡点用户确认后,用 edit 在头注释之后插入新一行(不要 append 到文件末尾 —— 倒序读才能秒看最新)。文件不存在就 write 创建带头注释的新文件。
反模式
- 用户没给材料就开始硬编内容
- 八条没对齐就跑 python-pptx
- 基于"场景判断"自行换配色(见上"默认主题"违规清单)
- 缺封面 / 缺尾页(Q&A) —— 两端都是强制项,不算在正文页数预算内
- 裸白纸版式 —— 所有版式起手都必须
apply_brand(slide, kind),见 layouts.md - 业务概念页只用几何形状 —— 比如"战略目标"页只摆圆点 bullet 没有
target图标,视觉太单薄;按 §阶段二第 2 步先拉 Iconify 图标再做页 - 一个
run_python出整 deck (中途改方向就要全推翻) - 跑完不做
quality_check.py就交付 - 起名
output.pptx/untitled.pptx—— 务必按主题给文件名
输出
完成后告诉用户:文件路径、页数、用到的版式列表、是否有未满足的 spec 项。问一句要不要再改。