每次都复盘 为什么我还是会在黑客松里跑题
做完 NBA 黑客松，我最不甘心的地方，是 AI 评分第二，却没有进入决赛。
我看到别人的作品，用 Claude Sonnet 写 Three.js 和 shader，把篮球分析渲染成一段好看、容易理解的视频。再回头看我们的 Courtside IQ，模型、数据、Agent、主播工作台、吉祥物、录制和播出，东西已经很多。可是到了需要把成果交出去的时候，我还在反复问：视频上传好了没有？声音还在吗？评委打开链接能不能直接看到？会不会播完就停？
这几句话，比架构图更能说明我当时的问题。
我把大量精力投入了制作平台，却没有足够早地验证一段完整、可观看的作品。现在再写“我们在受限环境里展现了很好的工程思维”，并不能回答这件事。它甚至可能让我又一次绕开更难的问题：为什么每次都能复盘出道理，下一次做项目时，我还是会逐渐跑题？
最后等着上传的那段视频
我们希望观众看懂一段进 攻：当前是谁在持球，防守发生了什么变化，哪条数据值得看，为什么这个选择有意思。观众需要的是画面、数据与解说在恰当的时刻一起出现。
项目推进中，我越来越多地从主播工作台出发思考。主播需要暂停、画线、选球员、查依据、改稿、录音、保存，再把作品发给观众。这些需求都有来处，队友也确实提出了实际使用中的问题。把它们认真做出来，有价值。
但一个能够生产节目的工作台，和一段已经能让陌生人看懂的节目，之间仍有距离。录制是否保留声音，作品是不是困在某个会话里，新浏览器能否访问，公共页面能否持续循环，都是交付的一部分。它们应该在最早的完整演示里接受检查。
当我还在补这些问题时，功能列表已经足够长了。最后那种反复确认上传状态的焦虑，提醒我：我检验了很多局部能力，却太晚才认真检验别人收到的究竟是什么。
这不等于那些修复不重要。跨会话可看、保留音频、正确循环，本来就应该优先。问题在于，我没有足够早地用这些条件安排其他工作的顺序。
每一次增加功能 都有一个说得通的理由
球员数据卡对应不上画面，就想增加分割高亮；身份会串，就继续改跟踪与校正；分析等待太久，就保存结果和可编辑播报稿；主播录节目需要节奏，就做关键帧、录音和时间线；助手缺少亲近感，又想给吉祥物做动作。
逐项讨论时，很难说它们都不该做。我也正是在这种逐 项合理里，慢慢接受了一个越来越大的项目。
最容易被省略的，是增加一项能力之后，哪项工作会被延后。一个动作做得更自然，可能意味着少一次完整节目的彩排；多接一种模型，可能意味着没有时间把一张关键数据卡放到最容易读的位置。代码生成变快了，这种替代关系仍然存在。测试、整合、解释和维护，不会自动消失。
我当时更常问“这个能不能做”，较少追问“它会让最终演示的哪一处发生变化”。只要回答是可行，项目就多了一个方向。
最后，原本围绕一段篮球内容的目标，逐渐扩大成了一个完整解说平台。目标没有被正式改写，投入却已经跟着新目标走了。
做对一些工程选择 仍然可能把作品做偏
我不想为了批评自己，就把所有实现都说成没有意义。
保留原视频，用 JSON 记录暂停和图层，让回放重现主播操作，是一个有具体用途的选择。保存已经分析过、能够人工修改的播报稿，可以避免录制时重复等待。把官方记录、视觉观察和 AI 解释区分开，也能减少把猜测包装成事实的风险。
这些选择值得继续写成技术文章。技术文章回答的是它如何工作、解决了什么问题、适用边界在哪里。
这篇复盘要补上另一个问题：为什么要在这次交付里，把这么多事情一起做？
一项选择技术上成立，不代表它当时值得优先投入。架构能展开很多层，不代表观众更容易理解那次进攻。主播有更多按钮，也不代表他更容易录出一段流畅解说。我需要同时判断实现本身的质量，以及它对眼前作品的贡献。
我看到的 Three.js 和 shader 视频，让我意识到自己低估了呈现本身需要的设计与工程投入。让观众看清变化、跟上信息、听懂解释，同样需要反复取舍和打磨。我不能因为自己的后端更容易写成长文，就把画面里的表达看轻。
我没有看过其他团队的完整实现，不能据此断言他们只做了渲染，也不能替评委解释结果。这个对照足以提醒我检查自己的投入，不需要再给别人的作品贴标签。
AI 的高分没有替我完成验收
AI 评分第二，是这次经历的一部分。没有进入决赛，也是结果。两个事实放在一起，并不能直接推出“AI 更懂技术”，或者“评委只喜欢好看的视频”。
我需要回到那次评分的输入与规则，才能知道这个名次具体说明了什么。如果评价主要接触功能说明和代码，它与观看成片得到的判断可能不同；如果评价直接观看视频，也仍要看它衡量的是什么。不能凭一个名次，就补出整套评分逻辑。
对我而言，更该警惕的是高分带来的放心感。一个积极评价，很容易被我理解成方向已经得到认可，接下来只要继续补齐就好。可是观众能否顺利打开、听清解说、理解重点，仍然需要有人实际走一遍。
以后我可以保留 AI 评测，但每次都要说清输入、标准和它没覆盖的部分。它帮助我检查某些问题，不能替我决定最终作品已经交付成功。
为什么复盘里的道理没有进入下一次开发
我过去很容易写出一篇完整的复盘：遇到了什么限制，想出了什么办法，哪些模块可以复用。事情做完以后，这样梳理有帮助，也让我从失落里恢复一点秩序。
但我发现，解释已经做过的选择，比限制下一次的选择容易得多。前者可以把每个难题接成一段有因果的故事；后者要在一个新点子很有吸引力的时候，真的放下它。
“下次更聚焦”没有告诉我，碰到一个队友确实需要的功能时该怎么决定。“先做最小版本”也没有说清，哪些东西缺了就不能交，哪些可以暂时用人工完成。没有触发条件，这些结论到了现场，就很容易被一句“这个也很重要”让过去。
还有一种让我需要警惕的满足感：修好一个接口、接通一个模型、画完一张架构图，都有明确的完成信号。让一个陌生人看懂作品，却可能只换来一句“我还是没明白”。我更熟悉前一种反馈，于是可能不断把工作转向自己擅长证明进展的地方。
这不是说工程工作不需要做，而是我需要承认自己的偏好会影响优先级。复盘如果总是从这种偏好里挑出优点，就很难改变它。
AI 合作者也参与了范围扩大
这次很多工作是和 AI 一起完 成的。它能把一个想法迅速拆成方案，再写成代码。我提出新需求，它很容易接着往下推进；我说某个实现很巧，它又能把这份巧思整理成一篇完整的工程总结。
这种协作很顺畅，却不一定帮助我收住范围。
我负责提出和接受需求，也需要为最终取舍负责。同时，我希望 AI 合作者承担更明确的工作：每次扩展前，指出它会改变哪一段演示、增加哪些整合工作、挤掉什么已有任务。执行得快，不能自动被当成值得执行的理由。
赛后也一样。我们很快就能把经历拆成多篇技术文章，但“有这么多可以写的内容”，不能反过来证明比赛中的范围就是合适的。我需要把技术沉淀与比赛复盘分别做好，允许前者有用，同时承认后者暴露了优先级问题。
下一次要留下能检查的决定
我想把这次反思变成几条会影响开发的约定。它们还没有在下一次比赛里经过验证，先写在这里，方便以后检查自己有没有做到。
先完成一份能交出去的样片。 对这类视频项目，先选定一段素材和一个要讲清的问题，做出包含原声或解说、关键画面、数据提示和观看入口的完整版本。用新的浏览器打开，按实际需要点击开启声音，再确认能够看完。后续能力围绕这份样片修改，不能一直拿工作台截图代替成片。
新增功能必须说明替代关系。 我或 AI 提出一项能力时，要指出它改善样片的哪个时刻，以及为此会暂缓什么。影响不了当前作品的想法，先留下用途和延后理由。 已经决定延后的需求，也要保留在协作上下文里，避免下一轮又被包装成一个新亮点加回来。
完整演示通过后 优先保持交付稳定。 身份错误、音频丢失、作品无法访问，仍然需要修复。增加一种形象或另一种操作方式，则要重新判断是否值得冒整合风险。不能把所有事情都叫作“完善细节”，让交付一直没有稳定版本。
找没有参与开发的人实际看。 给他最终链接，先不在旁边解释按钮和架构，再听他描述自己看到了什么。如果他无法对应球员、数据和变化，先修改表达与信息顺序。只有当作品已经讲清问题，才继续考虑增加内容。
我不想再给这几条约定做一套复杂管理系统。下一次留下少量决定就够了：拒绝了什么，为什么拒绝，省下来的精力最终用在了哪里。
到那时，复盘才有一个新的问题可以回答：当我又想加一个自己很喜欢的功能时，上一次写下的结论，有没有真的让我改过一次决定？