不是玄学。是让每次协作都有一个清晰的"起点"和"存档点"。
9:00 — 打开 WorkBuddy 9:01 — 你:继续昨天的任务 9:03 — WorkBuddy:好的,昨天我们做了什么? 9:05 — 你:...我昨天让你重构了用户模块,你忘了? 9:06 — WorkBuddy:开始回忆,但记得不完全 9:10 — 终于对齐了。但你已经烦了。
这不是 WorkBuddy 的问题。是每次协作都是一个"冷启动"——AI 从零开始定位。好在这个问题有非常简单的解法。
# ❌ 坏开始
你:继续做上次的
你:还记得我们在做什么吗?
# ✅ 好开始
你:上次我们在做 X 功能的 Y 模块。
完成了数据库 schema,API 层的 create 和 list 写好了。
今天做 update ——
注意:update 需要权限校验,和 create 不一样。
[可选] 上次遗留下来的待办:batch_update 的接口设计还没定。一个好开始的三要素:
要素 | 内容 | 例子 |
|---|---|---|
断点定位 | 上次停在哪 | "API 层写到 create 和 list" |
今天目标 | 今天做什么 | "做 update,需要权限校验" |
上下文钩子 | 和上次的关键关联 | "和 create 不一样的地方是..." |
三句话,20 秒。 剩下就是它的活了。
更好的方式——每次收工时写一个"下次起点",下次自动读取:
# 文件:NEXT_SESSION.md(每次收工写,下次开始自动读)
## 下次从哪里开始
- 任务:用户模块 update 接口
- 上下文:create 和 list 已完成,数据库 schema 已定
- 注意:update 需要权限校验(create 不需要)
- 遗留问题:batch_update 的接口设计还没决定下次 WorkBuddy 读了这个文件,你连"上次我们在做 X 功能的 Y 模块"都不用说。直接:
你:继续 WorkBuddy:好的,基于上次的 NEXT_SESSION.md, 今天做 update 接口。和 create 的区别是需要权限校验。 请确认:权限校验规则和 create 的用户角色检查一样吗?
这就是好的开始:你不用回忆,它不用猜。 对话的第一分钟就在推进任务,不是在回忆任务。
你:今天的改动可以了。 WorkBuddy:好的。三天后回来——你:继续 WorkBuddy:三天前的上下文已经不在窗口里了。
每次不存档的结束,等于对下次对话说"到时候你自己想吧"。
# 结束时的两分钟存档
1. 进度:今天做了什么 —— 一句话
2. 状态:代码是否可运行? —— "可运行,测试全过" 或 "中间态,跑不了"
3. 下次从哪开始 —— 明确的断点
4. 今天的关键决策 —— 选了方案 A 放弃 B,原因
5. 未解决的坑 —— 已知但暂时搁置的问题实际操作:
你:今天的改动可以了。写一下下次开始点。
WorkBuddy:
# 2026-05-15 收工存档
## 进度
用户模块 update 接口完成,测试通过。
## 状态
全部代码可运行,12 个测试全绿。
## 下次开始
1. batch_update 接口设计(今天只定了要用"事务包裹")
2. 前端联调需要的 API 文档
## 今天的关键决策
- 放弃了批量更新用消息队列的方案(项目规模用不上)
- 权限校验复用现有的 check_role(),不另写逻辑
## 已知坑
- 并发更新时 optimistic lock 的版本冲突处理还没写2 分钟存档 = 下次少花 10 分钟对齐。
如果每次收工都按固定格式存档,过一阵子你就有了一份按时间排列的项目日志。
# 日志目录
logs/
2026-05-12.md ← 每天的收工存档
2026-05-13.md
2026-05-14.md
2026-05-15.md ← 今天
# 回溯一个决策:
# "我们当时为什么放弃了消息队列方案?"
# → 打开 2026-05-15.md → 看"今天的关键决策"这叫"决策可追溯性"。 项目做久了,最贵的信息不是"代码怎么写",是"当时为什么这么决定"。
开始仪式 20 秒,结束仪式 2 分钟。总投入不到 3 分钟。
不仪式:下次冷启动 10 分钟对齐,过程中三四次"不对,不是这个意思"的纠正,在错误的方向上调试了 15 分钟才意识到它理解错了。
仪式不是"额外的成本"——是不仪式的成本太高。
坚持一个月开始和结束的仪式后,我发现一个变化:我不需要"进入状态"了。
以前每次打开 WorkBuddy 都有一个心理准备期——回忆上次、梳理上下文、决定今天做什么。现在打开就是接着上次往下走,像是没关过一样。
好的仪式让协作变成了一个连续流,不是一堆碎片化的交易。 连续性强到一定程度,你会忘记它是"下一段对话"——它只是"继续刚才的事"。
本文基于与 WorkBuddy 的协作经验撰写。你每次收工时会给 WorkBuddy 留"下次起点"吗?评论区分享你的仪式。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。