可哥：最近大家都在沉淀 skill，你们有没有什么可以沉淀的 skill？ 那一刻我脑子里开始疯狂刷屏： 接下来大家肯定都会卷 skill，类似功能的 skill 会越来越多。我最近又确实在“无脑下载”，装的时候很快乐，用的时候很随缘。 然后问题就来了：skill 变多以后，会不会很多其实根本没用？会不会有些看起来很忙，实际贡献很少？ 如果有个东西，能帮我客观看出哪些 skill 在认真干活、哪些 skill 只是“占着位置”，就好了。
项目github：github.com/summer-077/…
如果你也在玩 Agent、工作流、自动化，应该懂这种状态：
白天写需求，晚上逛 skill 商店，看到“提升效率 300%”就先安装再说。装到第 N 个的时候，你会很难回答一个简单问题：
这些 skill 里，到底谁在干活，谁在摸鱼？
我当时的结论很朴素：不能再靠感觉了，得有一套量化的“技能绩效系统”。
于是，skill-score 诞生了。
一、先能跑起来：一条命令，先看到结果
我最怕“概念很完整，落地很复杂”。所以入口尽量做成傻瓜式。
如果你是 Codex 用户，直接跑：
./scripts/run_one_click.sh
如果你是 ClaudeCode 用户，直接跑：
./scripts/run_claudecode_one_click.sh
这两条命令都会自动完成三件事：
- 导出日志。
- 构建评分输入（runs）。
- 计算评分并生成报告。
最后产物是三份：
reports/codex_logs_report.json（给程序看）reports/codex_logs_report_zh.md（给复盘看）reports/codex_logs_dashboard.html（给老板和自己看）
二、为什么要做这个：Skill 越多，管理成本越像指数曲线
Skill 少的时候，团队靠默契就能管理。谁稳定、谁玄学、谁脾气大，大家心里都有数。
但当 skill 规模来到 20、50、100，情况就变了。
你会遇到几个经典坑：
第一，触发次数很多，不代表贡献很大。有些 skill 很“勤奋”，但主要贡献是把上下文吃掉。
第二，同名 skill 不一定同一个东西。全局版和项目定制版，可能长得像双胞胎，行为却像表兄弟。
第三，多 skill 串起来之后，功劳和锅都容易失真。成功谁领，失败谁背，复盘时经常靠音量决胜负。
这时候如果还用“我感觉这个 skill 还行”来做治理，基本等于拿罗盘看股票。
所以我做 skill-score 的目标非常明确：
- 找出值得继续加投的 skill。
- 找出质量高但使用不足的 skill。
- 找出得分低、风险高、应该优先治理的 skill。
它不是为了做一个好看的榜单，而是为了做技术决策时少拍脑袋。
三、最容易吵起来的问题：来源类型到底是什么
这部分我被问过最多次，所以直接讲结论：
“来源类型”在当前系统里不是 skill 的“永久户口”，而是“这次运行看到的来源证据”。
判定逻辑也很直接：日志里有明确路径证据时，就能区分“全局来源”还是“项目来源”；
如果这次日志没有携带可判定路径，就会落入“未判定”。
重点来了：“未判定”不代表“这个 skill 没路径”。
它通常代表“这次采集到的日志里，只有‘使用了某 skill’的文本，没有抓到对应路径证据”。
换句话说，skill 本体肯定有文件，但你的日志不一定每次都给你把证据带齐。
四、我怎么打分：不只看成功率，还要看代价
如果只看成功率，很多问题会被掩盖。
有些 skill 成功率不错，但每次都要人工接管 10 分钟；有些 skill 触发挺准，但失败一次就烧掉关键路径。
所以 skill-score 采用了“质量 + 成本 + 风险”三维视角。
核心指标包括：
trigger_accuracy：触发准确度result_achievement：结果达成率feasibility：执行可行性（自动完成、可恢复、人工成本）roi_score：收益损失归一化分score：综合得分risk_index：风险指数total_loss：失败损失
报告里会给你档位提示，方便扫表：
- 总分：
🟢高 / 🟡中 / 🔴低 - 风险：
🔥高 / ⚠️中 / ✅低
我个人的使用习惯是，先不看绝对值，先看三类信号：
high_score_low_use：该扩大使用的。low_score_high_risk：该立刻治理的。high_risk_skills：该提前预警的。
这三类比“Top10 排名”更能指导动作。
五、多 Skill 一起干活时，账怎么算
这是一个非常真实的问题：一个需求经常不是一个 skill 单干，而是多人接力赛。
如果把成功全算最后一个 skill，前面的分析和兜底就“人间蒸发”； 如果把成本均摊得太平均，又会把关键责任稀释掉。
当前实现的做法是：
- 以任务事件为锚点，在时间窗口里找到活跃 skill。
- 一个任务可以拆成多个 run。
- 多 skill 情况下，通过 assistants 折算协作成本和收益。
- 多 skill 情况下，通过 assistants 折算协作成本和收益。
详细点说，先看时间窗口本身。窗口的右边界是当前任务完成时间，左边界默认是“往前 90 分钟”。但这里还有一个防串味设计：如果上一个 task 的完成时间比“90 分钟前”更靠后，系统会把左边界抬到上一个 task 时间。这一步非常关键，它避免了把上一个任务的 skill 污染到下一个任务。也就是说，系统不是单纯按“过去 90 分钟”暴力扫描，而是“90 分钟 + 任务边界”双约束。 然后是参与者识别。窗口内只要命中了 skill 事件，就算这个 skill 参与本任务；不会只挑一个，也不会做“最频繁者胜出”。同一个 skill 在窗口里出现多次时，只保留一个参与身份，避免重复记账；如果同一个 skill 的来源标记一会儿清晰、一会儿模糊，会优先保留清晰来源。到这里为止，系统回答的是“谁参与了”，还没有回答“谁贡献更大”。
接下来才是拆分。假设
task-101在窗口里命中了learn、role、top1三个 skill，系统就会生成三条 run：task-101:learn、task-101:role、task-101:top1。这一步的意义不是把功劳硬分三份，而是把“单任务结果”转换成“可统计样本”。没有这一步，你永远只能说“任务成功了”；有了这一步，你才能说“过去 200 次任务里，哪个 skill 参与后稳定、哪个 skill 参与后风险高”。
真正体现“多 skill 成本”的，是折算字段。系统会计算
assists_total = N - 1，N 是本任务命中的 skill 数。N 越大，协作复杂度越高，字段会这样变化：人工时长会上浮、失败成本会上浮、业务价值会折减，同时key_path会标记为真。你可以把它理解成一个很朴素的工程判断：参与者越多，沟通与依赖成本通常越高，出现不一致和回滚的概率也会上升。这些不确定性如果不写进数据，最后一定会在复盘里“失忆”。
它当然不是完美归因，但比“拍脑袋归功”和“谁最后发言谁背锅”强不少。
六、这个系统的边界（先说清楚，再谈未来）
skill-score 现在是“启发式归因”方案，不是强一致追踪系统。
这意味着它非常适合做治理决策和复盘，不适合直接做精确计费。
目前几个边界：
- 部分成本/收益字段仍有启发式估算成分。
- 在证据不足时，来源类型会出现“未判定”。
- 如果要做严肃考核，需要引入显式
run_id和更完整埋点。
这不是什么“缺陷公告”，而是工程常识：
先把方向跑通，再把精度做深。
七、我真正想做的：从评分走向 Skill 编排
评分本身不是终点，它更像导航地图。
真正让我兴奋的是下一步：让系统根据需求输入，自动推荐更优的 skill 组合。
我的想象是这样的：
当你输入一个需求，系统能结合历史数据判断：
- 该先调用哪个 skill，后调用哪个 skill；
- 哪些节点必须加校验；
- 哪些高风险 skill 应该降权或限流；
- 哪些高分低用 skill 应该被优先推荐。
这就是“Skill 编排”的起点。
而 skill-score，是这条路上最基础但必须的一块地基。
八、写在最后
这个项目目前是一个初步探索，离“完美方案”还很远，但已经足够帮我回答最初那个问题：
“这些 skill 到底有没有在认真干活？”
如果你也在做 skill 治理、Agent 工程化，或者对“自动编排 skill”感兴趣，欢迎一起讨论。
我很期待下一版不只是告诉我们“谁在偷懒”，而是直接告诉我们“下一次该怎么搭配 skill 才更优”。
