执行轨迹回溯 — 出问题时精准定位哪一步错了
为什么要轨迹
传统 AI 对话的输出是黑盒——你不知道 AI 在给你答案之前经历了什么推理、用了什么工具、调用了什么 API。出了问题只能猜。
Sophclaw 的执行轨迹就是为了解决这个问题：每一步文件变更、每一条命令执行、每一个 API 调用都留下可查看的记录，包括：
- 操作类型（读文件 / 写文件 / 运行命令 / 调用 API）
- 操作目标（哪个文件 / 哪条命令 / 哪个接口）
- 操作时间戳
- 执行结果（成功 / 失败 + 错误信息）
- 输出内容摘要
怎么查看轨迹
手机端 / PC 客户端：在对话界面里，每次执行后会显示一个"执行详情"或"轨迹记录"的入口，点击能看到逐步列表。
控制台 / 命令行：执行过程的每一步会实时滚动输出，结束后可以用方向键回看或导出日志。
文件系统：Sophclaw 在工作空间目录下会自动生成执行日志文件，可以用文本编辑器直接打开。
用轨迹排查问题
场景一：AI 删了不该删的文件
轨迹里看"写文件"那一步的具体路径 → 确认是哪个指令触发的 → 回到那个指令看是不是约束条件没写清
场景二：执行中途卡住不动
看轨迹停在什么操作上 → 如果停在某个命令执行太久 → 可能是那个命令本身有问题（比如
npm install超时）→ 手动去终端跑一下看看
场景三：输出结果不对
看轨迹里 AI 读取的源文件是什么 → 确认它是不是读对了文件 → 如果它读了错误的文件，那就是上下文/路径的问题
场景四：消耗的 token 远超预期
看轨迹里 AI 调用了哪些工具、输出了多少中间信息 → 有些任务路径设计会导致 token 浪费（比如反复读取同一份大文件）→ 优化指令或加约束
轨迹 vs 日志
轨迹和日志是两个相关但不同的东西：
| 对比 | 执行轨迹 | 系统日志 |
|---|---|---|
| 面向谁 | 用户看，面向任务 | 开发者看，面向系统 |
| 粒度 | 每一步操作 | 更细的底层事件 |
| 格式 | 人类可读 | 结构化 JSON 或文本 |
| 生命周期 | 任务完成后保留（可清理） | 长期保留（用于调试） |
日常使用中执行轨迹足够了，系统日志一般不需要手动看。
实践建议
养成看轨迹的习惯。每次执行完（不管成功失败），花 10 秒扫一眼轨迹：
- 有没有动了你没让它动的文件？
- 有没有执行了你没预期到的命令？
- 每一步的输出是不是你期望的？
这 10 秒能帮你避开大部分"AI 做了不该做的事"的坑。
如果你是第一次让 Sophclaw 碰正式目录的文件，看完轨迹再确认结果——多等 30 秒换回数据安全，值。