企业官网建设流程全解析

说实话，我对云盘的感情一直很复杂。一方面是真离不开，WorkBuddy 的工程文件、skill 库、Agent 会话记录，我全指望云端同步在笔记本和台式机之间无缝切换；另一方面又是真焦虑，每次打开云盘客户端看到一堆莫名其妙的冲突副本，或者一个 Agent 会话跑到一半提示找不到工作目录，都恨不得把整个同步文件夹删了重来。这阵子重新整理 WorkBuddy 的使用方式，我给自己定了一个目标：给每个 Agent 会话一个家。简单说，就是让每一次会话都有独立、稳定、可追溯的目录空间，而不是继续在云盘的共享文件夹里“流浪”。这套方案跑了一段时间，会话的可追溯性、可复用性和多设备交接效率明显提升，今天把完整思路、目录设计、初始化脚本和踩坑记录拆出来，分享给同样被云盘和 Agent 会话管理折磨过的人。

1. 先说清楚焦虑从哪来：云盘、会话、WorkBuddy 是怎么凑到一起打架的

1.1 会话数据散落一地，翻半天找不到上次的上下文

用 WorkBuddy 跑 Agent，本质上是在跟“上下文”打交道的。一个会话里，给 Agent 喂的指令、它读过的文件、产出的中间结果、中途切换过的技能，这些全是会话的一部分。最开始我图省事，把所有东西都往云盘同步目录里一扔，目录结构大概是这个画风：

CloudDrive/ ├── WorkBuddy/ ├── workbuddy_backup/ ├── WorkBuddy(1)/ ├── 新建文件夹/ ├── 会话导出/ └── tmp/

你看到这个结构就知道问题在哪里：WorkBuddy 默认的会话列表把东西都收进来了，但根本分不清哪个是哪个。尤其是隔几天回去复盘某个任务的产出，光看一串随机会话 ID，根本想不起来当时在做什么。云盘的全文搜索对 Agent 会话文件又几乎等于零，最后我都是靠“打开文件看内容”来认路的。时间一长，云盘上的 Agent 会话就变成了一座无法检索的数据坟场。

这里真正的问题不是云盘本身，而是会话没有“归属感”：没有统一命名、没有固定位置、没有根据项目分门别类。云盘只是一个放大镜，把混乱放大了十倍。想要在云盘同步的前提下把 Agent 项目管好，第一步必须承认一件事——会话是需要被“安家”的，不能让它散养在同步盘里。

1.2 同步冲突：同一个 skill 文件被两台设备改来改去

第二个翻车现场更痛。WorkBuddy 的 skill 机制很实用，我给它写过一批自定义指令和技能，比如代码审查、周报生成、需求拆分。问题出在多设备协作上：白天在公司电脑上微调了一个code_review/SKILL.md，晚上回家在笔记本上又改了同一个文件，第二天云盘同步直接弹冲突，生成了一个SKILL (conflicted copy).md。

WorkBuddy 的 skill 加载器恰恰是按目录扫描的，冲突副本混进去之后，轻则反复加载同名 skill 导致指令行为异常，重则直接解析失败、这个 skill 当场废掉。我当时一度以为是 WorkBuddy 的 bug，后来才发现是自己把 skill 目录和会话目录混在一个同步计划里，又没有做细粒度的同步规则，最后等于让云盘在替我管理代码版本。

这件事给我的启发是：共享的东西（skill、Agent 定义）和会话专属的东西（上下文、产物、指令记录）必须分开放，而且共享文件的编辑必须走“单设备为主、云盘只做分发”的流程。否则，云盘同步冲突一旦发生，Agent 的执行环境就再也不可复现了。

1.3 路径漂移：昨天还能跑的会话，今天就失联

第三个坑和路径相关。WorkBuddy 的会话记录里通常会保存工作目录的绝对路径。我用 Windows 的时候，云盘目录在D:\CloudDrive\WorkBuddy；后来换了 Mac，把同一个云盘目录挂到了/Users/me/CloudDrive/WorkBuddy。结果所有旧会话在启动时指向的还是 Windows 的绝对路径，Agent 一启动就说目录不存在，连历史对话都没办法续上。

这种“路径漂移”在原生本地项目里几乎不会碰到，但只要沾了云盘，就一定会碰到：要么换系统，要么云盘客户端换了挂载点，要么把目录挪了层级。而 Agent 会话恰恰是最怕路径漂移的，因为它的上下文里包含大量文件引用，路径一变，所有引用全断。

后来我的解决思路是两层：第一，所有会话目录都坚持用相对路径描述，真正的绝对根目录通过环境变量注入；第二，坚持“一个会话一个目录”，让 Agent 在这个目录内部的活动自洽，不依赖云盘根目录的位置。这两点会在后面详细展开。

2. 给会话安家的核心思路：一个会话一个目录，目录就是会话的完整生命周期

2.1 为什么隔离粒度要选在“会话”，而不是“项目”或“Agent”

在设计目录方案之前，我纠结过一个问题：到底该按什么维度来隔离？按“项目”分，粒度太粗。一个项目下往往有十几个会话，每个会话的任务目标、输入材料和产物都不一样，全塞在一个项目目录里，还是乱。按“Agent 实例”分，粒度又太细。同一个 Agent 可以反复用在类似任务上，如果每个实例一个文件夹，会产生大量重复的 skill 拷贝和配置副本。

最后我选的是“会话”这一层。原因也很简单：在 WorkBuddy 里，Agent 执行任务的边界就是会话。一个会话有明确的起止时间、一组独立的输入输出、一份独立的上下文。把会话作为目录边界，等于把 Agent 的执行过程从零散的状态变成了可复现、可归档、可移交的工作单元。这个概念很像给每个进程分配独立的内存空间——会话目录就是 Agent 的“进程沙箱”。

每当我打开一个会话目录，里面应该能回答三个问题：这个会话在做什么、已经做到哪一步、产出了什么。如果这三个问题答案清晰，那无论云盘怎么同步、怎么跨设备，我都能快速接手。

2.2 目录结构长什么样：一个三级命名体系

基于这个理念，我把 WorkBuddy 云盘目录结构重构成了下面这样：

workbuddy-sync/ ├── _local_only/ # 仅本地，不同步（缓存、临时文件） │ ├── tmp/ │ ├── cache/ │ └── logs/ ├── skills/ # 所有会话共享的公共技能库 │ ├── code_review/ │ │ └── SKILL.md │ ├── weekly_report/ │ │ └── SKILL.md │ └── requirements_split/ │ └── SKILL.md ├── agents/ # Agent 定义与角色配置 │ └── pm-agent/ │ └── agent.yaml └── sessions/ # 会话“家”目录 ├── 20250601/ │ ├── 001-build-landing/ │ │ ├── session.yaml │ │ ├── instructions.md │ │ ├── context/ │ │ ├── inputs/ │ │ ├── outputs/ │ │ └── diary.md │ └── 002-data-clean/ └── 20250602/ └── 001-agent-refactor/

一级目录用日期，二级目录用“三位序号加短横线加任务别名”，比如001-build-landing。为什么用日期做一级？因为云盘里按时间归档是最不容易产生歧义的维度，配合云盘自带的文件历史，哪天创建的会话、哪个时间段改过，一目了然。为什么用三位序号？为了在目录列表里保持稳定排序，避免10排在2前面的那种字符串排序问题。

每个会话目录内部的固定结构，我坚持“读、写、执行”三区分离：

这个结构解决了我最初遇到的“无法检索”问题：所有会话默认就有 7 个固定入口，云盘上看到任何一个会话文件夹，都能立刻定位到它的指令、输入和输出。

2.3 命名的玄机：日期、序号、任务别名一个都不能少

命名这件事看着简单，其实藏着不少讲究。很多人在项目初期图省事，直接给会话目录起名新建文件夹 (3)，等一个月后再看，神仙也不知道里面是什么。我的命名公式是：

{三位序号}-{短横线任务别名}

例如001-build-landing、002-data-clean。短横线比下划线更利于在网页端点击复制，而且不会和 WorkBuddy 内部对空格的处理冲突。任务别名一定用英文小写加短横线，原因是我发现 WorkBuddy 的 Agent 在处理文件路径时，对中文目录名也能支持，但在读取日志、拼接路径、生成 zip 包时偶尔会有编码问题。英文别名虽然看上去不如中文直白，但长期使用下来，在云盘分享、程序解压、跨平台迁移这些场景里是最省心的。

一句话总结命名原则：让人和 Agent 都能看懂，让目录在列表里稳定排序，让云盘搜索命中率尽量高。

3. 落地实操：初始化脚本、WorkBuddy 配置与云盘同步策略

3.1 三分钟搭好会话工作区：一个脚本解决 80% 的重复劳动

思路再清晰，如果每次手动 mkdir 一堆目录，用一次就会嫌烦。所以我写了一个init_session.sh，放在云盘根目录的_scripts/下面，每次新开会话前跑一下，自动生成会话目录骨架：

#!/usr/bin/env bash WORKSPACE_ROOT="${WORKBUDDY_WORKSPACE:-$(pwd)}" SESSION_ROOT="$WORKSPACE_ROOT/sessions" TODAY=$(date +%Y%m%d) NAME="${1:-untitled-task}" TODAY_DIR="$SESSION_ROOT/$TODAY" mkdir -p "$TODAY_DIR" # 序号自动递增 LAST_NUM=$(ls "$TODAY_DIR" | grep -E '^[0-9]{3}-' | tail -n 1 | cut -c1-3) if [ -z "$LAST_NUM" ]; then NUM="001" else NUM=$(printf "%03d" $((10#$LAST_NUM + 1))) fi SESSION_DIR="$TODAY_DIR/$NUM-$NAME" if [ -d "$SESSION_DIR" ]; then echo "Directory already exists: $SESSION_DIR" >&2 exit 1 fi mkdir -p "$SESSION_DIR"/{inputs,context,outputs,_work} cat > "$SESSION_DIR/session.yaml" <<EOF session_id: "${TODAY}-${NUM}" created_at: "$(date -Iseconds)" task_alias: "$NAME" agent: "" status: active EOF cat > "$SESSION_DIR/instructions.md" <<EOF # Session ${TODAY}-${NUM} ## 目标 （一句话描述这个会话要完成什么） ## 约束 - （这里写你必须遵守的规则，例如：不要修改 inputs 下的原始文件） ## 验收标准 - [ ] （可勾选的交付标准） EOF touch "$SESSION_DIR/diary.md" echo "Session created: $SESSION_DIR"

使用方式也很简单：

cd workbuddy-sync ./_scripts/init_session.sh build-landing

脚本会自动识别今天是20250601，自动算出下一个序号是001还是002，然后生成完整的目录骨架、session.yaml 和 instructions.md 模板。每次开会话前，我会先想清楚目标，再把可能用到的需求文件丢进inputs/，把纪律要求写进instructions.md，最后才启动 WorkBuddy 指向这个目录。

这套脚本看起来简陋，但实际价值非常大。它把“给会话安家”这个动作的摩擦成本降到了最低：以前开一个会话要手工建七八个目录、写模板，至少要三分钟；现在一条命令十秒钟搞定，而且目录结构永远统一，云盘同步时也不会因为人为改名而产生奇怪的冲突副本。

3.2 把 WorkBuddy 的会话目录指向这个“家”

目录建好之后，最关键的一步是让 WorkBuddy 使用这个目录作为会话的工作目录。以我当时用的 WorkBuddy 版本为例，它支持通过环境变量注入工作区根目录，也支持在启动参数里指定--session-dir。不同版本细节会有差异，但核心思路一致：把你刚才生成的会话目录告诉 WorkBuddy。

export WORKBUDDY_WORKSPACE="$HOME/workbuddy-sync" export WORKBUDDY_SESSION_DIR="$WORKBUDDY_WORKSPACE/sessions/20250601/001-build-landing" workbuddy --session-dir "$WORKBUDDY_SESSION_DIR"

这里有两个细节值得注意。第一，环境变量的值在每台设备上可能不同，所以绝对路径不能写死在 WorkBuddy 的配置文件里。我会把export WORKBUDDY_WORKSPACE=...这行写进本机的~/.bashrc或.env文件，让路径成为运行时配置而不是项目配置。第二，session.yaml里的agent字段我会在启动前补上，写明这个会话用的是哪个 Agent。WorkBuddy 的会话列表会自动读取元数据，之后在界面上筛选非常方便。

如果你想把公共技能和自定义指令统一管理，可以把 WorkBuddy 的skills/路径指到云盘根目录下的共享 skill 目录，例如：

WORKBUDDY_SKILLS_DIR=$WORKBUDDY_WORKSPACE/skills

这样所有会话都能用同一套 skill，又不会因为各会话复制一份造成版本漂移。不过要记住：共享 skill 的编辑尽量只在同一台设备上改，云盘负责分发，不负责合并。一台设备改完同步，另一台只拉取，能避开绝大多数冲突。

3.3 让云盘只同步该同步的：忽略规则和目录白名单

很多人的云盘焦虑其实来自“什么都同步”。缓存文件、临时文件、虚拟环境、日志，这些高频变动的东西一旦进云盘，轻则同步带宽被占满，重则冲突不断。给会话安家之后，云盘同步策略也要重新规划。

我的做法是把整个同步盘分成三层：

不同云盘客户端的忽略规则实现方式不一样，但大致都有两种手段：隐藏文件法（在目录里放.nosync标记文件）和客户端忽略列表法。我个人推荐在_local_only/目录下放一个.nosync文件，因为云盘客户端对目录层级敏感，这个标记会导致整个目录不被上传，效果最稳定。

另一个容易忽略的点是单个文件的大小。Agent 会话里经常会产生几百 MB 的日志或模型输出，这类大文件一旦进云盘，客户端会反复对比分块，严重拖慢同步。我会在会话结束时做一次产物整理：真正的交付物压缩成 zip 手动传到云盘，中间过程的大块临时数据直接丢进_work/，并确保_work/被云盘忽略。这样既保留了回溯能力，又不会让云盘变成垃圾场。

4. 运行一段时间后的经验：常见问题与排查技巧实录

4.1 云盘回滚把会话日记打回原形

方案跑起来之后，我遇到的第一个大问题是云盘回滚。某次我在一台设备上更新了diary.md，又在另一台设备上改了session.yaml，两边几乎同时同步。云盘客户端最后以“合并冲突”为名，把整批文件回滚到了较早的版本。结果就是：Agent 的上下文还在，但我在日记里记录的决策过程全部消失了。

排查起来非常费劲，因为文件本身没有任何异常标记，只有对比时间戳才能发现问题。后来我的对策有三条：第一，diary.md的更新尽量集中在会话结束时一次性写入，降低并发概率；第二，重要决策直接写进context/下的快照文件，而不是只依赖日记；第三，云盘开启历史版本保留功能，一旦发现回滚，立即从历史版本恢复。这是一个“低频率发生但影响很大”的坑，单靠目录结构不能完全规避，需要配合操作习惯。

4.2 多设备路径不统一的教训

我前面提到路径漂移问题，实际解决过程比预想的曲折。第一次我试图把所有设备上的云盘挂载到同一个路径，比如都叫D:/CloudDrive，结果 Windows 和 Mac 之间根本做不到。后来我把所有绝对路径从 WorkBuddy 配置和会话文件里清掉，统一改成相对路径。

具体做法是：所有会话文件里只写相对路径，比如context/xxx.md，根路径通过WORKBUDDY_WORKSPACE环境变量注入。这样无论在哪台设备上，启动 WorkBuddy 前先source .env把根路径配好，剩下的会话内容全部通用。这个改动之后，跨设备会话再也没有出现“目录不存在”的报错。

4.3 会话清理与归档：太多家也会变成负担

给每个会话一个家，家多了之后又面临新问题：目录数量膨胀。我跑了三个月，sessions/下已经有上百个会话目录，云盘客户端在手机上浏览时开始卡顿，WorkBuddy 的会话列表也变得冗长。

现在的清理策略是三层：活跃会话保留在sessions/当前月目录里；超过一个月的会话打包成 tar.gz 放到_archive/，并从云盘自动同步中移除；超过两个季度的会话按项目归类后存到冷存储。归档后 WorkBuddy 历史会话会丢失，所以我在归档前会把session.yaml和outputs/里的交付物单独摘出来，形成一份summary.md放到项目总目录，相当于给会话留一个“墓碑”，需要时还能根据墓碑找到归档包。

4.4 一份速查表：会话“无家可归”最小排查清单

最后整理一个排查清单，每当云端会话出问题，我按这个顺序查：

这套“给每个 Agent 会话一个家”的方案，说到底不是在折腾文件夹，而是在给 Agent 的运行边界做约束。会话有了明确的物理载体之后，WorkBuddy 不再只是一个聊天的入口，而是一个真正可管理、可交付、可交接的工作系统。我在实际使用中最大的体会是：云盘本身的同步机制没有那么可靠，但只要数据的组织方式足够清晰，即使同步出了错，恢复成本也非常低。最后再分享一个小技巧：给diary.md养一个固定模板，每次会话结束花两分钟填完，云盘上那几百个会话目录，未来就是你最好的项目复盘库。