先立规矩，后写代码一套 A 股盘后监控系统的开发实录与方法论

如何开发一个在线更新的 A 股筛选器？网上的教程大多教到「装个行情库、写个循环、把选出来的票打印出来」就收工了。可真要它每天收盘后自己更新、挂在网上给别人看、一用好几年，问题马上就变了：数据源当天没入全怎么办？需求方没说清的口径谁来定？改了一行代码，线上跑的是哪一版？半夜断网，补到一半的历史还算不算数？

这篇就从这几个问题出发。答案有一半在代码里，另一半在代码之外。

01 · 开门见山：系统不是写出来的，是管出来的

先说结论：一个靠 AI 写代码的项目，真正的瓶颈从来不是代码，而是管理代码进入现实世界的那道门。

故事很朴素。一位做了多年 A 股的朋友，手里有一套看盘的老经验，凝成一张表：小、中、大三档市值，温和与强两种启动信号，换手率、量比、振幅、收盘形态、突破位置等六个条件，每个条件一档一档的阈值。他的诉求也简单：每天收盘后，帮我把符合条件的票挑出来，别让我一只只翻。

三周后，这张表长成了这样一套东西：

写代码的主力是 AI：一个主会话负责规划、调度、验收和归档，若干子 agent 分头写各模块和测试，另请一家不同来源的模型只读审查。人只做四件事：转达需求方原话、定口径、验收点头、亲手按部署键。

这篇不讲 A 股，讲的是这三周里摔过的跟头，和跟头摔出来的规矩。不以规矩，不能成方圆，老祖宗两千多年前就说透了。只不过这一回，规矩不是写给人看的，是写给人和 AI 一起遵守的，最硬的那几条，干脆写进了程序。

02 · 野蛮生长的六天：勤快救不了流程

10 月 7 日到 12 日，项目跑得飞快。启动信号、历史回看、估值与公告建档、全市场筹码线扫描、在线网站、每日一条龙、指数与板块状态表，一周之内接连上线。24 个提交，每一个都带测试。

看上去很勤快。说实在的，问题就出在这份勤快上。

12 日晚上做了一次复盘，拿后来定下的六个阶段逐项对照这 24 个提交，结论扎心：

这像一支技术不差、跑动积极的球队，没有阵型，也没有换人纪律。每个人都在拼，可球一丢，谁也说不清是谁的位置空了。勤快是美德，但勤快填不了流程的窟窿，只会让窟窿漏得更快。AI 写代码尤其如此：模型不累、不烦、出活极快，人一兴奋，就忍不住「先上去看看效果」。千里之堤，溃于蚁穴，线上的每一次「先看看」，都是一个蚁穴。

03 · 立规矩：六个阶段，各守各的边界

复盘当晚，规矩写进了项目入口文档。核心是一张六阶段表，每一步都写明做什么、边界在哪、交出什么：

但不是每个小改动都要走全套六步，否则规矩就成了枷锁。所以再按大小分三档，拿不准就往大的一档靠：

这张表里有几条看着不起眼，后来都证明是关键：

说明书不写在前面。 系统的使用说明就是网站上的一页，每天随数据一起发布。先把新功能写进说明书，需求方当晚就会读到一个还不存在的功能。先写的应该是需求单，说明书只能在验收通过、合入主干之后改，和功能同一次上线。

上线形式在需求单里定。 这个站是纯静态页，只有五类地方允许带脚本：阅读读数、表格排序、说明书点图放大、首页按日期定位、个股 K 线图。别处想加脚本、动画，就算改规矩，按「大」档处理，先出本地原型给负责人看。克制是一种设计：页面越朴素，出错的面越小。

点头即授权。 负责人在第 4 步点头，就是第 5 步合入和部署的授权，不用再问第二遍。规矩要防的是失控，不是要人反复说 yes。

要求变了，回到第 1 步。 需求方的想法会反复，会越挖越深，这再正常不过。可一旦在开发途中边做边改口径，需求单就成了废纸。改需求单只要几分钟，却能让后来的每一步都知道自己在对什么标准干活。

04 · 规矩要长出牙齿：把闸门写进程序

写在文档里的规矩，靠的是自觉。人会忘，模型在长对话里也会漂移，熬到凌晨两点，谁都有「就这一次」的时候。所以最硬的几条，直接写进了程序。

闸门一：未提交不部署。 部署命令开头先查 git：程序、配置、说明书这三处只要有未提交的改动（包括已暂存的、新增未跟踪的），就拦住，日志列出是哪几个文件，网站不更新。为什么只查这三处？因为它们决定线上长什么样；写一行开发笔记、改一个测试，不该让当天的网站停更。最要紧的一条是：有意不做绕过开关。留了后门的闸门，迟早会被走成大门。

闸门二：数据骤降即拦截。 每天会变的只有上游数据，所以发布前只设一道数据自检：今天全市场的股票只数，比前一个交易日少了超过 5%，就拦住发布，弹一条通知，等人核对。防的是数据源当天还没入全、只返回一部分股票，程序却把这天记成「已同步」，名单从此永久少一截，而且没有任何提示。这个阈值不是拍脑袋：500 个交易日里单日最大降幅只有 0.48%，日常波动碰不到 5%；而 2015 年 7 月千股停牌那几天会被拦下，核对后人工放行，属于预期之内。

两道闸门之外，还有一条贯穿每日流程的铁律：任何一步没做成就停下，宁可今天不更新，也不发布半截结果。

这里有个分寸：情绪、宽度、榜单、资金这些附加页面，出错只告警，不拦主流程。不能因为一页图表坏了，就让主名单也发不出去。该硬的地方要硬，该软的地方要软，这跟铁路信号一个道理：主干道的红灯必须停，侧线上的故障，挂个牌子绕过去就行。

立规矩的那一晚，规矩本身也按新规矩上线了一次。先写测试，再写闸门；验收时故意在工作区留了 3 个未提交的文件，直接跑部署，结果被拦住，日志列出 3 个文件，退出码 1，网站未更新。闸门第一次咬人，咬的是立规矩的人自己。这一口咬得好。

05 · 一口井，多根管：架构上的克制

10 月 18 日那一轮最大的手术，是把全市场行情抽成一个公共行情层。

在此之前，筹码线、指数板块、情绪各自去数据源取一份行情，各存各的。三张指数表里，同一个指数同一天的收盘可能来自三次不同的请求。这就像一个村子每户自己打井：水质对不对得上，全看运气。

手术之后，整个系统变成了星形：

最后一行值得多说一句。今天随手 pip install 一个库，几乎没有成本；可一个每天都要跑、要跑很多年的系统，每一个依赖都是一笔利息不明的长期贷款。唯一的例外是个股 K 线图用的图表库：它随站发布、不引外部地址，入库时核对 npm 包的 sha512，站点每次组装时再核对一遍 sha256，不符即中止。依赖不是不能有，而是要有就得认得清、锁得住。

公共层建好后，历史也一口气补到了 2015 年：约八千次接口调用，连续跑了一夜。中途网络断开两次，订阅额度撞到五小时上限停过一次，终端崩溃过一次。每一次都从日志里判断进度，从断点续上，没有丢一行数据。长任务必须可续传、自动重试、写日志，这条经验是那一夜一刀一刀刻出来的。

06 · 证据压倒自信：五道对拍

AI 写代码最大的陷阱，不是写错，而是写得像对的。测试全绿、页面好看、数字合理，偏偏某个角落差了一点，而这一点肉眼看不出来。

所以这个项目的验证，核心不是「测试通过」，而是对拍：拿一份独立的答案，逐位比对。

几个故事，比数字更能说明问题。

基准逐字节比。 重构公共层之前，先用旧代码把筹码线的全部产物出一份，存作「对照答案」。重构、补历史之后逐字节比：505 天里 501 天一字不差。差的 4 天，每天各多出 1 只股票，查下去全是同一个原因：旧起点下，停牌股的 K 线只有 93 到 100 根，不够公式要的 101 根；起点拉到 2015 年，够数了。差异不可怕，可怕的是说不清差异从哪来。

拿需求方的截图对拍。 均线通道那一轮，需求方深夜只发来一段通达信公式和 7 张截图，没有一个字的说明。没有去猜他要什么，而是先用库里的数据把 7 只股票的三条线复算一遍，读数逐一对上；再把截图上红箭头的位置，和计算出的「最低价回踩下轨」的事件段逐只对照，也对上了。意图从猜测变成了证据。更关键的一步在后面：如果只看当天碰没碰下轨，恰好会漏掉他举的三个例子，因为它们前一天碰轨、当天已经大阳离开。「回看 5 日」这个口径，就是这样从需求方自己的例子里推出来的。

同源逐位比。 个股 K 线图上画的三条线，和均线通道名单表上的数，用的是同一个算法。照理说不该有差，可测试用的是「近似相等」，偏偏放过了 .xxx5 这种舍入边界。改成 1,423 只股票的字符串逐一比，才抓出 5 只差了 0.001。根子在浮点：一边用前缀和，一边直接求和，最后一位四舍五入的方向不同。改用精确求和之后，已上线的名单逐字节不变，新图与表 0 差异。

换一家模型来挑刺。 审查不让写代码的同一家模型自己审，而是请一家不同来源的模型，只读审查，放在验收之前。几轮下来累计提出 40 余条问题，每一条都在真实库上复现属实，没有一条误报。其中最有分量的一条，是第一轮就抓到的：宽度模块的缓存，会把重拉或换了成份之后的旧读数发布出去。这类问题页面上看不出来，验收时根本发现不了。还有一条更直接：均线通道页上写的「停牌 32 只」，当天就是错的，应该是 3 只。

审查方也会掉链子。K 线图那一轮，第一家审查模型读完代码，撞上用量上限，没交清单。于是同一份委托书改派另一家，以只读模式审完，事后再查工作树，确认它没有改动一个文件。审查方要有备份，这条也是撞出来的。

测试管得住你想到的，对拍管得住你没想到的。两者缺一不可。

07 · 不替人拍板，也不反复追问：口径台账

需求方给的是一张经验表，经验表天然有空白。「大阳线配温和档的量能，算什么？」「市值分档用总市值还是流通市值？」「宽度的分母含不含停牌股？」这些问题，需求方没说，程序又不能不跑。

两种常见的处理都不对：替需求方拍板，等于把自己的理解偷偷塞进他的系统；每遇到一个就去追问，人家只是想看个名单，不是来陪你开需求会的。

这个项目的做法是第三条路：每个说不清的口径，都做成配置项、给一个默认值，记进台账。

10 月 18 日那一轮，台账记了 34 项：需求方定 13 项，负责人定 13 项，其余自查。当天下午需求方一口气回复了 12 条口径，两小时内全部落地，几乎只改了配置。启动信号那个最大的悬案，大阳线配温和量能算什么，至今没定，程序就老老实实标成「待定」，单列出来供人判断，绝不擅自归档。

台账的价值不在于记得全，而在于谁定的、默认是什么、改了重跑什么，一眼就能看清。它把「需求没说清」从一种焦虑，变成了一张可以慢慢清的账。

08 · 人机分工：agent 干活，人按按钮

这套方法里，人和 AI 的分工是这样的：

其中最有意思的一条是部署由人亲手执行。合入主干、生成站点、核对产物，这些 agent 都做好了，最后那条部署命令，交给负责人在终端里自己敲。这不是对 AI 的不信任，而是让「上线」这个不可逆的动作，始终有一个人类的手指按在上面。半自动，不是因为做不到全自动，而是有意留三分摩擦。

这一套跑下来，账是这样算的：

其中两点值得单独说。

缓存才是大头。 九成以上的 token 是缓存读取，如果不用缓存、全部按基础输入价计，同样的工作量大约要贵十倍。长项目里，让上下文稳定、可缓存，本身就是省钱的工程。

效率提升几成，不知道。 开发过程中做过一次换算：同样的 token 量，按半年前的模型单价算，Claude 这一侧约贵一倍。但这只是单价差，不是效率差。旧模型可能要多走几轮、多返工，开发工具本身也在变，规矩本身又省掉了大量返工，混在一起拆不开。要可信的数，只能拿同一份需求单让新旧模型各做一遍。没做之前，任何「提升几倍」的说法都是猜。

09 · 摔过的跟头，都要记下来

方法论不是一路顺风写出来的。这三周里摔过的跟头，每一个都换来了一条规矩或一个习惯：

最后一条值得多说一句。均线通道上线前，所有测试都绿着，可在浏览器里一点，默认排序把一路暴跌、远在下轨之下的票排在了最前面；日期列点了不排，因为解析函数只认出了年份。这些问题测试不会发现，因为测试只检查程序有没有照设计做，不检查设计本身合不合人意。验收这一步必须有人，有眼睛，有手。

还有一条，是整个过程中最打动人的：承认不知道。成本报告里写「效率提升几成不知道」，台账里写「这一项需求方没说，我们先按默认做」，审计报告里给每个推算的数字标上「推算」。一个系统最可贵的品质，不是永远正确，而是你永远知道它在哪里可能不对。

10 · 举一反三：四根柱子，一副地基

把这三周的经验收拢，是这样一座屋子：

这五件事，单拎出来没有一件新鲜。需求单、发布闸门、特征测试、配置化，软件工程教科书里早就写过。新鲜的是语境：当写代码的成本被 AI 压到接近于零，这些老规矩的价值不降反升。从前写代码慢，慢本身就是一种闸门，人在敲键盘的间隙里自然会想一想；现在代码几分钟就出来，这道天然的闸门没了，只能靠人造的闸门补上。

工欲善其事，必先利其器。可器已经利到这个程度了，下一步要修的，是用器的规矩。

11 · 尾声：规矩是给自由修的路

回头看那张最初的阈值表，它现在还在系统的最深处，六个条件，三档市值，一个字没改。系统长大了十倍，可需求方最初的那份经验，被原封不动地供在那里，所有没说清的地方都记在台账上，等他来定。

这或许就是规矩的意义。它不是捆住手脚的绳子，而是让人敢跑快的路。有了闸门，才敢让 agent 放手去写；有了对拍，才敢在一夜之间重构整个数据底座；有了台账，才敢对需求方说：你没想好的，我们先替你记着，不替你决定。

从前写代码慢，规矩是一种奢侈。如今代码写得飞快，规矩成了刚需。也许下一个阶段，连规矩本身也会由 AI 来提议、由人来拍板。那就是另一篇文章了。

文中系统只做筛选与记录，不做收益回测，不构成任何投资建议。文中数字截至 2026-10-21，取自项目内部审计记录。