AI 产品礼宾式试点：先人工交付结果，再决定自动化什么

很多 AI 产品在验证需求之前就投入数周搭建工作流、向量库和多 Agent 编排，最后才发现客户真正需要的是另一种输入、不同的审批顺序，或一个完全不能自动化的责任判断。礼宾式试点把顺序反过来：客户看到清楚的服务边界，你在后台用模型、脚本和人工完成交付，以真实任务学习稳定流程。

这里的“礼宾”不等于冒充全自动系统。必须在试点协议中说明哪些步骤由人处理、数据会进入哪些工具、输出由谁复核。验证的对象是结果是否有价值和流程是否可重复，而不是用隐瞒换取漂亮的转化率。

把试点写成一份可验收合同

开始前用一页纸冻结六项内容：目标客户画像、允许输入、交付物、完成时限、验收条件、价格与退出方式。例如“为 5 至 20 人的招聘团队处理 10 份已脱敏面试记录，在 24 小时内交付带原文定位的候选人能力矩阵；客户逐项确认引用准确性；四周试点价 1,200 元”。

同时列出排除项，例如不替客户做录用决定、不接收身份证号、不处理未经授权的录音、不承诺模型永不出错。对于高影响决策，人工复核是产品边界而非临时缺陷。风险识别应在首位，不能等到自动化后再补。

试点承诺应来自前序访谈的具体证据，而不是临时猜测。如何识别真实预算与承诺，可参考AI 产品用户访谈与付费意愿验证。如果连输入和验收结果都说不清，就继续做低保真原型，不要收集生产数据。

每个任务分配匿名 caseId，逐步记录：收到输入的时间、输入缺陷、模型和提示词版本、人工操作分钟数、重试次数、输出复核项、交付时间、客户修改和最终是否验收。人工可以灵活处理，但记录格式必须固定，否则试点结束后只会留下“过程很忙”的感觉。

一个最小账本可以包含如下阶段：

不要只记录模型 token。礼宾试点的主要成本往往是解释需求、清洗输入和追踪审批。若这些步骤不进入账本，自动化后的毛利预测会被系统性高估。复杂流程可以借鉴从需求到上线构建 AI 写作助手中对输入、生成和发布环节的拆分，但仍需以本试点的实测数据为准。

假设四周内招募 6 家合格客户，每家交付 8 个案例，共 48 个。最终 5 家完成，4 家付款，1 家因内部审批退出。48 个案例中 42 个首次通过验收，6 个返工；人工总耗时 720 分钟，模型与存储成本 360 元。则：

这些数值不能因为客户数量少就宣称已经 PMF，但足以暴露流程瓶颈。还要查看分布：若 6 个返工都来自扫描件，优先限制输入或改善 OCR；若错误分散且涉及专业判断，就不能简单用更多编排掩盖问题。

优先自动化高频、规则稳定、错误可发现且能节省明显人工时间的步骤。例如输入字段检查连续 30 次由人工执行同样规则，可以先写确定性校验；而最终风险判断每次都需要结合上下文，就继续保留人工审批。可以用AI 功能灰度与 Feature Flag让自动化步骤只覆盖部分案例，并保留人工路径作为对照。

每替换一个人工步骤，都运行至少一轮并行对照：同一批脱敏样本由旧人工流程和新自动流程分别处理，比较首次验收率、严重错误、处理时间和成本。若自动流程仅仅更快，却让关键引用错误增加，就不应发布。对具体功能是否值得继续投入，可接入AI 功能证据评分卡，避免按开发趣味排序。

礼宾服务不能无限延长。开始时预设四种结局：

结束评审要检查原始账本，而不是只听执行者总结。随机抽取 5 个案例，从授权、输入、模型调用、人工修改到客户验收逐步回放；重新计算人工时间和退款；向退出客户确认原因。做到这些，礼宾式试点才是低成本的生产验证，而不是把尚未定义的产品变成创始人的无限手工作坊。