muse-agent-example/.agent/规范/审查标准.md

提示词与技能审查标准

状态：生效规范
适用范围：.agent/agents/*.md（角色提示词）与 muse/lifecycle/quality/harness/manifests/skills.json 登记的 Skill 包
门禁工具：muse/lifecycle/quality/harness/skill_harness.py 与 test_skill_harness.py

新增、修改或定期复核任何智能体提示词与技能时，按本规范逐条审查。

核心原则：一份提示词、一个技能只服务一个明确意图；与意图无关的词、约束、机制都是污染——它让执行者分心，也让合同两张皮。

---

1. 智能体提示词审查标准（.agent/agents/*.md 与角色系统提示词）

角色稳定合同以 角色合同 为唯一事实源。角色文件可以包含面向智能体的身份、技能路由、推荐工具能力和工作方法；审查硬边界、模型策略、实际工具权限和结构化输出时以中心合同与适配器为准。

审查时逐条核验四个问题：

1. 面对谁：这份提示词读给哪个模型/角色？它只该有这一个身份，不该同时背「执行器/评测器/审查器」之类第二身份。
2. 每个词都有意义吗：逐词问——它对「这个角色干好本业」有用吗？框架名、schema 名、字段名、运行身份、哈希、评测状态这类机器词，对创作/规划/抽取/检测等本体任务毫无意义，是其它层的泄漏，应予剔除。
3. 约束是该有的限制吗：每条约束问——它是角色意图本身需要的，还是支架（harness）本就能强制的？输出格式由结构化输出 Schema 强制、实际工具可用性由调用参数强制、盲化由「输入里压根没有该信息」保证；角色文件可以解释技能和工具的用途，但不能把提示文字当权限或结构门。
4. 正向与负向：分清哪些部分帮角色达成意图（正向：本业纪律、领域边界、知情范围），哪些妨碍它（负向：与本业无关的机器约束、诱导照搬输入原文的措辞、让模型惦记评测的暗示）。负向部分删除或移到对应层。

反例与正解：

• 反例（已纠正）：评测写手提示词曾塞入「你是 Gate A 离线回放的 writer…只输出 candidateBody…不输出哈希/身份…不访问 MCP」，把评测支架混进创作提示词——既没有写作指导，又诱导写手照抄细纲概述句。
• 正解：角色文件保留写作方法、技能路由和工具用途；输出格式、实际工具权限、盲化和证据绑定交给中心合同、Schema 与适配器。

---

2. 技能审查标准（Skill Review）

分类取值、八个评分维度、必备节清单和严重度定义的权威是 skill-quality-rubric.md。审查必须先跑机械门，再人工审，严禁用机械门跑绿代替人工判断：

# 静态审计门禁（阻断项与质量发现一并必须为零）
.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict

# 审计器回归测试
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q

人工逐条核验以下问题（括号内为对应质量维度）：

1. 给谁用：消费者必须明确、单一——主会话编排、某个角色智能体，还是别的技能。只能由编排调用的必须声明 orchestrated；"不得由 Agent 自行触发"这类禁令写在散文里不算数。
2. 该用时会不会被用上（D1，只对 model_routed 适用）：description 是模型唯一的路由依据，必须写清做什么、何时用、何时不用，并对易混的技能点名交接。
3. 目的单一（D2）：一个技能只实现一个能力。功能并列、又当编排又当执行的，必须拆分。
4. 边界不重叠（D3）：显式写出不做什么；集合内不得存在未声明的职责重叠。
5. 合同完整（D4）：必备节按分类裁剪；scripts/ 只放运行时确定性实现与机械门，测试归 tests/skills/，清单与模板归 references/。
6. 可靠性与失败关闭（D5）：失败明确关闭，不静默降级、不返回假成功；错误带稳定码、不泄漏原文与密钥；确定性步骤真不调模型；走 .venv，不裸调数据库、接口或模型。
7. 机制优先与边界一致（D6、D7）：能由 frontmatter、schema、adapter 或 scripts/ 强制的约束不写成散文叮嘱；引用的路径、合同、字段与现行 SoT 一致，引用已失效合同的不得执行；SKILL.md 只留执行时必须常驻的内容。
8. 用过之后系统有没有更强（D8，lifecycle ≠ platform 适用）：本次的方法与观察有没有沉淀成库内可被后续运行消费的资产（范式卡、规则、声音账、经验登记），还是用完即散。

命名与标识纪律

• 目录名必须等于 frontmatter name。
• 执行动作的系统能力技能命名采用小写 动作-对象，表达可调用能力，不复用 scenario 或含混阶段词。
• 创作方法技能采用小写领域名（如 scene-craft、narration-pov）。
• scenario、source_type、updater 和备份逻辑键是独立稳定标识，不随技能改名而随意变动。

---

3. 审查产出规范

每次审查对每个被审对象必须给出标准化产出：

1. 面对谁 / 目的：明确调用方与核心功能定位。
2. 逐条问题清单：按正向资产与负向污染分类，并逐条标注严重度（阻断 / 严重 / 一般）。
3. 具体修改建议：给出明确的重构或裁剪方案。

严重度定义：

• 阻断（Blocker）：存在维度 0 分项、违背红线、导致假绿或破坏数据一致性，必须立即修复才能合入。
• 严重（Major）：职责重叠、提示词泄漏、缺少机制约束等影响系统健壮性的问题。
• 一般（Minor）：措辞冗余、格式微调、非关键参考文档链接失效等。

审查过程只读、不直接改代码；修改需另行取得授权，框架改动与创作内容分开提交。