Axıs
技能目录

审计维度与发现分级

审计维度与发现分级

阶段 1(深度审计)的操作手册。目标是证据可复现的发现,不是印象清单。

维度清单

按仓库类型选取相关维度,不强行全覆盖:

  1. 正确性与契约
  2. 安全与隐私
  3. 架构与模块边界
  4. 代码质量与可读性
  5. 数据模型与迁移
  6. 性能与可扩展性
  7. 可靠性与失效模式
  8. 可观测性与诊断
  9. 测试与覆盖率
  10. CI/CD 与发布自动化
  11. 文档与上手体验
  12. 开发者体验
  13. 品牌与资产一致性
  14. 依赖健康度
  15. 配置与环境处理
  16. 错误处理与恢复
  17. 并发与状态管理
  18. 缓存与失效
  19. 领域能力覆盖(对标 benchmark.md 的能力清单)

证据纪律

  • 每条发现附 file:line 或可复现命令,二选一,不可都没有
  • 数字必须带口径:什么硬件、什么输入规模、warm/cold、用什么命令测的
  • 区分事实、推断、假设;假设必须标注为假设
  • 用户给的病因一律视为假设:先设计可否证它的量化实验,报数字,再修真因
  • 发现摘要在对话中交付,不止写进文档

系统问题 vs 硬件限制

测试暴露的每个问题必须先归因,再处置:

归因 判据 处置
系统问题 算法、架构、配置、并发、缓存、索引、批处理、序列化导致的瓶颈或错误 必须修,列入计划
硬件限制 同条件下换更好硬件即消失,且系统侧无可见浪费 如实标注,写入硬件需求,不假装已优化

禁双向伪装:把系统问题甩给硬件是逃避,把硬件限制包装成「已优化」是造假。

真实测试纪律

  • 使用真实数据与真实执行路径;mock 结论必须标注其作用域,不冒充端到端结论
  • 失败如实报告,不重跑到通过为止再报喜
  • 性能对比给基线与变量,单次数字不做结论

硬 bug 排查:可变红门

审计中确认 bug 类发现、或执行阶段修硬 bug 时,遵守硬门:造不出一条对该问题能变红的命令,不进入假设阶段。

  • 回路要求:确定可复现、运行快、agent 可执行、已实际跑过
  • 构造方式按场景选:失败测试 / 脚本复现 / CLI 快照 / 无头浏览器 / 回放捕获痕迹 / 一次性线束 / 属性或模糊测试 / 二分线束 / 差分对照;都不可行才退到人工操作脚本,并承认回路不在 agent 手里
  • 非确定性问题先把复现率调到可调试区间,再谈根因
  • 插桩带唯一可检索前缀(如 [DEBUG-xxxx]),修复完成 = 回路变绿 + 回归固化 + 插桩清场
  • 找不到可测试的接缝,本身记为一条架构发现

私有化部署实测

「能否流畅私有化部署」只能用实验回答:

  1. 干净环境(新容器 / 新 venv / 新机器)从零执行:clone → install → configure → run
  2. 记录每个卡点:隐性全局依赖、未文档化的环境变量、外部服务假设、硬件假设、网络假设
  3. 文档声明的硬件与系统需求必须有实测依据
  4. 卡点归因:系统问题 → 修复后再发布;环境固有限制 → 写进部署文档的前置条件

交付物视角预检

「本地能跑」与「别人拿到能跑」之间,隔着七类只在另一台机器上暴露的差异。它们共同的形状是:决定别人那台机器行为的属性,并不存在于你的工作目录里。逐项在新检上验证:

类别 失守形状 判据
权限元数据 工作树有执行位而索引里没有,本地全绿、别人 Permission denied 枚举交付集合里每个可执行文件的索引模式,不看磁盘
集合成员 磁盘上有而版本控制里没有 对每个被引用的资源问:它在不在克隆出来的树上
自动准备 由流水线创建的目录/文件一旦缺失,流水线本身永不暴露 空检跳过所有预备步骤直接跑生产命令
通配收集 空匹配照样构建成功,产出自认成功却打不开的交付物 把被通配的目录清空后跑一次,必须失败
工具差异 同名工具在别的系统上不给错、只给空值 每条测量加「取不到值即红」分支
时间与速度 拿 mtime 新旧或「至少 N 个」做闸,换环境随机翻脸 断言结构性下限,不断言经验计数
单机绿 只在一台机器上跑通过 ≠ 多平台可用 从未执行过的流水线按零证据计,单列未验证

判据权威在 axiom 11.3(判据自报分母、平坦样本致恒假、兜底下须指名通道)与三十二(批量改写的落盘门);跨环境项按四十一登记为未验证,不许由「本机全绿」推出。

发现分类

  • bug:行为与意图不符
  • 安全漏洞:可越权、可注入、可泄漏
  • 死代码:无引用、无触发路径
  • 未使用资产/依赖:存在但无消费点
  • 未完成实现:有入口无落地、有承诺无兑现
  • 缺失功能:领域能力清单中有而本仓无
  • 薄弱抽象:重复、泄漏、错层
  • 重构机会:同构可合并、复杂度可下降
  • 待讨论项:方向性分歧,须用户拍板
  • 可替换组件:有更简单或更成熟的替代
  • 可撤销组件:删掉更好
  • 可丰富项:值得做深的方向

优先级

级别 含义
P0 安全、数据丢失、发布阻塞
P1 正确性、契约破坏、严重可维护性风险
P2 架构、性能、测试缺口、DX
P3 文档、品牌、打磨
P4 可选丰富

发现记录格式

| 优先级 | 分类 | 位置 | 发现 | 证据 | 影响 | 建议 | 改动风险 |
|--------|------|------|------|------|------|------|----------|
| P1 | bug | src/x.ts:42 | … | 复现命令 | … | … | 低 |

报告结尾必须能回答:下一轮只修三个,修哪三个,为什么。