代码审查

命名不规范、日志少打一个字段、错误没往上抛——这类规范问题占了评审意见的大半，却最消耗注意力。等看到第三百行时，人已经疲了，而真正要紧的边界条件和并发问题往往就在后面。

团队规范写在 Wiki 上，最后一次更新是一年前。没人每次评审都去对照一遍，新人更不知道有这份文档。

把编码规范、错误处理约定、日志规范、既有架构约束打包成 Skill，连同典型反例一起放进技能文件包。

技能支持版本管理。规范调整时发新版本，所有加载它的评审智能体自动对齐——这比在群里发一条"大家注意以后日志都要带 trace_id"有效得多。

代码审查不是固定流程：看到一处可疑的空指针，需要去追调用链；怀疑并发有问题，可能要在沙箱里写个小用例跑一下验证。这是多步骤的自主探索。

用自主型智能体（Cowork Mode），它运行在隔离沙箱里，有文件系统和命令行。代码仓库通过 MCP 工具接入——GitHub、GitLab 这类已有成熟 MCP 服务的系统直接接，不必为拉 diff、读文件各封装一个插件。

角色设定要求输出严格分两类：

一是规范偏离——可以批量修，列清单即可，不需要逐条解释理由。二是潜在缺陷——边界条件、错误处理缺失、并发安全、资源泄漏，每条要说明推断过程和触发路径。

分开的意义是把人的注意力导向第二类。混在一起按行号排列，二十条命名问题里夹着一条空指针，评审人很容易滑过去。

每条意见给出可直接替换的代码片段和理由，而不是"建议优化此处"。

评审意见能不能被采纳，很大程度上取决于开发要花多大力气去改。能直接复制的建议才会真被采纳——这个道理和合同审查那边是一样的。