摘要：验收不仅看正常询盘是否进入队列，还要测试重复提交、缺字段、未知服务、模型超时和凭证失效。报价按输入渠道、路由数量、系统集成与维护责任拆分，不以“AI节点数量”计价值。
适用对象：网站建设公司、设备供应商和专业服务机构。本文提供交付设计与模拟演练，不代表已经验证的客户收入案例。
先看结论与交付范围
验收测试集、路由混淆记录、漏单对账、故障恢复SOP、维护套餐和服务交接单。
本项目最小范围：一个询盘表单、三类服务分流、一个内部审核队列；不自动发送报价、不收集与需求无关的个人信息。试点工具预算：100～800元（试点预算假设，不含人工）。预算是规划假设，模型价格和客户账号费用在实施时另行核实。
完整实施步骤
1. 先定义每个状态
收到表单、校验通过、需要补件、待分流、已分配、待人工处理和已关闭是不同状态。为每次转换记录时间与责任人，不用一个“成功”字段覆盖整个流程。漏单的定义是来源存在记录但队列无对应request_id，不能只看工作流显示绿色就认为没有丢失。
2. 构造正反两类测试
正常样本覆盖三种服务；异常样本覆盖空描述、超长文本、非法地址、重复ID、提示词注入和服务冲突。每条测试写预期路由与是否允许继续。如果客户只提供理想数据，服务方需要明确提出异常清单，不能以“客户没给”作为忽视故障的理由。
3. 手工标注作为对照
让销售负责人先对测试询盘独立分组，再比较模型结果。分歧分成规则不清、输入缺失和模型错误三种，而不是全算模型失误。规则不清应修订定义；输入缺失应转补件；模型错误才考虑改提示词或换模型。样本少时不要宣称分类准确率达到可泛化标准。
4. 对账检查真正漏单
逐条比较表单日志和处理队列中的request_id，统计收到数、拒绝数、待处理数和完成数。故意让模型调用失败一次，确认原始记录仍保存，恢复后可以只重试失败步骤。重试不能创建第二个销售任务，也不能把一次表单提交变成多次邮件。
5. 定义人工接管边界
出现连续失败、认证异常、批量错误路由时暂停自动分流，保留表单接收并通知负责人使用人工队列。告警只带记录ID和错误类别，不附完整个人信息。恢复前回放异常样本，确认新版本没有破坏原规则；写明谁有权重新启用。
6. 报价分为建设和维护
建设按表单数、字段数、路由数、目标系统和验收样本量算；维护按月度运行量、故障响应窗口、规则变更次数和培训计。客户增加新的业务部门属于规则扩展，新增CRM属于系统集成，不能含糊地都塞进“维护”。第三方平台停机不等于服务商可保证即时修复。
7. 移交运行手册
客户需要知道工作流在哪里、如何暂停、凭证由谁管理、哪里看错误、怎样人工补单和如何导出数据。移交时撤销临时权限，留一个脱敏演示样本供以后回归。验收文件注明当前环境版本与尚未支持的场景，避免演示成功被理解为所有业务都已自动化。
填写示例与输入输出对照
示例测试投递10条记录，包含2次同ID重放和1条字段错误。验收不能要求10条全部变成任务，而应要求有效唯一记录正确入队、重复被拦截、错误进入补件队列，且总数能对账。
| 原始情况 | 处理动作 | 可检查输出 |
|---|---|---|
| 模型返回未知路由 | 转manual并保存错误类别 | 不创建不存在部门 |
| 任务API返回超时 | 查目标系统记录再决定重试 | 不把未知结果当未执行 |
| 工作流重启后重放事件 | 依据持久唯一键核对 | 不以进程内缓存代替生产去重 |
可复制的提示词
将客户授权资料放在独立的输入区域，并与规则分隔；先使用脱敏或虚构样本。提示词不能替代程序校验与业务审核，不要把密钥和不必要的个人信息放进对话。
根据测试记录生成验收草稿，分别统计received、invalid、duplicate、routed、manual、failed。只使用给定计数；若各状态无法对账，输出reconciliation_failed，不得用文字解释为正常。列出失败用例ID和下一步，不自动标记通过。
字段与证据记录
| 字段 | 用途 | 模拟填写 |
|---|---|---|
| request_id | 本次提交唯一编号 | INQ-001 |
| service | 用户选择服务 | 网站改版 |
| requirements | 原始需求 | 需要10页双语网站 |
| budget | 明确预算或空值 | null |
| missing_fields | 仍需补充的信息 | 上线时间、现有网站 |
| route | 队列而非价值判断 | 网站项目组 |
| approval | 人工审核状态 | pending |
这张表是本项目共同的记录字典，不代表所有字段都可直接写入客户系统。实际接入前需确认字段类型、允许值、负责人和版本；未知值保留为空，原始资料与整理结果分开保存。人工审批的操作者与时间应由可信系统记录，而不是由模型填成“已批准”。
验收演练与失败处理
| 用例 | 输入情况 | 预期处理 | 验收证据 |
|---|---|---|---|
| V1 | 模型返回未知路由 | 转manual并保存错误类别 | 不创建不存在部门 |
| V2 | 任务API返回超时 | 查目标系统记录再决定重试 | 不把未知结果当未执行 |
| V3 | 工作流重启后重放事件 | 依据持久唯一键核对 | 不以进程内缓存代替生产去重 |
先人工写出预期输出，再运行模板或流程；对实际结果分别标注通过、失败和待确认。验收阈值是双方事先约定的规则，不是工具默认给出的评分。模拟测试通过仅说明这些样本符合条件，不能保证未覆盖的输入同样正确。发现关键错误时暂停受影响步骤，保留原始记录，以人工方式继续处理必要业务。
报价与商业边界
示例建设工时为需求4小时、配置8小时、测试5小时、培训3小时，共20小时。按目标时薪另加平台预算和风险准备报价；维护按实际变更与响应工作量单独列出，不引用为市场平均成交价。
正式报价列明输入数量、交付格式、批准人、修改轮次和反馈期限。客户改变已经确认的业务范围属于变更，服务方未忠实落实已确认要求属于修错，两者要分别记录。AI订阅费低不等于项目人工成本低，尤其不要漏算核验、培训和售后时间。任何参考价都不是已成交证明。
七天试单计划
| 时间 | 当天重点 | 完成条件 |
|---|---|---|
| 第1天 | 先定义每个状态 | 保存与“先定义每个状态”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第2天 | 构造正反两类测试 | 保存与“构造正反两类测试”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第3天 | 手工标注作为对照 | 保存与“手工标注作为对照”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第4天 | 对账检查真正漏单 | 保存与“对账检查真正漏单”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第5天 | 定义人工接管边界 | 保存与“定义人工接管边界”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第6天 | 报价分为建设和维护 | 保存与“报价分为建设和维护”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
| 第7天 | 移交运行手册 | 保存与“移交运行手册”对应的输入、处理说明和客户确认；若依据不够，记录待办而不是假装完成。 |
风险与不适用情形
- 表单内容可能包含提示词注入，不能当系统指令
- 询盘分流不代表自动接受订单或确认合同
- 重复提交需要持久化去重，内存数组不足以覆盖重启
所有案例与数字均已标为演示或估算，不构成收入保证、招聘决定、法律意见或效果承诺。涉及专业或高风险事项时先由客户指定负责人确认，超出能力或权限的部分不要自动执行。
常见问题 FAQ
路由准确率多少才能上线？
由风险和样本决定，先要求所有关键阻断场景正确，再约定低风险分类阈值。
表单正常但任务没建怎么办？
按唯一ID从接收日志追到失败节点，补处理后再次对账。
必须提供全天候维护吗？
不必须；在合同中明确服务时间、响应方式和紧急人工处理办法。
官方参考与适用范围
参考资料用于核对基础方法或工具能力；本文的报价、演练、检查标准与项目方案为编辑设计，不是官方推荐套餐。查阅日期：2026-09-03。
继续实践
配套AI网站询盘分流与报价准备完整资料包提供离线手册、可编辑模板与本地校验示例。更多方向见AI副业实战频道。
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
