導語

建?！@個聽起來高深的詞，本質上只是給一個黑箱喂入輸入、拿到輸出。傳統做法要求你親手搭建黑箱內部的每一條管道：數據清洗、特征工程、模型選擇、參數調優、結果可視化，任何一個環節出錯都要回頭排查。2025 年初，Andrej Karpathy 提出“vibe coding”概念：你不再逐行編寫代碼，而是用自然語言描述意圖，讓 AI 生成實現。在此基礎上提出“vibe modeling”——對 vibe coding 再做一層抽象：你不生成代碼，你生成模型。你只需給出文字指令，就能得到一個可運行的模型，以及模型運行后的數值解或可視化成果。

關鍵詞：建模（Modeling），Vibe Coding，Vibe Modeling，工作流抽象（Workflow Abstraction），大語言模型（Large Language Model）

任筱芃丨作者

金依琳、趙思怡丨審校

引言

她不會建模，也一直以為模型屬于那些會寫代碼的人。直到老板要求她明早交出一份解釋銷量下滑原因的分析報告。凌晨一點，辦公室只剩她一個人。她把 3 份 Excel 表格、2 頁會議紀要和 300 多條客服反饋全部拖進 ChatGPT DeepResearch，只輸入了“找出銷量下滑的原因，生成可匯報的模型結果”。30分鐘后，系統吐出了趨勢圖、異常點標注、原因排序和一份完整 PPT。她盯著那些圖，忽然冒出一個從未想過的問題：“如果它錯了，我該從哪里開始懷疑？”網頁安靜下來，像一只剛剛合上的全視之眼。天亮前，報告被發進了工作群。她依然不會建模，卻已經要為一個自己看不見的模型負責。

她的體驗并不孤例。從 2021 年首批 AI 編程工具上線算起，不過 5 年，這類工具已經滲透到數據分析、文檔撰寫、商業決策的幾乎所有環節。你不需要會建模，也能拿到模型結果，但也許、遲早你會和她一樣，對這些結果產生疑問。這種“用自然語言驅動建?！钡男路妒?，有人稱之為 vibe modeling。接下來的內容將回答 3 個問題：這種范式在技術上是怎么實現的？使用時需要注意什么？真實場景中的表現如何？

什么是建模

在工程或科學語境中，“建?！笔怯靡粋€簡化的系統去表示另一個更復雜的系統，亦或是是用可形式化的結構——變量、關系或規則——對現實系統進行抽象并用于解釋或預測結果的過程。氣象學家用偏微分方程組模擬大氣運動，經濟學家用回歸方程預測失業率，游戲設計師用有限狀態機控制 NPC 行為——形式千差萬別，底層邏輯是一致的。你有一個輸入（大氣初始條件、宏觀經濟指標、玩家動作），經過一個處理過程，得到一個輸出（未來 72 小時降水概率、下一季度 GDP 增長率、NPC 的下一個行為）。

這個處理過程對構建者來說是可透明的，但對使用者來說是一個黑箱。建模的核心價值在于抽象——把復雜性封裝在黑箱里，讓使用者只關心輸入和輸出。不一定要理解黑箱內部的全部細節，就像氣象學家不需要手動計算每一層大氣的熱力學過程，只需要輸入溫度、濕度、風速（矢量），模型就能給出降水概率。

本文討論的“建?！狈褐笍脑紨祿娇蓤蟾娼Y果的完整流程，而不局限于統計建模這一步。傳統做法的一個隱含假設是你必須親手搭建這個黑箱。以數據分析為例，你有一份 CSV 表格，目標是生成包含趨勢圖和統計摘要的報告。傳統工作流可以分 4 步：用 Python 讀取文件、處理缺失值和異常值；選擇統計方法（線性回歸、時間序列、聚類）；編寫繪圖代碼；將結果整合為報告格式。每一步都需要專業知識，每一步都可能出錯，而且錯誤在最后一步才暴露是最令人頭大的。

痛點不在于建模本身，而在于搭建箱子的過程。

Vibe Coding

2025 年 2 月，OpenAI 聯合創始人之一 Andrej Karpathy 在社交媒體上發表了一段話，迅速在開發者社區引發病毒式傳播。他寫道，自己最近在做一個項目時，“我實際上沒有寫任何一行代碼”。他只是用自然語言告訴 AI 想要什么，AI 生成代碼，他檢查結果，不滿意就調整描述，滿意就接受。他把這種方式稱為“vibe coding”——憑感覺編程 (Karpathy, 2025)。

這個概念之所以引起共鳴，不是因為它在技術上有多新穎——GitHub Copilot 自 2021 年起就提供代碼補全功能，截至 2026 年 1 月已擁有 470 萬付費訂閱用戶，總用戶數 2025 年 7 月突破 2000 萬 (GitHub, 2026)——而是因為它捕捉到了一種正在蔓延的工作方式的轉變。傳統編程要求你精確地知道每一行代碼做什么；vibe coding 只要求你知道你想要什么結果，然后通過“生成→檢查→調整→再生成”的反饋循環來逼近目標。交互方式從“逐行補全代碼”轉向“描述意圖、生成完整實現”，開發者的控制粒度發生了根本變化。

工具生態迅速跟進。Cursor 2026 年 4 月正洽談 20 億美元融資，估值超 500 億美元 (Cursor, 2026)。Windsurf（由 Codeium 開發）提供了類似的功能，但增加了“Cascade”特性——AI 可以跨多個文件進行連貫的編輯，2024 年用戶數突破 50 萬 (Codeium, 2024)。Replit Agent 則更進一步，2026 年平臺用戶突破 5000 萬，用戶只需描述一個應用的功能需求，Agent 就能從零開始搭建一個可運行的項目，包括前端界面、后端邏輯和數據庫 (Replit, 2026)。

這些工具的共同特征是用戶不再只直接操作代碼，而是提供操作代碼的意圖。你不需要知道 React 的 useState hook（一種讓網頁記住用戶操作狀態的技術）怎么用，你只需要說“我想要一個計數器，點擊按鈕加 1”。你不需要知道 pandas 的 groupby 語法（一種按類別匯總數據的命令），你只需要說“按月份匯總銷售額”。

代碼仍然是主要的執行媒介，但你不再需要直接與它交互。

Vibe Modeling

Vibe modeling 顯然指向的是“如果代碼的編寫與執行之間的中間層進一步被自動化，會發生什么？”

回到 PPT 制作的例子。傳統（指coding ( ?? ?? ?? )）流程可以是你寫 Python 腳本，調用 python-pptx 庫——一個專門用代碼操作 PPT 文件的工具包——手動設置每一頁幻燈片的布局、文字、圖表，運行腳本，得到 PPT 文件。你需要寫這樣的代碼：

prs.save('Q1_sales.pptx')               # 保存文件

Vibe coding——你只需要說”幫我做一個關于 Q1 銷售數據的 PPT，包含折線圖和餅圖”，AI 生成上面的代碼，你審查后運行。

Vibe modeling——你同樣說這句話，系統直接輸出 PPT 文件。代碼是否存在、調用了哪些庫——這些細節對你不可見。

圖：模擬 python-pptx 生成的演示文稿

這聽起來像是在描述一個高級的自動化工具，但兩者有本質區別。自動化工具執行預定義的工作流——一個主體事先定義好每一步，工具按順序執行。Vibe modeling 的工作流是運行時生成的——系統根據你的自然語言輸入，動態決定需要哪些步驟、以什么順序執行、如何處理異常。區別的核心不在于“是否自動化”，而在于流程的可配置程度和生成時機 (Chase, 2022)。

實現這一點的關鍵技術是大語言模型驅動的工作流編排。Vibe modeling 并不是一個單一模型直接“變出”結果，而是一個由 LLM 驅動的 Agent 工作流，內部經歷了多次角色切換。以 LangChain 的 Agent 框架（一種讓 AI 像項目經理一樣，收到大任務后自行拆解步驟、選工具、監督執行的架構）為例，整個過程可以拆解為 4 層：

意圖理解層，LLM 對用戶的自然語言目標進行業務語義的深層解析（例如“找出銷量下滑的原因”——系統需要理解“銷量”對應哪張表的哪個字段、“下滑”意味著什么時間跨度上的比較）；

規劃層，Planner 將任務拆解為多個具體的子步驟——讀取文件、識別字段、清洗數據、選擇統計方法、生成圖表、撰寫報告，每一步都有明確的輸入輸出，就像你在處理一份調查問卷時會先剔除亂填的答卷、再統計各選項頻次、最后畫圖展示結果；

執行層，Agent 通過 Tool Calling 調用具體的工具（Python 運行時、SQL 引擎、圖表庫），在沙箱或云端環境中完成真實計算；

整合層，LLM 再把各個子步驟的中間結果組織成用戶最終看到的圖表、文字結論或 PPT 文件 (Chase, 2022)。

LangChain 在 GitHub 上累計獲得超過 9.5 萬顆星標，已成為 LLM 應用開發的事實標準框架。這個過程中，LLM 充當了“工作流編排器”的角色——它不是在生成代碼，而是在生成并執行工作流水線。

更激進的實現讓中間步驟對用戶不可見。OpenAI 的 Advanced Data Analysis（原 Code Interpreter）在 GPT 系列模型支持下，允許用戶上傳 CSV 等文件，用自然語言描述分析需求，系統直接在沙箱——一個與外界隔離的臨時運行環境，程序在里面自由執行，但無法訪問你的個人文件——中執行 Python 代碼、生成圖表并返回結果——用戶全程無需看到或編寫任何代碼 (OpenAI, 2023)。這一能力經過 2025-2026 年多次重大迭代，現已深度集成 o3-pro 等高級推理模型、工具調用與 ChatGPT for Excel/Google Sheets 原生協作，支持更復雜的多步數據工作流。類似的，Anthropic 的 Claude Artifacts 則進一步演進為 Live Artifacts，支持連接實時數據源（如 Notion、Slack、Stripe），生成可交互、自更新的可視化和應用(Anthropic, 2024)。2026 年已全面集成 Claude Cowork 工作空間。

3 種范式的對比可以用 1 句話概括。傳統建模是“你自己造黑箱”，vibe coding 是“你告訴別人怎么造黑箱”，vibe modeling 是“你只描述黑箱應該干什么”。

討論：使用 vibe modeling 時要注意什么

Vibe modeling 讓建模從程序員的手藝變成人人可用的工具。但每一次抽象都有代價。使用 vibe modeling 時，有 3 件事值得注意——分別涉及控制權、驗證能力和長期技能維持三個層面。

第一件是精度與控制的取舍。傳統建模給你完全的控制權——精確選擇算法、調整參數、逐行調試。Vibe coding 讓你失去部分控制權——AI 生成的代碼可能不是最優解，你可能不理解它為什么選擇某個算法。Vibe modeling 讓你失去幾乎全部的控制權——你不知道系統用了什么算法，無法調試中間過程，只能在最終結果上判斷好壞。對于探索性分析——“這份數據有什么有趣的模式？”——精度不是首要目標，快速迭代更重要。對于關鍵決策——“基于這個模型的結果，我們是否應該投資 5000 萬？”——你需要理解模型的每一個假設和局限性。這就像你自己開車（傳統建模：方向盤在你手里）vs 坐出租車（vibe coding：你告訴司機去哪，但方向盤不在你手里）vs 坐自動駕駛（vibe modeling：你連司機都沒有，只輸入目的地）。3 種方式都能到達目的地，但你對手中方向盤的掌控程度從 100% 降到 0%。

第二件是驗證的困難。傳統建模中，驗證是一條從輸入到輸出的完整鏈條。你可以閱讀代碼確認數據處理是否正確，可以檢查算法實現是否準確，可以復現結果——“可復現”意味著換一個人用同樣的數據、同樣的方法，應該得到完全一樣的結果，就像同一道菜的食譜，不同廚師照著做應該味道相同。Vibe modeling 把這條鏈條從中切斷了。代碼不可見，你只能通過輸出反推過程——而輸出可能看起來完全合理。但看起來合理不等于正確。系統在自動處理數據時，在數據清洗、字段映射等環節中，每一步都包含”該不該把這行算進來”的隱含判斷——而你看不到判斷的依據。2021 年，房地產平臺 Zillow 信任自家算法對房價的預測，大量購房轉售，因為預測結果在火熱的市場中看起來完全合理，但算法無法捕捉急速冷卻，最終累計虧損超過 5 億美元，裁員 25% 并關閉該業務 (Zillow, 2021)。2024 年，加拿大航空的 AI 客服向乘客編造了一條不存在的喪親折扣政策，法院裁定航空公司需為 AI 的輸出承擔全部法律責任 (Air Canada, 2024)。前者是 5 億美元的財務災難，后者是法律追責 AI 輸出的先例。根源都是對不可見過程的盲目信任。想象系統生成了一份看起來合理的銷售趨勢圖表，但背后的數據清洗邏輯錯誤地將退貨訂單也算作了正向銷售——圖表的形狀和數值都在”合理范圍”內，你不會產生懷疑，但基于這份圖表做出的庫存決策將是可能也是災難性的。

第三件是能力的自強化悖論。Stack Overflow 2025 年度開發者調查顯示，84% 的開發者已在工作中使用或計劃使用 AI 輔助編程工具 (Stack Overflow, 2025)。Anthropic 對 52 名開發者進行的一項隨機對照實驗發現，使用 AI 輔助學習編程的開發者在后續技能測試中得分低了 17 個百分點（AI 輔助組 50%，手寫組 67%），其中調試能力受影響最大 (Shen & Tamkin, 2026)。Anthropic 對 132 名工程師進行的另一項內部調查顯示，員工已在 59% 的日常工作中使用 Claude，同時也指出了“監督悖論”：有效使用 Claude 需要監督能力，而監督能力恰恰會被 AI 的過度使用所侵蝕——你用來判斷 AI 輸出是否正確的能力，正是你因依賴 AI 而正在失去的能力 (Anthropic, 2025)。擁有近 30 年編程經驗的 Simon Willison 也報告說，使用 AI 工具后，他對應用程序“沒有一個牢固的心智模型” (Willison, 2026)。

這意味著什么？使用 vibe modeling 不需要你理解底層原理，但判斷輸出是否正確的能力仍然需要你來提供。這不是說你必須回去學 Python——而是說，在按下回車之前，你需要知道自己想問什么、答案應該長什么樣、哪些異常值得懷疑。

有人將這種演進比作從匯編語言到高級語言、從手動管理服務器到 AWS 的躍遷。但正如 Lars Faye 指出的：“更高的模糊性不等于更高的抽象” (Faye, 2026)。編譯器隱藏了機器碼但保留了確定性——同一個 C++ 程序編譯兩次，結果相同。而自然語言驅動的建模引入了不確定性：同一個指令可能被不同地理解，同一個輸出可能來自完全不同的內部過程。這不是更高層級的抽象，而是更高層級的不透明。

但這不意味著你不應該使用 vibe modeling。就像你不需要理解搜索引擎的 PageRank 算法也能有效地使用 Google 一樣，你不需要理解大語言模型的內部機制也能有效地使用 vibe modeling。關鍵在于：知道什么時候該信任結果，什么時候該質疑?；谏鲜龇治?，我們可以勾勒出當前 vibe modeling 的適用邊界：

• 適合的場景：探索性數據分析（“這份數據有什么有趣的模式？”）、標準化報告生成、數據可視化、快速原型驗證——在這些場景中，精度不是首要目標，快速迭代更重要。

• 需要謹慎的場景：關鍵決策建模（“基于這個模型的結果，我們是否應該投資 5000 萬？”）、需要可重復性的科學研究、需要審計軌跡的合規場景——在這些場景中，你需要理解模型的每一個假設和局限性。

• 可能翻車的條件：需求描述過于模糊（“幫我分析一下”）、數據質量差（缺失值多、格式不一致）、需要深度領域專業知識（醫學診斷、金融風控）——在這些條件下，系統的輸出可能看起來合理但實際上不可靠。

Vibe modeling 不是要取代傳統建模，而是在“會建?！焙汀安蛔鼋！敝g開辟了一個新的中間地帶。市場分析師、產品經理、記者、學生——這些本來不會寫代碼的人，現在可以通過自然語言描述需求來獲得建模能力。這是一種建模能力的擴展，代價是精度和控制權。

案例：真實場景中的 vibe modeling

以上 3 個問題在實際使用中是什么樣的？讓我們看幾個真實案例。

Julius AI（一家 2025 年 7 月完成 1000 萬美元種子輪融資、已服務超 200 萬用戶的數據分析平臺）的企業用戶 AthenaHQ 報告了一個極端的場景 (Julius, 2025)。工程師原本手寫 SQL 查詢來分析超過 700 萬行的產品使用數據，每次分析耗時 8 小時以上。改用 Julius AI 后，他們用語義模糊的自然語言提問“Show me feature usage trends”，分析時間反而降到不到 1 小時。這句話看起來很短，但系統要真正執行它，至少需要完成 4 層轉義：

語義映射——系統要判斷“feature usage”對應數據庫中的哪些表和字段；

意圖推斷——系統要理解“trends”通常意味著按時間維度聚合，比如按天、周或月統計；

指標選擇——系統要選擇合適的度量，例如使用次數、獨立用戶數或留存變化；

執行與呈現——最后才會生成 SQL 查詢、執行計算，并把結果轉換成趨勢圖。

換句話說，這里被自動化的不是單條 SQL，而是從業務語言到數據操作的整個映射過程。用一個類比來理解這個變化：700 萬行數據大致相當于把全城每一個出租車乘客的上下車地點、時間和金額逐條記錄下來。傳統做法要求工程師用 SQL——一種專門查詢數據庫的編程語言——手寫 300 到 500 行指令，逐條指定“先篩選哪些列、按什么條件過濾、怎樣分組匯總”。例如，僅僅是“展示各功能模塊的月度使用趨勢”，就需要這樣的查詢：

ORDER  BY month DESC, usage_count DESC;

這只是最簡用例。復雜分析常常需要 20 到 30 個類似下圖的查詢串聯，加上中間結果表、索引優化和錯誤處理。

圖：模擬數據庫客戶端查詢結果界面（如 DBeaver / pgAdmin 風格）

在 Reddit 的 r/ClaudeAI 社區，有用戶分享了用 Claude Artifacts 制作交互式金融儀表盤的經驗：上傳一份電子表格形式的財務數據，描述想要的圖表類型和篩選功能，Claude 直接生成了一個包含可交互圖表、對比分析和實時預測的儀表盤應用——同樣全程無代碼 (Reddit, 2024)。用傳統方式搭建這樣一個儀表盤，通常需要前端開發者編寫界面組件、實現圖表交互邏輯，后端工程師搭建數據接口——至少涉及 3 種編程語言和 2 到 3 周工時。例如，僅一個可篩選的折線圖組件就需要這樣的代碼：

}

這還只是 1 個組件。一個完整的儀表盤通常包含 5 到 15 個這樣的組件，加上數據接口、路由和狀態管理。

圖：模擬前端儀表盤應用風格

而這位用戶只用了幾句自然語言描述。

這些案例的共同特征是：用戶描述需求，系統給出結果，中間過程不可見。討論中提到的 3 個問題——精度與控制、驗證困難、能力退化——在這些真實案例中都有體現，只是不同場景下嚴重程度不同。

回到楔子里那個凌晨一點的問題：“如果它錯了，我該從哪里開始懷疑？”這個問題的答案，取決于你是否知道自己在懷疑什么。Vibe modeling 時，你不需要理解底層原理才能開始使用，但了解原理會讓你知道該從哪里開始懷疑。門檻降低了，你需要學會在低門檻上保持警覺——開始懷疑就是開始學習。

建模從手工時代進入代碼時代，又從代碼時代進入對話時代。每一次躍遷讓更多人參與、更多場景被覆蓋，也讓每次決策背后的假設變得更加隱蔽。Vibe modeling 的未來不在于它能取代什么，而在于它能讓什么成為可能。fast.ai 創始人 Jeremy Howard 的警告或許值得在按下回車之前想一想：“現在全面押注 AI Agent 的人，正在親手保證自己的過時。如果你把所有思考都外包給計算機，你就停止了提升、學習和變得更稱職。” 但反過來說，如果因為害怕失去思考能力而拒絕使用新工具，那也是一種放棄。學會使用，同時學會懷疑——這大概就是 vibe modeling 101 的全部要義。

參考文獻

Anthropic. (2024). Claude Artifacts.

Chase, H. (2022). LangChain: Building applications with LLMs through composability.

Codeium. (2024). Windsurf: The AI-powered code editor.

Cursor. (2026). Funding Updates & Valuation.

Anthropic. (2025). How AI Is Transforming Work at Anthropic.

Faye, L. (2026). Agentic Coding is a Trap.

Shen, J. H., & Tamkin, A. (2026). How AI Assistance Impacts the Formation of Coding Skills.

Willison, S. (2026). How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt.

GitHub Copilot Statistics (2026).

Julius AI. (2025). Case Study: AthenaHQ.

Karpathy, A. (2025). There's a new kind of coding I call “vibe coding”. X.

OpenAI. (2023). ChatGPT plugins: Code interpreter.

Reddit r/ClaudeAI. (2024). Interactive Financial Forecasting Dashboard.

Replit. (2026). AI Statistics & Growth.

Stack Overflow Developer Survey 2025 - AI Section.

Zillow. (2021). Zillow Offers shutdown: algorithm-driven iBuying losses exceed $500M.

Air Canada. (2024). Civil Resolution Tribunal of British Columbia: Moffatt v. Air Canada.

參考文獻可上下滑動查看

報名讀書會：「Vibe Modeling」

集智俱樂部聯合同濟大學長聘副教授陳小楊和北京林業大學副教授李周園共同發起，將在集體實踐中探索 vibe modeling 在不同領域的通用模式與特殊需求，沉淀可復用的提示策略、評估方法與工作流，為這一范式搭建早期社區基礎，助力 AI 賦能的跨學科研究與人才培養落地。

讀書會自2026年5月17日起，每周日下午14:00-16:00線上開展，持續10周，包含主講分享與討論交流，并提供會后視頻回放，誠邀相關領域研究者及跨學科興趣者參與。

詳情請見：

1.

2.

3.

4.

5.

6.

7.

8.