AI 工程化实战：如何像设计函数参数一样设计 System Prompt？

「系统提示词是每一个优秀AI应用的骨架。学会精确设计它们，构建一致、角色恰当的Claude集成。」

今天和大家讲一下系统提示词这件事。

先写个提示词，然后发布应用。接着用户问了个意料之外的问题，结果Claude像在读维基百科一样给出了回答。

这个问题不是模型本身造成的，而是系统架构设计上的问题。解决方案其实就在某个参数里，你可能压根没注意到它。系统提示词远不止是简单的设置，它是你的应用在用户说出第一个字之前，向模型作出的第一个承诺。

你没设计过的回应

Claude 默认运行在“通用助理性”模式中——因为你没给系统提示词。这情况平时看着还行，直到有一天你做了一个客服机器人，它居然开始推荐竞品了。

模型根本不知道你在做什么。它只知道你在对话开始之前告诉它的那些信息。

❝

「任何没有经过引导的回应，背后都藏着一个你留下的设计缺口。」

❞

没有明确的角色定义，模型的回应空间就是没有边界的——每一次调用都像在赌。

系统提示词到底改变了什么

系统提示词设定了所有回应的起点。它不是去限制模型的智能，而是去引导智能的发展方向。你定义什么，角色就是什么——包括它的边界，以及什么是可接受的回应。

数学 tutor 就是个典型的例子，教学方式的差别非常明显。没有引导的时候，Claude 直接帮你把题解完。而你只需要写三行提示词，它就会反过来问你：“要把 x 单独拎出来，这里应该用什么运算？”——然后耐心等着。

从一个只会给答案的机器，变成一个能陪你思考的伙伴，这个转变完全取决于你写下的那几行字。

❝

「模型并没有进化，它只是从一个被改变过的起点出发。」

❞

角色塑造的行为 vs. 泛化输出

模型没有明确的角色时，它会匹配统计上最常见的答案。结果通常勉强够用，但满足不了你应用的真实需求。

回应的有效性规则，会随着角色定义而变化。数学 tutor、法律摘要助手、客服机器人，它们是三个完全不同的角色，处理信息的方式也完全不同。

你不需要写一个巨长的提示词。三句清晰的话，效果几乎总是好过一段含糊其辞的规则。

没有系统提示词（泛化模式）：

有系统提示词：

❝

「清晰直接的指令，通常比冗长绕弯的规则更有用。」

❞

构建可复用的提示词，同时不丢失精度

第一种写法会产生维护问题，因为开发者必须在每次 API 请求里都带上系统提示词。更干净的写法是：把它当作一个函数参数——传进去，而不是硬埋在里面。

开发者容易卡在一个细节上。Claude 的 API 要求系统提示词是真实的数据字段，所以开发者必须在函数边界做条件注入——而不是在模型调用里面搞。

这种分离也让测试变得更容易。你可以在不同测试用例之间随意切换系统提示词，而不用改动模型调用的逻辑。

❝

「把系统提示词当作一份契约来设计——而不是一段注释。」

❞

开发者最容易失控的地方

最常见的错误：写提示词的时候只描述 Claude 是什么，而不描述 Claude 该做什么。比如“你是一个有用的助手”——这句话对模型来说没有任何可操作的指令。

具体，才是最有力的工具。一句“永远不要直接回答——先问一个引导性问题”，效果比任何角色描述都强得多。

第二个常见错误：把边缘情况晾在那不管。如果你没告诉 Claude 用户跑题了该怎么办，Claude 就会按自己的节奏慢慢发明一个方案出来。

❝

「含糊的指令带来含糊的行为，从来没有例外。」

❞

做 AI 功能做久了就会发现：模型本身并不是一个完整的产品。你真正能控制的变量，只有你提供给系统的那个上下文。

系统提示词不是可选功能，它需要你刻意去设计。用户反馈的每一个异常行为，往回追溯，都能找到一个你没定义清楚的地方。