我不是程序員，編程能力也一般，但是前兩天我花了一個(gè)下午用 Claude code 和 Claude agent sdk，在自己的服務(wù)器上構(gòu)建了一個(gè)完整的個(gè)人 AI agent 小助手，雖然還比較粗糙，但是我現(xiàn)在可以24/7 通過它分析數(shù)據(jù)、處理文件、構(gòu)建界面。

全程我沒有寫一行代碼，只是在構(gòu)思和交流。在和 Claude code 交流，并且目前還一直在迭代，以后也一定是這樣的方式，我想這就是 vibe coding 的樂趣，不是掌握編程語(yǔ)言或框架，而是把 AI 當(dāng)作你思維的延伸——以對(duì)話的速度，把模糊的想法變成真實(shí)可用的產(chǎn)品。

產(chǎn)品感比代碼能力很稀缺

今年，我自己構(gòu)建了幾十個(gè) demo，不是為了炫耀，而是我發(fā)現(xiàn)：demo 是傳達(dá)想法最有效的媒介。

也是得益于此，我進(jìn)入到 AI 初創(chuàng)當(dāng)產(chǎn)品經(jīng)理，后來 mentor 跟我說我的簡(jiǎn)歷都沒有表現(xiàn)出我和公司的契合度，而是我在 github 里面的一些項(xiàng)目，讓他特別想要我。

demo 有幾層價(jià)值，首先是把你的思想外化，把模糊的想法變成具體的，在你實(shí)踐的過程中，你會(huì)發(fā)現(xiàn)你接下來的思考會(huì)更輕松，因?yàn)槟愕乃伎际腔谝粋€(gè)已有的東西去延伸，而不是一直在天馬行空的想象。就像 AI 的思考模式一樣，可視化你的思考過程往往會(huì)改變你的結(jié)論，先前的 token 會(huì)收斂你后面 token 的輸出，不至于最后想法很好，實(shí)踐起來就…

第二個(gè)就是我在前文提到的，讓別人相信你看到的，建立信任。在學(xué)校的時(shí)候，很多人對(duì) AI 的理解還只是停留在簡(jiǎn)單的對(duì)話，我寫了很長(zhǎng)的如何用 AI 高效分析、調(diào)研、訪談的工作流方案，想和同學(xué)一起做一些事來賦能一下現(xiàn)有的工作——沒反應(yīng)。然后我做了一個(gè) demo，用 coze 和飛書表格，只花了幾個(gè)小時(shí)，將我們之前的來訪者訪談到分析的整個(gè)過程流程化。從來訪者預(yù)約、時(shí)間安排、到訪前通知以及過程中錄音轉(zhuǎn)寫到分析，然后他們就信了。

為什么？因?yàn)?demo 是信息密度最高的格式：報(bào)告會(huì)讓人睡著、Slides 會(huì)讓人分心、Demo 讓人看到自己眼睛的真實(shí)信息…

第三層就是 AI 已經(jīng)讓我們（至少是我這樣沒技術(shù)背景的人）利用最低的成本，讓別人看到你的想法到產(chǎn)品。從概念到可用產(chǎn)品，demo 的成本最低，一個(gè)下午+一個(gè) AI 工具 = 你可以展示給 100 個(gè)人的東西，這就是為什么我對(duì) demo 著迷。

vibe coding 的六大核心技巧

技巧 1：不要憑空創(chuàng)造，學(xué)習(xí)別人已經(jīng)做過的

這聽起來有點(diǎn)反直覺是吧，而且很多人肯定會(huì)說你這不就是抄，但這是最快的前進(jìn)方式。

當(dāng)我用 Claude code 構(gòu)建一個(gè) web dashboard 的時(shí)候，我沒有讓他憑空創(chuàng)建，而是：

在 GitHub 上找一個(gè)開源前端項(xiàng)目

告訴 AI：「按照這個(gè)項(xiàng)目的設(shè)計(jì)風(fēng)格，給我一個(gè) React Dashboard 組件庫(kù)」

AI 理解了美學(xué)，直接生成了匹配的代碼

假如我直接創(chuàng)造呢？他會(huì)給我一個(gè)「給我一個(gè)漂亮的 dashboard」，但是需要 10 輪反饋調(diào)整顏色、間距。我很清楚，自己并不是一個(gè)設(shè)計(jì)師，并且我自己腦子里的想法甚至都不是很清楚，與其去做填空題，不如去做選擇題。

在哪搜索？GitHub 上的開源項(xiàng)目（包括樣式表）、設(shè)計(jì)展示網(wǎng)站（Dribbble、Behance）、競(jìng)品代碼（用瀏覽器開發(fā)者工具檢查）……

我自己無聊的時(shí)候比較喜歡看 mobbin，去刷一刷網(wǎng)站或者上 x 去看看大家的分享，然后用 mymind 去記錄一些好的創(chuàng)意，不僅僅是記錄，有時(shí)候光看這些就挺開心的。

其實(shí)不僅僅是一個(gè)設(shè)計(jì)，包括說一些有用的，可能我現(xiàn)在用不上，但是我覺得它非常有用，我就會(huì)先把它記錄下來。后面我需要的時(shí)候，我就直接從中去找。

有一個(gè)記錄的過程，就會(huì)讓你的記憶留下一個(gè)印象。你后續(xù)再去做一個(gè)什么東西的時(shí)候，可能就會(huì)想起這個(gè)東西。想起這個(gè)東西，你就不用再去大海撈針地去找，你可以從已經(jīng)收集到的地方去進(jìn)行一個(gè)尋找。

這不是「拼湊怪物」——這是最高效的學(xué)習(xí)方式。著名的 Roguelike 游戲開發(fā)方法論就是這樣：站在巨人肩膀上，快速迭代。

技巧 2：不斷問 AI，逐步探索——每個(gè)操作前都要問為什么

我最初對(duì) VPS 一無所知。什么是 SSH？端口轉(zhuǎn)發(fā)怎么用？Docker 是什么？

但我沒有去買課程，而是在每個(gè)操作前都問 AI：

「我怎樣在手機(jī)上遠(yuǎn)程控制 Claude Code？」

「這個(gè) SSH 密鑰是用來干什么的？」

「Docker 對(duì)我的項(xiàng)目有什么好處？」

AI 會(huì)解釋概念、給具體步驟、遇到問題時(shí)幫助調(diào)試，所以我現(xiàn)在就能直接從手機(jī) push 代碼到 GitHub，用 Claude Code 在遠(yuǎn)程服務(wù)器上工作。我從未上過一堂 Linux 課，但我學(xué)會(huì)了「做事」。

這也是我認(rèn)為的 vibe coding 的精髓之一：不是「先學(xué)技術(shù)，再使用它」，而是「讓問題驅(qū)動(dòng)學(xué)習(xí)」，這樣每個(gè)提問都是一個(gè)教學(xué)時(shí)刻，也算是干中學(xué)吧。

技巧 3：漸進(jìn)式開發(fā)——理清順序和依賴關(guān)系

構(gòu)建 AI Bot 時(shí)，我最初的計(jì)劃是：先做消息處理器、再做用戶管理、再做會(huì)話管理、再做Agent 集成、最后安全方面…

但是到了第三步的時(shí)候，我發(fā)現(xiàn)安全需要提前設(shè)計(jì)，比如說一些權(quán)限隔離。然后像消息處理器，它就依賴后話管理的接口定義，那用戶管理又需要去預(yù)留配額的空間，所以我就跟 AI 一起去重新排序。

我首先就是去定義這個(gè)數(shù)據(jù)模型，比如說 user、session、task 結(jié)構(gòu)。然后第二步就去實(shí)現(xiàn)這個(gè)核心的邏輯，像 agent 和 mcp server。然后第三步就是添加約束層，就是每個(gè)用戶它有多少的存儲(chǔ)空間。

因?yàn)槲疫@個(gè)項(xiàng)目不僅給我自己用，它會(huì)給我家里人一起用，幫他們把一些生活上的一些需要用到 AI 的東西全部打包放在這個(gè) bot 里面。所以我會(huì)給每個(gè)人都會(huì)配一定的配額，畢竟 VPS 它的存儲(chǔ)是有限的。

然后權(quán)限和安全方面，因?yàn)槲医o他們直接用的是 Claude agent，如果不有一些權(quán)限的限制的話，那有可能他們的提示不小心觸發(fā)了 Claude agent 的一些操作，就會(huì)把我整個(gè)項(xiàng)目給損毀。所以我就添加了一些安全的一些權(quán)限。

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

這個(gè)順序的好處就是我后面的模塊，就不用后面模塊的添加就不用去改變前面模塊的一個(gè)接口。所以我加新功能的時(shí)候，AI 的上下文就會(huì)更加清晰。而且我一旦出現(xiàn)了 bug，我就知道我具體是哪一個(gè)層面出現(xiàn)的問題，我就直接去針對(duì)性地修改這一個(gè)層面就好了。

這其實(shí)就是一個(gè)基礎(chǔ)的系統(tǒng)設(shè)計(jì)，我個(gè)人認(rèn)為雖然我不懂代碼怎么去實(shí)現(xiàn)，但是很多架構(gòu)方面的東西你要想清楚。

就像我們?nèi)プ鍪虑橐粯樱麄€(gè)一個(gè)先后順序，你去驅(qū)使 AI 去做事情也是有一個(gè)先后順序，所以 AI 能夠幫你去實(shí)現(xiàn)它，但是你自己必須要思考清楚。

技巧 4：一個(gè)文件，一個(gè)工作——寫模塊化代碼

如果一個(gè)文件有 2000 行，AI 出錯(cuò)的概率成倍增加。如果一個(gè)文件 100 行，只做一件事：

AI 的上下文更好

你能更快定位問題

改動(dòng)的影響范圍受限

代碼塊復(fù)制

bot/├── handlers.py # 僅處理來自聊天軟件的命令├── agent/│ ├── client.py # 僅連接 Claude Agent│ ├── tools.py # 僅定義自定義工具│ ├── task_manager.py # 僅管理后臺(tái)任務(wù)├── user/│ ├── manager.py # 僅管理用戶數(shù)據(jù)│ ├── storage.py # 僅處理配額├── session/│ └── manager.py # 僅管理會(huì)話

LLM 在小的、聚焦的任務(wù)上表現(xiàn)肯定是更好，當(dāng)你要求它「寫完整系統(tǒng)」時(shí)，就像 10 個(gè)開發(fā)者同時(shí)編碼但不溝通、非常混亂。

所以我一般就是一個(gè)文件實(shí)現(xiàn)一個(gè)目標(biāo)，然后不同的功能就放不同的文件夾里面。

當(dāng)我想要去改某個(gè)功能的時(shí)候，我就告訴他在哪個(gè)文件里面去添加一個(gè)什么樣的函數(shù)，或者說他自己就能夠根據(jù)文件結(jié)構(gòu)自己去非常確定地知道在哪里，而不是說一類功能你把它拆到了不同的文件里面去放。那這樣子就會(huì)非常混亂，他就很容易搞錯(cuò)。

技巧 5：架構(gòu)思考（5 分鐘頭腦風(fēng)暴）

在每次開始寫代碼，我會(huì)先把我的想法給 AI，先去說我會(huì)先跟他說，我們先討論一下，你可以先不急著去往后實(shí)現(xiàn)出來，然后看有什么樣的一個(gè)方式，能不能實(shí)現(xiàn)。

首先我先要問他能不能實(shí)現(xiàn)，要實(shí)現(xiàn)的方案有什么樣子的，然后他會(huì)給我一些架構(gòu)的建議，以及一些潛在的問題，還有一些那種方案的選擇，就讓我能更有掌控感。

這樣我也能夠確定我的想法不會(huì)特別離譜，或者說他需要、他無法實(shí)現(xiàn)什么東西，然后他又需要什么，比如說一些 API key 啊，或者說一些外部服務(wù)的時(shí)候，他能夠去指導(dǎo)我，去幫他去獲取。

我感覺好的架構(gòu)它能夠預(yù)防你 80% 的后續(xù)問題，并且「先改架構(gòu)」是比你「開始架構(gòu)好了后面去改代碼」這樣是更容易一些。

并且對(duì)于我這樣沒有什么開發(fā)經(jīng)驗(yàn)也沒有系統(tǒng)學(xué)習(xí)過的人，我覺得 AI 的建議往往是會(huì)超過我的知識(shí)。所以你在干什么事情之前都去問清楚，跟他討論清楚。如果你自己不放心，每個(gè)人再去做一些事實(shí)核查，用其他的 AI 做核查也是一樣的。

技巧 6：利用 Claude Code 和 Agent SDK

這真的是 vibe Coding 的最高杠桿工具。我真感覺這個(gè)好東西就是被 code 這個(gè)字眼給耽誤了，Claude code 何必只能寫代碼…

2025年9月，當(dāng) Anthropic 宣布將 Claude Code SDK 正式更名為 Claude Agent SDK 時(shí)，這不僅是一次命名變化，更加表達(dá)了他不僅僅是寫 code 也能夠勝任通用任務(wù)。

官方工程博客明確表示：「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 的核心優(yōu)勢(shì)：

MCP Server： 讓 AI 使用自定義工具

上下文管理： 自動(dòng)管理上下文和會(huì)話

工具調(diào)用： AI 可以主動(dòng)調(diào)用你的函數(shù)

比如你就去跟 Claude Code 說，使用 Claude Agent SDK 構(gòu)建一個(gè)花費(fèi)分析器，用戶上傳收據(jù)圖片，Agent 提供統(tǒng)計(jì)、分類、支出。那他就能夠直接去用這個(gè) SDK 去寫一個(gè)整體的框架，去處理你的文件上傳，管理對(duì)話狀態(tài)，調(diào)用你的自定義攻擊。

并且 Claude Code 在他的 plugin Marketplace 里面就有 能幫你去寫基于 Claude agent sdk 程序的插件，也就是說他自己就能夠去查看這個(gè) SDK 去幫你寫，不需要你自己去查一些使用文檔，去告訴他該怎么寫。

所以他對(duì)用他來寫 Claude Agent SDK 相關(guān)的一些軟件或者功能是非常友好的，非常順滑的。如

果你用傳統(tǒng)的方式，你去把一些文檔、使用文檔去復(fù)制粘貼給他，或者說告訴他怎么去做，他就很容易會(huì)遇到一些錯(cuò)誤情況。因?yàn)樗约罕旧砭筒涣私猓缓笏谌フ{(diào)用一些服務(wù)的時(shí)候，他就很容易把接口寫錯(cuò)，就會(huì)出問題。

從想法到產(chǎn)品的完整工作流

步驟 1：?jiǎn)栴}定義，不是解決方案

我認(rèn)為錯(cuò)誤的方式是你教他用 Python 寫一個(gè)項(xiàng)目，用 Flask API 集成 Claude API 等等。我覺得正確的方式：我想在自己的服務(wù)器上有一個(gè)東西，然后能夠隨時(shí)通過指令，出了問題讓他處理文件。

這兩個(gè)有什么區(qū)別呢？

首先，為什么我會(huì)使用第二個(gè)方式？也是因?yàn)槲覍?duì)于技術(shù)的了解不是那么多，所以我也不會(huì)去問他像第一個(gè)問題那樣子那么具體，讓他去用什么技術(shù)的一個(gè)問題。

然后第二個(gè)就是，我覺得第一種方式限制了 AI 的思考，因?yàn)槟阍趺茨軌虼_定你用 Python 方向就一定是用 Python 這個(gè)語(yǔ)言去寫，一定就是對(duì)你這個(gè)程序是最友好的呢？然后說 Flask API 難道就一定是最優(yōu)的嗎？

所以我第二種就是直接讓 AI 自己去判斷、去選擇最佳的框架。那我們只用去定義 what 和 why，那 AI 他自己去推薦 how。

步驟 2：架構(gòu)思考——5 分鐘頭腦風(fēng)暴比 5 小時(shí)返工更值

在開始寫代碼之前，我會(huì)先和 AI 進(jìn)行一次架構(gòu)對(duì)話。這個(gè)步驟很多人會(huì)跳過，因?yàn)樗麄冇X得「反正 AI 會(huì)幫我寫」，但這恰恰是最容易踩坑的地方。

我會(huì)這樣和 AI 對(duì)話：「我想做一個(gè)聊天軟件 Bot，用戶可以通過它和 Claude Agent 交互。這個(gè) Bot 需要支持多用戶，每個(gè)用戶有獨(dú)立的工作目錄和存儲(chǔ)配額。你覺得應(yīng)該怎么設(shè)計(jì)模塊？有什么潛在的問題？」

然后 AI 會(huì)給我一個(gè)初步的架構(gòu)建議。但這里的關(guān)鍵不是 AI 給了什么答案，而是我怎么評(píng)估這個(gè)答案。

我會(huì)問自己三個(gè)問題：

我能理解這個(gè)架構(gòu)嗎？

如果 AI 給我的架構(gòu)我自己都看不懂，那后面出了問題我根本沒法調(diào)試。比如第一次 AI 給我的方案里，它建議用一個(gè)復(fù)雜的事件驅(qū)動(dòng)架構(gòu)，有 Message Queue、Event Bus 什么的。聽起來很專業(yè)，但我根本不理解這些東西是干什么的。

所以我直接告訴 AI：「這個(gè)太復(fù)雜了，你能給我講一下不，通俗易懂一點(diǎn)」。總之不會(huì)就要問，AI 又不會(huì)罵你，他會(huì)細(xì)心的教你。

哪個(gè)模塊風(fēng)險(xiǎn)最大？

AI 的初始方案很簡(jiǎn)單，它把整個(gè)系統(tǒng)分成四層：聊天交互層、Agent 客戶端層、用戶管理層、數(shù)據(jù)存儲(chǔ)層。聽起來很清晰，但我意識(shí)到一個(gè)問題：安全。

我的 Bot 可以讀寫服務(wù)器上的文件，如果用戶A可以訪問用戶B的文件怎么辦？如果 AI 出錯(cuò)，把我的整個(gè)服務(wù)器文件都刪了怎么辦？這些 AI 在初版架構(gòu)里都沒考慮到。

需要加安全層嗎？

所以我又問 AI：「如果一個(gè)用戶惡意操作，或者 AI 出現(xiàn) bug，怎么保證系統(tǒng)的安全？」

AI 給了我?guī)讉€(gè)建議：路徑隔離、Docker 容器、權(quán)限白名單。這時(shí)候我才意識(shí)到，架構(gòu)設(shè)計(jì)的時(shí)候就要把安全考慮進(jìn)去，而不是等到代碼寫完了再補(bǔ)。

這 5 分鐘的對(duì)話，省了我后面至少 5 個(gè)小時(shí)的返工時(shí)間。

因?yàn)槿绻抑苯幼?AI 開始寫代碼，它會(huì)按照最直接的方式去實(shí)現(xiàn)功能——沒有安全檢查、沒有路徑隔離、沒有錯(cuò)誤處理。等我發(fā)現(xiàn)問題的時(shí)候，代碼已經(jīng)寫了幾百行了，改起來又要重新理清楚邏輯。

架構(gòu)思考的本質(zhì)，不是讓 AI 告訴你該怎么做，而是逼自己想清楚：這個(gè)系統(tǒng)的邊界在哪里？最容易出問題的地方是哪里？如果我只能優(yōu)化一個(gè)模塊，我會(huì)選哪個(gè)？

步驟 3：逐模塊實(shí)現(xiàn)——一次只做一件事

確定好架構(gòu)之后，很多人會(huì)直接讓 AI「把整個(gè)項(xiàng)目寫出來」。我一開始也是這么干的，結(jié)果就是 AI 寫了一堆代碼，我完全看不懂，出了問題也不知道從哪里開始查。

就像人一樣，每個(gè)人的精力，工作都是一點(diǎn)一點(diǎn)做的。AI 也是一樣的，你讓他把所有的精力都用來做一個(gè)東西，他就能做得好。但如果你讓他分散精力去想那么多事情，他可能就沒有那么多精力，就會(huì)容易出錯(cuò)。所以我后面也是一次就讓 AI 做一件事。

比如說我要去做一個(gè)用戶管理模塊，我不會(huì)說讓他直接去幫我寫一個(gè)用戶管理系統(tǒng)，因?yàn)樘：耍约嚎赡軙?huì)腦補(bǔ)很多你根本不知道的功能。

得具體一點(diǎn)，實(shí)現(xiàn)一個(gè) user manager，有什么功能，比如創(chuàng)建用戶、獲取用戶的配置、檢查存儲(chǔ)配額，然后更新存儲(chǔ)的配額使用量，然后每個(gè)用戶它的數(shù)據(jù)又是在一個(gè)單獨(dú)的文件夾上。

這樣子 AI 就知道邊界在哪里，就不會(huì)寫著寫著就跑偏了。

如果你自己都想不清楚的東西，你也可以把你的想法你就跟他說，我要寫一個(gè)用戶管理模塊，然后你就問他用戶管理模塊大概有什么樣的部分。把一個(gè)大需求你跟著他一起把它給拆分下來，然后一個(gè)一個(gè)的來做，相對(duì)來說寫起來也不會(huì)那么容易出錯(cuò)。

步驟 4：處理錯(cuò)誤和細(xì)節(jié)——讓 AI 自己測(cè)試，給 AI 足夠的上下文

代碼寫完不代表就能用了。我感覺花在調(diào)試上的時(shí)間比寫新功能的時(shí)間還多。慢慢的也就養(yǎng)成了兩個(gè)技巧，讓調(diào)試效率提高了很多。

首先就是讓 AI 自己先測(cè)試代碼。

以前我會(huì)讓 AI 寫完代碼就直接集成到項(xiàng)目里，然后運(yùn)行整個(gè)項(xiàng)目看有沒有問題。結(jié)果經(jīng)常是：項(xiàng)目跑不起來，但我不知道是哪個(gè)模塊出了問題。

所以現(xiàn)在我會(huì)在 AI 寫完一個(gè)模塊之后，直接告訴它：「寫幾個(gè)測(cè)試用例，驗(yàn)證一下這些函數(shù)是不是正確的。」

AI 自己寫測(cè)試、自己跑測(cè)試，大部分低級(jí)錯(cuò)誤——比如參數(shù)類型錯(cuò)了、路徑拼接錯(cuò)了、邊界條件沒處理——它自己就能發(fā)現(xiàn)并修復(fù)。等它告訴我「測(cè)試通過」的時(shí)候，我拿到的代碼質(zhì)量比「寫完直接交付」高很多。

第二就是報(bào)錯(cuò)的時(shí)候，給 AI 足夠的上下文。

這是我踩過最多坑的地方。一開始遇到問題，我會(huì)直接告訴 AI：「這個(gè)功能不工作。」然后 AI 就開始猜——可能是這個(gè)問題、可能是那個(gè)問題——猜了十輪還沒猜對(duì)。

AI 不是神，它需要你告訴它發(fā)生了什么。

現(xiàn)在我報(bào)錯(cuò)的方式是這樣的：「我上傳了一個(gè) 2MB 的 PDF，期望得到 Markdown 輸出，但系統(tǒng)返回了 'Permission denied'。我覺得可能是目錄權(quán)限問題，因?yàn)檫@個(gè)目錄是第一次被寫入。」

這種描述包含了三個(gè)關(guān)鍵信息：我做了什么操作、我期望什么結(jié)果、我實(shí)際得到了什么。有了這些，AI 基本上一輪就能定位到問題。

坑 1：URL 拼接錯(cuò)誤

我用的不是官方的 Anthropic API，而是自己的 API 網(wǎng)關(guān)。配置的時(shí)候，我把 base URL 寫成了 https://my-gateway.com/v1。結(jié)果一直報(bào)錯(cuò)，找不到接口。

查了半天才發(fā)現(xiàn)，Claude SDK 會(huì)自動(dòng)在 URL 后面加 /v1，所以實(shí)際請(qǐng)求的地址變成了 https://my-gateway.com/v1/v1。

這種問題 AI 幫不了你，因?yàn)樗恢滥愕呐渲檬鞘裁础Ｎ业慕鉀Q方法是：在集成到項(xiàng)目之前，先用最簡(jiǎn)單的方式測(cè)試。比如直接用 curl 發(fā)一個(gè)請(qǐng)求，看能不能通。如果 curl 都不通，那問題肯定在配置上，不是代碼的問題。

比如說我這里，我直接問他「你能做什么」，結(jié)果呢，他返回了一個(gè) AI API 的報(bào)錯(cuò)。這個(gè)是在我剛集成了 API 之后，然后就直接去測(cè)試，然后他就給我報(bào)了錯(cuò)誤。

所以我就一直讓他去檢查到底是哪里錯(cuò)的。他就必須是用寫完了的整體代碼去測(cè)。

如果是我在讓他集成之前，就先去把這個(gè)什么網(wǎng)關(guān)配置、模型的名稱什么的都自己去測(cè)、去填寫好，再把它集成進(jìn)去，就不會(huì)那么麻煩。

因?yàn)樗F(xiàn)在是跟著整個(gè)代碼一起去測(cè)試，然后整個(gè)代碼又是跟整個(gè)大項(xiàng)目聯(lián)合在一起的，所以說你讓他去測(cè)試，就可能會(huì)動(dòng)到其他的部分。這樣子就會(huì)有一些不必要的麻煩。

所以你把這個(gè)單獨(dú)的 AI API 讓他單獨(dú)地去測(cè)試，就是在最小程度上去減少影響到其他的方面。這樣子首先他專門調(diào)這個(gè)地方也會(huì)調(diào)得比較專注，第二個(gè)也不會(huì)牽扯到其他的部分，就是不會(huì)把你的測(cè)試的部分跟你的生產(chǎn)代碼放在一起去混淆。

坑 2：Markdown 格式問題

AI 默認(rèn)會(huì)用 Markdown 格式輸出，加粗、斜體、代碼塊什么的。但我發(fā)現(xiàn)我在用的聊天軟件

一開始我想讓 AI 在發(fā)送前自動(dòng)轉(zhuǎn)換格式，但這樣太麻煩了，而且容易出 bug。后來我直接在系統(tǒng) prompt 里告訴 AI：「在這個(gè)聊天軟件加粗或斜體。可以用編號(hào)列表或者換行來組織內(nèi)容。」

當(dāng)然，其實(shí)你這么跟他說，他有時(shí)候還是不會(huì)去遵守這個(gè)prompt 規(guī)定。所以我就直接寫了一個(gè)腳本，用正則公式直接把這些什么「加粗」「斜體」這種原始的格式直接給去掉，問題直接從源頭解決了。

坑 3：目錄不存在

有一次我家里人上傳文件，系統(tǒng)報(bào)錯(cuò)「目錄不存在」。原因是代碼里假設(shè)目錄已經(jīng)存在，但對(duì)于新用戶來說，他的專屬目錄還沒有被創(chuàng)建過。

這種問題在本地測(cè)試的時(shí)候不容易發(fā)現(xiàn)，因?yàn)槟阕约簻y(cè)試的時(shí)候目錄都是現(xiàn)成的。解決方法很簡(jiǎn)單：讓 AI 在寫入文件之前，先檢查目錄是否存在，不存在就自動(dòng)創(chuàng)建。

但更重要的是，這讓我意識(shí)到：很多 bug 不是代碼邏輯的問題，而是環(huán)境假設(shè)的問題。AI 寫代碼的時(shí)候，它假設(shè)的環(huán)境可能和真實(shí)運(yùn)行的環(huán)境不一樣。所以我現(xiàn)在會(huì)特別注意問 AI：「這段代碼有什么前置條件？需要什么目錄、什么權(quán)限、什么依賴？」

總結(jié)一下處理錯(cuò)誤的心法：

先讓 AI 自己測(cè)，減少低級(jí)錯(cuò)誤

報(bào)錯(cuò)時(shí)給完整上下文：做了什么、期望什么、得到什么

集成前先用最小方式驗(yàn)證（curl、簡(jiǎn)單腳本）

問清楚代碼的前置條件和環(huán)境假設(shè)

歸根結(jié)底，調(diào)試不是玄學(xué)，是信息戰(zhàn)。你給 AI 的信息越完整，它幫你定位問題就越快。

產(chǎn)品思維——代碼能學(xué)會(huì)，這個(gè)學(xué)不會(huì)

到這里，有人可能會(huì)覺得：用 AI 寫代碼也沒什么難的嘛，跟著步驟來就行了。

但我想說的是，代碼只是最容易的部分。真正決定你做出來的東西能不能用、好不好用的，是你的產(chǎn)品思維。而這個(gè)東西，AI 幫不了你。

我舉幾個(gè)我在做 AI Agent Bot 時(shí)的真實(shí)例子。

設(shè)計(jì) 1：為什么要做存儲(chǔ)配額系統(tǒng)？

一開始我沒想過這個(gè)問題。用戶上傳文件，我就存到服務(wù)器上，很簡(jiǎn)單。

但后來我算了一筆賬：我的 VPS 總共 150GB 硬盤空間。如果我開放給 10 個(gè)朋友用，每個(gè)人傳 20GB 的文件，硬盤就滿了。更糟的是，如果有一個(gè)人傳了 100GB，其他人就沒法用了。

這時(shí)候我意識(shí)到，我需要一個(gè)配額系統(tǒng)。

但配額設(shè)成多少合適？我想了想自己的使用場(chǎng)景：日常處理的文件，PDF、圖片、文檔，加起來可能也就幾百 MB。給每個(gè)用戶 5GB，足夠用了，而且 150GB 可以支持 30 個(gè)用戶，還留有余量。

這個(gè)決策 AI 能幫我做嗎？

這也是可以的，你可以讓他自己去查整個(gè)系統(tǒng)的一個(gè)配置，然后你再跟他說你大概有幾個(gè)人會(huì)來使用，調(diào)研大概多少是合適的。

然后包括說，你可以讓他去設(shè)計(jì)那種：他的每一次用戶上傳的文件或者產(chǎn)生新文件，他就要自己去整理這種文件系統(tǒng)，他要有意識(shí)地去提示用戶，提醒文件「你這個(gè)文件需要整理了，你要怎么怎么樣」。

AI 很快就把代碼寫出來了。但「5GB」這個(gè)數(shù)字，是我們討論想出來的。

AI 是執(zhí)行者，你是決策者。 你要想清楚「做什么」和「為什么」，AI 負(fù)責(zé)「怎么做」。如果你自己都沒想清楚，AI 寫出來的東西就算能跑，也不一定是你真正需要的。

設(shè)計(jì) 2：消息太長(zhǎng)怎么辦？

這個(gè)問題是我在實(shí)際使用中發(fā)現(xiàn)的。

有一次我讓 AI 分析一個(gè)長(zhǎng)文檔，它返回了一大段分析結(jié)果，大概 2000 多字。結(jié)果這個(gè)聊天軟件顯示出來一團(tuán)亂麻——因?yàn)樗鼘?duì)長(zhǎng)消息的 Markdown 渲染很差，格式全亂了，而且滾動(dòng)起來也很難受。

我第一反應(yīng)是讓 AI 把消息拆成幾段發(fā)。但試了之后發(fā)現(xiàn)體驗(yàn)也不好，幾條消息刷屏，而且上下文被打斷了。

后來我想到一個(gè)辦法：如果回復(fù)超過 1000 字，就自動(dòng)打包成 .txt 文件發(fā)送。

這樣用戶收到的是一個(gè)文件，點(diǎn)開就能看完整內(nèi)容，排版也不會(huì)亂。而且文件可以保存、可以轉(zhuǎn)發(fā)，比一堆消息實(shí)用多了。

這個(gè)改動(dòng)從技術(shù)上看很簡(jiǎn)單，就是加一個(gè)字?jǐn)?shù)判斷和文件生成的邏輯。但這是一個(gè)產(chǎn)品決策，不是技術(shù)決策。AI 不會(huì)主動(dòng)告訴你「消息太長(zhǎng)體驗(yàn)不好」，因?yàn)樗恢肋@個(gè)聊天軟件

這種細(xì)節(jié)，只有你自己用過、踩過坑，才會(huì)想到要優(yōu)化。用戶體驗(yàn)的提升，往往就藏在這些「小」決策里。

設(shè)計(jì) 3：安全問題怎么想？

這是我花時(shí)間最多的一個(gè)設(shè)計(jì)。

我的 Bot 有一個(gè)核心能力：它可以讀寫服務(wù)器上的文件。這是它的價(jià)值所在，但也是最大的風(fēng)險(xiǎn)。

我問自己幾個(gè)問題：

如果 AI 出 bug，會(huì)不會(huì)把我服務(wù)器上的重要文件刪了？

如果用戶 A 能訪問用戶 B 的文件怎么辦？

如果有人通過 Bot 執(zhí)行惡意命令怎么辦？

這些問題 AI 不會(huì)主動(dòng)幫你想，因?yàn)樗回?fù)責(zé)實(shí)現(xiàn)你提出的功能。安全是你自己的責(zé)任。

想清楚風(fēng)險(xiǎn)之后，我做了幾個(gè)決策：

禁用 bash 執(zhí)行： Claude Agent SDK 默認(rèn)可以執(zhí)行任何系統(tǒng)命令，這太危險(xiǎn)了。我只需要 AI 能讀寫文件，不需要它能執(zhí)行 rm -rf /。所以我在配置里把 bash 權(quán)限關(guān)掉了。

路徑隔離： 每個(gè)用戶只能訪問自己的目錄 users/{user_id}/data/。任何試圖訪問這個(gè)目錄之外的路徑，都會(huì)被拒絕。這樣就算 AI 出錯(cuò)，影響范圍也只限于這個(gè)用戶自己的文件。

Docker 容器隔離： 整個(gè) Bot 跑在一個(gè) Docker 容器里。就算最壞的情況發(fā)生——容器里的東西全被搞壞了——我只需要重建容器就行，不會(huì)影響到服務(wù)器上的其他東西。

管理員面板： 我給自己做了一個(gè)管理功能，可以查看所有用戶的配額使用情況，可以禁用某個(gè)用戶。這樣如果有人濫用，我能及時(shí)處理。

這些措施聽起來好像很「專業(yè)」，但其實(shí)都是常識(shí)。不是什么高級(jí)工程，就是基礎(chǔ)的安全意識(shí)。 關(guān)鍵是你要主動(dòng)去想「會(huì)出什么問題」，而不是等問題發(fā)生了再補(bǔ)救。

我們之前也看到了很多人去用一些提示詞注入去搞什么破解。然后他們通過怎么去誘導(dǎo) AI，然后用到 agent，我們?nèi)グ阉麄兊囊恍┉h(huán)境給破壞掉的這種，這種新聞我覺得之前還是說得蠻多了。

所以你只要看得多了之后，你大概也會(huì)有這樣一個(gè)意思，所以我覺得安全是一個(gè)必要的方面。就算你雖然不知道具體你要怎么去做，但是你一定要考慮到這個(gè)方面。你可以去問它，但是你不能忘了去問。

所以從整體上來說，我在做這個(gè)產(chǎn)品，最開始是為了給身邊人、給家人用，但其實(shí)我的整個(gè)設(shè)計(jì)就是按照一個(gè)「想要把它給別人、給大家去用」的想法來做的。雖然我還不知道怎么去做這種商業(yè)化，但是我覺得這才是一個(gè)正常的產(chǎn)品。

我們從一開始就要養(yǎng)成這樣的習(xí)慣，不是說 demo，你就什么都可以不用去管，或者說你給身邊的人使用，你也不用去管很多東西，但我覺得這是一個(gè)習(xí)慣。

可能你現(xiàn)在只能做一個(gè) demo，但是隨著你的能力慢慢成長(zhǎng)起來，你就可以做一些大的產(chǎn)品。你從小就把這個(gè)習(xí)慣養(yǎng)好了之后，后面就可以減少很多不必要的麻煩。

回顧這三個(gè)設(shè)計(jì)，我發(fā)現(xiàn)它們有一個(gè)共同點(diǎn)：都是在回答「為什么」的問題。

為什么要有配額？因?yàn)橘Y源有限。

為什么長(zhǎng)消息要變成文件？因?yàn)橛脩趔w驗(yàn)更好。

為什么要做這么多安全措施？因?yàn)轱L(fēng)險(xiǎn)真實(shí)存在。

這些「為什么」，AI 回答不了。它只知道「怎么做」——你告訴它要配額系統(tǒng)，它就寫配額系統(tǒng)；你告訴它要生成文件，它就生成文件。但它不會(huì)問「我們真的需要這個(gè)嗎？」或者「有沒有更好的方案？」

這就是為什么我說產(chǎn)品思維是差異化因素。

會(huì)用 AI 寫代碼的人會(huì)越來越多，這個(gè)門檻已經(jīng)很低了。但能想清楚「做什么」和「為什么這樣做」的人，永遠(yuǎn)是少數(shù)。

不會(huì)寫代碼，反而是一種優(yōu)勢(shì)。因?yàn)槟悴粫?huì)陷入技術(shù)細(xì)節(jié)里，你會(huì)更多地思考：這個(gè)東西到底解決了什么問題？用戶真正需要的是什么？有沒有更簡(jiǎn)單的方案？

代碼是手段，產(chǎn)品是目的。 AI 幫你搞定了手段，但目的只有你自己能定義。

快去干吧

我在這個(gè)過程當(dāng)中其實(shí)一直使用的工具是 Claude Code，所以我覺得大家可以趕快去使用起來，不僅僅是用它寫代碼，也可以讓它幫你做一些個(gè)人生產(chǎn)力上的一些方法、一些實(shí)踐吧。

比如有的人就用它去跟 Obsidian 結(jié)合起來，去和知識(shí)管理放在一起。然后有的人又用它去做一些自動(dòng)化的操作，自己寫一些 skill，把自己的sop梳理下來。 我也看到有人會(huì)給自己設(shè)定一些文件夾，把文件夾對(duì)應(yīng)成生活、工作方面的一些不同部分，然后 agent 相當(dāng)于是他的一個(gè)個(gè)人秘書，幫他去管理、幫他去管理這些文件夾。

就是很多這樣的實(shí)踐，其實(shí)工具它的能力是很強(qiáng)的，可能現(xiàn)在限制我去用它的一些方面，就是我自己的一個(gè)想象力、審美吧。

然后現(xiàn)在也已經(jīng)有很多教程教大家怎么去用這類產(chǎn)品，包括說像 OpenCode 也有人推薦，如果說 Claude Code 太貴的話，也可以去用國(guó)內(nèi)的智譜的 GLM，這個(gè)教程也是有很多的。

包括這個(gè)新手指南寫的挺好的，然后可以看第一、二、三章，看完差不多就開始用了。后面的那些教程，其實(shí)你可以在做項(xiàng)目的過程當(dāng)中自己一點(diǎn)一點(diǎn)去摸索，然后逐漸學(xué)習(xí)。

為什么普通人要多 Vibe Coding

寫到這里，我想聊聊一個(gè)更大的問題：為什么我覺得不會(huì)編程的人，反而應(yīng)該多用 AI 去構(gòu)建東西？

這個(gè)問題我想了很久，因?yàn)楹芏嗳藭?huì)覺得「我又不是程序員，學(xué)這個(gè)干嘛」。但我的體會(huì)是，Vibe Coding 帶給我的收獲，遠(yuǎn)不止「做出了一個(gè) Bot」這么簡(jiǎn)單。

第一，邊干邊學(xué)是最高效的學(xué)習(xí)方式。

傳統(tǒng)的學(xué)習(xí)路徑是這樣的：先學(xué)編程語(yǔ)言，再學(xué)框架，再學(xué)架構(gòu)設(shè)計(jì)，然后才開始做項(xiàng)目。這條路走下來，少說也要一兩年。而且很多人學(xué)到一半就放棄了，因?yàn)閷W(xué)的時(shí)候不知道這些東西有什么用，純粹是在「為了學(xué)而學(xué)」。

Vibe Coding 的路徑完全反過來：你先有一個(gè)想做的東西，然后邊做邊學(xué)。遇到不懂的，問 AI；卡住了，讓 AI 幫你解決。整個(gè)過程可能只需要幾天甚至幾個(gè)小時(shí)，你就能做出一個(gè)可以用的東西。

區(qū)別在哪里？動(dòng)力。

當(dāng)你是為了解決自己的問題而學(xué)習(xí)時(shí)，每一個(gè)新知識(shí)都有明確的用途。我學(xué) Docker 不是因?yàn)椤窪ocker 是熱門技術(shù)」，而是因?yàn)椤肝倚枰盐业?Bot 隔離起來，不然出問題會(huì)影響整個(gè)服務(wù)器」。這種學(xué)習(xí)是有目標(biāo)的，所以記得住、用得上。

而且，這種方式的反饋循環(huán)特別短。傳統(tǒng)學(xué)習(xí)可能學(xué)了三個(gè)月還看不到成果，Vibe Coding 可能聊了三個(gè)小時(shí)就有一個(gè)能跑的 demo 了。每一次小的成功都會(huì)給你動(dòng)力繼續(xù)往下做，形成正向循環(huán)。

第二，Demo 是最有說服力的溝通方式。

這一點(diǎn)我在前面聊過，但我想再?gòu)?qiáng)調(diào)一下，因?yàn)檫@對(duì)不會(huì)編程的人來說太重要了。

以前，如果你有一個(gè)想法，你只能寫文檔、畫原型圖、做 PPT。但這些東西都是「描述」，不是「展示」。你說「我想做一個(gè)能自動(dòng)分析數(shù)據(jù)的工具」，別人聽了可能覺得「哦，又是一個(gè)想法」，然后就沒有然后了。但如果你直接做一個(gè) demo 出來，哪怕很粗糙，別人能親手用一下、看到真實(shí)的效果，說服力完全不一樣。

Demo 是穿透認(rèn)知壁壘的最短路徑。 而 Vibe Coding 讓不會(huì)編程的人也能做 demo 了。這是一個(gè)巨大的能力解鎖。

第三，這是系統(tǒng)化思維最好的訓(xùn)練場(chǎng)。

很多人覺得「系統(tǒng)化思維」是一個(gè)很虛的概念，不知道怎么培養(yǎng)。但我發(fā)現(xiàn)，用 AI 做一個(gè)完整項(xiàng)目，是培養(yǎng)系統(tǒng)化思維最實(shí)際的方式。

因?yàn)槟惚仨毾肭宄芏鄦栴}：

這個(gè)系統(tǒng)有哪些模塊？它們之間怎么交互？

先做什么，后做什么？為什么是這個(gè)順序？

如果這個(gè)模塊出問題，會(huì)影響哪些其他模塊？

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

這些問題在傳統(tǒng)工作中很少有機(jī)會(huì)思考，因?yàn)榇蠖鄶?shù)人只負(fù)責(zé)自己那一小塊。但當(dāng)你自己從零開始構(gòu)建一個(gè)東西時(shí)，你必須站在全局的角度去思考。

而且 AI 會(huì)逼著你把想法表達(dá)清楚。你不能說「幫我做一個(gè)好用的系統(tǒng)」，你得說清楚「好用」是什么意思、「系統(tǒng)」包含哪些功能。這個(gè)過程本身就是在訓(xùn)練你把模糊的想法結(jié)構(gòu)化。

做完幾個(gè)項(xiàng)目之后，我發(fā)現(xiàn)自己在工作中思考問題的方式也變了。以前看到一個(gè)需求，我會(huì)想「這個(gè)功能怎么實(shí)現(xiàn)」；現(xiàn)在我會(huì)先想「這個(gè)需求的本質(zhì)是什么、有哪些相關(guān)的模塊、改動(dòng)會(huì)帶來什么影響」。這種思維方式的轉(zhuǎn)變，比學(xué)會(huì)某個(gè)具體技術(shù)更有價(jià)值。

第四，這是認(rèn)識(shí)自己的一面鏡子。

這一點(diǎn)可能有點(diǎn)抽象，但我覺得很重要。

當(dāng)你用 AI 做項(xiàng)目時(shí)，你會(huì)不斷遇到「我想要什么」這個(gè)問題。AI 會(huì)問你：「你想要 A 方案還是 B 方案？」「這個(gè)功能的優(yōu)先級(jí)是什么？」「出錯(cuò)的時(shí)候應(yīng)該怎么處理？」

一開始你會(huì)發(fā)現(xiàn)，很多問題你自己都沒想清楚。你以為自己知道想要什么，但真正被問到細(xì)節(jié)的時(shí)候，你才發(fā)現(xiàn)自己的想法是模糊的。

這個(gè)過程會(huì)逼著你不斷澄清自己的想法。你要問自己：我真正在意的是什么？什么是必須有的，什么是可有可無的？我愿意為了簡(jiǎn)單犧牲多少功能？

做著做著，你會(huì)越來越清楚自己是一個(gè)什么樣的人。 你是喜歡復(fù)雜但強(qiáng)大的系統(tǒng)，還是簡(jiǎn)單但夠用的工具？你是在意功能完整性，還是在意用戶體驗(yàn)？你是愿意花時(shí)間打磨細(xì)節(jié)，還是先上線再說？

這些問題沒有對(duì)錯(cuò)，但你需要知道自己的答案。Vibe Coding 給了你一個(gè)低成本試錯(cuò)的機(jī)會(huì)，讓你通過實(shí)際的選擇來認(rèn)識(shí)自己。

第五，這是管理能力的預(yù)演。

這一點(diǎn)是我后來才意識(shí)到的。

當(dāng)你用 AI 做項(xiàng)目時(shí)，你其實(shí)在扮演一個(gè)「管理者」的角色。你負(fù)責(zé)定方向、做決策、分配任務(wù)、檢查結(jié)果。AI 是你的「執(zhí)行者」，負(fù)責(zé)把你的想法變成代碼。

這和管理一個(gè)團(tuán)隊(duì)其實(shí)很像。你要學(xué)會(huì)：

怎么把一個(gè)大目標(biāo)拆解成可執(zhí)行的小任務(wù)

怎么清晰地傳達(dá)你的期望

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

出了問題怎么定位原因、怎么給反饋

如果你未來想帶團(tuán)隊(duì)，這些能力是必須的。而 Vibe Coding 給了你一個(gè)零成本練習(xí)的機(jī)會(huì)——AI 不會(huì)抱怨你的需求不清楚，它只會(huì)按照你說的去做。如果結(jié)果不對(duì)，那一定是你沒說清楚。這會(huì)倒逼你提升表達(dá)能力和任務(wù)拆解能力。

所以，Vibe Coding 到底是什么？

它不是一種編程技術(shù)，而是一種做事的方式。

它的核心是：

敢于嘗試——因?yàn)樵囧e(cuò)成本很低，最多浪費(fèi)幾個(gè)小時(shí)

快速反饋——做出來的 demo 比任何文檔都有說服力

在行動(dòng)中學(xué)習(xí)——不是先學(xué)會(huì)再做，而是邊做邊學(xué)

用 AI 放大自己——你有想法但不會(huì)實(shí)現(xiàn)？AI 幫你實(shí)現(xiàn)。你有產(chǎn)品感但不會(huì)編程？AI 幫你編程

在 AI 時(shí)代，瓶頸已經(jīng)不是「我能不能寫代碼」，而是「我知不知道自己想要什么」。

技術(shù)門檻被 AI 抹平了，但想清楚「做什么」和「為什么做」的能力，AI 替代不了。這才是真正稀缺的東西。

所以，如果你有一個(gè)想法，一直覺得「我不會(huì)編程，所以做不了」——現(xiàn)在沒有這個(gè)借口了。

下載一個(gè) Claude Code 或者 Cursor，把你的想法告訴 AI。你會(huì)發(fā)現(xiàn)，原來自己能做到的事情，比想象中多得多。