PPT 不应该被画出来，
它应该被编译

我很想用一个漂亮的场景开头：某个深夜，我盯着一页 PPT，突然意识到全世界都把对象搞错了。

但证据不允许我这样写。

我能确认的开场，是一条 Git 记录。2026 年 8 月 13 日 20:32:42，仓库里出现首个 commit：feat: bootstrap structured narrative compiler。它能证明第一份可追踪的代码已经进入版本历史，却不能证明灵感在哪一分钟出现，更不能冒充“第一行代码”的时刻。【事实｜receipt_04d48e25a90c】

这恰好是我想记录这段旅程的方式：不为了戏剧性补写记忆，不把 AI 的推断伪装成我的感受；先把收据摊开，再谈我今天如何理解它。

01. brilliant idea：页面也许不是 PPT 的底层对象

传统制作 PPT 的动作，从一开始就在催促你处理页面：新建一页，选择版式，移动文本框，把图表向左挪几个像素。可真正的任务通常不是“得到十二页”，而是让一群特定的人理解一件事、相信一个判断，并在会后做出行动。

于是我提出了一个判断：PPT 的底层对象也许不应该是页面和坐标，而应该是受众、目标、观点、证据和行动。页面只是这些对象在某个场景下的一次投影。【我的判断｜receipt_0487167af83e】

一旦接受这个角度，PPT 就不再只是被“画”出来的文件。它更像一段程序：先声明意图和语义，再经过检查、计算与编译，最后渲染成适合演讲、阅读或复核的界面。

我暂时把中间那层叫作“叙事 IR”——一种介于原始材料与最终界面之间的结构化叙事表示。它不是一句让 AI “帮我做一份高级 PPT”的 prompt，而是一组可以被验证的对象：这份内容给谁看，想改变什么，每个观点由什么证据支持，最后希望对方做什么。

02. 从坐标转向受众、目标、观点、证据和行动

第一版 demo 没有先做首页。它先写了一份 brief：受众是谁、目标是什么、预计讲多久、希望触发什么行动。随后，story 文件把叙事拆成六个语义单元，类型包括 claim、metric、process、comparison 和 action。【事实｜receipt_4356a25e4402｜receipt_b792fea76d6f】

这一步看似只是“把内容写成 JSON”，其实改变了工作的责任边界。

如果内容只存在于页面里，一个数字错了，你不知道它来自哪份表；一段话需要复用，你只能复制粘贴；演讲版要改成长文，常常意味着重新排一遍。如果内容先成为结构化对象，布局可以变化，来源和关系仍然留在原地。

这个判断目前只是设计主张，不是市场结论。项目记录给出的理由是：内容与布局可以解耦；数字和观点能够被追溯、校验和版本化；同一份语义内容可以生成不同阅读方式。【我的判断｜receipt_09ad417426e0】它还没有证明所有 PPT 都应该这样做，也没有证明用户愿意为此改变习惯。

03. AI 没有直接“画一份 PPT”，而是搭了一条 compiler 链

接下来发生的事情，开始有了工程上的收据。

compiler 会读取 brief、story、source catalog 和 CSV，计算输入 SHA-256，然后输出带 compiler version、source 与 units 的 JSON。另一个检查脚本负责确认必填字段、单元 ID、来源引用和数值字段。测试则覆盖页面是否能渲染、是否同时存在“演示 / 阅读”、输入哈希、六个语义单元和 metric provenance。【事实｜receipt_f4b2da22b675｜receipt_e5858f1a2252】

换句话说，AI 的工作不是直接交付一个不可解释的成品，而是协助搭出一条可以重复运行的生产线：

结构化输入 → 确定性检查 → compiler → Web renderer → 自动测试。

其中最小、也最直观的证明，是同一份语义源被投影成两个界面：演示模式可以前后翻页、从侧栏跳转；阅读模式连续展示全部单元和讲者备注。【事实｜receipt_cbd7576bafe2】在这篇文章里，你也能切换“演示 / 阅读”小样，体验同一内容如何适配两种消费方式。

这还不是 PowerPoint 的替代品，但它已经不是聊天窗口里的一段建议。它是一段真实运行、可以失败、可以测试、可以被再次恢复的 Web 交付物。

04. 第一个 demo 为什么还不是产品

真正重要的转折，不是 demo 跑起来，而是我必须把它从“产品”降回“脚手架”。

首个 commit 后 1 小时 53 分，第二个 commit 3ad8e24 校准了仓库的说法：原先被描述为“第一个产品”、状态近似“已接受”的结构化叙事编译器，改为“可替换的脚手架样例”，方向尚未被正式接受。【事实｜receipt_04d48e25a90c｜receipt_08bd091bad56】

这不是代码失败。恰恰相反，作为 demo，它完成了该完成的验证。失败的是我对它身份的描述：做出一个漂亮、完整的样例，很容易让人误以为问题、用户和产品方向都已经被确认。

这是我从这段记录中得到的一个反直觉判断：demo 越完整，越需要主动证明它没有证明什么。

它没有证明真实用户更快完成工作，没有证明输出质量优于 PowerPoint，也没有证明商业价值。项目里的数字被明确标为 illustrative demo data，不代表行业事实或行业基准。【事实｜receipt_334d9252cdf1】所以我不能把示意数据包装成效率提升，更不能把工程完成写成市场验证。

05. 混乱没有消失，它只是需要被放到正确的层

今天回看这段过程，我最警惕的不是 AI 做得慢，而是“AI 看起来一直很忙”。对话很多、算力消耗很多、Agent 一直在运行，会制造一种项目正在高速前进的感觉；可如果没有可打开的交付物、可定位的决策和可恢复的状态，这种忙碌很可能没有留下结果。

这不是我对 8 月 13 日心情的追记。现有证据没有记录我当时兴奋、沮丧还是焦虑。我能确认的是：这是我在 8 月 17 日明确说出的反思，它直接促成了一个新要求——底层 Observer、完整文章和真实网站必须同时出现，任何一项都不能用“以后再做”搪塞。【我的解释｜receipt_2baa053ad6ba】

于是，“完成”被重新定义了。完成不是 AI 回答完；不是仓库里多了很多文件；甚至不是 demo 在我这台机器上跑起来。完成必须留下一条可恢复交付链：来源、事件、决策、代码、测试、版本和可访问结果彼此能重新对上。

06. 从聊天状态转向 Git、决策记录和可恢复项目

8 月 14 日，项目把长期记忆的责任明确交给私有 GitHub main。决策记录写得很直接：聊天、未提交修改、本机文件和 Cloud 临时状态不承担长期记忆职责。【事实｜receipt_8df2d4b8bb02】

这不是因为聊天没有价值。聊天适合探索、提出假设和快速协作；但它很难充当跨设备、跨模型、跨时间的唯一真源。只要项目还依赖“上一段对话里 AI 应该记得”，恢复就只能靠运气。

Git 保存实际状态，PROJECT.md 保存当前阶段与开放问题，决策记录保存“为什么”，测试保存“现在仍然成立吗”。Agent 可以更换，设备可以更换，模型也可以更换；下一次启动时，不必先复述一百轮对话，项目仍能从同一组收据恢复。

这套做法也有代价：没有提交的灵感不会自动成为长期知识，聊天里的聪明回答也不会因为听起来合理就升级成项目事实。遗漏会更明显，记录工作会增加。但我宁愿看见缺口，也不愿让流畅的摘要替我伪造连续性。

07. 真实时间线：20 小时 36 分 30 秒，到底证明了什么

以下时间来自 Git 提交记录，均为 +08:00：

从首个 commit 到 Cloud 验证记录，间隔是 20 小时 36 分 30 秒。【AI 推断｜依据 receipt_04d48e25a90c 的时间戳计算】

这个数字不能证明“不到 24 小时做出了一个产品”。它证明的是更窄、也更有用的事情：从第一份可追踪提交开始，不到 24 小时，项目形成了结构化源、compiler、双视图 Web、测试、版本历史、隔离 clone 恢复和 Cloud 恢复的链路。

所谓“跨设备验证”也需要说清边界：现有收据证明了隔离 clone、Codex Cloud 和 Ubuntu / Windows Actions 记录，并没有记录两台具体实体设备之间的完整操作过程。

08. 我得到了什么，也主动失去了什么

得到的第一样东西，是一个真实垂直切片：结构化语义源可以经过确定性处理，变成两个阅读界面。第二样，是一套更重要的恢复机制：稳定 ID、来源引用、输入哈希、测试、Git 真源和决策记录。它让成果不再只存在于某个模型当时的上下文里。

得到的第三样，是一个更严格的“完成”定义：结果必须可打开，事实必须可回到来源，失败必须留下边界，下一次必须可以恢复。

失去的，首先是一些设计自由。如果未来正式接受这个方向，决策记录列出的条件式取舍包括放弃任意拖拽、像素定位、直接编辑生成物，以及让 renderer 直接读取原始 CSV。【我的判断｜receipt_09ad417426e0】这不是已经生效的产品承诺，而是方向成立时必须正视的代价。

我还失去了一种轻松的叙事方式：不能把首个 commit 写成灵感诞生，不能把 scope correction 渲染成技术灾难，不能用 demo 数字冒充真实效果，也不能声称产品已经确定。故事少了一些戏剧性，却多了一点可信度。

09. 尚未解决的问题

到目前为止，第一款正式产品、首个真实垂直切片、最终技术栈、托管方式和商业模式仍未决定。【事实｜receipt_dfb33839b787】结构化叙事编译器仍然是一个强有力的脚手架样例，而不是已经获批的产品方向。

接下来真正困难的问题，不是再做一个更华丽的页面，而是找到现实中的工作：谁会因为页面坐标而受困？他们愿意把哪些结构交给 compiler，又必须保留哪些自由？可追溯性是否真的比手工编辑更有价值？同一份叙事源能否稳定地产生演讲、长文、互动网页和其他格式，而不牺牲表达质量？

这些问题不能由 demo 自己回答，也不能靠 AI 多聊几轮回答。它们需要真实用户、真实材料、真实取舍和新的收据。

10. 下一段旅程

这篇文章本身，是下一次实验的第一个交付物。它不是从一堆文件手工拼出的故事：Observer 先把项目注册为独立 namespace，把 Git、项目记录和当前口述分成 Source、Evidence 和 Event，再生成一个只属于这个项目的 Context Pack。事实、我的解释和 AI 推断被物理分开；另一个合成项目里放着不会发布的 canary，普通查询无法把它带进文章。

然后，网站只接收经审核的静态投影，不连接私有账本。

这还不是终点。它只证明了一件小但关键的事：AI 可以不只是制造更多上下文，也可以帮助我们把上下文变成一条可验证、可恢复、可公开解释的交付链。

如果你也在用 AI 做项目，却常常发现“大家都很忙，结果却没有留下”，欢迎进入下一段旅程。我会继续公开那些成功的、失败的、被校准的和仍然没有答案的部分——直到 brilliant ideas 不再只停留在对话里。

证据与边界说明

• 本文事实来自 Observer Context Pack ctx_a06bbd256eac2779，哈希为 a06bbd…fdf7。
• 【事实】 来自 Git 或项目正式记录；【我的判断 / 我的解释】 是用户立场；【AI 推断】 是基于时间戳等证据的计算或归纳。
• 文中所有 demo 数字均不作为行业事实、用户成效或商业验证。
• 现有资料没有记录 2026-08-13 的个人情绪、金钱、睡眠、关系或职业损失，因此本文没有补写这些情节。
• 结构化叙事编译器仍是脚手架样例，不是已确认产品。