微软工程师用3个月证明：写不出代码的人，99%卡在同一个死循环

我见过太多人卡在"准备学编程"这个阶段超过两年。他们收藏了127个教程，关注了43个技术博主，GitHub账号注册了，但提交记录为零。

一位微软工程师最近复盘了自己的经历：他花了三个月才完成人生第一个待办清单应用，而真正的编码时间可能只有8小时。剩下的时间全在原地打转——改需求、换技术栈、推翻重来。

AI都懵了：你到底想造什么？

他试过让AI辅助写代码。结果工具给出的回应像一盆冷水："你到底想建什么？先决定，再开始写。"

这句话戳中了无数人的盲区。我们总以为编程的门槛是语法、算法、数学，但这位工程师的发现是：门槛其实是"定义问题"的能力。

他的典型工作流程是这样的：今天想做个待办清单，明天觉得应该加上标签系统，后天发现日历视图更酷，大后天听说某个框架更好用于是整体迁移。每个想法单独看都合理，串在一起就是灾难。

最终产物像个弗兰肯斯坦——能动的部分互相不认识，不能动的部分不知道为什么会存在。

那个被忽略的"启动成本"

技术社区有个长期被低估的概念：启动成本（activation energy）。不是指环境配置，而是从"我想做"到"我知道第一步做什么"之间的认知距离。

这位工程师的待办清单项目，启动成本消耗了他90%的精力。真正写循环语句、操作DOM、处理本地存储的时候，反而很顺畅。

问题出在反馈机制。传统学习路径给你的是"先学HTML，再学CSS，再学JS"——但没人告诉你，这三个东西怎么在一个具体目标里咬合。于是你学完了每个零件，面对空白的编辑器依然发呆。

他的转折点来自一个粗暴的约束：先用最丑的方式实现核心功能，48小时内不允许添加任何新特性。

这个规则逼他直面一个事实——他一直在用"完善功能"来逃避"完成闭环"。

为什么AI反而暴露了问题

有趣的是，AI工具在这里扮演了镜子角色。当你输入模糊指令时，它的追问机制把"需求不清"翻译成可感知的阻力。

这位工程师描述的体验是：AI不会替他决定"要不要做日历视图"，但会逼他先回答"用户怎么添加任务"。这个颗粒度的差异，正是业余爱好者和专业开发者的分水岭。

他后来总结了一个自测标准：如果你没法用一句话向AI描述下一步要做什么，说明你还没准备好写这行代码。

这句话的残酷之处在于，它把责任完全推回给学习者——没有框架可怪，没有教程不够好的借口。

那个三个月的待办清单教会他的

项目最终上线时，功能比他最初设想的少了60%。但这是他第一次能把一个东西从头到尾讲完：用户打开页面，输入文字，点击保存，数据存在哪里，下次怎么取出来。

这个闭环的价值被严重低估。技术社区热衷于讨论"构建什么"，但很少有人承认：对初学者来说，"完成什么"才是稀缺体验。

他现在带新人时会问两个问题：你的最小可用版本是什么？以及，什么功能绝对不允许在第一个版本里出现？

第二个问题尤其重要。它预设了一个前提——你会忍不住加东西，所以提前给冲动上锁。

这位工程师的GitHub现在有超过30个仓库。最早的那些全是半成品，最近的几个都有明确的"完成"标记。变化的不是他的技术能力，而是他对"开始"的定义。

你收藏夹里 oldest 的那个教程，距离今天多少天了？