专注于 Infra 层的 AI Agent 技能平台——龙蜥社区 SkillHub 已收到数百个技能，当前陆续上线中。我们每周也会收到一些技能的最佳实践分享，本期给大家推荐的是李小雨贡献的软件变更请求影响分析（change-request-impact-analysis） Skill 实践文章，他是产品总监、独立开发者社群主理人和资深全栈工程师，拥有 13 年以上产品研发、技术管理与企业项目交付经验。长期关注大模型产品化、AI 原生产品设计、企业 AI 提效和工程化实践，同时持续参与龙蜥社区、CSDN、OpenTiny 等开发者生态的技术分享与内容建设。近期李小雨也在围绕 OpenAnolis Skills 开展 Skill 设计与实践，希望把真实项目中的分析方法、研发经验和交付流程沉淀为可复用、可验证的 Agent 能力。以下是他的实战分享：
背景
这两年，我在企业培训、项目咨询和日常开发中使用了大量 AI 编程工具。从 Cursor 到 Codex，再到各种能够直接读取项目、搜索代码和修改文件的 Agent，它们已经明显改变了软件开发的工作方式。
过去，一个开发人员接手陌生需求，需要先熟悉目录、搜索代码、梳理调用关系，再决定从哪里开始修改。现在，只要把需求交给 Agent，它通常几分钟就能找到相关文件，甚至可以直接给出一套完整改动。
这种效率提升非常明显。不过，随着我把 AI 编程用于更真实、更复杂的企业项目，我也越来越清楚地看到一个问题。AI 可以很快完成局部修改，但它未必能够主动判断这项修改会对整个项目产生什么影响。
尤其是在企业软件中，一个需求很少只对应一个页面或者一个接口。字段、状态、权限、历史数据、兼容性、测试和发布往往互相关联。只要其中一个环节没有考虑完整，前期节省的时间就可能在联调、测试和上线阶段以返工的形式重新付出。
基于这些实际经历，我开发了 change-request-impact-analysis Skill。它的中文定位是软件变更请求影响分析，所属方向是开发测试。
这个 Skill 的任务很明确。面对一项具体的软件变更，它会先读取项目、查找证据、梳理影响范围，然后再给出实施顺序、测试范围和回滚建议。整个分析过程默认只读，不直接修改业务代码。
为什么会做这个 Skill
这个 Skill 的直接背景，来自我前段时间完成的一次企业 AI 编程培训。
那次培训使用的是一个前后端分离的工单系统。课程进入需求变更阶段以后，我给学员安排了几项真实开发任务，其中包括新增工单优先级、增加预计完成时间、增加责任部门筛选、限制已关闭工单编辑，以及在详情页补充完整处理记录。
这些需求的难度并不在代码量，而在影响范围。以新增工单优先级为例，业务描述很简单。优先级分为高、中、低，创建和编辑工单时可以选择，列表页能够展示并筛选。无论是学员还是 Agent，拿到需求后的第一反应通常都很一致，先给工单增加一个 priority 字段，然后修改表单、列表和接口。
这条思路没有问题，但它很容易停留在最直观的实现位置。
继续沿着项目结构往下查，优先级字段还可能进入实体对象、请求对象、返回对象、字段转换逻辑和接口校验。如果系统采用数据库迁移工具，还需要增加迁移脚本。与此同时，项目中已经存在大量历史工单，因此还要确定历史数据使用什么默认值，以及这个默认值是否符合业务含义。
当列表需要支持优先级筛选以后，查询条件也会发生变化。如果数据规模较大，还要考虑索引。再继续检查，导出功能、统计报表、接口文档、移动端页面以及自动化测试都有可能依赖同一组工单数据。
这时就能看到，需求文档中只有一句增加优先级，落到工程实现中却会经过一整条数据链路。
我做过后端开发，也长期参与产品规划、项目管理和企业交付，所以在处理这类需求时，会习惯性地从业务目标一路检查到数据、接口、权限、测试和发布。可当任务直接交给 Agent 时，这些经验不会自动进入它的执行过程。用户明确说了什么，它会优先完成什么；用户没有提到的部分，则取决于它是否在搜索过程中碰巧发现。
更需要警惕的是，Agent 一旦开始修改代码，后面的判断很容易围绕已经修改过的文件继续展开。最初没有进入搜索范围的模块，后续通常也不会主动回到分析阶段重新检查。
于是，页面和接口可能都已经完成，导出功能却少了字段；新建数据没有问题，历史数据筛选却出现异常；当前前端可以正常调用接口，旧版本客户端却因为契约变化而无法解析。
这类问题让我逐渐确认，AI 编程流程里需要增加一个独立环节。这个环节应该发生在需求已经明确、代码尚未修改的时候，先把项目看清楚，再决定从哪里动手。
这就是我开发这个 Skill 的根本原因。
真实项目中的痛点，远不止漏改一个文件
确定要做这个 Skill 以后，我首先梳理的并非它应该输出多长的报告，而是它到底要解决哪些实际问题。
第一个问题是，业务需求和代码结构之间存在天然距离。
产品经理描述的是用户要完成什么，开发人员面对的却是数据如何进入系统、经过哪些模块、最终保存到哪里。需求中的一个业务名词，在代码中可能对应页面字段、接口参数、枚举、数据库列、查询条件和权限规则。项目越复杂，这种映射关系越难依赖单次关键词搜索完成。
第二个问题是，AI Agent 容易过早进入编码状态。
当用户输入帮我实现这个需求，Agent 通常会立即搜索文件并开始修改。执行速度确实很快，但项目约束、历史数据、兼容性要求和回滚条件可能还没有确认。等代码已经改完，再回头补分析，成本往往更高，因为此时项目现状已经被新的代码改变。
第三个问题是，很多分析结论缺少证据。
AI 很容易给出一句听起来正确的话，例如这个需求会影响前端、后端和数据库。可对于真正负责开发的人来说，这句话几乎无法直接使用。开发人员需要知道具体影响哪个页面、哪个接口、哪个实体、哪张表，以及这个判断来自真实引用关系，还是来自常见架构经验。
第四个问题是，AI 经常把推测写得过于确定。
例如，它看到一个 WorkOrderDTO，就可能判断所有接口都需要修改；看到一个同名目录，就可能认为存在调用关系。这些判断未必完全错误，但如果没有区分事实、推断和未知，报告就很容易误导后续开发。
第五个问题是，需求影响经常停留在编码层面，测试和发布被放到了最后。
很多开发任务完成以后，才开始考虑历史数据怎么处理、接口是否兼容、迁移脚本能不能回滚、旧版本服务能否短时间共存。到了这个阶段，能够调整的空间已经很小，任何遗漏都可能直接推迟上线。
把这些问题放在一起，就能看出我真正想解决的并非如何让 AI 多列几个文件，而是如何把开发人员原本依赖经验完成的变更评审过程，整理成一套可以重复执行的规则。
基于这个目标，我把 Skill 的范围收得很窄。它只处理单项明确变更的影响分析。完整项目总结、线上故障排查、Bug 修复、Pull Request 审查和直接功能开发，都被排除在外。
这个边界让 Skill 能够更稳定地触发，也能让输出保持一致。它不需要接管整个研发过程，只需要把需求评审和代码实现之间的空白补上。
这个 Skill 能解决哪些问题，又是怎样工作的
实际使用时，提示词不需要写得很复杂。打开项目以后，给出一项具体变更，并明确要求只分析、不修改即可。
请使用 change-request-impact-analysis 分析下面的变更请求。 给工单增加优先级字段，支持高、中、低三个值。 创建和编辑页面允许选择，列表页展示并支持筛选。 本次只做影响分析，不修改代码。 请检查前端、后端、API、数据库、权限、测试和发布影响， 并为关键结论提供对应的文件或代码位置。 复制
接到任务以后，Skill 会先确认当前行为、目标行为、变更范围和仍然缺失的信息。随后，它会读取项目说明、依赖配置和目录结构，再从需求中提取业务实体、字段名称、页面名称、状态值和用户操作。
完成这些准备以后，Agent 才开始追踪实际实现。
在常见前后端项目中，分析路径可能从页面进入 API 请求，再经过控制器、业务服务、领域模型、数据访问层，最后到达数据库和迁移文件。不过，这条路径只是一种常见情况。Node.js、Python、Go、Serverless 和事件驱动项目的组织方式差异很大，因此 Skill 会根据仓库中真实存在的文件和引用关系调整分析方式。
为了避免只检查最明显的代码位置，Skill 固定覆盖九个方面，包括用户界面、后端逻辑、API 契约、数据库、权限与安全、配置与依赖、测试、部署与回滚，以及文档与运维。
这里有一个重要原则，固定检查并不代表每个需求都会影响全部九项。没有发现关联时，Agent 需要明确说明已经检查，但暂时没有发现影响。当前仓库无法提供证据的内容，则进入待确认事项。
在结论表达上，Skill 使用三类置信度。
已经找到直接代码、配置或文档证据的内容，会标记为已确认。根据映射、引用和依赖关系能够合理判断，但证据链还没有完全闭合的内容，会标记为高概率影响。当前仓库无法判断，或者必须依赖数据库实例、外部系统和其他仓库才能继续确认的内容，则会标记为待确认。
仍然以工单优先级为例。如果 Agent 已经找到了 WorkOrder 实体和创建接口，这些位置可以列为已确认影响。如果它找到了实体到 DTO 的字段转换，但尚未找到全部调用入口，DTO 可以先列为高概率影响。如果仓库里没有历史迁移记录，存量工单应该怎样设置默认优先级，就只能进入待确认事项。
这套规则直接解决了前面提到的证据问题。报告不会只说可能需要修改，而会尽量说明影响对象、文件位置、判断依据、置信度和风险。
分析完成以后，报告还会继续给出实施顺序、测试计划和回滚建议。
例如，新增优先级字段时，合理的实施顺序通常是先确认字段语义、数据类型和历史数据默认值，然后编写数据库迁移，接着更新领域模型和 API 契约，最后完成页面展示、筛选和测试。
之所以要强调顺序，是因为很多返工来自前置问题没有确认。历史数据默认值没有统一，数据库和业务逻辑就可能采用不同规则；接口先完成改造，旧客户端兼容问题就会被推迟到联调阶段；迁移脚本没有回滚设计，上线以后出现异常就很难快速恢复。
测试范围也会根据影响分析展开。除了验证高、中、低三个正常值，还要覆盖空值、非法值、历史数据、组合筛选、权限差异、接口兼容和导出结果。如果涉及多个服务或客户端，还要考虑新旧版本短时间共存时的行为。
因此，这个 Skill 实际解决的是四个连续问题。它先帮助团队找到真实影响范围，然后用项目证据约束结论；在此基础上，它会把零散的修改点整理成实施顺序；最后，再把影响范围转换为测试和发布检查项。
从研发流程来看，它最适合放在需求确认和代码实现之间。产品经理可以用它补充需求评审，技术负责人可以用它确认改动范围，开发人员可以把报告作为实现依据，测试人员也可以直接从影响矩阵中提取回归范围。
我为这个 Skill 准备了 17 个评测用例，其中包括 8 个正向场景、4 个负向场景和5个降级场景。它们覆盖字段新增、状态规则、接口字段改名、权限调整、项目总结、容器故障、无仓库、找不到业务实体和缺少数据库迁移等情况。
这些评测目前属于静态规则检查和场景走查，没有执行真实运行时测试的部分，我也没有将其写成自动化验证结果。对于 Skill 开发来说，能力边界是否清楚、证据规则是否完整、降级行为是否可靠，与提示词能不能生成一份漂亮报告同样重要。
总结
本次开发的 change-request-impact-analysis，源于一个非常具体的判断。
AI 编程已经能够显著提高代码生成和修改效率，但在企业项目中，交付质量仍然取决于开发前是否真正理解了变更范围。项目越复杂，数据、接口、权限、历史版本和发布流程之间的关联越多，单纯追求快速修改就越容易把问题留到后面。
这个 Skill 没有试图接管完整研发流程。它只负责在一项明确变更进入开发之前，帮助团队查清当前实现、影响范围、风险和待确认事项。
它解决的核心问题也很清楚。业务需求与代码结构之间的距离，需要通过实际项目证据来补齐；Agent 过早编码的问题，需要通过只读分析来控制；结论过于笼统的问题，需要通过文件位置和置信度来约束；测试和发布考虑过晚的问题，则需要在开发前就纳入影响分析。
对于简单需求，这一步可能只需要几分钟。对于涉及数据库、权限、接口兼容和多个客户端的企业项目，它可以提前减少遗漏和返工，也能让产品、研发、测试和交付围绕同一份事实继续工作。
AI 写代码的速度已经足够快。接下来真正值得补强的，是让它在动手之前，先对变化可能带来的后果做出专业、完整并且有证据的判断。
相关链接：
软件变更请求影响分析 (change-request-impact-analysis)：
https://skillhub.openanolis.cn/skill/change-request-impact-analysis
Skillhub 官网链接：
https://skillhub.openanolis.cn
龙蜥社区 Skill 征集活动——「Skill 创造营」上线以来响应热烈。截至目前，龙蜥 SkillHub 已收到覆盖安全、系统运维、AI 推理、数据库等多个领域，一个面向 Infra 的 AI 技能生态正在加速成型。「Skill 创造营」持续征集中，诚挚欢迎每一位开发者提交你的 Skill 与最佳实践。如果你有感兴趣的方向或者关于 SkillHub 的问题，欢迎通过下方链接反馈给我们。
SkillHub 用户需求收集链接：
https://alidocs.dingtalk.com/notable/share/form/v014jKqm0b74KdjLnw1_f22ghuX_M7AJs3D
