先分清两种输入

和模型对话时，你写的每句话都属于两种输入之一：system prompt 是设定——“你是谁、按什么规矩干活”，它在整个会话里持续生效、优先级高于用户输入；user prompt 是当轮任务——“帮我看看这段代码”。新手最常见的错是把规矩写在 user prompt 里（“记住以后都这样回复”），结果两轮之后模型就忘了——规矩放错了地方，等于没立。

system prompt 写得好不好，直接决定这个"AI 助手"是稳定的专业角色，还是每次打开都要重新调教的随机状态。

六个区块，各司其职

结构化的 system prompt 可以拆成六个区块，每个区块只干一件事：

  1. 角色：一句话说清专业身份。“你是一位资深前端工程师，擅长 Vue 与 TypeScript”——具体到技术栈，比"你是编程专家"管用得多；
  2. 背景：服务对象和使用场景。“代码评审面向刚入职的初级工程师，团队规范是 ESLint 标准配置”——模型会自动调整讲解深度；
  3. 边界：明确"不做什么"。“不确定的 API 行为直接说明不确定，不要编造参数签名”——否定清单要短而狠，三条以内；
  4. 输出格式：告诉模型答案长什么样（分点？表格？JSON schema？），格式固定后下游处理和人工阅读都省力；
  5. 语气：专业严谨还是简洁直接，一句话定调；
  6. 少样本示例：一对"输入→理想输出"，比十条描述都有效——模型模仿样例的能力远强于理解抽象规则。

🔧 System Prompt 构建器 就是按这六个区块做的拼装器：左边逐块填写（每块都有占位示例），右边实时预览成品，支持分节式（# Role / # Constraints 的英文节名）和紧凑单段两种输出，还内置了站内统一的 token 估算（中文 1 字≈1 token，与🔧 Token 成本计算器 同口径）——成品超 1500 token 会提醒你精简，因为 system prompt 是每一轮对话都要重复计入上下文的固定开销。

三条实战经验

正指令优于负清单。“回答控制在 300 字内、先给结论再给依据"比"不要啰嗦、不要说废话"有效。模型擅长执行具体的动作，不擅长揣摩抽象的禁忌。

**示例是杠杆最大的区块。**同样教"评审意见要给修改建议”，写十条规则，不如直接放一条完整示例。哪怕只有一个 Q/A 对，行为一致性都会明显提升——构建器的示例区块就是为这个准备的。

**写完就测，测完就改。**system prompt 不是一次写对的东西。改一版、跑几个典型任务、再改——用站内的🔧 Prompt 对比 看两个版本差在哪，比凭记忆回溯可靠。如果是项目级的长期规则（CLAUDE.md、.cursorrules 这类），那本质上是按项目放置的持久 system prompt，🔧 AI 规则文件生成器 可以直接生成对应格式。

常见问题

system prompt 写多长合适？

日常任务几百 token 内足够；复杂角色（如固定格式的数据处理流水线）可以长，但要意识到它每轮都占上下文。构建器的 token 统计就是帮你守住这条线。

一次会话中途能改 system prompt 吗？

API 调用可以（每次请求都带），聊天产品里通常改不了。更好的实践是把"会变的规则"放进 user prompt，把"不变的人设"留在 system prompt——分层之后两边都稳定。

分节式和紧凑式怎么选？

给 API 用、指令多的场景选分节式（模型对结构化节名的遵循度更高）；给简短角色、或要省 token 的场景用紧凑单段。构建器两种都能一键切换对比。

本章配套工具箱

边读边用：以下工具均在浏览器本地运行，数据不上传。