独立开发3.0：如何使用vibecoding工具

前言

我大概是从2025年04月开始尝试使用AI工具进行开发，如果去掉磨洋工和学习其他内容的时间，到现在已经有4个月。最近刚刚完成第一个练习作品，所以准备写一个3篇文章的阶段总结，包括工具使用、产品设计、编程三个方面的内容。

年后到现在七八个月，我自己身在AI浪潮之中，感受真切。首先是ds的开源引爆推理市场，虽然一开始是惊吓，但市场很快就反应过来，AI领域无论是在资本市场层面还是产品和技术层面都可谓突飞猛进。这里我只从自己的主观感受描述一下历程，作为记录。

DS开源之后，很快Gemini等大厂的推理模型也开始加大推广，我最有印象的就是Gemini发了一年的学生账号免费，闲鱼上的号贩子忙翻天。

DS干废了一大堆模型自研厂商，但也直接催化了agent市场的繁荣（推理是agent的基石），很多agent类型的产品开始爆火比如Manus、Genspark、lovart等等，通用的、垂类的眼花缭乱。这时候产品市场就开始加速发展了，法律、金融、医疗领域都出现了专业的产品和技术解决方案。

在这之前出现了一个短暂的小插曲：MCP。目前已经不太能看到关于这个领域的大的新闻了，看样子是没什么戏。

6月以前最大的行业共识是来自于cursor，它证明了coding工具与市场的PMF，然后就是生物大爆发，windsurf、Claudecode都继续加速。

Agent与coding的结合领域创新产品很多，比如Base44、lovable、Bolt、Youware、nocode等等，都在解决产品设计、前端、后端整合方面的问题。不过最牛的agent，我觉得还是claudecode CLI以及最近的codex。

Claudecode CLI的发展还极大促进了开源社区的繁荣，与其配套的设计工具、prompt工具、路由代理工具层出不穷，很多人卖灰色工具/灰色账号都赚到了很多钱。

最近一段时间，明显感觉到各个领域开始偃旗息鼓，倒不是撤退了，而是在各个领域开始深耕市场。产品和技术逻辑都已经验证完毕，细分市场基本都有了玩家，AI市场进入到了成长期。模型厂商已经进入到了硬件升级降成本阶段，甚至不少人觉得C端领域的模型升级会告一段落，转入B端攻坚突破阶段。

半年时间恍如隔梦，我还记得学习Cursor的时候教程铺天盖地，学习Gemini/Claudecode CLI的时候却已经算是较早期的用户，需要等待一些教程的出现；在学习agent机制的时候教程已经不那么多，我自己写的一些文章也有了阅读量。我肯定比不上一些专业的程序员用户，但在工具上也有一点使用体会，希望能让更多人了解这个领域。

一、工具介绍：

模型

Gemini系列：稳定、高质量、全能、免费额度多；
Anthropic系列：编码能力；
Openai系列：唯快不破；GPT5路由能力大大降低了使用转换成本，越用越爽；
ds-R1：开创性的模型，产品能力和工程能力的阶段性集大成者。工程上是推理scallinglaw的验证者；产品上做了推理MOE显性化、搜索集成、极低价格、开源；
国产系列编码模型：GLM、K2、Qwen；

使用质量相对于sonnet有90分以上，但限制并发；
GLM不要买资源包（我是买过200资源包的大冤种），买月度会员还可以；
与claudecode等适配肯定没那么丝滑，不过也够用。

编程工具

Cursor

cursor的独到之处（当时的情况）：
- 让IDE成为万能工具；
- 认知和交互层面：ask+agent；自然拖动文件；图片识别解析；
- memory和规则机制：首次让用户理解了agent机制；
- MCP工具：辅助规划、自动测试、前端诊断、知识库等等；
- claude sonnet 3.7 的天作之合；
- 问题：付费不透明，20美金的套餐三四天就没了；
替代方案：
- vscode+cline/claude/codex：丰俭由人、稳定可靠；
- Trae、Kiro：换汤不换药，我觉得没必要尝试。

Claudecode CLI

CC CLI的独到之处（当时的情况）：
- CLI工具超越IDE的超强通用能力；
- memory与规则文件的大一统；
- 概念拓展：compact、clear、resume
- 自定义工具和助手：command、agent
- agents系统：扩展上下文、大规模并行自动化开发；
- 付费：5小时额度重置一次，20美金会员一次额度大概支撑1-2小时使用。性价比还可以；
相似工具：
- Opencode、Gemini CLI、Cursor CLI、Codebuddy：抄的都是壳子；
- 开源的不稳定、国内的模型不够；
辅助工具：claudecoderouter，学习成本不低，使用起来也不是特别好，还是推荐原生服务。

Google studio+cloud

Gemini文本、语音、图片、视频全能、高质量全能；
结合cloud的免费额度可以支撑产品demo验证；

codex

openai的编程工具，有多种形态，我用的是codex CLI；
非常适合解决单点、高难度问题，但据评测规划能力不如sonnet系列；
20美金的codex搭配20美金的claudecode是绝配，既能模型能力高低搭配也能补充额度。

构建工具

前端vercel：结合Github做自动部署；免费额度可以做demo；
后端supabase：认证、安全、数据库、环境管理、函数服务一站打包，适合编程小白；
代码托管Github：和vscode一样，都是基础工具。学习成本还是有一点的，但必须掌握。

其他工具我用的很少

通用agent：Manus、Genspark、OKcomputer；
一站式网站开发工具：Bass44、Yourware、lovable/Blot；
影音图设计工具：lovart、figma、canva、即梦；
开发小工具：github研究Deepwiki、多平台api切换Openrouter、MCP平台Smithery、本地部署工具Ollama；
下一代浏览器：Dia、Fellow、Perplexity、Gemini in chrome；
agent构建工具：n8n、Dify、COZE。

工具包推荐

编程工具（其实是全能工具）：vscode + codex CLI/claudecode CLI；
编程模型：GPT5（主力debug） + sonnet（主力干活） + GLM（替补）；
产品规划和设计工具：Gemini；
深度研究：Gemini Reasearch；
部署：Github + Vercel + supabase。

如何使用工具进行vibecoding

什么是vibecoding？

我个人觉得vibecoding这个名字起得挺好，让初学者明确知道现在有了一种不同的编程方式。当然，我也看到非常多的不负责的自媒体在夸张表达：程序员要失业啦！一句话做一个产品！人人都能编程！

这是非常严重的误导。

使用自然语言进行编程并没有脱离编程的范围。自然语言只是一种更高级的编程语言，它封装了更多的逻辑，让你更少关注甚至是不用关注一句代码一个接口是如何实现的。从这一点上来说，它更像是编程语言的内在发展的阶段性产物：机器语言、汇编、低级（C）、高级（java、python）、超高级（SQL、matlab）、自然语言。

但是如果你真的想做编程，基本的概念学习还是少不了：

前端的UI、交互、组件状态管理、服务层构建、页面路由、服务路由、类型管理、服务端和客户端概念、环境配置···
后端的环境管理、前后端一致性协同、服务抽象、接口规范、鉴权认证、安全与合规控制、日志监控、数据库管理、稳定部署···
数据库设计：···
自动化测试和部署：···

每一个概念拿出来展开又能写一大串，比如前端UIUX，涉及到样式、布局；色彩、字体、间距、组件库、图标库；交互逻辑、状态管理、数据流与错误处理。设计一个组件要考虑容器/业务/UI组件、全局/缓存/页面状态、UI/逻辑/服务层切分。

就算你把上面的都搞懂的差不多了，这也局限在工程开发上。

为什么需要这个产品功能？UIUX为什么这么设计？支付/模型服务如何选择？系统稳定/扩容/灾备如何保障？

你会发现这个vibecoding的范围还是无穷无尽。

如果你只是拿到了一个确定性的问题想让AI解决，你大概率会得到解决。但是，如果你只是有一个想法想让它帮你实现，你得知道这是一条漫长的道路，需要很专业的产品/设计/工程开发能力。如果你想让想法实现到可商业化的水平，这更是非常难，你还需要补上系统维护/产品定义/营销增长/企业注册合规管理等方面的知识。

今天上面这些做深度vibecoding会碰到的问题都不谈，只聊一件事：如何用好AI编程工具。我也先说明，我个人只是一个没有编程基础的产品经理，只是自己做了一个网站，很多AIcoding的高级用法完全没有涉及到，比如自动化测试和部署、ABtest、agents协同开发、复杂系统深度重构···不过，我也不会局限于如何用AI解决一个功能实现，我的目标是使用AI做出任何你能想象出来的软件。

架构很重要

产品架构、设计框架、前端架构、后端架构、系统架构···能把这些模块做好的人，在企业里往往也是各自领域内最优秀的一波人。在大企业的内部分工中，基础员工基本是不接触架构的：进了公司就继承前人的框架，修修补补。框架可以学，但基本没有实操机会。

但是在vibecoding上，具体的工程实现变得不那么重要，“概念”变得异常重要，你必须要做到“把话说清楚”。

世界上有两件难事，一个是把别人的钱放到自己兜里，一个是把自己的想法装到别人的脑子里。

vibecoding就是把你的想法装到AI的脑子里。它智商超群、能力无限，你说成什么样它就能做成什么样。所以如果你觉得使用AI做事效果很不好，那80%以上的原因是你自己不理解、没想明白、表达不清楚。

如何获得合格的表达能力、架构能力？读书读资料+复刻demo。

这一章我就略过了，如果你觉得自己架构和表达能力都一般，那建议先不要想着做多么复杂的项目，先放轻松做一些小demo练练。

正确认知模型

我知道还有很多人对模型的研发、内部构成比较疑惑，甚至是思考一些模型有没有意识、有没有生命的话题。建立对模型起码的认知还是有必要的，如果把模型当作不可知的“魔镜”，会给我们的使用带来很多问题。

当前我们说的模型基本就是大语言模型了，使用transformer架构，分为通用模型和推理模型。transformer架构之所以胜出，很大原因是它的多头注意力机制适配GPU的训练方式，能够更快速完成模型的验证。但它也只是找到了一种更好的理解语义的方法，本质上还是一个模拟函数。

计算机领域有个概念叫作“图灵完备”，只有一个实体达到了图灵完备，它才是一台通用机器，理论上可以完成任何计算（程序模拟）。图灵完备有几个条件：无限存储、条件分支、循环/递归。而大模型是有限上下文（有限存储）、无法无限循环、参数固定无法动态修改、概率生成结果（不可复现）。

为什么要借用这些概念呢？我是想说明，模型只是一个函数，一个输入内容得到结果的函数。它无论如何表现，就是一段冰冷的程序。我们要做的就是了解它的参数权重、控制输入、获取输出结果。

就这么简单。

为什么有些人很担心模型对人类的操作等等，他们就没搞明白模型只是一个函数。只是这个函数的权重矩阵非常庞大，庞大到可以模拟人类所有的语料和思考。但这个就好像一个人照镜子，无论镜子影像多么逼真，它也无法从镜子里走出来。

模型如何进化成图灵机？这时候就引入了agent的概念。

广义上Agent是一个能感知环境、做出决策并采取行动以达成目标的自主系统，狭义上是一个基于大语言模型的系统，它能理解用户输入，结合外部工具和记忆，自主规划并执行一系列动作来完成任务。

它的几个特性：感知、决策、行动；有大脑、有上下文记忆、有“自主性”、能做工具调用。

如果你想用模型完成任务，比如做一个自动接听电话的语音客服，你可以给它接入存储器、修改它的参数、加入逻辑控制流程和工具调用；如果你想让它做客服也能做家庭教师，那就需要在这套框架上它更通用，比如需要判断应用场景，调用不同的场景工具完成任务。这时候模型就进化成了agent（甚至是通用图灵机）。

到这里为止，模型和agent还是无法威胁人类，因为它只是一台能执行更泛化的任务的机器，升级版的电脑。

质变的一步在于，agent能够自己修改自己的参数权重、自由更新长期记忆和条件分支/递归/循环逻辑。一旦能做到这一步，机器就彻底拥有了自主意志。但即使到这个阶段机器也不能摆脱人类的控制。后续的推理就太过于遥远不展开了。

费了这么大劲，我只是想说明，我们普通人对于模型的使用是很简单的事情，完全都到达不了agent构建的层面，就是简单的输入输出。我们要做的就是判断任务的性质、选择合适的模型、提供精确的上下文、做关键的决策、进行任务的总结和存储。

等等，为什么我要做agent系统负责的事情呢？没错，用好模型的方法就是让自己成为一个agent，一个超强的智能图灵机！完结撒花hhh

模型工具使用建议

认知模型能力

模型不稳定：上面也提到了，模型是一个概率。一个模型在相同的问题上、不同的问题上、不同的时间，都会产生波动。有时候精力体力惊人，有时候像个弱智。这时候一定不要头铁，即时切换。
多模型交叉确认：由于模型能力参差和不稳定，而我们对架构等规划文件质量的依赖又非常重，为了高质量完成规划任务，一定要使用多模型交叉验证。比如用sonnet制定了一个开发计划，让GLM、GPT5轮番上阵去纠错，直到找到三者的最大公约数方案。这个方案的质量会远比用单一模型做一次、做多次的质量要高。当前有很多人在探索在单一工具中构建多角色的模型完成任务，比如构建产品经历、测试、架构师、研发等等。但我的经验是，与其在单一模型中构建不同子agent，不如同时使用多个模型针对同一个问题发起质询。我的做法是使用vscode和cursor同时打开一个项目，一问一答，效果不错。原理也很简单，多个模型相关性很低且能力互补，其合作收益必然大于子agent直接的能力互补（更何况agent都是瘸子）。
重建比重构简单：模型初始化项目时使用的是你最初的上下文、它自己的记忆和知识，是它表现能力最突出的阶段。当一个项目经过反复变更，产生了大量垃圾信息，它就会不堪重负。所以一定要牢记，在研究、规划、架构方面加大注意力资源的投入，这会节省几倍、十几倍的资源。【有时你做个规划，它会显示要10天完成，你点击执行它20分钟就完成了，你会想这样不过如此嘛。但实际上，如果你做的规划不好，它真不是危言耸听，修10天都算是快的】
模型没有“记忆”。这个概念很容易混淆，但使用者必须要记住，模型只是知道它自己的参数权重、只是知道这几轮对话你们的内容，不要以为它能记住什么。对这个机制的利用就是，在每一个任务章节给它注入最精确的内容，不要模糊、不要让它自由搜索自由规划。同时，尽量用简短的上下文解决问题，不要用长上下文，越长处理效果越差。
agents功能怎么用：我知道很多工具内嵌了agent，让你设置不同的agent组合完成任务，但我的认知是，子agent只适合完成重复性的工作，比如你告诉它有个什么功能已经构建好了，让它复刻一个应用到某某模块；或者让它做一下深度搜索，节约一下主agent的上下文资源。除此之外，不建议使用。我也看到很多人在夸agent机制很好用，我猜要么他们没有深度使用，要么是接入了很重的控制流工具或者规则，如果是后者，不建议个人模仿，这是个繁重的工程。具体可见独立开发2.4：多Agent系统的架构演进(系列终篇)

为模型提供上下文

架构很重要。我是从零开始学习编程的，项目架构和编程规则写了五六版不止。一开始用cursor我记得我连rules也没有设置，做一做前端ui还行，比如做个button、做个页面，但是稍微多一点点整个项目就崩了。除了模型能力不行之外，重要的原因就是我没有约束模型的编程规则也没有给它提供项目架构。后来我去YouTube上找了一些教程，学着写rules（其实是直接生成的，我也看不懂），前端总算能控制住了。再后来加了一点后端功能，项目又崩了。这时候我才去认真学习一下什么叫做编程规则和架构。就这样又信心满满做了一个月，又崩了。然后我又开始深入学习了一些，同时了解了memory机制和rules机制，才慢慢控制住了项目，具体看独立开发2：less intelligence，more structure。架构和规则我也没法教，我只能说这个很重要，而且每个人侧重点不一样，并不那么通用。最好的方式还是你选好自己的技术框架（比如用nextjs），然后边做边总结。
架构要化整为零。我曾经尝试过很多种管理说明文档的方式。比如构建prd、uiux、structure文档，以及配套的service、database、workflow文档、项目分版本计划、重点迭代记录等等，然后使用专门的agent进行文档的维护；或者维护一个综合的structure文档，降低文档维护的压力。但最后的效果都不好。原因很简单，一个功能更新你就要维护多个文档，你吃不消，模型也吃不消，慢慢文档内容就失控了。但这个也没办法，如果是小白做编程，根本没有办法做内容取舍，你会觉得什么都重要，最终攒了一堆破烂文档。规则控制文档最好的效果一定是你经过实践总结出了相对稳定的方法论和规则，然后把拆散放到每一个模块的claudemd文档中。比如前端一个、后端一个、全局一个、重点模块再写几个。这样做某一个模块的时候模型才能获取到真实有效的参考信息和约束，才能不跑偏。我知道prd、uiux、structure很重要，但这些大文档更多的是给人看的，在单次任务中模型很难消化。

成为模型的工具箱

智能路由：在模型卡壳鬼打墙的时候，你要指引它去参考某文档、某个知识，终止流程重新制定方案等等；
在模型不方便获取控制台、终端、数据库等信息的时候，要及时补充确实信息；
尽量不要太依赖自动化，要躬身入局，成为工具的一部分。

人做框架和决策，模型做执行

永远做不了撒手掌柜。我现在还能记起，我第一次看到模型一下子给我输出了后端数据库全部库表和服务的时候那种震撼。但很快我就傻眼了，因为问题太多了。我在项目中的每一次偷懒都让我加倍奉还了：认证模块、支付模块、前端组件层级拆分、后端服务标准化构建、统一错误响应、页面路由设计等等等等。到最后，重构了五六次，我虽然写不出来每一个服务和组件的内容，但它们为什么存在、上下游调用关系是什么，我基本知道七七八八。这是避免不了的过程，必须要接受。那些说“一句话生成xx产品”的自媒体，早点取关。
抓大放小，信任模型：如果改一个东西时你发现模型在跟你反复拉扯，它总是搞不明白你要什么、交付一些没质量的结果，那么很有可能原因是你的逻辑不够优雅，不符合最佳实现。最好的办法是放手，解除所有限制，让它自己定框架自己整改。

提效建议

自定义命令：如果工具支持自定义命令，我建议设置一下，比如中英文翻译、自动git、轻量化的自动查询等等。很提效。
是否要测试驱动开发？我看到很多人在跟风吴恩达提这个概念，我想说并不一定。首先测试是很重的流程，你需要把前前后后逻辑都梳理清楚才能写出这个测试程序，但实际情况是，开发过程中你可能都不知道最终方案是什么。测试驱动是很美好的愿景，我觉得产品稳定之后可以补上测试流程。

心态和认知

你觉得什么都对，只能证明你是个外行，需要加倍仔细。
模型是不稳定的，如果想让任务按时完成，你能做到就是每天前进三十公里，无论刮风还是下雨。
我觉得AI时代，每个人一周要主动消耗1百万token才不至于一无所知。行业内的人，一天消耗1千万token是基础水平。
用好模型有两方面必须要加强，第一是把自己当成agent，全力辅助模型做任务；第二是把自己当老板，事无巨细、事必躬亲、充分信任员工但鸡蛋不放在同一个篮子里、持续成长。
使用transformer的架构思想来做事情：多头注意力（要建立全局认知，不要线性推进）、残差连接（要保留原始经验/直觉，别在复杂过程中完全丢失核心目标）、层化归一（每做完一个阶段，要有“归一化”的心态调整，避免过度放大局部的情绪、极端的波动）、前馈网络（信息收集之后，要经过加工、抽象、提炼，变成真正能指导行动的知识或策略）。

前言