T3 Code 撤销改动怎么选：对话回退、文件恢复与检查点
Edit from here 的两个回退选项有什么区别？按 T3 Code v0.1.7 核对文件恢复范围、独立 Worktree 限制和未跟踪文件，给出恢复前后的检查步骤。
Agent 把代码改偏了，想回到上一条指令重新说一遍。在 T3 Code 点 Edit from here 后，会遇到两个容易混淆的选择：Revert and keep changes 和 Revert files too。
想重说需求、保留当前代码，选前者；想让文件也回到那条消息之前，才考虑后者。 恢复文件会影响检查点之后你自己改的内容，不能把它当成“只撤销 Agent 写的几行”。先保存还要保留的工作，再确认目标检查点和目录。
本文按 2026 年 11 月 9 日查询到的最新正式版 T3 Code v0.1.7说明。核验包括正式版文档、恢复源码、近期报告，以及临时 Git 仓库中的只读命令检查；没有在真实项目执行 T3 文件回退，也没有复现下文的完整客户端故障。
先决定：哪部分要回去，哪部分要留下
官方输入框说明给出的行为是：在网页或桌面端，从已发送消息下选择 Edit from here，对话回到这条消息之前。所选消息和后续对话从当前线程及提供方历史中移除，原提示词和附件回到输入框，供你修改后重发。这个操作要求提供方支持回退。
| 你的目标 | 选择或处理方式 | 完成后还要检查什么 |
|---|---|---|
| 需求说错了，但代码里已有值得保留的部分 | Revert and keep changes | 文件保持原样；下一条指令要说明现有改动 |
| 整段尝试都不要，文件也要回到消息之前 | 满足条件后使用 Revert files too | 手工改动、新文件和目标检查点是否符合预期 |
| 只撤销一个文件或其中几行 | 按具体差异定向修改，必要时使用项目的 Git 恢复流程 | 保留其他文件和已确认的修改 |
| 想撤销已推送、部署或外部系统里的操作 | 到对应系统处理 | 对话回退和本地文件恢复都不能替代外部撤销 |
选择保留代码后，Agent 重新看到的是较早的对话，磁盘上却仍有后来的修改。重发时加一句“当前文件保留了上次尝试，请先检查差异”，可以避免它按旧对话假定文件也已还原。
如果你只是要尝试另一种实现，还可以另开独立 Worktree，并带上必要的任务说明。Fork、Side chat 和新 Worktree 的目录关系见并行任务的工作区选择；Fork 不能直接当成文件备份。
为什么提示 File restore requires an isolated worktree
这个提示表示文件恢复没有通过目录独立性检查。v0.1.7 的恢复保护实现要求线程使用 Worktree，并检查其他线程和 Agent 会话是否占用同一目录、其子目录或父目录。
因此，即使另一个任务只改 src/，它与恢复整个工作区仍然重叠。只在项目原目录工作的线程，也不能按独立 Worktree 的条件恢复文件。
检查时看实际目录，不看线程标题：
- 确认当前线程在哪台机器、哪个 Worktree 上运行。
- 查看是否有其他线程、Fork、Side chat 或子任务使用这个目录及其上下级目录。
- 停止仍在写文件的工作，保留各方结果；如果只需要重写需求，使用 Revert and keep changes。
停止或归档另一个线程，不保证文件恢复就会放行。 该版本也检查归档线程保存的路径；只有特定的空闲、没有工具活动的 Side chat 会被跳过。不要为了消掉提示就批量删对话或绕过保护。
近期有两类相关报告：Issue #32429描述 nightly 版本仍展示文件回退选项、点击后才被拒绝；Issue #31865描述已经完成的子任务仍占着父线程的目录记录。两者都由 AI 辅助整理，截至查阅日仍开放、没有回复。前者是界面选择与可执行条件的问题，后者涉及子任务归属，不能统称为“Worktree 失效”。
与子任务相关的 PR #31877尚未合并。本文没有运行该补丁，也不把它作为正式版修复建议。
回退之前，别只保存一份 git diff
先暂停会写这个目录的任务，再在实际 Worktree 目录运行以下只读命令。远程任务就在远程机器检查：
pwd
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git status --short --untracked-files=all
git diff
git diff --cached
git ls-files --others --exclude-standard
它们分别帮助确认位置、分支、提交和不同类型的文件变化。git diff 主要显示未暂存的已跟踪文件变化；git diff --cached 显示已暂存变化；未跟踪文件要从 status 和 ls-files 另外找。
本文在临时仓库放入了已跟踪修改、已暂存新文件、未跟踪笔记和一个被忽略的示例配置，再执行上述检查：未跟踪笔记出现在文件列表里，但不在两份 diff 中；被忽略的配置也不出现在普通 status 中。检查前后工作文件与索引保持一致。这只验证了命令的读取范围，没有调用 T3 恢复。
需要保留的源码，可以审查后提交到当前任务分支，或将具体文件保存到工作区之外的私有备份位置。未跟踪文件要保存实际内容，列出文件名并不等于备份。被忽略的本地配置、数据库文件或嵌套仓库，也要单独确认；不要为了“备份完整”把密钥加入 Git。
一篇近期的 V2EX AI Coding 实践帖建议把修改拆小、及时提交，并在提交说明中写清验证与回滚方法。它是作者的经验，不能证明检查点覆盖完整，但这种做法能留下更容易核对的恢复起点。
检查点能恢复什么，不能靠名字猜
检查点是 T3 保存的工作区状态。v0.1.7 的 Git 恢复实现会从目标快照恢复文件，并清理不在恢复结果中的部分未跟踪文件。恢复范围也包含你在这段时间亲手写的内容。
这里有两个实际区别：
- 目标快照之后才新建的文件，恢复到更早状态时可能被移除。这符合回到过去文件状态的目的。
- 目标快照之前已经存在、却没有被快照保存的文件，不能期待靠这个快照找回来。检查点存在，并不证明每个需要的文件都在里面。
Issue #32360报告了第二种情况：在 Windows 11、Git 2.56.0.windows.4、T3 0.1.7 的条件下，根目录 .gitignore 中的空白 CRLF 行可能使目录被错误判为已忽略，快照因而漏掉未暂存的未跟踪文件。作者分开验证了 Git 判断、暂存选择与恢复命令，明确没有在 T3 客户端走完回退流程。
截至查阅日，该 Issue 仍开放、没有回复；相关 PR #32374未合并。本文没有在 Windows 独立复现，不能据此说所有 Windows 用户都会丢文件，也不能给旧检查点作完整性保证。
若怀疑自己遇到这个条件，可以先在工作区运行只读探测：
git check-ignore --no-index .
git check-ignore -v --no-index .
第一条输出 .，意味着 Git 把该路径判为忽略；第二条用于查看匹配来自哪份文件、哪一行和什么规则。没有匹配时退出码 1 是正常结果，不要把它当成网络或模型错误；-v 还可能展示否定规则，不能只按“有输出”判断。退出码含义也可查 Git 官方说明。
探测只是线索，不能代替检查目标快照。确需调整忽略规则时，先确认它是否本来就该忽略这个目录；改完规则不会补回旧快照漏掉的内容。重要文件先另存，再用无私有数据的临时项目验证新检查点。
回退后，分别验收对话和文件
不要仅凭对话变短或加载提示消失，就开始下一轮大改。根据自己的选择，检查两个结果：
- 选 Revert and keep changes：原提示词已回到输入框，当前文件仍是你决定保留的版本。重发前补充现有代码状态。
- 选 Revert files too：核对目标消息之前的文件内容、该保留的文件、预期移除的新文件，以及手工修改的去向，再运行项目已有的相关检查。
如果操作报错，先重新读 git status 和关键文件，确认当前实际状态，再决定下一步。不要假定所有步骤一定全部完成或全部没动，也不要连续点击回退来试运气。若卡住的是新线程启动前的准备阶段，应改查 Preparing workspace 的命令与 Action，那是另一条处理路径。
另外，官方差异说明提醒：一轮对话的文件列表只展示该轮自己的工作，可能省略 pull、merge 或 rebase 带入的文件；文件恢复仍返回完整的已保存工作区。“这轮只列了两个文件”不足以限定恢复范围。 要看完整分支交付，还需结合分支比较和未提交变化。
外部操作和模型请求，要到原记录里核对
对话回退不会撤销外部动作，也不会清除提供方单独保存的记忆。已经推送的提交、执行过的数据库变更、发出的通知，都要按各自系统的流程处理。本地文件恢复也不会把已发出的模型请求从服务记录里抹掉。
如果你通过 Nbility 使用模型，先按接入基础确认实际 API 入口，再到对应服务查请求。T3 界面估算与实际费用的核对方法见 Usage 与账单说明；重新发送任务可能产生新的调用，不能把“回退后重试”理解为自动撤销上一轮费用。
下次要撤销时，先写清一句话：我想回到哪条消息之前，哪些文件必须留下，哪些外部动作已经发生。 有了这三个答案，再选回退方式，恢复之后也更容易判断是否做对了。
