AI 文档和 PPT 生成后，不要用“再好一点”这类模糊要求反复重生。更有效的方法是先核对目标与事实，再分别处理结构、论据、文字和视觉，最后由责任人确认。AI 初稿的价值是加快迭代起点，不是取代编辑与审阅。
一、修改前先确认交付标准
1. 把目标写成可判断的要求
文档是用于审批、决策还是培训，PPT 是供演讲还是独立阅读，会直接改变内容密度与结构。修改前至少需要确认读者、使用场景、核心结论和最终负责人。
2. 区分必须正确和可以优化
必须正确的内容包括数据、产品名、时间、人名、引用和结论依据；可以优化的内容则包括句式、标题、页面节奏与视觉风格。前者应建立校对清单，后者可通过反馈逐步收敛。
- 事实类问题要指出原始依据和正确值。
- 结构类问题要说明哪个部分应前置、合并或删除。
- 表达类问题要提供期望语气和具体反例。
二、把反馈拆成四轮迭代
| 迭代轮次 | 主要问题 | 完成标准 |
|---|---|---|
| 目标轮 | 是否真正回答读者的问题 | 一句话能说清核心结论 |
| 事实轮 | 数据、引用、范围和时间是否正确 | 关键断言都有依据 |
| 结构轮 | 章节或页面是否服务阅读与演讲 | 每部分只承担一个主要任务 |
| 表达轮 | 文字、图表和视觉是否清晰一致 | 内容可读且符合使用场景 |
每轮反馈都应引用具体位置，例如“第三部分第二段”或“第 6 页图表”，并用“当前问题—修改要求—验收条件”表达。这能避免解决一个问题时破坏已确认的内容。
文档与 PPT 的修改重点并不完全相同。文档要检查标题层级、段落逻辑、引用位置和长文阅读节奏；PPT 还要检查每页承担的任务、讲述顺序、图表与口径、字号和演示时长。一次只解决一个层级的问题，先确认结论与事实，再调结构和视觉，能减少整稿反复重排。
如果同一轮收到相互冲突的意见，不要把两种方向都塞进成稿。先由最终负责人确认服务哪类读者、保留哪个结论，再要求 AI 按已裁决方向修改。每轮完成后还应保留一份简短修改记录，说明改了什么、依据是什么、哪些问题尚未确认，便于下一位审阅者接手。
三、让修改结果进入团队协作
一份文档只在个人与 AI 之间反复修改，很容易丢失责任边界。进入团队审阅前，应该保留可查看版本，标记待确认事实，并为不同审阅者分配问题。
建议按以下顺序完成审阅：
- 内容负责人确认结论、事实和删减边界。
- 数据或产品负责人校对数字、功能与适用范围。
- 设计或品牌负责人检查视觉、用词与对外表达。
- 最终负责人处理冲突意见，确认发布版本。
进入协作后，反馈也要区分“必须修改”“建议优化”和“需要补证”。必须修改项直接关联事实、合规或交付要求；建议优化项不应阻塞使用；需要补证项则暂不写成确定结论。反馈必须能够定位、执行和验收，只写个人感受会让修改轮次不断增加。
每次提交新版本时，最好同时附上已解决项、仍待确认项和本轮未改动范围。这样团队能在同一版本上继续评论，避免有人审阅旧稿、有人修改新稿。对于数据与产品口径，还应保留来源日期或链接，便于最终发布前再次核对。审阅中新增的要求若超出原目标，应进入下一版本，而不是在当前版本不断扩张范围。
修改的停止条件应该事先定义。当核心事实全部核对、必要审阅人完成确认、交付格式可用时，就应停止无限润色。
四、豆包进飞书如何承接反馈与修改
给企业用的豆包可根据自然语言生成文档、PPT 和表格等办公成果，并在用户反馈后继续修改。员工可以在独立 App 中发起创作与迭代，也可以通过飞书内 Agent 衔接当前工作；二者是同一产品的两种使用形态。成果可以保存或分享到飞书，由团队按权限查看、评论和编辑。
使用时可先给出目标、参考材料和读者，再按“目标—事实—结构—表达”的顺序逐轮反馈。具体格式和编辑范围应以实际交付结果为准，关键事实和发布质量仍由相关负责人确认。
