2024年Stack Overflow调研显示,76%的开发者每天用AI写代码,但仅12%认为产出质量有质变。差距不在工具,在打开方式。

Utkarsh Kulkarni在Medium发了篇帖子,标题很挑衅:「AI能完成任何任务,只要你用对方法」。不是「更快」,是「任何」。这哥们不是卖课的,是实打实写了8年代码的产品工程师。他的观察很直白——大多数人把AI用成了「聪明点的谷歌」,然后抱怨没惊喜。

「写代码」和「一起设计系统」之间,隔着一道认知墙

「写代码」和「一起设计系统」之间,隔着一道认知墙

Kulkarni举了个对比。同一需求,两种问法:

版本A:"Write code for this"(给这写个代码)

版本B:"Let's design this system step by step. First tell me the approach, then we'll code it together"(咱们一步步设计这个系统。先讲思路,再一起写代码)

第一种得到能跑的代码。第二种得到架构图、边界 case 讨论、可扩展性建议,以及——关键——一个能追问「这里如果流量涨10倍怎么办」的对话对象。Kulkarni管这叫「thinking partner」(思维伙伴),不是「code generator」(代码生成器)。

这区别类似请装修队刷墙 vs 请建筑师聊户型。前者交付结果,后者交付决策框架。

AI的三种隐藏身份,多数人只用了一种

AI的三种隐藏身份,多数人只用了一种

Kulkarni梳理了三个被低估的角色:

思维伙伴(Thinking partner)——卡壳时不是要答案,是要「怎么拆解这个问题」的视角。他举例:面对模糊需求,先让AI列出5种可行路径,再逐条评估 trade-off。

代码审查员(Code reviewer)——不是跑完测试就提交,是把 diff 丢给 AI 问「这里有没有我没想到的边界情况」。人类审查员会累,AI不会。

系统设计师(System designer)——新项目启动时,让AI扮演「有10年经验的老架构师」,先画模块图再写实现。Kulkarni强调:「它不会替你决策,但能把你没问的问题抛出来。」

这三个角色的共同点是:对话深度决定输出质量。浅层交互得到浅层结果,这是信息论的基本常识,但多数人操作层面忘了。

瓶颈从来不在AI,在提问者的「元认知」

瓶颈从来不在AI,在提问者的「元认知」

Kulkarni的核心判断很扎心:「The bottleneck is almost never the AI. It's the way we talk to it.」(瓶颈几乎从不是AI,是我们跟它说话的方式。)

他观察到两类典型误用:

第一类是「模糊输入→平均输出」循环。问得越笼统,AI越只能给安全答案。安全答案=平庸答案。

第二类是「工具心态」陷阱。把AI当快捷键,得到的就是快捷键级别的收益——省几分钟打字,思维没升级。

他的解法不复杂:想象对面坐着一个聪明但不懂你具体业务的同事。你需要提供上下文、明确目标、约定协作节奏。这和人类协作的常识一致,但面对AI时,很多人突然忘了怎么说话。

「Partner」vs「Tool」:一个词改变权力结构

「Partner」vs「Tool」:一个词改变权力结构

Kulkarni的帖子没提技术细节,全在讲关系定位。Tool 是单向的:你输入,它输出。Partner 是双向的:你提出半成品思路,它补全、挑战、迭代。

这种定位切换有实际代价。当 partner 用,你需要暴露思考过程——「我目前想到A方案,但担心B风险」——这比直接要答案累。但Kulkarni认为这正是价值所在:AI逼你把模糊直觉显性化,而显性化是清晰决策的前提。

他举的代码协作例子很具体:不是「给我写个登录功能」,是「我们设计一个登录系统,先讨论OAuth和自建session的利弊,选一种再实现」。时间未必更短,但返工率大幅下降。

为什么这个观点「unpopular」?

为什么这个观点「unpopular」?

Kulkarni自己解释了标题里的「unpopular」:极端说法容易引战,但「any task」是故意说的。他想戳破一种隐性假设——「有些工作AI就是做不好」。

他的反驳是:做不好的时候,先检查是不是用成了「问答模式」。写作、编程、数据分析、战略推演,他都试过用 partner 模式重做一遍,结论是「方法对了,天花板比想象高得多」。

当然他没说AI万能。原文明确限定:「if used correctly」(如果用对方法)。这个条件句很关键——不是鼓吹AI,是指出大多数人还没摸到正确用法的边。

一个值得试的本周实验

一个值得试的本周实验

Kulkarni没给 checklist,但逻辑很清晰:下次用AI时,把动词从「get」(获取)换成「build with」(共建)。不是「给我写」,是「我们一起设计」。

具体操作上,他建议加三步前缀:1)交代背景(我在做什么项目,约束条件是什么);2)明确角色(你现在扮演有经验的XX);3)约定节奏(先讨论方案,再分步执行)。

这会增加前5分钟的工作量,但减少后50分钟的返工。Kulkarni的原话:「You're not just getting answers. You're building something with it.」(你不只是得到答案,你在用它共建东西。)

最后留个他的观察:那些「actually getting ahead」(真正在进步)的人,早就这么干了。只是他们不声张,因为竞争优势在于「怎么用」,不在于「用没用」。

你最近一次用AI,是「查答案」还是「共建」?如果重来一遍,哪个环节可以改成对话模式?