title: " Claude System Prompt | 30个专家模式" category: 人工智能 tags:

最近看到一份很有意思的清单：30 个可以直接复制的 Claude System Prompts。

如果只把它当成“提示词合集”，其实有点可惜。

这份清单真正值得看的地方，不是给了 30 段英文 prompt，而是反复证明了一件事：

Claude 能不能从“会聊天”变成“像专家一样交付结果”，
很多时候差的不是最后那个问题，
而是前面那段 system prompt。

普通用户习惯这样问：

帮我写一篇文章。
帮我分析一下竞品。
帮我改一下代码。
帮我做一个计划。

高手会先做另一件事：

先定义 Claude 是谁。
再规定它按什么规则工作。
再限定它怎么判断质量。
最后规定它交付成什么格式。

这就是 system prompt 的价值。

如果你通过 4SAPI 这类大模型API中转站接入 Claude、GPT 或其他模型，system prompt 还会变成更重要的一层：它不只是“聊天前缀”，而是团队工作流里的角色、流程和质量标准。

这一篇不逐条翻译那 30 个 prompts。

我会把它改造成一套更适合我们实际使用的方法：

30 个模板
  -> 5 类岗位
  -> 1 套 Project 搭建方法
  -> 1 个 system prompt 骨架
  -> 1 套模型入口治理思路

重点不是收藏更多提示词，而是学会设计“岗位”。

1. System Prompt 不是咒语，是岗位说明书

很多人写 prompt，喜欢追求一句神奇开头。

比如：

你是世界顶级专家。
你是资深写作教练。
你是硅谷一线架构师。

这类角色设定有用，但只写到这里远远不够。

真正有效的 system prompt，更像一份岗位说明书。它至少要回答 5 个问题：

问题 对应内容
你是谁 Identity，角色和专业背景
你服务谁 Audience，读者、客户、团队或用户画像
你怎么工作 Process，先做什么、后做什么
你如何判断好坏 Standards，质量标准、边界和禁区
你交付什么 Output Format，结构、长度、格式和字段

所以，一段好的 system prompt 通常不是一句话，而是一个小型 SOP。

它会把 Claude 从“泛化回答者”切换成某个岗位：

内容编辑
研究分析师
商业策略顾问
代码审查员
学习教练
会议简报官
SOP 文档员

这就是我对那 30 条清单最大的理解：它们不是 30 个模板，而是 30 个岗位。

2. 那 30 条其实可以重排成 5 个工作台

原清单按序列列了 30 个 System Prompts。

如果从真实工作流看，我更建议把它们重排成 5 个工作台。

工作台 负责什么 最适合谁
内容增长台 写文章、改标题、拆分发、做 hook 创作者、运营、市场
研究分析台 做调研、竞品、数据、决策分析 产品、咨询、管理者
商业策略台 定价、提案、Pitch、会议准备、SOP 创始人、销售、业务负责人
技术交付台 代码审查、架构、Debug、测试、技术解释 开发者、技术负责人
个人效率台 周计划、学习路线、反馈、每日简报 个人用户、知识工作者

这样看会更清楚：你不是在管理 30 条 prompt，而是在给 Claude 配 5 个部门。

每个部门里再拆岗位。

3. 内容增长台：不要让 Claude “帮你写”，要让它接岗位

内容类 prompt 最容易被误用。

很多人会直接说：

帮我写一篇爆款文章。

然后得到一篇很像 AI 的文章。

真正有效的内容 system prompt，会把内容生产拆成不同岗位：

选题策划
长文作者
Thread 改写
标题编辑
邮件文案
SEO 博客作者
多平台分发编辑
润稿编辑
Hook 生成器

这些岗位看起来都在“写内容”，但工作标准完全不同。

岗位 关键规则
长文作者 明确读者、开头冲突、段落节奏、案例密度、结尾行动
Thread 改写 首条必须有 hook，每条独立有价值，最后收束 CTA
标题编辑 批量生成、按框架分类、按点击动机排序
SEO 博客作者 关键词、搜索意图、结构层级、FAQ、内部链接
分发编辑 同一内容按平台重写，而不是简单裁剪
润稿编辑 删废话、去模板感、保留作者观点和语气

这组 prompt 的核心启发是：

内容不是一个动作，而是一条产线。

如果你写公众号，可以给 Claude 建一个“内容编辑部 Project”。

Project instructions 可以这样设计：

你是我的中文内容编辑部，不是泛用写作助手。

你的职责：
1. 帮我把素材变成可发布的中文长文、短帖、标题和分发文案。
2. 优先保持观点清晰，其次才是表达好看。
3. 不使用空泛鸡汤、夸大收益、假装亲历和营销号套话。
4. 每次输出前先判断任务属于选题、结构、初稿、改稿、标题还是分发。
5. 不确定事实时标出“需核实”，不要编造数据和来源。

默认输出：
- 先给判断
- 再给结构
- 最后给正文或候选文案

这比“你是顶级写作者”更好，因为它把岗位边界写清楚了。

4. 研究分析台：防止 Claude 把研究写成散信息

研究类 prompt 最大的价值，是结构化。

很多 AI 调研看起来很长，但读完没有结论。原因不是模型不会总结，而是你没有规定分析框架。

一份好的研究型 system prompt，会提前规定：

先给 executive summary
再给 key findings
再给证据
再给反方观点
再给信息缺口
最后给行动建议

或者在竞品分析里规定：

对方在做什么
强项是什么
弱点是什么
最近动作是什么
错过了什么机会
对我们有什么威胁

这类约束很关键。

因为真正高质量的分析，不是“写得多”，而是先把判断框架立住。

建议给研究类 Claude 规定 4 条铁律：

铁律 原因
区分事实和判断 避免把模型推测当结论
标出信息缺口 避免假装资料完整
写出反方观点 避免只服务于用户想听的答案
给出下一步动作 避免报告停在“知道了”

可用的 Project instructions：

你是我的研究分析师。

你的任务不是堆资料，而是帮助我形成可行动判断。

工作规则：
1. 先区分事实、推测和观点。
2. 如果资料不足，直接写“信息不足”，不要补脑。
3. 如果来源之间冲突，要标出冲突点。
4. 每份分析都必须包含反方观点或替代解释。
5. 最后输出 3 个可执行动作，而不是只写总结。

默认结构：
1. 一句话结论
2. 关键发现
3. 证据和依据
4. 反方观点
5. 信息缺口
6. 建议行动

如果接入 4SAPI，可以把这类任务分层处理：

资料清洗：低成本模型
观点提炼：中等模型
复杂判断：强推理模型
事实核验：联网或人工复核

不要让最贵模型从头到尾读全部材料。研究工作流最省钱的方式，是先切分，再升级模型。

5. 商业策略台：从“看清楚”推进到“怎么做”

研究分析解决的是“看清楚”。

商业策略解决的是“接下来怎么做”。

这组 prompts 覆盖的不是单纯写作，而是业务推进：

商业策略
定价策略
客户提案
Pitch Deck 大纲
会议准备简报
SOP 流程文档

它们共同的特点是：不只输出一个文档，还要推动一个决策或行动。

比如商业策略，不应该只写“建议提升品牌影响力”。

更好的结构是：

真正问题是什么
可选方案有哪些
每个方案需要什么投入
时间周期多长
风险在哪里
第一步做什么

定价策略也不应该只给一个数字。

更好的结构是：

成本底线
竞品价格
客户感知价值
good / better / best 三档
试点价格
涨价和降价风险

SOP 文档也不是把口述内容整理成段落。

它要让一个没有上下文的人照着做，所以必须包含：

适用范围
前置条件
操作步骤
判断节点
质量检查
常见错误
预计耗时
交付标准

这组 prompt 给我的启发是：

Claude 不应该只做“文案员”，还可以做“业务推进器”。

适合小团队使用的系统提示：

你是我的业务策略助理。

你的任务不是写漂亮话，而是把模糊问题拆成可执行方案。

默认工作流程：
1. 先诊断真正的问题，不急着给方案。
2. 至少给 3 个可选方案。
3. 每个方案都写清投入、周期、预期结果和风险。
4. 如果涉及对外材料，要先判断对方最在意什么。
5. 最后给出推荐方案和第一步行动。

输出必须包含：
- 问题诊断
- 方案对比
- 风险提醒
- 推荐路径
- 下一步动作

6. 技术交付台：让 Claude 像 reviewer，而不是像热心网友

技术类 prompt 最能体现 system prompt 的差距。

同样是让 Claude 看代码，如果没有规则，它很容易泛泛而谈：

这个函数可以优化。
建议增加错误处理。
可以考虑性能问题。

这些话都对，但不够可执行。

一个真正有用的 Code Reviewer，需要被规定：

先看安全问题
再看逻辑错误
再看边界条件
再看性能
再看可维护性
必须给文件和行号
必须给修复建议
不要纠结无关风格

架构顾问也不能一上来就给“最佳方案”。

它应该先确认：

业务目标
用户规模
数据规模
团队能力
上线周期
可接受复杂度

然后再给两到三种架构路线，比较成本、复杂度和风险。

Debugging Partner 更需要流程：

复现问题
读错误信息
提出假设
验证假设
定位根因
给最小修复
补测试

技术解释器则刚好反过来。

它不是写给机器，而是写给人。好的 system prompt 会规定：

先用一句话讲清楚
再用类比解释
再讲真实工作原理
最后给 30 秒复述版本

适合放进 Claude 或 Codex 的技术审查指令：

你是我的代码审查员。

审查优先级：
1. 安全漏洞
2. 逻辑错误
3. 边界条件
4. 数据一致性
5. 性能风险
6. 可维护性

规则：
1. 只报告会影响正确性、安全性、性能或维护成本的问题。
2. 每个问题都要说明影响、触发条件和修复建议。
3. 如果能定位到文件和行号，必须写出来。
4. 不要因为个人风格偏好提出无关建议。
5. 如果没有严重问题，请明确说“未发现高风险问题”。

如果你用 4SAPI 接入多个 coding 模型，可以把技术工作拆成：

任务 推荐策略
代码解释 中低成本模型
单元测试生成 代码模型
安全审查 强代码模型
架构设计 强推理模型
报错修复 先中等模型，复杂问题再升级

技术场景最怕“看起来很懂，实际没落地”。system prompt 的作用，就是逼 Claude 给出可验证的交付。

7. 个人效率台：把日常节奏固定下来

最后一组看起来最轻，但其实最接近日常。

它覆盖：

周计划
学习教练
诚实反馈
每日简报

这类 prompt 的重点，不是让 Claude 显得聪明，而是让它稳定地帮你维持节奏。

比如周计划，不应该只是把任务排成列表。

更好的规则是：

先按 impact 排优先级
再看截止日期
上午放 deep work
下午放沟通和杂务
预留 buffer
标出不该做的事

学习教练也不应该给一堆链接。

更好的流程是：

先判断当前水平
再拆里程碑
再设计练习
再安排每周节奏
最后定义什么叫学会了

反馈型 prompt 则要明确“不哄人”：

先说最影响结果的问题
再说为什么
再给修改建议
最后给优先级

这类 Project instructions 可以很短：

你是我的个人工作教练。

你的职责：
1. 帮我把目标拆成每周和每天能执行的动作。
2. 优先指出最重要的 20%，不要平均用力。
3. 给反馈时要诚实、具体、可修改，不要泛泛鼓励。
4. 每天输出不超过 60 秒能读完的行动摘要。
5. 如果我列出的任务太多，请帮我砍掉低价值事项。

它的价值在于稳定。

每天都重新解释一遍偏好很累。把这些规则写进 Project 或 system prompt 后，Claude 才会更像长期协作者。

8. Claude Projects 的关键：不是文件夹，是工作系统

那 30 个 system prompts 和 Claude Projects 放在一起看，会更有启发。

根据 Anthropic 帮助文档，Claude Projects 可以创建带有独立聊天、知识库和项目说明的工作空间。你可以上传文档、文本、代码等资料，让 Claude 在项目内使用这些上下文；也可以设置 project instructions，让 Claude 在该项目的所有聊天里按同一套方式回应。

这里有一个很重要的提醒：项目里的聊天并不会自动共享上下文，除非信息被加入项目知识库。

这意味着，一个好用的 Claude Project 不应该只是：

项目名：写作
项目名：市场
项目名：代码

更应该包含：

Identity：这个 Project 里的 Claude 是谁
Rules：它必须遵守什么规则
Process：它默认怎么工作
Output：它交付什么格式
Knowledge：它应该读取哪些固定资料
Onboarding：每次新任务先问什么

一个 Project 的结构可以这样设计：

Claude Project
  -> Project instructions
      -> 角色
      -> 工作原则
      -> 禁止事项
      -> 输出格式
  -> Knowledge base
      -> 品牌语气
      -> 业务资料
      -> 过往案例
      -> 数据口径
      -> SOP
  -> Onboarding message
      -> 本次任务目标
      -> 输入材料
      -> 成功标准

也就是说，Project 不是“带标签的聊天框”。

它应该是一个轻量工作系统。

9. 我会怎么把它改成自己的 5 个 Project

如果让我把这 30 个 prompts 真正用起来，我不会建 30 个项目。

我会先建 5 个。

9.1 内容编辑部

适合：

公众号
小红书
X / Threads
Newsletter
课程文案
产品说明

项目知识库放：

我的文章样稿
标题库
禁用表达
常用案例
读者画像
平台规则

默认输出：

选题判断
文章结构
初稿
标题候选
分发版本

9.2 研究分析室

适合：

竞品分析
行业研究
用户反馈
市场规模
决策备忘录

项目知识库放：

行业资料
竞品资料
用户访谈
内部数据口径
历史报告

默认输出：

一句话结论
关键发现
证据
反方观点
信息缺口
建议动作

9.3 商业策略室

适合：

定价
提案
客户沟通
Pitch Deck
会议准备
SOP 文档

项目知识库放：

产品资料
客户画像
报价规则
案例库
公司介绍
流程文档

默认输出：

问题诊断
方案对比
推进路径
风险提醒
下一步行动

9.4 技术审查台

适合：

代码 review
架构评估
Debug
API 文档
测试用例
技术解释

项目知识库放：

项目 README
架构说明
代码规范
API 约定
测试命令
部署流程

默认输出：

问题列表
严重程度
影响范围
修复建议
验证方法

9.5 个人参谋部

适合：

周计划
学习路线
目标复盘
反馈改进
每日简报

项目知识库放：

长期目标
当前项目
时间约束
学习计划
个人偏好

默认输出：

优先级
时间块
风险提醒
今日最重要 3 件事
不该做的事

这样做的好处是：你不是在维护零散 prompt，而是在维护自己的 AI 工作组织架构。

10. 一段可复用的岗位设计模板

如果你想把任何一个 prompt 改成自己的，可以先套这个骨架。

# 角色
你是我的 [岗位名称]，服务对象是 [读者/客户/团队/我自己]。

# 目标
你的目标不是 [常见错误目标]，而是 [真正交付目标]。

# 工作原则
1. [原则一]
2. [原则二]
3. [原则三]

# 默认流程
1. 先判断任务类型
2. 再确认输入是否足够
3. 然后按步骤分析
4. 最后输出可执行结果

# 输出格式
每次输出必须包含：
1. 一句话结论
2. 关键分析
3. 可执行建议
4. 风险或待确认项

# 禁止事项
1. 不编造数据、来源和案例
2. 不输出空泛建议
3. 不绕过合规和平台规则
4. 不在信息不足时假装确定

# 追问规则
如果缺少关键信息，最多问 3 个问题。
如果可以基于合理假设继续，请先写明假设再继续。

这段模板的重点不是多复杂，而是把“角色、目标、流程、输出、禁区”都写进去。

当你能稳定写出这种岗位说明书，Claude 的输出就会明显不一样。

11. 接入 4SAPI 后，System Prompt 还能变成治理层

如果只是个人使用，system prompt 解决的是输出质量。

如果是团队使用，它还要解决三件事：

成本
权限
可追溯

这时 4SAPI 这类大模型API中转站就很适合放在中间。

你可以按工作台拆 Key：

Key 适合项目 模型策略
content-key 内容编辑部 中等模型为主，少量强模型改稿
research-key 研究分析室 低成本清洗 + 强模型判断
business-key 商业策略室 中强模型，保留日志
dev-key 技术审查台 代码模型，必要时强推理
personal-key 个人参谋部 低成本模型为主

也可以按 system prompt 做版本管理：

content-editor-v1
content-editor-v2
research-analyst-v1
code-reviewer-v1
strategy-advisor-v1

这样以后复盘时，你能知道：

哪套 prompt 输出更稳定？
哪个模型更适合这个岗位？
哪个工作流最烧钱？
哪些任务可以降级到便宜模型？
哪些任务必须保留强模型？

system prompt 不再只是写在对话框前面的一段话，而是团队 AI 工作流的一部分。

12. 写 System Prompt 的 8 条检查清单

下次你写 system prompt，可以用这张清单自检：

检查项 问自己
角色是否具体 它到底是什么岗位，而不是泛泛的专家？
服务对象是否明确 它是给老板、客户、读者、开发者还是我自己？
工作流程是否清楚 它先做什么、后做什么？
输出格式是否固定 每次交付是否能稳定复用？
质量标准是否可判断 什么叫好，什么叫不合格？
禁止事项是否写明 哪些话不能说，哪些动作不能做？
信息不足时怎么办 追问、假设还是停止？
是否能接入 Project 有没有知识库、样例和固定上下文？

如果这 8 条都写清楚，Claude 就更容易像一个岗位协作者。

如果只写“你是专家，请认真回答”，那它大概率还是一个会聊天的专家，而不是能交付结果的专家。

13. 总结

这 30 个 Claude System Prompts 最值得学的，不是 30 段话本身。

真正值得学的是背后的岗位设计思维。

先定义角色
再写规则
再限定流程
再规定输出
再接入知识库
最后用模型入口管理成本和日志

当你这样使用 Claude，它就不再只是“更会聊天”。

它会更像：

内容编辑
研究分析师
商业策略顾问
代码审查员
个人工作教练

一句话总结：

System Prompt 不是模板合集，而是专家模式开关。

如果你已经在用 Claude Projects，就不要只建几个带名字的文件夹。给每个 Project 写清楚 Identity、Rules、Process、Output Format，再放入知识文件和示例。

如果你已经通过 4SAPI 接入多模型，就把 system prompt 当成工作流配置的一部分：不同岗位用不同提示词、不同模型、不同额度和不同日志。

模型会继续变强，但真正拉开差距的，往往是你有没有把“专家的工作方式”提前写进去。

参考资料