我 2025 年的 GitHub contribution 图看起来像是两个不同开发者留下的。上半年几乎是空的。下半年有超过 4,000 次 commit。
并不是我突然多出了很多空闲时间。我还是一边全职工作，一边做 side project。真正变化的是从想法到“能跑起来的版本”之间的 friction：我开始更认真地使用 AI coding 工具。
这个数字需要谨慎解释。Commit 数量本身并不是生产力指标。4,000 次 commit 不等于 4,000 个有价值的改进，也不能证明代码质量很好。但这张图确实说明了我的工作方式发生了真实变化：相比以前，我更持续地 build、iterate，并把东西推进到真正能运行的状态。
真正的瓶颈是启动一次实验所需的能量
在个人项目里，我反复遇到同一个问题：第一个真正有用的版本之前，往往堆着大量例行工作。Routing、validation、scripts、tests、configuration 和 cleanup 会在我确认一个想法是否值得继续之前就消耗掉 momentum。
以前，如果第一个 working version 看起来要花几个晚上的 setup，我经常会把实验往后拖。AI coding tool 没有让这些工作消失，但它降低了 first pass 的成本，也缩短了到 testable version 的距离。
所以最大的收益并不是打字更快，而是更低的 activation energy：更多想法真的能走到可以收集 evidence 的阶段。
我的 Node.js workflow 实际发生了什么变化
我并没有用一个 chat window 替代开发流程。在 Node.js side project 里，我把 DeepSeek 当作处理明确小任务的 second pair of hands：起草第一版 implementation、阅读陌生 code、提出 test、分析 stack trace、拆分大型 refactor，以及检查 deployment assumption。
- Scaffolding：先做出 handler、validation、script 或 test 的枯燥第一版。
- Code reading：修改之前先追踪 request 或 value 的路径。
- Refactoring：把机械性改动拆成小而容易 review 的 diff。
- Debugging：从 logs 里生成多个假设，而不是相信第一个解释。
- Verification：happy path 跑通之后继续找 edge case 和 regression。
input、output、constraint 和现有 convention 越清楚，结果就越容易验证。模糊 task 更容易得到“看起来合理但 abstraction 错了”的答案。
因此我把 AI output 当作 candidate patch，而不是 final answer。Type checking、tests、build 和真实 flow 才是 evidence；自信的文字不是。
DeepSeek 最有帮助的地方，以及它不擅长的地方
DeepSeek 对我最有价值的一点，是可以在具体 programming task 上反复使用。我可以先要一个 first pass，丢掉其中一部分，把真实 error 发回去，缩小 scope，再快速 iterate。
我不会把这称为 benchmark。我没有和所有竞争 model 做 controlled study，而且 model lineup 变化很快。更可靠的说法是：DeepSeek 足够适合我的 workflow，以至于我使用 AI assistance 的频率明显提高了。
当问题有 function、tests 和真实 error 时，它表现最好；当 task 依赖没有写出来的 product context 或细微 architecture trade-off 时，它就弱得多。这种情况下，流畅的回答可能让错误 assumption 看起来像已经完成的 solution。
AI 改变的是“试错成本”
对我来说，最大的提升并不是“AI 会写代码，所以 development 自动化了”。真正变化的是很多小功能的尝试成本变低了。以前看起来需要太多 setup 的 side-project feature，现在有机会在我还对这个想法感兴趣时就做成 prototype。
这个区别很重要。AI 降低了做到可测试版本的成本，但没有让 architecture、产品判断、deployment 或 correctness 消失。生成的实现仍然可能错；build 成功仍然可能在 runtime 出问题；已经 deploy 的 prototype 仍然可能是一个糟糕的产品。
对我来说，实际收益是 momentum。一旦能看到整个系统真的跑起来，我就更愿意继续把它打磨下去。
更强的 benchmark 需要什么
如果要做可复现的 benchmark，我会记录精确 model version、固定 programming task、repository snapshot、prompt、raw output、耗时、accepted/rejected patch、review time、test result 和 rework。
还要测量 commit 之外的结果：从 idea 到 verified version 的时间、defect、rollback 和重写工作量。没有这些 context，4,000 次 commit 只能说明 activity 和行为发生变化，不能证明 software quality。
对我来说真正改变了什么
2025 年，我不再把每个 side project 都看成一座必须手工爬完的 setup 大山。AI 把第一个可运行版本的成本降到了足够低，让我更经常到达真正需要做产品判断的阶段。
这就是为什么我 GitHub 图表的下半年和上半年看起来完全不同。不是因为 AI 给了一天更多小时，也不是因为每一行生成的代码都很好。它只是减少了过去那些会让想法在真正成形前就死掉的 friction。
2026 年，我更关注这件事里不那么华丽的另一半：继续 refine workflow，更认真地测量 quality，并确认更快的 development 带来的是更好的 software，而不只是更多 commit。