第 2 章：从技术语言到业务价值
本章目标
把技术概念翻译成客户能理解的业务收益。
概念讲解
技术语言描述实现：
- 我们使用了流式输出。
- 我们支持工具调用。
- 我们使用 RAG。
业务语言描述结果：
- 用户不用等待完整回答。
- 系统可以自动处理订单和文件。
- 回答可以引用具体资料。
翻译方法是：
text
技术能力 -> 用户动作 -> 业务结果 -> 可衡量指标业务案例
教育案例：
- 技术：RAG。
- 业务：学生提问时，系统引用教材和讲义回答。
- 结果：答疑更准确，教师更容易审核。
企业服务案例：
- 技术：Tool Calling。
- 业务：客服 Agent 自动查询订单状态。
- 结果：减少等待时间，降低人工处理量。
技术对应关系
你学习过的 Agent 概念可以这样映射：
| 技术概念 | 业务表达 |
|---|---|
| Streaming | 用户能即时看到回答 |
| Tool Calling | 系统能自动执行任务 |
| Session Log | 过程可恢复、可审计 |
| RAG | 回答有来源 |
| Permission | 高风险操作可控制 |
售前/产品视角
产品视角：技术选择应该服务于用户问题，而不是为了技术而技术。
售前视角：客户不关心你用不用 Agent，只关心他的业务问题是否被解决。
示例模板
一句话价值表达：
text
我们帮助[目标用户]在[具体场景]中，通过[核心能力]，减少[成本/时间/错误]，提升[效率/体验/收入]。面试追问
问：怎样把工具调用讲给非技术客户？
回答要点：
- 不讲 Schema 和 JSON。
- 讲“系统能自动完成某件事”。
- 强调结果、风险和人工确认。
问：为什么客户不关心你的技术栈？
回答要点：
- 客户关心业务结果。
- 技术栈只是实现手段。
- 只有在影响成本、安全和交付时才重要。
问：什么情况下技术细节必须讲？
回答要点：
- 安全合规。
- 数据边界。
- 性能指标。
- 集成限制。
练习任务
为 Agent、RAG、MCP 各写一句技术解释和一句业务解释。
本章产出
- 30 秒价值表达。
- 一页产品价值主张。
验收标准
能用“用户问题、解决方案、业务结果”三句话讲清一个 AI 功能。