核心结论
Claude Cowork 的正确配置，不是不断创建文件夹、维护“关于我”文档，再把所有背景信息塞进每一次对话。
更有效的结构只有两层：
- Skills：保存可重复调用的能力与方法。
- Projects：保存某个客户、项目或团队工作的专属上下文。
在此基础上，尽量减少全局设置，通过
AskUserQuestion 让 Claude 主动追问，必要时连接 Gmail、Slack、Google Drive 等外部工具。这样既能降低上下文污染，也更适合团队共享和长期维护。一、先理解 Cowork：它不是普通聊天，而是一组协作中的 Claude
普通 Claude 更像一次问答；Cowork 会先理解任务、拆解步骤，再调用多个并行代理完成研究、分析和制作。
一次提问后，你可能会看到多个 Claude 会话分别读取文件、搜索资料、规划方案，再合并成最终结果。它适合持续数分钟甚至更久的复杂工作，而不是只生成一段即时回复。
Cowork 先读取 Excel，再规划如何完成任务。
同一任务背后可以运行多个代理，其中一个正在执行网页搜索。
这也是 Cowork 与普通 Chat 最大的差异：你只提交一次目标，系统负责规划、分工和执行。
二、为什么不再推荐“文件夹 + 文件”体系
早期常见做法是：在电脑中创建一个 Cowork 文件夹，放入“关于我”、品牌资料、提示词和历史输出；每次开始任务时，再把整个文件夹交给 Cowork。
这套方法个人短期使用看起来清晰，但长期会出现两个问题：
- 文件夹会泄漏上下文。 即使要求 Claude 不要读取某个输出目录，它仍可能把过时结果带入当前任务，使上下文受到污染。
- 文件难以维护。 “关于我”、品牌规范、客户信息和历史输出都会不断变化。维护成本最终会高于它带来的价值。
团队协作时问题更明显：每个人本地的文件夹版本不同，无法稳定同步，也难以控制权限和更新。
因此，应该把“能力”和“上下文”拆开管理。
三、只保留两种核心对象：Skills 与 Projects
1. Skill：可跨对话复用的能力
Skill 是一套可以通过斜杠命令调用的工作方法，例如：
/linkedin-post：按照固定方法生成 LinkedIn 内容；
/contract-drafting：根据合同规范起草文本；
/answer-onboarding：依据公司知识回答新人问题；
/design-review：按照设计评审框架检查方案。
它回答的是：“Claude 应该怎样完成这一类任务？”
Skill 可以在不同聊天、不同 Project 中重复使用，也更容易分享给团队。
Skill 通过
/命令 调用。2. Project：持续存在的专属上下文
Project 是一个具体工作的空间，例如某个客户、某次营销活动、一个产品项目或公司的新人培训库。
其中可以保存：
- 客户资料、合同和往来邮件；
- 品牌规范、研究资料和项目文件；
- 固定说明与权限范围；
- 团队共享的历史上下文。
它回答的是：“这项工作发生在什么背景中？”
每个 Project 内的对话都能读取该 Project 的完整上下文，但不会污染其他 Project。
3. 最简单的判断方法
- 能够教给别人、可反复调用的方法 → Skill
- 属于某个客户、项目或活动的专属资料 → Project
团队必须统一这条边界，否则很快会出现“几百个本应属于 Project 的 Skills”，或者“几十个本应共享为 Skill 的 Projects”。
四、如何创建和使用 Skills
方法一：使用 /skill-creator
在 Claude 中调用
/skill-creator，按提示回答问题、测试结果并保存。
在 Claude 内使用
/skill-creator。完成后，Skill 会成为可复用的斜杠命令。
保存后可通过名称调用，例如
/contract-drafting。方法二：使用外部 Skill 生成工具
原文使用
makemyskill.com 作为示例：输入目标后，工具会进一步检索网页资料并生成 Skill 文件。
描述你希望 Skill 完成的工作。
下载生成结果。
然后进入：
Claude Cowork → Customize → Skills → Add → Create skill → Upload a skill
将下载的 Skill 上传到 Claude。
上传后即可使用
/命令 调用。方法三：把现有聊天转换为 Skill
当某次对话形成了一套稳定方法时，不必从头编写：
- 点击聊天顶部的名称；
- 选择 Turn into skill；
- 让 Claude 将当前对话整理为可保存的 Skill。
这种方式适合把已经验证过的工作流快速沉淀下来。
Skill 不必很短。对于复杂工作，它可以包含大量示例、SOP、历史内容和参考资料。但应只保存“完成任务的方法”，不要混入某个客户的私有上下文。
五、如何创建 Projects
进入：
左侧菜单 → Projects → New project → Start from scratch创建时设置名称并上传必要文件。原文建议：如果没有稳定、必要的规则，Project Instructions 可以先留空，避免过度约束。
给 Project 命名并添加文件。
Project 内的聊天会自动携带已上传文件的上下文。
Project 的优势不只是保存文件，而是形成一个不会外溢的上下文边界。例如：把客户资料、邮件、历史活动和谈判偏好放入同一个 Project，之后每次对话都能读取这些信息，但不会影响其他客户。
Project 提供客户上下文，Skill 提供执行方法。
六、最佳组合：在 Project 内调用 Skill
推荐工作流：
- 把高频能力做成 Skill，例如“起草合同”；
- 把客户资料放进对应 Project；
- 在客户 Project 内调用合同 Skill；
- 必要时连接 Gmail、Outlook、Slack 或 Teams，补充实时上下文。
这样，Skill 决定“怎么做”，Project 决定“为谁做、依据什么做”。
分享 Project 给团队
原文中的操作路径略显反直觉：先在 Chat 中创建 Project，再切换到 Cowork 执行任务。
- 创建 Project；
- 点击右上角共享；
- 允许团队或工作区成员访问；
- 再从 Cowork 中打开该 Project。
点击 Project 入口。
Cowork 会在带有 Project 上下文的聊天中工作。
分享 Skill 给团队
进入：
左侧菜单 → Customize → Skills → 选择某个 Skill → Share然后选择对应工作区。
团队成员也通过
/命令 调用共享 Skill。七、全局设置越少越好
过多的全局说明会让 Claude 在所有任务中反复读取同一套背景，并倾向于输出相似答案。对于合同等高度标准化任务，这可能有帮助；但在研究、创意和策略任务中，过度上下文会限制探索空间。
建议：
- 不再使用全局文件夹；
- General Settings 只保留必要配置；
- Global Instructions 不写具体客户和项目背景；
- 只开启真正使用的 Connectors；
- 需要方法时调用 Skill，需要背景时进入 Project。
原文建议在该区域尽量保持关闭，只保留必要的 Connectors。
连接器可以让 Cowork直接读取 Gmail 等应用的上下文。
根据工作需要开启必要能力。
开启相关能力后，Claude 可以生成交互式图表。
目前并不完美：Skill 可能因为描述匹配而自动触发，Project 也可能存在文件数量限制。因此，仍需定期清理不再使用的 Skill 与 Project。
八、最有效的提示技巧：先让 Claude 采访你
很多提示失败，不是模型能力不足，而是用户没有提供足够目标、判断标准和约束。
可以从下面这类提示开始：
我需要完成【任务】，目标是【成功标准】。开始执行前，先使用 AskUserQuestion 向我收集完成任务所需的信息。
例如：
我需要为公司新品发布写一份公关简报，目标是获得更多有效线索。开始执行前，先使用 AskUserQuestion 向我收集受众、产品卖点、媒体范围、预算和时间表。
Claude 会生成一个问题表单。回答后，它会基于更完整的信息重新规划任务。
这个方法不限于第一次提问。执行过程中发现信息不足时，可以再次要求 Claude 使用
AskUserQuestion，持续补齐上下文，而不是自己猜测该补充什么。九、不要把文件留在 Cowork：输出到真正工作的地方
Cowork 适合制作表格、文档、PDF 和演示文稿，但最终成果通常还要在 Google Drive、Google Sheets 或其他协作工具中继续编辑。
更实用的流程是：
- 在 Cowork 中生成文档或多工作表 Excel；
- 通过 Google Drive 集成一键导出；
- 在 Google Sheets、Docs 或 Slides 中继续协作；
- 需要修改时，回到 Cowork，或在目标应用中使用 AI 扩展。
Cowork 可以生成结构完整的多工作表文件。
通过集成按钮将文件直接转为 Google Sheets、Docs 或 Slides。
一个更稳定的表格提示模板
根据【文件路径、文件夹或上传的数据】创建 Excel 表格。
用途：说明谁会使用，以及它支持什么决策。
所需工作表：列出每个 Sheet 的名称、字段、每行含义和计算逻辑。
格式要求：币种、日期格式、条件高亮、冻结表头、汇总行和图表。
开始制作前，先列出最重要的 10 条假设供我检查，确认后再执行。
关键不是把每个单元格都描述清楚，而是先明确用途、结构、假设和可编辑输入，避免 Claude 在公式中硬编码重要参数。
十、什么时候不该使用 Cowork
工具选择可以简单归纳为：
- Chat：快速问答、改写、解释；不需要构建文件，也不需要长期上下文。
- Claude Code：交付物是软件、代码或需要持续构建的技术项目。
- Claude Cowork：交付物是文档型成果，例如演示文稿、分析报告、客户材料、表格和研究成果。
不要因为 Cowork 强大，就把所有任务都放进 Cowork。
十一、用 Claude 完成新人培训
企业可以把 Project 与 Skill 组合成一个可重复使用的入职系统：
- 创建一个新人培训 Project；
- 上传公司使命、产品资料、管理层访谈、支持团队最佳实践等内容；
- 邀请新员工加入 Project；
- 创建
/answer-onboardingSkill，规定 Claude 如何依据 Project 内资料回答问题；
- 新员工先在 Project 内调用该 Skill，再向负责人求助。
这会把提问方式从“我是新人，不知道答案”转变为“我已经主动查找并形成了一个候选答案，还需要确认”。
这种机制不能替代正式培训和权限管理，但能显著降低重复问答成本。
十二、让人机交互更快：用语音代替长篇输入
复杂 Cowork 任务经常需要多轮澄清。模型读取和生成很快，真正拖慢流程的往往是用户思考并键入自定义答案。
原文推荐 Wispr Flow 一类系统级语音输入工具：按住快捷键说话，松开后文字出现在当前输入框中。
它的价值不只是速度：说话时，人通常会自然补充更多背景、逻辑和语气，因此得到的提示往往比一句简短输入更完整。
适合语音输入的三个环节：
- 初始提示：直接讲清背景、目标和顾虑；
- AskUserQuestion 回答：点击选项，复杂部分用语音补充；
- 反馈与调整：说明哪里不对、保留什么、只重做哪个部分。
十三、如何减少 Cowork 的 Token 消耗
1. 出错时重启或编辑旧消息，不要无限追加
每次发送新消息，模型都要重新读取当前会话历史。会话越长，重复读取的成本越高。
当某一步出错时：
- 在较早的消息处选择 Restart the conversation from here；
- 或编辑之前的提示，从该位置重新执行；
- 不要不断发送“不是这个意思，再改一次”。
2. 长会话定期迁移
当会话明显变长时，可以要求 Claude：
当前 Cowork 会话已经过长。请把目标、已确认事实、重要决策、文件位置、未完成事项和下一步整理为一个 Markdown 交接文档，我将用它开启新的 Cowork 会话。
新会话只加载整理后的必要上下文，而不是重新读取全部历史。
3. 把相关任务合并成一次请求
三个独立提示意味着三次上下文读取。若任务彼此相关，可以合并：
总结这篇文章、列出关键观点，并提供三个可用标题。
4. 根据任务难度选择模型
简单的语法检查、格式化和短回答不必始终使用最高成本模型。把高能力模型留给复杂推理、长文档和高风险任务。
原文提到的具体模型名称和价格属于 2026 年 7 月 2 日时的产品状态，当前应以客户端实际可用选项为准。
5. 把“关于我”从文件改成按需调用的 Skill
如果已经有完整的个人或公司背景文档，不必删除内容本身。可以把它转换为 Skill，只在确实需要时调用。
将长期资料做成可按需调用的 Skill，而不是默认加载。
6. 结合额度窗口安排重任务
原文建议把高消耗工作分散到不同时间段，避免在一个短窗口内集中使用全部额度。具体窗口与计费规则可能变化，应以当前套餐说明为准。
十四、前 20 分钟如何完成配置
- 0–3 分钟：清理全局设置，关闭不需要的选项。
- 3–8 分钟：创建第一个 Skill，选择一项你经常重复的任务。
- 8–13 分钟：创建第一个 Project，放入某个真实客户或项目的必要资料。
- 13–17 分钟：在 Project 中调用刚创建的 Skill，观察“能力 + 上下文”的组合效果。
- 17–20 分钟：检查共享权限、连接器和输出位置，删除多余设置。
总结
Claude Cowork 的关键不是把更多信息永久塞给模型，而是建立清晰的调用边界：
- Skill 管理可复用能力；
- Project 管理专属上下文；
- Connectors 提供实时外部信息；
- AskUserQuestion 补齐任务需求；
- Google Drive 等目标工具承接最终成果；
- 重启、迁移和合并任务控制会话成本。
对于团队，最重要的不是让每个人自由堆积自己的文件夹，而是统一 Skill 与 Project 的定义、命名、共享和维护规则。只有这样，Cowork 才能从个人效率工具升级为可协作、可治理的工作系统。
- 作者:yaney
- 链接:https://yaney.top/article/example-35
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
