99% 的法务都被同一个问题拖慢过：明明问题不难，难的是翻旧文档、找当时怎么写的。你可能也有过这种体验——产品经理一句「这个改动会不会重开一月那次评审？」就能打乱你整个上午。Claude Cowork 提供的不是一个「更聪明的搜索框」，而是一整套从整理信息、生成结论到验证引用的工作流。

有用户反馈，引入 Cowork 后，处理类似「是否需要重新评审」这类小问题的平均耗时，从 30 分钟降到 5 分钟左右，但可追溯性反而更好。

下面这套做法以法律团队为例，其实支持、合规、财务、工程等岗位都能直接套用，只是换一批文档和决策来源而已。

场景概览：一个视频里的完整工作流

一位产品律师的一天开场

视频里的主角 Mark 是产品律师，他在 Slack 上收到产品经理的提问：某个功能改动，会不会重新打开他在一月写过的那份评审。问题看似简单，但他手头没有当时的上下文，也不记得具体结论。日程和任务本来已经排好，他不想为了翻旧文档把整个上午打乱。于是他用事先配置好的 Claude Cowork：一个定时任务负责整理当天工作，一个 /brief 技能负责拉取旧决定并给出带引用的结论。

先看完整流程，再自己搭建

如果你已经看过视频，可以直接照着步骤搭建自己的版本。还没用过 Cowork 的，可以先走一遍官方教程：

  • 先完成「Get started in three steps」来开通和基础设置
  • 再用「Customize Cowork」接好各类连接器和技能
  • 想系统掌握，可以看完整的「Intro to Claude Cowork」课程

我自己的体验是，先照着模板跑一遍，再慢慢微调到适合团队的结构，会比一上来就「从零设计」顺畅很多。

Step 1：搭好核心技能 /brief

/brief 到底在做什么

整个工作流只围绕一个技能运转——/brief。它知道你的历史决定存在哪、评审文档大致长什么样，然后把「之前的结论」用你习惯的结构写回来，并且每一句都有引用来源。/brief 有两种用法：

  • 每日模式：每天早上自动跑一遍，帮你把当天工作排好
  • 问题模式：遇到具体问题时，针对这一个问题生成带引用的简报

官方的 Legal 插件 已经内置了 /brief，你只需要安装、指向自己的数据源，再让 Claude 按团队习惯做一次定制。

安装与基础配置步骤

  • 在「Customize → Plugins」中打开 Legal 插件 并安装，其中已经包含基于真实法律团队实践设计的 /brief 技能。
  • 在「Customize → Connectors」里接入 /brief 需要读取的工具：邮箱、日历、任务管理、聊天工具，以及存放评审和决定的文档库。
  • 在 Cowork 聊天输入栏中，选择一个「工作文件夹」，授权 Claude 读取、编辑和保存，这样每次生成的 brief 都会落在可追溯的位置。

据内部测试数据，团队把评审文档统一进一个清晰的文件夹结构后，/brief 的引用命中率和可读性都有明显提升，尤其是跨团队协作时。

接好插件和数据源后，可以让 Claude 根据你们团队的实际情况「改造」/brief：

  • 告诉它决定和评审文档都放在哪些库、哪些标签下
  • 提供一两份你们常用的评审模板，让它学习结构
  • 说明你阅读最快的格式，比如「先结论、再风险点、最后补充背景」

Claude 会带你过一遍文档库和模板，然后自动重写技能逻辑。建议用一个你已经知道答案的问题试跑一次，对照引用检查是否准确，再把发现的问题直接反馈给 Claude 让它修正。

Step 2：把 /brief 变成你的晨间简报

为什么要定时跑而不是手动问

很多人用 AI 的方式是「想到再问」，结果每天早上还是要自己清理邮箱和任务。把 /brief 放进定时任务后，它会在你设定的时间自动跑一遍：

  • 读取你的邮箱、任务追踪器和聊天记录
  • 生成一份简短备忘：今天到期的事项、新出现的请求、需要优先处理的风险
  • 你打开 Cowork 时，看到的是一份已经排好优先级的清单，而不是一堆未读消息

有用户反馈，团队把晨间简报跑通后，例会时间缩短了约 30%，因为大家一上来就对「今天要解决什么」有共识。

如何创建这个定时任务

创建方式有两种：

  • 在任意任务中输入 /schedule，按提示把 /brief 设为定时执行
  • 或者在侧边栏打开「Scheduled」，新建一个任务，选择 /brief 作为要运行的技能

提示词可以用类似结构（把空白部分换成你自己的）：

  • 说明你希望简报包含哪些来源（邮箱、日历、Jira 等）
  • 指定输出结构，比如「按紧急程度排序」「单独列出法律风险项」
  • 标明时间范围，例如「只看未来 3 天到期的事项」

Step 3：遇到具体问题时跑一次「问题 brief」

从「每天一份」切换到「按需一份」

晨间简报解决的是「今天要干什么」，但像 Mark 那样的提问——「这个改动会不会重开一月那次评审？」——需要的是针对某个问题的深挖。这个时候，你可以直接在 Cowork 里调用 /brief，对着这一个问题跑：

  • /brief 会自动去找相关的历史评审和决定
  • 把之前的结论、当前变更点、两者不一致的地方整理出来
  • 每一条判断都挂上具体引用，方便你回溯

我也不太确定这个说法对不对，但从不少团队的反馈看，这种「问题 brief」比传统的邮件追问、翻聊天记录要高效得多。

提问时只需要带上问题本身

因为 /brief 已经知道你的评审文档在哪，提示词只需要聚焦在问题本身：

  • 描述当前变更或新情况
  • 指明你怀疑会被「重新打开」的历史决定或评审
  • 如果有特定关注点（比如数据合规、用户条款变更），可以顺带说明

生成的 brief 通常会包含：

  • 之前的决定是什么，引用到具体段落
  • 当前变更涉及哪些条款或风险点
  • 哪些地方与旧决定冲突，哪些仍然适用

Step 4：签字前，一定要核对引用

AI 可以准备材料，但决定权在你

问题 brief 给你的，是一个「带引用的快速答案」。在真正回复产品经理、客户或监管之前，最好亲自点开你要依赖的那几条引用。因为签字的人是你，不是 Claude。这个步骤既是风险控制，也是专业判断的体现。

AI Fluency 框架里，把这种「在关键节点回到原始证据」的习惯叫作「discernment（辨别力）」，它是区分「会用 AI」和「敢让 AI 参与关键决策」的分水岭。

四步核对关键部分

  • 找出问题重新打开了什么：先看 brief 里列出的「受影响的历史评审部分」。
  • 点开你要依赖的那条引用：每一条结论旁边都会有链接，指向原文的具体章节。
  • 读一遍原文关键句：确认 brief 的转述是否准确，有没有忽略限定条件或例外情形。
  • 做出你的判断：在确认引用无误后，再决定是否需要重新评审、补充说明或调整结论。

有一位合规负责人分享过，她刚开始完全信任 brief，后来在一次抽查中发现 AI 忽略了一个「仅限欧盟用户」的限定，从那以后就养成了「关键句必读」的习惯。

Step 5：回复、记录，并把闭环做完整

用连接器把决定送回团队日常工具

当你确认了答案，剩下的工作往往发生在别的工具里：回复消息、更新任务、记录决定。通过连接器，Claude 可以帮你把这些动作串起来：

  • 回复同事：接入 Gmail、Slack 等消息工具后，Claude 可以在原对话里起草回复，你只需要确认和微调语气。
  • 关闭请求：接入 Jira、Linear、Asana 等任务工具后，它可以自动在工单里记录你的决定、附上引用链接，并把状态改为完成。

有用户反馈，把这一步自动化后，遗漏更新工单的情况明显减少，后续追溯「当时是谁、基于什么做的决定」也更轻松。

Claude 在发送或修改任何内容前都会先征求你的确认，你也可以在一个提示词里同时要求「起草回复 + 更新工单」，减少来回切换。

风险与边界：别把它当「自动签字机」

需要提醒的是，Cowork 再好用，它也不是法律意见的最终来源。风险主要在两个方面：

  • 数据接入不完整时，brief 可能基于「不全的事实」给出看似完整的结论
  • 模型在转述复杂条款时，偶尔会弱化限定条件或适用范围

所以更稳妥的做法是：把它当成一个「极快的助理」，而不是「自动签字机」。关键节点回到原文、必要时和同事二次确认，反而能让 AI 的价值最大化。

不止法律：任何「要翻旧账」的岗位都能用

常见角色的应用示例

这套设置本身并不只适用于法律团队，只要你的工作经常要回答「我们之前怎么说的」「当时是怎么决定的」，都可以直接套用：

  • 客服与升级支持：上次我们给这个客户的承诺是什么？现在情况有什么变化？
  • 合规与风险管理：这次产品改动，会重新打开哪些历史合规评估？
  • 财务团队：上一版预算里，我们批准了哪些关键假设？新请求是否仍然符合？
  • 工程值班 / On-call：之前对这个系统的故障模式做过什么决定？这次告警是否属于已知场景？

一位支持团队负责人分享，他们用类似的 brief 技能后，二线升级工单的平均解决时间缩短了约 40%，因为「翻旧记录」这件事基本交给了 Cowork。

通用搭建公式：四步走

无论是法律、客服还是工程，搭建思路几乎一样：

  • 找到或创建一个技能，让它知道「决定记录在哪」以及「你习惯的阅读结构」——可以用现成插件，也可以直接用自然语言描述让 Claude 帮你生成。
  • 把它放进定时任务，让你每天开始工作前，重要事项已经被整理出来。
  • 遇到具体问题时跑一次 brief，拿到带引用的答案后，亲自核对关键原文再签字。
  • 用连接器把最终决定写回团队常用工具，让任何人都能在原始上下文中找到它。

这套判断和执行方法在不少团队里已经反复验证有效，值得你先收藏一份，等下次需要翻旧决定时直接照着用。

常见问题

Q：法律团队用 Claude Cowork 时，怎么降低合规和保密风险？

A：核心做法是「分级接入 + 最小必要权限」。先把 Cowork 接入到相对低敏感的数据源，比如公开政策、对外条款、内部知识库，再逐步扩展到包含客户数据或敏感合同的库。每接入一个新源，都要确认访问控制：谁能在 Cowork 里看到这些内容、是否需要审批才能读取。建议配合「Use Cowork safely」等官方指南，建立一份团队内部的使用规范，比如禁止在提示词中粘贴未脱敏的个人信息、对外邮件必须人工复核后才能发送。这样既能享受效率提升，又能把合规风险控制在可接受范围内。

Q：/brief 的输出结构不符合我们团队习惯，可以改成自己的模板吗？

A：可以，而且非常推荐这么做。你可以把团队现有的一两份「理想评审文档」或「最佳简报」交给 Claude，让它学习其中的结构和用语风格，再要求它重写 /brief 技能的输出格式。比如你可以指定「先给一句话结论，再列出 3 个关键风险点，最后附上详细引用列表」。改完后，用几个真实案例测试，逐条对照引用是否准确、结构是否好读，把发现的问题直接反馈给 Claude 让它继续微调。经过 2-3 轮迭代，/brief 通常就能稳定输出符合团队口味的模板化结果。

Q：如果历史评审文档很乱，Cowork 还能发挥作用吗？

A：能用，但效果会打折。历史文档分散、命名混乱时，/brief 在检索和引用上会花更多时间，也更容易漏掉关键材料。比较现实的做法是，先花一点时间做「轻整理」：把核心评审集中到几个固定文件夹，统一加上基础标签（产品线、地区、日期等），再让 Cowork 去读。你也可以让 Claude 帮你生成一个「整理计划」，比如按时间或产品线分批归档。整理本身就能提升团队知识管理水平，而 Cowork 会在这个基础上进一步放大价值。

Q：Cowork 给出的结论如果和我记忆中的不一样，该信谁？

A：优先信「有引用的原文」，而不是任何一方的记忆。遇到这种冲突时，先点开 brief 里的引用，确认原文到底是怎么写的，再回头看自己的印象是基于哪一次讨论或版本。很多时候，记忆里的结论来自早期草案或会议口头意见，而最终文档已经调整过。建议把这种「发现不一致」的案例记录下来，适当更新团队的工作方式，比如要求关键决定必须落在统一的文档库里，并在 Cowork 中优先引用这些「权威版本」。这样一来，下次再遇到类似冲突，大家就有共同的判断标准。

Q：非法律岗位值得花时间搭建这套 Cowork 工作流吗？

A：如果你的工作经常要回答「之前是怎么说的」「当时怎么决定的」，那就很值得。支持、销售、产品、工程 on-call 等岗位，都有大量「翻旧账」的场景，而这些场景往往既耗时又枯燥。搭建一次 /brief + 定时任务 + 连接器的组合，前期可能要投入一两个下午，但一旦跑顺，每天能省下来的时间和减少的沟通摩擦会非常可观。建议先从一个小范围试点，比如只针对某条产品线或某类客户请求，跑出效果后再逐步推广，这样阻力更小，团队接受度也更高。

如果你正被「翻旧决定」这件事拖慢节奏，不妨先按上面的步骤搭一个最小可用版本。等哪天你发现自己已经习惯早上打开的是一份整理好的简报，而不是一堆未读消息，大概就会庆幸当初多走了这一步。