news 2026/6/10 4:14:45

一个下午,我折腾出了一个 Code Review 的 Skill

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
一个下午,我折腾出了一个 Code Review 的 Skill

一个下午,我折腾出了一个 Code Review 的 Skill

踩了个大坑,但挺值

起因

事情是这样的。

我手头有两个之前写的小工具:一个能分析代码里的 API 调用流程,画成时序图;另一个能从 Git 里捞变更内容。某天下午我突然想到,这俩拼一块儿,不就能做代码审查了吗?

不是那种"帮我看看有没有 bug"的审查——那个 Claude 本来就能干。我想要的是:告诉我这次改动到底改了哪些调用链,影响了哪些依赖,风险在哪。

想想就挺美,动手吧。


第一版:三步走,很合理(16:13)

我的设计很朴素:

第一步:分析变更前的代码,生成基准报告 第二步:用 Git 拿到变更内容 第三步:对比一下,出报告

嗯,逻辑清晰,无懈可击。

我还顺手规划了报告的样式——用 Mermaid 画图,绿色表示新增的,黄色表示改过的,红色虚线表示删掉的。脑子里已经在预演最终效果了。

/skill-creator初始化好目录结构,写完SKILL.md,感觉良好。


第二版:还是写个脚本吧(16:41)

开始实现第二步的时候,我犹豫了一下。

让 Claude 直接跑 Git 命令?比如:

gitdiff--name-statusgitshow abc123gitdiffmain..feature

想了想,还是算了。这些命令的输出格式乱七八糟,有的带颜色,有的不带;文件名要是有空格或者中文,又得特殊处理;diff 太长还会截断… 让 Claude 去解析这些乱麻,不太靠谱。

干脆自己写个 Node 脚本,把 Git 操作封装一下,统一输出成 JSON。这样 Claude 拿到的就是干干净净的结构化数据,省心。

给自己定了几个约束:

  • 用 Node 18+,能用原生 API 就不引依赖
  • npm install,拿来就能跑
  • 输出必须是 JSON,方便后续处理

最后这脚本写了 928 行。支持六种模式:看工作区变更、看暂存区、看某个 commit、和某个分支比、看最近 N 次提交、比较两个 commit 之间… 基本够用了。

{"metadata":{"gitMode":"branch:main","currentBranch":"feature/xxx"},"summary":{"added":2,"modified":3,"deleted":1},"files":[{"path":"src/hooks/useAuth.ts","status":"modified","diff":"..."}]}

到这儿为止,一切都挺顺的。


第三版:翻车了(17:02)

然后我实际跑了一遍。

跑完愣住了。

我设计的第一步是"分析变更前的代码"对吧?但问题是——当我执行这个 Skill 的时候,本地的代码已经是改完之后的代码了啊!

所以第一步分析出来的根本不是"变更前"的工作流,而是"变更后"的。整个对比的前提就是错的。

我盯着屏幕想了几秒,有点想笑。这 bug 属于"设计时觉得很合理,跑起来才发现根本不是那么回事"的典型。

怎么办?

想了一会儿,发现 Git diff 里其实啥都有:

- const API = '/api/v1/user' + const API = '/api/v2/user'

减号开头的是原来的,加号开头的是现在的。也就是说,我可以从 diff 反推出变更前的状态。

那就把顺序换一下:

第一步:先拿 Git diff(这里面有变更前后的全部信息) 第二步:分析当前代码的工作流(这是"变更后"的状态) 第三步:根据 diff 反推"变更前"的工作流,然后生成对比

这才对。当前能直接分析的是"变更后","变更前"得靠 diff 倒推。之前的设计完全搞反了。

改完之后顺畅多了。


第四版:补个默认值(17:18)

最后跑了一遍git diff --stat,发现文档里漏了一个东西:报告默认输出到哪?

这种细节不写清楚,用的时候肯定要问。补上:

默认输出目录:v6/docs/code-review

顺手整理了一下三份参考文档,一份管工作流分析,一份管 Git 变更检测,一份管报告格式。各管各的,以后好维护。


复盘

整个过程大概一个半小时,改了四版。

版本时间干了啥
v116:13定了三步走的框架
v216:41写了个 Node 脚本处理 Git
v317:02发现顺序错了,重排
v417:18补文档细节

最大的教训是 v3 那个坑。

画流程图的时候,很容易想当然地觉得"旧版本"和"新版本"都能直接拿到。但实际跑起来,你手头只有当前状态,历史状态得自己想办法重建。

这个道理说出来谁都懂,但设计的时候真的很容易忘。


最终长这样

skills/code-review/ ├── SKILL.md # 主文档 ├── scripts/ │ └── git-change-collector.js # Git 脚本(928 行) └── references/ ├── analyze-codeflow.md # 工作流分析 ├── git-change-detection.md # Git 变更检测 └── change-report-format.md # 报告格式

用起来大概这样:

# 看看工作区改了啥node scripts/git-change-collector.js --modediff--source src/modules/user# 和 main 分支比一下node scripts/git-change-collector.js --mode branch:main# 看最近 3 次提交node scripts/git-change-collector.js --mode last:3

输出的报告会有时序图对比、依赖图对比、每处变更的影响评估,还有个验证清单告诉你该测哪些东西。所有节点都有编号,讨论的时候可以直接说"S3 这个调用有问题",不用来回描述。


为什么要写成 Skill

有人可能会说:直接让 Claude 审查不就行了,干嘛非得搞个 Skill?

我是这么想的:Skill 就是把一套方法论固化下来。

每次审查都用同样的分析框架、同样的输出格式,结果是可预期的。下次再审查,不用重新解释一遍"帮我看看 API 调用链有没有变化",直接调就行。

而且写 Skill 的过程会逼着你把事情想清楚。那个"顺序搞反了"的 bug,如果不是认真设计工作流,可能就一直藏着,每次审查的结果都是错的还不自知。

工具会倒逼你思考。这个过程本身就挺有价值的。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/10 13:56:24

OPCDA转OPCUA工具软件:一个现代工业数据传输的解决方案

OPCDA转OPCUA工具软件。 以前许多老工程都是使用的DA Server。 本软件采用OPC Client读取数据并转换为UA Server。 支持读取选择的Item到UAserver;也支持选择Node回写到DAserver,也即具有双向传送功能。在工业自动化领域,数据传输和管理一直是关键挑战。传统的DA S…

作者头像 李华
网站建设 2026/6/10 13:56:58

当算法开始审标书:中小企业规避“串标误判“的实战指南

2024年11月28日,通报的一起案件,让投标圈炸了锅。两家分别来自陕西和兰州的技术公司,参加银川某设备采购项目。监管部门用大数据分析发现:它们的投标文件IP地址完全相同。两家公司最终承认串标,被处中标金额5.5%-6%的罚…

作者头像 李华
网站建设 2026/6/10 13:56:29

【医学图像算法手册004】ResNet 与 DenseNet 的结构原理与医学图像应用

【医学图像算法手册004】ResNet 与 DenseNet 的结构原理与医学图像应用 概述 在医学图像分析中,卷积神经网络通常需要具备较大的感受野和较强的特征表达能力,以刻画器官结构、病灶形态及其上下文关系。单纯通过增加网络深度来提升表达能力,往往会引入训练不稳定和性能退化…

作者头像 李华
网站建设 2026/6/10 13:59:02

二值化近似计算在量化交易策略中降低遗忘门运算复杂度

本文探讨了在量化交易策略中使用二值化近似计算技术来降低LSTM网络中遗忘门运算复杂度的可行性。通过理论分析和Python实现,展示了这种方法如何在保持模型性能的同时显著减少计算资源消耗,为高频交易场景提供了一种潜在的优化方案。该研究聚焦于算法层面…

作者头像 李华
网站建设 2026/6/10 0:40:41

你还在用GDB硬扛?现代Rust扩展PHP函数调试的4种高效方式

第一章:Rust 扩展 PHP 调试的背景与意义在现代 Web 开发中,PHP 作为长期广泛使用的服务器端脚本语言,依然在大量项目中承担核心角色。然而,随着系统复杂度上升,传统调试手段如 var_dump() 或 error_log() 已难以满足对…

作者头像 李华
网站建设 2026/6/10 8:34:49

【紧急升级预警】你的R Shiny应用可能正因数据格式不兼容而崩溃!

第一章:【紧急升级预警】你的R Shiny应用可能正因数据格式不兼容而崩溃!许多R Shiny开发者在部署应用时遭遇意外崩溃,根源往往并非逻辑错误,而是数据格式的隐性不兼容。当从外部源(如CSV、数据库或API)加载…

作者头像 李华