这 30 个 System Prompts 最值得看的，不是 30 段可以复制粘贴的话。
它们真正讲透的是：Claude 能不能从“会聊天”变成“像专家一样交付”，很多时候差的就是任务开始前那套岗位定义。
先规定身份、规则、流程和输出标准，再让模型工作。这个顺序，比在普通对话里反复补充要求稳定得多。
五组高频工作场景
这份清单覆盖五组场景：内容与写作、研究与分析、商业与策略、技术与开发、个人效率。
主题很多，但它们都在做同一件事：把 Claude 限定成某一种专业角色，再要求它按这个角色的工作方式交付。
内容与写作：把创作拆成岗位
第 1—8 条覆盖 Viral Article Writer、Thread Converter、Headline Generator、Email Copywriter、Blog Post SEO Writer、Social Media Repurposer、Editing Assassin、Caption and Hook Generator。
这组不是笼统地让 Claude “帮我写”，而是把内容生产拆成长文、短帖转换、标题、邮件、SEO 博客、多平台分发、编辑和钩子生成等岗位。
例如 Viral Article Writer 会明确受众、段落长度、开头结构、数据表达和结尾形式，还会列出禁用表达。
Thread Converter 则约束首条内容必须承担 hook，每条都要独立有价值，总长度受控，结尾完成明确收束。
这里真正可复用的是拆岗思路：同一个“写作”任务，研究、起标题、起草、编辑和分发需要不同标准。把它们塞给一个模糊角色，输出自然容易混成一锅粥。
研究与分析：先立判断框架
第 9—14 条覆盖 Deep Researcher、Competitive Intelligence Analyst、Data Analyzer、Market Sizer、Decision Analyst、Document Summarizer。
这一组的共同点是结构化。它们会预先规定 summary、key findings、contrarian view、gaps、actions，或者要求比较竞争对手的动作、优势、弱点、近期变化和潜在威胁。
高质量分析不是多写几段，而是先把判断框架立住。
Deep Researcher 会要求优先使用近期来源，数据不足时明确说 insufficient data，来源冲突时主动标注。
Decision Analyst 会把“不作为”也列为一个选项，并区分事实与观点。
这些约束能减少一种常见失败：模型收集了很多信息，却没有告诉你哪些可靠、哪里冲突，以及下一步该怎样判断。
商业与策略：从看清问题到推动执行
第 15—20 条包括 Business Strategist、Pricing Strategist、Client Proposal Writer、Pitch Deck Outliner、Meeting Prep Briefer、SOP/Process Documenter。
研究分析关注“看清楚”，商业策略更关心“接下来怎么做”。
Business Strategist 会先诊断问题，再给出多个战略选项，并比较投入、时间、结果和风险。
Pricing Strategist 同时考虑可比价格、价值定价和成本底线，再设计不同档位，而不是随手报一个数字。
Client Proposal Writer、Pitch Deck Outliner 和 Meeting Prep Briefer 则把对方关心什么、你想推动什么、可能遇到什么阻力都放进结构。
SOP/Process Documenter 很适合把口述流程变成零上下文读者也能执行的文档，并补上决策点、质量检查、常见错误和时间估计。
技术与开发：同一份代码，需要不同脑回路
第 21—26 条覆盖 Code Reviewer、Architecture Advisor、Debugging Partner、API Documentation Writer、Test Writer、Technical Explainer。
同样是“看代码”，不同岗位的判断顺序完全不同。
Code Reviewer 可以先检查安全，再看逻辑和性能，并要求指出具体位置与修改版本。
Architecture Advisor 应该先确认需求，提出至少两条路线，比较优缺点和复杂度，最后再给建议。
Debugging Partner 先定位根因再修复；Technical Explainer 则把复杂概念翻译给非技术读者，同时保留准确性。
这组覆盖了技术工作中常见的四次脑力切换：写代码、查问题、写文档、做解释。一个笼统的“资深工程师”角色，很难同时把四件事都做到位。
个人效率：让日常工作也有标准
第 27—30 条包括 Weekly Planner、Learning Coach、Feedback Giver、Daily Brief。
Weekly Planner 不只是排列任务，而是按影响排序、分配时间块、预留缓冲，并把深度工作和行政事务放到合适时段。
Learning Coach 先判断当前水平，再拆里程碑、练习、每周计划和达成信号。
Feedback Giver 负责诚实反馈，Daily Brief 则把信息压缩成一份能快速读完的行动摘要。
这组看似简单，却最容易进入日常。System prompt 不只服务专业产出，也可以用来稳定一套重复发生的工作节奏。
30 个提示词背后的共同骨架
把它们放在一起看，几乎都能还原成四层：
- Identity：这次 Claude 扮演谁，服务谁。
- Rules：必须遵守什么，不能做什么。
- Process：先做什么、后做什么，遇到信息不足怎样处理。
- Output Format：最终交付包含哪些部分，用什么结构呈现。
可以把这个骨架改成自己的 system prompt：
你是【具体岗位】，服务对象是【用户或团队】。
目标：
【这次要产生的业务结果】
规则：
1. 【必须遵守的事实、语气或质量要求】
2. 【明确禁止的行为】
3. 信息不足时先提问；无法验证时明确标注，不要猜测。
流程：
1. 先确认输入、范围和成功标准。
2. 按【岗位真实工作顺序】处理任务。
3. 检查遗漏、冲突、风险和边界。
4. 给出最终交付与下一步动作。
输出格式：
- 摘要
- 核心发现或成品
- 风险与限制
- 建议动作
这个模板故意没有塞进很多漂亮形容词。真正重要的，是把岗位的判断顺序写进去。
别把岗位设计写成角色扮演
“你是世界顶级专家”通常没有多少约束力。
有效的岗位定义应该回答更具体的问题：专家先检查什么，怎样处理证据冲突，什么时候必须停下来提问，交付怎样才算合格。
如果只是想找一句现成 prompt，这 30 条当然能用。
但更值得学的是它们背后的岗位设计：这次要 Claude 扮演谁，按什么规则工作，最后交付成什么样。
模型不一定因为一句角色设定突然变聪明，但清楚的工作方式，会让它少走很多歪路。
