回看一次 AI 协作，
找到下次怎样说。

先选一段具体经历。

不用先复盘整周。挑一次你觉得“改了好几轮”或“需要提醒第二遍”的任务，找出最初要求、一次交付和后续纠正。记录太多时，先只看一个问题。

下面以“页面交付时漏了手机布局”为教学示例，说明怎么回顾；它不是客户案例或效果统计。

把发生的事和你的解释分开。

先写事实：最初要求包含手机布局；第一次交付只展示了桌面；提醒后才补手机检查。再提出可能的解释：验收范围没有在交付前被逐项核对。

不要直接下结论说“AI 不理解我”。也可能是要求藏在较早的消息里、材料不足，或那次结果没有提供验证证据。回到原文确认。

下一次，试一句能检查的话。

针对这个问题，可以在原任务里这样说：

请先列出这次任务已有的要求和验收标准，再逐条对照当前结果。能验证的请实际检查；无法验证的先标出来，未满足的继续修正。

如果换到新对话，要一并提供原要求和当前结果。目标是让双方对齐同一份标准，而不是把一句话重复粘贴到所有任务。

看下一次结果，再决定是否保留。

检查下一次交付是否覆盖了手机布局、是否附上实际检查，以及是否仍要再次提醒同一项。只说“已完成”不算验证，测试没跑也不能当作通过。

若仍反复遗漏，把任务拆小、补充样例或缩小验收范围。不同问题需要不同表达；一次改善不能证明这句话普遍有效。

Peilo 帮你找到值得回查的片段。

电脑端的项目对话分布和思维轨迹可以帮助定位协作片段。主动生成 AI 洞察时，再把记录中的事实、可能的问题和下次说法连起来。

图表里的探索或校验占比不能单独证明返工。你也可以不用 Peilo，直接按上面的步骤回顾原对话。

完整例子：把反复修改变成下一次的检查。

以下为教学示例，不是真实客户效果。原要求是“手机上报名按钮清楚可用”；首次交付只检查了桌面版。用户指出手机按钮被遮挡，下一次就把“在 390px 宽度下检查按钮无遮挡、可点击”写进交付条件。回顾时回到原对话，区分原要求、首次结果、纠正和待验证结果。

下一次实际交付是否改善，仍需在手机视口检查，不能把一句建议当成已改善的证据。对话分类和次数也不能替代结果验收。