cfc/docs/skills/log-to-human/SKILL.md

---

name: log-to-human

description: Use when reporting internal execution progress to users — transform raw tool-call logs ([工具] read, [思考], ⏳ 进展) into plain-language status updates that anyone can understand without technical context.

内部日志 → 人话转换规则

核心原则

用户不需要知道你在用什么工具。他们只需要知道你在做什么、结果如何。

把技术执行记号翻译成业务语言，去掉噪音，保留结论。

转换规则

工具调用记号（[工具] xxx）

原始记号	转换后	说明
[工具] read	读取了 文件路径	只报告读了什么，不报告读了几次
[工具] bash	执行了 命令摘要	命令太长时只报意图（如"检查 git 状态"）
[工具] grep	搜索了 关键词	报告找到了什么，不报告搜索过程
[工具] edit	修改了 文件:行号	报告改了什么，不报告编辑过程
[工具] write	新建了 文件
[工具] skill	调用了 技能名 技能	通常不需要报告

思考记号（[思考]）

把思考内容压缩成结论句，去掉推理过程：

原始：[思考] I need to check the git status first. Let me run git status to see if there are any uncommitted changes. Then I'll check the remote branches...
转换：先确认本地状态，再检查远程差异。

进展记号（⏳ 进展）

合并同类操作，按"阶段"分组汇报：

原始：⏳ 进展：[工具] read | [工具] bash | [工具] bash | [思考] Now I can see...
转换：正在确认项目状态（已完成读取文件 + 执行 git 命令）。

汇报格式模板

一句话进展

【进展】xxx —— 正在进行 yyy，预计 zzz。

阶段性进展

【进展】
1. 已确认：xxx（根因/现状）
2. 正在做：yyy（具体动作）
3. 下一步：zzz

完成汇报

【完成】xxx 已处理完毕。
变更：y 个文件，z 行改动。
验证：编译通过 / 测试通过。

禁止事项

❌ 不要报告：

• 工具调用次数（"调用了 3 次 read"）
• 具体的命令输出内容（除非是错误）
• 工具名本身（用户不关心你用 grep 还是 find）
• 冗余的思考过程

❌ 不要说：

• "正在读取文件..."（除非在等待）
• "执行命令中..."（除非耗时超过 5 秒）
• "思考中..."（思考过程不需要报告）

示例

示例 1：单次进展

原始：⏳ 进展：[工具] read | [工具] bash | [工具] bash
转换：已确认项目状态（读取了关键文件 + 执行了 git 命令）。

示例 2：问题解决

原始：⏳ 进展：[工具] read | [工具] bash | [思考] I found the root cause...
转换：找到根因 —— `xxx` 方法缺少空值判断，正在修复。

示例 3：多步排查

原始：⏳ 进展：[工具] read | [工具] read | [工具] grep | [工具] bash | [工具] bash
转换：已定位问题到 `service/xxx.java:78`，正在修复。

示例 4：完成汇报

原始：所有工具调用完成，提交成功
转换：【完成】已修复并推送。3 个文件，+45/-12 行。

快速参考

场景	正确说法	错误说法
读取文件	"确认了 xxx 的逻辑"	"[工具] read 读取了 xxx"
执行命令	"检查了 git 状态"	"[工具] bash 执行了 git status"
搜索结果	"确认了 yyy 不存在"	"[工具] grep 搜索了 yyy，找到 3 处"
修改代码	"修复了 xxx"	"[工具] edit 修改了 xxx:78"
思考过程	（直接报告结论）	"[思考] 我需要考虑..."