一、AI项目验收，核心不是让客户表态，而是让交付有标准

（一）客户“不满意”，不能当然等于供应商没有履约

AI项目交付后，客户最常见的拒收理由，往往不是系统完全不能用，而是效果没有达到预期、回答不够准确、业务部门不满意、还不能替代人工、系统还需要继续优化、知识库内容还不完整、真实场景表现不如演示。

这些反馈有些是真问题，有些只是预期差。

有的属于合同范围内缺陷，供应商应当整改。

有的属于客户数据质量问题，例如客户提供的知识库资料本身过期、冲突、不完整。

有的属于客户业务流程未配合，例如接口没有开放、测试样本没有确认、业务人员没有参与验收。

有的属于客户对AI能力预期过高，例如希望系统直接替代专业人员，或者要求开放问答场景达到演示环境中的效果。

还有一些属于后续迭代优化，不应阻却初步验收。例如提示词继续优化、知识库继续补充、用户体验继续改进、业务流程继续适配。

AI项目的验收争议，最怕合同只写一句“经客户验收合格”。

如果没有具体标准、流程、期限、缺陷分级、整改次数和视为验收机制，客户一句“不满意”，就可能拖住验收和付款。供应商明明已经完成主要交付，却无法证明项目已经达到可验收状态。

（二）AI项目不能照搬普通软件验收

普通软件项目主要验收功能模块、接口联通、页面展示、权限配置、部署环境、数据迁移。

这些内容在AI项目中仍然重要，但不够。

AI项目还要验收模型版本、测试数据、知识库范围、召回和引用效果、输出质量、Agent工作流、客户输入和复核流程、异常处理和日志留存。

例如，一个企业知识库问答项目，不能只验收“系统页面能打开、账号能登录、文档能上传”。还要看知识库范围是否已经确认，文档是否完成切分和索引，检索结果是否能引用来源，回答是否能区分有依据和无依据，错误问题如何记录，客户如何更新知识库。

再如，一个Agent项目，不能只验收“智能体可以调用接口”。还要看调用权限、触发条件、执行前确认、执行日志、异常中止、回滚机制、高危操作控制。

如果只按普通软件项目写验收，AI项目最关键的“效果边界”会缺失。客户会把模型优化、业务流程调整、知识库补充、新场景扩展，都包装成“验收未通过”；供应商则会认为这些已经超出原合同范围。

（三）验收条款要解决十个问题

AI企业给客户交付项目时，验收条款至少要解决十个问题。

第一，验收对象是什么。不能只写“AI系统一套”。

第二，验收标准是什么。不能只写“客户认可”。

第三，测试数据是什么。不能验收时临时换题。

第四，验收流程怎么走。不能只等客户一句话。

第五，试运行期多长。不能无限试用。

第六，缺陷如何分级。不能有问题就拒收。

第七，整改几次、多久完成。不能无限整改。

第八，客户要配合什么。不能客户不配合却让供应商背锅。

第九，什么情况下视为验收。不能客户长期不表态。

第十，验收后持续优化如何处理。不能把运维期需求倒推成初次验收缺陷。

这些问题写清楚，AI项目才有交付闭环、收款闭环和争议处理边界。

二、先明确验收对象，不能笼统写“项目成果”

（一）AI项目交付成果通常不止一个

AI项目的交付成果，往往不是一个单一系统。

常见交付内容包括系统平台、模型接口、知识库、提示词模板、Agent工作流、数据清洗规则、权限配置、接口对接、部署文档、使用手册、培训服务、运维支持。

如果合同只写“交付AI系统一套”，客户很容易把所有后续期待都纳入验收范围。

客户可能认为，既然交付的是AI系统，就应当自动覆盖所有业务问题、所有知识库资料、所有部门场景、所有后续接口、所有新增功能、所有模型调优。

供应商则可能认为，自己交付的是合同范围内的系统平台和基础AI能力，客户后续提出的新场景、新数据、新接口、新工作流，不应免费纳入验收。

争议往往就从这里开始。

验收对象越模糊，供应商越难证明自己已经完成交付。客户也越难判断哪些问题属于缺陷，哪些问题属于优化，哪些问题属于新增需求。

（二）验收对象应分层列明

AI项目验收对象建议至少分五层。

第一层，基础系统交付。

包括账号、权限、页面、功能模块、接口、部署环境、系统访问、基础配置。这一层主要解决系统能不能正常部署和访问。

第二层，AI能力交付。

包括模型调用、知识库检索、生成输出、Agent流程、插件能力、提示词模板、模型版本。这一层主要解决AI能力是否按合同约定接入和运行。

第三层，客户数据和知识库配置。

包括数据导入、格式处理、分段、索引、标签、更新机制、知识库范围确认。这一层非常关键，因为很多AI效果问题并不来自模型，而来自知识库质量和数据边界。

第四层，文档和培训交付。

包括部署文档、操作手册、管理员说明、培训记录、常见问题说明、客户运维指南。这些内容决定客户能否正确使用系统，也关系到后续责任划分。

第五层，试运行和支持服务。

包括试运行周期、缺陷修复、调优支持、问题响应、日志协助、版本更新。这一层要和初次验收区分清楚，不能把所有运维优化都纳入初次验收。

（三）持续优化不应无限拖延初次验收

AI项目通常需要持续优化。

知识库会更新，提示词会优化，模型版本会迭代，业务流程会调整，用户反馈会不断出现。

但持续优化不应无限拖延初次验收。

合同中应区分四个阶段。

第一，初次交付验收。判断合同约定的基础系统、核心功能、初始知识库、模型调用、文档培训是否完成。

第二，试运行调优。对初次交付后的重大缺陷、一般缺陷、配置问题进行处理。

第三，运维期优化。对上线后的知识库更新、提示词优化、模型调优、用户反馈进行持续支持。

第四，新增需求变更。对新功能、新场景、新接口、新模型能力、新部门上线进行另行评估。

如果不区分，客户很容易把运维期需求倒推为初次验收缺陷。

例如，客户在系统上线后提出新增业务部门、新增知识库、新增报表、新增接口，如果合同没有边界，客户可能主张“这些不完成就不能验收”。供应商则会陷入无休止交付。

三、验收标准要客观，不能只写“客户认可”

（一）“客户认可”“客户满意”“符合预期”都是高风险表述

AI项目验收条款里，最危险的表述之一，是“经客户认可后验收”“达到客户满意”“符合客户预期”。

这类表述的问题在于，没有客观标准，没有测试方法，没有期限，没有缺陷分级，没有整改边界。

客户主观感受当然重要，但不应成为唯一验收标准。

否则，验收权事实上完全掌握在客户手里。供应商即使完成交付，也可能因为某个业务部门不满意、某个领导认为还不够智能、某个用户觉得体验一般，而无法触发验收和付款。

AI项目更容易出现这种问题。

因为AI产品不像传统软件那样只看按钮能不能点、页面能不能跳转。客户会自然关注“好不好用”“聪不聪明”“能不能替代人工”“真实问题答得怎么样”。

这些感受如果不转化为客观指标，就会成为争议源头。

（二）验收标准至少分三类

AI项目验收标准至少要分三类。

第一类，功能验收标准。

包括功能是否上线，接口是否联通，权限是否生效，系统是否可访问，用户能否登录，客户数据能否导入，基础流程能否走通。

这一类标准相对客观，适合用功能清单、测试用例、截图、接口记录、部署记录证明。

第二类，性能验收标准。

包括响应时间，并发能力，系统可用性，接口成功率，检索速度，页面加载速度。

这一类标准要写清统计口径，例如统计周期、测试环境、并发数量、排除情形。

第三类，AI效果验收标准。

包括准确率、召回率、任务完成率、引用命中率、人工复核通过率、知识库答案覆盖率、错误分类和容忍度。

这一类标准最容易争议，必须绑定测试数据、测试方法、模型版本、知识库版本和客户配合条件。

（三）AI效果指标必须绑定测试条件

不要只写“准确率达到90%”。

要写清楚在哪个任务、哪个数据集、哪个环境、哪个模型版本、哪个知识库版本、哪个输入格式、哪个评测方法下达到。

至少应明确九项内容。

测试数据集是什么。

测试样本量是多少。

测试场景有哪些。

测试时间和测试环境是什么。

模型版本是什么。

知识库版本是什么。

客户输入格式是什么。

评测方法是什么。

通过标准是什么。

如果不写清楚，后续争议很可能变成：客户拿真实复杂场景要求供应商达到演示环境指标。

例如，演示时系统在十个标准问题中答对九个，客户后续在生产环境中输入大量非标准问题、模糊问题、超出知识库范围的问题，然后主张准确率不达标。此时，如果合同没有测试边界，供应商会非常被动。

四、测试数据要提前确认，不能验收时临时换题

（一）测试数据经常是验收争议的核心

AI项目验收争议中，测试数据往往是核心争议点。

供应商可能认为，系统在约定测试集上已经达标。

客户可能认为，真实业务数据下效果不够好。

双方争议的根源，通常是测试数据没有提前确认，测试样本和真实场景差异太大，客户验收时临时加入新类型问题，或者客户把训练范围外的问题也纳入验收。

例如，合同约定建设企业制度知识库，验收时客户拿业务合同、历史判例、员工问答记录进行测试。

合同约定客服问答场景，验收时客户要求系统处理投诉工单、自动判断赔偿金额、生成法律风险意见。

合同约定中文文本问答，验收时客户加入大量英文资料、扫描件、图片和表格。

这些都可能导致验收争议。

（二）测试数据应在合同或验收方案中确认

测试数据应在合同附件、需求说明书或验收方案中提前确认。

至少包括八项内容。

第一，样本来源。由客户提供、供应商提供，还是双方共同构造。

第二，样本数量。测试多少条问题、多少份文档、多少个任务。

第三，覆盖场景。覆盖哪些业务线、哪些知识库范围、哪些任务类型。

第四，难度分级。基础问题、复杂问题、边界问题是否分别统计。

第五，标准答案。是否有客户确认的标准答案或评价规则。

第六，客户确认方式。测试集是否经客户书面确认。

第七，是否可更新。更新条件、更新时间、更新后是否重新测试。

第八，是否作为后续验收依据。避免客户验收时临时换题。

如果客户提供测试数据，客户应保证数据真实、合法、格式符合要求。

如果供应商协助构造测试数据，客户应确认测试集的代表性和适用范围。

（三）测试数据不能无限扩张

可以约定，验收以双方确认的测试数据和测试场景为准。

客户新增场景、新增业务线、新增知识库范围，应作为需求变更或后续优化处理。

不能在验收时临时提出合同未覆盖的新问题、知识库未包含的新资料、模型未训练的新任务、客户新业务部门的新要求。

这不是限制客户使用AI，而是区分初次验收和持续迭代。

AI系统可以继续优化，但验收必须有边界。

如果边界不清，项目验收会被无限拉长，供应商永远处在“还没完全达到客户想象”的状态。

五、试运行期要有期限，不能无限试用

（一）试运行有必要，但不能没有尽头

AI项目常需要试运行。

试运行的目的，是发现缺陷，收集反馈，优化配置，培训用户，验证系统稳定性。

这很正常。

但试运行不能没有尽头。

如果合同不设期限，客户可能长期试用而不验收，供应商持续投入却无法收款。

AI项目尤其容易出现“再试一段时间”“业务部门还想继续看看”“领导觉得效果还可以再优化”“知识库还要继续补”“用户反馈还没收齐”这类拖延。

如果试运行期没有期限，试用就可能变成免费长期服务。

（二）试运行期应明确起止时间

试运行期要写清起算节点。

可以约定从系统部署完成、账号开通、客户数据导入完成、培训完成、双方确认试运行开始之日起计算。

试运行期限也要写清。

例如15日、30日、60日，具体期限应根据项目复杂程度确定。

试运行结束后的动作也要写清。

客户应出具验收意见，或者提出缺陷清单。客户逾期未反馈的，应视为验收通过，或者视为无重大缺陷。

试运行期不能和运维期混同。

否则，客户可能把运维服务当作继续验收，项目长期无法收尾。

（三）试运行反馈要形成书面闭环

客户应在试运行期内提出问题清单。

问题要分类。

重大缺陷，是影响合同主要功能、主要任务或系统安全的问题。

一般缺陷，是不影响主要功能使用的问题。

优化建议，是用户体验、交互方式、知识库扩展、提示词调整等改进意见。

新增需求，是合同未约定的新功能、新场景、新接口、新模型能力。

供应商应按分类处理。

重大缺陷影响验收，应当整改。

一般缺陷可以不影响验收，在约定期限内修复。

优化建议进入运维期或优化计划。

新增需求另行计费或签补充协议。

如果不分类，所有反馈都会被客户当成拒收理由。

六、缺陷要分级，不是有问题就不能验收

（一）AI项目不可能没有任何问题

AI项目不可能没有任何问题。

尤其是生成式AI、RAG、Agent项目，一定会有边界问题，一定会有个别错误回答，一定会有知识库不完整问题，一定会有用户使用不规范问题。

如果合同写成“无任何缺陷方可验收”，供应商几乎无法完成验收。

因为AI系统永远可以继续优化，知识库永远可以继续更新，提示词永远可以继续调整，用户问题永远可能出现新类型。

合理做法是区分缺陷等级，不是所有问题都阻却验收。

（二）缺陷分级可以这样设计

缺陷可以分为四类。

第一，重大缺陷。

例如系统无法登录，核心功能不可用，数据严重错误，无法完成合同约定主要任务，存在重大安全风险，主要接口完全不通，Agent高危操作无法控制。

重大缺陷可以阻却验收，供应商应在约定期限内整改。

第二，一般缺陷。

例如部分功能异常，个别输出错误，页面显示问题，非核心接口偶发失败，个别知识库引用不完整。

一般缺陷不应阻却整体验收，可以约定在验收后一定期限内修复。

第三，优化建议。

例如客户希望改进交互体验，希望扩大知识库范围，希望增加提示词模板，希望增加管理报表，希望调整展示样式。

优化建议不应影响验收，可以进入运维或优化计划。

第四，新增需求。

例如合同未约定的新功能、新场景、新接口、新模型能力、新数据源、新用户规模、新部署环境。

新增需求不影响原项目验收，应另行报价或签署补充协议。

（三）不同缺陷要对应不同后果

验收条款应明确不同缺陷后果。

存在重大缺陷，可以顺延验收并要求整改。

存在一般缺陷，不影响验收，可在约定期限内修复。

优化建议不影响验收，进入运维或优化计划。

新增需求不影响验收，另行报价或签署补充协议。

这样才能防止客户把所有问题都包装成拒收理由。

对客户来说，缺陷分级也有好处。它能帮助客户把真正影响使用的问题优先解决，而不是把所有体验反馈混在一起，导致项目迟迟无法上线。

七、整改次数和期限要写清，不能无限整改

（一）AI项目如果没有整改边界，供应商会长期被动

AI项目如果没有整改边界，供应商会陷入长期被动。

客户可能反复提出：再优化一下，再调整一下，业务部门又有新意见，领导觉得效果还不够好，真实用户还要再看看。

如果合同没有整改次数和期限，供应商无法判断何时完成履约。

AI项目尤其容易被无限优化，因为模型和知识库永远存在改进空间。

但合同履约不能因为“还可以更好”而永远不能结束。

（二）整改机制要写清楚

合同应当写清整改机制。

客户在验收期内一次性提出缺陷清单。

供应商在约定期限内完成整改。

整改完成后客户复验。

复验仍不通过的，客户应说明具体未达标事项。

同一缺陷可约定整改次数，例如不超过两次或三次。

超过约定次数仍未达标，双方按合同约定处理，例如延期、减免费用、终止未达标部分、进入争议解决机制。

客户未按期复验的，应视为验收通过，或者视为相关缺陷已修复。

整改机制的关键，不是让供应商逃避责任，而是让整改可以结束。

（三）整改不应覆盖新增需求

客户在整改过程中提出的新功能，不应算作供应商未完成整改。

客户更换业务范围或测试标准，应作为需求变更。

客户提供新数据、新场景、新流程，应另行评估费用和周期。

否则，整改会变成无限开发。

例如，客户原本要求建设销售知识库，整改时提出还要接入售后工单系统、自动生成分析报表、支持多语言问答、增加数字人讲解。这些不属于原缺陷整改，而是新增需求。

合同里如果不写清，供应商很容易在“整改”名义下被迫免费开发新需求。

八、客户配合义务必须写进验收条款

（一）AI项目交付效果高度依赖客户配合

AI项目交付效果高度依赖客户配合。

客户应配合按时提供数据，确认知识库范围，提供测试样本，开放接口，提供业务人员，安排管理员培训，确认验收标准，按期反馈问题。

这些事项如果客户不配合，AI企业很难按期交付。

但如果合同没有客户配合义务，延期和效果不佳反而可能被归责给供应商。

例如，客户迟迟不提供数据，却要求供应商按原计划交付。

客户没有确认知识库范围，却认为回答覆盖不足。

客户没有开放接口，却认为Agent不能执行流程。

客户没有安排业务人员参与测试，却认为系统不符合业务需求。

客户内部审批延迟，却认为项目延期。

这些都需要在合同中提前写清。

（二）客户配合义务要具体

客户配合义务不能只写“客户应予以配合”。

要具体到事项、期限、责任人和后果。

数据配合方面，客户应提供真实、完整、合法、格式符合要求的数据，并对其提供的数据来源、内容和授权负责。

接口配合方面，客户应开放必要系统接口、测试环境、账号权限和技术联系人。

人员配合方面，客户应指定项目负责人、业务专家、技术联系人和验收联系人。

测试配合方面，客户应按期确认测试集、标准答案、测试结果和验收意见。

反馈配合方面，客户应在验收期内书面反馈缺陷，并按缺陷等级说明问题。

审批配合方面，客户内部审批延迟不应影响供应商已完成交付的确认。

（三）客户不配合应产生合同后果

客户配合义务如果没有后果，就是空话。

合同应约定，客户未按期提供数据、接口、测试环境、业务人员、验收意见的，交付期限和验收期限相应顺延。

因此产生的额外工作量、驻场成本、重复部署、重复测试、延期维护，可以另行计费。

客户逾期未提供材料的，不影响阶段性交付确认。

客户逾期未反馈验收意见的，视为验收通过。

客户未按约开放接口、提供测试数据或确认验收标准的，不得以相关事项未完成为由主张供应商违约。

这些条款很关键。否则客户不配合导致项目卡住，最后仍可能由供应商承担延期和拒收风险。

九、必须设置视为验收机制，否则付款容易被拖住

（一）没有视为验收，客户可以长期不表态

很多项目争议不是客户明确拒收，而是客户一直不出验收意见。

客户可能说，内部还在看，领导还没批，业务部门还没反馈，先继续试用，后面一起验收。

如果合同没有视为验收机制，供应商很难触发付款节点。

AI项目尤其容易被拖住，因为客户总能找到“还可以优化”的理由。

系统可以更智能，知识库可以更完整，提示词可以更精细，回答可以更自然，用户体验可以更好。

如果没有视为验收，客户长期不表态，供应商就只能不断投入，却无法收款。

（二）视为验收可以设置几类情形

视为验收可以设置以下情形。

第一，客户收到验收申请后，逾期未提出书面异议。

第二，客户已实际使用系统开展业务。

第三，客户已向其内部员工或外部用户开放系统。

第四，客户已将系统用于生产环境。

第五，客户已基于系统输出对外提供服务或形成业务结果。

第六，客户无正当理由拒绝配合验收。

第七，客户提出的问题不属于重大缺陷或合同范围内事项。

这类情形的逻辑是，客户不能一边实际使用系统，一边拒绝承认验收。

尤其是客户已经把系统开放给员工、客户、公众或生产环境，说明系统已经具备实际使用状态。此时，除非存在重大缺陷，不宜再无限拖延验收。

（三）视为验收要和付款节点联动

验收通过或视为验收通过，应触发相应付款义务。

客户不得以一般缺陷、优化建议、新增需求为由拒付全部款项。

可以约定保留一定尾款对应缺陷修复，但不影响主体款项支付。

例如，项目主体款项在验收或视为验收后支付，少量尾款在一般缺陷修复或运维服务完成后支付。

如果不这样设计，客户可能利用小问题拖延大额付款。

AI项目付款节点不应完全依赖客户主观满意，而应和客观交付、验收流程、视为验收机制相互联动。

十、验收后的运维和持续优化要另行分清

（一）AI项目验收后仍会持续优化，但不等于项目未完成

AI产品上线后通常还会更新知识库，优化提示词，调整召回策略，升级模型版本，修复输出问题，处理用户反馈。

这些属于运维和持续优化，不应全部倒回初次验收阶段。

否则项目永远无法结束，付款也永远无法闭环。

客户当然可以要求系统持续改进，但这应当通过运维服务、优化服务、需求变更来处理，而不是无限期拒绝初次验收。

（二）运维期应单独约定

运维期应单独约定服务期限、响应时间、问题等级、修复时限、知识库更新范围、模型升级方式、优化次数或工作量、超范围服务收费标准、客户新增需求处理方式。

例如，合同可以约定运维期内每月提供一定次数的知识库更新支持，或者提供一定小时数的提示词优化服务。

超过约定范围的内容，应另行收费。

模型升级也要写清楚，是由供应商自主升级，还是需要客户确认；升级后是否重新测试；是否可能影响原有输出效果。

（三）验收后新增需求应走变更流程

验收后，如果客户提出新增功能、新增接口、新增业务场景、新增数据源、新增用户规模、新增模型能力、新增部署环境，不应作为原合同免费整改内容。

合同中应写清需求变更流程。

客户提出需求。

供应商评估工作量。

双方确认报价。

调整交付周期。

签署补充协议或书面确认。

再进入交付。

这样既保护供应商收款，也保护客户管理预算和预期。

十一、AI项目验收条款建议形成“八件套”

（一）交付成果清单

第一件，是交付成果清单。

至少列明系统、模型接口、知识库、Agent流程、文档、培训、部署、运维支持。

交付成果越清楚，验收边界越清楚。

（二）验收标准

第二件，是验收标准。

至少包括功能标准、性能标准、AI效果标准、数据标准、接口标准、日志标准。

不同标准对应不同测试和证明材料。

（三）测试数据和测试方法

第三件，是测试数据和测试方法。

至少包括测试集、样本量、标准答案、评测方法、通过标准、复测机制。

AI效果验收如果没有测试数据，争议风险很高。

（四）验收流程

第四件，是验收流程。

包括提交验收申请、客户测试、反馈缺陷、供应商整改、客户复验、出具验收确认。

流程要有时间节点，不要无限等待。

（五）试运行期限

第五件，是试运行期限。

包括起算条件、持续时间、反馈期限、结束后的处理。

试运行可以有，但不能无期限。

（六）缺陷分级和整改机制

第六件，是缺陷分级和整改机制。

包括重大缺陷、一般缺陷、优化建议、新增需求、整改次数、整改期限。

不同问题对应不同后果。

（七）客户配合义务

第七件，是客户配合义务。

包括数据、接口、人员、测试、反馈、审批。

客户不配合，应当有顺延、视为确认或费用调整后果。

（八）视为验收和付款联动

第八件，是视为验收和付款联动。

包括逾期未反馈、实际使用、生产上线、对外开放、无正当理由拒绝验收、触发付款。

这决定项目能否形成收款闭环。

十二、验收条款的价值，是让AI项目有边界、有证据、有收款闭环

（一）验收条款不是让供应商逃避责任

AI项目验收条款的核心，不是让供应商逃避责任，而是让交付有边界。

供应商应当对约定交付成果负责。

客户也应当对数据、配合、测试、反馈和最终使用负责。

模型可以优化，知识库可以更新，客户体验可以改进。

但这些不能成为无限期拒绝验收的理由。

AI项目如果没有边界，客户永远可以说“还不够好”；供应商永远无法证明“已经完成”。

（二）验收争议往往在合同签订时已经埋下

AI项目最容易出争议的地方，不在项目结束，而在合同签订时已经埋下。

验收对象没写清。

验收标准没写清。

测试数据没写清。

试运行期限没写清。

整改次数没写清。

客户配合义务没写清。

视为验收没写清。

付款节点没写清。

这些没写清，项目做得越复杂，后续越容易争议。

尤其是AI项目，效果本身具有不确定性。如果合同再不设边界，验收就会变成一场围绕主观满意度的拉扯。

（三）验收条款写得好，AI企业才有商业闭环

验收条款写得好，AI企业才有收款闭环。

交付可以证明。

缺陷可以分类。

整改可以结束。

客户不表态可以触发视为验收。

新增需求可以另行收费。

付款节点可以落地。

这才是AI项目合同真正的商业价值。

否则，项目交付了，客户在用，供应商还收不到款；系统上线了，客户仍说没验收；供应商持续优化，客户仍说不满意。这样的项目越多，AI企业现金流和交付团队都会被拖垮。

十三、客户满意很重要，但不能成为唯一验收标准

AI项目不是不能追求客户满意。

客户满意当然重要。

但客户满意不能成为唯一验收标准。

AI项目更需要把“满意”拆成可验证的东西。

功能是否完成。

数据是否导入。

知识库是否覆盖。

模型是否达到约定指标。

系统是否稳定运行。

接口是否联通。

日志是否留存。

培训是否完成。

缺陷是否影响主要功能。

客户是否按期反馈。

只有这样，客户的不满意才不会变成无限拒收权。

成熟的AI项目验收，不是把客户感受排除在外，而是把客户感受转化为可测试、可整改、可闭环的机制。

客户可以提出问题，但应说明问题属于重大缺陷、一般缺陷、优化建议还是新增需求。

供应商应当整改合同范围内的缺陷，但不应对无限扩展的期待负责。

AI项目的验收条款，最终要回答一个最现实的问题：项目做到什么程度，可以确认交付并付款；哪些问题应当继续优化，但不能阻却验收；哪些新需求应当另行报价。

这个问题写清楚，AI项目才不会被一句“不满意”拖住。