企业 AI 项目 Wiki · 范围与变更
项目范围
也常写作Project scope · 项目工作范围 · 项目边界 · Scope
项目范围是相关方在一个明确版本中确认的交付边界：为了实现本期目标，要向哪些用户和业务场景交付哪些结果，完成哪些必要工作，接入哪些数据、系统和环境，由谁承担哪些责任，按照什么条件确认完成，以及哪些事项明确不在本期。它是报价、排期、资源、验收和变更判断的共同基准。
项目范围不是功能清单，也不是一句“做一个系统”
功能清单只能说明系统可能具备什么，不能说明本期交付到什么程度。例如“支持知识问答”没有交代资料来源、用户范围、权限、引用、资料不足处理、评测、部署、监控和人工接手，无法直接用于报价或验收。
项目范围同时约束结果和必要工作。只写页面、接口或模型能力，会漏掉数据准备、环境、测试、上线、培训和交接；只写团队要做的活动，又可能做完很多事情却没有形成客户可以使用和确认的结果。
范围需要有明确版本。讨论纪要、原型、报价单和需求表中的内容可能不断变化，只有被指定为当前基准的文件及其批准变更，才能共同回答“这件事是否属于本期”。
一份可执行的项目范围要说明哪些边界
文件名称可以不同，但下面这些问题需要能在范围文件或其明确引用的附件中找到答案。
目标与业务结果
说明本期要改善的业务过程、目标用户和预期状态。目标用于判断优先级，但不能用“提升效率”替代具体交付内容。
- 当前问题和目标状态
- 受影响部门与用户
- 成功结果怎样被观察
包含的业务场景
列出本期真正打通的起点、处理过程和结束状态，说明正常、异常和需要人工处理的分支。
- 谁在什么条件下发起
- 系统和人员分别做什么
- 记录写到哪里、何时结束
交付结果
把可运行系统、接口、配置、数据处理、文档、培训和交接资料分别写清，注明形态、数量或适用范围。
- 软件与配置
- 数据与迁移结果
- 说明、记录和交接资料
系统、接口与数据边界
确认接入哪些现有系统、环境、账号、字段和历史数据，谁提供访问条件，是否包含清洗、迁移、回写和第三方审批。
- 接口方向与负责人
- 数据范围、质量和权限
- 外部服务、许可证与配额
环境、部署与运行边界
说明开发、测试、验收和生产环境由谁提供，是否包含域名、证书、云资源、部署、监控、备份、上线值守和持续运维。
- 目标环境与区域
- 一次性交付与持续服务
- 生产访问和运行责任
质量与完成条件
范围应指向适用的验收对象、标准、样本、环境、证据和确认人。不能用“客户满意”或“系统正常”作为唯一完成条件。
- 功能与业务结果
- 性能、安全和兼容条件
- AI 质量、拒答与人工接手
责任与客户投入
区分供应商负责、客户负责和双方配合的事项，并写清资料、接口、账号、审核、测试反馈和确认需要在什么时间完成。
- 交付负责人
- 业务与技术确认人
- 依赖的客户和第三方工作
明确排除项
把容易被合理误解为包含、但本期不交付的事项直接列出，例如历史数据治理、全部部门推广、长期运维或某个旧系统改造。排除项不是免责声明，而是对边界的正面确认。
假设、依赖与约束
记录报价和排期成立所依赖的前提，以及预算、时间、法规、技术或采购限制。假设失效时，应触发影响评估而不是静默增加工作。
怎样检查范围是否已经能用于报价和排期
- 每个结果能否被唯一识别？
交付物有名称、适用场景、边界和完成状态，不使用“相关功能”“必要接口”等无法计量的兜底词。
可核对：交付清单、原型、接口清单、资料目录。
- 工作是否覆盖了完整交付？
开发之外的数据、接入、测试、部署、验收、培训和交接工作已经列入或明确排除。
可核对：工作分解结构、里程碑与责任表。
- 边界条件是否双向明确？
不仅写“包含什么”，也写出最容易产生误解的“不包含什么”，并说明一期与后续阶段的分界。
可核对：范围说明、排除项、阶段路线图。
- 依赖是否有负责人和日期？
客户资料、接口、第三方账号、采购和审核不是笼统的“客户配合”，而是可跟踪的输入。
可核对：依赖清单、负责人、最迟提供时间。
- 完成是否能按证据判定？
每类交付结果都能对应验收标准、验证方法、证据和确认权限。
可核对：验收标准、测试方案、确认记录。
- 报价与范围是否一一对应？
一次性费用、持续费用和第三方费用都能回到具体范围项，没有把未知数量或未确认依赖藏进固定总价。
可核对：报价明细、计费假设、用量边界。
- 文件版本是否唯一？
所有参与人知道当前生效的范围版本、批准人、日期，以及原型、邮件和会议纪要与它的关系。
可核对：版本号、批准记录、变更日志。
项目范围容易与什么混淆
| 相关概念 | 与项目范围的区别 |
|---|---|
| 产品范围 | 产品范围描述产品长期具备的特性和能力；项目范围描述某次项目为了形成约定结果要完成的工作。产品路线图中的功能不一定属于本期项目。 |
| 需求 | 需求表达相关方需要的能力、行为或约束；项目范围决定本期采纳哪些需求，以及围绕它们还需交付哪些环境、测试、资料和服务。 |
| 交付清单 | 交付清单是范围的重要组成，但不单独说明用户场景、责任、排除项、依赖和完成条件，不能替代完整范围。 |
| 工作分解结构（WBS） | WBS 把完成项目所需工作分解成可规划和控制的层级；它帮助覆盖范围，但范围还需要说明目标、边界、责任和验收。 |
| 报价 | 报价把已知范围、假设和计费方式转换为费用。报价金额相同不代表范围相同；范围变化后应重新评估工作量、费用和周期。 |
| 合同范围 | 合同可能把范围、价款、责任、知识产权、违约和法律条款组合起来。项目范围是其中的交付边界概念，不能代替合同解释。 |
| 第一期范围 | 第一期范围是完整目标中的一个阶段性子集，应形成自己的用户、场景、交付物和验收闭环，而不只是把长期功能表截取一部分。 |
怎样形成可以共同执行的范围基线
确认业务目标和决策人
由能够代表业务结果的人说明本期目标、优先级和不可接受结果，同时指定技术、数据、安全和验收确认人。
画出完整业务闭环
从发起、处理、异常、人工介入到记录和结束，确定本期覆盖哪些角色、部门、渠道和数据。
列出交付结果与必要工作
从业务结果反推系统、接口、数据、环境、测试、培训和交接，并用 WBS 或相当结构检查是否有遗漏。
写明包含、排除、假设和依赖
优先处理会改变报价或周期的模糊点，把第三方审批、客户输入和旧系统限制落实到负责人及日期。
绑定验收与费用
为每项交付结果指定完成条件和证据，确认一次性、持续和第三方费用如何对应，并说明数量或用量变化的处理方式。
完成跨角色评审
业务、使用者、技术、数据、安全、运维、采购和供应商按实际风险参与，检查同一个词是否有不同理解。
批准并冻结版本
记录范围文件、引用附件、版本、日期、批准人和未决项；只有这一版本及后续批准变更用于执行和比较。
范围变化后怎样处理，而不是默默加进项目
范围基线不是拒绝变化，而是让变化的影响和决定可以被看见。
登记变化
记录谁提出什么变化、原因、期望时间，以及它涉及的用户、流程、数据、接口和交付物。
先判断是不是范围变化
缺陷修复、对原范围的澄清、假设失效和新增需求处理方式不同，不能都叫“优化”。
评估完整影响
检查工作量、费用、排期、资源、架构、安全、数据、验收、已完成工作和其他范围项，不只估算开发时间。
给出处理选择
可以批准并调整基线、用等量内容替换、移到后续阶段、拒绝，或先做有时间上限的分析；每个选择说明后果。
由有权人员决定
按项目约定确认谁能改变预算、时间和交付承诺，避免开发人员或单个使用者在沟通中无意改变范围。
同步全部基线
批准后同时更新范围、需求、原型、报价、计划、测试和验收文件，并通知受影响负责人；保留旧版和变更理由。
企业 AI 项目范围还要额外确认什么
目标任务与禁用用途
明确 AI 支持哪些任务、面向哪些用户、结果怎样使用，以及哪些高风险决定、专业判断或超出知识边界的用途不允许自动完成。
知识与数据范围
列出本期接入的资料库、文件类型、历史范围、数据字段、权限和更新责任；“使用客户资料”不足以确定清洗、标注、迁移和持续维护工作。
回答与动作边界
区分只生成草稿、给出建议、检索引用、写回系统和执行外部动作。每增加一种工具权限，都需要增加授权、确认、审计、失败和补偿范围。
模型与第三方边界
说明选型、接入、微调、评测、调用费用、区域、版本变化和备用模型分别由谁负责；模型名称不能代替完整解决方案范围。
质量与风险范围
根据任务分别确定样本、引用、正确拒答、资料不足、敏感信息、越权、人工接手和硬停止条件，记录不能保证的能力和残余风险。
人工监督和运营
明确谁复核输出、谁接手异常、谁处理反馈、谁更新知识和评测集，以及上线后的监控、再评估、成本控制和事件处理是否属于本期。
组合版本
AI 行为由应用、模型、提示词、护栏、知识索引、检索参数和工具权限共同形成。范围和验收应识别这套组合，不能只交付一句提示词或一个模型接口。
依据与适用边界
本文解释项目管理和企业 AI 交付中的项目范围，即本期为了形成约定结果需要完成的工作与边界。它不替代合同法律条款、完整需求规格、产品长期路线图、单项验收标准、报价明细或变更请求。不同组织会把范围分别记录在项目章程、范围说明、工作说明书、需求基线、工作分解结构和合同附件中；项目应明确哪些文件共同构成当前有效范围，以及冲突时按什么顺序处理。