我不是程序员，编程能力也一般，但是前两天我花了一个下午用 Claude code 和 Claude agent sdk，在自己的服务器上构建了一个完整的个人 AI agent 小助手，虽然还比较粗糙，但是我现在可以24/7 通过它分析数据、处理文件、构建界面。

全程我没有写一行代码，只是在构思和交流。在和 Claude code 交流，并且目前还一直在迭代，以后也一定是这样的方式，我想这就是 vibe coding 的乐趣，不是掌握编程语言或框架，而是把 AI 当作你思维的延伸——以对话的速度，把模糊的想法变成真实可用的产品。

产品感比代码能力很稀缺

今年，我自己构建了几十个 demo，不是为了炫耀，而是我发现：demo 是传达想法最有效的媒介。

也是得益于此，我进入到 AI 初创当产品经理，后来 mentor 跟我说我的简历都没有表现出我和公司的契合度，而是我在 github 里面的一些项目，让他特别想要我。

demo 有几层价值，首先是把你的思想外化，把模糊的想法变成具体的，在你实践的过程中，你会发现你接下来的思考会更轻松，因为你的思考是基于一个已有的东西去延伸，而不是一直在天马行空的想象。就像 AI 的思考模式一样，可视化你的思考过程往往会改变你的结论，先前的 token 会收敛你后面 token 的输出，不至于最后想法很好，实践起来就…

第二个就是我在前文提到的，让别人相信你看到的，建立信任。在学校的时候，很多人对 AI 的理解还只是停留在简单的对话，我写了很长的如何用 AI 高效分析、调研、访谈的工作流方案，想和同学一起做一些事来赋能一下现有的工作——没反应。然后我做了一个 demo，用 coze 和飞书表格，只花了几个小时，将我们之前的来访者访谈到分析的整个过程流程化。从来访者预约、时间安排、到访前通知以及过程中录音转写到分析，然后他们就信了。

为什么？因为 demo 是信息密度最高的格式：报告会让人睡着、Slides 会让人分心、Demo 让人看到自己眼睛的真实信息…

第三层就是 AI 已经让我们（至少是我这样没技术背景的人）利用最低的成本，让别人看到你的想法到产品。从概念到可用产品，demo 的成本最低，一个下午+一个 AI 工具 = 你可以展示给 100 个人的东西，这就是为什么我对 demo 着迷。

vibe coding 的六大核心技巧

技巧 1：不要凭空创造，学习别人已经做过的

这听起来有点反直觉是吧，而且很多人肯定会说你这不就是抄，但这是最快的前进方式。

当我用 Claude code 构建一个 web dashboard 的时候，我没有让他凭空创建，而是：

在 GitHub 上找一个开源前端项目

告诉 AI：「按照这个项目的设计风格，给我一个 React Dashboard 组件库」

AI 理解了美学，直接生成了匹配的代码

假如我直接创造呢？他会给我一个「给我一个漂亮的 dashboard」，但是需要 10 轮反馈调整颜色、间距。我很清楚，自己并不是一个设计师，并且我自己脑子里的想法甚至都不是很清楚，与其去做填空题，不如去做选择题。

在哪搜索？GitHub 上的开源项目（包括样式表）、设计展示网站（Dribbble、Behance）、竞品代码（用浏览器开发者工具检查）……

我自己无聊的时候比较喜欢看 mobbin，去刷一刷网站或者上 x 去看看大家的分享，然后用 mymind 去记录一些好的创意，不仅仅是记录，有时候光看这些就挺开心的。

其实不仅仅是一个设计，包括说一些有用的，可能我现在用不上，但是我觉得它非常有用，我就会先把它记录下来。后面我需要的时候，我就直接从中去找。

有一个记录的过程，就会让你的记忆留下一个印象。你后续再去做一个什么东西的时候，可能就会想起这个东西。想起这个东西，你就不用再去大海捞针地去找，你可以从已经收集到的地方去进行一个寻找。

这不是「拼凑怪物」——这是最高效的学习方式。著名的 Roguelike 游戏开发方法论就是这样：站在巨人肩膀上，快速迭代。

技巧 2：不断问 AI，逐步探索——每个操作前都要问为什么

我最初对 VPS 一无所知。什么是 SSH？端口转发怎么用？Docker 是什么？

但我没有去买课程，而是在每个操作前都问 AI：

「我怎样在手机上远程控制 Claude Code？」

「这个 SSH 密钥是用来干什么的？」

「Docker 对我的项目有什么好处？」

AI 会解释概念、给具体步骤、遇到问题时帮助调试，所以我现在就能直接从手机 push 代码到 GitHub，用 Claude Code 在远程服务器上工作。我从未上过一堂 Linux 课，但我学会了「做事」。

这也是我认为的 vibe coding 的精髓之一：不是「先学技术，再使用它」，而是「让问题驱动学习」，这样每个提问都是一个教学时刻，也算是干中学吧。

技巧 3：渐进式开发——理清顺序和依赖关系

构建 AI Bot 时，我最初的计划是：先做消息处理器、再做用户管理、再做会话管理、再做Agent 集成、最后安全方面…

但是到了第三步的时候，我发现安全需要提前设计，比如说一些权限隔离。然后像消息处理器，它就依赖后话管理的接口定义，那用户管理又需要去预留配额的空间，所以我就跟 AI 一起去重新排序。

我首先就是去定义这个数据模型，比如说 user、session、task 结构。然后第二步就去实现这个核心的逻辑，像 agent 和 mcp server。然后第三步就是添加约束层，就是每个用户它有多少的存储空间。

因为我这个项目不仅给我自己用，它会给我家里人一起用，帮他们把一些生活上的一些需要用到 AI 的东西全部打包放在这个 bot 里面。所以我会给每个人都会配一定的配额，毕竟 VPS 它的存储是有限的。

然后权限和安全方面，因为我给他们直接用的是 Claude agent，如果不有一些权限的限制的话，那有可能他们的提示不小心触发了 Claude agent 的一些操作，就会把我整个项目给损毁。所以我就添加了一些安全的一些权限。

最后就是集成交付层，就比如和聊天软件去集成。

这个顺序的好处就是我后面的模块，就不用后面模块的添加就不用去改变前面模块的一个接口。所以我加新功能的时候，AI 的上下文就会更加清晰。而且我一旦出现了 bug，我就知道我具体是哪一个层面出现的问题，我就直接去针对性地修改这一个层面就好了。

这其实就是一个基础的系统设计，我个人认为虽然我不懂代码怎么去实现，但是很多架构方面的东西你要想清楚。

就像我们去做事情一样，整个一个先后顺序，你去驱使 AI 去做事情也是有一个先后顺序，所以 AI 能够帮你去实现它，但是你自己必须要思考清楚。

技巧 4：一个文件，一个工作——写模块化代码

如果一个文件有 2000 行，AI 出错的概率成倍增加。如果一个文件 100 行，只做一件事：

AI 的上下文更好

你能更快定位问题

改动的影响范围受限

代码块复制

bot/├── handlers.py # 仅处理来自聊天软件的命令├── agent/│ ├── client.py # 仅连接 Claude Agent│ ├── tools.py # 仅定义自定义工具│ ├── task_manager.py # 仅管理后台任务├── user/│ ├── manager.py # 仅管理用户数据│ ├── storage.py # 仅处理配额├── session/│ └── manager.py # 仅管理会话

LLM 在小的、聚焦的任务上表现肯定是更好，当你要求它「写完整系统」时，就像 10 个开发者同时编码但不沟通、非常混乱。

所以我一般就是一个文件实现一个目标，然后不同的功能就放不同的文件夹里面。

当我想要去改某个功能的时候，我就告诉他在哪个文件里面去添加一个什么样的函数，或者说他自己就能够根据文件结构自己去非常确定地知道在哪里，而不是说一类功能你把它拆到了不同的文件里面去放。那这样子就会非常混乱，他就很容易搞错。

技巧 5：架构思考（5 分钟头脑风暴）

在每次开始写代码，我会先把我的想法给 AI，先去说我会先跟他说，我们先讨论一下，你可以先不急着去往后实现出来，然后看有什么样的一个方式，能不能实现。

首先我先要问他能不能实现，要实现的方案有什么样子的，然后他会给我一些架构的建议，以及一些潜在的问题，还有一些那种方案的选择，就让我能更有掌控感。

这样我也能够确定我的想法不会特别离谱，或者说他需要、他无法实现什么东西，然后他又需要什么，比如说一些 API key 啊，或者说一些外部服务的时候，他能够去指导我，去帮他去获取。

我感觉好的架构它能够预防你 80% 的后续问题，并且「先改架构」是比你「开始架构好了后面去改代码」这样是更容易一些。

并且对于我这样没有什么开发经验也没有系统学习过的人，我觉得 AI 的建议往往是会超过我的知识。所以你在干什么事情之前都去问清楚，跟他讨论清楚。如果你自己不放心，每个人再去做一些事实核查，用其他的 AI 做核查也是一样的。

技巧 6：利用 Claude Code 和 Agent SDK

这真的是 vibe Coding 的最高杠杆工具。我真感觉这个好东西就是被 code 这个字眼给耽误了，Claude code 何必只能写代码…

2025年9月，当 Anthropic 宣布将 Claude Code SDK 正式更名为 Claude Agent SDK 时，这不仅是一次命名变化，更加表达了他不仅仅是写 code 也能够胜任通用任务。

官方工程博客明确表示：「The key design principle behind the Claude Agent SDK is to give your agents a computer, allowing them to work like humans do.」

Claude Agent SDK 的核心优势：

MCP Server： 让 AI 使用自定义工具

上下文管理： 自动管理上下文和会话

工具调用： AI 可以主动调用你的函数

比如你就去跟 Claude Code 说，使用 Claude Agent SDK 构建一个花费分析器，用户上传收据图片，Agent 提供统计、分类、支出。那他就能够直接去用这个 SDK 去写一个整体的框架，去处理你的文件上传，管理对话状态，调用你的自定义攻击。

并且 Claude Code 在他的 plugin Marketplace 里面就有 能帮你去写基于 Claude agent sdk 程序的插件，也就是说他自己就能够去查看这个 SDK 去帮你写，不需要你自己去查一些使用文档，去告诉他该怎么写。

所以他对用他来写 Claude Agent SDK 相关的一些软件或者功能是非常友好的，非常顺滑的。如

果你用传统的方式，你去把一些文档、使用文档去复制粘贴给他，或者说告诉他怎么去做，他就很容易会遇到一些错误情况。因为他自己本身就不了解，然后他在去调用一些服务的时候，他就很容易把接口写错，就会出问题。

从想法到产品的完整工作流

步骤 1：问题定义，不是解决方案

我认为错误的方式是你教他用 Python 写一个项目，用 Flask API 集成 Claude API 等等。我觉得正确的方式：我想在自己的服务器上有一个东西，然后能够随时通过指令，出了问题让他处理文件。

这两个有什么区别呢？

首先，为什么我会使用第二个方式？也是因为我对于技术的了解不是那么多，所以我也不会去问他像第一个问题那样子那么具体，让他去用什么技术的一个问题。

然后第二个就是，我觉得第一种方式限制了 AI 的思考，因为你怎么能够确定你用 Python 方向就一定是用 Python 这个语言去写，一定就是对你这个程序是最友好的呢？然后说 Flask API 难道就一定是最优的吗？

所以我第二种就是直接让 AI 自己去判断、去选择最佳的框架。那我们只用去定义 what 和 why，那 AI 他自己去推荐 how。

步骤 2：架构思考——5 分钟头脑风暴比 5 小时返工更值

在开始写代码之前，我会先和 AI 进行一次架构对话。这个步骤很多人会跳过，因为他们觉得「反正 AI 会帮我写」，但这恰恰是最容易踩坑的地方。

我会这样和 AI 对话：「我想做一个聊天软件 Bot，用户可以通过它和 Claude Agent 交互。这个 Bot 需要支持多用户，每个用户有独立的工作目录和存储配额。你觉得应该怎么设计模块？有什么潜在的问题？」

然后 AI 会给我一个初步的架构建议。但这里的关键不是 AI 给了什么答案，而是我怎么评估这个答案。

我会问自己三个问题：

我能理解这个架构吗？

如果 AI 给我的架构我自己都看不懂，那后面出了问题我根本没法调试。比如第一次 AI 给我的方案里，它建议用一个复杂的事件驱动架构，有 Message Queue、Event Bus 什么的。听起来很专业，但我根本不理解这些东西是干什么的。

所以我直接告诉 AI：「这个太复杂了，你能给我讲一下不，通俗易懂一点」。总之不会就要问，AI 又不会骂你，他会细心的教你。

哪个模块风险最大？

AI 的初始方案很简单，它把整个系统分成四层：聊天交互层、Agent 客户端层、用户管理层、数据存储层。听起来很清晰，但我意识到一个问题：安全。

我的 Bot 可以读写服务器上的文件，如果用户A可以访问用户B的文件怎么办？如果 AI 出错，把我的整个服务器文件都删了怎么办？这些 AI 在初版架构里都没考虑到。

需要加安全层吗？

所以我又问 AI：「如果一个用户恶意操作，或者 AI 出现 bug，怎么保证系统的安全？」

AI 给了我几个建议：路径隔离、Docker 容器、权限白名单。这时候我才意识到，架构设计的时候就要把安全考虑进去，而不是等到代码写完了再补。

这 5 分钟的对话，省了我后面至少 5 个小时的返工时间。

因为如果我直接让 AI 开始写代码，它会按照最直接的方式去实现功能——没有安全检查、没有路径隔离、没有错误处理。等我发现问题的时候，代码已经写了几百行了，改起来又要重新理清楚逻辑。

架构思考的本质，不是让 AI 告诉你该怎么做，而是逼自己想清楚：这个系统的边界在哪里？最容易出问题的地方是哪里？如果我只能优化一个模块，我会选哪个？

步骤 3：逐模块实现——一次只做一件事

确定好架构之后，很多人会直接让 AI「把整个项目写出来」。我一开始也是这么干的，结果就是 AI 写了一堆代码，我完全看不懂，出了问题也不知道从哪里开始查。

就像人一样，每个人的精力，工作都是一点一点做的。AI 也是一样的，你让他把所有的精力都用来做一个东西，他就能做得好。但如果你让他分散精力去想那么多事情，他可能就没有那么多精力，就会容易出错。所以我后面也是一次就让 AI 做一件事。

比如说我要去做一个用户管理模块，我不会说让他直接去帮我写一个用户管理系统，因为太模糊了，他自己可能会脑补很多你根本不知道的功能。

得具体一点，实现一个 user manager，有什么功能，比如创建用户、获取用户的配置、检查存储配额，然后更新存储的配额使用量，然后每个用户它的数据又是在一个单独的文件夹上。

这样子 AI 就知道边界在哪里，就不会写着写着就跑偏了。

如果你自己都想不清楚的东西，你也可以把你的想法你就跟他说，我要写一个用户管理模块，然后你就问他用户管理模块大概有什么样的部分。把一个大需求你跟着他一起把它给拆分下来，然后一个一个的来做，相对来说写起来也不会那么容易出错。

步骤 4：处理错误和细节——让 AI 自己测试，给 AI 足够的上下文

代码写完不代表就能用了。我感觉花在调试上的时间比写新功能的时间还多。慢慢的也就养成了两个技巧，让调试效率提高了很多。

首先就是让 AI 自己先测试代码。

以前我会让 AI 写完代码就直接集成到项目里，然后运行整个项目看有没有问题。结果经常是：项目跑不起来，但我不知道是哪个模块出了问题。

所以现在我会在 AI 写完一个模块之后，直接告诉它：「写几个测试用例，验证一下这些函数是不是正确的。」

AI 自己写测试、自己跑测试，大部分低级错误——比如参数类型错了、路径拼接错了、边界条件没处理——它自己就能发现并修复。等它告诉我「测试通过」的时候，我拿到的代码质量比「写完直接交付」高很多。

第二就是报错的时候，给 AI 足够的上下文。

这是我踩过最多坑的地方。一开始遇到问题，我会直接告诉 AI：「这个功能不工作。」然后 AI 就开始猜——可能是这个问题、可能是那个问题——猜了十轮还没猜对。

AI 不是神，它需要你告诉它发生了什么。

现在我报错的方式是这样的：「我上传了一个 2MB 的 PDF，期望得到 Markdown 输出，但系统返回了 'Permission denied'。我觉得可能是目录权限问题，因为这个目录是第一次被写入。」

这种描述包含了三个关键信息：我做了什么操作、我期望什么结果、我实际得到了什么。有了这些，AI 基本上一轮就能定位到问题。

坑 1：URL 拼接错误

我用的不是官方的 Anthropic API，而是自己的 API 网关。配置的时候，我把 base URL 写成了 https://my-gateway.com/v1。结果一直报错，找不到接口。

查了半天才发现，Claude SDK 会自动在 URL 后面加 /v1，所以实际请求的地址变成了 https://my-gateway.com/v1/v1。

这种问题 AI 帮不了你，因为它不知道你的配置是什么。我的解决方法是：在集成到项目之前，先用最简单的方式测试。比如直接用 curl 发一个请求，看能不能通。如果 curl 都不通，那问题肯定在配置上，不是代码的问题。

比如说我这里，我直接问他「你能做什么」，结果呢，他返回了一个 AI API 的报错。这个是在我刚集成了 API 之后，然后就直接去测试，然后他就给我报了错误。

所以我就一直让他去检查到底是哪里错的。他就必须是用写完了的整体代码去测。

如果是我在让他集成之前，就先去把这个什么网关配置、模型的名称什么的都自己去测、去填写好，再把它集成进去，就不会那么麻烦。

因为他现在是跟着整个代码一起去测试，然后整个代码又是跟整个大项目联合在一起的，所以说你让他去测试，就可能会动到其他的部分。这样子就会有一些不必要的麻烦。

所以你把这个单独的 AI API 让他单独地去测试，就是在最小程度上去减少影响到其他的方面。这样子首先他专门调这个地方也会调得比较专注，第二个也不会牵扯到其他的部分，就是不会把你的测试的部分跟你的生产代码放在一起去混淆。

坑 2：Markdown 格式问题

AI 默认会用 Markdown 格式输出，加粗、斜体、代码块什么的。但我发现我在用的聊天软件

一开始我想让 AI 在发送前自动转换格式，但这样太麻烦了，而且容易出 bug。后来我直接在系统 prompt 里告诉 AI：「在这个聊天软件加粗或斜体。可以用编号列表或者换行来组织内容。」

当然，其实你这么跟他说，他有时候还是不会去遵守这个prompt 规定。所以我就直接写了一个脚本，用正则公式直接把这些什么「加粗」「斜体」这种原始的格式直接给去掉，问题直接从源头解决了。

坑 3：目录不存在

有一次我家里人上传文件，系统报错「目录不存在」。原因是代码里假设目录已经存在，但对于新用户来说，他的专属目录还没有被创建过。

这种问题在本地测试的时候不容易发现，因为你自己测试的时候目录都是现成的。解决方法很简单：让 AI 在写入文件之前，先检查目录是否存在，不存在就自动创建。

但更重要的是，这让我意识到：很多 bug 不是代码逻辑的问题，而是环境假设的问题。AI 写代码的时候，它假设的环境可能和真实运行的环境不一样。所以我现在会特别注意问 AI：「这段代码有什么前置条件？需要什么目录、什么权限、什么依赖？」

总结一下处理错误的心法：

先让 AI 自己测，减少低级错误

报错时给完整上下文：做了什么、期望什么、得到什么

集成前先用最小方式验证（curl、简单脚本）

问清楚代码的前置条件和环境假设

归根结底，调试不是玄学，是信息战。你给 AI 的信息越完整，它帮你定位问题就越快。

产品思维——代码能学会，这个学不会

到这里，有人可能会觉得：用 AI 写代码也没什么难的嘛，跟着步骤来就行了。

但我想说的是，代码只是最容易的部分。真正决定你做出来的东西能不能用、好不好用的，是你的产品思维。而这个东西，AI 帮不了你。

我举几个我在做 AI Agent Bot 时的真实例子。

设计 1：为什么要做存储配额系统？

一开始我没想过这个问题。用户上传文件，我就存到服务器上，很简单。

但后来我算了一笔账：我的 VPS 总共 150GB 硬盘空间。如果我开放给 10 个朋友用，每个人传 20GB 的文件，硬盘就满了。更糟的是，如果有一个人传了 100GB，其他人就没法用了。

这时候我意识到，我需要一个配额系统。

但配额设成多少合适？我想了想自己的使用场景：日常处理的文件，PDF、图片、文档，加起来可能也就几百 MB。给每个用户 5GB，足够用了，而且 150GB 可以支持 30 个用户，还留有余量。

这个决策 AI 能帮我做吗？

这也是可以的，你可以让他自己去查整个系统的一个配置，然后你再跟他说你大概有几个人会来使用，调研大概多少是合适的。

然后包括说，你可以让他去设计那种：他的每一次用户上传的文件或者产生新文件，他就要自己去整理这种文件系统，他要有意识地去提示用户，提醒文件「你这个文件需要整理了，你要怎么怎么样」。

AI 很快就把代码写出来了。但「5GB」这个数字，是我们讨论想出来的。

AI 是执行者，你是决策者。 你要想清楚「做什么」和「为什么」，AI 负责「怎么做」。如果你自己都没想清楚，AI 写出来的东西就算能跑，也不一定是你真正需要的。

设计 2：消息太长怎么办？

这个问题是我在实际使用中发现的。

有一次我让 AI 分析一个长文档，它返回了一大段分析结果，大概 2000 多字。结果这个聊天软件显示出来一团乱麻——因为它对长消息的 Markdown 渲染很差，格式全乱了，而且滚动起来也很难受。

我第一反应是让 AI 把消息拆成几段发。但试了之后发现体验也不好，几条消息刷屏，而且上下文被打断了。

后来我想到一个办法：如果回复超过 1000 字，就自动打包成 .txt 文件发送。

这样用户收到的是一个文件，点开就能看完整内容，排版也不会乱。而且文件可以保存、可以转发，比一堆消息实用多了。

这个改动从技术上看很简单，就是加一个字数判断和文件生成的逻辑。但这是一个产品决策，不是技术决策。AI 不会主动告诉你「消息太长体验不好」，因为它不知道这个聊天软件

这种细节，只有你自己用过、踩过坑，才会想到要优化。用户体验的提升，往往就藏在这些「小」决策里。

设计 3：安全问题怎么想？

这是我花时间最多的一个设计。

我的 Bot 有一个核心能力：它可以读写服务器上的文件。这是它的价值所在，但也是最大的风险。

我问自己几个问题：

如果 AI 出 bug，会不会把我服务器上的重要文件删了？

如果用户 A 能访问用户 B 的文件怎么办？

如果有人通过 Bot 执行恶意命令怎么办？

这些问题 AI 不会主动帮你想，因为它只负责实现你提出的功能。安全是你自己的责任。

想清楚风险之后，我做了几个决策：

禁用 bash 执行： Claude Agent SDK 默认可以执行任何系统命令，这太危险了。我只需要 AI 能读写文件，不需要它能执行 rm -rf /。所以我在配置里把 bash 权限关掉了。

路径隔离： 每个用户只能访问自己的目录 users/{user_id}/data/。任何试图访问这个目录之外的路径，都会被拒绝。这样就算 AI 出错，影响范围也只限于这个用户自己的文件。

Docker 容器隔离： 整个 Bot 跑在一个 Docker 容器里。就算最坏的情况发生——容器里的东西全被搞坏了——我只需要重建容器就行，不会影响到服务器上的其他东西。

管理员面板： 我给自己做了一个管理功能，可以查看所有用户的配额使用情况，可以禁用某个用户。这样如果有人滥用，我能及时处理。

这些措施听起来好像很「专业」，但其实都是常识。不是什么高级工程，就是基础的安全意识。 关键是你要主动去想「会出什么问题」，而不是等问题发生了再补救。

我们之前也看到了很多人去用一些提示词注入去搞什么破解。然后他们通过怎么去诱导 AI，然后用到 agent，我们去把他们的一些环境给破坏掉的这种，这种新闻我觉得之前还是说得蛮多了。

所以你只要看得多了之后，你大概也会有这样一个意思，所以我觉得安全是一个必要的方面。就算你虽然不知道具体你要怎么去做，但是你一定要考虑到这个方面。你可以去问它，但是你不能忘了去问。

所以从整体上来说，我在做这个产品，最开始是为了给身边人、给家人用，但其实我的整个设计就是按照一个「想要把它给别人、给大家去用」的想法来做的。虽然我还不知道怎么去做这种商业化，但是我觉得这才是一个正常的产品。

我们从一开始就要养成这样的习惯，不是说 demo，你就什么都可以不用去管，或者说你给身边的人使用，你也不用去管很多东西，但我觉得这是一个习惯。

可能你现在只能做一个 demo，但是随着你的能力慢慢成长起来，你就可以做一些大的产品。你从小就把这个习惯养好了之后，后面就可以减少很多不必要的麻烦。

回顾这三个设计，我发现它们有一个共同点：都是在回答「为什么」的问题。

为什么要有配额？因为资源有限。

为什么长消息要变成文件？因为用户体验更好。

为什么要做这么多安全措施？因为风险真实存在。

这些「为什么」，AI 回答不了。它只知道「怎么做」——你告诉它要配额系统，它就写配额系统；你告诉它要生成文件，它就生成文件。但它不会问「我们真的需要这个吗？」或者「有没有更好的方案？」

这就是为什么我说产品思维是差异化因素。

会用 AI 写代码的人会越来越多，这个门槛已经很低了。但能想清楚「做什么」和「为什么这样做」的人，永远是少数。

不会写代码，反而是一种优势。因为你不会陷入技术细节里，你会更多地思考：这个东西到底解决了什么问题？用户真正需要的是什么？有没有更简单的方案？

代码是手段，产品是目的。 AI 帮你搞定了手段，但目的只有你自己能定义。

快去干吧

我在这个过程当中其实一直使用的工具是 Claude Code，所以我觉得大家可以赶快去使用起来，不仅仅是用它写代码，也可以让它帮你做一些个人生产力上的一些方法、一些实践吧。

比如有的人就用它去跟 Obsidian 结合起来，去和知识管理放在一起。然后有的人又用它去做一些自动化的操作，自己写一些 skill，把自己的sop梳理下来。 我也看到有人会给自己设定一些文件夹，把文件夹对应成生活、工作方面的一些不同部分，然后 agent 相当于是他的一个个人秘书，帮他去管理、帮他去管理这些文件夹。

就是很多这样的实践，其实工具它的能力是很强的，可能现在限制我去用它的一些方面，就是我自己的一个想象力、审美吧。

然后现在也已经有很多教程教大家怎么去用这类产品，包括说像 OpenCode 也有人推荐，如果说 Claude Code 太贵的话，也可以去用国内的智谱的 GLM，这个教程也是有很多的。

包括这个新手指南写的挺好的，然后可以看第一、二、三章，看完差不多就开始用了。后面的那些教程，其实你可以在做项目的过程当中自己一点一点去摸索，然后逐渐学习。

为什么普通人要多 Vibe Coding

写到这里，我想聊聊一个更大的问题：为什么我觉得不会编程的人，反而应该多用 AI 去构建东西？

这个问题我想了很久，因为很多人会觉得「我又不是程序员，学这个干嘛」。但我的体会是，Vibe Coding 带给我的收获，远不止「做出了一个 Bot」这么简单。

第一，边干边学是最高效的学习方式。

传统的学习路径是这样的：先学编程语言，再学框架，再学架构设计，然后才开始做项目。这条路走下来，少说也要一两年。而且很多人学到一半就放弃了，因为学的时候不知道这些东西有什么用，纯粹是在「为了学而学」。

Vibe Coding 的路径完全反过来：你先有一个想做的东西，然后边做边学。遇到不懂的，问 AI；卡住了，让 AI 帮你解决。整个过程可能只需要几天甚至几个小时，你就能做出一个可以用的东西。

区别在哪里？动力。

当你是为了解决自己的问题而学习时，每一个新知识都有明确的用途。我学 Docker 不是因为「Docker 是热门技术」，而是因为「我需要把我的 Bot 隔离起来，不然出问题会影响整个服务器」。这种学习是有目标的，所以记得住、用得上。

而且，这种方式的反馈循环特别短。传统学习可能学了三个月还看不到成果，Vibe Coding 可能聊了三个小时就有一个能跑的 demo 了。每一次小的成功都会给你动力继续往下做，形成正向循环。

第二，Demo 是最有说服力的沟通方式。

这一点我在前面聊过，但我想再强调一下，因为这对不会编程的人来说太重要了。

以前，如果你有一个想法，你只能写文档、画原型图、做 PPT。但这些东西都是「描述」，不是「展示」。你说「我想做一个能自动分析数据的工具」，别人听了可能觉得「哦，又是一个想法」，然后就没有然后了。但如果你直接做一个 demo 出来，哪怕很粗糙，别人能亲手用一下、看到真实的效果，说服力完全不一样。

Demo 是穿透认知壁垒的最短路径。 而 Vibe Coding 让不会编程的人也能做 demo 了。这是一个巨大的能力解锁。

第三，这是系统化思维最好的训练场。

很多人觉得「系统化思维」是一个很虚的概念，不知道怎么培养。但我发现，用 AI 做一个完整项目，是培养系统化思维最实际的方式。

因为你必须想清楚很多问题：

这个系统有哪些模块？它们之间怎么交互？

先做什么，后做什么？为什么是这个顺序？

如果这个模块出问题，会影响哪些其他模块？

资源有限的情况下，哪些功能是核心，哪些可以砍掉？

这些问题在传统工作中很少有机会思考，因为大多数人只负责自己那一小块。但当你自己从零开始构建一个东西时，你必须站在全局的角度去思考。

而且 AI 会逼着你把想法表达清楚。你不能说「帮我做一个好用的系统」，你得说清楚「好用」是什么意思、「系统」包含哪些功能。这个过程本身就是在训练你把模糊的想法结构化。

做完几个项目之后，我发现自己在工作中思考问题的方式也变了。以前看到一个需求，我会想「这个功能怎么实现」；现在我会先想「这个需求的本质是什么、有哪些相关的模块、改动会带来什么影响」。这种思维方式的转变，比学会某个具体技术更有价值。

第四，这是认识自己的一面镜子。

这一点可能有点抽象，但我觉得很重要。

当你用 AI 做项目时，你会不断遇到「我想要什么」这个问题。AI 会问你：「你想要 A 方案还是 B 方案？」「这个功能的优先级是什么？」「出错的时候应该怎么处理？」

一开始你会发现，很多问题你自己都没想清楚。你以为自己知道想要什么，但真正被问到细节的时候，你才发现自己的想法是模糊的。

这个过程会逼着你不断澄清自己的想法。你要问自己：我真正在意的是什么？什么是必须有的，什么是可有可无的？我愿意为了简单牺牲多少功能？

做着做着，你会越来越清楚自己是一个什么样的人。 你是喜欢复杂但强大的系统，还是简单但够用的工具？你是在意功能完整性，还是在意用户体验？你是愿意花时间打磨细节，还是先上线再说？

这些问题没有对错，但你需要知道自己的答案。Vibe Coding 给了你一个低成本试错的机会，让你通过实际的选择来认识自己。

第五，这是管理能力的预演。

这一点是我后来才意识到的。

当你用 AI 做项目时，你其实在扮演一个「管理者」的角色。你负责定方向、做决策、分配任务、检查结果。AI 是你的「执行者」，负责把你的想法变成代码。

这和管理一个团队其实很像。你要学会：

怎么把一个大目标拆解成可执行的小任务

怎么清晰地传达你的期望

怎么检查交付物是否符合要求

出了问题怎么定位原因、怎么给反馈

如果你未来想带团队，这些能力是必须的。而 Vibe Coding 给了你一个零成本练习的机会——AI 不会抱怨你的需求不清楚，它只会按照你说的去做。如果结果不对，那一定是你没说清楚。这会倒逼你提升表达能力和任务拆解能力。

所以，Vibe Coding 到底是什么？

它不是一种编程技术，而是一种做事的方式。

它的核心是：

敢于尝试——因为试错成本很低，最多浪费几个小时

快速反馈——做出来的 demo 比任何文档都有说服力

在行动中学习——不是先学会再做，而是边做边学

用 AI 放大自己——你有想法但不会实现？AI 帮你实现。你有产品感但不会编程？AI 帮你编程

在 AI 时代，瓶颈已经不是「我能不能写代码」，而是「我知不知道自己想要什么」。

技术门槛被 AI 抹平了，但想清楚「做什么」和「为什么做」的能力，AI 替代不了。这才是真正稀缺的东西。

所以，如果你有一个想法，一直觉得「我不会编程，所以做不了」——现在没有这个借口了。

下载一个 Claude Code 或者 Cursor，把你的想法告诉 AI。你会发现，原来自己能做到的事情，比想象中多得多。