企业官网建设流程全解析

1. 先说结论：Vibe Coding 把我从“想学编程”推进到了“有系统能用”

朋友圈发了个截图，说我花两个月让 AI 替我写出了六千行 A 股分析系统，评论区瞬间炸锅。私聊里的问题出奇一致：“这玩意到底靠谱吗？”“你写的时候是不是一直在帮它修 bug？”“我啥也不会也能复刻吗？”

先说我的答案：靠谱，但有前提。Vibe Coding 这门手艺，本质上不是“你不写代码”，而是“你把写代码的大部分体力活外包出去，自己守住需求、验证和边界”。对个人级别的 A 股分析系统来说，它确实能把一个过去需要半年才能磨出来的工具，压缩到两个月内落地。但如果你幻想张嘴说一句“给我一个自动赚钱的量化系统”，AI 就能还你一个印钞机，那趁早别碰。

我是谁？一个读了七八年 K 线的老股民，Python 属于“能看懂、会改、写不出优雅代码”的水平。职业和程序员搭点边但从不写生产代码。过去也试过自己写指标、抓数据、跑回测，每次都是前两周干劲十足，第三四周被数据格式、复权除权、交易日出错逼得直接弃坑。这次换成 Vibe Coding，最大的感受不是 AI 有多聪明，而是它把我以前倒在“体力活”这一关上的耐心，全部省了下来。

这套系统最终长什么样？它不是一个单文件脚本，而是一个完整的项目：

• 数据层：自动抓取 A 股日线行情、板块资金流、概念成分股、涨停晋级数据
• 处理层：清洗、复权、交易日过滤、特征构建
• 计算层：MACD、均线、量价、情绪周期等二十多个指标
• 回测层：支持多标的遍历、参数遍历、信号向量化计算
• 展示层：Streamlit 面板，输入代码就能看 K 线、信号、持仓模拟曲线

我能说它“好用”了，但这条路上踩过的坑，比代码行数多得多。这篇文章不只是讲“我成功了”，而是把所有决策点、避坑点、我和 AI 来回拉扯的真实过程，原原本本摊开给你看。

2. 系统设计与技术选型：为什么我放弃了传统 Copilot 思路

很多人一开始用 AI 写代码，习惯是开着编辑器，用 Copilot 自动补全，写一行确认一行。但我很快发现，对于 A 股分析系统这种“数据流清晰、模块划分明确”的项目，Copilot 模式反而低效。你想要的是一个能理解完整上下文、从零生成一个模块、再根据报错逐轮修复的 Agent 式对话闭环。

所以我在热门话题里搜 Vibe Coding 工具的时候，重点不是挑了哪个 IDE 插件，而是给自己定了三个硬性要求：

1. 会话上下文要长，能记住项目前两周的约定
2. 支持我吐给它报错日志和最小数据样例，它基于此修复
3. 它能读懂我放到上下文里的“需求清单和接口约定”

2.1 技术栈的最终选择与理由

这个项目压到最简，技术栈就四样：Python 3.10、pandas/numpy、akshare、Streamlit。中间也纠结过要不要上一套正经的时序数据库，但经过几轮测试后我反而把存储退回了 Sqlite。

为什么？因为我的数据量级也就是几百只股票的三五年日线，加上板块和资金流，撑死不到几百万行。Sqlite 加索引已经能跑进秒级响应，多上一套 ClickHouse 纯粹是给自己制造运维负担。Vibe Coding 的一个原则是：让复杂度停留在“够用”的位置。我和 AI 说的原话是：“存储方案选最简单的，能支撑 500 只股票五年日线查询即可，不考虑分布式。”这就是一个清晰约束，AI 就不会给你过度设计出一套 Kafka 流水线来。

akshare 则是数据源的关键。很多人纠结该用 tushare 还是 akshare，我的实际体验是：tushare pro 需要积分，部分高质量接口限制较多；akshare 完全免费，覆盖面广，缺点是接口本质上是爬取公开网页，稳定性一般。但对个人研究而言，这个取舍完全值得。更重要的是，akshare 的报错信息足够直观，AI 处理这类“已知开源库的小毛病”非常擅长——你只需要把报错原封不动丢给它。

2.2 为什么我强制要求模块化而不是单文件

刚开始图省事，我让 AI 把所有逻辑写在 main.py 里，三百行时还不觉得有问题，到八百行时改一个指标计算，后面所有行情输出全乱。最典型的翻车现场：我让 AI 给均线加一个“输出金叉死叉日期”的功能，它基于当时的变量顺序改了处理函数，结果把信号序列整体平移了一个 shift(-1)，所有历史回测信号晚了一天。

那次之后我痛定思痛，在提示词里强制加入模块拆分要求：

• src/data/：数据抓取与清洗
• src/factors/：指标计算
• src/backtest/：回测引擎
• src/visual/：图表
• src/utils/：通用工具

每个目录下单独拆 py 文件，文件之间用函数接口连接。AI 在明确目录树的前提下，生成的代码边界感明显变好。这背后是一个很朴素的道理：Vibe Coding 里你不是在“指挥”AI，你是在给 AI 描述一个工程结构，结构约清晰，它跑偏的概率就越低。

3. 核心模块拆解：数据、指标、回测、可视化是怎么一步步落地的

这一章是全文的干货，我会把每个模块的思考过程和 AI 协作细节都拆开。表面上看，代码是 AI 一行行生成的，但真正决定能不能跑、跑得对不对的，是我在每个环节设置的那些“人为干预点”。

3.1 数据层：从接口抓取到清洗的“语义之坑”

A 股数据是整个系统的地基。地基如果歪了，后面所有指标回测全是幻觉。我和 AI 在数据层的配合经历了三个阶段。

第一阶段是接口适配。akshare 接口很多，比如ak.stock_zh_a_hist返回日线，ak.stock_board_concept_hist返回概念板块历史，ak.stock_zt_pool_em返回涨停池。我最初的 prompt 是：“帮我写一个数据抓取模块，输入股票代码和起始日期，输出 DataFrame，列名为 trade_date, open, high, low, close, volume, amount, pct_chg。”AI 很快就给出了代码，这一轮一次通过，难度很低。

第二阶段是清洗。这才是真正的分水岭。A 股数据有三大“脏”：

1. 除权除息导致的价格跳空，需要复权处理
2. 停牌日数据缺失，不能直接删掉，否则影响指标连续性
3. 交易日历不总等于自然日，节假日调休导致日期断层

我要求 AI 做前复权处理。它生成的代码用了hfq_factor = df[['qfq_factor']].ffill()之类的方法，表面看着没问题。但是我用一个已知股票（贵州茅台）做验证的时候，发现它输出的前复权价格和同花顺里的数值差了接近 0.3%。原因是通过复权因子倒推价格时，它用了因子序列的前向填充，但没有处理“上市首日无因子”的边界。最终是我手动在 prompt 里补了一句：“每只股票取因子序列的第一个非空值作为基准，之后逐日累乘。”AI 修正后数值才完全对上了。

第三阶段是交易日历。这个坑特别典型，一定要分享。akshare 提供的交易日历接口有时会包含调休上班日，有时又会漏掉临时休市日。如果你直接用这个日历去对齐行情，回测里就会出现“在 10 月 9 号触发信号，但当天根本没有交易”这种荒谬结果。AI 靠自己是发现不了这类问题的，因为它对“中国的节假日调休导致某天休市”没有强约束。我的对策是加了一条业务规则：“清洗时必须以行情数据自身的 trade_date 为准，而不是以日历为准；任何日历里的日期如果在行情中缺失，直接剔除。”这种“语义规则”才是数据层真正需要人守住的阵地。

3.2 指标计算：教科书公式和交易软件之间有一条鸿沟

说个很多人不知道的事：你拿 pandas 实现的 MACD，和同花顺里显示的 MACD，数值可能对不上。

原因是 EMA 的初始化方式不同。通达信计算 EMA 时，第一个有效值直接取第一个收盘价，之后的公式是EMA(12) = 昨日EMA(12) * 11/13 + 今日收盘 * 2/13。但如果你的 DataFrame 里有缺失值或者从某一天开始计算，AI 生成的代码可能会用ewm(span=12, adjust=False)或更糟的ewm(span=12, adjust=True)。默认的 adjust=True 会让前几期的权重完全不同，导致头部数值偏差扩大到肉眼可辨的程度。

我的解决办法是一个笨但极其有效的方法：最小验证集比对法。具体操作是：

1. 取一只股票最近 100 根日线
2. 把 AI 算的 MACD 输出保存成 CSV
3. 打开同花顺，把同样参数（12, 26, 9）的 MACD 数值导出或肉眼读取关键拐点
4. 对比数值差，要求误差在 0.02 以内
5. 如果超差，直接把差异截图和代码反馈给 AI，要求它检查 EMA 初始化逻辑

这个流程每次迭代新指标都要做一遍，看起来低效，但它是整个系统所有输出可信度的基石。AI 写的指标代码再漂亮，如果和行业标准软件对不上，你的所有研究结论都会失真。

同样的思路也用在信号引擎上。我的信号规则包含均线多头排列、MACD 金叉回抽、放量突破平台等逻辑。我要求 AI 用向量化实现而非循环。举个例子，原始 prompt 是：“用 numpy 向量化计算金叉死叉信号，返回 0/1/2 三态数组，其中 1 表示金叉，2 表示死叉，0 表示无信号。”这比写“帮我实现一个金叉策略”要精确得多。

3.3 回测引擎：前视偏差是回测结果最致命的谎言

回测引擎是 AI 生成代码中最容易“看起来完美、实则暗雷遍布”的模块。核心雷区就是前视偏差。

我遇到的实际案例：我想在信号中纳入“当日涨停数量”作为情绪因子，逻辑是涨停数量高涨时市场情绪亢奋，追高风险大。AI 在实现时，为了对齐日期索引，用df.shift(1)或者merge的时候把当天涨停数据填到了前一天的信号行里。结果回测胜率高达 80%，我当时差点以为找到圣杯。后来我做了个简单的日期抽查，发现信号日的涨停数量实际上混入了第二天收盘后的数据，这就是教科书级的前视偏差。

解决方法是加一道“信息日期锁”。我在数据层的每个特征列后面都强制加了一列info_date，任何特征值必须标注它真正可用的日期。然后在回测 join 时要求信号生成日t只能引用info_date <= t的数据，不允许任何未来信息。AI 能不能自己悟出这个规则？我试过。它写出来的 join 逻辑在字段对齐上没问题，但它不懂“涨停数量是收盘后才公开的”这种 A 股信息时间语义。所以这一类规则必须由人来定义，AI 负责实现，绝不能反过来。

另一个常被忽略的是手续费和涨跌停约束。AI 默认的回测假设是股票可以按收盘价无限买入卖出，这不真实。我通过 prompt 加了三件事：

• 手续费单边千分之一点五，最低五元
• 卖出时加印花税千分之一
• 涨停板无法买入，跌停板无法卖出，对应当日价格超出涨跌停范围时信号无效

这些约束加进去以后，回测收益曲线肉眼可见地平滑下降了不少，但这才更接近真实可执行的结果。

3.4 可视化层：Streamlit 集成是项目交付的临门一脚

前七周系统一直是后台跑脚本，每次要看结果，要么打印一行行数字，要么调 matplotlib 存图再打开图片。体验感极差。第八周我决定加一个界面，选了 Streamlit，理由很简单：它支持纯 Python 写交互界面，不需要单独学前端，AI 生成起来也快。

这里的实现倒是出乎意料地顺利。我给的 prompt 是：“用 Streamlit 做一个简单的 A 股行情分析面板，支持输入股票代码、选择时间区间，显示 K 线图、均线、MACD 子图，以及最近 5 次信号提示。布局简洁，避免花哨。”

生成的界面虽然称不上精美，但完全能用。下拉选择框、日期选择器、matplotlib 绘制的三合一图（K 线、成交量、MACD）一次跑通。唯一的坑是缓存机制：Streamlit 默认每次交互会重跑脚本，导致频繁请求数据源，接口容易被限流。AI 的修复方案是加@st.cache_data(ttl=3600)装饰器，一小时缓存。第二天跑起来数据源就没再报错了。

这一个模块让我意识到：Vibe Coding 离“可用”最近的那一步，往往是最表面的交互层。因为交互层不涉及复杂业务逻辑，AI 的产出质量极高。

4. 工作流复盘：两个月六十次对话，我是怎么和 AI 协作的

整个开发过程不是一蹴而就，而是密集的小步迭代。我复盘了两个月的对话记录，整理出了一套对我行之有效的协作流程。这套流程完全可以复用到你自己的项目上。

4.1 需求的一句话模板：输入、输出、约束、测试

我最常用的提示词模板是这样的，模板化程度极高，但效果极好：

“为 A 股分析系统新增一个 [模块名] 模块。输入为 [数据结构描述 + 示例]，输出为 [目标数据结构描述]。项目现有目录结构是 [贴目录树]，请将代码放到 [指定路径]。请使用 [pandas/numpy] 实现，避免循环。完成后给出一个最小验证样例和预期输出。”

这个模板比“帮我写一个均线策略”这种口语化需求强十倍。关键差异在于：

• 输入输出必须可验证
• 目录约束避免“代码越界”
• 最小验证样例把验收标准前置

4.2 小步验证闭环：生成、运行、反馈、重生成

我的标准开发循环是：

1. AI 生成模块代码
2. 我复制到项目，跑一个调用例程
3. 如果通过，执行下一个任务
4. 如果不通过，把“报错日志 + 数据样例 + 预期输出”原样反馈给 AI
5. 重复最多三轮，三轮不通过就人工介入

我统计了一下，62 次有效对话中，平均每个模块需要 2.7 轮才达到验收标准。最短的 1 轮是纯数据格式转换，最长的 8 轮是回测模块的字段联动调整。这个数据说明：AI 不是一次就能写对，但它的正确率随着上下文中的验证反馈显著提升。如果你不反馈，AI 会一直在同一个错误上循环。

这里有一个容易忽略的细节：不要直接说“你的代码有 bug”，而是把报错日志原封不动贴进去，再加一句“请根据日志修复并解释根因”。AI 对报错信息的分析能力比对模糊指责的应对能力强太多了。

4.3 测试用例和 Git 提交：Vibe Coding 的安全带

我每天开工前第一件事是让 AI 跑一遍项目内置的最小测试集。这个测试集最早是我手写的几十行 pytest，后来也让 AI 帮我扩充到了数据结构校验、指标数值对照、信号日期检查三大类。

有了测试集以后，AI 改代码的“翻车成本”大幅降低。我可以随时让 AI “重构某模块”，改完跑测试，挂了就回滚。Git 在这里的作用是安全网。每次让 AI 大动干戈前，先 commit 一个 checkpoint，这句话是我踩了无数次坑之后总结出来的铁律。

具体操作：我要求 AI 在每次模块提交时代写一段变更说明，包括变更内容、影响范围、新增依赖、已知限制。然后我自己在 commit message 里补一句“这次改动帮系统解决了什么问题”。这个双轨记录习惯，帮我第四周回看第一周代码时省了大量重新理解的时间。

4.4 Prompt 里的工程素养：把“影响矩阵”变成武器

随着代码到五千行，我遇到了一个 Vibe Coding 特有的新问题：AI 改一个数据结构，改不准联动位置。比如我在股票 DataFrame 里加了一列fq_close（复权后收盘价），结果有五个模块都在引用df['close']做计算，AI 只改了其中三个。

我的解法是：每增加一个全局字段，强制要求 AI 生成一份“字段变更影响矩阵”，列出所有引用该字段的模块和函数。这个 prompt 是这么写的：“列出本项目中所有引用close字段的位置，标注文件路径、函数名、引用方式（读取/写入），并监督下一步修改是否覆盖全部引用点。”

这个方法基本解决了架构腐烂的问题。AI 能做全局代码分析，只是它默认不会主动做；你把它当工具人使唤，指示清晰，它就能交出高质量的“影响清单”。

5. 难点、局限与避坑手册：Vibe Coding 替你扛不了的那些事

写到这儿都是正面经验，但如果不把局限性说透，这篇文章就没有诚意。Vibe Coding 有非常明确的边界，边界之外你需要自己上。

5.1 数据语义与业务规则理解

前视偏差、交易日历、复权规则、T+1 信息约束、涨跌停可交易约束——这些都属于业务语义，A 股市场特有的东西。语言模型在训练时吸收了大量金融代码，它知道“应该怎么处理”，但它不知道“你的数据长得什么样”，更不会主动去校验。规则必须由你定义，它负责实现，这是最重要的分工原则。

5.2 代码质量随着时间推移的“熵增”

刚生成的前一千行代码质量最高，因为有上下文记忆，风格统一。到了四千行以后，同一个函数可能存在三个版本，有的用DataFrame有的用numpy array。AI 不会主动去统一它们，除非你明确提醒。我最后花了整整两天时间做代码清谱，把所有“玩具版本”砍掉，只留一套标准路径。这件事就没法外包给 AI，因为它没有全局审美的能力。

5.3 回测结果的情绪陷阱

做一个回测引擎很容易，拿着高回测收益率去自嗨也很容易。A 股系统天然会引发你对“圣杯”的幻想。Vibe Coding 把开发周期压缩到两个月，也把你的验证周期压缩了——你会更快地看到漂亮的回测曲线，更快地想要实盘。我的建议是：在系统跑满三个月、经历过两种行情风格之前，一律不碰自动下单。回测数据是统计学，不是财富密码。

5.4 常见错误速查表

这张表是我两个月踩坑的浓缩，按出现频率排序，直接拿去用：

6. 一点真实的体会

两个月下来，我对 Vibe Coding 的看法可以用一句话总结：它不是把你换掉，而是把你从“打字员”升维成“需求定义者和验证者”。

这个系统最终能不能赚钱，说实话我也没有把握。但比赚钱更重要的是，它让我第一次拥有了一个完全掌握在自己手里的研究工具。过去我在行情软件里看指标，只能看它预设好的那些；现在我可以把任何想法变成逻辑，把逻辑变成指标，把指标放回历史数据里去验证。这种“从想法到验证”的链路打通以后，你对市场的理解就彻底不一样了。

最后分享一个小技巧，是我踩了无数坑才养成的习惯：每次让 AI 生成完代码，不要急着看它写得有多漂亮，先跑一个我知道正确答案的测试样例。样例通过了，再开始聊下一个功能；样例不过，就把它丢回去，让它“看日志，解释根因，再改”。这个习惯看起来很笨，但正是它，把 AI 从一个“偶尔惊艳偶尔翻车的玩具”，变成了一个“稳定交付的同事”。

如果你也想试试用 Vibe Coding 做点自己的工具，我的建议是：挑一个你无比熟悉业务、但写代码头疼的领域下手。你对业务越熟，就越能定义出精准的输入输出和验收标准，AI 的表现就会越超出你预期。这大概是 Vibe Coding 里最不玄学的一条规律了。