programming-design-review

# 编程设计巡检 ## 选择范围与输出 本 Skill 是已有逻辑的分析与巡检入口；[编程设计风格](../programming-design-style/SKILL.md) 是写逻辑前的设计与实现入口。任务同时包含检查和修改时，先判断已有逻辑，再在动手前应用设计规范；不把只读分析自动变成修改。 | 用户要求 | 工作方式 | | --- | --- | | 分析、梳理或理解已有逻辑 | 按问题解释实际调用链与数据来源，不强制找缺陷或生成报告 | | 命名、格式、可读性、错误处理、日志、异步或测试检查 | 代码规范审计；默认对话输出问题和证据 | | 职责、状态来源、配置扩展、重复逻辑、模块分工或架构检查 | 设计巡检；追踪相关链路，复杂关系按需配图 | | 可视化设计报告或完整图解 | 使用 [可视化报告](references/visual-design-report.md) | | 开始编写新逻辑或修改已有实现 | 在动手前转用设计 Skill，遵循授权范围，不强制先做完整巡检报告 | 两类问题可以混合，但不把简单函数审查扩成全仓架构报告。不凑问题数量，不自动建立文件、Hook 或平台；审查请求本身不授权改代码。 ## 规则只有一个来源 先读取 [编程设计风格](../programming-design-style/SKILL.md)，按其条件表加载适用参考；同一版本已读内容复用。本 Skill 不另维护一份设计规则。源文件缺失时说明哪些规范未能核对，仍可按项目明确规则检查，但不能宣称完成用户风格审查。 ## 审查顺序 1. **确定目标**：使用用户给定的文件、模块、功能或差异范围；检查相关项目说明和已有改动。单文件审查不强制要求 Git 比较基线。范围不明时从项目入口选择一个能说明理由的小范围，不默认全仓扫描。 2. **寻找证据**：先定位定义、调用者、数据拥有者、配置/持久化入口和现有检查工具，再判断。涉及表现入口时沿真实链路查到业务模块和数据源，不能只读当前 UI。旧文档与实际调用冲突时用代码、配置和历史核对。 3. **核对适用规则**：按下表寻找证据，具体要求使用设计 Skill 的对应参考。不因某个词出现就认定问题；没有证据的推断列为待确认。 4. **验证并报告**：运行与目标匹配且不超出授权的最小检查；先确认命令是否会写文件，纯审查使用检查模式。按行为风险排序，说明位置、原因、最小改法、验证结果及未覆盖范围。 | 触及问题 | 应定位的证据 | | --- | --- | | 业务状态、内容和流程扩展 | 定义数据、作用域、加载入口、执行能力；新增同类内容是否还要改业务代码 | | 前后端或多入口数据不一致 | 命令是否到达拥有者、实际写入与独立读取结果、展示来源与刷新责任 | | 逻辑/表现职责或重复规则 | 正式状态与规则的定义、调用链、其他表现入口、现有可复用模块 | | 身份、配置与缓存 | 稳定标识生成、引用关系、源数据与派生数据、失效与重建入口 | | 新旧逻辑切换 | 兼容调用、当前待删内容与历史、未提交 diff、关联入口及构建/资源清单 | | 日志与排障 | 统一入口、日志组开关、真实数据源、关联标识、调用链和关键调用堆栈 | | 多来源锁定 | 锁组、ownerKey、逐次句柄、目标范围内全部获取/释放点及重复/迟到释放路径 | | 代码规范 | 项目规则、实际代码与调用点、成功失败契约、检查命令及结果 | ## 结论格式 - **设计矛盾**：职责、数据归属、依赖或协作方式有问题。 - **代码规范问题**：命名、结构、控制流、错误处理、注释、日志、格式或测试有可定位问题。 - 每项给出文件与准确行号、违反的适用规则、触发条件/后果、最小改法和验证证据。设计类附必要的调用/数据关系；不以抽象架构术语替代具体问题。 - 区分已观察事实、推断和待确认项；没有行级证据不写成确定缺陷。证据可以支持多个问题，但不要反复粘贴同一规则。 - 没有发现时说明检查范围及验证状态，不制造候选。用户已给方向时继续该方向，不固定追加“先深入哪个”的问题。 - 未决取舍确实影响职责、数据归属、兼容性或成本时，再按设计 Skill 比较方案；不把评审意见自动扩成实施计划。