自报打勾很容易把“我打算做”记成“我已经做了”，让连续记录看起来比真实进度更漂亮。LifeQuest用与任务匹配的验证方式来决定 XP，让进度尽量对应已经发生的行动，同时保留半 XP 自报作为诚实的退路。
下面的凯是一个虚构的学生形象，但他的困境并不陌生。
周四晚上十点四十，凯坐在杭州大学城附近一家快打烊的咖啡店里，电脑旁压着一张写满待办的便签。他第二天要在小组会上展示自己负责的程序模块，可编辑器里的核心函数还空着。
LifeQuest里却是另一番景象：连续学习七天，三个编程任务全部打勾，Craft 经验值稳步上涨。
那些勾没有对应三次完成。第一次，他写了十几分钟便觉得“思路已经理清”；第二次，他看完教程，顺手把“完成接口”标成已完成；第三次，他告诉自己回宿舍一定补上。每一次点击都能找到理由，每一次都让页面更好看。
现在，展示就在眼前。队友已经完成自己的部分，如果他的模块仍然跑不起来，整个演示就会卡在空白结果页。手机上那串连续记录帮不了他。
凯盯着屏幕，没有再点第四个勾。
当打勾开始替代行动
自报本身没有错。读完一章书、整理一次房间、完成一段无法客观记录的练习，都可能适合由本人确认。问题出现在另一个瞬间：打勾带来的满足感，比完成任务来得更快。
凯想要的原本是能运行的代码。几天后，他开始保护的却是连续天数。
这是一种很隐蔽的目标替换。任务写着“完成登录接口”，大脑记住的动作却变成“睡前打开应用并点完成”。当页面持续给出正反馈，人很容易把记录的完整误认成能力的增长。
空洞 XP 的危险也在这里。它不会立刻惩罚你，甚至会让你感觉良好，直到考试、演示或比赛要求你拿出真正完成的东西。那时，漂亮的进度条与现实之间的距离才突然显形。
如果你想进一步理解这种偏差，可以读读当现实 RPG 的 XP 只记录点击，它还能衡量真实成长吗？。
验证让奖励重新对应现实
那天晚上，凯删掉了那个含糊的“大任务”，重新创建了一个具体任务：写完登录接口并推送代码。他选择 GitHub 推送验证，因为这项任务属于 Craft 领域，而且代码提交能留下合适的行动记录。
LifeQuest检查的是任务创建后发生的合格推送。公开事件可能有几分钟缓存，所以凯不能靠刚才看过教程、打开过编辑器或口头承诺来换取全额 XP。他需要让代码真正向前走一步。
十一点过后，测试仍然报错。凯一度想改用自报，先拿半 XP 保住当天的进度。他的手停在按钮上。
如果现在结束，第二天的展示仍可能失败。半 XP 可以诚实记录一次不便举证的完成，却不能替他完成空着的函数。
他关掉任务页，回到编辑器。修正参数，重新运行，看到测试通过后提交并推送。验证随后确认了这次行动，全额 XP 才落到账户里。
改变凯的并不是一个更难点下去的按钮，而是一条清楚的边界：证据适合这项任务时，全额奖励留给已经发生的工作。
不同任务需要不同证据
验证不能只有一种模板。写代码可以看任务创建后的 GitHub 推送；专注学习可以运行由服务器计时的专注会话；适合拍照的现实任务可以提交应用内相机照片，交给 AI 做合理性审核。
当客观证明不现实，凯仍然可以诚实自报并获得半 XP。这个出口很重要，因为现实生活里并非每一次练习都能留下可靠凭证。验证层的目的不是假装消除欺骗，而是让奖励强度与证据强度更接近。
照片审核也不是绝对防作弊的裁判。AI只能判断提交内容是否看起来与任务相符。动作或手工练习的视频反馈同样与 XP 分开，最多 60 秒的录像可以收到异步反馈，包括总结、提示和注意点，但这些建议不会被包装成任务完成证明，更不能替代专业教练。
这种区分让系统少说一句“相信我”，多问一句“这项进步留下了什么？”
第二天，凯带去的是能运行的版本
小组会开始前，凯又跑了一遍程序。结果页正常出现，队友可以接着演示自己的部分。昨晚获得的全额 XP 没有替他写代码，它只是等到代码真正被推送后才出现。
此后，他把任务写得更容易验证：“完成一组习题并专注计时”“提交今天的代码修改”“拍下组装完成的模型”。对于无法合理举证的阅读和复盘，他照样用自报，只接受半 XP。
连续天数不再是他最想保护的东西。Skill Tree上的进度开始与桌面上、代码库里和日常生活中已经发生的变化对得上。
下次准备点“完成”时，可以先停一秒：我是在记录成果，还是在安慰自己？如果证据适合这项任务，就让证据替你回答。若不适合，坦然拿半 XP，也比用一个全额勾掩盖尚未完成的事更有用。
评论
暂无评论。