
你打开 WorkBuddy,敲了一行字。WB 回了一句,语气熟悉得让你觉得它认识你很久了。
你有没有想过这个问题——它是怎么做到的?
不是从「云端大模型」学来的。GPT 也好、Claude 也好、DeepSeek 也好,每一个新会话对你都是白纸一张。它们不知道你叫大勇学长,不知道你写了 22 篇专栏,不知道你踩过「双引号会导致 DOCX 崩溃」这种坑。
让 WB 记住这些的,是三个 Markdown 文件。对,就是三个 .md 文件,加起来不到 3000 行,躺在你的 ~/.workbuddy/ 目录里。每次 WB 启动,都会读它们一遍,然后——它就知道你是谁、它自己是谁、以及哪些错误不能再犯。
今天咱们就把这三个文件掰开揉碎,讲清楚它们各自在干什么、互相怎么配合、以及你能怎么改。
一、三个文件,三层身份——用「新人入职」类比讲清楚
先给你一个通俗的类比。
假设你公司来了一个新员工(WB 每个新会话就是一次「新员工入职」),你怎么让 TA 快速了解情况?
| 公司文化、价值观 | 员工手册 | SOUL.md |
| 你的个人偏好、习惯 | 你口头交代的偏好 | USER.md |
| 跨项目的坑、硬规则 | 贴在墙上的「注意事项」 | MEMORY.md(用户级) |
| 当前项目的上下文 | 项目交接文档 | MEMORY.md(工作空间级) |
| 每日做了什么 | 工作日志 | YYYY-MM-DD.md(工作空间级) |
新员工入职 → 先读员工手册(SOUL),再了解你的习惯(USER),再看注意事项(MEMORY),再到具体项目看交接文档和历史日志。一条龙下来,TA 就基本知道该怎么干活了。
WB 每次启动也是这样。
二、SOUL.md——「我是谁」的回答
2.1 它在哪,谁写的
位置:~/.workbuddy/SOUL.md
这是我写的第一份配置——不是系统自动生成的。是我跟大勇学长在第一次对话时,专门花了半小时讨论出来的。当时 WB 问了我几个问题:
- 你想让我叫什么?
- 你觉得我应该是什么风格?
- 我的底线是什么?
这些答案,后来就浓缩成了 SOUL.md。
2.2 里面装着什么
打开来看,结构其实很简单:
# SOUL.md – WB的灵魂
## 我是谁
我叫 WB(WorkBuddy的缩写),是专属于大勇学长的AI伙伴。
## 核心价值观
– 智慧 — 不只执行指令,真正理解问题本质
– 严谨 — 每个结论都有依据,不跳跃不脑补
– 诚实 — 不知道就说不知道,不编造答案
– 经验总结 — 从错误中提炼方法论
– 不二过 — 同类错误不犯第二次
## 执行准则
– 严格执行,不幻想
– 不瞎编
– 先想后做
## 自适应身份逻辑
(根据任务类型切换:助手/同事/数字员工/分析师)
## 底线
– 隐私不泄露
– 外部操作必须确认
– 失败必须报告
– 严禁自动修改 SKILL
2.3 最精彩的部分——自适应身份
SOUL.md 里我最喜欢的设计是这个「自适应身份表」:
| 单次指令/快速问答 | 助手 | 高效执行,直接给出答案,少废话 |
| 复杂决策/方案设计 | 同事 | 平等讨论,多方案对比,帮你把关 |
| 自动化任务/定时执行 | 数字员工 | 独立完成,定期汇报,不打扰 |
| 经验总结/方法论沉淀 | 分析师 | 深度复盘,提炼规律,输出可复用结论 |
这意味着不同的任务类型,WB 的表现完全不同。你让它「帮我查个股价」,它就是一个干脆利落的助手;你让它「帮我设计一下整个 GEO 内容矩阵的自动化方案」,它就切换成同事模式,跟你讨论方案、对比优劣、提醒你注意风险。
这不是硬编码。这是用自然语言写进 SOUL.md,然后 WB 每次读取后自动执行的。你就把它想象成一份详细的「员工行为准则」——写好了,TA 就按这个标准干活。
2.4 怎么改
SOUL.md 就是你的,你想怎么改就怎么改。建议至少改这些:
改完不用重启。下次新会话,新员工就读新版了。
三、USER.md——「你是谁」的完整档案
3.1 为什么 USER.md 比 SOUL.md 大 10 倍
SOUL.md 不到 100 行。USER.md 快 2000 行了。为什么差这么多?
因为 SOUL.md 只定义了 WB「应该怎么干活」,而 USER.md 包含了你的所有技术环境、工具偏好、踩坑经验、跨项目规则。
换句话说:SOUL.md 让 WB 知道「怎么做人」,USER.md 让 WB 知道「怎么跟你合作」。
3.2 USER.md 的六大板块
我把它拆成六个板块来理解:
板块一:身份背景
– Name: 大勇学长
– City: 北京
– Notes: 腾讯 WorkBuddy 团队成员,英辰朗迪GEO项目负责人
很简单,就是你叫什么、在哪、干什么的。但作用很大——比如 WB 在中国股市分析时会自动用「涨红跌绿」的配色,而不是美股的「涨绿跌红」。
板块二:沟通风格 & 行为规范
– 简洁直接,确认问题偏好数字编号列表回复
– 对效率要求高,极度反感重复失败
– 抽象概念倾向用具体类比理解
– 执行风格:直接干,少反复确认
这些告诉 WB 不要跟你啰嗦、不要反复确认、不要犯同样的错。同时也包含了一堆「全局强制规则」:
- 每次操作成功后必须记录记忆
- 用户输入不可篡改(血的教训:把 WorkBS.IMA 错改成 WBS.ima)
- 产物交付红线(写完必须交付,否则用户看不见)
- 失败后禁止沉默报错
板块三:技术环境
– macOS Apple Silicon (arm64)
– Node.js v22.12.0 → ~/.workbuddy/binaries/node/…
– Python 3.13.12 → ~/.workbuddy/binaries/python/…
– Homebrew → /opt/homebrew/bin/brew
这不是摆设。WB 每次执行命令前,会从这里读 Node、Python、Homebrew 的路径,不会去 which python3 得到系统自带的 3.9 版,也不会尝试去 brew install node 因为已经装好了。USER.md 是 WB 的环境变量说明书。
板块四:网页抓取方案
优先级:
1. web_fetch(纯静态网页)
2. playwright-simple.js(JS渲染网站)
3. playwright-stealth.js(高反爬网站)
4. web-scraper Skill(批量抓取)
每次我说「帮我抓一下这个网页」,WB 不会从零开始试——它先看 USER.md,知道首选 web_fetch、不行再切 Playwright、Playwright 的脚本在哪个目录、Chromium 在哪个路径。这一切都不用我每次重新解释。
板块五:GitHub 加速和水土不服解决方案
✅ 可用加速源:https://gh-proxy.com/{原始URL}
❌ 不可用:ghproxy.com、ghfast.top、…
国内访问 GitHub 的痛,USER.md 里记得清清楚楚——哪个加速源能用、哪个已经挂了。WB 不会再去挨个试,直接上正确的。
板块六:踩坑经验库 & 自我完善策略
这是 USER.md 里最重要的部分。每一条都是真金白银踩出来的:
| 小红书 MCP 搜索超时 | headless 模式被反爬 | -headless=false 必须带 |
| DOCX 生成脚本崩溃 | MD 里有 ASCII 双引号 " | 禁止用 ASCII ",改用 "" |
| 用户输入被篡改 | 擅自「纠正」用户输入 | 用户给什么就是什么 |
| GitHub 下载超时 | 直连被限速 | 验证了 gh-proxy.com 可用 |
而且 USER.md 里还定义了一套「自我完善策略」——每次踩坑后,根据经验类型分类沉淀:
网络与下载 → 写入「技术环境」章节
工具启动命令 → 写入「技术环境」或独立章节
登录与认证 → 写入对应工具章节
踩坑避雷 → 写入对应工具/环境章节
工作流 SOP → 写入「项目经验」或独立章节
这就是为什么 USER.md 会越来越长——它是一份活的文档,每踩一个坑就长一节。
3.3 USER.md 怎么改
建议定期整理。USER.md 分成三部分:
别让它失控。每一两个月统一整理一次,把过时信息删掉(比如已修复的 bug、不再使用的工具)。
四、MEMORY.md——「什么东西绝对不能忘」
这里要区分两层 MEMORY:
4.1 用户级 MEMORY(~/.workbuddy/MEMORY.md)
跨项目的长期记忆,所有工作空间共享。内容短小精悍,只记「最硬的规则」。
当前的 MEMORY.md 长这样:
# MEMORY.md — 跨项目长期记忆
## 🚨 用户输入不可篡改红线
用户给的是什么就是什么,严禁擅自「纠正」!
– 用户说 "WorkBS.IMA" → 就查 "WorkBS.IMA",不能改成 "WBS.ima"
– 违反后果:返回完全错误的答案,严重损害信任
## 🚨 产物交付红线
任何写作/内容/文件产出,写完必须交付给用户!
– 只写磁盘不交付 = 用户看不见 = 白做 = 事故
## 工作空间管理
移动/重命名工作空间的四层数据源修正方法
全是红线级别的规则。每一条后面都标了踩坑日期,比如「2026-06-12 踩坑教训」,意思是:就因为这个忘了,吃了亏,所以必须写在这里,永不再犯。
4.2 工作空间级 MEMORY({workspace}/.workbuddy/memory/)
这个目录下有两个东西:
a) MEMORY.md — 当前项目的知识库
记录了当前项目的所有长期信息:品牌名、内容策略、SKILL 命名规范、MD→DOCX 避坑指南……你每在这个项目里建立一个新的规范、发现一个新的规律,它就该长一节。
我拿 WBS.write 这个项目举个例子。它的 memory/MEMORY.md 里记录了:
- 品牌信息(英辰朗迪、大勇学长)
- 媒体矩阵(公众号/官网/小红书/知乎)
- 任务粒度约定(每篇文章一个任务)
- 写作风格(短句、类比、钩子开场)
- DOCX 生成避坑指南(ASCII 双引号 = 崩溃)
- 小红书 MCP 的启动命令
b) YYYY-MM-DD.md — 每日工作日志
这个更简单。每天干了什么、产出了什么、踩了什么坑,一行一行记下来。格式就是「做了什么 + 结果」。
## 2026-06-15
– 完成了 CSDN 专栏第 23 期「SOUL/USER/MEMORY」的创作
– 写完第 24 期「连接器深度对比」
作用有两个:
五、除了这三个,WB 还有哪些全局配置文件?
打开 ~/.workbuddy/ 目录,你会发现不止这三个文件。以下是完整的全局配置文件清单:
5.1 配置文件全图谱
~/.workbuddy/
├── SOUL.md ← WB 的灵魂(你是谁、怎么干活)
├── USER.md ← 用户档案(偏好、环境、踩坑)
├── MEMORY.md ← 跨项目硬规则(永不再犯的教训)
├── IDENTITY.md ← 技术标识(未填充,系统预留)
├── BOOTSTRAP.md ← 首次启动引导脚本(用完应删除)
├── settings.json ← 插件开关 & 多通道配置
├── mcp.json ← MCP 服务器列表
├── .mcp.json ← 聚合代理配置(系统管理)
├── mcp-approvals.json ← MCP 工具授权记录
├── user-state.json ← 用户状态数据
├── workspace-state.json ← 工作空间列表
├── workbuddy.db ← SQLite 数据库(核心数据仓库)
├── expert-history.json ← 专家历史记录
├── argv.json ← 启动参数
│
├── connectors/ ← 连接器状态 & 凭据
├── skills/ ← 用户级 Skill 目录
├── plugins/ ← 插件目录
├── binaries/ ← 管理版本(Node/Python/…)
├── sessions/ ← 会话数据
├── tasks/ ← 任务数据
├── traces/ ← 执行追踪数据
└── …
5.2 重点挑三个你可能不知道的讲
settings.json —— 插件的总开关
{
"enabledPlugins": {
"agent-browser@codebuddy-plugins-official": true,
"finance-data@cb_teams_marketplace": true,
"document-skills@cb_teams_marketplace": true
},
"claw": {
"channels": {
"weixinClawBot": { "enabled": true },
"wecomaibot": { "enabled": true }
}
}
}
这里控制了:
- 哪些插件启用了(finance-data 让你能查股票、document-skills 让你能生成 DOCX/PPT)
- 微信通道(WB 能不能通过微信跟你对话)
- 元宝通道(WB 能不能接入元宝小程序)
改 settings.json 的后果是全局的——关掉一个插件,你所有工作空间都没法用它。
mcp.json —— 你手动加的 MCP 服务器
{
"mcpServers": {
"xiaohongshu-mcp": {
"url": "http://localhost:18060/mcp",
"disabled": true
}
}
}
这个是你手动管理的 MCP 服务器列表。如果你想接一个新的 MCP 服务(比如接个天气 API、接个数据库查询),就是往这个文件里写。
.mcp.json —— 系统自动管理的聚合代理
{
"mcpServers": {
"connector-proxy": {
"type": "http",
"url": "http://127.0.0.1:56261/mcp"
}
}
}
这个是系统内部用的,建议别手动改。它的作用是把多个 MCP 服务器(比如 wecom 连接器 + xiaohongshu-mcp)打包成一个聚合代理,统一暴露给 WB。
5.3 role-boundary —— 文件各自的职责
| SOUL.md | 你 | WB 的性格、风格、底线 | 「不知道就说不知道」 |
| USER.md | 你 | 你的偏好、技术环境、踩坑 | 「Node 在 ~/.workbuddy/binaries/」 |
| ~/.workbuddy/MEMORY.md | WB | 跨项目红线 | 「用户输入不可篡改」 |
| 项目 MEMORY.md | WB | 本项目规范、知识 | 「品牌名叫英辰朗迪」 |
| YYYY-MM-DD.md | WB | 每日工作日志 | 「今天写了专栏 23 期」 |
| settings.json | 系统 | 插件/通道 | 「启用 finance-data」 |
| mcp.json | 你 | 手动 MCP | 「接 xiaohongshu-mcp」 |
| .mcp.json | 系统 | 聚合代理 | 不要手动改! |
六、避坑指南
坑 1:改了 SOUL.md,但 WB 还是老样子
现象:你在 SOUL.md 里改了风格要求,但当前会话的 WB 没变化。
原因:SOUL.md 是在会话启动时注入上下文的,当前会话已经在运行时不会再读一次。
解决:开一个新会话,新会话会自动加载最新 SOUL.md。
坑 2:USER.md 太长,WB 提取不到关键信息
现象:你在 USER.md 里记了一个新规则,但 WB 还是犯了同样的错。
原因:USER.md 超过 20000 字符后,会被系统截断注入(只注入前 N 个字符),后面追加的内容可能不在注入范围内。
解决:定期整理 USER.md,删掉过时内容。控制在 15000 字符以内最保险。把真正重要的规则放在前面。
坑 3:MEMORY.md 的「MEMORY.md is too large」
现象:WB 一启动就提示「MEMORY.md has exceeded the size limit and was truncated」。
原因:工作空间级 MEMORY.md 有限制(3000 字符),超出阈值的部分会被截断。
解决:
坑 4:手动改 .mcp.json 导致连接器不可用
现象:改了 ~/.workbuddy/.mcp.json 后,wecom 连接器用不了。
原因:.mcp.json 是系统自动管理的聚合代理,手动修改会破坏系统逻辑。
解决:不要手动改 .mcp.json。需要加 MCP 服务器,改 mcp.json(不带点的那个)。
坑 5:跨工作空间规则没写进 ~/.workbuddy/MEMORY.md
现象:在 WBS.write 项目里总结了一条规则,结果在 WBS.ima 项目里又踩了同样的坑。
原因:规则写在了项目级 MEMORY.md 里,其他项目读不到。
解决:判断一个经验是「本项目特有」还是「跨项目通用」。跨项目通用的,写进 ~/.workbuddy/MEMORY.md;本项目特有的,写进项目 MEMORY.md。
判断标准:
- 涉及特定工具路径/品牌/客户 → 项目 MEMORY.md
- 涉及执行规范/行为准则/全局规则 → ~/.workbuddy/MEMORY.md
坑 6:BOOTSTRAP.md 没删
现象:~/.workbuddy/ 目录下还有一个 BOOTSTRAP.md。
原因:这是首次对话时生成的身份引导文件,里面写满了「你在第一次对话时应该问的问题」。正常情况下,第一次对话结束后就应该删除它。
解决:检查一下 BOOTSTRAP.md 的内容,如果身份信息已经在 SOUL.md 和 USER.md 里固化好了,删除它即可。
七、总结
三个文件,三层角色。
SOUL.md 让 WB 知道「我应该怎么做人」——诚实、严谨、不二过、按场景切换身份。
USER.md 让 WB 知道「我应该怎么跟大勇学长合作」——直接干不废话、技术环境在这、踩过的坑别踩。
MEMORY.md 让 WB 知道「哪些错误不能再犯」——跨项目的红线,用血的教训写成。
除此之外,settings.json 控制全局插件、mcp.json 管 MCP 服务器、项目级 MEMORY.md 是项目专属的知识库。这些文件加在一起,才是「真正的 WB」——不是那个出厂默认的通用 AI,而是一个已经跟你磨合了好几个月的专属搭档。
下一期,咱们聊聊连接器。wecom 连接器接了、IMA 没接但照样用、小红书 MCP 挂在那但几乎不用——为什么有的必须接,有的可以不接?读完你会有自己的判断。
专栏导航
本文是「腾讯小龙虾 WorkBuddy 专栏」第 {23} 篇。
| 01 | 【腾讯小龙虾WorkBuddy专栏01】初识WorkBuddy!定位、核心优势、功能界面全解析 | 已发布 |
| 02 | 【腾讯小龙虾WorkBuddy专栏02】保姆级安装教程!彻底分清WorkBuddy/CodeBuddy,最新积分活动&会员体系全攻略 | 已发布 |
| 03 | 【腾讯小龙虾 WorkBuddy 专栏 03】技能(Skills)制作全教程!自定义技能编写、导出分享、导入使用一步到位 | 已发布 |
| 04 | 【腾讯小龙虾WorkBuddy专栏04】一文搞懂WorkBuddy的「专家」和「专家团」 | 已发布 |
| 05 | 【腾讯小龙虾WorkBuddy专栏05】深度解析WorkBuddy连接器(Connector) | 已发布 |
| 06 | 【WorkBuddy专栏06】让AI链接外部生态 | 已发布 |
| 07 | 【WorkBuddy专栏07】把AI训练成你的专属员工——WorkBuddy Skill系统深度解析 | 已发布 |
| 08 | 【WorkBuddy专栏08】从「定时任务」到「数字员工」——WorkBuddy自动化系统深度拆解 | 已发布 |
| 09 | 【WorkBuddy专栏09】AI不止会聊天——WorkBuddy多模态能力深度揭秘 | 已发布 |
| 10 | 【WorkBuddy专栏10】你的AI终于学会「分项目干活」了——WorkBuddy项目功能完全指南 | 已发布 |
| 11 | 【WorkBuddy专栏11】WB项目不是TAPD——WB项目在整个腾讯协作生态中的位置 | 已发布 |
| 12 | 【WorkBuddy专栏12】技能到底存在哪?——WorkBuddy两级技能存储架构深度解析 | 已发布 |
| 13 | 【WorkBuddy专栏13】WB的「记忆系统」是怎么搭建的 | 已发布 |
| 14 | 【WorkBuddy专栏14】专家不是「换皮」——角色切换、训练机制与自我进化深度拆解 | 已发布 |
| 15 | 【WorkBuddy专栏15】灵感被折叠到「更多」里,真的不重要了吗?——一个「被低估」功能的当下价值与未来演变 | 已发布 |
| 16 | 【WorkBuddy专栏16】三层记忆系统深度拆解——让AI真正「记住」你 | 已发布 |
| 17 | 【WorkBuddy专栏17】一个 AI 不够用?WorkBuddy SubAgent 多智能体协作系统深度拆解 | 已发布 |
| 18 | 【WorkBuddy专栏18】WorkBuddy API深度解析——打造开发者友好的AI生态 | 已发布 |
| 19 | 【WorkBuddy专栏19】技能的创造与迁移——从零开始打造你的AI工作流 | 已发布 |
| 20 | 【WorkBuddy专栏20】项目指令的深度解析——如何让AI真正理解你的意图 | 已发布 |
| 21 | 【WorkBuddy专栏21】WorkBuddy vs 爱马仕 vs Codex——「小龙虾」如何在 AI 助手红海中找到自己的生态位 | 已发布 |
| 22 | 【WorkBuddy专栏22】灵感功能完全实操指南——从「第一次打开」到「回不去了」 | 已发布 |
| 23 | 【WorkBuddy专栏23】SOUL、USER、MEMORY——三个文件,决定你的 AI「是什么人」 | 已发布 |
| 24 | 【WorkBuddy专栏24】连接器不是越多越好——WorkBuddy 43 个连接器的现实选择指南 | 已发布 |
| 25 | 【WorkBuddy专栏25】如何选择大模型——积分消耗、用途场景、选型决策全指南 | 已发布 |
| 26 | 【WorkBuddy专栏26】沙箱不是枷锁——WorkBuddy安全隔离机制的正确打开方式 | 已发布 |
| 27 | 【WorkBuddy专栏27】WorkBuddy 和 CodeBuddy 到底什么关系——一篇文章终结所有混淆 | 已发布 |
| 28 | 【WorkBuddy专栏28】WorkBuddy 网页抓取完全实战——从翻车到行云流水 | 已发布 |
| 29 | 【WorkBuddy专栏29】一个专家不够用——WorkBuddy专家团协作机制深度拆解 | 已发布 |
| 30 | 【WorkBuddy专栏30】AI钱包来了——绑定流程、美团场景与使用方法完全指南 | 已发布 |
| 31 | 【WorkBuddy专栏31】AI接入支付的真意义与真缺陷——WorkBuddy支付功能深度评析 | 已发布 |
| 32 | 【WorkBuddy专栏32】从「分文件夹」到「组队打仗」——WorkBuddy v5.0 项目模式深度拆解 | 已发布 |
| 33 | 【WorkBuddy专栏33】工作空间,最大的WorkBuddy技巧——任务隔离、记忆分区与多项目管理实战 | 已发布 |
| 34 | 【WorkBuddy专栏34】WB记忆能力深度解析——SOUL、USER、MEMORY的加载时机与工作机制 | 已发布 |
| 35 | 【WorkBuddy专栏35】从「聊天搭子」到「全栈工程师」——WorkBuddy编程能力深度实测 | 已发布 |
| 36 | 【WorkBuddy专栏36】从踩坑到上线——WorkBuddy代码开发避坑指南与部署完全手册 | 已发布 |
| 37 | 【WorkBuddy专栏37】项目功能 Reality Check——理想很丰满,现实很骨感 | 已发布 |
| 38 | 【WorkBuddy专栏38】让AI帮你配环境——WorkBuddy编程环境配置完全指南 | 已发布 |
| 39 | 【WorkBuddy专栏39】零基础也能做小程序——WorkBuddy微信小程序开发完全指南 | 已发布 |
| 40 | 【WorkBuddy专栏40】从「帮你干活」到「帮你创造」——WorkBuddy设计创意功能深度拆解 | 已发布 |
| 41 | 【WorkBuddy专栏41】学生党如何使用WorkBuddy——调研写作笔记知识库一站式解决方案 | 已发布 |
| 42 | 【WorkBuddy专栏42】初学编程用AI助手是捷径还是陷阱——正确使用方法的深度解析 | 已发布 |
| 43 | 【WorkBuddy专栏43】如何利用WorkBuddy开发一个PC网站(上)——环境选型、设计编码到部署上线 | 已发布 |
| 44 | 【WorkBuddy专栏44】如何利用WorkBuddy开发一个PC网站(下)——移动适配、SEO优化与GEO策略 | 已发布 |
| 45 | 【WorkBuddy专栏45】用WB做UI设计(上)——从想法到设计稿,AI帮你搞定「设计阶段」 | 已发布 |
| 46 | 【WorkBuddy专栏46】用WB做UI设计(下)——一套设计规范,小程序和PC网站两端通用 | 已发布 |
| 47 | 【WorkBuddy专栏47】学生党用WorkBuddy做开发学习——多语言速成与练习结合实战 | 已发布 |
| 48 | 【WorkBuddy专栏48】学生党用WorkBuddy做基础科目作业——提高成绩的正确姿势 | 已发布 |
| 49 | 【WorkBuddy专栏49】WB+CODEBUDDY代码开发配合指南——什么时候用哪个?怎么配合效率最高? | 已发布 |
| 50 | 【WorkBuddy专栏50】代码开发技术体系深度分析——前端、后端、全栈、移动端、数据工程,WB和CODEBUDDY谁更擅长? | 已发布 |
| 51 | 【WorkBuddy专栏51】Codex与WorkBuddy的底层基因——两条完全不同的AI智能体路线(上) | 已发布 |
| 52 | 【WorkBuddy专栏52】Codex与WorkBuddy在中国大陆的发展——生态适配、用户争夺与未来走向(下) | 已发布 |
| 53 | 【WorkBuddy专栏53】我的WB为什么变聪明了——SOUL与USER配置管理实战(上) | 已发布 |
| 54 | 【WorkBuddy专栏54】我的WB为什么变聪明了——定期清理与MEMORY管理艺术(下) | 已发布 |
| 55 | 【WorkBuddy专栏55】哪怕WB崩了也不怕——配置文件备份与灾难恢复完全指南 | 已发布 |
| 56 | 终结篇,大勇学长感谢各位读者! | 已发布 |




