绿色贡献方格只能证明某天有提交记录，不能证明你完成了原定功能。一个改单字符拼写的提交，和一项可运行功能的提交，会占据同样大小的方格；LifeQuest 用“先创建编程任务，再验证之后发生的合格推送”缩小这段差距。
2014 年，美国西弗吉尼亚大学替代燃料、发动机与排放中心的研究人员面对一组解释不通的数据。他们受国际清洁交通委员会委托，在美国道路上测试柴油车排放。车辆在实验室测试中表现合格，到了真实道路环境，氮氧化物排放却明显升高。
当时，研究团队还不能确定原因。可能是测试设备的问题，也可能是车辆故障，或者实验室流程遗漏了某个变量。那张“通过测试”的结果仍然摆在那里，看起来像一个绿色方格，给出了明确、整洁、令人放心的信号。
后来，调查指向大众汽车安装的软件。它能识别车辆是否正在接受排放测试，并在测试条件下改变发动机控制方式。2015 年，美国环境保护署向大众汽车发出违反《清洁空气法》的通知。西弗吉尼亚大学的道路测试及其后续影响，可在该校关于柴油排放研究的记录以及美国环境保护署的大众汽车执法资料中查证。
实验室结果没有凭空捏造一段行驶记录。它记录的条件太窄，无法回答人们真正关心的问题：这辆车在现实道路上如何排放？
代码贡献方格也有同样的边界。
一个方格记录了什么
GitHub 的贡献图很适合回答“这一天是否留下了符合统计条件的活动”。它没有承诺回答“你原计划完成的功能是否已经交付”。
想象两个提交：
第一个只修正 README 里的一个错别字。第二个实现注册表单校验，补齐测试，并把功能推送到远程仓库。两者都可能点亮一个方格。方格的颜色或许会因当天贡献数量而变化，但面积不会替第二个提交扩张，也不会替第一个提交缩小。
于是，连续几周的绿色可以同时对应两种完全不同的现实。你可能每天都在推进核心功能，也可能在截止日期逼近时，用极小改动维持一条看起来完整的连续记录。
问题不在 GitHub。贡献图准确完成了它的工作。偏差来自我们把“发生过贡献”读成了“完成了计划中的工作”。
LifeQuest 为什么要求先建任务
LifeQuest 的 GitHub 验证从一项已经创建的 Craft 类任务开始。你先写下准备完成的具体工作，再去编码和推送。系统验证的是任务创建之后发生的合格推送，而不是从历史记录里随便找一个绿色方格来匹配今天的目标。
顺序很关键。
如果你先提交，再补写任务，目标就容易变成对既成事实的包装。先创建任务，相当于提前留下判断标准：今天要完成什么，哪个技能在增长，什么行动才算向前一步。之后的推送只能证明你确实产生了新的代码活动，不能偷偷改写最初的承诺。
这也解释了 LifeQuest 为什么只向 Craft 领域的合适任务提供 GitHub 验证。一次推送能为编程任务提供相关证据，却不能证明你跑完了五公里、练好了一个动作，或者完成了一次线下交流。每类任务需要与它匹配的验证方式。
一次代码推送如何让连续打勾变成可见进步讨论的正是这种变化：先明确行动，再让证据回答一个足够具体的问题。
推送证明了进展，也有明确边界
通过 GitHub 验证后，LifeQuest 可以为任务发放全额 XP。这个结果意味着：任务创建之后，关联账号出现了符合条件的公开推送。
它不意味着代码质量已经通过评审，也不意味着功能已经部署，更不意味着用户能够正常使用。LifeQuest 不把一次推送包装成完整的软件交付证明。
这条边界反而让 XP 更可信。证据应该支持它真正能支持的结论。照片用于判断画面是否与任务相符，服务端计时用于记录经过的专注时间，GitHub 推送用于确认新的代码活动。无法提供合适客观证据时，你仍可诚实自报完成并获得一半 XP。
绿色方格可以继续保留它原本的意义。你的任务记录负责补上另一半：这个提交原本要推动什么？
让记录追上真实工作
开始编码前，先把任务写成可核对的结果，例如“为注册表单加入邮箱格式校验并补测试”，而不是“写代码”。完成后再推送，让提交信息对应那项结果。若核心功能仍未完成，就拆出下一项任务，别让一次无关的小改动替整天盖章。
西弗吉尼亚大学团队发现的问题提醒我们，整洁的通过标记可能准确，却仍然回答错了问题。实验室结果需要道路数据补充，贡献方格也需要事先定义的任务补充。
真正有用的记录，不是让日历看起来更绿，而是让你几周后仍能说清楚：我计划做什么，我留下了什么证据，我究竟推进了哪一步。
评论
暂无评论。