WorkBuddy交易复盘工作台：AI Agent Skill自动化实战

这篇我们来看一个最近在 AI 工具圈和量化交易圈子里面讨论热度都不低的东西：WorkBuddy。先不聊概念，直接说结论——它本质上是一个面向个人工作流的 AI Agent 工作台，核心玩法是把你日常反复要做的那些事，拆成步骤，装进 Skill（技能）这个容器里，之后只要一句话或者一个定时任务，它就能按步骤把活干完。交易复盘就是非常典型的高频重复场景：每天收盘后要看行情、对交易记录、算盈亏、写总结，中间还横跨行情软件、Excel、备忘录好几个工具。这次要做的交易复盘工作台，就是把这些散落的步骤全部收拢到一条流水线里。

具体来说，复盘工作台要解决三件事：第一，行情数据能自动拉取并落盘；第二，交易记录导入后能自动算出胜率、盈亏比、月度收益这些指标；第三，把统计结果和行情数据按固定模板生成一份 Markdown 复盘文档。这三件事以前是三个工具轮着切，用 WorkBuddy 之后可以变成一个 Skill 触发到底。这篇文章会按可复制的流程来写——先讲 WorkBuddy 的功能边界和适用场景，再走一遍环境准备、安装启动、Skill 配置，接着给出行情接口、批量任务和定时复盘的实现思路，最后是资源占用观察和常见问题排查。如果你正打算把一个重复性工作交给 AI Agent 去自动跑，这篇可以直接当参考模板。

先说硬件和启动门槛。WorkBuddy 这类客户端型的 AI 工作台，主要吃 CPU 和内存，不需要独立显卡，常规办公本就能跑；重点要关注的是磁盘空间——客户端本身不大，但本地缓存、会话记录和数据文件会一起增长，建议预留出足够的空间。启动方式上，目前主流是安装官方客户端后登录使用，部分版本也提供 CLI 入口，具体要以对应版本的官方文档为准。接口能力方面，只要本机 Python 或 Node 环境能跑的 HTTP 请求、数据库查询，通过 Skill 都能接进来，后面做批量行情拉取和定时复盘都依赖这一点。

1. 核心能力速览

在往下走之前，先把 WorkBuddy 的能力边界列清楚。下面这张表适合快速判断它适不适合你的场景。

1.1 WorkBuddy 能装下什么

WorkBuddy 和传统聊天式 AI 的差别在于“编排”这两个字。聊天式 AI 的逻辑是你问一句它答一句，而工作台模式是你把一个流程拆成若干步骤，每个步骤可以是读文件、执行脚本、调接口、生成文本，然后把这些步骤固定成一个 Skill。之后你只需要给一个触发词，比如“复盘”，它就会把整条流水线跑一遍。

从公开资料和社区讨论来看，WorkBuddy 经常和 Skill、自定义指令、SSH 连接器这几个词一起出现，说明它的设计重点不是单轮对话能力，而是把外界的数据源、本地脚本和 AI 的文本生成能力绑到一起。这正好契合交易复盘这种“数据 + 计算 + 写作”三位一体的任务形态。

1.2 复盘工作台的能力清单

用 WorkBuddy 搭出来的交易复盘工作台，最终应该具备以下能力：

• 自动读取指定目录下的交易记录 CSV，不手工打开 Excel。
• 按日、周、月维度统计交易次数、胜率、总盈亏、平均盈亏比。
• 调用行情数据接口，拉取大盘指数和持仓标的的区间涨跌。
• 把统计结果和行情数据合并，按固定模板生成复盘 Markdown。
• 通过定时触发，让每天收盘后的复盘自动完成。
• 批量拉取多只标的的行情，降低重复操作。

这六条是后面所有测试和配置的目标。能做到前三条，工作台已经比手工 Excel 高效；做到五条以上，基本就是一套个人量化工作流雏形了。

2. 适用场景与使用边界

2.1 适合谁来用

最合适的用户有两类。第一类是每天要做复盘但坚持不下来的人，问题往往不是不想复盘，而是流程太长——打开行情软件、导出交易记录、打开 Excel 拉透视表、写结论，一套下来半小时起步。把流程交给 WorkBuddy 后，耗时主要在“确认结果”和“补充判断”上。第二类是有一定脚本基础，但不想维护一套完整 Web 应用的开发者。你不需要写前端、不需要部署服务，只要把 Python 脚本放到项目目录里，用 Skill 串起来就能运行。

这套方案也适合需要周期性输出数据报告的人，比如每周整理板块涨跌、月度汇总交割单，本质上都是“拉数据 + 算指标 + 写总结”的循环，和交易复盘没有区别。

2.2 不适合什么场景

需要明确边界：WorkBuddy 适合做复盘，不适合做实盘自动化交易。高频行情采集、逐笔 Tick 数据、毫秒级下单这类场景，无论在稳定性还是延迟上都不属于一个 AI Agent 工作台该承担的工作。对大几千只股票做每日全量计算也不是它擅长的方向，建议把数据清洗和计算放到专门的脚本，只把少量结果交给工作台汇总。

此外，如果你的交易数据完全存储在封闭的券商系统里，且没有导出接口，那 WorkBuddy 能帮到的就有限了——它只能处理你能拿到手的数据文件。

2.3 数据与合规边界

这一点必须单独说。行情数据接口有明确的使用协议，个人使用和商用调用量限制完全不同，批量拉取前要确认数据源授权范围。自己做交易复盘的交易记录属于个人资产，但如果你拿的是别人的交割单、他人的持仓数据，或者涉及机构内部交易信息，必须先做脱敏和授权确认。任何情况下都不要把复盘工作台接进自动下单链路，复盘结论也不等于投资建议。涉及人脸、声音、肖像、版权素材的规则同样适用于行情数据和交易数据：来源要合法，用途要可控。

3. 环境准备与前置条件

3.1 系统与磁盘准备

WorkBuddy 客户端目前以 Windows 10/11 和 macOS 为主。如果你的系统比较老，比如 Windows 7，安装前建议先确认官方安装包是否仍然支持，社区里有人提到过旧系统环境，稳妥的做法是去官网看系统要求，不要盲目下载。

磁盘方面，工作目录建议放在非系统盘。原因是 WorkBuddy 会在本地保留会话记录、Skill 文件、日志和缓存，长期使用后体积会涨到不可忽视的程度。一块 50GB 以上的空闲空间足够覆盖客户端本身、缓存和数据文件。如果后续还要存行情历史数据，再单独评估扩展。

另外，工作台目录结构要先规划好。复盘工作台至少需要四个目录：数据目录、Skill 目录、脚本目录、输出目录。

workbuddy-trade-review/ ├── data/ │ ├── trades.csv │ └── market/ ├── skills/ │ ├── daily-review.md │ └── monthly-review.md ├── scripts/ │ ├── load_market.py │ └── calc_stats.py └── output/ ├── daily/ └── monthly/

数据目录放原始数据，脚本目录放 Python 统计脚本，Skill 目录放复盘流程定义，输出目录放最终生成的报告。这个结构不是必须，但强烈建议保持——后面排错的时候，目录是否规整直接影响定位效率。

3.2 数据源与脚本环境

复盘工作台的数据源建议用一个你能拿到 token 的行情接口，最常见的两个选择是 Tushare 和 AkShare。Tushare 适合以 Python 脚本方式拉取结构化日线数据，需要注册并申请 token；AkShare 相对更轻量，直接调用即可，但接口稳定性取决于数据源本身。下面的示例统一用 Tushare 作为参考，实际使用时替换成你有权限的接口即可。

Python 环境至少需要 3.9 以上。不论 WorkBuddy 本身是否内置脚本执行能力，你自己写统计脚本时都应该有一个独立可用的 Python 环境，这样出问题方便在命令行里直接验证。建议用 venv 创建项目虚拟环境，避免和系统 Python 互相污染。

# 创建独立虚拟环境示例，实际路径按项目调整 cd workbuddy-trade-review python -m venv .venv source .venv/bin/activate # Windows 下用 .venv\Scripts\activate pip install pandas requests

如果你的 WorkBuddy 版本能够调用本机 Python，就在 Skill 中指定这个解释器路径。

3.3 交易记录模板设计

交易记录的数据格式直接决定后续统计脚本的复杂度，这是最容易踩坑的地方。建议统一用 CSV 文件提供交割数据，字段至少包含日期、代码、方向、价格、数量、费用、盈亏。下面是一个参考模板：

date,symbol,side,price,volume,fee,pnl 2025-01-06,000001.SZ,buy,10.50,1000,5.00,0 2025-01-08,000001.SZ,sell,11.00,1000,5.00,450.00 2025-01-09,600519.SH,buy,1500.00,100,20.00,0 2025-01-10,600519.SH,sell,1480.00,100,20.00,-2040.00

字段解释：

• date：交易日期，格式统一为 YYYY-MM-DD。
• symbol：标的代码，建议格式为交易所代码，例如 000001.SZ。
• side：买卖方向，使用 buy / sell 两个值。
• price：成交价格。
• volume：成交数量。
• fee：手续费。
• pnl：本次平仓盈亏。持仓中的买入记录 pnl 填 0，卖出记录填实际盈亏。

把这个 CSV 文件放到 data 目录后，所有统计脚本都只依赖这一份结构，后续换数据源只需要做格式转换。

4. 安装部署与启动方式

4.1 客户端安装与启动

WorkBuddy 的安装流程和其他桌面客户端没有本质区别。从官网下载对应操作系统的安装包，双击安装。安装路径建议改到非系统盘，避免后续缓存和日志占用系统盘空间。启动后需要登录账号，首次登录会在本地初始化工作区和会话目录。如果你之前配置过自定义指令、Skill 或本地缓存，换账号后想要保留原来的记忆，重点要看工作区数据能否导出迁移，不要只依赖云端同步。

启动后先确认客户端能正常打开主界面，再开始配置项目。如果安装后白屏，大概率是本地 WebView 组件缺失或缓存异常，这一块在第八章单独给排查步骤。

4.2 创建项目目录

在 WorkBuddy 的本地工作区中，先按上一章的目录规范创建 workbuddy-trade-review 文件夹，并把交易记录 CSV 放进去。这个文件夹相当于整个复盘工作台的根目录，后续所有 Skill 和脚本都围绕它组织。目录创建可以直接在系统文件管理器中完成，完成后在 WorkBuddy 中确认它能够读取该目录，最简单的测试是让 WorkBuddy 列出 data 目录下的文件。

4.3 配置复盘 Skill

Skill 是 WorkBuddy 里把流程固化的载体，一般用 Markdown 或 JSON 文件描述。下面给出一个 daily-review Skill 的参考写法。不同版本的 Skill 管理入口会有差异，但文件内容的结构可以复用：

# Skill: 每日交易复盘 ## 触发条件 - 用户发送“复盘” - 每日定时任务触发 ## 执行步骤 1. 读取 data/trades.csv，调用 scripts/calc_stats.py 计算当日与前一日数据。 2. 读取 data/market/ 目录下的行情结果，汇总大盘与持仓标的表现。 3. 按固定模板输出复盘 Markdown，保存到 output/daily/。 4. 如果当日有亏损标的，额外列出亏损金额与可能原因候选。 ## 输出要求 - 不写“总的来说”“综上所述”这类过渡句。 - 先给数字，再给判断。 - 每只标的独立成段。 - 没有数据支撑的结论不要写。

这段定义的核心是“步骤固定 + 输出固定”。复盘这门手艺，最怕的就是每次格式不一样、想总结的点不一样。把格式写死在 Skill 里，AI 的输出一致性会明显提升。

4.4 自定义指令去掉 AI 味

社区里很多人反馈 AI 生成的内容一眼能认出来，原因不外乎连接词空洞、结论模糊、每段都有排比。复盘场景对文字质量要求不算高，但看起来像人写的更容易坚持读下去。可以在 WorkBuddy 的自定义指令中加入几条输出约束：

• 少用“此外”“值得注意的是”“总而言之”等过渡套话。
• 数字统一保留两位小数，不要用“大概”“左右”模糊表达。
• 每一段先给数据事实，再给判断结论。
• 避免连续三段使用相同句式开头。
• 写不出数据依据的判断直接删除。

这些指令要写进全局自定义指令，所有 Skill 都会继承。执行后如果发现仍有冗余句式，再针对性补充约束，比如“禁止排比句”“每段不超过三行”。

5. 功能测试与效果验证

配置完成后，不要一上来就指望定时任务，先用三个小测试跑通流程。每步测试都要有明确的预期结果和失败排查方向。

5.1 测试 1：交易记录月度盈亏统计

这一步的目标是验证脚本能正确读取 CSV 并输出月度统计。在 scripts 目录下准备 calc_stats.py：

import pandas as pd df = pd.read_csv("data/trades.csv") df["date"] = pd.to_datetime(df["date"]) df["month"] = df["date"].dt.to_period("M") stats = df.groupby("month").agg( 交易次数=("pnl", "count"), 总盈亏=("pnl", "sum"), 盈利笔数=("pnl", lambda x: (x > 0).sum()) ) stats["胜率"] = stats["盈利笔数"] / stats["交易次数"] print(stats.round(2))

直接命令行运行时，工作目录必须切到项目根目录，否则 data/trades.csv 的相对路径会找不到。预期输出是每个月一行统计，包含交易次数、总盈亏、盈利笔数和胜率四个字段。如果 csv 字段名不一致，先检查表头和脚本里的字段名；如果出现 missing column 错误，按 3.3 的模板字段重命名即可。

5.2 测试 2：行情数据拉取

第二步验证外部行情接口是否可用。以 Tushare 为例，先准备 load_market.py：

import tushare as ts pro = ts.pro_api("你的TUSHARE_TOKEN") df = pro.daily(ts_code="000001.SZ", start_date="20250101", end_date="20250131") print(df.head()) print("数据行数:", len(df))

如果接口返回数据行数大于 0，说明 token 和网络连接正常。如果返回权限提醒，需要到数据源平台确认你申请的 token 是否有对应接口权限。Tushare 的 daily 接口返回的是日线行情，默认不含前复权价格，复盘时做区间涨跌统计够用，但如果你需要复权价，需要用更高权限接口。

5.3 测试 3：完整复盘报告生成

前两项脚本跑通后，在 WorkBuddy 里触发“复盘”一词，让 daily-review Skill 执行完整流程。预期结果是 output/daily/ 目录下生成一个新的 Markdown 文件，文件中包含当日盈亏、持仓标的涨跌、月度累计、次日关注点四个小节。

判断成功的标准有三个：文件确实生成、数字与手工核对的 CSV 一致、格式符合 Skill 中输出要求。第三个标准最容易出问题，可以打开生成的 Markdown 检查有没有“综上所述”这类连接词，有的话回到自定义指令继续加约束。

5.4 判断成功与失败排查

6. 接口 API 与批量任务

6.1 用 Skill 封装行情接口

行情接口没必要每次都让 AI 现写请求。更好的方式是把请求封装成 Python 函数，Skill 里只负责传参数。以 Tushare 为例，封装一个批量拉取函数：

import tushare as ts import pandas as pd pro = ts.pro_api("你的TUSHARE_TOKEN") def fetch_daily(symbol: str, start: str, end: str) -> pd.DataFrame: df = pro.daily(ts_code=symbol, start_date=start, end_date=end) if df is None or df.empty: return pd.DataFrame() df = df.sort_values("trade_date") return df

之后在 Skill 中任何需要行情的地方，都可以通过脚本来调用，而不是让 AI 通过对话猜接口参数。这也是工作台模式和纯聊天工具的核心差异——数据获取路径是确定的，错误率会低很多。

6.2 批量处理多标的

复盘工作台每隔一段时间就要跑一次批量行情拉取，比如拉取持仓的 10 只股票近一个月的数据。写一个批量脚本：

import tushare as ts import pandas as pd pro = ts.pro_api("你的TUSHARE_TOKEN") codes = ["000001.SZ", "600519.SH", "300750.SZ"] frames = [] for code in codes: df = pro.daily(ts_code=code, start_date="20250101", end_date="20250131") if df is not None and not df.empty: df["code"] = code frames.append(df) result = pd.concat(frames, ignore_index=True) result.to_csv("data/market/batch_202501.csv", index=False) print(result.head())

批量任务有三个建议：第一，每次循环之间加一到两秒延时，避免触发接口频率限制；第二，把成功和失败的代码分别记日志；第三，失败的任务不要立即重试，在批次跑完后统一重试。批量脚本跑完后再让 WorkBuddy 读取合并数据做总结，不要让 AI 逐只拼接。

6.3 定时任务与失败重试

定时复盘可以通过 WorkBuddy 的定时触发功能实现，也可以通过系统计划任务调用脚本。如果你使用的版本没有内置定时器，可以用系统计划任务调度一个轮询脚本：

import time import datetime import subprocess while True: now = datetime.datetime.now() if now.hour == 17 and now.minute == 30: # 示例命令，实际以你的 WorkBuddy 可执行文件和 Skill 名称为准 subprocess.run(["workbuddy", "--run-skill", "daily-review"]) time.sleep(60) time.sleep(30)

这个脚本展示的是定时调度思路，实际运行时需要把命令行改成你本地环境中真实的调用方式，比如通过 Python 脚本直接执行统计和报告生成，或者调用客户端提供的 CLI。定时任务建议固定输出文件名加日期后缀，避免覆盖历史复盘结果：

import datetime today = datetime.date.today().isoformat() output_path = f"output/daily/review_{today}.md"

失败重试方面，最稳妥的做法不是让定时任务自动反复执行，而是让每次运行写一个状态日志。一个简单的做法是在脚本里记录开始和结束状态：

import datetime, os log_path = "logs/run.log" os.makedirs("logs", exist_ok=True) with open(log_path, "a", encoding="utf-8") as f: f.write(f"{datetime.datetime.now()} 开始复盘任务\n")

手动查看日志时，如果发现任务开始但没有结束标记，说明执行过程中中断了。这时候再去排查具体脚本或接口问题。

7. 资源占用与性能观察

7.1 观察 CPU 与内存

WorkBuddy 客户端本身是 Electron 或者类似桌面框架的话，内存占用会明显高于传统工具，这是正常现象。你更应该关注的是观察窗口里哪个进程在吃资源：

• WorkBuddy 主进程：负责界面、会话、Skill 编排，长时间运行内存会缓慢增长。
• Python 脚本进程：执行 Pandas 统计和行情拉取时 CPU 会短暂拉高，数据量大时内存占用也会上升。
• 云同步进程：如果开启了会话同步，上传大文件时网络会波动。

日常使用时，如果 16GB 内存的机器同时开着浏览器、行情软件和 WorkBuddy，建议关掉不用的标签页。内存吃紧时最容易出现的问题不是崩溃，而是界面卡顿和 Skill 执行变慢。

7.2 缓存目录管理与迁移

社区里关于 WorkBuddy 讨论比较多的问题是缓存目录占空间。默认情况下，会话记录、图片预览、临时文件都会写在系统盘的用户目录下。时间一长，系统盘空间可能被吃掉几个 G 到十几个 G。

处理思路有三个。第一，在 WorkBuddy 设置页面找“缓存位置”或“存储”相关选项，把缓存目录改到数据盘。第二，如果设置里没有入口，查看配置文件里是否有 cache_dir 或类似字段，手动修改后重启客户端。第三，已经产生的历史缓存可以手动清理，但要注意先确认不会影响当前会话和历史记录。无论哪种方式，改完路径后都要重启客户端，否则不会生效。

7.3 批量任务对资源的影响

批量任务和普通对话的资源占用差异很大。单次对话最多是文本计算，批量任务会启动 Python 进程、读取 CSV、请求外部接口，某些耗时步骤会持续几分钟或更久。

对性能影响最明显的三个指标是数据量、循环次数和输出长度。处理几千行交易记录时，Pandas 统计几乎瞬间完成；批量拉取几十个标的的日线数据时，耗时主要在接口请求；生成复盘报告时，输出长度会影响 LLM 推理时间。

建议批量任务分小批跑。比如 50 个标的的行情拉取，可以拆成 5 批，每批 10 个，中间加延时。这样即使某一批失败，重试成本也更低。同时，不要在批量任务执行过程中继续往 WorkBuddy 发送新的复杂指令，否则界面会出现明显的响应延迟。

8. 常见问题与排查方法

下面这张表合并了 WorkBuddy 使用过程中最高频的问题，以及对应的排查思路。

白屏问题值得单独展开。这类的根源大多不是 WorkBuddy 本身坏了，而是它依赖的 WebView 运行时在你的系统上没有正常加载。按照从简到繁的顺序依次试：先重启客户端，再清理缓存文件，然后重装系统运行库，最后检查显卡驱动更新。如果都不行，把本地日志保存下来再联系官方支持，不要反复重装制造更多变数。

另一个高频问题是行情接口权限。很多人注册了 Tushare 之后发现某些接口返回“抱歉，您没有访问该接口的权限”，这不是代码写错，而是 token 没有对应接口的积分权限。遇到这种情况，优先在数据源平台查看当前 token 允许的接口范围，而不是反复改代码。

Skill 不生效的排查要从文件本身开始。先检查 Skill 文件名和后缀是否符合版本要求，再确认是否放在正确的 Skill 目录下，最后看是否需要“保存并启用”这一步操作。改完 Skill 文件后，客户端通常要求重启或重新加载，不要改了文件就直接测试而不重启。

9. 最佳实践与使用建议

9.1 数据与目录规划

复盘工作台运行一段时间后，数据文件会越来越多。强烈建议把原始数据、中间结果和最终输出放在不同目录，并用日期命名文件：

• data/market/ 只放行情原始数据，文件名为 batch_YYYYMM.csv。
• output/daily/ 只放最终复盘报告，文件名为 review_YYYY-MM-DD.md。
• logs/ 放每次任务的运行日志，用来排查定时任务失败。

不要让脚本把中间文件乱丢。工作台的价值在于流程固定，如果每次跑完目录都变样，等于把手工混乱换成了自动化混乱。

9.2 流程验证与版本管理

第一次接入真实数据时，不要直接跑全量。先拿一个月的交易记录测试，确认统计口径正确后再扩展。每次修改 Skill 或脚本后，保留一个最小可运行配置，出了问题能快速回退。数据脚本建议放到 Git 仓库里，改动可以追溯；交易记录 CSV 如果涉及隐私就不要进仓库，用一个脱敏样例文件做测试。

二次运行的速度通常比第一次快很多，因为 Script 脚本已经写好、接口数据已落盘，WorkBuddy 只需要读取本地文件并生成总结。这也说明一个原则：能让脚本做的事决不让 AI 在对话中临时生成，对话只负责编排和总结。

9.3 安全、隐私与合规提醒

最后是最重要的部分。使用 WorkBuddy 做交易复盘，必须守住几条边界：

• 行情数据来自公开接口时，遵守该数据源的使用协议，不超量、不商用，除非你确认授权允许。
• 交易记录属于个人财务数据，存本地不要随意上传到云端，尤其是涉及他人信息的场景。
• 复盘工作台只做分析和总结，不接实盘下单、不接自动交易，避免策略缺陷直接造成资金损失。
• 如果以后拿同一套 WorkBuddy 技能做其他方向的内容生成，涉及版权素材、他人肖像时同样要先确认授权。这一条对任何 AI Agent 工具都适用。

不要因为工具能自动跑就放松流程审核。AI 生成的投资相关结论必须先人工复核，尤其是涉及具体操作建议的内容。

10. 总结与下一步

这次搭建的核心收获是：把“复盘”这件事从每日手工劳动变成了一条 Skill 流水线。行情拉取、交易统计、报告生成三个环节分别由脚本承担，WorkBuddy 承担编排和文本总结，它确实解决了复盘坚持不下去的根源问题——流程太长、反馈太慢。

如果你也要搭自己的工作台，最先验证的一定是那两个脚本：CSV 统计脚本和行情拉取脚本。这两个基础能力只要有任何偏差，后续所有复盘报告都会错得一致而隐蔽。最容易踩的坑集中在三处：交易记录字段不统一、行情接口 token 权限不够、缓存目录在系统盘越涨越大。这三件事如果在第一次配置时就处理掉，能省掉后面大量返工。

下一步可以考虑的方向包括：把多个账户的成交记录合并统计，按月自动归档复盘报告，接入更多行情数据源做行业板块对比，或者把每日复盘结果同步到内部协作群。WorkBuddy 的价值不止在交易复盘，任何“数据 + 计算 + 文本输出”的重复流程都能套用这套方法论，只需要换一组 Skill 和脚本。建议先拿小数据量跑通，再逐步加复杂度，这套配置可以作为你个人自动化工作台的起点，后面慢慢扩展也不迟。