跳到主要内容

第 2.14.1 节：先把客户需求访谈问到可报价范围

方案是否能交付，不能只凭感觉，需要结合“先把客户需求访谈问到可报价范围”的验收样例和实际证据。完成本节后，你应该能够写出需求访谈的验收样例、通过/不通过标准、判断阈值和风险说明。

本章要解决什么问题​

前面的章节讲了 RAG（检索增强生成）、文档解析、向量数据库、MCP（模型上下文协议）、Tool Calling（工具调用）、LangGraph（智能体状态图框架）、多智能体、部署、可观测性、安全和审批。技术链路已经有了，但商业项目还有另一个难点：客户不会按章节给你需求。

客户通常只会说一句话：

我们想做一个 AI（人工智能）客服。

这句话可能代表很多完全不同的项目：

  • 只是做 FAQ（常见问题）问答页面。
  • 做企业知识库 RAG 系统。
  • 接订单、物流、工单、CRM（客户关系管理系统）和售后系统。
  • 做客服回复草稿，不自动发送。
  • 做全自动外呼、短信或邮件回复。
  • 做内部客服质检和知识库更新。
  • 做一个给老板看的 Demo（演示）。
  • 做一个能上线给真实客户使用的生产系统。

如果你听完这句话就开始做，项目很容易失控。不是因为你技术不行，而是因为范围、资料、权限、风险、验收、维护和成本都没有说清。

本章要解决的问题是：把客户模糊愿望拆成可报价、可交付、可验收、可复盘的 AI Agent（人工智能体）项目。

这章也直接服务求职面试。很多智能体工程师岗位不会只问你“怎么调 API（应用程序接口）”，还会问：

  • 客户资料不完整怎么办？
  • 你怎么确认需求边界？
  • RAG 项目怎么验收？
  • 工具调用项目怎么避免责任不清？
  • 商业项目怎么报价？
  • 客户要求 100% 准确时怎么回答？
  • 你怎么把一个作品集项目讲成可交付项目？

如果你能回答这些问题，你就不只是“会写 Agent”，而是像能参与交付的工程师。

学习目标​

读完本章后，你应该能够：

  • 把“做个 AI 客服”拆成业务目标、资料范围、系统动作、权限风险和验收指标。
  • 设计一套 AI Agent 项目需求访谈问题。
  • 判断客户资料是否达到 RAG 项目入场条件。
  • 把项目范围拆成基础版、增强版和生产版。
  • 解释报价为什么要包含资料治理、接口对接、部署、监控、验收和维护。
  • 写出验收问题集、验收场景表和拒答规则。
  • 设计变更控制，避免客户不断追加功能。
  • 面试时用商业交付语言讲作品集项目。

贯穿业务场景​

本章继续使用“企业客服知识库与工单 Agent 工作台”。

客户是一家中型企业，有售前、售后、客服、运营和产品部门。现在他们希望用 AI 系统降低客服压力。

他们一开始提出的需求很简单：

我们有很多产品资料和售后政策，客服每天重复回答问题。你帮我们做一个 AI 客服，最好能自动回答用户，还能查订单、创建工单。

听起来像一个项目，但里面至少包含 8 个子问题：

子问题为什么必须问清
给谁用面向内部客服、外部客户、售前销售还是管理层，系统边界完全不同。
回答什么公开 FAQ（常见问题）、内部政策、订单状态、投诉处理、退款规则的风险不同。
资料在哪里PDF（便携式文档格式）、Word（文字文档）、网页、Excel（电子表格）、历史工单的处理成本不同。
资料谁维护没有负责人，知识库很快过期。
是否接业务系统只做问答和接订单系统的报价差很多。
是否自动执行动作自动回复、自动建单、自动退款的风险完全不同。
如何验收没有样例集，客户永远可以说“不够聪明”。
谁承担运行成本模型调用的 Token（文本计量单位）、向量数据库和服务器都会持续产生费用。

商业访谈不是销售话术，而是工程输入。访谈质量直接决定系统架构、报价、工期和风险。

新手为什么会卡住​

很多学习者做作品集还可以，一碰商业项目就会卡住。

卡点表现根因正确处理
听到客户需求就急着开工做到一半发现资料、接口、权限都没有没有需求澄清先做 Discovery（需求发现）和范围确认。
报价只报开发时间资料治理、部署、验收、维护都没算把 AI 项目当普通页面按模块、风险和交付物报价。
不敢拒绝客户客户说什么都答应不知道项目边界写清做什么、不做什么、什么算变更。
承诺效果太满说“准确率 99%”或“什么都能答”不理解模型不确定性用验收样例集、引用依据和拒答规则定义效果。
不知道怎么验收项目完成后客户主观评价没有测试集交付前共同确认验收问题和通过标准。
不知道怎么面试表达只说“我做了一个客服 Agent”缺少商业闭环用目标、范围、方案、风险、验收、复盘讲项目。

面试官最担心的不是你不会某个框架，而是你把企业项目做成不可控实验。商业交付能力，就是把不确定性拆成可管理的边界。

继续学习​