代码架构雷达

为什么一次小改动会牵动几十个文件

当业务规则散落在大量浅层模块中，理解一个概念需要在多个小文件间反复跳转，修改成本就会迅速放大。一次看似简单的字段校验或流程调整，往往同时触及一组文件，容易引入回归缺陷并提高测试成本。架构问题通常不会直接报错，而是表现为变更范围失控、重复逻辑扩散和测试难以触达关键路径。

基于代码证据的审查与演进

该技能将判断建立在项目语境与代码证据之上，默认保持只读审查。它会先读取项目级说明、构建配置、测试入口和文档，提取业务词汇与现有验证命令；再通过文件检索、文本检索、调用关系抽样和版本历史收集结构证据，而不是仅凭文件名下结论。

重点识别的模式包括：模块接口暴露了全部实现复杂度、多个调用方重复相同处理逻辑、纯转发模块没有隐藏规则、内部数据结构或错误模式泄漏到外部、依赖方向指向易变细节，以及测试只能绕过公开接口触碰内部状态。每个候选项至少附上两类证据，如具体符号与调用关系、重复实现、测试缺口或共同变更记录；证据不足时标记为“待验证”。

随后技能保留少量高价值候选项，说明当前摩擦、目标结构、可收拢的职责、应保留的接缝、迁移风险、最小实施切片、验证命令和回退办法，并生成离线可读的中文 HTML 报告，绘制并列的“现状 / 目标”结构图。

适用边界与注意点

审查阶段不修改代码，也不清理用户已有改动。只有在明确授权后，才按最小可回退切片实施：先补行为保护测试，再迁移调用方，最后删除失去价值的旧结构。它区分架构问题、普通代码质量问题和个人风格偏好，不把“多建一层”自动视为改进。若现有结构已经合理或证据不足，结论也会明确建议暂不重构。