我不是程序員，編程能力也一般，但是前兩天我花了一個下午用 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 個開發者同時編碼但不溝通、非?；靵y。

所以我一般就是一個文件實現一個目標，然后不同的功能就放不同的文件夾里面。

當我想要去改某個功能的時候，我就告訴他在哪個文件里面去添加一個什么樣的函數，或者說他自己就能夠根據文件結構自己去非常確定地知道在哪里，而不是說一類功能你把它拆到了不同的文件里面去放。那這樣子就會非?；靵y，他就很容易搞錯。

技巧 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'。我覺得可能是目錄權限問題，因為這個目錄是第一次被寫入?！?/p>

這種描述包含了三個關鍵信息：我做了什么操作、我期望什么結果、我實際得到了什么。有了這些，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：「在這個聊天軟件加粗或斜體。可以用編號列表或者換行來組織內容?！?/p>

當然，其實你這么跟他說，他有時候還是不會去遵守這個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。你會發現，原來自己能做到的事情，比想象中多得多。