Gamma：先确认讲什么，再决定每张卡片怎么改
Gamma 是制作演示文稿、文档等视觉内容的工具。需要汇报工作或解释方案的人，可以从笔记开始生成初稿，再用对话和手动编辑整理成可交付的作品。
先尝试拆解问题、设计和实现，再展开思路，检查状态、边界与取舍，并设计验证用例。思路提供分析路径，不给出完整实现。
01
代码思考进阶
拒绝过期修改，避免部分写入
实现一个教学用的修改审阅状态模块，语言不限。它不需要调用真实 AI，也不模拟 Gamma 的内部系统。
- 输入。 文档包含整数版本 v 和按 ID 保存的元素。生成请求带 requestId、baseVersion 和目标元素 ID；返回值是一整组候选修改。快照是请求发出时的文档副本，之后不随文档变化。
- 规则。 同时最多一个待处理请求。生成结果只进入预览，不直接改文档。接受时，当前版本必须仍等于 baseVersion，且所有目标仍存在，才能一次应用整组并把版本加一。手动编辑也加一。版本不符或目标缺失时整组拒绝，不做部分应用。
- 取消与重复。 取消后到达的结果不可重新打开预览；同一 requestId 的重复回调或重复接受不能多次写入。同一请求的不同回调内容应报告冲突，不静默替换。先前已结束的请求结果不能影响新请求。
- 小例子。 v=4 时请求 R 修改 A、B；等待中用户手动改 A，版本变成 5；R 返回后用户点接受。手工写出文档、预览和请求的最终状态，再考虑取消 R 后开始 S、R 又返回的情况。
- 交付。 给出状态定义与转移表、模块接口、错误分类，以及正常接受、手动冲突、目标缺失、取消后返回、重复回调五条事件轨迹。每条写明预期文档版本和是否产生写入。
查看思路
- 把文档状态和请求状态分开，明确“结果已到达”与“已接受”之间仍有用户决定。
- 找出唯一允许写入的转移，并检查版本和目标完整性；任何失败都不能留下半组修改。
- 推演 v=4→手动编辑至 5 的例子，判断保存候选结果是否等于允许它覆盖当前文档。
- 为取消、完成和重复事件保留足够的身份信息。比较同 ID 同内容重放与同 ID 不同内容冲突，避免只按当前活动请求判断。
- 用事件轨迹验证“每个请求最多写入一次”和“过期结果不能覆盖新文档”。不要求实现网络重试或跨设备协同。