用 AI 审核 Skill 消灭"编译器不报错"的隐藏 Bug
起因：一个查不出来的 Bug
我们的 HarmonyOS 项目里有个坑：bindSheet（半模态面板）绑在同一个组件上多次时，只有最后一个生效，前面的被静默覆盖。编译器不报错、运行时不崩溃，只是某个面板"莫名其妙"弹不出来。
typescript
// ❌ 看起来没问题，编译通过，运行正常——但 showSheetA 永远不会弹出
Column() {
Text('内容')
}
.bindSheet($$this.showSheetA, this.builderA(), options) // 被覆盖了
.bindSheet($$this.showSheetB, this.builderB(), options) // 只有这个生效这类问题人工 review 很容易漏掉——代码格式完全正常，不仔细看链式调用根本注意不到。
思路：让 AI 来盯
编译器管不了的事，人盯又容易疲劳，正好是 AI 审核擅长的场景。我们做的事情很简单：
- 踩坑后沉淀规则 — 把 bindSheet 的问题写成一条审核规则（skill）
- AI 每次 review 自动执行 — 不用人记，AI 会逐文件检查
- 规则跟着项目走 — skill 文件存在仓库里，团队共享，新人也自动受保护
具体做法
我们在项目里创建了一个 review skill 文件 .qwen/skills/review-bindsheet-single/SKILL.md，内容就是告诉 AI：
审核代码时，检查是否存在同一组件多次调用
.bindSheet()的情况。发现即 blocking，必须修复。
同时给出了正确写法（用 Blank() 拆分）和错误示例，AI 审核时就能对照判断。
这样以后不管是谁写的代码、哪个模块，只要提交了多个 bindSheet 绑在同一组件上，AI 就会自动标出来：
[Blocking] 同一组件上多次调用
.bindSheet()，只有最后一个会生效（编译器不报错）。请将每个bindSheet拆分到独立组件上。
这个模式可以复用
bindSheet 只是一个例子。实际上项目里有很多"编译器不报错但逻辑有坑"的情况：
@StorageProp不配@Watch，值变了 UI 不更新- ArkTS 严格模式下对象字面量缺少类型声明
- 某些 API 在高版本 SDK 才有，低版本静默失败
每踩一个坑，就花 5 分钟写一条 review skill，AI 就永远记住了。这比写文档有效——文档没人看，但 AI 每次 review 都会执行。
价值
| 方式 | 效果 |
|---|---|
| 踩坑后口头告知团队 | 容易忘，新人不知道 |
| 写在 wiki/文档里 | 没人看 |
| 加到 CI lint 规则 | 只能检查语法层面的问题 |
| 写成 AI review skill | 每次代码审核自动执行，能理解语义，覆盖"编译器不管"的灰色地带 |
本质上，review skill 就是把团队的经验教训编码成 AI 可执行的检查项。踩坑的成本不白付，每一次都变成了长期的质量保障。
如何落地
如果你也想在项目里用这个模式：
- 在项目目录下创建 skill 文件（如
.qwen/skills/review-xxx/SKILL.md） - 写清楚：检查什么、为什么是问题、错误/正确示例、blocking 级别
- AI 审核代码时会自动加载并执行这些规则
不需要改 CI 配置、不需要装额外工具——skill 就是给 AI 看的文档，AI 看懂了就能执行。