企业官网建设流程全解析

先说结论：我把跑了大半年的本地龙虾卸了，换成一套基于 Kimi Claw 和飞书搭出来的 7x24h 盯盘系统，稳定运行了一个多月没出大问题。如果你也被本地盯盘软件的高占用、消息延迟、规则写死不能改这些事折腾过，这篇文章大概能给你一个不一样的思路：盯盘这件事，不一定非得靠笨重的本地客户端，用 AI 工具 + 协作机器人组合，反而更轻、更准、更好改。

这套系统解决的核心问题是“信息差和反应速度”。盯盘要盯的不是 K 线跳来跳去，而是三个字：异动。价格异动、成交量异动、公告异动、海外市场异动。以前装本地龙虾还得每天盯着弹窗、手动刷新、偶尔还要忍受崩溃重启；现在变成了一条自动流水线：数据源拉取信息，Kimi Claw 负责判断和生成提醒文案，飞书机器人把结果推到手机和电脑上。人在哪不重要，消息一定到。

这套方案适合三类人：一是手里有持仓、信不过自己时刻盯盘的人；二是不想在一台电脑上装一堆重客户端、想轻量化盯盘的人；三是对 AI 工具感兴趣、想试着把大模型能力接进投资工作流里的技术型玩家。新手也能照着做，因为整个链路不复杂，最核心的就是一个脚本、一个机器人、一条 Webhook。

1. 为什么我把用了两年的本地龙虾卸载了

1.1 本地盯盘软件的“三大原罪”：占用高、延迟大、逻辑黑盒

先说说本地龙虾是哪类东西。它就是那类要安装在本地电脑上、登录后自动画 K 线、推送异动提醒的盯盘终端。圈内人这么叫它，是因为它跑起来占资源占得厉害，动不动风扇狂转，像龙虾下锅一样闹腾。我用了两年，忍了两年，最后卸载不是因为它完全不能用，而是它的问题越来越难忽略。

第一是资源占用。这类软件通常是常驻进程，开着就要吃几百 MB 内存，加上行情推送的长连接，CPU 时不时飘到 20% 上下。如果你平时要开编译器、浏览器十几个标签页，再挂一个它，电脑明显变卡。更烦的是，它还会在后台偷偷更新，偶尔睡前忘了关，第二天醒来发现它自动重启了一晚上，日志文件塞满 C 盘。

第二是消息延迟。我拿它和手机上的行情 App 对比过好几次，它弹出的异动提醒经常比手机慢十几秒到一分钟。别小看这一分钟，真到了情绪集中的盘面，一分钟足够价格拉出两三个点。盯盘工具本质上是给“决策反应”服务的，消息一到就得能快速处置，结果它慢半拍，那这提醒的价值就打折了。

第三是最要命的：逻辑黑盒。它内置的异动规则是厂商写死的，你能设置的只有“涨幅超过多少”“跌幅超过多少”这种粗粒度阈值。我想加一个“某只票放量上涨但主力资金流出”的复合条件，它在界面上根本找不到入口；我想把提醒按“重要程度”分级推送到不同地方，它也做不到。说白了，它是个“成品”，不是个“工具”，你只能在它画的框框里打转。

1.2 “7x24h盯盘”到底在盯什么：不只是盘中那四小时

很多不做交易的人会有个疑问：A 股一天交易四小时，哪来的 7x24h 可盯？我也踩过这个认知误区，直到朋友提醒我：盯盘不等于盯行情，而是要把所有跟持仓相关的信息及时汇总、判断、推送。拆开来看，一天里其实有几个关键时间窗口：

盘中时段（9:30-11:30、13:00-15:00）看的是实时价格和成交异动，这是盯盘的基本盘；但盘前（8:00-9:30）要盯隔夜外盘收盘情况、早间公告、竞价阶段的异常挂单；盘后（15:00-18:00）要盯龙虎榜、大宗交易、盘后公告和行业新闻；夜间（18:00-次日 8:00）还要盯美股开盘后的走势、中概股表现、汇率和商品价格波动——这些信息会直接影响你对第二天的判断。

这些时间窗口加起来，其实就是 7x24h。以前用本地龙虾，它只会在我打开电脑时工作，我睡觉时它就算挂着，也不会根据美股异动去提醒我“你持仓的行业板块今晚不太对”。新系统要解决的，就是把这 24 小时的信息流全部串起来：数据源持续更新，判断逻辑轮询触发，飞书把结果推到我的手机端，我早上睁眼看到的第一条消息就是“昨夜发生了什么、哪些信息跟你的持仓相关、综合判断是什么”。

1.3 方案选型：为什么是 Kimi Claw + 飞书，而不是硬写量化框架

定下需求之后，我对比过三条路。第一条是继续用本地龙虾，指望它出新版加功能，放弃。第二条是自己写一套完整的量化盯盘脚本，从数据采集到策略回测再到告警推送全套自己造。这条路的问题是太重：光是数据采集清洗、策略引擎、告警模块的代码量就很可观，而且调试周期长，一个人的精力很难维护到生产级水平。

第三条就是现在用的这套：用 Python 脚本做数据采集和管道传输，用 Kimi Claw 做判断和文案生成，用飞书机器人做消息出口。为什么选它，理由有三个。一是分层清楚：数据层、判断层、通知层互相独立，哪一环出问题就只修哪一环，不会因为一个模块崩了导致整个系统瘫了。二是改逻辑快：Kimi Claw 支持用自然语言描述盯盘规则，比如“当某只股票的涨幅超过 3% 且成交量大于过去五日平均成交量的 1.5 倍时，提醒我”，它会自动把它转成可执行的监控规则，比起在代码层面改阈值要友好得多。三是飞书这个出口太适合做告警了：Webhook 接入简单，消息卡片有结构化展示能力，还能按紧急程度用不同颜色标识，手机端推送也稳定。

表格对比一下就更直观了：

2. 核心脉络：一套 7x24h 盯盘系统的架构拆解

2.1 数据从哪来：行情源、新闻源、公告源的选型逻辑

整套系统的地基是数据源。数据源选得好不好，直接决定上层判断的准确度，也决定你维护成本高不高。我的选择标准有三条：第一是稳定，接口不能三天两头挂；第二是免费或者低成本，个人用没必要上来就买几万块的终端；第三是字段够用，有实时价、成交量、涨跌幅这些基本字段，最好还有盘口或者公告信息。

行情数据我选了开源行情库，这类库的好处是接口统一、字段结构清晰，一行代码就能拉到某只股票的实时价格和五日成交量均线。我实际用它拉数据的时候，错误率不高，偶尔遇到限频，休息几秒再重试就行。公告和新闻数据走的是公开财经接口，重点抓三类信息：公司公告（尤其是停复牌、股东增减持、业绩预告）、行业新闻（政策类、产业链上下游）、龙虎榜数据（机构席位买入卖出情况）。这些信息对判断“为什么涨为什么跌”很有价值，也是本地龙虾最弱的一块。

这里有个经验想多说两句：数据源不要只挂一家。我的方案里行情、公告、新闻分别来自不同接口源，这样某一个源挂了，其他源还能继续推送，系统不会整体失明。宁可偶尔重复推送，也不要全部数据缺失。重复推送还能靠后面的去重逻辑过滤，缺失就是盲区，盲区在盯盘场景里才是最危险的。

2.2 Kimi Claw 在系统里扮演什么角色：调度、判断、生成提示

Kimi Claw 在这套系统里不是可有可无的“展示层”，它实际上承担了三个核心职责：调度、判断、生成提示。

调度方面，它负责按时间窗口触发不同的监控任务。盘中每两分钟检查一次实时行情，盘后每半小时拉一次公告和龙虎榜，夜间则降频到每小时检查一次外部市场异动。这些任务调度不是写死的 crontab，而是用自然语言配置的规则，改频率不需要改代码，直接告诉它“盘中改成每三分钟一次”就行。

判断方面是它最核心的价值。普通脚本只能筛选数值阈值，Kimi Claw 可以处理语义级别的判断。举个例子，我配置了一条规则：“如果持仓股在收盘前半小时出现快速拉升，同时龙虎榜显示有机构席位买入，就提示‘可能是有资金在抢筹，注意次日惯性’。”这种判断没法用简单数学表达式完成，得把行情数据和龙虎榜数据一起拿过来做交叉推理，这正是 Kimi Claw 擅长的地方。它会把“快速拉升”理解成“尾盘时段内涨幅加速扩大”，把“机构席位买入”理解成“龙虎榜买入席位包含机构专用”，然后给出综合判断。

生成提示方面，Kimi Claw 会把判断结果转化成一段自然语言提醒，而不是给一个冷冰冰的数字。比如它不会推给我一句“涨幅超过 3%”，而是生成“你的持仓股 X 在 14:20 出现放量拉升，当前涨幅 3.4%，成交量已达到五日均量的 1.8 倍，结合今日板块动线来看，属于资金主动做多，建议关注明日是否延续”。这个“会说话的告警”在实际用的时候体验好太多了——半夜收到一条有逻辑的提醒，和收到一条干瘪的数字提醒，你的处理效率完全不一样。

2.3 飞书在系统里承担什么：机器人、消息卡片、分级触达

飞书在这套系统里是唯一的“消息出口”。我选它不选微信或者 Telegram，纯粹是看中它自定义机器人的成熟度。飞书的自定义机器人支持通过 Webhook 直接推送消息，三步就能创建：建一个群，添加自定义机器人，复制 Webhook 地址。整个过程不到两分钟，不用过审，非常适合个人工具。

飞书的消息卡片比纯文本通知好用太多。我可以把一条盯盘提醒分成多行：标题是“紧急提醒”还是“常规复盘”，正文里包含股票代码、当前价格、涨跌幅、触发规则、Kimi Claw 的综合判断，底部还能放一个链接，直接跳转到行情页。卡片支持不同颜色，紧急提醒用红色，盘后复盘用蓝色，夜间汇总用灰色。这样信息一到，扫一眼颜色和标题就知道严重程度，不需要细读正文。

触达层面我做了一个分级策略：紧急提醒直接推送到手机通知栏，用的是飞书 App 的消息推送；常规提醒只发到群里，不强制震动；每天的盘后复盘会在晚上固定时间汇总推送。这样既保证重要信息不漏，又避免高频打扰把我的注意力磨钝——盯盘工具的悖论恰恰在这里，提醒频率太密了，人会麻木，真正重要的异动反而被淹没。

2.4 整条链路的三个关键流程：盘中预警、盘后复盘、隔夜监控

架构拆到具体流程，就是三条流水线。第一条是盘中预警流：开源行情库按设定频率拉取持仓列表的实时行情，Kimi Claw 把当前价格、成交量、板块涨幅三个因素一起做判断，如果触发规则，就组装成飞书卡片推送到群里。这条流强调的是“快”，从数据拉取到消息推送，全程应该控制在十秒以内，要保证异动消息的时效性。

第二条是盘后复盘流：收盘后，脚本自动拉取全天的分钟级行情、龙虎榜、盘后公告，Kimi Claw 生成一份“当日持仓复盘”，内容包括：今天持仓的涨跌情况、哪笔操作对应当什么新闻、明日需要关注哪些事件（比如股东大会、解禁、财报日期）。我在飞书群里建了一个“每日复盘”子频道，它每天 18:00 准时把这份复盘推过去，我回家路上就能扫完。

第三条是隔夜监控流：这个流夜间运行，频率降下来了，但覆盖面更广。它会去拉美股主要指数的实时涨跌、中概股表现、商品期货的价格变动，以及与持仓板块相关的海外新闻。如果发现相关性强的异动（比如持仓的新能源板块在美股对应的龙头大跌超过 5%），它会立刻推一条紧急提醒。这条流是我觉得最值回票价的——以前晚上从来没想过要盯这些，现在早上起来，盘前怎么应对心里已经有底。

3. 从零搭建的完整实操记录：从申请机器人到跑起来

3.1 第一步：创建飞书群并添加自定义机器人，拿到 Webhook

整套系统的动手第一步不是碰代码，是先把“消息出口”打通。打开飞书，创建一个群，名字可以叫“盯盘告警”或者“市场监控”，建议至少拉个有权限的人进来，因为全空的群在某些配置界面会有限制。之后点击群设置，找到“群机器人”选项，选择“添加机器人”，在机器人列表里找到“自定义机器人”。

添加的时候有选择：可以通过 Webhook 接入，也可以扫码接入。个人用建议直接选 Webhook 方式，因为后面写脚本推送最方便。添加成功后飞书会生成一个 Webhook 地址，长这样的一串 URL，要把它记下来，放在配置环境变量里，不要硬编码在脚本里。Webhook 地址相当于你群里的一个“投递口”，谁拿着这个地址谁就能往群里发消息，泄露了别人就能往你群里灌垃圾消息，所以我在部署时单独建了一个配置文件，权限设为当前用户可读写。

添加完机器人后，强烈建议先在飞书群手动发一条消息试试。可以直接用飞书自带的“自定义机器人调试工具”或者拿浏览器直接访问 Webhook，传一段最简单的 JSON 格式文本，看看群里能不能收到。这一步别嫌麻烦，因为网络环境、防火墙、飞书服务端的问题都可能让 Webhook 调不通，先手动验通了再写代码，后面排查才能缩小范围。

3.2 第二步：搞懂 Kimi Claw 的两种用法：规则配置和脚本调用

接着是重头戏 Kimi Claw。我第一次接触它的时候也一头雾水，以为它只能像个聊天窗口一样在线回答问题，后来才知道它对自动化场景的支持是两种形态并用：一种是“规则配置模式”，一种是“脚本调用模式”。

规则配置模式适合设置长期不变的监控规则。我在 Kimi Claw 界面里用自然语言写规则，比如“每两个交易日检查一次持仓股的龙虎榜数据，如果出现机构专用席位卖出，提示风险”。它会把这些规则抽象成结构化配置，存下来，之后调度引擎按这个配置执行。这里的关键是，规则描述要尽量具体：说清楚检查频率、检查对象、触发条件、输出格式，越具体它出来的效果越接近你想要的样子。开始我偷懒，只写了句“帮我盯着点股票异动”，结果它跑出来的东西有股没说代码、有时间没提价格，基本没法用。后来把规则补成了“检查以下股票列表，对每只股票计算当前涨幅和五分钟成交额，如果涨幅大于 3% 且五分钟成交额大于 500 万，则推送一条格式为‘代码-名称-涨幅-成交额’的消息”，效果立刻正常了。

脚本调用模式则适合做动态任务。我的实现方式是，Python 脚本在拉到行情数据之后，不直接做阈值判断，而是把这些数据作为参数调用 Kimi Claw 的分析接口，让它生成判断文本。这个接口要提前配好鉴权密钥，调用的时候传一段上下文、几个数据字段、一个输出格式说明，它返回的就是加工后的提示文案。这样做的优势是，股票列表变化时不用去改代码里的规则，只要在调用参数里更新股票列表就行，灵活度高了不是一点半点。

3.3 第三步：写一个最小可用的盯盘脚本：数据拉取、条件判断、消息推送

数据源通了、正则能调了，就可以动手写最核心的轮询脚本。我不建议一上来就上架构、搞消息队列，先写一个能跑的线性脚本，验证整条链路能通，再慢慢优化。我的第一个版本长这样：

import time import requests # 拉取行情数据 def fetch_quote(stock_code): url = f"https://example-quote-api.com/quote/{stock_code}" resp = requests.get(url, timeout=10) data = resp.json() return { "code": stock_code, "name": data["name"], "price": data["price"], "change_pct": data["change_pct"], "volume": data["volume"], "avg_volume_5d": data["avg_volume_5d"] } # 判断是否触发异动 def should_alert(quote, threshold_pct=3.0, volume_ratio=1.5): price_ok = quote["change_pct"] >= threshold_pct volume_ok = quote["volume"] >= quote["avg_volume_5d"] * volume_ratio return price_ok and volume_ok # 发送飞书消息 def send_feishu(webhook_url, content): payload = { "msg_type": "text", "content": {"text": content} } requests.post(webhook_url, json=payload, timeout=10) # 主循环 def main(): webhook_url = "https://open.feishu.cn/open-apis/bot/v2/hook/your-webhook" watch_list = ["000001", "600000", "300750"] while True: for code in watch_list: quote = fetch_quote(code) if should_alert(quote): msg = f"异动提醒：{quote['name']}({quote['code']}) " msg += f"当前涨幅 {quote['change_pct']}%，" msg += f"成交量达五日均量的 {quote['volume'] / quote['avg_volume_5d']:.1f} 倍" send_feishu(webhook_url, msg) print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] alert: {msg}") time.sleep(120) if __name__ == "__main__": main()

这版脚本总共就三个函数加一个主循环，非常朴素。它有两个小细节值得说。一是time.sleep(120)，我选的是两分钟轮询一次，既不漏大行情，也不会因为请求太频繁被接口限频。如果你盯的是开盘那段时间的剧烈波动，可以改成 60 秒，但再快就要担心限频了，建议别小于 30 秒。二是消息里加了时间和成交量比值，这样收到提醒的时候能直接判断这条异动的“质量”，不是只看一个孤立涨幅。

脚本跑通以后，我没急着加功能，而是先让它连跑了两天，专心观察三件事：有没有漏推送（对比手动看盘）、有没有重复推送（同一条异动被推了两遍）、有没有接口报错导致脚本崩掉。盯盘工具的底线是可靠性，先保证它不会瞎报和漏报，再谈智能。

3.4 第四步：接入 Kimi Claw 的判断文本生成，让提醒“会说人话”

线性脚本跑稳之后，升级第二步：把要推送的文本从脚本里硬编码的固定字符串，换成 Kimi Claw 生成的判断文本。这样提醒就不再是干巴巴的条件描述，而是有逻辑推理的结论。

具体做法是，在should_alert触发之后，不要直接拼消息，而是先把行情数据、成交量数据、近期新闻标题这几个字段整理成一个 JSON，调用 Kimi Claw 的分析接口。举例来说，我会传给它这样的上下文：

持仓股 300750 当前价格 128.5，涨幅 3.4%，成交量是五日平均的 1.8 倍。 当日相关新闻标题：某电池厂商发布新一代快充技术，产业链或受益。 请结合这些信息生成一条适合推送到手机端的简短提醒，指出可能原因和次日关注点。

接口返回的文本就是最终的推送内容。这里需要提醒的一点是，Kimi Claw 生成的文本风格可以调，我在规则里加了“简短”“口语化”“不要堆术语”的约束，所以它生成的内容更像一个朋友给你发消息，而不是一份研报摘要。接入这一步之后，飞书群里收到的提醒一下子“活”了，很多朋友看了还以为是哪个资深交易员值班发的。

但这条路径也引入了一个新问题：接口响应有延迟。行情数据是实时的，调用分析接口可能耗时一两秒，极端情况下要三四秒。这个延迟对监控场景来说可以接受，因为异动判断的窗口不是毫秒级。如果你的场景需要极低延迟，可以把 Kimi Claw 降到只处理“二级提醒”，紧急的价格异动还是走规则直出，只有需要语义分析的提醒才走大模型接口。我实际就是这么做的：紧急涨跌走规则，板块归因、消息面解读走 Kimi Claw，兼顾速度和质量。

3.5 第五步：部署成 7x24h 常驻服务，加守护、加日志、加降频

脚本在电脑上开着确实能跑，但不可能 7x24h 人肉保证它活着。我做了三件事实让它变成服务：加守护、加日志、加降频策略。

守护最简单的方法是写一个外层 shell 循环，检测到主进程退出就自动重启。我没有用 systemd，因为当时是在一台云主机上部署，直接写了个无脑的守护脚本：

#!/bin/bash while true; do python3 monitor.py >> /var/log/stock_monitor.log 2>&1 echo "[$(date)] monitor exited, restarting in 10s" >> /var/log/stock_monitor.log sleep 10 done

这版结构很丑陋但非常可靠。只要磁盘不爆、机器不重启，它就会一直跑。日志一定要有，而且要带时间戳。你不希望半夜系统挂了，第二天早上才发现夜里什么都没推。每次脚本启动时我会在日志里打一行 “monitor started”，每次推送也打一行，这样第二天查日志就能清晰还原整个监控过程。

降频策略解决了夜间烦扰问题。脚本主体虽然一直轮询，但不同时段轮询间隔不同：盘中两分钟一次，收盘后改为十分钟一次，夜间改为三十分钟一次。同时在夜间关闭了非紧急类提醒的推送，只保留“隔夜外部市场异动超过阈值”这一种紧急提醒。这样脚本 7x24h 在跑，但不会半夜一小时给你推二十条行业新闻——那种推法一开始可能觉得很“专业”，第二天就会想砸手机。

部署完成以后，还有一个我最看重的验收标准：人为制造一次假异动来测试全链路。我选了持仓列表里的一只票，手动在行情数据文件里改了一个超阈值的价格，结果脚本确实在下一轮轮询时触发了判断，飞书群里也收到了提醒。这证明链路是通的，而不是想当然觉得“应该没问题”。做监控系统，永远不要靠“应该没问题”来验收。

4. 踩坑记录与排查速查表：那些文档里不会写的细节

4.1 六个高频问题：现象、原因、解决办法一次说清

这一个多月的运行里，我踩过的坑绝对不比代码写的少。这里整理一张速查表，每个问题都是真实发生过、真实排查过的。

这里我最想展开的是冷却时间。刚开始系统跑起来，一只票盘中放量拉升，脚本每两分钟检查一次，每次检查都满足异动条件，于是每两分钟推一条提醒，一个小时内推了三十条几乎一样的消息。这不仅是打扰的问题，更严重的是，一个反复响的闹钟很快就会被你无视，等真正出现新异动时你可能已经关闭通知了。我在每个股票代码上维护了一个last_alert_time字段，同类型的提醒必须在 15 分钟冷却期后才会再次推送。这个值不是拍脑袋定的：15 分钟既能覆盖大部分短线异动的持续性，又不会让真正的新变化被冷却期吞掉。

4.2 告警风暴怎么压：阈值、冷却、分级一个都不能少

告警风暴是监控系统的通病，股票盯盘也一样。我总结的压制手段有三件事：合理阈值、冷却机制、分级通知。

合理阈值的意思不是只设一个固定的 3% 就当完事，而是要根据个股的波动特性差异化设置。波动大的题材股平时振幅就大，3% 可能是家常便饭；低波动的蓝筹股 3% 就是大事。我给每只股票配了一个alert_threshold字段，在配置文件里单独设置。这个配置不是一成不变的，我跑了三周后根据实际触发频率调整了一轮，目的就是让提醒数量少而精。

冷却机制上文说过了。分级通知则是把消息按紧急程度分三档：第一档是紧急异动，直接推手机通知；第二档是常规异动，推群里但无关紧要；第三档是每日汇总，只在固定时间推。这样做的本质是管理注意力。盯盘工具存在的意义不是让你时刻神经紧绷，而是让你在该关注的时候被正确唤醒，在不该关注的时候安心做自己的事。

4.3 夜间与周末的差异化监控配置

7x24h 不是 7x24h 平均用力。深夜和美股的时段，你需要监控的内容明显不同于白天。我的做法是加了个时段开关：盘中是“主监控时段”，所有规则全开，轮询频率最高；盘后是“报告时段”，主要跑复盘和公告检查；夜间是“轻监控时段”，只监控美股指数和持仓行业龙头，轮询频率降到半小时一次，只推紧急异动。

周末也有活儿要干：周五收盘后，拉一次全周数据，生成周度复盘；周日晚间，检查一下下周的财经日历，把解禁、财报、重要经济数据发布这些事件提前标注出来。这个“轻监控时段”其实很关键，因为很多影响周一的信号是周末发酵出来的，比如政策新闻、海外市场周五晚的大波动。我每周日晚 8 点固定收一条“下周关注清单”，周一开盘前内心不慌，这是以前用本地龙虾时完全没体验过的功能。

4.4 数据源不可用的兜底策略：多源、重试、状态自检

最后说一个可靠性话题。任何第三方接口都可能挂，可能限频，可能返回脏数据。我实际遇到过行情库接口连续五六次请求超时，如果脚本没有做重试和兜底，那段时间里的异动就会被完全漏掉，而且你不会发现。

我的兜底策略有三层。第一层是重试：单个数据源请求失败后，退避重试三次，每次间隔十秒，期间轮询暂停，不往下走。第二层是多源：如果主行情源连续失败超过五次，脚本自动把行情拉取切换到备用源，备用源是一个门户网站的公开行情地址，格式不同但字段齐全。第三层是状态自检：脚本每小时往飞书群推一条“系统心跳”消息，包含最近一小时的请求成功率、推送次数、最近一次成功时间，这样即使没有异动发生，我也能确定系统是活着的。这三层做完，我这一个多月里再没出现过“静默死机”的情况。

5. 这套系统还能怎么扩展：从盯盘到投资工作流

系统的架子搭好以后，好处是你想加功能非常容易，不需要推翻重来。我最近在试两个扩展示例，给想抄作业的朋友做个参考。

第一个是接入财报日历自动提醒。把财报发布、分红派息、股权登记日这些事件做成一个日历数据源，Kimi Claw 结合持仓列表，提前三天推一次“你持仓的 XX 公司将在周五发布财报，历史同期财报次日上涨概率 60%，建议关注”。这类提醒不需要看盘，属于事件驱动型信息，对持仓管理特别有用。

第二个是把飞书群变成“交易日历+备忘清单”。每天收盘后的复盘消息里，除了当日行情总结，还可以让 Kimi Claw 把“明天需要关注的事项”转成一个 checkbox 列表，比如“关注 XX 股能否守住五日线”“验证 XX 板块的龙头切换是否成立”。第二天早上直接在飞书群点开一看，就知道今天要做什么、验证什么。这个用法已经有点偏离“盯盘”了，更像一个投资助手。

我个人的体会是：这套系统的价值不在于它有多智能，而在于它把“盯盘”这件事变成了一种可以积累、可以调整、可以复用的基础设施。以前本地龙虾的规则是别人写好的，你只能迁就它；现在这套系统的规则是你自己定义的，市场变了、你的策略变了，改一个配置文件、改一段提示词就完事。这种掌控感，是用任何成品软件都换不来的。

最后再分享一个小技巧：不要嫌系统复杂就一上来全做，先花一天时间把“一个脚本 + 一个飞书 Webhook”的雏形跑通，再花一天把 Kimi Claw 判断层接进去，最后再谈部署和兜底。一步步来，每一步都能看到效果，这套系统才不会半途而废。我现在每天早上睁眼第一件事就是看飞书群里的隔夜汇总，晚上睡前半小时扫一眼盘后复盘，盘中大多数时间反而不需要盯着手机——该看的异动都会自己找上门。