把本地跑了大半年的盯盘服务卸掉那天，我反而松了口气。那个代号叫“龙虾”的本地程序，帮我抓到过几次板块异动，也让我在凌晨三点被误报吵醒过好几回。真正让我决定换掉的不是它报得不准，而是它只能活在我的电脑上：电源掉了它失声，网络断了它失声，我人不在电脑前，它就算喊破喉咙我也听不到。所以我把整套盯盘逻辑迁到了云端，用Kimi Claw + 飞书重新搭了一条流水线——行情采集、AI理解、消息推送全部串起来，7x24小时跑，不需要我守着屏幕。这篇文章就把这套系统的设计思路、关键代码和踩过的坑完整拆一遍，给同样想用AI替代人工盯盘的人做个参考。
1. 为什么我把本地盯盘服务“龙虾”卸了
先解释一下“龙虾”是什么。它不是什么正经软件，是我之前写的一个本地Python常驻服务，名字纯粹是随手起的，跑在书房一台旧电脑上，功能就是定时拉行情、做规则判断、触发弹窗提醒。听起来够用，实际用下来问题比想象中多得多。这一节我把它的死穴一个个说出来，你会发现这些痛点不是“忍一忍就过去”的小毛病，而是本地架构天然解决不了的问题。
1.1 本地方案的三个死穴
第一个死穴是单点故障。旧电脑休眠、路由器重启、小区停电、系统自动更新后脚本没有跟着起来，任何一个环节出事，盯盘就成了摆设。我统计过，那半年里“龙虾”意外失联的次数至少有七八次，其中两次正好赶上盘中有异动，等我发现的时候行情已经走完了一波。本地跑服务就是这样，它和你共用一套电力、一个网络、一台设备，你没法要求它比你自己更可靠。
第二个死穴是通知触达做得太弱。最开始我让它弹窗，结果人离开书房就看不到；后来接了邮件告警，结果重要提醒混在垃圾邮件里，我自己都懒得翻；再后来试过短信，稳定是稳定，但每一条都要钱，而且只能发纯文本，行情数字和AI分析根本塞不进去。盯盘系统的价值在于“及时且准确地触达”，弹窗和邮件这两关都过不了，后面分析做得再好也白搭。
第三个死穴是分析能力只能靠写死的规则。股价涨了5%就报警、成交额超过某个阈值就报警、五日新高就报警——这些规则写起来不难，但完全不能回答“为什么涨”“该不该关注”这种问题。有一次某个板块突然集体拉升，盘中异动规则确实触发了，但推送过来的就是一句冷冰冰的“XX板块涨幅超过3%”，我盯着屏幕还得自己翻新闻、看资金流向才能判断是政策消息还是单纯的情绪炒作。盯盘的目的不是拿一堆数字轰炸自己，而是用最短的时间搞清楚发生了什么，本地规则引擎做不到这一点。
1.2 一套合格的盯盘系统应有的样子
吃够了本地方案的苦，我给自己列了一套新系统的硬性要求，总共四条。
第一，服务必须跑在别人的机器上。我的手机可以不开机，家里可以断网，但盯盘服务不能跟着一起停摆。第二，触达通道必须可靠、免费、支持富文本。手机通知是我能接受的最低门槛，必须是推送即达、要有内容排版。第三，除了规则告警，还要有AI层面的理解能力。规则负责圈定“值得看”的标的，AI负责把这些标的状态翻译成看得懂的人话，两个环节缺一不可。第四，整套系统必须在我的电脑完全关机的情况下也能自愈。进程崩了要自动拉起，拉不起来要告警，至少要保证“挂了我知道”。
把这几条放在一起看，答案其实已经很清晰了：行情数据从公开接口拿，AI分析走大模型开放接口，触达通知走飞书机器人。数据采集和调度脚本放在云服务器上，挂掉就自动重启，Kimi Claw负责抓取和分析的逻辑串联，飞书负责最后的触达。这套架构不复杂，但把上面四个硬性要求全部覆盖了。
2. 选型逻辑：Kimi Claw和飞书分别解决什么问题
标题里的Kimi Claw不是某个官方产品的名字，严格说是我自己给这套组合起的代号。Kimi负责理解和分析，Claw负责抓取与调度，合在一起就是“AI大脑 + 数据抓手”的组合。飞书则解决触达问题。这一节我具体讲讲为什么是它们，而不是其他方案。
2.1 “Kimi Claw”到底是什么
很多朋友看到这个名字以为是某个现成的工具，真不是。Kimi Claw在我这里是一个由两部分组成的组合方案。
Claw这部分，本质是一组负责数据抓取、清洗、规则过滤和任务调度的脚本。它像一只机械手，定时去公开行情接口拉数据，然后按规则做初步筛选，比如涨跌幅超过阈值、成交额放大、连续N日上涨等，筛完之后把候选标的结构化成一段JSON传给AI。Claw这层的核心职责是“减少AI的无效输入”。如果你把全市场几千只股票全部丢给大模型，它处理不过来，费用也扛不住，而且输出质量一定会稀释。规则过滤的价值就在这里：先用确定性逻辑圈出小范围，再让AI在小范围内做判断。
Kimi这部分，就是大模型开放接口，负责把结构化的行情数据翻译成有逻辑的盯盘摘要。比如Claw筛出五只异动股，Kimi会结合板块涨幅、成交额变化、近期走势历史，生成一段说明：哪些可能是事件驱动、哪些可能是资金轮动、哪些只是脉冲式异动需要观察。它不预测涨跌，只做即时解释。这样我收到飞书推送时，不需要再自己翻数据，一眼就能知道发生了什么、为什么值得注意。
为什么这个组合值得选？核心原因是规则和AI正好互补。规则擅长处理确定性场景，但写不出理由；AI擅长总结和解释，但不能保证每次都稳定输出。先让规则做减法，再让AI做解释，两个环节穿插起来，系统的准确率和可读性同时在线。如果你预算有限或者不想依赖云服务器，也可以把Claw部分跑在本地，结果依然比纯规则强一大截，但那就又回到单点故障的老问题了，所以我不太推荐。
2.2 为什么推送偏偏选飞书
推送通道我对比过几个方案，最后选了飞书，理由很实在。
第一是免费且稳定。飞书的自定义机器人Webhook调一下就能用，没有按条计费的问题，推送频率正常使用也不会被限制。第二是富文本卡片消息。行情数据是键值对形式的，AI分析是一段自然语言，飞书的卡片消息可以把这两部分组织得非常清楚，数字、标题、描述、注释都能分开排，阅读体验比纯文本短信高出一个维度。第三是历史记录和搜索。飞书消息自带留存，我自己复盘的时候可以直接搜“预警”就能把一段时间内的所有提醒翻出来，非常方便。
还有个细节是群机器人比单聊方便。我可以拉一个只有自己或者少数几个人的群，机器人往群里推消息，我的手机、电脑、平板所有端都能同时收到，不用单独做多端同步。如果你本身就用飞书办公，那更是顺手的事，不用多装一个App。当然它不是没有缺点，比如签名校验的配置要稍微花点心思，这个我会在后面的实操部分单独说。
3. 核心实现：采集、分析、推送三层怎么串起来
理想中的盯盘系统是分层的：最底层是行情采集，中间是规则筛选和AI分析，最上层是消息推送。三层各干各的活，通过约定好的数据结构串联，互不干扰。这样任何一层要改，都不会牵动其他层。
3.1 采集层：行情数据与服务稳定性
采集层是整个系统的地基。数据没拿对，后面所有分析都是空谈。我这边用的公开行情接口，免费额度下基本够用，但有几个细节必须处理好。
第一个细节是频率控制。免费接口通常有请求限制，所以不能每秒钟都去拉全市场数据。我这边设置了两个梯度：全市场扫描5分钟一次，对筛选出来的候选标的单独拉一次分钟级行情。这样高频请求只作用在少量标的上，整体压力小很多。实测下来，免费接口完全扛得住。
第二个细节是缓存和去重。同一只股票五分钟内不需要重复分析，哪怕中间被规则命中两次，也应该合并成一条消息。所以在Claw里我维护了一个简单的内存缓存，记录每只标的最近一次推送的时间，如果距离上次推送不足十分钟，就跳过。这个机制直接决定了推送会不会扰民。
第三个细节是交易时段判断。盯盘只需要在A股交易时段内干活。周末、节假日、午休时间都应该直接跳过，否则凌晨三点收到一条“某股票涨幅超过5%”的误报，除了吓人没有任何价值。我在Claw里写了一个函数，用来判断当前时间是否处于交易时段，核心逻辑是判断工作日、判断上下午时段、排除节假日。
3.2 AI分析层：把行情翻译成人话
AI分析层的输入是Claw筛选出来的候选标的和它们的关键行情字段，输出是一段自然语言摘要。一开始我也犯过错，想直接让AI看全市场数据，结果又慢又贵，输出还很空。后来改成先用规则筛选，候选标的控制在十只以内，AI的输出质量立刻上一个台阶。
Prompt的设计值得花点心思。我给Kimi的指令大概包括几个要素：当前日期和时间、候选标的列表（每只包含代码、名称、最新价、涨跌幅、成交额、换手率）、相关板块指数涨跌、历史同类走势的一段摘要。另外还会明确要求它按“事件驱动、资金轮动、脉冲异动”三个维度分类，并对每只标的给出“关注/观望/回避”的判断。所有这些内容最后要求以结构化的方式输出，方便程序解析。
这里必须强调一个参数心得：AI接口的temperature要调低，我会设到0.2左右。盯盘场景不是让AI写诗，而是让它基于事实做判断，随机性越低越好。另外不要让它输出太长的分析，单只标的解释控制在一两句话以内，整条推送读下来不超过半分钟。AI一啰嗦，看的人就会麻木，盯盘提醒的效果直接归零。
3.3 推送层：飞书卡片消息的接入细节
飞书自定义机器人的接入方式不复杂，核心流程是：建一个群 -> 添加自定义机器人 -> 复制Webhook地址 -> 用POST请求发消息。
这里有个必踩的坑：飞书自定义机器人有两种安全设置，一种是签名校验，一种是IP白名单。我建议两个都配。IP白名单很好理解，只有你的云服务器IP能发消息，别人拿到Webhook也用不了。签名校验就是在请求体里带上一个用时间戳加密钥算出来的签名，飞书收到后会校验。这两层加上之后，Webhook地址就算泄露了，别人也推不了消息。
卡片消息的JSON结构，我会给一个可以直接用的模板。卡片比纯文本好在可以设置标题、用字段列表展示键值对、还可以用markdown描述AI分析结果。这样收到的消息一眼分成两部分：上半部分是行情数字，下半部分是AI解读。我在实操部分会把完整的JSON结构写出来。
3.4 让整套系统7x24自愈的调度设计
系统跑在云上，不等于可以放任不管。我这边做了三层自愈保护。
第一层是进程守护。用systemd管理常驻脚本，如果进程意外退出，systemd会自动拉起。第二层是心跳检测。每天收盘后，系统会主动推送一条“今日盯盘结束，系统在线”的消息，如果我某天没收到这条心跳，就知道服务出问题了。第三层是看门狗。每个小时检查一次数据文件是否更新，如果超过一小时没有新数据写入，说明采集层可能卡住了，这时候会触发一次重启并推送告警。
这三层叠加起来，过去一个月我只收到过两次异常告警，而且都是数据源暂时性故障，系统在几分钟内就自己恢复了。对于一个人维护的小系统来说，这个稳定性已经够用。
4. 实操过程：从零搭好盯盘系统
这一节按照我自己搭建时的顺序来写，分四步走。核心思路是先把推送打通，再接入数据，最后加AI分析。每完成一步都有明确的验证方式，不会出现“写了一大堆代码但不知道对不对”的情况。
4.1 准备环境
我的运行环境是：一台云服务器，Linux系统，Python 3.10。依赖库装得非常少：requests用来发HTTP请求，json和time是Python自带的。不需要装Pandas这类重量级库，因为行情接口返回的一般就是JSON，直接处理即可。如果用本地调试，Windows和macOS也没问题，但要记得把计划任务或者守护进程的配置改成对应系统的。
目录结构上我建议分三个文件：claw.py负责采集和规则，brain.py负责AI分析，feishu.py负责推送逻辑。主入口main.py负责把三块串起来。文件少、职责清楚，后面要改哪一块直接进对应文件，不用在几千行代码里找函数。
4.2 先打通飞书推送
这一步是最容易获得正反馈的：弄好之后你能立刻在手机收到消息，后面的活儿全都有了信心。操作流程是：在飞书里建一个群，哪怕只有你一个人也行；群设置里找到“群机器人 -> 添加机器人 -> 自定义机器人”；复制Webhook地址；记住密钥，后面配置签名校验时需要用到。
发送消息的Python代码模板如下，注意POST请求的payload要按框架要求带一个timestamp和签名。如果配置了签名校验，必须在请求中带上这两个字段，否则飞书会返回签名错误。这里我用了一个send_card函数封装整个发送过程，后面所有推送都复用它。
飞书卡片消息的JSON大概是下面这个样子。注意msg_type为interactive，这就是卡片消息。里面用header放标题，用elements放内容，内容里可以混排文本和字段。测通了这段代码，你的手机就应该能收到一张干净的卡片消息。
4.3 接入行情采集
打通推送之后，开始接数据。行情接口很多，我这边用的是现成的公开行情接口，这里不指定具体的服务商，但接口返回的JSON字段大同小异。核心要拿到的字段有这些：代码、名称、最新价、涨跌幅、成交额、换手率、所属板块。如果还能拿到量比和近5日涨跌幅就更好了。
采集代码的核心是写一个fetch_quotes函数，这个函数负责请求接口并把返回结果转成统一的字典格式。我建议你把所有字段名做一个映射层，因为不同行情源的字段名不一样，统一之后上层逻辑就不用关心数据源了。这一步做完之后，先打印出来看一眼数据格式，确认没问题，再进下一步。
4.4 加上AI分析并完成闭环
采集和推送都通了以后，最后一步把AI接到中间。整体流程是这样：主程序先采集全市场行情，跑规则筛选，得到候选标的列表；把候选标的和板块行情拼成一段prompt，发给AI分析；AI返回结构化结果后，组装成飞书卡片消息推送出去。
AI分析这一层我强烈建议先做一次离线验证：拿历史某一天的数据试跑prompt，看看大模型输出的格式是否稳定。如果大模型偶尔会多输出一些解释性文字，就在请求参数里把输出格式约束开起来，同时在代码里加一个“如果解析失败就重试一次”的兜底。你自己的大模型服务一般都有响应格式参数，让接口直接返回JSON最省心。
AI请求的代码大概是这样，接口地址和模型名称用你自己的配置替换即可。注意控制timeout不要设太长，因为盯盘链路里任何一环卡住都会导致推送延迟，我这边把timeout设置成30秒，超时就跳过这一次分析，等下一个周期再处理。
最后一个关键操作是测试：先不加规则筛选，全市场数据直接打给AI，你会发现又慢又贵又空；加上规则筛选之后，系统才真正能用。我上线前用历史数据回放了两天，效果稳定了才切换到实盘监控。
5. 常见问题与排查手记
跑了一个多月，各种小毛病没少遇到，但基本都在可控范围内。这里整理一个高频问题速查表，以及几个我认为值得长期坚持的细节习惯，给想复制这套方案的朋友做个参考。
5.1 高频问题速查表
像表格里最后一条经历，某天系统突然不推了，排查了很久才发现是数据源接口的字段名从price换成了close。搞数据源对接的人应该都有同感，字段变动是最隐蔽的坑，代码不报错，但结果全是空值。从那以后我给采集层加了一层字段映射和空值检查，任何一个关键字段为空就立刻报警，不把脏数据传给下游。
5.2 几个值得长期坚持的细节
第一，推送消息里一定要带时间戳。盘中收到的消息如果你不能立刻看，事后回顾时没有时间信息会非常混乱。我会在每条卡片消息的副标题里写清楚“生成时间：XX:XX:XX”，另外再加上一句“数据延迟约X秒”，久而久之就能感知到整套系统的时效性。
第二，频率控制比你想的更重要。推送太密集的结果是你会开始忽略它，最后和没搭系统一样。我这边同一个标的两次提醒之间的间隔至少十分钟，每天推送总量不超过20条。低频、高质量的信息流才可持续。
第三，日志一定要落到磁盘上，而且要按天滚动。排查问题的时候最怕没有历史记录。我会把每次采集的耗时、AI的响应耗时、推送是否成功都写进日志，出了问题先看日志定位，再决定要不要动代码。
6. 这套系统的边界，必须先说清楚
Kimi Claw + 飞书这套组合能替代本地盯盘脚本，但它不是万能的。我在用的过程中越来越清楚它的边界在哪里，这里给打算照做的朋友提前打个预防针。
6.1 免费行情数据的延迟问题
公开行情接口的数据延迟通常在5到15秒之间，快一点的源能压到3秒以内。这种延迟对诊断和提醒场景完全没有问题，但如果你指望靠它做抢跑交易，那几乎不可能。盘中一分钟的波动就能走完一个波段，5秒的延迟已经足够让你吃不到第一口肉。所以这套系统的定位是“辅助你快速理解盘面”，不是“帮你抢在别人前面成交”。如果你有这种需求，请直接上商业行情源和合规的交易通道，不是这个方案该干的事。
6.2 AI分析与自动化交易之间隔着合规红线
Kimi这类大模型的能力边界也要认清：它会一本正经地解释行情，但它不具备预测能力，更不是投资顾问。我的使用原则是——让它做信息整理和异动归因，我自己做决策。而且我明确把它定位成“提醒工具”而不是“决策工具”，两者有本质区别。
关于自动化交易这件事，我必须说得直接一点：个人用户在没有充分准备的情况下尝试全自动化交易，逻辑不完备导致的回撤风险极高，而且账户、工具、合规三方面的坑非常多，这一块我不会展开写，也不建议新手碰。盯盘提醒和自动下单之间隔着一条很宽的河，你可以用这套系统辅助盯盘，但请把交易决策的主动权留在自己手里。文章里所有代码和配置都只是信息整理和提醒的实现思路，不构成任何投资建议。
跑了一个多月，这套系统最大的价值不是让我抓住过多少次异动，而是让我从“时刻盯着屏幕”的状态里解放出来。盘中该忙就忙，手机震了再扫一眼，每一条推送都是筛选过的、有解释的、值得看的信息。如果你也想搭一套类似的，建议从最简单的飞书webhook推送开始，先跑通触达，再慢慢加规则、接AI，最后再考虑要不要上云。每一步都能立刻看到效果，这条路走起来会有意思得多。
