不懂编程也能把脑子里的想法做成能用的工具，这是 Vibe Coding 给普通人的杠杆，2026 年人人都在试。作者用 WorkBuddy 十分钟做出一个工具，却在接下来的一星期里反复抓狂。他把这段经历完整复盘，讲清楚 AI 写代码真正卡人的地方在哪。

转眼间，又快要年底了，今年你Vibe Coding了几个真的用起来了的应用？

反正我已经有点数不清了。

2026年，可以说是人人都在Vibe Coding的年份。在这之前，确实是很难想象的，一个不懂编程的人，也能把脑子里的想法变成一个能用的工具，甚至带来经济价值。

当然，这背后依赖的是大模型在编程能力上持续提升，以及智能体的迅猛发展，并且我们拉长时间周期来看，大模型的能力一定还会越来越强，那么想法与实现之间的距离，也会越来越短。

而这对于有想法但是不懂编程的同学而言，我觉得它是一个巨大的杠杆！

甚至在我看来，Vibe Coding是一种造工具的元技能，我们每个人都应该掌握，以前遇到问题，首先去找有没有现成的工具可以解决，找不到的话，往往也就搁置了。现在没有的话可以自己造一个，因为成本足够低了。

Vibe Coding未必一开始就能帮我们做出什么了不起的产品，但我们可以从小处着手，去解决工作中那些琐碎、重复，又让人头疼的小麻烦。

这里举一个在大家看来微不足道的例子。

我经常从飞书文档导出Markdown，在发布到另外一个平台，但是导出的图片资源是临时链接，只有半小的访问时效，我不得不把图片一张张复制粘贴到另外一个平台，如果文章图片很多的情况下，就很费劲，遇到内容发生修改，两边同步起来会更加麻烦。

于是，我直接把我的场景和痛点口喷给了Codex，10分钟不到，它帮我Coding了一个浏览器扩展插件出来，大致实现思路是，把飞书中的图片上传到自己的OSS静态存储上，再将 Markdown 里的图片地址替换成对应链接，这样导出的文章就是我自己链接，不存在过期的问题了。

一个影响我效率的问题，就很轻松的被Vibe Coding出来的小工具解决了，并且没啥成本。

但对于新手而言，在开始Vibe Coding的时候，经常会有很多困惑，这里主要说两个非常典型的问题。

工具五花八门，不知道怎么选

说实话现在AI Coding的工具实在太多了，有国内的国外的，线上的和本地的，简直五花八门。

这里我并不会给大家分析这些工具的差异，也不想给大家推荐用哪一款工具更好，我只告诉你选择编程工具的底层逻辑是什么！

即使我现在告诉你Claude Code最好用，其它都没这个好，明天你在其它地方又会听到Codex最好用。

此时你就会动摇！到底哪个好用呢？你会始终被别人牵着鼻子走，一直在追求工具的路上。

所以我们要掌握的是评价好坏的能力，那么怎么判断呢？

首先，我们要搞清楚一件事情，无论是Claude Code、Codex、还是WorkBuddy，他们都是Agent。

而一个 Agent，我们可以简单理解为两个核心部分：Agent = Harness（身体）+ Model（大脑）

可以把 Agent 想象成一个人，模型相当于大脑，Harness 相当于身体和工作系统。

大脑负责理解需求、分析问题、推理决策，决定下一步应该做什么。

而 Harness 负责提供具体的执行能力，比如读取文件、修改代码、调用工具、以及管理整个任务的执行过程，上下文、记忆系统等。

而模型的能力往往决定了 Agent 能力的上限，Harness是保证下限。

并且这些Agent是可以换模型的，比如Claude Code 它不一定要用Claude的模型，它也可以用国内的模型，相当于身体没变，换一个脑子使用。

理解了这一点，我们再去理解别人说 Claude Code、Codex 能力很强，那它们到底是强在哪里？

其实是指Claude的模型和GPT的模型能力很强，而不是工具强，工具最终都会趋同，但是模型才是灵魂。

所以别去为了用上Codex，然后接入国产模型，没啥意义。

其次是上手门槛，我的观点是：先用起来比其它任何事情都要重要。

从用户使用入口来看，这些编码Agent分为5种形态：在线平台、编辑器、编辑器插件、命令行工具、桌面端工作台。

编辑器和命令行通通别去考虑，那是给专业程序员用的，对于新手最为友好的是桌面端工作台。

所以从这两个层面来考虑，一定要推荐的话，优先用Workbuddy，几乎没有门槛；如果愿意折腾，想吃点细糠，那就用Codex官方订阅。

Demo 出来很快，打磨起来却很难

很多同学在 Vibe Coding 时，应该都有过类似的体验：把想法告诉 Agent后，很快就能做出一个像模像样的 Demo，但要把它打磨到好用，这个过程却很慢。需要跟Agent沟通很多轮，不断修改，中途甚至跑偏，或者改好了这里，又把原本做好的功能弄坏了。

究其原因，还是流程没对，需求都没对齐，就开始写代码了。

为了更深刻的理解这个问题，这里我们要先看看传统的软件开发流程是怎么样的。

通常情况下，完成一个软件的开发，需要由产品经理、UI/UX设计师、前端/后端开发工程师、测试协作才能完成，从早期业务提出需求、验证需求可行性、产品经理设计产品方案、业产研对需求进行对齐、完成UI/UX和技术方案设计、任务拆解分工、开发编码实现、接口联调、测试与修复，然后交给产品和业务验收，通过后在发布上线。

大家可以看到整套流程分工很明确，专业的人做专业的事情，并且在真正进行编码之前，是有大量的验证、设计、确认环节的，目的就是尽早对齐需求理解，以减少后续返工的风险。

而Vibe Coding开发的流程又是怎么样的呢？直接跳过这些步骤进入编码实现环节了。

需求如果没有表达清楚，大模型就会按照自己的理解替我们做决策，如果把大量需要我们确认的都交给了AI做决策，最后实现出来的结果肯定会跑偏，在完成了在去纠正它，成本就很高了。

这也是Vibe Coding很普遍问题，其实传统软件开发的那些前置流程，就是为了降低发生这种情况的可能。

所以我认为更稳妥的Vibe Coding流程是怎么样的呢？

本质上还是传统的软件开发流程，验证需求可行性、方案设计、原型设计、编码实现、测试验证，这些步骤一个都不能减少。

其实编码在整个软件开发流程中只是其中一个环节，并且在AI时代是最不需要操心的环节，因为现在的大模型在编码方面已经训练得极好了。反而我们需要关心的是编码两端的流程。

同时，人机分工也发生了巨大的变化。

以前每个环节都是专业的人在干。现在，人变成了指挥官，Agent 变成了执行者。人只在关键路径上做确认和决策，但具体的分析、设计、编码、调试，全部交给 Agent 去执行。

就好比，我们从一线执行者升级成了Leader，不用再写代码，但是要决定做不做、怎么做、判断做得对不对。

讲到这里，可能还是有点抽象。

下面我就用最近做的一个文本 AI 率检测工具，完整走一遍这套流程。

整个过程也没用什么 SDD 框架，也没有依赖一大堆 Skills，就是通过简单的自然语言提示词，让 Codex 一步步把应用做出来，因为现在模型的能力足够强大了。

我是怎么用 Vibe Coding 出一个应用的？

先说一下做这个工具的背景。

起因是在朱雀文本检测网站上使用时，会频繁弹图形验证码，并且每天都有使用次数的限制，当然我知道平台是为了限流和防刷，但是体验感不太好。

基于这样一个痛点就产生了自己做一个检测工具的想法，但我并没有直接让 Codex 开始写代码。而是按照前面介绍的流程，一步步来。

先判断能不能做

我认为，无论做什么应用，第一步都应该先判断需求的可行性。可行性分析通常看两个层面：

1. 这个功能值不值得做？
2. 技术上能不能实现，成本结构是怎样的？

工具的价值层面我已经判断了，它是基于我的痛点出发的，值得做，所以我主要看技术上怎么实现。

于是我把需求直接通过语音转文字给了Codex，让它帮我做需求可行性分析。

它分析完给出的结论是可行，并给出了成本最低的解决方案，我快速扫描了一遍：它建议的是用朱雀API，跟现在用的平台是一致的，然后基于这个API做自己的页面。

因为这里核心是检测能力，能跟之前的保持一致当然是最好的，有了这个判断，我觉得这个方案是可以的。

注意这里的模式：Agent 做分析和罗列方案，人做最终判断和拍板。这就是“人在关键路径确认”的含义，我们不需要自己去研究每个技术方案的细节，但需要基于自己要实现的需求判断和技术直觉做最终决策。

把需求说清楚，输出设计文档

确定了可行性和技术方向，下一步是让 Agent 做详细的需求设计文档。

我这里有必要解释下为什么要让Agent输出设计文档：

在传统开发流程中，文档通常是团队中的一种负担，没人愿意写，写完就过时了，大家也不看，并且维护的速度永远跟不上需求变化的速度。

但现在执行的主体变成了Agent，文档恰好变成了人和Agent、Agent和Agent之间最重要的信息沟通媒介，原因如下：

第一，Agent 把方案写成文档，我们可以通读一遍，看方向对不对，细节有没有问题，有问题可以直接在文档上改。

第二，每一个 Agent 会话的上下文窗口是有限的，从设计进入开发实现，通常会开一个新的会话。那么前一个会话的思考过程、决策依据、技术方案，都需要通过文档传递给下一个 会话，没有文档，下一个会话就是从零开始。

这个也很好理解，大模型本身是没有记忆的，但它怎么知道我们之前聊过什么呢？

是因为每次对话，我们都把聊天的历史记录都给它了。但是要持久化记忆、或者夸会话记忆，就需要把这些内容放入文件中去，后续执行时把文件中的内容读出来放入上下文中就可以了。

有了需求设计文档，无论我们是新开一个会话，还是换一个Agent执行，都不需要重新给Agent解释来龙去脉，只需要一句话：“按 docs/xxxxx.md 实现”。

再做高保真原型，确认是不是自己想要的

方案设计完之后，并没有直接进入代码开发，而是进入高保真原型设计。做这一步是为了让整个功能设计更可视化，我能够直观地通过高保真原型看到界面上的功能交互和 UI 设计。

如果对任何交互或界面设计有不满意的地方只需要用自然语言描述我想要什么变化，AI 很快就能完成原型修改。在这个阶段调整的成本是最低的，因为它的原型是通过 HTML 文件实现，只有交互和UI，没有真实的业务逻辑。

如果等开发完成，在来修改的成本会呈指数级上升。不仅要改代码逻辑，还要改样式、改状态管理、改测试用例。但在原型阶段，改一个布局可能就是一句话的事。

所以这个阶段值得花时间反复打磨的。

注意这里做出来的原型，不是粗糙的线框图，而是接近最终成品的高保真设计，直接包含了交互逻辑和UI界面设计，它整个界面是可以交互的，包含空状态、处理中、检测结果、异常情况等状态的界面交互。

这在传统开发流程中基本很难做到，因为成本太高了，现在借助一个优质的Design Skill，比如Claude Design或者 baoyu-design，在对话中说“高保真原型设计”就能自动触发。

一切就绪，再让Agent执行长程任务

走到这一步，我们已经有了设计文档和确认过的高精度原型，那么让 Agent 写代码，对于现在的模型来说，就是一件非常简单的事情，这一步也是最不需要我们操心的了。

这里可以配合/goal命令，把设计文档和高保真原型一起发给Codex，让它按照文档去执行，它会按照顺序依次编写代码、运行测试用例、打开浏览器截图验证结果。

自动打开浏览器验证这里，需要依赖一个浏览器自动化操作MCP/Skill，我这里使用的Playwright，安装好之后，agent 就可以通过这个 MCP 打开浏览器运行项目，模拟人工进行交互。如果遇到报错，它也会自动从控制台获取错误信息并进行自我修复。

另外需要把权限设置为允许完全访问，否则它在执行中途弹个权限审批，你没处理的话，它就一直卡在哪里。

任务布置好下去之后，我们就可以去干其它事情了。

不过中途，它还是让我提供了朱雀官方的API Key，因为没有这个Key，它也没法真实验证逻辑是否跑通。

人工验收

agent 完成任务后，虽然它会自己也会写测试、跑用例、做截图验证，但我们也不能完全信赖它的结果，人工还是要做一次验收兜底。

因为我们前面提供了高保真原型设计，所以这里实现出来的样子基本上是百分之百还原，我们主要是验证它的一些功能逻辑和异常边界是否处理正确了。

如果遇到报错或其他异常，直接把错误信息反馈给 Codex，让他修复。

在验收过程中，只遇到两三个小的交付细节，让他修复了一下，之后基本完全可用了。

总结

回过头来看，整个过程里，并不是把想法扔给Agent，就啥都不管了。

从判断做这个工具是否可行，到确认方案、打磨原型，再到最后验收，每一步我都参与进去了。只不过我参与的方式，变成了表达需求、确认方向和判断结果。然后把过去需要专业人员才能完成的事情，都交给Agent。

工具会变，模型会变，但这套做事的方法，我认为是不会那么容易过时。

以后遇到新的需求，我们依然可以按照这个流程，把想法一步步实现出来。

回到开头的话题，Vibe Coding 是一种造工具的元技能。

对于大多数人而言，没必要一上来就想着做一个多么复杂的产品，就从工作中的小麻烦开始。把你的场景、现在的做法，以及希望达到的效果，直接告诉Agent。

先让它判断可不可行，再确认方案，必要时做个高保真原型，然后让它编码实现，最后自己验收。

核心是把需要人工判断、确认的问题尽量前置，把执行工作交给 Agent。

这一篇就先聊到这里，后面我们再继续。