我越来越觉得，今天讨论 Vibe Coding，必须先给它降一点温。
不是因为它不重要。
恰恰相反，是因为它太重要了。
如果我们把 Vibe Coding 理解成“给 AI 一句话，一个完整产品就完美出来了”，那大家很快会低估真实产品的复杂度，也会低估 Data Infra 的价值。
但如果我们把 Vibe Coding 理解成“把原型、场景表达、界面迭代和业务流程产品化的速度大幅提高”，那它会变成一件非常有生产力的事。
这两种理解，最后会走向完全不同的结果。
前一种理解，会让人觉得底座不重要，工程不重要，安全不重要，用户反馈不重要。反正 AI 都能写。
后一种理解，会让人更清楚地看到：Vibe Coding 缩短的是从想法到原型的距离，不是从原型到稳定产品的全部距离。
真实产品不是一句 prompt 生成的。
真实产品是用户不断反馈、工程师不断判断、系统不断修复、场景不断收敛，按月、按年慢慢长出来的。
所以我想把上一篇关于 Data Infra + Vibe Coding 的文章再往前推一步。
Data Infra 的价值，不只是“让 Vibe Coding 更快”。
更准确地说：
Data Infra 让 Vibe Coding 不必从最重、最容易出事故、最需要长期打磨的底层复杂度开始。
这样，懂行业、懂用户、懂交付 Know-how 的人，才能把精力放在真正有差异化的地方。
第一个误解：给一句话，产品就完成了
今天很多人看到 Lovable、AppSparks、Cursor、Codex、Claude Code 之后，都会有一种兴奋感：
原来我不需要完整研发团队，也能做应用了。
这个判断是对的。
但它很容易再往前滑一步，变成另一个判断：
既然我可以让 AI 写代码，那我是不是可以从零把完整产品都自己做掉？
这个判断就危险了。
因为一个产品的第一版页面，和一个可长期服务真实用户的产品，中间隔着很多东西。
比如你要做一个 Excel 分析工具。
第一版很快。
上传文件。
输入问题。
点击分析。
展示结果。
导出 PDF。
这对今天的 Code Agent 来说确实不难。
但真实用户一进来，问题马上会变得不一样：
- Excel 有多个 sheet，应该分析哪个？
- 字段名是中文、英文、缩写混在一起，怎么理解？
- 文件太大，上传和解析失败怎么办？
- 用户问的问题太宽，系统要不要追问？
- 模型生成的图表不合适，能不能重新选择？
- 分析结论错了，用户怎么追溯依据？
- 用户刷新页面，任务还在不在？
- 生成 PDF 时中文换行、分页、表格溢出怎么办？
- 企业用户的数据能不能隔离？
- 一次分析到底花了多少模型调用成本？
- 五百个人同时提交任务，队列和并发怎么处理？
这些问题不是“再写一个按钮”就能解决的。
它们是产品进入真实世界之后一定会遇到的边界。
Vibe Coding 可以帮你更快修。
但它不能让这些边界不出现。
更不能替你提前经历真实用户反馈。
产品不是提示词生成物，而是反馈生成物
一个稳定产品，通常不是第一句 prompt 写出来的。
它更像是这样长出来的：
第一版能跑。
用户开始试。
有人上传了奇怪格式的文件。
有人点了三次提交。
有人中途刷新浏览器。
有人把报告发给客户，发现 PDF 图表丢了。
有人说“这个结论没有来源，我不敢用”。
有人说“这段我已经手动改过了，AI 为什么又覆盖回去了”。
有人说“我们公司数据不能出域，能不能私有化”。
工程师再根据这些问题去补任务状态、补权限隔离、补导出链路、补来源结构、补重试机制、补日志、补监控、补成本控制。
这个过程不会因为 AI 写代码变快而消失。
它只是变成了另一种节奏。
过去是：
用户反馈一个问题，工程师排期，写代码，测试，上线。
现在可能是：
用户反馈一个问题，工程师判断根因，让 Code Agent 改，自己验收，再上线。
中间的编码时间确实短了。
但“用户先用、问题暴露、工程师判断、系统沉淀”这条链路并没有被取消。
这也是为什么很多产品不是按天成熟，而是按月、按年成熟。
稳定性来自时间。
来自用户不断把系统打到边界。
来自工程师一次次把这些边界变成系统能力。
来自团队慢慢知道：哪些问题要放在场景层解决，哪些问题必须沉到底座。
第二个误解：Vibe Coding 没有能力上限
Vibe Coding 很强，但它有明显上限。
一个简单例子：
今天你让 AI copy 一个 macOS 出来，不现实。
不是因为 AI 不聪明。
而是因为 macOS 不是一组页面。
它背后是内核、驱动、文件系统、权限模型、窗口系统、图形栈、安全沙箱、硬件适配、开发者生态、兼容性、分发机制、无障碍、国际化、性能调度、崩溃恢复，以及几十年用户习惯共同打磨出来的结果。
很多东西 AI 看不到。
很多东西没有完整公开。
更多东西不是“看到了代码就能复制”，而是要经历海量用户、海量硬件、海量应用、海量异常，一年一年磨出来。
这类复杂系统，不能靠一句 prompt 快进。
所以今天主流 Vibe Coding 出来的产品，更多是在解决边界相对清楚的小业务问题：
- 内部工具；
- 数据分析小应用；
- 报表和报告工作台；
- 文件处理流程；
- 轻量 CRM；
- 垂直助手；
- 原型验证；
- 小型业务系统。
这不是贬低 Vibe Coding。
恰恰相反，这是在准确理解它的威力。
它非常适合把一个具体场景快速产品化。
它不适合让每个人幻想自己一天复制一个复杂操作系统、数据库、浏览器、云平台或企业级数据基础设施。
即使是 Codex、Cursor、Claude Code 这些产品，我相信它们内部也一定大量使用 AI 辅助开发。
但它们绝不是“一句话生成出来”的。
它们是公司、团队、工程师、研究人员、设计师、用户反馈、模型能力、产品判断和长期工程投入共同推出来的结果。
周期仍然是按年来算的。
复杂度仍然不小。
成本仍然真实存在。
Vibe Coding 改变了生产方式，但没有取消时间、成本和工程经验。
第三个误解：AI 写代码，所以不再需要工程判断
这个误解更隐蔽。
因为 AI 确实能写出大量代码。
它能写页面、写接口、写数据库表、写任务队列、写测试、写部署脚本。
但写出来不等于能上线。
上线不等于能承压。
承压不等于能长期维护。
一个真实例子是并发问题。
一个应用一个人用的时候很好。
页面流畅，功能完整，数据库也没问题。
但一旦真实用户多起来，数据库超时、锁等待、死锁、连接池耗尽、长任务堆积，全都会冒出来。
我之前在 winclaw.cn 上就踩过类似坑。
第一版做得很快，一个人用的时候也很顺。页面能打开，功能能跑，流程看起来没问题。
但上线后，更多用户进来，系统开始出现大量数据库超时，服务被堵住。
一开始看起来像普通性能问题，让 AI 改几版也都“有道理”：加超时、改查询、优化逻辑、调整更新方式。
但每次上线，问题还在。
最后还是要靠工程经验一点点拆，才发现核心是一段 AI 写出来的 SQL Update 逻辑在并发下产生了死锁。
这类问题非常典型。
它不是“AI 不会写代码”。
它是“真实系统里的问题，往往先表现为模糊症状，然后才被工程师定位成明确根因”。
AI 可以根据你的指令改 SQL、加超时、改重试、优化查询。
但它首先需要有人判断：
问题到底在哪里？
是慢 SQL？
是事务范围太大？
是并发 update 死锁？
是任务队列没有限流？
是前端重复提交？
是某个长任务把连接占住？
如果人不知道问题在哪里，AI 可能会非常勤奋地在错误方向上改很多版。
这不是 Vibe Coding 的问题。
这是所有复杂工程系统都会遇到的问题。
AI 提高的是执行效率。
工程师的价值，会越来越集中到判断、拆解、验收和沉淀。
所以不要以为 Vibe Coding 之后就不需要工程师。
更准确地说，Vibe Coding 之后，更需要能驾驭 AI 的工程师：
- 能把模糊问题拆成可执行任务；
- 能给 AI 足够上下文和边界；
- 能看懂 diff；
- 能跑测试；
- 能看日志和监控；
- 能判断一个修复是不是只修了表面；
- 能把重复问题沉淀成系统能力。
没有这层判断，Vibe Coding 很容易变成“生成得很快，返工也很快”。
为什么是 Data Infra
到这里还要回答一个更底层的问题：
为什么是 Data Infra？
为什么不是普通 Infra？
为什么不是单纯的 App Builder？
因为软件真正的价值，不是“有一个界面”。
软件真正的价值，是帮助人理解世界、做决策、采取行动。
而今天绝大多数高价值决策，背后都是数据问题。
运营要看用户、漏斗、转化、留存、渠道、内容和成本。
营收要看订单、合同、回款、客户、毛利、销售周期和续费。
投研要看财报、估值、行业周期、新闻、政策、竞争格局和风险敞口。
宏观经济要看消费、投资、进出口、通胀、就业、财政、货币和产业结构。
企业管理要看组织、人效、客户分层、资源配置和经营动作。
这些都不是一个漂亮页面能解决的。
页面只是入口。
真正决定产品价值的是：它能不能连接数据，理解数据，从不同视角组织数据，并把数据变成决策依据。
没有数据的软件，很容易变成空洞的软件。
它可能很好看，交互也流畅，按钮也都在正确的位置。
但它不理解业务，不理解现实，不理解变化，也不理解结果。
它只是一个壳。
Data Infra 的价值就在这里。
它让 Vibe Coding 出来的应用不只是“有界面”，而是能接入真实世界的数字脉搏。
数据是数字世界的事实层。
没有数据，AI 更容易生成看起来合理的文本和流程。
有了数据，AI 才能基于事实做分析、对比、归因、预测和复盘。
这也是为什么 Data + Vibe Coding 是当前最大、最顺、也最有逻辑的组合。
未来一定还会出现其他组合。
比如 Industrial Infra + Vibe Coding，让 AI 应用进入工业流程。
比如 Robotics Infra + Vibe Coding，让 AI 应用进入机器人和物理世界。
比如 Supply Chain Infra + Vibe Coding，让 AI 应用进入采购、物流、库存和履约。
但在今天，最容易被软件产品化、最有广泛需求、最能形成闭环的，仍然是数据场景。
因为数据已经在数字世界里存在。
企业每天都在产生数据。
行业每天都在释放数据。
宏观经济每天都在变化数据。
用户行为每天都在沉淀数据。
Vibe Coding 解决“应用怎么快速长出来”。
Data Infra 解决“应用如何接入真实世界”。
前者让软件长出身体。
后者让软件接上神经。
这就是 Data Infra 的位置
如果不先纠正这些误解，Data Infra 的价值很难被看见。
因为很多人会觉得：
既然 Vibe Coding 这么强，我为什么还需要底座？
我自己写不就好了？
问题是，你当然可以自己写。
但你要清楚自己在写哪一层。
如果你写的是场景层，Vibe Coding 非常有杠杆。
比如：
- 投研报告需要哪些章节；
- 结论要先给还是后给；
- 哪些来源可信；
- 哪些地方必须给反例；
- 哪些风险必须前置；
- 导出给投资委员会的版本怎么压缩；
- 面向客户的版本哪些措辞要更谨慎；
- 右侧快捷按钮应该放“补来源”“补反例”“重写投资结论”还是“一页纸摘要”。
这些是 Know-how。
这些很适合让懂行业的人直接用 Vibe Coding 快速迭代。
但如果你写的是底座层，事情就完全不同。
底座层包括：
- 数据库连接；
- 文件上传和解析；
- PDF、Word、Markdown、Excel 读取；
- 知识库和 RAG；
- 多源数据接入；
- 浏览器和搜索；
- 长任务、队列和事件流；
- 任务工作区；
- 来源和证据结构；
- 图表生成；
- PDF/Word 导出；
- 用户权限和多租户隔离；
- API Key 管理；
- 成本控制；
- 日志、监控、失败恢复；
- 私有化和安全边界。
这些能力不是一个垂直 App 的装饰。
它们是真实产品的地基。
Data Infra 的意义，就是把这些重、慢、危险、重复的能力集中沉淀。
这样每个垂直应用就不必重新交同一笔学费。
用投研报告看这件事
投研报告是一个很好的例子。
表面看，它只是“让 AI 写一份报告”。
但真正的投研报告绝对不是一段漂亮文字。
它需要资料。
需要来源。
需要证据优先级。
需要反例。
需要估值口径。
需要同业对比。
需要风险提示。
需要把“我觉得”变成“我为什么这样判断”。
一个不懂投研的人做投研报告应用，很容易做成：
搜索资料。
总结信息。
生成 Markdown。
导出 PDF。
看起来像报告。
但它可能缺少真正的投研 Know-how：
- 哪些来源是一手信息，哪些只是二手评论；
- 财报、公告、电话会、研报、新闻和社媒信息权重不同；
- 同业估值不能跨行业简单横比；
- 市场规模估算必须交代假设；
- 投资结论不能只写机会，还要写风险和反例；
- 关键指标要说明口径；
- 对不确定事件要给置信度，而不是绝对判断；
- 给投资委员会看的摘要和给研究员看的过程稿不是同一种东西。
这就是 Know-how 的差距。
通用模型能帮你写第一版。
Vibe Coding 能帮你把界面做出来。
但一个投研报告产品有没有生产力，取决于它是否把这些判断变成了工作流。
它不是一个简单聊天框。
从页面结构上看，它已经是一个报告工作台：
- 工作区和项目文档；
- 内部数据源；
- 报告标题、主题和写作目标；
- 批量上传 PDF / Word / Markdown 资料；
- 资料知识库；
- 可编辑正文；
- 批注和再次修订；
- 来源追溯；
- Markdown、来源 JSON、图表数据、PDF 和 Word 等产物。
这里有两个已经跑出来的在线示例：
这张图展示的是中国经济研究报告工作台。
它说明一件事：真正的报告产品不是“生成一段话”，而是围绕资料、主题、正文、来源、结论和交付物组织一个持续工作区。
再看 Code Agent 市场研究报告。
这个例子更接近投资者定向研报：市场空间、收入验证、估值变化、竞争格局、技术趋势、风险挑战和投资观察点。
你会发现，两个报告主题完全不同。
一个是宏观经济。
一个是 Code Agent 市场。
但底层工作流是同一套：
收集资料 -> 组织知识 -> 分析判断 -> 绑定来源 -> 生成报告 -> 继续修订 -> 导出交付。
这就是 Data Infra 的价值。
它不是替代投研 Know-how。
它是让投研 Know-how 能更快进入产品。
直接 Vibe Coding 一个投研报告工具，会卡在哪里
假设今天一个人说：
“帮我做一个投研报告工具。用户输入股票代码，上传资料，AI 自动生成报告，最后导出 PDF。”
第一版大概率可以很快出来。
但第二周，真实问题就会出现：
上传的 PDF 里有扫描件，解析不出来怎么办？
一份年报 300 页，哪些部分最重要？
用户上传了三份券商研报，里面观点冲突，系统要怎么处理？
网页来源失效了，报告里的引用怎么办？
财报数据和新闻数据口径不一致，系统要不要提示？
用户手动改过投资结论，下一轮 AI 修改时能不能保留？
分析过程中生成了图表，导出 Word 时还能不能看到？
报告需要给客户，来源清单能不能附在末尾？
用户问“这个判断的证据在哪里”，系统能不能跳回原文？
多个人同时写不同公司，资料、任务、产物会不会串？
这些问题不是 prompt 长一点就能解决。
它们需要系统能力。
更重要的是，它们会反复出现在不同的垂直应用里。
投研报告会遇到。
咨询报告会遇到。
政策研究会遇到。
运营复盘会遇到。
客户研究会遇到。
如果每个 App 都从零补一遍文件、知识库、来源、批注、导出、权限、任务恢复，团队看起来一直在快速开发，实际是在重复支付同一类基础设施成本。
Data Infra 要解决的，就是这件事。
Data Infra 不是让应用更封闭，而是让应用更开放
这里还有一个容易误解的地方。
有人会担心：底座越重要，上层应用会不会越被控制？
我反而觉得，好的 Data Infra 应该让上层更开放。
因为它承接的是通用复杂度，不是替代行业创造力。
底座稳定以后，上层可以长出更多形态：
- 标准产品；
- 垂直 App；
- 企业内部系统；
- 客户交付入口；
- 桌面端；
- 私有化部署；
- 给 Codex、Cursor、Claude Code 调用的 Command Tools。
同一个 Data Infra，可以支持不同入口。
一个投研团队可以做自己的研究报告助手。
一个咨询团队可以做自己的交付报告助手。
一个运营团队可以做自己的增长复盘助手。
一个销售团队可以做自己的客户研究助手。
一个政企客户可以把数据、模型、权限和产物都留在自己域内。
这不是封闭。
这是分工。
底座负责稳定、通用、安全、可复用。
场景应用负责具体、灵活、贴近用户、表达 Know-how。
两者结合，才是 Vibe Coding 真正有杠杆的地方。
Vibe Coding 的结果，受限于人的认知和视野
还有一个更根本的问题：
Vibe Coding 会放大人，但不会替代人的认知。
一个不懂投研的人，用 AI 做投研产品，很容易做成“搜索 + 总结 + 报告”。
一个懂投研的人，会把产品做成证据优先级、估值口径、反例、风险、同业对比和投资委员会交付流程。
一个不懂招聘的人，可能会做成“上传简历，AI 打分”。
一个懂招聘的人，会关心项目经历真实性、技能证据、岗位画像、薪资区间、面试追问、风险信号和团队匹配。
一个不懂高考志愿的人，可能只做“输入分数推荐学校”。
一个懂高考志愿的人，会关心位次、批次、专业组、城市偏好、家庭预算、就业预期、冲稳保梯度和历史录取波动。
AI 可以把你的想法做快。
但如果你的想法本身浅，产品也会浅。
如果你的视野只到页面，AI 会帮你做页面。
如果你的视野到工作流，AI 会帮你做工作流。
如果你的视野到底层系统，你才会知道哪些东西不应该在每个小应用里重复造。
这就是为什么 Know-how 重要。
未来大家都能 Vibe Coding 之后，真正的差距不会是“谁会写一个按钮”。
差距会变成：
谁更懂用户？
谁更懂行业？
谁更懂交付？
谁更懂风险？
谁更懂哪些东西该快，哪些东西不能快？
不要因为 Vibe Coding 了，就闭门造车
Vibe Coding 还有一个副作用：
它容易让人更封闭。
过去你不会写代码，所以你必须找工程师，必须和业务方聊，必须和用户对齐，必须找懂行的人合作。
现在你可以自己生成代码，就容易觉得自己一个人够了。
这很危险。
Vibe Coding 不应该让我们闭门造车。
它应该让协作更快。
因为 Code Agent 解决的是实现速度，不是方向正确。
它不能替你拥有用户。
不能替你理解行业。
不能替你建立数据来源。
不能替你承担安全责任。
不能替你判断监管边界。
不能替你完成市场里的信任建立。
越是能快速生成，越要更快拿给真实用户看。
越是能自己改，越要让懂业务的人、懂数据的人、懂安全的人、懂运营的人参与进来。
越是有 Data Infra，越要把应用放进开放生态里，而不是把一切关在自己的小工作区里。
一个更现实的 Vibe Coding 工作流应该是：
- 用 Data Infra 承接通用复杂度；
- 用 Code Agent 快速做场景应用；
- 用行业 Know-how 定义流程和验收标准；
- 用真实用户反馈校验方向；
- 用工程师经验把反复出现的问题沉淀到底座；
- 用开放接口、Command Tools 和私有化形态扩展到更多场景。
这比“我一个人从零做完所有东西”更现实，也更有生命力。
最后：不是反 Vibe Coding，而是把它放对位置
我不是在反对 Vibe Coding。
相反，我认为它会成为未来很多人的基础能力。
就像今天很多人会写文档、做表格、做 PPT 一样，未来很多人都会用 AI 做小工具、改应用、搭流程。
但会做 PPT，不等于会做战略。
会写 Excel，不等于懂财务。
会写代码，不等于懂产品。
会 Vibe Coding，也不等于能做出有生产力的应用。
真正的问题会变成：
你有没有值得产品化的 Know-how？
你有没有足够稳定的底座承接真实用户？
你有没有把用户反馈转化成系统能力的耐心？
你有没有开放地连接用户、数据、工程和生态？
你有没有承认成本、时间和复杂度仍然存在？
如果没有底座，Vibe Coding 容易停在 demo。
如果没有 Know-how，Vibe Coding 容易变成同质化页面。
如果没有真实用户反馈，Vibe Coding 很难长成稳定产品。
如果没有开放协作，Vibe Coding 容易变成一个人的闭门造车。
所以，下一阶段更准确的判断应该是：
Vibe Coding 缩短原型距离，Data Infra 承接真实复杂度，Know-how 决定产品深度，用户反馈和工程经验决定产品寿命。
Data Infra 的价值，也正是在这里。
它不是给 Vibe Coding 泼冷水。
它是让 Vibe Coding 不必每次都从泥地里起步。
当底座把数据、知识、任务、来源、文件、图表、报告、权限、安全、成本和交付这些重活接住，懂行业的人才更容易把自己的判断、流程和方法论做成产品。
这才是我真正看好的方向：
不是每个人都从零造车。
而是更多懂路的人，可以站在成熟底盘上，更快做出适合自己场景的车。