从交代一个函数，到交付一个目标

Claude Code 是帮助开发者完成编程工作的 AI 工具。访谈还介绍了 Claude Tag——团队正在使用和开发的 Slack 原生智能体。Slack 是团队沟通工具；Claude Tag 在这里接收任务，也能查阅产品讨论和团队已经做出的决定。

一位成员估计，自己约 70%—80% 的工作发生在 Claude Tag 里，剩下的一部分会打开终端界面或桌面应用精修。这是他的个人用法，但足以说明一个变化：对话的入口已经进入团队日常协作的地方，交给 Claude 的问题也远远超出了“实现这个类”或“写这个函数”。

产品为什么这样设计，团队曾经放弃过哪些方案，某个决定背后有什么约束，这些信息往往不在代码里。只有代码库时，模型可能知道“怎样做得出来”；加上讨论和决策背景，它才更有机会判断“怎样做符合这个团队的目标”。

人的关注点也随之改变。过去，他们会仔细看每次工具调用和模型的每个决定；后来，更多时候是提出一个目标，等 Claude 带回结果。比如，“实现我指定的修改”把方案留给了人；“改善用户完成这个流程的情况”则把分析现象、提出方案和比较选择的空间也交给了 Claude。

委派到目标这一层，对智能体的要求更高。它要取得背景、组织工作、运行产物，还要把结果带回来，让人有依据决定下一步。团队随后讲到的工具变化，正是在为这种工作方式补齐条件。

目标变大，辅助工具也要随模型改变

团队遇到的一个特殊问题是，工具依赖的模型能力变化很快。受访者形容，过去一项技术可能稳定使用多年，现在底层能力大约每两个月就有一次明显变化。工具开发既要解决今天的困难，也要判断哪些困难可能很快消失。

待办清单就是一个例子。在 Sonnet 3.5 附近的时期，他们发现模型处理长任务容易遗漏：交代五件事，可能做完三件就停。增加清单后，表现有了改善。后来，模型能力和可用的记忆状态发生变化，成员认为原来那种清单已经不再那么必要。

这里有一条持续变化的链条：先发现模型的具体失败，用工具补上；模型进步后，重新检查这个补偿机制是否仍有价值；接着把任务扩大，又会遇到新的协调和状态管理问题。工具需要跟着问题变化，不能把每一代模型的补丁一直累加下去。

团队把围绕模型组织工具、状态和执行过程的系统称为 harness，可以理解为让模型完成工作的运行框架。删掉过时机制，也是在为新的任务形态腾出设计空间。

提问方式的演化展示了另一种变化。最初，成员希望 Claude 在制定计划后向用户提问；后来，这变成了模型可以自行调用的 AskUserQuestion 工具，当时还需要仔细设计接口，才能让模型用好。随着能力提高，Claude 又能直接生成 HTML 产物，把图示、界面原型和问题放在一起。

例如，讨论界面方案时，人可以对着可见的原型作决定，减少双方仅凭文字想象不同界面的情况。原来固定的提问界面，开始成为 Claude 可以按任务生成的产物。权限管理、可视化和提问等基础能力仍然重要，但它们可以组合成不同的工作方式，上层产品不必固定在早期的形态。

要持续推进，先让工作离开笔记本

目标扩大后，执行往往会跨越一次对话或一次上班时间。团队讲到循环任务时，先提了一个朴素的障碍：智能体跑在笔记本上，离开办公室、合上电脑，工作就停了。

他们先使用远程开发机器，解决了必须一直开着笔记本的问题；但连接远程机器、重新进入相应工作环境仍有摩擦。后来，Web 上的托管容器提供了更方便的入口，让开发环境在远端持续运行。

这里要解决两件不同的事。第一件是任务能否持续运行；第二件是 Claude 在那个环境里能否真正完成开发。仅把代码放到远端还不够，它还需要启动软件、访问必要依赖、运行测试，并检查从开始到结束的完整流程。

Robert 在谈到用 Claude Tag 开发 Claude Tag 时，就把主要精力放在打通这些条件上：尽量让智能体拥有开发者完成工作时所需的环境和端到端测试能力。软件依赖的集成越复杂，这项准备越费力，也越影响智能体最后能独立推进到哪里。

环境稳定后，指令才容易成为一项持续责任。例如，每天检查收到的反馈，按重要性分类，再处理其中有较高把握的问题。这样的循环跨越多次执行，不需要人每次重新发起同一个任务。

一位成员把搭建远端环境后的个人生产力感受形容为约十倍提升；访谈没有提供测量方法。可以借鉴的具体做法是，把运行环境也当成委派工作的一部分来建设：目标需要哪些动作，就让 Claude 具备完成那些动作的条件。

任务更复杂，让 Claude 自己组织工作流

复杂目标还有一个独立的难题：工作怎样分解。团队以代码审查为例：先让多个智能体从不同方向探索潜在问题，再针对每个候选问题进行多角度复核，最后筛选出值得人关注的重要项目。

这个流程的关键是先扩大探索范围，再逐层收敛结果。

访谈举的做法是，从三个角度重新审视一个候选问题，判断它是否真实存在。这样，开发者收到的就不只是大量疑似问题，还包括经过进一步分析和筛选的发现。多角度复核能帮助降低误报，最终判断仍要有证据支持。

他们把求解时增加推理和计算投入称为 test-time compute。这里增加的是当前任务的分析工作：多找一些方向、多做几轮复核，再把额外工作转化成更有用的结果。

更进一步，Claude 连工作流本身也可以设计。人提出问题后，它可以决定需要哪些代理、哪些方向并行展开、前一层输出怎样传给下一层，以及最后如何汇总。随后，它再写代码，把这些代理连接起来执行。委派范围由此从单项分析扩展到了分析工作怎样组织。

代码和模型在其中承担不同职责。程序循环负责对每个项目执行同一套步骤，减少“说好检查五项却只检查三项”的遗漏；模型负责每一项里面需要理解和判断的内容。程序能帮助维持流程的一致性，每项分析是否正确仍要另外判断。

这套方法也能用于普通研究。团队举了带父母去 Tahoe 旅行的例子：住宿、活动等方向可以分别搜索，再经过筛选、核对和汇总。最后的收敛很重要，否则并行工作只是把更多零散材料交给了人。

代码审查中，人的注意力也随之上移。Claude 可以先处理细碎问题，人则更值得看接口为什么这样设计、服务边界为什么划在这里，以及实现是否符合团队的产品意图。这又回到了开头的上下文问题：局部代码看起来合理，不代表它符合整个系统的设计理由。

少盯每一步，把协作建立在可检查的结果上

工作流能在后台推进，人与智能体的界面也需要变化。Claude Tag 把日常消息与完整执行记录分开：发消息是模型可以调用的工具，它选择什么时候向人汇报、汇报什么；需要追查过程时，人可以打开完整记录的链接。

这让产品界面不必同步展示模型的每个输出和工具调用。受访者说，最初无法像以前那样盯着细节，会让人不安；后来，反复拿到好结果，又让这种工作方式变得轻松。界面变化推动他们练习另一种协作：围绕目标、待决问题和交付结果交流。

支撑这种信任的是具体的验证。Claude 提交代码变更时，会运行测试、发送界面截图。内部工具的开发者还让它录下自己操作终端界面的过程；看完录像后，他把代码拉到本地，亲自试用，确认自己喜欢实际体验。

这些反馈各有用途：测试帮助检查功能，截图让人看到界面状态，操作录像展示一段流程怎样完成，亲自试用则补上使用感受。开发者减少了逐步监督，仍然能通过交付物判断工作到了什么程度。

实现是否符合目标，还需要代码审查与真实使用反馈：前者帮助发现代码和设计问题，后者让团队看见工具投入使用后发生了什么。

把实现和反馈接起来，推进一个完整产品

访谈中最完整的案例，是一位成员开发一个需要多人支持的内部工具。他先让 Claude 找出应该与谁讨论这个想法、谁可能关心它，再制作界面原型。人在手机上通过 Slack 就能看原型、讨论具体方案，想法因此更容易进入下一步实现。

代码写出来后，还有一个新问题：工具是否真的被使用，使用者能不能走完流程？他在工具中加入事件记录，内部部署后让 Claude 持续观察使用情况，也关注同事的反馈，在需要时提醒自己加入讨论。

这条产品推进链中，每一步都为下一步提供了信息。

最后一个转折最有价值。开发者看到一些用户没有走完整个操作流程，原本想把自己的改法交给 Claude 实现。随后他改了提问方式：请 Claude 改善这个流程，先提出思路；自己的方案可以作为一个例子。

团队把这个流程称为“漏斗”：它指用户从开始使用到完成目标所经过的一系列步骤。知道用户在哪一步停下，只是分析的起点。把改善目标交给 Claude，意味着它可以结合现象寻找原因、比较方案，而不必从一开始就只执行开发者已经选好的答案。

相关同事、原型、实现、事件记录和反馈因此围绕同一个目标连接起来。测试与审查帮助检查改动，使用反馈又为下一轮选择提供依据。Claude 参与的范围从一段代码延伸到了产品的持续改进，人则在其中决定方向、处理重要问题并检查实际体验。

工程师也要更新自己能做什么的判断

工具在变，团队成员对自己工作的想象也在变。有人过去喜欢钻研性能优化，有人曾用一天时间精细复刻 macOS Aqua 按钮的 CSS 渐变。如今，他们更愿意把这些具体实现交给 Claude，把精力投入新想法，让原型更快走向可用产品。

一位成员还回忆，小时候因为不会编程，就用 PowerPoint 尝试做游戏。这个故事对应着一种熟悉的限制：有想法，却被自己不会的技术挡住。与 Claude 协作后，更多这样的想法可以被拆开、尝试并做成东西。人的能力边界，也需要随着工具能力重新估计。

迁移这套经验，可以从正在做的一项工作开始。先把目标和背景讲清楚，再补齐运行环境，让 Claude 参与设计工作步骤，并约定可以拿回哪些产物与反馈。

这些做法来自团队在自身环境中的实践，具体配置需要按自己的项目调整。更值得持续练习的是，同时更新两种判断：哪些工作可以交得更完整，哪些旧的工具和习惯已经值得重新设计。