非技术背景也能打造个人 AI 伙伴：我的 vibe coding 体验

非技术背景也能打造个人 AI 伙伴：我的 vibe coding 体验

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

整个过程我没有写一行代码，只是在构思和交流。我一直在与 Claude Code 互动，并不断迭代。这正是 vibe coding 的乐趣所在，不是掌握编程语言或框架，而是把 AI 当作你思维的延伸——以对话的速度，把模糊的想法变成真实可用的产品。

产品感比代码能力很稀缺

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

也是得益于此，我进入了 AI 初创领域担任产品经理。后来一位 mentor 告诉我，我的简历没有表现出与公司的契合度，是我在 GitHub 上的一些项目让他特别想要我。

Demo 有几层价值，首先是把你的思想外化，把模糊的想法变成具体的，让你的思考更有依据；其次是让别人相信你看到的，建立信任；第三层就是 AI 已经让我们（至少是我这样没有技术背景的人）以最低的成本，让别人看到你的想法到产品。

从概念到可用产品，Demo 的成本最低，一个下午 + 一个 AI 工具 = 你可以展示给 100 个人的东西，这就是为什么我对 Demo 着迷。

vibe coding 的六大核心技巧

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

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

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

在 GitHub 上找一个开源前端项目
告诉 AI：「按照这个项目的设计风格，给我一个 React Dashboard 组件库」
AI 理解了美学，直接生成了匹配的代码

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

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

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

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

这不是「拼凑怪物」——这是最高效的学习方式。著名的 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 进行一次架构对话。这个步骤很多人会跳过，因为他们觉得「反正 AI 会帮我写」，但这恰恰是最容易踩坑的地方。

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

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

我会问自己三个问题：

我能理解这个架构吗？

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

技巧 6：利用 Claude Code 和 Agent SDK

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

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

官方工程博客明确表示：「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 会帮我写」，但这恰恰是最容易踩坑的地方。