Agentic coding-我对各种 AI Coding Agent 工具的看法

1- 📌 文章导航

graph TD
    A[背景介绍] --> B[产品分析]
    B --> C1(Cursor)
    B --> C2(VS Code/Copilot)
    B --> C3(Claude Code)
    B --> C4(...其他工具)
    B --> D[行业格局]
    D --> E[技术方向]
    D --> F[未来思考]

Agentic coding 🔥 或许是当下最火（最卷）的方向，一万家公司在做。隔三差五就在社交媒体上看到新工具发布（“blow mind”、" 颠覆 XX" 等宣传层出不穷），这造成了普遍的困惑：

  • 很多人质疑：" 这些 AI coding 工具真有那么牛吗？"
  • 常见疑问：“XX 和 YY 到底有啥区别？”
  • 不少用户试用后感觉 " 不过如此 "，迅速下头
  • 甚至还有程序员连 Cursor 都没用过

作为深度体验过各种 agentic coding tool 的用户，我决定撰写这篇深度分析。这个领域虽充满 hype，但仔细审视仍能发现：

  1. 不同产品间的技术差异
  2. 行业发展方向
  3. 使用 " 手艺 "（如何有效运用 Agent）

最佳了解方式仍是亲身体验，但本文旨在系统化整理我的观察与思考。

2- 背景与挑战

2.1- 核心观点

💡 我坚信 "agent coding 能成 " 的未来：AI agent 将能独立完成大型项目中的复杂开发任务（功能添加/bug 修复/代码重构）

2.2- 实践基础

作为开源流数据库 RisingWave 的开发者（60 万行 Rust 代码），我的使用观察：

  • ✅ 适合明确上下文的小任务
  • ⚠️ 尚未用于核心复杂开发
  • 🤔 对技术边界认识尚不清晰

2.3- 现实阻碍

pie
    title 使用障碍分析
    "成本问题" : 45
    "工具选择困难" : 30
    "学习曲线" : 25

主要痛点：

  1. 💸 成本敏感：单任务 5-10 美元（存在杰文斯悖论）
  2. 🛠️ 工具过载：深度体验需 1 周 + 时间
  3. 🔁 切换成本：订阅机制造成锁定效应

3- 主流工具深度评测

::: tip 本章导读
本节将剖析 8 类 AI 编程工具的技术特点与商业模式，揭示其背后的设计哲学与用户定位
:::

3.1- Cursor：生态整合者

Cursor 🏆 当前 AI 编程工具领域的绝对领导者

3.1.1- 版本演进线索（0.50/1.0）

0.50版本更新 透露了 Cursor 的未来方向（尽管现在已发布 1.0）：

3.1.1.1- 关键更新分析

  • 定价简化
    新版统一为 “Requests” 计费模式，解决了之前模糊的 “fast request” 定义问题。但按请求计费在 Agent 时代可能不合理——复杂任务会消耗大量 token。这种定价可能是**" 健身房模式 "**，用轻度用户补贴重度用户。

  • Max 模式
    官方宣称 " 适合最难题 "，实际是放弃上下文精细管理 +token 计费。早期上下文管理有价值，但现在模型能力提升使其成为负担。有趣的是，开源方案如 Roo Code 一直倡导 " 全上下文=最佳性能 "。

    Cursor 的 Max 模式像是技术债回调，其价值主张 " 类似 CLI 工具体验 " 令人困惑——既然 CLI 工具可用，为何支付 20% 溢价？

  • 长文件快速编辑
    改用基于文本的模型输出应用方式。早期 Cursor 的 apply 模型设计超前，但随着模型精度提升，复杂 apply 逻辑变得多余。

  • 后台 Agent 与 BugBot
    标志 Cursor 正式进军全自动领域：

    • Background Agent：任务派发后自动执行
    • BugBot：自动代码审查
    • 未来可能支持 GitHub issue 分配

    战略意义：直接对标 Devin，采用渐进式自动驾驶路线（特斯拉模式）vs Devin 的一步到位（Waymo 模式）。渐进式优势：

    1. 用户期望管理更灵活
    2. 保留现有功能粘性
    3. 更适应小白用户需求

3.1.1.2- 1.0 版本补充

  • 记忆功能：Agent 必备能力
  • 聊天增强：支持 Mermaid 图表和 Markdown 表格
  • 总体仍以营销为主，无实质突破

与 Cursor 的激进大动作相应的则是 Anysphere, which makes Cursor, has reportedly raised $900M at$ 9B valuation 。对应 OpenAI 想要收购 windsurf 的新闻，可见 Cursor 急切的想要一统江湖的野心。融了这么多钱，我猜他们下一步很可能就是训练自己的模型。除此以外，它也完全有可能会收购市场上的其他玩家，成为一个整合者的角色。

3.1.2- Cursor 的核心优势

其实我当初（2024/05）用 curosr 完全是为了他惊艳的 TAB 功能 。在早期我几乎不用 AI chat，甚至能忍着很多非常影响体验的 editor bug 还要用。

相比 GitHub Copilot 的 “append only” 补全，想修改就得删了重来；Cursor 的生成 “Edit”，帮你修改代码，显然是更 " 正确 " 的形态，而且准确率相当不错。它的补全还能在改完一处后，跳到后面同时修改多处，这在重构时极其有用。例如改一个类型签名的时候 IDE 不太能智能重构，要手动改很多地方，而 Cursor 解决了这个痛点。

就为了这个 TAB 功能，我心甘情愿地付了 20 刀。

Cursor的TAB编辑功能 - 智能多位置同步修改
图：Cursor 的 TAB 编辑功能实现多位置同步修改

后来在我没意识到的时候 “Agent mode” 在 non-coder 中先火了。我才后知后觉地发现了 agent 的能力。🔥 关键转折点：

  1. 定价策略：维持 20 刀不变 → 培养用户习惯
  2. 先发优势：最早建立品牌认知
  3. 心理锚定：用户形成路径依赖
graph LR
    A[早期TAB功能] --> B[核心开发者]
    B --> C[口碑传播]
    C --> D[非技术用户]
    D --> E[Agent生态]

他们有一篇 Our Problems ，看他之前画的饼其实都是 AI-assisted coding 的范畴，现在感觉在 agent 的时代稍微有点过时了。AI assisted coding 的 UX 感觉还是有很多可以做的事情的，但现在大力做 Agent 的话可能会没那么优先了。

所以，Cursor 的好在哪？它好在一种奇妙的组合拳上。它先用一个真正懂开发者的杀手级功能（那个无敌的 TAB Edit）抓住了最挑剔重的核心用户，然后又敏锐地捕捉到了 Agent 的浪潮，在大众心中成功地将自己与 "AI 编程 " 这个概念划上了等号，哪怕它的技术在现在并非最领先。这种 " 硬核实力 " 和 " 抓风口能力 " 的结合，再配上一点先发优势的 " 玄学 "，最终成就了它现在的地位。

现在如果你不知道什么工具最适合自己，那 Cursor 可能是一个比较稳的选择：有充足资金，不一定是最强但肯定差不到哪去。

3.1.3- Cursor 的战略定位

核心问题：为何要 fork VS Code？

  • 初期答案：AI 特化体验（如 TAB 编辑）
  • 现状：VS Code/Augment Code 快速追赶

最新判断：

🚀 Cursor 致力于打造 ALL-in-one 开发者入口平台

战略要素 说明
定位 一站式开发中心
优势 IDE 作为工程师核心场景
挑战 传统 IDE 功能迭代滞后 
graph LR
    A[IDE] --> B[AI辅助]
    A --> C[版本控制]
    A --> D[任务管理]
    A --> E[云服务集成]

竞争格局：

  • ⚔️ 新兴编辑器 (windsurf/trae) 难抗衡
  • 💰 资本优势可收购整合对手
  • 🆕 颠覆可能来自Zed类重构产品

3.1.4- 竞争壁垒分析

Cursor 的创始人曾谈过他们对 " 壁垒 " 的看法：在这个发展过快，未来的想象空间也仍然很大的领域， 壁垒的本质就是 " 快 " 。只要你够快，就能领先。反之无论你当前的技术有多强、产品体验有多好，一旦你在某个阶段慢下来，就可能被超越、被取代，非常残酷。

我在这个事情上没完全想明白。我曾经觉得靠 " 体验 " 是可以成为壁垒的。但或许那只是你做的事情不够大。如果足够大，那么巨头一定会出手自己做，然后用技术（模型）和资源能力比你做的更好。

3.2- VS Code/GitHub Copilot

Copilot 绝对是里程碑，是第一个让人感觉 " 能用 " 的 AI coding 工具。但后来，它的体验逐渐被后起之秀超越。我猜测可能的理由包括：

  1. OpenAI/微软重心转移（比如微软大力搞 copilot for office）
  2. 毕竟微软是个巨厂，层层审批，Github Copilot 拿不到太多资源
  3. Copilot 本身当初可能是想着做做看，做出效果以后也没想好再往后能怎么做，而且 coding 模型的发展缓慢（Codex 是 GPT-3 的一个 finetune 版本），后面专注提升基座能力去了，没人/资源专门训练 coding 特化模型
  4. Copilot 用户（特别是 enterprise 用户）多了以后不好大刀阔斧地改体验，领先占据市场反而成了包袱
  5. 受限于 VS Code 的壳，不像 fork 的 AI IDE 可以乱改，要往主分支里塞 AI 相关的东西可能还是要掂量一下，特别是在当年 AI coding 还原非共识，有很多程序员反感 AI

但是 VS Code 最近逐渐把功能慢慢都加上了。甚至还发了一篇有意思的宣言： VS Code: Open Source AI Editor

长远看 VS Code 可能还是会重回巅峰 。理由很简单：大厂认真起来是很吓人的（比如 gemini）。当 AI coding 成为共识，微软投入足够资源，体验差异很可能被逐渐抹平（比如 Cursor TAB 这种东西 Copilot 没理由不做），除非他们持续在 "AI Editor 的 UX 创新 " 上整新活。但是目前看来并没有。更重要的一点是，既然 agent 不需要 IDE 就能工作，那么程序员自己写代码时，还是会回归到功能扎实、bug 更少的传统 IDE。这也 Cursor 的一大弱点，它在 IDE 本身的迭代上，似乎总比 VS Code 慢半拍。

未来，VS Code 和 Cursor 两分天下，感觉也挺有可能。喜欢古典和喜欢大而全的人，各取所需。

3.3- Claude Code：原厂精工

graph LR
    A[Claude Code] --> B[CLI-Based]
    A --> C[云原生]
    A --> D[长时任务]
    style A fill:#ffd700,stroke:#333

深度技术解析 表明 Claude Code 的核心优势：

相比于 IDE 或者浏览器里的 agent，CLI-based agent 本质上没太大差距，最主要的区别可能就是对 prompt 和 tool 的设计。但它的优点是可以 iterate faster。因为能做的事情更少，反而可以专注在 agent 最本质的地方。因此正如上次的文章分析的，claude code 的 prompt 包括 tool spec 写的都非常的长。我自己使用下来的体感是感觉 claude code 明显要比 Cursor 更 " 聪明 " 一点。这只是因为 prompt 调教的水平吗？还是说 Claude Code 有特供的模型？（感觉暂时不太像，但未来不好说）

Claude Code 其实并不只能跑在自己本地的 terminal 里，现在已经可以在 GitHub 上 @它，然后自己干活了（跑在 CI 里）。但它的思路并非深度集成，而更像是利用 CLI 无限的可组合性（所以非常第一性原理做事？）。

在过去这一个月里，Anthropic 又有一些明显的动作，让人感觉想要力推 claude code：

  • 在 Code with Claude 大会上发布了 Claude Code 1.0，以及 4.0 新模型
  • 断供 windsurf
  • Claude 20 块的 pro plan 也可以用 claude code 了，大大降低试用门槛。

最后一点让我果断订阅了 Pro Plan。我试了一下，在达到 usage limit 之前（几个小时后刷新），我让 Claude Code 跑了一个比较复杂的重构任务，大概持续了三四十分钟。这个用量如果按 API token 计费，少说也得 10 刀。这或许就是 LLM 原厂做 agent 的一个优势 ：反正机器已经在那里了，可以把闲时资源充分利用起来。而做应用的公司，又不可能去整租机器。

3.3.1- Anthropic 的战略意图

我其实还没完全看懂，Anthropic 做 Claude Code 的最终目的到底是什么？是想做一个好用的产品，还是想用它帮助模型训练本身？OpenAI 现在明显在花力气做 ChatGPT 这个产品，未来的想法大概是把 ChatGPT 作为一个入口，让它成为一个调度型的 agent。那 Claude Code 在这件事上的定位又是什么？

这一方面涉及对 Coding 这个市场的规模到底有多大的判断。从 Cursor 一开始的估值来看，大家普遍认为也就那样——因为开发者群体的体量就那么大。但现在 Vibe Coder 起来以后，整个故事又被撑大了不少。

不过，回到 Anthropic 这么一家大模型公司，直接下场卷应用层的东西，是否有点 " 不体面 "？或许他们的目的并不是要把市场上其他人都吃掉，而是带着一定的试验心态，看看这种东西到底能做成什么样子。但说起应用层，Claude App 里面其实也有很多非常漂亮的功能，比如它的 Artifact，体验明显比 ChatGPT 好很多，虽然 Claude App 整体上很挫。

当然，更有可能的目的还是 通过用户使用它的产品来收集数据，最终用于训练模型 。 因为像 Cursor 这种合作伙伴的用户行为数据，它可能是拿不到的。所以它得自己做一个完整的产品，把整个链条打通。而且，Cursor 里那些乱七八糟的功能它可能也不太需要，它更关注的是训练模型过程中，真正与 Coding 直接相关的部分。

3.3.2- 能力进化：从智能到持久

说回模型训练，Claude Code 宣称能独立跑七个小时，给我的感觉是：现在模型的 " 聪明程度 " 短期内好像有点提不上去了，于是大家开始发力做 " 长期任务执行 " （所谓 Agent）——让模型持续工作得更久、更自主，并且能用工具来辅助提升自己。

在使用中，能很明显地观察到模型的一些新行为：

  • 它会先说：" 我接下来要做 123"，体现出任务规划能力；（我原来觉得需要外化的 TODO list，但它似乎在内化这个能力）
  • 它会先写一个方案，然后写到一半突然说：" 让我想一想有没有更简单的方式 "，然后重头来过。

这些行为看着其实还挺好笑的，但也清晰地揭示了往 agent 这条路上走。

3.4- Amp

他们整体上给我一种很有 " 产品 sense"，" 很懂 agent 应该怎么 work" 的感觉。但其实就是 claude code - like。我能想到他们的优势是 move （slightly） faster（？）；有 sourcegraph 这个 code search & indexing 后端能力（真的有用吗？）；不和 claude 一家强绑定，在别的模型追上的时候可以切；另外他们毫不掩饰、充满原则性的产品哲学可能可以赢得一批用户的深度信赖。他们是这么说的：

Amp设计原则：
- 不计token成本 → 价值优先
- 无模型选择器 → 始终最佳模型
- 面向变化构建 → 避免过度适配当前模型

他们的 “ Frequently Ignored Feedback ” 也很有意思（用户：我要 xxx；amp：不，你不要），体现出他们对 Agent 的深刻理解：

  • Requiring edit-by-edit approval traps you in a local maximum by impeding the agentic feedback loop. You’re not giving the agent a chance to iterate on its first draft through review, diagnostics, compiler output, and test execution. If you find that the agent rarely produces good enough code on its own, instead of trying to “micro-manage” it, we recommend writing more detailed prompts and improving your AGENT.md files.
  • Making the costs salient will make devs use it less than they should. Customers tell us they don’t want their devs worrying about 10 cents here and there. We all know the dev who buys $5 coffee daily but won’t pay for a tool that improves their productivity.

非常 Opinionated，有点 " 果味 " 。

除此以外，他们还做了个 leader board & share thread 功能，很有意思，可以在团队内激起一些奇妙的火花。

但短期内有点谨慎不看好，因为 Claude Code 已经足够好用了，而且绑定 Claude 订阅有巨大的成本优势……Amp 目前的收费模式是完全 pass-through 按 token 收费（没有 margin）。那虽然他们不盈利，可能也不会太烧钱。可以拭目以待一下。

3.5- OpenAI Codex （in ChatGPT）

上个月，OpenAI 也发布了自己的全自动 coding agent。是完全符合我对 agent 的想象的产品形态。我之前就在想，为什么我不能在手机上给 Cursor 派活？现在通过 ChatGPT 就能实现了。

但要看懂这个动作，就不能只盯着 coding。虽然他们收购了 Windsurf，但我认为 OpenAI 的野心远不止在 coding 市场上分一杯羹，他们更想做的是让 ChatGPT 成为未来的调度入口，甚至是一个操作系统 。 Codex 的目的，或许只是为了比较专业的 " 高价值用户 " 能做更多事情，从而提高用户粘性。而收购 Windsurf，看中的可能是他们对 long context 的管理能力和宝贵的用户数据，从而赋能模型能力提升。

偏题说一嘴，ChatGPT 的整体体验远超其他官方 AI app，比如说

  • memory：有一种很神奇的感觉，但对我个人而言提供的 " 价值 " 似乎还没那么大，真有偏个人思考的问题我还是更愿意问没有 memory，甚至更难用的 gemini。
  • o3 的 web search 体验过于好。相当于 mini 版 deep research
  • 虽然也不能说非常丝滑，还是时不时有点 bug，但还是比其他家好太多了。

3.6- Devin

当年在 AI coding 还没那么普及的时候他们就打着 “First AI Software Engineer” 的旗号，要做全自动 end-to-end。初次发布后 500 刀/月的高价也是让人望而却步。并且试过的人也说它笨。

现在变成 20 刀起订，pay as you go 以后我立马试了试。

给我整体的感觉是，模型智力水平一般般。但他们的产品整体上是一种 " 基本上能 work" 的感觉。我有一种强烈的预感，在经过适当的 prompt engineering 之后，它能工作得很好。他们现在的说法也是很实在：" Treat Devin like a junior engineer "。（其实任何 Agent 产品目前大概都是这个状态。）

这是我第一次真切地感受到 agent 烧钱的威力。我让它处理一个 issue，它可以自主探索出一个框架（花了 2 个 ACU，每个 2.25 美元）。但后面让他改 bug，就有点改不对了，开始乱撞，很快就飙到了 4 个 ACU，20 刀迅速蒸发。或许现在的最佳用法是，先用它生成一个初版，然后手工或用 Cursor 精修。（当然，现在 Cursor 也有了 background agent，界限开始模糊了。）

对 devin（包括现在 Curosr remote agent）来说，还有一笔 vCPU 的钱。例如 m5.4xlarge（16C64G）ondeman $0.768/h。其实相比 token 并不算很贵……

在 Agent 成为大热门之后， Devin 直接受 Cursor、claude code、Codex 等各个方向的夹击了。

Devin 目前的优势在于 integration（能直接在 Slack、Linear & Jira 上派活）和较高的产品完成度（设计良好的 knowledge base、playbook 系统）。但这种 " 脏活累活 " 能撑起它的估值，能成为壁垒吗？直觉上，这些是任何一个好的 agent 都必须具备的功能。感觉 agent 这个领域确实需要大量时间去打磨体验，但资本似乎太急了。

他们最新版又出了一个 Confidence rating 功能很不错，可以避免用户因过高预期而烧钱搞出一堆垃圾。其实这也是 agent 挺有意思的一个地方，你用的不对的话就会效果又差又烧钱。换个角度说，一个好的程序员或者乙方不应该你说什么就做什么，而是会试图理解你的意图，为什么你想做这个，以及有什么潜在的坑。

他们的 deepwiki 也有点像是秀肌肉，可能体现了在他们 agent 上的技术积累。毕竟，他们是一开始就融巨资自研大模型、奔着超大上下文去的团队。或许他们有很多的卡，在成本上也有优势。

在写这篇文章的时候又看到一个新的平台 Factory ，看起来也是叫板 devin。它的 release 感觉 too good to be true：“Factory integrates with your entire engineering system (GitHub, Slack, Linear, Notion, Sentry) and serves that context to your Droids as they autonomously build production-ready software.”。但我仔细看了一家这家公司成立 even 比 devin 还早一点。他们的 demo 视频中，一个有意思的地方是他所有的 integration 都是要跳回到它 factory 的页面上的（比如在 slack 里@它，它给一个链接）。它的体验其实是你在它的 portal 上完成所有事情，拉取 linear、GitHub、slack 的 context。（说个不恰当的比喻，这看着有点像 coding 领域的 Manus。）相比之下 devin 是让你在 Slack、Linear 上直接和它交互，更加的 in-context，in-flow。但 anyways，有竞争是好事。

3.7- v0

上面其实说的都是比较偏为 engineer 设计的工具（不管是全自动还是半自动），下面开始聊聊更偏 “non-coder” 或者 “product” 向的平台。

v0 是 coding 垂类赛道中更垂的一个，更偏前端 UI prototype。你可以把它想象成一个用自然语言驱动的 Figma，直接在 v0 里就能把界面 " 画 " 出来。另外一个讨巧的地方是利用 React/shadcn UI 的组件化能力，它生成的东西直接能整合到自己的代码里，是个能用的东西。

Vercel 这家公司一直很讲究 " 品味 "，他们凭借在前端领域的深厚积累，把 v0 这个垂类的体验做得非常好。但可以想见，v0 的流畅体验背后，肯定有大量的工程优化，比如套用模板、专门微调模型，以及一套精心设计的 workflow 来保证生成效果。

一个有意思的动向是他们最近 发布了自己的模型 ，并且开放了 API。他们对此的解释是：“Frontier models also have little reason to focus on goals unique to building web applications like fixing errors automatically or editing code quickly. You end up needing to prompt them through every change, even for small corrections.” 非常合理，但是这是不是属于雕花？当然对于 deliver 一个好用的产品来说，雕花是必须的。但我有一点看不懂他们为啥要出 api，可能一方面是回收训模型的成本，一方面是开始探索让自己成为一个 " 被调度的 agent"。

但感觉他们并不满足于只做 UI，他现在的定位已经是 “Full stack vibe coding platform” 了，另外一方面他们也在做 GitHub sync 等和现有代码整合的工作，而不再是只能在 v0 平台上生成。

3.8- Bolt / Replit / Lovable：" 想法到应用 " Vibe Coding platform

这一类的产品，其实有点大同小异。它们都是端到端的全栈平台，或者叫 app builder，有个更好听的名字叫 “idea to app” 。

相比 Cursor，它们解决的痛点一是部署（包括前后端以及数据库），二是更丝滑的 vibe coding 体验：我在 Cursor 里生成的代码反正也不看，为什么还要展示 code diff？直接 chat - live preview 才是更直接的体验。另外它们应该有一定的项目模板成分，让首条 prompt to app 的体验感受非常好。

虽然它们各自定位可能略有不同，比如开发者可能更喜欢 Bolt，非开发者更喜欢 Lovable（纯瞎说），但本质上做的事情是一样的：让用户在接近零手动改代码的情况下，搞出一个能用的产品来。

3.8.1- Vibe Coding 平台的困境

这个事情的 tricky 之处在于，如果他们的目标是 deliver 最终产品给用户，那用户的期待会很高。在比较严肃的场景下，用户往往需要非常具体的修改，全权让 AI 来改不一定能达到效果，而且还很费钱。我在用 Cursor 糊前端的时候，感觉加功能很爽，但想微调按钮位置、布局、交互逻辑时，它往往就改不对了。

虽然有些 vibe coding 平台也提供一定的 online code editor 能力，但真到了需要精细控制的时候，会写代码的人可能还是会回到 Cursor，因为那里最顺手。可一旦回到了 Cursor，后续的开发可能就没必要再回到 vibe coding 平台了。部署的痛点是一次性的，CI/CD 搞好之后，改完代码 push 一下就行。

精细开发的话，Cursor 的 agent 或许能提供更精确的 context。这些 vibe coding 的平台或许也可以把 coding agent 的能力都提上去，但是他们要做的事情太多了，把一个平台打造好得花很多精力。他们在 coding 的技术积累肯定是不如 Cursor 等 for developer 的平台。

简言之， vibe coding 平台在严肃、复杂场景下的上限可能不足。价值主要体现在：

  • 简单项目或 demo 原型
  • 非技术用户快速验证想法

但商业可行性存疑，类似 Vercel/Neon 等 PaaS 平台的发展轨迹：初期体验获赞，项目壮大后用户仍转向 AWS。

大胆预测：Cursor 可能整合 vibe coding 体验

  • 开屏对话框式交互
  • 集成 live preview 和云服务
  • 一年内实现此转型

3.8.1.1- Lovable 的自我定位 (FAQ)

比较维度 Lovable 宣称优势
用户体验 " 更自然 “、” 细节更优 "
视觉编辑器 支持 UI 元素直接修改（文字/字号/边距）
技术前景 远期目标替代 Figma（技术挑战大）

3.9- YouWare：User Generated Software 的激进实验

AI coding 真正让人兴奋的地方，在于它所展现的 " 自然语言调度算力 " 的能力。这让普通人能使用代码这个工具去解决他们自己的之前无法被满足的需求：一个 User Generated Software (UGS) 的时代，正在到来。

在所有产品中， YouWare 仿佛是一个精准为此而生的平台，它把 UGS 作为了自己唯一的目标。

3.9.1- 把 AI coding 做成内容社区，这对吗？

我一开始对 YouWare 谨慎不看好。

它给我的感觉，是想把 UGC 时代那套（社区、流量、平台）的想法，生搬硬套到 UGS 上来。如果他做一个新的内容平台，是要和抖音、小红书竞争注意力的，但感觉不如他们好刷。个性化的娱乐需求已经被短视频充分满足了。（……吗？在我说完这句话之后，又突然感觉短视频还是没那么好刷，也总觉得也总找不到符合我偏好的游戏。）

我最初的想法是：UGS 的潜力在于满足海量的、未被满足的长尾工具需求。用户不缺动机，只缺能力。如果是为了解决自己的痛点，那用户干完活就走了，不一定有分享或分发的欲望（或者在 Twitter/小红书上发发就够了），更不会没事干去一个工具网站上 " 刷 " 来 " 刷 " 去。

YouWare 认为许多人并不知道自己可以做什么，因此需要一个平台来激发他们的思考和创造欲，社交元素在此便扮演了激发灵感的角色。

v0、Lovable 这些平台，虽然也号称小白可用，也做一点社区，但它们仍然会把代码展示给用户，会弹出 build error，会让你去连接 Supabase。它们的假设用户，依然是有一定技术背景的 " 专业人士 "（如产品经理、设计师）。例如这段：“Lovable provides product managers, designers, and engineers with a shared workspace to build high-fidelity apps, collaborate effectively, and streamline the path to production-ready code.”

而 YouWare 的激进之处在于，它 完全不给用户看代码 。它面向的 non-coder 是更广泛的普通人。

这有点像小红书限制图文的字数，通过一种限制，反而最大化了目标用户的可用性。对于一个完全不懂技术的人来说，看到 build error 意味着终点，而在 YouWare 里，这个终点被隐藏了。

上面说工具需求和娱乐需求的区别，其实小红书也可以被看作是一个用户记录的工具，而且小红书火起来很大程度上是它 " 有用 "。

在我自己试用过 YouWare 之后（ 我生成的东西 ），感受了一些有趣的点

  • 确实有点毒性（以及免费额度非常重要）。比如我会有个脑洞就想扔上去看看行不行。如果用其他的平台搞正经项目的话我会更要掂量一下再做。（在心里预期包含了 debug 成本等，毕竟我是想要一个真的能用的东西。在 mental burden 上，YouWare < Lovable < Cursor，但有用性可能相反）。这种感觉和我用 cursor 的 background agent 时很像，都是 " 跑跑看，反正不亏 "。
  • 它真的隐藏了代码细节，包括失败。Lovable 在我试用的时候初次生成报错的概率还是挺大的（虽然点一下也就修了），而 YouWare 没出现过。
    YouWare隐藏代码细节的界面设计
  • 它鼓励 " 玩耍 "。YouWare 的 Remix 和 Boost 功能也挺有意思的（先不谈效果好不好）。很符合 " 用户并不知道他想 build 什么东西 " 的出发点，鼓励探索和再创作。
    • 但突然发现这东西很多家都有了，甚至连 claude artifact 都做了类似的功能，而且完成度高得惊人。）
      Claude Artifact的再创作功能
      YouWare的Remix功能界面

3.9.2- 一堆关于 YouWare 的零散思考

  • Vibe Coder 是什么样的人？ UGC 时代出现了一个新东西叫专业 " 创作者 "，现在的 “vibe coder” 倒是有点像。但内容创作者的收入主要靠流量和商单，而 vibe coder 更接近独立开发者，他们想的是 build 自己的产品，然后靠卖软件或订阅赚钱。卖软件终究要靠解决实际需求，然后去各个平台推广，而不是等着别人在你的 UGS 平台上刷到你（例如去发小红书而不是等人在 GitHub 上刷到你）。。 ……想到这里，我开了个脑洞：真要做的话，岂不是应该做 vibe coder 的 OnlyFans ，而不是 YouTube/Instagram？🤣
  • 代码确实有娱乐需求 （有个东西叫创意编程）…但还是那句话，娱乐需求是要竞争注意力的。再其中的一个小用法是把文章变成交互式网站，满足教育学习的需求，比如这些：
  • Power User vs. 小白用户： 这两者的需求是矛盾的，一个平台很难同时满足。YouWare 显然选择了后者。
  • 输出形式的局限： 为什么目前这类 coding 平台（包括 Devin、Lovable 等）的最终产出大多是网站？对于许多小型工具性需求，命令行或桌面应用或许更直接、更高效。当然，从 UX 角度看，网站对普通用户最友好。
  • 成本问题
    • 作为内容平台，有很大的合规风险和成本问题。但可能也没那么难，毕竟 deepseek 都能在国内上了。
    • host 网站的成本问题。以及不同形式的网站可能有不同的计算需求，对热门项目可能还得动态 scale。
    • Agent 的巨大算力成本。相比 UGC，用户生产内容时其实平台没什么成本，但 UGS 则不一样。相比 Amp 说我的优化目标就是最大效用，这里 YouWare 的账就更难算了，这里有很大的生成效果和成本之间的 tradeoff 要做。 这就引到一个核心问题是它鼓励用户创造，那盈利模式是什么？如果沿用传统平台的流量广告模式，考虑到巨大的成本，盈利上限恐怕不高。
  • 是否要对特定场景优化？
    • 例如现在平台上可能有过半用户会用来写报告什么的。但其实这是类 deepresearch 功能，在 YouWare 里做效果会很一般。Manus/flowith 倒是估计会优化（Manus 最近还真特化了 slides 功能，让我有点无语，说好的通用 Agent 最后还是做这种东西去了）。
  • 数据驱动平台演化？
    • 我一开始很困惑于为何 YouWare（包括 Manus 等）在能力尚不完善的阶段就大力买流量推广。而不是先将产品效果打磨得更好再推广。可能是他们已获得充足融资，急于扩张。
    • 但在产品成熟前就推出，可以帮助他们了解用户到底想 build 什么，然后针对性地优化。我之前可能低估了社交对于激发用户创造力的作用。这可能类似于一种进化算法，或者 " 伟大无法被计划 " 的理念：让用户自由探索，或许能裂变出意想不到的创新。YouWare 团队的字节背景，想必会沿用数据驱动的决策方式，通过用户行为来让平台演化，或许做着做着就能发现奇妙的突破点。

3.9.3- YouWare 的未来

我相信一家公司是有它的基因的。YouWare 的字节剪映 PM 创始人背景，或许才能想出这么个玩意儿。

虽然上面分析的很多东西可能 Lovable 会往 YouWare 的方向靠，更加隐藏代码；或者 YouWare 往普通的 Agent 平台上靠，提高 ultility，但期待未来的结果。我觉得 YouWare 的形态未来一定不是现在这样。同时我越来越觉得 YouWare 的出发点很有意思，或许能做出一些不一样的事情。这个团队可能比做 coding 的人更懂创作、平台和消费者，比懂创作者的人更懂 AI coding。

YouWare 的目标并非最大化 utility，而是 激发普通人的 creativity 。当然 utility 也要至少 good enough。

一个残酷的问题是未来会 curosor 的人越来越多了，会不会就吃掉这种傻瓜工具了？可能会想摄影师用相机和普通人用手机拍照可以共存一样，程序员和 vibe coder 共存。另一个想法是我最近越来越觉得，当前的 AI 正在加剧马太效应（或许从 200 刀订阅就开始了）。懂得如何用好 AI、并能负担得起开销的人（比如真见过人用 Cursor 一天消耗好几百刀），与普通人的差距会越来越大。对于那些不那么乐于动脑、需求表达不清的普通用户，他们会被 " 淘汰 " 吗？这个未来太残忍，我有点不愿设想，宁愿投身对抗潮流。从这个角度看，YouWare 这种致力于服务广大普通人的尝试让我觉得很有价值。

当然虽然 YouWare 很有想法。但认知能否成功转化为可落地的产品并实现商业价值，尚存不确定性。

4- 行业全景分析

4.1- 赛道矩阵

flowchart TD
    A[AI Coding领域] --> B[AI辅助编程]
    A --> C[端到端Agent]
    A --> D[Vibe编程/UGS]
    
    B --> E1("Cursor")
    B --> E2("GitHub Copilot")
    C --> F1("Devin")
    C --> F2("Claude Code")
    D --> G1("v0")
    D --> G2("YouWare")

4.2- 用户定位

类型 代表产品 核心价值 目标用户
🛠️ AI 辅助编程 Cursor, Copilot 增强开发效率 专业开发者
🤖 端到端 Agent Devin, Claude 替代初级工程 技术管理者
🎨 Vibe 编程 v0, YouWare 自然语言创造 非技术用户

📌 行业预测：到 2025 年 Q3，Agent 将成为中级工程师的智能合作伙伴

4.3- " 半成品 " 的尴尬现状，依然不够理想的成本与性能

我们必须承认一个现实： Agent 依然是一个 " 半成品 " 。它的效果还不足以真正端到端地交付一个完美的结果，有时甚至不如我们自己动手来得省事。（比如还是手动调 button 爽）

但我们也能清晰地看到 agent 的进化路径：从最早在 ChatGPT 里手动复制粘贴，到后来在 IDE 里进行单轮对话，再到如今的 Cursor Background Agent 和 Claude Code， Agent 能够独立工作的时间越来越长，做事的数量和质量都越来越高，这无疑是一个不可逆转的趋势。

或许我们应该换个心态：把它想象成一个外包合作方。你把任务派给它，让它干一段时间，然后你来检查、给反馈，而不是指望它一次性搞定。这和我们与人类外包商（也就是 “Agent”）的合作模式，并无二致。

4.3.1- 成本的诅咒，与模型的赌局

与此同时，Agent 是个非常贵的东西。这出了让用户不敢大规模使用之外，也让 agent 应用公司陷入两难：是继续不计成本地提升效果，还是转而研究各种 " 奇技淫巧 “” 雕花 " 以降本增效？但存在性能和成本的 tradeoff。我不知道是否可能同时兼顾两者，比如团队的一部分专注于性能提升，另一部分研究成本优化。如果完全不考虑成本控制，高昂的价格也可能会吓退用户。但 AI Agent 公司是否真的那么急于获客？或许也不然。

这里存在的一个更大的变数：如果上游的 LLM 厂商大幅降价，那么之前在成本优化上所做的努力，比如辛辛苦苦优化了 30%-50%，就可能因为外部因素而显得 " 白费功夫 "。当然，也存在原厂优化不力，或者他们转而发展自家 Agent 业务的可能性。因此，对于 AI Agent 创业公司而言，其决策中充满了需要 " 赌 " 的成分。

4.4- Agent 需要哪些能力？怎么做 coding agent？

从各个产品的探索中，我们可以窥见一个好的 Agent 需要具备哪些能力：

  • Memory/知识库 ：例如能自动学习 Cursor rule。（devin/manus 都有了）

  • Long context 能力 ：indexing & RAG？

    • 我对这点的作用是有点存疑的。现在进入 Agent 时代之后，Agent 可以自己去 grep 代码找到 context。而且这和我自己开发的流程也很像。还是大量依赖字符串搜索，并不是什么聪明的办法。但其实 grep 仅限于知道要改什么的时候。"xxx 是怎么 work 的 " 这种模糊的问题就不行了。
    • 但对于 long context 的考验其实挺难验证的，需要用的很深才能知道到底什么水平。我也还没有用出感觉来。

  • 任务管理能力：初期认为需要显式 TODO 列表，但 Claude 开始内化此能力

    Claude任务管理示例：
1. 分析代码结构
2. 重构模块X
3. 更新测试用例

    Claude任务规划界面

  • 主动沟通与 Interaction: 一个好的 Agent 不应该你说什么就做什么。它应该像一个好的乙方，会反问、会澄清意图、会评估风险（比如 Devin 的 " 置信度评级 “）。例如 " 我要做一个 ppt”，就问用户你有没有已经有的素材，或者课本资料提供等。deep research 类产品在这这事情上做的也不错。

话说回来，做好 coding agent 是不是需要你自己用 coding agent 用的很好？

5- 最后的思考：我们与 AI 的关系

那自然语言调度算力与 User-Generated Software 这个概念，可能 somehow 已成为行业共识，但其具体的实现形式，则远未达成一致。

聊了这么多，最后还是回到我们自己身上。

5.1- 普通人到底该怎么选？

总的来说，现在所有的工具都处于一个 “still early, but already useful (if used correctly)” 的阶段。它们在简单的小活儿或生成 demo 上表现不错，但在复杂场景下，则非常考验使用者的 " 手艺 " 。

这门 " 手艺 " 既包括 prompt engineering 的技巧，也包括对代码和 Agent 工作原理的理解。" 了解 ai 能力边界 " 也是个有点说烂了的东西。所以，未来能把 Agent 用得最好的，大概率还是专业人士。这就像专业摄影师和普通人的手机拍照，工具模糊了专业间的边界（比如工程师可以搞设计，PM 可以写 demo），但最终还是拉开了上限。

Agent 可能是越用越好用的东西，需在团队里一起探索最佳实践、积累 prompt 技巧和知识库，本身就是一种投资。

但我也时常怀疑，研究这些东西会不会是徒劳？等到模型能力到达某个奇点，我们直接拥抱最终形态就行了，中间的各种探索和使用经验都会过时。这或许是对的。多说无益，我也不再想按着别人的头让他用 AI，but I just can’t help playing with it, it’s fun! 😁🤪

5.2- 终极思考：生成能力的哲学

❓ 当 LLM 生成能力趋向无限时，我们该创造什么？

现实矛盾：

  • 🤯 知识获取更容易，但认知负担反而加重
  • 💻 代码生成无限制，但创造方向不明确

可能的答案：

graph TD
    A[无限生成能力] --> B[工具民主化]
    A --> C[创意释放]
    A --> D[问题重构]
    
    B --> E("YouWare类UGS平台")
    C --> F("艺术/教育创新")
    D --> G("重新定义人类价值")

开放命题：

🌌 这如同问 " 实现核聚变后该做什么 "——答案可能正在我们创造的过程中显现