机械规则交给检查工具，判断留给评审

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

团队反复发生测试深导入，提示里不断追加“记得使用入口”。这是固定导入形状，现有检查器若未接CI，应先修接线；跨模块一致性判断仍需评审。

具体做法

读取项目脚本、检查器与CI，确认现有规则是否可用和执行。对固定语法、路径或API约束使用最便宜的现有工具规则，定义允许/禁止与生成代码范围。用正常/违规对照验证并接到适用流程；把需理解业务、跨文件权衡的部分留给评审。不要新造重复检查或将所有判断硬编码。

反例

把“不深导入”反复写进全局提示，检查器没接入也不管；用正则声称所有架构问题解决。

改进写法

复用项目导入检查，修复CI未执行的入口，编码测试必须经公开入口的规则。证明合法导入通过、深导入触发具名错误；跨文件职责与接口取舍保留评审说明。报告检查范围而非全架构保证。

为什么这样改

确定性检查能每次拦同类机械错误，不依赖记住长指令。判断型问题则需要语境，清楚分工能让自动化负责可判定内容。

如何验证

教学CI记录实际运行边界命令；故意深导入被拒、公开入口通过。禁规则漏别名需列范围缺口；已有同等规则不应再加一套重复工具。

适用边界

简单语法不能判断所有语义或设计质量，规则也可能误报。应匹配项目栈与现有流程，新增强制检查需在授权任务范围。规范文本仍可解释理由，但不是实际执行证明。