企业官网建设流程全解析

周日晚上 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、布林带；回测层要考虑手续费、滑点、涨跌停、T+1；最后还要一个能看 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 确实生成了一大坨能跑的代码，但每个模块之间的边界是糊的：数据格式没对齐、函数命名混乱、回测里把"买入信号日当天成交"直接当成了默认行为。

那次之后，我把工作流改成了固定套路：

1. 把系统拆成数据层、指标层、策略层、回测层、可视化层五个模块。
2. 每个模块再拆成输入输出可描述的小任务。
3. 每个小任务给出明确 prompt：输入什么、输出什么、边界条件是什么、正确性怎么验证。
4. AI 生成代码后，我先做人工审查，再让它补测试用例。
5. 测试通过后才并入主干。

这套流程听起来像是传统开发里的需求细化，本质也没区别。但关键差异在于：细化后的需求是用自然语言表达的，AI 能以极快的速度产出代码，省掉的是我打字和调试语法的时间，而不是思考的时间。从第二周开始，我每天的有效产出从"几十行"跳到了"两百到三百行能通过的代码"。

3. 六千行代码长什么样：系统模块与 AI 真正擅长的部分

3.1 整体模块划分：哪些是 AI 生成、哪些是我自己写

两个月的最终代码量约六千行，分布如下：

看到这个表你就能明白一件事：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 股特有的规则：

• T+1：当天买入的股票下个交易日才能卖出。
• 涨跌停约束：涨停时买单大概率排不上队，跌停时卖单大概率卖不出去。
• 停牌：停牌期间无法交易，但信号可能仍在计算。
• 手续费与印花税：卖出时收取印花税，费率因年份不同有差异。

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 月被 ST，2021 年摘帽，到 2025 年看它现在的股票简称已经不带 ST 了。可 2020 年那段时期的回测数据里，它的交易状态确实受到了 ST 涨跌幅限制的影响。AI 默认的"剔除 ST"只是在当前代码上过滤了一次名称，并没有在历史时间轴上做逐日判断。这种时间维度上的规则理解，必须靠人喂给 AI。

4.3 测试覆盖的幻觉：AI 说"测过了"，但断言太弱

AI 生成测试用例时有一个通病：断言太弱。它写出来的测试往往是：

def test_rsi_calculation(): result = calculate_rsi(df, period=14) 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 个小时（含周末和工作日晚间）花在了这些地方：

看到这张表你应该能感觉到，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 给后来者的五条实践建议：我自己从头再来一遍会怎么干

如果让我现在重新开始这个项目，我会用下面这套打法：

1. Prompt 以"输入输出和正确性要求"为骨架，不要用"帮我实现一个功能"这种开放式描述。每个任务都要写清楚输入格式、输出格式、边界条件和验证方法。
2. 每个模块建立独立测试文件，用真实市场数据做验证基准，不要用 AI 生成的虚构数据。A 股的真实 K 线数据随处可得，拿真实数据测，一测一个准。
3. 对 AI 生成代码做"变更审查"，重点看它有没有偷懒，比如把假设写死在常量里、跳过异常处理、忽略 None 值。
4. 关键路径代码（撮合、资金计算）用传统方式手工写。这是我踩坑之后最坚定的原则。
5. 每天用 Git 打 tag，每次 AI 大改之前保存快照。有时候改坏了，与其让 AI 修，不如回到一个稳定版本重新来。

提示：本文提到的所有代码与系统仅为技术研究用途，不构成任何投资建议。A 股市场风险较大，技术分析结果不代表未来收益，请理性看待。

回看这两个月，我最深的感触是：Vibe Coding 不会让一个不懂领域的人凭空做出可靠的工具，但它能让一个理解领域的人把精力从键盘上解放出来，投入到更值得做的事——验证想法、理解市场、修正规则。如果你也打算让 AI 替你做一套类似的分析工具，请记住：AI 是你的实习生，不是你的替身。你可以让它写一万行代码，但你必须亲自知道每一行为什么存在。