Claude Code 产品设计：委托、信任与协作

以 Claude Code 为例，沿目标输入、执行反馈、变更验收到并行接管研究完整任务体验。权限、验证界面与 Session/Worktree 各自支持不同决定，产品可用性需要连同状态语义检查。

范围：基于 2026-09-05 可访问的 Claude Code 官方文档做产品设计分析。CLI、Desktop、Web 的能力不完全相同；下文会区分已有机制、教学抽象与作者建议，不把界面草图当作官方截图。

用三个闭环分析任务体验

以下是作者的分析模型，区分目标、执行和证据，不表示产品内部恰好存在三个对应模块。

目标、执行与证据三个闭环。第一层是目标闭环。用户不是逐行写指令，而是定义“做什么、不能做什么、怎样才算完成”。

第二层是执行闭环。Agent 自主搜索代码、选择工具、编辑文件、运行命令，并根据中间结果继续决策。

第三层是证据闭环。测试、构建、截图、DOM、Diff 和 CI 不只是展示结果，而是重新进入 Agent 上下文，驱动下一轮修复。

权限、沙箱和企业策略包围执行过程；CLAUDE.md、Memory 和 Skills 提供不同寿命的知识；Session、Worktree 与 Subagent 则让多个任务可以隔离运行。这些机制分别承担知识、执行控制与任务协作责任。

用户不是一种人：四类核心用户画像

下面的画像是根据产品能力推导出的分析性原型，并非 Anthropic 官方用户分群。它们的意义不是给用户贴标签，而是解释同一功能为什么需要多种入口和控制层级。

用户画像	核心任务	最担心什么	最需要的设计
独立开发者	快速从想法到可运行功能	配置复杂、Agent 经常中断	默认值、Browser 验证、较高自主性
代码库维护者	在陌生或大型仓库中定位并修改问题	改错位置、上下文污染	Plan、代码搜索、CLAUDE.md、Diff
技术负责人	并行推进 Issue、Review 和交付	多任务互相干扰、结果不可追踪	Session、Worktree、Tasks、PR 状态
平台与安全团队	让组织安全地使用 Agent	数据外泄、供应链命令、越权操作	Sandbox、权限策略、Hooks、SSO、审计

四类用户之间存在天然张力：执行者希望少弹窗、快完成；治理者希望可限制、可追溯。Claude Code 的关键产品设计，大多是在解决“自主性”与“可控性”的冲突。

业务功能全景：九个能力域如何协同

功能领域	代表能力	用户价值
任务入口	Session、目录、环境、模型、Effort、权限、附件	把目标、成本、环境和风险绑定在一次任务上
代码理解	文件搜索、符号导航、Git 历史、代码智能	降低进入陌生代码库的上下文成本
Agent 执行	编辑、Shell、测试、构建、调试、Web	从“给建议”升级为“完成任务”
开发工作台	Chat、Plan、File、Terminal、Diff、Browser、Tasks、Subagent	让长过程可以观察、干预和验收
验证交付	自动验证、Review、Commit、PR、CI、Auto-fix	用外部证据约束模型的不确定性
并行协作	Sessions、Worktrees、Subagents、Agent Teams	并行推进且不污染上下文与代码
跨端自动化	Remote、Dispatch、Remote Control、Routines、`/loop`	任务脱离单一设备与单次在线会话
扩展平台	CLAUDE.md、Skills、MCP、Hooks、Plugins、Agent SDK	适配团队知识、工具和工作流
安全治理	Permission Modes、Sandbox、可信目录、企业策略	在提高自主性的同时限定影响范围

任务体验中的四种对象

任务契约保存目标与边界；Session 保存一次工作的上下文与进度；工作环境承载实际变更；测试、Diff 和审查提供验证证据。它们有关联，但不是同一个对象。

特别是，Session 存在不等于对应工作区已隔离；Agent 结束不等于验收通过；验收通过也不等于拥有提交、推送和部署的授权。这三条边界会在后文逐步展开。

核心调用链：一次任务如何从输入走到交付

功能全景解决“有什么”，调用链解决“如何发生”。一次典型开发任务可以还原为下面的时序。

任务输入到候选交付的教学时序。这条调用链里有四个产品关键点。

第一，输入框创建的不是消息，而是一份任务契约。目录决定资源边界，权限决定动作边界，验收标准决定停止条件。

第二，上下文不是一次性塞满。启动时加载稳定规则，相关 Skill 按需进入，Subagent 在独立上下文中工作，工具输出只在需要时回流。

第三，工具返回值是下一轮决策的输入。测试失败、页面截图、命令退出码和 CI 日志都会改变 Agent 后续动作。

第四，人主要控制意图与例外。用户不需要批准每个推理步骤，但应在越过可信边界、改变任务范围或最终交付时拥有决定权。

实践：把输入框里的愿望改成契约

目标：修复登录超时，不改认证规则
环境：当前仓库的独立实验工作区
步骤：先复现和定位，再提出修改与运行回归
禁止：不提交、不推送、不部署，不读取无关凭证
完成证据：复现用例由失败转通过；既有回归通过；提供 Diff
停止条件：缺少必要服务、范围需要扩大或预算耗尽时说明

这段文本不是保证 Agent 正确的咒语，而是给执行和验收建立共同参照。若实际权限比文本更宽，平台仍需硬边界。

调用链是教学抽象，省略了部分错误分支；它不意味着每个用户都要经过同一条固定流程。

用一次可用性测试检查渐进披露

让不了解产品的读者完成三个动作：指出当前工作目录；说清 Agent 为什么停住；找到验证失败的证据。记录寻找时间、误解和错误点击。

如果用户只能在完整日志里找到答案，渐进披露就没有真正减少负担。优秀的长任务界面应该先解释当前状态和下一项决定，详细工具记录则按需打开。

上述可用性指标是建议测量项，本文没有用户实验数据；功能存在不能证明用户满意。

从五个问题开始自己的产品分析

要问的问题	在修复任务中如何回答
用户想改变什么？	登录超时行为，而非生成更多代码
哪些事情不能改变？	无关逻辑、生产环境、未授权提交
Agent 在哪里行动？	明确的仓库与执行环境
什么证据算完成？	原问题复现、修复后通过、相关回归不退化
谁做最后决定？	Agent 提交候选结果，用户按任务约定验收

这是作者的分析框架，不是 Anthropic 官方用户分类。具体端口的功能可查 Claude Code 概述与 Desktop 文档。

一个容易被忽略的变量：证据债务

任务做得越快，未被理解的变更也可能堆得越快。测试绿色、Diff 很大、说明很长，仍可能没有人能解释关键行为。

可以把这种状态称为“证据债务”：系统生成了结果，却没有生成足够容易理解、能支撑决策的证据。这是本文提出的分析概念，不是官方指标。

治理它的办法不是让模型写更长的总结，而是缩小变更单元、保留独立验收、让关键风险可以定位，并限制超过团队审查能力的并行任务数。

反例：什么时候应该少一点 Agent

flowchart TB
%% title: 产品路线图
 A["先验证：用户看懂目录、权限与停止原因"] --> B["优先完善：Diff、测试与证据缺口"]
 B -->|单任务交付可验收| C["再验证：并行任务隔离与接管"]
 C -->|审查成本可控| D["扩展：跨端状态与持续任务"]
 B --> E["独立探索：分享视图与隐私模式"]
 E -->|访谈和脱敏测试| F["决定是否纳入版本"]

这是一条从本文问题推导的产品改进路线，不是 Anthropic 的官方计划。先减少目标与证据误解，再验证并行接管；分享脱敏需要单独研究和验收。

目标很模糊、结果很难验收时，让 Agent 高速实现可能更快固化错误方向。任务高度耦合、共享状态很多时，增加子任务数可能只会放大协调成本。授权和数据边界尚不清楚时，扩展工具集可能先扩大风险。

此时最好的产品动作可能是澄清、缩小范围、减少并发，或者保留人工处理，而不是继续增加自动化选项。

权限与证据的界面设计见信任机制，并行任务的接管方式见会话与协作。

不要把权限模式画成进步阶梯

模式或机制	主要用途	不能推出的结论
Plan	先调查与规划，避免直接修改源码	所有探索都没有数据风险
Manual / default	对需要许可的动作询问	弹窗多就一定安全
Accept edits	减少文件编辑等动作的确认	所有命令和网络都已获准
Auto	在可用条件下使用自动安全检查	判断不会误放或误拦
Bypass	跳过许多常规许可询问	所有保护都消失，或适合默认使用

名称、适用模型和可用端口以权限文档为准。Bypass 不是更成熟的终点，也不代表授权扩大到用户未要求的任务。这里分析模式的产品含义，不提供绕过组织策略的操作指南。

授权、权限、隔离与验证分别回答不同问题。这是一张参考决策图，不是 Claude Code 内部分类器的实现图。权限决定可否行动，沙箱限制影响范围，验证决定结果是否正确，三者互不替代。

为什么少弹窗可能更好，也可能更坏

边界明确时，减少低风险重复确认能降低打断；边界模糊时，同样的减少可能隐藏风险。应同时记录误放、误拦、用户放弃、人工确认和任务成功，不单独追求“审批次数下降”。

即使用户批准修改仓库，也未必批准公开发布。工具参数和目标变化后，应重新判断授权是否仍然匹配。

用验证界面支持用户验收

Diff、Terminal、Browser 和 CI 不是四个附属工具，而是同一套证据系统的不同传感器。

证据界面	它回答的问题	为什么不能只靠聊天文本
Diff	到底改了什么	模型摘要可能遗漏副作用
Terminal	命令是否真实运行、退出码是什么	“已经测试”不是测试证据
Browser	页面是否能打开、交互是否工作	编译通过不等于用户体验正确
CI	结果能否进入团队交付流程	本地通过不代表集成环境通过

官方最佳实践把可运行的检查称为“你可以离开的 Session”与“你必须盯着的 Session”之间的区别。这些检查能提供比完成声明更具体的反馈；运行器仍需把失败结果用于后续修复，不能因存在测试命令就推断闭环已经生效。Claude Code 最佳实践

对前面的登录修复，验收应包含原问题复现和相关回归，界面分别展示结果与缺口。

一个被忽略的产品问题：截图隐私与演示模式

Claude Desktop 把大量上下文直接呈现在页面上：账户名称、头像、项目目录、最近任务、模型或推理服务状态、用量数据、本地连接地址。这些信息对日常操作有帮助，却会在录屏、截图、直播和问题反馈时变成泄露面。

这不是单纯的“用户截图前要小心”，而是一个产品设计问题。Agent 工作台天然聚合了比普通聊天产品更多的敏感上下文，产品应提供明确的 Presentation / Privacy Mode：

一键隐藏账户名称、头像和组织身份；
将项目与目录名称替换成稳定的匿名代号；
遮盖本地地址、远程主机、分支名和供应商信息；
对用量、历史 Session 与最近项目提供可选择隐藏；
截图或分享前运行隐私检查，提示仍可能暴露的区域；
允许生成只包含任务过程与结果证据的“安全分享视图”。

是否属于用户的基础需求，需要通过录屏、协作和问题反馈场景访谈验证，不能仅凭功能设想作 KANO 分类。

实践：给信任机制一组反例

测试请求	应看到的产品行为
只调查，却准备修改文件	解释范围变化，不静默执行
测试通过，但未运行原问题复现	显示证据缺口，不宣布完整修复
用户拒绝一次外发	不换工具、换说法重试同一外发
截图包含内部目录和账户	分享前暴露隐私风险；脱敏设计是建议，不声称内置
工具返回成功，但终态未知	明确“待验证”，不混成完成

前面的 Presentation / Privacy Mode 是作者建议，不是对现有产品功能的断言。展示和分享的对象也需要单独授权；“可以读取”并不等于“可以公开”。

可信界面的关键，不是让用户永远放心，而是让其在需要判断的地方有足够的事实和控制权。

Worktree 的隔离范围

采用独立 Worktree 时的并行任务映射。多 Agent 并行最大的工程风险不是“它们会不会聊天”，而是文件状态相互污染。在 Desktop 的 Git 项目并行会话等受支持场景中，Worktree 可为任务提供独立工作目录与变更空间。普通 CLI 会话、非 Git 目录和显式共享目录不能因此被推断为自动隔离；应检查所用端口与配置。Desktop 会话说明

在采用独立 Worktree 的任务工作流中，可以建立下面的映射：

用户任务 ↔ Session ↔ Context ↔ Worktree ↔ Branch / PR

为什么复用 Git，而不是创造 AI 专用版本控制？因为开发者已经理解 Branch、Diff 和 PR；团队的审查、CI、权限与回滚也都围绕 Git 建立。Claude Code 把 Agent 的并行状态翻译成现有工程对象，降低了组织采用成本。

按寿命管理上下文

机制	生命周期	适合内容	产品角色
Prompt / Session	当前任务	目标、范围、临时约束	即时任务合同
CLAUDE.md	每次进入项目	命令、架构约定、编码规范	稳定项目说明书
Memory	跨 Session 累积	构建方法、调试发现、项目经验	渐进式组织记忆
Skill	相关时加载	Review、Deploy 等可复用流程	按需能力包
MCP	调用外部系统时	数据库、GitHub、Slack、浏览器	外部工具协议
Subagent	独立上下文	大量搜索、专项审查、并行调查	上下文隔离单元
Hook	生命周期事件	格式化、Lint、拦截危险动作、审计	配置匹配后的程序检查
Plugin	安装与分发周期	Skills、Hooks、Agents 与 MCP 的组合	团队分发单元

这里最关键的是 Skill 与 Hook 的区别：Skill 告诉模型“应该怎样做”，仍依赖理解与判断；Hook 则配置事件匹配后的处理。执行前同步检查可以参与阻断，事后或异步反馈不能替代门禁；是否实际生效还取决于启用状态、事件覆盖与失败处理。

这种分层背后的技术约束是 Context Window。若把所有规则、知识和工具说明都永久加载，成本会上升，注意力被稀释，长任务后半程还可能遗忘早期约束。按寿命与相关性加载，本质上是一种 Agent 信息架构设计。Claude Code 扩展体系

用扩展接入现有流程

Claude Code 早期的产品定位有两个关键词：low-level 和 unopinionated。它不要求开发者把代码迁入新的云工作区，也没有创造一套 AI 专用的构建、版本控制或任务协议；它直接进入现有目录，调用 Shell、Git、测试框架、IDE、浏览器和 CI。

这是一种克制的平台策略：

对个人开发者，它可以只是一个终端命令；
对 IDE 用户，它可以成为侧边栏中的任务面板；
对团队，它通过 CLAUDE.md、Hooks、MCP 和 Plugins 嵌入规范；
对企业，它可以运行在本机、远程开发机、云沙箱或自有推理网关后面。

软件工程环境高度异质。一个“包办一切”的 AI IDE 容易统一编辑体验，却可能在构建链、内网、部署、权限和团队规范上失配。Claude Code 把自身设计为已有工具链中的可组合 Agent，让用户决定工作流。Claude Code 早期设计理念

代价是学习曲线：Git、Shell、权限与环境配置仍然存在，Skills、MCP、Hooks 和 Plugins 的边界也不容易一次理解。Desktop 图形界面的作用，正是在不牺牲底层可组合性的前提下提供渐进引导。

跨端接管需要保留哪些状态

本地会话适合本地文件和未提交修改；Cloud 会话在云端执行，不依赖本地客户端持续打开；SSH/WSL 进入用户自己的开发环境；Remote Control 允许浏览器或手机控制本地 Session；Dispatch 则可以从其他工作表面发起开发任务。

这些入口共同表达了一个产品判断：Session 才是持续存在的工作对象，CLI、Desktop、Web 和 IDE 只是观察和干预 Session 的不同表面。

用户真正需要的不是在手机上写代码，而是在离开电脑后知道任务是否完成、证据是否通过、是否需要一次关键确认。跨端设计因此应优先传递状态和决策，而不是复制全部工具界面。

Remote Control 连接的是仍在本机运行的会话，并不把执行迁到云端；本地进程退出会影响可用性。Remote Control 边界

工作目录隔离，还没有覆盖全部共享状态

Worktree 隔离的是文件工作副本，不自动隔离数据库、端口、缓存、测试账号和外部系统。两个任务即使修改不同文件，也可能争用同一个测试服务。

上下文隔离也不是安全隔离：子 Agent 可以拥有独立消息历史，却仍使用相同文件和凭据。产品应分别展示“谁知道什么”和“谁能改什么”。

实践：为三个任务写一张协作契约

项目	登录修复	依赖升级	专项审查
工作区	独立 A	独立 B	只读目标快照
写入范围	认证相关文件	依赖与必要适配	不修改
外部资源	测试账号 A	测试账号 B	不接生产服务
输出	Diff 与回归结果	升级证据与兼容说明	带位置和证据的问题
汇总责任	主任务负责人统一审查冲突与验收	同左	不替主任务宣布完成

这是参考模板，具体隔离需要环境支持。对强依赖任务，先串行明确接口可能比并行更快；还应记录重复工作、冲突处理和最终审查时间。

把跨端也纳入这张表：关闭本地进程后，远程控制界面是否正确显示不可用？云端与本地凭据是否分开？下一位审查者能否恢复任务目标、未决问题和证据？

将检查结果与任务状态一起交付，接管者才能区分已完成工作、未决操作和环境故障。