企业 AI 项目 Wiki · 范围与变更

变更请求

也常写作Change request · CR · 变更申请 · 修改请求

定义

变更请求是针对一个已识别的文件、交付物或基线提出修改的正式记录。它把现状、拟议状态、提出理由、影响、处理选择、决定权限、实施与验证要求连接起来，使团队在改变承诺或受控系统之前能够先判断是否必要、是否值得、是否安全，并在决定后同步相关基线。

变更请求首先是一项提议，不是批准结果

项目开始执行后仍然会出现新信息：业务优先级改变、依赖条件失效、用户提出新需求、风险转化为问题，或者测试发现原设计需要调整。变更请求让这些变化进入同一条可见、可判断的通道，而不是由某个人在会议、聊天或代码提交中直接改变项目。

提交请求只证明有人正式提出了修改，并不自动承诺费用、日期或实现。评估人可以要求补充资料，决策人可以批准、附条件批准、延期、拒绝或撤回；在获得适用授权之前，团队不应把拟议状态当作新的基线。

变更控制保护的不是一成不变的计划，而是决定质量和承诺一致性。好的流程允许必要变化发生，同时让相关方看见它会替换什么、牺牲什么、带来什么风险，以及不批准会有什么后果。

什么时候需要正式提交变更请求

判断重点不是工作看起来大不大，而是它是否改变了已经确认并受控制的对象。组织应预先规定哪些基线、金额、风险等级和系统变动必须进入变更流程。

范围或交付结果改变

增加、删除或替换用户、业务场景、功能、接口、数据、环境、文档、培训、运维责任或明确排除项。

完成条件或质量门槛改变

修改验收标准、测试样本、性能目标、安全要求、上线门禁、允许误差或必须停止处理的条件。

计划与资源基线改变

调整关键里程碑、交付顺序、预算、人员、外部采购、持续费用或已承诺的客户投入。

受控技术配置改变

变更已批准的架构、接口契约、数据库结构、生产配置、访问权限、网络路径、供应商服务或恢复策略。

风险处置需要改变基线

某个风险或问题无法在当前边界内解决，需要增加控制、接受新的残余风险、暂停功能或改变运行方式。

已批准内容需要撤销或重新安排

停止一项已纳入基线的工作、把它移至后续阶段，或用另一项内容交换，都应显示原承诺怎样被替换。

一份可以进入评估的变更请求要写什么

请求能被唯一识别吗？
分配编号，记录提出人、提出日期、业务负责人、紧急程度和期望决定时间。
记录：请求编号、所有者、状态和时间戳。
当前基线说清了吗？
指向当前有效的范围、需求、设计、计划、预算、配置或版本，不能只写“把原来的方案改一下”。
记录：对象名称、版本、位置和相关条目。
拟议状态可以验证吗？
描述要增加、删除、替换或停止的具体内容，以及完成后可观察到的结果；必要时附原型、规则或接口差异。
记录：目标状态、包含项、排除项和完成条件。
理由和不变更后果完整吗？
说明触发原因、业务价值、合规或风险需要，并写明维持现状可能造成的成本、延误、风险或机会损失。
记录：依据、紧迫性、不采取行动的后果。
影响范围可追踪吗？
列出受影响的用户、流程、交付物、需求、系统、数据、供应商、环境、测试、文档和运行团队。
记录：关联项、依赖和初步影响清单。
实施与验证有初步方案吗？
至少说明预计怎样实施、是否需要迁移或停机、怎样测试、怎样回退，以及谁确认完成。
记录：实施选择、验证方法、恢复方向和责任人。

影响评估不能只估算开发工时

评估应同时比较“批准”“不批准”和可行替代方案。小改动也可能穿过数据、安全、合同或运营边界；大改动则未必只能接受或拒绝，还可以缩小、替换或分阶段实施。

业务价值与目标

变更支持哪个目标或解决哪个问题，受益对象和衡量方法是什么，是否挤占更高优先级工作。

范围、进度、成本与资源

计算分析、设计、开发、数据、测试、部署、培训、交接和持续运行的完整工作，说明里程碑、预算、人员和采购怎样变化。

解决方案与依赖

检查架构、接口、数据模型、迁移、配置、基础设施、供应商和其他交付物的连锁影响，维护相互关联对象的可追溯性。

质量、验收与已完成证据

确定哪些标准、用例和已通过结果需要更新或重新执行；旧证据是否仍适用于新状态必须明确。

安全、隐私、合规与合同

评估权限、数据用途与流向、威胁面、记录保留、监管义务、许可证、采购和合同价款或责任是否改变。

上线、运行与恢复

说明停机、容量、监控、支持、告警、备份、回滚、业务连续性和长期维护负担，不能只判断能否部署。

不批准与替代方案

把维持现状的后果与缩小范围、交换优先级、延后、试点或采用不同技术路径的结果并列给决策人。

从提交到关闭的完整处理流程

登记并建立关联
给请求分配编号，关联触发它的需求、缺陷、风险、问题、决定或客户沟通，保留原始提出内容。
分诊和确认完整性
判断它是否真的改变受控基线、是否重复、是否属于紧急通道，并把缺失资料退回补充；分诊不是批准。
组织跨角色影响评估
由业务、交付、技术、数据、安全、测试、运维、财务、采购或供应商按实际影响参与，形成估算、风险和选项。
提交有权人员决定
根据金额、范围、周期、风险和合同授权等级，由项目负责人、产品负责人、变更控制委员会、客户或其他指定角色作出决定。
记录并沟通决定
保存决定人、日期、状态、理由、条件、生效范围和后续责任；向所有受影响人员说明，而不是只在会议中口头同意。
批准后更新基线
在开始或按批准条件实施前，同步范围、需求、设计、预算、计划、配置、验收、合同附件和版本记录，保留旧状态与差异。
按受控方案实施
把获批内容拆成可执行工作，使用指定版本、环境、权限和部署路径；实施中出现新的实质影响时重新评估，不能擅自扩大。
验证、移交并关闭
按批准的标准验证结果，更新运行和交接资料，确认相关记录已同步、临时措施已清理，再由约定角色关闭请求。

状态、决定权限和紧急变更怎样设计

状态或决定	它准确表示什么
已提交 / 待补充	请求已经登记，或资料尚不足以评估；两者都不授权实施。
评估中	相关人员正在分析影响和选项，不表示倾向批准，也不应成为提前开发的依据。
已批准	有权人员授权按记录的范围、条件、预算和时间实施；若关键条件变化，应重新请求决定。
附条件批准	只有满足指定前置条件、限额、测试、复核或截止日期后，授权才适用。条件需要可验证。
延期 / 拒绝	延期保留请求但推迟决定或实施；拒绝维持当前基线。两者都应记录理由和重新提出条件。
已实施 / 已关闭	已实施表示技术或业务修改已执行；只有验证通过、基线和资料已更新、责任已移交后才应关闭。

企业 AI 项目的变更请求要识别整套行为基线

模型与服务变更

记录供应商、模型 ID、固定版本或可移动别名、区域、参数和弃用时间。即使应用代码没变，托管模型更新也可能改变质量、延迟、成本和安全表现。

提示词、护栏与人工规则

系统提示词、结构化输出模式、内容过滤、拒答、人工批准和升级规则都属于行为控制；修改后要评估误拒、漏拦和业务流程影响。

知识与检索链路

新增资料源、权限、清洗、切分、嵌入、索引、检索或重排会改变回答依据。请求应说明数据授权、过期删除、重建范围和回退到哪个知识状态。

工具、动作与权限

增加写回、发信、下单、工单或审批能力，会扩大系统可造成的真实影响。要评估最小权限、参数确认、幂等、限额、审计、失败补偿和人工接手。

评测基线与重新验证

明确受影响的正常、异常、资料不足、恶意输入、敏感信息和高风险动作样本；记录评测集与量表版本，不能用原平均分自动继承结论。

第三方变化和持续监测

供应商模型、API 或政策可能在项目之外变化。合同通知、版本固定、漂移监测、重新评估触发条件和备用方案应进入影响与运行安排。

停止、回退和事件联动

预先定义越权泄露、不可逆误操作、关键事实无依据、绕过人工批准或无法审计等停止条件，并把可恢复的应用、模型、提示词、知识索引和工具配置目标写进方案。

关闭变更请求前应留下哪些证据

决定记录完整
保留批准、附条件批准、延期、拒绝、撤回或替代的决定人、授权依据、日期、理由和适用范围。
新旧基线可比较
范围、需求、设计、计划、预算、配置和合同资料已经更新，旧版本、差异和生效时间仍可追溯。
实施对象可识别
记录实际采用的制品、配置、数据库迁移、模型、提示词、知识索引、工具权限和部署环境，而不是只写“已完成”。
验证结果可复核
把受影响标准、测试、复测、回归、安全检查、运行观察和例外绑定到实施版本，并明确谁确认。
运行和交接已同步
监控、告警、恢复、支持、培训、用户说明、资产清单和持续费用已经交给相应责任人。
未完成事项有去向
残余风险、延期内容、临时措施、后续观察和撤销日期已有负责人及独立记录，不能通过关闭请求把它们隐藏。

变更请求容易与什么混淆

相关记录	与变更请求的区别
需求	需求描述相关方需要的能力或约束；变更请求提议修改已经受控的需求或其他基线，并承载影响与决定。
缺陷单	缺陷记录实际结果未达到现有要求。把系统修回原标准通常不改变范围；若解决方案、成本或承诺需要改变，可关联变更请求。
风险	风险是不确定事件及其影响；风险处置如果要修改基线，通过变更请求获得授权，风险记录继续跟踪不确定性和残余风险。
问题或事故	问题已经发生，事故流程优先恢复和控制影响；需要永久改变受控状态时，再关联普通或紧急变更请求。
任务或待办	任务说明已经决定要做的工作；变更请求位于决定之前，解释是否应改变以及改变的完整影响。
决定记录	决定记录保存选择及理由；变更请求还包含被修改对象、影响评估、授权、实施、验证和关闭全过程。
合同变更单	合同变更单具有特定法律和商业效力。项目变更请求可能触发它，但不能自行替代合同要求的签署、价款和责任调整。
变更控制	变更控制是识别、记录、评估、批准或拒绝并跟踪修改的整体制度；变更请求是其中承载一项具体提议的记录。

依据与适用边界

本文解释项目或系统基线发生拟议修改时使用的正式变更请求。它不是口头意见、普通待办、缺陷单、风险或问题记录，也不等于变更已经获批、已经实施或合同价款已经调整。组织可以在项目工具、工单系统、配置管理系统或合同流程中使用不同表单和名称，但只要请求会改变已确认的范围、交付物、需求、设计、计划、预算、配置或运行基线，就需要能够识别修改对象、评估影响、确定有权决定者，并保留从提出到关闭的记录。