七吟覃，经管专业，8 年 AI 产品经理，一行代码不会写。2024 年国庆假期，他读完 Pieter Levels 的《MAKE》，决定自己也试一把。10 小时后，他上线了一个微信小程序。

这篇文章会带你走完他从动机到上线的每一步——包括他给 Cursor 写的完整 Prompt、技术架构怎么搭的、踩了什么坑、怎么解决的。你可以直接拿这个案例去跟朋友说："看，不会写代码的人也能用 AI 做出产品。"

第一部分：这个人是谁，为什么想做

背景

• 学历： 经管专业
• 职业： AI 产品经理，做了近 8 年
• 编程能力： 零。从来没有写过一行代码
• 他的知乎专栏： "书味集"（shuweiji）
• 他的 B 站频道： "七吟覃_随便聊聊大模型"系列
• 他在 GitHub 上： 参与了毕昇（BISHENG）和 Dify 两个开源 LLM 平台的社区

转折点：读完《MAKE》

2024 年国庆假期，七吟覃读了 Pieter Levels 的 《MAKE: Building Startups the Indie Way》。

这本书的核心观点是：一个人就能做产品，不需要团队，不需要融资，先做出来再说。

"虽然不会写代码，但看完《MAKE》我也想做独立开发者了。"

他的心态转变：

• 之前："先学编程，再做产品"（永远学不完，永远不开始）
• 之后："先开始做产品，碰到什么不会的再边做边学"

他给自己定了一个目标：一年做 12 个产品，每个月一个。 灵感库里有 20 多个想法。"读啥鸭"是第一个，选它没什么特别的商业考量——就是因为他喜欢读书。

"并没有什么商业考量或者细致的需求分析。"

他的核心理念

"尽早发布，尽早获得真实反馈。用户的真实反应要抵过自己无数巧妙的思考、分析。"

第二部分：产品是什么

读啥鸭（微信小程序搜索"读啥鸭"）

核心功能：自动从各平台爬取书单，然后用 AI 给每份书单写一段毒辣点评。

覆盖的平台：豆瓣、微信读书、微博、小红书。

功能拆解

1. 定时爬取（每 20 分钟）
   从各平台抓取新书单链接
   ↓
2. 内容解析
   提取书单名称、作者、描述、包含书目
   ↓
3. AI 毒评生成
   调用毕昇 BISHENG + 大模型
   生成标签 + 评级 + 诙谐评价
   ↓
4. 存入云数据库
   结构化存储，前端直接读取
   ↓
5. 小程序展示
   分类浏览 + 打字机效果 + 手机振动反馈

16 级评级体系

七吟覃设计了一套递进式的评级，越往后越稀有：

平淡无奇 → 普通 → 有意思 → 别具一格 → 栩栩如生 →
艰深晦涩 → 见微知著 → 引人入胜 → 刻骨铭心 → 发人深省 →
气势磅礴 → 一针见血 → 意味深长 → 弥足珍贵 → 典藏 → 出神入化

评级徽章图片用即梦 AI（jimeng.jianying.com）生成，存在微信云存储里。

AI 评价效果示例

输入书单：《西游记》、《水浒传》、《红楼梦》、《三国演义》

AI 输出：

"《西游记》🐒 也可以说是'公费吃喝，到此一游'🏞️，何为真经，孰能定义 🤔 《红楼梦》可是文学巅峰，拥有极高的艺术成就和思想价值，可惜一般人不懂 😂"

第三部分：工具选择——为什么用这些

为什么选 Cursor 不选别的？

七吟覃没有做工具对比——他是产品经理，先试再说。Cursor 免费版的 500 次调用对他来说足够了。

为什么选微信云开发？

不需要自己搞服务器、数据库。云函数直接在微信开发者工具里管理，右键上传就行。

第四部分：完整开发过程——9 个阶段

阶段 1：注册微信小程序（~30 分钟）

1. 打开 mp.weixin.qq.com 注册小程序账号
2. 下载微信开发者工具
3. 创建项目 → 选择"不使用模板" + "微信云开发"
4. 注意：选"不使用模板"时后端会自动变成"不使用云服务"，但后续开通云开发不受影响

阶段 2：配置 Cursor（~10 分钟）

1. 打开 Cursor
2. File → Open Folder → 选择小程序项目目录
3. 切换模型为 claude-3.5-sonnet
4. 免费版约 500 次使用额度

阶段 3：向 Cursor 描述需求（~1 小时）

这是最关键的步骤。七吟覃的做法是一次性把所有页面和功能逻辑描述清楚：

"我要做一个书单小程序，具体功能如下：

首页：按主题分类展示书单列表，每个卡片显示书单名称、
      AI评级标签、评价摘要
      点击进入书单详情页

书单详情页：展示书单名称、作者、描述
           书单包含的所有书目（书名+作者）
           AI 生成的毒辣评价（带打字机效果）
           收藏和分享按钮

分类页：按标签筛选书单
        支持搜索

我的页：收藏的书单列表
       提交书单链接的入口

整体风格：简洁、文艺、中国风
配色：米白色背景、深灰文字、暗红强调色"

关键：他不是逐步加功能，而是一开始就把全部需求说清楚。 这样 AI 能生成更完整的代码，减少后期冲突。

阶段 4：Cursor 生成代码 → 复制到文件（~2 小时）

Cursor 生成了完整的小程序代码，包括：

• 页面文件（.wxml 模板 + .wxss 样式 + .js 逻辑 + .json 配置）
• 全局样式和配置
• 基础组件

七吟覃的四个操作：

1. 看懂 Cursor 生成的文件结构
2. 在微信开发者工具中创建对应文件
3. 把代码复制进去
4. 在模拟器中预览效果

阶段 5：用 Apply 功能迭代修改（~3 小时）

这是最核心的工作方式。七吟覃用了 Cursor 的 Apply 功能：

工作流程：
1. 在 Cursor 聊天中描述要修改的内容
   例如："首页的书单卡片太大了，改成两列布局，间距缩小"
2. Cursor 生成修改后的代码
3. 点击 Apply 按钮
4. Cursor 自动定位到需要修改的代码位置
5. 自动增删改代码
6. 在微信开发者工具中预览效果

Apply 是他最重要的功能——因为他不会写代码，不能手动改。Apply 让 AI 自己找到要改的地方。

阶段 6：搭建云函数（~1 小时）

创建云函数目录：

cloudfunctions/
  └── processBookList/    # 核心云函数
      ├── index.js        # 书单爬取 + AI解析 + 存入数据库
      ├── config.json     # 超时时间（60秒）+ 定时触发（每20分钟）
      └── package.json    # 依赖：axios

config.json 的定时器配置：

{
  "triggers": [
    {
      "name": "bookListTimer",
      "type": "timer",
      "config": "0 */20 * * * * *"
    }
  ]
}

注意：微信云函数的 cron 表达式是 7 个字段（比标准 Linux crontab 多一个秒字段），七吟覃在这里踩了坑。

部署方式： 在微信开发者工具中，右键 processBookList 文件夹 → "上传并部署：云端安装依赖"。

阶段 7：接入毕昇 BISHENG 做 AI 解析（~1 小时）

七吟覃用毕昇 BISHENG（开源 LLM 应用平台）来处理书单的 AI 评价生成：

处理流程：
1. 云函数爬取网页文本
2. 正则匹配过滤非书单内容（降低 LLM 调用成本）
3. 调用毕昇 API，传入文本 + Prompt
4. 毕昇平台：文本解析 → 组装 Prompt → 调用大模型 → 返回结构化 JSON
5. 云函数接收结果 → 存入云数据库

为什么用毕昇而不是直接调用大模型 API？

因为毕昇帮他处理了：

• 网页文本解析（提取正文、去掉广告和导航）
• Prompt 模板管理
• 多模型切换（可以换不同的底层模型）
• 结构化输出

阶段 8：云数据库 + 云存储（~30 分钟）

云数据库集合：

• booklists：存储处理后的书单数据（名称、作者、标签、评级、评价、书目）

云存储：

• 16 个评级徽章图片（即梦 AI 生成）
• 因为微信小程序总大小限制 2MB，图片必须存在云存储里

阶段 9：测试和发布（~1 小时）

1. 在微信开发者工具中全面测试
2. 清缓存（"全部清除"按钮）
3. 真机预览
4. 提交审核 → 上线

第五部分：AI Prompt 全文

这是七吟覃在毕昇平台配置的完整 Prompt——用于生成书单的毒辣评价：

# 角色
你是一名毒辣的{input}，态度要非常鲜明。

# 任务
1. 提取【书单名称】【书单作者】【书单描述】【书单内容】
   - 不能编造，不存在则置空
   - 【书单内容】用 书名+作者名 形式，换行分隔
2. 生成【标签】（不超过5个）和【评级】
   - 评级选项：平淡无奇、普通、有意思、别具一格、栩栩如生、艰深晦涩、
     见微知著、引人入胜、刻骨铭心、发人深省、气势磅礴、一针见血、
     意味深长、弥足珍贵、典藏、出神入化
   - 越往后要求越高、概率越低
3. 【评价】：
   - 说明为什么要读这些书
   - 语言风格诙谐幽默、一针见血、出人意料
   - 穿插不少于5个emoji
   - 字数越少越好
   - 不用"哇"、"哇塞"开头
   - 不用"xxx简直是xxx"句式
4. 以JSON格式输出
5. 如非书单内容则俏皮提示用户

# 书单文章
{content}

这个 Prompt 的精妙之处：

1. 角色设定灵活 — {input} 是动态变量，可以是"书评人"、"毒舌编辑"等不同角色
2. 评级体系严格 — 16 级评级，明确要求"越往后概率越低"，避免 AI 一律给高分
3. 风格约束精确 — 禁用了"哇"开头和"xxx简直是xxx"句式，这两类是 AI 最容易生成的套路表达
4. 输出格式固定 — JSON 格式，方便程序解析和存储
5. 兜底处理 — "如非书单内容则俏皮提示用户"，处理爬虫抓到非书单页面的情况

第六部分：技术架构总览

graph TB
    subgraph 数据采集
        A1[定时触发器<br/>每20分钟] --> A2[云函数<br/>processBookList]
        A2 --> A3[爬取豆瓣/微信读书<br/>微博/小红书]
        A3 --> A4[正则过滤<br/>降低LLM成本]
    end

    subgraph AI处理
        A4 --> B1[毕昇BISHENG平台]
        B1 --> B2[网页文本解析]
        B2 --> B3[组装Prompt<br/>角色+任务+内容]
        B3 --> B4[调用大模型]
        B4 --> B5[结构化JSON输出]
    end

    subgraph 数据存储
        B5 --> C1[微信云数据库<br/>booklists集合]
        B5 --> C2[评级徽章图片<br/>即梦AI生成]
        C2 --> C3[微信云存储]
    end

    subgraph 前端展示
        C1 --> D1[微信小程序]
        C3 --> D1
        D1 --> D2[首页: 分类浏览]
        D1 --> D3[详情: AI毒评<br/>打字机效果]
        D1 --> D4[我的: 收藏/提交]
    end

    style A1 fill:#fff3e0
    style B1 fill:#e3f2fd
    style D1 fill:#c8e6c9

完整技术栈：

前端：微信小程序原生框架
UI：  NutUI 组件库
后端：微信云开发（云函数 + 云数据库 + 云存储）
运行时：Node.js
依赖：axios（HTTP 请求）
AI平台：毕昇 BISHENG（开源）
图片生成：即梦 AI
开发工具：Cursor（claude-3.5-sonnet）

第七部分：踩过的 6 个坑

坑 1：AI 记忆有限——改着改着把之前的功能删了

问题： Cursor/Claude 的上下文窗口有限，聊了几轮之后，AI 开始"忘记"之前加过的功能。新改的代码可能把旧功能覆盖掉。

解决：

• 适时提醒 AI："注意，首页已经有分类筛选功能了，不要改动它"
• 在提问时附上相关代码，帮 AI 理解上下文
• 每完成一个重要功能就备份整个文件夹

坑 2：代码被 AI 改坏了

问题： Cursor 生成的代码不总是对的，有时候 Apply 之后小程序直接报错。

解决：

• 不要慌，重新描述需求，补充更多背景信息
• 把报错信息直接贴给 Cursor："运行后报了这个错：[错误信息]，帮我修复"
• Cursor 通常能在 2-3 轮对话内修好

坑 3：微信小程序 2MB 大小限制

问题： 小程序包不能超过 2MB，评级徽章图片太多放不下。

解决：

• 图片全部迁移到微信云存储
• 小程序代码只保留逻辑和样式
• 图片通过 wx.cloud.getTempFileURL 动态获取

坑 4：云函数超时

问题： 默认超时 3 秒，爬取 + AI 调用远远不够。

解决： 在 config.json 中把超时设为 60 秒（微信云函数最大值）。

坑 5：定时器 cron 表达式字段不同

问题： 微信云函数的 cron 是 7 个字段（比 Linux 多一个秒字段），按标准 5 字段写会报错。

解决： 改成 7 字段格式 "0 */20 * * * * *"。

坑 6：Cursor 和 GitHub 同步超时

问题： Cursor 内置的 GitHub 集成总是超时。

解决： 改用 GitHub Desktop 单独管理 Git 操作。

第八部分：他的"四件事"工作法

七吟覃总结说，作为零代码的产品经理，他实际做的事情只有四件：

1. 学会工具
   Cursor、微信开发者工具、微信云开发后台
   各花 1-2 小时看教程

2. 清晰描述需求
   把产品经理写 PRD 的能力用在这里
   一次说清楚，比反复改更高效

3. 复制粘贴 / 用 Apply
   AI 生成代码 → 复制到文件 → 或用 Apply 自动修改
   一行代码不用自己写

4. 测试迭代
   遇到问题把报错贴给 AI
   让 AI 帮你修
   反复循环直到满意

"需要有比较强的逻辑思维能力和新概念学习能力。"

但他强调： 不需要学编程语言，不需要学算法，不需要学数据结构。只需要能清晰地描述你想要什么，然后读懂 AI 给你的东西对不对。

第九部分：总结

"他的技术栈是微信云开发 + Cursor。有意思的点：

1. 他用毕昇 BISHENG 做中间层处理 AI 调用，而不是直接调 API——省了不少工程量
2. 他的 Prompt 设计得很好——16 级递进评级、禁用 AI 套路表达、JSON 强制输出
3. 微信云开发对这种轻量级应用很合适——不用自己搞服务器
4. 他在正则匹配后调 LLM，先过滤再调 API，降低了成本"

数据来源：

• 原文：人人都是产品经理 woshipm.com/share/6132011.html（3039 阅读、37 分钟长文）
• 腾讯新闻转载：view.inews.qq.com/a/20241028A02SFB00
• GitHub：github.com/wisdomqin/dushaya（已归档）
• 知乎专栏：zhihu.com/column/shuweiji
• B 站：七吟覃_随便聊聊大模型系列

这篇全是中国人。

你要拿去给朋友讲"AI Agent 在实际生产中怎么用"——这三个案例够了。每个人从选工具、写 Prompt、搭技术栈、到赚了多少钱，全部分解开。

人物一：艾逗笔（idoubi）— 腾讯辞职，用 Cursor 一年半做出 10+ 产品

他是谁： 2015 年武大核工程毕业，自学编程入行，2018 年进腾讯，5 年做到高级工程师。2023 年裸辞，全职做独立开发者。 产品： ThinkAny（AI 搜索）、ShipAny（SaaS 开发框架）、MCP.so（MCP 应用市场）等 10+ 个产品 收入： ShipAny 预售 4 小时卖了 1 万美元；MCP.so 月访问量 100 万+ 工具： Cursor（主力）+ Bolt.new（原型）+ v0.dev（UI）+ Claude

他选的技术栈

核心框架: TypeScript + React + Next.js
登录认证: next-auth / clerk
数据库:   Supabase / Neon
多语言:   next-intl
支付:     Stripe / LemonSqueezy / Creem
文件存储: AWS S3 / Cloudflare R2
部署:     Cloudflare / Vercel
域名:     GoDaddy / Namecheap
UI组件:   Shadcn/UI / MagicUI / HeroUI

他选 Next.js 的原因很直接：全栈一套代码搞定，出海天然支持 SEO。Cursor 对 Next.js 的代码补全和上下文理解也是最好的。

他怎么用 Cursor 的

日常工作流：

他在 Cursor 里切换 claude-3.5-sonnet 模型——在他看来 Sonnet 是 Cursor 中性价比最高的模型。

他的"SOP 套壳追热点"工作法

这是艾逗笔最值得学的部分——他把"快速追热点做产品"变成了标准化流程：

graph LR
    A[发现热点<br/>HuggingFace Space<br/>Google Trends<br/>GitHub Trending] --> B[抢注域名<br/>Namecheap<br/>$1-10/年]
    B --> C[Vibe Coding<br/>Cursor 一周末<br/>出 MVP]
    C --> D[程序化 SEO<br/>数据采集+AI摘要<br/>批量生成页面]
    D --> E[社媒引流<br/>Product Hunt 打榜<br/>Twitter/X 传播]
    E --> F[变现<br/>订阅/一次性购买<br/>广告收入]

    style A fill:#fff3e0
    style C fill:#e3f2fd
    style F fill:#c8e6c9

具体例子 — MCP.so 怎么做到谷歌搜索第一的：

1. 发现 MCP（Model Context Protocol）成为热点
2. 用 Cursor 一周搭建了 MCP 应用市场
3. 程序化 SEO：自动采集 GitHub 上的 MCP 项目 → AI 生成摘要描述 → 为每个项目生成独立的结构化页面
4. 大量长尾关键词页面被谷歌收录
5. "MCP" 关键词谷歌搜索排名第一
6. 近 3 个月均访问量 100 万+，被 a16z 市场报告引用

ShipAny 的真实数据

ShipAny 是一个 Next.js SaaS 开发脚手架——帮你省掉登录、支付、多语言、部署这些重复工作。

2024 年 12 月预售当天：

• 4 小时销售额破 1 万美元
• 一周收入超过他其他产品一整年的收入
• 客户主要是想出海的中国开发者和海外独立开发者

给朋友讲的关键点

"先起飞再加油。"

艾逗笔的核心理念：不要等产品完美了再上线。他用 Cursor 一个周末就能出一个 MVP，然后靠数据决定要不要继续投入。

来源：InfoQ 专访、智源社区报道、idoubi.ai

人物二：苏魁 — 一个人做 AI 骨骼动画平台，月成本几十块

他是谁： 前高途、趣加游戏（FunPlus）、昆仑万维技术专家 产品： 龙骨动画 — AI 辅助的 2D 骨骼动画创作平台 公司： 北京哪吒互娱科技有限公司（他是唯一员工） 收入： 付费用户约 300 人，国内 4700+ 注册、海外 1000+ 注册 工具： 腾讯 Cloud Studio + DeepSeek + 豆包（全用国产免费工具）

他为什么不用 Cursor

苏魁做了一个很有意思的选择——全部用国产免费 AI 工具，不用 Cursor（$20/月）：

他的全年运营成本不到 5000 元（不含工资）： 公司注册 2000 多 + 代理记账 1000 多/年 + 服务器可忽略 + AI token 月几十块。

龙骨动画是怎么做出来的

产品功能： 用户构建人物骨架 → 绑定图片 → 输入自然语言指令（"让角色做一个挥手动作"）→ 点击"AI 生成" → 系统自动生成关键帧动画。

他的日常工作：

graph LR
    A[上午10点到<br/>中关村AI北纬社区] --> B[审核用户作品<br/>查看留言需求]
    B --> C[全天6小时+<br/>编码+调试]
    C --> D[用 DeepSeek<br/>写代码/查Bug]
    D --> E[用豆包<br/>写宣传文案]
    E --> F[B站发教程<br/>每周一期]

    style A fill:#fff3e0
    style D fill:#e3f2fd
    style F fill:#c8e6c9

他一个人干的事：

• 产品设计
• 前端 + 后端开发（AI 辅助）
• B 站运营（16 期教程，420+ 粉丝）
• 客服（审核用户上传作品）
• 甚至法务——因为代理机构纠纷，他自学打官司并胜诉，全额退款

商业模式

订阅制:
  月费 20 元
  年费 200 元

未来计划:
  合作销售 + 私有化部署
  预计年销售额可达百万元级别

给朋友讲的关键点

苏魁的故事证明：你不一定要用 Cursor/Claude，国产免费工具也能做出产品。关键不是用什么工具，而是你能不能解决一个具体的用户需求。

他用最低的成本验证了市场——4700 个注册用户、300 个付费用户、年度运营成本不到 5000 块。

来源：36氪 2026 年报道

人物三：七吟覃 — 不会写代码的产品经理，10 小时做出微信小程序

他是谁： 经管专业，近 8 年 AI 产品经理经验，完全不会写代码 产品： 读啥鸭 — 微信小程序，按主题自动汇聚书单 + AI 给毒辣点评 开发时间： 核心 10 小时（一行代码没写，全部 Cursor 完成） 工具： Cursor + 毕昇 BISHENG（开源 LLM 平台）+ 即梦 AI（图片生成）

他怎么用 Cursor 的（非技术人员必看）

这是一个完全不会写代码的人用 Cursor 的完整步骤：

第一步：打开 Cursor → Open a folder → 选择小程序目录

第二步：切换模型为 claude-3.5-sonnet（免费用户约500次使用额度）

第三步：一次性描述所有页面和功能逻辑
       例如："我要做一个书单小程序，
             首页按主题分类展示书单，
             点击书单可以看到详细书单和AI点评，
             用户可以收藏和分享书单"

第四步：使用 Apply 功能 → Cursor 自动在代码中定位增删改位置
       不需要你自己找要改哪个文件

第五步：带上相关代码提问 → 帮 AI 理解上下文

第六步：完成重要功能后 → 备份整个文件夹

他给 AI 的 Prompt 样例（书单解析）：

你是一个毒辣的书评家。请根据以下书单信息：
1. 提取书单主题标签
2. 对每本书给出 1-5 星评级
3. 写一段诙谐又尖刻的评论
4. 输出 JSON 格式

技术架构

前端:     微信小程序原生框架
UI组件:   NutUI
云开发:   微信云开发（云函数 + 云数据库 + 云存储）
运行时:   Node.js
依赖:     axios（网页解析）
AI推理:   毕昇 BISHENG 平台
图片生成: 即梦 AI

云函数结构：

cloudfunctions/
  └── processBookList/    # 核心云函数
      ├── index.js        # 书单解析 + AI点评
      ├── config.json     # 60秒超时 + 定时触发
      └── package.json    # 依赖项

定时器每 10 分钟执行一次，自动从各平台抓取新书单 → AI 生成点评 → 存入云数据库。

他踩过的坑

1. AI 记忆有限 大模型上下文有限，Cursor 有时会忘记之前加过的功能，不小心删掉。解决：适时提醒已有功能，附上相关代码。

2. 代码被 AI 改坏了 Cursor 生成代码不总是对的。解决：重新描述需求，补充背景信息，让 AI 重写。

3. 小程序超 2MB 限制 图片太多超过微信限制。解决：图片迁移到云存储，小程序只留代码。

给朋友讲的关键点

七吟覃的故事最适合给非技术人员讲——他一行代码都没写。Cursor 的 Apply 功能让 AI 自动找到要修改的代码位置，他只需要描述想要什么。

他的经验总结成一句话：

"像对待真人开发者一样给 Cursor 提要求——清晰、具体、一次说清楚。"

代码已开源：github.com/wisdomqin/dushaya_readlist

来源：人人都是产品经理（woshipm.com）

三种模式，三种启示

graph TB
    subgraph 模式一-技术出海
        A1[艾逗笔<br/>腾讯高级工程师]
        A2[Cursor + Next.js<br/>全套现代技术栈]
        A3[追热点+程序化SEO<br/>出海赚美元]
        A4[ShipAny 4小时<br/>$10,000]
        A1 --> A2 --> A3 --> A4
    end

    subgraph 模式二-国内垂直
        B1[苏魁<br/>游戏行业技术专家]
        B2[国产免费工具<br/>DeepSeek+豆包]
        B3[垂直领域深耕<br/>AI骨骼动画]
        B4[月成本几十块<br/>4700注册用户]
        B1 --> B2 --> B3 --> B4
    end

    subgraph 模式三-零代码创业
        C1[七吟覃<br/>产品经理零代码]
        C2[Cursor Apply功能<br/>AI自动定位代码]
        C3[微信小程序<br/>10小时出产品]
        C4[开源分享<br/>验证想法可行性]
        C1 --> C2 --> C3 --> C4
    end

    style A4 fill:#c8e6c9
    style B4 fill:#c8e6c9
    style C4 fill:#c8e6c9

给朋友讲解时的关键信息：

数据来源：

• 艾逗笔：InfoQ 专访 (infoq.cn)、智源社区 (hub.baai.ac.cn)、idoubi.ai
• 苏魁：36氪 2026 年报道 (36kr.com/p/3705517920825736)
• 七吟覃：人人都是产品经理 (woshipm.com/share/6132011.html)

之前写的像报菜名，被骂了。这篇不一样。

只有三个人。每个人的技术栈、开发工具、日常工作流、写的 Prompt、踩的坑、怎么赚到的钱——全部分解开。

人物一：Pieter Levels — 一个 4 万行 PHP 文件，月入 13 万美元

他是谁： 荷兰人，35 岁，数字游民，自学编程，零员工，零融资 产品： PhotoAI — AI 证件照/写真生成工具 收入： 月入 13.2 万美元，利润率 87%+（月利润约 11.9 万美元） 工具： Cursor + Claude

他选的技术栈（以及为什么）

核心哲学：整个产品是一个 PHP 文件。

PhotoAI 的核心代码是一个 40,870 行的 index.php。这不是段子。

为什么单文件？

1. Cursor 能看到全部代码 — 如果分成 50 个文件，AI 只能看到一部分，改一处坏另一处。单文件意味着 Cursor/Claude 能理解完整的上下文。
2. 一个人维护更快 — 不用在 50 个文件之间跳转，Cmd+F 搜索比任何 IDE 导航都快。
3. 不需要 CI/CD — 没有 staging 环境，没有测试流水线，直接 push 到生产。

"我太懒了不想搭 staging server... 有人推特报 bug，我按秒表计时... 两分钟后修完上线。" — Lex Fridman Podcast #440

他的日常工作流

graph LR
    A[坐在沙发上<br/>16寸 MacBook] --> B[Trello 看板<br/>This Year→Month→Week→Today→Now]
    B --> C[打开 Cursor<br/>直接改 index.php]
    C --> D[Cmd+Enter<br/>Git push 上线]
    D --> E{有人报 bug？}
    E -->|是| F[2分钟修完<br/>再 push]
    E -->|否| G[继续写新功能]

    style A fill:#fff3e0
    style D fill:#c8e6c9

他给 Cursor/Claude 的指令： 让 AI 永远自动 push。有一次 Claude 推了一个语法错误到生产，网站挂了 2 秒。他在推特上咆哮 "CLAUDEEEEEEEEEEEEEEEEEEE"，获得了数百万浏览。

他一年提交了 37,000+ 次 Git commit，平均每天 100+ 次。这是 AI 辅助编程的速度——改一下、推一下、看效果、再改。

PhotoAI 是怎么一步步搭出来的

graph TB
    subgraph 第一阶段-手工验证
        A1[Stripe 付款链接<br/>用户付款] --> A2[Typeform 表单<br/>用户上传照片]
        A2 --> A3[Pieter 手动<br/>在自己电脑训练模型]
        A3 --> A4[从个人邮箱<br/>把结果发给用户]
    end

    subgraph 第二阶段-Web化
        B1[用 Cursor 写 Web App<br/>替代手工流程]
        B2[接入 Replicate API<br/>云端推理不用自己管 GPU]
        B3[用户上传→自动训练<br/>→自动生成写真]
    end

    subgraph 第三阶段-优化
        C1[接入 Google Vision API<br/>过滤 NSFW 内容]
        C2[A/B 测试引擎<br/>10% 用户测不同参数<br/>按收藏率自动优化]
        C3[17天达到<br/>$1M ARR]
    end

    A4 --> B1
    B3 --> C1

    style A3 fill:#ffebee
    style B1 fill:#e3f2fd
    style C3 fill:#c8e6c9

具体的 A/B 测试： 他让系统在 10% 的用户上随机测试不同的 Stable Diffusion 参数（调度器、步数等），然后按"用户收藏率"自动挑选最优参数。这整个功能是 Cursor 帮他写的。

他踩过的真实 Bug

1. 训练数据污染 用户上传的照片如果都穿绿色衬衫，AI 会认为"衬衫=这个人"，生成的人脸不像。修复：强制要求用户上传不同衣服、不同光线、不同角度的照片。

2. 裸露内容 最好的写实模型底层训练数据包含色情内容，生成的照片可能暴露。修复：负面 Prompt（negative prompt）+ Google Vision API 安全过滤双重防护。

"现在人们用的写实模型，底层还是有色情内容的... 你需要用 prompt 把裸露的东西去掉。每个做 AI 创业的都要处理这个问题。"

这个人为什么成功

不是因为技术好（他的技术选择被无数人嘲笑过——2025 年了还用 jQuery + PHP 单文件）。而是因为他出货速度极快，快速验证想法，AI 让这个速度再快了 10 倍。

人物二：Jon Cheney — 钢琴作曲家的 400 美元周末创业

他是谁： 前职业钢琴作曲家，零编程经验 产品： GenAIPI — AI 能力评估和培训平台 收入： 第 5 天就赚了 1.5 万美元，一年内 250 万美元 工具： Replit AI Agent

完整时间线——每一天发生了什么

周三 2月26日 → 在 LinkedIn 看到 Replit。把一份 $105K 的开发报价 PDF
               拖进 Replit。20 分钟出了个能跑的原型（虽然 UI 是乱的）。

周四 2月27日 → 决定用 Replit 做一个"AI IQ 测试"漏斗产品。
               给 Replit Agent 描述了他想要的功能。
               连续工作 12 小时。

周五 2月28日 → 再干 12 小时。继续用自然语言告诉 AI 要改什么。

周六 3月01日 → 再干 11 小时。累计 35 小时。网站基本完成。
               10 万行代码，全部由 AI 生成。

周日 3月02日 → 凌晨 3 点上线。网站正式开放。

周一 3月03日 → 收集到 150 个 leads，但 $0 收入。
               发现 Stripe 集成坏了 → 用 Replit 5 分钟修好。
               转向直接 B2B 外联。
               在 LinkedIn 给 6 个弱关系联系人发了私信。

周二 3月04日 → 一个人回复 → 通电话 → 开价 $15K → "成交。"
               第 5 天。现金流回正。总花费约 $400。

他到底怎么用 Replit 的

Jon 不会写代码。 他的开发方式是纯自然语言对话：

他输入的 Prompt（还原）：

"我需要一个平台，可以评估 AI 熟练程度，有一个 40 题 30 分钟的测试，
管理课程内容，处理用户认证，生成证书。还要有一个免费的 12 题预览版，
用来做获客漏斗。"

Replit Agent 就开始写代码。然后他不断调试迭代：

"我花了至少 40 小时在调试、测试、修 bug 上，才让它真正能用。" "期望：几个 Prompt 就能生成一个完美应用。现实：需要大量调试和迭代。"

他的经验总结（非技术人员必读）：

为什么选 Replit 不选 Cursor：

"Replit 的好处是不用离开平台。前端、后端、数据库全在一个地方。 我不需要搞 GitHub、Supabase、外接数据库。直接跟 Agent 说'创建一个数据库'就行了。"

商业模式的关键转折

上线第一天 $0 收入。他发现——没人愿意为一个 AI 测试付 $59。

第二天他在 LinkedIn 发了 6 条私信，结果一个回复就带来 $15K。他瞬间悟了：

graph LR
    A[产品: $59 AI测试] -->|没人买| B[问题不在产品<br/>在客户]
    B --> C[转型: 不卖测试<br/>卖分时首席AI官]
    C --> D[$10K-$25K/月<br/>企业订阅]
    D --> E[6周: $180K<br/>一年: $2.5M]

    style A fill:#ffebee
    style C fill:#e8f5e9
    style E fill:#c8e6c9

他的冷启动销售话术：

Hey [名字],

我有个新东西——我可以测量你所有员工的 AI 就绪度，
看看他们对工具的掌握程度，然后制定一个计划
确保你的团队不会掉队。你们大概也在尝试拥抱这些。
值得聊 15 分钟吗？

— Jon

结果：6 条私信 → 1 个回复 → 1 个电话 → $15K 成交

目标客户画像：年收入 $10-30M 的公司 CEO，公司没有 CTO，蓝领行业。

他为什么成功

不是技术——他到现在也不会写代码。而是：

1. 他有商业直觉（之前的创业融了 $13M）
2. 他有行业人脉（LinkedIn 弱关系网络）
3. AI 帮他跳过了"找技术合伙人"这个最大的创业瓶颈

人物三：Maor Shlomo — 用 Cursor 独自开发，6 个月被收购拿走 8000 万美元

他是谁： 31 岁，以色列程序员，前 Explorium 联合创始人/CTO（融过 $130M），Forbes 30 Under 30 产品： Base44 — 用自然语言描述就能生成完整应用的 vibe-coding 平台 收入： 被收购时月利润 $189K，用户 25 万+ 结局： 2025 年 6 月被 Wix 以 $8000 万现金收购 工具： Cursor

他选的技术栈（以及一个反直觉决策）

关键决策：为什么不用 TypeScript？

"LLM 在写纯 JavaScript 时出错更少。TypeScript 的类型系统对 AI 来说是额外的出错点。"

这不是偷懒——"对 LLM 友好的代码"是一个产品设计决策。Base44 自己生成的代码也是 JavaScript 而非 TypeScript，因为 AI 生成的 JS 更可靠。

他怎么用 Cursor 的

"AI 写了我 90% 的代码。我已经三个月没写过前端代码了。"

他的开发方式：

1. 代码仓库专门为 AI 结构化 — 文件组织方式让 Cursor 能清晰理解每个模块的职责
2. 每天部署 13 次 — 从改代码到上线 7 分钟
3. 先建再删 — 用 AI 快速建功能，不好用就删

"验证完了再建"这套已经过时了——当建一个东西这么快的时候，直接建就是最好的验证。"

Base44 从零到 $80M 的四个阶段

graph TB
    subgraph 阶段一-前10个用户
        A1[女朋友的艺术生意<br/>需要获客网站] --> A2[用 Cursor 做了个<br/>AI 建站原型]
        A2 --> A3[找朋友当面测试<br/>他们在旁边看<br/>当场修 bug]
    end

    subgraph 阶段二-Product-Hunt
        B1[发布到 Product Hunt] --> B2[拿下当日/当周<br/>/当月最佳产品]
        B2 --> B3[用户增长加速]
    end

    subgraph 阶段三-病毒增长
        C1[激励分享机制<br/>分享获得额度过] --> C2[用户自发传播<br/>零广告费]
    end

    subgraph 阶段四-收购
        D1[举办黑客松<br/>3000支队伍参加] --> D2[Wix 注意到<br/>开出 $80M]
        D2 --> D3[2025年6月<br/>现金收购完成]
    end

    A3 --> B1
    B3 --> C1
    C2 --> D1

    style A1 fill:#fff3e0
    style B2 fill:#e3f2fd
    style D3 fill:#c8e6c9

增长数据：

• $0 广告费
• 4 周达到 $1.5M ARR（原计划年底才达到）
• 被收购当月利润 $189K
• 6 个月内 25 万用户

他踩过的坑

1. "Demo 里能用" ≠ "真人能用" 所有 AI vibe-code 出来的东西，在真实用户手里都会散架。他的解决方式是死盯前 10 个用户，当面看他们操作，当场修。

2. 功能臃肿 AI 写代码太快了，他建了一堆功能，大部分没人用。后来开始以同样的速度删功能。

3. 一个"有帮助"的功能被删掉后，激活率翻了 3 倍 一个反直觉的产品决策——删掉了看似有用的引导功能后，用户成功率反而提高了。

他给 AI 创业者的建议

"前几个月不要见任何不是潜在付费用户的人。"

"没人关心你怎么建的东西。语言、基础设施、CI/CD——对用户来说全都不重要。"

"你的产品很可能在基础设施成为问题之前就已经没人用了。"

三条路径的共同本质

graph TB
    subgraph Pieter-Levels
        L1[有经验的开发者] --> L2[用 Cursor 加速<br/>已有的工作流]
        L2 --> L3[单文件哲学<br/>极致简单]
        L3 --> L4[快速出货<br/>快速验证]
    end

    subgraph Jon-Cheney
        J1[零编程经验] --> J2[用 Replit 替代<br/>找技术合伙人]
        J2 --> J3[自然语言描述<br/>AI 生成+调试]
        J3 --> J4[商业直觉+人脉<br/>B2B 高客单价]
    end

    subgraph Maor-Shlomo
        M1[资深工程师] --> M2[用 Cursor 写一个<br/>AI 帮别人写代码的平台]
        M2 --> M3[为 LLM 优化代码<br/>不用 TypeScript]
        M3 --> M4[建了删、删了建<br/>速度是唯一优势]
    end

    L4 --> R[赚到钱]
    J4 --> R
    M4 --> R

    style L2 fill:#e3f2fd
    style J2 fill:#fff3e0
    style M2 fill:#e8f5e9
    style R fill:#c8e6c9

三个人、三种背景、三种工具链，但做对了一件相同的事：

不追求技术完美，追求市场验证速度。

Pieter 用 PHP 单文件，被全互联网嘲笑技术过时——但他月入 13 万美元。 Jon 不会写代码，靠 Replit 对话做出产品——但他第 5 天就赚了 1.5 万。 Maor 不用 TypeScript，代码仓库为 AI 而非人类优化——但他 6 个月卖了 8000 万。

AI 时代创业，代码质量是最不重要的东西。重要的是你多快能把东西放到用户面前。

数据来源：

• Pieter Levels：Lex Fridman Podcast #440, @levelsio 推特历史
• Jon Cheney：Taskade Blog 专访, The AI Marketers 播客, LinkedIn 帖子
• Maor Shlomo：Lenny's Podcast, TechCrunch 2025-06-18, Reddit AMA

上一篇写了大型企业的 Agent 落地。这篇换个角度——中小团队怎么用 AI Agent。

两个案例：知乎 B 端团队用 Cursor 的完整踩坑过程（含从失败到成功的转折点），以及 Dify 开源平台如何帮助中型企业搭建智能客服+知识库系统。

案例一：知乎 B 端团队 × Cursor — 从抗拒到全团队采纳

背景

知乎是国内最大的问答/知识社区平台。B 端（企业服务）产品开发团队负责知乎的商业化功能——广告系统、创作者工具、企业号管理等。

2024 年 11 月，团队第一次尝试 Cursor，结果很差，几乎放弃。直到 2025 年 2 月 Claude 模型升级后重新尝试，才找到正确的使用方式，最终全团队采纳。

时间线：从失败到成功的转折

graph LR
    subgraph 2024-11
        A[首次尝试 Cursor<br/>Vibe Coding 阶段<br/>兴奋→混乱→放弃]
    end

    subgraph 2025-01
        B[观察期<br/>个别成员继续探索<br/>总结失败原因]
    end

    subgraph 2025-02
        C[模型升级<br/>Claude 新版本发布<br/>代码质量跃升]
    end

    subgraph 2025-03
        D[全团队推广<br/>制定使用规范<br/>建立最佳实践]
    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（凭感觉写代码）：

graph TB
    subgraph 错误模式-Vibe-Coding
        V1[随意描述需求<br/>AI 你看着办]
        V2[AI 生成一大段代码<br/>不看直接 Accept]
        V3[跑通了！<br/>但代码质量差]
        V4[需求变更<br/>AI 重新生成]
        V5[代码越来越乱<br/>无法维护]
        V6[最终放弃<br/>回到手写]
    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：

graph TB
    subgraph 正确模式-Planned-Mode
        P1[先写 .cursorrules<br/>定义项目规范]
        P2[详细描述需求<br/>包含边界条件]
        P3[AI 生成代码后<br/>逐行 Review]
        P4[小步提交<br/>每个功能点一个 commit]
        P5[Code Review 流程<br/>AI 代码也要过审]
        P6[持续迭代<br/>可控地优化]
    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. 使用模式选择

3. Git 工作流

graph LR
    A[开始任务前<br/>git stash 保存当前状态] --> B[用 Cursor 完成任务]
    B --> C{代码质量检查}
    C -->|通过| D[小步 commit<br/>描述清楚改了什么]
    C -->|不通过| E[回滚到上一步<br/>重新描述需求]
    D --> F[Push + PR]
    F --> G[Code Review<br/>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+，知识文档上万篇。

架构设计

graph TB
    subgraph 知识层
        DOC[文档上传<br/>TXT/DOCX/PDF/MD/HTML]
        CHUNK[分块 Chunking<br/>智能分段]
        EMB[向量嵌入 Embedding]
        VDB[向量数据库<br/>相似度检索]
    end

    subgraph 应用层-Dify-Workflow
        INTENT[意图分类节点<br/>订单查询/产品咨询/售后/投诉]
        RETRIEVE[知识检索节点<br/>Top-K 检索]
        LLM[LLM 生成节点<br/>带变量模板]
        JUDGE{判断节点<br/>是否需要人工}
    end

    subgraph 集成层
        API[REST API<br/>对接 CRM/ERP]
        WEB[网站嵌入组件<br/>客服窗口]
        HAND[人工转接<br/>上下文传递]
    end

    subgraph 模型路由
        M1[简单问题→低成本模型<br/>GPT-3.5/Qwen-Turbo]
        M2[复杂问题→高能力模型<br/>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. 涉及退款的场景，引导到人工客服

模型路由：成本优化

graph LR
    INPUT[用户问题] --> CLASSIFY{复杂度判断}
    CLASSIFY -->|简单<br/>FAQ类| LOW[低成本模型<br/>GPT-3.5/Qwen-Turbo<br/>¥0.002/次]
    CLASSIFY -->|复杂<br/>需要推理| HIGH[高能力模型<br/>GPT-4/Qwen-Max<br/>¥0.05/次]
    CLASSIFY -->|敏感<br/>涉及金钱| HUMAN[人工客服]

    LOW --> REPLY[回复用户]
    HIGH --> REPLY
    HUMAN --> REPLY

    style LOW fill:#c8e6c9
    style HIGH fill:#fff3e0
    style HUMAN fill:#ffebee

通过模型路由，约 60% 的问题走低成本模型，整体推理成本控制在可接受范围。

部署方案

Dify 支持多种部署方式，国内企业常用的是阿里云 SAE 一键部署：

结果（综合多个 Dify 生产用户）

两个案例的共同经验

给中小团队的落地建议

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 编程工具前沿论坛
• 百度智能云、阿里云、火山引擎官方技术博客

上一篇写了 Nubank、Anthropic、OpenAI 三个国外案例。有读者问：国内的呢？

这篇专门讲国内。三个案例分别来自零售（周黑鸭）、电商（抖音电商）和消费电子（OPPO），都是已经上线运行的生产系统，不是 PPT。

每个案例包含：遇到什么问题 → 怎么设计架构 → Agent 扮演什么角色 → 配了什么工具 → 效果如何。

案例一：周黑鸭 × 实在智能 — 600 小时/月对账自动化

背景：50 个平台、90 个系统的数据孤岛

周黑鸭是港股上市的休闲零食连锁品牌，全国上千家门店。它的业务同时入驻了 50+ 电商平台（美团、饿了么、抖音、京东等），内部有 约 90 个系统（ERP、WMS、CRM、BI 等）。

每月财务对账时，员工需要在几十个系统之间来回切换：

• 从电商平台导出订单数据
• 从 ERP 导出库存数据
• 从 WMS 导出物流数据
• 人工逐笔核对、标记差异
• 发现异常后再回到对应系统查证

每月对账耗时约 600 小时，涉及 8 名财务人员全职投入。

架构设计

graph TB
    subgraph 数据源
        P1[50+ 电商平台<br/>美团/饿了么/抖音/京东]
        P2[ERP 系统<br/>SAP/金蝶]
        P3[WMS 仓储系统]
        P4[CRM 会员系统]
        P5[BI 报表系统]
    end

    subgraph Agent-核心决策层
        TARS[TARS 垂直大模型<br/>决策中心]
        PLAN[任务规划引擎<br/>自然语言→步骤分解]
        JUDGE[异常判断引擎<br/>数据差异检测]
    end

    subgraph 执行层-RPA引擎
        RPA[RPA 自动化引擎<br/>非侵入式 UI 操作]
        ISSUT[ISSUT 屏幕语义理解<br/>视觉识别+语义解析]
        HEAL[自愈机制<br/>UI 变化自动适应]
    end

    subgraph 输出
        R1[自动对账报告]
        R2[异常标记+原因分析]
        R3[自动触发补货/调拨]
    end

    P1 --> RPA
    P2 --> RPA
    P3 --> RPA
    P4 --> RPA
    P5 --> RPA

    RPA --> ISSUT
    ISSUT --> TARS
    TARS --> PLAN
    TARS --> JUDGE
    HEAL --> RPA

    JUDGE --> R1
    JUDGE --> R2
    JUDGE --> R3

    style TARS fill:#fff3e0
    style RPA fill:#e3f2fd
    style HEAL fill:#e8f5e9

核心技术：非侵入式操作 + 自愈机制

传统自动化需要对接 API，但周黑鸭的 90 个系统中很多没有开放 API。实在智能的方案是：

非侵入式操作 — Agent 像"数字员工"一样，通过视觉识别操作电脑界面：

• 识别屏幕上的按钮、输入框、表格
• 模拟人类的点击、输入、复制粘贴操作
• 不需要任何 API 接口或系统改造

自愈机制（关键创新）：

graph LR
    A[UI 发生变化<br/>按钮位置移动] --> B{ISSUT 视觉识别}
    B -->|语义匹配成功| C[定位新位置<br/>继续执行]
    B -->|匹配失败| D[暂停任务<br/>通知人工]
    D --> E[人工标注新位置]
    E --> F[更新视觉模型]
    F --> C

    style C fill:#c8e6c9
    style D fill:#ffebee

比如"提交"按钮从页面左侧移到右侧，传统 RPA 会报错停止。但 ISSUT 通过语义理解（识别"提交"这个词的含义）自动找到新位置，任务不中断。

Agent 角色分工

结果

同平台案例 — 太平鸟（服装零售）：30 家门店、1000+ 数据类型自动化后，人工干预从全职降到每周仅 1 小时，效率提升 300%+，成本降低 80%。

案例二：抖音电商 × 扣子(Coze) — 多 Agent 协作客服系统

背景：关键词匹配客服的瓶颈

抖音电商的商家客服面临三个痛点：

1. 传统客服机器人靠关键词匹配，不配置就回复不了，灵活性差
2. 机械式单轮问答，无法理解上下文，经常答非所问
3. 大促期间咨询量暴增，人工排队时间长，流失率高

架构设计：多 Agent 流水线

抖音电商没有用一个"万能 Agent"，而是把客服流程拆成多个专业 Agent 协作：

graph TB
    USER[用户消息] --> GREET[寒暄收尾 Agent<br/>识别问候/感谢/告别]

    GREET --> CLARIFY[问题澄清 Agent<br/>补充缺失信息<br/>确认用户意图]

    CLARIFY --> ROUTE{场景路由 Agent<br/>意图分类}

    ROUTE -->|订单查询| S1[订单状态查询<br/>对接订单系统]
    ROUTE -->|物流咨询| S2[物流信息查询<br/>对接物流系统]
    ROUTE -->|售后问题| S3[售后服务 Agent<br/>退款/换货/维修]
    ROUTE -->|产品咨询| S4[产品推荐 Agent<br/>属性+知识库匹配]
    ROUTE -->|投诉建议| S5[人工转接<br/>情感识别触发]

    S1 --> JUDGE[判断解决方案 Agent<br/>评估回复质量+风险]
    S2 --> JUDGE
    S3 --> JUDGE
    S4 --> JUDGE

    JUDGE --> EXEC[协商执行 Agent<br/>生成最终回复]
    EXEC -->|低风险| REPLY[自动回复用户]
    EXEC -->|高风险| HUMAN[人工审核]

    HUMAN --> REPLY

    style ROUTE fill:#fff3e0
    style JUDGE fill:#e8f5e9
    style HUMAN fill:#ffebee

Agent 角色定义

每个 Agent 有明确的职责边界：

人机协作模型

抖音电商设计了一个**"有效干预率"**指标来评估人机协作质量：

graph LR
    subgraph 评估维度
        A[AI 回复质量<br/>准确率/满意度]
        B[人工干预必要性<br/>干预是否真的有用]
        C[自学习效果<br/>干预后 AI 是否改善]
    end

    A --> SCORE[有效干预率<br/>综合评分]
    B --> SCORE
    C --> SCORE

    SCORE -->|高| GOOD[模型表现好<br/>减少人工干预]
    SCORE -->|低| BAD[需要优化<br/>增加训练数据]

    style SCORE fill:#fff3e0

关键创新：不只评估 AI 的表现，还评估人工干预是否真的有必要——避免"过度纠正"反而降低效率。

结果

• 部分场景实现全自动处理，无需人工介入
• Agent 越用越聪明，回答准确率持续提升
• 解决方案已开源到扣子模板商店：coze.cn/s/uM1e-yIzEzo
• 探域科技等多家企业基于同一架构搭建了定制化客服方案

案例三：OPPO × 百度文心智能体 — 多语种智能客服

背景：全球化客服的语言壁垒

OPPO 在东南亚市场（越南、印尼等）面临客服挑战：

• 用户用口语化表达描述手机问题，传统 FAQ 匹配不到
• 客服回复使用技术术语，用户听不懂
• 越南语、印尼语等小语种客服人力稀缺
• 服务质量完全依赖个别老员工经验，无法复制

架构设计

graph TB
    subgraph 用户触点
        U1[中文用户]
        U2[越南语用户]
        U3[印尼语用户]
    end

    subgraph 知识层
        KB[10万+ 篇服务经验文章<br/>RAG 检索增强]
        EMB[向量嵌入引擎]
        RET[Top-K 相似度检索]
    end

    subgraph Agent-推理层
        LLM[文心大模型<br/>芯云模体全栈基础设施]
        NLU[口语理解模块<br/>技术术语→通俗解释]
        ML[多语言生成模块<br/>中/越/印尼语]
    end

    subgraph 输出
        R1[通俗中文回复]
        R2[越南语回复]
        R3[印尼语回复]
    end

    U1 --> KB
    U2 --> KB
    U3 --> KB

    KB --> EMB --> RET --> LLM
    LLM --> NLU --> ML

    ML --> R1
    ML --> R2
    ML --> R3

    style KB fill:#e3f2fd
    style LLM fill:#fff3e0
    style ML fill:#e8f5e9

核心突破：从"个人经验"到"企业资产"

OPPO 之前最大的痛点是：优秀的客服经验锁在老员工脑子里。

通过文心智能体的 RAG 架构，10 万+ 篇历史服务案例被转化为可检索、可复用的企业知识资产：

graph LR
    subgraph 之前
        A[老员工经验<br/>不可复制<br/>离职即流失]
        B[知识碎片化<br/>散落在各系统]
        C[新人培训慢<br/>3-6 个月上手]
    end

    subgraph 之后
        D[10万+ 知识条目<br/>结构化存储]
        E[实时检索<br/>秒级匹配]
        F[新人即插即用<br/>Agent 辅助回复]
    end

    A --> D
    B --> E
    C --> F

    style D fill:#c8e6c9
    style E fill:#c8e6c9
    style F fill:#c8e6c9

结果

同平台其他案例：

• 银河证券：交易 Agent 将询价到下单转化效率提升 3x
• 百信银行：风控 Agent 用 LLM 自进化风险特征，显著提升识别率
• 阿尔特汽车：气动 Agent 将风阻测试从 10 小时 → 分钟级

三个案例的共同启示

graph TB
    subgraph 启示一-选择正确的切入点
        I1[周黑鸭：选了最耗人力<br/>的重复性对账任务]
        I2[抖音：选了咨询量最大<br/>的客服场景]
        I3[OPPO：选了人才最缺<br/>的小语种服务]
    end

    subgraph 启示二-人机协作不是全自动
        I4[关键决策仍由人做<br/>Agent 执行+建议]
        I5[有效干预率指标<br/>量化人机协作质量]
        I6[持续反馈循环<br/>Agent 越用越准]
    end

    subgraph 启示三-非侵入式部署
        I7[不改造现有系统<br/>Agent 通过 UI 操作]
        I8[视觉识别+语义理解<br/>适应 UI 变化]
        I9[零代码拖拽设计<br/>业务人员可配置]
    end

    I1 --> I4 --> I7
    I2 --> I5 --> I8
    I3 --> I6 --> I9

    style I1 fill:#e3f2fd
    style I4 fill:#fff3e0
    style I7 fill:#e8f5e9

国内 AI Agent 落地的三个实用建议

1. 从"数字员工"思维开始 — 不要想着 AI 取代人，而是设计一个"数字员工"做最枯燥的部分。周黑鸭的 600 小时对账就是典型的"没人愿意做但必须做"的任务。

2. 优先选非侵入式方案 — 国内企业系统复杂（ERP/WMS/CRM 五花八门），API 对接成本极高。实在智能的视觉识别方案证明：不碰系统内部，只操作界面，反而是更务实的路径。

3. 知识资产化比自动化更重要 — OPPO 的案例最有价值的一步不是"自动回复"，而是把 10 万篇经验文档变成了可检索的知识库。从"人在做"到"Agent 读了再做"，这是质变。

数据来源：

• 周黑鸭 × 实在智能：ai-indeed.com 官方案例、CSDN 技术详解
• 抖音电商 × 扣子：火山引擎开发者社区 (developer.volcengine.com)
• OPPO × 百度文心：科技日报 2026-03 报道、百度智能云案例
• 太平鸟/银河证券/百信银行/阿尔特汽车：百度智能云年度报告

这不是又一篇「AI Agent 很酷」的泛泛介绍。

下面三个案例来自 Nubank（1.1 亿用户的拉美最大数字银行）、Anthropic（Claude 的创造者）和 OpenAI（Codex 的创造者）。每个案例都包含：他们遇到了什么问题 → 怎么设计架构 → Agent 扮演什么角色 → 配了什么工具链 → 最终效果如何。

所有数据来自官方博客、技术演讲和已公开文档。

案例一：Nubank × Devin — 10 万级 Clojure 代码迁移

背景：一个不可能的人工任务

Nubank 是拉丁美洲最大的数字银行，拥有超过 1.1 亿用户。他们的核心 ETL 系统是一个 8 年历史、600 万行 Clojure 代码的单体应用，需要拆分为子模块。

拆分意味着要迁移 约 10 万个数据类实现（data class implementations），依赖链深达 70 层。

初步估算：1000+ 工程师，耗时 18 个月。

这些任务有个特点——太复杂无法脚本化（每种迁移都有不同变体和边界情况），但量太大无法人工完成。

架构设计

Nubank 和 Cognition（Devin 的开发团队）一起设计了一套「微调 + 评估 + 人机协作」的闭环架构：

graph TB
    subgraph 阶段一-冷启动
        A[工程师手动完成<br/>一批迁移样本] --> B[拆分训练集/评估集]
        B --> C[用训练集微调 Devin]
        B --> D[用评估集建立基准线<br/>cognition-golden]
    end

    subgraph 阶段二-生产循环
        E[Devin 自主执行迁移任务] --> F[自动分析源码<br/>解析 70 层依赖链]
        F --> G[重写数据类实现]
        G --> H[运行测试验证]
        H --> I[提交 PR]
        I --> J[工程师审查 PR]
        J -->|需要调整| K[人工修正并合并]
        J -->|直接通过| K
        K -->|新样本反馈| L[更新训练数据]
        L --> C
    end

    C --> E
    D --> M[持续评估任务完成率]

    style A fill:#e8f4f8
    style E fill:#fff3e0
    style J fill:#e8f5e9

Agent 角色：Devin 具体做了什么

每个数据类迁移是一个独立的 Devin 任务，执行流程如下：

sequenceDiagram
    participant H as 人类工程师
    participant D as Devin Agent
    participant R as 代码仓库
    participant T as 测试系统

    H->>D: 分配迁移任务<br/>(源模块 + 目标模块)

    D->>R: 读取源数据类代码
    D->>R: 分析 70 层依赖链
    D->>D: 自主构建辅助脚本<br/>(如自动识别国家扩展名)

    Note over D: Devin 自我工具化<br/>把多步操作封装为<br/>单一可执行脚本

    D->>R: 重写数据类到目标模块
    D->>T: 运行单元测试
    T-->>D: 测试结果

    alt 测试通过
        D->>R: 提交 PR
        R-->>H: PR 审查通知
        H->>R: Approve & Merge
    else 测试失败
        D->>D: 分析失败原因<br/>自主修复
        D->>T: 重新运行测试
    end

Devin 的一个独特行为：自我工具化（Self-tooling）

Devin 在执行过程中会自主编写辅助脚本来加速后续工作。例如，它发现需要从文件路径中识别国家代码（br/co/mx），于是自己写了一个脚本把这个多步判断变成单次调用。这种"元工具"行为是传统脚本无法做到的。

关键技术细节

结果

Jose Carlos Castro（Nubank 高级 PM）原话： "Devin provided an easy way to reduce the number of engineering hours for the migration, in a way that was more stable and less prone to human error."

案例二：Anthropic × Claude Code — 132 名工程师的内部实践

背景：造工具的人怎么用工具

Anthropic 研究了自己 132 名工程师 横跨 10 个部门使用 Claude Code 的实际数据。这不是概念验证——是他们真实的日常工作流。

系统架构

graph TB
    subgraph 文档层
        CL[CLAUDE.md<br/>仓库级文档<br/>架构约定+工作流]
        SC[自定义 Slash 命令<br/>安全团队用了 50% 的全部命令]
        SK[Skills<br/>可复用的能力包]
    end

    subgraph Agent层
        CC[Claude Code<br/>终端 Agent]
        AA[Auto-accept 模式<br/>自主循环：写码→测试→迭代]
        PA[并行实例<br/>多个 Agent 同时在不同仓库工作]
    end

    subgraph 安全层
        MC[MCP Server<br/>安全数据访问层<br/>带日志和隐私控制]
    end

    subgraph 集成层
        GA[GitHub Actions<br/>自动处理 PR 评论]
        GR[Git 集成<br/>检查点提交 + PR 修复]
    end

    CL --> CC
    SC --> CC
    SK --> CC
    MC --> CC
    CC --> GA
    CC --> GR
    CC --> AA
    CC --> PA

    style CL fill:#e3f2fd
    style CC fill:#fff3e0
    style MC fill:#fce4ec

10 个团队的真实用法

graph LR
    subgraph 自主执行模式
        PD[产品开发<br/>Vim 模式开发<br/>70% 代码 AI 写]
        GM[增长营销<br/>双 Agent 协作<br/>100 条广告变体/0.5秒]
    end

    subgraph 同步协作模式
        DI[数据基础设施<br/>K8s 截图→诊断<br/>故障定位 50%↓]
        SE[安全工程<br/>调试 15min→5min<br/>自定义命令密集使用]
    end

    subgraph 知识提取模式
        DS[数据科学<br/>新员工代码库导航<br/>替代传统数据目录]
        IN[推理团队<br/>调研时间↓80%<br/>1小时→10-20分钟]
    end
    subgraph 非技术团队
        LG[法务团队<br/>无工程支持<br/>自建无障碍工具]
        PD2[产品设计<br/>快速原型验证]
    end

    style PD fill:#c8e6c9
    style GM fill:#c8e6c9
    style DI fill:#fff9c4
    style SE fill:#fff9c4
    style DS fill:#e1bee7
    style IN fill:#e1bee7

重点场景：增长营销的双 Agent 广告生成系统

这个场景特别值得展开——它展示了多个 Agent 分工协作的生产级架构：

graph TB
    subgraph 输入
        CSV[广告数据 CSV<br/>数百条广告素材]
        FIG[Figma 插件<br/>设计模板]
    end

    subgraph Agent1-分析
        A1[读取 CSV]
        A2[识别低效广告<br/>按 ROI/点击率排序]
        A3[生成优化建议<br/>标题+描述]
    end

    subgraph Agent2-创意
        B1[接收分析结果]
        B2[生成 30 字标题变体]
        B3[生成 90 字描述变体]
        B4[调用 Figma 插件<br/>渲染广告图]
    end

    subgraph 输出
        OUT[100 条广告变体<br/>0.5 秒/批次]
    end

    CSV --> A1 --> A2 --> A3 --> B1
    FIG --> B4
    B1 --> B2 --> B3 --> B4 --> OUT

    style A2 fill:#fff3e0
    style B4 fill:#e8f5e9
    style OUT fill:#c8e6c9

技术细节：

• 分析 Agent：处理 CSV → 按 ROI 排序 → 标记低效广告 → 生成变体策略
• 创意 Agent：根据策略生成 30 字标题 + 90 字描述 → 调用 Figma 插件批量渲染
• Figma 插件：100 条广告变体，每批次 0.5 秒
• 之前这个流程需要营销团队手工逐条制作，耗时数小时

三种经过验证的采用模式

Anthropic 总结了三种成功模式，适用于任何想引入 AI Agent 的团队：

结果

案例三：OpenAI × Codex — 一个自己写自己的 Agent

背景：造 Agent 的终极测试

OpenAI 的 2025 年最高目标是构建一个自主软件工程师（aSWE）。Codex 团队的终极验证方式：用 Codex 开发 Codex。

目前 Codex 每周有超过 100 万活跃开发者，自 CLI 发布以来使用量增长 20 倍。

核心架构：状态机 Agent 循环

graph TB
    INPUT[用户输入] --> PA[提示词组装]
    
    PA --> MI[模型推理]
    
    MI --> ER{需要调用工具？}
    ER -->|是| TE[执行工具<br/>文件读写/终端/Git/代码搜索]
    ER -->|否| FR[最终响应输出]
    
    TE --> MI
    
    subgraph NOTES [提示词优先级]
        N1[1. 系统消息 - 服务端控制]
        N2[2. 工具定义 - 客户端提供]
        N3[3. 开发者指令]
        N4[4. 用户消息]
    end
    
    NOTES -.-> PA

    style INPUT fill:#e3f2fd
    style TE fill:#fff3e0
    style FR fill:#c8e6c9

指令级联系统（AGENTS.md 解析）

Codex 有一个精密的指令解析机制，确保 Agent 在不同项目中都能获得正确上下文：

graph TB
    A["AGENTS.override.md<br/>或 AGENTS.md<br/>在 $CODEX_HOME"] --> B["Git 仓库根目录<br/>AGENTS.md"]
    B --> C["当前工作目录<br/>AGENTS.md"]
    C --> D["Skills 指令<br/>（可复用能力包）"]
    D --> E["Config.toml<br/>开发者指令"]

    F["32 KiB 默认上限<br/>聚合指令总大小"] -.-> E

    style A fill:#e3f2fd
    style D fill:#fff3e0
    style F fill:#ffebee

性能优化：让 Agent 跑得快

两个关键优化让 Codex 能处理数百次模型-工具迭代：

graph LR
    subgraph 优化一-前缀缓存
        P1[旧 Prompt] --> P2[新 Prompt]
        P2 -.->|"旧 Prompt 是新 Prompt<br/>的精确前缀"| PC[缓存命中<br/>线性而非二次成本]
    end

    subgraph 优化二-对话压缩
        C1[对话历史<br/>超过 token 阈值] --> C2[Responses API<br/>生成压缩表示]
        C2 --> C3[继续对话<br/>用压缩版本]
    end

    style PC fill:#c8e6c9
    style C2 fill:#fff9c4

内部工作流：每个工程师 4-8 个并行 Agent

graph TB
    ENG[工程师] --> AG1[Agent 1<br/>功能实现]
    ENG --> AG2[Agent 2<br/>代码审查]
    ENG --> AG3[Agent 3<br/>安全审查]
    ENG --> AG4[Agent 4<br/>代码库理解]
    ENG --> AG5[Agent 5<br/>计划摘要]
    ENG --> AG6[Agent 6<br/>变更摘要]

    AG1 --> PR[Pull Request]
    AG2 --> PR
    AG3 --> PR

    PR --> AIR[AI 代码审查<br/>自动触发<br/>~90% 有效评论]
    AIR --> HR[人工审查<br/>聚焦 AI 标记的问题]
    HR --> MG[Merge]

    style ENG fill:#e3f2fd
    style AIR fill:#fff3e0
    style MG fill:#c8e6c9

100+ 内部 Agent Skills 示例

结果

三个案例的共同模式

把三个案例放在一起看，会发现一个清晰的模式：

graph TB
    subgraph 1-架构设计阶段
        S1[定义 Agent 边界<br/>哪些任务适合 Agent]
        S2[建立评估体系<br/>如何量化效果]
        S3[设计人机协作流程<br/>人做什么/Agent 做什么]
    end

    subgraph 2-冷启动阶段
        S4[提供高质量上下文<br/>CLAUDE.md / 微调 / AGENTS.md]
        S5[从小任务开始<br/>外围功能 > 核心逻辑]
        S6[建立反馈循环<br/>人工修正 → 训练数据]
    end

    subgraph 3-扩展阶段
        S7[并行运行多 Agent<br/>4-8 个同时工作]
        S8[构建 Skills 库<br/>100+ 可复用能力]
        S9[全流程集成<br/>PR 审查 + CI/CD + 监控]
    end

    S1 --> S4 --> S7
    S2 --> S5 --> S8
    S3 --> S6 --> S9

    style S1 fill:#e3f2fd
    style S4 fill:#fff3e0
    style S7 fill:#e8f5e9

给想落地 AI Agent 的团队的建议

1. 从文档开始，不要从代码开始 — Anthropic 的经验表明，写好 CLAUDE.md / AGENTS.md 比写代码更重要。Agent 需要上下文，就像新人需要读文档。

2. 设计人机协作流程，而不是追求全自动 — Nubank 的成功不是让 Devin 全自动迁移，而是让工程师从「执行者」变成「审查者」。27% 的 Anthropic 工程师做了"没有 AI 就不会做的事"——这意味着 Agent 不是替代人，而是让人做以前做不到的事。

3. 建立评估体系 — Nubank 建了 cognition-golden 评估集，OpenAI 有 ~90% 有效率的 AI 代码审查。没有度量就没有改进。

4. 让 Agent 自己造工具 — Devin 的自我工具化行为、Codex 的 100+ Skills 库，都指向同一个方向：最好的 Agent 工作流是 Agent 自己设计的。

5. 选对语言/框架 — Codex 选择 Rust 是因为性能和正确性；Claude Code 选择 MCP 是因为安全控制。技术选型要匹配你的约束。

数据来源：

• Nubank × Devin: devin.ai/customers/nubank, Nubank Engineering Blog, Clojure Conj 2024
• Anthropic × Claude Code: cdn.anthropic.com, Anthropic Research Blog (Dec 2025)
• OpenAI × Codex: Pragmatic Engineer Newsletter, Ars Technica, github.com/openai/codex

这是过去两年被讨论最多的问题。简短的回答是：不会，但程序员的定义会改变。

更准确地说，被改变的不仅是程序员这个职业，而是「编程」这件事本身。我们正在经历从「写代码」到「设计系统」的范式转移。

从编码者到架构师

过去的程序员

传统软件开发中，程序员大部分时间花在：

• 编写重复性的样板代码（Boilerplate）
• 调试语法错误和类型错误
• 查阅文档和 API 参考
• 编写单元测试
• 处理依赖和配置

这些工作中，很大一部分正在被 AI 自动化。但这并不意味着程序员不再被需要——恰恰相反，它释放了程序员去做更有价值的工作。

未来的程序员

AI 时代的程序员，核心能力将从「写代码」转向：

• 系统设计：定义系统的整体架构和关键决策
• 需求理解：将模糊的业务需求转化为清晰的技术方案
• 质量把关：审阅 AI 生成的代码，确保质量和安全
• 创新探索：尝试新的技术方案，寻找最优解

用一句话概括：程序员将从「代码生产者」进化为「系统设计师」。

人机协作的三个层次

层次一：AI 作为工具

这是目前大多数人使用 AI 编程工具的方式：

• AI 补全代码
• AI 生成测试
• AI 解释错误信息

人是完全的主导者，AI 是工具。协作模式是单向的：人 → AI。

层次二：AI 作为搭档

随着 Agent 类工具的成熟，协作进入双向模式：

• 人描述目标和约束
• AI 提出实现方案
• 人审阅和调整
• AI 执行实现

这种模式下，人和 AI 形成了真正的协作循环。每个人发挥自己的优势：人负责判断和创意，AI 负责执行和检索。

层次三：AI 作为团队

未来的终极形态可能是：

• 人类定义产品愿景和核心价值
• AI Agent 团队分工协作，完成从设计到部署的全流程
• 人类作为「技术总监」角色，把控方向和质量

这个图景并不遥远——Devin 等 AI 已经展示了自主完成完整开发任务的能力。

新技能树

在这个新范式中，程序员需要培养的技能也在变化：

变得更重要的技能

• 系统思维：理解复杂系统的整体设计
• Prompt Engineering：精确表达需求，引导 AI 产出高质量代码
• 代码审阅：快速审阅和理解大量 AI 生成的代码
• 安全意识：识别 AI 可能引入的安全隐患
• 业务理解：将业务需求转化为技术方案的能力

逐渐弱化的技能

• 语法记忆：不需要记住每个 API 的具体用法
• 样板代码编写：重复性代码由 AI 生成
• 手动调试：AI 能快速定位和修复常见错误

教育的变革

传统的计算机科学教育以「教学生写代码」为核心。但在 AI 时代，教育需要转向：

1. 计算思维：如何将问题分解为可计算的步骤
2. 系统设计：如何在多个可行方案中做出权衡
3. AI 协作：如何有效地与 AI 工具协作
4. 批判性思维：如何审阅和验证 AI 的输出

这并不意味着编程基础不重要——恰恰相反，理解底层原理对于审阅 AI 代码至关重要。但学习的重点将从「如何写」转向「如何判断」。

潜在风险与应对

人机协作的新范式也带来了一些风险：

过度依赖

如果开发者完全依赖 AI 而不理解代码背后的原理，一旦 AI 出错，他们将无法发现和修复。

应对策略：保持学习，把 AI 产出当作学习材料，而不仅仅是黑箱工具。

安全隐患

AI 可能生成看起来正确但包含安全漏洞的代码。

应对策略：建立 AI 代码审阅流程，使用自动化安全扫描工具。

创意枯竭

如果所有初步方案都由 AI 生成，人类的创造力是否会退化？

应对策略：将 AI 视为灵感的起点，而不是终点的决定者。

小结

编程的未来不是 AI 替代人类，而是人类和 AI 各自发挥优势的协作模式。在这个新范式中：

• 程序员的价值不在于能写多少代码，而在于能设计多好的系统
• AI 的价值不在于能替代多少程序员，而在于能放大多少创造力
• 最好的软件将由懂得利用 AI 的人类创造

这个系列从 AI 编程工具的进化历史出发，探讨了工具选择和未来趋势。希望这些内容能帮助你在 AI 时代的软件开发中找到自己的定位和方向。

未来已来，让我们一起拥抱人机协作的新范式。

2026 年的 AI 编程工具已经形成清晰的三层架构：

┌─────────────────────────────────────────┐
│          Layer 3: AI Agents              │
│   自主代理——任务分配、多步执行、自我改进    │
│   Hermes Agent · OpenClaw · Devin        │
├─────────────────────────────────────────┤
│          Layer 2: AI Coding Systems      │
│   编程系统——多文件编辑、测试、Git 操作     │
│   Claude Code · Codex CLI · OpenCode     │
├─────────────────────────────────────────┤
│          Layer 1: AI-Assisted IDEs       │
│   辅助编辑器——补全、聊天、内联建议         │
│   Cursor · Copilot · Windsurf · Cline    │
└─────────────────────────────────────────┘

每一层都在迅速演进，而且层与层之间的边界正在模糊。让我们逐层深入。

Layer 1：AI 辅助编辑器

GitHub Copilot —— 市场之王

市场份额：42% | 用户数：数百万

GitHub Copilot 仍然是 AI 编程工具市场的绝对王者。2026 年的关键更新：

• Agent Mode：Copilot 可以自主执行多步任务
• Issue → PR 工作流：分配一个 Issue 给 Copilot，它自动完成编码并提交 PR
• 免费层：2,000 次补全/月，50 次聊天
• Pro：$10/月，企业版 $39/用户/月

Copilot 的优势在于生态和合规——它被集成到 VS Code、JetBrains、Neovim 等几乎所有主流编辑器中，并且通过了企业级的安全审计。

Cursor —— AI 原生先锋

用户数：100 万+ | 付费用户：36 万

详见 Cursor 专题文章。核心亮点：

• VS Code Fork，AI 原生集成
• Supermaven 补全引擎
• Composer 多文件编辑
• $20/月 Pro 计划

Windsurf（原 Codeium）—— 隐私优先

定位：隐私友好的 AI 编辑器

Windsurf 是 Codeium 的进化版，基于 VS Code 构建，主打：

• Cascade：AI 流式交互系统，理解开发者的实时操作
• Devin 集成：Kanban 风格管理本地和云端 AI 代理
• 隐私控制：更好的数据处理透明度
• 价格：$15/月 Pro 计划

Cline —— 开源 VS Code 插件

GitHub Stars：40k+ | 开源协议：Apache 2.0

Cline 是 VS Code 生态中最受欢迎的开源 AI 编程助手。2026 年已扩展为多平台：

• VS Code 扩展：编辑器内 AI 助手
• JetBrains 插件：IntelliJ、PyCharm、WebStorm 等
• CLI：命令行模式
• Kanban：Web 界面并行管理多个 Agent
• SDK：构建自定义 AI 代理

Cline 的核心优势是模型自由——支持 OpenAI、Anthropic、Google、Ollama 等几乎所有模型提供商。而且它是完全开源的。

Layer 2：AI 编程系统

Claude Code —— 最强的单一模型代理

详见 Claude Code 专题文章。

Anthropic 出品的 CLI 编程系统，以深度代码库理解和跨文件编辑著称。缺点是模型锁定在 Claude 系列。

OpenCode → Crush —— 终端 AI 的巅峰

详见 OpenCode 专题文章。

75+ 模型提供商、精美 TUI、LSP 集成。已从 OpenCode 演进为 Charm 团队的 Crush 项目。

Aider —— 老牌终端工具

GitHub Stars：39k | 安装量：410 万+

Aider 是终端 AI 编程工具的先驱之一：

• 支持几乎所有 LLM
• 与 Git 深度集成（每个修改都是一个 commit）
• 支持多个编辑器（通过 editor 配置）
• 命令行原生，无 TUI

虽然界面不如 OpenCode 精美，但稳定性和成熟度是它的优势。

Codex CLI（OpenAI）

OpenAI 的官方 CLI 编程工具，基于 Codex 模型：

• 集成在 ChatGPT 订阅中
• 支持沙箱化代码执行
• 与 OpenAI 生态深度绑定
• Apache 2.0 开源

Layer 3：AI 自主代理

Hermes Agent —— 自进化的代理框架

详见 Hermes Agent 专题文章。

Nous Research 出品，具备持久记忆、自主技能创建、定时自动化和跨平台消息。代表了「AI 代理随你成长」的理念。

OpenClaw —— 社区讨论度最高的代理

OpenClaw 是 2026 年开源 AI 代理领域讨论度最高的项目之一，但它的安全记录（CVE、供应链事件）也引发了广泛担忧。

Devin —— 商业化代理的标杆

Cognition 出品的 Devin 是第一个引起广泛关注的 AI 软件工程师。它现在已集成到 Windsurf 编辑器中。

OpenHands —— 学术背景的代理

前身是 OpenDevin，一个来自学术界的开源 AI 软件工程师代理框架。支持多种 LLM 和工具集成。

中国市场特色工具

中国 AI 编程工具市场也有独特的产品：

通义灵码（Tongyi Lingma）

阿里云出品，基于通义千问大模型：

• VS Code / JetBrains 插件
• 支持中文注释生成代码
• 企业版支持私有化部署
• 免费使用

CodeGeeX

智谱 AI 出品，基于 GLM 模型：

• 开源（部分组件）
• 支持多种编程语言
• 中英文混合提示效果好

豆包/MarsCode

字节跳动出品的 AI 编程助手：

• 集成在豆包生态中
• 云端 IDE 支持
• 免费额度充足

如何选择？

根据你的需求，这是一个简化的选择指南：

如果你是 VS Code 用户……

• 预算充足 → Cursor Pro（$20/月）
• 预算有限 → VS Code + Copilot Free 或 Cline + 免费 API
• 隐私敏感 → Windsurf 或 Cline + Ollama

如果你偏好终端……

• 模型自由 → OpenCode/Crush
• 最强效果 → Claude Code
• 老牌稳定 → Aider

如果你需要长期 AI 伙伴……

• 自主代理 → Hermes Agent
• 开发工作流 → OpenClaw（注意安全）
• 商业方案 → Devin

趋势与展望

2026 年下半年，我们可以预期：

1. 代理能力持续增强：从辅助编码到独立完成完整功能
2. 多模态融合：AI 不仅能读写代码，还能理解设计图、截图
3. IDE 边界消融：编辑器、终端、浏览器之间的界限越来越模糊
4. 本地模型追赶：开源模型在编程任务上的表现快速接近闭源模型
5. 团队协作 AI：从个人助手扩展到团队级别的 AI 协作

AI 编程工具正在从「锦上添花」变成「不可或缺」。选择适合自己工作流的工具，比追逐最新热点更重要。

本文持续更新中。如果你发现信息有误或有新的工具推荐，欢迎反馈。

Hermes Agent 是由 Nous Research 开发的开源、自进化 AI 代理框架。Nous Research 是 Hermes、Nomos、Psyche 等知名模型家族的幕后团队，而 Hermes Agent 则代表了他们对「AI 代理应当如何工作」这一问题的回答。

与传统聊天机器人不同，Hermes Agent 不只是「一问一答」——它运行在服务器上，作为一个长期存活的代理运行时，具备：

• 持久记忆：跨会话保留上下文，不会因为新对话而丢失信息
• 自主技能创建：完成复杂任务后自动将方法保存为可复用的 Skill
• 定时自动化：通过 Cron 机制安排定期任务，完全自主运行
• 跨渠道消息：同时连接 Telegram、Discord、Slack 等多个平台
• 自我改进循环：从每次交互中学习，不断优化自己的行为

核心架构

Hermes Agent 的设计哲学是在服务器上运行、通过终端或消息应用驱动。它的架构有几个关键设计决策：

1. 服务器端运行

Agent 本身作为服务运行在你的服务器上（支持从 $5 VPS 到多 GPU 集群），你通过 Telegram、Discord 或终端 TUI 与之交互。这意味着：

• Agent 始终在线，可以处理定时任务和事件驱动触发
• 你的代码和数据留在你自己的基础设施上
• 近零空闲成本——不使用时不消耗 GPU 资源

2. 模型无关性

支持几乎所有主流 LLM 提供商：

• 商业模型：OpenAI (GPT-4o/5)、Anthropic (Claude)、Google (Gemini)、xAI (Grok)
• 开源模型：通过 Ollama、vLLM 运行本地模型
• 聚合平台：OpenRouter、自定义 OpenAI 兼容端点
• Nous 自家模型：Hermes 系列模型深度优化

你可以在配置中随时切换模型，甚至为不同任务使用不同模型。

3. Skills 系统

这是 Hermes Agent 最独特的设计之一。当你完成一个复杂任务（比如部署一个监控系统），Agent 会自动将这个工作流保存为一个 Skill——一个包含步骤、命令、注意事项的 Markdown 文件。下次遇到类似任务时，Agent 会自动加载这个 Skill 并遵循已验证的流程。

# Skill 文件示例结构
---
name: deploy-monitoring
trigger: 监控系统部署
steps:
  - 检查服务器环境
  - 安装依赖
  - 配置 Docker Compose
  - 验证部署
pitfalls:
  - NFS v4 不支持 v4.2
  - 容器权限需要与宿主机对齐
---

4. Memory 系统

分为两个层次：

• Session Memory：对话内的上下文管理，包括自动压缩（Auto Compact）机制
• Persistent Memory：跨会话的持久记忆，通过 Mem0 或内置 SQLite 存储用户偏好、项目事实、环境细节

实际使用场景

场景一：DevOps 自动化

# 通过 Telegram 发送指令
"帮我检查所有服务器的磁盘使用情况，超过 80% 的告警"

Agent 会 SSH 到每台服务器、收集数据、格式化报告、发送告警。完成后自动保存为 Skill。

场景二：定时监控

# 设置 Cron 任务
"每天早上 9 点检查 VPS 库存，有货就通知我"

Agent 创建定时任务，每天自动运行脚本，只在有结果时通知你。

场景三：代码开发

# 委派编码任务
"在 PT-Publisher 项目中添加 Nyaa 站点支持"

Agent 可以使用内置的子代理系统（delegate_task）将工作并行拆分给多个子代理，每个子代理在隔离环境中工作。

与其他框架的对比

快速上手

# 安装
pip install hermes-agent

# 初始化
hermes setup

# 启动
hermes start

配置文件位于 ~/.hermes/config.yaml，你可以在这里设置模型提供商、消息渠道连接、技能目录等。

安全考量

Hermes Agent 采取了多层安全设计：

• 终端沙箱：所有 shell 命令在受控环境中执行
• 权限控制：可配置允许/禁止的命令和路径
• 确认机制：危险操作需要用户确认
• 代码透明：完全开源，可审计每一行代码

总结

Hermes Agent 代表了 AI 代理框架的一个新方向：不是一次性工具，而是一个随你成长的长期 AI 伙伴。它的自我改进能力、持久记忆和跨平台集成使其成为个人效率自动化的强大选择。

如果你在寻找一个可以部署在自己的服务器上、通过消息应用随时交互、越用越懂你的 AI 代理框架，Hermes Agent 值得一试。

相关链接：

• GitHub 仓库
• 官方文档
• Nous Research 官网

如果你在团队开发中工作过，你一定遇到过这个经典场景：

「这个 Bug 我本地复现不了啊，在我电脑上是正常的。」

这个问题的根源是环境不一致——每个开发者的本地环境都有微妙差异：不同的操作系统、不同的运行时版本、不同的依赖安装方式。

Docker 和容器化开发环境就是为解决这个问题而生的。

为什么容器化开发？

核心价值

容器化开发环境提供了三个关键价值：

1. 一致性：所有开发者在相同的环境中工作
2. 可复现：环境配置即代码（Infrastructure as Code）
3. 隔离性：不同项目的依赖互不干扰

什么时候需要？

• 团队成员使用不同的操作系统（macOS、Linux、Windows）
• 项目依赖复杂的系统级库（数据库、消息队列等）
• 新成员加入需要快速搭建开发环境
• CI/CD 需要与本地一致的环境

Dev Containers：最佳实践

VS Code 的 Dev Containers 功能是目前最成熟的容器化开发方案。

基本配置

在项目根目录创建 .devcontainer/devcontainer.json：

{
  "name": "My Project",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    }
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
      ]
    }
  },
  "postCreateCommand": "npm install"
}

Docker Compose 配置

配合 docker-compose.yml 使用，可以一次性启动所有依赖服务：

version: '3.8'
services:
  app:
    build:
      context: ..
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: myapp_dev
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:

Dockerfile 最佳实践

FROM node:20-bookworm

# 安装系统依赖
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get install -y \
    git \
    curl \
    postgresql-client \
    && apt-get clean -y

# 设置非 root 用户（安全最佳实践）
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID
RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME

USER $USERNAME

开发工作流

日常开发

使用 Dev Containers 后的日常工作流：

1. 打开项目：VS Code 自动检测并提示在容器中打开
2. 编码：和本地开发体验完全一致
3. 运行/调试：在容器内执行，环境完全一致
4. 测试：连接到容器化的数据库和 Redis

数据库管理

容器化的数据库有几个注意事项：

• 数据持久化：使用 Docker Volume 而不是 bind mount
• 初始化脚本：放在 /docker-entrypoint-initdb.d/ 自动执行
• 连接字符串：使用服务名（如 db）而不是 localhost

# 连接到容器化的 PostgreSQL
docker compose exec db psql -U dev -d myapp_dev

多环境配置

开发、测试、CI 的统一

好的容器化策略能让开发、测试和 CI 使用相同的基础镜像：

# Dockerfile（多阶段构建）
# --- 开发阶段 ---
FROM node:20-bookworm AS development
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "dev"]

# --- 构建阶段 ---
FROM node:20-bookworm AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# --- 生产阶段 ---
FROM node:20-bookworm-slim AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/main.js"]

常见陷阱

1. 文件系统性能

在 macOS 上，bind mount 的 I/O 性能较差。

解决方案：

• 使用 :cached 选项
• 将 node_modules 放在容器内的匿名 Volume 中
• 考虑使用 Mutagen 进行文件同步

volumes:
  - ..:/workspace:cached
  - /workspace/node_modules  # 匿名 volume，避免同步

2. 镜像体积过大

解决方案：

• 使用 Alpine 或 slim 基础镜像
• 多阶段构建
• 清理 apt 缓存

3. 启动速度慢

解决方案：

• 善用 Docker 构建缓存
• 将不常变化的层（如 npm install）放在前面
• 使用 BuildKit 加速构建

替代方案

除了 Dev Containers，还有其他选择：

• Nix：函数式包管理器，提供可复现的环境
• Devbox：基于 Nix 的简化方案
• asdf / mise：多语言版本管理器
• Vagrant：传统虚拟机方案（现在较少使用）

对于大多数团队，Dev Containers + Docker Compose 是当前最佳选择，因为它的学习曲线最平缓，工具链支持最完善。

小结

容器化开发环境消除了「在我电脑上能跑」的问题，让团队协作更加顺畅。虽然前期配置需要一些投入，但长期来看，它是提升团队效率的重要基础设施。

关键原则：

• 开发环境即代码：所有配置都应该被版本控制
• 保持简单：不要过度复杂化，按需添加服务
• 统一工具链：让整个团队使用相同的 Dev Container 配置

在 AI 编程工具百花齐放的时代，最常见的问题是：「哪个工具最好？」答案是：取决于你的场景。

一个全栈开发者、一个数据科学家、一个 DevOps 工程师，他们对 AI 编程工具的需求是截然不同的。本文将按不同场景，给出具体的工具选择建议。

场景一：日常功能开发

推荐工具：Cursor / Windsurf

如果你每天的主要工作是开发新功能、修复 Bug、重构代码，那么一个 AI 原生编辑器是最佳选择。

为什么选择 Cursor？

• 深度 IDE 集成：AI 不是附加功能，而是编辑器的核心体验
• Composer 模式：描述需求，自动修改多个文件
• Supermaven 补全：业界最快的代码补全，延迟几乎为零
• 丰富的扩展生态：完整的 VS Code 扩展支持

什么时候选 Windsurf？

• 你更喜欢轻量级的体验
• Cascade 功能适合需要快速原型开发的场景
• 团队协作功能更突出

场景二：大型项目重构

推荐工具：Claude Code / Hermes Agent

当你需要对一个大型项目进行重构时，Agent 类工具更有优势。

Claude Code 的优势

• 项目级理解：能分析整个代码库的架构和依赖关系
• 自主执行：自动完成多文件、多步骤的重构任务
• 测试驱动：重构后自动运行测试，确保功能不变

实际案例

任务：将一个 Express.js 项目迁移到 Hono 框架

Claude Code 的执行过程：
1. 分析现有路由结构和中间件使用
2. 逐个文件替换 Express API 为 Hono API
3. 更新依赖配置
4. 运行测试，修复兼容性问题
5. 清理旧的 import 语句

整个迁移在 30 分钟内完成，而手动操作可能需要一整天。

场景三：学习新技术

推荐工具：OpenCode AI / ChatGPT

当你需要学习一个新的框架或技术栈时，交互式学习体验最重要。

OpenCode AI 的学习模式

• 渐进式引导：从基础概念到高级用法，循序渐进
• 代码示例：自动生成可运行的示例代码
• 概念解释：不懂的地方随时追问

ChatGPT 的角色

• 适合前期的概念调研和选型评估
• 生成技术方案文档
• 解释复杂的概念和原理

场景四：快速原型 / Hackathon

推荐工具：Bolt.new / v0.dev

当你需要在极短时间内把一个想法变成可运行的原型时：

Bolt.new

• 从自然语言描述直接生成完整的 Web 应用
• 自动处理部署和托管
• 适合快速验证产品想法

v0.dev

• Vercel 出品，专注于 UI 组件生成
• 从设计稿或文字描述生成 React 组件
• 与 Next.js 生态深度集成

场景五：DevOps / 基础设施

推荐工具：Hermes Agent / Claude Code

基础设施即代码（IaC）和 DevOps 任务有独特的需求：

• 需要理解云服务的 API 和配置
• 需要处理 YAML、Terraform 等配置文件
• 需要考虑安全性和最佳实践

Hermes Agent 在这类任务中表现出色，因为它的工具链集成能力可以：

• 直接操作文件系统和命令行
• 读取和修改配置文件
• 执行验证命令

组合使用策略

实际上，最高效的开发者不是只用一个工具，而是根据任务灵活切换：

选型 Checklist

在选择工具时，问自己这几个问题：

1. 任务复杂度：是简单的功能开发还是需要跨多文件的重构？
2. 自主性需求：你需要完全控制每一步，还是可以让 AI 自主执行？
3. 项目规模：代码库有多大？AI 能否有效理解项目上下文？
4. 预算：Agent 模式的 token 成本显著高于补全模式
5. 安全要求：代码是否涉及敏感信息？是否需要本地运行？

小结

选择 AI 编程工具的关键是匹配场景。不要被「最强 AI」的营销话术迷惑，而是根据你实际的工作内容和开发风格来选择。

下一篇文章中，我们将探讨一个更深层次的问题：当 AI 越来越强大，程序员的角色将如何转变？

OpenCode 是 2025 年最引人注目的开源终端 AI 编程工具之一，由 Go 语言编写，以精美的 TUI（终端用户界面）和极致的模型灵活性著称。

2025 年 9 月，原仓库归档，项目以 Crush 之名加入 Charm 团队（就是打造了 Bubble Tea、Lip Gloss 等经典终端工具的团队）。这并不意外——OpenCode 的 TUI 本就基于 Charm 的 Bubble Tea 框架构建。

核心功能一览

精美的 TUI 交互界面

OpenCode 不是那种简陋的命令行问答工具。它有一个完整的终端用户界面：

• 分屏布局：左侧对话，右侧代码预览
• Vim 风格的键盘导航
• 实时文件变更追踪
• 语法高亮的代码展示

75+ LLM 提供商支持

这是 OpenCode 最强大的卖点。它几乎支持所有能想到的 AI 模型：

• OpenAI：GPT-5.2、GPT-5.1 Codex、O3/O4 Mini
• Anthropic：Claude Opus 4.5、Sonnet 4.5
• Google：Gemini 3 Pro、Gemini 2.5 Flash
• GitHub Copilot：复用你的 Copilot 订阅
• 本地模型：通过 Ollama、LM Studio 运行
• 聚合器：OpenRouter、自定义 OpenAI 兼容端点
• 中国模型：通过 OpenAI 兼容 API 接入

你甚至可以在对话中随时切换模型，用快捷键在不同模型变体间跳转。

智能代码操作

AI 不只是回答问题，它能实际操作你的代码：

• 文件搜索与浏览：glob/grep 模式搜索文件
• 代码编辑：精确的 find-and-replace 修改
• Shell 命令执行：运行测试、构建、部署脚本
• LSP 集成：通过 Language Server Protocol 获取代码智能（跳转定义、诊断等）

会话管理

基于 SQLite 的持久化会话系统：

• 多会话切换和继续
• 会话分支（从某个历史点继续）
• Auto Compact：上下文窗口达 95% 时自动摘要压缩

MCP 协议支持

支持 Model Context Protocol（模型上下文协议），可以连接外部工具服务器扩展能力。

安装与使用

# 一键安装
curl -fsSL https://opencode.ai/install | bash

# 或通过 Homebrew
brew install opencode-ai/tap/opencode

# 或 npm
npm i -g opencode-ai@latest

# 启动 TUI
opencode

# 非交互模式（适合脚本/CI）
opencode run "解释这个函数的作用"

# 指定模型
opencode -m anthropic/claude-sonnet-4

# 继续上次对话
opencode -c

TUI 内操作指南

启动后你会看到一个分屏界面：

• /models — 切换 AI 模型
• /connect — 添加/管理 API 密钥
• /agent — 切换 Agent 角色（coder、task、title 等）
• Tab — 在面板间切换
• j/k — Vim 风格上下滚动

OpenCode Zen：开箱即用的免费模型

OpenCode 提供了 Zen 服务——精选的、经过编程场景测试的模型，有免费额度可用。这意味着你甚至不需要 API Key 就能开始使用。

对于需要更多配额的用户，OpenCode Go 提供低成本的订阅方案。

与同类工具对比

适用人群

OpenCode/Crush 特别适合以下开发者：

• Vim/Neovim 爱好者：键盘驱动的 TUI 体验
• 多模型切换需求：不想绑定单一厂商
• 隐私敏感场景：支持纯本地模型运行
• 预算有限：免费 Zen 层 + 可选的低成本订阅
• 终端原教旨主义者：不喜欢 IDE 插件模式

注意事项

1. 原仓库已归档，请使用 Crush 获取最新更新
2. Anthropic 禁止第三方使用 Pro/Max 订阅，Claude 模型需要 API 访问
3. 最佳体验仍推荐搭配至少一个 API Key

总结

OpenCode（现 Crush）以模型自由度和终端体验为核心，是 2025-2026 年间开源 AI 编程工具领域的标杆之作。如果你厌倦了被单一模型厂商锁定，或者只是想要一个真正好用的终端 AI 助手，它值得一试。

相关链接：

• 原 GitHub 仓库（已归档）
• Crush - 新项目地址
• OpenCode 官网

2021 年，GitHub Copilot 的发布标志着 AI 编程工具进入主流视野。最初的使用体验简单而直接：你写几行代码，按下 Tab 键，AI 就会帮你补全接下来的内容。

这种模式的核心理念是辅助（Assistance）——AI 作为编辑器的附属功能，在你写作的间隙提供智能建议。就像一个超级版的自动补全，它理解的不只是当前文件，而是整个项目的上下文。

Copilot 的突破

Copilot 的真正突破在于：

• 多行补全：不再只是补全一个函数名，而是能生成整段逻辑
• 上下文理解：基于项目中的其他文件、类型定义来生成建议
• 自然语言转代码：在注释中描述需求，AI 直接生成实现

但这个阶段的 AI 编程工具有一个根本性的限制——它只能被动响应。你写一段，它补一段。它无法理解你的整体意图，也无法主动规划实现路径。

进化：对话式编程

2023-2024 年，随着 ChatGPT 和 Claude 等大语言模型的成熟，编程工具进入了一个新阶段：对话式编程（Conversational Coding）。

Cursor、Windsurf、Continue 等工具开始将 AI Chat 深度集成到编辑器中。你不再需要切换到浏览器去问 ChatGPT，而是直接在编辑器里和 AI 对话。

这个阶段的关键进化：

• 多文件编辑：AI 可以同时修改多个文件，理解跨文件的依赖关系
• 项目级上下文：通过 RAG（Retrieval-Augmented Generation）索引整个代码库
• 迭代式开发：与 AI 反复对话，逐步完善代码

Cursor 的 Composer

Cursor 的 Composer 功能是这个阶段的代表。你可以描述一个需求，AI 会：

1. 分析现有代码结构
2. 规划需要修改的文件
3. 生成所有必要的代码变更
4. 展示 diff 供你审阅

这已经从「补全」进化到了「协作」，但本质上还是人在驱动，AI 在响应。

范式转移：AI Agent

2025-2026 年，我们看到了真正的范式转移：AI Agent（自主代理）。

Claude Code、Hermes Agent、Devin 等工具代表了全新的编程范式——AI 不再只是等待你的指令，而是能够：

• 自主规划：理解一个高层目标，拆解成具体的实现步骤
• 独立执行：自动创建文件、运行测试、修复错误
• 自我纠正：遇到问题时分析原因，调整方案，继续推进

Claude Code 的自主模式

Claude Code 开创了「Agentic Coding」的概念。在自主模式下：

你：实现一个用户注册功能，包含邮箱验证

Claude Code：
1. 创建数据库 schema（users 表 + verification_tokens 表）
2. 实现 POST /api/register 端点
3. 添加邮箱验证逻辑
4. 编写单元测试
5. 运行测试，发现 2 个失败
6. 自动修复测试
7. 所有测试通过 ✓

整个过程你可能只需要说一句话，AI 就能完成从设计到测试的全部工作。

新挑战

但 Agent 模式也带来了新的挑战：

• 信任问题：你如何确保 AI 生成的代码是正确的？
• 可控性：当 AI 自作主张做了错误的决定，如何快速回滚？
• 成本：Agent 模式的 token 消耗远超简单补全
• 安全性：AI 可能在不知不觉中引入安全漏洞

这些挑战推动了新一代工具的出现——它们在自主性和可控性之间寻找平衡点。

小结

从 Tab 补全到自主代理，AI 编程工具的进化可以用三个阶段概括：

1. 辅助阶段（2021-2023）：AI 作为补全工具，被动响应
2. 协作阶段（2023-2025）：AI 作为对话伙伴，多文件协作
3. 代理阶段（2025+）：AI 作为自主开发者，独立完成任务

下一篇文章中，我们将深入探讨在不同场景下如何选择最合适的工具。

Claude Code 的故事始于 Boris Cherny 在 Anthropic 的一个内部副项目。它最初是一个实验性的命令行工具，用于让 Claude 直接操作代码。由于效果出众，很快就成为了 Anthropic 的官方产品，甚至 Google 工程师也开始在日常工作中使用它。

Claude Code 的定位不是「代码补全工具」——它是一个完整的代理式编程系统（Agentic Coding System）。

核心能力

1. 深度代码库理解

Claude Code 不只是看当前文件。它会：

• 扫描整个项目结构
• 理解模块间依赖关系
• 跟踪调用链路
• 识别设计模式和架构意图

2. 跨文件编辑

这是 Claude Code 最强大的能力之一。一个指令可以触发多文件修改：

# 示例指令
"将用户认证从 JWT 迁移到 OAuth2，更新所有相关文件"

# Claude Code 会：
# 1. 找到所有使用 JWT 的文件
# 2. 修改认证中间件
# 3. 更新路由配置
# 4. 调整测试用例
# 5. 更新类型定义

3. 测试驱动工作流

Claude Code 可以：

• 编写并运行测试
• 根据测试失败修复代码
• 执行完整的 Red-Green-Refactor 循环
• 支持 Jest、pytest、Go test 等主流测试框架

4. Git 集成

# 自动化的代码审查和提交
claude "review this PR and leave inline comments"
claude "commit these changes with a good message"

支持 GitHub PR 工作流：创建分支、提交代码、开启 PR、处理 CI 反馈。

5. 安全与控制

• 每次文件修改和命令执行都需要确认
• 沙箱化的 shell 执行环境
• 详细的操作日志
• 企业级的权限管理

安装与使用

# 通过 npm 安装
npm install -g @anthropic-ai/claude-code

# 在项目目录中启动
cd your-project
claude

# 非交互模式
claude -p "解释这个项目的架构"

# 恢复上次会话
claude --resume

付费模式

Claude Code 通过 Anthropic 的 API 计费，按 token 用量收费。也可以通过 Claude Pro/Max 订阅使用（有限额）。

• Claude Pro：$20/月，包含一定额度的 Claude Code 使用
• Claude Max：$100/月或 $200/月，更大额度
• API 直连：按 token 计费，适合重度用户

实际工作流示例

开发新功能

claude
> 在用户设置页面添加两步验证功能
  需要支持 TOTP 和短信验证码
  写好测试

# Claude Code 会：
# 1. 分析现有用户模型
# 2. 创建数据库迁移
# 3. 实现 TOTP 和短信逻辑
# 4. 添加前端界面
# 5. 编写测试用例
# 6. 运行测试确认通过

Bug 修复

claude
> 用户报告登录后偶尔被重定向到 404 页面
  这是错误日志：...

# Claude Code 会：
# 1. 分析错误日志
# 2. 追踪重定向链路
# 3. 定位竞态条件
# 4. 修复并添加测试

代码重构

claude
> 将这个 Express 应用迁移到 Hono 框架
  保持所有 API 端点兼容

# Claude Code 会逐模块迁移，确保测试始终通过

与其他工具的定位差异

适用人群

• 全栈开发者：需要跨前后端大规模修改
• 代码重构：需要系统性的架构调整
• Bug 调试：需要追踪跨文件的问题链路
• CI/CD 集成：需要在自动化流水线中使用 AI

局限性

1. 模型锁定：仅支持 Claude 系列模型，无法使用 GPT、Gemini 等
2. 非开源：无法审计或自定义底层逻辑
3. 成本：对于大型代码库，API 调用成本可能较高
4. 终端依赖：需要习惯命令行工作流

总结

Claude Code 是目前最强大的单一模型 AI 编程代理。如果你已经在使用 Claude 并且需要一个能真正理解项目、跨文件编辑、自主完成复杂任务的 AI 编程助手，它是当前最好的选择。

但如果你需要模型灵活性或开源方案，应该考虑 OpenCode/Crush 或 Cline 等替代方案。

相关链接：

• Anthropic 产品页
• Claude Code 文档
• Claude Code GitHub

Git 是现代软件开发的基石，但很多团队并没有充分发挥它的潜力。一个好的 Git 工作流不仅是「保存代码历史」，更是：

• 团队沟通的载体
• 代码质量的保障
• 项目进度的可视化
• 问题追溯的线索

分支策略

Git Flow

Git Flow 是最经典的分支策略，适合有明确版本发布周期的项目：

• main：生产代码，永远是可部署的
• develop：开发主分支，集成所有功能
• feature/*：功能分支，从 develop 拉出
• release/*：发布准备分支
• hotfix/*：紧急修复分支

优点：结构清晰，适合大型团队 缺点：流程较重，对小团队可能过度

GitHub Flow

更轻量的策略，适合持续部署的项目：

• main：永远是可部署的
• 功能分支从 main 拉出
• 通过 PR 合并回 main
• 合并即部署

优点：简单直接，适合快速迭代 缺点：缺乏明确的版本管理

Trunk-Based Development

最简化的策略，适合高度成熟的团队：

• 只有 main（或 trunk）一个长期分支
• 所有开发在 main 上进行
• 使用 Feature Flag 控制未完成功能
• 频繁提交，小步快跑

优点：避免合并地狱，强制持续集成 缺点：需要成熟的 CI/CD 和 Feature Flag 基础设施

我的建议

根据团队规模选择：

Commit 规范

Conventional Commits

这是目前最广泛使用的 Commit 规范：

<type>(<scope>): <subject>

<body>

<footer>

常用的 type：

• feat: 新功能
• fix: Bug 修复
• docs: 文档更新
• style: 代码格式调整（不影响逻辑）
• refactor: 重构
• perf: 性能优化
• test: 测试相关
• chore: 构建、工具变更

示例

好的 commit message：

feat(auth): add JWT refresh token rotation

Implement refresh token rotation to enhance security.
When a refresh token is used, a new one is issued and
the old one is invalidated.

Closes #123

不好的 commit message：

fix stuff

为什么规范重要？

• 自动化 Changelog：通过 type 自动生成变更日志
• 快速定位：git log --oneline 一目了然
• Code Review：PR 标题和描述可以直接用 commit message
• 回滚依据：出现问题时快速定位需要回滚的 commit

PR / MR 最佳实践

标题和描述

PR 标题应该简洁明了地描述变更内容：

## 变更内容
- 添加用户注册 API
- 实现邮箱验证逻辑
- 添加注册相关单元测试

## 测试
- [x] 单元测试通过
- [x] 手动测试注册流程
- [ ] 邮件发送测试（需要 staging 环境）

## 截图
（如有 UI 变更，附截图）

Review 规范

• 小 PR：每个 PR 控制在 200-400 行以内
• 自描述：PR 应该能独立理解，不需要额外背景知识
• 及时 Review：24 小时内完成 Review
• 建设性反馈：提出具体的改进建议，而不是笼统的「这里有问题」

常用 Git 技巧

交互式 Rebase

# 修改最近 3 个 commit
git rebase -i HEAD~3

可以合并、重排、修改 commit message，保持历史整洁。

Stash 管理

# 临时保存工作区
git stash push -m "WIP: feature-x"

# 查看所有 stash
git stash list

# 恢复并删除
git stash pop

Cherry-pick

# 将某个 commit 应用到当前分支
git cherry-pick abc123

适合将 hotfix 应用到多个分支。

Bisect

# 二分法查找引入 Bug 的 commit
git bisect start
git bisect bad          # 当前版本有问题
git bisect good v1.0    # v1.0 没问题

Git 会自动帮你找到第一个出问题的 commit。

小结

一个好的 Git 工作流是团队效率的乘数。投入时间建立规范，在项目成长过程中会获得巨大的回报。记住：

• 分支策略选择适合团队的，不要过度设计
• Commit message 是写给人看的，也是写给未来的自己看的
• PR 是交流的机会，充分利用 Code Review 提升代码质量

你每天在编辑器里度过的时间可能比在床上还多。选择一个合适的编辑器，不只是选择一个工具，更是选择一种工作方式。

2026 年的编辑器生态，两大阵营最为活跃：VS Code（及其衍生品） 和 Neovim。它们各有拥趸，也各有优劣。

VS Code：主流之选

为什么 VS Code 如此流行？

VS Code 的成功秘诀不是技术上的突破，而是体验上的平衡：

• 开箱即用：安装后 5 分钟就能开始高效开发
• 扩展生态：超过 50,000 个扩展，覆盖几乎所有语言和框架
• 调试集成：内置调试器，支持断点、变量查看、调用栈
• Git 集成：直观的源代码管理界面
• 远程开发：Remote SSH、Dev Containers、WSL 支持完善

VS Code 的衍生生态

VS Code 的开源核心（OSS）催生了一批优秀的衍生编辑器：

• Cursor：AI 原生编辑器，将 AI 能力深度集成
• Windsurf：轻量级 AI 编辑器，Cascade 功能突出
• VSCodium：去除微软遥测的纯净版

这些衍生品保留了 VS Code 的扩展兼容性，同时增加了各自独特的功能。

最佳实践

用好 VS Code 的几个建议：

1. 善用 Workspace Settings：每个项目独立配置，避免全局设置污染
2. 安装必备扩展：ESLint、Prettier、GitLens、Error Lens
3. 掌握快捷键：Command Palette（Ctrl+Shift+P）是你的好朋友
4. 配置 Tasks：将常用操作自动化

Neovim：极客之选

Neovim 的魅力

Neovim 不是「另一个编辑器」，它是一种哲学：

• 键盘驱动：所有操作通过键盘完成，手永远不需要离开主行
• 无限可定制：用 Lua 编写配置，精确控制每一个细节
• 极速启动：冷启动时间在 50ms 以内
• 终端原生：在 SSH 会话中也能获得完整的编辑体验

Neovim 的现代生态

2024-2026 年的 Neovim 生态已经非常成熟：

• LazyVim / NvChad / AstroNvim：开箱即用的 Neovim 发行版
• LSP 集成：通过 nvim-lspconfig 获得 IDE 级别的语言支持
• 自动补全：nvim-cmp + 各种 source 提供智能补全
• 文件浏览：neo-tree、telescope 提供高效的文件导航
• Git 集成：gitsigns、lazygit 提供版本控制支持

配置示例

一个现代 Neovim 配置的核心结构：

-- lazy.nvim 插件管理
require("lazy").setup({
  -- LSP
  { "neovim/nvim-lspconfig" },
  -- 自动补全
  { "hrsh7th/nvim-cmp" },
  -- 语法高亮
  { "nvim-treesitter/nvim-treesitter" },
  -- 文件搜索
  { "nvim-telescope/telescope.nvim" },
  -- Git
  { "lewis6991/gitsigns.nvim" },
})

如何选择？

这不是一个非此即彼的问题。以下是一些决策参考：

选择 VS Code（或衍生品）如果你：

• 刚开始编程，或者团队协作是首要考虑
• 需要调试复杂的应用（前端、Node.js）
• 依赖特定的 VS Code 扩展
• 不想花时间配置编辑器

选择 Neovim 如果你：

• 熟悉 Vim 操作，享受键盘流的工作方式
• 经常需要 SSH 到远程服务器开发
• 追求极致的启动速度和响应速度
• 享受定制工具的过程本身

实际建议

很多开发者的做法是：两个都用。

• 日常开发用 VS Code（或 Cursor），享受完整的 IDE 体验
• 快速编辑和服务器操作用 Neovim，享受极速和便携

未来趋势

编辑器生态的未来有几个值得关注的趋势：

1. AI 原生：编辑器将 AI 作为核心功能，而非附加插件
2. 协作编辑：实时协作将成为标配
3. 云原生：浏览器内的完整开发体验（如 GitHub Codespaces）
4. 统一体验：本地、远程、云端的无缝切换

小结

选择编辑器就像选择一双鞋子——最重要的是合脚。不要被别人的选择影响，花时间试用不同的选项，找到最适合你工作方式的那一个。

Cursor 在 2024-2025 年间以惊人速度崛起，成为开发者社区讨论度最高的 AI 编辑器。它的核心思路很简单却很深刻：

AI 不应该是编辑器上的一个插件，而应该是编辑器本身的核心。

Cursor 是一个完整的 VS Code 分支（Fork），这意味着：

• 你所有的 VS Code 扩展、主题、快捷键都能直接用
• 但 AI 能力被深度嵌入到编辑器的每一个角落
• 不存在「插件和编辑器之间的接口摩擦」

核心功能

1. Supermaven 自动补全——杀手级特性

Cursor 集成了 Supermaven 的补全引擎，这是目前最快、最准确的代码自动补全：

• 多行预测：不只补全当前行，能预测整段代码
• 项目级上下文：理解整个项目的类型定义和导入关系
• 自动导入：补全时自动添加所需的 import 语句
• 近乎心灵感应：很多用户形容「它知道我想写什么」

2. 智能聊天（Chat）

内嵌的 AI 聊天面板：

• @file 引用项目中的特定文件
• @web 搜索网络获取最新文档
• @docs 索引并查询项目文档
• 支持多轮对话，维护完整的上下文

3. Composer（多文件编辑）

这是 Cursor 的旗舰功能。它允许 AI 同时编辑多个文件：

# 在 Composer 中输入
"添加一个用户管理页面，包括列表、搜索、增删改查"

Cursor 会同时创建/修改：

• 前端组件文件
• API 路由
• 数据库模型
• 测试文件
• 样式文件

所有修改以 Diff 形式展示，你可以逐个审查和接受。

4. 代码库索引

Cursor 会在后台索引你的整个代码库，构建语义搜索索引。当你提问时，它能：

• 找到最相关的代码片段
• 理解函数调用关系
• 跟踪变量使用位置

5. Cursor Tab

智能 Tab 补全，在你打字时提供多行建议。与 Supermaven 配合使用，体验非常流畅。

定价（2026 年最新）

值得注意的是，2025 年 8 月的定价调整曾引发社区争议，但 $20/月的 Pro 价格在市场上仍具竞争力。

实际体验

每周节省 8-12 小时

对于中大型项目，Cursor 的用户普遍报告每周能节省 8-12 小时的编码时间。主要体现在：

• 减少样板代码编写：自动补全处理了大量重复性代码
• 加速调试：AI 能快速定位错误根因
• 简化重构：批量修改的可靠性显著高于手动操作

学习曲线

从 VS Code 切换到 Cursor 几乎零成本：

• 界面布局一致
• 扩展自动迁移
• 只需要学习 AI 相关的快捷键

与竞品对比

Cursor vs VS Code + Copilot

Cursor vs Windsurf

适用人群

• 全栈开发者：需要在前端、后端、数据库间频繁切换
• 新项目启动：Composer 能快速生成项目骨架
• 代码重构：大规模跨文件修改
• 团队协作：Business 计划提供团队管理功能

注意事项

1. 闭源：Cursor 是闭源商业软件，与开源 IDE 不同
2. VS Code 分支：可能滞后于 VS Code 主线的某些更新
3. API 调用：高级请求消耗模型 API 额度
4. 性能：AI 索引在大型项目中可能占用较多资源

总结

Cursor 是 2025-2026 年间 AI 原生编辑器的事实标准。如果你想要一个「开箱即用、AI 深度集成、VS Code 体验无缝迁移」的编码环境，它是当前最安全的选择。

$20/月的 Pro 价格对于专业开发者来说性价比很高——每周省 8 小时，相当于时薪不到 $1 的投入。

相关链接：

• Cursor 官网
• Cursor 文档
• Cursor 社区