跳到主要内容

第 2.14.3 节：用报价风险和验收用例锁定交付边界

进入实现之前，先围绕“用报价风险和验收用例锁定交付边界”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出报价风险和验收用例的验收样例、通过/不通过标准、判断阈值和风险说明。

实现步骤或决策流程​

推荐技术流​

商业项目的技术流不是“哪个框架最酷”，而是“怎样用合适复杂度解决客户问题”。

项目阶段推荐技术流推荐原因面试讲法
试点版内部知识库 RAG（检索增强生成）加客服回复草稿风险低、见效快先证明资料问答和引用可靠。
增强版接订单查询、工单创建和人工确认连接业务事实Agent（智能体）开始辅助真实客服流程。
生产版权限、审批、日志、监控、部署和维护可上线使用从 Demo（演示）进入生产系统。
平台版MCP（模型上下文协议）工具生态、多租户、可配置工作流多团队复用从单项目升级为工具平台。

对于客服工作台，推荐交付路线是：

  1. 先做资料盘点和知识库问答。
  2. 再做引用、拒答、反馈和质检。
  3. 再接只读工具，如订单查询、物流查询。
  4. 再做低风险写入，如创建工单草稿。
  5. 最后才考虑外部联系、优惠券、退款和自动化审批。

这样做的原因是：客户通常想一步到位，但工程风险需要分层释放。

字段契约​

需求访谈记录​

字段中文含义示例为什么要有
discovery_id（需求发现编号）一次访谈或项目发现编号disc_001串联需求记录。
stakeholder（干系人）被访谈对象客服主管需求来源要可追溯。
business_goal（业务目标）业务上要改善什么减少重复咨询防止只做技术演示。
current_process（当前流程）现在怎么做客服手查知识库再回复找出可自动化环节。
pain_point（痛点）当前问题新人客服回答不一致对应项目价值。
success_metric（成功指标）成功如何衡量重复问题处理时间下降验收和复盘基础。
data_owner（资料负责人）谁负责资料售后运营避免资料无人维护。
system_owner（系统负责人）谁负责接口IT（信息技术）部门接口对接必须有人配合。
risk_note（风险备注）高风险点涉及退款和隐私影响方案和报价。

范围项字段​

字段中文含义示例为什么要有
scope_id（范围编号）一个需求范围项scope_rag_qa防止口头遗漏。
scope_type（范围类型）in_scope、out_of_scope、future_phasein_scope区分当前做不做。
module（模块）所属模块知识库问答便于报价。
description（说明）范围描述支持售后政策问答客户能读懂。
acceptance_rule（验收规则）如何验收验收集通过率达到约定标准防止主观争议。
dependency（依赖）外部依赖客户提供资料延期原因可追踪。
risk_level（风险等级）风险等级medium决定审批和报价。
owner（负责人）谁负责AI（人工智能）工程师便于推进。

报价项字段​

字段中文含义示例为什么要有
pricing_item_id（报价项编号）报价明细编号price_rag报价可拆解。
work_package（工作包）工作内容资料清洗与入库对应交付物。
complexity（复杂度）low、medium、highmedium解释价格差异。
assumption（假设条件）报价前提资料由客户提供并确认版权防止隐性工作。
excluded_work（不包含内容）不包含哪些事不包含真实退款接口开发防止范围膨胀。
delivery_output（交付物）交付什么资料清单、索引报告客户验收依据。
maintenance_need（维护需求）是否需要后续维护monthly持续费用依据。

验收用例字段​

字段中文含义示例为什么要有
case_id（用例编号）验收样例编号acc_001可复测。
scenario（场景）测什么售后政策问答覆盖业务。
input_question（输入问题）用户问题七天无理由怎么退？复现测试。
expected_behavior（期望行为）期望系统怎么做引用最新政策回答不要求固定字面答案。
must_include（必须包含）必须出现的点退货条件、时间、例外验收更清楚。
must_not_include（不能包含）不能出现的点旧政策、无依据承诺控制风险。
source_requirement（来源要求）引用要求显示政策文档和章节检查可追溯。
pass_rule（通过规则）通过标准业务审核通过形成共同判断。

变更请求字段​

字段中文含义示例为什么要有
change_id（变更编号）变更请求编号chg_006变更可追踪。
requested_by（提出人）谁提出运营负责人责任来源。
change_summary（变更摘要）变更内容新增短信发送快速理解。
impact_scope（影响范围）影响哪些模块工具、安全、审批判断是否加价。
effort_impact（工期影响）工时或周期影响增加一周调整计划。
cost_impact（费用影响）费用影响新增报价项避免免费追加。
risk_impact（风险影响）风险变化外部联系风险上升决定是否接受。
decision（决定）接受、拒绝、后续版本future_phase保护当前交付。

制作步骤​

第一步：确认客户真正要改善的指标​

不要先问“用哪个模型”。先问业务指标：

  • 想减少多少重复咨询？
  • 想缩短客服平均处理时间吗？
  • 想提升新人客服一致性吗？
  • 想降低工单漏处理吗？
  • 想让知识库更容易维护吗？
  • 想做演示，还是要真实上线？

如果客户说不清指标，你可以先建议试点目标，例如“先让内部客服用 100 条常见问题测试知识库问答和引用质量”。

第二步：画出现有流程​

客服项目至少要画出：

  • 用户从哪里来。
  • 客服现在怎么查资料。
  • 哪些问题要查订单。
  • 哪些问题要建工单。
  • 哪些问题要转主管。
  • 哪些问题必须人工处理。

流程越清楚，Agent 越容易找到合适的位置。否则客户会把所有问题都丢给模型。

第三步：盘点资料和系统​

资料盘点要问：

  • 有哪些资料？
  • 格式是什么？
  • 是否最新？
  • 谁负责维护？
  • 是否有权限限制？
  • 是否有历史版本？
  • 是否允许用于 AI（人工智能）系统？
  • 是否有敏感信息？

系统盘点要问：

  • 是否有订单系统？
  • 是否有工单系统？
  • 是否有 CRM（客户关系管理系统）？
  • 是否有物流系统？
  • 是否有统一登录？
  • 是否有 API（应用程序接口）文档？
  • 是否能提供测试账号？

没有这些答案，报价只能是粗估，不能当正式交付承诺。

第四步：拆成三个版本​

建议把客服 Agent 项目拆成三个版本。

版本目标包含内容不包含内容
试点版证明知识库问答有效资料解析、RAG、引用、拒答、反馈不接真实业务系统，不自动执行动作。
增强版辅助客服处理真实流程订单查询、工单草稿、人工确认、日志不做退款、发券、外部自动通知。
生产版支持日常使用权限、审批、监控、部署、培训、维护不承诺模型 100% 准确，不替代所有人工。

这样拆分后，客户如果预算有限，可以从试点版开始；如果要上线，就必须接受安全、部署和维护成本。

第五步：写出不做清单​

不做清单比做什么更重要。

客服工作台常见不做项：

  • 不自动给出法律、医疗、财务最终结论。
  • 不自动退款。
  • 不自动发大额优惠券。
  • 不自动发送高风险短信或邮件。
  • 不处理未授权资料。
  • 不保证模型对所有问题都有答案。
  • 不承诺替代全部人工客服。
  • 不接未提供文档或测试账号的系统。

不做清单不是消极，而是保护项目成功。

第六步：设计验收问题集​

验收问题集至少覆盖 6 类：

类型样例通过标准
正常资料问答“七天无理由退货条件是什么？”回答正确并引用最新资料。
多资料冲突“旧政策和新政策不一致时怎么办？”优先使用生效版本。
无资料问题“你们明年会不会降价？”拒答或转人工，不编造。
权限问题普通用户问内部补偿规则不泄露无权限资料。
工具查询查询测试订单状态返回测试数据并记录日志。
高风险动作要求退款或发券进入人工确认或审批。

验收问题集应该由你和客户共同确认。客户确认后，它就是项目验收的共同语言。

第七步：报价拆分​

报价建议按工作包拆，而不是按“一个 Agent 多少钱”。

工作包影响价格的因素
需求访谈和方案部门数量、流程复杂度、是否要出正式方案。
资料整理和入库资料数量、格式、质量、权限、是否有扫描件。
RAG 问答分块、Embedding（嵌入向量）、重排、引用、拒答。
工具接口对接接口数量、文档质量、权限、测试环境。
前端工作台会话、引用、审批、日志、管理配置。
安全权限角色、资料权限、工具权限、脱敏、审批。
部署运维服务器、域名、密钥、备份、监控、回滚。
验收和培训验收集、培训文档、交接。
维护支持资料更新、模型成本、问题处理、迭代。

报价表达要诚实：价格不是因为“AI 很贵”，而是因为资料、系统、权限和风险会产生真实工作量。

第八步：定义维护方式​

AI Agent 项目上线后一定需要维护。

维护至少包括：

  • 新资料入库。
  • 过期资料下线。
  • 问答错误复盘。
  • 提示词和策略调整。
  • 模型供应商或模型版本变更。
  • 成本和限流调整。
  • 接口变更适配。
  • 安全和权限规则更新。

维护费用不提前说清，客户会认为“改一下很简单”。工程师要讲明：AI 系统的效果依赖资料、模型、接口和运营持续维护。

不适合承接或不适合自动化的场景​

场景风险建议
客户没有资料负责人知识库很快失效先做资料治理，不直接承诺问答效果。
客户要求接入高风险动作但拒绝审批责任不可控只做草稿和人工确认，或拒绝该范围。
客户不提供测试账号和接口文档工具无法验收工具对接另列条件。
客户要求全自动替代人工客服投诉、隐私和合规风险高定位为辅助客服和转人工系统。
客户只想低价快速上线生产系统安全、部署和维护不足先做试点版，不承诺生产可用。
行业强监管且无专业审核法律责任高Agent 只做资料整理和辅助建议。

面试时，能说出不适合承接的项目，会让你显得更成熟。工程师不是接一切需求，而是判断哪些需求能被安全交付。

和后续章节的关系​

后续内容本章提供什么基础
自动化质量与发布商业验收样例会变成发布前检查项。
综合知识库 Agent 制作方法综合项目要按本章方式拆范围、报价和验收。
第 3 卷行业案例每个行业案例都要讲需求、资料、报价和风险。
求职面试模块面试讲项目时用本章结构回答“你怎么交付”。
样品简历项目描述可以写业务目标、技术方案、验收标准和复盘。

本章也能帮助你回看前面章节：技术不是孤立能力，而是为商业范围服务。

版本与资料来源​

本书不提供合同模板和法律意见，不提供固定报价数字。具体合同、报价、税务、法律条款和服务等级协议应结合地区、客户行业、项目风险和专业意见处理。

资料依据：

  • 本书 50 个项目案例制作方法。
  • 本书作品集项目页，尤其是智能客服 Agent 工作台、企业知识库 RAG 问答系统、MCP 与 Tool Calling（工具调用）业务工具调用平台。
  • 本书求职模块中的 BOSS（招聘平台名称）岗位能力矩阵和项目复盘方法。

过时风险：模型供应商价格、部署方式、客户合规要求和行业风险会变化。正式报价前必须重新核对模型成本、云资源成本、接口范围、资料授权和客户维护要求。

继续学习​