从年初开始我一直被一个想法折腾得睡不好觉能不能让 AI 帮我写一套 A 股分析系统当时的背景很朴素——我想做量化研究但自己的 Python 水平停留在“能看懂、能改”的阶段真要零基础写一个几千行的系统至少得啃半年的书。正好那段时间 Vibe Coding 这个词到处刷屏身边好几个朋友都在用 Claude 和 Copilot 搞原型我也就顺势试了一把。结果就是这道题目的标题两个月六千行一套能跑通的 A 股分析系统。今天这篇不聊玄学把整个过程中的架构设计、实操步骤、翻车记录和个人评判全部摊开说清楚。先说结论Vibe Coding 不是开盲盒也不是无脑让 AI 写代码然后祈祷能跑。它更像一个“需求拆解 代码生成 人工審查”的流水线AI 负责把话说人话翻译成代码但方向感、边界感、以及踩坑后的反思全都得你自己来。这套 A 股分析系统包含数据抓取、K线可视化、技术指标计算、策略回测、每日信号推送五个模块代码总量确实到了六千行左右。如果你也想搞一套类似的个人分析工具或者想评估“让 AI 写代码到底靠不靠谱”这篇文章应该能帮你省下不少试错成本。1. 项目背景与核心动机1.1 为什么想用 AI 写一套 A 股分析系统作为一个业余投资者我的需求其实挺明确希望每天有一份自动生成的复盘报告把收盘后的涨跌分布、板块强弱、自选股的技术面信号整理成固定格式最好还能跑一点历史回测验证某个简单策略在过去的胜率和最大回撤。市面上现成的炒股软件功能都挺全但数据都在别人的服务器里策略又不可定制权限受限很厉害。自己写又面临几个现实问题第一时间碎片化不可能每天抽三小时去刷语法文档第二脚本一多就混乱没有系统化设计能力第三A股的数据细节比想象中麻烦很多复权因子、停牌剔除、ST过滤每一件都够新手喝一壶。后来我刷到一篇文章讲的就是 Vibe Coding核心思路是“用自然语言描述想要的程序让 AI 批量生成代码人只负责验证和修方向”。我当时想的是与其学完整个工具链再开工不如让 AI 当助理边做边学。于是定了两个月的期限前四周搭框架中间四周做回测和策略最后两周打磨展示和报告输出。1.2 Vibe Coding 到底是什么Vibe Coding 这个词简单说就是“跟着感觉驱动编程”——你描述你想要什么AI 帮你写代码你跑起来之后觉得哪里不对再描述新的修改需求继续让 AI 改。这个过程里有大量的对话式迭代有点像用嘴写代码而不是用手敲。我第一次用这个概念时心情是很爽的一句话就能让 AI 生成一个爬虫脚本一个“把回测函数性能优化一下”就能得到多线程版本。但用了几周才发现那种“爽”是有陷阱的AI 生成的代码往往可以运行却不一定正确尤其是涉及边界条件、数据口径、浮点精度时都会在不经意的地方给你埋雷。更准确地说Vibe Coding 并不是“不思考”而是把思考重心从“语法细节”放到“系统语义”。你不需要记住每个函数的参数但你需要清楚这段代码要解决什么问题、输入输出是什么、异常情况下应该怎么表现。否则 AI 听不懂指令你也不知道怎么反馈两个星期下来代码量涨得很快能用的功能却还是原来那几个。1.3 选型与边界哪些部分该交给 AI动手之前我给这件事划了一条边界线。第一类坚决交给 AI数据接口封装、行情下载、数据清洗、表格展示、图表绘制、基础算法实现。这些都是成熟套路互联网上有大量相似代码AI 见过足够多的样本生成质量很高。第二类人工主导、AI 辅助策略逻辑、买卖信号、资金管理、回测框架的参数设计。因为这些背后是金融逻辑AI 并不懂你对亏损的容忍度也不懂 A 股特有的涨跌停制度如果直接让它“优化收益”它可能会给你生成一个理论上限极高但实盘根本成交不了的策略。第三类绝对不让 AI 碰数据源的合规性判断、是否使用未来函数、是否有幸存者偏差。这些风险用人话说就是“看起来很美实盘亏光”必须靠自己的常识和经验把关。这条边界线是整个项目能走下去的基础。没有它的约束这两个月大概率会变成“AI 编故事我信了然后完蛋”的灾难。2. 系统整体设计与技术架构2.1 六千行代码拆成了哪些模块六千行听起来很多但分到具体模块后其实很薄。我的项目目录大致是这样data_fetcher/负责从公开数据源获取日K线、个股基本面、指数行情包含抓取、重试、缓存、限速逻辑。cleaner/负责统一字段格式处理缺失值、停牌日、涨跌停特殊标记、复权计算。indicators/技术指标计算比如 MA、MACD、RSI、布林带、ATR这部分基本是 TA-Lib 的替代实现方便后续扩展自定义指标。strategy/策略层每个策略是一个函数输入 DataFrame输出买卖信号 Series。backtest/回测引擎支持按仓位比例成交、手续费设置、涨跌停无法成交的模拟。report/把回测结果和每日信号渲染成 Markdown 报告附带图表。此外还有一个config.yaml集中管理数据源地址、频率、策略参数。整体结构是 AI 辅助我讨论后定下来的但它最初给出的版本是“一个文件包打天下”两三千行塞一起根本没法维护。后来我花了整整两天和 AI 来回沟通才把它拆成上述模块化的样子。所以这里有个经验不要让 AI 直接设计系统目录结构至少你要先给它一个大致的模块划分思路。2.2 数据源与存储方案A 股日线数据看起来简单做起来全是坑。最开始 AI 给我生成的是一个直接用第三方库tushare的脚本只需要几行代码就能拿到股票列表和日线数据跑起来也很稳定。但问题是注册和积分限制比较多免费额度有限。于是我又让 AI 换成了从某个财经网站抓取公开页面数据的方案。这次就复杂多了需要伪装请求头、处理异步渲染、应对反爬、设置访问频率。AI 确实能生成一个可以跑的抓取脚本但稳定性完全看数据源心情。我最后用的是“公共接口 本地缓存 手动更新”的组合每次新增股票数据先去本地查没有再请求远程避免每天都全量刷新。存储方面我选了 SQLite原因很简单本地文件无需部署六千行级别的小系统根本不用上 PostgreSQL。AI 帮我把表结构设计成了daily_price、stock_info、trade_calendar、strategy_result四张表其中trade_calendar专门存交易日历解决了“非交易日程序还在跑”的蠢问题。SQLite 的并发读写性能对个人系统完全够用每天收盘后批量更新一次几百毫秒就完了。2.3 技术栈的选择逻辑技术栈是 Python pandas SQLite Plotly没有用重量级框架。选 Python 纯粹因为金融数据分析生态最成熟pandas 做表格操作无可替代Plotly 负责生成交互式图表能嵌入 HTML 报告。系统最终跑在 Windows 上用schedule库做每个交易日的定时任务。AI 还一度建议我上 FastAPI 做 Web 服务我果断否了——个人工具没必要搞一个常驻服务每天跑一遍脚本就够了能简单就不复杂。但有一个决定让我后悔了几周没有一开始就使用虚拟环境管理依赖。AI 生成的代码很笃定地往site-packages里装了一堆包后来版本冲突搞得我一整天都在处理环境问题。第二次重来我让 AI 生成了标准的requirements.txt和 venv 激活脚本世界清净了。这也是 Vibe Coding 容易踩的坑AI 默认你的环境是干净可控的但它根本不知道你机器上已经有了一万件乱七八糟的依赖。3. 实操过程从需求描述到第一版可运行3.1 第一周搭骨架让 AI 生成数据抓取模块第一周的目标很单纯让系统能自动下载一批股票的日线数据并写入 SQLite。我的第一个 Prompt 是请写一个 Python 脚本使用 akshare 接口获取沪深京 A 股全部股票列表然后循环下载每只股票 2020 年到现在的 日K线数据统一字段名为 date, open, high, low, close, volume, amount存到 SQLite 数据库中注意限制每秒请求次数超过 1000 只股票要断点续传。AI 给出的代码大约两百行结构清晰最让我意外的是它自己加了断点续传逻辑每次下载前查询本地数据库里已有的最大日期然后只增量下载缺失部分。这个能力真的很强。不过它也埋了一个雷没有处理新旧股上市时间早晚的问题对 2020 年之后才上市的股票它会一直尝试从 2020 年开始请求导致频繁返回空数据。我花了一个下午跟 AI 描述这个情况最后通过让 AI 在下载前先获取个股上市日期字段再以max(上市日期, 2020-01-01)作为起点问题解决。第一周我还学到了一个非常重要的 Prompt 技巧永远别让 AI“帮我处理所有异常情况”而是把具体异常场景喂给它。比如“300xxx 这只股票在复牌后第一天没有任何成交量但前一天的收盘价存在如何处理”AI 的反应明显比笼统的要求靠谱得多。3.2 第二至四周策略回测模块与常见坑回测模块是整个系统里最需要谨慎的部分。我最初的想法是让 AI 实现一个简单的“双均线策略”——金叉买入死叉卖出看看近三年沪深 300 成分股的表现。AI 很快给出了下面的核心代码ma_short close.rolling(window5).mean() ma_long close.rolling(window20).mean() signal (ma_short ma_long).astype(int) signal[ma_short ma_long] -1逻辑没错但在 A 股里有两个致命问题一是没有考虑涨跌停无法成交的现实涨停板你根本买不进跌停板卖不出二是信号出现当天就用收盘价成交实际上你看到信号已经是收盘后了最快只能按第二天的价格操作这就是未来函数。AI 生成的代码本身没有这些概念它只是照着教科书策略做数学计算。我把自己对交易执行的理解一点点告诉 AI让它加入“信号延迟一天执行”和“涨跌停时跳过交易”的规则回测结果的年化收益立刻难看了一个档次但这才接近真实。这里有个值得单独说的点回测中“手续费万二、印花税千一”是很容易让 AI 忽略的细节。如果你让 AI 直接写回测它大概率只会计算价格之差导致回测胜率虚高。我后来在配置文件里显式定义了成本模型让 AI 按这个模型计算净值曲线才把回测结果的含水量降下来。Vibe Coding 在这种地方尤其危险AI 永远会把代码写得很漂亮而你有没有能力看出其中的“漂亮”是虚假的决定了这套系统最终是工具还是玩具。3.3 第五至八周可视化与信号提示可视化对我来说是最享受的阶段因为 AI 几乎可以完美胜任。我只需要说“绘制最近一年的K线图叠加成交量和 20 日均线红色表示上涨绿色表示下跌”它就能给你一段 Plotly 代码结果完全符合预期。后来我让它把所有股票的信号汇总成一个表格并用不同颜色高亮“连续三日放量上涨”“MACD 底背离”等模式它也能很快完成。信号提示方面AI 生成了基于smtplib的邮件发送脚本每天收盘后把自选股信号推送给我。这个功能并不复杂但让我第一次真切感受到了“程序员的快乐”晚上看到邮件里写着的“持仓中 2 只出现顶背离注意风险”有一种自己掌控信息流的感觉。随后我又加了微信通知通道用的是第三方推送接口AI 也立刻能对接上。这些高度标准化的功能用 Vibe Coding 来做确实效率极高。4. 核心难点拆解AI 写代码的边界在哪里4.1 能自动化的CRUD、接口对接、常规计算经过这两个月的实践我敢说下面这类工作已经在 AI 能力的舒适区里从网站或接口读取 JSON 并转 DataFrame数据库的增删改查对接图表库绘制基本图形实现常规技术指标计算把一段 Markdown 表格转换成 HTML 邮件播放。这些任务在 GitHub 和 Stack Overflow 上有海量先例AI 模型看过足够多的数据生成的代码质量有时候比初级程序员还靠谱。效率提升非常明显。比如写一个“根据交易日历生成交易日列表”的工具函数AI 用了不到十秒代码简洁而且包含节假日我如果自己写至少要半小时到一小时。整个项目的数据抓取和数据清洗部分如果纯手写我估计要占到三周时间而用 AI 一周就搞定了前提是我得能准确描述“什么是交易日”“遇到 10-01 到 10-07 这种节假日怎么处理”。4.2 容易翻车的财务数据处理、时区、复权最容易翻车的部分集中在我称之为“真实世界的脏数据”上。A 股有很多特殊场景股票简称发生变化、停牌复牌导致 K 线不连续、除权除息导致价格跳空、B 股和 A 股交易规则不同、退市整理期等。AI 的模型对这些情况有基本的文字知识但它没见过你手里的具体数据不知道你的数据源里这些情况长什么样。复权问题最典型。如果用前复权价格计算信号那么最近的价格是准确的但早期历史价格会随着每次除权除息而改变如果不复权则会在除权日出现一个巨大的假跌破信号。我和 AI 沟通了三次才让代码正确区分前复权和后复权接口。AI 很乐意给你写一个adjust参数但它不会主动问你“历史回测应当使用复权价而实时信号则可能需要不复权价”这种问题只能由人来提。时区问题更隐蔽。某个数据源返回的时间戳可能是北京时间 UTC8但如果中间经过一次时区转换日期可能会偏移一天。AI 生成的代码默认datetime是 naive 类型根本不带时区信息。我靠肉眼对比数据才发现交易日错位的问题。建议所有与时间相关的字段在一开始就统一用字符串YYYY-MM-DD存储拒绝让 pandas 自动推断时间类型可以省下很多乌龙。4.3 必须人工兜底的策略逻辑与资金管理策略逻辑这部分我采取的是“AI 实现、人类定义”的方式。比如我自己设计了一个基于“波动率突破”的想法当 20 日平均真实波幅 ATR 上升超过 30% 且收盘价突破布林带中轨时次日开盘买入持有 5 天止损止盈。这个逻辑听完就让我给 AI 写描述它用几行代码就实现了。但真正到资金管理层面比如单笔风险控制、最大回撤熔断、仓位上限我会强制自己写注释和规则后再把注释翻译成 Prompt 给 AI。原因是AI 对“安全边际”没有体感它会尝试让策略永远满仓因为单纯从历史数据计算满仓的收益上限最高。可人不能接受 80% 的净值回撤。你在和 AI 对话时加入“当净值从最高点回撤 15% 时停止新开仓”这样的条件它就会照做但如果你不说它永远不会自己提。5. 常见问题与排查技巧实录5.1 AI 生成重复代码、混乱依赖怎么办第一个问题同一个功能反复出现在三四个模块里比如“计算 RSI”的函数被 AI 复制粘贴在各个策略文件中。这其实不能全怪 AI也怪我没有在需求描述里强调“只能定义一次复用模块”。我后来在项目根目录放了一个utils_common.py明确让 AI 以后所有公共函数都先检查这个文件里是否已存在不再自我重复。同时用 IDE 的“查找引用”功能定期检查死代码顺手删掉。依赖混乱的解法更简单把环境清理干净后重建。新建虚拟环境只安装requirements.txt里的固定版本。因为我之前让 AI 升级某个包结果它连 pandas 大版本都改了导致一堆.groupby行为变化回测结果全变了。教训是要 AI 动依赖之前先自己检查锁定文件不要放任它“顺手升级”。5.2 “修一个 bug 引入两个新 bug”的恶性循环这是 Vibe Coding 最常见的负反馈。某段代码因为边界条件报错你让 AI 修复它修改后确实解决了这个边界但另一个原本正常的路径却因为它的新判断被 break 了。第一个月这种循环我至少经历七八轮。后来我学乖了做法是给 AI 提供足够严谨的“验收单”每次修复前我会列出三条正常用例和三条异常用例要求 AI 保证所有用例都能通过才交付代码。相当于把它当作一个初级程序员来管理不给模糊任务只给明确验收标准。另外我强烈建议把关键代码的修改记录推到 Git 仓库里。AI 改崩了之后随时git diff看它改了什么如果改动不可控直接git checkout回滚上一版。这招救了我不下五次。很多初学者不喜欢用版本管理但 Vibe Coding 如果不配合版本管理你真的会被 AI 的“随机修复”折磨到怀疑人生。5.3 Prompt 提示词实操模板整理一下我这个项目里用得最顺手的 Prompt 结构【任务】在 backtest/engine.py 中修改下单逻辑。 【现状】当前 signal 为 1 时用当天收盘价买入。 【问题】这样会使用未来数据实际无法在收盘前成交。 【期望】改为 signal 为 1 时在下一个交易日开盘价买入并添加涨停时无法买入的过滤条件。 【约束】不要改动其他函数签名新增逻辑必须有注释输出完整修改后的代码块。这套模板的要点是任务控制范围现状和问题让 AI 理解上下文期望描述目标行为约束避免副作用。用这个格式以后返工率显著降低而且生成的代码基本能直接跑。当然你也可以直接用自然语言描述但最好别只是一句“帮我修 bug”因为 AI 面对模糊指令时最常用的策略就是在原有代码上打补丁而不会去评估会不会引入新问题。5.4 版本管理与代码审查习惯四千行左右时我开始引入小幅度的代码审查流程。其实很简单每次让 AI 生成重要模块后我会抽出其中的关键计算部分自己手动用 Excel 或简单脚本验证一遍。比如某个策略在平安银行上连续五天的信号是否正确我会打印出每一天的指标值对着行情软件核对。不要以为这个过程很繁琐它其实就是 Vibe Coding 里最核心的“人在环路”。AI 生成的是候选解你验证过的才是有效解。版本管理方面我还会为每个里程碑打 Tagv0.1是数据抓取完成v0.2是回测引擎完成v0.3是报告输出完成。Tag 之间如果发现 AI 生成的模块有不可接受的问题可以精准 diff 到底哪个阶段引入了回归。长期维护时这种做法让你面对一堆 AI 时代的“可再生代码”时仍然能保持主动权。6. 两个月复盘Vibe Coding 到底靠不靠谱6.1 哪些地方真正提升了效率数据比例大概是整个系统的代码有七成左右由 AI 直接生成剩下的三成主要是我带着 AI 修修改改。如果纯手写同等功能的系统至少需要两个半月到三个月而且前期学习曲线会非常陡。Vibe Coding 把“写代码”的门槛大大降低了让我把主要精力放在了数据理解、策略设计、结果验证上这也是作为半量化爱好者更需要的技能。尤其要说的是 AI 的“翻译能力”我只需要把心里模糊的想法描述出来AI 能迅速给我一个可以运行的原型哪怕它的性能和扩展性一般但至少让我对后续设计有了具体的参照物。这种“快速获得反馈”的节奏对保持心态和驱动力非常有帮助。每周末看到系统能跑出一个新功能那种成就感支撑我撑完了第二个容易被惰性打败的月份。6.2 容易产生的“虚假进度”幻觉但也要泼一盆冷水。Vibe Coding 很容易让人误以为“代码在涨系统就是真的在变强”。实际上AI 生成六千行代码里面可能有至少一千行是无用的、重复的甚至错误的。系统的真实功能量取决于你验证了多少而不是 AI 写了多少。我用“可运行用例数”来衡量进度每天能通过哪些测试用例新增的模块是否保证旧模块不回归。这个数字比代码行数诚实得多。虚假进度另一个表现是“跑通就以为对”。用真实数据验证时如果只跑了一两天、正好没有触发边界情况代码报错的机会就没暴露暂时不报错并不代表逻辑正确。我第三次回测时发现某个策略在涨停日依然产生买入信号就是因为代码里虽然加了判断但判断条件写在了订单撮合之前导致 signal 已经生成净资产曲线脱离了实际。这种逻辑顺序问题只有认真读代码才能发现。6.3 给想尝试的人的建议如果你也想用 Vibe Coding 搞一套类似系统我的建议可以浓缩成四点第一把项目拆成一个个可以独立验收的小块每块做完立刻测试和记录不要攒到最后一起来。第二数据源相关的代码优先使用稳定成熟的 SDK 而不是你去抓别人的私人接口因为这些反爬逻辑会浪费你大量时间。第三所有金融领域回测代码都要对“未来函数”和“交易成本”保持高度敏感这两点 AI 通常不会主动为你处理。第四用版本控制管理 AI 生成的每一份代码养成看 diff 的习惯哪怕只能看懂一半也比不看强。我对 Vibe Coding 的最终判断是它是一项可以显著提升效率的技术协作方式但前提是使用的人具备足够的领域知识和判断力。AI 是很好用的杠杆而支点就是你自己对问题本身的理解。你越清楚地知道自己要构建什么AI 就越能帮你实现。反过来如果你在这个领域基本是空白Vibe Coding 会放大你的错误判断让你得到一套能运行但完全不可信的花架子。我说到最后再分享一个实际体会真正让“AI 写代码”变得好用的时刻不是在我装作自己很懂编程的时候而是在我耐心读完 AI 生成的关键函数发现自己居然能挑出逻辑漏洞的时候。那一刻我才意识到这两个月我真正学会的不是 Python不是量化策略而是如何像一个系统设计者那样去描述问题、质疑结果。这套 A 股分析系统以后还会继续改但那些被踩平的过程已经沉淀成我自己的方法论了。对我个人来说这六千行代码里最有价值的不是代码而是最后留下来的二十多条 Prompt 笔记和四处修出来的紧急修复记录。希望这篇东西也能给你一个客观的参考。 
长河君 · 2026/11/2 22:16:20 · 阅读 1.2k Vibe Coding实战：两个月打造A股量化分析系统
从年初开始我一直被一个想法折腾得睡不好觉能不能让 AI 帮我写一套 A 股分析系统当时的背景很朴素——我想做量化研究但自己的 Python 水平停留在“能看懂、能改”的阶段真要零基础写一个几千行的系统至少得啃半年的书。正好那段时间 Vibe Coding 这个词到处刷屏身边好几个朋友都在用 Claude 和 Copilot 搞原型我也就顺势试了一把。结果就是这道题目的标题两个月六千行一套能跑通的 A 股分析系统。今天这篇不聊玄学把整个过程中的架构设计、实操步骤、翻车记录和个人评判全部摊开说清楚。先说结论Vibe Coding 不是开盲盒也不是无脑让 AI 写代码然后祈祷能跑。它更像一个“需求拆解 代码生成 人工審查”的流水线AI 负责把话说人话翻译成代码但方向感、边界感、以及踩坑后的反思全都得你自己来。这套 A 股分析系统包含数据抓取、K线可视化、技术指标计算、策略回测、每日信号推送五个模块代码总量确实到了六千行左右。如果你也想搞一套类似的个人分析工具或者想评估“让 AI 写代码到底靠不靠谱”这篇文章应该能帮你省下不少试错成本。1. 项目背景与核心动机1.1 为什么想用 AI 写一套 A 股分析系统作为一个业余投资者我的需求其实挺明确希望每天有一份自动生成的复盘报告把收盘后的涨跌分布、板块强弱、自选股的技术面信号整理成固定格式最好还能跑一点历史回测验证某个简单策略在过去的胜率和最大回撤。市面上现成的炒股软件功能都挺全但数据都在别人的服务器里策略又不可定制权限受限很厉害。自己写又面临几个现实问题第一时间碎片化不可能每天抽三小时去刷语法文档第二脚本一多就混乱没有系统化设计能力第三A股的数据细节比想象中麻烦很多复权因子、停牌剔除、ST过滤每一件都够新手喝一壶。后来我刷到一篇文章讲的就是 Vibe Coding核心思路是“用自然语言描述想要的程序让 AI 批量生成代码人只负责验证和修方向”。我当时想的是与其学完整个工具链再开工不如让 AI 当助理边做边学。于是定了两个月的期限前四周搭框架中间四周做回测和策略最后两周打磨展示和报告输出。1.2 Vibe Coding 到底是什么Vibe Coding 这个词简单说就是“跟着感觉驱动编程”——你描述你想要什么AI 帮你写代码你跑起来之后觉得哪里不对再描述新的修改需求继续让 AI 改。这个过程里有大量的对话式迭代有点像用嘴写代码而不是用手敲。我第一次用这个概念时心情是很爽的一句话就能让 AI 生成一个爬虫脚本一个“把回测函数性能优化一下”就能得到多线程版本。但用了几周才发现那种“爽”是有陷阱的AI 生成的代码往往可以运行却不一定正确尤其是涉及边界条件、数据口径、浮点精度时都会在不经意的地方给你埋雷。更准确地说Vibe Coding 并不是“不思考”而是把思考重心从“语法细节”放到“系统语义”。你不需要记住每个函数的参数但你需要清楚这段代码要解决什么问题、输入输出是什么、异常情况下应该怎么表现。否则 AI 听不懂指令你也不知道怎么反馈两个星期下来代码量涨得很快能用的功能却还是原来那几个。1.3 选型与边界哪些部分该交给 AI动手之前我给这件事划了一条边界线。第一类坚决交给 AI数据接口封装、行情下载、数据清洗、表格展示、图表绘制、基础算法实现。这些都是成熟套路互联网上有大量相似代码AI 见过足够多的样本生成质量很高。第二类人工主导、AI 辅助策略逻辑、买卖信号、资金管理、回测框架的参数设计。因为这些背后是金融逻辑AI 并不懂你对亏损的容忍度也不懂 A 股特有的涨跌停制度如果直接让它“优化收益”它可能会给你生成一个理论上限极高但实盘根本成交不了的策略。第三类绝对不让 AI 碰数据源的合规性判断、是否使用未来函数、是否有幸存者偏差。这些风险用人话说就是“看起来很美实盘亏光”必须靠自己的常识和经验把关。这条边界线是整个项目能走下去的基础。没有它的约束这两个月大概率会变成“AI 编故事我信了然后完蛋”的灾难。2. 系统整体设计与技术架构2.1 六千行代码拆成了哪些模块六千行听起来很多但分到具体模块后其实很薄。我的项目目录大致是这样data_fetcher/负责从公开数据源获取日K线、个股基本面、指数行情包含抓取、重试、缓存、限速逻辑。cleaner/负责统一字段格式处理缺失值、停牌日、涨跌停特殊标记、复权计算。indicators/技术指标计算比如 MA、MACD、RSI、布林带、ATR这部分基本是 TA-Lib 的替代实现方便后续扩展自定义指标。strategy/策略层每个策略是一个函数输入 DataFrame输出买卖信号 Series。backtest/回测引擎支持按仓位比例成交、手续费设置、涨跌停无法成交的模拟。report/把回测结果和每日信号渲染成 Markdown 报告附带图表。此外还有一个config.yaml集中管理数据源地址、频率、策略参数。整体结构是 AI 辅助我讨论后定下来的但它最初给出的版本是“一个文件包打天下”两三千行塞一起根本没法维护。后来我花了整整两天和 AI 来回沟通才把它拆成上述模块化的样子。所以这里有个经验不要让 AI 直接设计系统目录结构至少你要先给它一个大致的模块划分思路。2.2 数据源与存储方案A 股日线数据看起来简单做起来全是坑。最开始 AI 给我生成的是一个直接用第三方库tushare的脚本只需要几行代码就能拿到股票列表和日线数据跑起来也很稳定。但问题是注册和积分限制比较多免费额度有限。于是我又让 AI 换成了从某个财经网站抓取公开页面数据的方案。这次就复杂多了需要伪装请求头、处理异步渲染、应对反爬、设置访问频率。AI 确实能生成一个可以跑的抓取脚本但稳定性完全看数据源心情。我最后用的是“公共接口 本地缓存 手动更新”的组合每次新增股票数据先去本地查没有再请求远程避免每天都全量刷新。存储方面我选了 SQLite原因很简单本地文件无需部署六千行级别的小系统根本不用上 PostgreSQL。AI 帮我把表结构设计成了daily_price、stock_info、trade_calendar、strategy_result四张表其中trade_calendar专门存交易日历解决了“非交易日程序还在跑”的蠢问题。SQLite 的并发读写性能对个人系统完全够用每天收盘后批量更新一次几百毫秒就完了。2.3 技术栈的选择逻辑技术栈是 Python pandas SQLite Plotly没有用重量级框架。选 Python 纯粹因为金融数据分析生态最成熟pandas 做表格操作无可替代Plotly 负责生成交互式图表能嵌入 HTML 报告。系统最终跑在 Windows 上用schedule库做每个交易日的定时任务。AI 还一度建议我上 FastAPI 做 Web 服务我果断否了——个人工具没必要搞一个常驻服务每天跑一遍脚本就够了能简单就不复杂。但有一个决定让我后悔了几周没有一开始就使用虚拟环境管理依赖。AI 生成的代码很笃定地往site-packages里装了一堆包后来版本冲突搞得我一整天都在处理环境问题。第二次重来我让 AI 生成了标准的requirements.txt和 venv 激活脚本世界清净了。这也是 Vibe Coding 容易踩的坑AI 默认你的环境是干净可控的但它根本不知道你机器上已经有了一万件乱七八糟的依赖。3. 实操过程从需求描述到第一版可运行3.1 第一周搭骨架让 AI 生成数据抓取模块第一周的目标很单纯让系统能自动下载一批股票的日线数据并写入 SQLite。我的第一个 Prompt 是请写一个 Python 脚本使用 akshare 接口获取沪深京 A 股全部股票列表然后循环下载每只股票 2020 年到现在的 日K线数据统一字段名为 date, open, high, low, close, volume, amount存到 SQLite 数据库中注意限制每秒请求次数超过 1000 只股票要断点续传。AI 给出的代码大约两百行结构清晰最让我意外的是它自己加了断点续传逻辑每次下载前查询本地数据库里已有的最大日期然后只增量下载缺失部分。这个能力真的很强。不过它也埋了一个雷没有处理新旧股上市时间早晚的问题对 2020 年之后才上市的股票它会一直尝试从 2020 年开始请求导致频繁返回空数据。我花了一个下午跟 AI 描述这个情况最后通过让 AI 在下载前先获取个股上市日期字段再以max(上市日期, 2020-01-01)作为起点问题解决。第一周我还学到了一个非常重要的 Prompt 技巧永远别让 AI“帮我处理所有异常情况”而是把具体异常场景喂给它。比如“300xxx 这只股票在复牌后第一天没有任何成交量但前一天的收盘价存在如何处理”AI 的反应明显比笼统的要求靠谱得多。3.2 第二至四周策略回测模块与常见坑回测模块是整个系统里最需要谨慎的部分。我最初的想法是让 AI 实现一个简单的“双均线策略”——金叉买入死叉卖出看看近三年沪深 300 成分股的表现。AI 很快给出了下面的核心代码ma_short close.rolling(window5).mean() ma_long close.rolling(window20).mean() signal (ma_short ma_long).astype(int) signal[ma_short ma_long] -1逻辑没错但在 A 股里有两个致命问题一是没有考虑涨跌停无法成交的现实涨停板你根本买不进跌停板卖不出二是信号出现当天就用收盘价成交实际上你看到信号已经是收盘后了最快只能按第二天的价格操作这就是未来函数。AI 生成的代码本身没有这些概念它只是照着教科书策略做数学计算。我把自己对交易执行的理解一点点告诉 AI让它加入“信号延迟一天执行”和“涨跌停时跳过交易”的规则回测结果的年化收益立刻难看了一个档次但这才接近真实。这里有个值得单独说的点回测中“手续费万二、印花税千一”是很容易让 AI 忽略的细节。如果你让 AI 直接写回测它大概率只会计算价格之差导致回测胜率虚高。我后来在配置文件里显式定义了成本模型让 AI 按这个模型计算净值曲线才把回测结果的含水量降下来。Vibe Coding 在这种地方尤其危险AI 永远会把代码写得很漂亮而你有没有能力看出其中的“漂亮”是虚假的决定了这套系统最终是工具还是玩具。3.3 第五至八周可视化与信号提示可视化对我来说是最享受的阶段因为 AI 几乎可以完美胜任。我只需要说“绘制最近一年的K线图叠加成交量和 20 日均线红色表示上涨绿色表示下跌”它就能给你一段 Plotly 代码结果完全符合预期。后来我让它把所有股票的信号汇总成一个表格并用不同颜色高亮“连续三日放量上涨”“MACD 底背离”等模式它也能很快完成。信号提示方面AI 生成了基于smtplib的邮件发送脚本每天收盘后把自选股信号推送给我。这个功能并不复杂但让我第一次真切感受到了“程序员的快乐”晚上看到邮件里写着的“持仓中 2 只出现顶背离注意风险”有一种自己掌控信息流的感觉。随后我又加了微信通知通道用的是第三方推送接口AI 也立刻能对接上。这些高度标准化的功能用 Vibe Coding 来做确实效率极高。4. 核心难点拆解AI 写代码的边界在哪里4.1 能自动化的CRUD、接口对接、常规计算经过这两个月的实践我敢说下面这类工作已经在 AI 能力的舒适区里从网站或接口读取 JSON 并转 DataFrame数据库的增删改查对接图表库绘制基本图形实现常规技术指标计算把一段 Markdown 表格转换成 HTML 邮件播放。这些任务在 GitHub 和 Stack Overflow 上有海量先例AI 模型看过足够多的数据生成的代码质量有时候比初级程序员还靠谱。效率提升非常明显。比如写一个“根据交易日历生成交易日列表”的工具函数AI 用了不到十秒代码简洁而且包含节假日我如果自己写至少要半小时到一小时。整个项目的数据抓取和数据清洗部分如果纯手写我估计要占到三周时间而用 AI 一周就搞定了前提是我得能准确描述“什么是交易日”“遇到 10-01 到 10-07 这种节假日怎么处理”。4.2 容易翻车的财务数据处理、时区、复权最容易翻车的部分集中在我称之为“真实世界的脏数据”上。A 股有很多特殊场景股票简称发生变化、停牌复牌导致 K 线不连续、除权除息导致价格跳空、B 股和 A 股交易规则不同、退市整理期等。AI 的模型对这些情况有基本的文字知识但它没见过你手里的具体数据不知道你的数据源里这些情况长什么样。复权问题最典型。如果用前复权价格计算信号那么最近的价格是准确的但早期历史价格会随着每次除权除息而改变如果不复权则会在除权日出现一个巨大的假跌破信号。我和 AI 沟通了三次才让代码正确区分前复权和后复权接口。AI 很乐意给你写一个adjust参数但它不会主动问你“历史回测应当使用复权价而实时信号则可能需要不复权价”这种问题只能由人来提。时区问题更隐蔽。某个数据源返回的时间戳可能是北京时间 UTC8但如果中间经过一次时区转换日期可能会偏移一天。AI 生成的代码默认datetime是 naive 类型根本不带时区信息。我靠肉眼对比数据才发现交易日错位的问题。建议所有与时间相关的字段在一开始就统一用字符串YYYY-MM-DD存储拒绝让 pandas 自动推断时间类型可以省下很多乌龙。4.3 必须人工兜底的策略逻辑与资金管理策略逻辑这部分我采取的是“AI 实现、人类定义”的方式。比如我自己设计了一个基于“波动率突破”的想法当 20 日平均真实波幅 ATR 上升超过 30% 且收盘价突破布林带中轨时次日开盘买入持有 5 天止损止盈。这个逻辑听完就让我给 AI 写描述它用几行代码就实现了。但真正到资金管理层面比如单笔风险控制、最大回撤熔断、仓位上限我会强制自己写注释和规则后再把注释翻译成 Prompt 给 AI。原因是AI 对“安全边际”没有体感它会尝试让策略永远满仓因为单纯从历史数据计算满仓的收益上限最高。可人不能接受 80% 的净值回撤。你在和 AI 对话时加入“当净值从最高点回撤 15% 时停止新开仓”这样的条件它就会照做但如果你不说它永远不会自己提。5. 常见问题与排查技巧实录5.1 AI 生成重复代码、混乱依赖怎么办第一个问题同一个功能反复出现在三四个模块里比如“计算 RSI”的函数被 AI 复制粘贴在各个策略文件中。这其实不能全怪 AI也怪我没有在需求描述里强调“只能定义一次复用模块”。我后来在项目根目录放了一个utils_common.py明确让 AI 以后所有公共函数都先检查这个文件里是否已存在不再自我重复。同时用 IDE 的“查找引用”功能定期检查死代码顺手删掉。依赖混乱的解法更简单把环境清理干净后重建。新建虚拟环境只安装requirements.txt里的固定版本。因为我之前让 AI 升级某个包结果它连 pandas 大版本都改了导致一堆.groupby行为变化回测结果全变了。教训是要 AI 动依赖之前先自己检查锁定文件不要放任它“顺手升级”。5.2 “修一个 bug 引入两个新 bug”的恶性循环这是 Vibe Coding 最常见的负反馈。某段代码因为边界条件报错你让 AI 修复它修改后确实解决了这个边界但另一个原本正常的路径却因为它的新判断被 break 了。第一个月这种循环我至少经历七八轮。后来我学乖了做法是给 AI 提供足够严谨的“验收单”每次修复前我会列出三条正常用例和三条异常用例要求 AI 保证所有用例都能通过才交付代码。相当于把它当作一个初级程序员来管理不给模糊任务只给明确验收标准。另外我强烈建议把关键代码的修改记录推到 Git 仓库里。AI 改崩了之后随时git diff看它改了什么如果改动不可控直接git checkout回滚上一版。这招救了我不下五次。很多初学者不喜欢用版本管理但 Vibe Coding 如果不配合版本管理你真的会被 AI 的“随机修复”折磨到怀疑人生。5.3 Prompt 提示词实操模板整理一下我这个项目里用得最顺手的 Prompt 结构【任务】在 backtest/engine.py 中修改下单逻辑。 【现状】当前 signal 为 1 时用当天收盘价买入。 【问题】这样会使用未来数据实际无法在收盘前成交。 【期望】改为 signal 为 1 时在下一个交易日开盘价买入并添加涨停时无法买入的过滤条件。 【约束】不要改动其他函数签名新增逻辑必须有注释输出完整修改后的代码块。这套模板的要点是任务控制范围现状和问题让 AI 理解上下文期望描述目标行为约束避免副作用。用这个格式以后返工率显著降低而且生成的代码基本能直接跑。当然你也可以直接用自然语言描述但最好别只是一句“帮我修 bug”因为 AI 面对模糊指令时最常用的策略就是在原有代码上打补丁而不会去评估会不会引入新问题。5.4 版本管理与代码审查习惯四千行左右时我开始引入小幅度的代码审查流程。其实很简单每次让 AI 生成重要模块后我会抽出其中的关键计算部分自己手动用 Excel 或简单脚本验证一遍。比如某个策略在平安银行上连续五天的信号是否正确我会打印出每一天的指标值对着行情软件核对。不要以为这个过程很繁琐它其实就是 Vibe Coding 里最核心的“人在环路”。AI 生成的是候选解你验证过的才是有效解。版本管理方面我还会为每个里程碑打 Tagv0.1是数据抓取完成v0.2是回测引擎完成v0.3是报告输出完成。Tag 之间如果发现 AI 生成的模块有不可接受的问题可以精准 diff 到底哪个阶段引入了回归。长期维护时这种做法让你面对一堆 AI 时代的“可再生代码”时仍然能保持主动权。6. 两个月复盘Vibe Coding 到底靠不靠谱6.1 哪些地方真正提升了效率数据比例大概是整个系统的代码有七成左右由 AI 直接生成剩下的三成主要是我带着 AI 修修改改。如果纯手写同等功能的系统至少需要两个半月到三个月而且前期学习曲线会非常陡。Vibe Coding 把“写代码”的门槛大大降低了让我把主要精力放在了数据理解、策略设计、结果验证上这也是作为半量化爱好者更需要的技能。尤其要说的是 AI 的“翻译能力”我只需要把心里模糊的想法描述出来AI 能迅速给我一个可以运行的原型哪怕它的性能和扩展性一般但至少让我对后续设计有了具体的参照物。这种“快速获得反馈”的节奏对保持心态和驱动力非常有帮助。每周末看到系统能跑出一个新功能那种成就感支撑我撑完了第二个容易被惰性打败的月份。6.2 容易产生的“虚假进度”幻觉但也要泼一盆冷水。Vibe Coding 很容易让人误以为“代码在涨系统就是真的在变强”。实际上AI 生成六千行代码里面可能有至少一千行是无用的、重复的甚至错误的。系统的真实功能量取决于你验证了多少而不是 AI 写了多少。我用“可运行用例数”来衡量进度每天能通过哪些测试用例新增的模块是否保证旧模块不回归。这个数字比代码行数诚实得多。虚假进度另一个表现是“跑通就以为对”。用真实数据验证时如果只跑了一两天、正好没有触发边界情况代码报错的机会就没暴露暂时不报错并不代表逻辑正确。我第三次回测时发现某个策略在涨停日依然产生买入信号就是因为代码里虽然加了判断但判断条件写在了订单撮合之前导致 signal 已经生成净资产曲线脱离了实际。这种逻辑顺序问题只有认真读代码才能发现。6.3 给想尝试的人的建议如果你也想用 Vibe Coding 搞一套类似系统我的建议可以浓缩成四点第一把项目拆成一个个可以独立验收的小块每块做完立刻测试和记录不要攒到最后一起来。第二数据源相关的代码优先使用稳定成熟的 SDK 而不是你去抓别人的私人接口因为这些反爬逻辑会浪费你大量时间。第三所有金融领域回测代码都要对“未来函数”和“交易成本”保持高度敏感这两点 AI 通常不会主动为你处理。第四用版本控制管理 AI 生成的每一份代码养成看 diff 的习惯哪怕只能看懂一半也比不看强。我对 Vibe Coding 的最终判断是它是一项可以显著提升效率的技术协作方式但前提是使用的人具备足够的领域知识和判断力。AI 是很好用的杠杆而支点就是你自己对问题本身的理解。你越清楚地知道自己要构建什么AI 就越能帮你实现。反过来如果你在这个领域基本是空白Vibe Coding 会放大你的错误判断让你得到一套能运行但完全不可信的花架子。我说到最后再分享一个实际体会真正让“AI 写代码”变得好用的时刻不是在我装作自己很懂编程的时候而是在我耐心读完 AI 生成的关键函数发现自己居然能挑出逻辑漏洞的时候。那一刻我才意识到这两个月我真正学会的不是 Python不是量化策略而是如何像一个系统设计者那样去描述问题、质疑结果。这套 A 股分析系统以后还会继续改但那些被踩平的过程已经沉淀成我自己的方法论了。对我个人来说这六千行代码里最有价值的不是代码而是最后留下来的二十多条 Prompt 笔记和四处修出来的紧急修复记录。希望这篇东西也能给你一个客观的参考。