昨天刷GitHub Trending，又看到Ponytail了。
160k stars。
这个项目上个月就在trending，我以为热度会降，结果越涨越高。
README第一句话就把我整不会了：
“最好的代码是你没写的代码。”
我盯着这句话看了三分钟。
然后点了个star。
不是因为它说得多对，是因为这句话我信了18年，但直到今天，我都不敢说自己真的做到了。
先说说我为什么信这句话。
2008年，我刚工作第二年，参与了一个电商系统重构。
当时的技术负责人是个大神，写过好几本技术书的那种。
他带着我们搞了一套"完美的架构"。
分层清晰，依赖倒置，设计模式用了个遍。
代码写得那叫一个漂亮，每次code review都是教科书级别的示范。
结果呢？
上线三个月，业务方说要加个功能。
我们一看代码，傻眼了。
那个"完美的架构"为了支持"未来的扩展性"，加了无数抽象层。
一个简单的需求，要改7个文件，跨越4个模块。
最后那个功能延期了两周。
业务方直接找老板告状。
老板问：你们那个架构不是很牛逼吗？怎么改个功能这么慢？
技术负责人解释了一堆"技术债务"“架构复杂度"之类的词。
老板听完说了一句：我不管什么架构，我只要功能。
那天晚上，技术负责人请我们喝酒。
喝到一半，他说了一句话，我记到现在：
“我犯了个错误。我把代码写给了未来的开发者，但忘了现在的业务等不了。”
那是我第一次理解"过度工程化"的代价。
后来这些年，我见过太多类似的惨案。
有个项目为了"支持多数据库”，抽象了一个DAO层。
结果上线两年，只用过MySQL。
那个DAO层反而成了最大的负担，每次改查询都要改一堆接口。
还有个项目为了"未来可能的微服务化"，把单体应用拆成了十几个模块。
结果业务一直没起来，那十几个模块之间的通信成本反而比单体还高。
最后老板说：算了，合并回去吧。
合并的时候，大家才发现，那些模块之间的依赖关系已经乱成一团麻。
所以我第一次看到Ponytail的理念时，是认同的。
“最好的代码是没写的代码。”
这话没毛病。
但问题是，这个理念被AI放大之后，味道变了。
Ponytail是个AI编程技能包。
它让AI在写代码之前，先过6个问题：
- 这个功能真的需要吗？
- 能用现有组件实现吗？
- 能用更简单的方式吗？
- 能少写一行吗？
- 能合并吗？
- 能用一行代码搞定吗？
如果所有答案都是"不能"，才写最少量的代码。
听起来很美好对吧？
AI终于学会"偷懒"了。
但我想问一个问题：
如果AI真的"懒"了，谁来为那些"应该写但没写"的代码负责？
我见过一个用AI写的项目。
代码确实很少，看起来很"优雅"。
但一跑起来，到处都是bug。
为什么？
因为AI为了"少写代码"，把边界条件都省略了。
把错误处理都简化了。
把性能优化都跳过了。
最后那个项目上线后，用户一多就崩。
开发者回头一看，AI写的那些"简洁"的代码，根本扛不住真实场景。
这就是我想说的：
“懒"不是不写，是想清楚再写。
Ponytail的价值不是让AI偷懒，是逼AI先思考。
但很多开发者理解反了。
他们以为"少写代码=高级”。
于是让AI能省就省，能简就简。
最后代码是少了，但质量也没了。
我带了几年团队，见过两类新人。
一类是"写得多"的。
代码量大，但逻辑清晰，边界条件都考虑到了。
这类人需要学的是"简化"。
另一类是"写得少"的。
代码看起来很"优雅"，但一跑就出问题。
这类人需要学的是"完整"。
前者容易教，后者难。
因为前者是技术问题，后者是认知问题。
我见过一个新人，特别喜欢用"一行代码"解决问题。
每次code review，他的代码都是最短的。
但每次上线，他的bug都是最多的。
为什么？
因为他为了"简洁"，把可读性都牺牲了。
一个复杂的业务逻辑，他硬塞进一个三元表达式。
一个需要多步处理的数据流，他硬写成链式调用。
代码是短了，但维护的人想骂人。
后来我跟他聊了一次。
我说：你知道为什么资深开发者写得少吗？
他说：因为他们经验丰富，知道哪些可以省略。
我说：对，但不完全对。
资深开发者写得少，是因为他们知道什么时候该写，什么时候不该写。
他们省略的不是"必要的复杂度"，是"不必要的复杂度"。
这两者的区别，就是"懒"和"懒"的区别。
Ponytail的README里有一句话，我觉得比"最好的代码是没写的代码"更重要：
“懒不是 careless（粗心），是 efficient（高效）。”
这才是关键。
真正的"懒"，是把时间花在刀刃上。
不是不写代码，是不写没用的代码。
不是简化逻辑，是简化实现。
不是省略边界条件，是省略冗余的抽象层。
我现在的团队，有个规矩：
每次写代码之前，先问三个问题：
- 这个功能，业务真的需要吗？
- 这个实现，是最简单的吗？
- 这段代码，三个月后我还能看懂吗？
如果第一个问题答案是"不确定"，那就先别写。
如果第二个问题答案是"不是"，那就再想想。
如果第三个问题答案是"不能"，那就重写。
这不是Ponytail的规矩，是我们自己踩坑踩出来的。
回到Ponytail。
160k stars，说明很多人认同这个理念。
但我有点担心。
担心的是，这个理念被误解了。
很多人以为"少写代码=高级"。
于是让AI能省就省，能简就简。
最后代码是少了，但问题也多了。
我写过18年代码。
从Java写到Python，从后端写到全栈。
我见过太多"完美的架构"死在业务变化上。
也见过太多"简洁的代码"死在真实场景里。
我现在相信的是：
代码不是越少越好，是越合适越好。
该写的一行不能少，不该写的一行不能多。
这才是真正的"懒"。
昨天我又看了一遍Ponytail的README。
这次我没看"最好的代码是没写的代码"。
我看的是它的"Ladder of Laziness"（懒惰阶梯）。
6个问题，从"这个功能真的需要吗"到"能用一行代码搞定吗"。
我突然明白了。
Ponytail不是让AI"懒"。
Ponytail是让AI"想清楚再写"。
这才是它值160k stars的原因。
最后说一句。
如果你也在用AI写代码，别只盯着"少写"。
盯着"想清楚"。
代码可以少，但思考不能少。
这才是18年教会我的东西。