遇到大任务如果做到一半发现之前的判断失误需要重新考虑，这些要推倒重来吗还是更新一下计划文档反复改，怎么防止再接下来的修改中漏问题和把原来改好的问题又改错了

先回答核心那一问：判断失误要不要推倒重来，取决于错误的影响面，而不是取决于你觉得有多挫败。 一、先分清两种错误 方向性错误：目标或方案本身错了。比如你本来打算把整个 src 迁到 TS，做到一半发现核心依赖库根本不提供类型定义、社区方案也不成熟。这种错误的影响面是"所有还没做的工作"，继续做下去全是白费。 实现性错误：方向没问题，某一步做错了。比如迁移顺序错了，先做了有依赖的组件导致循环引用。这种只要回滚那一步就行。 判断标准很干脆：问一句"已经做完且验收过的部分，还有效吗？" 有效 → 局部回滚，继续走。 无效 → 停，重新规划。 二、推倒的是计划，不是文档结构 文档永远不用推倒重来。因为 PROGRESS.md 本来就是覆盖式的，它只描述"此刻"，改它就是正常更新，不是"反复改"。真正要推倒的是没做完的工作。 具体做法是三步，顺序别乱： 第一步，先冻结。发现判断错了，立刻停止动手，不要在错误认知下继续写代码。 第二步，在 LOG.md 追加一条，写清错误本身。格式大致是： 09-09 02:10 发现原方案不可行：xxx 库无类型定义，社区没有成熟 @types。影响面：已完成的 api、hooks 不受影响；components 目录 12 个文件的迁移全部作废。证据：官方 issue #1234 明确说明不提供。 这一步是防你自己以后忘记为什么改方案。没有这条记录，三天后新会话看到方案变了会以为是别人瞎改的。 第三步，重写 PROGRESS.md 的"方案"和"下一步"字段，已完成部分原样保留。 三、为什么这样不会漏 关键在于 PROGRESS.md 里要有三类字段，缺一类就会漏： 已完成且已验证：不是写"改了 Button.tsx"，而是写"改了 Button.tsx，跑了单测通过、手动点了三种状态正常"。验收方式是这段的全部价值，没有它新会话会以为改完就等于好了。 约束与不变量：不动 utils、不升级依赖、外部 API 行为不变。每次动手前先读这一节。这是防"改好又改错"的第一道闸——大部分回退都是因为不知道有个约束存在。 未验证项：明确列出来，比如"还没跑端到端测试""只在 Node 20 上试过，没试 18"。 四、防回退，最有效的手段是测试而不是文档 这点必须说清楚，文档管不了回退。 假设你迁移到一半发现 X 组件之前修过的空值 bug 又被改回来了。靠人读文档是发现不了的，因为文档写的是"当前状态"，它不检查。能发现的是回归验证。 所以规则定成：每完成一个小单元，跑一遍最小验证集，而不是只跑新改的那部分。最小验证集就是之前所有已验收项的验证命令，能自动化就自动化，跑一次几十秒。这样任何回退当场暴露。 如果暂时没有测试，退一步的做法是留可执行的验收清单，每条是能手动复现的动作，比如"打开 /settings，把语言切成英文再切回来，确认不刷新页面"。写在 PROGRESS.md 里，每阶段过一遍。 五、一次只改一件事 这条是防"分不清哪个改动导致回退"的。如果你在同一次修改里既改了迁移方案又顺手修了个小 bug 又调整了目录结构，出了问题你没法二分定位。 所以给 Agent 的指令里可以写死： 一次改动只解决一个问题，改完先跑验证再进入下一个。 如果必须同时改，先拆成两个提交，各自可独立回滚。 任何回滚都要在 LOG.md 记一条，写清回滚了什么、为什么。 六、给新会话的接续指令 发现方案变更后，新会话的第一句话建议是： 读 PROGRESS.md。注意方案在 09-09 变更过，原因看 LOG.md 最后 3 条。从下一步继续，动手前先确认约束一节。 这样它不会因为看到方案和昨天的日志不一致就卡住，也不会重蹈覆辙。 七、一句话总结 文档只覆盖不推倒，工作按影响面决定回滚范围；漏问题靠固定更新时机和未验证项清单，改回退靠回归验证和一次一改。判断失误不可怕，可怕的是在错的方向上继续补文档。 如果你说的是迁移那类具体场景，可以把你现在的 PROGRESS.md 结构发我，我帮你看看字段够不够。