Claude 合并聊天与 Cowork｜文档幻灯片直接出成品

Anthropic 把 Claude Cowork 与聊天合并成了一个统一的 Claude，不必再判断一项任务该归到哪个入口，Cowork 与 Design 的能力可以在任意对话中使用。对做接入的一方而言，这不是一次界面微调，而是端点模型、产物模型和权限模型同时发生了变化——我按接入架构把它拆开讲，配上下面的请求流图示、Python 代码与成本风险清单，顺手把 4sapi（https://4sapi.com）网关侧要跟着改的地方一并标注清楚。

一、开篇痛点：入口分裂把判断成本推给了调用方

同一件事该从哪个入口开始，本来是产品替使用者做的决策，却被推回给了使用者。Cowork 原本是处理更大任务的独立空间，Design 是处理视觉工作的独立空间，两者都用的人很快就撞上同一堵墙：一项任务到底该归到哪个空间，而且在一个空间里起了头的工作，没办法顺着延续到另一个空间里去。

做接入的一侧感受更直接。每多一个空间，就多一套鉴权、限流、计费口径和产物存储；调用方还得先替业务判断"这算聊天任务还是 Cowork 任务"，判断错了就得整段重来。真正昂贵的不是多写几行适配代码，而是判断逻辑被硬编码进了业务层：入口一改，业务层跟着改。

合并之后这件事的性质变了。入口收敛成一个，判断归 Claude：由 Claude 判断任务需要什么，能力可以在任意对话中使用，并且带着已有的上下文、技能与连接器。做接入的一方从"维护多个入口"变成"维护一条路由"。

二、合并动因：能力被空间切开，上下文也被空间切开

把两个空间并成一个，动因并不复杂。Cowork 面向更大的任务，Design 面向视觉工作，两个空间各自成立、各自好用，问题出在交界处：既写文档又要出幻灯片的任务，天然横跨两边。使用者不得不先决定起点，再在中间人工搬运上下文——把文档里的结论复制到另一个空间，把设计稿里的版式搬回对话里。

搬运的代价有三层。第一层是判断成本，每次都要猜任务归属，猜错了要重做。第二层是上下文成本，跨空间意味着重新交代背景，重新挂技能与连接器，token 花在重复说明上。第三层是一致性成本，两个空间各自产出，报告改了第三版而幻灯片还停在第二版，只能靠人眼比对。

现在的做法是把这三层成本收回到 Claude 一侧：由 Claude 判断任务需要什么，能力在任意对话中可用，上下文、技能与连接器随对话走。对做接入的来说，这等于把"入口选择"从业务逻辑里删掉了一整个分支。

三、单端点 + 能力路由：新的端点模型长什么样

老的端点模型是三条并行的线：聊天一条、Cowork 一条、Design 一条。每条线自己一套请求形状、一套返回、一套产物落点。调用方要选线，还要在选错之后承担返工。

新的端点模型是一条线加一层路由：请求只有一个入口，路由的输入是任务描述、已有的上下文引用、挂载的技能与连接器，输出是本次要动用的能力集合与产物形态。文档与幻灯片同日推出的 Claude Docs 与 Claude Slides，以及现在也能直接在对话里使用的 Claude Design，都是这条路由后面的能力，而不是需要单独寻址的系统。

这张表里最值得盯的是最后一行。入口收敛降低了接入复杂度，但把风险从"配置错误"换成了"运行时行为"，风险的位置从部署阶段挪到了每一次请求里。

四、请求流图示：从统一入口到产物落地

单端点路由的请求流大致是这样一条链：

统一入口（单端点，一套鉴权与计量）
        |
   意图与产物判定（Claude 判断任务需要什么）
        |
        +--> 需要文档   --> 文档能力：可协作撰写、可编辑、可导出 PDF
        +--> 需要幻灯片 --> 幻灯片能力：可起草、直接在对话里演示、可下载 PowerPoint
        +--> 需要视觉稿 --> 设计能力：仍可单独使用，设计稿照旧工作
        |
   装配已有上下文 / 技能 / 连接器（随对话携带，跨产物一致）
        |
   按审批密度执行：默认先问后做，或持续工作、必要时才来问
        |
   产物写入同一个可分享链接（手机可打开）
        |
   指标回传：token 用量、产物版本、审批记录、连接器调用

这张图上有三个位置需要额外留意。判定层的输入质量决定路由准确率，任务描述含糊时 Claude 会追问，追问本身是消耗 token 的；装配层决定上下文膨胀的幅度，一次对话里连续产出文档与幻灯片，上下文只增不减；审批层决定自动化任务能不能在无人值守时启动。

五、产物变成对话的中间产物，而不是独立系统的产物

旧模型里，文档是文档系统的产物、幻灯片是幻灯片系统的产物，对话只是下达指令的通道。新模型把关系倒了过来：对话是主对象，文档、幻灯片、设计稿都成了同一次对话的中间产物。

这个变化带来的第一个直接结果是天然一致。文档与幻灯片出自同一次对话，所以幻灯片与报告内容一致——改一处结论，两边读到的是同一份原文，不存在"报告已更新、幻灯片还停在上一版"的漂移。

第二个结果是产物可继续被编辑。内容存放在一个可分享链接里，手机上也能打开；可以选中某个元素移动它，也可以直接告诉 Claude 想改什么。产物不是导出的终点，而是对话中可以继续操作的节点。

第三个结果是导出变成了一种出口而不是终点。可以直接编辑、从 Claude 中直接演示，或下载为 PowerPoint 或 PDF。导出这一步不切断对话与产物之间的关联。

对做接入的来说，产物模型变了，存储与审计的设计也得跟着变：产物的身份不再是某个系统里的一个文档 ID，而是"某次对话 + 某个版本"的组合，审计要能沿着对话回溯到具体产物版本。

六、Docs、Slides、Design 的能力边界与共存

这三项功能都处于测试阶段，面向付费套餐开放。能力边界需要说清楚：Claude Docs 与 Claude Slides 在同一天推出，Claude Design 现在也能直接在对话里使用，可以让 Claude 一起写文档、起草幻灯片。单独使用 Claude Design 仍照旧工作，也就是说，视觉工作不需要迁就对话形态，独立入口还在。

Enterprise 管理员可以自行决定何时启用。这一条对做企业接入的非常关键：能力存在不等于能力生效，组织内的启用时机由管理员掌握，接入方的灰度策略要和管理员开关对齐，而不是假定功能上线即全员可用。

从接入视角看，这三项能力共享同一套路由之后，接入方要做的不再是"为每项能力写一套适配"，而是"为每类产物定义一套验收标准"。文档的验收看结构与引用，幻灯片的验收看页数与要点覆盖，设计稿的验收看版式与元素约束。

七、场景复盘：一份中午要交的周报

把能力放进一个具体任务里，链路会更清楚。一份中午要交的周报，出门前可以先问 Claude 上周流水线有什么变动，紧接着要求"按一贯写法写、标出延误、把要点做成五页幻灯片用于领导会议"。不清楚的地方 Claude 会追问，而不是自行猜一个答案。

路上可以用手机查看进度。到工位时，报告已经成了一份文档，里面还带着同事的批注，幻灯片也就绪，可以直接下载为 PowerPoint。两者出自同一次对话，所以幻灯片与报告内容一致。接下来可以自己改一行，在某一页幻灯片上留评论，再分享出去。

这条链路上有三个接入设计值得抄：一是产物与批注在同一处，文档的协作痕迹不需要额外同步；二是从对话直接演示，演示态不需要额外的导出步骤；三是分享粒度可以细到一页幻灯片上的评论，权限模型必须支持到元素级别，而不是整个文件的全有全无。

八、可自动化：每周一自动执行意味着什么

把这件事设为每周一自动执行之后，Claude 无需开口即开始写报告。这一条把前面的链路从"人驱动"改成"时序驱动"，接入侧的关注点随之改变。

人驱动的任务里，出错的兜底是人会看见异常；时序驱动的任务里，兜底必须写在系统里。要提前确定的是：自动执行时挂哪些连接器、能不能写外部系统、产物默认落在哪个分享链接、失败之后重试几次、重试是否会产生重复产物。审批密度在这里不是可选项而是前置条件，决定了自动化任务能走多远。

高级经济学家 Andrew Keller 的做法是可以直接参考的形态：让 Claude 调出法律研究数据库，拉取案例、逐一阅读、判断还需要哪些其他案例、下载并存入文件夹供人工审阅。整条链是自动的，但出口落在一个供人工审阅的文件夹里——自动执行负责跑量，人工负责判断，边界画得很干净。

九、审批密度可配：对生产接入的意义

默认情况下 Claude 会在执行操作前先询问。也可以开启"持续工作、只在需要仔细查看时才来问"的模式，最终决定权始终掌握在使用者手里。

这两档对生产接入的意义完全不同。默认档适合交互式场景：调用方在场，每一步确认的成本可以接受，风险最低。持续工作档适合批量与长任务：确认频次下降，吞吐上升，但审批点从"每一步"变成"少数关键步"，一旦关键步的判定失准，错误会连续放大。

落地时我按三条线划分审批点：一是写外部系统的动作，例如把内容推到外部数据库、发消息给第三方；二是改变分享范围的动作，例如把可分享链接从内部改成对外；三是不可逆的动作，例如删除既有产物版本。这三类走强制审批，其余动作在执行后回传记录即可。

配套的记录字段建议固定下来：任务标识、产物类型与版本、审批模式、审批点、连接器名称、执行结果。审批记录与产物版本绑定之后，事后追溯才有落点，否则只能看到"某天执行过一次"，看不出改的是哪一版。

十、教程：单端点 + 能力路由的 Python 接入示例

这套路由我在网关层做过简化版，思路是把产物判定、连接器白名单和审批密度拆成三个独立函数，方便分别回归测试。所有能力走同一个 OpenAI 兼容端点，能力路由在提示层与服务端完成。

import os
from openai import OpenAI

# 单端点：文档、幻灯片、设计能力走同一个 base_url，不再按入口分别寻址
client = OpenAI(
    api_key=os.environ["FOURSAPI_API_KEY"],
    base_url="https://4sapi.com/v1",
)

ARTIFACT_KEYWORDS = {
    "doc": ("文档", "报告", "周报", "说明书", "纪要"),
    "slides": ("幻灯片", "PPT", "演示", "五页", "汇报"),
    "design": ("设计稿", "视觉", "版式", "封面"),
}

# 连接器白名单：自动化任务在无人值守时只能碰这里面的资源
ALLOWED_CONNECTORS = {"shared_link", "workspace_docs", "legal_research_db"}


def route_task(task: str, skill_ids: list[str], connector_ids: list[str]) -> dict:
    """能力路由：先判定要什么产物，再决定挂哪些技能与连接器。"""
    artifacts = [
        kind
        for kind, words in ARTIFACT_KEYWORDS.items()
        if any(w in task for w in words)
    ]
    return {
        "task": task,
        "artifacts": artifacts,
        # 上下文、技能、连接器随对话携带，跨产物保持一致
        "skills": skill_ids,
        "connectors": [c for c in connector_ids if c in ALLOWED_CONNECTORS],
        "share_scope": "conversation",
    }


def approval_policy(mode: str, artifacts: list[str]) -> dict:
    """审批密度可配：默认先问后做；也可持续工作、仅在需要细看时来问。"""
    if mode == "continuous":
        return {
            "ask_before_act": False,
            "escalate_on": ["外部写操作", "分享范围变更", "删除产物版本"],
        }
    return {"ask_before_act": True, "escalate_on": artifacts}


def build_messages(plan: dict) -> list[dict]:
    lines = [
        "按一贯写法完成这份产物",
        "产物形态：" + "、".join(plan["artifacts"]),
        "标出延误项，并把要点整理成五页幻灯片",
    ]
    return [{"role": "user", "content": "\n".join(lines)}]


def run(task: str, mode: str = "ask_before_act") -> object:
    plan = route_task(
        task,
        skill_ids=["weekly_report"],
        connector_ids=["shared_link", "workspace_docs"],
    )
    plan["approval"] = approval_policy(mode, plan["artifacts"])
    trace = {
        "task_id": os.environ.get("TASK_ID", "adhoc"),
        "artifacts": plan["artifacts"],
        "approval_mode": mode,
    }
    return client.chat.completions.create(
        model=os.environ["DEFAULT_MODEL"],
        messages=build_messages(plan),
        stream=True,
        extra_headers={"X-Trace": str(trace)},
    )

三个实现细节值得强调。第一，产物判定与执行分离，判定结果是可测的纯数据，路由准确率可以单独回归。第二，连接器走白名单而不是黑名单，自动化任务只会碰到明确登记过的资源，未登记的一律拒绝。第三，密钥全部从环境变量读取，绝不写进代码与配置文件，网关侧对同一套请求标识做计量，对账时每一笔都能落到具体任务。

十一、迁移成本：主要用聊天的一侧几乎为零

迁移成本非常低，这一点直接决定了接入方要不要动手。主要用聊天的不必做任何改变；一直用 Cowork 的，对话、项目、artifacts、连接器与技能都保持原位，打开应用从上次停下的地方继续。

对已经有集成在跑的一方，这意味着不需要做数据迁移，也不需要改端点地址，需要改的是三处配置：产物落点从多个存储收敛到一个分享链接、审批密度从写死的确认流程改成可配策略、审计记录的粒度从"会话级"细化到"产物版本级"。

发布节奏也影响排期。功能率先面向 Pro 和 Max 套餐，在未来几周内通过网页版、桌面端与移动端应用向现有及新用户开放，无需开启任何设置；Team 与 Free 套餐很快跟进。多端同时开放意味着产物要在手机、桌面、网页三个形态下都能打开与编辑，权限模型必须与端无关，只与账号和分享范围有关。

十二、企业开关与 30 天通知期：合规窗口怎么排

Enterprise 套餐在组织内任何变更生效前，管理员至少提前 30 天收到通知。这条时间窗口是整篇里对合规排期最有价值的一条。

30 天可以拆成四段用。前 10 天做评估：把文档、幻灯片、设计三类产物的数据流画出来，确认哪些内容会进入对话上下文，哪些连接器会被挂载。中间 10 天做策略：定义审批点、连接器白名单、分享范围上限与产物保留期限。接下来 5 天做灰度：先在一个小组内启用，观察 token 用量、产物版本数与审批记录覆盖率。最后 5 天做回滚预案：确认关闭开关后，已生成的产物与分享链接如何处置，是否需要在关闭前批量导出。

这一段里最容易漏的是产物与分享链接的生命周期。功能可以关闭，但已经发出去的链接不会自己失效。合规窗口内必须回答清楚：关闭能力之后，存量产物保留多久、分享链接是否回收、审计记录是否继续留存。

十三、成本与风险清单

把上线前要盯的项摊开成一张表，逐项找到观测指标，比逐条背诵结论更有用：

成本侧要单独算一笔账：能力合并之后，同样的任务在一条对话里完成，省掉的是跨空间重复交代背景的那部分 token；但一次对话要连续产出文档与幻灯片，上下文只增不减，长尾请求的单价会上去。省钱与省显存不是同一个命题，最稳的做法是把单次对话的产物数量设为可配上限，超过上限就拆会话。

十四、上线前的验收清单

1. 同一句任务描述分别要求文档与幻灯片，确认两类产物出自同一次对话且内容一致。
2. 在含糊的任务描述下确认 Claude 会追问，而不是自行补全关键参数。
3. 切换审批密度两档，确认默认档在执行前询问、持续工作档只在设定点位询问。
4. 用一个未登记在白名单里的连接器发起调用，确认被拒绝且留下记录。
5. 从手机端打开分享链接，确认产物可见、可选中元素移动、可留下评论。
6. 导出 PowerPoint 与 PDF 各一次，确认导出不切断对话与产物之间的关联。
7. 检查日志与追踪头，确认密钥未出现在任何输出中，产物版本号可回溯。
8. 模拟自动执行任务失败重试，确认不会产生重复产物版本。
9. 核对账单与请求标识，确认单端点计量口径一致、无口径分叉。

十五、总结

Claude 把 Cowork 与聊天合并成一个统一入口，Cowork 与 Design 的能力进入任意对话，由 Claude 判断任务需要什么，上下文、技能与连接器随对话携带。对做接入的来说，端点模型从三条并行线收敃为"单端点 + 能力路由"，产物模型从独立系统的产出变成对话的中间产物，因此报告与幻灯片天然一致；审批密度可配，默认先问后做，也能持续工作、只在需要细看时来问，最终决定权留在使用者手里；Enterprise 管理员可自行决定启用时机，组织内变更生效前至少有 30 天通知窗口，这段时间正好用来排评估、策略、灰度与回滚四段动作。迁移几乎不用动数据，主要用聊天的无需改变，一直用 Cowork 的对话、项目、artifacts、连接器与技能都保持原位。风险集中在上下文膨胀、权限边界、产物版本与审计缺口四件事上，清单化的办法是一条条量出来。这套单端点加能力路由的接入方式我在 4sapi（https://4sapi.com）网关层跑通并配了观测面板，谁家业务里更适合拆会话还是开持续工作档，欢迎在评论区聊聊。