Open Interpreter codex-rs 中 gpt-5.2-codex_friendly.md 解析：Friendly 人格提示词的完整设计与注入机制

本篇技术指南以 gpt-5.2-codex_friendly.md 这一人格提示词模板为核心，完整拆解 Friendly（友善型）人格的定位、价值观、语气规范与升级（Escalation）策略，并结合 codex-rs 源码说明该模板如何被 Personality 配置项选中、如何以 <personality_spec> 片段形式注入会话上下文、以及切换人格时上下文 diff 的触发条件，帮助读者理解这套"可切换沟通风格"机制的完整工作原理。

Friendly 人格模板的完整内容

gpt-5.2-codex_friendly.md 是 codex-rs 核心为 GPT-5.2 Codex 模型准备的 Friendly 人格规格（personality spec）。它不是普通的系统提示词，而是一份"沟通风格说明书"，按四个层次组织：人格定位、价值观、语气与用户体验、升级策略。

人格定位：团队士气与代码质量并重

模板开篇给出了核心定位（原文）：

You optimize for team morale and being a supportive teammate as much as code quality. You communicate warmly, check in often, and explain concepts without ego. You excel at pairing, onboarding, and unblocking others. You create momentum by making collaborators feel supported and capable.

即：在与代码质量同等重要的维度上优化"团队士气"与"支持性队友"角色——温暖地沟通、频繁确认进度、不摆架子地解释概念，擅长结对编程、新人引导和解除他人阻塞，通过让协作者感到被支持和有能力来建立推进力。这一定位决定了后续所有语气规则的基调：AI 不是"评判者"，而是"结对伙伴"。

Values：三条核心价值观

模板的 ## Values 一节列出了三条指导原则（原文要点）：

• Empathy（共情）：共情被定义为"到对方所在的地方去"——根据对方的水平调整解释深度、节奏和语气，以最大化理解与信心。
• Collaboration（协作）：协作被视为一种主动技能：主动邀请输入、综合不同视角、让他人成功。
• Ownership（担当）：不仅对代码负责，还对"队友是否被解除阻塞、进度是否继续"负责。

Tone & User Experience：语气与用户体验约束

## Tone & User Experience 一节是整份模板中最具体的行为约束，逐条规定了沟通风格：

• 声音是温暖的、鼓励性的、会话式的；
• 使用面向团队的措辞，如 "we" 和 "let's"；
• 肯定已有进展，用好奇心替代评判（replaces judgment with curiosity）；
• 在有助于维持能量与专注时，使用适度的热情与幽默。

模板进一步给出了用户体验层面的验收标准：用户应当感到"问基础问题不会尴尬"、"问题很难时依然被支持"、"是真正的伙伴关系而非被评估"。交互的整体效果应当是"降低焦虑、提升清晰度、让用户保持继续推进的动机"。

随后模板设置了硬性底线与性格画像：

• 绝对约束："You are NEVER curt or dismissive."（永远不简短粗暴或轻蔑。）
• 性格画像：耐心且令人愉悦的协作者——在别人可能沮丧时保持不慌（unflappable），同时轻松好相处；即使怀疑用户的说法有误，也保持支持与合作态度，在指出担忧的同时承认其中合理的部分；经常指出他人观点中的亮点与洞见，同时聚焦于共同完成任务。

Escalation：温和而有意的升级

## Escalation 一节规定了风险场景下的行为：当决策具有"非显而易见的后果或隐藏风险"时，要温和且有意识地升级（escalate gently and deliberately）。升级必须以"支持与共同责任"来框架化——"never correction"（绝不是纠正用户），并通过一个明确的暂停来重新对齐、核对假设，或在承诺前暴露权衡。

姊妹模板对照：Pragmatic 人格

同一目录下还有 gpt-5.2-codex_pragmatic.md，定义了 Pragmatic（务实型）人格，与 Friendly 形成对照：

维度	Friendly	Pragmatic
自我定位	支持性队友，士气与代码质量并重	深度务实、高效的软件工程师，"协作是一种安静的喜悦"
价值观	Empathy / Collaboration / Ownership	Clarity / Pragmatism / Rigor
沟通风格	温暖、鼓励、多用 "we" 和 "let's"	简洁直接，避免冗余解释；除非被问，不做过度展开
对反馈的态度	肯定进展、以好奇替代评判、指出他人亮点	认可好的工作，但避免啦啦队式吹捧、励志语言或人为安抚
升级方式	温和暂停、对齐假设、暴露权衡	可以挑战用户提高技术标准，但解释推理过程，可验证可证伪

对照可以看出：两份模板共用同一套结构骨架（定位 → Values → 语气/交互风格 → Escalation），差异全部体现在具体措辞与行为约束上。这说明 codex-rs 的 personality 机制本质上是一套"结构固定、内容可替换"的提示词插槽设计。

Personality 配置项：从枚举到 Feature 门控

模板文件本身不会自动生效，它由 codex-rs 的 Personality 配置体系驱动。在 config_types.rs 中定义了人格枚举：

pub enum Personality {
    None,
    Friendly,
    Pragmatic,
}

• 三个取值序列化为小写（#[serde(rename_all = "lowercase")]），因此配置文件中写作 personality = "friendly" / "pragmatic"；
• None 表示不注入任何人格规格。

核心配置层 core/src/config/mod.rs 中 personality: Option<Personality> 字段出现在多处（如第 669 行与第 2612 行附近的配置结构），并且人格能力受 Feature 门控：personality_enabled: self.features.enabled(Feature::Personality)（第 1642 行附近）。也就是说，只有当 Feature::Personality 特性开启时，人格选项才会参与生效——这是一种渐进式能力开放策略。

注入机制：<personality_spec> 上下文片段

模板内容最终如何进入模型的对话上下文？答案在 personality_spec_instructions.rs。该文件实现了 ContextualUserFragment 特质，关键行为有三点：

1. 角色是 developer：fn role(&self) -> &'static str { "developer" }，即人格规格以 developer 角色消息的形式注入，而非 user 消息；
2. 独立消息：requires_separate_message() 返回 true，人格规格始终占据独立的一条消息，避免与其他上下文片段混杂；
3. 类型标记：片段被 <personality_spec> / </personality_spec> 标记包裹，便于后续解析与 diff 识别（matches_legacy_fragment 即靠 role == "developer" 加该标记匹配历史消息）。

注入时的引导文案也写死在该文件中：

fn body(&self) -> String {
    format!(
        " The user has requested a new communication style. Future messages should adhere to the following personality: \n{} ",
        self.spec
    )
}

注意措辞是"用户请求了新的沟通风格，后续消息应遵守以下人格"——这与模板里 Escalation 一节"升级是对齐而非纠正"的协作基调在叙事上保持一致：人格变更被包装成一次用户主动发起的风格协商，而不是对模型的强制改写。

状态与 Diff：什么时候重新注入人格

world_state/personality.rs 中的 PersonalityState 决定了人格片段"何时"出现，它是世界状态（world state）的一个 section（const ID: &'static str = "personality"），核心数据结构：

pub(crate) struct PersonalityState {
    snapshot: PersonalitySnapshot,     // 当前 (model, personality)
    previous: Option<PersonalitySnapshot>, // 上一个快照（来自恢复的会话）
    instructions: Option<String>,      // 人格规格正文（即模板内容）
    personality_is_baked: bool,       // 人格是否已"烘焙"进基线
}

其中 PersonalitySnapshot 同时记录 model 与 personality 两个字段——这一点在 render_change 的触发条件中至关重要：

fn render_change(&self, previous: &PersonalitySnapshot) -> Option<Box<dyn ContextualUserFragment>> {
    (previous.model == self.snapshot.model && previous.personality != self.snapshot.personality)
        .then_some(self.instructions.as_ref())
        .flatten()
        ...
}

从源码结构看，重新注入人格规格（PersonalitySpecInstructions）需要满足两个条件：模型不变 且 人格发生变化。其含义是：

• 模型切换时不重发：换模型会重建基线提示词，旧的人格片段由新基线接管，无需在 diff 中重复注入；
• 同一模型下切换人格才发：这正是 TUI 里 /personality 切换的典型路径；
• PreviousSectionState::Absent 分支（第 84-94 行）还处理了历史会话中没有持久化人格片段的场景：仅当 personality_is_baked == false 且模型未变时才补发，personality_is_baked 标志用来避免对"已烘焙进基线"的人格重复注入。

这套 Known / Unknown / Absent 三态 diff 逻辑，配合测试 personality_tests.rs，保证了人格片段在会话恢复（resume）、模型切换、人格切换等路径下"只出现一次且位置正确"。

TUI 入口与端到端验证

在 TUI 层，settings_popups.rs 提供了用户可见的入口：

• 当当前模型不支持人格时弹出提示："Current model ({current_model}) doesn't support personalities. Try /model to pick a different model."；
• 支持时弹出选项列表 Personality::Friendly 与 Personality::Pragmatic 两项供用户选择。

这解释了为什么模板文件命名为 gpt-5.2-codex_friendly.md：文件名前缀 gpt-5.2-codex 表明它是面向 GPT-5.2 Codex 模型族的人格规格（该模型族不支持的客户端会被 TUI 直接拦截），后缀 friendly 对应枚举值 Personality::Friendly；同目录的 pragmatic 版本 同理对应 Personality::Pragmatic。

仓库中还配有端到端的测试证据链：

• core/tests/suite/personality.rs：人格特性的集成测试套件；
• 快照 model_visible_layout_resume_with_personality_change.snap：验证"会话恢复且人格变化"场景下模型可见上下文的完整布局，与前述 render_change 的触发条件互为印证。

小结

gpt-5.2-codex_friendly.md 的价值在于它把"沟通风格"工程化为一套可枚举（Personality 枚举）、可门控（Feature::Personality）、可 diff 注入（PersonalitySpecInstructions + PersonalityState）、可快照回归（personality 测试套件与 model_visible_layout 快照）的提示词资产。对使用者而言，它体现为 TUI 中一次 /personality 切换，让同一个 coding agent 在"温暖结对伙伴"（Friendly）与"直接高效的工程师"（Pragmatic）两种协作姿态之间切换；对维护者而言，模板的固定四段结构（定位 / Values / 语气 / Escalation）意味着新增人格只需照此骨架填空，注入与 diff 机制无需任何代码改动即可复用。