Vibe Coding 时代：为什么说“产品感”比“写代码”更稀缺？

本文来自微信公众号： 少数派 ，作者：愚人哲，责编：广陵止息，原文标题：《Vibe Coding 时代：为什么说「产品感」比「写代码」更稀缺？》

我不是程序员，编程能力也一般，但是前两天我花了一个下午用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，这个教程也是有很多的。

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

链接：https://claudecode.tangshuang.net/easy-tutorial

▍为什么普通人要多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。你会发现，原来自己能做到的事情，比想象中多得多。

原文链接：

https://sspai.com/post/105331?utm_source=wechat&utm_medium=social