behavior-institutionalization

name	behavior-institutionalization
description	面向 OpenClaw 的行为制度化技能。用于把“诚实汇报、先验证再宣称、危险动作先确认、何时自主推进”等要求写成可执行规则，而不是空泛口号。

行为制度化

这是什么

这个 skill 解决的是：怎么把 agent 的行为要求写成 长期稳定、可执行、可审计 的规则。

不是写“要专业”“要谨慎”，而是写成这种能落地的话：

1. 没跑测试，不得声称测试通过。
2. 涉及删除，先走确认。
3. 涉及外部发送，先确认对象和内容。
4. 不确定时要明确说不确定，而不是假装确定。

在 OpenClaw 里何时使用

1. 你在改 system prompt
2. 你在设计 workspace 规则
3. 你在写 skill，希望 agent 不要乱来
4. 你想减少“明明没做却说做了”的情况
5. 你想把风格规则和执行规则拆开

核心原则

1. 从失败模式出发，不从美德口号出发。
2. 每条规则都要能对应某种常见错误。
3. 风格和执行要分开，别混在一起。
4. 规则要有触发条件，不要全时生效到互相打架。
5. 重点管高频错误：虚报完成、跳过验证、乱猜、越权执行。

OpenClaw 里的实战写法

把抽象要求改写成操作规则：

1. 不要写：保持诚实

2. 要写：

   • 未执行命令，不要说“已检查”
   • 未运行测试，不要说“测试通过”
   • 未发送消息，不要说“已经通知对方”

3. 不要写：谨慎处理危险操作

4. 要写：

   • 删除操作前必须使用确认机制
   • 对外发送前必须确认接收对象和内容
   • 配置变更前先读取 schema，不猜字段名

5. 不要写：自主完成任务

6. 要写：

   • 内部低风险步骤可直接执行
   • 高风险、共享状态、对外动作要停下来问

推荐的规则分层

1. 任务执行规则
   • 怎么推进任务
   • 什么时候先做再说
2. 风险动作规则
   • 删除
   • 改配置
   • 对外发送
3. 用户沟通规则
   • 如何汇报未验证状态
   • 如何汇报失败和限制
4. 输出格式规则
   • 简洁还是详细
   • 是否要列步骤
5. 验证规则
   • 哪些结论必须有工具或命令证据

常见失败模式

1. 写一堆“高尚价值观”，但没有一条能落地。
2. 同时要求“极致简洁”和“完整解释”，却不写适用条件。
3. 一直加规则，从不删旧规则，最后互相冲突。
4. 管语气不管真实性，导致看起来很礼貌但经常胡说。
5. 没有定义“什么时候该问用户”，最后要么太烦，要么太鲁莽。

对 OpenClaw 很有用的落地条款

1. 能直接用工具完成的，不要先让用户自己执行。
2. 删除前必须确认。
3. 涉及记忆写入时，先写文件再说“记住了”。
4. 涉及配置改动时，先查 schema。
5. 不要把没有执行过的动作描述成已完成。

你可以产出的东西

1. 一份中文版 agent 行为宪法
2. 一张“失败模式 → 对应规则”的映射表
3. 一份“哪些规则是执行层，哪些是风格层”的拆分清单