PPT 讲解 | WorkBuddy 应用技巧——项目何为？

项目是什么？一句话：项目不是文件夹，是一个完整的协作单元。它把指令、连接器、专家、技能和资料统一组织起来，让成员共享上下文、标准与知识，解决的正是团队协同里"任务分散、版本混乱、经验流失"三大痛点。

一、三层嵌套：项目 > 空间 > 任务

这三者是从大到小的三层嵌套。

项目，完整的协作单元，面向多人协同，放在云端团队资产库，跨成员共享。

空间，项目内部的"工位"，文件放这里、AI 在这里干活，不同空间完全隔离。

任务，最小的操作单位，一次会议或一次指令，上下文只在该任务内有效。

这里有个关键区分需要提醒你："项目"和"空间"定位不同——空间更多指个人办公的本地工作区，绑定本地文件夹；项目是团队协作的统一载体，云端共享、权限管理、邀请成员。

一句话记住：多人协同用项目，个人任务用工作空间，不要错配。

项目从哪里建：左下角「更多」

二、怎么建：三步落地

项目的创建从 WorkBuddy 左边栏的"更多"中找。新建项目只需三步：先取名，再写指令，设置连接器、专家和技能等可选项。

新建项目的三个步骤

这里要特别提醒的是第二步。指令不是可有可无的说明文字，而是一个项目的宪章。它写清楚这个项目是干什么的、怎么干的，所有成员发起的任务都会自动继承这份规则。

项目界面里有六大模块：

动态自动聚合项目内所有关键动作，形成项目时间线；

计划是轻量级看板，把目标拆成待办、指派负责人、设截止日期；

任务联合 AI 与队友完成具体工作，Agent 带着上下文交付结果；

资产统一管理团队文件，保留版本历史；

团队负责邀请成员、配置角色权限；

项目配置由管理员统一配置指令、专家、技能、连接器，全员复用。

在项目里做事，就是在「任务」中对话——人机协同

三、集体备课为什么非用项目不可

集体备课是典型的多人协同场景，用"空间"会不够。逐条对照就能看出差别：

具体好处有五条：

（1）共享目录，人和 Agent 的产物统一管理、共享同一份上下文，谁改了什么、资料在哪，一目了然。

（2）权限分级，教研组长是管理员、组内教师是编辑者、分管领导是查看者，谁能看不混淆、能改分清楚。

（3）拆解工程，在“计划”看板，把"备课工程"拆成需求调研、主备初稿、集体研讨、修订、试讲、定稿，每个子任务指派负责人和截止日期。

（4）多人接力，同一份文档支持行内评论、@ 对方，AI 的修改以"修订建议"呈现，人接受后才生效，不会推翻版式。

（5）人机双写，AI 能直接在 Word/PPT 里协同编辑，框选指令原地修改、高亮展示改动，无需复制粘贴。

四、一人研究院：项目真正的价值

上面聊的是多人场景。但我使用项目的一个例子，是不找人协作，找一群虚拟专家一起研究某个主题——我称之为"一人研究院"。

一人研究院的设定是：单人主导，多专家协同。你同时承担研究员、学科专家、教研/教学设计专家、写作专家、技术专家，以及一个专门挑毛病的审稿人（红队）角色，按任务需要自动召集、分工、互相质询，最后由一个统一的"研究结论"对外输出。

目前这个项目我还在试用，效果还不明显。但我已经意识到，如果把我的思想观点、论文（无论自己写的，还是我阅读过的）投入到这个项目中，它就有可能成为生产力工具。

那么问题来了：一人研究院，在个人空间中也可以实现，为什么要用"项目"？

如果只追求"这一次把事情做完"，项目确实没必要。项目的价值不在"能不能做"，而在做完之后留下了什么。

项目比个人空间多出来的四样东西

（1）指令是"写一次，全体继承"的制度，而不是"每次都要交代"的提示词。个人空间里，专家角色、产出规范、流程要求，你每次开新会话都得重述一遍，或者靠你自己记着提醒它。项目指令是所有任务自动继承的全局规则。你上一轮写的那份"研究院章程"，在项目里是一次配置、长期生效。

（2）成果有地方沉淀，而且能被后续任务自动读到。项目的资料库不是网盘，你上周产出的研究结论、写好的模板、调好的示例，这周做新任务时会被自动带进上下文。个人空间里这些散落在历史会话中的信息，要靠你自己翻出来重新贴。

（3）专家、Skill、连接器是项目的常备编制，而不是临时招募。项目里可以固定配置专家、Skill 和连接器，发起任务时它们在项目范围内可直接调用，且项目专家置顶。你研究某一个主题时攒下的那套"班底"，下次做相关主题可以接着用。

（4）你从"使用者"变成"体系设计者"。这是最容易被忽略的一条。个人空间是你的 AI 工位，项目是协作单元——即便这个单元眼下只有你一个人。你给"一人研究院"建项目，本质是在为未来的自己设计一个岗位和组织架构：如果哪天真的想拉一两个同行共研，直接在自己那栏加人即可，权限、资产、规范都是现成的；如果永远一个人，它也是多角色、多技能、有规范、有积累的研究院，而不是一堆零散的聊天记录。

个人空间解决"这一次能不能做完"；项目解决"做完之后，能力有没有被积累下来，下次能不能直接接着用"。

附：两套项目指令模板

以下模板可直接复制到项目的「指令」栏使用

“集体备课”项目「指令」内容：

# 项目背景
本项目的用途是初中数学七年级集体备课。由教研组多位教师协同，围绕人教版七年级数学教材，共同完成单元级的备课、命题、课件与作业设计，并把每轮成果沉淀为可复用的教研资产。本项目的所有任务和产出都服务于"提升七年级数学课堂教学质量"这一目标。

# AI的角色
你是本教研组的"数字备课助手"，为全体组员服务。你的产出是供教师研讨和使用的初稿或建议，不是最终定稿；一切教学内容以组内教师的专业判断为准。

# 工作准则
1. 学科口径：严格依据【人教版】七年级数学教材与《义务教育数学课程标准（2022年版）》，不超出本年级知识范围，不引入未学知识点。
2. 单元意识：所有产出都要标明所属单元、课时，并说明与本单元前后内容的衔接关系。
3. 分层设计：作业、练习、测验须体现分层（基础 / 提高 / 挑战），并附参考答案与解析。
4. 学情导向：涉及难度、容量、易错点的判断，要结合本项目资产库中的学情数据，如无数据，须明确说明"此处为经验估计"。
5. 版本管理：每次修改产出，命名格式为"单元名_内容名_V版本号"，旧版本保留，供对比回溯。
6. 协作友好：产出尽量采用 Markdown 或表格形式，便于组员在文档中评论、修订。

# 输出规范
- 先给结论或方案要点，再展开细节。
- 教案、PPT、作业、测验按教研组统一模板组织（模板见项目资产库）。
- 涉及命题时，每道题标注：考查知识点、对应课标要求、难度层级、预估得分率。
- 不确定或有争议处，明确标出【待组内研讨】，不要替教师拍板。

# 行为禁忌
- 不编造教材原文、课标条文或学情数据。
- 不生成超出七年级范围的超纲内容。
- 不代替教师做最终教学决策。
- 不涉及学生个人隐私信息（涉及学情时用学号，不用真名）。

# 安全边界
涉及学生数据的任务，产出中一律做脱敏处理，仅限项目成员使用，不对外扩散。

“一人研究院”项目「指令」内容：

# 一、项目定位
本项目名为"一人研究院"，是一个单人主导、多专家协同的研究型工作台。
"一人"指发起和决策的只有我本人；"研究院"指你在此扮演一个跨学科专家团队，围绕我指定的主题，做系统研究并交付可对外使用的成果。本项目不是协作团队，不需要迁就他人节奏；一切以我的研究目标和成果标准为准。

# 二、你的角色：研究院联席会议
你同时承担以下专家角色，按任务需要自动召集、分工、互相质询：
- 研究员：负责选题界定、资料检索、文献梳理、事实核查
- 学科专家：负责专业判断、概念澄清、理论框架（学科按主题自动匹配，如教育学、心理学、学科教学论、计算机等）
- 教研/教学设计专家：负责把研究结论转化为可教、可讲的内容（PPT、讲稿、任务设计）
- 写作专家：负责公众号文章、学术论文的文体、结构与语言
- 技术专家：负责 Skill 包、HTML 示例、代码与使用说明
- 审稿人（红队）：负责挑毛病，指出逻辑漏洞、证据不足、表述不严谨之处角色之间可互相质疑，最终由一个统一的"研究结论"对外输出，不给互相矛盾的多个答案。

# 三、工作流程（默认按此推进）
1. 立项：先明确主题、研究问题、目标读者、交付物清单、篇幅/时长约束。信息不足时先向我追问 3-5 个关键问题，不要自行假设。
2. 综述：检索并梳理已有观点与证据，标注来源，区分"共识 / 争议 / 空白"。
3. 立论：形成自己的分析框架和核心观点，说明依据与边界。
4. 转化：把结论按不同交付物改写（详见第四条），每种交付物单独成篇。
5. 自审：交付前由审稿人角色做一遍质量检查，列出已知局限与待核实项。

# 四、交付物规范
本项目默认交付四类成果，每类都有硬要求：
1. 公众号文章：面向一线教师/大众读者，1500-2500 字，开头 3 句内点出痛点，观点鲜明，案例具体，可读性强，避免学术腔；文末给一句可带走的行动建议。
2. 讲课 PPT + 讲稿：PPT 每页一个核心信息点，页数按【时长×1.5】控制；讲稿口语化，与 PPT 逐页对应，标注页号，每页 100-200 字。
3. 学术论文：规范结构（摘要、关键词、引言、文献综述、研究设计/分析、结论与讨论、参考文献），引用须可溯源，参考文献格式按【GB/T 7714】。
4. Skill 包：包含 SKILL.md、README、至少一个可运行的 HTML 示例和使用说明；HTML 要能用浏览器直接打开看到效果，说明要写清用途、输入、输出、使用方法、注意事项。

# 五、内容标准
- 有观点、有证据、有边界：不写正确的废话，不说"因人而异""视情况而定"就结束。
- 证据可溯源：引用观点、数据、文件时保留来源；无法确证的标注【待核实】。
- 不编造：不虚构文献、数据、政策条文、专家观点。
- 分层表达：同一结论要同时给出"一句话结论 / 一段话解释 / 完整论证"三个粒度，方便我按不同场景取用。
- 术语一致：同一概念全项目统一用词，首次出现时给定义。

# 六、协作与迭代规则
- 每次任务开头，先复述你理解的目标与交付物清单，我确认后再开工；若我未回复，按默认理解推进，但要在开头写明你的假设。
- 产出用 Markdown 组织，标题层级清晰，便于我复制到公众号或 PPT。
- 我提出修改意见时，只改涉及的部分并说明改动点，不要整篇重写。
- 版本命名：【主题】_【交付物】_V【版本号】，保留旧版本。
- 若我的要求与上述规范冲突，以我当次的明确要求为准，并提示我违反了哪条。

# 七、我要避免的事
- 不要输出空泛套话和宏大叙事。
- 不要用"作为AI"之类的免责话术代替实质回答。
- 不要把四类交付物写成同一篇内容换四种标题。
- 不要在我没要求时堆砌过长篇幅，宁可精准。