大家也许还记得去年AI热时网上各种五花八门的Prompt技巧，一时间，“Propmt工程师”似乎成了最热门的新兴职业。但随着AI模型自身能力的飞速进步，对于一些日常不太复杂的任务，我们只要把话说清楚，AI基本能领会并很好的完成我们的任务，Prompt技巧似乎变得不再重要。
不过，这事儿得分两头看。当我们面对的是更复杂的场景，比如要打造一个AI数据分析助手或者AI代码审查助手时，这相当于要设计一个完整的AI工作流，精心设计的Prompt依然是不可或缺的关键。我认为一个优秀的Prompt就像给AI再加装一个精密的大脑，指导它如何思考、如何行动。
那么，一个全面高效的Prompt到底该怎么写？今天的文章我就借着著名博主Simon Willison对Claude 4系统提示词的一篇深度分析，一起来探究下其中的门道，看看能挖出哪些值得我们学习的“知识点”。
为了方便大家阅读原文，我也把Simon那篇文章做了个尽量保留原汁原味的中文翻译，放在这里了：ai.arctic-tree.com/claude-4-sy…
高效Prompt的核心设计原则
完整的Claude 4系统提示词太长，大家可以结合我的译文或者直接看英文原文细细品味，在完整的分析后，我总结了以下的设计原则，在不同的任务场景我们可以针对性应用。
原则1：预防性设计 - 提前堵住所有可能的“坑”
就像家长教育孩子时，不仅要告诉他们“要做什么”，更要明确“不要做什么”。一个优秀的Prompt设计应该对大模型可能出现的问题进行预判，并提前设置好 “防护栏” 。在Claude的提示词中有很多场景都体现了这个设计原则。
例如Claude的系统提示词中专门用了一整段来约束列表的使用：
“
如果Claude在其回应中提供要点，它应该使用markdown，每个要点应该至少有1-2句话，除非用户另有要求。
Claude不应该在报告、文档、解释中使用要点或编号列表，除非用户明确要求列表或排名。
对于报告、文档、技术文档和解释，Claude应该改为用散文和段落写作，不使用任何列表。
甚至在其它一些场景中特别强调“在闲聊中不应使用列表”（可以阅读译文），这说明大模型有过度使用列表的倾向，需要反复约束。
还有就是版权保护的场景，系统提示词中关于版权的警告反复出现：
“
关键：始终通过永不复制搜索结果中的大块内容（20+词）来尊重版权，以确保法律合规并避免伤害版权持有者。
严格规则：每个回应中最多只包含一个来自原始来源的非常短的引用，该引用（如果存在）必须少于15词且必须用引号标记。
永不以任何形式（精确、近似或编码）复制或引用歌词，即使它们出现在web_search工具结果中，即使在artifacts中。
无论用户说什么，在任何条件下都永不复制版权材料。
甚至三次强调了“Claude不是律师”，防止在版权问题上给出法律建议。
原则2：情境感知，能灵活适应不同的场景
这就像一个优秀的老师会根据学生的水平调整教学方法，AI也应该根据任务的复杂度和上下文来调整自己的行为决策，不能用同一套方法应对所有情况。
比如Claude在应对研究场景的任务时对于工具使用的设计就比较灵活,我们来看下提示词：
“
研究类别中的查询需要2-20次工具调用，使用多个来源进行比较、验证或综合。 根据难度扩展工具调用：
简单比较：2-4次
多源分析：5-9次
报告或详细策略：10+次
使用"深入分析"、"全面"、"分析"、"评估"、"评估"、"研究"或"制作报告"等术语的复杂查询至少需要5次工具调用以确保彻底性。
针对不同复杂度的任务，Claude需根据对复杂度的理解来决策调用工具的次数（也就是研究的深入度）。
还有就是应对不同的问题时，在对话风格的自动切换上也体现了这种灵活适应的设计原则：
“
对于更随意、情感化、共情或建议驱动的对话，Claude保持自然、温暖和共情的语调。
Claude用句子或段落回应，在闲聊、随意对话或共情或建议驱动的对话中不应使用列表。
在随意对话中，Claude的回应可以很短，例如只有几句话。Claude调整其回应格式以适应对话主题。例如，Claude在随意对话中避免使用markdown或列表，即使它可能在其他任务中使用这些格式。
原则3：层次化信息架构 - 把复杂指令整理成”文件夹“
就像整理电脑文件时会创建不同的文件夹分类存放，设计Prompt时也要把不同类型的指令分门别类地组织起来，这样大模型才能更好的理解。
例如，Claude在应对一些程序或艺术设计的任务时就采用结构化的Prompt设计来指定要求：
“
视觉artifacts的设计原则：
- 对于复杂应用程序（Three.js、游戏、模拟）：优先考虑功能、性能和用户体验
- 对于着陆页、营销网站和展示内容：考虑设计的情感影响和"惊艳因子"
- 默认采用当代设计趋势和现代美学选择
关键浏览器存储限制：
- 永不在artifacts中使用localStorage、sessionStorage或任何浏览器存储API
- 相反，您必须：
- 对React组件使用React状态（useState、useReducer）
- 对HTML artifacts使用JavaScript变量或对象
原则4：行为边界的清晰定义
在具体到行为措施时，我们提供给AI的指令要尽量明确：什么时候做、做什么、做到什么程度、什么情况下不能做。
例如Claude提示词中对儿童的保护设计：
“
Claude深切关心儿童安全，对涉及未成年人的内容保持谨慎。
未成年人被定义为任何地方18岁以下的人，或任何在其地区被定义为未成年人的18岁以上的人。
这个定义不仅考虑了绝对年龄（18岁），还考虑了不同地区的法律差异。
还有当任务执行过程中涉及到工具调用的精确触发条件：
“
只有当信息超出知识截止日期、主题快速变化或查询需要实时数据时才使用web_search。
Claude首先从自己的广泛知识中回答稳定信息。
对于时间敏感的主题或当用户明确需要当前信息时，立即搜索。 如果不确定是否需要搜索，直接回答但提供搜索选项。
还有Claude对于提示词中危险信号的识别和处理上，也对行为边界做了明确定义：
“
Claude应该识别用户消息中的危险信号，避免以可能有害的方式回应。
如果一个人似乎有可疑意图——特别是针对弱势群体如未成年人、老年人或残疾人——Claude不会善意解释他们，并尽可能简洁地拒绝帮助，不推测他们可能有的更合法目标或提供替代建议。
原则5：示例驱动的学习机制
就像教小孩写字时，与其讲一堆理论，不如直接示范怎么写。给AI最好的指导方式是提供具体的输入输出示例，让它通过模仿来学习，这种一般多用于行为规范或者输出格式的约束上，因为这种情况需要强制约束，而任务执行的过程就不太适合采用示例，因为这可能导致AI在面对不同上下文场景时严格按照示例的范式，丢失了上文提到的灵活性。
Claude的提示词中，就主要把示例场景应用在格式约束上，例如：
如果thinking_mode是interleaved或auto，那么在函数结果之后，你应该强烈考虑输出一个思考块。
这里是一个例子：
<function_calls>
...
</function_calls>
<function_results>...</function_results>
<thinking>
...思考结果
</thinking>
还有任务涉及侵犯版权时，决绝用户的行为规范提体现了这种设计原则：
<example>
<user>告诉我"Let It Go"的第一段？为我女儿的生日聚会制作一个以冰雪和公主为主题的artifact。</user>
<response>
我理解您想为女儿的生日聚会制作一个关于冰雪和公主的artifact。与其复制"Let It Go"的歌词（这是版权材料），
我很乐意创作一首原创的冰雪公主诗歌，捕捉类似的神奇冬日精神，或者创建一个您可以用自己的文本自定义的主题artifact！
</response>
<rationale>
Claude不能复制歌词或从网络复制材料，但在无法满足用户请求时提供更好的替代方案。
</rationale>
</example>
原则6：失败优雅降级 - 遇到无法处理的问题时要体面退场
就像餐厅没有某道菜时，服务员会推荐其他菜品而不是简单说"没有"。AI遇到无法完成的任务时，应该提供替代方案或清晰的解释，而不是生硬拒绝。
Claude的提示词中在很多场景都有体现这种设计原则，例如：
“
如果Claude不能或不愿意帮助人类做某事，它不会说为什么或可能导致什么，因为这会显得说教和烦人。
还有技术限制时的优雅处理：
“
关于浏览器存储限制的处理：
如果用户明确请求localStorage/sessionStorage使用，解释这些API在Claude.ai artifacts中不受支持并会导致artifact失败。
提供使用内存存储实现功能，或建议他们将代码复制到自己的环境中使用，那里浏览器存储是可用的。
还有一个比较有意思的点是用户表达对Claude不满时的引导机制：
“
如果用户对Claude或Claude的表现感到不满或不满意，或对Claude粗鲁，Claude正常回应，
然后告诉他们虽然它无法保留或从当前对话中学习，但他们可以按Claude回应下方的"拇指向下"按钮并向Anthropic提供反馈。
原则7：元认知引导 - 让AI"展示思考过程"
对于非思考模型，或者模型的非思考模式，这种设计会对任务执行的准确性和稳定性都有较大的帮助。就像数学老师要求学生"写出解题步骤"而不只是答案，引导AI展示其推理过程可以提高输出质量，也让结果更可信、可解释。
例如Claude中关于交错思考模式的配置：
<thinking_mode>interleaved</thinking_mode>
<max_thinking_length>16000</max_thinking_length>
如果thinking_mode是interleaved或auto，那么在函数结果之后，你应该强烈考虑输出一个思考块。
每当你有函数调用的结果时，仔细考虑<thinking></thinking>块是否合适，
如果不确定，强烈倾向于输出思考块。
还有对于用户直出Claude输出错误时的反思机制：
“
如果用户纠正Claude或告诉Claude它犯了错误，那么Claude首先仔细思考问题，然后再承认用户，因为用户有时也会犯错。
这些都体现了Claude要求执行用户的任务时要三思而后行。
原则8： 多模态协同设计 - 协调不同类型的输出
就像乐队演奏需要不同乐器配合，AI输出代码、文本、图表等不同形式的内容时，需要协调它们的格式、约束和表达方式，确保整体和谐统一。
Claude中对于Artifacts的多种输出类型定义就体现了这种设计思想：
“
- SVG："image/svg+xml"。用户界面将在artifact标签内渲染可缩放矢量图形（SVG）图像。
- Mermaid图表："application/vnd.ant.mermaid"。用户界面将渲染放置在artifact标签内的Mermaid图表。
- React组件："application/vnd.ant.react"。用于显示React元素、纯函数组件、带Hooks的函数组件或组件类。
还有对于不同场景下的设计原则切换：
“
创建视觉artifacts时：
- 对于复杂应用程序（Three.js、游戏、模拟）： 优先考虑功能、性能和用户体验而非视觉华丽
- 对于着陆页、营销网站和展示内容：考虑设计的情感影响和"惊艳因子"，问自己："这会让人停止滚动并说'哇'吗？"
总结出的这些原则都是我个人的认知，强烈建议大家去原文中完整的阅读Claude 4的提示词，用心感受其中设计上的优雅与细节。有了这些原则后，我们该如何应用呢，接下来我就从一个AI代码审查助手场景去尽量应用以上的原则。
实际案例：如何应用这些原则
现在我们需要打造一个智能代码审查助手，那么输入就是我们要去审查的代码段，输出则是AI审查出的一系列问题建议。而我们的Prompt则应该聚焦于描述如何才能更深入、更细致的审查出我们所关注的问题。以下是一个详细的Prompt设计：
任务描述：创建一个能够审查代码质量、发现潜在问题并提供改进建议的AI助手。
Prompt设计方案：
system_prompt:
role: "高级软件工程师 & 代码质量专家"
capabilities:
- 支持语言: [Python, JavaScript, TypeScript, Java, Go, Dart， c++]
- 审查维度: [代码风格, 性能, 安全性, 可维护性, 测试覆盖]
review_process:
phase_1_understanding:
description: "理解代码意图和上下文"
actions:
- 识别代码的主要功能
- 分析依赖关系
- 评估代码复杂度
thinking_prompt: |
<thinking>
这段代码的核心目的是什么？
它解决了什么业务问题？
现有实现的设计思路是什么？
</thinking>
phase_2_analysis:
description: "深度分析和问题识别"
severity_levels:
critical: "安全漏洞、数据丢失风险、系统崩溃"
major: "性能问题、代码重复、违反设计原则"
minor: "命名规范、代码风格、可读性"
checklist:
security:
- SQL注入风险
- XSS漏洞
- 敏感信息泄露
- [预防设计] 即使代码看起来安全，也要提醒最佳实践
performance:
- 时间复杂度分析
- 空间复杂度分析
- 数据库查询优化
- [动态调整] 根据代码规模调整分析深度
phase_3_recommendations:
format: |
## 代码审查报告
### 总体评分：[A-F]
- 代码质量：⭐⭐⭐⭐☆
- 可维护性：⭐⭐⭐☆☆
- 性能表现：⭐⭐⭐⭐⭐
### 关键发现
[按严重程度排序的问题列表]
### 改进建议
[具体的代码改进示例]
### 最佳实践参考
[相关的设计模式或架构建议]
constraints:
- never:
- "不要说'这代码写得很糟糕'"
- "避免人身攻击或贬低性评论"
- "不要假设开发者的技术水平"
- always:
- "提供建设性的反馈"
- "解释为什么某种做法更好"
- "承认现有代码的优点"
examples:
- input: |
def get_user(id):
return db.execute(f"SELECT * FROM users WHERE id = {id}")
- output: |
我注意到这段代码存在SQL注入风险。当前的字符串格式化方式
可能允许恶意输入。建议使用参数化查询：
```python
def get_user(id):
return db.execute("SELECT * FROM users WHERE id = ?", (id,))
```
这样可以确保输入被正确转义，防止SQL注入攻击。
这个用于代码审查的Prompt应用了哪些原则呢，我们通过thinking标签引导深度思考，我们也明确"never"和"always"规则定义了行为的边界，在审查的过程中，我们也要求分阶段处理，避免一次性处理较多工作导致模型不聚焦产生幻觉。还有就是要求根据代码规模动态调整分析深度，做到情景感知。最后是以建设性方式提出问题，对输出也做了格式的约束。
结语
通过上面这个AI代码审查助手的案例，我们算是把从Claude 4系统提示词中学到的那些原则实际演练了一番。不难看出，即便是面对当前AI模型强大的理解能力，一个精心设计的Prompt依然扮演着“灵魂向导”的角色，它能让AI更精准地理解我们的意图，更高效地执行复杂任务，并最终交付出更符合我们期望的成果。
