老项目研发评审技术方案

它解决的问题

老项目里，需求常常以 Issue、工单、聊天记录或一句话的形式出现，研发团队面临的困难不是缺少方案，而是方案缺少事实支撑。现状不清、契约不明、影响面评估不足，很容易出现改动范围失控、兼容性问题、上线后回滚困难。这个技能要做的，是把模糊需求整理成一份可以进入研发评审的技术方案：为什么改、改哪里、怎么改、影响谁、风险是什么、哪些点必须确认。

核心能力与关键步骤

• 输入处理：统一处理 Issue、工单、口头描述、聊天记录或一句需求；提炼需求来源、原始描述、目标、触发场景、验收标准、已知限制、可能涉及模块和本次非目标。缺少目标、触发场景或验收标准时，先追问一个最关键问题，不直接输出最终方案。
• 现状定位：写方案前必须查找项目入口（Controller、API、页面入口、任务入口、消息消费入口）、契约（facade/RPC、HTTP API、DTO、枚举、错误码、状态码）、编排（Service、Manager、Processor、Job、Listener）、数据（表结构、DO/Entity、Mapper、Repository、SQL/XML、迁移脚本）、配置（properties/yaml、配置中心 key、开关、灰度、限流、超时）、外部依赖（三方接口、内部系统、SDK、消息主题、缓存、定时任务）、测试和文档。
• 影响面分析：至少覆盖接口兼容性、facade/RPC 调用方与消费方、老数据与存量状态、SQL 查询/写入/事务/索引/慢查询风险、配置默认值与回滚、消息与定时任务幂等、权限与审计、缓存一致性、上下游联调、测试回归范围。
• 方案生成：优先输出最小可控改动方案；必要时给出备选方案并说明取舍，包括是否分阶段上线、如何回滚或降级。
• 评审前检查：最终方案必须包含已确认事实、合理推断、待确认问题、改动范围、风险和验证计划；关键事实未定位时，输出受限方案并标明阻塞点。

适用边界与注意点

• 这个技能不替代项目规则。涉及具体项目时，先遵守项目入口文档、模块边界、设计先行和验证要求。
• 涉及 facade/RPC 时，把 facade 理解为老项目中跨系统或跨应用调用的 RPC 服务接口契约，类似 Dubbo 接口，而不是普通应用层门面模式；默认视为高风险变更，必须检查接口方法签名、请求/响应 DTO、枚举/状态码/错误码、多调用方与多版本、接口文档、测试桩、消费者适配、超时/重试/幂等/降级/限流、联调和回归清单。
• 涉及 SQL、表结构或数据修复时，不能只写“修改 SQL”或“新增字段”；必须说明是否读写老表或核心表、历史数据语义、迁移/补偿/回填、索引与查询条件、事务边界、幂等保护、灰度/回滚 SQL、分页/排序/锁表/慢查询风险和验证方式。
• 涉及配置时，必须检查配置 key、默认值、生效范围、环境/商户/渠道/灰度人群差异、配置缺失行为、热更新、回滚开关、运维或值班手册说明。
• 结论要具体到文件、类、方法、接口、表、配置或模块；无法具体时说明原因。不要把“可能”“建议”包装成事实，不要为了显得完整扩大改动范围，不要跳过待确认问题。研发评审材料允许暴露未知，不允许伪装确定。