上个月我把每天收盘后的例行工作从三个小时压缩到了三分钟。方法不是买了什么量化终端而是花了一个周末把 OpenClaw 接进了自己的交易项目做成了一个飞书里的 A 股智能分析机器人我管它叫 AI Trading Partner。现在每天早上 9 点前打开飞书盘前要闻、昨日复盘、关注池个股的技术指标状态已经整整齐齐躺在消息卡片里盘中想看某只票的龙虎榜资金流或历史筹码分布直接 机器人说句话就能拿到结果。这篇文章就把整个落地过程完整记录一遍包括为什么选这套方案、飞书自建应用怎么创建、交易逻辑怎么拆成 skill、消息卡片和定时任务怎么接以及我在接的过程中踩过的一堆坑。适合手里已经有一套自己的选股或复盘逻辑、想把它变成 7×24 小时助手的人参考。1. 从收盘三小时到三分钟我为什么要在飞书里养一个分析伙伴先说说我原来的工作流有多痛苦。每天收盘后我先要在行情软件里把指数、板块、自选股全部过一遍然后打开另一个网站看公告和龙虎榜再回去核对持仓股的技术指标最后打开备忘录写明日观察清单。这一套下来运气好两小时运气差直接干到晚上。真正让我下决心动手的是一次普通的周二晚上八点半我发现自己还没吃晚饭而手头只完成了三分之一的复盘。当时我就想这活儿里至少有一大半是信息搬运和格式整理为什么不能让 AI 把脏活累活干了我只做判断1.1 我原来的盘后流程到底卡在哪拆开来看我每天要处理的事情大概有五件扫指数和行业板块确认当日市场情绪和风格偏向。过一遍自选股池看有没有出现我定义的启动信号。翻公告和龙虎榜筛掉明显有雷的标的。复盘持仓对照买入逻辑检查有没有被破坏。写第二天的观察清单把候选标的和触发条件记下来。问题在于这五件事分散在行情软件、财经网站、备忘录和 Excel 里每切换一次就要重新登录、重新找入口而且第二天我又得把同样的流程再走一遍。市面上不是没有现成的智能选股工具但它们的判断逻辑是黑盒我不清楚它为什么推这只票也不敢把真金白银交给它。我需要的是一个能严格执行我自己交易规则、并且能随时被我追问细节的助手。1.2 先划红线它是分析助手不是荐股机器人在动手之前我先给自己立了一条规矩这个机器人只负责把原始数据整理成符合我交易框架的结构化简报并按照我设定的规则打标签、给提示绝不直接输出买入 XX卖出 XX之类的指令。原因很简单第一AI 模型本质上是在做模式匹配它对市场的理解深度还不足以承担最终决策第二如果模型一本正经地推荐一只基本面已经恶化的股票然后我真的买了亏损的锅肯定是我自己的。所以我在全局设定里明确了它的职责边界所有输出都围绕数据是什么、技术形态处于什么状态、历史统计中类似情况后发生了什么来组织最终的决策永远由人来按下扳机。这一点后面讲 prompt 设计时还会细说。1.3 把需求拆成三张清单动手之前我习惯先列清单避免做着做着方向跑偏。这次的需求被我拆成三块数据接入清单行情、技术指标、财报关键字段、公告、龙虎榜、涨跌停与资金流。交互场景清单随时 机器人查个股、查板块、查指数用一句自然语言发起复盘或异动扫描结果必须在一个消息卡片里看完不用翻网页。自动化任务清单盘前要闻、盘中异动提醒、午间简评、收盘复盘、晚间公告与龙虎榜汇总全部定时推送到飞书群里。清单列完我就明白了这本质上不是一个 AI 应用而是一个消息触达系统 数据管道 规则引擎的组合。想清楚这一点后面选型就顺了很多。2. 技术选型为什么是 OpenClaw而不是又一个 FastAPI 机器人其实在最开始我的方案不是 OpenClaw而是自己写一个 FastAPI 服务注册一个飞书 webhook收到消息后用正则匹配命令再调用我自己的 Python 交易脚本。这套方案我确实写过一版但最终越写越痛苦。2.1 我写过的第一版 Bot 是怎么死掉的第一版架构很简单飞书把用户消息 POST 到我的服务器我解析文本命中复盘查 XX这种关键词就去调交易模块然后把结果以文本形式发回飞书。听起来很顺但实际跑起来全是杂活飞书事件订阅要有 URL 校验消息要处理重试和去重长连接断了要重连服务器进程挂了要守护协议升级以后验签逻辑要跟着改。更麻烦的是每加一个新功能我都要手动写一段路由逻辑把用户说了什么话和该调哪个函数绑在一起。到了第四个功能的时候路由代码已经比业务代码还长我意识到自己百分之八十的时间都在解决 IM 平台协议问题而不是在解决交易分析问题。2.2 OpenClaw 这类 agent 框架真正解决了什么后来我换了思路去看 OpenClaw 这类 agent 框架。它的核心设计是三层解耦模型对话编排、工具调用能力、IM 通道适配三件事分开处理。对于我来说IM 通道适配——也就是怎么和飞书收发消息——它是现成的工具调用能力——也就是让模型判断什么时候去执行我的交易脚本——它有 skill 机制我要写的只剩下业务本身定义几个 skill把我的交易模块封装成模型能调用、能理解输入输出的积木。这就像你不需要从零搓一台汽车只需要考虑怎么改造发动机。当时我还有一个顾虑协议层是别人写的万一不满足需求怎么办但 OpenClaw 本身是开源项目飞书适配器有问题可以直接看源码去修这比我从头维护一个 IM 适配层要靠谱得多。2.3 为什么触达层选了飞书而不是别的触达层我也纠结过Telegram 的 bot API 确实文档好、消息自由度大但国内访问不稳定推送延迟看运气企业微信和钉钉偏向办公审批流机器人能力和卡片格式远不如飞书丰富。最后选了飞书理由是它作为协作工具在 A 股从业者圈子里的渗透率足够高而且开放平台能力确实细消息卡片可以做成可折叠、可交互的样式机器人能发文件、能读写云文档、能写多维表格这些恰好覆盖了我要做的日报、复盘存档和历史数据沉淀场景。下面这个表格是我当时做的选型对比方案消息触达卡片能力文件/表格能力维护成本自研 FastAPI 机器人依赖 webhook需要自己拼 JSON全部自己调 API高协议层都要管Telegram Bot快但国内不稳定中等一般中但访问是硬伤飞书 OpenClaw快国内原生强卡片交互丰富云文档、多维表格、文件全支持低只写 skill选型到这里基本定了OpenClaw 做 agent 底座飞书做触达层我自己的交易 Python 模块做数据源和规则引擎。3. 部署与接入从空目录到飞书里能回消息选型结束就开始动手。整个接入过程分成四块模型接入、飞书自建应用、OpenClaw 配置、全局人格设定。3.1 模型接入云端 API 和本地模型我都要先解决AI 的大脑问题。我的做法是双路配置日常对话和需要强指令理解的场景比如用户问XX 股票现在技术上什么状态走云端 API理由很简单指令理解稳定、输出格式规范、响应速度快而批量任务比如每天收盘后的全市场扫描、财报长文本读取、历史数据归纳走本地模型用 Ollama 跑开源模型好处是不用心疼 token 消耗也不怕并发。本地模型我推荐内存至少 16G 起步因为量化分析场景下小模型输出质量确实不够稳定Qwen 系列 7B 到 14B 是一个比较合适的甜点区间。这里有个细节模型接入的配置在框架里集中维护切换模型商只需要改一个配置块不用改任何业务代码所以先接哪家后接哪家并不重要。3.2 在飞书开放平台创建自建应用飞书侧的准备工作是固定的照着做就行。登录飞书开放平台选择创建企业自建应用填完基础信息后你会拿到两个关键凭证App ID 和 App Secret。接着在应用功能里开启机器人能力这是让应用能以机器人身份收发消息的前提。然后去事件订阅里添加im.message.receive_v1事件这是接收用户消息必须的事件回调地址先填一个占位符等服务器部署好了再改回来。最后是权限配置这一步我建议一次性想清楚发消息需要im:message:send_as_bot读写云文档需要docx:document相关权限上传文件需要im:resource如果后面要写多维表格还需要bitable:app。权限配好之后创建版本并发布等管理员审核通过机器人在飞书里就能被搜到了。3.3 把凭证写进 OpenClaw 并解决回调问题OpenClaw 这边我在配置文件里找到消息通道/IM 适配器的段落把飞书应用的 App ID、App Secret、Verification Token、Encrypt Key 填进去。Verification Token 和 Encrypt Key 在飞书开放平台的事件订阅页面里能看到前者用于校验请求合法性后者是消息内容加密用的。这里有一个我踩过的大坑如果开着加密模式但回调校验逻辑和飞书的加解密规则对不上飞书事件订阅会一直报URL 校验失败看起来像网络问题实际上完全是密码学问题。另外飞书要求回调地址必须公网可达本地调试必须用内网穿透工具把 localhost 暴露出去生产环境建议直接部署在有公网 IP 的轻量服务器上省得穿透工具半夜掉线导致定时任务失联。3.4 全局人格设定让 AI 从聊天模型变成 A 股分析师机器人在飞书里能回消息之后还差最后一步告诉它你是谁、你要干什么、你不许干什么。这一步我放在全局 system prompt 里内容分成三块角色定义、输出规范、纪律红线。角色定义直接写清楚你是 AI Trading Partner一个 A 股数据分析助手。你的职责是调用内部工具获取行情、财务、公告数据并将结果整理成结构化简报。输出规范规定所有结果必须使用飞书消息卡片格式关键数字加粗结论放在最前面判断依据放后面如果数据不足明确说数据不足禁止猜测。纪律红线是硬性的严禁给出买卖建议严禁预测具体点位严禁推荐个股你只能陈述数据状态和概率统计。我还把自己的交易规则参数写进了这部分均线组用 5/20/60量比超过 1.8 算放量MACD 金叉需要配合成交量确认单只标的仓位上限 20%触发止损线必须提醒。这样模型输出的解读就不是泛泛而谈而是带着我的个人口径。4. 核心 Skills 拆解把交易分析拆成能被机器调用的积木到这一步机器人已经有对话能力了但它还不会分析因为我自己的交易项目里那些 Python 模块还没暴露给它。这就要靠 skill 机制。4.1 Skill 设计的三个原则我在写 skill 之前先定了三条原则后来发现这三条原则直接决定了整个系统的稳定程度。第一条一个 skill 只干一件事不要写一个analyze_everything的大杂烩函数否则模型调用时不知道传什么参数输出也不可控。第二条skill 内部先输出结构化 JSON再由模型负责转述绝不让模型直接拿原始接口的返回去面向用户信息过载会让输出变得一团糟。第三条每个 skill 的描述里必须写清楚什么时候该调用我因为大模型是靠描述来路由意图的描述越具体调用准确率越高。4.2 行情快照与技术指标 skill第一个 skill 是行情快照输入是一串股票代码和周期参数输出是收盘价、涨跌幅、量比、MA5、MA20、MACD 状态、RSI 这些字段。数据源我用的是 akshare它是国内量化社区用得很多的开源数据接口不需要注册 token直接 pip 安装就能用。核心代码大概是这样的import akshare as ak # 示意拉取个股历史行情并计算指标 df ak.stock_zh_a_hist(symbol000001, perioddaily, adjustqfq) close df[收盘] ma5 close.rolling(5).mean() ma20 close.rolling(20).mean() # 后续把指标封装成固定 JSON 返回给模型这个 skill 的 description 我写的是当用户询问某只股票或某个指数当前价格、均线、MACD、RSI、量比时调用。不要用于询问板块涨跌。输出格式是固定 JSON模型拿到之后只需要用大白话把数字讲清楚不用自己重新算指标——这一点很关键因为模型口头算的指标大概率不可靠。4.3 财报、公告与龙虎榜 skill第二个 skill 面向基本面和非结构化信息。财报部分输入股票代码后自动拉最新定期报告里的关键字段营收、净利润、毛利率、经营现金流、资产负债率然后和上一期做环比和行业均值做对比。输出的时候我要求模型只能打标签比如营收加速增长毛利率连续两期下滑经营现金流为负不允许它自由发挥。公告部分按类型归类减持、质押、回购、中标、业绩预告、立案调查每类一个标签只有命中了预设的风险标签才会额外提醒。龙虎榜部分整理上榜原因、买方前五和卖方前五营业部模型只负责转述谁买了谁卖了不解析背后有什么神秘资金——那个纯属玄学我还不想让模型教我占卜。4.4 盘中异动与纪律提醒 skill第三个 skill 是个轮询任务每隔几分钟扫一遍关注池一旦触发我预设的异动条件比如涨幅超过 5% 但量能只有前五日均量的 60%、或者跌幅触及止损线就生成一条提醒推送到飞书。这个 skill 里有一个参数极其重要冷却时间。同一只标的触发异动提醒后30 分钟内不再重复推送。没有这个参数股价在某个区间反复震荡的时候机器人会把你手机震成按摩仪。我的原则是宁可少发不可多发推送一旦过于频繁人就会麻木真正重要的信号也会被淹没。另外这个 skill 里我还写了一条纪律提醒逻辑如果某只持仓股的收盘价跌破买入逻辑里的关键均线在收盘复盘时强制输出一条风险提醒而不是等到第二天才反应过来。4.5 复盘指令背后的调用链有了这些独立 skill我就可以编排一个完整复盘流程了。当我在飞书里说复盘时模型会读取各 skill 的描述决定调用顺序先行情快照拉指数和自选股状态再财报公告龙虎榜 skill 扫风险事件最后盘后异动 skill 汇总当天触发提醒的标的。这几个 skill 的执行结果都是不同结构的 JSON模型把它们拼接成统一报告写成消息卡片发回飞书同时扔一份到云文档里归档。用户看到的是一条复盘指令、一份完整报告背后其实是四五个 skill 在流水线上协作。一个 skill 的配置结构大致是这样SKILL { name: snapshot_quote, description: 获取单只股票/指数的行情快照和常用技术指标适合询问当前状态、均线、量比、MACD 时调用, input_params: [symbol, period], execute: call_my_trading_module(symbol), output_format: json, output_fields: [close, pct_chg, volume_ratio, ma5, ma20, macd, rsi14] }当然这是示意具体字段以你所用框架的 skill 规范为准但整体思路是通用的。5. 飞书集成进阶消息卡片、表格、定时任务与云文档机器人能跑通基础问答之后我开始做体验层面的东西。毕竟用户也就是我自己每天要盯着飞书看如果收到的是一坨密密麻麻的纯文本我宁愿退回原来的手动流程。5.1 为什么放弃纯文本改用消息卡片纯文本的问题在于手机上阅读体验太差一段复盘报告 800 个字在飞书里就是连续几个消息气泡想回头找某只股票的数据要往上翻半天而且数字一多根本抓不住重点。消息卡片可以把内容结构化底部有按钮可以点击展开更多、关键数字可以放在表格里、风险提醒可以用不同底色区分。我在 OpenAI 兼容格式的基础上把复盘报告做成了结论先行 详情折叠 表格明细的卡片结构。大概长这样{ msg_type: interactive, card: { header: {title: {tag: plain_text, content: A股收盘复盘 2025-06-01}}, elements: [ {tag: markdown, content: **结论** 市场缩量下跌关注池 3 只触发止损提醒}, {tag: hr}, {tag: table, content: 股票代码 | 涨跌幅 | 量比 | 信号\n000001 | -2.3% | 0.7 | 跌破MA20} ] } }细节字段以飞书卡片最新文档为准但结论放头部、表格放中间、折叠放后部这个思路我强烈推荐。5.2 机器人发送表格的三种姿势交易分析里表格是逃不开的比如持仓列表、自选池状态、龙虎榜明细。我陆续试了三种方式各有适用场景。姿势实现方式适用场景卡片内嵌表格消息卡片里用表格元素展示数据日报、盘中提醒打开就能看上传 CSV/Excel调用飞书文件上传 API把生成的表格文件发到群里明细太多、需要下载二次分析写入多维表格调用 bitable API创建数据表并逐行写入长期历史复盘、周度汇总统计实践下来日报我用卡片内嵌表格因为只看一眼就能做决策周度数据我会让机器人把汇总表生成为 CSV 上传到群文件方便我导出到本地做进一步统计而每日的完整复盘记录我直接写入飞书多维表格相当于自动维护了一个复盘数据库月底可以按股票代码、信号类型做筛选。5.3 定时任务怎么排才不打扰定时任务是 AI Trading Partner 的主动性来源但排不好就变成了骚扰源。我最终的 cron 表是这样排的08:55 盘前要闻隔夜外盘、当日重要公告、宏观数据日历。09:25 竞价异动自选池竞价涨幅过大或异常的标的。11:35 午间简评上午大盘状态和板块涨跌控制在两条消息内。15:10 收盘简评指数、成交量、涨跌停家数。15:40 完整复盘触发条件较多的完整复盘包含持仓风险提醒。21:00 晚间公告与龙虎榜当天晚间公告和收盘后龙虎榜数据。注意每条定时任务的间隔至少要错开十分钟以上。第一次上线时我把盘前要闻和竞价异动排在了同一分钟飞书直接把第二条消息吞掉了后来才意识到是频控问题后面第五节会详细讲。5.4 把复盘报告沉淀到飞书云文档每日复盘如果只在群聊里发一遍就结束时间长了就找不到了。我在飞书云文档里建了一个复盘归档目录每次复盘完成后机器人通过开放平台 API 新建一篇 docx把复盘报告和关键信号写进去文件名按日期命名。这样我在手机上随时可以翻历史复盘翻到哪一天就能看到那一天的市场状态和我的判断依据。最近我还看到有人在折腾 lark sync 这类同步方案把飞书云空间的文档同步到本地笔记库和 Obsidian 双向打通。我正准备在下一步把复盘归档目录同步到本地这样我的每日笔记、持仓记录和复盘报告就能在一个知识库里互相引用。6. 踩坑记录这三天我都经历了什么最后聊聊真正让这套系统变稳的几个坑。说实话前面所有配置加起来花的功夫不如这几个坑带来的教训多。6.1 回调 URL 校验失败内网穿透和加密密钥的坑第一天晚上我折腾了三个小时飞书事件订阅一直报URL 校验失败。一开始我以为是内网穿透工具不稳定换了两三个工具都不行后来想到可能是加密配置问题关掉 Encrypt Key 再试竟然秒过。原因是我在 OpenClaw 里把加密开关打开了但框架侧飞书通道的加解密校验规则和飞书文档里描述的版本不匹配。幸好 OpenClaw 是开源的我直接看了源码里飞书适配器对 Encrypt Key 的处理逻辑发现它只支持一种固定的 AES 模式而飞书后台默认推荐的配置是另一种模式两边各说各话。解决办法要么保持飞书后台的加密配置与框架源码一致要么干脆关掉加密只用 Verification Token 校验。本地调试我建议先关加密把链路跑通了再在服务器上开加密。6.2 长文本被截断从纯文本换成卡片分段机器人刚接入飞书时我用纯文本发消息结果长一点的复盘报告会被飞书直接截断有时候最后几行关键结论就这么没了。排查后发现飞书对单条文本消息的长度有限制不是 agent 框架的问题。解决方案是把文本消息全部改造为消息卡片卡片对内容长度的容忍度高得多而且可以把内容拆成多个元素块结论块、表格块、折叠块。改造之后再也没有出现过消息被吞的问题。这里有个小技巧如果你要给用户看的内容特别长与其一直往下堆文字不如分成摘要卡片 详细文档链接两层摘要卡片只给结论详细信息写进飞书云文档。6.3 本地模型的正确的废话工具调用链经常断本地模型跑通后我发现一个现象它很爱说根据我的分析该股票近期走势较强这种废话但让它严格按 JSON 格式输出工具调用参数时却经常出错导致调用链断掉。后来我定位到原因开源小模型在语义理解上还凑合但严格遵循指令格式的能力确实弱。解决办法有两招重要交互链路全部走云端模型宁可多花点 token也要保证调用链稳定本地模型的批量任务场景我给每条 skill 都配了 few-shot 示例先在调试环境跑通再放生产。还有一招更简单粗暴如果发现模型持续输出格式错误直接把它的 temperature 调低到 0.2 以下输出稳定性会肉眼可见地提升。6.4 机器人被限流消息推送节奏控制第一次部署定时任务那天早上八点五十五我一次性让机器人发了四条消息盘前要闻、竞价异动、持仓提醒、昨日未读公告。结果第二条之后飞书直接把后续消息吞了群里安静得像没发生过一样。查了开放平台文档才知道机器人发消息有频控限制短时间大量发送会被限流甚至禁言。后来我把 8 点 55 到 9 点 25 的定时任务做了合并同类消息合并成一张卡片不同类的任务错开时间。最重要的经验是定时任务推送宁可合并、不要拆散一个时间段只让机器人说一次话。6.5 在安卓上跑 OpenClaw 的尝试与放弃看到有人用 Termux 在安卓上部署 OpenClaw我也试了一次。理想很丰满随身带着个人 AI 助手出门在外也能处理任务。现实很骨感手机内存不够跑本地模型云端 API 倒是能用但 Termux 里的进程很难常驻后台锁屏一会儿就被系统杀掉了而且手机的网络唤醒策略极其折腾。折腾了半天我最终放弃手机端把 OpenClaw 作为常驻服务跑在主力 Windows 机上配好开机自启和掉线重连手机上只装飞书客户端作为纯粹的交互入口。Windows 上那块之前大家常问的 companion 配置其实主要就是解决怎么能让服务开机自动跑、断网自动恢复的问题我把这些做成系统计划任务和看门脚本之后就再没管过它。真要说这套东西值钱在哪我觉得既不是模型也不是飞书而是它逼着我把自己的交易规则全部显性化了。以前我脑子里那些差不多了感觉要启动的模糊判断现在全变成了写在 prompt 和 skill 里的明确参数均线多少、量比多少、盈利增速达到什么水平才算合格。哪怕哪天我决定换回手动盯盘这套规则也能随时拿出来对照执行。下一步我准备把每天的复盘报告通过 lark 同步到本地笔记库和 Obsidian 的每日记录打通让这个 Trading Partner 不只是盘后助手还是我自己的交易日志管家。整个项目代码量不算大但对个人交易系统自动化这件事来说它已经是我生产力提升最明显的一次改造了。