那时公司在快速扩张，工程团队分布在多个仓库、多个时区，发布节奏越来越快。早期还能靠记忆判断谁做了什么，后来已经不可能了。
问题不是没有数据，而是数据没有被翻译成管理层能理解的语言。代码提交、评审、问题讨论都在那里，但它们只是散落的记录，不会自动说明一个人的真实贡献。
如果没有一套更可靠的解释方式，贡献讨论就容易落到表面指标上：谁提交次数多，谁在会议里说得多，谁离管理层更近。真正重要的贡献模式，反而没有被放到桌面上。
代码平台可以给出很多数字：多少个仓库、多少次提交、多少次评审、多少个问题讨论。但这些数字不能直接等于贡献。一个小修复可能比十次简单提交更关键；一个长期负责评审和设计的人，也可能在提交数量上并不显眼。
真正难的问题，是把这些散乱记录翻译成一份经得起追问的贡献说明。每个结论都应该能回到原始证据，每个标签都应该能解释为什么这样贴。
所以这个系统不能只是一个看板。它必须同时做到四件事：把人对齐、把记录收全、把代码变化读懂、把判断过程公开。少任何一环，最后都会变成没人真正相信的数字表。
第一步不是读代码，而是确认每条记录属于谁。工程师可能有多个账号，自动化账号也会混进来，合并代码时还可能丢掉共同作者。人没对齐，后面所有分析都会偏。
系统会收集合并请求、代码提交、评审和问题讨论。这样做是为了避免只看“谁写了代码”，也能看到谁在评审、协调、修补和推动问题关闭。
模型不直接给人下结论，而是先读每次代码变化：这是不是实质工作，属于新功能、修复、整理还是重构，里面有多少可能是自动生成内容。原始内容会被缓存和截断，避免每次重跑都重新取数，也避免单个超大提交拖垮整条管线。
系统再按人聚合前面的结果，生成一份贡献画像：这个人主要承担什么角色，贡献集中在哪些方向，有哪些关键交付。模型看到的是已经整理过的证据，而不是凭空评价一个人。
我没有把这套东西做成黑箱。系统里有一页方法论，解释每一步怎么做、为什么这么做、哪里可能有误差。这样别人不认同结论时，可以指出具体哪一步有问题，而不是只能说“我不信这个系统”。
最重要的结果不是多了一个看板，而是讨论方式变了。管理层不再只问“这个人提交了多少”，而是能看到：他主要解决什么问题、在哪些模块持续投入、哪些交付最能代表他的贡献。
方法论页面也很关键。被分析的人可以看到系统为什么这样描述自己，哪些证据支撑这个判断。如果他不同意，可以针对具体步骤和证据讨论，而不是只能否定整个系统。
这样一来，工程贡献从“只能工程内部理解的东西”，变成了管理层、工程团队和当事人都能讨论的共同材料。
一开始我以为难点在技术实现：怎么取数、怎么缓存、怎么控制模型成本、怎么生成画像。做完之后发现，这只是前半部分。
真正难的是方法论。系统说一个人是什么角色、贡献在哪里、重要性如何，这些判断必须有证据，也必须允许别人反驳。写得太软，结论没有力量；写得太硬，别人不会相信。
衡量工程贡献的难处，不是把数据拉出来，而是让每一个判断都能回到证据，并且经得起当事人追问。