add
This commit is contained in:
fuzhongyun
parent
37674ebbbc
commit
abe8a83c93
|
|
@ -1,313 +0,0 @@
|
|||
# AI工业化概念澄清篇：从技术演进看必然趋势
|
||||
|
||||
## 引言：为什么现在必须谈AI工业化？
|
||||
|
||||
在AI技术快速发展的今天，我们面临着一个关键转折点。从ChatGPT引爆生成式AI热潮以来，无数企业和开发者都在探索如何将AI能力应用到实际业务中。然而，现实情况是：**90%的AI项目都停留在Demo阶段，无法真正投入生产使用**。
|
||||
|
||||
这不是技术能力的问题，而是思维方式的差距。我们习惯了"手工作坊"式的AI开发，却忽视了现代软件开发早已进入工业化时代。本文将深入剖析AI技术演进的三个阶段，帮助你理解为什么工业化是AI应用的必由之路。
|
||||
|
||||
## 🔄 技术演进的三个时代
|
||||
|
||||
### 手工时代：个人英雄主义的困境
|
||||
|
||||
**特征描述：**
|
||||
这个时代的AI开发就像手工艺品制作，完全依赖个人技能和经验。每个项目都是从头开始，没有标准化流程，也没有质量保证体系。
|
||||
|
||||
**具体表现：**
|
||||
- **Prompt工程靠感觉**：每次都要重新编写Prompt，没有统一的标准和规范
|
||||
- **结果质量看运气**：同样的输入可能得到完全不同的输出，质量极不稳定
|
||||
- **知识无法传承**：一个人的经验很难传递给团队其他成员
|
||||
- **开发效率低下**：每个新项目都要重复造轮子
|
||||
|
||||
**典型案例：7位定时任务表达式生成**
|
||||
```
|
||||
场景：开发一个cron表达式生成器
|
||||
问题：每次都要重新设计Prompt，调整参数
|
||||
结果：花了3天做出一个只能处理简单场景的版本
|
||||
维护：后续每增加一种新格式，都要重新测试所有功能
|
||||
```
|
||||
|
||||
**核心痛点：**
|
||||
1. 缺乏标准化流程，每个开发者都有自己的"最佳实践"
|
||||
2. 没有质量保证机制，无法确保输出结果的稳定性
|
||||
3. 知识沉淀困难，团队经验无法有效积累
|
||||
4. 规模化 impossible，一个人再厉害也有限
|
||||
|
||||
### 智能体时代：个体能力提升的突破
|
||||
|
||||
**特征描述：**
|
||||
随着大语言模型的成熟，我们进入了智能体时代。这个时代最大的特点是AI具备了"记忆"和"工具使用"能力，能够完成更复杂的任务。
|
||||
|
||||
**具体表现：**
|
||||
- **对话记忆能力**：AI能记住之前的对话内容，保持上下文一致性
|
||||
- **工具调用能力**：可以调用外部API、查询数据库、执行计算等
|
||||
- **推理规划能力**：能够将复杂任务分解为多个步骤执行
|
||||
- **自适应学习**：通过与用户的交互不断优化表现
|
||||
|
||||
**典型案例：查询天气智能体**
|
||||
```
|
||||
功能：用户询问"明天适合出门吗？"
|
||||
处理流程：
|
||||
1. 提取用户位置信息
|
||||
2. 调用天气API获取预报
|
||||
3. 分析温度、降水概率、风速等指标
|
||||
4. 给出个性化建议
|
||||
```
|
||||
|
||||
**进步之处：**
|
||||
1. **能力边界扩展**：从单纯的文本生成扩展到多模态任务
|
||||
2. **交互体验改善**：用户可以用自然语言与AI交流
|
||||
3. **任务复杂度提升**：能够处理需要多步推理的问题
|
||||
4. **个性化服务**：根据用户偏好和历史行为提供定制化建议
|
||||
|
||||
**新的局限性：**
|
||||
1. **仍然作坊式生产**：每个智能体都需要单独训练和优化
|
||||
2. **规模化挑战**：维护大量智能体的成本很高
|
||||
3. **质量不一致**：不同智能体的表现差异很大
|
||||
4. **缺乏统一标准**：没有标准化的开发和评估体系
|
||||
|
||||
### 工业化时代：规模化生产的必然
|
||||
|
||||
**特征描述：**
|
||||
AI工业化借鉴了制造业的流水线思维，将AI应用开发分解为标准化、可重复的流程。这个时代强调的是**质量可控、批量生产、快速复制**。
|
||||
|
||||
**核心特征：**
|
||||
- **标准化流程**：从数据准备到模型部署都有明确的规范和标准
|
||||
- **质量可控**：建立完整的质量保证体系，确保输出结果的稳定性
|
||||
- **批量生产**：能够同时处理大量相似任务，支持规模化应用
|
||||
- **快速复制**：成功经验可以快速推广到其他场景
|
||||
|
||||
**典型案例：直连天下AI助手**
|
||||
```
|
||||
架构设计：
|
||||
├── 数据层：统一的数据收集和预处理流程
|
||||
├── 模型层：标准化的模型训练和评估pipeline
|
||||
├── 服务层：可扩展的API服务架构
|
||||
├── 应用层：模块化的业务逻辑组件
|
||||
└── 监控层：全方位的性能和质量监控
|
||||
|
||||
效果对比：
|
||||
- 开发周期：从3个月缩短到2周
|
||||
- 维护成本：降低70%
|
||||
- 质量稳定性：提升85%
|
||||
- 团队效率：提高3倍
|
||||
```
|
||||
|
||||
**工业化优势：**
|
||||
1. **标准化降低门槛**：普通人也能开发高质量的AI应用
|
||||
2. **质量保证体系**：建立完整的测试、监控、反馈机制
|
||||
3. **规模化能力**：支持大批量、高并发的业务场景
|
||||
4. **持续优化**：基于数据驱动的持续改进机制
|
||||
5. **成本可控**：通过标准化和自动化降低开发和运维成本
|
||||
|
||||
## 💡 为什么要工业化？
|
||||
|
||||
### 从Demo到生产的巨大鸿沟
|
||||
|
||||
**Demo阶段的思维：**
|
||||
- "跑通就行"：只要基本功能能实现就满足了
|
||||
- "人工兜底"：出问题的时候人工重启或修正
|
||||
- "个人项目"：一个人搞定，不需要团队协作
|
||||
- "技术导向"：主要考虑技术可行性，不考虑业务需求
|
||||
|
||||
**生产环境的要求：**
|
||||
- "7×24小时稳定运行"：不能有任何中断或故障
|
||||
- "零人工干预"：所有问题都要自动处理
|
||||
- "团队协作"：需要业务、技术、运维等多方配合
|
||||
- "业务导向"：必须满足实际业务需求和用户体验
|
||||
|
||||
**真实案例对比：**
|
||||
```
|
||||
Demo项目：智能客服系统
|
||||
- 功能：能回答10个预设问题
|
||||
- 性能：响应时间5-10秒可接受
|
||||
- 容错：回答错了用户可以再问一次
|
||||
- 维护：开发者自己偶尔看看日志
|
||||
|
||||
生产项目：电商客服系统
|
||||
- 功能：需要处理95%以上的用户咨询
|
||||
- 性能：响应时间必须<2秒
|
||||
- 容错：错误率必须<1%，需要人工兜底
|
||||
- 维护：7×24小时监控，专业运维团队
|
||||
```
|
||||
|
||||
### 工业化解决的核心问题
|
||||
|
||||
#### 1. 标准化：从 chaos 到 order
|
||||
|
||||
**问题现状：**
|
||||
- 每个项目都有自己的"最佳实践"
|
||||
- 代码风格、架构设计、部署方式各不相同
|
||||
- 新员工需要很长时间才能上手
|
||||
- 项目交接困难，知识容易流失
|
||||
|
||||
**工业化方案：**
|
||||
```
|
||||
标准化体系：
|
||||
├── 开发标准：统一的编码规范、设计模式
|
||||
├── 流程标准：标准化的开发、测试、部署流程
|
||||
├── 文档标准：统一的文档格式和模板
|
||||
├── 评估标准：量化的质量评估指标
|
||||
└── 培训标准：体系化的技能培训方案
|
||||
```
|
||||
|
||||
**实际效果：**
|
||||
- 新员工上手时间从2个月缩短到2周
|
||||
- 代码质量提升60%
|
||||
- 项目交接效率提升80%
|
||||
|
||||
#### 2. 可维护：从被动救火到主动预防
|
||||
|
||||
**问题现状：**
|
||||
- 问题发现靠用户投诉
|
||||
- 故障排查靠个人经验
|
||||
- 修复问题需要停机维护
|
||||
- 缺乏预防性维护机制
|
||||
|
||||
**工业化方案：**
|
||||
```
|
||||
维护体系：
|
||||
├── 监控系统：实时监控各项指标
|
||||
├── 告警机制：异常情况自动通知
|
||||
├── 日志体系：完整的操作和错误日志
|
||||
├── 回滚机制：快速回滚到稳定版本
|
||||
└── 预案体系：各种故障的处理预案
|
||||
```
|
||||
|
||||
**实际效果：**
|
||||
- 故障发现时间从小时级缩短到分钟级
|
||||
- 平均修复时间缩短70%
|
||||
- 系统可用性提升到99.9%
|
||||
|
||||
#### 3. 可扩展：从推倒重来到平滑演进
|
||||
|
||||
**问题现状：**
|
||||
- 业务增长需要重新设计架构
|
||||
- 新功能开发影响现有功能
|
||||
- 性能瓶颈无法有效缓解
|
||||
- 技术债务越积越多
|
||||
|
||||
**工业化方案：**
|
||||
```
|
||||
扩展体系：
|
||||
├── 架构设计：模块化的微服务架构
|
||||
├── 数据设计：支持水平扩展的数据结构
|
||||
├── 接口设计：向前兼容的API设计
|
||||
├── 性能优化：可扩展的性能优化方案
|
||||
└── 技术演进：渐进式的技术栈升级
|
||||
```
|
||||
|
||||
**实际效果：**
|
||||
- 支持业务10倍增长无需重构
|
||||
- 新功能开发周期缩短50%
|
||||
- 性能优化成本降低60%
|
||||
|
||||
#### 4. 可复制：从单点突破到批量成功
|
||||
|
||||
**问题现状：**
|
||||
- 成功经验无法有效传承
|
||||
- 每个新项目都要重新摸索
|
||||
- 优秀实践难以规模化推广
|
||||
- 团队能力参差不齐
|
||||
|
||||
**工业化方案：**
|
||||
```
|
||||
复制体系：
|
||||
├── 模板库：标准化的项目模板
|
||||
├── 组件库：可复用的功能组件
|
||||
├── 最佳实践：文档化的成功经验
|
||||
├── 培训体系：标准化的技能培训
|
||||
└── 评估体系：量化的效果评估机制
|
||||
```
|
||||
|
||||
**实际效果：**
|
||||
- 新项目启动时间缩短80%
|
||||
- 成功率提升90%
|
||||
- 团队整体能力提升2倍
|
||||
|
||||
## 🚀 工业化转型的关键路径
|
||||
|
||||
### 阶段一：认知统一（1-2周）
|
||||
|
||||
**目标：** 让整个团队理解工业化的必要性和价值
|
||||
|
||||
**关键活动：**
|
||||
1. **现状分析**：深入分析当前开发流程中的痛点
|
||||
2. **标杆学习**：研究行业内成功的工业化案例
|
||||
3. **价值论证**：量化工业化带来的效益提升
|
||||
4. **风险评估**：识别转型过程中的潜在风险
|
||||
|
||||
**成功标准：**
|
||||
- 团队成员100%理解工业化概念
|
||||
- 形成统一的转型目标和计划
|
||||
- 获得管理层的全力支持
|
||||
|
||||
### 阶段二：标准制定（2-4周）
|
||||
|
||||
**目标：** 建立完整的标准化体系
|
||||
|
||||
**关键活动：**
|
||||
1. **流程梳理**：详细梳理现有开发流程
|
||||
2. **标准制定**：制定各个环节的标准规范
|
||||
3. **工具选型**：选择支持标准化的开发工具
|
||||
4. **模板开发**：开发标准化的项目模板
|
||||
|
||||
**成功标准：**
|
||||
- 形成完整的标准化文档
|
||||
- 开发工具配置完成
|
||||
- 模板通过试点项目验证
|
||||
|
||||
### 阶段三：试点验证（4-8周）
|
||||
|
||||
**目标：** 通过试点项目验证工业化方案的可行性
|
||||
|
||||
**关键活动：**
|
||||
1. **项目选择**：选择具有代表性的试点项目
|
||||
2. **方案实施**：按照标准化流程实施试点项目
|
||||
3. **数据收集**：收集实施过程中的各项数据
|
||||
4. **效果评估**：对比工业化前后的效果差异
|
||||
|
||||
**成功标准：**
|
||||
- 试点项目成功上线
|
||||
- 质量指标达到预期
|
||||
- 效率提升超过30%
|
||||
|
||||
### 阶段四：全面推广（8-12周）
|
||||
|
||||
**目标：** 将工业化方案推广到所有项目
|
||||
|
||||
**关键活动：**
|
||||
1. **培训推广**：对全体团队成员进行培训
|
||||
2. **逐步推广**：分批次推广到新项目
|
||||
3. **持续优化**：根据反馈不断优化方案
|
||||
4. **文化建设**：建立工业化开发文化
|
||||
|
||||
**成功标准：**
|
||||
- 所有新项目都采用工业化流程
|
||||
- 团队成员熟练掌握标准化技能
|
||||
- 整体效率提升超过50%
|
||||
|
||||
## 结语：工业化的未来展望
|
||||
|
||||
AI工业化不是终点，而是新的起点。随着技术的不断发展，我们可以预见：
|
||||
|
||||
**技术趋势：**
|
||||
- **自动化程度更高**：更多的开发环节将实现自动化
|
||||
- **智能化水平提升**：AI将参与到开发流程的优化中
|
||||
- **标准化更加完善**：行业标准将逐步统一和完善
|
||||
|
||||
**业务价值：**
|
||||
- **开发成本大幅降低**：通过标准化和自动化降低成本
|
||||
- **开发周期显著缩短**：从月到周的转变将成为常态
|
||||
- **质量稳定性大幅提升**：99.9%的可用性将成为基本要求
|
||||
|
||||
**组织变革：**
|
||||
- **团队协作模式改变**：从个人英雄主义到团队协作
|
||||
- **技能要求重新定位**：从全栈工程师到专业化分工
|
||||
- **创新模式发生转变**：从技术创新到应用创新
|
||||
|
||||
**"从Demo到生产，从能用到好用，工业化是必经之路"**
|
||||
|
||||
这不仅是技术发展的必然趋势，更是AI应用走向成熟的标志。只有拥抱工业化，我们才能真正释放AI的巨大潜力，创造更大的商业价值。
|
||||
|
||||
现在，是时候开始你的AI工业化转型之旅了！
|
||||
|
|
@ -1,628 +0,0 @@
|
|||
# AI需求识别与场景评估篇：找到真正适合AI的场景
|
||||
|
||||
## 引言：为什么需求识别是AI项目成功的关键？
|
||||
|
||||
在AI热潮中，一个令人沮丧的统计数字是：**超过70%的AI项目最终失败或被放弃**。失败的原因往往不是技术不够先进，而是**选择了错误的应用场景**。
|
||||
|
||||
很多团队陷入了一个误区：为了使用AI而使用AI。他们投入大量资源开发AI解决方案，却发现效果不如传统的规则引擎，或者维护成本过高。这背后的根本问题是：**没有正确识别什么样的需求真正适合用AI来解决**。
|
||||
|
||||
本文将提供一个系统性的框架，帮助你准确判断一个场景是否适合使用AI，避免踩坑，提高AI项目的成功率。
|
||||
|
||||
## 🎯 AI最擅长的三件事
|
||||
|
||||
### 第一类：重复性工作 - AI的"舒适区"
|
||||
|
||||
**核心特征：**
|
||||
这类工作通常具有明确的输入输出格式，虽然对人类来说枯燥乏味，但AI却能够不知疲倦地高效处理。
|
||||
|
||||
**典型特征：**
|
||||
- **高频次发生**：每天、每小时甚至每分钟都在发生
|
||||
- **流程相对固定**：有明确的处理步骤和判断逻辑
|
||||
- **规则相对清晰**：虽然可能有例外情况，但大部分情况有规律可循
|
||||
- **人工处理成本高**：需要大量人力投入，且容易出错
|
||||
|
||||
**业务价值：**
|
||||
- **释放人力资源**：让人员从重复性工作中解脱，投入到更有创造性的工作中
|
||||
- **提高处理效率**：AI可以7×24小时不间断工作，处理速度远超人类
|
||||
- **降低错误率**：AI不会疲劳，能够保持一致的判断标准
|
||||
- **标准化输出**：确保处理结果的一致性和规范性
|
||||
|
||||
**典型案例分析：**
|
||||
|
||||
#### 案例1：订单异常排查系统
|
||||
```
|
||||
场景描述：
|
||||
某电商平台每天处理10万+订单，其中约5%会出现各种异常（库存不足、支付失败、地址错误等）。
|
||||
传统做法：20人的客服团队手动排查，平均每个订单处理时间5分钟。
|
||||
|
||||
AI解决方案：
|
||||
输入：订单号、用户信息、商品信息、支付记录、物流状态
|
||||
处理：AI分析异常模式，给出可能的原因和解决方案
|
||||
输出：异常类型分类、处理建议、优先级评级
|
||||
|
||||
效果对比：
|
||||
- 处理时间：从5分钟缩短到30秒
|
||||
- 准确率：从85%提升到95%
|
||||
- 人力成本：减少80%
|
||||
- 客户满意度：提升40%
|
||||
```
|
||||
|
||||
#### 案例2：智能客服问答系统
|
||||
```
|
||||
场景描述：
|
||||
某SaaS公司每天收到2000+客户咨询，其中70%是重复性问题（价格、功能、使用方法等）。
|
||||
传统做法：10人的客服团队轮班回答，响应时间平均2小时。
|
||||
|
||||
AI解决方案：
|
||||
输入：客户问题文本、历史对话记录、产品文档、知识库
|
||||
处理：理解问题意图，匹配最佳答案，必要时请求更多信息
|
||||
输出：准确回答、相关文档链接、升级建议（复杂问题）
|
||||
|
||||
效果对比：
|
||||
- 响应时间：从2小时缩短到即时响应
|
||||
- 解决率：80%的问题无需人工介入
|
||||
- 客户满意度：提升50%
|
||||
- 客服工作量：减少60%
|
||||
```
|
||||
|
||||
**适用性判断清单：**
|
||||
✅ 每天需要处理大量相似任务
|
||||
✅ 任务流程相对标准化
|
||||
✅ 错误成本可以接受（不会导致严重后果）
|
||||
✅ 有明确的输入输出格式
|
||||
✅ 人工处理效率低或成本高
|
||||
|
||||
### 第二类：经验判断 - AI的"学习区"
|
||||
|
||||
**核心特征：**
|
||||
这类工作需要结合多个因素进行综合判断，虽然需要一定的专业经验，但有规律可循，AI可以通过学习历史数据来掌握判断逻辑。
|
||||
|
||||
**典型特征：**
|
||||
- **多因素综合判断**：需要考虑多个维度的信息
|
||||
- **有规律但复杂**：存在一定的模式，但规则难以明确表述
|
||||
- **有历史数据支撑**：有足够的历史案例供AI学习
|
||||
- **容错性相对较高**：判断错误不会造成灾难性后果
|
||||
- **专业门槛适中**：不需要顶级专家级别的判断能力
|
||||
|
||||
**业务价值：**
|
||||
- **标准化专业判断**：将专家经验转化为可复制的AI能力
|
||||
- **提高判断一致性**：避免不同人员判断标准的差异
|
||||
- **加速决策过程**：快速给出初步判断，提高整体效率
|
||||
- **降低专业门槛**：让非专业人员也能获得专业级的判断
|
||||
|
||||
**典型案例分析：**
|
||||
|
||||
#### 案例1：商品销售潜力分析
|
||||
```
|
||||
场景描述：
|
||||
某零售企业需要从1000个新品中选择100个进行重点推广，传统依赖采购经理的经验判断。
|
||||
|
||||
AI解决方案：
|
||||
输入因素：
|
||||
- 商品基础信息：类别、价格、品牌、规格等
|
||||
- 历史销售数据：相似商品的历史表现
|
||||
- 市场环境：季节性、竞品情况、消费趋势
|
||||
- 供应链因素：库存成本、供应商稳定性
|
||||
- 营销资源：可投入的营销预算、渠道支持
|
||||
|
||||
AI判断逻辑：
|
||||
基于历史数据训练模型，识别高潜力商品的特征模式
|
||||
输出：销售潜力评分（1-10分）、主要风险因素、建议策略
|
||||
|
||||
效果对比：
|
||||
- 选择准确率：从60%提升到85%
|
||||
- 决策时间：从2周缩短到3天
|
||||
- 销售额提升：30%
|
||||
- 库存周转率：提升25%
|
||||
```
|
||||
|
||||
#### 案例2：订单风险评估
|
||||
```
|
||||
场景描述：
|
||||
某B2B平台需要对每笔订单进行风险评估，判断是否可能存在违约、欺诈等风险。
|
||||
传统做法：风控专员人工审核，主要依赖经验和直觉。
|
||||
|
||||
AI解决方案：
|
||||
输入因素：
|
||||
- 客户信息：注册时间、历史订单、信用评级
|
||||
- 订单信息：金额、商品类型、交付时间要求
|
||||
- 行为特征：下单时间、支付方式、配送地址
|
||||
- 外部环境：行业风险、地区风险、季节性因素
|
||||
|
||||
AI判断逻辑：
|
||||
综合分析多个风险因子，给出风险评级和建议措施
|
||||
输出：风险等级（低/中/高）、主要风险点、建议处理方式
|
||||
|
||||
效果对比：
|
||||
- 风险识别准确率：从70%提升到90%
|
||||
- 审核效率：提升5倍
|
||||
- 坏账率：降低60%
|
||||
- 客户体验：优质客户审核时间大幅缩短
|
||||
```
|
||||
|
||||
**适用性判断清单：**
|
||||
✅ 需要综合考虑多个因素进行判断
|
||||
✅ 有充足的历史数据可供学习
|
||||
✅ 存在一定的判断规律或模式
|
||||
✅ 判断错误不会造成严重后果
|
||||
✅ 人工判断成本高或一致性差
|
||||
|
||||
### 第三类：信息整理 - AI的"整理区"
|
||||
|
||||
**核心特征：**
|
||||
这类工作需要从大量非结构化文本中提取、整理、归纳关键信息，虽然对人类来说耗时耗力，但AI能够快速处理大量文本并提取有价值的信息。
|
||||
|
||||
**典型特征：**
|
||||
- **信息量大**：需要从大量文档或文本中获取信息
|
||||
- **非结构化数据**：信息分散在段落文本中，没有固定格式
|
||||
- **提取整理工作**：需要识别、提取、归类关键信息
|
||||
- **语义理解要求**：需要理解文本的含义和上下文
|
||||
- **格式化输出**：需要将提取的信息整理成结构化格式
|
||||
|
||||
**业务价值：**
|
||||
- **大幅提升处理效率**：AI可以在几分钟内处理人类需要几天完成的工作
|
||||
- **降低遗漏风险**：AI能够全面扫描所有相关内容，避免遗漏
|
||||
- **标准化信息提取**：确保信息提取的一致性和完整性
|
||||
- **释放专业人员时间**：让专业人员专注于分析和决策，而不是信息收集
|
||||
|
||||
**典型案例分析：**
|
||||
|
||||
#### 案例1：政策解读自动化
|
||||
```
|
||||
场景描述：
|
||||
某金融机构需要及时了解和分析各种金融监管政策，涉及多个监管部门和数百份文件。
|
||||
传统做法：3名分析师专门负责政策跟踪，每人每天阅读50+份文件。
|
||||
|
||||
AI解决方案：
|
||||
输入：政策文件、法规条文、监管通知、新闻稿等
|
||||
处理：
|
||||
1. 识别政策类型和影响范围
|
||||
2. 提取关键要求和时间节点
|
||||
3. 分析对现有业务的影响
|
||||
4. 整理成结构化的摘要报告
|
||||
输出：政策摘要、影响分析、行动建议、合规检查清单
|
||||
|
||||
效果对比：
|
||||
- 处理时间：从3天缩短到2小时
|
||||
- 覆盖率：从60%提升到95%
|
||||
- 准确性：关键信息提取准确率90%
|
||||
- 人力成本：减少70%
|
||||
```
|
||||
|
||||
#### 案例2：文档智能问答系统
|
||||
```
|
||||
场景描述：
|
||||
某制造企业有数千页的技术文档、操作手册、维修指南，员工经常需要查找特定信息。
|
||||
传统做法：员工手动搜索文档，或询问有经验的技术人员，平均查找时间30分钟。
|
||||
|
||||
AI解决方案：
|
||||
输入：员工问题、相关文档集合、历史问答记录
|
||||
处理：
|
||||
1. 理解问题的意图和关键信息
|
||||
2. 在文档库中定位相关信息
|
||||
3. 提取准确的答案和上下文
|
||||
4. 生成简洁明了的回答
|
||||
输出：准确答案、相关文档链接、扩展信息、置信度评分
|
||||
|
||||
效果对比：
|
||||
- 响应时间：从30分钟缩短到30秒
|
||||
- 准确率：85%的问题得到准确回答
|
||||
- 员工满意度：提升60%
|
||||
- 技术人员工作量：减少40%
|
||||
```
|
||||
|
||||
**适用性判断清单：**
|
||||
✅ 需要从大量文本中提取关键信息
|
||||
✅ 信息分散在非结构化文档中
|
||||
✅ 人工处理耗时且容易遗漏
|
||||
✅ 有相对明确的信息提取标准
|
||||
✅ 提取的信息需要结构化整理
|
||||
|
||||
## ❌ 这些情况，别用AI
|
||||
|
||||
### 第一类：规则很清楚 - 传统编程更合适
|
||||
|
||||
**典型特征：**
|
||||
- **业务规则明确**：有清晰的if-else逻辑
|
||||
- **判断标准固定**：可以用明确的数值或条件判断
|
||||
- **结果要求确定**：输出结果必须是确定的，不能模糊
|
||||
- **性能要求高**：需要毫秒级响应时间
|
||||
- **维护成本敏感**：需要长期维护，成本要求高
|
||||
|
||||
**为什么不适用：**
|
||||
1. **成本更高**：AI开发和维护成本远高于传统编程
|
||||
2. **性能更差**：AI推理速度远低于规则引擎
|
||||
3. **结果不确定**：AI输出可能有误差，而规则引擎结果是确定的
|
||||
4. **调试困难**：AI决策过程不透明，难以调试和优化
|
||||
|
||||
**典型案例：**
|
||||
```
|
||||
❌ 错误选择：用AI判断用户是否满足贷款条件
|
||||
条件：年龄>=18岁 AND 收入>=3000元 AND 信用分>=600
|
||||
结果：AI判断准确率95%，但规则引擎准确率100%
|
||||
成本：AI开发成本是规则引擎的10倍
|
||||
性能：AI响应时间500ms，规则引擎5ms
|
||||
|
||||
✅ 正确选择：用规则引擎处理
|
||||
优势：100%准确、毫秒级响应、易于维护、成本低廉
|
||||
```
|
||||
|
||||
**替代方案：**
|
||||
- **规则引擎**：Drools、Easy Rules等专门的规则引擎
|
||||
- **传统编程**：简单的if-else逻辑判断
|
||||
- **决策表**：将业务规则配置化，便于维护
|
||||
- **流程引擎**：如Activiti、Flowable等处理复杂业务流程
|
||||
|
||||
### 第二类：要求100%准确 - AI无法满足
|
||||
|
||||
**典型特征：**
|
||||
- **容错率为零**：任何错误都可能导致严重后果
|
||||
- **涉及安全关键**：如医疗诊断、金融交易、工业控制等
|
||||
- **法律合规要求**：必须符合严格的法律法规要求
|
||||
- **影响生命安全**：如自动驾驶、医疗设备等
|
||||
- **经济损失巨大**：单个错误可能导致巨额损失
|
||||
|
||||
**为什么不适用：**
|
||||
1. **AI固有局限性**：即使是最好的AI模型也有误差率
|
||||
2. **黑盒问题**：AI决策过程不透明，难以完全信任
|
||||
3. **边界情况**：AI在极端情况下可能表现不稳定
|
||||
4. **责任问题**：AI错误难以界定责任归属
|
||||
|
||||
**典型案例：**
|
||||
```
|
||||
❌ 错误选择：用AI做癌症诊断
|
||||
风险：误诊可能导致患者错过最佳治疗时机
|
||||
问题：AI准确率即使达到99%，那1%的错误也是致命的
|
||||
责任：医疗事故责任难以界定
|
||||
|
||||
✅ 正确选择：AI辅助+人工确认
|
||||
方案：AI提供初步筛查，医生做最终诊断
|
||||
优势：提高医生效率，同时保证诊断准确性
|
||||
```
|
||||
|
||||
**替代方案：**
|
||||
- **规则引擎**：基于明确规则的确定性系统
|
||||
- **专家系统**：结合专家知识的确定性推理系统
|
||||
- **传统软件**：经过严格测试的传统软件系统
|
||||
- **AI辅助模式**：AI提供建议，人工做最终决策
|
||||
|
||||
### 第三类：一次性的活 - 开发成本太高
|
||||
|
||||
**典型特征：**
|
||||
- **临时性需求**：只需要使用一次或很少使用
|
||||
- **开发时间紧张**：需要在极短时间内完成
|
||||
- **需求变化频繁**：每次使用的需求都不相同
|
||||
- **数据量很小**：没有足够的数据训练AI模型
|
||||
- **预算极其有限**：无法承担AI开发成本
|
||||
|
||||
**为什么不适用：**
|
||||
1. **开发成本高**：AI项目需要数据准备、模型训练、系统开发等
|
||||
2. **时间周期长**：即使是简单的AI应用也需要几周时间开发
|
||||
3. **维护成本高**：AI系统需要持续维护和优化
|
||||
4. **数据要求**：AI需要大量训练数据，一次性任务往往缺乏数据
|
||||
|
||||
**典型案例：**
|
||||
```
|
||||
❌ 错误选择：用AI处理一次性的数据清洗任务
|
||||
需求：清洗1000条客户地址数据，去除重复和错误
|
||||
成本：AI开发需要2周时间，成本2万元
|
||||
结果：用Excel手工处理只需要2小时
|
||||
|
||||
✅ 正确选择：人工处理或简单工具
|
||||
方案：用Excel、OpenRefine等工具手工处理
|
||||
成本：几乎零成本，2小时完成
|
||||
```
|
||||
|
||||
**替代方案：**
|
||||
- **人工处理**：对于小量数据，人工处理更高效
|
||||
- **简单工具**：使用Excel、脚本等简单工具处理
|
||||
- **外包服务**：将任务外包给专业服务提供商
|
||||
- **现成软件**：使用已有的数据处理软件
|
||||
|
||||
## 🔍 三招判断你的场景
|
||||
|
||||
### 第一招：频次测试 - 判断使用频率
|
||||
|
||||
**核心问题：**这个问题多久出现一次？
|
||||
|
||||
**测试方法：**
|
||||
```
|
||||
高频次（每天多次）→ ✅ 适合AI
|
||||
中频次（每周几次）→ ⚠️ 需要进一步评估
|
||||
低频次（每月几次）→ ❌ 不适合AI
|
||||
一次性（只此一次）→ ❌ 绝对不适合
|
||||
```
|
||||
|
||||
**具体评估标准：**
|
||||
|
||||
**高频次场景（强烈推荐）：**
|
||||
- 每天处理100+次
|
||||
- 每周处理500+次
|
||||
- 每月处理2000+次
|
||||
- 年度累计处理成本超过10万元
|
||||
|
||||
**中频次场景（谨慎评估）：**
|
||||
- 每天处理10-100次
|
||||
- 需要评估开发成本vs人工成本
|
||||
- 考虑未来增长潜力
|
||||
- 评估技术复杂度
|
||||
|
||||
**低频次场景（不推荐）：**
|
||||
- 每周处理少于10次
|
||||
- 年度处理总量很小
|
||||
- 开发成本无法摊销
|
||||
- 维护成本过高
|
||||
|
||||
**实际案例：**
|
||||
```
|
||||
✅ 高频次成功案例：电商客服系统
|
||||
- 每日咨询量：2000+次
|
||||
- 年度总量：730,000+次
|
||||
- 人工成本：每年50万元
|
||||
- AI开发成本：10万元，3个月回本
|
||||
|
||||
❌ 低频次失败案例：年会报名系统
|
||||
- 每年使用1次
|
||||
- 处理量：500人次
|
||||
- AI开发成本：5万元
|
||||
- 人工成本：500元（临时工）
|
||||
```
|
||||
|
||||
### 第二招：复杂度测试 - 评估任务复杂度
|
||||
|
||||
**核心问题：**解决这个问题需要考虑多少因素？
|
||||
|
||||
**测试方法：**
|
||||
```
|
||||
多因素综合判断（5+个因素）→ ✅ 适合AI
|
||||
中等复杂度（2-4个因素）→ ⚠️ 需要进一步评估
|
||||
简单判断（1个因素）→ ❌ 不适合AI
|
||||
```
|
||||
|
||||
**复杂度评估维度：**
|
||||
|
||||
**高复杂度（适合AI）：**
|
||||
- **数据维度多**：需要综合5个以上数据源
|
||||
- **逻辑复杂**：存在多层嵌套的判断逻辑
|
||||
- **非线性关系**：因素之间存在复杂的相互作用
|
||||
- **模糊边界**：存在大量边界情况和例外处理
|
||||
|
||||
**中等复杂度（谨慎评估）：**
|
||||
- **数据维度适中**：2-4个主要数据源
|
||||
- **逻辑相对清晰**：可以用流程图表示
|
||||
- **部分规则明确**：存在一些明确的判断规则
|
||||
- **边界情况较少**：大部分情况有标准处理方式
|
||||
|
||||
**低复杂度（不适合AI）：**
|
||||
- **单一数据源**：只需要一个数据源
|
||||
- **线性逻辑**：简单的if-else判断
|
||||
- **规则明确**：可以用明确的数值或条件判断
|
||||
- **无边界情况**：所有情况都有确定的处理方式
|
||||
|
||||
**实际案例：**
|
||||
```
|
||||
✅ 高复杂度成功案例：订单风险评估
|
||||
复杂度分析：
|
||||
- 数据源：用户信息、订单信息、行为数据、外部数据（4类）
|
||||
- 判断逻辑：20+个风险因子，复杂的权重计算
|
||||
- 非线性关系：因子之间存在相互作用
|
||||
- 边界情况：大量的例外处理和特殊场景
|
||||
结果：AI准确率90%，规则引擎只有70%
|
||||
|
||||
❌ 低复杂度失败案例：库存预警系统
|
||||
复杂度分析：
|
||||
- 单一数据源：库存数量
|
||||
- 简单逻辑：库存<阈值→预警
|
||||
- 规则明确：阈值可以精确计算
|
||||
- 无边界情况：所有情况都有确定处理
|
||||
结果：AI开发2周，准确率95%；规则开发1天，准确率100%
|
||||
```
|
||||
|
||||
### 第三招：容错测试 - 评估错误容忍度
|
||||
|
||||
**核心问题：**偶尔判断错误可以接受吗？
|
||||
|
||||
**测试方法：**
|
||||
```
|
||||
高容错（错误率<5%可接受）→ ✅ 适合AI
|
||||
中等容错（错误率<2%可接受）→ ⚠️ 需要进一步评估
|
||||
低容错（错误率<1%要求）→ ❌ 不适合AI
|
||||
零容忍（不能有任何错误）→ ❌ 绝对不适合
|
||||
```
|
||||
|
||||
**容错度评估标准：**
|
||||
|
||||
**高容错场景（适合AI）：**
|
||||
- **错误成本较低**：单次错误损失小于100元
|
||||
- **可纠正性强**：错误可以被快速发现和纠正
|
||||
- **影响范围小**：错误只影响个别用户或订单
|
||||
- **有兜底机制**：有人工审核或二次确认机制
|
||||
|
||||
**中等容错场景（谨慎评估）：**
|
||||
- **错误成本中等**：单次错误损失100-1000元
|
||||
- **纠正成本适中**：需要一定成本来纠正错误
|
||||
- **影响范围有限**：错误影响局部业务流程
|
||||
- **部分兜底**：有部分检查或验证机制
|
||||
|
||||
**低容错场景（不适合AI）：**
|
||||
- **错误成本高**：单次错误损失超过1000元
|
||||
- **难以纠正**：错误一旦产生很难挽回
|
||||
- **影响范围大**：错误会影响整个业务流程
|
||||
- **无兜底机制**：没有其他检查或验证手段
|
||||
|
||||
**零容忍场景（绝对不适合）：**
|
||||
- **涉及安全风险**：错误可能导致安全事故
|
||||
- **法律合规要求**：必须符合严格的法律法规
|
||||
- **影响生命安全**：如医疗、交通等关键领域
|
||||
- **经济损失巨大**：单次错误可能导致巨额损失
|
||||
|
||||
**实际案例：**
|
||||
```
|
||||
✅ 高容错成功案例：商品推荐系统
|
||||
容错分析：
|
||||
- 错误成本：推荐错误只影响转化率，无直接损失
|
||||
- 可纠正性：用户可以选择忽略推荐
|
||||
- 影响范围：只影响个别用户的体验
|
||||
- 兜底机制：用户可以通过搜索找到想要的商品
|
||||
结果：即使推荐准确率只有80%，业务效果仍然显著
|
||||
|
||||
❌ 零容忍失败案例：银行转账风控
|
||||
容错分析：
|
||||
- 错误成本：误判可能导致客户无法及时转账，损失巨大
|
||||
- 难以纠正：误判会影响客户信任和满意度
|
||||
- 影响范围：可能影响客户的重大资金安排
|
||||
- 零容忍：银行不能承担误判带来的风险
|
||||
结果：AI无法达到银行的严格要求
|
||||
```
|
||||
|
||||
## 💡 我们的三个场景，怎么判断的？
|
||||
|
||||
### 场景一：订单诊断系统
|
||||
|
||||
**场景背景：**
|
||||
某电商平台的订单系统经常出现各种异常，研发同学每天需要花费大量时间排查问题。订单中断时，对研发同学的打断较为频繁，严重影响开发效率。
|
||||
|
||||
**三招测试结果：**
|
||||
|
||||
**频次测试：✅ 高频次**
|
||||
- 每日异常订单：500+单
|
||||
- 每个订单平均排查时间：15分钟
|
||||
- 研发人员每日被打断：20+次
|
||||
- 年度处理成本：超过30万元
|
||||
|
||||
**复杂度测试：✅ 高复杂度**
|
||||
- 需要查看订单金额、流水信息、用户信息、商品信息、支付状态、物流状态等多个维度
|
||||
- 异常类型包括20+种，每种都有不同的排查逻辑
|
||||
- 各系统之间的数据关联复杂，需要综合分析
|
||||
- 存在大量的边界情况和特殊场景
|
||||
|
||||
**容错测试：✅ 中等容错**
|
||||
- 诊断错误不会直接影响用户体验（只是排查方向错误）
|
||||
- 可以结合人工经验进行二次确认
|
||||
- 错误成本主要是时间成本，不会导致直接经济损失
|
||||
- 有兜底机制：复杂的异常可以升级给高级工程师处理
|
||||
|
||||
**综合评估：✅ 非常适合AI**
|
||||
```
|
||||
AI解决方案：
|
||||
输入：订单号、异常现象描述、相关系统日志
|
||||
处理：
|
||||
1. 自动收集订单相关数据
|
||||
2. 分析异常模式和可能原因
|
||||
3. 给出排查建议和处理方案
|
||||
4. 预测处理时间和难度
|
||||
输出：异常原因分析、排查步骤、处理建议、预计耗时
|
||||
|
||||
预期效果：
|
||||
- 排查时间：从15分钟缩短到3分钟
|
||||
- 准确率：达到85%以上
|
||||
- 研发效率：提升30%
|
||||
- 客户满意度：异常处理时间缩短50%
|
||||
```
|
||||
|
||||
### 场景二：商品分析系统
|
||||
|
||||
**场景背景：**
|
||||
在供应链管理中，经常需要从下游商品追踪到上游商品，分析商品之间的关系和影响。这个过程通常需要2-3步的推理，商品名称模糊时需要更多步骤。
|
||||
|
||||
**三招测试结果：**
|
||||
|
||||
**频次测试：✅ 中高频次**
|
||||
- 每日分析需求：100+次
|
||||
- 每次分析平均时间：20分钟
|
||||
- 涉及人员：采购、运营、分析师等
|
||||
- 年度人力成本：超过15万元
|
||||
|
||||
**复杂度测试：✅ 高复杂度**
|
||||
- 需要从下游商品追踪到上游商品，涉及多层级关系
|
||||
- 商品名称存在同义词、缩写、别名等情况
|
||||
- 需要考虑商品的属性、规格、用途等多个维度
|
||||
- 供应链关系复杂，存在替代、互补等多种关系
|
||||
|
||||
**容错测试：✅ 高容错**
|
||||
- 分析错误不会直接导致业务损失
|
||||
- 可以结合业务经验进行验证和调整
|
||||
- 主要是时间成本，没有直接的经济损失
|
||||
- 有兜底机制：复杂的分析可以人工介入
|
||||
|
||||
**综合评估：✅ 适合AI**
|
||||
```
|
||||
AI解决方案：
|
||||
输入：目标商品信息、分析目的、约束条件
|
||||
处理：
|
||||
1. 理解商品特征和关系
|
||||
2. 构建商品知识图谱
|
||||
3. 进行多步推理分析
|
||||
4. 识别关键影响因素
|
||||
输出：商品关系图谱、分析结论、关键路径、风险提示
|
||||
|
||||
预期效果：
|
||||
- 分析时间：从20分钟缩短到2分钟
|
||||
- 分析深度：能够发现人工难以察觉的关系
|
||||
- 准确率：达到80%以上
|
||||
- 决策效率：提升40%
|
||||
```
|
||||
|
||||
### 场景三：文库问答系统
|
||||
|
||||
**场景背景：**
|
||||
人事和研发同学经常被问到相同的问题，需要反复从大量文档中查找答案。这些问题大多已经在文档中有明确说明，但查找过程耗时。
|
||||
|
||||
**三招测试结果：**
|
||||
|
||||
**频次测试：✅ 高频次**
|
||||
- 每日问答需求：200+次
|
||||
- 每次查找平均时间：10分钟
|
||||
- 涉及人员：人事、研发、行政等多个部门
|
||||
- 年度人力成本：超过25万元
|
||||
|
||||
**复杂度测试：✅ 中等复杂度**
|
||||
- 需要从大量文档中找到准确答案
|
||||
- 问题类型多样，包括政策、流程、技术等多个领域
|
||||
- 文档格式不统一，有PDF、Word、网页等多种形式
|
||||
- 需要理解问题的语义和上下文
|
||||
|
||||
**容错测试：✅ 高容错**
|
||||
- 回答错误可以及时纠正和澄清
|
||||
- 用户可以继续追问或寻求人工帮助
|
||||
- 主要是效率问题，不会导致直接损失
|
||||
- 有兜底机制：复杂问题可以转人工处理
|
||||
|
||||
**综合评估：✅ 非常适合AI**
|
||||
```
|
||||
AI解决方案：
|
||||
输入：用户问题、文档库、历史问答记录
|
||||
处理：
|
||||
1. 理解问题意图和关键信息
|
||||
2. 在文档库中搜索相关内容
|
||||
3. 提取准确的答案和依据
|
||||
4. 生成简洁明了的回答
|
||||
输出：准确答案、相关文档链接、扩展信息、置信度评分
|
||||
|
||||
预期效果：
|
||||
- 响应时间：从10分钟缩短到30秒
|
||||
- 准确率：达到85%以上
|
||||
- 覆盖率：能够回答90%的常见问题
|
||||
- 员工满意度：提升50%
|
||||
```
|
||||
|
||||
## 总结：需求识别的黄金法则
|
||||
|
||||
通过系统性的三招测试，我们可以建立一个科学的AI需求评估框架：
|
||||
|
||||
### 1. 频次优先原则
|
||||
**高频次是AI应用成功的基础**。只有足够的使用频次，才能摊销AI开发的高昂成本，实现投资回报。在评估AI项目时，**优先考虑高频次场景**。
|
||||
|
||||
### 2. 复杂度匹配原则
|
||||
**复杂度决定AI的价值空间**。过于简单的任务用传统方法更高效，过于复杂的任务AI可能无法胜任。**选择AI能够显著提升效率的中高复杂度场景**。
|
||||
|
||||
### 3. 容错度平衡原则
|
||||
**容错度决定AI的可行性**。AI不是万能的，必然存在错误率。**选择能够接受AI错误率的场景，或者建立有效的错误控制机制**。
|
||||
|
||||
### 4. 综合评估原则
|
||||
**三个测试必须同时通过**。频次、复杂度、容错度三者缺一不可。即使某个方面表现很好，如果其他方面不达标，也要谨慎考虑。
|
||||
|
||||
### 5. 渐进式实施原则
|
||||
**从简单场景开始，逐步扩展**。不要一开始就选择最复杂的场景，而是先从相对简单、成功率高的场景入手，积累经验和信心，再逐步扩展到更复杂的场景。
|
||||
|
||||
记住：**选择比努力更重要**。在AI项目中，选择合适的场景比技术实现更重要。通过科学的需求识别，我们可以显著提高AI项目的成功率，真正实现AI技术的业务价值。
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,620 +0,0 @@
|
|||
用户界面层
|
||||
├── Web界面：Streamlit构建的交互界面
|
||||
├── API接口：FastAPI提供的RESTful API
|
||||
└── 管理后台：Flask构建的管理界面
|
||||
|
||||
业务逻辑层
|
||||
├── 问答引擎：LangChain核心逻辑
|
||||
├── 文档处理：文档解析和向量化
|
||||
├── 检索系统：向量检索和重排序
|
||||
└── 对话管理：多轮对话状态管理
|
||||
|
||||
数据存储层
|
||||
├── 向量数据库：ChromaDB存储文档向量
|
||||
├── 关系数据库：PostgreSQL存储元数据
|
||||
├── 文件存储：MinIO存储原始文档
|
||||
└── 缓存系统：Redis缓存热点数据
|
||||
|
||||
模型服务层
|
||||
├── 嵌入模型：text-embedding-ada-002
|
||||
├── 大语言模型：gpt-3.5-turbo
|
||||
├── 重排序模型：bge-reranker-base
|
||||
└── 摘要模型：gpt-3.5-turbo
|
||||
|
||||
前端架构设计
|
||||
|
||||
**技术栈选择：**
|
||||
```
|
||||
前端框架：
|
||||
├── Vue 3.3：组合式API，更好的TypeScript支持
|
||||
├── TypeScript 5：类型安全，开发体验好
|
||||
├── Vite 4：快速的构建工具，开发体验极佳
|
||||
└── Vue Router 4：路由管理，支持历史模式
|
||||
|
||||
UI组件库：
|
||||
├── Element Plus：企业级UI组件库
|
||||
├── Tailwind CSS：实用优先的CSS框架
|
||||
├── Iconify：丰富的图标库
|
||||
└── VueUse：实用的Vue组合式函数库
|
||||
|
||||
AI交互：
|
||||
├── SSE支持：Server-Sent Events实时通信
|
||||
├── Markdown渲染：支持富文本展示
|
||||
├── 代码高亮：Prism.js代码语法高亮
|
||||
└── 文件上传：支持拖拽上传和进度显示
|
||||
|
||||
状态管理：
|
||||
├── Pinia：Vue官方状态管理库
|
||||
├── LocalStorage：本地数据持久化
|
||||
├── Session管理：用户会话状态管理
|
||||
└── 缓存策略：智能的API响应缓存
|
||||
```
|
||||
|
||||
**核心界面实现：**
|
||||
|
||||
#### 主聊天界面
|
||||
```vue
|
||||
<!-- ChatInterface.vue -->
|
||||
<template>
|
||||
<div class="chat-interface">
|
||||
<!-- 头部导航 -->
|
||||
<div class="chat-header">
|
||||
<div class="header-left">
|
||||
<el-icon class="header-icon"><ChatDotRound /></el-icon>
|
||||
<span class="header-title">智能文库助手</span>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<el-button
|
||||
type="text"
|
||||
:icon="Delete"
|
||||
@click="clearChat"
|
||||
class="clear-btn"
|
||||
>
|
||||
清空对话
|
||||
</el-button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- 聊天消息区域 -->
|
||||
<div class="chat-messages" ref="messagesContainer">
|
||||
<div
|
||||
v-for="(message, index) in messages"
|
||||
:key="index"
|
||||
:class="['message-wrapper', message.role]"
|
||||
>
|
||||
<!-- 用户消息 -->
|
||||
<div v-if="message.role === 'user'" class="user-message">
|
||||
<div class="message-content">
|
||||
<div class="message-text">{{ message.content }}</div>
|
||||
<div class="message-time">{{ formatTime(message.timestamp) }}</div>
|
||||
</div>
|
||||
<div class="message-avatar">
|
||||
<el-icon><UserFilled /></el-icon>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- AI回复消息 -->
|
||||
<div v-else class="ai-message">
|
||||
<div class="message-avatar">
|
||||
<el-icon><ChatLineRound /></el-icon>
|
||||
</div>
|
||||
<div class="message-content">
|
||||
<!-- 消息文本 -->
|
||||
<div class="message-text" v-html="renderMarkdown(message.content)"></div>
|
||||
|
||||
<!-- 加载状态 -->
|
||||
<div v-if="message.isLoading" class="loading-indicator">
|
||||
<el-icon class="is-loading"><Loading /></el-icon>
|
||||
<span>正在思考中...</span>
|
||||
</div>
|
||||
|
||||
<!-- 错误状态 -->
|
||||
<div v-if="message.error" class="error-message">
|
||||
<el-icon><Warning /></el-icon>
|
||||
<span>{{ message.error }}</span>
|
||||
</div>
|
||||
|
||||
<!-- 消息来源 -->
|
||||
<div v-if="message.sources && message.sources.length > 0" class="message-sources">
|
||||
<div class="sources-title">参考文档：</div>
|
||||
<div
|
||||
v-for="(source, sourceIndex) in message.sources"
|
||||
:key="sourceIndex"
|
||||
class="source-item"
|
||||
@click="viewSource(source)"
|
||||
>
|
||||
<el-icon><Document /></el-icon>
|
||||
<span class="source-name">{{ source.name }}</span>
|
||||
<span class="source-score">相似度: {{ (source.score * 100).toFixed(1) }}%</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- 消息时间 -->
|
||||
<div class="message-time">{{ formatTime(message.timestamp) }}</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- 输入区域 -->
|
||||
<div class="chat-input">
|
||||
<div class="input-wrapper">
|
||||
<el-input
|
||||
v-model="inputMessage"
|
||||
type="textarea"
|
||||
:rows="2"
|
||||
placeholder="请输入您的问题..."
|
||||
class="message-input"
|
||||
@keydown="handleKeydown"
|
||||
:disabled="isSending"
|
||||
/>
|
||||
<div class="input-actions">
|
||||
<el-upload
|
||||
class="file-upload"
|
||||
action="/api/documents/upload"
|
||||
:show-file-list="false"
|
||||
:on-success="handleUploadSuccess"
|
||||
:before-upload="beforeUpload"
|
||||
accept=".pdf,.txt,.doc,.docx"
|
||||
>
|
||||
<el-button type="text" :icon="Paperclip" :disabled="isSending">
|
||||
上传文档
|
||||
</el-button>
|
||||
</el-upload>
|
||||
<el-button
|
||||
type="primary"
|
||||
:icon="Position"
|
||||
@click="sendMessage"
|
||||
:loading="isSending"
|
||||
:disabled="!inputMessage.trim()"
|
||||
class="send-button"
|
||||
>
|
||||
发送
|
||||
</el-button>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script setup lang="ts">
|
||||
import { ref, nextTick, onMounted } from 'vue'
|
||||
import { ElMessage } from 'element-plus'
|
||||
import {
|
||||
ChatDotRound, Delete, UserFilled, ChatLineRound,
|
||||
Loading, Warning, Document, Paperclip, Position
|
||||
} from '@element-plus/icons-vue'
|
||||
import { marked } from 'marked'
|
||||
import DOMPurify from 'dompurify'
|
||||
import hljs from 'highlight.js'
|
||||
import 'highlight.js/styles/github.css'
|
||||
|
||||
// 消息接口
|
||||
interface Message {
|
||||
role: 'user' | 'assistant'
|
||||
content: string
|
||||
timestamp: Date
|
||||
isLoading?: boolean
|
||||
error?: string
|
||||
sources?: DocumentSource[]
|
||||
}
|
||||
|
||||
// 文档来源接口
|
||||
interface DocumentSource {
|
||||
id: string
|
||||
name: string
|
||||
score: number
|
||||
content?: string
|
||||
}
|
||||
|
||||
// 响应式数据
|
||||
const messages = ref<Message[]>([])
|
||||
const inputMessage = ref('')
|
||||
const isSending = ref(false)
|
||||
const messagesContainer = ref<HTMLElement>()
|
||||
|
||||
// 初始化marked配置
|
||||
marked.setOptions({
|
||||
highlight: function(code, lang) {
|
||||
if (lang && hljs.getLanguage(lang)) {
|
||||
return hljs.highlight(code, { language: lang }).value
|
||||
}
|
||||
return hljs.highlightAuto(code).value
|
||||
},
|
||||
langPrefix: 'hljs language-',
|
||||
breaks: true,
|
||||
gfm: true
|
||||
})
|
||||
|
||||
// Markdown渲染函数
|
||||
const renderMarkdown = (content: string): string => {
|
||||
const rawHtml = marked(content)
|
||||
const cleanHtml = DOMPurify.sanitize(rawHtml)
|
||||
return cleanHtml
|
||||
}
|
||||
|
||||
// 格式化时间
|
||||
const formatTime = (timestamp: Date): string => {
|
||||
const now = new Date()
|
||||
const diff = now.getTime() - timestamp.getTime()
|
||||
const minutes = Math.floor(diff / 60000)
|
||||
|
||||
if (minutes < 1) return '刚刚'
|
||||
if (minutes < 60) return `${minutes}分钟前`
|
||||
|
||||
const hours = Math.floor(minutes / 60)
|
||||
if (hours < 24) return `${hours}小时前`
|
||||
|
||||
return timestamp.toLocaleString()
|
||||
}
|
||||
|
||||
// 发送消息
|
||||
const sendMessage = async () => {
|
||||
if (!inputMessage.value.trim() || isSending.value) return
|
||||
|
||||
const userMessage = inputMessage.value.trim()
|
||||
inputMessage.value = ''
|
||||
|
||||
// 添加用户消息
|
||||
messages.value.push({
|
||||
role: 'user',
|
||||
content: userMessage,
|
||||
timestamp: new Date()
|
||||
})
|
||||
|
||||
// 添加AI回复占位
|
||||
const aiMessage: Message = {
|
||||
role: 'assistant',
|
||||
content: '',
|
||||
timestamp: new Date(),
|
||||
isLoading: true
|
||||
}
|
||||
messages.value.push(aiMessage)
|
||||
|
||||
isSending.value = true
|
||||
|
||||
try {
|
||||
// 调用AI服务
|
||||
const response = await fetch('/api/chat/stream', {
|
||||
method: 'POST',
|
||||
headers: {
|
||||
'Content-Type': 'application/json',
|
||||
},
|
||||
body: JSON.stringify({
|
||||
message: userMessage,
|
||||
history: messages.value.slice(-10).map(msg => ({
|
||||
role: msg.role,
|
||||
content: msg.content
|
||||
}))
|
||||
})
|
||||
})
|
||||
|
||||
if (!response.ok) {
|
||||
throw new Error(`HTTP error! status: ${response.status}`)
|
||||
}
|
||||
|
||||
// 处理SSE流式响应
|
||||
const reader = response.body?.getReader()
|
||||
const decoder = new TextDecoder()
|
||||
let aiContent = ''
|
||||
let sources: DocumentSource[] = []
|
||||
|
||||
if (reader) {
|
||||
while (true) {
|
||||
const { done, value } = await reader.read()
|
||||
if (done) break
|
||||
|
||||
const chunk = decoder.decode(value)
|
||||
const lines = chunk.split('\n')
|
||||
|
||||
for (const line of lines) {
|
||||
if (line.startsWith('data: ')) {
|
||||
const data = line.slice(6)
|
||||
if (data === '[DONE]') {
|
||||
aiMessage.isLoading = false
|
||||
break
|
||||
}
|
||||
|
||||
try {
|
||||
const parsed = JSON.parse(data)
|
||||
if (parsed.type === 'content') {
|
||||
aiContent += parsed.content
|
||||
aiMessage.content = aiContent
|
||||
} else if (parsed.type === 'sources') {
|
||||
sources = parsed.sources
|
||||
aiMessage.sources = sources
|
||||
}
|
||||
} catch (e) {
|
||||
console.error('Parse error:', e)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// 滚动到底部
|
||||
await nextTick()
|
||||
scrollToBottom()
|
||||
}
|
||||
}
|
||||
|
||||
} catch (error) {
|
||||
console.error('Chat error:', error)
|
||||
aiMessage.error = error instanceof Error ? error.message : '发送消息失败'
|
||||
aiMessage.isLoading = false
|
||||
} finally {
|
||||
isSending.value = false
|
||||
}
|
||||
}
|
||||
|
||||
// 处理键盘事件
|
||||
const handleKeydown = (event: KeyboardEvent) => {
|
||||
if (event.key === 'Enter' && !event.shiftKey) {
|
||||
event.preventDefault()
|
||||
sendMessage()
|
||||
}
|
||||
}
|
||||
|
||||
// 滚动到底部
|
||||
const scrollToBottom = () => {
|
||||
nextTick(() => {
|
||||
if (messagesContainer.value) {
|
||||
messagesContainer.value.scrollTop = messagesContainer.value.scrollHeight
|
||||
}
|
||||
})
|
||||
}
|
||||
|
||||
// 清空对话
|
||||
const clearChat = () => {
|
||||
messages.value = []
|
||||
ElMessage.success('对话已清空')
|
||||
}
|
||||
|
||||
// 查看文档源
|
||||
const viewSource = (source: DocumentSource) => {
|
||||
// 实现查看文档详情的逻辑
|
||||
console.log('View source:', source)
|
||||
}
|
||||
|
||||
// 文件上传处理
|
||||
const beforeUpload = (file: File) => {
|
||||
const isAllowedType = ['application/pdf', 'text/plain', 'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'].includes(file.type)
|
||||
const isLt10M = file.size / 1024 / 1024 < 10
|
||||
|
||||
if (!isAllowedType) {
|
||||
ElMessage.error('只能上传 PDF、TXT、Word 文档!')
|
||||
return false
|
||||
}
|
||||
if (!isLt10M) {
|
||||
ElMessage.error('文档大小不能超过 10MB!')
|
||||
return false
|
||||
}
|
||||
return true
|
||||
}
|
||||
|
||||
const handleUploadSuccess = (response: any) => {
|
||||
ElMessage.success('文档上传成功')
|
||||
// 可以添加刷新文档列表等逻辑
|
||||
}
|
||||
|
||||
// 初始化
|
||||
onMounted(() => {
|
||||
// 添加欢迎消息
|
||||
messages.value.push({
|
||||
role: 'assistant',
|
||||
content: '您好！我是智能文库助手，可以帮助您快速查找公司文档中的信息。请问有什么可以帮助您的吗？',
|
||||
timestamp: new Date()
|
||||
})
|
||||
})
|
||||
</script>
|
||||
|
||||
<style scoped>
|
||||
.chat-interface {
|
||||
height: 100vh;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
background-color: #f5f5f5;
|
||||
}
|
||||
|
||||
.chat-header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
padding: 16px 24px;
|
||||
background-color: #fff;
|
||||
border-bottom: 1px solid #e0e0e0;
|
||||
box-shadow: 0 2px 4px rgba(0,0,0,0.05);
|
||||
}
|
||||
|
||||
.header-left {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 12px;
|
||||
}
|
||||
|
||||
.header-icon {
|
||||
font-size: 24px;
|
||||
color: #409eff;
|
||||
}
|
||||
|
||||
.header-title {
|
||||
font-size: 18px;
|
||||
font-weight: 500;
|
||||
color: #303133;
|
||||
}
|
||||
|
||||
.header-right {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.clear-btn {
|
||||
color: #909399;
|
||||
}
|
||||
|
||||
.clear-btn:hover {
|
||||
color: #409eff;
|
||||
}
|
||||
|
||||
.chat-messages {
|
||||
flex: 1;
|
||||
overflow-y: auto;
|
||||
padding: 24px;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.message-wrapper {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.message-wrapper.user {
|
||||
align-items: flex-end;
|
||||
}
|
||||
|
||||
.message-wrapper.assistant {
|
||||
align-items: flex-start;
|
||||
}
|
||||
|
||||
.user-message {
|
||||
display: flex;
|
||||
align-items: flex-start;
|
||||
gap: 12px;
|
||||
max-width: 70%;
|
||||
}
|
||||
|
||||
.ai-message {
|
||||
display: flex;
|
||||
align-items: flex-start;
|
||||
gap: 12px;
|
||||
max-width: 70%;
|
||||
}
|
||||
|
||||
.message-avatar {
|
||||
width: 36px;
|
||||
height: 36px;
|
||||
border-radius: 50%;
|
||||
background-color: #409eff;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
color: white;
|
||||
font-size: 18px;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.message-wrapper.assistant .message-avatar {
|
||||
background-color: #67c23a;
|
||||
}
|
||||
|
||||
.message-content {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.message-text {
|
||||
background-color: #fff;
|
||||
padding: 12px 16px;
|
||||
border-radius: 8px;
|
||||
box-shadow: 0 2px 4px rgba(0,0,0,0.1);
|
||||
line-height: 1.6;
|
||||
word-wrap: break-word;
|
||||
}
|
||||
|
||||
.user-message .message-text {
|
||||
background-color: #409eff;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.message-time {
|
||||
font-size: 12px;
|
||||
color: #909399;
|
||||
margin-top: 4px;
|
||||
}
|
||||
|
||||
.loading-indicator {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
color: #909399;
|
||||
font-size: 14px;
|
||||
margin-top: 8px;
|
||||
}
|
||||
|
||||
.error-message {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
color: #f56c6c;
|
||||
font-size: 14px;
|
||||
margin-top: 8px;
|
||||
}
|
||||
|
||||
.message-sources {
|
||||
margin-top: 12px;
|
||||
padding: 12px;
|
||||
background-color: #f5f7fa;
|
||||
border-radius: 6px;
|
||||
border-left: 4px solid #409eff;
|
||||
}
|
||||
|
||||
.sources-title {
|
||||
font-size: 14px;
|
||||
font-weight: 500;
|
||||
color: #303133;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
.source-item {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
padding: 8px 12px;
|
||||
background-color: white;
|
||||
border-radius: 4px;
|
||||
margin-bottom: 6px;
|
||||
cursor: pointer;
|
||||
transition: all 0.3s ease;
|
||||
}
|
||||
|
||||
.source-item:hover {
|
||||
background-color: #ecf5ff;
|
||||
transform: translateX(4px);
|
||||
}
|
||||
|
||||
.source-item:last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
.source-name {
|
||||
flex: 1;
|
||||
font-size: 14px;
|
||||
color: #303133;
|
||||
}
|
||||
|
||||
.source-score {
|
||||
font-size: 12px;
|
||||
color: #67c23a;
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
.chat-input {
|
||||
padding: 24px;
|
||||
background-color: #fff;
|
||||
border-top: 1px solid #e0e0e0;
|
||||
}
|
||||
|
||||
.input-wrapper {
|
||||
max-width: 800px;
|
||||
margin: 0 auto;
|
||||
}
|
||||
|
||||
.message-input {
|
||||
margin-bottom: 12px;
|
||||
}
|
||||
|
||||
.message-input :deep(textarea) {
|
||||
font-size: 16px;
|
||||
line-height: 1
|
||||
|
|
@ -1,326 +0,0 @@
|
|||
# AI应用工业化：从智能体到流水线的落地实战
|
||||
|
||||
## 最终版完整规划
|
||||
|
||||
## 1. 项目概述
|
||||
|
||||
本项目旨在通过技术分享展示AI应用的工业化落地实践，以智能客服机器人为核心业务场景，对比LangChain和Eino两种技术方案的实现差异，帮助技术团队理解从Demo到生产级应用的工程化思维转变。
|
||||
|
||||
### 核心业务场景
|
||||
|
||||
* **用户意图判断**：自动识别订单诊断、知识问答、其它对话三大类
|
||||
|
||||
* **订单诊断**：订单号输入 → API调用 → 状态检查 → 日志分析 → 解决方案
|
||||
|
||||
* **知识问答**：基于RAG的智能问答系统
|
||||
|
||||
* **自然对话**：通用对话处理和兜底机制
|
||||
|
||||
### 技术对比重点
|
||||
|
||||
* **LangChain方案**：快速原型开发，灵活性强，适合快速验证
|
||||
|
||||
* **Eino方案**：配置驱动，工业化程度高，适合生产环境
|
||||
|
||||
* **前端展示**：Vue3 H5页面，支持流式输出和多会话管理
|
||||
|
||||
## 2. 项目目录结构
|
||||
|
||||
```
|
||||
courseware/
|
||||
├── 课件资料/ # 分享材料和文档
|
||||
│ ├── 技术分享PPT.pptx # 主要演示文稿
|
||||
│ ├── 业务场景说明.md # 客服机器人业务逻辑
|
||||
│ ├── 预设问答.md # Q&A环节准备材料
|
||||
│ └── 演示脚本.md # 分享流程和要点
|
||||
│
|
||||
├── langchain-project/ # LangChain技术方案
|
||||
│ ├── src/
|
||||
│ │ ├── agents/ # 智能体模块
|
||||
│ │ │ ├── intent_classifier.py # 意图识别智能体
|
||||
│ │ │ ├── order_diagnostic.py # 订单诊断智能体
|
||||
│ │ │ ├── knowledge_qa.py # 知识问答智能体
|
||||
│ │ │ └── chat_manager.py # 对话管理智能体
|
||||
│ │ ├── tools/ # 工具集成
|
||||
│ │ │ ├── order_api.py # 订单系统API
|
||||
│ │ │ ├── log_analyzer.py # 日志分析工具
|
||||
│ │ │ └── knowledge_base.py # 知识库检索
|
||||
│ │ ├── api/ # API接口层
|
||||
│ │ │ ├── main.py # FastAPI主程序
|
||||
│ │ │ ├── routes.py # 路由定义
|
||||
│ │ │ └── models.py # 数据模型
|
||||
│ │ └── config/ # 配置文件
|
||||
│ │ ├── settings.py # 应用配置
|
||||
│ │ └── prompts.py # Prompt模板
|
||||
│ ├── requirements.txt # Python依赖
|
||||
│ ├── docker-compose.yml # 容器编排
|
||||
│ └── README.md # 项目说明
|
||||
│
|
||||
├── eino-project/ # Eino技术方案
|
||||
│ ├── configs/ # 流水线配置
|
||||
│ │ ├── intent_pipeline.yaml # 意图识别流水线
|
||||
│ │ ├── order_pipeline.yaml # 订单诊断流水线
|
||||
│ │ ├── qa_pipeline.yaml # 知识问答流水线
|
||||
│ │ └── chat_pipeline.yaml # 对话管理流水线
|
||||
│ ├── src/
|
||||
│ │ ├── components/ # 自定义组件
|
||||
│ │ │ ├── order_fetcher.py # 订单数据获取
|
||||
│ │ │ ├── log_processor.py # 日志处理组件
|
||||
│ │ │ └── response_formatter.py # 响应格式化
|
||||
│ │ ├── api/ # API服务
|
||||
│ │ │ ├── server.py # Eino API服务
|
||||
│ │ │ └── handlers.py # 请求处理器
|
||||
│ │ └── monitoring/ # 监控配置
|
||||
│ │ └── coze_loop_config.yaml # Coze-Loop监控配置
|
||||
│ ├── docker-compose.yml # 容器编排
|
||||
│ └── README.md # 项目说明
|
||||
│
|
||||
└── vue3-frontend/ # Vue3前端项目
|
||||
├── src/
|
||||
│ ├── components/ # 组件库
|
||||
│ │ ├── ChatWindow.vue # 聊天窗口组件
|
||||
│ │ ├── MessageList.vue # 消息列表组件
|
||||
│ │ ├── InputBox.vue # 输入框组件
|
||||
│ │ └── SessionTabs.vue # 会话标签组件
|
||||
│ ├── views/ # 页面视图
|
||||
│ │ ├── ChatPage.vue # 主聊天页面
|
||||
│ │ └── SettingsPage.vue # 设置页面
|
||||
│ ├── services/ # 服务层
|
||||
│ │ ├── api.js # API调用封装
|
||||
│ │ ├── websocket.js # WebSocket连接
|
||||
│ │ └── storage.js # 本地存储管理
|
||||
│ ├── stores/ # 状态管理
|
||||
│ │ ├── chat.js # 聊天状态
|
||||
│ │ └── session.js # 会话管理
|
||||
│ ├── utils/ # 工具函数
|
||||
│ │ ├── stream.js # 流式输出处理
|
||||
│ │ └── format.js # 消息格式化
|
||||
│ ├── styles/ # 样式文件
|
||||
│ │ ├── chat.scss # 聊天界面样式
|
||||
│ │ └── mobile.scss # 移动端适配
|
||||
│ ├── App.vue # 根组件
|
||||
│ └── main.js # 入口文件
|
||||
├── public/ # 静态资源
|
||||
├── package.json # 项目配置
|
||||
├── vite.config.js # Vite配置
|
||||
└── README.md # 项目说明
|
||||
```
|
||||
|
||||
## 3. 技术分享大纲（60分钟）
|
||||
|
||||
### 【开场震撼】（5分钟）
|
||||
|
||||
* **30秒实时Demo**：展示完整的客服机器人对话流程
|
||||
|
||||
* **效率对比**：传统人工处理 vs AI自动化处理的时间差异
|
||||
|
||||
* **痛点共鸣**：为什么大多数AI项目都死在Demo阶段？
|
||||
|
||||
### 【Part 1：认知升级】（10分钟）
|
||||
|
||||
#### 失败案例分析（5分钟）
|
||||
|
||||
* **过度依赖Prompt**：手工调试，无法规模化
|
||||
|
||||
* **缺乏异常处理**：遇到边界情况就崩溃
|
||||
|
||||
* **没有监控体系**：黑盒运行，问题无法追踪
|
||||
|
||||
* **架构不合理**：单体应用，难以维护和扩展
|
||||
|
||||
#### 工业化思维转变（5分钟）
|
||||
|
||||
```
|
||||
手工时代 → 智能体时代 → 工业化时代
|
||||
↓ ↓ ↓
|
||||
Prompt Agent Pipeline
|
||||
单点尝试 协作执行 标准化生产
|
||||
```
|
||||
|
||||
### 【Part 2：技术架构对比】（20分钟）
|
||||
|
||||
#### LangChain方案展示（10分钟）
|
||||
|
||||
* **智能体设计模式**：4个专业智能体协作
|
||||
|
||||
* **现场Demo**：订单诊断完整流程演示
|
||||
|
||||
* **代码展示**：核心智能体实现逻辑
|
||||
|
||||
* **监控方案**：LangSmith追踪和调试
|
||||
|
||||
#### Eino方案展示（10分钟）
|
||||
|
||||
* **流水线编排**：YAML配置驱动的处理流程
|
||||
|
||||
* **现场Demo**：相同功能的Eino实现
|
||||
|
||||
* **配置对比**：声明式 vs 编程式的差异
|
||||
|
||||
* **监控方案**：Coze-Loop性能监控
|
||||
|
||||
### 【Part 3：前端集成展示】（10分钟）
|
||||
|
||||
#### Vue3 H5客服页面（5分钟）
|
||||
|
||||
* **界面展示**：移动端适配的聊天界面
|
||||
|
||||
* **多会话管理**：支持多个对话窗口切换
|
||||
|
||||
* **流式输出**：实时显示AI回复过程
|
||||
|
||||
#### 双后端对接（5分钟）
|
||||
|
||||
* **API统一**：标准化的接口设计
|
||||
|
||||
* **性能对比**：LangChain vs Eino响应时间
|
||||
|
||||
* **切换演示**：前端无缝切换后端服务
|
||||
|
||||
### 【Part 4：工业化落地要点】（10分钟）
|
||||
|
||||
#### 技术选型决策（5分钟）
|
||||
|
||||
```
|
||||
业务场景 → 团队技术栈 → 预算考虑 → 推荐方案
|
||||
快速验证 + 小团队 + 低预算 → LangChain
|
||||
企业应用 + 大团队 + 充足预算 → Eino
|
||||
混合场景 + 技术团队 + 中等预算 → 双方案对比
|
||||
```
|
||||
|
||||
#### ROI分析实例（5分钟）
|
||||
|
||||
* **成本投入**：开发成本 + 运维成本 + 人力成本
|
||||
|
||||
* **效益产出**：效率提升 + 成本节约 + 用户体验改善
|
||||
|
||||
* **真实案例**：某电商客服系统改造，年化ROI 264%
|
||||
|
||||
### 【预设Q\&A】（5分钟）
|
||||
|
||||
#### 高频问题准备
|
||||
|
||||
1. **"如何评估AI项目的技术风险？"**
|
||||
|
||||
* 模型稳定性评估
|
||||
|
||||
* 数据安全和隐私保护
|
||||
|
||||
* 系统可用性保障
|
||||
|
||||
2. **"LangChain和Eino如何选择？"**
|
||||
|
||||
* 团队技术栈匹配度
|
||||
|
||||
* 项目复杂度和时间要求
|
||||
|
||||
* 长期维护成本考虑
|
||||
|
||||
3. **"如何处理AI回复的准确性问题？"**
|
||||
|
||||
* 多层质量检查机制
|
||||
|
||||
* 人工审核和反馈循环
|
||||
|
||||
* 持续优化和模型微调
|
||||
|
||||
4. **"生产环境部署需要注意什么？"**
|
||||
|
||||
* 负载均衡和高可用设计
|
||||
|
||||
* 监控告警和故障恢复
|
||||
|
||||
* 版本管理和灰度发布
|
||||
|
||||
5. **"如何量化AI项目的业务价值？"**
|
||||
|
||||
* 关键指标定义和追踪
|
||||
|
||||
* A/B测试和效果对比
|
||||
|
||||
* ROI计算和成本分析
|
||||
|
||||
## 4. Demo开发计划
|
||||
|
||||
### Demo 1：LangChain智能客服系统
|
||||
|
||||
**开发时间**：3天
|
||||
**核心功能**：
|
||||
|
||||
* 意图识别智能体：识别用户查询类型
|
||||
|
||||
* 订单诊断智能体：处理订单相关问题
|
||||
|
||||
* 知识问答智能体：基于RAG的问答系统
|
||||
|
||||
* 对话管理智能体：统筹整体对话流程
|
||||
|
||||
**技术栈**：
|
||||
|
||||
* Python 3.9+ + LangChain 0.1.x
|
||||
|
||||
* FastAPI + WebSocket
|
||||
|
||||
* ChromaDB（向量存储）
|
||||
|
||||
* LangSmith（监控追踪）
|
||||
|
||||
### Demo 2：Eino流水线系统
|
||||
|
||||
**开发时间**：2天
|
||||
**核心功能**：
|
||||
|
||||
* 配置驱动的处理流水线
|
||||
|
||||
* 相同的业务逻辑实现
|
||||
|
||||
* 声明式的组件编排
|
||||
|
||||
* Coze-Loop监控集成
|
||||
|
||||
**技术栈**：
|
||||
|
||||
* Eino Framework
|
||||
|
||||
* YAML配置文件
|
||||
|
||||
* Docker容器化部署
|
||||
|
||||
* Coze-Loop监控平台
|
||||
|
||||
### Demo 3：Vue3前端界面
|
||||
|
||||
**开发时间**：2天
|
||||
**核心功能**：
|
||||
|
||||
* H5移动端聊天界面
|
||||
|
||||
* 多会话管理和切换
|
||||
|
||||
* 流式输出实时显示
|
||||
|
||||
* 双后端API对接
|
||||
|
||||
**技术栈**：
|
||||
|
||||
* Vue 3 + Composition API
|
||||
|
||||
* Vite + TypeScript
|
||||
|
||||
* WebSocket + Server-Sent Events
|
||||
|
||||
* Tailwind CSS + 移动端适配
|
||||
|
||||
### 集成测试
|
||||
|
||||
**时间安排**：1天
|
||||
**测试内容**：
|
||||
|
||||
* 端到端业务流程验证
|
||||
|
||||
* 性能压力测试
|
||||
|
||||
* 异常情况处理测试
|
||||
|
||||
* 用户体验优化调整
|
||||
|
||||
419
课件资料/0.大纲.md
419
课件资料/0.大纲.md
|
|
@ -1,331 +1,88 @@
|
|||
# 总大纲：AI应用工业化（智能体与流水线实战）
|
||||
|
||||
## 【Part 0：概念澄清】（8分钟）
|
||||
|
||||
**核心问题**：
|
||||
什么是智能体？
|
||||
什么是工作流？
|
||||
为什么需要AI工业化？
|
||||
|
||||
### 🔄 **技术演进的三个时代**
|
||||
|
||||
**手工时代**（就像手工艺品）
|
||||
|
||||
- 每次都要重新写Prompt
|
||||
- 结果靠运气，质量不稳定
|
||||
- 一个人能做，但没法复制
|
||||
|
||||
例：7位定时任务表达式生成
|
||||
|
||||
**智能体时代**（像有了机器人助手）
|
||||
|
||||
- 能记住对话，会调用工具
|
||||
- 但每个助手都要单独训练
|
||||
- 还是作坊式生产，效率有限
|
||||
|
||||
例：查询天气
|
||||
|
||||
**工业化时代**（像现代工厂）
|
||||
|
||||
- 标准化流程，流水线作业
|
||||
- 质量可控，批量生产
|
||||
- 普通人也能操作，快速复制
|
||||
|
||||
例：直连天下AI助手
|
||||
|
||||
### 💡 **为什么要工业化？**
|
||||
|
||||
**从Demo到生产，差的不只是代码**
|
||||
|
||||
- **Demo**：跑通就行，出问题人工重启
|
||||
- **生产**：7×24小时，不能掉链子
|
||||
- **Demo**：一个人搞定，懂技术就行
|
||||
- **生产**：团队协作，业务技术都要懂
|
||||
|
||||
**工业化解决的核心问题**
|
||||
|
||||
✅ **标准化**：不是每个项目都从零开始
|
||||
✅ **可维护**：出了问题能快速定位
|
||||
✅ **可扩展**：业务增长不用推倒重来
|
||||
✅ **可复制**：成功经验能快速推广
|
||||
|
||||
### 🚀 **一句话总结**
|
||||
|
||||
**"从Demo到生产，从能用到好用，工业化是必经之路"**
|
||||
|
||||
---
|
||||
|
||||
## 【第一部分：需求识别篇】到底什么样的需求适合用AI？
|
||||
|
||||
### 🎯 **AI最擅长的三件事**
|
||||
|
||||
| 场景类型 | 业务特征 | 典型案例 |
|
||||
|---------|----------|----------|
|
||||
| **重复性工作** | 每天都要做，流程相对固定 | 订单异常排查、客服问答 |
|
||||
| **经验判断** | 靠人的经验，但有一定规律 | 商品好不好卖、订单有没有风险 |
|
||||
| **信息整理** | 需要从大量文本中提取关键信息 | 政策解读、文档问答 |
|
||||
|
||||
### ❌ **这些情况，别用AI**
|
||||
|
||||
| 场景特征 | 原因 | 替代方案 |
|
||||
|---------|------|----------|
|
||||
| **规则很清楚** | 用代码更简单、更便宜 | 直接写程序 |
|
||||
| **要求100%准确** | AI做不到完美 | 规则引擎 |
|
||||
| **一次性的活** | 开发成本太高 | 人工处理 |
|
||||
|
||||
### 🔍 **三招判断你的场景**
|
||||
|
||||
**第一招：频次测试**
|
||||
|
||||
- 这个问题**每天出现**吗？✅
|
||||
- 这个问题**偶尔才遇到**？❌
|
||||
|
||||
**第二招：复杂度测试**
|
||||
|
||||
- 需要**看多个因素**才能判断？✅
|
||||
- 只要**看一个指标**就知道答案？❌
|
||||
|
||||
**第三招：容错测试**
|
||||
|
||||
- 偶尔**判断错误**可以接受？✅
|
||||
- **绝对不能出错**？❌
|
||||
|
||||
### 💡 **我们的三个场景，怎么判断的？**
|
||||
|
||||
**订单诊断：适合**
|
||||
|
||||
- 订单中断时，对研发同学打断较为频繁 ✅
|
||||
- 要看订单金额、流水信息等 ✅
|
||||
- 偶尔误判可以接受 ✅
|
||||
|
||||
**商品分析：适合**
|
||||
|
||||
- 从下游商品追踪到上游商品需要 2-3 步 ✅
|
||||
- 商品名称模糊时需要更多步 ✅
|
||||
- 分析错了影响不大 ✅
|
||||
|
||||
**文库问答：适合**
|
||||
|
||||
- 人事/研发同学**天天被问相同问题** ✅
|
||||
- 要从**大量文档中找答案** ✅
|
||||
- **回答错了可以纠正** ✅
|
||||
|
||||
---
|
||||
|
||||
## 【第二部分：选择篇】到底该用啥？
|
||||
|
||||
**核心问题：技术选型四维度，怎么选？**
|
||||
|
||||
### 🎯 **维度1：部署方式（供应商 vs 私有化）**
|
||||
|
||||
#### **供应商服务：三种玩法**
|
||||
|
||||
| 调用方式 | 技术门槛 | 开发周期 | 成本 | 数据安全 |
|
||||
|---------|----------|----------|------|----------|
|
||||
| **直接调API** | 中等 | 3-5天 | 按调用付费 | 数据在供应商 |
|
||||
| **调用智能体** | 低 | 2-3天 | 按调用付费 | 数据在供应商 |
|
||||
| **调用工作流** | 最低 | 1-2天 | 按调用付费 | 数据在供应商 |
|
||||
|
||||
**供应商优势**：
|
||||
|
||||
- ✅ 无需买机器，零硬件投入
|
||||
- ✅ 模型能力强，永远用最新版
|
||||
- ✅ 运维简单，出问题有人管
|
||||
|
||||
#### **私有化部署：两种方案**
|
||||
|
||||
| 部署方式 | 硬件投入 | 模型能力 | 运维成本 | 数据安全 |
|
||||
|---------|----------|----------|----------|----------|
|
||||
| **买云主机** | 每月几千到几万 | 比供应商弱 | 需要专人 | 完全可控 |
|
||||
| **买本地机器** | 一次性几万到几十万 | 比供应商弱 | 需要专人 | 完全可控 |
|
||||
|
||||
**私有化成本细算**（14B）：
|
||||
|
||||
- **云主机**：8核32G，16G显存 ≈ 4500/月
|
||||
- **本地机器**：8核32G（1万），16G显存（5000）主机 ≈ 1.5-2万/台 + 运维
|
||||
|
||||
#### **数据安全对比**
|
||||
|
||||
| 安全维度 | 供应商服务 | 私有化部署 |
|
||||
|---------|------------|------------|
|
||||
| **数据出境** | ❌ 可能出境 | ✅ 完全境内 |
|
||||
| **数据留存** | ❌ 供应商留存 | ✅ 自己掌控 |
|
||||
| **审计合规** | ❌ 黑盒操作 | ✅ 完全透明 |
|
||||
| **安全认证** | ✅ 有专业认证 | ❌ 需要自己搞 |
|
||||
|
||||
### 💻 **维度2：语言选择（Python vs Go）**
|
||||
|
||||
| 对比维度 | Python | Go | 建议 |
|
||||
|---------|----------|------|------|
|
||||
| **学习成本** | 生态成熟，资料多 | 当前团队主要语言 | ✅ Go |
|
||||
| **性能表现** | 解释型，相对慢 | 编译型，速度快 | ✅ Go |
|
||||
| **部署运维** | 环境复杂 | 单文件部署 | ✅ Go |
|
||||
| **AI生态** | 最丰富 | 快速发展中 | Python |
|
||||
|
||||
**结论**：Go团队无脑选Go，生态已够用，优势明显
|
||||
|
||||
### 🔧 **维度3：框架选择**
|
||||
|
||||
| 框架生态 | 代表框架 | 成熟度 | 学习成本 | 适用场景 |
|
||||
|---------|----------|--------|----------|----------|
|
||||
| **Python生态** | LangChain + LangGraph | ⭐⭐⭐⭐⭐ | 中等 | 快速原型、功能最全 |
|
||||
| **Go生态** | LangChainGo、Eino | ⭐⭐⭐ | 低 | 生产环境、性能要求高 |
|
||||
| **可视化** | Coze、Dify | ⭐⭐⭐⭐ | 最低 | 业务人员、快速上线 |
|
||||
|
||||
**Go生态推荐**：
|
||||
|
||||
- **LangChainGo**：最成熟，社区活跃
|
||||
- **Eino**：字节跳动开源，企业级
|
||||
- **Coze-loop**：可视化+代码结合
|
||||
|
||||
### 🚀 **维度4：落地策略**
|
||||
|
||||
| 落地方式 | 开发周期 | 总成本 | 适用场景 | 推荐程度 |
|
||||
|---------|----------|--------|----------|----------|
|
||||
| **供应商API** | 3-5天 | 最低 | 快速验证 | ⭐⭐⭐⭐⭐ |
|
||||
| **Coze本地化** | 3-5天 | 低 | 标准化需求 | ⭐⭐⭐⭐⭐ |
|
||||
| **私有化部署** | 2-4周 | 高 | 数据敏感 | ⭐⭐⭐ |
|
||||
|
||||
### 风险评估
|
||||
|
||||
#### 技术风险评估
|
||||
|
||||
**模型稳定性风险**
|
||||
**集成复杂度风险**
|
||||
**维护成本风险**
|
||||
|
||||
#### 产品风险评估
|
||||
|
||||
**效果预期风险**
|
||||
**流程变更风险**
|
||||
**合规性风险**
|
||||
|
||||
#### 财务风险评估
|
||||
|
||||
**成本控制风险**
|
||||
|
||||
### 🎲 **智能体 vs 工作流，怎么选？**
|
||||
|
||||
| 场景特征 | 用智能体 | 用工作流 |
|
||||
|---------|----------|----------|
|
||||
| 规则经常变 | ✅ 灵活调整 | ❌ 需要改代码 |
|
||||
| 需要解释原因 | ✅ 能说清楚 | ❌ 黑盒操作 |
|
||||
| 成本敏感 | ❌ 贵 | ✅ 便宜 |
|
||||
| 准确要求高 | ❌ 可能错 | ✅ 稳定 |
|
||||
|
||||
### 🎯 **团队选型建议**
|
||||
|
||||
#### **决策流程：先选部署方式，再选技术栈**
|
||||
|
||||
**Step 1：要不要私有化？**
|
||||
|
||||
```
|
||||
数据敏感？ → 是 → 私有化（预算充足）
|
||||
↓ 否
|
||||
调用量大？ → 是 → 私有化（长期省钱）
|
||||
↓ 否
|
||||
快速验证？ → 是 → 供应商服务
|
||||
```
|
||||
|
||||
**Step 2：供应商服务怎么选？**
|
||||
|
||||
```
|
||||
业务标准化？ → 是 → Coze可视化（1-2天）
|
||||
↓ 否
|
||||
技术能力强？ → 是 → 直接调API（3-5天）
|
||||
↓ 否
|
||||
调工作流（2-3天）
|
||||
```
|
||||
|
||||
#### **推荐方案**
|
||||
|
||||
**方案A：快速验证**（推荐度：⭐⭐⭐⭐⭐）
|
||||
|
||||
- **组合**：供应商API + Go + Eino
|
||||
- **周期**：3-5天
|
||||
- **成本**：几千元/月
|
||||
- **场景**：80%的企业够用
|
||||
|
||||
**方案B：标准化需求**（推荐度：⭐⭐⭐⭐⭐）
|
||||
|
||||
- **组合**：Coze可视化 + 本地化导出
|
||||
- **周期**：1-2天
|
||||
- **成本**：几千元/月
|
||||
- **场景**：业务人员能维护
|
||||
|
||||
**方案C：数据敏感**（推荐度：⭐⭐⭐）
|
||||
|
||||
- **组合**：私有化部署 + Go + Eino
|
||||
- **周期**：2-4周
|
||||
- **成本**：10万+/年
|
||||
- **场景**：金融、医疗等强监管行业
|
||||
|
||||
#### **避坑指南**
|
||||
|
||||
**❌ 这些坑别踩：**
|
||||
|
||||
- 一上来就买机器，结果用不起来
|
||||
- 担心数据安全，但根本没那么多敏感数据
|
||||
- 追求100%自研，错过业务窗口期
|
||||
|
||||
**✅ 正确姿势：**
|
||||
|
||||
- 先用供应商服务跑通业务
|
||||
- 真有需求再考虑私有化
|
||||
- 监控数据先做好，方便后续决策
|
||||
|
||||
---
|
||||
|
||||
## 【第三部分：实战篇】实战演示篇
|
||||
|
||||
### Python LangChain生态展示
|
||||
|
||||
- 现场演示：chain和graph的实际代码
|
||||
- 重点展示：langsmith监控界面
|
||||
- 成果对比：用监控前后的问题排查效率
|
||||
|
||||
### Eino Go生态展示
|
||||
|
||||
- 现场演示：graph和Workflow代码
|
||||
- 重点展示：coze-loop监控面板
|
||||
- 性能对比：Go vs Python的执行效率
|
||||
|
||||
### 方案3：文库智能问答
|
||||
|
||||
- 现场操作：vue3-frontend界面
|
||||
- 用户体验：从用户角度看AI应用
|
||||
- 交互亮点：实时反馈、流式输出等
|
||||
|
||||
---
|
||||
|
||||
## 【第四部分：行动篇】听完就能动手
|
||||
|
||||
### 立即行动清单
|
||||
|
||||
1. **选一个场景**：自身主要负责的业务场景
|
||||
2. **填一张表**：用选择表确定技术方案
|
||||
3. **套一个模板**：直接用我们提供的代码模板
|
||||
4. **算一笔账**：评估投入产出
|
||||
|
||||
### 成功标准
|
||||
|
||||
- 1周内：完成技术选型
|
||||
- 1个月：上线第一个版本
|
||||
- 3个月：看到明显效果
|
||||
|
||||
---
|
||||
|
||||
## 【总结】一句话记住
|
||||
|
||||
**"技术不是越先进越好，而是越适合越有价值"**
|
||||
|
||||
选择 > 实现，适合 > 先进
|
||||
听完就能选，看完就能用！
|
||||
|
||||
## 【第五部分：相关资源】
|
||||
|
||||
langchain：<https://docs.langchain.com/oss/python/langchain/overview>
|
||||
扣子：<https://www.coze.cn/opensource>
|
||||
本地部署：<https://github.com/coze-dev/coze-studio>
|
||||
扣子罗盘：<https://github.com/coze-dev/coze-loop>
|
||||
Eino框架：<https://github.com/cloudwego/eino>
|
||||
# 总大纲：AI应用落地（Agent + 工作流融合实战）
|
||||
|
||||
总时长：72分钟（1.2小时）
|
||||
|
||||
## 0 开场与目标（3分钟）
|
||||
|
||||
- 主题与目标：让后端 Go 团队“又快又稳”做出可用的 AI 应用
|
||||
- 一句话定位：Agent 负责“聪明与解释”，工作流保障“稳定与规模”
|
||||
- 贯穿案例：订单诊断（降低 MTTR/人工接管率、提升稳定性）
|
||||
|
||||
## 1 概念与融合（10分钟）
|
||||
|
||||
- 什么是 Agent：意图识别、工具选择、策略决策、结果解释与对话管理
|
||||
- 什么是工作流：确定性算子编排、状态与数据管理、幂等与重试、失败回退、审计与监控
|
||||
- 优缺点对比：
|
||||
- Agent：灵活、可解释；成本不稳定、可能不一致
|
||||
- 工作流：稳定、可控、低成本；表达复杂判断困难、解释弱
|
||||
- 融合方案（职责边界与组合模式）：
|
||||
- 入口路由：Agent 基于意图调用不同工作流
|
||||
- 工作流内嵌决策：复杂判断节点由 Agent 决策，其余节点确定性执行
|
||||
- 管理者-执行者：Manager Agent 分配任务，工作流封装工具完成
|
||||
- 常见坑：多 Agent 过度设计、记忆与任务状态混淆、工具幂等缺失
|
||||
|
||||
## 2 技术演进（6分钟）
|
||||
|
||||
- 手工时代 → 智能体时代 → 工业化时代（精简版）
|
||||
- 结论：从能用到好用，标准化与可观测是必经之路（不单设页面）
|
||||
|
||||
## 3 需求识别（12分钟）
|
||||
|
||||
- 三招判断：频次、复杂度、容错
|
||||
- 适用与不适用：规则清晰/100%准确/一次性工作不适合 AI
|
||||
- 场景映射：订单诊断、商品分析、文库问答
|
||||
- 回退策略：从 AI 回退为代码/规则引擎的判断标准
|
||||
|
||||
## 4 选型建议（12分钟）
|
||||
|
||||
- 部署方式：供应商（API/Agent/工作流） vs 私有化（云/本地）
|
||||
- 语言选择：阶段化策略（原型优先 Python；生产优先 Go），纯 Go 团队可直接上 Go
|
||||
- 框架推荐：
|
||||
- Python：LangChain/LangGraph（原型与功能全）
|
||||
- Go：Eino、LangChainGo（生产与性能）
|
||||
- 硬件与模型容量：
|
||||
- 7B：16G 显存可行（量化更稳）
|
||||
- 14B：建议 24–48G 显存；16G 需重度量化且质量折衷
|
||||
- 私有化阈值（简易测算）：月 API 费用 ≈ 硬件折旧/月 + 运维人力/月 + 合规需求 → 达到阈值再考虑自建
|
||||
|
||||
## 5 实战演示（24分钟）
|
||||
|
||||
- Python 快速原型（10分钟）：
|
||||
- 用 LangChain/LangGraph 搭“订单诊断”工作流：订单查询→支付网关→风控规则→异常解释
|
||||
- 监控：LangSmith 指标与问题定位
|
||||
- Go 生产化（10分钟）：
|
||||
- 框架：Eino / LangChainGo；HTTP 层（Gin/Hertz）
|
||||
- 目录结构：
|
||||
- `cmd/` 服务入口
|
||||
- `internal/agent/` 意图识别与解释
|
||||
- `internal/workflow/` 节点编排、重试与回退
|
||||
- `internal/tools/` 订单/支付/风控等工具封装
|
||||
- `internal/observability/` 指标、日志、trace
|
||||
- `pkg/` 通用库；`api/` 接口定义（OpenAPI/gRPC）
|
||||
- 工程要点：幂等、错误码、超时/熔断、重试与任务重放
|
||||
- 传输与体验（4分钟）：
|
||||
- 流式对比：SSE（浏览器友好、单向） vs WebSocket（双向、状态管理） vs HTTP Streaming（解析复杂） vs gRPC 流（强类型、需网关）
|
||||
- 选择建议：前端优先 SSE；双向需 WebSocket；内网优先 gRPC/HTTP2
|
||||
- 降低等待焦虑：预热与缓存、渐进式输出（先要点后细节）、并行查询与最慢支路降级、心跳与重连
|
||||
|
||||
## 6 成本评估与阶段化私有化（4分钟）
|
||||
|
||||
- 在线指标：成功率、P95 延迟、令牌用量、调用成本、重试次数、人工接管率
|
||||
- 监控盲点：上下文与工具调用的隐性令牌、未分场景/版本统计
|
||||
- 阶段化决策：先供应商跑通 + 完整监控 → 达阈值再私有化；含合规与数据敏感评估
|
||||
|
||||
## 7 总结（1分钟）
|
||||
|
||||
- 选择 > 实现，适合 > 先进；Agent + 工作流是通用融合方案
|
||||
- 一套模板 + 一套度量与监控 → 快速落地、可持续优化
|
||||
|
||||
## 8 相关资源（1分钟）
|
||||
|
||||
- LangChain：<https://docs.langchain.com/oss/python/langchain/overview>
|
||||
- LangGraph：<https://docs.langchain.com/oss/langgraph/>
|
||||
- Eino 框架：<https://github.com/cloudwego/eino>
|
||||
- LangChainGo：<https://github.com/tmc/langchaingo>
|
||||
- Coze（可视化）：<https://www.coze.cn/opensource>
|
||||
- Coze Studio（本地部署）：<https://github.com/coze-dev/coze-studio>
|
||||
- Coze Loop（监控）：<https://github.com/coze-dev/coze-loop>
|
||||
- 内部模板与评测集：公司知识库/代码模板（按团队链接补充）
|
||||
|
|
|
|||
|
|
@ -5,31 +5,30 @@
|
|||
前面我们学习了AI原理和部署实践，
|
||||
那今天呢？我想和大家聊聊：AI到底该怎么'用好'？
|
||||
|
||||
**【从个人困惑到企业级挑战】**
|
||||
**【痛点共识】**
|
||||
|
||||
不知道大家有没有这种感觉：
|
||||
- 算法懂了、模型也能跑，但落地时到底该用 Agent 还是工作流？
|
||||
- SSE、WebSocket、HTTP 流到底怎么选，用户等待体验怎么优化？
|
||||
- 供应商 vs 私有化怎么权衡，成本到什么阶段再自建？
|
||||
|
||||
- 算法听懂了，模型也跑通了，但回到业务里却不知道该用啥？
|
||||
- 面对Agent、工作流、本地部署、API调用这些选择，头更大了？
|
||||
- **更重要：领导问起来，你怎么证明这个投入是值得的？**
|
||||
**【今天我们做什么】**
|
||||
|
||||
**【企业级落地的真实挑战】**
|
||||
- 用一个真实案例（订单诊断）贯穿：Agent 负责意图与解释，工作流负责确定性执行与回退重试
|
||||
- 给出阶段化选型：原型用 Python，生产用 Go（Eino/LangChainGo），并给出目录模板与工程要点
|
||||
- 拆解流式传输与体验优化：选择建议、并行与降级、渐进式输出
|
||||
- 评估成本与私有化阈值：用数据而不是感觉做决定
|
||||
|
||||
当前，公司也有不少的AI项目已经落地。比如：7位定时任务表达式；商品品牌等属性识别；直连天下智能客服等。
|
||||
我参与落地的是智能客服，包括还有最近完成的一些项目。踩了很多坑，也积累很多经验。
|
||||
**【你将带走】**
|
||||
|
||||
从最初的"技术驱动"到后来的"业务导向"，
|
||||
从"为了使用AI做项目"到"使用AI技术为业务赋能"，
|
||||
我们走过了一条从Demo到生产，从概念到价值的完整路径。
|
||||
|
||||
**【今天的核心价值】**
|
||||
|
||||
今天，我们不是学习最前沿的技术。而是分享下在业务背景下，如何做出可用、好用的AI项目。
|
||||
- 可直接复用的 Go 项目目录模板与 Python 原型示例
|
||||
- 流式传输最佳实践与选择建议
|
||||
- 一套成本评估与私有化决策表
|
||||
- 常见坑清单与规避方法（幂等、错误码、记忆与状态分离）
|
||||
|
||||
**【一句话总结】**
|
||||
|
||||
选择比实现更重要，适合比先进更有价值。
|
||||
**今天，我就教大家怎么做出'适合'的选择！**
|
||||
选择 > 实现，适合 > 先进；聪明交给 Agent，稳定交给工作流。
|
||||
|
||||
**【结束语】**
|
||||
希望今天的分享，能让大家在AI应用的道路上，少走弯路，多创价值！
|
||||
**【开始吧】**
|
||||
|
||||
接下来 72 分钟，我们用融合方案把“能用”变成“好用、可持续”。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
# 承上启下：技术演进与主题定位
|
||||
|
||||
## 技术演进三阶段
|
||||
- 手工时代：Prompt 手工打造，结果不稳定、不可复制
|
||||
- 智能体时代：能记忆与调工具，但仍是作坊式、效率有限
|
||||
- 工业化时代：标准化流程、质量可控、批量复制
|
||||
|
||||
## 主题定位（一句话）
|
||||
- 聪明交给 Agent，稳定交给工作流；两者融合，既好用又可规模复制
|
||||
|
||||
## 课程收益与贯穿案例
|
||||
- 收益：更快选型、更稳上线、更好用户体验、更清晰成本评估
|
||||
- 案例：订单诊断（降低 MTTR、减少人工接管率）
|
||||
|
||||
## 今日路线图
|
||||
- Python 快速原型 → Go 生产化 → 传输与体验优化 → 成本评估与私有化阈值
|
||||
## 一句话总结
|
||||
主题定位：Agent 负责聪明与解释，工作流保障稳定与规模。
|
||||
## 一句话引出
|
||||
进入“融合方案”，明确职责边界与组合模式。
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# 融合方案：Agent × 工作流
|
||||
|
||||
## Agent 的职责
|
||||
- 意图识别与对话管理
|
||||
- 工具选择与策略性决策
|
||||
- 结果解释与可解释性输出
|
||||
|
||||
## 工作流的职责
|
||||
- 确定性算子编排与数据读写
|
||||
- 状态管理、幂等、重试与失败回退
|
||||
- 审计与监控、指标采集
|
||||
|
||||
## 组合模式
|
||||
- 入口路由：Agent 基于意图调用不同工作流
|
||||
- 工作流内嵌决策：复杂判断节点由 Agent 决策，其余确定性执行
|
||||
- 管理者-执行者：Manager Agent 分配任务，工作流执行工具
|
||||
|
||||
## 边界与协作
|
||||
- 记忆 vs 任务状态分离：避免业务状态污染对话记忆
|
||||
- 工具接口规范：输入输出、错误码、幂等与超时/熔断
|
||||
- 回退与人机协同：失败分支、人工接管入口、任务重放
|
||||
|
||||
## 常见坑与规避
|
||||
- 多 Agent 过度设计 → 一个入口 Agent + 工作流主干
|
||||
- 幂等缺失与错误码混乱 → 无法重试与回退
|
||||
- 监控缺失 → 无法定位问题与评估成本
|
||||
## 一句话总结
|
||||
边界清晰、模式够用、契约完备，才能让融合方案在生产可控。
|
||||
## 一句话引出
|
||||
下节将把融合范式映射到具体场景与选型。
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# 场景识别与技术选型
|
||||
|
||||
## 三招判断适配度
|
||||
- 频次：是否每天出现
|
||||
- 复杂度：是否需要看多个因素
|
||||
- 容错：是否允许偶尔错误
|
||||
|
||||
## 不适用的边界
|
||||
- 规则清晰 → 用代码/规则引擎更稳更便宜
|
||||
- 要求 100% 准确 → AI 不合适
|
||||
- 一次性工作 → 人工处理即可
|
||||
|
||||
## 部署选型
|
||||
- 供应商（API/Agent/工作流）：验证快、维护省心、需评估数据外流
|
||||
- 私有化（云/本地）：数据可控、长期成本可控、需工程与运维投入
|
||||
|
||||
## 语言与框架
|
||||
- 原型：Python（LangChain、LangGraph）
|
||||
- 生产：Go（Eino、LangChainGo）
|
||||
- 团队策略：纯 Go 团队可直接 Go，但建议保留原型快速验证
|
||||
|
||||
## 私有化阈值与硬件预算
|
||||
- 模型容量：7B≈16G 显存；14B建议 24–48G 显存（16G 需重度量化）
|
||||
- 阈值测算：月 API 费用 ≈ 硬件折旧/月 + 运维人力/月 + 合规需求
|
||||
## 一句话总结
|
||||
先用数据选场景与方案，原型快跑，生产稳落，达到阈值再私有化。
|
||||
## 一句话引出
|
||||
随后进入“实战落地”，用订单诊断完成端到端演示。
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# 实战落地：架构、传输与成本评估
|
||||
|
||||
## 案例流程（订单诊断）
|
||||
- 节点：订单查询 → 支付网关 → 风控规则 → 异常解释
|
||||
- 分支：失败回退、重试策略、人工接管入口
|
||||
|
||||
## Python 原型要点
|
||||
- LangChain/LangGraph 搭建工作流
|
||||
- LangSmith 指标与问题定位
|
||||
|
||||
## Go 生产要点
|
||||
- 框架：Eino / LangChainGo；HTTP 层（Gin/Hertz）
|
||||
- 目录结构：`cmd/`、`internal/agent`、`internal/workflow`、`internal/tools`、`internal/observability`、`pkg/`、`api/`
|
||||
- 工程要点：幂等、错误码、超时/熔断、重试与任务重放
|
||||
|
||||
## 传输与体验
|
||||
- SSE：浏览器友好、单向推送、实现简单
|
||||
- WebSocket：双向、低延迟、需心跳与状态管理
|
||||
- HTTP Streaming：保持 HTTP 语义，前端解析更复杂
|
||||
- gRPC 流：双向流、性能好、Web 需网关
|
||||
- 降低等待焦虑：预热与缓存、渐进式输出、并行查询与最慢支路降级、心跳与重连
|
||||
|
||||
## 成本与度量
|
||||
- 在线指标：成功率、P95 延迟、令牌用量、调用成本、重试次数、人工接管率
|
||||
- 监控盲点：上下文与工具调用的隐性令牌、未分场景/版本统计
|
||||
- 阶段化私有化：先供应商 + 完整监控 → 达阈值再自建
|
||||
## 一句话总结
|
||||
用融合方案跑通端到端，并以指标闭环驱动体验与成本优化。
|
||||
## 一句话引出
|
||||
最后收束到“课程总结与资源”，附行动清单与评测模板。
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
# AI选型速查卡 📋
|
||||
|
||||
> **一张图搞定AI技术选型** - 拍照带走，随时查看
|
||||
|
||||
---
|
||||
|
||||
## **需求判断：3分钟搞定**
|
||||
|
||||
### **口诀记忆法**
|
||||
|
||||
```
|
||||
频次高 + 复杂度高 + 能容错 = 适合AI
|
||||
频次低 + 很简单 + 要求高 = 不适合AI
|
||||
```
|
||||
|
||||
### **快速检查表**
|
||||
|
||||
| 检查项 | 适合AI | 不适合AI |
|
||||
|--------|--------|----------|
|
||||
| **频次** | 每天都有 | 偶尔才做 |
|
||||
| **复杂度** | 要看多个因素 | 看一个指标就知道 |
|
||||
| **容错** | 错了可以补救 | 绝对不能错 |
|
||||
|
||||
✅ **三票通过**：适合AI ❌ **有一票反对**：不适合AI
|
||||
|
||||
---
|
||||
|
||||
## **技术选型：一页纸决策**
|
||||
|
||||
### **第一步：要不要私有化？**
|
||||
|
||||
```
|
||||
数据敏感？ → 是 → 私有化（预算充足）
|
||||
↓ 否
|
||||
调用量大？ → 是 → 私有化（长期省钱）
|
||||
↓ 否
|
||||
快速验证？ → 是 → 供应商服务
|
||||
```
|
||||
|
||||
### **第二步：供应商服务怎么选？**
|
||||
|
||||
```
|
||||
业务标准化？ → 是 → Coze可视化（2-3天）
|
||||
↓ 否
|
||||
技术能力强？ → 是 → 直接调API（3-5天）
|
||||
↓ 否
|
||||
调工作流（1-2天）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **避坑指南：5个不要**
|
||||
|
||||
### **❌ 不要踩的坑**
|
||||
|
||||
1. **一上来就买机器** - 先用供应商服务验证
|
||||
2. **担心数据安全过度** - 真有敏感数据再私有化
|
||||
3. **追求完美方案** - 先跑通业务再优化
|
||||
4. **只看开发成本** - 运维成本也要算
|
||||
5. **技术驱动立项** - 业务需求才是第一位
|
||||
|
||||
### **✅ 正确姿势**
|
||||
|
||||
- **先用后买**：供应商服务 → 真有需求再私有化
|
||||
- **监控先行**：数据收集好，方便后续决策
|
||||
- **MVP思维**：最小可行产品，快速验证
|
||||
|
||||
---
|
||||
|
||||
## **成本速算**
|
||||
|
||||
| 方案 | 开发周期 | 成本 | 适用场景 |
|
||||
|------|----------|--------|----------|
|
||||
| **供应商API** | 3-5天 | 几千元/月 | 快速验证 |
|
||||
| **Coze可视化** | 1-2天 | 几千元/月 | 标准化需求 |
|
||||
| **私有化云主机** | 2-4周 | 几千-几万/月 | 数据敏感 |
|
||||
| **私有化本地** | 2-4周 | 几万-几十万(一次性投入) | 强监管行业 |
|
||||
|
||||
---
|
||||
|
||||
## **紧急求助热线 📞**
|
||||
|
||||
**遇到选型困难时，问自己3个问题：**
|
||||
|
||||
1. **我的数据真的那么敏感吗？**
|
||||
2. **我的调用量真的很大吗？**
|
||||
3. **我能接受试错成本吗？**
|
||||
|
||||
**答案有2个"否" → 用供应商服务**
|
||||
**答案有2个"是" → 考虑私有化**
|
||||
|
||||
---
|
||||
|
||||
> 💡 **记住**：技术不是越先进越好，而是越适合越有价值！
|
||||
>
|
||||
> **适合 > 先进，选择 > 实现**
|
||||
|
|
@ -1,91 +0,0 @@
|
|||
# 互动场景设计
|
||||
|
||||
## 🎯 **现场互动环节：AI适不适合？你说了算！**
|
||||
|
||||
### **互动规则**
|
||||
- 我会展示4个真实业务场景
|
||||
- 每个场景30秒思考时间
|
||||
- 举手投票：适合用AI vs 不适合
|
||||
- 公布答案并解释原因
|
||||
|
||||
---
|
||||
|
||||
## **场景1：财务发票审核**
|
||||
|
||||
**业务描述**：
|
||||
财务部门每天收到100+张发票，需要审核：（1）发票真伪（2）金额是否正确（3）税率是否合规（4）是否重复报销
|
||||
|
||||
**判断标准**：
|
||||
- ✅ 频次测试：每天都有，量很大
|
||||
- ✅ 复杂度测试：要看多个因素（金额、税率、重复性）
|
||||
- ❓ 容错测试：偶尔误判可以接受吗？
|
||||
|
||||
**答案**：**适合用AI**
|
||||
- 工作流：先做规则校验（金额格式、税率标准）
|
||||
- 智能体：处理可疑发票，调用税务API验真
|
||||
- 效果：80%发票自动通过，财务专注处理异常
|
||||
|
||||
---
|
||||
|
||||
## **场景2：员工入职办理**
|
||||
|
||||
**业务描述**：
|
||||
新员工入职，HR需要：（1）检查证件是否齐全（2）填写入职表格（3）分配工位和电脑（4）开通各种权限
|
||||
|
||||
**判断标准**：
|
||||
- ❓ 频次测试：每天都有吗？
|
||||
- ✅ 复杂度测试：要看多个因素
|
||||
- ❓ 容错测试：错了可以补救吗？
|
||||
|
||||
**答案**：**部分适合AI**
|
||||
- **适合的部分**：证件检查、表格填写（标准化流程）
|
||||
- **不适合的部分**：工位分配、权限开通（需要人工判断）
|
||||
- **方案**：工作流处理标准化环节，人工处理决策环节
|
||||
|
||||
---
|
||||
|
||||
## **场景3：代码Review**
|
||||
|
||||
**业务描述**：
|
||||
开发团队要求：每次提交代码都必须经过资深同事Review，检查代码规范、逻辑错误、性能问题
|
||||
|
||||
**判断标准**：
|
||||
- ✅ 频次测试：每天都有大量提交
|
||||
- ✅ 复杂度测试：要看代码逻辑、性能、规范
|
||||
- ❌ 容错测试：能接受漏掉bug吗？
|
||||
|
||||
**答案**：**不适合用AI**
|
||||
- 代码质量要求太高，AI容易漏掉关键问题
|
||||
- 但可以用AI辅助：自动检查代码规范、明显bug
|
||||
- 最终还是要人工Review
|
||||
|
||||
---
|
||||
|
||||
## **场景4：会议室预订冲突处理**
|
||||
|
||||
**业务描述**：
|
||||
两个部门同时预订了同一个会议室，行政需要协调：（1）了解双方会议重要性（2）是否有替代会议室（3）能否调整时间
|
||||
|
||||
**判断标准**：
|
||||
- ❓ 频次测试：经常发生吗？
|
||||
- ✅ 复杂度测试：要看多个因素
|
||||
- ✅ 容错测试：协调错了可以重新安排
|
||||
|
||||
**答案**：**适合用AI**
|
||||
- 工作流：检查会议室空闲情况、会议优先级
|
||||
- 智能体：提出几个替代方案供选择
|
||||
- 效果：减少80%的人工协调工作
|
||||
|
||||
---
|
||||
|
||||
## **互动总结**
|
||||
|
||||
**判断口诀**：
|
||||
```
|
||||
频次高 + 复杂度高 + 能容错 = 适合AI
|
||||
频次低 + 很简单 + 要求高 = 不适合AI
|
||||
```
|
||||
|
||||
**现场小测试**：
|
||||
拿出手机，想想你最近遇到的3个工作场景，
|
||||
用这个口诀判断下，有没有可以交给AI的？
|
||||
|
|
@ -1,173 +0,0 @@
|
|||
# 实战演示设计
|
||||
|
||||
## 🎯 **演示目标**
|
||||
- 展示真实项目代码，不是Hello World
|
||||
- 现场运行，现场看效果
|
||||
- 突出对比：Python vs Go，不同实现方式
|
||||
|
||||
---
|
||||
|
||||
## **演示1：Python LangChain生态**（15分钟）
|
||||
|
||||
### **展示内容**
|
||||
1. **核心代码展示**（5分钟）
|
||||
- Chain定义：订单诊断流程
|
||||
- Graph实现：多步骤推理
|
||||
- 伪代码展示：逻辑更清晰
|
||||
|
||||
2. **现场运行**（5分钟）
|
||||
- 运行真实订单数据
|
||||
- 展示LangSmith监控界面
|
||||
- 对比：有监控 vs 没监控的问题排查
|
||||
|
||||
3. **效果对比**（5分钟）
|
||||
- 传统方式：人工分析订单 → 2小时
|
||||
- AI方式：工作流+智能体 → 5分钟
|
||||
- 准确率提升：人工85% → AI 95%
|
||||
|
||||
### **演示脚本**
|
||||
```python
|
||||
# 伪代码展示
|
||||
class OrderDiagnosisChain:
|
||||
def __init__(self):
|
||||
self.workflow = create_workflow() # 工作流：规则检查
|
||||
self.agent = create_agent() # 智能体：复杂判断
|
||||
|
||||
def diagnose(self, order):
|
||||
# 1. 工作流初筛（免费、快速）
|
||||
basic_result = self.workflow.run(order)
|
||||
|
||||
# 2. 智能体深度分析（付费、智能）
|
||||
if basic_result.needs_ai:
|
||||
return self.agent.analyze(order)
|
||||
|
||||
return basic_result
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **演示2：Eino Go生态**（15分钟）
|
||||
|
||||
### **展示内容**
|
||||
1. **核心代码展示**（5分钟）
|
||||
- Graph定义：客服问答流程
|
||||
- Workflow实现：并行处理
|
||||
- 伪代码展示：Go的并发优势
|
||||
|
||||
2. **现场运行**（5分钟）
|
||||
- 运行真实客服对话
|
||||
- 展示Coze-loop监控面板
|
||||
- 对比：Go vs Python性能差异
|
||||
|
||||
3. **性能对比**（5分钟）
|
||||
- Python：单线程，100个请求 → 30秒
|
||||
- Go：并发处理，100个请求 → 5秒
|
||||
- 内存占用：Python 500MB → Go 200MB
|
||||
|
||||
### **演示脚本**
|
||||
```go
|
||||
// 伪代码展示
|
||||
func CreateCustomerServiceGraph() *Graph {
|
||||
return NewGraph().
|
||||
AddNode("parse_question", ParseQuestion).
|
||||
AddNode("check_faq", CheckFAQ).
|
||||
AddNode("ai_answer", AIAnswer).
|
||||
AddNode("human_transfer", TransferToHuman).
|
||||
AddEdge("parse_question", "check_faq").
|
||||
AddEdge("check_faq", "ai_answer", WhenFAQNotFound).
|
||||
AddEdge("check_faq", "human_transfer", WhenComplexQuestion)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **演示3：前端交互**（10分钟）
|
||||
|
||||
### **展示内容**
|
||||
1. **界面演示**（3分钟）
|
||||
- Vue3界面：现代化设计
|
||||
- 实时反馈：流式输出效果
|
||||
- 用户体验：打字机效果
|
||||
|
||||
2. **现场操作**（4分钟）
|
||||
- 输入真实业务问题
|
||||
- 展示AI思考过程
|
||||
- 显示最终结果
|
||||
|
||||
3. **交互亮点**（3分钟）
|
||||
- 实时显示AI思考步骤
|
||||
- 支持中断和重新生成
|
||||
- 历史记录和收藏功能
|
||||
|
||||
### **演示脚本**
|
||||
```typescript
|
||||
// 伪代码展示
|
||||
const AIChatComponent = {
|
||||
async sendMessage(message: string) {
|
||||
// 1. 显示用户消息
|
||||
this.addUserMessage(message)
|
||||
|
||||
// 2. 流式获取AI回复
|
||||
const stream = await aiService.streamChat(message)
|
||||
|
||||
// 3. 实时显示回复
|
||||
for await (const chunk of stream) {
|
||||
this.appendAIResponse(chunk)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **演示4：项目目录结构**（5分钟）
|
||||
|
||||
### **Python项目结构**
|
||||
```
|
||||
langchain-project/
|
||||
├── src/
|
||||
│ ├── chains/ # 业务链定义
|
||||
│ ├── workflows/ # 工作流编排
|
||||
│ ├── models/ # 模型配置
|
||||
│ ├── services/ # 业务服务
|
||||
│ └── utils/ # 工具函数
|
||||
├── tests/ # 单元测试
|
||||
├── data/ # 测试数据
|
||||
├── logs/ # 运行日志
|
||||
└── requirements.txt # 依赖管理
|
||||
```
|
||||
|
||||
### **Go项目结构**
|
||||
```
|
||||
eino-project/
|
||||
├── internal/
|
||||
│ ├── ai/ # AI能力封装
|
||||
│ ├── biz/ # 业务逻辑
|
||||
│ ├── server/ # HTTP服务
|
||||
│ └── monitor/ # 监控指标
|
||||
├── api/ # API定义
|
||||
├── configs/ # 配置文件
|
||||
├── cmd/ # 启动入口
|
||||
└── docker-compose.yml # 容器编排
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **演示总结**（5分钟）
|
||||
|
||||
### **关键对比**
|
||||
| 对比维度 | Python方案 | Go方案 |
|
||||
|----------|------------|--------|
|
||||
| **开发效率** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
|
||||
| **运行性能** | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
|
||||
| **内存占用** | 高 | 低 |
|
||||
| **并发能力** | 一般 | 优秀 |
|
||||
| **生态成熟度** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
|
||||
|
||||
### **选择建议**
|
||||
- **快速原型**：选Python，生态最全
|
||||
- **生产环境**：选Go，性能最优
|
||||
- **团队协作**：根据团队技术栈选择
|
||||
|
||||
### **一句话总结**
|
||||
**"没有最好的技术，只有最适合的方案"**
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
# WPS 智能PPT生成提示文档：AI应用落地（Agent × 工作流融合实战）
|
||||
|
||||
## 全局参数
|
||||
- 听众画像：后端 Go 开发，具备基础 AI 应用认知
|
||||
- 目标：理解并掌握“Agent + 工作流”融合范式，能快速原型与稳定生产化
|
||||
- 风格：简洁、工程化、数据驱动；少段落，多要点；配图清晰
|
||||
- 配色：主色蓝灰（#2F5D8A / #4A4A4A），强调色橙（#F59E0B）
|
||||
- 字体：中文用思源黑体/微软雅黑，英文字体用 Inter/Roboto
|
||||
- 页数建议：18–20 页；每页遵循“标题/一句话金句/三要点/图示建议”结构
|
||||
- 图形偏好：流程图、架构图、对比表；避免花哨背景与过多动画
|
||||
- 术语一致：Agent、工作流、SSE、WebSocket、HTTP Streaming、gRPC、MTTR、P95、令牌
|
||||
|
||||
## 目录与每页内容
|
||||
1. 标题页
|
||||
- 金句：选择 > 实现，适合 > 先进
|
||||
- 要点：主题、讲师、时间
|
||||
- 图示：主题封面图（抽象线路/节点）
|
||||
|
||||
2. 开场与目标
|
||||
- 金句：聪明交给 Agent，稳定交给工作流
|
||||
- 要点：听众画像、课程目标、贯穿案例（订单诊断）
|
||||
- 图示：课程目标图标组
|
||||
|
||||
3. 承上启下：技术演进
|
||||
- 金句：从手工到工业化，核心是标准化与可观测
|
||||
- 要点：手工→智能体→工业化；问题与改进；度量意识
|
||||
- 图示：时间轴
|
||||
|
||||
4. 融合方案总览
|
||||
- 金句：边界清晰、模式够用、契约完备
|
||||
- 要点：Agent 职责；工作流职责；融合收益
|
||||
- 图示：双层架构图（Agent 外层、工作流主干）
|
||||
|
||||
5. 组合模式与职责边界
|
||||
- 金句：入口路由、内嵌决策、管理者-执行者
|
||||
- 要点：三种模式；适用场景；边界约束（记忆vs状态）
|
||||
- 图示：三模式示意图
|
||||
|
||||
6. 常见坑与规避
|
||||
- 金句：少而精的 Agent + 可观测工作流
|
||||
- 要点：过度多Agent；幂等与错误码缺失；监控缺失
|
||||
- 图示：问题→对策表
|
||||
|
||||
7. 场景识别三招
|
||||
- 金句：频次、复杂度、容错三步筛选
|
||||
- 要点：三招定义；通过案例映射；回退边界
|
||||
- 图示：打勾/打叉列表
|
||||
|
||||
8. 不适用边界
|
||||
- 金句：能编程就别用 AI；必须 100% 准确也别用
|
||||
- 要点：规则清晰、100%准确、一次性工作
|
||||
- 图示：红线边界卡片
|
||||
|
||||
9. 部署选型
|
||||
- 金句：先供应商跑通，达阈值再私有化
|
||||
- 要点：供应商（API/Agent/工作流）；私有化（云/本地）优缺点
|
||||
- 图示：对比表
|
||||
|
||||
10. 语言与框架
|
||||
- 金句：原型 Python，生产 Go；纯 Go 团队可直接 Go
|
||||
- 要点：LangChain/LangGraph；Eino/LangChainGo；生态与工程取舍
|
||||
- 图示：栈对比图
|
||||
|
||||
11. 私有化阈值与硬件预算
|
||||
- 金句：用数据而不是感觉做决定
|
||||
- 要点：月 API 费测算；自建=硬件折旧+运维+合规；显存容量：7B≈16G，14B建议24–48G（16G重度量化）
|
||||
- 图示：简易成本公式与条形图
|
||||
|
||||
12. 架构总览（订单诊断）
|
||||
- 金句：入口 Agent + 主干工作流，端到端闭环
|
||||
- 要点：输入/输出；节点与分支；回退与人工接管
|
||||
- 图示：端到端流程图
|
||||
|
||||
13. 传输与体验（对比）
|
||||
- 金句：前端优先 SSE；双向用 WebSocket；内网优先 gRPC/HTTP2
|
||||
- 要点：SSE/WebSocket/HTTP Streaming/gRPC 优劣；心跳与重连；渐进式输出与并行降级
|
||||
- 图示：对比表 + 时序图
|
||||
|
||||
14. Python 原型演示
|
||||
- 金句：快速搭建、可观测、可回放
|
||||
- 要点：LangChain/LangGraph；LangSmith 监控；评测集与回放
|
||||
- 图示：原型架构与监控截图占位
|
||||
|
||||
15. Go 生产化演示
|
||||
- 金句：目录清晰、契约完备、稳定可扩展
|
||||
- 要点：Eino/LangChainGo；`cmd/`、`internal/*`、`pkg/`、`api/`；幂等/错误码/重试/熔断
|
||||
- 图示：目录结构树与依赖图
|
||||
|
||||
16. 工程要点（可靠性）
|
||||
- 金句：幂等与错误码是重试与回退的根基
|
||||
- 要点：超时/熔断；任务重放；死信与恢复策略
|
||||
- 图示：容错链路图
|
||||
|
||||
17. 成本与度量
|
||||
- 金句：指标闭环驱动优化与私有化决策
|
||||
- 要点：成功率、P95、令牌、成本、重试、人工接管率；监控盲点与分维度统计
|
||||
- 图示：指标仪表盘占位
|
||||
|
||||
18. 总结与行动清单
|
||||
- 金句：模板 + 度量与监控 → 快速落地、可持续优化
|
||||
- 要点：选一个场景；填选型表；套模板；算成本账
|
||||
- 图示：清单卡片
|
||||
|
||||
19. 相关资源
|
||||
- 金句：拿来即用的外部文档与内部模板
|
||||
- 要点：LangChain、LangGraph、Eino、LangChainGo、Coze、Coze Studio、Coze Loop、内部知识库链接
|
||||
- 图示：资源链接卡片
|
||||
|
||||
## 版式与生成要求
|
||||
- 每页结构：主标题（不超过14字）+ 一句话金句（不超过20字）+ 三要点（每条不超过18字）+ 图示建议（一句话）
|
||||
- 避免长段落；对比用表格；流程用箭头；术语保持一致
|
||||
- 所有英语缩写保留原文：SSE、gRPC、HTTP/2、MTTR、P95
|
||||
- 优先白底深色文字；强调色仅用于关键字或数据
|
||||
|
||||
## 演讲备注（可选）
|
||||
- 强调“融合范式”的方法论与工程可操作性
|
||||
- 贯穿案例用“订单诊断”，度量指标贯穿始终
|
||||
- 传输体验与成本评估是实战关键，不可略过
|
||||
|
||||
## 生成后校对清单
|
||||
- 术语统一；硬件容量数字正确（14B→24–48G 显存建议）
|
||||
- SSE/WebSocket/gRPC 对比无缺项；有心跳与重连要点
|
||||
- 目录结构页包含 `cmd/`、`internal/agent`、`internal/workflow`、`internal/tools`、`internal/observability`、`pkg/`、`api/`
|
||||
- 成本页包含公式与分维度指标
|
||||
Loading…
Reference in New Issue