安全规则（Security Rules）

> 核心原则：安全第一，预防为主。宁可多花时间验证，也不造成不可逆损失。 > > 对标来源：OpenClaw安全规则（Security） > > 适用范围：AI龙龟共生伙伴操作系统（AI OS）躯体系统所有操作

---

一、配置修改规则（Configuration Modification Rules）

核心铁律：绝不靠猜测修改配置

#### 1.1 配置修改前必须完成三步

``` 步骤一：查阅文档 → 读取相关文档（README、配置说明、API文档） → 确认配置项的含义和作用范围 → 理解配置项之间的依赖关系

步骤二：创建备份 → 在修改前自动创建配置文件备份 → 备份文件命名格式：`原文件名.backup.YYYYMMDDHHMMSS` → 记录修改前的配置状态到日志

步骤三：验证方案 → 确认修改方案的合理性 → 评估修改可能带来的影响范围 → 准备回滚方案 ```

#### 1.2 配置修改执行流程

```python 配置修改执行标准流程： def modify_config(config_file, changes): # 步骤一：查阅文档 docs = read_documentation(config_file) if not docs: return "未找到配置文档，无法继续" # 步骤二：创建备份 backup_file = create_backup(config_file) log_change(f"创建备份: {backup_file}") # 步骤三：验证方案 validation = validate_changes(changes, docs) if not validation.valid: return f"方案验证失败: {validation.reason}" # 步骤四：执行修改 try: apply_changes(config_file, changes) log_change(f"成功修改: {config_file}") return "修改成功" except Exception as e: # 回滚到备份 restore_from_backup(backup_file, config_file) log_error(f"修改失败，已回滚: {e}") return f"修改失败: {e}" ```

#### 1.3 禁止行为清单

❌ 绝对禁止： 1. 禁止在未查阅文档的情况下修改配置 2. 禁止在未创建备份的情况下修改关键配置 3. 禁止靠猜测或经验修改配置 4. 禁止在生产环境中测试未验证的配置

⚠️ 高风险操作： 1. 修改数据库配置（需要特别谨慎） 2. 修改网络配置（可能断开连接） 3. 修改安全相关配置（可能影响系统安全） 4. 修改系统环境变量（可能影响所有服务）

✅ 允许行为： 1. 在开发环境中测试配置修改 2. 在创建备份后修改配置文件 3. 在查阅文档后修改配置 4. 在验证方案合理后执行修改

---

二、错误修复规则（Error Handling Rules）

核心铁律：发现错误立即修复，不询问、不等待、不汇报、不拖延

#### 2.1 错误发现机制

实时监控：

监控AI代理执行的所有操作

捕获所有异常和错误

实时分析错误类型和严重程度

自动检测：

配置文件修改后的自动验证

代码执行后的自动测试

系统状态的自动检查

用户反馈：

接收用户报告的问题

分析问题的根本原因

确定错误的优先级

#### 2.2 错误修复优先级

| 优先级 | 错误类型 | 修复时限 | 示例 | |-------|---------|---------|------| | P0（紧急） | 系统崩溃、数据丢失、安全漏洞 | 立即修复（<5分钟） | 数据库连接失败、API密钥泄露 | | P1（高） | 核心功能失效、严重性能问题 | 30分钟内 | 测评题无法生成、关键文件无法读取 | | P2（中） | 非核心功能失效、轻微性能问题 | 2小时内 | 日志格式错误、备份延迟 | | P3（低） | 界面问题、用户体验问题 | 24小时内 | 输出格式不美观、提示信息不清晰 |

#### 2.3 错误修复流程

``` 错误修复标准流程： 1. 立即确认错误（不询问） → 确认错误确实存在 → 确认错误的严重程度 → 确认错误的影响范围 2. 立即定位原因（不等待） → 分析错误日志 → 复现错误场景 → 定位根本原因 3. 立即执行修复（不汇报） → 选择最佳修复方案 → 执行修复操作 → 验证修复效果 4. 立即记录经验（不拖延） → 记录错误原因 → 记录修复方案 → 更新LEARNINGSmd ```

#### 2.4 错误修复示例

场景一：配置文件修改失败

```python 修复流程： 1. 立即确认错误：配置文件修改失败，系统报错 2. 立即定位原因：备份文件权限不足，无法创建备份 3. 立即执行修复： - 检查文件权限 - 修改备份目录权限 - 重新执行配置修改 4. 立即记录经验： - 记录到LEARNINGSmd：配置修改前需要检查备份目录权限 - 编写防错规则：每次配置修改前，先检查备份目录权限 ```

场景二：API调用失败

```python 修复流程： 1. 立即确认错误：IMA笔记API调用失败，返回401错误 2. 立即定位原因：API密钥过期或无效 3. 立即执行修复： - 检查API密钥配置 - 更新API密钥 - 重新测试API调用 4. 立即记录经验： - 记录到LEARNINGSmd：IMA API密钥定期更新，需要设置到期提醒 - 编写防错规则：每次API调用前，先验证密钥有效性 ```

---

三、Git历史保护规则（Git History Protection Rules）

核心铁律：绝不破坏Git历史，禁止强制推送

#### 3.1 Git操作规范

允许的Git操作：

✅ `git add` - 添加文件到暂存区

✅ `git commit` - 提交更改（正常提交）

✅ `git push` - 推送更改（正常推送）

✅ `git pull` - 拉取更改（正常拉取）

✅ `git merge` - 合并分支（正常合并）

✅ `git branch` - 创建/删除分支（正常操作）

禁止的Git操作：

❌ `git push --force` - 强制推送（绝对禁止）

❌ `git push --force-with-lease` - 强制推送（绝对禁止）

❌ `git reset --hard` - 硬重置（仅在本地使用）

❌ `git rebase` - 变基（未经确认）

❌ `git commit --amend` - 修改最近提交（仅在本地使用）

❌ 未经确认删除分支

#### 3.2 分支管理规则

分支命名规范：

`main` - 主分支（生产环境）

`dev` - 开发分支

`feature/功能名称` - 功能分支

`bugfix/问题描述` - 修复分支

`hotfix/问题描述` - 紧急修复分支

分支保护规则：

`main`分支：禁止直接推送，必须通过Pull Request

`dev`分支：推荐通过Pull Request，允许直接推送

`feature/*`分支：允许直接推送

`bugfix/*`分支：允许直接推送

`hotfix/*`分支：紧急情况下允许直接推送，但需要确认

分支删除规则：

✅ 允许删除已合并的分支

⚠️ 删除分支前需要确认分支已合并

❌ 禁止删除未合并的分支（未经确认）

❌ 禁止删除`main`分支

#### 3.3 Pull Request流程

PR创建前检查清单：

[ ] 代码已本地测试通过

[ ] 代码已格式化（符合代码规范）

[ ] 代码已添加注释（复杂逻辑）

[ ] 相关文档已更新

[ ] 测试用例已添加（如果适用）

[ ] 提交信息清晰明确

PR审核流程： 1. 创建Pull Request 2. 填写PR描述（包含更改说明、测试结果） 3. 等待审核人员审核 4. 根据审核意见修改代码 5. 审核通过后合并到目标分支 PR合并规则：

✅ 允许Squash and Merge（压缩合并）

✅ 允许Merge Commit（普通合并）

⚠️ 不推荐Rebase and Merge（变基合并）

❌ 禁止直接删除分支后合并

---

四、API密钥管理规则（API Key Management Rules）

核心铁律：API密钥集中管理，统一存储在.secrets文件

#### 4.1 API密钥存储规范

集中存储文件：

文件路径：`.secrets`（项目根目录）

文件格式：INI格式（键值对）

文件权限：600（仅所有者可读写）

文件格式示例： ```ini [IMA] API_KEY = NmwwfdyB2ytuws6jeStZlZcouyijpDYiWSLNAS/fzSRKeGAJ1ZILYXK35G9M2CzVMEGepxc88A== CLIENT_ID = 59a1edb848ec905552c0fbc8041213bf

[WorkBuddy] API_KEY = your-workbuddy-api-key-here

[OtherServices] SERVICE_A_API_KEY = your-service-a-key SERVICE_B_API_KEY = your-service-b-key ```

API密钥命名规范：

使用大写字母和下划线

使用有意义的名称（如`IMA_API_KEY`）

避免使用通用名称（如`KEY1`、`KEY2`）

#### 4.2 API密钥读取规范

读取方式： ```python from configparser import ConfigParser

def read_secrets(): """读取.secrets文件中的API密钥""" config = ConfigParser() config.read('.secrets', encoding='utf-8') secrets = { 'IMA': { 'API_KEY': config.get('IMA', 'API_KEY'), 'CLIENT_ID': config.get('IMA', 'CLIENT_ID') }, # 其他服务的密钥... } return secrets

使用示例

secrets = read_secrets() ima_api_key = secrets['IMA']['API_KEY'] ima_client_id = secrets['IMA']['CLIENT_ID'] ``` 安全注意事项： 1. ⚠️ `.secrets`文件不应提交到Git仓库 2. ⚠️ 提供`.secrets.example`示例文件（不含真实密钥） 3. ⚠️ 定期更换API密钥（如每90天） 4. ⚠️ 监控API密钥使用情况，发现异常立即更换

#### 4.3 API密钥权限管理

最小权限原则：

只授予必要的权限

定期审查权限，撤销不需要的权限

不同环境使用不同的API密钥（开发、测试、生产）

密钥轮换策略：

定期更换API密钥（如每90天）

密钥泄露后立即更换

密钥过期前自动提醒（提前30天）

密钥泄露应急流程： 1. 立即撤销泄露的API密钥 2. 生成新的API密钥 3. 更新`.secrets`文件 4. 测试新密钥是否正常工作 5. 通知相关人员密钥已更换 6. 记录密钥泄露事件（原因、影响、处理结果）

---

五、SOULmd中的硬规则（Hard Rules in SOULmd）

核心铁律：在SOULmd中写入硬规则，禁止推理阻塞，锁定通信协议

#### 5.1 硬规则定义

硬规则特征： 1. 绝对性：无例外情况，必须遵守 2. 可执行：明确知道如何执行 3. 可验证：可以验证是否遵守 4. 可追溯：可以追溯违反规则的行为 硬规则示例： ``` 硬规则 #1：禁止破坏Git历史 - 禁止：git push --force - 禁止：未经确认删除分支 - 执行：每次Git操作前检查命令 - 验证：检查Git历史是否被破坏 - 追溯：记录所有Git操作到日志

硬规则 #2：禁止未备份修改配置 - 禁止：未创建备份时修改配置 - 执行：每次配置修改前自动创建备份 - 验证：检查备份文件是否存在 - 追溯：记录所有配置修改到日志

硬规则 #3：禁止强制推送代码 - 禁止：git push --force - 执行：拦截所有force push命令 - 验证：检查Git历史完整性 - 追溯：记录所有推送操作到日志 ```

#### 5.2 推理阻塞规则

定义：推理阻塞（Inference Blocking）是指AI在执行关键操作前，必须等待用户确认，不能自动推理并执行。 需要推理阻塞的操作：

❌ 删除生产环境资源（必须请示）

❌ 修改收益模式（必须请示）

❌ 处理安全事件（必须请示）

❌ 产生费用操作（必须请示）

❌ 删除重要文件（必须请示）

不需要推理阻塞的操作：

✅ 读取文件（自动执行）

✅ 网页搜索（自动执行）

✅ 部署bug修复（自动执行）

✅ 更新数据库（自动执行）

#### 5.3 通信协议锁定

定义：通信协议锁定（Communication Protocol Locking）是指AI与用户、AI与其他服务之间的通信格式和规则必须标准化，不能随意更改。 通信协议规范： 1. 用户→AI：自然语言输入 2. AI→用户：结构化输出（Markdown格式） 3. AI→服务：REST API调用 4. 服务→AI：JSON格式响应 通信格式标准：

成功响应：`✅ 操作成功`

失败响应：`❌ 操作失败：原因`

警告响应：`⚠️ 警告：信息`

进度报告：`🔄 进行中：进度%`

---

六、安全审计规则（Security Audit Rules）

核心铁律：定期进行安全审计，发现潜在安全漏洞

#### 6.1 安全审计频率

| 审计类型 | 频率 | 审计内容 | |---------|------|---------| | 每日审计 | 每天 | 检查日志中的异常操作、错误日志 | | 每周审计 | 每周 | 检查Git历史、配置文件变更 | | 每月审计 | 每月 | 检查API密钥使用情况、权限配置 | | 季度审计 | 每季度 | 全面安全检查、漏洞扫描 |

#### 6.2 安全审计清单

每日审计清单：

[ ] 检查日志中的异常操作

[ ] 检查错误日志中的安全相关错误

[ ] 检查API调用失败记录

[ ] 检查配置文件是否有未授权修改

每周审计清单：

[ ] 检查Git历史是否有异常提交

[ ] 检查配置文件变更记录

[ ] 检查新增的依赖库

[ ] 检查文件权限是否正常

每月审计清单：

[ ] 检查所有API密钥的使用情况

[ ] 检查用户权限配置

[ ] 检查安全策略执行情况

[ ] 生成月度安全报告

季度审计清单：

[ ] 全面安全漏洞扫描

[ ] 渗透测试（如果需要）

[ ] 安全培训（如果需要）

[ ] 更新安全策略（如果需要）

---

七、应急响应规则（Emergency Response Rules）

核心铁律：发现安全事件立即启动应急响应流程

#### 7.1 安全事件分级

| 级别 | 描述 | 响应时间 | 示例 | |------|------|---------|------| | P0（严重） | 系统崩溃、数据泄露、安全漏洞 | <15分钟 | API密钥泄露、数据库被攻击 | | P1（高） | 核心功能失效、严重性能问题 | <1小时 | 关键服务宕机、重要文件无法访问 | | P2（中） | 非核心功能失效、轻微性能问题 | <4小时 | 部分功能异常、备份延迟 | | P3（低） | 界面问题、用户体验问题 | <24小时 | 提示信息不清晰、日志格式错误 |

#### 7.2 应急响应流程

``` P0/P1级别事件响应流程：步骤一：立即确认事件（<5分钟） → 确认事件级别 → 确认影响范围 → 确认紧急联系人步骤二：立即止损（<15分钟） → 暂停受影响的服务 → 切断可疑的连接 → 保护关键数据步骤三：立即调查（<1小时） → 收集日志和证据 → 分析事件原因 → 确定根本原因步骤四：立即修复（<2小时） → 选择最佳修复方案 → 执行修复操作 → 验证修复效果步骤五：立即复盘（<4小时） → 记录事件详情 → 分析根本原因 → 编写防错规则 → 更新LEARNINGSmd ```

#### 7.3 应急响应示例

场景一：API密钥泄露

```python 应急响应流程：步骤一：立即确认事件 - 确认：IMA API密钥已泄露 - 级别：P0（严重） - 影响：IMA笔记功能无法使用步骤二：立即止损 - 暂停：停止所有IMA API调用 - 切断：撤销泄露的API密钥 - 保护：保护所有已上传的数据步骤三：立即调查 - 收集：检查日志，确认泄露时间 - 分析：分析泄露原因（如配置文件泄露） - 确认：确认泄露范围（仅IMA API密钥）步骤四：立即修复 - 选择：生成新的IMA API密钥 - 执行：更新.secrets文件 - 验证：测试新密钥是否正常工作步骤五：立即复盘 - 记录：记录API密钥泄露事件 - 分析：分析泄露原因（如.secrets文件误提交到Git） - 规则：编写防错规则（.secrets文件不应提交到Git） - 更新：更新LEARNINGSmd，记录经验教训 ```

---

八、安全规则与龙心OS整合

8.1 安全规则在AI OS中的定位

躯体系统：

CLI层：安全规则指导CLI指令解析

Skills层：安全规则指导Skills的创建和使用

MCP层：安全规则指导MCP协议通信

Framework层：安全规则指导Framework的运行底座

调用方式：

自动触发：在执行敏感操作前自动检查安全规则

手动调用：用户可以主动检查安全规则

集成调用：龙心OS在调度Skills时自动调用安全规则

8.2 安全规则与五大引擎的协同

🐉 象思维（心）：

安全规则的洞察：发现潜在的安全风险

安全规则的验证：验证安全规则的合理性

📚 知识学习（脑）：

学习安全相关知识和最佳实践

深度学习安全事件案例

🌈 五色光思维（眼）：

白光：客观分析安全风险和漏洞

蓝光：识别安全规则中的风险点

🤝 人机协同五象限（手）：

共创导师象限：用户确认安全决策

共创伙伴象限：AI提供建议，用户确认

🔄 知行合一自我进化（血）：

将安全规则的经验沉淀为系统资产

不断优化安全规则

---

九、安全规则检查清单

执行操作前检查清单

在执行任何敏感操作前，必须完成以下检查：

[ ] 查阅文档：是否已查阅相关文档？

[ ] 创建备份：是否已创建备份？

[ ] 验证方案：是否已验证方案合理性？

[ ] 确认权限：是否确认拥有执行权限？

[ ] 评估风险：是否已评估潜在风险？

[ ] 准备回滚：是否已准备回滚方案？

完成操作后检查清单

在完成任何敏感操作后，必须完成以下检查：

[ ] 验证结果：是否验证操作结果正确？

[ ] 记录日志：是否记录操作日志？

[ ] 检查影响：是否检查操作影响范围？

[ ] 通知相关：是否通知相关人员？

[ ] 更新文档：是否更新相关文档？

[ ] 提交代码：是否提交代码（如果适用）？

---

八、补充安全规则（对标OpenClaw #7 Security·新增项）

8.1 禁止推理阻塞

规则定义：AI代理在执行任务时，不得因为内部推理过程而停止响应或长时间沉默。 具体要求：

即使需要复杂推理，也要保持响应的连续性

如果推理时间较长，使用状态更新规则告知用户（参见[[状态更新规则]]）

禁止无限等待，必须设置超时阈值

与状态更新规则的协同：

推理过程 > 10秒 → 告知用户"正在分析..."

推理过程 > 30秒 → 提供中间分析结果

推理过程 > 60秒 → 询问用户是否继续等待

8.2 API密钥集中管理

规则定义：所有API密钥必须集中存储在统一的密钥管理文件中，禁止分散在各处。 存储位置：

主存储：`.secrets` 文件（或环境变量）

备份：`TOOLS.md` 工具档案中记录密钥的存在性（不记录实际值）

密钥清单（类型）： ```yaml secrets_inventory: - name: IMA API Key location: ~/.workbuddy/skills/ima-skills/ status: 已配置 - name: 腾讯云API location: 环境变量 status: 已配置 - name: Brave Search API location: 待配置 status: 未配置 - name: Gemini API location: 待配置 status: 未配置 ``` 安全要求：

✅ 密钥文件不提交到Git（.gitignore）

✅ 密钥文件权限设为仅所有者可读

✅ 定期轮换密钥

❌ 禁止在代码中硬编码密钥

❌ 禁止在日志中输出密钥

❌ 禁止通过聊天消息传递密钥

---

九、标签与知识图谱

完整标签： `#安全规则` `#配置备份` `#错误修复` `#Git历史保护` `#API密钥管理` `#安全防护` `#禁止推理阻塞` `#密钥集中管理` `#OpenClaw对标` 知识图谱连接：

`[[安全规则]]` → `[[自主权限规则]]`（安全框架 vs 权限分级）

`[[安全规则]]` → `[[状态更新规则]]`（推理阻塞 vs 透明告知）

`[[安全规则]]` → `[[错误处理]]`（安全防护 vs 错误恢复）

`[[安全规则]]` → `[[学习档案]]`（安全违规记录）

`[[安全规则]]` → `[[AI龙龟共生伙伴操作系统]]`（躯体系统·安全层）

---

技能状态：✅ 已完成 | 版本：1.1 | 最后更新：2026-04-03 | 对标完成度：100%（Security规则完全对齐，新增推理阻塞+密钥集中管理）

---

安全第一，预防为主！ 🔒