过去一年，AI 写周报、写方案、写大纲已经相当熟练。但真正拿 AI 出过 PPT 的人，大概率都踩过同一批坑：HTML 转 PPT 必定跑版、Markdown 导出排版失控、AI 生成的幻灯片内容堆砌毫无视觉层次——最终还得手动调两小时才能交出去。
核心矛盾很清晰：AI 擅长生成语义内容，但不擅长生成具备交付级排版和交互的办公文档。 Vibe Coding 让开发者用自然语言直接产出可运行代码，跳过了"写伪代码再翻译"的中间步骤；办公场景缺的就是同样的东西——从意图直达可交付文档，中间不经过一堆格式修补。
OfficeDex（GitHub: officecli/officedex）就是在这个方向上做的尝试。它把自己定位为 VibeOfficing 平台，思路和 Vibe Coding 对齐：你描述意图，平台直接产出结构完整、排版可控的 Office 文档。
HTML 转 PPT 为什么总是跑版
大多数 AI 生成 PPT 的工具走的是这条链路：
用户意图 → LLM 生成 HTML/Markdown → 转换器导出 PPTX
跑版不是偶然，而是结构性问题。HTML 的排版模型（CSS Box Model、Flexbox、Grid）和 PPTX 的排版模型（DrawingML、Slide Layout、Placeholder）是两套完全不同的体系。CSS 里的 margin: auto 居中在 PPTX 里没有对应概念；HTML 的流式布局在 PPTX 里是绝对定位。转换器只能做近似映射，结果就是每个元素的位置都偏一点，累积起来整页失控。
Markdown 转 PPT 同理。Markdown 只有语义层级（h1/h2/p），没有视觉层级（字号/间距/配色/版式）。转换器只能硬套模板，内容一多就挤成一团。
OfficeDex 的做法是跳过 HTML/Markdown 中间层，直接操作 PPTX 的原生结构：
用户意图 → LLM 生成结构化描述 → OfficeDex 直接构建 PPTX 对象
这不是"转换"，而是"构建"——从 Slide Layout 到 Placeholder 到 DrawingML Shape，每一步都落在 PPTX 格式的原生语义上，不存在跨模型映射的精度损失。
从意图到可交付文档的工作流
OfficeDex 的核心流程可以拆成三步：
第一步：意图解析。 你给一段自然语言描述，平台解析出文档类型（PPT/Word/Excel）、内容结构（几页、每页什么角色）、视觉风格（配色、字体、版式偏好）。
第二步：结构化生成。 平台根据解析结果，直接构建 Office 文档的原生对象树。PPTX 里一个 Slide 由 Layout、Placeholder、Shape 组成，每个元素的位置、大小、样式都是 PPTX 格式的精确坐标和属性，不是 HTML 的近似翻译。
第三步：交付级输出。 生成的文档可以直接在 PowerPoint/WPS 里打开，版式和手动做的效果对齐。不需要二次调整间距、字号、对齐方式。
这个流程的关键差异在于：中间产物是结构化描述，不是 HTML。 结构化描述可以精确映射到 PPTX 的每个属性，而 HTML 只能做粗粒度近似。
实际上手：用 OfficeDex CLI 生成一份技术方案 PPT
OfficeDex 提供了 CLI 工具，可以直接在终端里用。以下是一个完整可运行的示例：
安装
# 从 GitHub 仓库安装
pip install git+https://github.com/officecli/officedex.git
# 或者如果已发布到 PyPI
pip install officedex
生成一份技术方案 PPT
# 用自然语言描述意图，直接生成 PPTX
officedex create \
--type pptx \
--intent "技术方案汇报：微服务架构迁移。5页，第1页封面标题+副标题，第2页现状问题列表，第3页架构图示意，第4页迁移步骤时间线，第5页风险与收益对比表。风格：深色背景，科技感，字体偏大。" \
--output migration-plan.pptx
打开 migration-plan.pptx，你会看到每页的版式都落在 PPTX 原生 Placeholder 上——标题居中、内容区有明确的文本框边界、时间线用 Shape 排布而不是 HTML div 的近似映射。
用 Python SDK 批量生成
如果需要批量生成多份文档（比如每周的周报、每个项目的方案），可以用 Python SDK：
from officedex import DocumentBuilder
# 构建一份周报 PPT
builder = DocumentBuilder(doc_type="pptx")
slides = builder.from_intent(
"项目周报：本周完成用户认证模块重构，修复3个P0缺陷，"
"下周计划启动支付模块集成。4页：封面、进展、缺陷列表、下周计划。"
"风格：简洁白底，蓝色强调色。"
)
# 保存
slides.save("weekly-report.pptx")
# 批量生成：为每个项目生成一份方案
projects = [
("用户中心重构", "3页，架构对比+迁移路径+风险"),
("支付系统升级", "4页，现状+目标架构+实施步骤+成本估算"),
("数据平台建设", "5页，背景+技术选型+架构设计+实施计划+预期收益"),
]
for name, desc in projects:
doc = DocumentBuilder(doc_type="pptx").from_intent(
f"技术方案：{name}。{desc}。风格：深色科技感。"
)
doc.save(f"proposal-{name}.pptx")
print(f"✓ 已生成: proposal-{name}.pptx")
自定义模板 + 意意生成
如果你公司有固定的 PPT 模板（比如品牌模板），可以结合模板和意图：
# 用公司模板作为基础，AI 只填充内容
officedex create \
--type pptx \
--template company-brand-template.pptx \
--intent "季度业务复盘：Q3收入增长18%，用户留存率提升5个百分点。3页内容页。" \
--output q3-review.pptx
这样生成的 PPT 既保持公司品牌视觉规范，又跳过了手动填内容的环节。
Vibe Coding 和 VibeOfficing 的对齐与差异
把两个概念放在一起看，对齐点很明显：
| 维度 | Vibe Coding | VibeOfficing |
|---|---|---|
| 输入 | 自然语言描述意图 | 自然语言描述意图 |
| 中间产物 | 结构化代码描述（不是伪代码） | 结构化文档描述（不是 HTML） |
| 输出 | 可运行代码 | 可交付文档 |
| 核心跳过 | "写伪代码再翻译为代码" | "写 HTML 再翻译为 PPTX" |
差异也很重要：
- 代码有编译器和测试做验证。 生成出来的代码能不能跑、跑出来对不对，有明确的判定标准。文档没有这种自动验证——排版好不好看、信息层次是否清晰，目前只能靠人判断。
- 代码的"可运行"是客观的。 文档的"可交付"是主观的——不同场景对交付标准不同，内部周报和客户提案的排版要求差很远。
这意味着 VibeOfficing 平台需要更强的风格控制和模板约束能力，不能只靠 LLM 的自由生成。OfficeDex 的 --template 参数就是在解决这个问题：把主观的视觉规范固化到模板里，AI 只负责内容填充和结构编排。
当前边界和采用建议
OfficeDex 目前还在早期阶段，几个实际边界需要注意：
复杂图表仍然是短板。 PPTX 里的 SmartArt、嵌入式 Excel 图表、动画路径这些复杂对象，结构化描述的覆盖还不完整。如果你的 PPT 重度依赖复杂图表，目前还是需要手动补充。
中文排版的细节控制。 中文字符宽度、行间距、标点挤压这些细节，PPTX 格式本身的支持就比英文复杂。OfficeDex 在这方面的精确度还在迭代。
风格一致性需要模板锁定。 纯意图生成在多页文档里容易出现风格漂移——第1页深色科技感，第3页不知不觉变成白底简洁。用 --template 参数锁定基础风格是更稳妥的做法。
采用建议：
- 先从标准化文档入手。 周报、复盘、常规方案这类格式固定、内容重复的文档，是 VibeOfficing 最容易见效的场景。
- 准备公司模板。 把品牌模板传给
--template，让 AI 在约束范围内填充，比纯意图生成更可控。 - 复杂视觉元素手动补充。 架构图、流程图、数据图表这些需要精确视觉表达的部分，目前建议用 OfficeDex 生成骨架后手动补充。
- 建立意图描述的固定模式。 比如团队统一用"X页，第1页角色，第2页内容类型…"的格式描述意图，减少 LLM 解析的随机性。
Vibe Coding 证明了"从意图直达可运行产物"这条路在代码场景是可行的。VibeOfficing 是同一条路在办公场景的延伸——跳过 HTML 中间层，直接构建原生文档对象。OfficeDex 是这个方向的早期实践，标准化文档场景已经可以试用，复杂视觉场景还需要等后续迭代。