# WorkBuddy高阶教程｜万字复盘：如何让Agent接手真实项目
**作者**: 智见AI-大鹏
**日期**: 2026-07-19T10:26:57.000Z
**来源**: [https://x.com/zjp1997720/status/2078788676872720579](https://x.com/zjp1997720/status/2078788676872720579)
---
7 月 15 日，我在绍兴市国土空间规划研究院，讲了一场两个半小时的 WorkBuddy 实战培训。
这次我没有从“哪个模型更强”讲起，也没有按照功能菜单，一个按钮一个按钮往下介绍。
我只给大家设定了一个情节：
> 我现在是一个规划项目的负责人，明天上午要向院里做阶段汇报。但是项目刚接手，文件夹里面有七份材料，时间、版本、用途和可信程度都没有理清楚。
我们要做的，是带着 WorkBuddy 从这一堆乱材料开始，一步一步把项目接下来。
我第一次输入的任务，也不是“帮我做一个 PPT”。
而是：
> 先不要写汇报，也不要移动文件。
这句话其实就是整场培训的起点。
因为真实项目里，最危险的事情，就是 AI 还没搞清楚材料、口径和边界，就开始帮你包装答案。
## 大家缺的已经不是“会不会问 AI”
这场培训之前，院里向员工收集了一份问卷。
我把问卷里反复出现的问题，归纳成了五类：
- 政策多、来源散，报告的依据很难追溯。
- 各种来源的材料太多，重点、难点很难提炼。
- 汇报结构难组织，不知道怎么把专业信息讲清楚。
- 项目时间很长，人脑很难持续记住项目背景和当前状态。
- 今天领导修改，明天专家评审，版本和口径很容易乱。
这五个问题表面上不一样，但背后实际上是同一个问题：
> 材料都在，但项目的上下文没有建立起来。
我们过去用 DeepSeek、豆包或者其他 Chatbot，大部分时候是一问一答。我们问一个问题，它回答一个问题。
但是一个真实项目，不是一个问题。
它是一堆材料，一系列任务，很多次修改，以及不断发生变化的项目状态。
所以这节课真正要解决的，已经不是“大家会不会问 AI”。
而是怎么让 Agent 进入一个完整的工作现场，然后持续把事情往下做。
## 从问问题，到给 Agent 派活
我在现场讲了一个词，叫做“Agent 领导力”。
我的判断是：一个真正有领导力的人，大概率也可以把 AI 用好。
因为给 Agent 派活，和领导给员工派活，本质上是一样的。
你不能只说一句“帮我做个规划汇报”，然后就期待它把你脑子里的想法全部猜出来。
你至少要说清楚三件事：
- 现在是什么情况。
- 最后要交付什么。
- 这件事准备怎么推进。
我把它压缩成了一个很简单的结构：SGP。
S 是 State，现状。
这里包含两个维度：人的现状和事情的现状。
你是谁？你在这个任务里面负责什么？你手上已经有哪些材料？项目发展到哪一步了？这些都是 State。
G 是 Goal，目标。
不只要说清楚交付物是 PPT、PDF 还是研究报告，还要说清楚这个交付物想要产生什么影响。
同样是一份 PPT，是给领导做决策，还是给客户看方案，信息密度、表达顺序和视觉重点都不一样。
P 是 Process，过程。
如果你非常懂这件事，当然可以告诉 Agent 先干什么，再干什么。但随着模型能力提升，我越来越不建议把所有过程都写死。
你可以让 Agent 先制定计划。计划没问题，再让它执行。
说白了，任务有一个起点，有一个终点。人先把起点和终点说清楚，Agent 再帮我们规划中间怎么走。
这比背一堆六个单词、八个步骤的提示词框架，更容易记，也更接近真实工作。
## Chatbot 回答问题，Agent 接手一件事
接下来，我让大家回想一下自己用 Chatbot 的过程。
假设我想让豆包帮我做一个 PPT，我要先思考这个任务需要哪些材料，再到电脑里一个个找出来，点加号，上传附件，然后再写一大段提示词。
这个过程里，是人在帮 AI 收集上下文。
Agent 的工作方式不一样。
Agent 活在一个具体的文件夹里，也就是工作空间。
在你授权的范围内，它可以自己搜索文件、读取文件、比较不同版本，也可以新建、编辑和整理文件。
我们过去人工挑附件、人工收集上下文的过程，开始可以由 Agent 自己完成。
而且 Agent 的工作方式，是一个循环：
```
计划 → 执行 → 检查结果 → 修改计划 → 继续执行
```
这也是为什么 Agent 可以接手一件事，而不只是回答当前这一个问题。
我在现场又拆了三个词：工具、状态和循环。
工具决定它能做什么，状态决定它知不知道自己做到哪了，循环让它不断向最终目标靠近。
当然，能干活不代表一定能把活干对。
Agent 还缺一个最关键的东西：上下文。
## 上下文，是那些人知道、AI 不知道的信息
很多人用 AI 之后会说：“也不怎么样，产出的东西还没有我自己做的好。”
这种情况确实很多。
但我的第一反应不是先怪模型，而是先问一个问题：
> 那些会影响结果的信息，你真的全部给 AI 了吗？
为了讲清楚这个概念，我在现场用了一个“AI 乔哈里视窗”。
我们可以把知识分成四个区域：
- 人知道，AI 也知道。比如通用的规划知识。
- 人不知道，AI 通过搜索和研究可以帮我们补齐。
- 人和 AI 都不知道，需要共同探索。
- 人知道，但 AI 默认不知道。
最后这一块，才是我们用好 Agent 最需要解决的问题。
AI 不知道你是谁，不知道你的岗位、经验和表达习惯；它也不知道你们单位内部的材料、项目进展、会议决定、领导反馈和当前口径。
这些信息没有进入 Agent 的工作环境，它就只能用通用知识补空白。
看起来很合理，但不一定是你这个项目的答案。
所以我对上下文的定义很简单：
> 上下文，就是那些 AI 默认不知道，但会影响任务结果的信息。
当时我又给大家画了一个很简单的类比：
> 提示词是方向盘，上下文是真实路况，验收标准是终点。
方向盘再好，路况不对，也到不了你真正想去的地方。
## 工作空间是房子，上下文窗口是桌子
讲完上下文，我现场让大家打开 WorkBuddy，选择我提前准备好的“青岚片区更新研究_现场跑”文件夹作为工作空间。
我先让大家搞清楚工作空间和上下文窗口的区别。
工作空间就像 Agent 待的一间房子。
房子里面可以放很多文件，很多材料，很多历史成果。它可以在房子里面找东西。
上下文窗口是 Agent 干活的桌子。
桌子有大有小，它不可能把房子里所有东西永远全放在桌子上。它要根据当前任务，找出最相关的材料放到桌子上，完成思考和交付。
所以文件夹乱不乱，文件名清不清楚，对 Agent 来说真的很重要。
人有时候还可以凭印象记得“那个最终最终版应该在某个文件夹里”，Agent 需要依靠清楚的目录、文件名和项目规则进行稳定检索。
从这里开始，我们正式进入第一个实操。
## 第一项任务不是写汇报，而是先搞清楚手上有什么
我给大家的完整任务大概是这样的：
```
我明天要向院里汇报一个存量城区片区的规划优化情况，
刚接手这个文件夹，里面的材料比较乱。
先不要写汇报，也不要移动文件。
请逐份看完这些材料，告诉我每份材料主要讲什么，
大概是什么时间和版本，可以直接使用、只能参考，
还是需要进一步确认。
再帮我找出材料之间说法不一致的地方，
以及完成这次汇报还缺什么。
最后给我一个文件夹整理方案和接下来的工作建议，
等我确认后再执行。
```
这段话不是为了把提示词写得很长，每一句都有它的作用。
“明天要汇报，刚接手文件夹”，说清楚了时间压力和人物状态。
“先不要写汇报”，是为了防止 Agent 跳过理解材料，直接开始包装答案。
“不要移动文件”，是把读取和改写分开，先看清楚，再决定怎么整理。
“可以直接使用、只能参考、需要确认”，是在给材料分可信等级。
“等我确认后再执行”，是把人工检查点放进了任务里。
任务启动之后，WorkBuddy 自己列出了目录，开始读取不同格式的文件。
它发现 Word、PPT、Excel 这些文件不能直接当成普通文本读，就自己写了脚本，把里面的文字内容提取出来。
这个细节在现场很有意思。
我没有教它“请先写一个脚本解析 Word”。我只是说清楚了我有什么，最后想要什么。
它自己遇到了障碍，自己找工具解决了。
这就是 Agent 和普通对话式 AI 很大的区别。
最后它不仅说清楚了七份材料分别是干什么的，还识别出了不同文件之间的口径冲突。
比如旧 PPT 里说现有服务点是 9 处，Excel 里列了 12 处。这 3 处的差异到底是新增，还是统计口径不一样，需要人进一步确认。
它还建议我们整理文件夹。
这个时候，大家已经不是在看一个 AI “总结文档”。
大家开始看到，Agent 真的在接手这个项目的第一步。
## 目录结构本身，也在给 Agent 提供上下文
第一轮材料审读结束后，我们没有一上来就搭一套很复杂的项目管理系统。
我只让 WorkBuddy 把文件夹分成了四个区域：
```
01_输入材料
02_研究分析
03_内容底稿
04_交付成果
```
输入材料放项目收到的原始文件。
研究分析放联网调研、数据分析和各种中间研究成果。
内容底稿放经过人工确认、可以供 PPT、PDF 和其他交付物共同读取的内容。
交付成果放最终给人看、给人用的文件。
这四个目录其实就是一条工作管道。
而且它不只服务 Agent，也服务人。任何一个人进入项目，都可以很快知道哪里是原始证据，哪里是研究过程，哪里是统一口径，哪里是对外成果。
我们还定了一条非常重要的规则：
> 原始材料永远只读，不覆盖，不在原文件上直接修改。
这不是为了显得专业。是因为任何一个后来发生的判断，都应该能够回到原始材料去核对。
## 项目分身不是一个人设，而是一套可以延续的项目上下文
文件夹整理完之后，我带大家做了一个“项目分身”。
这里容易有一个误解。
一提到“分身”，很多人会想到给 AI 取个名字，设计一个性格，让它说话像自己。
这只是很小的一部分。
一个项目分身真正要解决的，是新开一个对话之后，Agent 还知不知道这个项目是干什么的，做到哪了，哪些事已经确认，哪些事还不能乱下结论。
我们先用 /init 建立身份和记忆基础。
然后明确让 WorkBuddy 完善项目根目录里的 CODEBUDDY.md，并建立 00_项目总览.md。
CODEBUDDY.md 可以理解为这个项目的系统提示词。
它写的不是某一次任务，而是长期、稳定、每次新对话都应该生效的项目规则。
比如：
- 这个项目是干什么的。
- 各个文件夹分别放什么。
- 原始材料只读，不覆盖。
- 事实必须区分已确认和待确认。
- 移动、删除文件和改变重要结论前，先询问人。
- 完成关键任务后，主动更新 00_项目总览.md。
00_项目总览.md 放的是会变化的项目状态：
- 当前目标和阶段。
- 已经确认的事实和约束。
- 现有成果及其路径。
- 待确认事项和风险。
- 接下来要做什么。
我现场用的提示词是这样的，建议逐句学习～
```
这个项目后面还要持续做很多任务。
我希望 WorkBuddy 每次进入这个文件夹，都知道项目已经做到哪一步，也不要把还没确认的内容当成正式结论。
请结合刚才的材料梳理结果，检查并完善 CODEBUDDY.md。
写清楚这个项目是做什么的、文件夹分别放什么，以及下面几条工作规则：
原始材料只读取，不覆盖；研究、内容底稿和交付成果放进对应文件夹；事实要区分“已确认”和“待确认”；移动或删除文件、改变重要结论前先问我；完成关键任务后主动更新 00_项目总览.md。
完善后，再创建 00_项目总览.md，记录项目当前目标、已经确认的事实和约束、现有成果、待确认事项以及下一步工作
```
这两份文件不冲突。
系统提示词放稳定的规则，项目总览放动态的状态。
一次性的任务，仍然留在当前对话的用户提示词里。
最有意思的一步，是我带大家新建了一个空白对话。
前面那个对话里的历史消息，全部都没有了。然后我只输入一句：
> 你自我介绍一下，然后告诉我们这个项目进展到什么地步了，下一步要干什么。
WorkBuddy 主动读取了项目总览。
它告诉我：项目的基础工作已经完成，现在卡在“等你开板”这一步。还没有开始写汇报稿，不是因为懒，是因为材料里面还有几处数据矛盾，如果不先确认，写出来的东西站不住脚。
那一刻，项目分身这个概念就不需要再解释了。
大家已经看见它了。
## DeepResearch 不是搜索，而是一支临时组建的研究团队
中场休息之后，我们进入了 DeepResearch。
这一段录音开始得晚了几分钟，我把现场讲的核心内容在这里补齐。
很多人会把 DeepResearch 理解成“更强的联网搜索”。
我不是这么理解的。
DeepResearch 本质上是一套主从 Agent 的研究系统。
主 Agent 拿到研究问题之后，会先分析项目已经有什么，还缺什么，再把大问题拆成多个研究方向。
不同方向会交给不同的 Subagent 并行执行。
每个 Subagent 都有自己的独立上下文，专注于一个研究子问题。它们完成检索后，把带来源的结果交回主 Agent，再由主 Agent 去重、交叉核验和统一汇总。
如果把它说得更直白一点：
> 主 Agent 就像团长，它负责理解全局、拆任务和验收结果；Subagent 就像几位同时出发的研究员，每个人只负责一个方向。
在更完整的架构里，Rule 负责定义研究流程，Subagent 负责检索，Skill 负责补充特定信息源和工具，Plugin 把它们统一打包。
但普通用户真正需要记住的，是两件事。
第一，研究任务的边界不要给得太泛。
每个 Subagent 都有工具调用预算。问题太宽，它们就会把预算浪费在漫游和重复搜索上。
第二，正式开跑之前，一定要先看研究计划。
## 长线程复杂任务，需要在高成本执行前停一次
DeepResearch 内部会制定研究计划，但这份计划更像它自己在长任务里的“北极星”，默认不等于一定会完整展示给用户确认。
所以我在调研提示词里，专门增加了一句：
```
正式开展调研前，请先向我展示调研计划，
包括准备回答的问题、拆分的研究方向、
重点来源和预期产出。
我确认后再开始执行。
```
为什么要这么说？
因为 DeepResearch 不是一个几秒钟就能返回的小任务。
它可能要跑十几分钟，会调动多个 Subagent，消耗搜索、阅读和模型资源，产出的研究结果还会被后面的报告和汇报继续使用。
如果方向错了，后面做得越多，返工越大。
这时候，人的专业经验特别重要。
规划行业的人能看出它拆分的命题对不对，来源范围够不够，哪个方向被遗漏，哪些判断不应该让 AI 自己做。
现场的研究计划出来后，我们停了一次，确认四个研究方向是否需要增减，案例是只看浙江，还是可以扩展到长三角，产出形式是否满足下游需求。
确认之后，主 Agent 并行启动了多位研究员。
有的研究存量空间政策，有的研究同类城市案例，有的研究滨水慢行方案。每个 Subagent 都收到了一份由主 Agent 写好的结构化任务，最后把结果分别写入 02_研究分析。
这里还有一个现场才会遇到的问题。
有些学员的主 Agent 并没有稳定启动 Subagent，而是准备自己把所有研究做完。
这个时候我告诉大家，提示词从来不是强制指令。模型是否严格遵守，和它自身的指令遵循能力有关。
我们可以明确补一句：
> 确认研究计划，请启动 Subagent 并行完成调研。
然后继续观察它是否真的进入了主从协作路径。
用 Agent 不是写完提示词就闭上眼睛。
我们仍然要观察它的过程，在关键节点发现它有没有走到我们期待的路径上。
## 一次做成，还不算真正的能力
DeepResearch 跑起来之后，我开始讲整场培训里我最想让大家带走的一个概念：Skill。
很多人第一次听到 Skill，会觉得它是一个非常技术的东西。
我当时用了一个安装桌子的比喻。
如果我想装好一张桌子，我需要一把电钻。电钻让我拥有拧螺丝的能力，这是工具。
普通人拿到电钻不一定会用，所以还需要一份说明书。
但有工具、会用工具，也不代表一定能把桌子安装好。如果能把老木工多年总结出来的那条最短成功路径一起打包进去，普通人拿到之后才更容易把这件事做成。
所以：
> Skill = 工具 + 说明书 + 做成一件事的最短成功路径。
有些 Skill 不需要额外的技术工具，可能只是一份高质量说明书和成功路径。但一个完整 Skill 的价值，就是让 Agent 不用每次从零开始猜怎么做。
现场我先演示了怎么找 Skill、安装 Skill，以及怎么用斜杠、技能按钮和自然语言触发 Skill。
然后我们做了一个很具体的任务：
> 把 DeepResearch 产出的 Markdown 研究报告，转成一份符合单位格式要求的 Word 文档。
我现场给了一组格式要求：一级标题用什么字号，二级标题用什么字体，正文怎么排，表头用什么底色。
WorkBuddy 主动找到了文档生成 Skill，安装依赖，生成脚本，最后输出了 Word 文档。
我们打开文件，一项一项核对。标题字号对不对，正文字体对不对，表头的浅蓝底色对不对。
全部正确。
这时候我问大家：
> 如果这就是你们单位每次都要使用的 Word 格式，以后每次都要把同样的要求重新说一遍吗？
当然不用。
这就是一个特别适合做成 Skill 的任务。
## 高频、稳定、可验收的成功路径，都值得被固化
我在现场给了三个判断标准：
- 高频：这件事一周、一月或者每个项目都会反复出现。
- 稳定：它的关键步骤和质量标准相对稳定。
- 可验收：人可以清楚判断结果是否合格。
凡是符合这三个条件的任务，都值得考虑固化成 Skill。
但是顺序不能反。
> 先带着 Agent 把一件事真实做成，再把已经验证过的最短成功路径固化成 Skill。
不要还没有做过任务，就凭空想象一个完美流程。
因为你只有真正跑过一遍，才会知道哪些步骤可以删，哪些检查不能少，哪些决定必须由人来做。
我们当场调用了 WorkBuddy 内置的 Skill Creator，也就是“创建 Skill 的 Skill”。
我用的话术很自然：
```
以上的格式要求，就是我们单位固定的 Word 模板要求。
请使用 Skill Creator 帮我创建一个 Skill。
它的作用是把任何 Markdown 文档，
按照这套固定模板生成 Word 文档。
正式开始设计前，请通过提问的方式与我对齐需求。
```
这里最重要的，不是记住 Skill Creator 这个名字。
而是两个设计习惯。
一个是先跑通，再固化。
另一个是高成本的长期资产在真正落盘前，先通过提问把边界对齐清楚。
WorkBuddy 接着询问了表格样式、页面设置、页眉页脚、需要支持的 Markdown 元素等问题。
我回答完之后，它创建了 Skill 的主说明文件和转换脚本。
我们又换了另外一份 Markdown 报告，用新创建的 Skill 重新生成 Word。
格式仍然正确。
这才算真正验证了这个 Skill 不是只能应付第一份文档。
我当时跟大家说，Skill 这个东西是会上瘾的。
当你第一次把自己工作里的一条成功路径做成 Skill，后面你会不断发现，这件事也可以固化，那件事也可以固化。
你的 Skill 会越来越多，但更重要的是，你过去靠脑子记住、靠手把手带人的经验，开始变成一份可以反复调用的数字资产。
而且 Skill 不会第一天就完美。
使用过程里发现了问题，你让 Agent 纠正结果，再让它根据这次纠正去更新 Skill。
每一次失败都不只是把当前任务改对，还可以让下一次的成功率变高。
## 从一次实操，延伸到会议、手机和自动化
这场培训的后面，我又快速演示了三个方向。
第一个是连接器。
连接器可以理解为 Agent 进入其他工具的通道。比如授权腾讯会议之后，WorkBuddy 可以读取会议纪要；授权邮箱之后，它可以帮你整理最近收到的邮件。
这个能力放到项目里非常实际。
围绕项目开过的会，不管线上还是线下，都可以通过会议转写进入工作空间。会议里的决定、领导反馈和待办，不再只存在参会者的脑子里。
第二个是手机助理。
只要电脑开着，手机通过 IM 连接到 WorkBuddy，人在外面也可以给电脑发任务。
比如在手机上说：帮我看一下过去 30 天有哪些重要邮件，按重要程度分级，并为最重要的几封准备回复草稿。
它不是只在手机上回答你，而是通过手机触发电脑上的 Agent 去完成任务。
第三个是自动化。
自动化的底层逻辑其实很简单：按照固定频率，向指定工作空间发送一段固定提示词，需要的时候还可以一起带上 Skill。
我现场配置了一个规划政策日报。
它每天定时检查过去 24 小时内，自然资源部、浙江省自然资源厅、绍兴市相关部门公开发布的新政策、规程和典型案例，最多保留 5 条，写清楚来源和与项目的关系。
但我在提示词里特意增加了一条边界：
> 日报只作为研究线索，不要自动修改项目总览，也不要把新线索直接写成项目结论。发现重要变化时，只生成一个值得进一步研究的问题，等人决定是否启动 DeepResearch。
自动化可以负责持续发现线索。
什么时候启动正式研究，哪些内容可以进入项目事实，仍然由人决定。
## 这场课最后没有把所有内容都跑完
我原本还准备了两轮反馈修改、独立专家 Review、PPT 与 PDF 二次装配和版本闭环。
但现场只有两个半小时，不同学员的电脑环境、模型执行速度和任务状态都不一样。
所以到最后，我没有为了显得这场课“什么都讲了”，强行把所有页面快速过一遍。
我把时间留给了 Skill 的查找、安装、调用、创建和复跑，因为这是学员当时最需要亲手看见的部分。
课后回头听录音，我反而觉得这次的临场调整是对的。
因为一场真正有用的 AI 培训，验收标准不是讲师过了多少页 PPT。
而是学员是不是真的完成了几次认知切换：
- 从“问 AI 一个问题”，切换到“给 Agent 交付一件事”。
- 从“人工上传附件”，切换到“让 Agent 在工作空间主动收集上下文”。
- 从“联网搜索几条信息”，切换到“让主 Agent 带着 Subagent 完成一次可检查的深度研究”。
- 从“这次任务做完了”，切换到“把成功路径留下来，下次可以直接复用”。
这四次切换建立起来，后面的功能菜单换了，产品更新了，学员仍然知道自己在做什么。
整套方法的完整闭环，可以用四个词来概括：
- 做成：给 Agent 完整上下文，让它真正执行任务。
- 做对：在研究计划、重要结论和文件操作前放入人工检查点。
- 做稳：用项目总览、Skill 和版本让成功路径可以重复。
- 持续进化：自动化负责发现新线索，人再决定是否启动新一轮研究。
我现在越来越相信，企业或组织里真正有价值的 AI 能力，不是某个员工偶尔用 AI 少干了半个小时的活。
那只是一次效率。
项目的上下文能不能留下来，人的检查点能不能留下来，已经验证过的最短成功路径能不能做成 Skill，然后被同事和下一个项目继续使用，这才是组织能力。
这场培训之后，我也更确定了一件事：
> 企业 AI 培训不应该从工具菜单开始，应该从一条真实工作链开始。
学员不需要背住每个按钮。
他们需要亲手经历一次：一堆乱材料怎么进入工作空间，一个项目怎么建立可持续的状态，一次高成本研究怎么在开始前被人检查，一条做成过的路径怎么留在组织里。
这才是从“会问 AI”，走到“让 Agent 接手真实项目”的过程。
我之前把与电子工业出版社合作的《初识 WorkBuddy》课程整理成公众号文章，那篇文章后来跑到了 3 万阅读，也间接带来了几次培训和课程录制的机会。
这次绍兴的合作，也是对方从 X 上找到我。
我不知道这篇文章最后会有多少阅读。
但我还是愿意把整套过程分享出来。
因为我越来越相信四个字：
> 越分享，越幸运。
如果你所在的单位，也在思考怎么让 AI 真正进入项目，而不只是给员工再上一节工具课，欢迎找我交流。
大鹏只做深度实践类的内容。
## 相关链接
- [智见AI-大鹏](https://x.com/zjp1997720)
- [@zjp1997720](https://x.com/zjp1997720)
- [3.3K](https://x.com/zjp1997720/status/2078788676872720579/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:26 PM · Jul 19, 2026](https://x.com/zjp1997720/status/2078788676872720579)
- [3,391 Views](https://x.com/zjp1997720/status/2078788676872720579/analytics)
- [View quotes](https://x.com/zjp1997720/status/2078788676872720579/quotes)
---
*导出时间: 2026/7/20 08:34:51*