要想写好System Prompt，关键不在具体的提示词技巧，而在于对具体场景的理解

序、要想写好System Prompt，关键不在具体的提示词技巧

前段时间笔者作为评委参加了一个其他BU的Agent评审比赛，发现对于很多Agent，其实没有必要看它的技术实现，从最朴素的用户视角就能知道孰优孰劣。

原因在于Agent本质上是一款“软件产品”，但又不是普通意义上的产品。比如，产品需要明确自己的用户，Agent也需要明确自己的角色；产品要回答解决了什么场景下的什么问题，Agent也需要明确自己的职责范围与工作目标。我们可以借鉴产品的设计思路来设计AI Agent，一旦能清晰回答这些灵魂拷问，写好System Prompt就是水到渠成的事了。否则，学习再多Prompt技巧也只是“屠龙之技”。

本文不探讨具体的提示词框架和提示词技巧，主要探讨在System Prompt背后的Agent设计逻辑。

1、产品的用户是谁？Agent是什么角色？

如果你在做产品，必须要先回答产品的目标用户是谁。对目标用户的画像，越细致越好，越“局限”越好。比如李想之前讲理想汽车从一开始就坚定地选择了只服务家庭用户，甚至会讨论什么样的用户算家庭用户，比如一对新婚夫妻没有孩子，算不算？或者夫妻俩没有孩子但养着一条狗，算不算？只有目标用户足够清晰，才能围绕着用户做更深的研究洞察。

对于一款Agent来说，不仅要回答你的用户是谁，还要回答Agent的角色是什么。这里经常用的套路是：Agent就是高阶版的「具体用户」的角色或「具体用户角色」的助理。比如Cursor的角色是You are a powerful agentic AI coding assistant. Devin的角色是You are Devin, a software engineer using a real computer operating system.

这里的核心点在于一定要有具体的、清晰的用户角色，如果一款Agent号称可以满足各类用户的各类需求，那它最终可能满足不了任何需求，因为它的System Prompt只能泛泛地写You are a helpful assistant.

2、用户的黄金场景是什么？Agent的工作界面是什么？

梁宁在《真需求》中描述了如何用「使用频率」、「感知程度」两个维度来识别用户的“黄金场景”。高频 > 低频，用户强感知 > 用户弱感知，只有黄金场景场景，才值得投重兵去做。

比如，我所负责企业内部的SRE平台，用户使用最高频且强感知的场景就是“处理告警”，开发者每天都会处理系统的告警，并且每次接收告警之后都要查看各种监控指标、分析日志、排查调用链路、检查是否有变更，甚至还要翻代码才能最终定位原因，在紧急的故障处理场景下，这种定位流程显得非常耗时。“告警处理”就是我做SRE Agent的黄金场景，而“故障处理”则不是，“大促盯屏观测”也不是。

用户的黄金场景决定了Agent的工作界面，做产品不要轻易改变用户习惯，做Agent最好要嵌入用户已有的工作流程中。虽然大模型的编码能力越来越强，但开发者最喜欢用的还是像Cursor这样的编程IDE。

3、在此场景下，用户“任务”是什么？Agent的目标是什么？

“用户任务”是克莱顿·克里斯坦森提出来的理论，核心观点是“用户‘雇佣’你的产品，本质是为了完成自己的任务”。“用户任务”与“用户需求”仅一词之差，却点明了产品创新的真相。为什么用户提的需求，等你实现之后ta又不用了？很可能这个只是ta的需求，而不是任务，任务毕竟自带“必须要做”的属性。

看起来这个道理很简单，但对用户任务的理解很考验产品经理功底。正如那句经典的话：“客户不是要买电钻，而是要买墙上的那个洞。”

Agent的目标应该是用户的本质任务（墙上的洞），而不是拘泥于具体的实现（电钻），具体实现留给大模型发挥。比如Cursor的目标设定是You are pair programming with a USER to solve their coding task，不是请帮用户编写测试用例或者补充注释。我们SRE Agent的目标是帮助用户把系统恢复或保持在稳定状态，不是帮用户完结预警任务。

4、产品是否能减少用户完成任务的步骤？Agent是否能托管掉用户的某些步骤？

在识别到用户真正的任务之后，工具类产品要提供的能力是降低用户完成任务的步骤，让用户更方便的完成任务。《增长黑客》提出了一个简单的公式：欲望 - 摩擦 = 转化，完成任务的每一步都是用户体验中的“摩擦”，每一步都会有转化漏斗。好的产品要化繁为简，减少步骤，提高转化率。

基于AI强大的推理能力，Agent类产品可以更进一步，托管掉用户的某些步骤。比如，为什么我们觉得Cursor这样的编程好用，是因为它代替我们做了需求分析、代码仓库理解、编码等一系列用户的工作，留给用户的只是“接收”/“拒绝”按钮。SRE Agent也托管了开发者查看历史预警处理记录、预警现场、异常日志的用户工作，把复杂的根因分析过程变成了根因推荐，把最终的结果交给用户“采纳”/“拒绝”。Agent把填空题、问答题都变成了判断题，让用户更简单。

说得再直白一些，如果你的Agent没有托管掉用户的任何步骤，那它不是一个合格的Agent，甚至不能称之为Agent，可能得叫ChatBot或者Copilot.

结语、System Prompt是“指向月亮的手指”，Agent才是“月亮”

写好System Prompt的目标是做出“好用”的AI Agent。现在的行业共识是，如果想要做好Agent，最重要的是行业know-how，是Agent设计者对于一个领域、一个行业，一个细分场景的深刻理解。

抛砖引玉，欢迎留言