用 Skills 把业务缺陷检测前移到编码阶段

多数团队并不缺少静态扫描和代码规范，真正棘手的是业务缺陷：规则分散在 PRD、TRD、历史对话和 Wiki 中，开发在 IDE 内很难持续拿到“当前场景下的正确规则”。

结论先行：要降低这类缺陷，核心不是再加一个离线质检平台，而是把质量能力直接做成可调用的 Skills，放到开发者的编码主路径里。

业务缺陷与通用代码缺陷的差异在于，它高度依赖上下文。

• 通用缺陷有确定答案，静态工具可覆盖
• 业务缺陷依赖规则、时序、角色、边界条件，通常需要“知道背景”

当规则与代码分离时，团队会出现三个高频问题：

1. 需求碎片化，关键约束藏在多源文档中
2. 知识隐性化，规则依赖个人经验而非系统沉淀
3. 反馈滞后，问题常在提测或上线后才暴露

这本质上是认知负荷问题，而不是编码能力问题。

推荐把质量检查拆成可复用的原子 Skill，并串成一条有数据依赖的流水线，而不是零散工具调用。原因很直接：每一步输出都是下一步的上下文约束，串行能显著降低误判。

实践中，这条链路可以抽象为五步：

1. codebase-insight-analyzer：建立仓库级技术画像（架构、核心域、调用路径）
2. prd-function-extractor：把 PRD 规则提炼为结构化约束
3. trd-spec-extractor：把业务规则映射为代码层面的可验证规格
4. function-level-defect-tracer：基于 diff 聚焦函数级变更并过滤噪音
5. business-rule-defect-detector：结合前四步证据给出缺陷判定与修复建议

这套设计的关键收益不是“更智能”，而是“更稳定”：规则在上下文里持续传递，检测结果具备可解释性。

实际落地时，最容易被忽略的是第 2~3 步的语义对齐。

如果缺少“PRD 规则 -> TRD 约束 -> 代码检查项”的映射，检测系统会退化成普通 lint，无法回答业务正确性问题，例如：

• 时间规则是否按用户时区而非服务器时区计算
• 特殊消息类型是否有豁免路径
• 状态机跳转是否符合业务边界

因此，推荐把“规则映射产物”以结构化 JSON 持久化，并作为后续检测的唯一判定依据。

对于 Flutter/iOS/Android 协作团队，建议从高风险业务链路试点，而不是全量铺开：

1. 先选一个跨端一致性要求高的场景（如消息、支付、会员权益）
2. 仅固化 P0/P1 业务规则，避免早期 Skill 过重
3. 将 Skill 输出接入现有评审流程（PR comment 或文档报告）
4. 每两周回收误报/漏报并迭代 Prompt 与规则

推荐优先级：先做“规则显式化 + 变更聚焦”，再做“自动修复建议”。

若你要快速验证收益，可以先落地这个最小闭环：

• 输入：PRD 链接、TRD 链接、当前 diff
• 输出：
  • 结构化规则清单
  • 变更影响函数列表
  • 缺陷列表（含定位、触发条件、修复建议）

当团队能够稳定得到这三类产物时，业务缺陷检测就已经从“事后发现”转为“编码期拦截”。

这篇实践的价值不在于“又一种 AI 用法”，而在于给出了一个可工程化的质量前移路径：

• 人负责规则定义与价值判断
• Agent 负责规则记忆、变更对齐与一致性检查

当质量规则真正住进 IDE，研发流程才会从“靠经验兜底”转向“靠系统兜底”。