知乎团队用 Cursor 重构开发流程：从踩坑到全团队落地的真实经历
知乎 B 端开发团队从 2024 年 11 月首次尝试 Cursor 失败，到 2025 年 2 月模型升级后全团队采纳——完整踩坑记录、最佳实践、以及 Dify 企业知识库如何让信息检索效率提升 70%。
上一篇写了大型企业的 Agent 落地。这篇换个角度——中小团队怎么用 AI Agent。
两个案例：知乎 B 端团队用 Cursor 的完整踩坑过程（含从失败到成功的转折点），以及 Dify 开源平台如何帮助中型企业搭建智能客服+知识库系统。
案例一：知乎 B 端团队 × Cursor — 从抗拒到全团队采纳
背景
知乎是国内最大的问答/知识社区平台。B 端（企业服务）产品开发团队负责知乎的商业化功能——广告系统、创作者工具、企业号管理等。
2024 年 11 月，团队第一次尝试 Cursor，结果很差，几乎放弃。直到 2025 年 2 月 Claude 模型升级后重新尝试，才找到正确的使用方式，最终全团队采纳。
时间线：从失败到成功的转折
失败阶段：Vibe Coding 的陷阱
2024 年 11 月的首次尝试中，团队犯了典型错误——Vibe Coding（凭感觉写代码）：
踩过的坑：
- 不写
.cursorrules，AI 不知道项目规范，生成的代码风格混乱 - 用 Composer 模式一次改多个文件，出错后不知道哪里改坏了
- 没有 git 检查点习惯，AI 改坏了回不去
- 对 AI 生成的代码不做 review，直接合并
成功阶段：Planned Mode 的正确姿势
2025 年 2 月，团队重新出发，核心转变是从 Vibe Coding 回到 Planned Mode：
团队制定的最佳实践
知乎团队总结了以下规范（适用于任何想引入 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 工作流
结果
- 团队从全面抗拒到全团队采纳
- 开发速度显著提升（团队主动选择继续使用而非强制推行）
- 产出了完整的踩坑指南，帮助其他团队避免同样的错误
- 核心教训：工具不是问题，使用方式才是关键
同生态补充 — 国内 AI 编程工具百花齐放：
- 百度文心快码：百度内部 + 外部企业使用
- 阿里通义灵码：阿里系全栈 AI 编程助手
- 腾讯 CodeBuddy：腾讯内部开发工具
- CCF TF-167 技术前沿论坛上，AfterShip 等多家企业分享了 Cursor 实践
案例二：Dify 开源平台 — 中型企业的智能客服+知识库
背景
Dify 是一个开源的 LLM 应用开发平台，在中国中小企业中被广泛用于快速搭建 AI 应用。以下案例综合了多个 Dify 生产用户的实践。
典型场景： 一家中型电商企业，日均客服咨询 2000+ 条，产品 SKU 3000+，知识文档上万篇。
架构设计
关键技术：Prompt 模板 + 意图路由
Dify 的工作流不是简单的"问题→答案"，而是条件分支 + 多步骤：
用户输入 → 意图分类 → [条件分支]
├─ 订单查询 → 查询订单系统API → 格式化回复
├─ 产品咨询 → 知识库检索 → 生成推荐 → 回复
├─ 售后问题 → 检查订单状态 → 判断是否在售后期 → 给出方案
└─ 投诉建议 → 情感分析 → 触发人工转接（带完整上下文）Prompt 模板示例：
你是 {{company_name}} 的客服助手。
用户意图: {{intent}}
产品信息: {{product_info}}
相关知识: {{retrieved_context}}
用户历史: {{user_history}}
请根据以上信息回复用户。注意：
1. 用通俗语言，避免技术术语
2. 如果不确定，说"我帮您确认一下"而不是编造答案
3. 涉及退款的场景，引导到人工客服模型路由：成本优化
通过模型路由，约 60% 的问题走低成本模型，整体推理成本控制在可接受范围。
部署方案
Dify 支持多种部署方式，国内企业常用的是阿里云 SAE 一键部署：
| 部署方式 | 适用场景 | 特点 |
|---|---|---|
| 阿里云 SAE | 中小企业 | 一键部署，按量计费 |
| Docker 自建 | 有运维能力 | 完全可控，成本更低 |
| Dify Cloud | 快速验证 | 免费额度，省去运维 |
结果（综合多个 Dify 生产用户）
| 行业 | 效果 |
|---|---|
| 电商客服 | 60% 咨询自主处理，整体效率 +40% |
| 制造业知识库 | 信息检索时间减少 70%，HR/IT 从重复问题中释放 |
| 数字营销 | 内容创作时间缩短 50%+，创意多样性提升 |
| 金融投研 | RAG 知识库辅助投资研究，信息覆盖面显著扩大 |
两个案例的共同经验
给中小团队的落地建议
-
不要 Vibe Coding，要 Planned Mode — 知乎团队的教训：随意的 Prompt 产出随意的代码。写好规则文件、小步提交、Code Review，这三步不能省。
-
先选痛点，再选工具 — 不要因为"Cool"就上 AI。选最耗人力、最重复、最有规则可循的任务作为切入点。
-
开源平台 + 自建 > 封闭平台 — Dify 的优势在于可自部署、数据不出企业。对数据敏感的行业（金融、医疗、政务），这是刚需。
-
模型路由省钱 — 不是每个问题都需要 GPT-4。60% 的 FAQ 用低成本模型就够了，把预算留给真正需要推理的场景。
数据来源：
- 知乎 Cursor 实践：知乎专栏技术分享
- Dify 生产案例：火山引擎开发者社区、阿里云开发者社区、dify.ai
- CCF TF-167 AI 编程工具前沿论坛
- 百度智能云、阿里云、火山引擎官方技术博客
Related Articles
三个中国人用 AI Agent 创业的真实故事：从腾讯辞职的、做动画的、不会写代码的产品经理
艾逗笔从腾讯辞职用 Cursor 一年半做出 10+ 产品，ShipAny 预售 4 小时卖了 1 万美元；苏魁一个人做 AI 骨骼动画平台，用国产免费 AI 工具月成本几十块；产品经理七吟覃完全不会写代码，用 Cursor 10 小时做出了微信小程序——三个人、三条路径、全是中国人。
产品经理零代码实录：七吟覃怎么用 Cursor 10 小时做出「读啥鸭」小程序
经管专业、8 年产品经理、一行代码没写过——国庆假期读完 Pieter Levels 的《MAKE》，打开 Cursor 免费版，花了 10 小时做出了一个能自动爬取豆瓣书单、用 AI 写毒评的微信小程序。完整的 9 个开发阶段、AI Prompt 全文、6 个踩坑记录、16 级评级体系设计思路，全部拆解开。
他们是怎么用 AI Agent 赚到钱的：三个人、三种技术栈、三条完整路径
Pieter Levels 用一个 4 万行 PHP 文件做出月入 13 万美元的 PhotoAI、Jon Cheney 从钢琴作曲家用 Replit 周末花 400 块搭出一年赚 250 万美元的 AI 教育平台、Maor Shlomo 用 Cursor 独自开发被 Wix 8000 万美元收购的 Base44——不是报菜名，是三个人从打开工具到赚到钱的每一步。