zfl-skill-absorb-audit
同事技能吸收与对抗审查的可复现测试引擎。v1 是纯方法论 SOP；v2 升级为
带可执行 harness + 量化评分卡的引擎——把"装技能→跑通→找出真缺陷→出报告"
从一次性操作变成可回归、可机读、可门禁的流程。
0. 如何触发（一句话上手，普通用户直接照抄）
自然语言触发：直接对我说下面任一句即可加载本技能走审计——
- "帮我审查这个技能
C:/Users/.../某技能" - "审计一下
~/skills/某技能有没有安全隐患" - "这个技能能不能装？先帮我测一遍"
- "对 XX 技能做对抗审查 / 暴露问题 / 回归一下守卫"
最简命令行（只需一个目录参数，全自动）：
cd ~/.workbuddy/skills/zfl-skill-absorb-audit
python scripts/audit_skill.py ~/.workbuddy/skills/某技能
# → 自动跑：安全门禁 + 规范 + 触发自洽 + 资源代价，产出 JSON+MD 报告
# 可选：--name 某技能 --json out.json --md out.md -v(异常看堆栈)
> 不想写任何用例、不想装任何外部技能，上面这一条命令就能用——这是开箱即用零配置审计包。
> 进阶：要测特定技能的功能缺陷，再为它写 cases_*.py（参考 cases_demo.py）。
1. 定位与能力边界（消除重叠，防漂移）
> 能力边界与限制清单（一眼看完）：本技能是测试执行引擎，明确不做以下事——
> - ❌ 不做吸收决策：只给"能不能吸收"的客观门禁证据，装不装由你/absorb-sop.md 决定。
> - ❌ 不执行被审技能做运行时污点分析：安全门禁是纯静态文本扫描（只读源码，绝不运行目标）。
> - ❌ 不替代多角色定性评审：多专家打分/薄弱项交给 zfl-expert-review（阶段5.7 桥接）。
> - ❌ 不保证发现所有漏洞：覆盖安全/触发/规范/资源代价等可机审维度；业务逻辑正确性需人工+真实样本复核。
> - ❌ 不处理网络/远程技能：纯本地审计，不拉取线上仓库、不发任何网络请求。
> - ❌ 不修改被审技能：只读审计，产出报告给你/作者，不改对方代码。
> 其余能力（触发率、增益/资源代价、可视化看板）见各阶段说明，缺外部协作技能时自动降级。
本技能 = 测试执行引擎（跑对抗用例 + 采证据 + 出评分卡）。下列能力不重造，复用既有：
| 职责 | 复用对象 | 何时 |
|---|---|---|
| 多角色专家评分/薄弱项 | zfl-expert-review（15 角色池） |
P1-4 已落地：阶段 5.7 用 expert_handoff.py 产 brief 桥接，证据齐后做多专家定性汇总（absorb-audit 不再写多专家评分） |
| 安全/越权/注入/外传门禁 | 内置 scripts/security_gate.py（复用 skills-security-check 云鼎的确定性规则） |
阶段 0 自动门禁（harness --skill-dir 触发） |
| 隐私/PII 硬编码专项 | 内置 scripts/security_gate.py 的隐私子集（对齐 zfl-redaction 高精度敏感类规则） |
阶段 0 自动门禁的"隐私泄露"类别 |
| 多源覆盖无守卫专项 | 内置 scripts/security_gate.py 的表驱动取主覆盖判据（防首选源脏时静默污染产物）+ scripts/measure_reconcile_scope.py 生态度量器（靶例覆盖断言，防「空洞的零」，PF-623） |
阶段 0 自动门禁的"多源覆盖无守卫"类别 |
| 触发率/触发卫生测试（TRACE·A） | 内置 scripts/trigger_test.py（词法近似 WorkBuddy frontmatter 匹配） |
P1-5 已落地：阶段 5.6 用 --trigger-corpus 触发，验证召回/精确/碰撞 |
| 增益与资源代价测试（TRACE·E） | 内置 scripts/effectiveness_test.py（no-skill 基线对照 + 资源代价确定性统计） |
P1-6 已落地：阶段 5.8 用 --baseline 触发，验证净增益 + 注入上下文规模 |
| 吸收决策流（是否吸收/集成形态） | zfl-skill-factory/references/absorb-sop.md |
本技能是其"步骤7 测试引擎"的实现 |
> 与 absorb-sop.md 的边界：absorb-sop = 决策流（装不装、怎么集成）；
> 本技能 = 测试引擎（怎么测出缺陷、出报告）。两者单一可信源，勿在别处重复维护。
> 详细调用命令、技术方法论、各阶段完整指令（含阶段 0/3/5.5/5.8）已外置至 references/implementation-details.md，AI 执行时照读。
1. 六阶段 SOP（v2）
阶段 0.5 · 吸收前快照评估（轻量前置，决定是否值得装）
目的：在「安装实测」之前，先用静态核对判断这个外部/同事技能是否值得吸收，
避免把"文档吹牛版 / 倒退版"装进体系、浪费后续测试成本。
输入：技能 zip 或目录。zip 先解压到沙箱临时目录（不污染 ~/.workbuddy/skills/）。
- 提取声称能力：读 SKILL.md frontmatter + 版本记录，列「声称能力清单」
（检测项 / 触发场景 / 报告格式），尤其盯版本记录里的"新增"条目。 - 能力重叠矩阵：定位自有对应技能（必须验证实际在装目录，教训 #28），
逐项标已覆盖 / 自有更强 / 缺失 / 退化。 - 文档/代码一致性门禁（P0）：声称能力是否真有函数实现？
抽查声称检测项 →Grep脚本确认函数存在且被主流程调用。
文档声称但代码无 → 记「文档吹牛」P0 缺陷：吸收前必须先把代码落地或从文档删掉，
否则等于吸收空壳（本生态五源齐改纪律的反面教材）。 - 架构判定（LLM vs code）：统计/数值核心（末位分布计数、等差间距、CV、跨盘指纹、
dB/km 归一化）必须由代码实现；若技能意图让 LLM 直接算这些 → 判架构缺陷
（LLM 在数百行数据上会编数、不可复现、过不了回归）。正确架构：
LLM 路由/选检测器 → 代码算确定性统计 → 返回 JSON → LLM 翻通俗结论。 - 吸收判定：
- 重叠矩阵「全量已覆盖且自有更强」→ 否决吸收（倒退风险 + 双实现冗余）。
重叠矩阵的能力覆盖度检索腿：python ~/.workbuddy/skills/zfl-common/scripts/grep_redundancy.py <kw1,kw2,...> --skills-dir ~/.workbuddy/skills --json（公共标准件，结构化命中表 + 自动跳噪声目录，@see zfl-common）。
- 有净增量且无 P0 文档/代码不符 → 进入阶段 1 安装实测。
- 有 P0 文档吹牛 / 架构缺陷 → 先打回同事修复，或仅吸收已落地的正项。
输出：吸收前评估卡（覆盖矩阵 + 文档代码一致性 + 架构判定 + 吸收结论），
作为阶段 1 的输入；否决时直接终止流水线，不进入安装。
阶段 1 · 安装与映射
- 解压到沙箱，读
SKILL.mdfrontmatter /scripts//references//assets/。 - 定位自有对应技能：必须验证实际在装目录，不要凭记忆（教训 #28）。
- 画"同事 vs 自有"功能对照矩阵，标 P0/P1 高价值项。
阶段 2 · happy-path 真实场景
- 用用户给的真实指令格式跑主流程（不编简化输入）；案例用工作区真实样本。
- 验证：正常用例能生成、内容合规、关键字段正确填充。
阶段 4 · 对抗审查（核心，harness 驱动）
- v2 改为 harness 驱动：把对抗用例写成
tests/cases_*.py，用
scripts/audit_harness.py真实调用目标脚本、按可观测结果判定、量化评分。 - 自带用例包：
tests/cases_demo.py— 自验证包（内置 mock 目标，无需外部技能即可跑，证明引擎可用）。tests/cases_supervision.py— 真实监理技能回归包（调zfl-supervision-log-generator的
旁站/日志脚本，验证日期/工序/安全门禁 exit code）。- 写新用例包：复制
cases_template模式——@case(id, 维度, 严重度, 描述)装饰函数，
函数体真实调用目标、返回Finding(passed, observed)。维度词含 TRACE 关键词
（安全/隐私/鲁棒/边界/触发/规范/有效）以便自动归入五维。
跨专业对抗要点（本次实测，P1-7）：域内 happy-path 全对，缺陷全在"相邻但错误"的跨边界输入。
写对抗用例时：
- 用四维模板：happy(域内正确) / robust(空·数字·脏输入) / coverage(KB应支持却未入库) /
adversarial(跨专业误标·应是X却报Y)。
- 直接 import 被测函数调用（非 subprocess）：Windows 下密集子进程会静默崩；import 模式更可控、
可落 JSON 证据、可入 CI。示例见 tests/cases_peer_cross_professional.py。
- 安全/有限空间门禁要专测"应 CLEAR 却报 AMBIGUOUS"的相邻场景（云/IDC「平台」、室内「楼梯」），
同源技能（如 zfl/jianli 共享 clarify）要整组扫、整组修。
- 知识库类技能要专测"该支持却没支持"的条目（matched:false 覆盖缺口），不止测已入库项。
阶段 5 · 缺陷矩阵 + 量化评分卡（确定性门禁，非多专家定性）
- 本阶段产出的是确定性客观门禁（CI 退出码，回答"能不能吸收"），不是多角色定性评分——
多角色定性汇总/薄弱项/优先级交由阶段 5.7 的zfl-expert-review完成（见 §0 能力边界与references/reuse_map.md）。 - harness 输出双产物：
audit_report.json（机读，供治理/门禁消费）+audit_report.md（评分卡+缺陷矩阵）。 - 评分：基础 100，按失败严重度扣分（P0 -25 / P1 -15 / P2 -8 / P3 -3），得 A-F 等级与门禁结论
（P0 失败或 <60 分 →BLOCK，否则PASS）。对齐 Skill Security Checker 形态。 - 每个失败用例四要素：现象 → 证据(实测 observed) → 根因 → 修复建议，证据来自真实调用结果。
- 第二份报告：自有技能对照核查（见 §3）。
阶段 5.6 · 触发率测试（TRACE 的 A 维度，--trigger-corpus）
- 加
--trigger-corpus <json>时，在功能用例之前跑scripts/trigger_test.py：
从被测技能 SKILL.md frontmatter 提取声明触发词（触发场景/trigger/触发/description），
对语料做词法匹配（近似 WorkBuddy 的 frontmatter 匹配；非线上真实匹配，仅暴露过窄/过宽/碰撞）。 - 三类指标：
- 召回率（Recall）：
should_trigger语料中，被声明触发词命中的比例 → 暴露「触发过窄」（口语/同义漏触发）。 - 精确率（Precision）：
should_not_trigger语料中，未误命中其他技能的比例 → 暴露「触发过宽」（单 token 误命中）。 - 碰撞（Collision）：声明触发词与
siblings技能触发词重叠 → 暴露「抢触发」（与既有技能触发词撞车）。 - 缺陷映射（合并进评分卡 TRACE·A，缺陷号
TRG-NN）： - 召回缺口 → P2（「召回缺口」）
- 误触发/触发过宽 → P1（「误触发/触发过宽」）
- 触发碰撞 → P2（「触发碰撞」）
- 声明触发词为空/无法解析 → P1（「触发缺失」）
- 门禁：
--trigger-corpus存在 P0/P1 触发缺陷 → 退出码 1（CI 可用）。报告含trigger段 + 「触发率测试」小节。 - 语料 JSON 结构（参考
tests/trigger_corpus_template.json）：
{
"skill": "被测技能名",
"should_trigger": [{"q": "用户原话", "intent": "期望触发意图"}],
"should_not_trigger": [{"q": "用户原话", "expect_skill": "期望命中的其他技能"}],
"siblings": {"兄弟技能名": ["其触发词", "..."]}
}
- 独立运行：
python scripts/trigger_test.py --skill-dir <技能目录> --corpus <语料.json> [--json][--md]。
阶段 5.7 · 多专家汇总复用（zfl-expert-review 桥，P1-4）
分工红线：阶段 5 的 audit_report.json 是确定性客观证据 + CI 门禁（回答"能不能吸收"）；
多角色定性汇总、薄弱项识别、Top3 改进、优先级排序属于 zfl-expert-review（回答"怎么改更好"）。
absorb-audit 不重造多专家评分逻辑——用桥接脚本把证据包交给 zfl-expert-review。
桥接步骤：
1. harness 跑完 → audit_report.json（确定性门禁，含 TRACE 五维 + 安全 + 一致性）。
2. 产 brief（事实底座，等价于 zfl-expert-review 的 review_preflight.py E1 角色）：
3. 把 expert_review_brief.md 作为事实底座，加载 zfl-expert-review，
按 brief 推荐的证据驱动角色集（见 references/reuse_map.md §2）做多角色定性评审。
4. 两份产物互补：audit_report.json（门禁证据）+ zfl-expert-review 结论（定性建议）。
角色推荐逻辑（evidence-driven，zfl-expert-review 最终从 15 角色池挑 3~12）：
- 安全/隐私/越权（TRACE·T / Malicious·Suspicious）→ P3（安全监理）+ C1（合规）
- 一致性不稳定 / 可靠性失败（TRACE·R）→ S1（稳定性策略）
- 触发/适用失败（TRACE·A）→ I1（跨行业扩展）
- 存在 P0 缺陷（架构/文档吹牛/LLM-vs-code）→ P1（总监）+ P2（专业）
- 规范/文档失败（TRACE·C）→ C2（内容生成/SKILL.md 瘦身）
- 有效/正确/完整失败（TRACE·E）→ P2（专业）+ P5（质监）
- 基座必含 E1（事实底座）；产品经理透镜默认含 M1。
> 复用地图与完整衔接规则见 references/reuse_map.md。
阶段 5.9 · 看板化交付（zfl-audit-charts，P1-7）
把阶段 5 的确定性评分卡转为可视化看板，便于给非技术干系人（总监/业主）快速读结论。
- 聚合契约（audit 模式）：顶层
kpis（支持display:gauge评分环）+files_audited[].issues[]
（四要素：desc/severity/rating/source/prediction/basis/suggestion），详见zfl-audit-charts的
references/json_contract.md。 - 转换：harness 的
audit_report.json（findings 列表）映射到上述契约——每条 finding 映射为一个
file_name，失败 finding 展开为issues[]，评分由100 - Σ严重度扣分得出填入kpis.gauge
（动态判定版，遍历 findings 实时计算，不依赖硬编码缺陷表）。字段契约见zfl-audit-charts
的references/json_contract.md；本技能tests/make_dashboard_input.py提供可直接复用的转换器。 - 出图（命令见 references/implementation-details.md）：
- 看板含：评分环、结论饼图、模块柱状图、明细表、整改闭环工作台（issues 可点选 待整改→已整改→已复核）。
- 跨专业对抗模板：
tests/cases_peer_cross_professional.py（import 函数模式 + 四维用例，规避 Windows 密集 subprocess 不稳）。
阶段 6 · 优化建议书交付（可转发给同事/外部作者）
把阶段 1–5 的发现沉淀为一份可转发的优化建议书（Markdown + Word 双格式），
格式与脱敏规则固定，避免每次现写 python-docx、格式漂移。
输入：一次审计的发现写成 JSON（字段见 references/proposal_schema.md），
含 skill_name / version / author / diagnosis / p0 / p1 / p2 / architecture / action_plan / acceptance。
脱敏规则（默认遵守）：不写本生态私有信息（技能 id、私有路径、zfl- 前缀技能名、内部纪律编号）；
引用自有技能作对照时用泛称（"成熟做法"/"参考实现"），结论仅针对代码质量、不含业务数据真伪判定。
产出 ./out/<skill_name>_优化建议书.md 与 .docx（命令见 references/implementation-details.md）。
结构固定七节：总体诊断 → P0 阻断 → P1 检测质量 → P2 工程化 → 架构原则(LLM-vs-code)
→ 优先级行动清单 → 验收标准。与 audit_report.md（机读评分卡）互补：
前者给同事看、促其改进；后者给自己看、做吸收决策。
2. 防误判纪律（命门，v1 沉淀，保留）
- 不靠独立脚本 exit code 判门禁：仅主流程脚本（被 harness 直接调用的入口）的退出码可靠；
独立子脚本 print 不设退出码时，须读 stdout 或从主流程跑。 - 取产物用精确路径，绝不
sorted(glob(*.docx))[-1]（文件名含年份会取错）。 - Bash 内联 heredoc 含反斜杠/长命令易拒：写提取脚本到
.py再跑（教训 #23）。 rm -rf会被 safe-delete 守卫拦截：用新输出目录隔离，不删旧产物。- 验证修复必须复现负向用例：修了 P-1/P-2 后，重跑"非法日期/空工序"确认被拦，再跑正常用例确认仍通过。
3. 自有技能对照核查模板
拿到缺陷清单后反查自有技能是否同款（触发路径不同但漏洞同类）。对照表格模板已外置至 references/implementation-details.md。
自有也存在 → 加校验+非零退出，升版五源齐改，自测闭环。可用 cases_supervision.py 模式
把自有脚本的守卫固化成回归用例，防止回退。
4. 修复落地 SOP（当授权修复）
- 读目标脚本定位插入点（
Grep函数签名 /add_argument/sys.exit）。 - 加门禁：非法值 →
sys.exit(11/12/2)并打印字段提示；空值 → 非零退出。 - 吸收正项（如安全门禁）焊进主流程做双保险（文档级+代码级）。
- 自测四用例：非法/空 → 拦；正常/清晰 → 过（写进
tests/cases_*.py防回退）。 - 版本步进：frontmatter + metadata + VERSION +
_skillhub_meta.json+ CHANGELOG 五源齐改（教训 #24）。 - 决策固化：设计取舍（如"刻意不开放
--force"）写进 SKILL.md，避免返工。
5. 调用时机
用户说"测试同事技能""对抗审查""暴露问题""我自己有没有这个坑""吸收评估""回归守卫"时，
加载本技能走六阶段，优先用 harness 跑既有/新建用例包，不即兴发挥。
6. 快速开始
> 一句话零配置审计（最常用，只需一个目录参数）：
> bash
> cd ~/.workbuddy/skills/zfl-skill-absorb-audit
> python scripts/audit_skill.py ~/.workbuddy/skills/待测技能
> # 自动产出 ./out/<技能名>_audit.json 与 .md（安全门禁+规范+触发自洽+资源代价）
>
> 首次想看自己装了哪些协作技能、缺哪些，先跑 python scripts/setup_check.py。
> 等价的底层命令（想精确控制时用）：
> bash
> python scripts/audit_harness.py --cases tests/cases_universal.py \
> --skill 待测技能名 --skill-dir ~/.workbuddy/skills/待测技能 \
> --json tests/out_universal.json --md tests/out_universal.md
>
> 进阶：要测特定技能的功能缺陷，再为它写 cases_*.py（参考 cases_demo.py）。
> 完整调用命令清单（自验证 / 触发率 / 增益与资源代价 / 看板化 / 优化建议书）已外置至 references/implementation-details.md，AI 执行时照读。
> 复用地图（何时调 zfl-expert-review / skills-security-check / zfl-redaction / absorb-sop.md）：
> 见 references/reuse_map.md。
> 常见问题与错误避坑（中文路径/无skill-dir/非UTF8/外部技能缺失/CI退出码/Windows子进程）：
> 见 references/FAQ.md。
