版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
1. 售前转大模型，最先撞上的墙不是技术
1.1 你最值钱的能力，在 AI 项目里换了个用法
你原来做技术销售、售前或解决方案，手上最强的一张牌，是「把客户模糊的诉求翻译成方案」。客户说一句「我们想要个智能客服」，你能很快拆出场景、角色、对接系统和报价口径。这套能力转到 AI 大模型方向，依旧值钱——只是用法要从「翻译诉求」往前多走一步。
1.2 翻车的根源：把「效果」直接写成了功能
最容易翻车的地方是：你习惯把「客户想要的效果」直接写成功能清单。到了验收那天，客户说「这跟我想的不一样」，你说「功能都做了啊」。两边对「算不算做完」各说各话，项目卡在中间。
问题不在你不会写方案，而在 AI 项目的「做完」比传统软件更难定义。模型输出有随机性，同一句话问三遍可能三个样；客户心里的「好」往往是感受，不是指标。举个很有代表性的例子：客户要「智能写周报」，你列了功能——能读取项目系统、能生成结构化周报、能推送给主管。PoC 做完，客户说「这写的不是我想要的重点，感觉差点意思」。你说「功能都齐了啊」。问题就出在：你验的是功能在不在，客户验的是「写得好不好」，而「好」从来没被定义成可勾选的条件。
1.3 先认清两个词：PoC 与验收判据
PoC，英文 Proof of Concept，是「正式投钱做之前，先用一个小规模版本验证这条路走不走得通」。验收判据，就是双方提前约定好的「满足哪些条件，就算这一关过了」。本篇的落点是：PoC 阶段最该先写清楚的，不是功能，而是边界与验收判据——什么在范围内、什么明确不做、什么条件下算通过、失败时怎么算。
2. 功能清单 vs 边界说明：差别在哪
2.1 功能清单回答「做什么」，边界说明回答「做到什么程度算完」
传统项目里，功能清单配合测试用例，基本能验。AI 项目里，光列功能会漏掉三件事：模型的输出质量怎么算达标、哪些情况不算我们的事、跑偏了什么时候喊停。这三件事，恰恰决定验收时吵不吵架。
据 PMBOK（PMI 的项目管理知识体系）的做法，范围说明里本来就要求同时写「验收标准」和「排除项」两项——前者告诉双方什么叫做完，后者提前划清什么叫不归我们管。下面这张对照表把两类写法摆在一起。
| 对比维度 | 只写功能清单 | 同时写边界与验收说明 |
|---|---|---|
| 验收依据 | 「功能都实现了」 | 「功能实现 + 判据达标 + 排除项未越界」 |
| 质量定义 | 主观感受，「客户满意」 | 可勾选或可量化的条件 |
| 扯皮点 | 集中在「这算不算我们要的」 | 集中在「这条当初就写明不归我们」 |
| 适合场景 | 逻辑确定、输入输出固定的系统 | 模型输出有波动、效果靠判据的 AI 项目 |
2.2 一句话记住
功能清单解决「做没做」，边界说明解决「做没做对、做没做全、做没做偏」。售前转大模型，先把第二类写扎实，比多列十个功能更有用。
3. 可直接套用的「AI PoC 范围与验收说明」结构
3.1 六个字段，先把骨架立住
下面这六个字段，是我建议你在任何 AI PoC 启动会上当场和客户对齐、并写进文档的。前两个交代背景，中间两个定标准，最后两个管住边界和兜底。
填的时候有个小窍门：目标场景只写一个主场景，别把三个部门的需求揉到一起；成功判据每一条都要能回答「怎么证明这条过了」，答不上来的就还不够格写进判据。很多售前第一次写会觉得「排除项没什么可写」，真到验收时才发现，恰恰是那些没写的东西最容易变成争议。
| 字段 | 它要回答的问题 | 写的时候注意 |
|---|---|---|
| 目标场景 | 给谁用、解决什么具体事 | 只写一个主场景，别贪全 |
| 输入数据 | 模型吃进来的东西长什么样 | 写明格式、来源、是否含敏感信息 |
| 成功判据 | 满足什么条件算这一关过了 | 要可勾选或可量化，见第 4 章 |
| 排除项 | 明确哪些事这次不做 | 见第 5 章，比功能更该先写 |
| 停止条件 | 跑偏到什么程度立刻停 | 触发即停，不纠结 |
| 人工兜底点 | 哪些环节必须有人拍板 | 见第 6 章，定责任人 |
3.2 一份空白模板
把上面六个字段直接落成结构化文档，复制就能用。
poc_name:项目代号 / 一句话目标目标场景:使用者:谁在用要解决的问题:一句话不在本 PoC 验证的:写「见排除项」输入数据:格式:文本 / 表格 / 接口来源:客户提供 / 公开脱敏敏感信息:有 / 无，如何处理成功判据:-指标:关键字段抽取准确率门槛:F1分数>= 0.85（在留出样例上）-指标:合规标注门槛:涉及金额必须出现「以官方文件为准」排除项:-多轮复杂推理不在范围内-截图 / 拍照识别后续再说停止条件:-连续 20 条样例触发合规红线即终止人工兜底点:-对外发布前由人复核-边界拿不准时由人拍板3.3 把判据拆成可跑的用例
模板定下后，每条成功判据最好再落成一条结构化用例：给输入、给期望、给通过规则。这样验收时不是「凭感觉看」，而是「按规则勾」。下面是一条样例（纯数据，不需运行）。
{"scenario":"refund_qa","input":"我的退款多久到账？","expected":"回答中必须出现「以官方规则为准」字样","pass_rule":"expected_phrase in output"}4. 成功判据怎么写：从「客户满意」到可衡量
4.1 好判据与坏判据
Anthropic 的官方评测文档里讲得很直接：好的成功判据要Specific（具体）、Measurable（可衡量）、Achievable（可达）、Relevant（相关）；它举的坏例子是「模型应该分类得好」，好例子是「在留出测试集上，情感分析模型 F1分数 不低于 0.85」。一句话——把感受换成条件。
| 维度 | 模糊写法（坏） | 可衡量写法（好） |
|---|---|---|
| 准确率 | 模型回答得准 | 在 200 条留出样例上，关键字段抽取 F1分数 ≥ 0.85 |
| 合规 | 不要胡说 | 涉及金额 / 法律的回答必须标注「以官方文件为准」，缺标即判不通过 |
| 一致性 | 客户觉得稳 | 同一问题连续问 3 次，核心结论语义一致 |
4.2 把判据交给代码，而不是交给「感觉」
判据一旦写成条件，就能用一小段代码当门禁。下面这段没在本地跑过，思路是先按「可自动检查」来设计，能自动判的就别让人肉眼看。
⚠️代码待验证
defcheck_poc_pass(output:str,required_fields:list[str],min_len:int)->dict:missing=[fforfinrequired_fieldsiffnotinoutput]return{"pass":len(missing)==0andlen(output)>=min_len,"missing_fields":missing,}case=check_poc_pass("答案见《操作手册》第三章：先核对账户再处理",["答案见"],20)print(case)4.3 合规提醒：别替模型承诺效果
这里要泼盆冷水。做售前容易顺手写「准确率可达某值」「效果有保障」，但在 AI 项目里这不只不专业，还可能踩线。
- 《中华人民共和国反不正当竞争法》（2025 年第二次修订，2025-10-15 施行）第九条：经营者不得对其商品的性能、功能、质量、销售状况、用户评价、曾获荣誉、资质许可等作虚假或者引人误解的商业宣传，欺骗、误导消费者。（提醒一句：这一条在旧版里是第八条，2025 年修订后条号顺延为第九条，第八条现在是商业贿赂。写方案引法条时留意版本。）
- 《中华人民共和国广告法》第二十八条：广告以虚假或者引人误解的内容欺骗、误导消费者的，构成虚假广告。
- 《生成式人工智能服务管理暂行办法》（国家网信办等令第 15 号，2023-08-15 施行）第四条（五）：提供生成式人工智能服务应「提高生成内容的准确性和可靠性」。
结论很明确：判据是你和客户事先约定的验证条件，不是你对外的效果承诺。把「保证做到」换成「满足以下条件即视为通过」，既是职业分寸，也是合规底线。
5. 排除项与停止条件：明确「不做什么」
5.1 为什么排除项比功能更该先写
客户提需求时，习惯做加法：「最好也能识别截图」「顺便接一下实时数据」。你不写排除项，这些就会在验收时变成「你当初没说不做」。排除项的价值，是提前把「不归本次 PoC 管」写进白纸黑字，避免范围蔓延（scope creep，指项目边界被悄悄撑大）。
很多售前本能地想把功能写满，觉得「给得多显得专业」。但在 AI PoC 里，写清不做什么，反而让客户觉得你懂行——因为你清楚模型的边界在哪里，而不是什么大话都敢接。把「这次不做」摆上桌，客户反而更信任你后面说的「这次能做」。
PMBOK 的范围说明里，「排除项（exclusions）」本就是和标准字段并列的一项，作用正是「防止范围蔓延、统一预期」。
5.2 排除项示例
| 排除项 | 说明 |
|---|---|
| 多轮复杂推理 | 本次 PoC 只测单轮问答，多轮对话留到下一阶段 |
| 非结构化图片输入 | 仅接受文本工单，截图 / 拍照识别不在范围内 |
| 实时数据 | 用截至固定日期的快照，不接实时接口 |
5.3 停止条件：触发即停，不纠结
停止条件回答「跑偏到什么程度，我们认输并重来」。它保护的是你的时间和客户的下次信任。常见写法：
- 连续若干条样例触发合规红线（如模型编造政策条文），立即终止本 PoC；
- 核心判据在限定样例上达标情况持续低于约定门槛，转为需求重谈，而非硬撑上线；
- 输入数据无法稳定提供，暂停而非带病推进。
PoC 范围与验收模板（可套用版）：把第 3、5 章的六个字段整理成一份可直接复制的空白模板，并附两个填好的样例。放在资料包里，扫码即可获取：
6. 人工兜底点：什么时候必须有人
6.1 哪些环节模型不能自己拍板
大模型擅长「生成」，不擅长「担责」。凡涉及对外责任、边界判定、失败处置，都得留一个真人节点。这不仅是稳妥，也是前面那部《暂行办法》里「准确性、可靠性」要求的落地方式。
人工兜底点不是给模型找借口，而是把「谁负责」写进流程。没有指定责任人的兜底点，等于没兜底——真出事时，又会回到「各说各话」。
6.2 人工兜底点示例
| 环节 | 为什么必须有人 |
|---|---|
| 最终答复对外发布 | 涉及客户名称、金额、条款，模型输出需人复核 |
| 边界判定 | 拿不准是否在区间内时，由人拍板而非模型自判 |
| 失败处理 | 触发停止条件后，由人决定是否终止或重谈 |
7. 一份模板 + 上线前自检清单
7.1 把六字段串成一份样例
以「工单自动初筛」为例：目标场景是客服同事把用户文本工单贴进来，PoC 只做「该转哪个部门」的单轮判断；输入数据是脱敏后的文本工单；成功判据是部门归类在 200 条留出样例上 F1分数 ≥ 0.85，且输出必须附「建议转交」字样；排除项是多轮对话与截图；停止条件是连续出现编造部门编号即终止；人工兜底点是对外工单由人复核后发出。
7.2 上线前自检清单
| 检查项 | 是否满足 |
|---|---|
| 目标场景写清了「给谁用、解决什么」 | □ |
| 成功判据有数字或可勾选条件 | □ |
| 排除项列了至少 3 条 | □ |
| 停止条件写明了触发即停 | □ |
| 人工兜底点指定了责任人 | □ |
7.3 给售前的转型一句话
你原来最会「翻译诉求」，现在把这套本事往前挪一步：在 PoC 启动会上，先帮客户把边界和验收判据写清楚，再谈功能。这步做扎实，后面验收不吵、上线不慌，也正是你从「卖方案」走向「交付可信 AI」的第一道分水岭。
售前转大模型自查清单（含样例）：第 7 章的自检清单，外加一份真实项目的边界说明样例，方便你照着改。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 事实 | 出处（标题 + 域名 / 文号） | 本文位置 |
|---|---|---|
| 好的成功判据应 Specific、Measurable、Achievable、Relevant；坏例「模型应该分类得好」，好例「留出测试集上 F1分数 不低于 0.85」 | Define success criteria and build evaluations（docs.anthropic.com） | 第 4 章 |
| 评测要先定义「什么算通过、什么算不通过」，并把构造讲清楚 | What we look for in a wellbeing evaluation（anthropic.com 官方 PDF） | 第 4 章 |
| 经营者不得对其商品的性能、功能、质量、销售状况、用户评价、曾获荣誉、资质许可等作虚假或者引人误解的商业宣传，欺骗、误导消费者 | 中华人民共和国反不正当竞争法 第九条（2025 年第二次修订，2025-10-15 施行，主席令第五十号；neris.csrc.gov.cn 法规库载全文，效力状态「现行有效」） | 第 4 章 |
| 广告以虚假或者引人误解的内容欺骗、误导消费者的，构成虚假广告 | 中华人民共和国广告法 第二十八条（wb.flk.npc.gov.cn 法规库 PDF 原文） | 第 4 章 |
| 提供生成式人工智能服务应提高生成内容的准确性和可靠性 | 生成式人工智能服务管理暂行办法 第四条（五），国家网信办等令第 15 号（www.gov.cn） | 第 4 章 |
| 范围说明应包含验收标准、排除项，排除项用于防止范围蔓延 | PMBOK Guide（PMI）范围说明字段；范围基线指南 projectmanagement.com.br 引 PMBOK 8（2025） | 第 2、3、5 章 |
附表 B：术语速查表
| 术语 | 一句人话解释 |
|---|---|
| PoC | 正式投钱做大项目前，先用小版本验证这条路走不走得通 |
| 范围说明（Scope Statement） | 写清项目交付什么、不交付什么、按什么条件算验收的文档 |
| 验收判据（Acceptance Criteria） | 双方提前约好的「满足哪些条件就算这一关过了」 |
| 排除项（Exclusions） | 明确写进文档的「这次 PoC 不做的事」，用来防范围蔓延 |
| 停止条件 | 跑偏到什么程度就立刻终止 PoC，不硬撑 |
| 人工兜底点 | 模型不能自己担责的环节，必须留真人复核或拍板 |
| 范围蔓延（Scope Creep） | 项目边界被悄悄撑大，做完才发现多了没人认的活 |
写在最后：这篇用到的资料
写这篇文章时，我把过去做售前最容易被客户牵着走的那股劲儿，转成了「先把边界和验收判据写清楚再谈功能」的习惯，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。
