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

第一期范围

也常写作Phase 1 scope · 一期范围 · 首期范围 · 第一阶段范围

定义

第一期范围是完整项目目标中，经明确授权在第一个约定阶段完成的目标、用户与业务场景、交付结果、必要工作、技术与数据边界、责任、成本和完成条件的集合，并同时标出本期不做、后续再做和依赖外部完成的事项。它应形成自己的可识别基线，使团队能够为这一期单独报价、排期、执行、验收，并在阶段结束时决定继续、调整、重复或停止。

第一期范围先定义一个阶段，不是先把功能数量砍小

“第一期”只有在项目把阶段起点和终点说清后才有实际含义。有的第一期从立项批准开始，以可行性决定结束；有的从已确认需求开始，以有限用户投入正式使用结束。两者交付结果、工作内容、风险和报价基础完全不同，不能只用同一个“一期”名称替代说明。

第一期范围是完整项目范围的一个阶段性子集，但不是随意截取的功能表。它既要说明这一阶段取得什么结果，也要包含取得结果所必需的数据、接口、环境、测试、培训、交接和管理工作。否则看似范围较小，实际责任会留在阶段外却仍阻止本期完成。

阶段结束不一定意味着系统已经正式上线。调研期可以用是否值得继续作为结果，Alpha 可以用是否存在可行方案作为结果，Beta 或首批上线则需要更接近生产的运行、支持和风险条件。名称、目标和完成决定必须互相一致。

先给“第一期”建立可识别的起止关口

“第一期”最容易变成一个不断向后延伸的称呼：功能陆续加入，日期不断移动，却没人能说清它何时算结束。给它明确的开始条件和结束关口，才能把这一阶段与长期路线图分开，也才能单独报价、验收和复盘。

阶段名称和版本

记录本期的正式名称、范围文件版本和适用项目。不要让“第一期”“第一阶段”“MVP 阶段”在不同文件中指向不同内容。

进入决定

说明谁在什么日期依据哪些输入授权本期开始，以及预算、团队、数据、系统访问和客户配合是否已经具备。

阶段目标

写明这一期要验证什么决定、形成什么业务能力或交付什么可运行结果。目标应能影响取舍，不使用“先做一部分”作为目标。

时间与资源边界

记录计划开始、结束、关键窗口、预算或投入上限、核心人员和外部资源。时间盒不能替代范围，但会约束能承诺的结果。

退出条件

列出本期可以结束的质量、证据、移交和未决项条件，并说明什么结果会导致阶段不能通过。

关口决定

指定阶段结束后由谁决定进入下一期、附条件继续、调整后再做、重复本期或停止项目，以及决定需要查看哪些材料。

一份可执行的第一期范围包含什么

第一期的边界通常不会只出现在一份文件里，范围、报价、计划、需求和验收会分别承担一部分。但这些文件必须指向同一个有效版本，让任何参与人都能拼出同一幅图，而不是销售、开发和客户各自理解一个“第一期”。

目标用户与使用边界

确认本期服务哪些岗位、部门、组织、地区或受限用户群，谁不在本期；说明是真实使用、受控试用、内部验证还是仅供决策。

包含的业务场景

列出本期接入的任务、起点、结束状态、正常分支、关键异常和人工责任。场景范围应对应本期目标，而不是把整个长期需求都塞进来。

本期交付结果

逐项说明软件、接口、配置、数据处理、迁移、环境、文档、培训、测试记录和阶段报告的形态、数量、适用对象与完成状态。

必要工作

包含分析、设计、开发、接入、数据准备、测试、部署、评审、上线支持和交接中为本期结果不可缺少的工作；不把非界面工作默认为免费附带。

系统、数据与第三方边界

确定接哪些系统、字段、历史范围、账号、接口和外部服务，由谁提供、授权和承担用量费用；未就绪的依赖怎样影响本期。

质量与验收边界

把交付结果对应到版本、环境、样本、验收标准、证据和确认人，区分阶段结果确认、正式业务验收和生产授权。

双方责任与投入

明确供应方、客户和第三方在资料、接口、审核、测试、培训、采购和运行中的责任、交付时间及延误处理。

本期排除与后续接口

明确容易被误认为包含的事项，指出延期到哪一阶段、当前设计是否要为它保留接口，以及后续仍需重新评估的条件。

假设、约束和依赖

记录本期报价与排期成立所依赖的数据质量、访问时间、用户数量、审批、法规、技术能力和采购条件，并为关键不确定项指定验证点。

怎样决定什么属于第一期

第一期不是优先挑最容易开发的功能，也不是简单从长期清单顶部截取几项。更可靠的选择方式，是先找到一个值得解决、能够独立跑通并能留下验证结果的业务闭环，再判断哪些能力必须现在具备，哪些可以安全延后。

确定本期要支持的下一项决定
先问阶段结束后需要决定继续投资、选择方案、开放给受限用户还是正式上线。不同决定需要不同的交付与证据。
选择能够证明目标的用户和场景
限定用户、任务、地区、渠道和数据范围，优先覆盖能检验核心价值、关键依赖和主要风险的代表性场景。
从结果反推完整必要工作
从本期结束状态反推数据、接口、权限、异常处理、测试、环境、支持和记录，避免只保留可见功能而删掉完成它的条件。
把延期内容写成明确边界
对后续功能、部门、数据、自动化程度和运维服务说明暂不包含的原因、预计归属和对本期设计的影响，不用“以后优化”代替。
用依赖和风险校验可交付性
确认本期依赖的资料、接口、采购、审批和人员能在窗口内获得；无法控制的关键依赖要改变范围、时间或阶段目标。
用完整估算核对承诺
把非开发工作、客户投入、第三方费用、持续费用和风险储备一起纳入，再判断预算、时间和团队能否支持承诺结果。
跨角色批准基线
让业务、使用者、技术、数据、安全、运维、采购、验收和交付负责人按风险参与，确认同一版的一期范围、排除项和关口决定。

第一期范围能否用于报价和启动的检查

第一期看起来“小”，并不代表它天然容易报价。范围越紧，越需要说明哪些工作仍然必不可少，尤其是数据、接入、部署、验收和客户配合。下面的检查用来确认团队是在启动一个完整阶段，而不是先报一个低价、再把必要工作逐项补回来。

阶段目的是否唯一？
能用一句话说明本期结束要形成的结果或支持的决定，并与后续长期愿景区分。
可核对：阶段目标、业务理由和关口决定。
起止状态是否可识别？
开始需要的授权和输入、结束需要的交付与证据已经列清，不只写日期区间。
可核对：进入条件、退出条件和批准角色。
范围是否覆盖完整责任？
每个包含场景从触发到结果、异常、人工处理和记录都有归属，没有把关键步骤藏在“客户配合”或下一期。
可核对：场景图、责任表和交付清单。
排除项是否足够具体？
本期不覆盖的用户、数据、系统、渠道、自动化程度和运行服务明确，读者不会合理误解为已包含。
可核对：排除清单和后续阶段映射。
依赖是否具备负责人和日期？
资料、接口、账号、审批、采购和测试人员都有提供人、最迟时间及未满足后的处理。
可核对：依赖清单、责任人、截止日和替代方案。
报价是否覆盖本期全部工作？
费用对应交付和必要工作，区分一次性、持续和第三方费用，并说明估算不确定性。
可核对：报价明细、计费假设、资源和用量边界。
验收和下一步决定是否分清？
本期交付通过什么标准确认，以及确认后是否继续投资或进入下一阶段，是两个可记录的决定。
可核对：验收方案、阶段报告和关口授权。

第一期范围容易与什么混淆

MVP、试点、PoC、原型和 Sprint 都可能发生在项目早期，但它们并不自动等于合同或交付意义上的第一期。先说明这一阶段要形成什么正式结果，再选择适合的验证或开发方式，能避免用一个流行名词掩盖边界。

相关概念	与第一期范围的区别
完整项目范围	完整项目范围覆盖当前项目全部获批工作和结果；第一期范围只覆盖第一个约定阶段，并说明与剩余范围怎样衔接。
最小可行产品（MVP）	MVP 通常指能够安全投入使用并用于尽早获得真实反馈的最小产品状态；第一期可能交付 MVP，也可能只完成调研、原型、PoC 或一个尚不对外的基础阶段。
概念验证（PoC）	PoC 主要验证某项技术或方法是否可行，可能不具备完整用户流程和运行条件；第一期范围可以包含 PoC，但还要定义本期所有工作、责任、费用和结束决定。
原型	原型用于探索、演示或测试设计，代码和数据未必可投入生产；第一期可以以原型和决策报告为结果，也可以要求正式可运行系统。
试点	试点让受限对象在明确条件下试用方案并观察结果；它是使用和验证方式，第一期范围还要覆盖构建、数据、支持、风险、费用和退出安排。
Sprint 或迭代	Sprint 是团队完成计划工作的一段短周期，一个第一期通常包含多个迭代；Sprint 完成不自动等于本期交付、验收或关口通过。
产品路线图	路线图表达产品随时间实现价值的方向、阶段和优先级；第一期范围是其中已经获得授权、需要按明确责任交付的近期基线。
第一笔付款	付款节点是商业结算安排，可以与阶段成果关联，但付款序号不定义本期用户、场景、交付物或完成条件。

企业 AI 第一期可以缩小用途，不能省掉相应风险底线

AI 第一期完全可以只服务一个岗位、一个资料范围或一种输出用途，但“用户少”不等于风险可以暂时不管。如果它已经接触真实数据、生成会被业务采用的结论，或能够调用外部工具，相应的权限、拒答、人工接手和审计就必须同期存在。

先限定谁用、用来做什么

同一个 AI 能力，用来起草内部材料和用来直接修改客户订单，承担的后果完全不同。第一期要写清具体任务、使用人、受影响对象和结果用途，并明确系统只是生成草稿、提供建议、检索引用，还是已经获准写回数据或执行外部动作。

限定知识与数据状态

列出本期资料源、字段、历史区间、权限、质量、更新和删除责任。样本数据可用于验证，但若目标是正式使用，就不能把数据授权和生命周期无限延期。

识别组合版本

把应用、模型或托管部署、提示词、护栏、知识索引、检索参数、工具权限和评测集作为本期可追溯对象，不用“接入某模型”代替范围。

按风险保留测试和人工监督

即使用户很少，也要根据实际用途测试正常、资料不足、异常、敏感信息、越权和高影响动作，并明确复核、拒答、人工接手和停止条件。

把第三方变化纳入边界

模型、API、内容策略和价格可能由供应商改变。本期应说明可固定的版本、变更通知、调用地区、用量上限、重新评估触发条件和备用安排。

区分验证环境与真实运行

若本期只是原型或 PoC，应阻断真实订单、消息、审批和生产数据副作用；若面向真实用户，则补齐身份、权限、监控、日志、事件处理、恢复和运营责任。

定义阶段后的处理

说明本期产生的对话、评测、反馈、临时账号、索引和供应商资源怎样保留、迁移或删除，以及继续、扩围或停止时谁接手。

第一期执行中怎样变更，结束时怎样作决定

第一期的意义，不只是尽快做出一版东西，而是在约定关口用真实结果决定下一步。执行中可以调整，但不能让每次调整都悄悄扩大阶段；结束时也不能因为团队已经投入很多，就默认继续扩张。

建立第一期基线
批准并记录范围、计划、报价、依赖、验收和排除项的有效版本，使本期与后续愿景、路线图和待办清单可区分。
按证据更新预测
持续记录实际进度、费用、依赖和风险。近期计划可以比远期更详细，但不确定性要显式表达，不能把预测变化伪装成已批准范围。
用变更请求处理基线修改
新增或删除用户、场景、数据、接口、交付、周期、费用或完成条件时，评估对本期目标、已完成工作、风险和后续阶段的影响，由有权人员决定。
形成阶段结束材料
汇总交付版本、验收结果、费用进度、未决问题、残余风险、运行状态、经验和后续建议，并列出未完成需求的明确去向。
分开作出两个决定
先确认本期是否按照它自己的标准完成，再决定项目是否继续、怎样调整和是否投入下一期；本期验收通过不自动批准下一笔投入。
更新后续范围而不倒改历史
把学习结果用于下一期和路线图，保留第一期当时的基线、变更和决定。后续优先级变化不能把原本未包含的工作写成第一期欠交。

依据与适用边界

本文解释项目中被称为“第一期范围”的阶段性交付边界。它不是全球统一的标准术语，也不默认等于 MVP、试点、原型、PoC、敏捷项目的第一个 Sprint、完整项目范围的功能删减版或合同中的第一笔付款。不同项目的第一期可以是调研验证、原型决策、受限用户试用、第一批正式上线或一个独立交付阶段；项目必须写明这里的“第一期”从什么决定开始、以什么结果和关口结束。本文不重复本站文章《AI 项目第一期怎么定？》所拥有的“怎样把一期设计成最小业务闭环”方法意图。