面向 WNS 固件项目的深度代码审查技能，采用语义审查 + 机械合规检查双轨编排架构。
- 语义审查（智审主脑）：理解代码改动意图，评估设计合理性、安全性与正确性
- 规范合规检查（机械子代理）：按 C/C++/Shell 编码规范逐条检查（91+91+14 条）
- 场景差异化审查：自动识别新增需求/修复缺陷/重构场景，调整审查重心
- TD 缺陷查询：从 TD 系统获取缺陷详情，支持根因分析
- MR/Commit 双模式：支持 GitLab MR 合并请求审查和单次提交审查
code-review/
├── SKILL.md # 代码审查技能定义（语义+机械双轨编排）
├── compliance-checker.md # 规范合规检查子代理定义
├── scripts/
│ ├── td-cli.py # TD 缺陷查询工具
│ ├── td-cli.exe # Windows 可执行版本
│ └── td-cli # Linux/macOS 脚本
├── references/
│ ├── C_Coding_Standards.md # C/C++ 编码规范（91条）
│ ├── CAPI_Coding_Standards.md # C API 接口规范（91条）
│ ├── Shell_Coding_Standards.md # Shell 脚本规范（14条）
│ └── checklist-business.md # 业务逻辑检查清单（82条）
当用户请求以下操作时自动触发：
review代码/代码审查/检查提交/审核代码/review commit- 完成功能开发后请求 review 时主动触发
Phase 0: MR 环境检测
Phase 1: 信息收集（git log / TD查询 / 知识库）
Phase 2: 场景识别（新增需求 / 修复缺陷 / 重构）
Phase 3: 关联影响分析
↓ 获得 diff 后立即启动 ──────→ 机械子代理（规范合规）
Phase 4: 语义分层审查（L1-L3） ←并行→ 逐条检查 91+91+14 条
Phase 5: Verification 自检
Phase 6: Commit 有效性判断
Phase 7: 汇总 → 生成报告
审查报告保存至 code_review_docs/ 目录，格式包含：
| 章节 | 内容 |
|---|---|
| 审查结论 | 总体评价 + 问题数量统计 |
| 问题清单 | 严重问题 / 建议改进 / 规范提醒 |
| 深度分析 | 根因评估 / 遗漏场景检查 / 新问题评估 / 8维度安全性评估 |
| 审查摘要 | 改动背景 + 主要发现 |
| 规范类型 | 条款数 | 适用文件 |
|---|---|---|
| C/C++ 通用规范 | 91 条 | .c / .h / .cpp |
| C API 接口规范 | 91 条 | 含 _api.h / _interface.h 的文件 |
| Shell 脚本规范 | 14 条 | .sh / .bash |
| 业务逻辑检查 | 82 条 | 业务逻辑审查参考 |
| 指标 | 数值 |
|---|---|
| 持续运行时间 | 83 天（2026-01-27 至 2026-04-20） |
| 生成报告数 | 260+ 份 |
| 单日最高报告数 | 26 份 |
| 严重 Bug 拦截数 | 20+ 个 |
以下为实际拦截的真实严重 Bug：
// 提交的代码（崩溃）
if (!timer && !timer->data)
// 正确写法
if (!timer || !timer->data)后果：timer 为 NULL 时，&& 短路不进入 if，代码继续执行解引用 NULL 指针，容灾切换模块崩溃。
// 提交的代码（void* 指针算术 = 未定义行为）
uint64_t val = *(uint64_t *)(data + 1); // 偏移1字节，不是8字节
// 正确写法
uint64_t val = *(uint64_t *)((uint8_t *)data + sizeof(uint64_t));后果：修复代码本身导致程序崩溃，容灾切换功能彻底失效。
目录从 pse_manager 重命名为 pse_upgrade，但 wns/apps/Makefile 第236行仍引用旧名字，导致整个项目无法编译。
<<<<<<< HEAD 残留在 .proto 文件中，导致编译失败。
| Bug 类型 | 严重程度 | 特征 |
|---|---|---|
&& 写 ||，NULL 指针解引用 |
🔴 崩溃级 | TD2026032500257 |
void* 指针算术 UB，偏移错误 |
🔴 崩溃级 | TD2026032300114 |
switch/case 缺 break，状态机穿透 |
🔴 状态异常级 | TD2025050700011 |
| 重构遗漏 Makefile，编译失败 | 🟠 编译失败级 | TD2026030900170 |
| Proto 合并冲突标记未清理 | 🟠 编译失败级 | TD2026010700317 |
| Proto 字段删除破坏版本兼容 | 🟠 数据丢失级 | 字段编号前移 |
| 协议号变更缺版本协商 | 🟠 功能失效级 | TD2026020200144 |
| 状态通知逻辑错误永远不执行 | 🔴 功能失效级 | 条件永远为假 |
| 类别 | 数量 | 说明 |
|---|---|---|
| 失败模式 | 23 个 | 来自历史 confirmed fix commit，有 commit hash 可追溯 |
| 设计决策 | 101 个 | 无线团队多年积累的架构知识 |
| 隐式约束 | 253 个 | 从代码里提炼，非文档记录 |
| 知识库文件 | 40+ 个 | 按模块组织，精准加载避免上下文污染 |
| 领域知识 | 1.9 MB | 按场景动态加载 |
知识库是本项目的护城河——不是 prompt 工程，是无线团队经验资产的数字化。
每次代码提交，两个 AI 代理同时启动，互不等待：
| 代理 | 职责 | 输出 |
|---|---|---|
| 智审主脑 | 语义判断：意图对不对、逻辑有无漏洞、是否解决 TD 问题 | 8 维度安全性评估 |
| 机械子代理 | 规范核查：196 条规则逐条 PASS/FAIL/N/A | 结构化合规报告 |
规范来源：公司官方 SFRD-PPQA-15-5.7 研发编码 checklist，以前是人工对着 Excel 逐条核查。
本项目的独特能力——不只是审查代码，是审查这段代码是否真的解决了那个 Bug：
- 自动解析 commit message 中的 TD 号
- 拉取 TD 系统中的现象描述
- 验证代码修复是否针对根因而非症状
- 构建"现象 → 根因 → 修复路径"完整因果链
| 对比对象 | 能力 | 本项目多了什么 |
|---|---|---|
| 通用 AI（ChatGPT/Copilot） | 代码语法审查 | 23 个无线团队专属失败模式、TD 因果链验证、关联影响分析 |
| 静态分析工具（SonarQube） | 规范检查 | 业务意图理解、根因验证、场景识别、8 维度安全分析 |
| 人工审查 | 全部 | 不累、不漏、分钟级、全自动、可追溯、7×24 小时 |
成功标准：将所有缺陷拦截在发布前，零遗漏。
代码审查的本质是风险对冲——生产故障修复成本是 Review 阶段的 10～100 倍。
两个核心认知：
- 代码改动的危险在于与系统其余部分的交互，而非改动本身
- 规则合规是审查的地板，不是天花板——代码可以完全符合规范，却在逻辑上是错的
- 只读原则：禁止擅自修改代码或执行
git commit - 报告保存路径：
code_review_docs/${hash}-${timestamp}.md
# 获取 TD 详情
./code-review/scripts/td-cli.py get-td --td-no <TD号>
# 下载 TD 附件
./code-review/scripts/td-cli.py download-attachments -t <TD号> -o ./unfix-td-problem在 GitLab CI 环境中设置以下环境变量自动进入 MR 审查模式：
CI_MERGE_REQUEST_ID或MERGE_REQUEST_IDSOURCE_BRANCH/CI_SOURCE_BRANCHTARGET_BRANCH/CI_TARGET_BRANCH
WNS Code Review 技能 v3.0 语义+机械双轨编排 | 场景差异化审查 | 2026-03-25