Vibe Coding 实战复盘：从 0 到 1 做一个基金股票 AI 分析面板

最近我做了一个叫Fund Analysis Matrix的小项目。它不是传统的单一行情页，而是一个把基金、股票、黄金放到同一视图里的轻量看板：支持自选列表、行情快照、趋势图、今日板块分析、AI 复盘和 AI 问答。
👻在线访问地址
🔗github仓库：fund-analysis-matrix

1. 为什么做这个项目

这个项目的起点很简单：方便对自选的基金、股票进行统一的涨跌分析，想知道涨跌背后的原因，以及接下来如何操作。

所以我想做的不是一个更复杂的投研平台，而是一个更轻的金融看板：

• 上来就能统一添加基金、股票、黄金
• 用一套卡片式布局展示核心行情
• 点开即可看趋势图
• 基于当前自选自动生成 AI 复盘和今日板块分析
• 可以继续追问，让 AI 做陪伴式解释

2. Vibe Coding 在这个项目里是怎么落地的

这个项目里，我并不是先把所有页面、接口、状态流全部设计完再编码，而是先定义“产品感觉”，再让结构逐步收敛。

我的实际协作方式大概是这样的：
先告诉AI自己想做的是一个什么项目，以及大概的功能有哪些，使用哪些技术栈去实现，然后让他生成一个MVP项目的需求文档，再基于这个文档进行修改和补充。

1. 让 AI 产出第一版项目架构
2. 自己检查这版是否符合预期，再在基础上补充功能模块
3. 把问题拆成更小的任务继续迭代，比如“补趋势图弹窗”“补 AI 复盘区”“补错误态和空状态”
4. 到关键节点手动接管，整理数据模型、接口边界和异常路径

可以使用一些skills，让AI更有约束性和规范性。我常用的skills有ui-ux-pro-max-skill、vercel-react-best-practices、andrej-karpathy-skills

3. 产品设计是怎么收敛的

项目最开始其实可以继续往很多方向长：更复杂的筛选、更完整的研究页、更重的分析链路，甚至可以做成一个“迷你投研平台”。但我最后有意识地把它压回了“金融看板”这个形态。

因为看板的核心不是功能多，而是进入成本低、反馈快、信息密度高。

所以功能优先级上，我的取舍是：

• 第一优先级：统一资产入口、自选列表、行情卡片
• 第二优先级：趋势图弹窗和基础刷新机制
• 第三优先级：AI 复盘和 AI 聊天
• 最后再处理主题、视觉细节和体验修饰

这个顺序的好处是，哪怕 AI 功能还没完全打磨好，项目本身也已经是可用的。对这类中小项目来说，我觉得“先把核心路径做短”比“把所有能力堆满”更重要。

4. 技术架构怎么搭的

这个项目整体是一个典型的“轻量但完整”的结构：

src/ components/ React 业务组件 services/ 前端请求封装 store/ Zustand 自选列表持久化 theme/ 主题配置 api/ quote.ts 行情聚合 kline.ts 趋势数据 review.ts AI 复盘 chat.ts AI 问答 lib/ BFF 核心逻辑

前端技术栈是：

• React 19
• TypeScript
• Vite
• Ant Design
• Zustand
• ECharts

后端不是传统独立服务，而是放在api/下的一层serverless BFF。这层 BFF 是我觉得整个项目里最关键的结构决定，因为它把原本会污染前端的问题都拦住了：

• 不同数据源的字段差异由服务端统一清洗
• AI 的 API key 不暴露到前端
• prompt 拼接、超时控制、错误兜底都放在服务端处理
• 前端只消费统一结构的数据，不直接面对多个上游接口

如果不做这层 BFF，前端会很快长成一堆和业务展示无关的脏逻辑。对于一个看板型项目，这是非常不划算的。

5. 这个项目里最有含金量的几个实现点

5.1 多品类数据源统一成一个QuoteSnapshot

基金、股票、黄金本来就不是同一种资产，字段语义也不一致。所以我先在 BFF 层做了统一模型，把前端需要的最小公共集抽出来：

typeQuoteSnapshot={id:stringkind:"fund"|"stock"|"gold"code:stringname:stringprice:numberchangePctDay:numberchangePctWeek:number|nullasOf:string}

前端只围绕这个模型渲染卡片、趋势图和 AI 上下文，不再关心数据到底来自基金估值接口还是股票 K 线接口。这个抽象一旦成立，组件复杂度会明显下降。

5.2 数据源差异不是“显示问题”，而是“建模问题”

项目里基金数据来自基金估值接口，股票和黄金更多依赖东方财富 K 线接口。这里有一个很现实的问题：基金接口没有直接提供统一的周线历史，因此changePctWeek在基金场景下可能为空，趋势图里也只能基于当前净值做模拟曲线，而不是伪装成真实历史。

这个点我最后没有“硬补齐”，而是显式承认差异，然后在 UI 和文案里做提示。因为工程上最危险的不是功能缺失，而是把不可靠的数据包装成可靠的数据。

5.3 AI 复盘不能只靠“写得像”，必须靠结构约束

AI 复盘这一块，我没有让模型自由生成一大段文本，而是尽量把输出格式收紧：

• 要求返回 JSON，而不是自由文本
• 区分summary、items、portfolioTips等字段
• 对每个标的的分析拆成短摘要和详细说明
• 显式加入免责声明
• 要求模型尽量区分事实和推断，避免直接给买卖建议

这样做的价值不是“完全杜绝幻觉”，而是让输出从“会说”变成“可消费”。前端也因此可以稳定渲染，而不是被一大段不确定格式的文本牵着走。

5.4 AI 问答真正难的不是聊天框，而是上下文治理

聊天功能本身不复杂，复杂的是怎么把它限制在一个合理范围内。我的做法是：

• 把当前自选行情摘要拼进 system prompt
• 限制历史消息长度和条数
• 对“深度思考”模式做单独格式约束
• 流式返回时把 reasoning 和 answer 分通道处理
• 明确禁止输出具体交易建议和伪造新闻

从实现角度看，聊天框只是壳，真正有含金量的是 prompt 设计、上下文裁剪和流式处理。

5.5 体验细节决定它更像产品还是 demo

项目里还有几个看起来不大、但我觉得非常“产品化”的点：

• 自选列表通过Zustand persist本地持久化
• 首次 hydration 完成后立即拉一遍行情
• 行情每 5 分钟自动刷新，同时保留手动刷新入口
• 趋势图做成独立弹窗，并支持周 / 月 / 年切换
• 失败态、空状态、加载态都做了明确兜底

这些地方 AI 可以帮忙起草，但最后是否顺手，还是得靠自己一轮轮试。

6. Vibe Coding 的边界和坑

这个项目做下来，我对 vibe coding 的感受是：它确实能加速，但不会自动带来“工程正确性”。

我踩过或者明显感受到的几个坑是：

第一，AI 很擅长铺页面，但不一定理解金融场景的约束。它能写出看起来合理的分析文案，却不一定知道哪些表达在金融类项目里是不能随便说的。

第二，AI 很容易让数据契约和异常处理变松。开发前期如果只盯着“页面跑起来了没有”，后面就会花很多时间补接口边界、补错误路径、补空值处理。

第三，prompt 的第一版通常都很好用，但不代表长期可维护。随着需求变复杂，prompt 会越来越长、越来越脆，真正耗时的往往不是生成，而是后期的校准和收敛。

所以我现在对 vibe coding 的理解是：它特别适合把项目从 0 推到 1，但从 1 推到“稳定可维护”，还是得靠开发者把系统重新收紧。

7. 结果、反思和下一步

如果把这次实践做个总结，我会认为这种方式很适合三类项目：

• 产品感觉先行的中小型工具
• 需要快速验证交互和功能闭环的原型
• 前后端边界相对清晰、但不值得上重架构的应用

但它不太适合那种一开始就要求高一致性、高审计性、多人深度协作的大型系统。

后续这个项目的改进：

• 持仓视角：不仅看自选，还能输入持仓成本、仓位，展示浮盈亏和资产占比
• AI复盘优化：让 AI 回答“我的自选是不是过于集中”“风险暴露在哪”。解释“今天为什么涨跌”，并区分事实与推断。AI 模式可以切换，比如“复盘模式” 、“风险提示模式”、 “新手解释模式”。
• 从“行情快照”升级到“分析数据”：可以显示更多指标，比如年内收益、最大回撤、波动率、夏普比率、近 1/3/6/12 月表现。更多关于基金类型、主题、经理、费率、持仓方向、重仓行业等信息
• 优化适配移动端布局（功能可以简化些）
• 用户配置中心：模型、API Base、刷新频率、默认主题、默认观察周期都可配置