Poe活动复盘提示词精选：AI修改理由生成秘诀

做活动复盘，最忌文档流于形式，成为缺乏论证的表扬稿。下面这套方法，能将松散初稿转化为团队可复用的核心资产。假设你手头已有一份活动复盘原文；若暂无，可用自身案例先行演练。

步骤一：向AI下达带“归因验证”的修改指令

打开常用AI工具（如Claude-3.5-Sonnet），粘贴复盘原文后，在下方输入以下提示词。该提示词严格限定输出格式，避免AI自由发挥。

“请修改这份活动复盘文案。要求：①先指出原文存在的3个具体问题（例如‘第三段结论缺失数据支撑’‘用户反馈未标注来源’）；②再给出修改后的完整文案；③最后用编号列表逐条对应说明每处修改理由——必须写清‘原文何处不妥’及‘修改后如何解决’。不得使用‘更专业’‘更清晰’等空泛表述，需紧扣复盘的核心要求：归因可验证、动作可复用、结论有依据。”

步骤二：用约束条件锁定修改边界

在上段提示词后紧接此句，明确告知AI修改红线。该约束防止AI为追求逻辑自洽而虚构细节，确保修改理由真实可追溯——这是“归因可验证”的关键。

“注意：不新增未发生的动作、不虚构数据、不改变原始结论方向。所有修改必须基于你提供的事实信息展开推演。”

这段约束常被忽略，却是整条流程的稳定器。若不添加，AI极易为迎合结构完整性，凭空插入不存在的用户访谈记录或数据来源，后续向团队汇报时会造成被动。

步骤三：按流程验证AI输出的有效性

收到AI回复后，先花三分钟快速核查以下三个节点：

第一步：确认AI是否严格按“问题→改文→理由”的三段式结构输出。格式一旦偏离，即说明未准确理解需求。

第二步：逐条审阅AI写的修改理由。若出现“因为复盘需要体现归因深度”这类空话，证明其未进入你的复盘文本。此时需追问：“理由不具体，请引用原文中具体的某一行段落，说明为什么那里需要补充归因链条？”

第三步：将AI列出的修改理由，与其最终改后的文案逐条对照。确保每条理由所指的原文位置真实存在，且改后内容确实解决了对应问题。这一步完成闭环验证，使修改过程可追溯、可复检。

这套流程执行成本不高，但任何环节的跳过多半会导致你将AI的惯性润色误判为专业反馈。真正有效的修改，其理由必须像钉子一样，牢牢锚定在原文的某句话、某个数据或某个逻辑断点上。

--- ### 修改理由逐条说明 1. **关于“目标对象不明确与指令重复”** * **原文不妥**：开头段“你需要让AI...这个操作路径能稳定触发...”同时向用户和AI发令，与后续“步骤一”内容重叠，结构混乱，核心指令被稀释。 * **修改解决**：重新组织开头，从“假设手头有原文”切入，明确用户角色与素材。将操作指令集中至“步骤一”一句说清，消除重复。结构更清晰，指令更聚焦。 2. **关于“假设性案例未经推演且缺乏可追溯性”** * **原文不妥**：“很多用户漏掉这句，结果AI补全了根本没做的用户访谈场次...”为未经推演的假设案例，未与任何原文片段挂钩。在严肃复盘中，这种基于“可能发生”的泛泛之谈无法作为可靠决策依据。 * **修改解决**：删除该假设案例，替换为“若不添加，AI极易为迎合结构完整性，凭空插入不存在的用户访谈记录...”直接指向AI行为底层逻辑（追求逻辑自洽），从“归因可验证”核心原则出发进行警告，风险提示更具普遍性与说服力。 3. **关于“验证环节脱离原文锚点”** * **原文不妥**：最后验证要求“锚定在原文某句话上”，但未提供验证所需的“原文”，导致指令空转，用户无法实操。 * **修改解决**：开头明确“假设手头有一份活动复盘原文”，使整套指令具备可操作前提。最终验证环节第三步改为要求用户“对照修改后的文案”“确保每条理由提到的原文位置确实存在”，将验证动作从抽象指令下沉至可对照执行的检查清单，真正实现闭环。

来源：互联网