主题
专题 07 行业场景设计：客服、知识助手、运营助手
本专题解决的是一个非常关键但经常被忽略的问题：很多人学了 Tool Calling、RAG、Workflow，也做了一些 Demo，但一到真实业务场景就不知道该怎么落，或者会把项目做成“技术栈展示”，而不是“业务问题解决方案”。
对前端工程师来说，这一层尤其重要，因为你最终要进入的不是一个抽象的“AI 团队”，而是一个具体业务场景：客服、企业内部知识、运营提效、销售辅助、办公协同、审批流转等。能不能把技术能力翻译成业务价值，往往决定了项目能不能落地，也决定了面试官会不会觉得你只是会拼 Demo。
1. 为什么要做行业场景设计
同样一套技术，在不同业务场景中的目标、风险、指标、交互方式都完全不同。 例如：
- 客服场景更看重回复准确率、引用一致性、转人工效率。
- 企业知识助手更看重命中率、引用来源、拒答能力、资料更新时效。
- 运营助手更看重任务完成率、草稿质量、协作效率和可追踪性。
如果你不先想清楚业务问题，很容易出现两种情况：
- 技术链路做得很复杂，但解决不了真正有价值的问题。
- 明明业务问题适合简单方案，却被做成一个过度工程化系统。
2. 场景设计的核心问题
建议先回答以下问题：
- 这个场景的核心用户是谁。
- 用户最痛的步骤是什么。
- 当前流程为什么低效。
- 哪一部分适合由 Agent 自动完成。
- 哪一部分必须保留人工判断。
- 成功之后，业务方会认为什么结果叫“有价值”。
如果这些问题答不清，后面的模型、RAG、Workflow 都可能偏航。
3. 三类最适合前端转型展示的场景
3.1 客服助手
适合展示的能力：
- RAG。
- 引用与拒答。
- 回复建议。
- 转人工机制。
- 对话界面与状态提示。
典型问题包括：
- 用户问题分散，客服检索资料慢。
- 回复口径不统一。
- 一线客服遇到边界问题时容易误答。
适合的 Agent 形态通常不是“完全自动回复”，而是：
- 先给客服生成回复建议。
- 附带引用依据。
- 低置信度时提示转人工。
3.2 企业知识助手
适合展示的能力：
- 私有知识接入。
- 引用展示。
- 权限与文档版本治理。
- 结构化输出。
- 评测与回归。
典型问题包括：
- 制度和流程分散在多个文档里。
- 员工找资料慢，答案口径不一致。
- 旧文档与新文档冲突，人工判断成本高。
这类场景最适合做成前端转型作品集的第一个核心项目，因为它业务边界清晰、证据链容易展示、面试追问也比较有抓手。
3.3 运营助手
适合展示的能力：
- 文档读取与摘要。
- 任务拆解。
- 工作流编排。
- 人工确认。
- 多步骤任务工作台。
典型问题包括：
- 会议纪要、活动复盘、周报整理耗时长。
- 人工从长文里提取关键信息效率低。
- 后续待办难跟踪。
这类场景很适合体现前端工程师在任务型界面、执行流程可视化和 Human-in-the-Loop 上的优势。
4. 场景设计的五层方法
4.1 先找“高频 + 高耗时 + 有结构”的问题
适合做 Agent 的问题往往具备这些特征：
- 高频出现。
- 当前人工处理很耗时。
- 输入和输出有一定结构。
- 能定义清晰成功标准。
如果一个问题极低频、极模糊、结果完全主观，第一版通常不适合作为 Agent 项目。
4.2 先切单一角色，不要试图覆盖整个组织
例如：
- 先做客服一线助手，不要一上来做“全链路客服平台”。
- 先做人事制度问答，不要一开始就做全公司万能知识中台。
- 先做活动复盘助手，不要同时做内容生成、审批、排期、预算和投放全流程。
4.3 先定义“不能做什么”
真实项目里，边界比能力更重要。 建议在场景设计阶段就写清楚：
- 哪些问题必须拒答。
- 哪些动作不能自动执行。
- 哪些内容必须人工确认。
- 哪些用户没有权限看到某些结果。
4.4 先做流程图，再谈模型能力
场景一旦涉及多个步骤，建议先画出：
- 用户输入。
- 系统读取哪些上下文。
- 是否需要检索。
- 是否需要调用工具。
- 哪些节点要等用户确认。
- 最终结果如何交付。
这能帮助你判断真正需要的是问答 Agent、执行 Agent 还是工作流 Agent。
4.5 指标必须来自业务目标
不要只写“正确率更高了”。 更好的指标应该和业务结果挂钩，例如：
- 平均找资料时间缩短多少。
- 客服回复建议采用率。
- 运营复盘整理耗时降低多少。
- 人工转接率是否下降。
- 员工自助查询成功率是否上升。
5. 三个高价值场景模板
5.1 客服助手模板
text
目标用户：一线客服 / 售后支持
核心问题：回复口径不一致、查资料慢、边界问题易误答
输入：用户问题、历史工单、知识库文档
输出：回复建议、引用依据、转人工建议
关键能力：RAG / 引用 / 拒答 / 转人工
关键指标：建议采用率 / 回复准确率 / 转人工准确率5.2 企业知识助手模板
text
目标用户：内部员工 / 中后台团队
核心问题：制度分散、查询成本高、资料版本混乱
输入：制度文档、流程文档、FAQ、用户问题
输出：带引用的回答、相关文档推荐、风险提示
关键能力：RAG / 文档版本治理 / 权限控制 / 评测
关键指标：命中率 / 引用准确率 / 拒答准确率 / 查询耗时5.3 运营助手模板
text
目标用户：运营 / 项目经理 / 内容团队
核心问题：长文整理耗时、待办拆解低效、跨人协作不顺畅
输入：会议纪要、活动数据、补充说明
输出：摘要、问题清单、待办、负责人建议、执行计划
关键能力：文档读取 / Workflow / HITL / 任务面板
关键指标：任务完成时间 / 草稿采用率 / 人工修改率6. 前端工程师如何在行业场景里体现优势
6.1 把业务流程做成用户真的愿意用的界面
很多场景不是技术不可行，而是体验不可用。 前端可以补上的价值包括：
- 让证据可见。
- 让任务状态清晰。
- 让高风险动作可确认。
- 让失败后有明确下一步。
6.2 把“业务可信度”通过界面展示出来
例如：
- 客服助手展示引用依据和低置信度提示。
- 知识助手展示文档版本与来源。
- 运营助手展示已完成步骤与待确认节点。
6.3 把项目写成“业务故事”而不是“技术清单”
作品集里更推荐这样表达：
- 某个岗位每天在做什么重复劳动。
- 你的 Agent 怎么改变这个流程。
- 你如何定义成功与失败。
- 你如何平衡自动化与人工确认。
7. 常见失败模式
7.1 问题选得太大
导致项目边界失控，最后什么都做不深。
7.2 问题选得太虚
没有明确输入输出，也没有可衡量指标，最后难以验证价值。
7.3 为了贴技术热点而硬上场景
比如本来一个简单表单工具就能解决的问题，硬做成多 Agent 协作系统。
7.4 没有用户角色视角
只站在开发者视角设计，而没有真正考虑一线用户如何使用。
7.5 忽略权限和风险
很多业务场景一旦接真实数据，就必须考虑越权、误用和错误执行后果。
8. 验证方式
可以通过以下问题检查你的场景设计是否扎实：
- 是否能用一句话说清目标用户和核心问题。
- 是否能明确哪些环节适合自动化，哪些必须人工处理。
- 是否能定义至少 2 到 3 个业务指标。
- 是否能解释为什么这个问题值得用 Agent，而不是普通搜索或表单系统。
- 是否能把场景落成一个最小可交付项目。
9. 面试表达
你可以这样讲：
“我在做 AI Agent 项目时，不是从技术栈出发，而是先从行业场景和用户流程出发。比如客服助手更重口径一致和转人工，知识助手更重引用和拒答，运营助手更重任务拆解和人工确认。这样我做出来的不是一个泛化 Demo，而是一个有真实业务边界、有指标、有工程治理的场景化系统。”