三个月里连踩三个坑我终于把团队那套通用代码审查流程扔了。不是说通用 CR 不好。是它在我碰到的三个项目上全翻车了。第一个坑来自一个支付回调的 PR。我们用的是公司通用的 review 清单风格、命名、有没有注释、单测覆盖率。reviewer 把命名改了一轮注释补了一堆PR 顺利合了。结果上线当天晚上资损告警——回调的重复幂等没做同一个支付通知被处理了两次。通用清单里压根没有功能是否对齐需求这一项大家默认需求对了是产品的事。第二个坑更隐蔽。一个数据导出功能spec 里要求导出字段要脱敏但实现里把手机号原样写进了 CSV。通用 CR 看的是代码写得好不好没人去逐条比对 spec。等客户投诉已经是两周后。第三个坑直接把我劝退。一个并发计数器的修复代码漂亮得挑不出毛病但锁的粒度错了高并发下计数漂移。通用审查里并发正确从来不是默认检查项除非 reviewer 自己碰巧懂这块。你猜怎么着这三个问题没有一个是代码质量问题。全是做了对的事吗没被问过。通用代码审查最大的毛病就是把功能对不对和代码好不好搅在一起。reviewer 一边看命名一边看需求注意力被漂亮代码带跑真正致命的规格错漏反而溜过去。我自己就干过这种事——看一个写得特别优雅的函数顺手就 approve 了事后才发现它实现的根本不是 spec 要的那个行为。如果让我重来我会先把这代码做的是不是需求要的这关单独拎出来而不是跟命名、注释混着看。说句难听的我特别讨厌那种清单越长越专业的错觉。我们那份通用清单满满两屏可真正能拦住资损、拦住数据泄露的项一个都没有。清单长不代表审查对这是踩完坑才懂的。后来我换成了 tri-review一个专门干代码审查的 skill定位是 tri-intent 下游的 L2 编码特殊路由项。说白了它不是个通用工具而是专门吃代码审查这个意图的。tri-intent 那套意图路由里代码审查被单独拎出来不占 I11 编码、I12 调试的编号位直接路由到 tri-review。识别特征也直白你说了review 一下这个 PR“做个 CR”“过一遍代码”它就判定为代码审查落盘成快照再交给 tri-review 跑两阶段工作流。它跟 I11 编码开发只看不改产出新代码、I12 调试修复故障已发生后的补救也划得清清楚楚——代码审查是预防性验证只看不改。它最对我胃口的是两阶段分离。Phase 1 先问做了对的事吗只盯规格合规功能完整性、行为正确性、需求对齐、上下文一致性。这一关专门找我那三个坑里的问题——幂等没做、脱敏漏了、锁粒度错。而且它有个狠规矩Phase 1 存在 BLOCKER 级问题直接标[PHASE1-FAIL]根本不进 Phase 2。也就是说代码再漂亮功能错了就打回不给你写得不错但功能不对的侥幸。Phase 2 才问做得对吗看代码结构、可读性、健壮性、性能、安全、测试再叠加 Fowler 那 12 种坏味基线。两阶段强制分两次跑还带反规避检测防止你嫌麻烦把两阶段合并成走过场——比如它查 Phase 1 结论里有没有冒出 Phase 2 的类别标记有就打[INVALID:CROSS-PHASE]退回去重审。我特别喜欢它的标记格式审查意见一眼能溯源。给一段真实风格的评审意见模板[PHASE1-ISSUE] BLOCKER 行为正确性 — 证据payment/callback.ts:42 — 描述未实现幂等校验同一支付通知重复到达时会重复入账存在资损风险 [PHASE1-NOTE:QUALITY] 可读性 — 描述回调处理函数过长约 80 行建议拆分 [PHASE2-ISSUE] SECURITY MAJOR 安全性 — 证据export/csv.ts:17 — 描述导出 CSV 未对手机号脱敏违反 spec §3.2 数据脱敏要求每一条都带file:line证据门①确认范围、门②确认结论两道落盘审批门串行走跳门直接打回。复选框[ ]/[x]表示审没审过跟过没过分开——[x]只是审了不代表通过。这个区分我以前手动 review 从没认真做过踩坑后才懂它有多重要审过不等于没问题。生成 diff 也很省事固定点锁定后一条命令就出来# 锁定上游最新一个 commit 作为固定点三点 diff 比较 merge-basegitdiff固定点...HEADgitlog固定点..HEAD--oneline审查报告最终落盘在.tribro/reviews/命名/review-report.md门①负责确认审查范围门②负责确认结论一个文件串起两道门。它跟 tri-coding、tri-fix 的协作也清楚审查没过上游 skill 据报告改完代码再提交复查。我个人的判断通用 CR 适合代码已经基本对了求个质量兜底的场景但凡需求复杂、规格多、涉及钱或数据的就该上这种专用路由。它把验证和执行切开——tri-review 只审查不改代码发现问题写进报告修复交回 tri-coding / tri-fix。职责边界清楚不会有人边 review 边顺手改把审查变成一团浆糊。填坑填到第三次我算想明白一件事review 的失败往往不是因为 reviewer 不认真而是流程从一开始就没逼他问功能对不对。通用 CR 把这道关漏了专用路由把它补回来仅此一项就值回票价。我做的雷达鸭刚好也是这么干的——核心功能上线前都要过一遍两阶段审查应用市场能搜到。关于我我是老三10 年以上软件开发经验软件设计师 / 人工智能应用工程师平时做鸿蒙ArkTS北向开发和 Web 前端也在 CSDN 断断续续写点鸿蒙和 AI 方向的文章。本文遵循 MIT 协议转载请注明出处。请根据 https://skillhub.cn/install/skillhub.md安装 tri-review。 我为什么弃用通用代码审查，换成了专用的 tri-review
三个月里连踩三个坑我终于把团队那套通用代码审查流程扔了。不是说通用 CR 不好。是它在我碰到的三个项目上全翻车了。第一个坑来自一个支付回调的 PR。我们用的是公司通用的 review 清单风格、命名、有没有注释、单测覆盖率。reviewer 把命名改了一轮注释补了一堆PR 顺利合了。结果上线当天晚上资损告警——回调的重复幂等没做同一个支付通知被处理了两次。通用清单里压根没有功能是否对齐需求这一项大家默认需求对了是产品的事。第二个坑更隐蔽。一个数据导出功能spec 里要求导出字段要脱敏但实现里把手机号原样写进了 CSV。通用 CR 看的是代码写得好不好没人去逐条比对 spec。等客户投诉已经是两周后。第三个坑直接把我劝退。一个并发计数器的修复代码漂亮得挑不出毛病但锁的粒度错了高并发下计数漂移。通用审查里并发正确从来不是默认检查项除非 reviewer 自己碰巧懂这块。你猜怎么着这三个问题没有一个是代码质量问题。全是做了对的事吗没被问过。通用代码审查最大的毛病就是把功能对不对和代码好不好搅在一起。reviewer 一边看命名一边看需求注意力被漂亮代码带跑真正致命的规格错漏反而溜过去。我自己就干过这种事——看一个写得特别优雅的函数顺手就 approve 了事后才发现它实现的根本不是 spec 要的那个行为。如果让我重来我会先把这代码做的是不是需求要的这关单独拎出来而不是跟命名、注释混着看。说句难听的我特别讨厌那种清单越长越专业的错觉。我们那份通用清单满满两屏可真正能拦住资损、拦住数据泄露的项一个都没有。清单长不代表审查对这是踩完坑才懂的。后来我换成了 tri-review一个专门干代码审查的 skill定位是 tri-intent 下游的 L2 编码特殊路由项。说白了它不是个通用工具而是专门吃代码审查这个意图的。tri-intent 那套意图路由里代码审查被单独拎出来不占 I11 编码、I12 调试的编号位直接路由到 tri-review。识别特征也直白你说了review 一下这个 PR“做个 CR”“过一遍代码”它就判定为代码审查落盘成快照再交给 tri-review 跑两阶段工作流。它跟 I11 编码开发只看不改产出新代码、I12 调试修复故障已发生后的补救也划得清清楚楚——代码审查是预防性验证只看不改。它最对我胃口的是两阶段分离。Phase 1 先问做了对的事吗只盯规格合规功能完整性、行为正确性、需求对齐、上下文一致性。这一关专门找我那三个坑里的问题——幂等没做、脱敏漏了、锁粒度错。而且它有个狠规矩Phase 1 存在 BLOCKER 级问题直接标[PHASE1-FAIL]根本不进 Phase 2。也就是说代码再漂亮功能错了就打回不给你写得不错但功能不对的侥幸。Phase 2 才问做得对吗看代码结构、可读性、健壮性、性能、安全、测试再叠加 Fowler 那 12 种坏味基线。两阶段强制分两次跑还带反规避检测防止你嫌麻烦把两阶段合并成走过场——比如它查 Phase 1 结论里有没有冒出 Phase 2 的类别标记有就打[INVALID:CROSS-PHASE]退回去重审。我特别喜欢它的标记格式审查意见一眼能溯源。给一段真实风格的评审意见模板[PHASE1-ISSUE] BLOCKER 行为正确性 — 证据payment/callback.ts:42 — 描述未实现幂等校验同一支付通知重复到达时会重复入账存在资损风险 [PHASE1-NOTE:QUALITY] 可读性 — 描述回调处理函数过长约 80 行建议拆分 [PHASE2-ISSUE] SECURITY MAJOR 安全性 — 证据export/csv.ts:17 — 描述导出 CSV 未对手机号脱敏违反 spec §3.2 数据脱敏要求每一条都带file:line证据门①确认范围、门②确认结论两道落盘审批门串行走跳门直接打回。复选框[ ]/[x]表示审没审过跟过没过分开——[x]只是审了不代表通过。这个区分我以前手动 review 从没认真做过踩坑后才懂它有多重要审过不等于没问题。生成 diff 也很省事固定点锁定后一条命令就出来# 锁定上游最新一个 commit 作为固定点三点 diff 比较 merge-basegitdiff固定点...HEADgitlog固定点..HEAD--oneline审查报告最终落盘在.tribro/reviews/命名/review-report.md门①负责确认审查范围门②负责确认结论一个文件串起两道门。它跟 tri-coding、tri-fix 的协作也清楚审查没过上游 skill 据报告改完代码再提交复查。我个人的判断通用 CR 适合代码已经基本对了求个质量兜底的场景但凡需求复杂、规格多、涉及钱或数据的就该上这种专用路由。它把验证和执行切开——tri-review 只审查不改代码发现问题写进报告修复交回 tri-coding / tri-fix。职责边界清楚不会有人边 review 边顺手改把审查变成一团浆糊。填坑填到第三次我算想明白一件事review 的失败往往不是因为 reviewer 不认真而是流程从一开始就没逼他问功能对不对。通用 CR 把这道关漏了专用路由把它补回来仅此一项就值回票价。我做的雷达鸭刚好也是这么干的——核心功能上线前都要过一遍两阶段审查应用市场能搜到。关于我我是老三10 年以上软件开发经验软件设计师 / 人工智能应用工程师平时做鸿蒙ArkTS北向开发和 Web 前端也在 CSDN 断断续续写点鸿蒙和 AI 方向的文章。本文遵循 MIT 协议转载请注明出处。请根据 https://skillhub.cn/install/skillhub.md安装 tri-review。