2026-05-22 14:35
扫码打开虎嗅APP
本文来自微信公众号： 集智俱乐部 ，作者：任筱芃
建模——这个听起来高深的词，本质上只是给一个黑箱喂入输入、拿到输出。传统做法要求你亲手搭建黑箱内部的每一条管道：数据清洗、特征工程、模型选择、参数调优、结果可视化，任何一个环节出错都要回头排查。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读取文件、处理缺失值和异常值；选择统计方法（线性回归、时间序列、聚类）；编写绘图代码；将结果整合为报告格式。每一步都需要专业知识，每一步都可能出错，而且错误在最后一步才暴露是最令人头大的。
痛点不在于建模本身，而在于搭建箱子的过程。
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显然指向的是“如果代码的编写与执行之间的中间层进一步被自动化，会发生什么？”
回到PPT制作的例子。传统（指coding(͡•͜ʖ͡•)）流程可以是你写Python脚本，调用python-pptx库——一个专门用代码操作PPT文件的工具包——手动设置每一页幻灯片的布局、文字、图表，运行脚本，得到PPT文件。你需要写这样的代码：
frompptximportPresentationfrompptx.chart.dataimportCategoryChartDataprs=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时，有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不是要取代传统建模，而是在“会建模”和“不做建模”之间开辟了一个新的中间地带。市场分析师、产品经理、记者、学生——这些本来不会写代码的人，现在可以通过自然语言描述需求来获得建模能力。这是一种建模能力的扩展，代价是精度和控制权。
以上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行指令，逐条指定“先筛选哪些列、按什么条件过滤、怎样分组汇总”。例如，仅仅是“展示各功能模块的月度使用趋势”，就需要这样的查询：
SELECTfeature_name,DATE_TRUNC('month',event_time)ASmonth,COUNT(*)ASusage_count,COUNT(DISTINCTuser_id)ASunique_usersFROM product_usageWHERE event_timeBETWEEN'2025-01-01'AND'2025-06-30'GROUPBYfeature_name,DATE_TRUNC('month',event_time)ORDERBYmonthDESC,usage_countDESC;
这只是最简用例。复杂分析常常需要20到30个类似下图的查询串联，加上中间结果表、索引优化和错误处理。
图：模拟数据库客户端查询结果界面（如DBeaver/pgAdmin风格）
在Reddit的r/ClaudeAI社区，有用户分享了用Claude Artifacts制作交互式金融仪表盘的经验：上传一份电子表格形式的财务数据，描述想要的图表类型和筛选功能，Claude直接生成了一个包含可交互图表、对比分析和实时预测的仪表盘应用——同样全程无代码(Reddit,2024)。用传统方式搭建这样一个仪表盘，通常需要前端开发者编写界面组件、实现图表交互逻辑，后端工程师搭建数据接口——至少涉及3种编程语言和2到3周工时。例如，仅一个可筛选的折线图组件就需要这样的代码：
