开头
AI辅助编程工具早已不是什么新鲜事物，但坦白说，多数开发者对它的使用仍停留在“帮我生成这段代码”的层面。真正具有高价值的，往往是那些能无缝嵌入日常开发工作流的应用场景。
因此，我们换个更有启发性的视角来探讨：
这篇文章将以一个小而精的Demo，完整展示一条可落地的AI工作流——从读取Git diff，到构建结构化的Review提示，再到让AI输出代码风险、测试建议以及可维护性建议。整个过程清晰高效，没有冗余的花哨功能。
为什么从 PR Review 开始
选择PR Review作为切入点，并非随意决定。它具备几个非常典型的特征：
- 输入足够明确：仅涉及代码diff，不存在歧义。
- 输出同样明确：问题、风险、改进建议均能条理清晰。
- 效果立竿见影：能帮助团队拦截低级错误，提升Review的起点质量。
- 不需要替代人类：AI完成第一轮筛查，由人类最终拍板做判断。
相较“让AI写出整个项目”这类画饼式愿景，这条路径更可控，也更适合实际落地与持续迭代。
工作流设计
该Demo拆解为4个步骤，逻辑层次非常清晰：
- 从Git中读取diff内容。
- 将diff与Review规则组装成一个完整的Prompt。
- 调用AI模型，正式执行代码审查。
- 输出一份结构清晰的Markdown报告。
整个最小化流程串联起来，就是一条自动化流水线：
git diff -> review prompt -> AI review -> markdown report
Review 规则
说实话，我不希望AI输出一堆“代码写得很优雅”这类空洞评价。因此，重点应聚焦在以下几个实际问题上：
- 是否存在明显的Bug？
- 边界条件是否考虑周全？
- 有无安全漏洞？
- 性能层面是否可能存在隐患？
- 代码的可读性与可维护性如何？
- 是否缺少必要的测试用例？
- 是否存在过度设计？
这几个维度比笼统的“代码质量”要具体得多，也更容易转化为可执行的改进建议。这才是代码审查应有的模样。
本地运行
操作起来非常简单。先进入工具目录：
cd tools/git-diff-review
如果想先预览Prompt的生成结果，可以使用以下命令：
node bin/ai-diff-review.mjs --prompt-only --cached
如果代码尚未暂存，需要比较最近一次提交也能轻松搞定：
node bin/ai-diff-review.mjs --prompt-only --base HEAD~1
配置好API Key之后，直接执行即可生成完整的Review结果：
set OPENAI_API_KEY=你的key node bin/ai-diff-review.mjs --cached
输出示例
AI最终输出的结果应呈现为如下格式，结构清晰，关键信息一目了然：
## Summary
这次修改主要影响了...
## Must Fix
- 问题：
- 位置：
- 原因：
- 建议：
## Should Improve
- ...
## Tests To Add
- ...
这个工具不该做什么
有一点必须说明清楚：该工具并非用于替代人工Review。
它更合理的定位是：
- 提前将一眼就能识别的问题揪出来。
- 帮助Reviewer省去第一轮扫读代码的时间，直接进入深度讨论。
- 在开发者提交PR之前，提供一个自我检查的机会。
- 将团队的审查标准沉淀下来，形成一套可复用的模板。
简而言之，它是一个得力助手，但绝非终结者。
下一步可以怎么扩展
这个Demo只是一个起点。后续可拓展的方向其实不少：
- 接入GitHub Actions，PR一提交即自动评论。
- 根据项目所用编程语言，加载不同的Review规则。
- 只审查特定目录，例如仅关注
src/下的代码。 - 不仅给出测试建议，甚至可以自动生成测试草稿。
- 将团队的编码规范写入Prompt，比如日志规范、异常处理、API风格等。
每一条都很实用，且实现难度都不高。
结论
归根结底，AI编程真正产生价值的地方，从来不是让它替你写代码。
更高价值的方向，是将它嵌入你每天都在执行的流程中。
PR Review正好是一个特别适合切入的节点——输入输出均足够明确，风险也完全可控。
这也就是为何会出现这个系列的原因：不空谈AI提效，而是一个工作流一个工作流地拆解开来深度探讨。
