这篇我们来看一个最近在 AI 工具圈和量化交易圈子里面讨论热度都不低的东西WorkBuddy。先不聊概念直接说结论——它本质上是一个面向个人工作流的 AI Agent 工作台核心玩法是把你日常反复要做的那些事拆成步骤装进 Skill技能这个容器里之后只要一句话或者一个定时任务它就能按步骤把活干完。交易复盘就是非常典型的高频重复场景每天收盘后要看行情、对交易记录、算盈亏、写总结中间还横跨行情软件、Excel、备忘录好几个工具。这次要做的交易复盘工作台就是把这些散落的步骤全部收拢到一条流水线里。具体来说复盘工作台要解决三件事第一行情数据能自动拉取并落盘第二交易记录导入后能自动算出胜率、盈亏比、月度收益这些指标第三把统计结果和行情数据按固定模板生成一份 Markdown 复盘文档。这三件事以前是三个工具轮着切用 WorkBuddy 之后可以变成一个 Skill 触发到底。这篇文章会按可复制的流程来写——先讲 WorkBuddy 的功能边界和适用场景再走一遍环境准备、安装启动、Skill 配置接着给出行情接口、批量任务和定时复盘的实现思路最后是资源占用观察和常见问题排查。如果你正打算把一个重复性工作交给 AI Agent 去自动跑这篇可以直接当参考模板。先说硬件和启动门槛。WorkBuddy 这类客户端型的 AI 工作台主要吃 CPU 和内存不需要独立显卡常规办公本就能跑重点要关注的是磁盘空间——客户端本身不大但本地缓存、会话记录和数据文件会一起增长建议预留出足够的空间。启动方式上目前主流是安装官方客户端后登录使用部分版本也提供 CLI 入口具体要以对应版本的官方文档为准。接口能力方面只要本机 Python 或 Node 环境能跑的 HTTP 请求、数据库查询通过 Skill 都能接进来后面做批量行情拉取和定时复盘都依赖这一点。1. 核心能力速览在往下走之前先把 WorkBuddy 的能力边界列清楚。下面这张表适合快速判断它适不适合你的场景。能力项说明工具定位AI Agent 工作台通过 Skill 组织自动化任务核心功能对话式任务编排、Skill 技能、自定义指令、SSH 连接、批量与定时任务硬件要求客户端以 CPU 和内存为主不需要独立显卡跑数据脚本按数据量评估支持平台以官网提供的 Windows / macOS 版本为准社区有提及旧系统环境需自行确认启动方式客户端启动为主部分版本有 CLI 入口接口能力可调用行情 API、HTTP 服务、本地脚本接口细节以实际版本为准批量任务支持用 Skill 批量处理多标的、多日期数据典型场景交易复盘、数据整理、自动报告、日常自动化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 脚本方式拉取结构化日线数据需要注册并申请 tokenAkShare 相对更轻量直接调用即可但接口稳定性取决于数据源本身。下面的示例统一用 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 配置复盘 SkillSkill 是 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.pyimport 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.pyimport tushare as ts pro ts.pro_api(你的TUSHARE_TOKEN) df pro.daily(ts_code000001.SZ, start_date20250101, end_date20250131) 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 判断成功与失败排查测试步骤预期结果失败时排查方向月度统计脚本输出每月的交易次数、盈亏、胜率字段名是否匹配工作目录是否正确行情拉取脚本返回数据行数大于 0token 权限网络连通接口调用频率复盘报告生成output/daily 下生成 MarkdownSkill 文件格式是否生效脚本路径是否错误报告格式无套话连接词每个标的分段自定义指令是否覆盖当前 Skill6. 接口 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_codesymbol, start_datestart, end_dateend) 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_codecode, start_date20250101, end_date20250131) if df is not None and not df.empty: df[code] code frames.append(df) result pd.concat(frames, ignore_indexTrue) result.to_csv(data/market/batch_202501.csv, indexFalse) 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 foutput/daily/review_{today}.md失败重试方面最稳妥的做法不是让定时任务自动反复执行而是让每次运行写一个状态日志。一个简单的做法是在脚本里记录开始和结束状态import datetime, os log_path logs/run.log os.makedirs(logs, exist_okTrue) with open(log_path, a, encodingutf-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 使用过程中最高频的问题以及对应的排查思路。问题现象可能原因排查方式解决方案安装后白屏WebView 组件缺失、缓存异常、显卡驱动问题查看日志确认是否有渲染错误重装运行库、清空本地缓存、重启客户端、升级版本缓存路径占用系统盘默认缓存目录在用户目录查看设置中的缓存路径把缓存目录迁移到数据盘重启生效登录后界面异常网络环境或服务节点不匹配检查网络连通性和服务状态根据网络环境选择对应版本或服务节点Skill 不生效文件格式不对、未启用、触发词冲突检查 Skill 文件内容和启用状态按模板重写 Skill 并重启客户端脚本无法读取 data 目录相对路径错误或工作目录不对在命令行中手动运行脚本并打印当前目录统一使用项目根目录或改为绝对路径API 返回权限错误token 无对应接口权限用 curl 或脚本直接测试 HTTP 请求到数据源平台申请对应权限生成的报告 AI 味重缺少自定义指令约束检查全局指令是否覆盖当前 Skill增加输出风格约束禁止套话连接词换账号后旧记忆丢失会话数据绑定原账号查找本地工作区和会话备份提前导出工作区数据换账号后手动导入批量任务卡住接口限流或数据量过大查看日志和网络请求耗时拆分批次、增加延时、失败后重试白屏问题值得单独展开。这类的根源大多不是 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 和脚本。建议先拿小数据量跑通再逐步加复杂度这套配置可以作为你个人自动化工作台的起点后面慢慢扩展也不迟。 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 的能力边界列清楚。下面这张表适合快速判断它适不适合你的场景。能力项说明工具定位AI Agent 工作台通过 Skill 组织自动化任务核心功能对话式任务编排、Skill 技能、自定义指令、SSH 连接、批量与定时任务硬件要求客户端以 CPU 和内存为主不需要独立显卡跑数据脚本按数据量评估支持平台以官网提供的 Windows / macOS 版本为准社区有提及旧系统环境需自行确认启动方式客户端启动为主部分版本有 CLI 入口接口能力可调用行情 API、HTTP 服务、本地脚本接口细节以实际版本为准批量任务支持用 Skill 批量处理多标的、多日期数据典型场景交易复盘、数据整理、自动报告、日常自动化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 脚本方式拉取结构化日线数据需要注册并申请 tokenAkShare 相对更轻量直接调用即可但接口稳定性取决于数据源本身。下面的示例统一用 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 配置复盘 SkillSkill 是 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.pyimport 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.pyimport tushare as ts pro ts.pro_api(你的TUSHARE_TOKEN) df pro.daily(ts_code000001.SZ, start_date20250101, end_date20250131) 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 判断成功与失败排查测试步骤预期结果失败时排查方向月度统计脚本输出每月的交易次数、盈亏、胜率字段名是否匹配工作目录是否正确行情拉取脚本返回数据行数大于 0token 权限网络连通接口调用频率复盘报告生成output/daily 下生成 MarkdownSkill 文件格式是否生效脚本路径是否错误报告格式无套话连接词每个标的分段自定义指令是否覆盖当前 Skill6. 接口 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_codesymbol, start_datestart, end_dateend) 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_codecode, start_date20250101, end_date20250131) if df is not None and not df.empty: df[code] code frames.append(df) result pd.concat(frames, ignore_indexTrue) result.to_csv(data/market/batch_202501.csv, indexFalse) 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 foutput/daily/review_{today}.md失败重试方面最稳妥的做法不是让定时任务自动反复执行而是让每次运行写一个状态日志。一个简单的做法是在脚本里记录开始和结束状态import datetime, os log_path logs/run.log os.makedirs(logs, exist_okTrue) with open(log_path, a, encodingutf-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 使用过程中最高频的问题以及对应的排查思路。问题现象可能原因排查方式解决方案安装后白屏WebView 组件缺失、缓存异常、显卡驱动问题查看日志确认是否有渲染错误重装运行库、清空本地缓存、重启客户端、升级版本缓存路径占用系统盘默认缓存目录在用户目录查看设置中的缓存路径把缓存目录迁移到数据盘重启生效登录后界面异常网络环境或服务节点不匹配检查网络连通性和服务状态根据网络环境选择对应版本或服务节点Skill 不生效文件格式不对、未启用、触发词冲突检查 Skill 文件内容和启用状态按模板重写 Skill 并重启客户端脚本无法读取 data 目录相对路径错误或工作目录不对在命令行中手动运行脚本并打印当前目录统一使用项目根目录或改为绝对路径API 返回权限错误token 无对应接口权限用 curl 或脚本直接测试 HTTP 请求到数据源平台申请对应权限生成的报告 AI 味重缺少自定义指令约束检查全局指令是否覆盖当前 Skill增加输出风格约束禁止套话连接词换账号后旧记忆丢失会话数据绑定原账号查找本地工作区和会话备份提前导出工作区数据换账号后手动导入批量任务卡住接口限流或数据量过大查看日志和网络请求耗时拆分批次、增加延时、失败后重试白屏问题值得单独展开。这类的根源大多不是 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 和脚本。建议先拿小数据量跑通再逐步加复杂度这套配置可以作为你个人自动化工作台的起点后面慢慢扩展也不迟。