Claude Code系统提示词精简80%:模型越强,越需要给AI松绑

引言

近日,Anthropic Claude Code团队成员Thariq Shihipar在一场播客访谈中,分享了一个有趣的数据:他们将Claude Code的系统提示词精简了80%。背后的逻辑颇有意思——模型越智能,其实越不需要那些条条框框。

这场对话围绕AI Agent如何从被动接受逐句指令,演变为能够长时间自主运行、自我纠偏的工作流机制展开。本文提炼了其中的核心观点,enjoy~

从提示词到自主编排:让Agent跑起来

在谈及AI Agent从接受一次性提示词转向自主运行编排机制时,Thariq指出,循环是一个相当宽泛的概念,指的是让AI Agent获取反馈,或者以精心编排的方式长时间工作。Claude Code团队为此设计了 /loop、/goal 以及工作流三种机制。

其中,/goal 的作用非常像给Agent吃了颗“定心丸”。它的作用是帮助AI Agent记住其退出条件——只有条件满足了,才允许它停止运行。当处理一项复杂任务并且必须确保最终百分之百完成时,/goal 就显得尤为关键,可以防止Agent中途“摆烂”。

如果现实中交给你一项任务,遇到复杂状况后你可能会停下来询问是否继续。而 /goal 就是在传达一种态度:我已做出充分的说明和探索,你只管执行,遇到问题自行解决。

Thariq认为,工作流可能是这些机制中最为强大的形式。用户可以借助工作流启动多个子AI Agent并行处理任务并相互验证——这对于非技术类工作尤其有效,是将非确定性任务拆解为确定性任务的绝佳方式。

他以设计工作举例:如果设计稿是Figma文件,可借助Figma MCP运行 /goal,确保最终渲染出的设计与源文件匹配,这远比如仅提供一张截图来得容易。但如果只有截图,就需要构建更灵活的工作流,设定评估标准并配备专门负责验证的子Agent。

实战演示:一句提示词跑通视频剪辑全流程

Thariq现场演示了一个具体的例子。他向Claude Code下达的提示词是:这是一个针对该播客的代码仓库,其中有一个示例视频,请使用Whisper对其进行转录,然后使用Remotion创建界面,显示逐字高亮的字幕以及不同的悬浮遮罩,并配合 /goal 指令,要求Agent直到视频完全渲染完毕才能停止。

仅通过一次提示词,Agent便完成了语音转录、文本遮罩、字幕和悬浮遮罩的生成。这很好地展示了Claude Code处理非创意类工作之外、同样拿手的“非技术类杂活”的能力。

不过Thariq也坦言,目前还没将其固化为一项技能——因为在转化为技能之前,得先弄清自己到底想要什么。比如遮罩位置需要更精准地追踪手部或手指方向,后续可能需向Agent提供更多元数据,才能制作出更有趣的动态遮罩效果。

与此同时,他还演示了另一项并行任务:要求Agent参考Peter Yang博客的视觉风格,创建一个HTML工件,用于探索悬浮遮罩与字幕的不同设计变体。他坦言自己并非设计师,往往只有亲眼看到成品才能判断是否符合预期,这也是他偏好采用“探索式规划”的原因。

规划的本质是“消除未知盲区”

Thariq提出了一个核心观点:规划并非人们通常理解的那种“制定计划→执行→结束”的一次性动作,而是一个不断探索、调查、发现未知盲区并明确自身需求的迭代过程。

他以视频转录项目为例:在动手前,他要求Agent解释Whisper的工作原理并列出各类边缘情况。Agent反馈说,静音片段可能被误识别为“感谢观看”之类的文字、一个单词可能被拆分成两个片段、系统不具备说话人识别能力等等。提前掌握这些局限,帮他避免了费尽心思搭建复杂工作流、运行后才发现漏洞百出的局面。

他也指出一种常见的失败模式:提示词输入框很容易变成一个“偷懒按钮”——用户只需输入指令便可让Agent去干活,人们对AI生成的计划和说明文档也往往敷衍了事、一扫而过。但如果希望认真完成一项工作,却在每一步都想偷懒,最终往往会付出更多时间乃至更高成本的代价。

完整的流程应当是:从人类需求出发,Agent进行技术探索并反馈,团队据此制作原型以厘清未知,再完善需求重新交给Agent执行。执行过程中,要求Agent记录实施笔记,发现出乎意料的情况后重新调整规范。这不再是单向交接,而是一个反复沟通的动态过程。

Claude tag与多Claude协作:让Agent融入团队工作流

Thariq谈到,团队内部很大比例的并行工作是通过Claude tag完成的。多Claude协作本质上是指所有在后台运行的任务——过去可能需要在Claude Code中同时开启五个不同会话,如今基本只需保持一个活跃的Claude Code会话,外加一批在Claude tag中运行的会话即可。

Slack是Anthropic团队日常办公所在的平台,Claude要想成为一个主动融入现有工作流的Agent,选择团队已有的协作工具是一条自然的路径。已经有部分团队成员几乎完全在Claude tag中完成全部编程工作。

在Claude tag中,每个频道都拥有各自独立的记忆——可以理解为每次被标记的其实是不同的Claude,它们在Slack中拥有各自的身份。团队更希望让模型本身的能力将协作模式引向何处,而非过早为其设定僵化边界。

工作流实战:用子Agent拆解短视频切片

短视频切片是工作流应用的典型场景。比如需要从一段长视频中生成十个甚至更多的短视频切片时,可以指令主Agent决定从哪些片段提取,随后由工作流为每个片段衍生出一个子Agent去执行,并提供一套评估标准,让每个子Agent对照标准进行验证。

这样每个切片都能获得充分的算力投入。若把两三个切片交给同一个Agent同时处理,验证质量往往会打折扣。

搭建工作流的操作很直接:要求Agent创建若干视频切片、使用工作流机制、提供验证标准即可。这套工作流本质上只是一个JS文件,可以被封装为可复用技能保存下来。

工作流相比单一技能的核心优势有两点:保持上下文清晰,克服模型的惰性以加强结果验证。Thariq将后者的原理归结为“自我偏好偏差”——当一个模型评估自己的输出时,验证标准会不自觉地变得更宽松。因此,一套健壯的工作流往往需要三个各自独立的角色:统筹的主Agent、执行的子Agent、以及负责验证的Agent,三者拥有各自独立的上下文窗口。

系统提示词精简80%:模型越智能,越需要更少约束

Thariq分享了团队近期的一项重要判断:随着模型能力不断增强,Claude Code已经将系统提示词精简了80%。原因在于,模型越智能,其实际所需的指导、约束和示例就越少。

此前团队的系统提示词中包含大量关于bash工具用法的细节说明,附带五个示例,并强调在某些情况下“绝对不要”使用该工具。但如今模型的对齐程度已经相当高,给出具体示例反而会限制其发挥——模型会默认用户期望的结果必须与示例完全一致;去掉这些示例后,模型表现反而更加自由灵活。

他进一步指出,硬性约束条件本身也会成为一种限制。当用户要求Agent“绝对不要”做某件事时,实际想表达的往往并非绝对禁止,而是“大多数情况下不建议这样做”。相比直接下达禁令,向Agent说明不希望这样做的原因,效果会更好。

基于这一判断,他建议用户持续精简上下文内容——当前许多 claude.md 文件可能已经偏长,不少技能中的代码篇幅也可能存在冗余。总体而言,模型往往只是需要更多的自主发挥空间。

提示词写作方法:用原则代替硬性规则

在技术文档写作中,好的系统提示词讲究“授人以渔”而非“授人以鱼”。Thariq以撰写社交媒体文案举例:与其硬性规定字数上限并列出种种“不要做”的禁令,不如为Agent提供关于任务背景与写作原则的上下文——说明团队性质、列出希望遵循的若干原则。

字数限制这类硬性规则固然仍不可或缺,但完全可以只交代任务性质、让Agent自行把握篇幅节奏。比如告知Agent“倾向于用精炼的表达方式,但如果分成多条内容形成系列会有更好效果,也可酌情采用”——相比生硬的字数限制,这种方式给了Agent更大的自由度去寻找更优的呈现方式。

由此,话题延伸到如何在编程能力已近乎被AI解决的当下,仍能持续提升个人技术理解力。Thariq认为,变得更懂技术的核心目的,是为了认识到自己“未知的未知”。了解不同后端服务之间的权衡取舍、各类视频加密库的运作方式、本地与远程视频转录方案的差异——这些认知远比精通某门语言的语法本身更有价值。

他习惯去学习系统的边界——哪些事是可行的、系统如何运作、能力上限在哪里。如果主动要求,Claude通常能帮助用户进行头脑风暴并教会这些知识;但前提是用户必须主动逼迫自己去探究,这也是学习过程中最困难的一环。

访谈最后,Thariq表示团队接下来的许多规划都将围绕Claude tag展开。他理想中的人机协作状态,应当像团队里一位能力极强的员工——你不需要事无巨细地微观管理,只需在Slack上标记任务、说明需求,或是像随口路过同事工位提出几个问题一样,便能自然获得回应。