一个不懂后端的产品经理，和一个会写代码但会撒谎的 AI，花了一个月把这件事做出来。
本文所有数字都是写稿当天从真库里现取的，不是文档里抄的。
**这是系列第 1 篇。** 五篇的题目和分工：

| | | |
|:-:|:-:|:-:|
|篇|标题|写什么|
|**1（本文）**|**我把 740 万条 A 股 K 线塞进一个离线零依赖的工作台**|选源、被封 IP、11 批灌数、灌坏了怎么兜|
|2|AI 帮我写代码不稀奇，难的是让它别撒谎|踩坑档案 **[80]** 条的由来|
|3|38 页高保真原型，从一张白纸到一个能跑的工作台|设计 → 实现的完整链路|
|4|我让 AI 帮我验证了 4 个数据源，3 个结果是错的|数据源验证方法论|
|5|AI 写的回测代码，我用负例亲手推翻它|负例回归 / 真值表|
本文只点到为止：凡是和后面几篇有重叠的地方，这里只提一句结论，**详细情况后续系列里会详细说。**


----
## 写在前面：为什么要自己造

我不是程序员。日常工作是写需求文档、画原型、跟开发吵架。
做这个工作台的原因特别朴素：**市面上的炒股软件，没有一个能按我的想法记账和复盘。**
我想要的东西其实很简单：
- 一套完全跑在自己电脑上的软件。断网能用，不登录，不注册，不把我的持仓同步到任何服务器。

- 卖出规则我自己定义。止损、止盈、移动止损、时间止损……每一类的触发条件、执行时机，我都要能一条条配出来。

- 配色按 A 股习惯来：涨是红的，跌是绿的。这个要求听着可笑，但我试过的软件里，一半默认美股配色，改都改不了。

- 所有数据落在本地一个文件里，我想怎么查就怎么查，想怎么算就怎么算。

这些要求加起来，结论就是：买不到，只能自己做。
我不会写代码，但 WorkBuddy 会。于是这件事就变成了：**我出判断，它出代码；我负责"对不对"，它负责"能不能跑"。**
一个月之后，它长这样：

| | |
|:-:|:-:|
|项|数字|
|本地数据库体积|**1.79 GB**（单个 SQLite 文件）|
|数据表|**36 张**|
|日线 K 线|**7,414,371 行**|
|覆盖股票|**5,786 只**|
|数据区间|2020-07-27 至 2026-10-16|
|季频财务|123,274 行（5,847 只）|
|后端代码|40 个文件 / 15,507 行|
|前端页面|42 个 HTML + 1,781 行主脚本|
![图1_库表清单.png](https://developer.qcloudimg.com/http-save/yehe-12827795/6df0ebc29a5c66715090d26feb41eda1.png)图注：演示库的数据快照（2026-10-19 导出）——36 张表、740 万行日线的全景。行情是真实行情，持仓和自选股是编造的演示数据。

这篇只讲一件事：**740 万行数据是怎么进去的，中间踩了什么坑。**
因为它真的不是"写个脚本跑一晚上"那么简单。


----
## 第一节：我要的是"能追溯"，不是"能看"

先说我为什么对数据这么较真。
做产品的人有个毛病：看到一个数字，第一反应是"这个数可信吗"。我给自己定了一条死规矩：
>**任何一个指标，我必须能说清它从哪来、什么时候取的、用什么口径算的、和我以为的是不是一回事。**

这四条里有任何一条说不清，这个指标就不能进产品。
比如"换手率"。软件里显示 3.2%，那到底是 3.2% 还是 0.032%？是当天的还是近五日均值？是流通股本口径还是总股本口径？前复权之后还对不对？
这些事在买入决策里会直接变成钱。所以我给这个项目定了几条红线，其中一条至今没破过：
**K 线和回测，只用一个数据源。而且这个源必须能给出复权因子，让我能自己验算。**
不许混源，不许"这个字段这家有就用这家"。宁可少一个指标，不许出现两个口径打架的同一个指标。
当时的我并不知道，这条红线后来救了整个项目。


----
## 第二节：数据源，用最笨的办法判死四个

需求文档里原定的方案，用的是东财（东方财富）的数据接口。看起来最省事：一个接口全包，K 线、资金流、报表都有。
我没直接信。让 AI 写了个探测脚本，一个源一个源地试。结果：

| | | |
|:-:|:-:|:-:|
|数据源|用来干什么|实测结果|
|东财 **push2his** / **push2**|历史 K 线 / 资金流|❌ **连打 10 次，0 次成功**|
|东财 **datacenter-web**|报表类（龙虎榜等）|✅ 可用|
|腾讯 **web.ifzq**|历史 K 线|⚠️ 能取，但前复权最多 **640 根**|
|新浪|实时快照|✅ 可用|
|Baostock|日/周/月/分钟 K 线 + 财务|✅ 可用（官方客户端）|
东财那一行我印象最深。第一次探测返回 200、496 条真实数据、字段齐全，AI 当场跟我说"东财可用"。
我没敢信，让它**连打 10 次**——0/10。
于是有了后来我给自己定的第一条判据：
>**验证通过 = 连续 10 次成功。单次成功不算。**

对一个要长期跑下去的系统来说，"偶尔能通"和"完全不通"是一回事。区别只是前者会让你在联调阶段以为是自己代码写错了。
腾讯那条死在另一件事上：**硬上限 640 根**。按一年 242 个交易日算，不到三年。
一个要算"近五年最大回撤"的回测系统，数据只有三年——这不是数据少，这是**结论错**。
（这些判据是怎么一条条试出来的、另外四个候选源又怎么被证伪，**详细情况后续系列第 4 篇会详细说**，这里只给结论。）
最后定下来的是 **Baostock**。它慢、要装客户端、有频率限制，但它给出的是**完整的、带复权因子的、可自己验算的**日线。对我要做的事情，这比"快"重要得多。


----
## 第三节：最难的那一关 —— 被封 IP

数据源定了，接下来是灌数。
全市场待灌 **5,500 只**（沪 2,439 + 深 3,061），每只约 1,300 个交易日。这个量级，得跑一整个通宵。
第一次跑，我用 8 个线程并发去拉。
跑到 15:30，全断了，屏幕上只剩一行：
>**10001011 黑名单用户**

被封了。
当时的我完全不知道这意味着什么。我以为是我代码写错了，让 AI 查了半天，最后才确认：**是服务端主动封了我的出口 IP。**
原因很直白——8 个并发连接，在对方看来就是异常流量。
这件事教给我两件事，后来都变成了红线：
**第一条：绝不允许两个数据源连接同时存在。**
不是"最好别"，是"绝对不允许"。所以后来所有的灌数流程都写成串行，一个连接用完、退出，再开下一个。
**第二条：不要用 taskkill /F 强杀进程。**
强杀会留下没正常 logout 的悬挂连接，在服务端看起来比正常请求更像攻击流量。要用 **Ctrl+C** 让它自己退。
那怎么解封？
网上给的办法是"等冷却期"。我试了一个完全不同的思路——**换出口 IP**。
我家宽带是 PPPoE 拨号，出口 IP 不是固定的。拔掉光猫电源，等 30 秒（只拔 3 秒不够，运营商的 DHCP 租约没释放），插回去，重拨。
新 IP 是 **120.245.101.194**。
然后我让 AI 调了一次 **login()**：
**0.3 秒，返回 success。**
这条路线是从第三方经验里看来的，原本我标的是"🔴 待验证"。那次之后，它变成了"✅ 实测证实"，写进了 **doc/换IP解封操作指引.md**，八步，每一步都有自查命令，包括"确认 IP 真的换了"和"确认只认 IPv4 出口"（Baostock 走 IPv4，本机还有 IPv6 出口，变了不算数）。
后来我把整个灌数流程重做了一遍。重点不是"跑得更快"，是"跑得更稳"：
- **串行**：一条连接，4.53 秒一只。全市场待灌 **5,500 只**，约 6.9 小时。慢，但在源端配额内安全。

- **切成 11 批**：每批 500 只，一批约 38 分钟。这样出问题只损失半小时内的工作量，而不是"跑了一夜全废"。

- **批次切在"全量列表"上，不切在"待灌列表"上**。这条是我坚持的：如果按待灌的列表切，灌完一批编号就整体前移，"重跑第 7 批"会指到另一批股票——那分批最大的好处（出问题能定位到固定的一小批）就白给了。

- **每批结束就落账**：commit → 写台账（**kline_batch**：批号、起止时间、几只、几行、几个空值、几个失败、首末代码）→ 批间 sleep → 重新 login。

- **断点游标每 10 只更新一次**：真断了也只丢 10 只的活。

还有一道墙是硬的：我要求"早上 7:30 之前必须停"（我要关电脑）。所以做了两道闸——
**闸①**：每批开跑前估算"现在 + 本批预计 + 缓冲"，超过 7:30 就不开新批；
**闸②**：批内每只都检查一次时间，到点立刻收尾。
只做闸①不够。估算会偏——某只股票特别慢、或者源端抖一下，就冲过去了。必须有一道按"只"粒度的兜底。


----
## 第四节：灌坏了怎么办

灌数有两种"坏法"，我一开始只想到第一种：
- **跑一半断了**（网络、被封、关机）→ 数据半新半旧

- **源返回了半截数据**（分页异常、接口抽风）→ 表面上跑完了，其实少了一批，**而且不报错**

第二种更危险。所以两种数据用了两种保护。
**① K 线（740 万行）：靠"幂等 + 断点"**
写入是 **INSERT OR REPLACE**，同一只股票重复灌不会变成两份——这条很重要，因为**断了要能放心重跑**。
游标每 10 只 commit 一次，加上每批结束的 commit，最坏情况只丢 10 只的活。所以"续跑"不是靠猜上次跑到哪，是查库里已经有谁、台账记了谁。
**② 证券主数据（6,446 只）：靠"整表原子替换"**
这张表是"全市场清单"。它一旦被半截数据覆盖，后面所有按它统计的数字全错——而且它只有 6 千多行，跑得很快，你根本不会怀疑它。
所以这张表的写法是：临时表 → 一个事务里换名 → 删旧表。任何一步失败就 **ROLLBACK**：
```

```换之前还有三道闸门：

| | | |
|:-:|:-:|:-:|
|闸门|规则|拦什么|
|行数下限|首次灌数少于 **6,000 只** → 拒绝|源返回空/半截|
|缩水检查|比上次少超过 **20** 只 → 拒绝替换（旧数据保留）|源分页异常|
|暴涨检查|比上次多超过 **50** 只 → 只告警但仍替换|新股批量上市（这种情况告警就够）|
**为什么是"拒绝"而不是"覆盖"？**
因为一次失败的覆盖，损失的不是那一次的时间，是**你之后所有基于这张表的结论**。而且它不会报错，会安安静静留在库里，等你几个月后算出个离谱的数，再花两天去查。
这是我做产品十年学到的最贵的一课：**静默的错误比报错贵一百倍。**
![图2_批次台账.png](https://developer.qcloudimg.com/http-save/yehe-12827795/c958a5bea0ed17ac6156946de8f4682f.png)图注：**kline_batch** 表快照——11 批的起止时间、只数、行数、空值、失败全留痕。
表里第 1 批显示 **aborted**：那是后来补 PE/PB 估值时重跑第 1 批中断，把原记录覆盖掉了。
这条我留着没删，因为它本身就是个教训：**台账用 INSERT OR REPLACE 写，会让"跑成功过"的记录被"后来失败了"覆盖掉。**


----
## 第五节：数据进去之后，它才真正有用

7 个一级菜单：**驾驶舱、策略实验室、组合风控、情报中心、验证中心、交易与复盘、全局设置**。整个前端在 **app/** 下是 42 个 html（含状态页、弹窗这些零碎页），淡绿主色，涨红跌绿。
![图3_驾驶舱.png](https://developer.qcloudimg.com/http-save/yehe-12827795/8c537bc09cd80f00cdcb7e3725bde2eb.png)图注：产品真实截图（2026-10-05，演示态）——淡绿主色 #52c48d，涨红跌绿；初始资金 ¥1,000,000 为演示值，不含任何真实持仓。

卖出规则是我花时间最多的部分，最后按"执行时机"分成两类：
- **盘中立即成交**：止盈、止损、移动止损、锁定盈利、多阶段止盈

- **次日开盘成交**：时间止损、技术卖出

为什么非要分？因为"触发就立刻卖"和"触发后明天开盘卖"是两种完全不同的策略——前者滑点小但要盯盘，后者能睡着觉但要承担隔夜跳空。混在一起做，回测出来的收益曲线就是假的。
页面怎么从设计说明书一页页翻译出来的（38 页、5 轮迭代，从一张白纸到能跑），**详细情况后续系列第 3 篇会详细说**，本文不展开。


----
## 第六节：一个月，我踩了 80 个坑

从第一行代码到现在，**doc/踩坑档案.md** 里记了 80 条，编号到 **[80]**。
这 80 条里**没有一条是"我不知道怎么写代码"**。全是同一类：
>**我以为我拿到了结论，其实只拿到了假象。**

最典型的一个：代码读起来全对、逻辑通顺、变量名清晰，跑起来就是错。
所以后来我给自己定了条最硬的规矩——**"源码合规"不等于"运行正确"**。改完任何显示或计算逻辑，必须把库里的真数据取出来、手工算一遍、跟界面上的数字对。对不上就不算修好。
这些坑具体怎么发现的、AI 怎么骗过我、后来用什么机制拦住，**详细情况后续系列第 2 篇会详细说**。这里只留一个提醒：**当一个 AI 跟你说"修好了"的时候，它可能真的只是"代码看起来对了"。**


----
## 第七节：诚实说一下它现在的样子

我不想把这篇写成"一个月做出一个神器"。
它现在的真实状态：
- ✅ 数据是完整的、可信的，能自己验算

- ✅ 7 个模块的界面都做完了，能跑

- ✅ 卖出规则的 7 类逻辑写完了，回测能出数

- 🟡 回测的胜率数据样本还不够，我还不敢按它下单

- 🟡 Baostock 时不时封 IP（好在换出口 IP 就能解封，月度校准层最近停过一次，已恢复）

- ⚪ 移动端没有，只能在电脑上用

**它现在是个"好用的记账和复盘工具"，还不是一个"能替我做决策的系统"。**
这个区别很重要，因为市面上很多文章会把这两件事混起来讲。


----
### 附：这套东西的工作方式

如果有人想照着做，最要紧的两条：
1. **先把需求文档写到"可判定"**。每一条都能被回答"做到了/没做到"，否则后面所有验收都是靠感觉。我的 PRD 有 2,300 多段。

1. **保留所有错误**。**doc/踩坑档案.md** 和 **doc/经验规则.md** 比代码重要——代码可以重写，错不记下来就会再犯一次。

一个不懂后端的产品经理，和一个会写代码但会撒谎的 AI，花了一个月把这件事做出来。本文所有数字都是写稿当天从真库里现取的，不是文档里抄的。这是系列第 1 篇。 五篇的题目和分工：

我用 WorkBuddy 搭了个 A 股工作台，库里躺着 740 万条 K 线 #WorkBuddy#

一个不懂后端的产品经理，用 WorkBuddy 花一个月做了一个离线零依赖的 A 股工作台：36 张表、740 万条日线、5,786 只股票，全落在一个 1.79 GB 的本地 SQLite 里。本文只讲一件事——数据怎么进去的：五个数据源判死四个、被服务端封 IP 后怎么解封、11 批灌数怎么做到断了只丢 10 只。含全部实测数字与踩坑过程。

人工智能

740万条A股K线、36张表、5786只股票，一个不懂后端的产品经理靠AI花一个月自建离线工作台。本文揭秘数据灌入全流程：四个数据源如何用“连续10次成功”标准判死、被封IP后如何换出口IP解封、断点续跑与整表原子替换双保险机制，以及80条踩坑档案背后的静默错误教训。

数据接口

数据库

服务器

WorkBuddy 

SQLite

DHCP

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我用 WorkBuddy 搭了个 A 股工作台，库里躺着 740 万条 K 线 #WorkBuddy#-腾讯云开发者社区-腾讯云

我用 WorkBuddy 搭了个 A 股工作台，库里躺着 740 万条 K 线 #WorkBuddy#

我用 WorkBuddy 搭了个 A 股工作台，库里躺着 740 万条 K 线 #WorkBuddy#

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐