跳到主要内容

第 3.1.1 节：把客户原话翻译成可报价的项目范围

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

章节定位​

客户不会按技术文档的方式提出需求。他们更常说“能不能让它自动回复客户”“能不能自动整理销售线索”“能不能每天帮我看报表”。这些表达背后可能是一个简单的问答助手，也可能是跨系统、跨部门、带审批责任的业务流程。如果一开始就讨论模型、插件或界面，项目很容易变成“看起来很智能，但无法验收”的演示。

本章是一套项目拆解方法论。它帮助你把客户的一句话，拆成业务问题、资料边界、智能体能力、工具权限、验收样例、报价工期和作品集表达。读完这一章，你应该能在面对任何行业案例时，用同一套顺序完成售前判断和交付方案，而不是每次从零开始。

本章不展开代码语法，也不把技术名词当成方案本身。重点是学会判断：什么该交给 AI Agent（人工智能体），什么必须保留人工确认，什么资料不足会导致项目失败，什么验收标准能让客户和交付方站在同一张桌子上。

行业业务问题​

多数 AI Agent 项目失败，不是因为模型不会回答，而是因为需求没有被翻译成可交付的业务系统。客户说“自动化”，实际可能想要减少人工重复；客户说“更智能”，实际可能想要降低漏单、漏跟进或误判风险；客户说“接入系统”，实际可能只需要先导入一批表格做半自动处理。

常见问题有四类：

  • 目标混乱：客户把降本、提效、提转化、降风险混在一起，但没有明确优先级。
  • 资料混乱：客户有聊天记录、表格、制度和经验话术，但没有区分哪些可信、哪些过期、哪些不能外发。
  • 权限混乱：系统可以查询、生成、提醒、创建工单、发送消息，但每个动作的责任边界没有写清楚。
  • 验收混乱：客户说“准确率高一点”，却没有给出样例、阈值、失败处理和上线后的维护人。

方法论的价值，是把这些模糊问题变成可讨论的交付对象。你不是向客户承诺“AI（人工智能）什么都能做”，而是帮助客户看清：先做哪一段流程，先接哪些资料，哪些动作自动化，哪些动作只做建议，出现失败时谁接管。

适合/不适合场景​

判断项适合做 AI Agent 项目不适合直接做 AI Agent 项目
需求状态客户有明确业务痛点，愿意提供样例并参与验收客户只想“试试看”，没有负责人和验收样例
资料状态已有制度、FAQ（常见问题）、历史记录、表格或系统导出资料分散在个人经验里，且没人愿意整理
流程状态人工流程已经存在，只是重复、慢、容易漏人工流程本身还没确定，部门之间口径冲突
风险状态可以通过人工确认、权限控制和日志追踪降低风险涉及强监管、资金划拨、法律承诺，却不允许人工审核
业务收益节省时间、减少错误、提升响应、沉淀知识或辅助决策客户期待无人负责的“全自动决策”

一个实用原则是：AI Agent 先改造“已有流程中的低风险重复环节”，再逐步靠近高价值环节。越接近资金、合同、外发、客户承诺和人事决策，越要引入 Human-in-the-loop（人工参与闭环），让人保留最终判断权。

需求澄清清单​

和客户沟通时，不要先问“你想用什么模型”。先把业务问清楚：

  • 客户原话是什么？其中哪些是想要的结果，哪些只是客户想象中的实现方式？
  • 当前人工流程怎么做？谁接收输入，谁判断，谁执行，谁复核？
  • 项目成功后优先改善什么指标：响应速度、处理量、错误率、转化率、满意度、合规风险，还是管理透明度？
  • 客户能提供哪些真实样例？正例、反例、边界例和高风险例分别有多少？
  • 哪些资料是官方口径？哪些资料只是员工经验？哪些资料已经过期？
  • 系统需要读取哪些数据？需要写入哪些数据？是否涉及订单、合同、客户隐私、财务或审批？
  • 哪些动作允许自动完成？哪些动作只能生成草稿？哪些动作必须转人工？
  • 输出给谁看？一线员工、主管、客户、老板看到的内容是否不同？
  • 验收怎么做？用多少条样例测，谁打分，什么情况算失败？
  • 上线后谁维护资料、查看日志、处理反馈和调整规则？

这份清单的作用不是把客户问烦，而是避免把一个“业务责任不清”的问题包装成“模型能力问题”。如果客户无法回答关键问题，就先交付需求诊断和资料梳理，而不是直接进入系统制作。

失败兜底​

AI Agent 项目必须提前设计失败时怎么表现。好的系统不是永远正确，而是在不确定时知道停下来。

失败类型表现兜底策略交付要求
资料缺失找不到依据、政策不明确明确说明资料不足，转人工或发起资料补充日志记录缺失资料主题
意图不清用户一句话包含多个需求追问关键字段，不直接执行追问问题不超过业务所需
工具失败系统接口超时或返回异常保留草稿，提示人工稍后处理不重复提交高风险动作
权限不足用户请求越权查询或修改拒绝并说明需要授权不泄露敏感字段
高风险命中涉及退款、投诉、法律、合同停止自动处理并转人工风险原因可追踪
输出低置信分类或建议不稳定降级为“建议人工复核”不把低置信结果伪装成结论

兜底不是失败后的补丁，而是方案的一部分。报价和验收都应该包含兜底设计，否则客户上线后会把所有异常都归因于“AI 不靠谱”。

评估方法​

项目方法论的评估，不只看模型回答是否流畅，而是看需求是否被拆成了可交付系统。可以用下面的评分表做内部复盘：

维度评分问题合格表现
需求清晰度是否能用一句话说明业务目标、用户、触发条件和成功指标不再停留在“更智能”“更自动”
范围边界是否写清楚能做、不能做、需要人工确认的动作客户不会把草稿误认为正式动作
字段契约输入、输出、权限、风险、追踪字段是否稳定不靠临场解释判断项目是否完成
样例覆盖正常、异常、边界、高风险和工具失败样例是否齐全验收不是只测最顺利的路径
兜底能力资料不足、意图不清、权限不足和工具失败时是否可控系统不硬答、不越权、不重复危险动作
作品集表达是否能讲清商业价值、技术取舍、指标和复盘面试官能看出你的交付思维

如果一个案例在这些维度上说不清，就算模型演示能回答，也还不是可用于作品集的项目。作品集要展示的是“从需求到交付”的判断力。

验收标准​

通用验收标准可以分成五层：

  • 需求验收：客户确认业务目标、范围边界、自动动作和人工确认规则。
  • 资料验收：知识来源、样例来源、过期资料和禁用资料都有清单。
  • 输出验收：输出字段稳定、引用清楚、语气符合业务、不会编造关键事实。
  • 流程验收：工具调用、人工确认、失败兜底和日志追踪都能跑通。
  • 业务验收：在约定样例上达到准确率、效率、转人工率、采纳率或风险识别指标。

验收标准必须写成“可观察结果”，不要写成“效果好”“比较智能”“体验不错”。例如：“50 条历史售后问题中，至少 45 条能识别正确问题类型；涉及退款、投诉、法律风险的 8 条全部转人工；无资料依据的 5 条不得编造政策。”

报价/工期判断​

报价和工期由六个因素决定：

因素低复杂度中复杂度高复杂度
资料整理已有结构化 FAQ（常见问题）或表格多份文档需要清洗资料分散、冲突、过期
任务类型问答或草稿生成分类、评分、报告、提醒多角色协作与跨系统流程
系统接入不接系统或只导入导出只读查询接口写入、审批、外发、多系统
风险等级内部辅助客户可见但可人工确认涉及资金、合同、隐私、合规
验收难度样例明确、指标简单多类型样例需要长期业务结果验证
维护要求偶尔更新资料每月复盘持续质检、看板、权限管理

常见工期判断：

  • 需求诊断与交付方案：0.5-2 天。
  • 可演示的业务原型：3-7 天。
  • 单一场景标准交付：1-3 周。
  • 接入系统、权限、日志和看板的正式交付：3-8 周。
  • 涉及多部门、多系统和高风险审批的项目：需要按里程碑拆分报价。

不要低价承诺“全自动”。真正值钱的是资料治理、流程边界、风险控制和业务复盘能力。

继续学习​