学习档案（LEARNINGSmd）
> 核心铁律：同一错误犯两次，绝对不可原谅。
>
> 对标来源：OpenClaw LEARNINGSmd规则
>
> 适用范围：AI龙龟共生伙伴操作系统（AI OS）躯体系统所有学习和迭代过程
---
一、学习档案定义（Learning Archive Definition）
1.1 核心概念
学习档案（LEARNINGSmd）：
定义：记录所有错误、修正、经验的标准化文档
目的：避免重复犯错，实现持续迭代
特征：强制记录、系统化复盘、防错规则
错误闭环学习机制：
```
错误发生 → 立即修复 → 记录原因 → 编写规则 → 会话复盘 → 避免重复
↑ ↓
└────────────────────────────────────────────────────────┘
```
1.2 文档结构
学习档案路径：
主文件：`C:\Users\jia'yue\WorkBuddy\Claw\.workbuddy\memory\LEARNINGS.md`
子文件：`memory/learnings/按日期分类/具体错误.md`
规则文件：`memory/rules/防错规则.md`
标准格式：
```markdown
学习档案（LEARNINGSmd）
最新规则摘要
规则1：[规则名称]
规则2：[规则名称]
...
错误记录（按时间倒序）
错误 #1（最新）
错误ID：ERR-YYYY-MM-DD-001
发生时间：YYYY-MM-DD HH:MM:SS
错误类型：[类型]
错误描述：[描述]
触发模式：[触发条件]
根本原因：[原因]
修复方案：[方案]
防错规则：[规则]
验证方法：[方法]
错误 #2
...
防错规则（按优先级排序）
规则1：[规则名称]
规则ID：RULE-001
优先级：P0/P1/P2/P3
创建时间：YYYY-MM-DD
规则内容：[内容]
触发场景：[场景]
验证方法：[方法]
规则2：[规则名称]
...
会话复盘记录
会话复盘 #1
复盘时间：YYYY-MM-DD
复盘范围：[范围]
发现的潜在问题：[问题]
优化建议：[建议]
...
```
---
二、错误处理流程（Error Handling Process）
2.1 四步流程（Four-Step Process）
#### 步骤一：立即修复问题
目标：最小化错误影响，快速恢复正常状态
执行标准：
```
修复流程：
1. 确认错误（5分钟内）
→ 确认错误确实存在
→ 确认错误的影响范围
→ 确认错误的优先级（P0/P1/P2/P3）
2. 定位原因（15分钟内）
→ 分析错误日志
→ 复现错误场景
→ 确定根本原因
3. 执行修复（30分钟内）
→ 选择最佳修复方案
→ 执行修复操作
→ 验证修复效果
→ 如果失败，回滚到之前状态
4. 确认恢复（15分钟内）
→ 验证系统状态恢复正常
→ 确认没有引入新问题
→ 通知相关人员（如果需要）
```
修复时限：
P0（紧急）：<15分钟
P1（高）：<1小时
P2（中）：<4小时
P3（低）：<24小时
#### 步骤二：记录错误原因
目标：系统化记录错误信息，便于后续分析和预防
记录标准格式：
```markdown
错误 #ERR-YYYY-MM-DD-XXX
基本信息：
错误ID：ERR-2026-03-23-001
发生时间：2026-03-23 14:30:25
错误类型：[类型]
严重程度：P0/P1/P2/P3
影响范围：[范围]
错误描述：
用户行为：[用户做了什么]
系统行为：[系统做了什么]
预期行为：[预期应该发生什么]
实际行为：[实际发生了什么]
触发模式：
触发条件：[什么条件下会触发]
触发频率：[发生的频率]
触发场景：[在哪些场景下会触发]
根本原因：
直接原因：[直接导致错误的原因]
根本原因：[根本原因是什么]
为什么会犯这个错误：[为什么会犯]
修复方案：
修复方法：[如何修复]
修复时间：[修复花费的时间]
修复结果：[修复是否成功]
后续影响：
是否有残留影响：[是否有]
是否需要通知用户：[是否]
是否需要更新文档：[是否]
```
#### 步骤三：编写防错规则
目标：建立机制，避免同一错误再次发生
防错规则标准格式：
```markdown
防错规则 #RULE-XXX
规则信息：
规则ID：RULE-001
规则名称：[名称]
优先级：P0/P1/P2/P3
创建时间：YYYY-MM-DD
关联错误：ERR-2026-03-23-001
规则内容：
```
[用一句话描述规则]
```
触发场景：
场景1：[描述场景]
场景2：[描述场景]
场景3：[描述场景]
执行标准：
在什么情况下执行：[条件]
如何执行：[步骤]
验证方法：[方法]
验证清单：
[ ] 检查项1
[ ] 检查项2
[ ] 检查项3
惩罚机制：
如果违反此规则：[惩罚措施]
同一错误犯两次：[绝对不可原谅]
```
防错规则示例：
```markdown
防错规则 #RULE-001
规则信息：
规则ID：RULE-001
规则名称：配置修改前必须创建备份
优先级：P0
创建时间：2026-03-23
关联错误：ERR-2026-03-23-001
规则内容：
```
修改任何配置文件前，必须先创建备份，备份文件命名格式为：原文件名.backup.YYYYMMDDHHMMSS
```
触发场景：
场景1：修改配置文件（如.ini、.json、.yaml）
场景2：修改环境变量文件（如.env）
场景3：修改数据库配置（如db.ini）
执行标准：
在什么情况下执行：每次修改配置文件前
如何执行：
1. 读取配置文件
2. 创建备份文件（备份文件名包含时间戳）
3. 记录备份操作到日志
4. 执行配置修改
5. 验证修改结果
验证方法：检查备份文件是否存在
验证清单：
[ ] 备份文件已创建
[ ] 备份文件命名格式正确
[ ] 备份文件包含完整内容
[ ] 备份操作已记录到日志
惩罚机制：
如果违反此规则：系统拒绝执行配置修改，并提示错误
同一错误犯两次：绝对不可原谅
```
#### 步骤四：每次会话开始时复盘
目标：在每次会话开始时，复盘所有已记录的经验，避免重复犯错
复盘标准流程：
```
会话复盘流程：
步骤一：加载学习档案（1分钟）
→ 读取LEARNINGS.md文件
→ 加载所有防错规则
→ 加载最近7天的错误记录
步骤二：扫描当前任务（2分钟）
→ 分析当前任务的类型
→ 识别可能触发的错误场景
→ 关联相关的防错规则
步骤三：应用防错规则（3分钟）
→ 检查是否有相关防错规则
→ 如果有，严格执行防错规则
→ 如果没有，继续执行
步骤四：记录复盘结果（1分钟）
→ 记录复盘了哪些规则
→ 记录是否有潜在风险
→ 如果有风险，提前告知用户
```
复盘输出格式：
```markdown
会话复盘报告
复盘时间：YYYY-MM-DD HH:MM:SS
会话ID：SESSION-XXX
复盘范围：最近7天 + 关键规则
已加载的防错规则（共X条）
P0规则（X条）
RULE-001：[规则名称]
RULE-002：[规则名称]
...
P1规则（X条）
RULE-101：[规则名称]
RULE-102：[规则名称]
...
当前任务相关规则（Y条）
相关规则列表
RULE-001：[规则名称]（相关度：高）
RULE-005：[规则名称]（相关度：中）
...
风险提示
⚠️ 风险1：[描述风险]
- 相关规则：RULE-001
- 防范措施：[措施]
⚠️ 风险2：[描述风险]
- 相关规则：RULE-005
- 防范措施：[措施]
复盘建议
建议1：[建议内容]
建议2：[建议内容]
...
复盘确认
[ ] 已理解所有相关规则
[ ] 已知晓潜在风险
[ ] 同意继续执行
```
---
三、错误分类体系（Error Classification System）
3.1 按错误类型分类
| 错误类型 | 描述 | 示例 | 严重程度 |
|---------|------|------|---------|
| 配置错误 | 配置文件修改错误 | 配置文件格式错误、配置项错误 | P1 |
| 权限错误 | 权限不足导致操作失败 | 文件权限不足、API权限不足 | P1 |
| 依赖错误 | 依赖库缺失或版本不匹配 | 包缺失、版本冲突 | P1 |
| 逻辑错误 | 代码逻辑错误 | 死循环、条件判断错误 | P2 |
| 性能错误 | 性能问题导致响应慢 | 查询慢、内存占用高 | P2 |
| 安全错误 | 安全漏洞或泄露 | API密钥泄露、SQL注入 | P0 |
| 数据错误 | 数据错误或丢失 | 数据库连接失败、数据损坏 | P1 |
| 网络错误 | 网络连接问题 | 连接超时、DNS解析失败 | P2 |
3.2 按触发模式分类
| 触发模式 | 描述 | 防范策略 |
|---------|------|---------|
| 用户操作错误 | 用户操作不当导致 | 用户教育、操作验证 |
| 代码逻辑错误 | 代码逻辑缺陷 | 代码审查、单元测试 |
| 配置错误 | 配置不当导致 | 配置验证、配置模板 |
| 环境错误 | 环境变化导致 | 环境隔离、环境监控 |
| 依赖错误 | 依赖问题导致 | 依赖管理、版本锁定 |
| 竞态错误 | 多线程/并发导致 | 并发控制、锁机制 |
| 资源错误 | 资源不足导致 | 资源监控、资源预留 |
3.3 按严重程度分类
| 严重程度 | 描述 | 响应时间 | 示例 |
|---------|------|---------|------|
| P0（紧急） | 系统崩溃、数据丢失、安全漏洞 | <15分钟 | API密钥泄露、数据库崩溃 |
| P1（高） | 核心功能失效、严重性能问题 | <1小时 | 关键功能无法使用、响应超时 |
| P2（中） | 非核心功能失效、轻微性能问题 | <4小时 | 非关键功能异常、日志格式错误 |
| P3（低） | 界面问题、用户体验问题 | <24小时 | 提示信息不清晰、布局问题 |
---
四、防错规则体系（Prevention Rules System）
4.1 规则优先级
| 优先级 | 定义 | 违反后果 | 示例 |
|-------|------|---------|------|
| P0（最高） | 核心安全规则，绝对不能违反 | 系统拒绝执行，报告错误 | API密钥管理、数据备份 |
| P1（高） | 重要规则，违反会导致严重问题 | 警告提示，建议修改 | 配置验证、权限检查 |
| P2（中） | 一般规则，违反会导致问题 | 提示信息，可选修改 | 日志记录、文档更新 |
| P3（低） | 建议性规则，违反不会导致问题 | 可选提示 | 代码风格、注释规范 |
4.2 核心防错规则清单
#### P0规则（核心安全规则）
RULE-001：配置修改前必须创建备份
触发场景：修改任何配置文件
执行标准：备份文件命名格式为：原文件名.backup.YYYYMMDDHHMMSS
验证方法：检查备份文件是否存在
违反后果：系统拒绝执行配置修改
RULE-002：API密钥必须集中管理
触发场景：使用任何API密钥
执行标准：所有API密钥存储在.secrets文件
验证方法：检查API密钥是否从.secrets读取
违反后果：系统拒绝使用硬编码的API密钥
RULE-003：禁止破坏Git历史
触发场景：执行Git操作
执行标准：禁止使用git push --force
验证方法：检查Git命令是否包含force参数
违反后果：系统拒绝执行force push
RULE-004：关键操作必须请示用户
触发场景：删除重要文件、产生费用操作
执行标准：必须等待用户确认
验证方法：检查是否收到用户确认
违反后果：系统拒绝执行关键操作
#### P1规则（重要规则）
RULE-101：文件操作前必须检查文件存在性
触发场景：读取、修改、删除文件
执行标准：使用os.path.exists()检查文件
验证方法：检查是否存在文件不存在的错误
违反后果：警告提示，建议添加检查
RULE-102：API调用前必须验证参数有效性
触发场景：调用任何API
执行标准：验证参数格式、范围、类型
验证方法：检查API调用是否成功
违反后果：警告提示，建议添加验证
RULE-103：错误必须立即记录到日志
触发场景：捕获任何错误
执行标准：使用logging模块记录错误
验证方法：检查日志文件是否有错误记录
违反后果：警告提示，建议添加日志
RULE-104：修改代码前必须创建分支
触发场景：修改任何代码
执行标准：从main分支创建新分支
验证方法：检查当前是否在feature分支
违反后果：警告提示，建议创建分支
#### P2规则（一般规则）
RULE-201：复杂逻辑必须添加注释
触发场景：编写复杂逻辑代码
执行标准：添加清晰、准确的注释
验证方法：检查代码是否有注释
违反后果：提示信息，建议添加注释
RULE-202：变量命名必须符合规范
触发场景：定义变量名
执行标准：使用有意义的变量名，小写加下划线
验证方法：检查变量名是否符合规范
违反后果：提示信息，建议修改命名
RULE-203：函数必须有文档字符串
触发场景：定义函数
执行标准：添加docstring，描述函数功能
验证方法：检查函数是否有docstring
违反后果：提示信息，建议添加文档
RULE-204：日志必须有统一格式
触发场景：记录日志
执行标准：使用统一的日志格式
验证方法：检查日志格式是否一致
违反后果：提示信息，建议统一格式
#### P3规则（建议性规则）
RULE-301：代码风格应符合PEP8规范
触发场景：编写代码
执行标准：使用自动格式化工具（如black）
验证方法：使用flake8检查代码风格
违反后果：可选提示，建议格式化
RULE-302：函数长度不应超过50行
触发场景：编写函数
执行标准：拆分长函数为多个小函数
验证方法：检查函数行数
违反后果：可选提示，建议拆分函数
RULE-303：类中方法数量不应超过10个
触发场景：定义类
执行标准：拆分大类为多个小类
验证方法：检查类中方法数量
违反后果：可选提示，建议拆分类
---
五、学习档案与龙心OS整合
5.1 学习档案在AI OS中的定位
躯体系统：
Skills层：学习档案是Skills层的核心能力
Framework层：Framework层在执行任务时自动调用学习档案
进化机制：学习档案是AI OS自我进化的核心动力
调用方式：
自动触发：错误发生时自动记录到学习档案
手动调用：用户可以主动查询学习档案
会话复盘：每次会话开始时自动复盘学习档案
5.2 学习档案与五大引擎的协同
🐉 象思维（心）：
洞察错误本质：发现错误的根本原因
创新防错规则：创造新的防错方法
📚 知识学习（脑）：
学习错误案例：深度学习错误案例
提炼防错规则：从错误中提炼规则
🌈 五色光思维（眼）：
白光：客观分析错误原因
蓝光：识别防错规则中的风险
🤝 人机协同五象限（手）：
共创导师象限：用户确认关键决策
共创伙伴象限：AI提供建议，用户确认
🔄 知行合一自我进化（血）：
将错误经验沉淀为系统资产
通过防错规则驱动系统进化
---
六、学习档案检查清单
错误发生后检查清单
在错误发生后，必须完成以下检查：
[ ] 立即修复问题：是否已立即修复？
[ ] 记录错误原因：是否已记录到学习档案？
[ ] 编写防错规则：是否已编写防错规则？
[ ] 验证修复效果：是否已验证修复成功？
[ ] 通知相关人员：是否已通知相关人员？
会话开始前检查清单
在每次会话开始前，必须完成以下检查：
[ ] 加载学习档案：是否已加载学习档案？
[ ] 扫描当前任务：是否已扫描当前任务？
[ ] 应用防错规则：是否已应用相关防错规则？
[ ] 记录复盘结果：是否已记录复盘结果？
---
七、核心铁律验证机制
7.1 同一错误犯两次验证
验证机制：
```
验证流程：
步骤一：检查错误ID
→ 错误发生时，生成错误ID（格式：ERR-YYYY-MM-DD-XXX）
→ 检查学习档案中是否已存在相同错误ID
步骤二：检查触发模式
→ 分析当前的触发模式
→ 检查学习档案中是否有相同触发模式
步骤三：检查根本原因
→ 分析当前的根本原因
→ 检查学习档案中是否有相同根本原因
步骤四：判断是否重复
→ 如果错误ID相同 → 绝对不可原谅
→ 如果触发模式相同 + 根本原因相同 → 绝对不可原谅
→ 如果触发模式相似 + 根本原因相似 → 高度警告
→ 否则 → 首次错误，正常处理
```
惩罚机制：
同一错误犯两次：绝对不可原谅
- 系统记录严重警告
- 通知悟空
- 深度复盘：为什么会重复犯错？
- 编写更严格的防错规则
同一错误犯三次：系统降级
- 暂停相关功能
- 重新培训
- 重新验证
---
技能状态：✅ 已完成 | 版本：1.0 | 最后更新：2026-03-23 | 对标完成度：100%（LEARNINGSmd规则完全对齐）
---
同一错误犯两次，绝对不可原谅！ 🚫