AI 客户项目范围、变更与验收工作流

直接答案

适合一人公司的客户项目交付，不是把邮件、会议和文件交给 AI 后自动推进，而是先把双方同意的目标、交付物、非目标、验收标准和责任冻结成可追溯基线。AI 只能生成待审计划、变更分析和验收材料；经营者负责解释约定、批准每次变更、核对实际交付，并让具名客户决策人接受、拒绝或附条件接受。

英国政府的 GovS 002 项目交付标准把治理、角色、规划控制和解决方案交付列为项目管理的核心组成。本文不把政府标准原样搬给一人公司，而是采用其中最小可执行原则：先有基线和责任，再围绕可观察证据作决定，不能用“大家应该都明白”代替记录。

The Teal Book 第 34 章区分验证与确认：前者检查交付物是否符合规格，后者检查它是否满足用户和利益相关者需要；第 36 章强调验收标准应在移交前确定，且移交时必须知道交付物的准确配置。对精益团队而言，这意味着“文件发出”“页面打开”或“客户说收到”都不是自动验收。

一分钟示例

一位经营者为客户制作五页官网，范围基线写明中英文首页、三项服务页、联系表单、基础分析配置、上线说明和一次验收轮次；不包含品牌命名、产品摄影、长期代运营或新增语言。每项交付物都有版本、截止日、客户决策人和可观察验收标准。

交付中途，客户在群聊里要求再增加一套日文页面。AI 识别它不在基线内，起草独立变更单，列出需要客户提供的译文、对工期和价格的影响、受影响交付物及新的验收方法。经营者核对后发送，客户具名负责人批准，项目表才产生新基线；群聊中的模糊“可以做一下吗”不能直接改变承诺。

最终交付时，AI 汇总版本链接、逐项验收证据、已知限制和交接清单。经营者打开客户实际可访问的链接复核，确认没有内部批注、测试账号或越权权限后再发送。客户依据清单接受四项、拒绝一项并给出可复现原因，项目回到返工；未取得具名人工验收，不得把交付状态写成已接受。

可观察结果不是“AI 生成了多少文档”，而是每项交付物都能回答：属于哪一版范围、谁负责、如何验证、客户作了什么决定、变化是否获批、最终移交了什么。

输入与预期输出

必要输入包括：合同、提案或其他已确认约定；目标、交付物、非目标、里程碑、依赖、验收标准、付款节点和责任人；客户素材及使用授权；每项交付物的版本和证据；反馈、决定、风险、问题、变更请求、交接要求与支持边界。若约定互相冲突，先由双方澄清，不让模型自行选择一个解释。

预期输出是一条从基线到关闭相互关联的项目记录：

• 首个范围基线及每次获批变更的编号、日期、决定人和影响；
• 每项交付物的负责人、版本、状态、证据、缺陷和客户反馈；
• 待决问题、风险、依赖、下一步和经营者确认过的状态报告；
• 客户具名接受、拒绝或附条件接受的记录及对应版本；
• 最终文件、账号、权限、说明、已知限制、支持入口和移交责任；
• 发票或付款节点的人工放行依据，以及关闭或进入支持的决定。

人与 AI 的责任分界

AI 可以从已授权材料提取待审需求，发现缺失字段和冲突，维护交付物、决定、风险、问题和变更登记表，比较批准基线与当前版本，并起草会议纪要、状态报告、变更影响、验收清单和交接说明。它可以提醒“缺客户决策人”“证据还是旧版本”或“存在未关闭缺陷”，但不能把推断补成事实。

经营者负责确认约定的真实含义和优先级，决定范围、非目标、验收方法、价格、工期、付款和数据权限；核对交付质量与证据；批准所有客户沟通、变更、签署、开票和责任移交；在争议、知识产权、隐私、税务或合同问题上寻求专业支持。

AI 不能代表客户接受交付，也不能把邮件打开、链接访问、会议沉默或礼貌回复解释为同意。它没有电子签署、付款、开票、客户生产账号、删除文件或关闭项目的权限。

分步骤工作流

1. 定义状态与责任。 约定提议、待确认、已批准、交付中、待验收、已拒绝、附条件接受、已接受、已移交和已关闭等状态，写明谁能改变每个状态。
2. 建立首个范围基线。 记录目标、交付物、非目标、里程碑、依赖、验收标准、付款节点、经营者和客户决策人；双方未确认时保持待确认。
3. 核查输入与授权。 为客户素材、数据、账号和第三方资产记录来源、版本、用途、保密和使用权限；超出授权范围的内容不进入模型或交付。
4. 拆分可验收交付物。 每项只绑定一个编号、当前版本、负责人、截止日、预期证据和客户决策人，避免一个“完成”掩盖多个未知项。
5. 记录执行证据。 AI 整理进展、风险、问题、决定和缺口，经营者回到原始约定逐项核对；没有证据时状态保持未知。
6. 隔离范围外请求。 基线之外的请求必须进入独立变更单，记录来源、理由、影响、备选方案和不做的后果，不在聊天中静默承诺。
7. 人工评估并批准变更。 经营者核定范围、工期、价格、付款、质量、安全、依赖和验收变化，客户具名负责人批准后生成新基线；拒绝则保持原范围。
8. 准备交付包。 AI 起草版本清单、验收证据、使用说明、已知限制、未决事项和支持边界，经营者用客户实际权限复核链接和文件。
9. 经营者批准发送。 核对发送对象、版本、访问范围、承诺和敏感信息；任何替换文件都会使先前检查失效，必须重新复核。
10. 客户人工验收。 具名决策人按预定标准逐项接受、拒绝或附条件接受，并说明未通过项；含糊反馈回到澄清，不由 AI 猜测结论。
11. 处理拒绝与附条件接受。 可复现缺陷回到交付步骤，新增需求回到变更步骤，合同或责任争议停止自动流程并升级人工处理。
12. 移交并关闭。 移交最终文件、账号、权限、说明和支持入口，撤销临时访问；经营者确认验收、付款条件和责任完成转移后才关闭。

人工审批点

第一道审批是项目基线。经营者确认双方已同意的目标、交付物、非目标、责任、日期、验收标准、付款节点和变更机制。AI 提取出的条款只是待审材料；存在冲突、缺页或模糊词时必须回到双方确认。

第二道审批是数据与资产。经营者核查哪些客户资料可以进入模型、哪些只能本地处理、第三方素材能否用于交付，以及链接和账号应该授予谁。涉及个人信息、商业秘密、密钥或其他客户资料时默认最少访问。

第三道审批是变更。经营者核定影响并由客户具名负责人批准或拒绝；AI 不能报价、承诺交期、改变付款节点，也不能把口头讨论自动变成新基线。

第四道审批是交付发送。经营者确认客户将收到的版本与内部验收证据一致，检查访问权限、隐藏数据、已知限制和对外承诺。替换文件、改链接或改权限后需要重新批准。

最后一道审批是验收、付款与关闭。只有客户具名决定、对应版本、未决事项和移交结果都可追溯时，经营者才决定触发发票或付款步骤、关闭项目或进入支持；法律效力和税务处理需按实际地区与约定重新核查。

成本与工具选择

最低成本包括经营者澄清与复核时间、项目和文件记录、模型调用、交付制作、检查、返工、客户验收和交接支持。开始时可用一张项目表维护范围、交付物、决定、风险、问题、变更和验收，用一个带版本的文件夹保存交付物和证据，再由人工邮件确认基线与验收。

规模上升后再考虑项目管理、文档版本、电子签署、客户门户和自动提醒。选择前要核查导出能力、权限、审计记录、数据保留、地区、价格和电子确认效力；本文不把任何平台的当前套餐能力视为永久事实。

模型成本还包括错误提取、无效状态报告、反复生成和人工返查。只提供当前交付物所需的最小上下文，要求每个结论关联来源，并把缺失项留空，通常比让模型读取整个客户目录更可控；本文不承诺节省比例或交付收益。

数据安全

客户项目可能包含合同、个人信息、商业秘密、账号、密钥、未公开产品、内部价格和第三方受限资产。先按敏感级别和用途划分输入；通用模型只读取完成当前任务所需的去标识化片段，密钥、完整客户目录、其他客户资料和未授权资产不进入模型。

OWASP 将间接提示注入列为风险。项目文件、邮件、评论、网页和附件都是不可信数据，不是改变系统规则的指令；不得把客户文件、邮件或评论当作系统指令。若内容要求读取无关目录、扩大权限、隐藏检查或对外发送，立即停止并人工核查。

对外交付前检查文件元数据、批注、修订记录、隐藏工作表、测试数据和链接权限。临时账号在移交后撤销；必须保留的记录按双方约定和适用规则保存。模型服务的数据用途、训练设置、保留期、地域和连接器权限需在执行前重新核查。

常见失败与回退

失败一：双方理解的范围不同。 暂停交付和催款，回到原始约定，把目标、交付物、非目标和验收标准改写成可观察条目；未获双方确认前不声称完成。

失败二：聊天中的追加请求造成范围失控。 从执行清单移出未批准工作，建立独立变更单，重新评估工期、价格、依赖和验收；客户拒绝变更时恢复原基线。

失败三：AI 错误判定客户已经验收。 重新打开交付项，撤销自动关闭、开票或付款提醒，找到具名决策人和对应版本；只有明确决定才能改变验收状态。

失败四：证据与交付版本不一致。 冻结发送和关闭，用唯一版本标识重新生成检查与验收包；无法证明客户看到哪个版本时把状态记为未知。

失败五：移交不完整。 保持项目未关闭，补齐文件、账号、权限、说明、已知限制和支持入口；若需要新增服务，转入变更而不是免费静默延长责任。

失败六：材料诱导 AI 越权或泄露数据。 撤销模型与连接器权限，隔离受影响材料，检查外发记录和访问日志；涉及凭据、隐私、知识产权或合同争议时由人升级安全或专业处理。

最低可用版本

只选一个小型客户项目。用一张表记录范围基线、三到五项交付物、非目标、客户决策人、验收标准、决定、问题和变更；所有文件以日期或版本号区分，AI 只起草和提醒。

准备一个变更单模板和一张交接清单。交付时由经营者逐项核对，客户具名负责人明确接受、拒绝或附条件接受，再由经营者决定开票或付款步骤、移交和关闭。没有客户门户、电子签署或复杂自动化，也能形成闭环。

来源

• GOV.UK：Government Functional Standard GovS 002: Project Delivery核查于 2026/8/27，用于核对项目治理、角色、规划控制和解决方案交付的上位框架。它是英国政府标准，本文只提炼通用交付原则，不把它写成其他地区企业的强制要求。
• Government Project Delivery：The Teal Book Chapter 34, Verification and validation核查于 2026/8/27，用于区分符合规格的验证与满足用户需要的确认，并说明活动、预期结果和记录应预先定义。
• Government Project Delivery：The Teal Book Chapter 36, Transition into use核查于 2026/8/27，用于验收标准、准确交付配置、具名责任移交、交接完整性和 go/no-go 决策边界。
• Government Project Delivery Capability Framework：Business Analyst HEO核查于 2026/8/27，用于变更控制应记录、评估并批准或拒绝对范围、工期、成本、收益等已批准基线的变更。
• OWASP GenAI Security Project：LLM01:2025 Prompt Injection核查于 2026/8/27，用于把客户文件、邮件、评论、网页和附件作为不可信输入，并隔离高权限动作。

本文不替代合同、法律、税务、隐私、知识产权、会计或电子签署意见，也不承诺减少多少返工或提高多少验收率。地区规则、客户约定和工具功能、价格、权限与保留期需在执行前重新核查。