Wes Roth 的 Grokbot 研究台：分工、协作与投资演示的证据边界

一、主讲人与议题背景

这期节目由 Wes Roth 主持并上传，标题为“my bots just BROKE Wall St...”，时长 1,658 秒，约二十八分钟。转录呈现的是 Wes 对自己所搭建系统的讲解和演示，没有可核实的嘉宾身份或访谈背景。

Wes 将 Grokbot 比作在云端电脑上工作的远程员工，并称即使用户关闭个人电脑和手机，机器人仍能继续执行任务。他用一套模拟投资研究台串起创建机器人、分配专长、连接应用、组织协作和教授浏览器技能等操作。节目由此呈现了他的产品使用方式与搭建过程，没有对实际基金的经营成绩展开调查。

Wes 同时披露，视频由 SpaceX 赞助，自己不因订阅或下载获得佣金。这一推广背景需要与功能展示一并理解。赞助事实本身不能否定演示，但个人推荐、展示出的操作和经过验证的效果，仍需分别判断。

二、本期主要内容

这套研究台按信息来源和工作类型分配岗位。Hardcode 负责搭建研究仪表盘，也处理脚本、网页应用、自动化和代码仓库工作。Wes 会询问机器人负责什么，以及需要哪些资源才能完成工作；Hardcode 提出的需求是一个代码仓库。岗位由此有了更具体的内容：除了职责，还要明确所需材料和交付环境。

研究信息由几个岗位分别收集。Clerk 监控关注公司的 SEC 文件，记录并标记内部人出售股票、大额交易等事项。Mapper 跟踪与 AI 相关的供应链环节，包括芯片、晶圆制造设备、内存、数据中心、电力和云。Calendar 关注财报、美联储会议和通胀报告；Analyst 负责财报分析，并综合其他岗位提供的信息。Keeper 保存持仓记录，衡量持仓相对目标权重的偏离，再拟出交由 Wes 签字确认的计划。Taxman 则被安排处理税务及税收优惠账户事项。这些是演示中的职责安排，岗位说明本身并不能证明税务判断的准确性。

交易环节由 Paper Trader 承接。Wes 明确说明，账户用于模拟交易，不涉及真实资金，演示也不构成买卖证券的建议。他还介绍了回测以及与标普五百进行比较的安排。投资研究和交易为这期教程提供了应用场景；岗位名称、回测安排和交易界面的出现，本身不足以证明系统已经具备实际投资能力。

为让各岗位交换信息，Wes 把 Clerk、Mapper、Calendar、Bear、Analyst 和 Paper Trader 加入同一群聊，讨论下一笔交易。按他的解说，文件信息、供应链分析、即将到来的财报、反对意见和综合判断共同形成了从 Nvidia 转出的建议。转入标的在转录中写作“apply the material”，名称存在歧义，无法据此确定是哪只证券。这段演示呈现了建议形成的协作过程，没有证明建议已经执行或带来收益。

定时任务让信息收集能够持续进行。Wes 示范的例行任务是在开盘前一小时和收盘前一小时查看股票相关 Reddit 社区，发现涉及关注股票的重大新闻时通知他。另一个信息入口是 X：他介绍了通过付费 API 调取帖子、查看 Google 相关情绪的做法，也可以安排重复检查。这些功能连接了收集、筛选和提醒，但节目没有说明情绪样本的选择或计算方法，信息汇总的展示尚不能证明市场预测能力。

三、核心观点：推理、例子与边界

Wes 的组织思路是先拆分工作，再连接各个环节。他建议从每周重复的一项任务开始，确认能够运行后，再逐步加入后续任务，接成完整流程。这一主张针对的是自动化中的交接问题：即使收集已经自动完成，只要整理和转交仍需人工，使用者就仍要持续衔接各个环节。不过，节目没有比较单个机器人与整个团队的总成本，也没有展示流程扩展后的返工量。因此，连接完整工作流能带来更大价值，是他的实施判断，尚不是经过测量的普遍收益规律。

Chief of Staff 是这套分工的协调入口。Wes 主要通过它分派工作、过滤消息，无须逐一询问所有机器人。据他介绍，它可以创建和管理机器人，为其改名、设置头像，但演示时还不能删除机器人。集中协调减少了日常沟通入口，却没有转移最终责任。Wes 明确表示，决定仍由自己作出。他所称的“完全自主”，因而需要放在研究和日常执行的范围内理解，不能据此认定系统拥有最终投资决定权。

Bear 的职责让这套分工多了一层质疑机制。Wes 展示了它如何挑战 Mapper，也展示了它对自身悲观判断失效条件的说明。这比增加一份看空意见更进一步：反对者也要说明，什么证据足以改变自己的判断，才能在新材料出现时修正论点。但节目没有证明各机器人采用了彼此独立的来源、模型或验证方法。多个角色相互回应能够组织异议，尚不足以证明共同偏误已经消除。

文件交付中的偏差暴露了另一类问题。Wes 原以为团队会把表格上传至 Google Sheets，却发现部分机器人只保留了逗号分隔文件。他将原因归于自己没有说清要求，随后让 Chief of Staff 确认 Drive 访问、安排上传并改善可读性。机器人已经产出了文件，文件却没有按预期进入协作环境。这说明验收还需要检查下游能否找到、读取和使用结果，仅有“完成”的回复并不足够。

岗位分工也不能直接等同于权限隔离。按 Wes 的说明，各机器人在同一台机器上拥有各自的工作区；Gmail、Calendar、Drive 等应用一旦连接，访问能力便会在机器人之间共享。独立工作区与应用访问范围是两回事。角色名称和职责说明能够约定谁来做什么，却不能据此认定系统已经限制了谁可以访问哪些应用。

对效果的判断同样需要区分证据。Wes 提到机器人自夸跑赢标普五百，但节目没有提供可审计的收益历史，无法据此确认投资超额表现。对于跨网站的数据采集，他估计手工操作需要二十至三十分钟，并称自动化版本运行得毫无差错；节目却没有给出对照计时或错误率研究。这些陈述可以说明他的使用感受，但投资收益、节省时间与运行准确性仍需各自验证，不能相互充当证据。

Wes 还提出，把交易、分析和当时的想法持续写入 Drive，日后再比较哪些推理伴随着盈利或亏损。这样的记录有助于保留作出判断时的依据，供后续复盘使用。不过，节目展示的是记录与分析的设想，没有呈现已经完成的长期研究。即使未来发现某类推理与盈利同时出现，也仍需辨别那是偶然结果，还是可以重复的方法优势。

四、学习与应用

将 Wes 的方法用于实际工作，可以先选定一项输入固定、接收者明确的重复任务，写清来源、筛选范围、输出字段、存储位置和完成条件。先让一个机器人完成一轮，再检查接收者能否直接使用结果；达到要求后，继续连接整理、分析和提醒。这延续了他从一项每周任务逐步扩展的思路，也让每次新增交接时都有明确的检查对象。

分工时，Wes 向 Hardcode 提问的方式值得借鉴：除了询问职责，还要问清完成工作需要哪些资料、工具和交付环境。相互依赖的岗位需要共享材料，而 Google Sheets 的交付偏差提醒使用者，文件存在并不等于已经交付，格式正确也不等于接收者有权限读取。协调者的汇报应包含具体链接、存放位置和仍待解决的问题。节目还说明，应用连接后的访问能力会跨机器人共享，因此涉及邮箱或业务资料时，需要另行确认可接受的访问范围，不能用岗位说明替代权限控制。

分析任务可以采用 Bear 展示的要求：在结论和支持理由之外，写出哪些新事实会改变判断。这样，后续收集到新材料时，就有条件检查原有结论是否仍然成立。但反方角色仍需核对来源；如果几个机器人反复引用同一份材料，增加讨论轮次也不会增加独立证据。

定时任务则需要同时规定检查频率和提醒门槛。开盘前一小时、收盘前一小时扫描，展示了如何围绕信息使用的时间安排任务。Wes 也说，等待预期发布时，他有时会每两三分钟检查一次。这是他个人更密集的用法，不宜直接作为所有任务的默认频率。他将手机通知限制在 Chief of Staff 和通用 Grokbot，也提供了一种集中接收消息的安排。采用这种方式后，仍需抽查漏报的重要事项和没有必要的提醒，才能判断筛选是否有效。

日志应保留作出判断时的依据、异议和最终决定，结果出现后再追加记录，以便复盘时还原当时掌握的信息。Wes 提出的定期检查数据和备份，也可以用于确认材料是否确实存入 Drive、备份是否可用。分析这些记录时，需要分别判断结果好坏与当时推理是否充分。日志能够提供复盘材料，却不能自行保证策略改善；节目也尚未展示这类长期分析已经取得的结果。

对于重复的浏览器操作，Wes 展示了另一条路径：录制操作，由视觉能力解读录像，再生成 Markdown 技能。他用扫雷演示教学过程，并表示文字技能可以在代理之间转移。实际采用时，可以先限定采集任务的范围，检查生成的文字是否准确，再用新一轮输入试运行并核对仪表盘结果。扫雷演示说明了教学功能如何使用，业务流程仍需单独验证；技能以文本保存、能够转移，也不等于在另一个代理上必然兼容。

Wes 说，自己常用一项技能从多个网站收集信息，填入内部 KPI 仪表盘，往往每天运行两次。他估计原先手工收集需要二十至三十分钟，并称自动化版本运行得毫无差错。由于节目没有提供比较计时或错误率研究，评估自己的工作流时仍应计入教学、检查和纠错所需的时间，不能直接套用这一估计。对于会影响资金或其他重要决定的输出，还应保留他在演示中明确坚持的安排：最终决定由人作出。

来源

• 原始节目：my bots just BROKE Wall St...