项目成功标准要在立项时定下来：用 AI 拆清业务结果、范围、质量和验收指标

教程定位

这篇教程解决什么问题

很多项目不是败在没有交付，而是败在“交付了以后，大家才发现成功的定义不一样”。立项会上说的是“做一套系统”“把流程线上化”“提高效率”“支撑业务增长”，这些话听起来方向一致，但到了上线验收时，甲方业务负责人可能关心订单处理时效，财务关心对账差错率，仓配关心异常单闭环，乙方项目经理关心合同范围内的功能是否完成，信息化部门关心稳定性和权限安全。每个人都能说自己有道理，项目却很难被一句话判定为成功。

这篇教程解决的是立项阶段的一个具体动作：用 AI 帮你把“项目成功”拆成可以讨论、确认和追踪的标准。它不替代客户验收清单，也不替甲乙方拍板，更不把合同条款重新解释成对某一方有利的版本。它的价值是把模糊目标拆成四类材料：业务结果、交付范围、质量要求、验收指标。这样项目还没有正式开工时，相关方就能看到同一张表，并把争议提前暴露出来。

我们用一个虚构但真实感很强的项目举例：一家区域消费品公司准备建设“经销商订单协同系统”。立项时老板说，希望三个月内上线系统，减少销售助理手工录单，提高订单处理效率。合同里写了订单创建、审批、库存校验、发货跟踪、对账导出等模块。业务 KPI 里有订单处理时效、错单率、客户满意度和月度销售达成率。历史类似项目复盘里提到，上一套系统功能做完了，但因为没有定义“效率提升”怎么算，最终上线后业务说没有达到预期，交付团队说范围内功能都完成了。

如果这类项目只在立项材料里写“目标：提升订单协同效率”，风险很大。因为这句话至少有四种解释。业务负责人可能理解为订单从提交到确认的平均时间下降 30%；销售助理可能理解为少填重复字段；仓库可能理解为异常库存能提前发现；项目经理可能理解为合同约定功能按期上线。没有人恶意曲解，但每个人都从自己的工作压力出发。

正确的做法是在立项时把成功标准写出来。比如业务结果可以写成“试点区域订单从经销商提交到销售确认的平均处理时长，由当前约 2 个工作日降到 1 个工作日内，统计口径以试点期样本数据为准”。交付范围可以写成“本期覆盖经销商下单、销售确认、库存校验、发货状态同步、对账导出，不覆盖价格政策自动推荐和经销商授信调整”。质量要求可以写成“核心下单链路在预发环境完成不少于 30 条脱敏样例订单验证，关键字段权限符合信息化部门既有规范”。验收指标可以写成“使用约定样例数据时，经销商可完成下单，销售可完成确认，仓配可看到发货状态，财务可导出对账明细；出现库存不足时有明确提示并进入异常处理队列”。

这些表述仍然需要人确认。AI 可以帮你起草，但不能决定“1 个工作日”是不是合理，不能决定“试点区域”包括哪些城市，不能决定“错单率下降”是否纳入首期验收，不能代替甲方签字，也不能代替乙方承诺。它只是把隐含分歧翻译成显性问题，让立项会从“大家都觉得要做完系统”变成“大家确认什么结果算成功”。

读完这篇，你可以拿走三份产物。第一份是项目成功标准表，用来把业务结果、范围、质量和验收指标放到同一个页面。第二份是验收指标草案，用来在立项阶段先写出可观察的验收口径。第三份是不可量化目标的确认问题，用来处理“体验更好”“协同更顺畅”“管理更透明”这类常见但容易争议的目标。

使用场景

什么情况下最适合用这一套

你可能是业务负责人，也可能是项目经理。你不一定负责写代码，但你负责让项目在组织里真的落地。你遇到的场景通常是这样的：公司决定上一个系统，大家在立项会上讨论了背景、预算、时间和大致范围。会议纪要写得很积极，标题也很清楚，例如“经销商订单协同系统项目立项”。但当你追问“上线以后怎么判断成功”时，答案开始变得模糊。

业务负责人说：“至少要让销售同事觉得好用，别再到处催单。”销售运营说：“希望能减少重复录入。”财务说：“对账导出要准确。”信息化说：“权限和稳定性必须符合规范。”乙方项目经理说：“合同范围内功能按期交付就是基础。”老板最后补一句：“关键是三个月内做出来，别又拖半年。”

这些话都重要，但它们还不是成功标准。它们更像一组期待。如果没有进一步拆解，项目执行中会不断出现判断题：为了赶三个月，要不要先不上对账导出？销售觉得页面多点一次不顺手，这算不算没有成功？库存数据不是实时同步，是不是质量问题？错单率下降要不要统计？试点区域反馈好，但总部运营觉得报表不够，这算不算通过？

更麻烦的是，上线后的争论往往没有赢家。甲方说“系统是上了，但业务没有改善”，乙方说“合同功能都验收过了”，业务部门说“你们当时没问清楚我们怎么用”，信息化说“需求一直在变”。这时候再补成功标准，已经很难客观。因为每个人都会带着已经发生的成本、延误和情绪来解释标准。

所以成功标准应该在立项时定。立项不是只确认项目要不要做，还要确认“为什么做、做到哪里、用什么证据判断做到”。尤其在项目还没有进入详细设计时，相关方更容易承认不确定，也更容易调整表达。这个阶段用 AI 最合适，因为它不会替你拍板，却能帮你把零散材料整理成一张可讨论的草案。

本文适合这些情况：

它不适合用来做合同争议裁决。如果双方已经进入正式争议、法务沟通或费用结算冲突，AI 起草的成功标准不能作为事后改变合同的依据。本文讨论的是立项时的预防动作：在项目开跑前，把成功的定义尽量摊开。

1. 项目目标写得很大，例如“提升效率”“打通流程”“支撑增长”，但缺少判断标准。
2. 合同条款写了功能模块，但业务负责人更关心实际经营结果。
3. 甲方、乙方、业务、信息化对“成功”各有理解，尚未形成统一口径。
4. 项目有明确上线时间，但对范围取舍、质量底线和验收指标还没有说透。
5. 过去类似项目出现过“功能完成但业务不买账”或“业务满意但验收材料不足”的问题。

材料准备

开始前先把材料和边界备齐

开始前准备五类输入材料。材料不要求完美，但要尽量保留原始表述。AI 很擅长整理，但如果你把材料提前改成“你以为对方想要的样子”，它就很难发现真正的分歧。

第一类是项目目标。这里要包含立项材料、老板口头要求、业务部门提出项目的背景，以及项目为什么现在要做。比如：“销售助理每天从经销商群里收订单，再手工录入 ERP，容易错单，旺季处理不及时。希望通过订单协同系统减少人工录入，提高订单处理效率，并为后续经销商自助下单打基础。”这类文字能帮助 AI 判断业务结果应该从哪里拆。

第二类是合同条款或范围说明。即使合同还没最终签，也要拿到当前范围版本。包括本期模块、明确不做的内容、里程碑、交付物、验收方式、试运行周期、数据迁移口径、培训要求和售后支持边界。合同条款通常强调“交付什么”，业务目标通常强调“带来什么变化”，两者不能混为一谈。

第三类是业务 KPI。不要只给年度销售额这种大指标，也要给和项目更贴近的过程指标。例如订单确认时长、错单率、手工录入量、异常订单处理时长、经销商投诉量、对账差异数、销售助理人均处理订单数。不是每个 KPI 都要进入项目验收，但它们能帮助你识别“业务结果”到底指什么。

第四类是验收要求。包括甲方内部验收流程、谁签字、是否需要试点部门确认、是否需要信息化安全检查、是否要求测试报告、是否有上线评审、是否有培训签到、是否有试运行观察期。很多项目争议不是功能本身，而是“谁有权说通过”和“通过要看哪些证据”没有提前讲清楚。

第五类是历史类似项目复盘。尤其要找失败或争议案例。比如上一期 CRM 项目上线后，销售说字段太多，录入更慢；供应链看板项目功能完成，但数据口径和财务不一致；售后工单系统验收通过，但一线没有使用。复盘材料能提醒 AI：这家公司过去在哪些地方最容易把“完成”和“成功”混在一起。

整理材料时可以用下面这个模板。它不需要写得漂亮，重点是把事实、猜测和待确认项分开。

在输入材料里一定要写清楚“不要让 AI 直接定最终标准”。这不是客气话，而是保护项目。比如 AI 可能会建议“订单处理时长下降 50%”，但这只是草案，不是承诺。你需要让业务负责人判断是否符合业务节奏，让项目经理判断是否在范围内，让数据负责人判断是否能统计，让合同负责人判断是否与交付条款一致。

项目成功标准输入包

项目名称：
经销商订单协同系统一期

项目目标原文：
三个月内上线订单协同系统，减少销售助理手工录单，提高订单处理效率，支撑重点区域经销商线上协同。

合同或范围摘录：
- 经销商下单
- 销售确认
- 库存校验
- 发货状态同步
- 对账明细导出
- 基础权限管理
- 一期不包含价格政策自动推荐、授信调整、移动端小程序重构

业务 KPI 或线索：
- 当前订单从经销商提交到销售确认通常需要 2 个工作日
- 旺季错单率约 3%，主要来自手工录入和规格选择错误
- 销售助理每天约 2 小时用于收单、转单和催状态
- 经销商希望能看到订单处理进度

验收要求：
- 甲方业务负责人、信息化负责人、试点区域负责人共同确认
- 需要预发环境测试记录
- 需要试点区域不少于 2 周试运行反馈
- 最终验收不以单个用户主观感受为唯一依据

历史复盘：
- 上一个流程系统功能上线，但没有统计效率变化，业务认为收益不明显
- 报表项目曾因数据口径没有提前定义，验收阶段反复修改
- 培训材料不足导致一线使用率低

本次请 AI 产出：
1. 成功标准表
2. 验收指标草案
3. 不可量化目标的确认问题

限制：
- 不替甲乙方决定最终指标
- 不重新解释合同责任
- 不输出技术方案

实操流程

按这套步骤把工作跑起来

第一步，先让 AI 区分“成功”和“交付完成”。

很多项目一开始会把这两个词混在一起。交付完成通常指合同约定的功能、文档、培训、部署和验收流程完成。成功则指项目对业务产生了预期价值，并且相关方认可这种价值。一个项目可能交付完成但业务不成功，也可能业务试点效果不错但验收材料不足。立项时必须把两者放在同一张桌面上讨论。

你可以要求 AI 从输入材料里提取两栏：一栏是“交付完成证据”，例如功能模块上线、测试报告、培训记录、试运行反馈、验收签字；另一栏是“业务成功证据”，例如处理时长下降、错单率下降、人工录入减少、经销商能查看进度、异常单能闭环。这样能避免项目经理只盯合同清单，也避免业务负责人只讲感受。

第二步，把业务结果写成可观察变化。

业务结果不是“提高效率”四个字，而是某个对象在某个场景里的状态变化。建议按“对象、当前状态、目标状态、统计口径、观察周期”来写。比如“试点区域订单从经销商提交到销售确认的平均处理时长，由当前约 2 个工作日降到 1 个工作日内，观察周期为试运行后连续 2 周，统计口径排除因经销商资料缺失导致的暂停订单”。这个句子比“提高订单效率”长，但它能减少后续争议。

如果暂时没有基线数据，不要让 AI 编一个看似精确的数字。可以写成“待确认基线”。例如“当前平均处理时长需由销售运营在立项后一周内提供样本数据；若无法提供，则本期先以流程可追踪和重复录入减少作为成功观察项，不承诺量化降幅”。这样比随便写“提升 30%”更稳。

第三步，把交付范围拆成“本期包含”和“本期不包含”。

成功标准不能无限扩张。一个订单协同系统可能未来会包含移动端、价格政策、客户信用、促销规则、库存预测、经销商门户和 BI 报表，但一期不可能全部做。你要让 AI 根据合同条款和目标，整理范围边界，并特别写出“非目标”。非目标不是推脱，而是让所有人知道这次成功不依赖哪些东西。

例如本期包含“经销商下单、销售确认、库存校验、发货状态同步、对账明细导出、基础权限管理”。本期不包含“价格政策自动推荐、经销商授信调整、促销活动自动匹配、移动端小程序重构、跨区域库存调拨优化”。如果业务结果里写了“提高订单协同效率”，就要说明该效率提升只针对本期覆盖链路，不等于解决所有销售运营效率问题。

第四步，把质量要求写成底线，而不是口号。

质量要求经常被写成“系统稳定、数据准确、体验友好”。这些词都对，但不够验收。你可以让 AI 从功能质量、数据质量、权限安全、性能稳定、可运维性、培训可用性几个角度拆。每一项尽量写成能检查的标准。

例如“数据准确”可以拆成“订单号、客户、商品规格、数量、金额、发货状态在系统内传递时不出现字段错位；对账导出与系统订单明细使用同一口径；试点期发现的数据差异需要有登记、归因和修复记录”。“系统稳定”可以拆成“核心下单和销售确认链路在试运行期间无连续 2 小时不可用；重大故障有响应记录和恢复说明”。这些表述不是最终 SLA，但能把质量讨论拉到可验证层面。

第五步，把验收指标分成“功能验收、业务观察、质量检查、材料确认”。

功能验收回答“系统能不能做合同里说的事”。业务观察回答“业务有没有看到预期变化”。质量检查回答“上线后是否可靠、准确、安全”。材料确认回答“验收证据是否完整”。四类指标都需要，但不要互相替代。

例如功能验收指标是“经销商可创建订单，销售可确认订单，库存不足时出现提示并进入异常处理队列”。业务观察指标是“试点期间销售助理手工录单时间下降，具体降幅根据立项后一周确认的基线确定”。质量检查指标是“脱敏样例订单覆盖正常订单、库存不足、规格错误、取消订单、发货状态更新五类场景”。材料确认指标是“交付测试记录、培训材料、试运行反馈、问题清单和关闭记录齐全”。这样即使某个指标还需要确认，也不会把所有责任压在一个模糊词上。

第六步，专门处理不可量化目标。

项目目标里经常有“体验更好”“管理更透明”“协同更顺畅”“减少扯皮”“方便领导查看”。这些目标不一定错，也不一定都能量化。问题不在于不能量化，而在于没有确认“谁的体验、哪个动作、更好体现在哪里”。你要让 AI 为每个不可量化目标生成确认问题。

例如“协同更顺畅”可以追问：主要指经销商和销售之间，还是销售和仓配之间？当前最典型的不顺畅场景是什么？上线后希望少发生哪类沟通？是否用消息通知、状态可见、异常队列或责任人明确来判断？谁来代表一线确认顺畅度？如果有人仍然觉得不顺畅，是否有可复盘的具体场景？

这一步很重要，因为不可量化目标往往是上线后争论的来源。AI 不应该把它们强行改成数字，也不应该忽略它们。更好的处理方式是形成“确认问题”，让相关方决定是否纳入验收、如何观察、谁来确认。

第七步，把草案发给相关方确认，而不是直接当成结论。

AI 生成的成功标准表必须有状态。建议标成“待业务确认”“待合同确认”“待数据口径确认”“待验收负责人确认”。每个指标后面都写一个负责人或待确认角色。比如订单处理时长指标需要业务负责人和销售运营确认，系统稳定性指标需要信息化确认，范围边界需要甲乙方项目经理确认，最终验收材料需要验收负责人确认。

这能防止一个常见误区：项目经理让 AI 写了一张很完整的表，然后默认大家已经同意。没有确认就没有标准。AI 只是把讨论稿写得更完整，真正生效必须经过项目治理流程。

第八步，把确认后的成功标准放进项目管理节奏。

成功标准不是立项材料里的摆设。立项确认后，它应该进入周会、里程碑评审、范围变更和验收准备。每次出现需求变更时，都问一句：这会改变哪条成功标准？每次讨论延期时，都问一句：延期是为了保住哪个业务结果、范围项或质量底线？每次准备验收时，都按照成功标准收证据。

这一步能让成功标准从“写得好”变成“用得上”。否则再好的表，开工后没人看，验收时仍然会回到口水仗。

输入示例

可以直接参考的输入材料

下面是一段可以直接给 AI 的输入样例。它使用虚构项目，但结构来自真实立项场景。你可以替换成自己的项目材料。

你是项目立项成功标准梳理助手。请根据以下材料，帮我把项目成功标准拆成业务结果、交付范围、质量要求和验收指标。

项目背景：
我们准备做“经销商订单协同系统一期”。现在经销商通过微信群、表格和电话提交订单，销售助理再手工录入 ERP。旺季时容易漏单、错单，订单状态也需要人工反复询问。

立项目标原文：
三个月内上线系统，减少销售助理手工录单，提高订单处理效率，让重点区域经销商能在线提交订单并查看处理状态。

合同范围草案：
1. 经销商下单
2. 销售确认
3. 库存校验
4. 发货状态同步
5. 对账明细导出
6. 基础权限管理
一期不包含价格政策自动推荐、授信调整、移动端小程序重构和经营分析大屏。

业务 KPI 和线索：
- 当前订单从经销商提交到销售确认通常需要约 2 个工作日，但还没有正式基线统计。
- 销售助理每天约 2 小时用于收单、录单和催状态。
- 旺季错单率约 3%，主要来自商品规格、数量和收货信息录入错误。
- 经销商希望知道订单是否已确认、是否缺货、是否已发货。

验收要求：
- 甲方业务负责人、信息化负责人、试点区域负责人和乙方项目经理共同参与确认。
- 需要预发环境测试记录、培训材料、试运行反馈和问题关闭记录。
- 试点区域预计运行 2 周后做阶段验收。

历史复盘：
- 上一个流程系统功能上线，但没有定义效率提升口径，上线后业务认为没有达到预期。
- 报表项目曾因数据口径没有提前确认，在验收阶段反复返工。

请输出：
1. 成功标准表，字段包括：维度、标准草案、证据或指标、确认人、待确认问题。
2. 验收指标草案，分成功能验收、业务观察、质量检查、材料确认。
3. 不可量化目标的确认问题，专门处理“效率提升、协同顺畅、体验好、状态透明”。

要求：
- 不要替甲乙方拍板。
- 不要把草案写成最终承诺。
- 不输出技术方案。
- 对缺少基线数据的地方标注“待确认基线”。

提示词

可复制使用的提示词

你可以复制下面这段提示词，用在自己的项目立项材料上。建议把真实客户名、合同金额、个人信息、内部密钥和敏感经营数据先脱敏。

使用时有一个小技巧：如果 AI 输出太像最终文件，你要追问它“请把所有未经确认的数字、范围和负责人标出来”。如果它把“效率提升 30%”写得很肯定，你要让它改成“效率提升目标待业务负责人确认，建议先确认当前基线和试点期观察周期”。立项阶段宁可多一个待确认项，也不要多一个假确定。

请你作为项目立项成功标准梳理助手，帮我把一个即将启动的项目从“模糊目标”整理成“可确认的成功标准草案”。

我的项目材料如下：
【项目目标】
粘贴立项目标、老板要求、业务背景。

【合同条款或范围说明】
粘贴本期包含模块、交付物、里程碑、明确不做的范围。

【业务 KPI 或过程指标】
粘贴处理时长、差错率、人工耗时、满意度、投诉量、使用率、历史基线等材料。没有基线就写没有。

【验收要求】
粘贴谁参与验收、验收材料、试运行周期、测试要求、签字流程。

【历史类似项目复盘】
粘贴过去类似项目成功或失败的原因，尤其是上线后争议点。

请按以下结构输出：

一、成功标准表
字段包括：维度、成功标准草案、证据或指标、确认人、待确认问题。
维度至少包括：业务结果、交付范围、质量要求、验收指标。

二、验收指标草案
分为功能验收、业务观察、质量检查、材料确认。每条指标都要说明可观察证据。

三、不可量化目标确认问题
针对“体验更好、协同更顺畅、管理更透明、效率提升”等表达，列出必须向业务方确认的问题。

四、风险提醒
指出哪些标准目前缺少基线、缺少负责人、与合同范围可能不一致，或需要甲乙方共同确认。

限制：
1. 你只能起草和拆解，不能替甲乙方拍板。
2. 不要把建议指标写成已经承诺的最终指标。
3. 不要输出技术方案、数据库设计或排期。
4. 对无法判断的地方标注“待确认”，并给出确认问题。
5. 专门区分“交付完成”和“项目成功”。

输出样例

AI 应该输出到什么程度

下面是基于前面输入材料可能得到的输出样例。注意，它是草案，不是最终验收文件。

| 维度 | 成功标准草案 | 证据或指标 | 确认人 | 待确认问题 | | --- | --- | --- | --- | --- | | 业务结果 | 试点区域订单从经销商提交到销售确认的处理效率提升，目标口径以立项后一周确认的基线为准 | 当前约 2 个工作日为线索，需补充样本统计；试运行 2 周后对比处理时长 | 业务负责人、销售运营负责人 | 是否以平均时长、中位数，还是超时订单占比作为主指标 | | 业务结果 | 销售助理手工收单、录单、催状态的时间减少 | 试点前后抽样记录销售助理每日相关耗时；若无法量化，至少收集典型任务步骤变化 | 试点区域负责人 | 是否要求明确降幅，还是先作为观察指标 | | 交付范围 | 一期覆盖经销商下单、销售确认、库存校验、发货状态同步、对账明细导出、基础权限管理 | 合同范围、功能演示记录、测试用例通过记录 | 甲乙方项目经理 | 对账导出字段是否以财务现有模板为准 | | 交付范围 | 一期不覆盖价格政策自动推荐、授信调整、移动端小程序重构和经营分析大屏 | 立项纪要、范围边界确认 | 业务负责人、乙方项目经理 | 若试点经销商强烈要求移动端优化，是否进入二期 | | 质量要求 | 核心下单链路在试点期可稳定使用，关键异常有提示和处理记录 | 正常订单、库存不足、规格错误、取消订单、发货状态更新等样例测试记录 | 信息化负责人、乙方测试负责人 | 试点期重大故障的定义和响应时限 | | 质量要求 | 订单关键字段传递准确，导出明细与系统订单明细口径一致 | 字段核对记录、对账样例、问题关闭记录 | 财务负责人、信息化负责人 | 金额、折扣、税率等字段是否纳入一期核对 | | 验收指标 | 功能验收、业务观察、质量检查、材料确认四类证据齐全后进入阶段验收 | 测试报告、培训材料、试运行反馈、问题清单和关闭记录 | 验收负责人 | 谁拥有最终验收签字权，试点反馈是否有否决权 |

验收指标草案可以进一步写成：

不可量化目标的确认问题可以写成：

这份输出的关键不是让你照抄，而是让立项会有东西可改。业务负责人可以把处理时长目标调低或调高，项目经理可以指出某项不在合同范围内，信息化可以补充安全要求，财务可以确认对账口径。AI 起草之后，人来确认，标准才真正成立。

1. 功能验收：使用脱敏样例数据，经销商能够提交订单，销售能够确认订单，系统能够进行库存校验，发货状态能够被查看，财务能够导出对账明细。
2. 业务观察：试点运行 2 周后，观察订单确认时长、销售助理手工处理耗时、错单登记数量和经销商状态查询反馈。具体降幅需在立项后一周确认基线后再定。
3. 质量检查：测试样例覆盖正常订单、库存不足、商品规格错误、订单取消、发货状态延迟、权限不足六类场景。发现的问题需要有归因、负责人和关闭记录。
4. 材料确认：交付测试记录、上线说明、培训材料、试运行反馈、问题关闭清单和范围边界确认表齐全。
5. “效率提升”主要指订单确认更快、销售助理少录入，还是经销商少催问状态？
6. “协同更顺畅”主要发生在哪些角色之间：经销商和销售、销售和仓配、销售和财务，还是全部都包括？
7. “体验好”由谁代表一线确认？是试点经销商、销售助理、销售主管，还是业务负责人？
8. 如果试点用户觉得页面还不够顺手，但核心流程和指标达到草案要求，是否算阶段成功？
9. 如果业务观察指标改善明显，但部分非核心体验建议未处理，是否进入二期需求池？
10. 哪些主观反馈会阻塞验收，哪些只作为优化建议记录？

人工验收

人要怎么检查和改到可用

拿到 AI 输出后，不要急着放进立项文档。先做五轮人工检查。

第一轮，检查是否偷换合同范围。AI 可能会根据“效率提升”自动加入一些听起来合理的功能，例如自动分单、智能推荐、移动端提醒、经营分析看板。你要逐条对照合同和范围说明，确认它们是本期范围、二期建议，还是完全不该出现。如果不在本期，就放到“非目标”或“后续机会”，不要让它混进成功标准。

第二轮，检查是否伪造基线。很多项目没有现成数据，AI 容易写出“处理时长下降 30%”“错单率下降 50%”这类漂亮数字。只要材料里没有依据，就必须改成“待确认基线”。如果业务确实需要量化目标，就安排立项后一周做样本统计，再把目标写进确认版。

第三轮，检查是否有人负责确认。每条成功标准都应该有确认角色。业务结果由业务负责人确认，范围边界由甲乙方项目经理确认，质量要求由信息化或测试负责人确认，财务口径由财务负责人确认，最终验收由约定验收人确认。如果一条标准没有确认人，它很可能会在验收时变成争议。

第四轮，检查是否混淆“阶段成功”和“最终成功”。有些项目一期只是试点，不可能承担全部经营结果。比如试点区域订单效率改善，不等于全国经销商体系都完成数字化转型。你要把一期成功写成一期能承担的结果，把长期目标放到背景或后续阶段。否则项目会背上过大的承诺。

第五轮，检查语言是否能被执行。把“显著提升”“大幅减少”“高效协同”“体验友好”改成更具体的描述。如果确实不能量化，就补确认问题和观察方式。例如“体验友好”可以改成“试点销售助理能在培训后独立完成下单确认、异常处理和状态查询，遇到问题能根据页面提示或操作手册处理”。这不完美，但比“友好”更容易检查。

最后，把修改后的草案带回相关方会议。你可以这样说：“这不是最终验收清单，也不是新增合同义务，而是为了避免上线后对成功理解不一致。请大家确认哪些是本期必须达到的，哪些只是观察指标，哪些放到二期。”这句话能降低对抗感，也能提醒大家：现在定标准，是为了保护项目，而不是给任何一方增加陷阱。

失败反例

这些失败反例要提前避开

【反例 1：只写“系统按期上线”，不写业务结果】

错误写法：

这句话只覆盖交付完成，没有覆盖项目为什么要做。到了上线后，乙方可以说功能完成，甲方业务可以说效率没有提升。双方都能找到理由。更稳的写法是把交付完成和业务观察分开：三个月内完成合同范围功能上线，同时在试点期观察订单确认时长、手工录入耗时、错单登记和经销商状态查询反馈。若缺少基线，就明确基线确认时间，而不是假装已经有数字。

【反例 2：把主观感受写成唯一验收标准】

错误写法：

这句话很容易引发争议。谁代表销售？几个经销商反馈算数？一个关键用户不满意是否否决验收？“明显”由谁判断？更稳的写法是保留主观反馈，但不要让它单独决定成败。例如“试点销售助理和经销商代表完成培训后，能独立完成下单、确认、状态查询和异常反馈；主观体验反馈作为优化建议记录，其中阻塞核心流程的问题必须关闭后再验收”。这样既尊重体验，也不让体验变成无限争议。

【反例 3：让 AI 直接定承诺数字】

错误写法：

这类数字看起来专业，其实很危险。如果没有历史基线、统计口径、样本范围和业务确认，它们只是漂亮的幻觉。项目经理把它写进材料，后面很可能变成承诺风险。更稳的写法是：“订单处理效率提升目标待确认。建议先由销售运营提供试点区域最近 4 周样本，确定当前平均处理时长、中位数和超时订单占比，再由业务负责人确认一期目标。”AI 可以提出候选指标，但不能替甲乙方决定目标值。

【反例 4：把二期愿望塞进一期成功标准】

错误写法：

如果合同一期没有价格政策自动推荐和经营分析大屏，这就是范围蔓延。上线后任何一个二期愿望没完成，都可能被拿来否定一期。更稳的写法是明确“一期成功不以价格政策自动推荐、授信调整、移动端重构和经营分析大屏为前提；相关需求进入二期候选池”。项目成功标准要保护本期范围，不是把所有愿望都装进去。

成功标准：三个月内完成经销商订单协同系统上线，合同范围内功能可用。

成功标准：销售和经销商觉得系统好用，协同体验明显提升。

AI 建议本项目成功标准为：订单处理效率提升 50%，错单率降低 80%，用户满意度达到 95%。

成功标准：经销商能在线下单，系统能根据价格政策自动推荐最优价格，领导能实时查看全国经营分析大屏。

主题边界

它和相邻主题的区别

这个主题专门处理“成功定义”，不替代客户验收清单。两者相邻，但不是一回事。

成功定义回答的是：项目为什么做，做到什么业务状态算值得，哪些范围和质量底线必须守住，验收时用哪些证据判断方向是否达成。它应该在立项时讨论，服务对象是业务负责人、项目经理、信息化负责人和关键验收人。它更关注业务结果、范围边界、质量底线和指标口径。

客户验收清单回答的是：到验收节点时，需要逐项检查哪些功能、文档、培训、测试和交付物是否完成。它通常更细、更流程化，服务于验收执行。比如按钮能不能点击、字段是否正确、导出文件是否符合模板、培训记录是否齐全、问题是否关闭。这些都重要，但它们不能单独证明项目成功。

如果你只做成功定义，不做验收清单，项目会有方向但缺少落地检查。如果你只做验收清单，不做成功定义，项目可能功能都勾选通过，却没人说得清业务价值是否实现。比较稳的做法是：立项时先定成功标准，实施过程中据此管理范围和质量，验收前再把成功标准展开成客户验收清单和证据包。

它也不同于项目复盘。复盘是在项目结束后总结哪里做得好、哪里做得不好；成功标准是在项目开始前约定怎么判断。好的复盘会反过来改进下一次立项的成功标准，但不能等到复盘时才第一次讨论成功。

它还不同于 KPI 设计。KPI 是组织管理指标，可能跨项目、跨部门、跨周期。项目成功标准可以引用 KPI，但不应该把整个组织 KPI 都压到一个项目上。比如月度销售达成率受市场、价格、渠道、库存等多因素影响，订单协同系统一期最多能承诺改善订单处理链路中的一部分过程指标。把大 KPI 拆成项目能影响的过程指标，才是立项阶段该做的事。

最后再强调一次：AI 的角色是整理、追问、起草和暴露分歧。它可以帮你把“提高效率”拆成订单确认时长、手工录入耗时、错单率、状态查询次数；可以把“做完系统”拆成功能范围、非目标、质量底线和验收证据；可以把“体验好”拆成谁的体验、哪个任务、什么反馈阻塞验收。但最终成功标准必须由相关方确认。项目能不能被叫作成功，不能交给 AI，也不能留到上线后再吵。