Claude Cowork怎么用：从三份资料交接一份可复核报告

Claude Cowork怎么用，关键是把“帮我做个报告”改成一项能验收的任务：报告给谁看、支持什么决定、只能使用哪些资料、缺信息时怎样停下来。交代清楚这些，比不断追加“再专业一点”更有用。

本文用一个虚构的社区维修活动资料包，完整走过简报、任务计划、证据审核和交接。示例报告由作者编写，用来展示验收方法，不声称是某个账号实际运行Cowork后的结果。

先找到你账号里的实际入口

官方入门帮助将Cowork用于多步骤知识工作。具体入口随套餐和逐步发布而变化：有的账号显示Chat/Cowork切换，有的已合并到同一体验。请以当前帮助和自己的界面为准，不照搬旧截图，也不要因为没有开关就直接判断不能用。

下面的练习不依赖特定连接器。只用三份虚构文本材料，是为了先学会定义任务和检查输出。换成真实工作资料时，先确认材料适合提供给相关服务，不必一上来连接整个工作区。

适合委派的目标是“为是否再办一次活动准备决策简报”，而不是“管理整个社区项目”。后者混合了持续职责、对外沟通和授权，一句话很难说明白。

三份资料，保留真实的信息缺口

假设图书馆举办了一场周末小物维修活动，协调人要讨论下个月是否继续。

数字都是虚构练习输入，不是实际活动成绩。它们足以支持“继续讨论缩小规模”，却不足以支持“活动非常成功、大家都满意、下次排队会更快”。

下载资料包、任务简报和审核表。保留S1–S3编号，报告旁边就可以直接写来源。中途改文件名也要更新对应表，不能让证据引用变成猜谜。

用结果描述任务，而不是堆形容词

先说明读者和用途：给协调人讨论排期用的一页简报，不是可以发进微信群或公众号的公开预告。输出应区分观察、解释、缺失信息与附条件的建议。

可以使用这份原创提示：

仅根据S1–S3，为活动协调人准备决策简报，讨论是否支持下个月重复活动。事实旁标注来源编号。不推断满意度、修复成功率、排队时长或志愿者可用性。列出确认排期前必须回答的问题。只返回待审核草稿，不联系任何人、不发布内容。

再补充结构：一段建议、证据表、两个可行选项和待确认问题。结构让验收稳定，但不必把每句话都写死。

不要同时要求“给唯一确定答案”和“不要任何保留条件”。资料本身有缺口，删除保留条件只会让读者失去必要信息。简洁并不意味着假装确定。

先审核计划，再看漂亮的报告

这项任务可以拆成读取三份材料、提取事实、检查冲突、起草选项、组装简报。实际使用时，看看计划有没有悄悄变成联系志愿者、搜索私人文件或整理无关目录；这些已经超出本练习。

在图上画三条泳道：协调人、Cowork任务、复核人。选资料和确认排期放在协调人一侧，提取和起草放在任务一侧，核对事实放在复核人一侧。缺输入时回到补资料，别只写一个“继续处理”的循环。

打开泳道图模板，把角色换成这三类，再填入你自己的交接问题，例如“房间最多容纳多少人”“谁确认下次值班”。这样留下的是能分工的工作图，而不是一句抽象的AI流程。

作者示例：先核对关系，再按自己的任务修改模板。

把泳道图改成你的版本

从可编辑的示例开始，替换文字、移动图形，整理成你自己的内容。

编辑这份泳道图

无需注册即可开始编辑。

固定的审核步骤可以进一步组织成可复用规则，见Claude Skills案例。但本次活动事实应放在当前任务资料里，不要永久写死进技能。

完整示例：怎样审核一段建议

作者编写的合理示例是：

建议在确认房间容量和志愿者可用性后，再讨论小规模重复活动。S1记录18人到场、12人带来待检查物件，并未说明修复结果。S2指出接待拥挤，S3说明可用房间变小，应先调整接待安排，再确认下一次日期。

第一句保留前提；第二句不把“带来物件”变成“修好物件”；后两句提出需要讨论的安排，没有假设已经证明了因果。

反例可以故意写成：“本次活动满意度很高，12件物品全部修好，下个月继续并缩短等待。”这是作者编写的错误示范，不是模型输出记录。

复核时可以双向走查：报告里的每个重要事实是否有来源；来源里的关键限制是否进入报告。逐句没写错，也可能因为漏掉小房间这个条件而误导决策。

给出能接手的交付说明

交接要写清哪些内容现在可用、哪些仍需决定。保留报告名称、来源目录、审核状态和开放问题。只说“报告完成”容易让别人把草稿当成已批准计划。

本例可以交接为：“草稿可开始核对事实；房间容量和志愿者排班未确认。适合用于内部排期讨论，不适合直接作为活动公告。”

请复核人至少从每份来源抽查一条事实，不要只看开头。资料更新时给报告一个新版本，记录变化影响了哪项结论、由谁接受修订。不能修改场地说明后，仍把旧建议标成已批准。

Cowork和Claude Code怎么选

先看工作环境和最终产物。本例需要的是资料包、报告和编辑审核；代码任务则需要仓库、命令、代码变更和技术检查。两者也会交叉，例如通过脚本整理表格后再写报告。

不要因为工具会写代码，就把每份报告都做成软件项目；也不要因为界面面向文档，就不检查计算和生成文件。无论选哪种工具，验收标准都应保留。

真实任务若需要连接器，应另外记录它能读什么、能执行什么。连接成功不等于允许发消息或更新记录；“准备建议”和“执行建议”仍是不同动作。

常见错误与修法

一次塞入整个资料库。 旧版本和无关信息容易混进结论。先选当前任务需要的材料，出现具体缺口时再补。可参考上下文工程筛选案例。

看到引用就默认正确。 要打开原文核对含义，确认引用支持的是这句话，而非只提到相同主题。

把草稿和对外行动混在一起。 准备建议与公开宣布活动要分别定义，尤其要写明收件人、发布渠道和批准人。

只说“再改好一点”。 指出具体错误、来源和修订要求，才能避免好段落反复变化、错误事实却一直保留。

接手的人再查三件事

使用草稿前，协调人应确认：事实句可追溯吗，建议保留房间和人员条件吗，下一项决定交给能决定的人了吗？这些没确认，草稿就继续保持审核状态。

若要改成公开邀请，应另写任务简报，补确认日期、地点、参与办法和可用咨询或报名入口。直接把内部报告当公告，会改变受众与后果。整理文件同样要明确：只返回草稿，还是建立审核文件夹？移动原资料可能破坏其他人的引用，实际需要时才单独列入动作。

用到自己的下一项任务

选一个近期确实需要作出的决定，替换练习里的活动，保留来源编号、可接受的未完成结果和责任交接。需要更详细的失败状态设计，可以继续看Agentic Workflow案例。目标是把一块能检查、能使用的工作交出去。