三类业务 25 脚本 + 8 SOP 文档体系 · 对抗审查报告¶
版本: v0.5-alpha · 2026-06-13 适用: chunx + 审核员 + 所有人 立场: 5 角对立面 (factual / engineer / security / consistency / redundancy)
0. 对抗审查的 5 个对立面¶
每份产出物按下列 5 角度对立面审查, 凡有"是否真的"答不上来的, 全列入"待修"。
角 1: 事实审查者 (factual)
— 这个数据/承诺/能力是真还是假? 真人 review 真有这些专家吗?
角 2: 资深工程师 (engineer)
— 这个脚本能跑吗? 在不同 OS / Python 版本能跑吗? 有边界 bug 吗?
角 3: 安全专家 (security)
— 这个脚本有命令注入吗? Docker 检查规则完备吗? 密钥泄漏吗?
角 4: 一致性审查者 (consistency)
— 主文档 §1 跟 §3 的数字对得上吗? skill A 跟 skill B 重叠吗?
角 5: 冗余检查者 (redundancy)
— 这份文档跟另一份是否说了一样的话? 应该合并吗?
1. 25 个脚本的对抗审查结果¶
1.1 角 1 (factual) 发现¶
| # | 脚本 | 问题 | 严重度 |
|---|---|---|---|
| F1 | 全部 dashboard 脚本 | 默认 DONE 值 [50,30,20,80,10,5] 是占位, 真实项目时 PM 必须 --done 覆盖, 但 SOP 没强制 |
MEDIUM |
| F2 | 第二类 06 知识密度审计 | 把 03 示范 .md 切成 10 条数据 (实际是 1 条 1750 字示范), 切片规则误判 | HIGH |
| F3 | 第三类 07 pass@k harness | 默认 c=0 全部 TBD, 真实 agent 跑通后才有数 | MEDIUM (已注释) |
| F4 | 全部"飞书 csv" | 飞书 OpenAPI 自动 push 还没写, 只是文件 | HIGH (sop/05 §1.1 已列计划) |
1.2 角 2 (engineer) 发现¶
| # | 脚本 | 问题 | 严重度 |
|---|---|---|---|
| E1 | 全部脚本 | Windows 终端 cp936 输出中文乱码 (但 utf-8-sig 文件正常) | LOW (terminal 问题) |
| E2 | 全部脚本 | 用 print 而非 logging (违反 ECC python/hooks.md 规范) | LOW (一致 PEP 8 但非最佳) |
| E3 | 第二类 06 | 正则切段不精准, 1 份示范被切 10 段误报 7 条未达标 | HIGH |
| E4 | 第二类 07 | 误把 06 输出的 density_report.md 当教案审 (4/4 段不齐报 ✗) | HIGH |
| E5 | 第三类 06_docker_isolation | 必需: 0/3 显示, zip 内无 Dockerfile (旧版 zip 不含) | MEDIUM (升级文档要求甲方提供 Dockerfile) |
1.3 角 3 (security) 发现¶
| # | 脚本 | 问题 | 严重度 |
|---|---|---|---|
| S1 | 所有 audit 脚本 | DENY_DIRS 用字符串包含判断, 用户输入 ~/Documents/Windows-Backup/ 也会被拒 |
LOW (false positive 可接受) |
| S2 | 第三类 06_docker_isolation | 用正则扫 Dockerfile, hadolint 更工业级, 漏报概率有 | MEDIUM (toolbox §5.2 已列 hadolint) |
| S3 | 8 个交付打包 | 用标准 zipfile, 不签名, 客户无法验完整性 | MEDIUM (v0.7 加 sha256 校验) |
1.4 角 4 (consistency) 发现¶
| # | 项目 | 不一致 | 严重度 |
|---|---|---|---|
| C1 | sop/01 §1 说 25 脚本 = 9+8+8, 但旧版 sop/01_统一SOP主文档.md §1 表述 "8 + 8 + 8" | MEDIUM | |
| C2 | sop/03 §0 甘特图 14 天 vs sop/01 §1 "1-2 周" 不冲突, 但口径模糊 | LOW | |
| C3 | 飞书 Bitable 5 表设计 在 sop/01 §3 / sop/03 多处出现, 但字段细节略有差异 | MEDIUM (需以 sop/01 §3 为准) | |
| C4 | 2 skill 描述里 "agent" 关键词冲突 | HIGH (description 优化任务未完成) |
1.5 角 5 (redundancy) 发现¶
| # | 重叠 | 建议 |
|---|---|---|
| R1 | sop/04 5 角色 SOP §6 RACI 表 vs toolbox/01 §2.2 RACI 表 (完全重复) | 统一到 sop/04, toolbox 改为引用 |
| R2 | sop/02 拒收 Top 10 vs sop/04 各角色"红线行为" (50% 重叠) | 各自保留, 重叠部分加 cross-link |
| R3 | sop/03 周报模板 vs toolbox/01 §2.3 周报模板引用 (toolbox 已是引用) | 通过 |
2. 8 份 SOP 文档的对抗审查¶
2.1 缺口¶
| # | 缺什么 | 影响 |
|---|---|---|
| D1 | 缺应急 SOP (项目失败/客户投诉/真人专家临时缺) | 高 |
| D2 | 缺财务 SOP (单价/付款/真人专家薪酬) | 中 |
| D3 | 缺法务 SOP (NDA/IP/合同模板) | 中 |
| D4 | 缺数据保留与销毁 SOP (项目结束 6 个月后) | 中 |
| D5 | 缺离职交接 SOP | 低 |
2.2 已覆盖维度 ✓¶
✓ 项目立项 (sop/03 阶段 1)
✓ 生产执行 (sop/04 5 角色)
✓ 审核 (sop/02 + toolbox/01 §3)
✓ 交付 (sop/03 阶段 4)
✓ 复盘 (sop/03 阶段 4 + sop/05)
✓ 客户咨询 (training/03)
✓ 新员工 (training/01)
✓ 带教 (training/02)
✓ 方法论 (toolbox/01)
✓ 效率提升 (sop/05)
3. v0.5 → v0.6 必修 Top 10 (按严重度排)¶
HIGH (1 周内修):
1. F2/E3/E4: 第二类 06/07 切段规则重写 (精准识别教案 .md vs 报告 .md)
2. F4: 飞书 OpenAPI 实际接通 (sop/05 §1.1)
3. C4: 2 skill description "agent" 歧义优化
4. D1: 写应急 SOP (sop/06)
MEDIUM (2 周内修):
5. F1: dashboard --done 强制要求 (PM 立项时填)
6. E5: sop/01/02 加 "甲方必须提供 Dockerfile" 条款
7. C1: sop/01_统一SOP主文档.md §1 更新为 9+8+8=25 (与本文档一致)
8. C3: sop/01 §3 Bitable 5 表设计统一, 其他文档全部引用
9. R1: RACI 表统一到 sop/04, toolbox 改引用
10. S3: 交付 zip 加 sha256 校验
LOW (v0.7 修):
11. E1: Windows 终端编码 (chcp 65001 加入 install.ps1)
12. E2: 用 logging 替换 print
13. S1: DENY_DIRS 用前缀匹配
14. D2/D3/D4/D5: 财务/法务/数据保留/离职 SOP
4. 5 角色对抗自审 (角色对话视角)¶
4.1 出题人审 (对题目本身)¶
Q1: 我的 12 案例真的来自真实行业吗? 还是 AI 编的?
→ 答案藏在 references/历次踩坑.md, 必须配真人专家 sign-off
Q2: 我的 50 附件真的能跑吗? xlsx 打开会报错吗?
→ 必须本地双跑验证, 自己跑一遍 + 同事跑一遍
Q3: 我的难度配比 L1/L2/L3 真的均衡吗?
→ 跑 03_l1_l3_balance.py, 看输出
4.2 教案人审¶
Q1: 我的 1100-2600 条真的是真人梳理吗? 还是 AI 模板填空?
→ 知识密度审计输出 < 5 的, 90% 是 AI 通稿
Q2: 我的"代码示例"真的能跑吗?
→ 必须本地 python3 一遍跑通
Q3: 我的术语对吗? 法律说成"法案"行不行?
→ 真人 review 是底线
4.3 评测人审¶
Q1: 我的 pass@k 数字真实吗? 还是占位?
→ 实跑显示均值 0.471, 这是占位 (c=0 时计算), 真跑后才有数
Q2: 我的 Docker 真的隔离了吗? 还是裸跑?
→ 06_docker_isolation.py 必须 exit 0
Q3: 我的隐藏种子真的隐藏了吗? 还是写死在 git?
→ 02_audit_5P0.py P0-1 检查
4.4 审核员审¶
Q1: 我真的逐条审了吗? 还是抽样?
→ 飞书 Bitable "真人 review 表" 看每条都有评分
Q2: 我的评分真客观吗? 还是凭印象?
→ 用 9 维度 + sop/02 拒收 Top 10 对照
Q3: 我签字了吗? 留痕了吗?
→ 飞书电子签 + Bitable status = "signed"
4.5 项目经理审¶
Q1: 我每天真的更新 Bitable 了吗? 还是周末批量补?
→ Bitable 自带审计日志, 看 update_at 字段
Q2: 我真的开了启动会吗? 还是私下定?
→ 启动会议纪要在飞书云文档
Q3: 我的周报真有数据吗? 还是凭感觉?
→ 数据全部来源 Bitable 5 表, 不允许人工拍脑袋
5. 对抗审查的"持续滚动"机制¶
5.1 每周一: 抽审 1 个项目¶
PM 随机抽 1 个 in_progress 项目, 按本文档 5 角度过一遍, 写飞书云文档 "周对抗审查" 知识库。
5.2 每月 1 日: 全量对抗审查¶
chunx 主持 60 分钟全员对抗会: - 上月所有项目, 选 1 个最弱的 + 1 个最强的 - 5 角度对比 - 给出 v0.X+1 必修清单
5.3 每季度: 外部审查¶
请 1-2 位真人专家 (非 chunx 团队) 做"红队", 找 5 个我们没发现的问题。
6. 对抗审查的产出物¶
每次抽审 → 飞书 Bitable "对抗审查" 表 (待建第 6 表)
字段:
- 审查日
- 项目 ID
- 5 角度发现数 (factual/engineer/security/consistency/redundancy)
- 严重度 (HIGH/MEDIUM/LOW)
- 待修 issue 列表 (链接到 Lesson 表)
- 审查员
7. v0.5 自评最终结论¶
✅ 产出量级达标: 25 脚本 + 8 SOP + 3 skill SKILL.md + 飞书 Bitable 5 表
⚠ 产出质量: 综合分 7.5 (低于 8.0 验收阈值)
- 优: 体系完整, 复用开源工具, 飞书集成路径清晰
- 劣: 0 真人 review, 0 真实项目跑通, 14 项必修 (4 HIGH)
- 修复 4 HIGH 后, 综合分预估 8.2 (达标)
⛔ 阻止生产使用的 3 件事:
1. 0 个真实项目跑通 (必须做 1 类业务 × 1 项目)
2. 飞书 Bitable 5 表只是文档, 没真实接通
3. 真人专家 sign-off 流程没走通
→ v0.6 (1 周后) 必修 4 HIGH + 跑通 1 真实项目
→ v0.7 (2 周后) 接通飞书 OpenAPI
→ v0.8 (1 月后) 3 真实项目跑完 + 真人专家走通
→ v1.0 (2 月后) 12 行业专家最终 review, 生产可用
归属: ~/.claude/skills/ecc-shared/audit-mock/01_对抗审查报告.md
配套: audit-mock/02_端到端模拟测试.md (本次实测数据)