跳到主要内容

角色配置与系统提示词编写

本文不讨论通用“提示词工程”理论，只说明在 CountBot 中如何把角色、人设、团队成员提示词写得稳定、可维护、可执行。

先分清四层内容​

在 CountBot 中，常见的文本配置大致分为四层：

  1. persona 决定默认名称、称呼、输出语言和整体说话风格。
  2. 团队成员的 role、task、system_prompt 决定每个成员在团队里的职责边界和执行要求。
  3. 技能文档 SKILL.md 决定某个技能如何被理解和调用。
  4. 用户当前任务 决定这一次到底要交付什么结果。

写配置时，最常见的问题不是“提示词不够长”，而是这四层内容写混了。
人格写成任务要求，任务要求写到技能文档里，最后会导致模型风格混乱、职责重复、团队协作失焦。

persona 负责什么​

persona 是全局默认基线，适合放这些内容：

  • AI 的名称与自称
  • 对用户的称呼
  • 默认输出语言
  • 整体语气与风格
  • 默认历史消息长度等对话层参数

适合写进 persona 的内容：

  • “默认用中文回答”
  • “称呼用户为项目负责人”
  • “保持正式、直接、少空话”

不适合写进 persona 的内容：

  • “你负责代码评审”
  • “你必须先调研再写作”
  • “遇到发布任务先找测试报告”

这些都不是全局人格，而是具体角色或具体任务。

角色成员的 system_prompt 负责什么​

团队成员的 system_prompt 应只解决“这个成员负责什么、如何判断完成”。

推荐把它写成四段：

  1. 角色定位 说明该成员在团队中的职责。
  2. 输入范围 说明它通常接收什么材料。
  3. 输出要求 说明它要产出什么结果。
  4. 边界约束 说明它不负责什么，不要越权。

例如，评审成员可以这样写：

{
  "id": "reviewer",
  "role": "Reviewer",
  "task": "审查实现结果并指出风险",
  "system_prompt": "你负责识别行为回归、配置遗漏、兼容性风险和缺失测试。输出时先列风险，再给结论；如果证据不足，明确指出缺口。不要改写需求，不要替实现成员重新设计方案。"
}

这段配置里：

  • role 说明身份
  • task 说明当前职责
  • system_prompt 说明工作方式与边界

三者要互相补充，不要重复堆同一句话。

编写时的基本原则​

1. 先写职责，再写风格​

很多配置把“专业、严谨、资深、负责”写了一大段，却没有写清楚到底要做什么。
在 CountBot 中，职责定义永远比形容词重要。

不推荐：

你是一名专业、严谨、经验丰富、能力全面的高级专家。

推荐：

你负责核对配置项是否齐全，检查渠道参数、模型参数和工作空间路径是否一致。

2. 写清输入和输出​

如果某个成员接收的是“上一节点输出”“配置草稿”“发布说明”，就直接写明。
如果输出必须是“问题清单”“上线建议”“最终发布文案”，也要直接写明。

不推荐：

请认真完成工作并给出专业结果。

推荐：

输入是开发成员提交的实现说明与变更文件。输出为风险清单、是否可发布、缺失测试三部分。

3. 边界必须明确​

CountBot 支持团队协作、技能注入和工具调用。如果不写边界，多个成员很容易做重复工作。

建议显式写出：

  • 不负责哪些步骤
  • 不需要重复哪些前置结论
  • 不得擅自改变哪些约束

例如：

你不重新拆解需求，不重写已有实现，只对当前结果做审查。

4. 避免把工具规则写得过细​

工具是否可用，最终取决于运行时注册情况和安全策略。
system_prompt 可以说明“优先查证再结论”“必要时读取文件”，但不要假设所有工具一定存在，更不要把某个工具的参数手册全部塞进角色提示词。

工具细节更适合放在：

  • 技能文档
  • 工具文档
  • 具体任务描述

5. 不要让人格和角色互相打架​

例如：

  • persona 要求“轻松幽默”
  • 评审成员 system_prompt 要求“结论必须正式、审慎、严厉”

这种冲突会直接影响输出稳定性。
如果某个团队场景必须正式，就在该成员的职责提示里明确覆盖，不要依赖全局人格自然收敛。

推荐模板​

人设基线模板​

{
  "persona": {
    "ai_name": "CountBot",
    "user_name": "项目负责人",
    "output_language": "中文",
    "personality": "custom",
    "custom_personality": "表达正式、结论明确、避免空泛表述；信息不足时先说明缺口，再继续分析。"
  }
}

适用于需要整体输出风格统一的场景。

团队成员模板​

{
  "id": "writer",
  "role": "Writer",
  "task": "根据已确认材料形成对外文案",
  "system_prompt": "你只根据已确认资料写作，不补造事实。输出需结构完整、语言正式、可直接发布；若关键信息缺失，先列缺口，再暂停下结论。"
}

适用于内容、公告、发布说明等团队成员。

什么时候该改提示词，什么时候不该改​

出现效果问题时，先判断问题属于哪一层：

  • 说话风格不对：先检查 persona
  • 某成员职责不清：先检查团队成员 system_prompt
  • 工具不会用或参数总出错：先检查技能文档和工具文档
  • 本次任务目标含糊：先改用户任务描述

不要把所有问题都归因到“提示词不够强”。
在 CountBot 里，配置分层比堆长文本更重要。

常见误区​

误区 1：把成员写成“万能专家”​

如果每个成员都写成“负责全流程分析、执行、审查、交付”，那团队模式就失去意义了。

误区 2：把输出格式写得过于空泛​

“清晰一点”“专业一点”“尽量完整”都不如直接指定输出结构有效。

误区 3：在 system_prompt 里重复用户任务​

成员提示词应该描述长期职责，不应该把某一次任务全文抄进去。
任务本身应通过聊天输入、@团队名 调用或 workflow_run 传入。

误区 4：把渠道限制忘了​

有些输出会进入钉钉、飞书、QQ、Telegram 等渠道。
如果某个成员输出面向外部渠道，应明确是否允许长文、是否需要分点、是否必须避免工具执行细节。

建议的落地顺序​

  1. 先确定全局 persona 是否稳定。
  2. 再定义团队成员的职责边界。
  3. 再补充每个成员的输入、输出、约束。
  4. 最后再针对特定场景微调文案风格。

这样维护成本最低，也最符合 CountBot 当前的配置结构。

相关文档​