用途
Structure Review 用于审查代码结构，围绕两个问题：每一处结构是否在当前就物有所值，以及是否缺少能让代码更易导航和理解的结构。
过度结构（推测性抽象、过早泛化）会掩盖真实流程；结构不足（扁平目录、职责混杂、所有内容集中在一个文件或层级）会迫使读者扫描无关代码才能找到所需内容。
主要能力
该技能提供一套结构审查工作流，包括：
- 将审查锚定在真实代码上：阅读变更文件、附近接口以及受影响的测试或文档，并将每个变更文件分类为必要结构、当前即可回本的可读性结构、或推测性低价值结构。
- 查找过度结构信号：例如当前行为几乎不涉及的额外数据库列、JSON 字段、DTO 属性、配置键或钩子；增加跳转却不改善命名、复用、不变量或边界的辅助函数或包装器；调用方仍需了解抽象声称隐藏的内部细节；没有具体第二用途的扩展点、策略对象、插件钩子或标志；纯粹为保持泛化而存在的映射对象或转换层；围绕仍只有一条具体路径的概念的多层间接；实践中只有一种情况有效的选项、枚举或模式开关；在具体消费者、生产者或不变量需要之前添加的状态或持久化；增加查找难度而非理解度的模块拆分或目录嵌套。
- 查找结构不足信号：例如一个目录有 10 个以上文件且跨越三个或更多不相关关注点而无子目录分组；模块公开接口混杂调用方必须自行过滤的能力；总是一起变更的文件在树中相距甚远而无关文件相邻；文件系统树无法传达项目主要关注点，新读者无法预测去哪里查找；单层目录可拆分为两到三个各自命名清晰职责的子目录。
- 检查结构是否物有所值：询问额外层现在带来了什么，如更清晰的名称或调用点、更强的类型边界、更清晰的归属边界、减少重复分支或胶水代码、更简单的不变量、隔离丑陋的外部细节、更清晰的文件或目录级理解。
- 保持高变更门槛：不因某物抽象就建议移除，不因目录文件多就建议嵌套，不惩罚显式代码，不将可读性结构视为浪费。仅在额外结构带来持续维护成本、掩盖真实流程或主要为当前不需要的未来而存在时，才建议简化；仅在扁平布局迫使读者定期扫描无关代码或职责混杂造成真正混淆时，才建议重组。
使用方式
该技能以工作流形式使用，审查时按以下步骤进行：
- 锚定审查：阅读变更文件、附近接口、受影响的测试或文档，将每个变更文件分类。
- 检查过度结构信号：对每个变更文件和目录逐项核对上述信号。
- 检查结构不足信号：对每个变更文件和目录逐项核对上述信号。
- 检查结构是否物有所值：询问额外层当前带来的收益，若答案薄弱或假设性，则视为简化候选。
- 保持高变更门槛：仅在有充分理由时建议简化或重组。
输出报告时使用以下结构：
- Findings：仅列出有代码支持的具体结构问题，无论过度结构还是结构不足。对每个问题解释当前形态为何似乎不抵成本，或缺失结构为何损害导航。当代码本身是重点时，附上简短嵌入片段或目录列表。
- Keep As-Is：指出乍看可能显得沉重或扁平但值得保留的选择，说明它们当前提供的收益。
- Restructure Candidates：仅包含通过上述门槛的变更。对每个变更说明：最小合理变更（简化、重组、拆分或合并）；将移除、折叠或重新分组什么；将获得什么；可能失去什么；为何现在是或不是合适时机。
- Open Questions：列出可能证明当前形态合理的缺失约束或未来需求。
- Verdict：以以下之一结尾：Structure is appropriate；Small restructure is justified；Broader reorganization may help, but only after clarifying constraints。
片段规则：优先使用嵌入片段而非编辑器风格的行引用；将源文件路径作为注释放在每个片段第一行；保持片段紧凑，签名、模式定义、包装器、配置形态和转换层通常足够。
沟通规则：默认给出最小有用建议；如果代码已经适当精简，直接说明；如果某个关注点合理但支持薄弱，标记为观察项而非建议；不要为了显得审查有用而制造简化机会。
适用场景
适用于被询问代码是否过度工程化（推测性抽象、额外层等），或需要评估代码组织是否合理、是否存在结构不足时。
限制
资料未提供该技能的具体安装命令、平台支持、收费信息或效果保证。