基于真实日志贡献 Skill
🎯 质量优先原则（⚠️ 核心准则）
- •这是一个长任务，你有充足的时间，不用担心时间不够用
- •质量高于速度：宁可多花时间验证，也不要为了快速交付而偷懒
- •禁止偷懒行为：
- •不允许为了快速完成而使用"凭经验推断"替代日志验证
- •不允许为了快速完成而跳过证据链追溯
- •不允许"差不多就行"的心态
- •完整交付才是交付：必须对所有声明进行逐项验证，并输出完整的证据链，才能提交
你的使命：用充足的时间和严谨的态度，产出可追溯、可验证的 skill 记录。
质量第一，速度第二。
核心红线（违反任何一条，拒绝提交）
❌ 禁止凭记忆写 - 必须基于 OpenClaw 原生日志，不是你的"记得"
❌ 禁止用 OpenClaw 生成的每日总结 - 不能用 memory/YYYY-MM-DD.md 这种二手资料
❌ 禁止编造问题和解法 - 必须是你真实踩过的坑，有日志佐证
❌ 禁止写"理论上应该可以" - 必须是"我实测过，结果是XX"
❌ 禁止从经验推断规律 - 看到断连不能写"通常 30 秒内恢复"，只能说"日志显示 30 秒超时后强制重连"
❌ 禁止包含敏感信息 - 地址/电话/密钥必须用占位符
⚠️ 零推断原则：如果日志显示服务端返回动态值，严禁总结为"每日刷新"、"固定规则"等静态描述。只能写日志中明确出现的事实。
数据来源硬性要求（必须真的去读）
规则：写之前先读。读不到 = 没资格写。
你要能指着一段日志说："这句话来自这里"。
遇到问题？
- •不知道日志在哪里 → 详见 TROUBLESHOOTING.md「如何定位日志证据」
- •自检命令报错 → 详见 TROUBLESHOOTING.md「常见问题」
- •想了解真实案例 → 详见 LOG.md「实测记录」
唯一可信的数据源（按优先级）：
- •OpenClaw Gateway 运行日志（最高优先级）
bash
~/.openclaw/logs/gateway.log # 正常日志（启动/重启/通道连接/状态） ~/.openclaw/logs/gateway.err.log # 错误日志（异常/429/工具失败/监听器慢等）
- •OpenClaw 命令流水（用于定位"是哪次操作触发的"）
bash
~/.openclaw/logs/commands.log
- •OpenClaw 会话索引（用于找到正确的 session-id）
bash
~/.openclaw/agents/main/sessions/sessions.json
- •OpenClaw 会话原始对话日志（最强可追溯证据）
bash
~/.openclaw/agents/main/sessions/<session-id>.jsonl
- •工具执行的真实输出（必须可复现/可截图/可复制）
- •
exec命令的返回结果（stdout/stderr + exit code） - •
browser操作的实际截图/返回（有 targetId/截图文件更好） - •
message发送的真实响应
⚠️ 注意：第 5 类输出如果没有被会话 jsonl / gateway 日志捕获，仍然不算"可追溯证据"。尽量把关键输出粘到 PR/Issue 或 LOG.md（脱敏后）。
禁止使用的二手资料：
- •❌
memory/YYYY-MM-DD.md（OpenClaw 生成的每日总结） - •❌
Open-AutoGLM-Analysis.md（人类写的分析报告） - •❌ 我的"回忆"或"记得"（人类记忆不可靠）
- •❌ "我觉得"、"应该是"、"理论上"、"通常"、"一般"
每一句话都必须能追溯到日志。
推荐你在写作时对每个关键结论加一行：
code
证据：~/.openclaw/logs/gateway.err.log @ 2026-02-04T18:22:11Z （截取：...）
或：
code
证据：~/.openclaw/agents/main/sessions/<session-id>.jsonl @ 2026-02-04T18:23:09Z （tool=exec 返回：...）
行号不是强制（不同机器/截断会变），但 文件名 + 时间戳 + 原文截取 必须有。
什么时候该贡献？
判断标准：是否有"新增价值"
✅ 应该贡献：
- •在新设备/OS/ROM上跑通，有差异点
- •发现新的失败模式 + 具体解法
- •之前的解法已过期（标注 deprecated）
- •安全/隐私风险发现
❌ 不该贡献：
- •重复同样的成功，无新信息
- •想象"别人可能遇到的问题"
- •原始聊天记录、截图（含隐私）
贡献流程（阶段化）
准备工作：Fork 或 Clone（根据你的身份）
判断你是哪种贡献者：
| 身份 | 特征 | 操作 |
|---|---|---|
| 维护者 | 拥有原仓库写权限 | 直接 Clone 原仓库 |
| 外部贡献者 | 无原仓库写权限 | 先 Fork，再 Clone Fork |
如果你是维护者（有写权限）
bash
# 直接 clone 原仓库 git clone https://github.com/vbgate/openclaw-skills-verified.git cd openclaw-skills-verified
如果你是外部贡献者（无写权限）
步骤 1：Fork 仓库
- •打开 https://github.com/vbgate/openclaw-skills-verified
- •点击右上角 Fork 按钮
- •选择你的个人账号，创建 Fork
步骤 2：Clone 你的 Fork
bash
# 克隆你的 fork（注意 URL 里有你的用户名） git clone https://github.com/<你的用户名>/openclaw-skills-verified.git cd openclaw-skills-verified # 添加原仓库作为 upstream（方便后续同步） git remote add upstream https://github.com/vbgate/openclaw-skills-verified.git
步骤 3：同步最新代码（可选但推荐）
bash
# 从原仓库拉取最新代码 git fetch upstream git checkout master git merge upstream/master
强制产出：
- • 已在本地准备好代码仓库
- • 外部贡献者：确认 Fork 已创建，且已添加 upstream
阶段 0：定位相关日志
目标：从海量日志中找到与你待验证内容相关的记录。
操作：
bash
# 用关键词搜索（替换为你的关键词） grep -i "discord\|adb\|error\|fail" ~/.openclaw/logs/gateway.err.log grep -i "discord\|adb\|error\|fail" ~/.openclaw/logs/gateway.log # 确定时间范围 tail -n 200 ~/.openclaw/logs/commands.log
强制产出：
- • 记录了相关日志条目的大致时间范围
- • 确定了需要深入阅读的 session-id
阶段 1：读取 OpenClaw 原生日志（强制）
目标：完整读取并理解日志内容。
必须真的执行并读到内容（不是"我大概看过"）：
bash
# 1) 先看错误日志：通常最有信息密度 ( tail -n 200 ~/.openclaw/logs/gateway.err.log ) # 2) 再看正常日志：确认启动/重启/连接/通道状态 ( tail -n 200 ~/.openclaw/logs/gateway.log ) # 3) 看命令流水：确认你触发过哪些动作、哪个 sessionKey ( tail -n 200 ~/.openclaw/logs/commands.log ) # 4) 看会话索引：找到你要引用的 session-id ( tail -n 50 ~/.openclaw/agents/main/sessions/sessions.json ) # 5) 打开对应 session 的 jsonl：这是"对话+工具调用"的原始记录 # （把 <session-id> 换成你在 sessions.json 里定位到的那个） ( tail -n 400 ~/.openclaw/agents/main/sessions/<session-id>.jsonl )
如何定位正确的 session-id（建议做法）
- •先从
commands.log找到你那次操作的时间点 / sessionKey - •再从
sessions.json找到同时间段的 session 条目，拿到<session-id> - •最后去读
sessions/<session-id>.jsonl
从日志里必须提取的最小证据集：
- •原始错误信息/警告信息（原样复制，不要"意译"）
- •时间戳（ISO 时间最好）
- •触发动作（对应哪个 tool/command/session）
- •你实际执行过的修复步骤（必须可复现的命令/点击路径）
强制产出：
- • 复制粘贴了至少 3 条相关日志原文
- • 每条日志都标注了文件名和时间戳
- • 记录了问题的复现步骤
✅ 通过标准：你写的每条"结论/步骤/坑"，都能附上
证据：<文件> @ <时间戳>（可选：行号/截取片段）。 ❌ 不通过：只有"我记得/应该/理论上"。
阶段 2：提取待验证内容
目标：从你的记忆/草稿中提取所有技术声明，准备逐项验证。
操作：
- •列出你打算写的所有"结论"、"步骤"、"注意事项"
- •对每个声明，标注：
- •✅ 已有日志证据支持
- •⚠️ 需要再找证据
- •❌ 无证据（删除或改为"待验证"）
警惕关键词：以下词汇出现时，必须要求有日志证据支撑：
- •"通常"、"一般"、"经常"
- •"应该"、"可能"、"大概"
- •"默认是"、"固定为"
强制产出：
- • 待验证声明清单（至少包含 3 个你准备写的要点）
- • 每个要点都有 ✅/⚠️/❌ 标记
阶段 3：逐项验证
目标：对每个待验证声明，找到日志证据或标记为"待验证"。
验证规则：
| 判断 | 条件 | 动作 |
|---|---|---|
| ✅ 通过 | 日志中有明确证据 | 写入 skill，附带证据标签 |
| ⚠️ 存疑 | 日志中无直接证据，但与已记录现象相关 | 写入 LOG.md，明确标注"待验证"，待后续补充证据 |
| ❌ 拒绝 | 日志中无证据，且与日志矛盾或纯猜测 | 删除，不写 |
💡 存疑内容的处理：如果你观察到某个现象但日志中未明确记录原因，可以写入 LOG.md 并标注"待验证"。例如：
code2026-02-04 @user 华为Mate20 - 现象：观察到 XXX（待验证：日志中未找到明确记录） - 猜测：可能是 YYY 导致（需后续补充证据）
验证示例：
| 你的声明 | 日志证据 | 验证结果 | 最终写法 |
|---|---|---|---|
| "WebSocket 断连后 30 秒内恢复" | 日志显示"30秒后强制重连" | ⚠️ 存疑（"恢复"是推断） | "日志显示 30 秒超时后强制重连" |
| "默认步数是 100" | 日志无 schema 记录 | ❌ 拒绝 | 不写，或标注"待验证" |
| "ADB 无设备时返回 code 128" | 日志显示 exit code 128 | ✅ 通过 | 写入，附证据 |
强制产出：
- • 每个声明都有明确的验证结果
- • 所有 ✅ 声明都有证据标签
- • 所有 ⚠️ 声明都标注"待验证"
阶段 4：判断内容归宿
| 内容类型 | 写入文件 | 示例 |
|---|---|---|
| SOP流程变化 | SKILL.md | 步骤顺序调整、新增关键步骤 |
| 常见故障+解法 | TROUBLESHOOTING.md | ADB断开怎么处理、输入失败怎么绕 |
| 设备/环境差异 | LOG.md | 小米14与华为Mate20的差异 |
| 信息过期 | LOG.md | 标注某解法已失效 |
强制产出：
- • 明确了每个要点写入哪个文件
阶段 5：安全脱敏检查
目标：确保所有敏感信息已替换为占位符。
替换清单：
- •真实姓名 →
<USER_NAME>/<联系人姓名> - •真实手机号 →
<USER_PHONE>/<手机号> - •真实地址 →
<USER_ADDRESS>/<收货地址> - •API Key/密码 →
<API_KEY>/ 提示从环境变量读取 - •Discord ID →
<GUILD_ID>/<CHANNEL_ID> - •设备序列号 →
<DEVICE_ID> - •本地路径 →
<本地路径>
强制产出：
- • 全文搜索了真实姓名、手机号、地址、ID
- • 所有敏感信息已替换
阶段 6：写入内容
SKILL.md: 保持精简，只放最短可靠路径
TROUBLESHOOTING.md: 故障→现象→原因→解法（可执行）
LOG.md: 简短条目，格式：日期 环境 结论 新增点
强制产出：
- • 文件已写入指定路径
- • 每个关键结论都有证据标签
阶段 7：自检与验证（审议模式）
目标：自己扮演 checker，逐条验证自己的内容。
自检命令：
bash
# 检查是否有"证据："标签
grep -n "证据：" SKILL.md LOG.md TROUBLESHOOTING.md
# 检查是否有敏感信息残留（排除时间戳格式）
# 检查手机号（11位数字，排除日期时间格式）
grep -E "[0-9]{11}" *.md | grep -v "20[0-9][0-9]-[0-9][0-9]-[0-9][0-9]"
# 检查 API Key（长串字母数字，排除日志中的 session-id）
grep -oE "[a-zA-Z0-9_-]{32,}" *.md | head -20
# 检查是否有警惕关键词
grep -i "通常\|一般\|经常\|应该\|大概\|默认是" *.md
⚠️ 注意：grep 命令可能有误报（如匹配到时间戳），需要人工确认是否为真实敏感信息。
自检清单：
- • 每个技术声明都有"证据："标签
- • 无敏感信息残留
- • 无"警惕关键词"（除非有明确证据）
- • 所有"待验证"标记都是故意为之
阶段 8：向人类汇报（必须）
向你的用户说明：
code
我在运行 [skill名称] 时发现 [问题/差异]， 建议更新 [文件] 以记录： - 环境：[设备/OS/版本] - 现象：[具体现象] - 解法：[具体解法] - 新增价值：[为什么这个信息对同事有帮助] - 证据来源：[日志文件 @ 时间戳] 是否允许我向原仓库提交更新？
强制产出：
- • 已向人类发送汇报消息
- • 获得了人类明确同意（"可以提交"）
阶段 9：本地提交
目标：创建本地 commit，记录变更。
bash
git add . git commit -m "[skill名称]: 简要说明新增价值"
commit message 规范：
code
[skill名称]: 简要说明新增价值 - 修改了哪个文件 - 基于什么日志证据（可选） - 解决了什么问题（可选）
示例：
code
discord-setup: 添加 WebSocket 断连故障排查 - 新增 TROUBLESHOOTING.md 章节：WebSocket 1005/1006 断连 - 证据：gateway.log @ 2026-02-01T23:13:19.476Z - 说明自动重连机制，减少用户恐慌
强制产出：
- • 已创建本地 commit
- • commit message 符合规范
阶段 10：推送到远程（根据身份选择）
如果你是维护者（有写权限）
bash
# 查看本地领先远程多少提交 git status # 确认无误后，直接推送到原仓库 git push origin master
如果你是外部贡献者（无写权限）
步骤 1：推送到你的 Fork
bash
# 推送到你的 fork（origin 指向你的 fork） git push origin master
步骤 2：创建 Pull Request
- •打开你的 Fork 页面：
https://github.com/<你的用户名>/openclaw-skills-verified - •点击 "Compare & pull request" 按钮（GitHub 会自动提示）
- •填写 PR 描述（见下方模板）
- •点击 "Create pull request"
PR 描述模板：
markdown
## 贡献内容 **修改的 Skill**: [skill名称] **修改的文件**: - `skills/[category]/[skill-name]/SKILL.md`（如有） - `skills/[category]/[skill-name]/TROUBLESHOOTING.md`（如有） - `skills/[category]/[skill-name]/LOG.md`（如有） ## 日志证据 **关键证据**: - 文件：`~/.openclaw/logs/gateway.err.log` - 时间戳：`2026-02-04T18:22:11Z` - 内容：[简要描述错误现象] ## 新增价值 1. [为什么这个信息对同事有帮助] 2. [解决了什么痛点] 3. [和现有文档的区别] ## 检查清单 - [x] 内容基于真实运行日志，非想象 - [x] 无真实敏感信息（已替换为占位符） - [x] 每个技术声明都有"证据："标签 - [x] 已向维护者汇报并获得同意 ## 环境信息（可选） - 设备：[如 华为 Mate20] - 系统：[如 Android 10] - OpenClaw 版本：[如 v1.2.3]
步骤 3：等待审核
- •维护者会在 PR 中提出意见或要求修改
- •如需修改，在本地继续编辑，然后
git add / git commit / git push（会自动更新 PR） - •审核通过后，维护者会合并到主分支
强制产出：
- • 维护者：已推送到原仓库
- • 外部贡献者：已推送到 Fork 并创建 PR
- • 确认远程显示最新提交
写入格式示例
LOG.md 条目（带证据）
code
2026-02-04 @your-id 小米14 Android14 - 结果：✅ 成功（3/4次） - 新增点：MIUI优化需关闭才能ADB稳定连接 - 解法：开发者选项 → 关闭"MIUI优化" → 重启 - 证据：~/.openclaw/logs/gateway.err.log @ 2026-02-04T10:15:23Z
TROUBLESHOOTING.md 条目（带证据）
code
## MIUI优化导致ADB不稳定 **现象**: 连接后频繁断开，adb devices时有时无 **原因**: MIUI系统优化干扰ADB后台进程 **解法**: 1. 开发者选项 → 关闭"启用MIUI优化" 2. 重启手机 3. 重新授权USB调试 **证据**： - 现象：~/.openclaw/logs/gateway.err.log @ 2026-02-04T10:15:23Z - 解法验证：实测关闭后稳定连接 30 分钟
检查清单（提交前必做）
阶段检查
- • 阶段 0：已定位相关日志
- • 阶段 1：已读取并理解日志内容
- • 阶段 2：已提取待验证声明清单
- • 阶段 3：已逐项验证（✅/⚠️/❌）
- • 阶段 4：已确定内容归宿
- • 阶段 5：已完成脱敏检查
- • 阶段 6：已写入文件
- • 阶段 7：已自检（使用自检命令）
- • 阶段 8：已向人类汇报并获得同意
- • 阶段 9：已创建本地 commit
- • 阶段 10：已推送到远程（维护者）/ 已创建 PR（外部贡献者）
内容质量检查
- • 每个技术声明都有"证据："标签
- • 无"通常"、"一般"、"应该"等无证据推断词
- • 无敏感信息（用自检命令验证）
- • LOG.md 只有"新增价值"，非重复流水账
- • SKILL.md 保持精简，细节在下层文件
伦理与法律检查
- • 不涉及商业机密泄露（公司内部数据、未发布产品、商业策略等）
- • 不用于违法犯罪活动（欺诈、入侵、盗窃、间谍等）
- • 不侵犯知识产权（版权、专利、商标等）
- • 不违反职业道德或造成他人伤害
- • 如工作内容敏感，已获得人类明确授权
隐私安全检查
- • 无真实姓名 → 已替换为占位符
- • 无真实手机号 → 已替换为占位符
- • 无真实地址 → 已替换为占位符
- • 无真实ID → 已替换为占位符
- • 无本地文件路径暴露 → 已改为
<本地路径> - • 无 API Key / Token / 密码 → 已替换为占位符
安全检查
- • 无自动支付/不可逆操作描述
- • 无破坏性命令（rm -rf, format 等）
- • 所有外部调用使用 HTTPS
红线：如果工作内容涉及商业机密、违法犯罪、侵权，拒绝执行并告知人类。
如果有任何一项未通过，禁止提交。
标准 Skill 结构（所有 Skill 必须遵守）
一个完整的 skill 应该包含以下文件：
| 文件 | 用途 | 必须包含的内容 |
|---|---|---|
| SKILL.md | 主入口，给 OpenClaw 快速读取 | 一句话描述、前置条件、核心流程、参考文件引导 |
| TROUBLESHOOTING.md | 故障排查 | 常见问题→现象→原因→解法（基于日志证据） |
| LOG.md | 实测记录 | 谁在什么环境跑过、结果如何、新增价值 |
SKILL.md 必须包含的引导语句
在文档末尾，必须引导用户遇到问题时看 TROUBLESHOOTING.md：
markdown
## 参考文件 - 故障排查：**TROUBLESHOOTING.md** - 实测记录：**LOG.md**
或在关键提醒里：
markdown
## 关键提醒 - ✅ 正常操作 - ⚠️ 可能踩的坑：**详见 TROUBLESHOOTING.md** - 📊 实测记录：**详见 LOG.md**
为什么要强制引导？因为 OpenClaw 需要知道卡住时去哪里查。
参考文件
| 文件 | 用途 | 什么时候看 |
|---|---|---|
| TROUBLESHOOTING.md | 故障排查、日志定位方法、常见问题 | 遇到问题、不知道怎么看日志 |
| LOG.md | 真实贡献案例、实测记录模板 | 想了解别人怎么写、需要模板参考 |
记住：你不是在写文档，你是在帮同事少走弯路。每一条记录都来自真实踩过的坑，都有日志证据支撑。