企业官网建设流程全解析

ThinkRail 代码审查指南：把 Diff 上的评论组装成结构化工单，派单给 AI Agent 逐条修复

【免费下载链接】thinkrailVibe code with pi in a lightweight, real IDE that customises itself around the way you work — The Vibe You Need项目地址: https://gitcode.com/GitHub_Trending/th/thinkrail

ThinkRail 是一款围绕 pi 编码代理打造的 Agentic IDE。它的代码审查能力让你直接在 Diff 上圈选行、留下带行号和代码片段的锚点评论，再用一次点击把这些评论组装成结构化上下文包，喂回 AI Agent 逐条修复并销账。本文先拆解它"评论锚点如何随文件变化自愈"的核心机制，再给出从留评、发送到 Agent 修复的完整操作路径。

功能全景：它把"改这里"变成一条可执行的工单

多数工具里，审查意见就是一句丢进聊天框的话——"那块改一下"。Agent 不知道你说的是哪个文件的哪几行，改到一半也说不清还剩哪几条没办。锚点评论（anchored review comment）是 ThinkRail 的解法：评论被"钉"在某个文件的具体行段或 Diff 块上，记录行号、选中片段的原文、以及片段前后各 10 行的上下文。

发送时它不会原样转发文字，而是把每个文件的评论渲染成一个review 上下文包：每条评论带稳定 id、文件路径、行号范围、锚点状态，外加给 Agent 的明确指令——逐条处理、修完调用resolve_comment销账、遇到过期先核对当前文件、不同意就在对话里反驳而不是硬改。于是一句模糊的口头要求，变成了一张可追踪、可销账的结构化工单。

核心机制拆解：文件变了，锚点为什么还能对上

审查往往跨好几个 Agent 回合，文件内容一直在变。ThinkRail 在每次读取和发送前都会跑一遍重锚（re-anchoring），依据是落评时固化的两个证据：文件字节的sha-256 哈希（contentHash），以及落评时截取的文本引用（textQuote，含前后各 32 个字符的前缀/后缀用于消歧）。结果落在三种状态：

几个值得注意的细节：

• moved是有记忆的。一旦发生过漂移，即便下一次哈希又对上了，状态也不会悄悄退回anchored——它要保留"这条评论曾经漂移过"这个事实。
• outdated 不假装还在原位。它把落评时的片段原样留在评论里，并在发送包里标注"先对照当前文件核实"，而不是让 Agent 照着一个已经失效的位置乱改。
• 没有可搜索文本的锚点更严格。对图片这类纯字节资源，只要位置型选择器还在而文件变了，直接判outdated——因为"尺寸没变"并不能证明那个区域里的像素没变，宁可让你再看一眼。

Diff 两侧是两套独立的锚点空间

Diff 的左（base）侧和右（worktree）侧是两套互不干扰的锚点。针对改动前被删除或重写的代码留言时，锚点会捕获它所属的那个 commit 并固化成一个不可变的 commit oid（baseRef），片段和上下文就永远对着这个历史版本——你之后无论怎么提交，它都不会"复活错位"到新的行号上。而右侧 worktree 锚点才参与上面那套重锚逻辑，两侧读各自的内容，绝不互相串读。

实操：留评、发送与追踪、Agent 逐条修复

在 Diff 上留下锚点评论

在Changes 面板双击某个文件打开 Diff，用鼠标或方向键选中任意几行，行选区旁会出现一个评论图标。点开后弹出内联输入框，显示选中行号（如Line 2），此时有两个去向：

• 存为草稿——先钉在文件上，稍后统一发送；
• 立即发送——当场创建该文件的审查会话并派单。

草稿会渲染成一张review-thread-card线程卡片，标注draft状态，旁边带发送按钮；对应编辑器标签页会亮出 Review 角标和待发送计数。评论的粒度不止"某几行"：还可以挂在整个文件（file）、整组改动（Whole change set），以及普通文件（inline）上。

在分支 Diff（All changes）视图里，每个 hunk 额外配了Keep / Revert / Ask agent about this hunk三个按钮。Keep 以 hunk 内容为键，行号漂移后依然有效；底部有进度条和Next unreviewed按钮（快捷键J），V键标记当前文件已读，Alt+↑/↓ 上下切换文件——大改动的逐块过审体验很完整。

发送与追踪：按文件分组，一次派单

右侧Review 面板把所有评论按文件分组。发送有两个粒度：

• 文件级 Send review (N)——只发这一个文件的 N 条草稿；
• 全局 Send all (N)——一键清空所有草稿。

每个文件的首次发送会自动创建它专属的审查会话，之后该文件的新评论都续进同一个会话，讨论不中断；发送时也可以直接指定当前打开的聊天。Review 面板里，每条评论会随 Agent 的处理从"待处理"移到"已解决"。

Agent 逐条修复与销账

Agent 收到上下文包后，用真实的编辑工具去改文件，每办完一条就调用resolve_comment工具、附上"做了什么"的一句话，Review 面板里对应评论随即移入 Resolved。如果 Agent 还没动手、发送前就报错（比如模型密钥失效），评论会自动回滚成草稿，随时可重发——不会出现"发出去了但 AI 没收到"的尴尬。

状态与边界：一条评论从草稿到归档

评论的生命周期由几个清晰的状态串起来，发送之后它就从"你的草稿"变成"一条记录"：

• 草稿（draft）：你未发送的临时稿，仍可编辑、可删除、可单独发送。
• 已发送（sent）：已进入某条会话，成为不可删除的记录——因为 Agent 的对话里已经引用了它的 id，删了会造成悬空引用。
• 已解决（resolved）/ 已忽略（dismissed）：Agent 处理完或你人工确认后进入终态，只能回看讨论。
• 收尾：某个文件全部处理完，可点Done标记收尾；之后用Clear把已发送评论归档、丢弃剩余草稿，开启下一轮审查。归档发生在替换活动快照之前，即便中途有 Agent 正在销账也能落到归档记录上。

所有审查记录与 Agent 对话各自持久化在~/.thinkrail，重启应用后评论不会丢。

效率技巧

• 🔧先做减法再留言：用 hunk 级 Keep/Revert 处理掉明显没问题的改动，只给真正需要 Agent 动手的 hunk 写评论，减少上下文噪音。
• 锚点状态徽标先看一眼：发送前若某条显示outdated，先回文件里对一眼，再让 Agent 处理，避免它照着旧快照改到别处。
• 一个文件一个闭环：推进完"发送 → 修复 → 销账"再发下一个文件，全部 resolved 后点 Done，底部进度条的反馈会更清晰。
• 全局判断用文件级/整组锚点：具体行用行锚，跨文件的整体评价用 file 或 Whole change set 锚点，别把大段讨论塞进某一行。
• 🖥️长审查切 Review 预设布局：Settings → Layout 内置 1 左 + 2 右栏组的 Review 预设，聊天、Diff、Changes/Review 同屏，省去来回切换。
• 大改动切 One file：改动超过 50 个文件会自动提示逐文件审查，虚拟列表不卡，锚点也不会因跨文件跳跃而错乱。

相关模块导读

• 审查层设计与状态机
• 锚点捕获与重锚算法
• 上下文包渲染，Agent 收到什么
• resolve_comment 工具定义
• Review 侧栏面板
• Changes 分支 Diff 审查视图

结语

ThinkRail 把代码审查从聊天记录里的一笔带过，升级成了一条可追踪、位置能自愈的结构化流水线。它的完整链路可以浓缩成一句话：圈选 → 落评 → 重锚 → 装配 → 修复 → 销账。当审查意见能精确到行号、带着代码片段和上下文喂回 Agent，vibe coding 才真正从"许愿"走向"协作"。

【免费下载链接】thinkrailVibe code with pi in a lightweight, real IDE that customises itself around the way you work — The Vibe You Need项目地址: https://gitcode.com/GitHub_Trending/th/thinkrail