周日晚上 23:47我的屏幕上滚动着最后一版回测净值曲线。手边的 Excel 里是我手工从行情软件里逐段核对的月收益数据。两条线对上了。这一刻我才真的松了一口气——这个从想法到落地、前后折腾了两个月、累计六千多行代码的 A 股分析系统终于能让我放心地把结论拿出去与人讨论。这套系统不是我在命令行里一行行敲出来的。它的大部分代码是我用自然语言聊出来的——把需求讲给 AI 听让 AI 生成代码我再审查、修改、要求返工反复二十多个版本。这就是所谓的 Vibe Coding。今天想聊的不是AI 写代码有多神也不是程序员要失业了而是把它放到一个真实、有约束、有隐性规则的领域——A 股市场分析——里去检验Vibe Coding 到底靠不靠谱边界在哪里什么环节能加速什么环节它绝对帮不上忙。这篇文章适合两类人。一类是想用 AI 快速搭建个人分析工具、但没想清楚该信它到什么程度的开发者另一类是刚接触量化/技术分析、想知道 AI 生成代码里哪些坑最容易埋雷的投资者。我会把这两月的操作过程、翻车记录、效率数据和最终判断全部摊开讲不吹不黑。1. 从躺着写代码的幻想说起我为什么要让 AI 替我写 A 股分析系统1.1 起因被手工开发成本劝退的一百次先交代一下背景。我是一个长期做后端业务的开发写过交易系统周边的东西但从来没正儿八经搞过量化。2025 年初我手里的策略想法其实很朴素想验证均线多头排列 成交量放大 突破前期高点这类常见技术形态到底在 A 股日线尺度上有没有超额收益。按理说这种想法用现成平台也能验证。但问题在于我需要的是能反复修改、能控制每一个计算细节、能把指标输出和回测过程完全打开来看清楚自己写的东西。现成平台封闭普通 Excel 算几百行可以拉到全市场几千只股票、五到十年的日线数据根本撑不住。自己写呢数据层要管复权、停牌、ST、退市、新股指标层要写 MACD、RSI、布林带回测层要考虑手续费、滑点、涨跌停、T1最后还要一个能看 K 线的界面。我不止一次打开 IDE 之后又关掉——按我对自己的效率评估正常下班后写至少要两到三个月才能到能信的程度。1.2 目标收敛把项目压缩到 AI 能驾驭的边界真正让我下决心尝试 AI 编程的是我把自己的需求做了一次瘦身必须做A 股日线数据获取与存储技术指标计算策略信号扫描简易回测K 线可视化。明确不做实时行情、自动下单、券商接口对接、分钟级交易、多因子模型。不做的那些每一项都会让系统的复杂度和风险上升一个量级。尤其自动交易牵扯到实盘资金和接口稳定根本不适合拿 AI 生成的代码去赌。把范围锁死后我发现这个系统的难点不在条条大路通罗马的业务建模而在数据必须准确、规则必须符合 A 股实际的细节里。这恰恰是我可以做人工把关、AI 可以加速生产的地方。后来的实践证明这个收敛非常重要。Vibe Coding 能跑通的通常是边界清晰、验收标准可描述的项目。一旦目标是模糊的比如做一个智能交易系统AI 会给你生成一个看起来很完整、实则到处是洞的东西。1.3 一句话定义Vibe Coding 到底是什么很多人对 Vibe Coding 有误解以为就是丢一句话给 AI让 AI 自己从零写到尾。我理解的 Vibe Coding 不是这么回事。它的核心一句话用自然语言描述需求和约束让大模型直接产出代码然后通过人工审查和测试来收敛质量。Vibe 的意思是跟着感觉走但感觉要有边界——边界就是程序员自己的领域判断。这几个月我用的主力工具是 Cursor 编辑器里接入的 Claude 模型复杂逻辑会切到 DeepSeek 的编程模型做交叉评审。具体选型思路在后面章节展开。这里先给结论工具是谁不重要重要的是你和 AI 之间的那份需求文档怎么写。2. Vibe Coding 的实操姿势工具链、工作流和我的第一周2.1 工具链选择Cursor Claude 为主DeepSeek 做交叉评审市面上的 AI 编程工具不少GitHub Copilot、Cursor、Codex CLI、Cline 这些我都试过。实际用下来我的组合是编辑器Cursor看中的是它在多文件上下文里的能力能让我直接框选一个模块让它改而不是反复复制粘贴。主生成模型Claude 系列代码生成的一次成型率确实高对中文需求的理解也自然。交叉评审DeepSeek 的编程模型专门用来找代码里的低概率 bug——两个不同训练来源的模型互相看不惯反而更容易挑出对方的问题。版本控制Git 每天一个 tag保证任何时候都能回到能跑的版本。为什么不用 Codex CLI 做主力因为我的项目里有大量 A 股业务规则需要反复追问和澄清GUI 编辑器里边看代码边聊的体验更顺手。CLI 更适合那种不需要看上下文、直接生成文件的场景。2.2 我的第一周从 0 到能拉数据的 600 行第一周的目标很简单让系统能拿到数据。我给的第一个 prompt 大致是写一个 Python 程序用 akshare 获取 A 股所有股票的历史日线数据周期为日线时间范围 2015 年到今天数据存到 SQLite。要求股票代码归一化为 6 位字符串去掉北交所股票去掉上市日期晚于 2015 年 1 月 1 日之后一年的新股表结构包含 code、date、open、high、low、close、volume、amount并给 date 和 code 建联合唯一索引重复写入时跳过。这个 prompt 里我做了几件事明确数据源、存储方式、周期、股票范围、筛选规则、表结构、去重策略。AI 生成出来的代码基本能跑唯一的问题是它没有处理接口请求失败重试导致跑到一半程序因为网络抖动挂掉。我追加了一个要求所有请求加 retry 机制指数退避最大重试 5 次每次间隔 1 秒以上。第一周结束时系统已经能维护一份包含全市场约 5000 只股票的日线数据库。从零到这一步600 行左右代码大约用了三个晚上的时间。这比我手工写至少快一倍。2.3 工作流的进化从全交给 AI到需求拆碎、逐块验收第一周快结束时就碰了一次壁。我想让 AI 直接生成整个 MACD 指标模块 信号扫描逻辑 回测主体一个 prompt 塞了将近一千字的描述。结果 AI 确实生成了一大坨能跑的代码但每个模块之间的边界是糊的数据格式没对齐、函数命名混乱、回测里把买入信号日当天成交直接当成了默认行为。那次之后我把工作流改成了固定套路把系统拆成数据层、指标层、策略层、回测层、可视化层五个模块。每个模块再拆成输入输出可描述的小任务。每个小任务给出明确 prompt输入什么、输出什么、边界条件是什么、正确性怎么验证。AI 生成代码后我先做人工审查再让它补测试用例。测试通过后才并入主干。这套流程听起来像是传统开发里的需求细化本质也没区别。但关键差异在于细化后的需求是用自然语言表达的AI 能以极快的速度产出代码省掉的是我打字和调试语法的时间而不是思考的时间。从第二周开始我每天的有效产出从几十行跳到了两百到三百行能通过的代码。3. 六千行代码长什么样系统模块与 AI 真正擅长的部分3.1 整体模块划分哪些是 AI 生成、哪些是我自己写两个月的最终代码量约六千行分布如下模块代码量行主要语言AI 直接生成占比人工有效修改量数据获取与清洗1100Python90%数据筛选规则、重试策略指标计算900Python70%RSI、MACD 等全部人工核对公式策略信号与扫描700Python75%形态判定逻辑、过滤条件回测引擎1300Python30%撮合规则、资金管理几乎重写可视化与前端1400Python HTML/JS85%交互流程、数据接口测试与脚本600Python60%断言、t1 与涨跌停测试看到这个表你就能明白一件事AI 越擅长的部分越是输入输出明确、不含隐性业务规则的部分。数据获取、前端展示这类工作AI 的生成效率是压倒性的。而回测引擎牵扯到 A 股特有的撮合约束AI 生成的东西漏洞百出最后三分之一几乎是重写。3.2 数据层AI 帮我处理的脏数据比我预想的多得多A 股的日线数据看着简单实际上全是坑。前复权、后复权、不复权三种口径在同一天的价格完全不一样。分红送转的除权日当天价格会跳空不复权数据会导致技术指标计算出现虚假的暴跌暴涨信号。我在 prompt 里明确要求默认使用前复权数据且必须在所有指标计算前统一复权口径。AI 在这里帮了大忙——它知道 akshare 有复权参数也会帮我写取数后统一检查价格是否有异常跳空的逻辑。但它不知道的是 A 股的一些具体场景比如科创板上市前五日无涨跌停限制、北交所规则与沪深有明显差异。这些规则是我在筛选股票范围时手动排除掉的。数据层的另一个教训是日期对齐。从 akshare 拿到的数据有些股票停牌期间缺数据有些股票上市首日有数据但没有涨跌幅限制记录。AI 生成的初版代码在计算指标前没有做日期重采样导致不同股票在同一时间轴上的数据错位。我最后加了以交易日历为基础做全市场对齐的强制步骤。这个需求不是 AI 能主动想到的而是基于 A 股市场运行规则的人工输入。3.3 指标计算AI 在数学实现上有明显短板这是我最想吐槽的部分。MACD、RSI、布林带这些指标网上一搜一大把公式。但 AI 最大的问题是它可能把公式背得滚瓜烂熟却在你最不注意的地方漏掉一个变量。我遇到过一次它把 RSI 的周期参数写死成 14但在平均涨跌幅的平滑处理上把平均算成了总和除以窗口长度。这种错误特别隐蔽因为结果的大小看起来是合理的只有和标准实现对比才能发现。我的应对方式是指标层所有代码都要求 AI 同时生成针对同一输入的标准实现对比测试然后我再把结果交给一个独立的验证脚本去跑。比如 RSI我用通达信标准公式的手工计算结果做基准要求误差在 0.001 以内。从效率角度说AI 在这里帮的是把公式转化成代码的活但它节省不了多少时间——因为验证它编码是否正确的时间和直接自己写公式的时间差不多。我花了大约两天把所有指标统一审查和修正这期间做的其实是很传统的代码审计工作。3.4 回测引擎这是整个系统里唯一我坚持自己写主体的部分回测是整个系统的灵魂也是 Vibe Coding 表现得最差的地方。A 股的回测有几个 A 股特有的规则T1当天买入的股票下个交易日才能卖出。涨跌停约束涨停时买单大概率排不上队跌停时卖单大概率卖不出去。停牌停牌期间无法交易但信号可能仍在计算。手续费与印花税卖出时收取印花税费率因年份不同有差异。AI 生成的第一个回测引擎完全没有处理这些约束。它假设当天信号出现就能以收盘价买入第二天就能卖出还忽略涨跌停和停牌。用这种回测跑出来的年化收益比真实情况乐观不少——甚至可以说AI 的第一版回测结果成了一条几乎完美的向上曲线而真实可交易的收益要打一个大折扣。我最终保留 AI 生成的框架但把撮合逻辑如何匹配买卖、如何扣费、如何判断涨跌停不可成交全部重写。这部分代码我有意识自己写因为交易正确性直接关系到结论的可信度。我无法把模糊的规则讲给 AI 听并且相信它能准确落到每一行这超出了当前 Vibe Coding 的可靠性边界。4. 两个月里踩过的四种典型坑它们决定了 Vibe Coding 的边界4.1 文档型幻觉代码看起来对实际上根本没按规则来典型一例除权除息日的数据。系统里需要获取除权除息信息来校验复权数据的正确性。AI 给出的方案是从 akshare 的 dividend 接口拉数据合并到价格表。接口确实存在文档也确实写明了参数含义。但 AI 生成的代码里日期参数被错误地当成了除权日当天来用而正确语义是公告日期在指定区间。结果就是 2018 年之后的数据正确地合并了分红信息2015 到 2017 年的数据却少了一大截。这个 bug 是我在对比分红次数与实际价格跳空次数时才发现的。类似这种API 文档没读透、只按名字猜参数的问题AI 会反复犯。4.2 隐性业务规则的缺失AI 不懂中国市场如果说文档型幻觉还能靠测试抓出来隐性规则缺失就更难防了。A 股的 ST 股票、退市整理期股票在普通 K 线上看起来和其他股票没区别。但它们的基本面风险完全不同很多人做策略时明确要排除它们。我在 prompt 里写了一句剔除所有 ST 股票。AI 照做了。但它没有做到的是动态识别历史上曾经 ST 的股票。一只股票在 2020 年 4 月被 ST2021 年摘帽到 2025 年看它现在的股票简称已经不带 ST 了。可 2020 年那段时期的回测数据里它的交易状态确实受到了 ST 涨跌幅限制的影响。AI 默认的剔除 ST只是在当前代码上过滤了一次名称并没有在历史时间轴上做逐日判断。这种时间维度上的规则理解必须靠人喂给 AI。4.3 测试覆盖的幻觉AI 说测过了但断言太弱AI 生成测试用例时有一个通病断言太弱。它写出来的测试往往是def test_rsi_calculation(): result calculate_rsi(df, period14) assert result is not None assert len(result) len(df)这种测试只能证明函数跑了、没有报错、长度对完全不能证明算出来的值是对的。我后来要求 AI 生成测试时必须加入与标准实现对比和区间合理性检查。例如 RSI 的结果必须在 0 到 100 之间MACD 的 DIF 与 DEA 差值的正负号要和历史 K 线的趋势符合常识策略信号触发日期的前后价格关系必须满足突破的定义。一旦把断言要求提高AI 的测试生成能力其实也跟着变强了——因为它有足够多的标准答案可以对照。这个坑的教训是不是 AI 不会写测试而是你给它的质量标准太低。4.4 维护期的隐性成本改一行牵动三处第六周开始做策略参数优化时我遇到了维护地狱。AI 生成代码时喜欢把指标计算和信号判断的函数耦合在一起参数通过字典层层传递改一个参数名可能导致五个函数报错。它生成时确实能跑但维护性很差。典型的例子我把均线周期从 20 日改成 60 日这个需求通过自然语言提给 AI它改了一个函数的参数定义却没有同步修改策略信号判断函数里的默认值回测结果直接报废。我花了两个晚上定位问题最终决定把策略层的所有输入统一收敛到一个配置类里所有指标参数从配置类读取。在这个重构过程中AI 的作用大幅下降——因为要改的横截面太大模型反而容易顾此失彼。5. 两个月的账本时间花在哪、效率是几倍5.1 时间开销拆解开发不再是主要成本按环节拆分我的两个月大约 240 个小时含周末和工作日晚间花在了这些地方环节耗时小时AI 参与度我的真实感受需求设计与模块拆分25低纯人工无法节省数据层获取、清洗、对齐35高比预期快很多但清洗规则全得靠人想指标层编码与验证30中AI 快但不可靠验证成本高回测引擎60中撮合逻辑几乎全部人工最耗时策略扫描与结果校验40高AI 生成快人工核验不可省前端可视化15高AI 的强项非常畅快测试与回归20中测试写的快坏没想到的边界还是靠人重构与问题定位15低维护期 AI 帮不上忙看到这张表你应该能感觉到Vibe Coding 真正节省的是编码动作本身的时间而不是思考和验证的时间。我的实际情况是如果传统方式需要 600 小时用 AI 未必能压缩到 240 小时的一半以下但一定比 240 小时多。预估在同样的功能范围内纯手工开发大概需要 450 到 500 小时AI 让我的总工时大约节省了 40%而不是一些宣传中说的十倍效率。5.2 效率提升的真实来源不是写代码是快速试错我发现 AI 带来的最大效率提升不在把想法变成代码那一环而在试错的环节。以前我改一个策略参数需要改代码、重新计算、导出结果、看图表来回要一小时。现在改一个参数AI 帮我改配置和下游依赖五分钟就能出一版新报告。虽然 AI 改出来的东西偶尔要修但整体试错的循环时间缩短了一个量级。这也是为什么我最终认为 Vibe Coding 对个人项目最大的意义在于它把重构成本变得极低让探索性开发成为可能。传统开发里你不敢轻易改一个底层函数因为怕连带问题。AI 环境下改坏了重生成就好心理负担大幅下降我反而更愿意做实验了。6. 那 Vibe Coding 到底靠不靠谱我的结论只对个人项目有效6.1 什么场景下靠谱可描述、可验证、正确性边界清晰用一句话总结我这两个月的判断只要验收标准能被程序员自己清晰描述Vibe Coding 就非常靠谱。标准越清晰AI 生成的代码越准确。以我自己的项目为例靠谱的部分数据获取、数据清洗、指标公式转换、前端展示、接口包装、批量脚本。这些任务对错看得见检查成本低。不靠谱的部分回测撮合、异常交易状态处理、时间序列对齐、长期维护。这些任务里面有复杂的业务规则或者错误的后果在短时间难以察觉。对刚入门的朋友我给一个很实战的建议刚开始不要让它直接生成整个功能模块而是让它生成单个函数 极其严格的测试。比如写一个函数输入为 DataFrame输出为 RSI 序列测试断言必须包含与标准库对照的误差上限。这样你两小时就能摸清它的脾气比直接上大项目靠谱得多。6.2 什么场景下不靠谱隐性规则多、正确性难以验证、长期演进结合 A 股这个领域我更直白地说任何涉及交易正确性、资金模拟、撮合规则的代码都不要完全交给 AI。不是它不行而是它的训练数据里包含大量简化版或错误版的实现它有极大概率把某个简化假设带进你的代码里。另外AI 生成代码的可维护性是一个真实的长期负担。项目交付后我每改一个业务规则都要同时告诉 AI 三到五处可能受影响的代码位置。如果你要做的是一个会持续迭代、需要长期维护的系统建议在关键模块回测引擎、资金管理上坚持手写核心逻辑AI 只当辅助。6.3 给后来者的五条实践建议我自己从头再来一遍会怎么干如果让我现在重新开始这个项目我会用下面这套打法Prompt 以输入输出和正确性要求为骨架不要用帮我实现一个功能这种开放式描述。每个任务都要写清楚输入格式、输出格式、边界条件和验证方法。每个模块建立独立测试文件用真实市场数据做验证基准不要用 AI 生成的虚构数据。A 股的真实 K 线数据随处可得拿真实数据测一测一个准。对 AI 生成代码做变更审查重点看它有没有偷懒比如把假设写死在常量里、跳过异常处理、忽略 None 值。关键路径代码撮合、资金计算用传统方式手工写。这是我踩坑之后最坚定的原则。每天用 Git 打 tag每次 AI 大改之前保存快照。有时候改坏了与其让 AI 修不如回到一个稳定版本重新来。提示本文提到的所有代码与系统仅为技术研究用途不构成任何投资建议。A 股市场风险较大技术分析结果不代表未来收益请理性看待。回看这两个月我最深的感触是Vibe Coding 不会让一个不懂领域的人凭空做出可靠的工具但它能让一个理解领域的人把精力从键盘上解放出来投入到更值得做的事——验证想法、理解市场、修正规则。如果你也打算让 AI 替你做一套类似的分析工具请记住AI 是你的实习生不是你的替身。你可以让它写一万行代码但你必须亲自知道每一行为什么存在。
