这半年，“vibe coding”这个词被讲得太多了。

有人把它当成一种解放：不用细想架构，不用写太多代码，给 AI 说清楚想法，屏幕上很快就能跑起来一个东西。也有人把它当成一种危险：代码看着能跑，边界全是洞，过两周没人敢改。

我觉得这两个判断都对，只是说的不是同一个阶段。

如果把 vibe coding 理解成“我完全不看代码，AI 写什么就是什么”，那它确实很危险。如果把它理解成“我用 AI 快速把想法压成一个可操作的产品实验”，那它是非常有价值的。关键差别不在于用了哪个模型，也不在于编辑器有多炫，而在于：你有没有把真实数据、真实用户、真实交付链路放进来。

本文用一个具体案例聊这个问题：假设我们要做一个“周末户外活动决策助手”，它不从金融数据出发，而是用 QVeris 里天气、空气质量、公共数据这类能力，帮用户判断某个城市周末适不适合跑步、骑行、露营或带孩子出门。

这不是一个宏大的产品，但它很适合讨论 vibe coding。因为它刚好卡在几个真实问题上：数据怎么来，AI 生成的页面能不能信，原型怎么变成产品，研发同事怎么接手，质量又该怎么衡量。

先把词说清楚

vibe coding 最早流行起来时，强调的是一种很松弛的开发方式：人用自然语言描述意图，AI 负责生成大量代码，人更多是在试用、反馈、调整方向。后来这个词越传越广，含义也变得混乱。

我更愿意把它拆成三层：

第一层是“生成代码”。这只是最表面的部分。让 AI 写一个页面、一个接口、一个脚本，现在已经不稀奇。

第二层是“生成可运行的产品片段”。这比生成代码更进一步，需要能连上真实数据，能跑完整流程，能让用户点几下就感受到价值。

第三层是“生成可以被工程系统接住的资产”。它不一定马上达到生产质量，但必须有清楚的输入输出、数据契约、测试样例、失败边界、交接文档和下一步改造路径。

多数失败的 vibe coding 卡在第二层到第三层之间。原型做得很快，演示也好看，但一旦要接入现有产品、接给研发同事、算成本、做权限、处理异常，它就露馅了。

所以更好的 vibe coding，不是更会写 prompt，而是更早地把产品化条件放进 prompt 里。

为什么案例一定要有真实数据

没有真实数据的 vibe coding，很容易变成 UI 练习。

比如让 AI 做一个“天气助手”，它可以很快生成一个漂亮页面：晴天图标、温度卡片、折线图、推荐语。但如果数据都是 mock 的，这个页面没有产品判断力。真正难的地方不是画卡片，而是：

• 天气预报的时间粒度是什么？
• 空气质量和天气冲突时怎么排序？
• 城市、经纬度、行政区怎么映射？
• 数据缺失时是降级、提示，还是不展示？
• 推荐语应该保守还是激进？
• 用户会不会因为一句“适合骑行”做出真实行动？

这些问题只有接上真实数据才会出现。

QVeris 的价值正在这里。它不是只提供金融数据。公开能力分类里能看到，除了金融相关能力，还有 Science, Health & Public Data、Weather & Environment、Media & Creative、IoT & Industry 等方向。以公开分类数据为例，Science, Health & Public Data 下覆盖了公共统计、开放政府数据、天气环境、生命科学等子类；Weather & Environment 里能看到天气预报、空气质量、气象参考数据、空间天气、地球观测等方向。这些数据很适合做非金融场景的 vibe coding。

也就是说，真实案例可以不是“股票分析助手”。它也可以是：

• 城市户外活动建议
• 社区空气质量提醒
• 公共数据趋势看板
• 医学文献或药品信息整理
• IoT 设备状态观察
• 内容创作素材工作台

这些场景的共同点是：数据比页面重要，判断比动效重要，异常处理比演示截图重要。

一个小案例：周末户外活动决策助手

先设一个很具体的产品。

用户输入城市、日期、活动类型，比如“北京，周六上午，带孩子去公园”。系统返回一个建议：

• 是否适合出门
• 主要风险是什么，比如降雨、大风、高温、空气质量
• 建议时间窗口
• 备选活动
• 数据来源和更新时间
• 不确定性说明

用 vibe coding 做第一版，最容易写成这样：

帮我做一个户外活动推荐网站。
用户输入城市和活动类型，展示天气、空气质量和推荐结论。
使用 React，页面要好看。

这类 prompt 能得到一个页面，但很难得到产品。

更好的 prompt 应该从数据和决策开始：

我们要做一个“周末户外活动决策助手”的最小可用原型。

目标用户：城市家庭、跑步和骑行爱好者。
真实数据：通过 QVeris 搜索并调用天气预报、空气质量、公共地理或城市参考数据能力。
输入：城市、日期、时间段、活动类型。
输出：适合度评分、推荐时间窗口、风险因素、数据更新时间、无法判断的原因。

请先不要写 UI。
先设计数据契约：
1. 前端需要的 JSON schema
2. 后端需要调用的数据能力
3. 每个字段缺失时的降级策略
4. 三个可复现的测试样例
5. 最小成本估算

确认后再生成代码。

这段 prompt 的核心不是“请帮我写代码”，而是“请帮我把一个产品问题压成数据契约和验证样例”。一旦有了这一步，后面的代码才有锚点。

好的 vibe coding，从数据契约开始

我现在越来越不喜欢一上来就让 AI 生成页面。

页面太容易骗过人。尤其是现代前端组件库很好看，一个没有真实逻辑的产品，也能做得像融资 Demo。

更稳的顺序是：

1. 写清楚用户决策
2. 写清楚数据来源
3. 写清楚输入输出
4. 写清楚失败边界
5. 写清楚验收样例
6. 再写页面和接口

还是以上面的户外助手为例，数据契约可以先长这样：

{
  "city": "北京",
  "activity": "family_outdoor",
  "time_window": "2026-07-04 09:00-12:00",
  "score": 72,
  "recommendation": "可以出门，但建议避开中午前后高温时段。",
  "risk_factors": [
    {"type": "temperature", "level": "medium", "reason": "上午后段升温较快"},
    {"type": "air_quality", "level": "low", "reason": "空气质量风险较低"}
  ],
  "data_freshness": {
    "weather": "分钟级或小时级，取决于上游数据源",
    "air_quality": "按监测源延迟"
  },
  "fallbacks": [
    "空气质量缺失时，只输出天气建议，并标记可信度下降"
  ]
}

这份 JSON 本身就可以成为 vibe coding 的核心资产。前端可以根据它生成页面，后端可以根据它设计接口，测试可以根据它做断言，产品也能根据它讨论是否符合用户心智。

如果没有这份契约，AI 生成出来的代码再多，也只是临时堆出来的东西。

QVeris 在这个案例里的位置

QVeris 更像是这个原型的数据底座，而不是页面组件。

在这个案例里，它可以承担三件事。

第一，发现能力。开发者不用一开始就知道具体该接哪个 API，而是先用自然语言搜索“天气预报”“空气质量”“开放城市数据”“地理参考数据”等能力，再从候选能力里选择适合的工具。

第二，检查能力。原型阶段不要急着调用。先看工具说明、参数、费用、延迟、数据覆盖范围和示例参数。很多 vibe coding 的失败，就是 AI 猜了一个不存在的参数，或者把返回字段理解错了。

第三，执行能力。真正调用时，把调用结果保存成 fixture。后面无论 UI 怎么改、模型怎么换，都有一份真实数据样例可以回归。

这也解释了为什么“有数据的 vibe coding”和“只做 UI 的 vibe coding”完全不同。前者能沉淀资产，后者很容易只沉淀一堆漂亮但没人敢接的代码。

成本如何更快转成产品

vibe coding 最大的诱惑是快。

但快有两种。一种是“很快看到一个东西”，另一种是“很快知道这个东西值不值得继续做”。真正能省钱的是第二种。

一个原型要更快转成产品，至少要留下四类资产：

资产	为什么重要
数据契约	让产品、前端、后端、测试讨论的是同一个对象
真实 fixture	防止每次演示都靠模型临场发挥
失败样例	让后续工程改造知道边界在哪里
成本账本	让产品判断是否适合免费试用、按次收费或打包进套餐

以上面的户外助手为例，成本账本不需要一开始就特别精细，但要能回答几个问题：

• 一次推荐要调用几个能力？
• 哪些调用可以缓存？
• 城市和日期相同的请求能不能复用？
• 免费用户能不能只看简版？
• 付费用户是否需要更高频更新、更长时间窗口或更多活动类型？

如果这些问题在原型阶段完全没有记录，后面产品化时会很痛苦。因为你不是在改一个 Demo，而是在重新理解一遍这个 Demo 到底做了什么。

怎么和现有产品结合

vibe coding 做出来的东西，最好不要一上来就幻想成一个独立产品。

更现实的路径是：把它当成现有产品里的一个可插拔能力。

比如户外助手可以有三种接入方式：

• 作为网站里的一个小页面，验证搜索流量和用户停留
• 作为已有 App 的一个卡片，给用户提供每日建议
• 作为 Agent 工具，允许其他产品通过 API 调用它

这三种方式对工程要求完全不同。

如果是页面，重点是交互、SEO、分享图和加载速度。如果是 App 卡片，重点是接口稳定、端上缓存、灰度和埋点。如果是 Agent 工具，重点是 schema、错误码、幂等、调用成本和结果可解释。

所以 vibe coding 的产物要尽量避免“只有页面”。它至少应该拆成：

• data adapter：负责调用 QVeris 能力
• decision engine：负责把天气、空气质量、活动类型转成建议
• api contract：负责给前端或其他产品稳定输出
• ui layer：负责展示
• fixtures and tests：负责回归

这样它才有机会接入现有产品，而不是每次都要整坨搬过去。

怎么和其他产品、开发人员互动

AI 原型最容易让团队产生误会。

产品同事看到的是“已经能用了”，研发同事看到的是“这东西还没法上线”。两边都没错，只是看的层面不同。

我觉得比较好的做法，是在 vibe coding 结束时输出一份很短的交接包，而不是只发一个仓库链接。

交接包可以包括：

1. 这个原型解决什么用户问题
2. 哪些流程已经跑通，哪些只是 mock
3. 调用了哪些真实数据能力
4. 每次调用的大致成本
5. 当前已知失败样例
6. 哪些代码可以保留，哪些建议重写
7. 如果上线，最小工程改造清单

这份文档越诚实，研发越愿意接。

最怕的是把 AI 生成物包装成“已经完成 80%”。很多时候真实情况是：产品探索完成了 80%，工程实现只完成了 20%。这不是坏事，但必须说清楚。

研发人员怎么接手

研发接手 vibe coding 成果时，不应该从“代码风格”开始骂。

更有效的顺序是先判断哪些东西值得保留：

层级	接手策略
用户流程	如果用户路径成立，应尽量保留
数据契约	如果字段设计合理，应优先固化
fixture	如果来自真实调用，应纳入测试
UI 组件	看质量决定保留或重写
状态管理	高风险，通常需要重审
鉴权、计费、权限	基本不要信任原型代码
错误处理	必须重新梳理

一个实用方法是先建“原型保护壳”。

也就是把 vibe coding 产物放进隔离目录或独立服务，先写端到端测试固定当前行为，再逐步替换内部实现。这样研发不是在一团不确定代码里裸手重构，而是在有测试边界的情况下拆弹。

对上面的户外助手来说，研发第一天不需要重写全部代码。更合理的是：

1. 保留三个真实 fixture
2. 固定 /api/outdoor-advice 的输入输出
3. 写 5 到 10 个边界测试
4. 把 QVeris 调用封装成 adapter
5. 把推荐规则从 UI 里移到独立模块
6. 再讨论是否换框架、换组件、换部署方式

这样接手成本会低很多。

如何衡量 vibe coding 的质量

不要只用“能不能跑”衡量。

能跑只是最低标准。更好的质量指标应该覆盖产品、数据、工程、协作四个方面。

维度	可以怎么量化
产品有效性	用户是否能在 30 秒内理解它解决什么问题
数据真实性	核心页面中真实数据占比，mock 数据是否明确标注
可复现性	是否有固定输入、fixture、测试命令
成本可见性	是否估算每次使用的数据调用成本
失败可解释	数据缺失、接口失败、模型不确定时是否能说明原因
可交接性	新研发是否能在半天内跑起来并定位主流程
可集成性	是否有稳定 API，而不是只有页面状态
可演进性	业务规则是否从 UI 组件中拆出来

如果只能选三个，我会选：

• 真实数据比例
• 可复现测试
• 可交接说明

这三个指标能直接区分“玩具原型”和“产品实验”。

prompt 也要分阶段写

很多人把 vibe coding 的 prompt 写成一次性愿望清单。

比如：

帮我做一个完整网站，要好看，要有登录，要有支付，要有数据分析，要能上线。

这类 prompt 不是不能用，但它会鼓励 AI 一次性生成太多不可靠代码。

更好的做法是分阶段。

探索阶段：

不要写代码。请把这个想法拆成用户流程、数据需求、风险点和最小验证实验。

数据阶段：

请基于 QVeris 可搜索的数据能力，列出这个产品需要的能力类型、输入参数、返回字段、缓存策略和失败降级。

原型阶段：

只实现一个端到端 happy path。禁止引入登录、支付、复杂状态管理。必须包含 fixture 和测试命令。

交接阶段：

请审查当前原型，标注哪些代码可保留、哪些必须重写，并生成研发接手清单。

上线阶段：

请围绕权限、计费、观测、错误码、缓存、幂等、数据合规，列出上线前阻塞项。

prompt 分阶段之后，AI 不再是“写代码机器”，而更像一个随时可用的产品工程搭档。

别把 AI 生成代码当成债，先把它当成调研

有些研发人员对 vibe coding 很抵触，原因也合理：他们见过太多 AI 生成的烂代码。

但我觉得不必把所有 AI 生成代码都看成技术债。更准确地说，它先是一种调研资产。

传统调研经常停留在文档、竞品截图、会议纪要里。vibe coding 的好处是，它能把调研变成可以点击、可以调用、可以被用户试用的东西。它的价值不是“代码已经写好了”，而是“我们更早知道这个方向有没有戏”。

当然，一旦决定继续做，就必须切换模式。

从那一刻开始，规则要从“快点看到效果”变成“让系统能长期维护”。这意味着：

• 数据源要稳定
• schema 要冻结
• 错误码要明确
• 测试要补齐
• 成本要入账
• 监控要接上
• 代码要有人负责

如果团队能接受这个切换，vibe coding 就不是混乱的来源，而是产品探索的加速器。

最后

我现在判断一个 vibe coding 项目值不值得继续，不看页面多漂亮，也不看 AI 写了多少代码。

我看三件事。

第一，它有没有接真实数据。没有真实数据，很多判断都是假的。

第二，它有没有留下可复现资产。没有 fixture、测试和数据契约，演示结束就开始贬值。

第三，它有没有被工程系统接住的可能。不能被接手、不能接入现有产品、不能解释成本和失败边界，再快也只是一次性 Demo。

所以，“怎样更好地 vibe coding”这个问题，我的答案并不浪漫：

少一点许愿，多一点契约；少一点炫技，多一点真实数据；少一点“AI 已经帮我做完了”，多一点“我已经把这个想法验证到可以交接了”。

这才是 vibe coding 真正能改变开发方式的地方。

参考

• Simon Willison: Not all AI-assisted programming is vibe coding
• Addy Osmani: Vibe Coding: The Future of Programming or Just a Fad?
• QVeris public capability explorer: Capabilities summary, Categories

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。

X 打开 X 主页 @ax2_zicode