反着来的工作流
主流叙事里 AI 编程的卖点是快，作者偏偏把它用慢：写完代码让模型挑刺、追问边界情况、要求它解释每个设计取舍，像旁边坐了个不知疲倦的资深审查者。产出速度是降了，可返工率和线上事故也降了。作者那句话说得挺准——以前的瓶颈是打字速度，现在的瓶颈是思考质量，AI 两头都能放大，看你往哪头使。
这套用法挑场景
它显然不万能。原型验证、一次性脚本这种「快就是对」的活儿，照作者那样做纯属浪费；它适合的是长寿命、改一次代价很高的核心代码。讨论区有个观察挺有意思：团队里最资深的人往往自发用出这种模式，新手却默认把 AI 当代笔，于是工具放大了两类人本就有的习惯差距。怎么把前一种用法变成团队默认，恐怕比纠结选哪家模型更要紧。
via: Hacker News