caseHelper 复盘飞轮

思想为何在本次实践中成立

dot1x 项目没做状态矩阵分析就批量创建，66 条用例全部返工。此后硬编码了"批量创建前必须等人确认"的阻断规则。dot1x 之后所有项目再未出现批量返工。

门禁具体落在哪

Phase 0 的五步标准动作，每一步都需要人工判断：

• 状态维度拆解——人工确认哪些维度正交、哪些组合有业务意义
• 公共模版映射——人工判断哪些参数需要抓包确认
• 目录结构设计——人工审核多层业务目录是否符合组织架构
• 分析报告审批——人工放行后才能进入公共步骤创建和批量生成

最值得继续挖的人工判断

审计规则的自动生成：Phase 0 已经产出了维度拆解和状态组合表，但审计规则配置仍然是手写的。从"Phase 0 产物"到"Phase 2 审计"之间存在断裂。

全局公共用例识别：审计器识别不了 51401/51403 等全局公共用例，会误报为 COMMON_MISSING。修复方案已明确但未落地。

AI 如何通过提问辅助人工判断

留给未来的启发

思想为何在本次实践中成立

case-debugger 的定位从一开始就是"创建样本后立即跑审计，0 偏差才放行批量"。审计被定位为 CI lint 而不是事后 hotfix。链路：公共步骤创建 → 样本用例创建 → contract_smoke → case-debugger 审计 → 批量生成。

样本验证具体落在哪

• contract_smoke——验证用例结构与接口契约一致
• case-debugger——验证公共步骤引用、审计规则、参数类型
• 人工确认——样本在飞书上实际跑一遍，确认端到端链路通

最值得继续挖的人工判断

知识库结构校验：145 条公共用例 JSON 没有 schema 校验，同步脚本出 bug 可能写入缺字段的 JSON。人在"创建样本 → 跑审计"这一步无法感知数据层已损坏，错误会延迟到批量创建阶段才暴露。

AI 如何通过提问辅助人工判断

留给未来的启发

思想为何在本次实践中成立

复盘中明确识别了 6 类无用功：Lark 过度拆分、agent_service 空转、POC 停滞、skill 发现系统解决不存在的问题、早期专题脚本重复、平台 client 拆分建议。无效投入的共性：解决了一个不存在的问题。

做减法具体落在哪

• 删代码：archive 归档历史脚本，scripts 只保留当前在用的
• 砍方向：不做自动化 Phase 0、不扩展 agent_service、不做双向同步
• 收敛配置：从 4 个配置来源收敛到 1 个
• 拒绝建议：架构审阅建议拆分 platform_client，评估后决定不拆

冗余过滤器

最值得继续挖的人工判断

"不做"的边界判断：什么该砍、什么该留，不是技术问题而是判断问题。Lark 5 模块砍到 2 个是对的，但当时怎么知道"2 个就够了"？判断标准是"覆盖 90% 使用场景的模块数"——这个 90% 的阈值本身也需要定期验证。

AI 如何通过提问辅助人工判断

留给未来的启发