企业官网建设流程全解析

上周五我同时开着六个 WorkBuddy 会话，一个在梳理需求，一个在重构老模块，一个在整理接口文档，还有一个帮我跑竞品分析。下午四点半我打开云盘想找上午那份 Agent 生成的架构方案，翻了五分钟没找到，只看到一堆 session_xxx、output_final_v2、tmp 之类的目录。那一瞬间我意识到：工具越顺手，数据越容易失控。当天晚上我做了个决定——给每个 Agent 会话一个"家"。

这篇不是什么官方教程，就是一次真实整理过程的记录，包含我对 WorkBuddy 云盘机制的理解、目录规划方案、Skill 配置方法，以及云盘同步场景下踩过的坑。如果你和我一样，同时跑多个 Agent 会话、依赖云盘同步文件、又经常找不到上次的产出物，那这篇应该能帮你少走点弯路。

1. 先弄清 WorkBuddy 的云盘到底在替你存什么

1.1 云盘不是网盘，是会话的"记忆仓库"

很多刚接触 WorkBuddy 的人会把云盘理解成网盘，觉得它就是个放文件的地方。我用了一段时间之后发现，这个理解不太对。WorkBuddy 的云盘空间，本质上承担的是"会话记忆仓库"的角色：每次 Agent 会话产生的上下文记录、Agent 自己生成的中间文件、Skill 包、自定义指令文件，以及最后交付的产物，默认都会落在云盘划分出来的工作区里。

这意味着什么？意味着每启动一个会话，你其实是在云盘里给这个 Agent 开辟了一块"临时工地"。Agent 在里面搬砖、焊接、盖楼，所有过程数据都堆在这块工地上。问题是，这块工地的位置、命名、边界，WorkBuddy 默认并没有给你管得很好。它更像一个只管发工具、不管收拾工地的包工头。

我见过的默认状态是这样的：会话一多，云盘根目录下就会出现大量随机命名的目录，比如session_7f3a2b、workspace_tmp、code_review_final这种，谁也分不清里面是什么、是哪个任务留下的、能不能删。如果你和我一样喜欢同时开五六个会话，那不出半天，云盘就会变成一个谁都不想进去的杂物间。

1.2 会话连接数背后，藏着一个存储问题

WorkBuddy 里的"会话连接"机制也值得单独拎出来说。所谓开启会话连接，就是让一个 Agent 会话真正跑起来，占用一个本地或远程的执行通道。不少人应该碰到过"会话数达到上限"或者"连接失败"的提示，这限制一方面来自执行通道的并发能力，另一方面和云盘的读写压力也有关系——每个会话都在往自己的工作区写数据，会话越多，目录越乱，同步时的冲突概率也越高。

我最早以为这是个性能问题，后来想明白了，它其实是存储管理问题。你真正缺的未必是会话额度，而是一套让每个会话"知道自己该往哪写"的规则。WorkBuddy 允许你在会话里指定工作目录，但默认情况下，很多人都没设，Agent 就随手往默认位置丢。一次两次没什么，时间一长，云盘就成了数据坟场。

1.3 先承认一个事实：Agent 不会替你收拾房间

用过多个 Agent 工具之后，我有个很深的体会：不管模型多聪明，它默认只会对你当前会话里说得清楚的事情负责。你没告诉它"文件该放哪"，它就按自己习惯放；你没告诉它"目录结构长什么样"，它就现场即兴发挥。这不是 WorkBuddy 的锅，而是所有 Agent 工具的共性——主动权在你这儿，只要你给出明确的指令，Agent 基本都是愿意配合的。

所以，问题的本质不是"WorkBuddy 云盘不好用"，而是"我没有给会话定义清晰的工作边界"。

2. 焦虑的根源：当一个会话失去"归属感"

2.1 一天跑完六个会话后的文件夹灾难

为了让大家直观感受这个焦虑是怎么来的，我贴一张典型的混乱目录结构，这是我某一天下班前从云盘里随手抓的：

云盘工作区/ ├── session_7f3a2b/ │ ├── chat_log.jsonl │ └── generated_files/ ├── workspace_tmp/ │ ├── 需求文档_draft.md │ └── 接口方案_v3.md ├── skill_demo/ │ └── output/ │ └── 架构图.png ├── code_review_notes/ │ └── review_result.md ├── Untitled/ ├── 桌面截图.png └── 新建文档(2).md

这个结构的问题不在于乱，而在于"不可追溯"。每个目录看起来都像那么回事，但你根本想不起来workspace_tmp是哪个任务用的，session_7f3a2b里到底有没有最终版本。更麻烦的是，当你需要把成果同步给同事或者迁移到另一台设备时，你完全不知道该打包哪个目录、删掉哪个目录。

2.2 会话数据"有家不回"的三种典型表现

我把这种失控总结成三种情况，大家可以对照一下自己有没有遇到过：

第一种：Agent 把中间产物写到临时目录。比如让 Agent 拆分一个大文件，它会自动建一个temp_split或chunks目录，任务结束了目录还在，下次看到根本不知道能不能删。

第二种：会话记录和交付物混在一起。云盘里既有chat_log.jsonl（对话记录），又有final_report.md（最终成果），没有做区分。对话记录是过程资产，可能过几天就没用了；交付物是要长期保留的。混在一起，归档和管理都很麻烦。

第三种：Skill 和会话数据到处乱放。自己攒的 Skill 可能在这个会话的目录里，自定义指令放在了另一个地方，结果新开一个会话想复用，还得翻云盘找半天。

这三种情况一叠加，就是"云盘焦虑"。焦虑的本质不是"文件太多"，而是"文件之间没有归属关系"——你不知道这个文件属于哪个会话、哪个任务、哪个阶段。用一句话概括：会话没有家，文件就只能是流浪儿童。

2.3 我给"家"下的定义

为了解决这个焦虑，我给自己定了一个原则：每个 Agent 会话，都应该对应一个独立、命名清晰、结构固定的云盘目录。我把这个目录称为"会话之家"（Session Home）。

这个"家"需要满足三个条件：

1. 一看目录名就知道这个会话是干什么的；
2. 目录内部结构是固定的，每次开会话都用同一套骨架；
3. 会话的产出物、过程文件、记录文件都有明确的放置位置。

有了这三个条件，云盘焦虑基本就能消解大半，剩下的就是执行层面的事。

3. 给每个 Agent 会话一个"家"：目录规划方案

3.1 命名规范：目录门牌号怎么定

先说目录命名。这个是最简单、也最容易被忽略的一步。我的规范是三层结构：

{项目代号}/{日期}/{会话主题}

举个例子：

workbuddy-project/20250617/云盘目录整理方案 workbuddy-project/20250617/Agent并发排查

这样命名的好处是：既有项目维度（方便汇总），又有时间维度（方便回溯），还有主题维度（方便识别）。有人可能觉得"会话主题"用中文不好，怕跨平台乱码，我可以负责任地说，现在主流云盘和文件系统对 UTF-8 的支持都很好，中文命名没问题；但如果你习惯英文，也可以把主题翻译成短语，比如cloud-dir-cleanup、agent-concurrency-check。

这里有个细节：目录名不要带会话 ID。很多人习惯把 WorkBuddy 自动生成的会话 ID 拼在目录名里，比如session_20250617_7f3a2b。我建议只保留人类可读的信息，会话 ID 这种机器标识码，放内部记录文件里就够了。否则你搜文件的时候，脑子还得先把 ID 翻译成任务。

3.2 每个"家"里放什么：固定四件套

目录名定了之后，内部结构我固定用"四件套"：

{会话之家}/ ├── brief.md # 任务书：会话目标、约束条件、验收标准 ├── memory.md # 会话备忘：Agent 自行记录的关键决策和待办 ├── workspace/ # 工作区：过程文件、中间产物、临时文件 └── output/ # 交付区：最终成果、可交付文件、汇总文档

这四件套的摆放逻辑是：brief.md在最前面，是给 Agent 看的"任务合同"，明确它这个会话要干什么；memory.md是会话进行过程中的短期记忆，记录关键决策，方便下次续接；workspace是随便造的，Agent 想建什么子目录都行；output是严格管的，只能放最终要保留的东西。

为什么要把workspace和output分开？这是我踩过坑之后总结出来的。之前我把过程文件和交付物放一起，结果每周要花半小时清理云盘，不然同步速度越来越慢。分开之后，清理策略特别简单：workspace可以定期清理，output基本不动。这个动作看起来小，但每次同步和迁移时能省掉大量纠结。

3.3 配合 WorkBuddy 云盘同步的正确姿势

WorkBuddy 的云盘同步机制，默认是把整个工作区作为同步单位。也就是说，如果你不指定目录，它会把所有会话的数据全部同步上去，包括那些临时文件、垃圾缓存。这就是为什么有些人觉得云盘越来越慢。

正确姿势是：在项目层级开启同步，而不是在云盘根目录开启同步。我目前的配置是，云盘根目录下只有各个项目的顶层目录，每个项目是一个相对独立的同步单元。

云盘工作区/ ├── workbuddy-project/ # 项目 A，单独同步 ├── personal-blog/ # 项目 B，单独同步 └── _archive/ # 归档区，不同步或低频同步

这里补充一句，_archive是我自己加的归档目录。当一个项目彻底结束，我会把整个项目目录挪进去，然后从 WorkBuddy 的同步列表里移除。这样云盘同步范围永远是活跃项目，速度和稳定性都会好很多。

4. 让 Agent 自觉回"家"：WorkBuddy 配置实操

4.1 用自定义指令固定会话根目录

WorkBuddy 的自定义指令（相当于系统提示词的扩展）是约束 Agent 行为最直接的方式。很多人的自定义指令只写"你是一个专业助手""回答要详细"，这些当然有用，但少了"文件系统行为"的约束。

我在自定义指令里固定加了一段"会话工作目录协议"：

本会话的根目录是 {SESSION_HOME}。 规则： 1. 所有过程文件、临时文件、中间产物一律写入 {SESSION_HOME}/workspace/，禁止写入云盘根目录或其他无关目录； 2. 最终交付物统一放入 {SESSION_HOME}/output/，并在 brief.md 中登记文件清单； 3. 不得修改 {SESSION_HOME} 之外的任何文件，除非用户明确要求； 4. 每次完成任务后，在 memory.md 追加一条记录，说明做了什么、留下了哪些关键文件； 5. 如果发现 {SESSION_HOME} 不存在，先执行目录初始化流程再开工。

这段指令的效果是：Agent 每次动手前，会先确认自己的"家"在哪，然后所有写操作都被限定在这个范围内。实测下来，Agent 乱写文件的比例大幅下降。当然，你不一定要完全照抄，可以根据自己工作习惯调整。核心思想就一个：把文件管理规则写进指令，而不是每次都靠临时口头交代。

4.2 Skill 化：把"搬新家"变成一条指令

自定义指令负责兜底，但每次开会话手动指定{SESSION_HOME}还是有点麻烦。更顺手的做法是写一个 Skill，把"建房"过程自动化。

WorkBuddy 的 Skill 机制类似插件，格式不复杂。我写了一个叫init_session_home的 Skill，大致长这样：

name: init_session_home description: 在当前项目下初始化一个标准会话目录骨架，用于给每个 Agent 会话创建独立工作空间。 inputs: project_name: description: 项目代号，对应云盘顶层目录名 required: true session_topic: description: 会话主题，会作为目录名的一部分 required: true steps: - command: make_session_home args: base: "${WORKBUDDY_CLOUD_ROOT}/${project_name}/${date}+%Y%m%d}/${session_topic}" - command: create_files args: path: "${base}" files: - brief.md - memory.md - command: create_dirs args: path: "${base}" dirs: - workspace - output - command: write_instruction args: path: "${base}/brief.md" content: | # 会话任务书 项目代号：${project_name} 会话主题：${session_topic} 根目录：${base} 协议：遵守自定义指令中的会话工作目录协议。

有了这个 Skill，开会话时只需要说一句"初始化一个会话之家，项目名是 workbuddy-project，主题是接口优化"，它就把整个骨架建好了。

4.3 会话启动时的 30 秒检查清单

就算有 Skill 辅助，我仍然建议你在会话正式开始前，花 30 秒确认三件事。不是菜鸟才需要检查，而是因为 Agent 执行起来之后，再纠正文件路径成本就高了。

第一，确认brief.md里写的目标和验收标准是本次会话真正想做的事。很多人会跳着写，但这是给 Agent 看的"合同"，写清楚了后面它能少问你好多问题。

第二，确认output是空的或者只有上一版的成果。如果上次会话留下过旧文件，Agent 有可能把新旧混在一起，导致你拿到一个"拼接版"。

第三，确认当前默认工作目录已经被切换到新会话的根目录。WorkBuddy 支持会话级工作目录切换，你可以在界面里看到当前路径；如果路径不对，Agent 可能把文件写到上一个会话的家里去。

这三步看起来琐碎，但每次开会话之前做一遍，基本可以消除九成以上的"文件迷路"问题。

5. 云盘同步场景下的坑与兜底办法

5.1 并发会话多写时的同步冲突

使用云盘最经典的坑就是：多个会话同时写文件，同步工具报冲突。

我遇到的情况是这样的：两个会话跑在同一个项目里，一个在改brief.md，另一个在往output写文件。本来它们目录不同，理论上不该冲突，但 WorkBuddy 的某些内置操作（比如读取上下文、写入会话日志）会动公共目录下的文件。于是某天下午，我收到了三条同步冲突通知，点开一看，全是chat_log.jsonl的版本冲突。

这个问题的处理思路不是"尽量避免并发"，而是"让会话之间的交集尽可能小"。具体做法是：

• 不同会话用不同的workspace子目录，别共享临时区；
• 公共的brief.md在会话启动后尽快固化，不反复修改；
• 如果确实需要多会话协作，固定只让一个 Agent 负责写最终文件，其他 Agent 只读。

把冲突文件从"多写"变成"单写"，同步自然就稳定了。

5.2 会话记录越滚越大之后的归档策略

用 WorkBuddy 跑久了，云盘里最占空间的往往是会话日志和 Agent 产生的中间缓存。我见过一个会话跑了一整天，chat_log.jsonl涨到上百兆。这种文件如果每次全量同步，云盘客户端会非常吃力。

我目前的归档周期是每周一次，分三步：

1. 把已经结束会话的workspace目录清空，只保留output和memory.md；
2. 把超过 30 天的项目从活跃同步列表移除，挪进_archive；
3. 对特别大的会话日志，用压缩命令打成.tar.gz后归档，云盘里只留压缩包。

这套策略执行了一个多月，我的云盘同步速度明显改善，打开目录的响应也快了很多。

5.3 多设备切换时"找不到家"的修复

最后一个坑，是换设备之后 WorkBuddy 找不到之前的会话目录。这里要区分两种情况：

一是本地缓存没同步到位。常见于云盘客户端刚装好，文件还没全部拉下来，你急着重开会话去翻目录，发现是空的。我现在的习惯是，切设备之后先让云盘客户端静默同步五分钟，等几个关键目录出现output里的文件再开始干活。

二是路径结构对不上。比如你在一台设备上把项目放在D:\Cloud\workbuddy-project，在另一台设备上云盘挂载到了/Users/me/WorkBuddy/Cloud，WorkBuddy 里配置的绝对路径就失效了。解决办法是尽量用 WorkBuddy 环境变量提供的路径占位符，而不是硬编码绝对路径。我前面 Skill 示例里的${WORKBUDDY_CLOUD_ROOT}就是用来干这个的，它会自动跟随当前设备的云盘挂载位置。

我把这两类问题整理成了一张表，方便排查：

写在最后

这套"会话之家"的方案我用了五周。最大的变化不是云盘变整齐了这么简单，而是我对"Agent 产出去哪了"这件事重新建立了掌控感。以前每次让 Agent 跑一个长任务，中间我总要担心它有没有把关键文件写丢，现在不怕了——无论它折腾到什么程度，最终成果一定会出现在output里，过程记录一定在workspace里，决策备忘一定在memory.md里。

如果你也想动手整理，建议从最小的粒度开始，不用一口气把所有项目都改造完。先挑一个最常跑的项目，按我上面的命名规范和四件套结构试一周，感受一下 Agent 的文件行为变化。等自己顺手了，再慢慢铺开到其他项目。工具是越用越顺手的，但前提是，你得先给每个会话一个"家"。