学习目标
一张可在新对话核对的接续卡，区分有效决定和待验证假设。
适用场景
你与 AI 已决定列表保留单列，换对话后它又改成瀑布流，还把未运行的测试写成通过。问题往往不是提示词不够长，而是决定、现状和下一步混在聊天历史里。
准备条件
- 当前需求与实际代码版本可定位。
- 知道哪些是你已确认的决定，哪些只是 AI 提过的方案。
操作步骤
保留四种事实，删掉过程流水账
接续卡写目标、有效决定、实际完成情况和下一步。尝试过但放弃的方案只保留原因；源码、测试和发布版本用可核对位置引用。不要把“计划上线”写成“已上线”，也不把长聊天全文当作可靠规格。
可直接填写的接续卡# 当前任务 目标：让资料列表在手机上可读，保留单列。 已确认：列表结构不改；长标题可换行；时间是次要信息。 非目标：推荐算法、新组件库。 实际版本：填写分支、提交与未提交改动归属。 已完成：列实际文件与行为，不写计划。 已验证：检查命令/人工路径、版本、结果与证据位置。 未验证：例如 iOS Safari；不得写成通过。 待决定：仅列会影响下一步的业务问题。 下一步：一项有明确完成条件的动作。 恢复办法：保留哪些已有改动、哪些可撤回。让新对话先核对现状
把接续卡和相关材料交给 AI，要求先读真实文件与有效决定，指出不一致再继续。已有改动要识别所有权，不能为了得到干净环境删除他人的工作。缓存和旧文档可能落后，核对后更新卡片，不能直接选择更顺手的版本。
需求变化时记录被替代的决定
你明确改成双列，就注明替代了哪条单列决定、原因和影响页面。AI 的建议本身不能覆盖原要求；实现选择与业务范围变更分开写。已确定的细节不必每次重新审批，但影响方向的未知项不能沉默猜测。
变更记录原决定 D2：手机和桌面均单列。 新决定 D3：用户明确要求桌面双列，手机单列。 影响：列表布局、长标题样本、键盘顺序与桌面截图。 保留：排序、数据接口、返回位置。 需重验：受影响视口与导航；无关后台流程不重复重构。交付前逐项对照，而不是只读改动总结
从必需需求出发找实现与证据，再检查所有改动能否归属本轮目标。完全没做的一项不会出现在 diff 中，必须从需求清单发现。技术验证、真实使用反馈和效果观察分别记录；没有后者就不宣称体验已获认可。
常见误区
- 接续卡越长越安全，复制全部日志。
- 保留可行动的事实与证据引用，删去不影响当前判断的过程。
- 只检查修改过的文件，遗漏原需求的一半。
- 从需求向实现追踪，再反查所有改动的必要性。
验收清单
- 新对话可以定位实际版本和工作区状态。
- 有效决定、旧方案、假设有区别。
- 已验证项有证据，未运行保持未验证。
- 需求变化能说明替代关系和受影响验证。
资料与版本
本文为原创方法整理，示例与提示词需按项目调整；不代表真实用户研究或账号执行结果。