30 秒看懂
对 Claude Code 团队来说,验证意味着让智能体能够运行并实际操作它修改的软件,而不只是通过现有测试。Anthropic 的 Boris Cherny 和 Cat Wu 描述了一个会点击桌面应用、修复问题并再次检查的智能体,以及收集漏洞报告并准备修复方案的定期任务。他们还解释了自动模式如何使用另一个模型评估权限请求,以及团队如何针对攻击进行测试。两人都倾向于减少对新模型的预设指令,同时让它们自行获取所需上下文。
- 1验证意味着运行真正的软件Cherny 将智能体验证与现有的单元测试、代码规范和类型检查区分开。他介绍了如何让 Claude 运行自己构建的功能并测试其行为。
- 2桌面技能教 Claude 点击操作应用Wu 说,Claude 会运行本地桌面应用,操作新界面并测试边缘情况,修复问题后再次检查。遇到环境问题时,她会让它调查并更新技能。
- 3定期任务查找无人处理的漏洞报告并提出修复Wu 介绍了一位工程师设置的任务,用来监测语音模式报告。另一个任务会接手五小时内无人回复的漏洞报告,并准备修复方案,供工程师验证和合并。
- 4自动模式通过另一个模型处理权限决定Cherny 说,他使用自动模式,避免亲自盯着大多数权限请求。两位嘉宾表示,分类器会拒绝可疑操作,用户之后可以选择允许。
- 5团队用对抗性提示测试自动模式Wu 说,团队让系统对数千条智能体轨迹和权限提示进行分类,再利用红队及内部攻击尝试建立评估并改进系统。
- 6两位嘉宾倾向于提供精简上下文及获取更多信息的方式Cherny 和 Wu 说,他们只给当前模型必要的指令和工具,让它们自行获取更多上下文。Wu 认为上下文过多可能变成事无巨细地干预。
要点建议
- 让智能体能够运行修改后的产品并操作其界面,包括测试边缘情况,再接受其工作。
- 把反复出现的错误及修复方式记录到项目指令或可复用技能中,让智能体以后使用这些经验。
- 用定期任务收集问题并准备修复方案,由人合并那些容易验证的修改。
- 把自动权限分类器当作需要评估和对抗测试的安全系统,而不仅是减少弹窗的手段。
- Cherny 和 Wu 倾向于提供模型必要的上下文和获取更多信息的方式,而不是规定每一步。
按章节阅读整理后的全文
从早期编码辅助到智能体验证
Cherny 介绍如何记录错误的经验,以及如何让智能体测试自己的工作。Wu 解释了一项能够运行并点击操作应用的桌面开发技能。
Boris Cherny 和 Cat Wu 回忆了 Claude Code 的早期发布:发到 Slack 的一段短视频只收到了几个回应,当时工具只能处理简单的工程任务。Cherny 说,一年后,他可能同时让许多智能体工作,或者让智能体向其他智能体发送提示。
Cherny 说,当 Claude 犯错时,他会让它把经验记录到 CLAUDE.md 或创建一项技能,而不只是纠正那一次尝试。他说,团队也认识到了验证的重要性。
Wu 问如何让验证真正有效。Cherny 将它与单元测试、代码规范检查和类型检查区分开,这些现有检查已经比较容易自动化。他说,对智能体而言,问题是它能否运行并实际操作自己构建的东西;要做到这一点可能需要有意识地进行设置。
Cherny 回忆说,他曾让使用 Opus 4 的 Claude 构建一个功能,并在 shell 中自行测试。它打开了一个 Claude 命令行会话来测试该功能。他说,团队现在为移动模拟器和桌面计算机建立了类似循环,但当时这种行为让他感到意外。
Wu 说,她正在开发桌面应用,并使用一项开发技能教 Claude 运行本地版本。如果预发布环境出现问题,她会让 Claude 去 Slack 查看是否存在故障或已知问题,然后用学到的内容更新该技能。
这项技能会启动桌面应用,使用计算机控制功能点击操作新界面、测试边缘情况,修复问题后再次检查。Cherny 说,他重视团队的一点是,包括产品经理在内的不同岗位成员都会贡献代码。
更多角色参与写代码,定期任务处理报告
两位嘉宾介绍了设计师和产品人员直接进行代码修改的情况。定期任务可以监控问题、准备修复方案并帮助维护拉取请求。
两位嘉宾说,当 Claude 能够编写代码时,创意以及产品、业务、设计和用户背景就变得更加重要。Cherny 回忆,最初看到设计师提交代码变更时他感到意外,后来发现代码写得不错。Wu 说,设计师和产品经理可以直接制作原型或修改应用;财务和数据科学同事也使用 Claude Code。
被问及哪些用法正在挑战能力边界时,Wu 提到了定期任务。一位推出语音模式的工程师设置了任务,监测工单、GitHub 问题和漏洞报告;Claude 会准备修复方案,并把拉取请求发给他。
Wu 说,这位工程师还为其他反馈设置了定期任务。她曾推出一个遗漏了边缘情况的功能,随后自己的 Claude 告诉她,另一个 Claude 已经修复了漏洞。工程师告诉她,他的任务会接手五小时内无人处理的报告,而他会合并那些容易验证的修复。
Cherny 说,定期任务让 Claude Code 的程序化使用变得更加具体。他提到这些任务能帮助进行代码审查、跟踪拉取请求、回复评论、修复持续集成问题和变基修改。
自动模式及其安全检查
Cherny 说,他目前的工作流更喜欢使用自动模式。Wu 介绍了团队如何评估权限决定,并针对对抗性尝试测试系统。
被问到在命令行中使用哪些功能时,Cherny 说他过去偏爱计划模式,现在则使用自动模式。按他的经验,新模型处理他的工作不再需要单独的计划步骤,尽管有些人仍重视计划产物。自动模式让他启动一个智能体后就能转向另一个。
此前的权限模式要求人逐一批准工具调用。Cherny 和 Wu 说,自动模式会把请求转给另一个模型进行安全判断;可疑操作可能被拒绝,用户之后可以选择允许。他们认为,这有助于人们把注意力放在影响重大的请求上,而不必反复批准常规操作。
Cherny 强调持续开展安全工作,包括红队测试、渗透测试和针对提示注入等攻击的威胁建模。他说,正是对这些工作的信任,让他能够在处理另一个智能体时放手让当前智能体运行。
Wu 说,团队首先收集了数千份智能体记录和权限提示,让自动模式对其安全性进行分类。随后,团队请红队和内部团队尝试提示注入及其他攻击,用这些尝试建立评估,并改进系统以捕获它们。
Cherny 说,他起初怀疑通过另一个模型处理权限提示是否可行,但看到结果后改变了想法。他认为,在模型之上构建产品需要不断重新审视过去工程工作中形成的假设。
围绕智能体重新思考工作
Cherny 比较了直接向智能体发送提示和通过定期任务代人发送提示的方式。两位嘉宾还讨论了业务流程变化以及产品和工程角色的重叠。
Cherny 说,循环和定期任务代表了他工作方式的又一次转变。起初,他从自己写源代码转向让智能体编写;现在,他有时会向循环或定期任务下达指令,再由它代自己向 Claude 发送提示。
被问及工程组织如何变化时,Cherny 回忆了一个关于个人电脑的商业案例:要获得生产力收益,需要围绕电脑重新设计流程,而不是仅仅在纸质工作流旁放一台电脑。他认为 AI 的采用同样会改变流程,但由于工作已经数字化,且 Claude 会使用计算机和编写代码,转变可能更快。
Cherny 说,Claude 已融入 Anthropic 的各项工作:员工向它询问入职问题、用它编写和审查代码,并用 Cowork 处理表单。他说,这让他有更多时间构思和与客户交谈。
Wu 问未来属于产品经理还是工程师。Cherny 认为这些角色正在融合:产品、开发者关系和设计同事会写代码,而工程师也可以从一个想法出发完成实现,并与法务、营销和安全团队合作发布。
用更少预设上下文管理多个智能体
Cherny 介绍了桌面、手机和远程控制工作流。他和 Wu 倾向于使用精简指令并提供获取上下文的方式,同时承认工具仍将继续变化。
Cherny 介绍了自己如何从六个终端标签页、每个标签页一个独立检出目录,转向使用智能体视图和管理 worktree 的桌面应用。他说,如今约有一半的工程工作在手机上完成:他用远程控制查看智能体,或在对话激发新想法后启动一个新智能体。
谈到上下文工程,Cherny 说,只要当前模型能够自行获取上下文,精简的系统提示和工具就能让它工作。Wu 称自己是上下文极简主义者:她更愿意告诉模型必要信息,让它自己找到路径,而不是提供过多信息、事无巨细地干预。
Wu 说,团队也在精简支持软件,为用户提示留出更多空间。Cherny 预计,运行时间更长、更自主的智能体会需要新界面,但他还不知道具体是什么样。他预计,想法会来自团队及其用户社区。
同频道的其他文章
16:17EN → 简体中文
10:38EN → 简体中文
12:19EN → 简体中文
33:46EN → 简体中文
17:50EN → 简体中文
34:42EN → 简体中文