> 上一篇写了大型企业的 Agent 落地。这篇换个角度——**中小团队**怎么用 AI Agent。 > > 两个案例：知乎 B 端团队用 Cursor 的完整踩坑过程（含从失败到成功的转折点），以及 Dify 开源平台如何帮助中型企业搭建智能客服+知识库系统。 --- ## 案例一：知乎 B 端团队 × Cursor — 从抗拒到全团队采纳 ### 背景知乎是国内最大的问答/知识社区平台。B 端（企业服务）产品开发团队负责知乎的商业化功能——广告系统、创作者工具、企业号管理等。 2024 年 11 月，团队第一次尝试 Cursor，**结果很差**，几乎放弃。直到 2025 年 2 月 Claude 模型升级后重新尝试，才找到正确的使用方式，最终全团队采纳。 ### 时间线：从失败到成功的转折 ```mermaid graph LR subgraph 2024-11 A[首次尝试 Cursor
Vibe Coding 阶段
兴奋→混乱→放弃] end subgraph 2025-01 B[观察期
个别成员继续探索
总结失败原因] end subgraph 2025-02 C[模型升级
Claude 新版本发布
代码质量跃升] end subgraph 2025-03 D[全团队推广
制定使用规范
建立最佳实践] end A -->|2个月| B -->|1个月| C -->|1个月| D style A fill:#ffebee style C fill:#e8f5e9 style D fill:#c8e6c9 ``` ### 失败阶段：Vibe Coding 的陷阱 2024 年 11 月的首次尝试中，团队犯了典型错误——**Vibe Coding**（凭感觉写代码）： ```mermaid graph TB subgraph 错误模式-Vibe-Coding V1[随意描述需求
AI 你看着办] V2[AI 生成一大段代码
不看直接 Accept] V3[跑通了！
但代码质量差] V4[需求变更
AI 重新生成] V5[代码越来越乱
无法维护] V6[最终放弃
回到手写] end V1 --> V2 --> V3 --> V4 --> V5 --> V6 style V1 fill:#ffebee style V6 fill:#ffebee ``` **踩过的坑：** - 不写 `.cursorrules`，AI 不知道项目规范，生成的代码风格混乱 - 用 Composer 模式一次改多个文件，出错后不知道哪里改坏了 - 没有 git 检查点习惯，AI 改坏了回不去 - 对 AI 生成的代码不做 review，直接合并 ### 成功阶段：Planned Mode 的正确姿势 2025 年 2 月，团队重新出发，核心转变是**从 Vibe Coding 回到 Planned Mode**： ```mermaid graph TB subgraph 正确模式-Planned-Mode P1[先写 .cursorrules
定义项目规范] P2[详细描述需求
包含边界条件] P3[AI 生成代码后
逐行 Review] P4[小步提交
每个功能点一个 commit] P5[Code Review 流程
AI 代码也要过审] P6[持续迭代
可控地优化] end P1 --> P2 --> P3 --> P4 --> P5 --> P6 style P1 fill:#e8f5e9 style P6 fill:#c8e6c9 ``` ### 团队制定的最佳实践知乎团队总结了以下规范（适用于任何想引入 Cursor 的团队）： **1. 项目配置文件** 在项目根目录创建 `.cursorrules`： ``` # 项目规范 - 语言: TypeScript + React - 状态管理: Zustand - 样式: Tailwind CSS - 测试: Vitest + Testing Library - 提交规范: Conventional Commits - 不要使用 any 类型 - 优先使用函数式组件 - 所有 API 调用必须通过 src/api/ 层 ``` **2. 使用模式选择** | 场景 | 推荐模式 | 原因 | |------|----------|------| | 新功能开发 | Composer + Planned | 多文件联动，有计划地执行 | | Bug 修复 | Chat 模式 | 单点问题，不需要改多个文件 | | 代码重构 | Composer + 分步 | 大范围改动，需要检查点 | | 文档/测试 | Auto 模式 | 低风险，可以快速生成 | **3. Git 工作流** ```mermaid graph LR A[开始任务前
git stash 保存当前状态] --> B[用 Cursor 完成任务] B --> C{代码质量检查} C -->|通过| D[小步 commit
描述清楚改了什么] C -->|不通过| E[回滚到上一步
重新描述需求] D --> F[Push + PR] F --> G[Code Review
AI 代码也要审] style A fill:#e3f2fd style D fill:#c8e6c9 style E fill:#ffebee ``` ### 结果 - 团队从**全面抗拒**到**全团队采纳** - 开发速度显著提升（团队主动选择继续使用而非强制推行） - 产出了完整的踩坑指南，帮助其他团队避免同样的错误 - **核心教训：工具不是问题，使用方式才是关键** > 同生态补充 — 国内 AI 编程工具百花齐放： > - **百度文心快码**：百度内部 + 外部企业使用 > - **阿里通义灵码**：阿里系全栈 AI 编程助手 > - **腾讯 CodeBuddy**：腾讯内部开发工具 > - CCF TF-167 技术前沿论坛上，AfterShip 等多家企业分享了 Cursor 实践 --- ## 案例二：Dify 开源平台 — 中型企业的智能客服+知识库 ### 背景 Dify 是一个**开源的 LLM 应用开发平台**，在中国中小企业中被广泛用于快速搭建 AI 应用。以下案例综合了多个 Dify 生产用户的实践。 **典型场景：** 一家中型电商企业，日均客服咨询 2000+ 条，产品 SKU 3000+，知识文档上万篇。 ### 架构设计 ```mermaid graph TB subgraph 知识层 DOC[文档上传
TXT/DOCX/PDF/MD/HTML] CHUNK[分块 Chunking
智能分段] EMB[向量嵌入 Embedding] VDB[向量数据库
相似度检索] end subgraph 应用层-Dify-Workflow INTENT[意图分类节点
订单查询/产品咨询/售后/投诉] RETRIEVE[知识检索节点
Top-K 检索] LLM[LLM 生成节点
带变量模板] JUDGE{判断节点
是否需要人工} end subgraph 集成层 API[REST API
对接 CRM/ERP] WEB[网站嵌入组件
客服窗口] HAND[人工转接
上下文传递] end subgraph 模型路由 M1[简单问题→低成本模型
GPT-3.5/Qwen-Turbo] M2[复杂问题→高能力模型
GPT-4/Qwen-Max] end DOC --> CHUNK --> EMB --> VDB VDB --> RETRIEVE INTENT -->|订单查询| RETRIEVE INTENT -->|产品咨询| RETRIEVE INTENT -->|售后问题| RETRIEVE INTENT -->|投诉| HAND RETRIEVE --> LLM LLM --> JUDGE JUDGE -->|低风险| API JUDGE -->|高风险| HAND INTENT --> M1 INTENT --> M2 API --> WEB style VDB fill:#e3f2fd style INTENT fill:#fff3e0 style HAND fill:#ffebee ``` ### 关键技术：Prompt 模板 + 意图路由 Dify 的工作流不是简单的"问题→答案"，而是**条件分支 + 多步骤**： ``` 用户输入 → 意图分类 → [条件分支] ├─ 订单查询 → 查询订单系统API → 格式化回复 ├─ 产品咨询 → 知识库检索 → 生成推荐 → 回复 ├─ 售后问题 → 检查订单状态 → 判断是否在售后期 → 给出方案 └─ 投诉建议 → 情感分析 → 触发人工转接（带完整上下文） ``` **Prompt 模板示例：** ``` 你是 {{company_name}} 的客服助手。用户意图: {{intent}} 产品信息: {{product_info}} 相关知识: {{retrieved_context}} 用户历史: {{user_history}} 请根据以上信息回复用户。注意： 1. 用通俗语言，避免技术术语 2. 如果不确定，说"我帮您确认一下"而不是编造答案 3. 涉及退款的场景，引导到人工客服 ``` ### 模型路由：成本优化 ```mermaid graph LR INPUT[用户问题] --> CLASSIFY{复杂度判断} CLASSIFY -->|简单
FAQ类| LOW[低成本模型
GPT-3.5/Qwen-Turbo
¥0.002/次] CLASSIFY -->|复杂
需要推理| HIGH[高能力模型
GPT-4/Qwen-Max
¥0.05/次] CLASSIFY -->|敏感
涉及金钱| HUMAN[人工客服] LOW --> REPLY[回复用户] HIGH --> REPLY HUMAN --> REPLY style LOW fill:#c8e6c9 style HIGH fill:#fff3e0 style HUMAN fill:#ffebee ``` 通过模型路由，**约 60% 的问题走低成本模型**，整体推理成本控制在可接受范围。 ### 部署方案 Dify 支持多种部署方式，国内企业常用的是**阿里云 SAE 一键部署**： | 部署方式 | 适用场景 | 特点 | |----------|----------|------| | 阿里云 SAE | 中小企业 | 一键部署，按量计费 | | Docker 自建 | 有运维能力 | 完全可控，成本更低 | | Dify Cloud | 快速验证 | 免费额度，省去运维 | ### 结果（综合多个 Dify 生产用户） | 行业 | 效果 | |------|------| | 电商客服 | **60% 咨询自主处理**，整体效率 +40% | | 制造业知识库 | 信息检索时间**减少 70%**，HR/IT 从重复问题中释放 | | 数字营销 | 内容创作时间**缩短 50%+**，创意多样性提升 | | 金融投研 | RAG 知识库辅助投资研究，信息覆盖面显著扩大 | --- ## 两个案例的共同经验 ### 给中小团队的落地建议 ```mermaid graph TB subgraph 第一步-工具选型 A1[开发类: Cursor/通义灵码/CodeBuddy] A2[应用类: Dify/扣子/百度文心] A3[自动化类: 实在Agent/RPA+LLM] end subgraph 第二步-试点策略 B1[选一个痛点场景] B2[1-2 周快速验证] B3[量化效果再决定推广] end subgraph 第三步-规模化 C1[制定使用规范] C2[建立评估体系] C3[持续迭代优化] end A1 --> B1 --> C1 A2 --> B2 --> C2 A3 --> B3 --> C3 style A1 fill:#e3f2fd style B1 fill:#fff3e0 style C1 fill:#e8f5e9 ``` 1. **不要 Vibe Coding，要 Planned Mode** — 知乎团队的教训：随意的 Prompt 产出随意的代码。写好规则文件、小步提交、Code Review，这三步不能省。 2. **先选痛点，再选工具** — 不要因为"Cool"就上 AI。选最耗人力、最重复、最有规则可循的任务作为切入点。 3. **开源平台 + 自建 > 封闭平台** — Dify 的优势在于可自部署、数据不出企业。对数据敏感的行业（金融、医疗、政务），这是刚需。 4. **模型路由省钱** — 不是每个问题都需要 GPT-4。60% 的 FAQ 用低成本模型就够了，把预算留给真正需要推理的场景。 --- **数据来源：** - 知乎 Cursor 实践：知乎专栏技术分享 - Dify 生产案例：火山引擎开发者社区、阿里云开发者社区、dify.ai - CCF TF-167 AI 编程工具前沿论坛 - 百度智能云、阿里云、火山引擎官方技术博客

知乎团队用 Cursor 重构开发流程：从踩坑到全团队落地的真实经历