1. 项目缘起与核心问题拆解
1.1 一个“零服务器”的自动化复盘系统到底在解决什么
每天收盘后手动翻看几十只自选股的涨跌、成交量、资金流向，再写一段复盘笔记，这件事我坚持过不到两周就放弃了。不是懒，是重复劳动太消耗精力，而且人脑在盘后容易受当天情绪影响，涨了过度乐观，跌了过度悲观，复盘质量极不稳定。后来接触到一类开源项目，核心思路就是用一套脚本把“数据抓取、指标计算、AI点评、结果推送”串成流水线，每天定时跑一次，全程不需要自己维护一台常驻服务器。标题里提到的这个项目就是典型代表，它在开源社区积累了相当高的关注度，说明“自动复盘”这个需求是真实且普遍的。
所谓“零服务器”，并不是真的没有计算资源，而是指不需要你租一台云主机7×24小时开着。实现方式通常是借助代码托管平台自带的定时任务能力，比如在仓库里配置一个工作流文件，设定每天固定时间触发脚本执行。脚本跑完把结果写回仓库或者推送到某个通知渠道，整个过程按需启动、用完即走。对于个人投资者或者小团队来说，这种模式省去了服务器运维成本，也不用担心机器宕机导致任务中断。我第一次看到这种玩法时觉得挺巧妙，因为它把“定时调度”这个原本需要运维知识的事情，降维成了一个配置文件的事。
这个项目要解决的核心问题可以拆成三层。第一层是数据自动化，每天定时拉取行情数据、财务数据、公告信息，不需要人工复制粘贴。第二层是分析自动化，用预设的规则和指标对数据做初步筛选，比如均线突破、成交量异动、估值分位等。第三层是表达自动化，把分析结果交给大语言模型生成一段可读的复盘文字。第三层是最容易出问题的环节，也是标题里“防止AI乱喊单”这个说法的由来。AI模型在金融场景下如果没有约束，很容易生成模棱两可或者过度自信的表述，比如“明天必涨”“强烈建议买入”这类话，既不负责任也容易误导人。所以这个项目的价值不仅在于“自动”，更在于“可控地自动”。
适合参考这个项目的人群其实比想象中广。如果你是有一定编程基础的个人投资者，想搭建自己的复盘工作流，可以直接借鉴它的架构。如果你是量化交易的初学者，想了解如何把数据管道和AI接口串起来，这个项目是一个很好的练手样本。甚至如果你只是对“定时任务+AI生成”这种组合感兴趣，想用在其他领域比如每日新闻摘要、竞品监控，它的设计思路同样可以迁移。前提是你愿意花一点时间理解它的配置逻辑，而不是指望开箱即用、一键暴富。
1.2 为什么“防止AI乱喊单”成了关键卖点
大语言模型在金融文本生成上的能力有目共睹，它能快速把一堆数字转化成通顺的段落，也能根据上下文给出看似合理的判断。但问题恰恰出在“看似合理”上。我做过一个小实验，把同一组行情数据分别用三种不同的提示词喂给模型，第一种问“这只股票怎么样”，第二种问“这只股票有哪些风险”，第三种要求“只陈述数据事实，不做涨跌判断”。结果第一种回答里出现了“短期有望走强”这种模糊的乐观表述，第二种回答又过度强调风险，第三种最克制但读起来像流水账。这说明模型的输出高度依赖提示词的设计，如果没有明确的约束，它就会按照训练数据里的常见模式去“喊单”。
这个项目在社区里被反复讨论的一个点，就是它如何通过工程手段来限制AI的自由发挥。我梳理下来主要有几个层面。第一个层面是输入约束，传给模型的不是原始行情数据，而是经过计算的指标结果，比如“收盘价高于20日均线”“成交量是过去5日均量的1.8倍”，这些是客观事实，模型没有太多发挥空间。第二个层面是提示词模板，在系统提示里明确要求“只做数据陈述和逻辑推演，不给出买卖建议”，并且用 few-shot 示例告诉模型什么样的输出是合格的。第三个层面是输出后处理，对模型返回的文本做关键词过滤，如果出现“必涨”“满仓”“梭哈”这类词就替换或者截断。这三个层面叠加起来，才能把AI的“乱喊单”概率压到一个可接受的水平。
我自己的体会是，完全杜绝AI的主观判断很难，因为语言模型本质上就是在做概率生成，你很难用规则穷举所有可能的“越界”表述。但你可以通过结构化输入和严格的输出模板，把它的发挥空间压缩到“描述性分析”这个范围内。比如要求它必须按照“今日行情概述→资金流向分析→技术指标解读→风险提示”这个固定结构来写，每个部分只允许引用给定的数据，不允许引入外部信息。这样即使它想喊单，也没有合适的句式位置。这个思路其实和写研报的合规要求很像，不是不让说话，而是规定好说话的框架。
2. 系统架构与核心模块拆解
2.1 零服务器方案的底层逻辑与选型考量
“零服务器”这个说法容易让人误解，以为整个系统跑在某种无服务器的计算环境里。实际上更准确的理解是：调度层托管在代码平台上，计算层按需启动，存储层用仓库本身或者轻量数据库。我拆解过几个类似项目，它们的共同点是都依赖代码托管平台提供的定时工作流功能。你只需要在仓库里放一个配置文件，声明触发时间和执行命令，平台就会在指定时间拉起一个临时容器来跑你的脚本。脚本执行完毕后容器销毁，不产生持续费用。对于每天只跑一次、每次几分钟的任务来说，这种模式比租一台最低配的云主机还划算，而且省去了系统更新、安全补丁这些琐事。
选型上有一个关键决策：数据存在哪里。常见方案有三种。第一种是直接写回仓库，比如把每天的复盘结果存成 Markdown 文件提交到指定目录。优点是简单、可追溯、天然有版本记录，缺点是仓库会越来越大，而且频繁提交可能触发平台的风控。第二种是用轻量云数据库，比如一些免费额度的文档型数据库，优点是查询灵活，缺点是需要管理连接凭证，增加了配置复杂度。第三种是只推送到通知渠道，比如邮件或者群机器人，本地不留存。这个项目我印象中采用的是第一种和第三种结合，既在仓库里保留历史记录，又推送到即时通讯工具方便查看。对于个人使用来说，这种组合足够务实。
还有一个容易被忽略的细节是时区处理。定时任务平台通常默认使用协调世界时，而A股复盘需要在收盘后、北京时间下午六点左右执行。如果你直接写“每天18点”，平台可能理解成协调世界时的18点，对应北京时间凌晨两点，那就完全跑偏了。所以配置文件里必须显式指定时区，或者在脚本里做时间转换。我见过有人踩过这个坑，任务确实每天跑了，但跑出来的数据是前一天的，因为触发时间对应的是北京时间半夜，当天行情还没开始。这种问题排查起来很费时间，因为日志显示任务成功执行，只是数据不对。
2.2 数据抓取层的稳定性设计
数据抓取是整个流水线的第一环，也是最容易出问题的一环。免费数据接口通常有频率限制、字段缺失、偶尔抽风的特点。如果脚本没有做好容错，某一天接口返回空数据，后面的分析和推送就会全部失败，你收到的可能是一封空白邮件或者一段“今日无数据”的废话。这个项目在社区讨论中被提到的一个改进点，就是给数据抓取加了重试机制和降级策略。具体来说，主接口失败时自动切换备用接口，备用接口也失败时使用上一次成功抓取的数据做占位，并在输出里明确标注“数据可能滞后”。这种设计思路值得借鉴，因为复盘的核心是连续性，偶尔一天数据不准可以接受，但完全断掉会破坏习惯。
抓取频率也需要控制。有些新手会写一个循环，对自选列表里的每只股票逐个请求，中间不加延时。这样做在股票数量少的时候没问题，一旦自选池超过五十只，很容易触发接口的限流，导致后面一半的请求全部失败。合理的做法是批量请求，很多接口支持一次传入多个代码，返回一个数组。如果接口不支持批量，那就需要在请求之间加一个短暂的等待，比如每请求五次暂停一秒。这个等待时间需要根据接口的实际承受能力来调整，没有统一标准，只能实测。我一般会先小批量测试，观察返回状态码，如果出现429或者超时，就加大间隔。
数据清洗是另一个关键步骤。原始行情数据里经常有停牌、涨跌停、除权除息这些特殊情况，如果不做处理直接算指标，结果会失真。比如某只股票当天停牌，收盘价沿用前一交易日，成交量是零，如果你用这个数据去算“成交量是否放大”，就会得出错误结论。所以脚本里需要有一个过滤逻辑，把停牌、一字板这些异常样本标记出来，在后续分析中单独处理或者直接跳过。这个细节在项目文档里可能不会写得很细，但实际使用中一定会遇到。我的经验是，在数据抓取之后、指标计算之前，加一个“数据质量检查”环节，对每个字段做空值、零值、极端值的判断，不通过的样本打上标记，后续分析时区别对待。
2.3 AI分析模块的提示词工程与约束机制
这是整个项目最核心也最微妙的部分。大语言模型在金融文本生成上的表现，很大程度上取决于你怎么“问”它。我对比过几种常见的提示词设计思路。第一种是“角色扮演式”，告诉模型“你是一个资深分析师，请对以下数据发表看法”。这种写法容易让模型进入“表演模式”，生成一些听起来专业但缺乏数据支撑的判断。第二种是“任务指令式”，直接说“请根据以下数据，按照给定模板生成一段复盘文字，不要添加任何未在数据中出现的信息”。这种写法更克制，输出也更可控。这个项目采用的是第二种思路，并且在系统提示里反复强调“只陈述事实、只做逻辑推演、不给出操作建议”。
提示词模板的结构也很讲究。我见过一个设计得比较好的模板，它把输出分成四个固定段落，每个段落都有明确的写作要求。第一段“行情概览”要求用一句话概括指数涨跌和成交量变化，只能引用给定的数字。第二段“板块异动”要求列出涨幅前三和跌幅前三的板块，并说明是否有连续性。第三段“个股跟踪”要求对自选池里涨跌幅超过阈值的个股做简要点评，点评内容必须包含至少一个技术指标。第四段“风险提示”要求列出当天出现的异常信号，比如放量下跌、跌破关键均线等。这种结构化模板的好处是，模型没有空间去自由发挥“喊单”，它只能在这个框架里填充内容。
输出后处理是最后一道防线。即使提示词写得再严格，模型偶尔还是会冒出一些越界表述。常见的做法是维护一个敏感词列表，比如“必涨”“翻倍”“满仓”“抄底”“逃顶”这些词，一旦检测到就替换成中性表述或者直接删除整句。更精细的做法是用正则表达式匹配“建议买入”“强烈推荐”这类句式，把它们改写成“数据显示”“指标呈现”这样的客观描述。我自己的经验是，敏感词列表需要持续维护，因为模型的表达方式会随着版本更新而变化，今天过滤掉的词明天可能换个说法又出现了。所以这个环节不能一劳永逸，得定期检查输出样本，发现新的越界表述就补充到列表里。
3. 实操部署与关键环节实现
3.1 从零搭建的完整步骤与配置要点
假设你从零开始，想复现一套类似的自动复盘系统，我建议按照以下顺序推进。第一步是明确自选池和复盘维度。不要一上来就追求全市场覆盖，那样数据量和计算量都会失控。先选二十到三十只你真正关注的标的，确定你要跟踪的指标，比如均线、成交量、换手率、市盈率分位。第二步是跑通数据抓取。写一个最简单的脚本，只做一件事：拉取自选池的当日行情，打印出来。确认数据字段完整、格式正确、没有乱码。第三步是加入指标计算。用 pandas 或者类似的库，对原始数据做滚动计算，生成均线、量比、涨跌幅等衍生指标。第四步是接入AI接口。先用固定的示例数据测试提示词模板，观察输出是否符合预期，反复调整直到稳定。第五步是配置定时任务。把脚本提交到仓库，写好工作流配置文件，设定触发时间。第六步是接入通知渠道。把最终结果推送到你常用的工具，确保每天能收到。
配置定时任务时，有几个参数需要特别注意。触发时间建议设在收盘后半小时到一小时之间，给数据接口留出更新缓冲。太早可能拿到的是盘中数据，太晚则失去了“当日复盘”的时效性。执行超时时间要设置合理，如果脚本需要抓取大量数据或者调用AI接口，几分钟可能不够，建议先手动跑一次记录耗时，然后在此基础上留出百分之五十的余量。环境变量里要存放敏感信息，比如AI接口的密钥、通知渠道的令牌，不要直接写在代码里。仓库的权限设置也要检查，如果仓库是公开的，提交历史里的数据可能会被其他人看到，涉及个人持仓的信息需要谨慎处理。
3.2 定时触发与结果推送的细节处理
定时触发看起来简单，实际有几个坑。第一个坑是任务并发。如果你配置了多个工作流，或者同一天手动触发了一次又等到了定时触发，可能会出现两个任务同时跑的情况。如果它们都要写同一个文件或者调用同一个接口，就可能冲突。解决办法是在脚本开头加一个简单的锁机制，比如检查某个标记文件是否存在，存在就退出。第二个坑是失败通知。定时任务失败时，平台通常会发邮件给仓库所有者，但如果你不常看邮箱，可能几天后才发现任务挂了。更好的做法是在脚本里加异常捕获，一旦出错就通过通知渠道发一条告警，这样你能第一时间知道。
结果推送的格式也值得琢磨。纯文本的复盘内容在手机上看还行，但如果包含表格和指标对比，纯文本就很乱。我试过几种方案。一种是生成 Markdown 格式，推送到支持 Markdown 渲染的工具，阅读体验最好。另一种是生成图片，用绘图库把关键指标画成图表，直观但增加了依赖。还有一种是生成 HTML 邮件，排版自由但容易被邮箱归类为垃圾邮件。这个项目采用的是 Markdown 加关键数据表格的组合，在简洁和可读之间取了平衡。我的建议是，推送内容不要贪多，把最重要的三到五个结论放在最前面，详细数据放在后面或者只保留在仓库里。毕竟你每天看的是结论，不是原始数据。
还有一个细节是历史记录的归档。每天的结果如果只推送不保存，过一段时间想回看就找不到了。把结果按日期命名存到仓库的指定目录，是一个简单有效的做法。文件名可以用“年份-月份-日期.md”的格式，方便排序和检索。如果担心仓库体积膨胀，可以设置一个清理策略，比如只保留最近半年的记录，更早的自动删除或者转移到其他存储。这个策略可以根据你的实际需求调整，但一定要有，否则一年后仓库里堆了几百个文件，管理和克隆都会变慢。
3.3 防止AI越界的工程化手段实录
我在自己的实践中总结了几条约束AI输出的经验，和这个项目的思路有重合也有补充。第一条是数据与判断分离。让AI只负责把数据翻译成自然语言，判断逻辑由代码里的规则来完成。比如代码判断“收盘价高于20日均线且成交量放大”，然后告诉AI“请描述以下事实：该标的收盘价位于20日均线上方，成交量为5日均量的1.8倍”。AI的任务只是把这句话润色得更通顺，而不是自己去判断这意味着什么。这样做的好处是，判断标准是确定的、可回溯的，不会因为模型版本更新而改变。
第二条是输出模板的强约束。不要给AI自由发挥的空间，而是给它一个填空式的模板。比如“今日自选池中，上涨X只，下跌Y只，其中涨幅最大的是___，跌幅最大的是___，成交量异动的是___”。AI只需要把下划线部分填上，其他文字都是固定的。这种模板看起来死板，但胜在稳定可控。你可以准备多个模板，根据当天的市场情况选择不同的模板，比如大涨日用一个模板，大跌日用另一个，震荡日再用一个。这样既保证了结构统一，又避免每天读起来一模一样。
第三条是人工抽检机制。完全依赖自动化是有风险的，我建议每周至少抽一天，把AI生成的复盘内容和原始数据做一次人工比对，看看有没有事实性错误或者越界表述。这个习惯帮我发现过好几次问题，比如某天AI把“下跌”写成了“上涨”，原因是数据字段的符号处理有误。如果完全不看，这种错误可能持续很久才被发现。抽检不需要花太多时间，十分钟足够，但能显著提升系统的可信度。
4. 常见问题与排查技巧实录
4.1 任务执行失败的高频原因与速查表
| 问题现象 | 可能原因 | 排查方法 | 解决思路 |
|---|---|---|---|
| 任务未触发 | 时区配置错误 | 检查工作流文件中的时区设置 | 显式指定目标时区，或改用协调世界时换算 |
| 任务触发但秒退 | 依赖未安装 | 查看执行日志中的报错信息 | 在配置文件中补充依赖安装步骤 |
| 数据为空 | 接口限流或变更 | 手动请求接口查看返回状态码 | 增加重试、切换备用接口、调整请求频率 |
| AI输出乱码 | 编码问题 | 检查脚本文件编码和接口返回编码 | 统一使用UTF-8，必要时做编码转换 |
| 推送未收到 | 令牌过期或渠道变更 | 检查通知渠道的令牌有效期 | 更新令牌，确认渠道配置未变 |
| 结果重复 | 任务并发执行 | 查看是否有多次触发记录 | 加锁机制，避免同一时间多个实例运行 |
这张表里的问题我几乎都遇到过。最让人头疼的是“任务触发但秒退”，因为日志可能只显示一行“exit code 1”，没有更多信息。这时候需要把脚本的日志级别调高，或者在关键步骤前后加打印语句，逐步定位是哪一行出的问题。另一个常见问题是接口返回的数据结构变了，比如原来字段叫“close”，现在改成了“closing_price”，脚本读取不到就报错。这种问题只能通过定期检查数据字段来预防，或者在脚本里加一个字段校验，发现缺失就发告警。
4.2 数据异常与AI输出偏差的处理经验
数据异常里最常见的是停牌和涨跌停。停牌股票没有成交，所有基于成交量的指标都会失真。涨跌停股票的价格波动被限制，技术指标也会钝化。我的处理方式是在数据清洗阶段给这些样本打标签，在后续分析中单独归类。比如在复盘输出里加一句“今日自选池中有X只停牌、Y只涨跌停，相关指标未纳入统计”。这样既保证了数据的准确性，也让读者知道哪些标的被排除了。如果不做这个处理，AI可能会对一只停牌股票生成一段“今日无成交，建议关注”的废话，浪费篇幅。
AI输出偏差主要有三种表现。第一种是事实性错误，比如把跌幅写成涨幅，把行业分类搞混。这种通常是因为输入数据本身有问题，或者提示词里的示例有误导。解决办法是加强数据校验，并且在提示词里明确“所有数字必须与输入数据完全一致，不得修改”。第二种是过度解读，比如从“成交量放大”推导出“主力资金进场”。这种需要靠敏感词过滤和输出模板来约束，把“主力”“进场”这类词加入过滤列表。第三种是格式错乱，比如该分段的地方没分段，该用表格的地方用了纯文本。这种通常是提示词模板不够明确，需要把格式要求写得更具体，甚至给出一个完整的输出示例。
我自己的经验是，AI输出的问题很难一次性解决，需要持续迭代。建议每次发现新的问题，就记录下来，然后针对性地调整提示词或者过滤规则。不要指望调一次就完美，把它当成一个需要长期维护的系统。另外，保留每次的输入数据和输出结果，方便回溯问题。如果某天输出特别离谱，你可以翻出当天的输入，看看是数据的问题还是提示词的问题。这种记录习惯在排查复杂问题时特别有用。
4.3 长期运行中的维护要点与避坑清单
系统跑起来之后，维护比搭建更重要。我列几个长期运行中容易忽略的点。第一是接口凭证过期。很多免费接口的令牌有有效期，短则一个月，长则半年。到期后接口返回鉴权失败，任务就会中断。建议在日历里设一个提醒，提前一周更新令牌。或者写一个检查脚本，每天跑任务前先验证令牌有效性，失效就发告警。第二是依赖库版本冲突。Python 生态更新快，某个库升级后可能和其他库不兼容。建议锁定依赖版本，不要用“最新版”，而是在配置里写死版本号。第三是仓库体积膨胀。每天提交一个文件，一年就是三百多个，如果每个文件还包含大量数据，仓库会变得很大。定期清理旧文件，或者把历史数据转移到其他存储。
还有一个坑是过度依赖单一数据源。我见过有人只用一个免费接口，结果某天接口维护，整个复盘就断了。建议至少准备两个数据源，主源失败时自动切换。切换逻辑可以很简单，就是 try-except 包裹，主源抛异常就调用备源。备源的数据字段可能和主源不一样，需要在切换时做字段映射。这个工作量不大，但能显著提升系统的可用性。另外，AI接口也可能出问题，比如限流、超时、返回空结果。建议在调用AI之前先检查数据是否完整，数据不完整就直接跳过AI分析，只推送原始数据摘要，避免AI基于残缺数据生成误导性内容。
最后说一个心态上的坑。自动复盘系统是辅助工具，不是决策替代品。它帮你节省的是收集数据和整理信息的时间，但最终的判断还是得你自己做。我见过有人完全按照AI生成的复盘文字去操作，结果亏了钱回头骂系统。这其实是对工具定位的误解。系统输出的是“发生了什么”，不是“应该怎么做”。把这两者分清楚，你才能从这个项目里获得真正的价值。每天花五分钟看看系统推送的摘要，再花十分钟自己翻翻关键标的的走势，这个组合比完全依赖任何一方都更靠谱。
