全程 Vibe Coding 做了一个股票分析系统，我的一些技巧
最近全程 Vibe Coding 了一个股票分析系统。
第一版大概用了 15 个小时。
比较有意思的是，这 15 个小时里，大部分实现都不是我一行一行写出来的，而是 Codex 按照我给的计划自己往前推进。
我做的更多是给方向、补充约束、看结果、提调整意见。
这次体验让我对 Vibe Coding 又有了一些新的感受。
以前说 AI 写代码快，更多是在说“它能帮我补代码、修 bug、写页面”。
但这一次，我更明显地感觉到：如果前置计划足够清楚，Codex 真的可以像一个执行力很强的工程协作者，把一个项目从 0 推到第一版可用。
当然，这里说的是股票分析系统的工程实现。
它不是投资建议系统，也不代表生成出来的分析结果就可以直接用于决策。
我关心的重点，是这次 Vibe Coding 的工程过程。
不要只给一句需求
Section titled “不要只给一句需求”很多人用 AI 做项目，第一句话可能是：
帮我做一个股票分析系统。
这句话当然可以开始，但它太空了。
AI 会做，但它只能根据自己的理解去猜。
它会猜页面长什么样，猜后端接口怎么设计，猜数据怎么组织，猜你想要哪些分析指标，猜要不要登录，猜要不要缓存，猜要不要图表。
猜得多了，项目就容易偏。
这次我没有让 Codex 猜。
我先给了一个非常详细的计划方案。
里面包括系统目标、技术栈、模块边界、页面结构、数据流、接口设计、核心功能、优先级、实现步骤、验收标准。
不是一句“做个系统”。
而是告诉它：
- 这个系统先解决什么问题
- 第一版做到什么程度
- 哪些功能必须有
- 哪些功能可以后面再补
- 前端有哪些页面
- 后端有哪些接口
- 数据怎么流转
- 什么情况下算跑通
这一步非常关键。
因为 AI 的执行力很强，但它需要一个明确的方向。
方向越模糊，它越容易“看起来很努力”，但做出来不是你想要的东西。
把 AI 当执行团队，而不是许愿机
Section titled “把 AI 当执行团队，而不是许愿机”这次我最大的体会是：Vibe Coding 不是许愿。
不是我说一句“我要股票分析系统”，然后等它变出一个完整产品。
更好的心态是，把 Codex 当成一个执行团队。
我负责产品判断和架构方案。
它负责大量实现、联调、修复和补齐细节。
这两件事不能混在一起。
如果我把方向也完全交给 AI，它可能会做得很快，但最后会越来越像“它理解中的产品”。
如果我只把它当自动补全，那又浪费了它完整读项目、改项目、跑命令、修错误的能力。
比较舒服的方式，是把目标和边界给清楚，然后让它充分执行。
就像你带一个工程同事做项目。
你不会只说“随便做个股票系统”。
你也不会每一行代码都盯着他写。
你会说清楚目标、约束、优先级和验收标准，然后让他推进。
Codex 也是这样。
计划要写成可执行任务
Section titled “计划要写成可执行任务”我现在越来越觉得，给 AI 的计划不能只是“想法列表”。
想法列表对人有用，但对 AI 来说还不够。
它更需要任务链。
比如不要只写：
做股票列表、股票详情、分析报告。
而是写成：
- 先搭建项目结构，确认前后端能启动。
- 再实现股票基础数据模型和接口。
- 再做股票列表页面。
- 再做股票详情页。
- 再接入分析指标。
- 再补图表展示。
- 最后跑构建，修复类型和样式问题。
这样 Codex 就知道先后顺序。
它不会一上来就纠结一个复杂图表，也不会在后端模型没定的时候先写一堆页面。
任务顺序越清楚，它越能自主推进。
这次第一版能比较顺地跑下来，很大一部分原因就是计划里已经把路径铺好了。
AI 不是不知道怎么做。
它最怕的是不知道先做什么，做到哪里停，什么叫完成。
先让系统跑起来，再追求漂亮
Section titled “先让系统跑起来，再追求漂亮”股票分析系统很容易一开始就想做复杂。
各种指标、K 线、财务数据、新闻情绪、行业对比、AI 解读、风险提示。
这些都可以做。
但第一版不能全塞进去。
我这次的策略是先跑通主链路。
先有股票列表。
再有详情页。
再有基础分析。
再有图表和展示。
先让用户能点进去、看得到数据、读得到分析结果。
第一版最重要的不是完美，而是闭环。
闭环跑通以后，再优化体验、样式、指标和数据质量。
这对 Vibe Coding 尤其重要。
因为 AI 很擅长在已有结构上继续补东西。
但如果一开始结构就混乱，它补得越快，后面整理成本越高。
所以我更愿意先让它完成一个清晰的小闭环，再逐步加功能。
让 Codex 自己跑命令和修问题
Section titled “让 Codex 自己跑命令和修问题”这次我没有只让 Codex 写代码。
我让它自己读项目、改文件、跑构建、看报错、继续修。
这是 Vibe Coding 和普通聊天式写代码很不一样的地方。
以前用 AI，很多时候是它给一段代码，我复制过去，然后自己跑。
报错了，再贴错误回来。
这个过程其实很割裂。
而 Codex 可以在项目里直接工作，它能看到文件结构，也能运行命令。
所以我更倾向于让它完成一个闭环：
- 先理解项目
- 再修改代码
- 再运行检查
- 再根据错误修复
- 再继续验证
我只在关键节点做判断。
比如它修复方向不对，我再介入。
比如它做得太复杂，我让它收回来。
比如页面气质不对，我重新描述目标。
其他重复的调试工作，就交给它自己处理。
这会省很多精力。
验收标准要具体
Section titled “验收标准要具体”Vibe Coding 里，人最重要的工作之一是验收。
不是 AI 写完就结束了。
尤其是股票分析系统这种项目，表面看起来能跑，不代表真的对。
我会检查几个东西：
- 页面是不是能正常打开
- 列表和详情是不是能串起来
- 接口返回结构是不是稳定
- 空数据和异常状态有没有处理
- 构建是否通过
- 图表是否遮挡
- 分析文案是否过度自信
- 有没有把展示工具写成投资建议
最后这个点很重要。
股票分析系统可以做趋势展示、指标汇总、风险提示、数据对比。
但它不能给人一种“照着买就行”的感觉。
所以我会让它在文案和产品边界上保持克制。
这也是人要负责的地方。
AI 可以帮你实现功能，但什么东西该不该这样表达，还是要人判断。
提示词不如上下文重要
Section titled “提示词不如上下文重要”这次还有一个感受：提示词当然重要，但上下文更重要。
如果项目结构、技术栈、计划方案、验收标准都很清楚，提示词不需要写得多花。
你只要说：
按计划继续实现下一阶段。
或者：
根据当前报错修复构建问题。
或者：
保留现有架构，不要引入新的复杂依赖。
它就能接着往下做。
但如果上下文缺失，你写再多漂亮提示词，它也可能跑偏。
所以我现在更重视前置文档。
把项目目标、模块边界、接口约定、数据模型、优先级写清楚。
这些内容既是给人看的，也是给 AI 看的。
文档越清楚，AI 越像一个熟悉项目的协作者。
文档越模糊，AI 越像一个手很快但刚进组的人。
人的角色变了
Section titled “人的角色变了”这次 15 个小时做出第一版，我并不觉得自己“没参与”。
只是参与方式变了。
以前我更多是在写代码细节里消耗时间。
现在我更多是在做这些事：
- 定义目标
- 拆分阶段
- 控制范围
- 判断取舍
- 验收结果
- 修正方向
这其实更像产品负责人加架构师的角色。
AI 把大量执行工作接走了，但人的判断没有消失。
甚至更重要了。
因为执行速度越快，方向错了的代价也越大。
以前方向错了，可能写两小时才发现。
现在方向错了，AI 可能很快帮你实现一大片。
所以 Vibe Coding 不是让人不用思考。
它是把人的思考从“怎么写这一段代码”，往上推到了“这个系统应该怎么长出来”。
我这次最大的收获
Section titled “我这次最大的收获”我觉得最重要的一句话是：计划越清楚，AI 的自主执行能力越强。
Codex 这次能在 15 个小时左右把第一版跑通，不只是因为它代码能力强。
更重要的是，我给了一个足够具体的计划。
它知道要做什么，知道先做什么，知道做到什么程度算完成，也知道哪些地方不要越界。
Vibe Coding 的技巧，不是写一句神奇提示词。
而是把你的想法整理成 AI 可以执行的工程上下文。
你给它一个模糊愿望，它会给你一个模糊结果。
你给它一个清晰方案，它就能变成一个很强的执行者。
这也是我现在越来越喜欢 Vibe Coding 的原因。
它不是替我做决定。
它是在我把决定说清楚以后，能够将任务推进到验收版本。
