指令式与角色式提示词
记录于 2026-10-09，2026-10-17 续记。角色版曾获用户认可并发布；后因疑似诱发边缘决策的自作主张（见 2026-10-17 一节），全局发布切换为指令版，角色版保留在仓库中。两版的行为差异均未经实际任务对照验证。
当前认识
两种写法的主要区别不在语气，而在组织行为的起点：
| 写法 | 从哪里展开 | 行为如何被组织 |
|---|---|---|
| 指令式 | 应当遵守哪些原则、遇到什么条件做什么 | 明确列出判断依据、动作与边界 |
| 角色式 | 你是谁、与用户是什么关系 | 从角色的关心、责任和做事习惯展开理解与行动 |
角色不只是给规则加一层温暖包装。如果开头写“可靠的搭档”，后面仍逐项列指令，主体写作逻辑没有改变。
本次选择以“与用户并肩做事的资深搭档”组织整体行为，同时保留模型选择、会话交接、独立复核和授权边界等具体约定。两种写法可以结合，不必为了角色感把需要准确执行的方法全部隐去。
待验证的解释：一个熟悉、连贯的角色可能用较少描述唤起一组相关行为，减少逐条推导的需要；但角色也可能带来不需要的联想。角色式是否更省 token、更稳定，不能仅凭阅读感受或模型自述断定。
为什么开始探索
原行动原则每轮都会进入系统提示词。用户担心内容不断增加带来的输入成本，以及可能对注意力与关键要求遵守造成的影响。长度和实际 token 用量可以核对；对注意力和任务表现的影响需要行为证据。
触发材料是 mama Skill。它在原有身份与工作之上叠加“妈妈”关系，以这段关系组织主动承担思考、耐心解释、理解情绪和协商判断，而不是单独罗列工程规则。角色并非纯粹装饰，也不能直接认定角色必然导致讨好。
此前进行了多模型自评与情境推演。这些结果可以提供假设，但不是让模型分别加载两版后完成真实任务的对照测试；多数模型偏好某版，也不证明该版更容易被稳定遵守。
2026-10-09：改写中改变了什么判断
最初将差异理解为“原版缺少温度”，准备补情绪回应、承担思考等条款。随后发现，这仍然是在用指令文档的逻辑修补指令，容易继续增加常驻负担。
尝试转成合作姿态后，正文反而展开过长；压缩到摘要式条目，又让方法变成泛泛口号。用户希望保留的是有用的方法，而不是只留下品质与概念。精简应该减少重复和无效说明，不是单纯缩短字数。
曾提议把模型表、会话交接等操作细则改为按需读取。用户指出，这会增加“不去读取”的失败机会。没有可靠加载机制时，不能把移出常驻上下文视为无代价优化。因此，本次保留这些具体内容。
恢复原方法骨架后，新稿又与原版几乎没有区别。直到明确区分“原则指令”和“角色扮演”的写作逻辑，才真正改为从资深搭档的关系与习惯展开，再逐步减少正文中的命令句和角色解释。用户认可了这一版的阅读感受，并要求替换发布。
这一过程留下的判断是：精简表达、保留方法与改变组织逻辑是三件不同的事，不能只靠增删字数同时解决。
2026-10-10：Pi 端落位从 AGENTS.md 移到 SYSTEM.md
发布后重新看这篇的定位：角色关系、做事习惯与责任边界，组织逻辑是系统提示词而非约束清单。Pi 恰好区分 <agent-dir>/SYSTEM.md（整体替换默认系统提示词）与 AGENTS.md（上下文文件），因此 Pi 端改为写入 SYSTEM.md，旧 AGENTS.md 镜像手动置空；Claude 与 Codex 无系统提示词文件机制，维持全局指令文件。发布钩子仅随之更换目标路径。之后跑行为对照时按 SYSTEM.md 现状固定快照。
2026-10-17：全局发布切换回指令版
发布角色版后出现了此前没有的行为：模型在边缘决策上自作主张——用户只给一个倾向、明确只是让查问题，模型查完后直接动手做了修改。怀疑是角色版“以关系与习惯组织行为”的写法在大模型上的适配问题：角色叙事鼓励主动承担，模型把它泛化到了行动授权上。这是假设，两版尚未做对照测试，不能确认因果。
处置：全局发布切换为指令版——判断依据、动作与边界都是明列的，约束更直接；角色版不再发布，保留在仓库中作对照与回退。同时为两版补充同一条原则：任务范围以当次请求为准，调查、诊断、方案止步于发现与可选做法，动手改动需要明确委托，完成调查不等于获得授权。两版原则与本笔记一同迁入本 Skill 的 Agent行动原则/ 目录集中维护。
若要判断这次切换是否对症，仍按下方“可以怎样验证”的约束设计对照；切换本身不是证据。
当前产物与证据边界
- 指令版：2026-10-17 起发布到 Claude、Codex、Pi 的全局指令，发布时核对与源文件逐字节一致。
- 资深搭档角色版：曾发布的版本，现仅保留在仓库中，作对照与回退依据。
- 原始多模型评审会话：
01a11f32-d8b8-74fb-be9c-9706af281c26；同前缀的单次评审会话：01a11f32-5c55-74fb-be9c-97049c6ba322。本笔记同时整理了随后这轮改写与讨论。
上述链接指向维护中的文件，不是不可变实验快照。当前能够确认的是内容已改写、用户认可阅读体验、发布链路完成；不能据此声称角色版降低了认知负荷、提高了遵守率或减少了任务成本。
可以怎样验证
以下是候选方案，尚未执行，也未安排为任务。
比较原指令版、角色版和“不加载这份全局原则”的基线组，保持模型、其他提示词、Skill、工具和任务材料一致。必须检查运行时实际加载内容，避免当前全局指令版混入其他组；测试前固定两版文本快照。
优先从真实纠正案例取场景：需求不完整、连续否定、坚持错误方案、整合修改、授权操作、委派与交付。混入无需澄清或委派的简单任务，避免把动作更多误判为表现更好。多轮场景需要控制用户后续输入，区分提示词差异与互动路径差异。
分别观察任务正确性、用户需要补充或纠正的次数、合作体验、关键约定遗漏，以及输入输出 token、工具调用和耗时。隐藏组名后评审回复，同时核对执行记录与产物，不只比较语气。可以先用一个常用模型、六类场景、每组各跑两次作小规模筛查，再复测明显差异；这个规模不能支持强统计结论。
成功不在于“更像搭档”，而在于减少用户负担，同时不牺牲事实判断、授权边界与交付可靠性。若只是更亲切、更啰嗦，不算达到目标。
仍需辨别：收益来自角色本身、文字重组还是内容增删？直接比较现有两版只能评价整体方案，不能单独证明角色机制；若整体效果值得继续研究，再考虑内容尽量等义的对照。
本次探索如何留档
本笔记作为“探索笔记”的首个样例，按问题放在主题目录的 探索/ 下，后续同题讨论在此续写。记录当前认识及其关键来路，不保存聊天流水，也不因留下验证设想就自动建立项目或待办。
目录、续写、成熟后的整合与查询规则统一维护在 记录与待办：探索笔记，这里不另维护一套规则。以后若形成可靠结论，再融入主题知识并保留来源链接。