使用OpenClaw生成团队体检报告并识别出摸鱼的同事,这听起来像是一个结合了数据分析与人工智能技术的应用。以下是对这一过程的简要描述:1. **数据收集**:首先,需要收集团队成员的工作数据,这可能包括工作时长、工作效率、项目进度、任务完成情况等。2.

摘要:你有没有好奇过,你的队友到底是几点写的代码?是凌晨三点灵感爆发的夜猫子,还是朝九晚五准时下班的养生达人? 一切的起源:一个深夜的疑问 故事要从一个加班到凌晨两点的夜晚说起。 那天我照例在提交代码,突然发现 Git log 里有一条提交时间是
你有没有好奇过,你的队友到底是几点写的代码?是凌晨三点灵感爆发的夜猫子,还是朝九晚五准时下班的养生达人? 一切的起源:一个深夜的疑问 故事要从一个加班到凌晨两点的夜晚说起。 那天我照例在提交代码,突然发现 Git log 里有一条提交时间是 03:47,来自我们组的后端同学。我震惊之余又有点心疼,然后下意识地翻了翻其他人的记录,发现了更多有趣的事,有人专挑周末提交,有人的 commit message 永远只有一个字 fix,还有人一个提交能改 500 个文件…… 我心想,如果把这些数据系统地分析一下,会不会看到一幅很有意思的开发者画像? 这就是 who-is-actor 诞生的初心。 它是什么? 简单来说,这是一个 OpenClaw 分析工具的 Skill 插件。它做的事情很纯粹:扫描你指定的 Git 仓库,或者一整个目录下的所有仓库,然后像一个沉默的观察者,把每个开发者的行为数据抽丝剥茧,最终生成一份五维度的体检报告。 五个维度分别是: 提交习惯 -- 你一天提交几次?每次改多少行?commit message 写了几个字? 工作习惯 -- 你是早起鸟还是夜猫子?周末有没有在偷偷加班?最长连续写了几天代码? 研发效率 -- 你写的代码有多少后来又被删了?是不是经常在同一个文件上反复改? 代码风格 -- 你主要写什么语言?commit message 有没有遵循规范? 代码质量 -- 修 bug 的提交占了多大比例?有没有动不动就一个大提交甩上来? 扒出来的「真实画像」 我用它分析了团队仓库后,看到的一些真实画面: 深夜战士 -- "A 同学" 这位老兄的提交时间几乎全部集中在深夜,而且清一色在周末。如果你半夜两点 @ 他,大概率能秒回。他不是不睡觉,他只是把白天的时间让给了生活,然后在万籁俱寂的时候打开编辑器,一个人安静地写代码。 不过看数据也会发现一些值得关注的信号:他的代码流失率高达 66%,意味着写下的代码有三分之二后来又被删除了。这可能是探索性编码的正常现象 -- 毕竟深夜写代码,有时候是先写再想,写完再推倒重来。他的返工率也有 46.2%,7 天内重复修改同一个文件的频率不低。 但换个角度想,这也许恰恰说明他是一个追求完美的人,代码写完不满意,再改,改完还是不满意,接着改。 批量输出者 -- "B 同学" 看到这个数据的时候我差点以为分析工具出了 bug,单次提交平均两万行?再仔细一看,原来是做项目初始化和大规模迁移的。他拥有仓库中 100% 的文件所有权,是当之无愧的项目奠基人。 有趣的是,他的代码流失率为 0%,写下的每一行代码都还活着。搞基建的人就是这样,一砖一瓦都是实打实的。不过他的 commit message 也就 30 来个字符,简洁高效,有那味了。 周末勇士 -- "C 同学" 三分之二的提交都在周末,还有三分之一在深夜。但看另一组数据就知道,这是一个效率极高的人:代码流失率只有 3.8%,几乎不做无用功。每一次提交都目标明确,落笔精准。如果说深夜战士是先写再想,那这位就是想清楚再写。 偶尔现身的贡献者 -- "D 同学" 有些人在项目中只留下了一个提交,但那一个提交可能就是修了一个关键 bug,或者补上了一段缺失的文档。开源世界里不存在贡献太少这一说,每一个 commit 背后,都是一个真实的人在某个时刻打开了编辑器,读懂了代码,然后伸出了手。 技术解剖:它是怎么做到的? 架构一览 整个项目的架构非常清晰,像一条流水线: 路径输入 → Scanner 发现仓库 → 5 个 Analyzer 遍历 Git 历史 → Reporter 生成报告 Scanner 负责扫描,找到指定路径下的所有 Git 仓库 5 个 Analyzer 各司其职,遍历提交历史,按作者分组聚合数据 3 个 Reporter 提供 Markdown、JSON、HTML 三种输出格式 核心算法亮点 几个我觉得设计得比较巧妙的地方: 1. 返工率 Rework Ratio 的计算 如果你在 7 天内对同一个文件改了两次以上,就算一次返工。这个定义很现实 -- 真正的返工通常发生在短时间内反复修改同一个地方,可能是需求变了,可能是 code review 的反馈,也可能是自己发现了之前的问题。 2. 文件所有权 Ownership 的判定 如果你对某个文件的修改次数超过了所有人修改该文件总次数的 50%,你就拥有这个文件。这个概念借鉴了 Google 的 Code Ownership 实践 -- 每个文件都应该有一个主人,出了问题知道找谁。 3. Bus Factor 的衡量 如果某个人被公交车撞了,不是真的,项目还能继续吗?工具统计每个文件有多少独立贡献者,取平均值。
阅读全文