谷歌3年没教会的事，有人用1句话让AI效率翻了4倍

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的三种隐藏身份，多数人只用了一种

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

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

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

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

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

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

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

他观察到两类典型误用：

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

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

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

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

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

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

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

为什么这个观点「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，是「查答案」还是「共建」？如果重来一遍，哪个环节可以改成对话模式？