零服务器自动复盘：如何防止AI乱喊单的工程实践

1. 从"AI 喊单"这个痛点说起：为什么自动复盘工具最怕的不是数据源，而是模型嘴瓢

做量化复盘工具的人，迟早会撞上同一个尴尬：你辛辛苦苦搭好数据管道、写好指标计算、跑通定时任务，结果模型在收盘后吐出一句"明日大概率高开，建议重仓介入"，你盯着屏幕半天不知道该笑还是该哭。这不是段子，这是绝大多数"AI 自动复盘"项目在真实使用中翻车的典型场景。

daily_stock_analysis这个项目之所以能攒到 6.6 万 Star，核心不在于它接了多少数据源、算了多少指标，而在于它把"防止 AI 乱喊单"这件事当成了一等公民来设计。标题里那句"零服务器每天 18 点自动复盘"，其实包含三个独立的技术命题：零服务器怎么跑定时任务、18 点这个时间点怎么卡准、复盘结论怎么不被模型带偏。前两个是工程问题，第三个是产品与提示工程的交叉问题，也是最容易被忽视、翻车代价最大的部分。

这篇内容适合三类人看：一是正在做自动化复盘/日报类工具、被模型输出稳定性折磨的开发者；二是想用零服务器方案跑定时任务、但不确定边界在哪的工程同学；三是单纯好奇"一个开源项目怎么把 AI 约束住"的产品和运营。我会把项目里最值得抄的几个设计拆开讲，包括时间调度、数据落盘、提示约束、输出校验这几条主线，也会把我自己在类似项目里踩过的坑一并摊开。

先说结论性的判断：自动复盘工具的质量上限，取决于你对模型输出的约束强度，而不是你喂给它的数据量。数据再多，模型一句"建议买入"就能让整个工具失去可信度。下面按模块拆。

2. 零服务器跑定时任务：18 点这个时间点到底该怎么卡

2.1 "零服务器"不是没有计算，而是把调度权交出去

很多人一听"零服务器"就以为是纯前端跑，其实不是。这类项目的典型架构是：代码托管在代码平台，调度交给平台的定时流水线能力，数据落盘到仓库或对象存储，通知走 Webhook。整条链路里没有一台你需要自己运维的常驻机器，但计算是真实发生的，只是发生在别人的 CI 容器里。

为什么这个方案对个人项目特别香？算一笔账：一台最低配的常驻云主机，一年成本大概几百到上千元不等，还要自己管系统更新、进程守护、日志轮转。而定时流水线方案，对于每天跑一次、单次几分钟的任务，基本落在免费额度内。成本差异不是重点，运维心智负担的差异才是——你不需要半夜起来看进程是不是挂了。

但这里有个前提必须说清楚：定时流水线适合"短时、幂等、无状态"的任务。如果你的复盘需要跑几十分钟的重计算，或者需要维护一个常驻的内存状态，那这套方案会很难受。daily_stock_analysis这类项目之所以适配，是因为它的单次复盘本质上是"拉数据 → 算指标 → 调模型 → 出报告"的线性流程，跑完即销毁，天然契合。

2.2 18 点卡点：为什么不是收盘就立刻跑

A 股收盘是 15:00，但项目把复盘时间定在 18:00，这个选择背后有实打实的工程考量，不是随便定的。

• 数据回补延迟：收盘瞬间很多数据源还没完成当日数据的清洗和入库，尤其是涉及资金流向、龙虎榜、北向这类需要盘后汇总的字段。15:30 去拉，经常拿到的是残缺数据或者前一日数据。
• 公告与资讯沉淀：盘后公告、机构研报摘要、财经资讯的集中发布窗口通常在 16:00 到 18:00 之间。18 点跑，能把这些文本信息一并纳入复盘上下文。
• 避开数据源高峰：收盘后半小时是各类接口的访问高峰，限流和超时概率明显上升。错峰到 18 点，接口稳定性会好很多。

提示：定时任务的 cron 表达式一定要按目标时区配置。很多平台的定时流水线默认走 UTC，如果你直接写0 18 * * *，实际触发时间是北京时间凌晨 2 点。正确做法是显式声明时区，或者把 UTC 时间换算好再填。

2.3 调度配置的实操细节与容错设计

具体到配置层面，我建议按下面的结构来组织，这套结构我在多个类似项目里验证过，稳定性不错：

# 伪配置示意，字段名按你所用平台的规范调整 schedule: cron: "0 18 * * 1-5" # 周一到周五 18:00 timezone: "Asia/Shanghai" # 显式声明时区，别省 timeout_minutes: 15 # 单次任务超时上限 retry: max_attempts: 2 backoff_minutes: 10

几个关键点展开说：

第一，交易日过滤。用1-5只能过滤周末，过滤不了法定节假日。更稳的做法是在任务开头加一道判断：拉取当日交易日历，如果不是交易日就直接退出，不消耗后续资源。这一步能省掉大量无效的模型调用。

第二，超时与重试。定时任务最怕的是卡死。设置 15 分钟超时，超时后自动终止，避免占用额度。重试次数不要给太多，2 次足够，因为数据源故障通常不是重试能解决的，给多了反而会触发限流。

第三，幂等性。同一天重复触发不能产生两份报告、不能重复推送通知。做法是用日期作为唯一键，落盘前先检查当天文件是否已存在，存在就跳过或覆盖。这个细节不做，某天平台抽风重跑一次，你的通知渠道就会被刷屏。

第四，失败要能看见。零服务器方案最大的隐患是"静默失败"——任务挂了但你不知道。务必配置失败告警，最简单的方式是任务异常时也发一条通知，内容写明失败原因。我见过太多项目，报告连着三天没出，作者第四天才发现。

3. 数据落盘与状态管理：没有数据库，怎么保证复盘可追溯

3.1 用文件系统当"轻量数据库"的取舍

零服务器方案通常没有独立数据库，数据落在仓库文件或对象存储里。这带来一个直接问题：历史复盘怎么查、怎么对比。

daily_stock_analysis这类项目的常见做法是按日期分目录存储，结构大致是：

reports/ 2024-01-15/ raw_data.json # 当日原始数据快照 indicators.json # 计算后的指标 analysis.md # 模型生成的复盘正文 meta.json # 运行元信息：耗时、模型、token 用量

这个结构的好处是可追溯。当某天报告结论离谱时，你能回查当天的原始数据和指标，判断是数据错了、指标算错了，还是模型自己跑偏了。没有这层留痕，排查就是无头案。

注意：原始数据快照不要只存处理后的结果。我踩过的坑是只存了指标，结果某天发现指标异常，却无法判断是数据源给错了还是计算逻辑有 bug，只能干瞪眼。原始数据和处理结果分开存，是排查的命根子。

3.2 状态文件的读写冲突怎么避免

定时任务如果支持手动触发，就可能出现两次运行同时读写同一份状态文件的情况。文件系统没有数据库的事务能力，并发写会直接损坏文件。

处理方式有两种，按复杂度递增：

• 加锁文件：运行前创建一个 lock 文件，结束时删除。检测到 lock 存在就退出。简单有效，但异常退出时 lock 可能残留，需要加过期时间。
• 日期分区 + 原子写：每次写入先写临时文件，写完再重命名覆盖。重命名在多数文件系统上是原子操作，能避免读到半截文件。

我一般推荐第二种，因为它同时解决了并发和"读到写了一半的文件"两个问题。实现上就是write to tmp → fsync → rename三步，代码量很小，收益很大。

3.3 历史数据的滚动清理策略

文件越堆越多，仓库会越来越臃肿，克隆和拉取都会变慢。需要一套清理策略：

清理逻辑放在每次任务开头执行，删旧不删新。注意清理操作也要幂等，重复执行不能误删。

4. 防 AI 乱喊单的核心：提示约束、输出校验与降级策略

4.1 为什么模型天生爱"喊单"

这是整篇内容最核心的部分。大语言模型在财经语境下有个强烈的倾向：它会把"分析"默认理解成"给建议"。你让它复盘今天的行情，它很容易滑向"明日关注 XX 板块""建议逢低布局"这类表述。

原因不复杂。训练语料里大量的财经内容本身就是带观点的，研报、股评、财经自媒体，绝大多数都在给结论。模型学到的是这个分布，所以它默认输出也带结论。你不主动约束，它就会喊单。

更麻烦的是，模型的"喊单"往往看起来很专业——有逻辑、有数据引用、有术语，普通用户很难分辨这是分析还是建议。这正是危险所在。

4.2 三层约束：系统提示、结构化输出、后置校验

daily_stock_analysis这类项目防喊单，靠的不是单一手段，而是三层叠加。我把这套思路整理成可复用的框架：

第一层：系统提示里的硬性禁令。

系统提示要明确列出禁止输出的内容类型，并且给出替代写法。光说"不要给建议"没用，模型不知道边界在哪。要具体到句式级别：

禁止输出以下类型的内容： - 任何形式的买卖建议（如"建议买入""可以关注""逢低布局"） - 任何形式的点位预测（如"明日支撑位在 XX""大概率高开"） - 任何形式的收益承诺或暗示 - 任何带有指令性的操作动词 允许输出的内容类型： - 对当日已发生行情的客观描述 - 指标数值及其历史分位 - 数据之间的相关性陈述（需注明"仅为统计观察，不构成因果"） - 已知事实的复述

关键在于给出正向清单。只给禁令，模型会陷入"这也不能说那也不能说"的混乱，输出质量反而下降。正负清单配合，边界才清晰。

第二层：结构化输出，把自由文本关进笼子。

让模型直接写一段自由文本，是最难约束的。更好的做法是要求它输出结构化字段，每个字段有明确的语义约束：

{ "market_summary": "客观描述当日指数与板块表现", "indicator_observations": [ {"name": "指标名", "value": 0.0, "percentile": 0.0, "note": "仅陈述数值与分位"} ], "anomalies": ["当日出现的异常数据点，仅描述现象"], "disclaimer": "固定免责声明文本" }

结构化之后，每个字段的职责被限定死，模型很难在market_summary里塞进买卖建议。而且结构化输出便于后续程序化校验。

第三层：后置校验，用规则兜底。

模型再听话也可能偶尔越界，所以必须有一道程序化的校验。做法是维护一个敏感句式词表，对模型输出做匹配扫描：

FORBIDDEN_PATTERNS = [ r"建议(买入|卖出|持有|加仓|减仓)", r"(可以|应该|不妨)(关注|布局|介入)", r"(明日|下周|后市).*(涨|跌|高开|低开)", r"(支撑位|压力位|目标价)", r"(稳赚|必涨|翻倍|抄底)", ] def validate_output(text: str) -> tuple[bool, list[str]]: hits = [] for pattern in FORBIDDEN_PATTERNS: if re.search(pattern, text): hits.append(pattern) return len(hits) == 0, hits

校验不通过怎么办？这就是降级策略要解决的问题。

4.3 校验不通过时的降级：宁可少说，不可乱说

降级策略的设计原则是：当模型输出不可信时，退回到纯数据呈现，而不是硬着头皮发出去。

具体分三档：

• 轻度越界（命中 1 个模式）：对命中片段做替换或删除，重新拼接输出，并在报告末尾标注"部分内容已做合规处理"。
• 中度越界（命中 2-3 个模式）：丢弃模型生成的文字部分，只保留结构化数据和指标，报告退化为"数据日报"。
• 重度越界（命中 3 个以上，或出现明确买卖指令）：整份模型输出作废，只发一条"今日复盘生成异常，已跳过"的通知，附带原始数据链接供人工查看。

提示：降级策略一定要在提示里就告诉模型，让它知道"越界会导致输出被丢弃"。这种"后果前置"的提示，对降低越界率有实测效果。模型在知道输出会被校验的情况下，自我约束会更强。

4.4 温度参数与采样策略：别让模型太"兴奋"

除了提示和校验，生成参数本身也影响喊单倾向。经验值：

• temperature 调低，一般 0.2 到 0.4 之间。温度越高，模型越倾向于生成"有观点"的内容，喊单概率上升。
• top_p 收紧，0.8 左右，减少长尾采样带来的意外表述。
• 避免使用鼓励"创造性"的系统提示词。有些模板喜欢写"你是一位富有洞察力的分析师"，这种措辞会诱导模型输出观点。改成"你是一位严谨的数据记录员"，输出风格会明显收敛。

这几项参数调整，成本几乎为零，但对输出稳定性的提升很直接。我自己的项目里，把 temperature 从 0.7 降到 0.3 之后，越界率大概降了一半以上。

5. 通知推送与报告呈现：怎么让复盘"有用但不越界"

5.1 推送渠道的选择与内容裁剪

复盘报告生成后要推送出去，常见渠道是 Webhook 到群机器人。这里有个容易忽略的点：推送内容要裁剪，不能把完整报告直接塞进去。

原因有两个。一是群消息有长度限制，长报告会被截断，截断位置不可控，可能正好截在敏感句子上。二是群消息是"扫一眼"的场景，塞太多反而没人看。

我的做法是推送一份摘要卡片，只包含：日期、主要指数涨跌、当日异常点数量、报告全文链接。详细内容让人点链接去看。这样既控制了推送内容的合规风险，又提升了可读性。

5.2 报告正文的排版：数据在前，文字在后

报告正文的排版顺序也有讲究。把结构化数据放在最前面，模型生成的文字描述放在后面。这样做的好处是，即使文字部分被降级处理，报告的核心信息（数据）依然完整可用。

一个可参考的排版骨架：

1. 当日核心指标表（纯数据）
2. 异常点列表（纯数据 + 客观描述）
3. 模型生成的行情综述（受约束的文字）
4. 固定免责声明

免责声明不要用模型生成，直接写死一段固定文本。模型生成的免责声明可能措辞不当，反而引入风险。

5.3 通知失败的兜底

推送本身也会失败——Webhook 地址失效、群机器人被限流、网络抖动。要有兜底：

• 推送失败时，把报告链接写入一个"待推送"队列文件，下次任务开头重试。
• 连续失败超过阈值，切换到备用通知渠道。
• 所有推送结果记录到 meta.json，便于事后统计成功率。

这些机制听起来琐碎，但正是它们决定了工具能不能"每天稳定出现"。一个三天两头漏推的工具，用户很快就会弃用。

6. 我在类似项目里踩过的坑与几条硬经验

6.1 坑一：把"交易日判断"写死在代码里

早期我图省事，直接在代码里写了个节假日列表。结果每年年初都要手动更新，有一年忘了更新，春节假期连着跑了好几天无效任务，白白消耗额度，还推送了几份基于陈旧数据的报告。

正确做法是从数据源动态拉取交易日历，或者用一个可靠的日历接口。如果实在要本地缓存，也要设置过期时间，到期自动刷新。

6.2 坑二：模型输出直接拼接进 Markdown

模型输出的文本里可能包含 Markdown 特殊字符，直接拼接会破坏排版，严重时甚至能注入链接或图片。处理方式是对模型输出做转义，或者用代码块包裹。别小看这个细节，我见过因为模型输出里带了|符号，把整个表格结构搞崩的情况。

6.3 坑三：忽略 token 成本，月底账单吓一跳

每天跑一次，每次输入包含大量历史数据和指标，token 消耗很容易失控。控制手段：

• 历史数据只传必要的窗口，不要全量塞。
• 指标用紧凑的 JSON 表示，别用自然语言描述。
• 设置单次调用的 max_tokens 上限。
• 在 meta.json 里记录每次的 token 用量，定期复盘。

我自己的项目里，把输入从"自然语言描述指标"改成"紧凑 JSON"之后，单次 token 消耗降了大概四成，输出质量没有明显下降。

6.4 坑四：以为"零服务器"就等于"零维护"

这是认知层面的坑。零服务器省掉的是机器运维，但代码维护、依赖更新、平台规则变化一样都少不了。平台的定时流水线能力可能调整，数据源接口可能变更，模型 API 可能升级。这些都需要你持续跟进。

所以别把"零服务器"理解成"搭完就不管"。它降低的是固定成本，不是全部成本。心态上要把它当成一个需要定期照看的小项目，而不是一次性交付的成品。

6.5 一条贯穿始终的经验：约束要写在最前面

最后分享一条我认为最重要的经验：对模型的约束，要写在系统提示的最前面，而不是散落在中间。

模型的注意力对开头和结尾更敏感。把禁令和正向清单放在系统提示的开头，约束效果明显好于放在中间或结尾。这个细节调整成本极低，但实测对越界率有可感知的改善。

另外，约束清单不要一次写几十条，模型记不住。核心禁令控制在 5 到 8 条，每条都具体到句式级别，比写一大堆笼统的原则有用得多。剩下的细节，交给后置校验去兜底。提示负责"引导"，校验负责"兜底"，两者分工明确，整套防喊单机制才立得住。