exhaustive-systems-analysis

用途：对系统及其子系统做全面深度分析，找出缺陷、竞态条件、过时文档、死代码和正确性问题，特别适用于上线前验证由智能体（Agent）编写的代码。核心原则：子系统隔离以避免上下文污染；每条问题必须引用具体代码位置；按严重程度排序，先严重后表面；直接指出问题，不模糊化。工作流程分三阶段。阶段一系统分解：读取项目结构识别模块、包或目录；追踪数据从进入到转换再到离开的流向；识别副作用（文件 I/O、网络、数据库、IPC、状态变更）；梳理子系统依赖，产出子系统表（编号、名称、文件、副作用、优先级）。优先级启发式：高为副作用、状态管理、安全、并发；中为业务逻辑、数据转换、校验；低为纯工具、格式化、日志。阶段二顺序分析：按优先级依次分析子系统；大型代码库（超过 5 个子系统或单子系统超过 3000 行）建议在子系统之间清空上下文以防分析漂移；按子系统类型套用相应检查清单，包括有状态系统、API 与网络、并发、UI 与呈现、数据处理、配置与初始化。阶段三整合：去重跨领域发现，按严重程度排序，给出建议的修复顺序。严重程度分为 Critical（数据丢失、安全漏洞、生产崩溃）、High（用户可感知的错误行为）、Medium（技术债）、Low（外观或次要改进）。每条发现需包含标题、严重程度、类型、位置、问题、证据与建议。输出可采用审计目录（适合 5 个以上子系统，含分析计划、各子系统文档和 SUMMARY）、单文档或与现有文档合并，摘要需含各严重级别总数、最关键的 5 个问题和建议修复顺序。会话管理：小型系统可单会话；中型系统在阶段间清空上下文；大型系统按子系统分会话，清空时把进度写入分析计划文件。分析前先扫描已知问题：查阅 CLAUDE.md / README 的注意事项、搜索 TODO/FIXME/HACK、回顾近期修复提交、查看问题追踪器，作为待验证或推翻的假设。应避免的反模式：略读代码、假设正确、发现模糊、范围过大、忽略测试。完成标准：所有高优先级子系统已分析，每条发现都有严重程度、位置和建议，存在含优先行动项的摘要，没有待定项，相关发现间有交叉引用。具体安装命令、收费模式、支持平台和实际效果暂未提供。