Codiff v0.1.0 的发布信息很小：GitHub 第三方开源项目，仓库是 nkzw-tech/codiff，当前约 117 stars、3 forks，版本标注为 Initial Release。

但它切的位置不小。

它不是 GitHub 官方产品，也不是完整代码审查平台。它把动作放在更早的地方：代码还没开 PR，甚至还没 commit，开发者先在本机把 diff 看一遍、批注一遍。需要时，让 LLM 生成 walkthrough，再把带 diff context 的 Markdown review 复制出去。

代码审查这几年越做越平台化：PR、CI、权限、合并队列、机器人评论。Codiff 反着走。它把第一道门，挪回开发者桌面。

Codiff v0.1.0 到底是什么

目前能确认的信息很克制。它是一个 macOS 本地原生桌面 diff viewer，面向 Git 的 staged 和 unstaged changes。

项目信息
来源GitHub Releases，仓库 nkzw-tech/codiff
版本v0.1.0 Initial Release
定位macOS 本地原生桌面 diff review 工具
可查看内容staged / unstaged Git changes
AI 功能codiff -w 生成 LLM walkthrough
协作功能行内评论；复制完整 Markdown review，包含 diff context
当前下载资产目前只看到 macOS darwin-arm64 包
命令行启用安装后需在 App 内通过 Codiff > Install Terminal Helper 启用 codiff 命令

这张表也说明了它的边界。

它现在更适合 Apple Silicon Mac 用户。材料里没有显示 Windows、Linux 支持，也不能把它说成跨平台方案。安装后还要手动启用 Terminal Helper，才有 codiff 命令。

更重要的是，它解决的不是“PR review 怎么替代”。它处理的是 PR 之前那段没人正式接管的时间。

代码已经改了，但还没准备公开。你想自己先过一遍，又不想开一个半成品 PR。你想让 AI 看看 diff，又不想把上下文剪成碎片。你想请同事快速瞄一眼，又不想把团队流程提前拉起来。

Codiff 把这件事包装成一个本地动作。

它真正踩中的是 PR 前灰区

很多团队都说重视 code review。现实里，review 流程常常很重。

开 PR 之后，事情就正式了。标题要写，描述要补，CI 要跑，Reviewer 要挂上去。小改动还能忍。半成品就会变成噪音。

于是问题经常被推迟。等到 PR 出来，代码已经写顺手了，作者也已经形成防守姿态。Reviewer 再提结构问题，成本就高了。

Codiff 的价值在这里：把一部分检查前移。

它让开发者先看 staged/unstaged changes，再用 LLM walkthrough 快速理解 diff，最后把带上下文的 Markdown review 交给同事或 AI 工具。这不是把审查做大，而是把第一次审查看得更轻。

对独立开发者来说，动作很直接：commit 前先用它过一遍 diff，把 walkthrough 当作自查清单，再决定哪些变更该拆 commit、哪些地方该补注释或测试。

对小团队工程师来说，它更像低成本交接工具：不必为一个还没成型的改动开 PR，可以先把 Markdown review 发给同事，让对方带上下文看关键行。少一次来回，就少一次流程摩擦。

关注 AI 编程工作流的人，也该把它放进“提交前工具链”里看，而不是拿它和完整 PR 平台硬比。它的位置更靠近 IDE、Git GUI、本地 lint，而不是 GitHub pull request 页面。

这有点像早期 IDE 和本地开发工具对中心化流程的反拨。不完全一样，但脉络相似：当平台流程变重，工具会往离手更近的地方长。

“工欲善其事，必先利其器。”这句话放在这里合适，但只能放一半。器利不等于人勤。工具能把问题照亮，不能替团队建立纪律。

AI walkthrough 不是代码审查员

我更在意 Codiff 对 AI 的摆放位置。

它说的是 codiff -w 生成 LLM walkthrough。这个词比“AI reviewer”诚实。walkthrough 是导览，是解释，是帮你进入 diff 的结构。

这很关键。

AI 适合把变更拆开，提示可能遗漏的分支、命名、边界条件和上下文关系。它像放大镜，不像法槌。

真正的代码审查还有很多非代码因素：业务意图、团队约定、长期维护成本、上线风险、责任归属。这些东西，本地 diff 工具看不全。LLM 也不能替你背锅。

所以别把 Codiff 神化。

它能减少平台摩擦，不能替代团队治理。它能让小团队更快形成一次像样的预审，不能自动建立工程纪律。它能把本地变更整理成 Markdown，不能保证接收者认真看。

这里还有几个现实约束，不能跳过去。

变量现在能看到什么影响
平台目前下载资产只显示 macOS darwin-arm64Windows/Linux 用户先观望，团队统一采用会受限
AI 调用方式材料只写 LLM-generated walkthrough不能推断具体模型、供应商、联网方式或隐私策略
协作深度支持行内评论和 Markdown 导出更像提交前交接，不是权限、审批、CI 一体化平台
成熟度v0.1.0 Initial Release适合尝鲜和局部流程试用，不适合直接当团队标准流程

这也是接下来最该看的地方。

不是看它会不会喊更大的口号，而是看三个具体问题：是否扩展到更多平台；LLM walkthrough 是否足够稳定、可控；Markdown 交接能不能真正嵌进小团队日常，而不是变成又一份没人读的文本。

如果这三件事做不好，它就是一个漂亮的本地 diff 小工具。如果做得好，它会变成开发者提交前的轻量检查站。

我不太买账那种“AI 将替代 code review”的说法。工程里的很多麻烦，不是模型不会读代码，而是人不愿意提前处理问题。PR 页面只是把矛盾摊开；Codiff 这类工具试图把矛盾提前一点暴露。

这才是它有意思的地方。

AI 编程工作流的下一轮竞争，不一定都在云端大平台。很多价值会回到本机，回到 commit 之前，回到那几分钟没人监督、但最容易决定代码质量的窗口。

模型越强，越要问它被放在流程的哪个位置。放错了，是噪音。放对了，才是利器。