第 8 卷

哪个文件夹里，请你去理解这个文件。这样既节省时间，也能减少不必

要的上下文消耗。

第二步：不要流水账，要按业务问题重组

第一轮摘要出来之后，还不能直接拿给老板看。做过项目的人都知道，

如果摘要里没有明确结论，只是按时间线把材料复述一遍，还夹着一些

没确认的信息，它就不是一份合格的汇报。

所以第二步，我们要明确告诉 Codex：不要按照时间线整理，而是按

照业务问题分类。这里可以继续打开计划模式，让它先给出整理计划，

再执行。

提示词可以这样写：

不要按照时间线来整理。按照业务问题进行分类，包括当前进展、关

键决策、阻塞点和下一步行动。重要结论后面请注明来源文件。如果

发现不同文件之间有矛盾，请单独列出来。

Codex 会先给出汇报摘要整理计划。它会说明输出一个汇报摘要

Markdown 文件，结构固定为当前进展、关键决策、阻塞点、下一步

行动、跨文件矛盾和重要结论；重要结论后面用括号标注来源；同时明

确不移动、不重命名原始文件。

这一步很重要，我们不是让 AI“自由发挥写一份漂亮稿子”，而是先把

汇报结构、来源标注和风险边界讲清楚，再让它执行。

执行完成后，右侧输出区会出现新增文件，比如汇报摘要和整理日志。

我们先看汇报摘要。

它会把当前进展写出来：首场活动已经完成，报名结果超过预期。原始

目标是 80 人，后来目标上调到 120 人，最终报名 126 人，去重后报名

123 人；这些信息分别来自会议纪要、报名数据表和邮件截图。

它还会主动整理预算和风险：预算实际发生 9200 元，比 8000 元预算

口径超出 1200 元；供应商状态不能写成“已签约”，因为截图只能证

明报价和有效期；二次活动只能写成候选档期，不能直接汇报成“已定

档”。

最有价值的是跨文件矛盾。比如方案V3仍然沿用8000元预算，但Excel

里的预算跟踪和复盘数据都显示为 9200 元。再比如供应商状态在不同

材料里的表述不一致。这些内容未必都要原封不动汇报给老板，但它们

一定是你汇报前要自己确认的问题。

这就避免了一种很常见的情况：你做完汇报，领导一追问细节，才发现

预算口径、签约状态或数据来源没有对齐。流水账汇报看起来材料很多，

但背后没有判断；按业务问题整理，才真正体现你对项目的理解。

第三步：把摘要扩成汇报包

摘要只是第一步。真实汇报里，老板可能要看 PPT，你自己上去讲也需

要演讲提纲，同时还要知道哪些信息必须补齐。

所以第三步，我们基于刚才的汇报摘要继续让 Codex 扩展：

在这个汇报摘要的基础上，帮我出一份 PPT 大纲，一份演讲提纲和一

份补充材料清单。

这个任务会完成得很快，因为 Codex 前面已经读过整个文件夹，也已

经生成过汇报摘要。现在它只是把同一套信息换成不同的交付形式：

PPT 需要大纲，演讲需要口播逻辑，补充材料清单则帮助你判断正式汇

报前还差什么。

我们先看 PPT 大纲。它建议正文 7 页、附录 1 页，并且给出一条很清

楚的汇报主线：先讲报名超过预期，说明活动模型有需求，用户反馈支

持二次举办；然后再主动解释预算超支。

这个顺序很重要。你不能一上来就说“领导，我们这次活动预算超支了”，

那领导马上会进入负面判断。更好的顺序是先讲结果成立：目标从 80

人上调到 120 人，最终报名 126 人，说明需求验证成立；再解释为什

么超支、超在哪里、是否可控。

PPT 大纲里还会给出每一页的标题、核心信息、呈现方式、渠道建议和

讲述重点。拿到这个大纲之后，你可以继续交给自己习惯的 PPT 工具

生成页面，也可以自己照着做。

再看演讲提纲。它会建议你不要按照会议过程去讲，而是按照业务问题

来讲：结果是什么，为什么成立，哪里超支，哪里还不能下结论，下一