用WorkBuddy搭建7×24小时AI投研团队：岗位设计到落地复盘

写今天这篇之前，我刚结束一天的盯盘和复盘。说实话，一个人做投研最累的不是分析，而是那些绕不开的重复劳动：早上翻隔夜市场、白天盯公告和新闻、晚上拆财报、深夜还要写纪要。一个月前，我把这套活儿交给了用 WorkBuddy 搭起来的一支 AI 投研团队，让它 7×24 小时待命，运行到现在效果比我想象中好，也踩了不少坑。这篇就把整个搭建过程、岗位设计、模型接入和排雷经验完整复盘一遍，给同样在一个人做研究、写报告、整理信息的读者一个可以直接参考的落地模板。

1. 一个人做投研的痛点：数据太多、盯不过来、写不完

1.1 投研工作里"高频重复又不得不做"的那部分

我身边不少做研究的朋友，包括我自己，都陷入过同一种状态：真正花在"思考"上的时间，其实只占一天工作的一小半，剩下大半时间都耗在信息搬运上。

早上第一件事，是把隔夜美股、欧洲市场、商品期货、政策新闻，以及前一天的收盘数据汇总成一份材料。盘中要盯着行情异动，同时留意公司公告、交易所问询函、行业新闻。盘后更重，定期报告披露季来了，一份年报上百页，要把关键财务科目从三张表里捞出来，拆解同比、环比变化，整理成可用的卡片。碰到电话会、调研纪要，还得边听边整理成文字版。这些工作有一个共同特点：对智力要求不高，但对细致程度、时间密度要求极高，而且每天都会卷土重来。

我算过一笔账，一个覆盖 3 到 5 只重点标的的独立研究者，光是把"信息收集 + 初步整理"做好，每天至少要花 3 到 4 个小时。这个时间挤占的是真正该用来做判断的时间。更麻烦的是，很多信息是时效性的，错过晚高峰，等到收盘后再看，可能已经错过最好的介入观察窗口。所以问题不是"要不要用AI"，而是"用什么样的 AI 方式才能真正把人从流水线上解放出来"。

1.2 为什么"多开几个聊天窗口"解决不了问题

很多人面对这种场景时的第一反应是：我把 Kimi、豆包、ChatGPT 全部打开，哪个适合读长文就用哪个，哪个适合搜索就用哪个。我自己也这么试过，坚持了一周就放弃了。

原因很直接：

• 聊天窗口是"你在等它"的模式，所有任务都得手动发起，没有任何主动触发的机制；
• 信息还是得靠人搬运，从一个窗口复制到另一个窗口，再把结果粘贴到笔记里，自动化程度很低；
• 每个窗口都是独立的，上下文不共享，上午问过的背景下午还要重新交代一遍；
• 没有固定的输出模板，今天让它写晨报是一种格式，明天换个说法就是另一种格式，后期整理反而更费劲。

聊天助手本质上是一个"很聪明但没有工位的顾问"，你喊它它才动。而投研这种工作，需要的是有人每天定时到岗、按 SOP 干活、把结果放在固定位置，这完全是两种工作方式。也正是在这个背景下，我开始认真研究 AI Agent 工作台这类工具，最终选定了 WorkBuddy 作为常驻载体。

1.3 从"问答式用 AI"到"排班式用 AI"的思路转变

把 AI 从"问答式"升级成"排班式"，核心变化在于角色和责任，不只是技术。

问答式时代，用户是唯一的信息入口，自己判断该问什么、把材料喂进去、把结果拿走。到了排班式时代，用户变成了管理者：给 AI 定义岗位、写岗位说明书、设定工作流程、约定输出格式，然后让它自己去面对一堆原始信息流。AI 成了流水线上的工人，人成了流程设计者和最终复核者。

这个转变最大的好处是，AI 的能力被"流程"稳定下来。单次调用大模型，结果是有随机性的，今天让它写晨报写得像模像样，明天可能就胡言乱语。但如果你把"岗位说明书 + 输入数据 + 输出模板 + 质检点"这四个要素固定下来，再配合多次运行和失败重试，它的表现会稳定到接近一个靠谱的初级研究员。WorkBuddy 恰好提供了把这四要素固化下来的能力：Agent 角色管理对应岗位说明书，Skill 对应作业手册，工作流编排对应流程，定时任务对应排班。

2. WorkBuddy 在 AI 投研团队里扮演什么：不是聊天机器人，是调度中枢

2.1 先搞清楚 WorkBuddy 到底是什么

我对 WorkBuddy 的理解，可以概括成一句话：它是跑在本地的 AI 工作台，核心能力不是"聊天"，而是把多个大模型、多个角色、多个任务流程统一调度起来。

普通用户接触最多的 AI 产品，是那种打开网页就能聊天的助手，你问一句它答一句。WorkBuddy 的思路不一样，它更像一个"AI 时代的操作系统"，你在里面可以完成几类核心操作：

• 统一接入多个大模型的 API，不同任务可以指定用不同模型；
• 把某一个角色的完整设定保存下来，变成一个可复用的 Agent；
• 给 Agent 挂载技能包（Skill），技能包里放着作业流程、模板和质检清单；
• 用工作流把多个 Agent 串起来，前一个 Agent 的输出会自动成为后一个 Agent 的输入；
• 支持定时触发和外部 API 调用，让任务可以在无人值守的状态下自动运行。

如果用一句话类比，ChatGPT 这类产品是"懂很多但只会等吩咐的顾问"，WorkBuddy 则是"给顾问们排班、发工单、盯进度的车间主任"。它不是某一个模型的替代品，而是把各家模型组织起来干活的中枢。

2.2 和豆包、Claude Code、CodeBuddy、Obsidian 的边界怎么划

很多人看到 WorkBuddy 的第一反应是：这和豆包有什么区别？和 Claude Code 是不是一回事？我实际用下来，觉得边界其实很清楚。下面这张表是我个人视角的定位对比：

我的实际组合方式是：WorkBuddy 当调度和总装线，Claude Code / CodeBuddy 这类工具在需要写数据处理脚本时单独拉出来用，最终报告统一落到 Obsidian 的 vault 里做长期沉淀。WorkBuddy 和 Obsidian 不是竞争关系，前者负责加工信息，后者负责存储沉淀。

2.3 为什么投研场景特别吃"流程编排"而不是"单点对话"

投研工作的产出，本质上是一条流水线：原始信息 -> 提取关键变量 -> 初步判断 -> 结构化输出 -> 人复核决策。这条流水线里，单点 AI 对话能做到的只是第一环到第三环的零散片段，而且每一环之间的衔接，比如把舆情摘要喂给写手、让拆好的财务数据进入模板，如果靠人手动搬运，前面省出来的时间又全浪费了。

WorkBuddy 的价值恰恰在这里：它把环节之间的"搬运工"角色承担了下来。我在实测中发现，只要把数据传递协议定清楚，也就是规定每个 Agent 的输出格式必须是某种固定的 Markdown 表格或 JSON 结构，整条流水线就能自动跑通。这也是我觉得 WorkBuddy 这类工作台，相比聊天助手，更适合做"7×24 团队"的根本原因：聊天窗口没有流程概念，而投研这种工作，全流程自动化才能真正把时间省下来。

3. 团队岗位拆解：宏观扫描、财报拆解、舆情监控、纪要整理四个岗位如何分工

3.1 岗位一：市场晨报员，每天 8:40 前把隔夜信息压缩成一页纸

我给这支 AI 团队设置的第一个岗位是市场晨报员，职责非常简单：每个工作日早上 8:40 之前，基于我配置的信息源，输出一份三分钟能读完的晨报。

晨报的输入源包括：隔夜美股三大指数、欧洲主要指数、WTI 和布伦特原油、COMEX 黄金、美债收益率、当日早上 8 点前的国内政策类新闻、昨天 A 股收盘的行业涨跌数据。这些都是可以在公开渠道拿到的数据，我整理成固定的源后，让 WorkBuddy 通过定时任务去拉取。

晨报员的 Prompt 我改了三版才稳定下来。第一版只写了"帮我总结隔夜市场"，结果它输出了一堆教科书式的废话，没有重点。第二版加了来源范围和字数限制，好了一些，但还是缺少"影响路径"。第三版我干脆给了一个固定模板，必须按"隔夜要点 / 今日关注 / 风险提示 / 昨日数据回顾"四段输出。这个模板把它的工作方式彻底约束住了。有关键一点，晨报里所有结论后必须带依据，比如"美股新能源板块走强（费城半导体指数 +2.1%，特斯拉 +3.2%）"，不允许出现没有出处的判断。

3.2 岗位二：财报拆解员，把三张表变成结构化数据卡片

第二个岗位是财报拆解员。投研里最怕 AI 做的一件事，就是编数字。所以我给这个角色的最高指令是：只从给定材料中提取信息，绝不调用训练记忆里的"知识"，材料里没有的字段就填 N/A。

财报拆解员的输入，是定期报告的全文文本。我先把 PDF 转成纯文本，丢给它，让它抽取这些关键科目：营业总收入、归母净利润、扣非净利润、毛利率、净利率、经营性现金流、研发投入、应收账款、存货、合同负债，以及每个科目的同比变化。输出要求是一张 Markdown 表格，外加三条以内的重要变动说明。

这个岗位的 Prompt 里我专门加了一整段"禁止事项"：不得编造不存在的财务数据；不得使用"约""大概"这类模糊表达；如果要写同比变化，必须给出计算所依据的两个原始数值。实测下来，这份约束非常有效，它能保证输出的东西可以直接进入下一道环节，不需要我再花时间做格式清洁。

3.3 岗位三：舆情雷达兵，监控公告、新闻、互动易并做去重初判

第三个岗位是舆情雷达兵。它的职责是盯着公司公告、主流财经媒体的快讯、交易所的问询函回复，以及投资者互动平台上的高热度问答。

舆情雷达兵输出的事件流，每条都要包含几个固定字段：事件标题、事件类型、来源、发布时间、情绪倾向初判（利好 / 利空 / 中性）、是否需要人工重点复核。这个角色最核心的能力是"去重"。同一件事，公司在互动易上答一次，财经媒体发三篇快讯，雪球上又有十几个帖子，如果不做去重，下游统计会被直接带偏。我的解决办法是给雷达兵一条规则：先按标题相似度做粗聚类，同一事件只保留信息量最全、来源最权威的一条，并标注事件被多少家独立来源报道。

刚开始雷达兵经常把"利好""利空"判断错，比如把"大股东承诺不减持"判成中性。后来我在它的 Skill 里加了一个分类词典，把"增持、回购、中标、获批、业绩预增"归入偏利好，"减持、质押、诉讼、问询、下修"归入偏利空，"人事变动、日常经营、投资者关系活动"归入中性，准确率才明显上来。

3.4 岗位四：复盘写作员，把零散结论变成可归档的纪要

最后一个岗位是复盘写作员。前面三个岗位输出的都是结构化卡片式内容，生产出来还比较碎，复盘写作员的工作是把这些碎块组装成一份完整、可读、可归档的复盘纪要。

复盘写作员的输出结构我定为四个部分：

• 今日发生了什么：按重要性排序的事实清单；
• 影响路径是什么：每个事实可能影响的产业链环节和上市公司逻辑；
• 哪些信息还没落地：比如某项传闻尚未得到公告确认，某个新签订单还没有收入贡献的时间表；
• 需要进一步查证的问题：给人类研究员的下一步行动提示。

我对这个岗位还有一个特殊要求：区分"事实"与"推测"。每一句推测都必须以"推测"两个字开头，后面注明推测依据。这样读纪要的人能一眼看清哪些是机器判断，哪些是硬信息。实测中这个岗位的可用性最高，因为它不直接面对原始材料，输入已经是经过前面几道工序净化的中间产物，出错概率天然低。

3.5 四个岗位之间的数据传递协议

整个团队能跑起来的核心，不是单个 Agent 有多聪明，而是四个岗位之间的数据传递协议足够严格。

我定的协议很简单：所有中间产物一律输出为"Markdown 表格 + 结论段落"的组合。表格负责承载结构化数据，结论段落负责解释。下游岗位只认表格特定列的字段名，比如"事件类型""财务科目""同比变动"，字段名对不上，工作流就报错，而不是强行往下走。

这套协议让整条流水线具备了可调试性。比如财报拆解员如果某天输出里"净利润"列变成了"归母净利润（元）"，工作流会解析失败，然后自动触发一次重试，把模板重新灌给它。重试两次仍失败，就会生成一条告警通知我人工处理。这比让每个岗位自由发挥可靠得多，也是我最推荐复制的一条经验。

4. 从安装到上岗：环境配置、模型接入和第一个 Agent 的诞生

4.1 安装与工作台初始化：三类系统的差异

WorkBuddy 支持主流的桌面系统，官网下载对应安装包就可以。我自己主力机是 macOS，另外一台跑数据定时任务的机器是 Linux，Windows 也试过。三者的初始配置有一点差异，值得单独说一下。

Windows 上安装之后，建议把开机自启动打开，否则"7×24 待命"无从谈起。macOS 上首次运行如果要用全局快捷键唤起或自动处理剪贴板，需要在系统设置里给 WorkBuddy 开放辅助功能权限，这个容易漏，跑了半天才发现快捷键无效就是它的问题。Linux 上是重头戏，我用的是 .deb 包装在 Ubuntu 上，装完之后一定要通过 systemd 用户服务把 WorkBuddy 常驻起来，而不是依赖终端挂起。终端一关，定时任务全部失效，这是最容易踩的坑之一。

工作区初始化时，我专门建了一个名为 ai-research-team 的目录，里面分三个子目录：skills/ 放技能包，outputs/ 放每份报告成品，contexts/ 放共享的项目背景资料。这样做的目的是让所有 Agent 都能从约定位置读写文件，而不是各写各的，最后找不到东西。

4.2 模型接入：主力推理选 DeepSeek，为什么还要多备一个模型

WorkBuddy 可以同时接入多家模型服务商的 API。我在接入时的原则是：主力推理用 DeepSeek，关键任务用双模型交叉验证。

选择 DeepSeek 作为主力，主要看中两点：一是推理质量在同价位里确实能打，尤其是长文本理解和财务材料提取，实测效果接近我用过的更贵模型；二是成本确实便宜，作为 7×24 小时常驻的任务系统，token 消耗量比人工对话大一个量级，成本必须压下来。

我做过一个粗略估算，按每天跑 20 次任务、每次任务平均消耗 1 万 token（输入输出合计）算，一个月大约 600 万 token，按 DeepSeek 的定价，混合输入输出后的成本大约在个位数到十几元人民币这个区间，基本可以忽略。如果全部换成更高价的模型，这个数字会翻十几倍，运行一个月后可能就没动力继续跑下去。

不过还要备一个模型的原因，是为了交叉验证关键数字。市场晨报这种摘要类任务，单模型跑没问题；但财报里的重大金额、同比变动这类关键数据，如果只信一个模型的输出，等于把赌注全押在一次采样上。我目前的做法是：财报拆解员的输出，每个月挑 9 份以上重点标的，用另一个模型重新跑一遍，两边数字不一致就自动告警，我再人工核对原始报告。成本多花一点，但防住了一次数字错误，可能就值回一年的 API 费用。

4.3 用"岗位说明书"方式写 Agent 的 System Prompt

我在创建第一个 Agent 之前，做了个关键决定：不用传统的"提示词"思路写 Prompt，而是按"岗位说明书"的格式来写。两者的差别在于，提示词是给 AI 的一个请求，岗位说明书是一份包含职责边界、操作规范、输出模板、自检清单的完整文档。

下面这份是我给财报拆解员写的岗位说明书核心片段，也是团队里第一份稳定运行的模板：

# 角色：财报拆解员 ## 职责范围 - 负责从给定定期报告全文中提取核心财务数据； - 负责计算关键科目的同比、环比变化； - 负责输出结构化财务卡片。 ## 输入协议 - 输入：report_text（定期报告纯文本） - 来源范围：只允许基于 report_text 的内容，不得使用训练记忆中的任何数据 ## 输出协议 - 输出格式：Markdown 表格，字段名固定如下 | 财务科目 | 本期数值 | 上期数值 | 同比变动 | 备注 | - 缺失项填写 N/A，禁止使用“约”“大概”等模糊词 ## 工作 SOP 1. 先提取利润表核心科目，再做现金流量表，最后看资产负债表的应收、存货、合同负债； 2. 计算同比变动时，必须列出公式与原始数值； 3. 输出三条以内的重要变动说明，每条必须带一句原文佐证。 ## 禁止事项 - 不得编造材料中不存在的财务数据； - 不得直接给出投资建议； - 不得在输出中出现分析性形容词（如“表现优秀”“显著改善”），只能用数据说话。 ## 质量自检清单 - [ ] 所有数值是否都来自 report_text？ - [ ] 同比变动是否有原始数值计算公式？ - [ ] 是否包含任何“投资建议类”表述？

这份说明书跑完第一轮之后，输出质量的确比随便问一句"帮我看看这份财报"高出一个层级。原因不难理解：投研工作需要的是稳定复现，不是灵光一现。岗位说明书把不确定的生成过程变成了相对确定的"按单执行"。

4.4 第一个 Agent 实测：让市场晨报员跑出第一份完整日报

第一版 Agent 配置好之后，我直接让它跑了一天的真实数据。结果谈不上完美，但足以让我确认方向是对的。

当天早上 8 点 40 分，WorkBuddy 自动触发市场晨报员任务。它从预置的信息源拉取隔夜行情，生成了约 600 字的晨报，把美股三大指数、原油、黄金、10 年期美债收益率、前一日 A 股行业表现五项数据全部覆盖。格式完全符合我预设的模板，而且每一条结论后面都带了具体数值。我第一次真正体会到"有人替你值早班"是什么感觉。

不过这版晨报也有明显问题：它对"隔夜重要政策新闻"的筛选标准偏松，把一条只有边际影响的行业小政策当成了"今日关注"第一条。这让我意识到，光有岗位说明书还不够，还要在技能包里加入"重要程度分级规则"。我随后加了五级重要度标签，只有达到 A 级（涉及行业全局定价逻辑）和 B 级（直接涉及重点跟踪公司）的事件才能进入"今日关注"，这个毛病才被治住。

5. 把四个人拧成一条流水线：Skill、工作流编排与定时任务

5.1 Skill 是什么：给 Agent 装的"工作手册"，而不只是一句听话指令

WorkBuddy 里 Skill 这个概念，我一开始没当回事，直到我发现它才是整个系统的"魂"。Agent 是工人，Skill 就是工人的工作手册。岗位说明书告诉工人"你是什么岗位、该干什么"，Skill 则更细，告诉工人"每一步具体怎么干、按什么模板出活、达到什么标准才算完"。两者的关系是：岗位说明书是总纲，Skill 是可执行的 SOP。

我的 Skill 目录组织方式很简单，每个技能一个文件夹：

skills/ market_brief/ SOP.md # 晨报任务的操作步骤 template.md # 晨报输出的固定模板 examples/ # 两到三个历史优秀输出样例 financial_parser/ SOP.md template.md field_dict.md # 财务科目别名与标准字段对照表 sentiment_radar/ SOP.md classification_dict.md # 利好/利空/中性事件类型词典

这里有一个重要经验：Skill 里必须放"优秀输出样例"。大模型从小样本里学习的效率远大于指令，给它两个写得好的晨报作为例子，比反复强调"要有重点、要简洁"有效得多。我后来每次手动修改 AI 产出的报告，都会把修改后的版本追加到 examples/ 里，相当于技能包本身也在持续训练。

5.2 用工作流把岗位串起来：前一个 Agent 的输出变成后一个 Agent 的输入

岗位设计好了，Skill 备齐了，下一步就是让四个人（四个 Agent）按顺序配合。WorkBuddy 的工作流编排器支持把多个 Agent 串成 DAG（有向无环图）结构，前一个节点的输出会作为后一个节点的上下文传入。

我的每日晨间流程是这样配置的，用 YAML 描述大致逻辑：

workflow: morning_cycle schedule: cron(0 8 * * 1-5) steps: - agent: sentiment_radar task: pull_news_and_announcements output: radar_events.md - agent: market_brief task: generate_morning_brief input: radar_events.md output: morning_brief.md - agent: financial_parser task: check_financial_updates input: radar_events.md when: "events contains '业绩' or '财报'" output: financial_cards.md - agent: review_writer task: compose_daily_summary input: [morning_brief.md, financial_cards.md] output: daily_review_repo/YYYY-MM-DD.md

这个配置的核心在于第三步的条件触发。舆情雷达兵发现当天的信息流里有"业绩""财报"这类关键词时，财报拆解员才会被拉进流水线；没有财报任务时，流水线会跳过它，不浪费 token。这种按需触发的方式，把日均 token 消耗压到了很低的水平。

5.3 定时任务与触发机制：cron 配置和"错过补跑"策略

"7×24 小时待命"在 WorkBuddy 里是靠定时任务加外部触发实现的。我目前配置了三个主要触发点：

• 每个工作日 08:00，触发舆情雷达兵拉取早间公告和隔夜新闻；
• 每个工作日 08:40，触发晨间流水线，生成晨报；
• 每个交易日 15:10，触发盘后复盘流水线；
• 每半小时，舆情雷达兵做一次增量轮询，发现高优事件立即推送告警。

定时配置用的是 cron 表达式，如果你之前没接触过，可以直接在 WorkBuddy 的调度界面里用可视化方式选择时间和频率，不用手写表达式。

真正要提醒的是"错过补跑"策略。电脑一旦进入休眠状态，或者网络断了，就算有定时任务也跑不起来。我的对策是在 WorkBuddy 里给每个任务加了一个 last_run 记录，任务开始时先检查当前时间和上次完成时间，如果发现超过预定周期且任务未执行，就立即补跑。这里有一个比较微妙的点是，补跑顺序要按时间先后排列，不能全部并发执行，否则多个任务同时请求模型 API，容易出现限流导致批量失败。我把补跑任务设置为串行队列，宁可慢一点，也要保证每份报告都实际产出。

5.4 人机复核点：哪些环节保留人工确认，哪些环节可以放心全自动

很多读者可能会问，这种流水线跑起来，是不是就意味着完全不用看了？我的答案很明确：不是，绝对不行。AI 投研团队能替代的是"信息整理"和"初步分类"这类确定性工作，不能替代的是"判断"和"责任"。

我按照"错误代价"来划分复核级别：

• 自动执行不加人工：舆情去重、晨报内容汇总、格式排版、历史纪要归档。这些环节出错代价低，重跑一次就能修复。
• 结果人工确认：所有涉及具体金额、同比变动、增减持方向的内容，必须触发复核告警。这类错误代价高，一次误导可能导致错误判断。
• 双模型交叉验证：对重点标的的重大财务科目变动，用两个不同模型分别跑，数字不一致时挂起等待人工处理。

我实测下来，这个复核体系比较合理，既不会让人累死在人工审核里，也不会让机器错误在无人知晓的情况下进入最终报告。

6. 一次真实排班记录：让团队跑通一个完整标的分析

6.1 测试标的与输入数据：选取一个公开信息充足的新能源产业链公司

为了验证整套系统在真实场景下的表现，我选了一个样本：某新能源产业链上市公司（下称 ZD 科技，信息经过脱敏处理）。选它的原因有几点：公开财报和公告多，便于验证信息完整性；行业关注度高，舆情事件密集，适合测试雷达兵的筛选和去重能力；同时它的业务与市场政策联动紧密，能看出晨报员对行业层面的理解是否合格。

需要先声明，这里只是把它当流水线测试样本，不构成任何投资建议。AI 投研团队做的是"把信息整理成结构化资料"这件事，最终判断必须由人完成。

测试从周一开始，这意味着舆情雷达兵需要在一天内处理周末两天积累的公告和新闻，任务量比较有代表性。

6.2 从舆情原文到最终纪要：信息是怎么一步步变干净的

我把实际的输入和输出按流水线步骤复盘一下。

第一步，舆情雷达兵先跑了早间公告拉取。一个小时内，它从公告源、新闻源聚合了 17 条原始信息。经过标题聚类和内容去重后，最终收敛为 6 个独立事件：一份定增预案修订公告、一条回购进展公告、一条监管问询函回复、两条行业政策解读类新闻、一组投资者关系活动记录。

第二步，市场晨报员拿到雷达兵的事件清单，结合隔夜外盘和行业数据，生成晨报。它把定增预案修订列为今日关注，理由是定增拟募资规模出现明显缩减，可能影响公司未来扩产节奏的判断，影响路径写得比较清楚。

第三步，因为当天信息流里包含"投资者关系活动记录"和"业绩相关提问"，条件触发让财报拆解员进入流水线。它从投资者关系记录文本里抽取了公司管理层对 2024 年营收增速区间的口径表述，做成了结构化卡片。

第四步，复盘写作员把前三步的产物汇总成一份当日纪要，输出到 Obsidian 归档。纪要的结构是：事件清单、对业绩的可能影响路径、未落地信息（比如定增方案还需股东大会审议）、下一步要查证的问题（比如"产线投产进度在季报中是否有更明确指引"）。

整个过程从触发到归档，耗时约 25 分钟，其中大部分时间是模型推理等待，人工参与为零。

6.3 实测下来，有一个环节需要人工介入了

这次排班跑下来并不是完美无缺，财报拆解员在提取"投资者关系活动记录"中一个关键数据时出了错：管理层说"2024 年出货量预计同比增长约 18%"，这本来是好消息，结果拆解员把"同比增长"理解成"较上年同期下降"，在结构化卡片里输出成了"出货量同比下降 18%"，情绪初判直接变成利空。

好在我在工作流里设了关键数据复核告警。这个字段"同比变动"属于需要人工确认的类型，所以它没有直接进入最终纪要，而是生成了一条复核提醒，把我拉进来人工查看原文。我一核对，立刻发现方向错了，修正标注后重新交给复盘写作员，最终纪要是正确的。

这次翻车给我两个有价值的提醒。一是中文财务语境里"较上年同期下降 18% 和同比增长 18%"是两种完全不同的方向，模型有时会理解反，数字绝对值越大，方向错误的风险越高。二是我把复核点设计在流水线中间而不是末尾，是正确决定，它阻止了错误信息进入最终归档文件。假如复核点设在全部输出之后，我可能根本不会去检查那份财务卡片。

6.4 这不能用来直接下单：AI 投研的边界与人工复核

这次实测让我对"7×24 待命"有了更实际的认知。它能做到的，是随时把信息流梳理好，把该关注的公告、财务变化、舆情方向摆到你面前；它做不到的，是替你形成投资结论。模型理解错方向、漏掉关键上下文、给出看似合理但站不住脚的推测，这些都可能在任何一个 Agent 上发生。所以我把复核点视为整个系统的一部分，而不是多余的检查。

尤其在涉及真金白银的场景里，我强烈建议不要绕过复核直接使用机器产出。AI 投研团队是望远镜和筛子，不是导航仪。它帮你看到更多、筛得更快，但方向盘永远要抓在自己手里。

7. 连续跑一个月后，我最想提醒你的 7 个坑

7.1 上下文窗口撑不住长文本？让每个 Agent 做"窄而深"的事

第一个踩到的问题，是我一开始为了省事，让一个 Agent 同时承担"读完整份财报 + 写纪要"两件事。结果它的输出在中间部分明显出现信息丢失，前面章节的数据记得清楚，后面章节的内容开始混淆。原因不复杂，一次塞给模型的上下文越长，它对中间位置的注意力就越低。

解决办法是强制拆分：财报拆解员只做数据抽取，复盘写作员只做文字组装，中间用固定格式对接。每个 Agent 的输入都被控制在它最擅长的范围内，输出质量立刻稳定下来。这个经验我称为"窄而深"，一份长材料，拆成职责窄的小任务并行处理，比让一个全能 Agent 从头读到尾可靠得多。

7.2 模型幻觉会在关键数字上翻车：用交叉验证 SOP 兜底

第二个坑在实测部分已经说过，财报拆解员把"同比增长"理解成"下降"，方向判断反了。这种幻觉很难靠提示词完全消除，只能靠流程兜底。

我现在对重点标的的关键财务科目，采取双模型并行验证的方式。两个模型各自独立跑同一份材料，输出的数值如果不一致，工作流会生成一条差异告警，然后交由我人工核对原文。我的经验是，交叉验证不需要覆盖所有字段，那样成本太高，只覆盖几个高影响字段就足够：营收、净利润、毛利率、经营现金流、同比变动方向。其他的低敏感字段，单模型跑完直接过，节省成本。

7.3 定时任务在电脑休眠后"漏岗"：补跑机制必须做

连续跑了大概两周，我发现某个周一的晨报没有按时出现。排查后确认，原因是周末电脑进入了休眠，定时任务根本没被触发，周一早上大家看到的还是周五的旧报告。

这个坑我之前提过解决思路，这里再补一个细节：补跑逻辑不能只覆盖"当天任务"，还要处理"昨晚已经错过的任务"。我的做法是给每个任务配一个持久化的 last_success_time 字段，每次启动时扫描一次，如果发现时间差超过一个调度周期，就把错过的任务按原定时间顺序依次补跑。这个机制已经在一次电量耗尽强制关机后验证过了，恢复供电再启动时，系统把错过的两轮舆情轮询自动补齐，没有任何告警遗漏。

7.4 不同模型输出格式打架：用固定 Schema 约束下游

WorkBuddy 支持多模型混合使用，但这会带来一个新问题：不同模型对同样的格式指令服从度不同。有的模型会老老实实按 Markdown 表格输出，有的则会在表格前面加一句"好的，以下是输出结果"，导致下游解析对不上。

我的解决办法是两层保险。第一层，给每个 Agent 的 Skill 里植入一个输出 Schema 校验器，要求模型在正式输出前先自我检查是否符合模板，不符合就重新修正。第二层，工作流解析端做容错，如果某一步解析失败，自动把这步重新跑一遍，重试两次仍失败才告警人工。这两层配合下来，格式问题导致的流程中断已经基本消失。

7.5 别把 API Key 写死在 Skill 文件里：用环境变量管理

早期我图省事，把某个模型 API Key 直接写进了 Skill 的配置文件里，后来我的一个技能包文件夹被分享给别人做参考时，差点泄露了 Key。虽然是内部工具，但这种习惯非常危险。

正确做法是把 API Key 统一放在环境变量里，WorkBuddy 在加载任务时自动注入。我在所有 Skill 的配置里都不会出现明文密钥，只有 ${DEEPSEEK_API_KEY} 这类占位符。这个习惯一定要养成，尤其是未来 Skill 社区化分享会越来越频繁，这个问题会变得更加关键。

7.6 同一事件多源重复报道导致舆情计数虚高：去重要看质量不看数量

舆情雷达兵最初版本的计数逻辑太简单，直接把所有新闻条数当作事件数统计。某一天某公司发布减持预披露公告，市面上各种渠道发了 30 多条相关快讯，雷达兵把"事件数"计成了 30，这个虚高的数字会严重干扰下游的晨报判断。

改进后，我给它加了三级去重规则：先按标题归一化，把同一公告的各个转载版本合并；再按核心主体 + 核心动作进行聚类，比如"XX公司发布减持预披露"是一个事件，不管它被转载多少遍都只算一次；最后，只保留信息量最全的原文来源，其余作为"相关报道"挂在事件下面做参考。这样统计出来的事件数才真正反映信息面的实际变化，而不是媒体刷屏的强度。

7.7 Prompt 和 Skill 也要跟着市场和公告变：定期 Review 技能包

跑了一个月之后，我发现市场晨报员对某些话题的判断明显过时。查了一下，原因是它的分类词典和关注要点还是按三个月前的行业逻辑写的，而期间行业政策框架已经调整过一轮。

从这之后，我养成了一个习惯：每两周抽半小时，把 AI 产出的历史报告和我手动修改过的版本做一次对比，把修改点提炼成新的规则，更新到对应的 Skill 里。这套"人工修正 -> 规则沉淀 -> 技能升级"的闭环，是系统质量持续提升的真正引擎。没有这个环节，AI 团队的能力会一直停在搭建那天的水平。

跑了一个多月，我最深的体会是，这支 AI 投研团队真正省下的不是"判断"，而是"检索和整理"的时间。以前我写一份日度纪要，光是把各种渠道的信息捞齐、排重、梳逻辑，就要两三个小时；现在这部分压缩到半小时以内，多出来的时间被我用在自己真正需要想的事情上。WorkBuddy 这类工作台产品还在快速迭代，功能入口和底层模型随时会变，但"给 AI 定岗位、定 SOP、定质检节点"这套方法论是稳的。与其等一个全能 AI 出现，还不如现在就用手头的模型，配合流程把它们组织起来，先把今天晚上的复盘从你手里接过去。