传统做法要求你亲手搭建黑箱内部的每一条管道：数据清洗、特征工程、模型选择、参数调优、结果可视化，任何一个环节出错都要回头排查。
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 的下一个行为）。
这个处理过程对构建者来说是可透明的，但对使用者来说是一个黑箱。
建模的核心价值在于抽象——把复杂性封装在黑箱里，让使用者只关心输入和输出。
不一定要理解黑箱内部的全部细节，就像气象学家不需要手动计算每一层大气的热力学过程，只需要输入温度、湿度、风速（矢量），模型就能给出降水概率。
本文讨论的“建模”泛指从原始数据到可报告结果的完整流程，而不局限于统计建模这一步。
传统做法的一个隐含假设是你必须亲手搭建这个黑箱。以数据分析为例，你有一份 CSV 表格，目标是生成包含趋势图和统计摘要的报告。
传统工作流可以分 4 步：用 Python 读取文件、处理缺失值和异常值；选择统计方法（线性回归、时间序列、聚类）；编写绘图代码；将结果整合为报告格式。
每一步都需要专业知识，每一步都可能出错，而且错误在最后一步才暴露是最令人头大的。
痛点不在于建模本身，而在于搭建箱子的过程。Vibe Coding2025 年 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 ModelingVibe modeling 显然指向的是“如果代码的编写与执行之间的中间层进一步被自动化，会发生什么？”回到 PPT 制作的例子。
传统（指coding ( ͡• ͜ʖ ͡• )）流程可以是你写 Python 脚本，调用 python-pptx 库——
一个专门用代码操作 PPT 文件的工具包——手动设置每一页幻灯片的布局、文字、图表，运行脚本，得到 PPT 文件。
你需要写这样的代码：from pptx import Presentationfrom pptx.chart.data import CategoryChartDataprs = Presentation() # 创建空白演示文稿slide = prs.slides.add_slide(prs.slide_layouts[5]) # 添加第 1 页# 添加折线图：Q1 月度销售额chart_data = CategoryChartData()chart_data.categories = ['1月', '2月', '3月']chart_data.add_series('销售额', (120, 150, 180))slide.shapes.add_chart( 1, chart_data, left=100, top=100, width=500, height=350)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 不是要取代传统建模，而是在“会建模”和“不做建模”之间开辟了一个新的中间地带。
市场分析师、产品经理、记者、学生——这些本来不会写代码的人，现在可以通过自然语言描述需求来获得建模能力。
这是一种建模能力的扩展，代价是精度和控制权。案例：真实场景中的 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 行指令，逐条指定“先筛选哪些列、按什么条件过滤、怎样分组汇总”。
例如，仅仅是“展示各功能模块的月度使用趋势”，就需要这样的查询：SELECT feature_name, DATE_TRUNC('month', event_time) AS month, COUNT(*) AS usage_count, COUNT(DISTINCT user_id) AS unique_usersFROM product_usageWHERE event_time BETWEEN '2025-01-01' AND '2025-06-30'GROUP BY feature_name, DATE_TRUNC('month', event_time)ORDER BY month DESC, usage_count DESC;这只是最简用例。
复杂分析常常需要 20 到 30 个类似下图的查询串联，加上中间结果表、索引优化和错误处理。
图：模拟数据库客户端查询结果界面（如 DBeaver / pgAdmin 风格）在 Reddit 的 r/ClaudeAI 社区，有用户分享了用 Claude Artifacts 制作交互式金融仪表盘的经验：上传一份电子表格形式的财务数据，描述想要的图表类型和筛选功能，Claude 直接生成了一个包含可交互图表、对比分析和实时预测的仪表盘应用——
同样全程无代码 (Reddit, 2024)。用传统方式搭建这样一个仪表盘，通常需要前端开发者编写界面组件、实现图表交互逻辑，后端工程师搭建数据接口——
至少涉及 3 种编程语言和 2 到 3 周工时。例如，仅一个可筛选的折线图组件就需要这样的代码：import { LineChart, Line, XAxis, YAxis, Tooltip } from 'recharts';function Dashboard({ data, selectedMetric }) { const filtered = data.filter(d => d.metric === selectedMetric); return (
一个完整的仪表盘通常包含 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」读书会，将在集体实践中探索 vibe modeling 在不同领域的通用模式与特殊需求，沉淀可复用的提示策略、评估方法与工作流，为这一范式搭建早期社区基础，助力 AI 赋能的跨学科研究与人才培养落地。
读书会自2026年5月17日起，每周日下午14:00-16:00线上开展，持续10周，包含主讲分享与讨论交流，并提供会后视频回放，诚邀相关领域研究者及跨学科兴趣者参与。
详情请见：「Vibe Modeling：从技术框架到跨学科应用」读书会#原创推荐阅读1. 自然语言驱动数学建模技术丨Vibe Modeling读书会第一期2. 招募发起人：一场关于“Vibe Modeling”的读书会3. 人工智能与数学前沿综述：如何借助 AI 发现数学规律？
4. 人工智能与数学读书会启动：AI for Math，Math for AI5. 诚招系统科学/AI/物理背景的内容创作者6. 集智学园精品课程免费开放，解锁系统科学与 AI 新世界7. 高考分数只是张入场券，你的科研冒险在这里启航！
8. 加入集智字幕组：成为复杂科学知识社区的“织网人”点击“阅读原文”，报名读书会