如果你运行很长的会话，迟早会遇到这一刻：

一小时后（或第二天）回来，你连一个简单的问题都回答不了：

改了什么？

对话记录很长。

工具调用分散各处。

如果你在手机上，滚动本身就成了一种失败方式。

所以别再试图“全部读完”。

而是围绕 diff 和工具时间线建立一个小的审阅循环。

本指南就是这个循环。

简要总结

1. 不要重读整个对话记录。从“改了什么”的界面开始：
   • 修改的文件
   • diff
   • 工具调用
2. 如果你的工具支持，使用能统一呈现 Claude Code/Codex/OpenCode 工具调用的工具时间线。
3. 使用轮次结束循环：
   • 快速浏览工具时间线的行
   • 跳转到 diff
   • 决定：保留 / 撤销 / 拆分
4. Happier 是让这件事在移动端更容易的选项之一：对话记录会用专门的工具外观（卡片或活动流）呈现工具调用，点按即可直接跳转到文件或 diff 视图。

问题所在

你想避免的不是工作。

而是没有边界的审阅。

如果你无法快速看到“改了什么”，你要么：

• 相信自己没审阅过的改动
• 要么浪费时间重新梳理上下文

审阅循环需要有边界。

常见做法及其权衡

• 从头到尾读对话记录：短的运行没问题，长的运行就很糟。
• 只看 git diff：不错，但你会错过改动为什么发生。
• 让模型总结：有帮助，但你仍然想看真实的 diff。

如果你第一次接触 Happier

如果你之前没见过 Happier：它是一款面向编码会话的开源配套应用（移动端/网页/桌面）。

在本指南中，相关的是界面上的审阅循环：

• 工具调用显示为时间线的行（或工具卡片）
• 点按时间线的行可跳转到详情
• 工具调用可以直接链接到 diff 或文件

开始设置：

• 如何在手机上使用 Happier
• GitHub: https://github.com/happier-dev/happier
• 安装/下载: https://github.com/happier-dev/happier#how-it-works
• Discord（社区与支持）: https://discord.gg/W6Pb8KuHfg

可行的审阅循环

2 分钟版（手机）

在手机上，不要试图做“完整审阅”。

只做一次有边界的浏览：

1. 扫一遍工具时间线的行。
2. 打开看起来风险较高的那个 diff。
3. 决定：保留 / 撤销 / 要求总结。

然后停下。

10 分钟版（键盘）

回到键盘前，做更深入的一遍：

1. 查看已更改的文件列表。
2. 分块审阅 diff。
3. 把改动拆分成多个提交。
4. 决定哪些原样保留、哪些重做。

本指南其余部分会让这两种浏览都可预期。

1) 使用轮次结束时的“diff 摘要”工具（出现时）

对于 Claude Code、Codex 和 OpenCode 会话，Happier 可以在一轮结束时显示上一轮 diff 摘要工具。

如果有它，它就是信息量很高的起点，因为它已经限定在：

• “上一轮改了哪些文件”
• “代理实际编辑了什么”

一个不错的默认做法：

1. 点按上一轮 diff 摘要。
2. 先打开风险较高的那一个文件。
3. 如果看起来没问题，继续。
4. 如果看起来不对，停下来要求逐个文件说明理由（或只撤销那个文件）。

2) 在版本控制中审阅上一轮（“真实 diff”的界面）

如果你想认真审阅（而不只是快速浏览），就去 版本控制（Source Control）。

在桌面或宽屏布局下：

1. 打开会话。
2. 打开 右侧边栏 → 版本控制（Source Control）。
3. 在已更改的文件列表中，打开你关心的文件。
4. 审阅 diff。

如果你发现想改的地方，又不想在聊天里重写指令，就直接在 diff 上添加行级审阅评论。

准备把评论变成行动时：

• 点按输入框中的 审查评论（N）（Review comments (N)）标签
• 可选地补充一句上下文（“应用这些并重新运行测试”）
• 发送

这会生成一条结构化的“精确应用这些改动”消息，而不是含糊的来回沟通。

在手机或窄屏布局下流程相同，只是用全屏视图代替停靠的侧边栏。

如何让它保持“只看上一轮”而不是“没有边界的审阅”：

• 从上一轮 diff 摘要工具开始，挑 1 到 3 个文件，然后在版本控制中审阅这些同样的文件。
• 如果会话已经运行了多轮，不要试图审阅当前所有未提交的内容。

3) 把“文件”当作“限定范围的导航器”（仅显示已修改）

当你想要一份简短的已修改清单、又不想考虑 Git 语义时，文件（Files）标签页很有用。

1. 打开会话。
2. 打开 右侧边栏 → 文件（Files）。
3. 开启仅显示已修改的筛选。
4. 用筛选后的目录树在文件之间跳转。

认真审阅 diff 时，最终的“保留还是撤销？”要在 版本控制 中决定。“文件”是帮你保持方向感的好方法。

这样你就有了一个无需滚动对话记录的清爽审阅界面。

4) （可选）把工具时间线当作“为什么会这样？”的索引

如果你仍然不确定某处为什么改了，工具时间线是回答以下问题的辅助界面：

• 运行了哪些命令？
• 安装或测试输出了什么？
• 是什么步骤顺序导致了这个 diff？

但它是可选的。对大多数审阅来说，diff 摘要加上版本控制中的 diff 就够了。

5) 决定工具详情看多深（快速浏览 / 深入查看）

把工具详情当作变焦镜头：

• 浏览模式：刚好能看到“运行了哪些工具”并发现有风险的步骤。
• 深入模式：需要确切的命令或输出时，打开某一个工具调用。

关键是：别让“工具详情”变成第二份你没完没了重读的对话记录。

6) 每个长轮次都以一个决定结束（保留 / 撤销 / 拆分）

轮次结束时的审阅决定总是以下之一：

• 全部保留
• 撤销一个文件
• 把改动拆成 2 个提交

关键是你要有意识地做决定。

还有一个很有用的选项（尤其在手机上）：留下审阅评论，而不是试图“现场修复”。

如果某处基本正确，但你想要几处精确修改，通常更快的做法是：

1. 直接在 diff 上添加几条行级审阅评论
2. 通过 审查评论（N） 标签把它们作为一条结构化消息发送

这会给代理一份非常字面的修改清单，并锚定在你关心的确切行上。

7) 可复用的“改了什么？”清单

如果你只记得一份清单，就记这一份：

• 改了哪些文件？
• 有没有碰到配置、认证或迁移？
• 有没有运行测试？
• 依赖有没有变化？
• 有没有不该提交的生成产物？

8) 要求正确类型的总结（diff 太大时）

如果 diff 大到无法在手机上审阅，不要只说“总结一下”。

要求结构化的审阅辅助：

• “列出你改过的每个文件及原因，每个一句话。”
• “哪些改动是机械性的，哪些是概念性的？”
• “哪些改动可以撤销而不破坏构建？”

这样下次在键盘前审阅会快得多。

一个有用的工作流：行内审阅评论 → 一条结构化的“应用这些改动”消息

在手机上审阅，或者你想明确说明到底该改什么时，这很有用。

与其发送“修一下 diff”这种含糊的消息，你可以直接在 diff 或文件上留下行级审阅评论，然后把它们作为一条结构化消息发给代理。

大致流程：

1. 在 设置（Settings）→ 功能（Features） 中启用 文件审查评论（File review comments）（实验性）。
2. 打开一个 diff（从 版本控制 或任何 diff 视图）。
3. 在你想修改的确切行上添加几条审阅评论。
4. 点按输入框中的 审查评论 标签（显示为 Review comments (N)），可选地补充一句，然后发送。

代理会收到一个结构化的“Review comments:”块，其中包含文件路径、行锚点和代码片段，这让它更有可能精确地应用修改，而不是重写无关的代码。

如果这感觉像“会话里的 GitHub PR 审阅评论”，那正是它的用意。

故障排查

我搞不清改了什么

• 从工具时间线开始
• 然后跳转到 diff
• 如果没有 diff，要求一份逐文件清单和理由

时间线太杂乱

切换到浏览模式（紧凑），重点找：

• 编辑或写入类工具
• git 工具
• 安装

我担心漏掉有风险的改动

做一遍“风险筛选”：

• 迁移
• 认证
• 包管理器文件
• CI 配置

即使其他都不看，这些也要审阅。

常见问题

我应该每一轮都审阅吗？

不必每一轮。

但如果某一轮产生了有意义的文件改动，至少做一次 2 分钟版。

审阅中常见的大错误是什么？

让审阅变得没有边界。

diff 摘要工作流的目的，就是让审阅有开始也有结束。

相关指南

• 如何在手机上提交代码
• 如何在手机上审查 diff