AI写码浪潮下：理清需求才是核心竞争力

「在AI写代码的浪潮下，真正匮乏的是把问题想透彻的本事」

Karpathy的那段话，我是深夜熬夜刷资讯时刷到的。

当时已是凌晨两点多，正打算闭眼入眠。结果就看到他发了一条动态，声称当下最火的编程语言既非Python，也不是Rust，而是自然语言。

刚看到时，我起初没觉得有啥深意，可越琢磨越觉得震撼，导致我整晚都没睡着。

说实话，我敲代码将近十年，却从未有哪句话能让我对自身饭碗生出一种难以言喻的危机感，直白点说，就是产生了动摇。这十年里我有个很深的体会，就是越往后做越发现，真正的难点从来不在于技术栈怎么挑，不在于高并发怎么扛，也不在于哪个框架性能更优。真正的难点只有一个——

甲方究竟想要什么。

写代码本质上就是做转译。将人脑中的意图转译成机器能读懂的指令。你要A我就敲A，你要B我就敲B。

但绝大多数情况下，人压根不清楚自己究竟要啥。

列个数据。今年前六个月，GitHub上借助AI搭建的项目突破了十万个。OpenClaw，作为开源AI Agent框架，从零飙升到35万星，耗时不到60天。GitLab给出的数据表明，2026年第一季度新增的代码库里，41%的首次提交源于AI Agent。

并非人类手写，而是AI生成。

过去我会觉得这数据太夸张，难以置信。

如今我意识到，这仅仅是个开端。

别误会，我提这些并非为了贩卖焦虑。我是打心底认为，程序员岗位不会消亡。但「懂敲代码」这项技能本身，正在飞速掉价。

你自诩编码速度极快，可你再快也快不过AI；你自夸缺陷少，AI比你还少，毕竟它不需要靠灌咖啡和硬扛在凌晨三点修缺陷。你标榜自己精通各类框架，然而AI掌握的比你还多。

那还剩下啥？

我耗费许久思考这个疑惑，随后察觉到一件颇具讽刺意味的事：

这数十年的编程教育教给咱们的，或许从起步阶段就搞错了重心。

回想一下你学编程的经历。先学变量，再学循环，接着数据结构、算法、设计模式。整套体系的潜台词是什么——需求已定，安心敲代码即可。

基于此假设，需求成了定量，实现成了变量。谁的实现更精妙，谁就是优秀码农。

直至今日，多数技术面试仍沿用这套逻辑。

但AI将这层关系彻底逆转了。

当Cursor与Copilot能在数小时内搞定一个完整模块时，「实现」本身便从变量化为了定量。无论需求是啥，AI皆能输出，并且写得愈发优秀。

如此一来，原本的定量——需求——便化作了仅存的变量。

而在真实场景下，需求这东西，绝非一份罗列详尽的PRD。它往往是个混沌的想法，一句「我想弄个能搞定XX问题的玩意」，或是看完竞品后蹦出的「我能否搞个差异化的」。

这些，AI无法替你界定。它仅能在你界定清晰后辅助你落地。

在此我想同各位分享个案例。

有位做技术顾问的哥们，有次给一家中型企业做咨询，运营总监找来，声称需要一套数据报表系统。原话如此——「字段得极度灵活，各部门均可自定义，可操作务必极简，绝不能让员工嫌麻烦。」

灵活自定义与操作极简，竟凑在同一句话中。

你肯定明白这俩要求碰一块，势必有一方得让步。

我那哥们便多问了一句，是否每个部门都要自定义。

运营总监琢磨片刻。道出实情，其实仅财务与销售需自定义，其余六个部门用的几乎是雷同的标准模板。而所谓的「极简」，是针对那六个标准部门的一线人员，别让繁杂的配置项把他们吓退即可。

你瞧，同一人说出的一句诉求，实则暗含两个截然对立的期望。但这俩期望并非真源于同一伙人——它们分属两拨人。一拨是需灵活配置的专业团队，另一拨是仅需一键出报表的一线人员。

将两拨人拆开，冲突便化解了。给财务与销售开放高阶配置入口，给其余六个部门留存一键生成标准界面。

代码量相差无几，但用户体验的落差，可谓天壤之别。

这便是需求分析的核心工作，绝非照搬需求，而是拆解需求。

客户抛出的初版要求，通常自带三类硬伤。

第一、含糊

「体验要好」「速度要快」「界面要美」——写这些等同于废话。需求分析的职责便是将形容词转为可量化的指标，「速度要快」转为「页面加载低于两秒，五百并发不卡顿」，「界面要美」转为「统一下发设计组件，过WCAG 2.1无障碍标准」。

第二、冲突

这情形太普遍了。「既要安全又要省事」「既要大而全又要极简易」「既要能定制又要成本低」。你讲这是胡搅蛮缠吗，当然不是。实则，需求分析中一关键准则即是：用户提的需求永远有其合理性，无论多矛盾、多突兀、多棘手，其存续皆具相当逻辑，之所以现此窘况，是因缺一框架去理清各场景的优先级。此处便彰显出卓越需求分析师的功底：你助其将「既要又要」拆为「何时保啥」，价值即在此。

第三、缺失

这点最致命。客户聊需求时，立足其自身视角。他默认你懂其行话，懂其业务链路，懂异常咋处置。但你岂能全知。他不经意漏掉的边界条件，至开发期便是一场返工。故老手分析师皆有习惯——凡客户未提但你直觉有异之处，务必追查到底。

含糊变可量化。冲突变可权衡。缺失变可覆盖。

三步走完，你所得不再是乱糟糟的初版诉求。而是一份逻辑自洽、无自相矛盾、边界完备的规格说明。

此物，方是递给AI的纯正原料。

原料齐了。但仍缺一步。

此规格说明内的要求，究竟该由哪些功能模块来承担？

这便是需求设计。

「设计」此词极易遭误解。它并非指你挑了何类数据库、用了何款缓存、搭了何种微服务。那些归技术选型与详细设计管。

需求设计的使命仅一项——将敲定的客户诉求，映射作系统的功能模块骨架。

仍以报表系统为例，分析敲定了四点：财务部自定义字段与公式、销售部自定义图表样式、六个标准部门一键生成、所有报表可导PDF及邮件定时推送。

需求设计要解答的，是这些事该由哪些模块各自兜底。

经反复推敲，定下此系统应切分为四块。

报表模板引擎，兜底标准部门的一键生成；自定义配置中心，兜底财务与销售的灵活配置；数据查询与聚合层，兜底数据咋取咋算；导出与分发服务，兜底PDF生成与定时邮件。四块切毕，各司其职。改一块，其余三块免受波及。此骨架一搭，后续无论交AI写抑或手动写，你皆知进度几何。

需求设计最棘手之处，非想得细，乃切得准。切太粗，一模块塞满功能，AI上下文崩盘，写一堆缺陷互掐；切太细，模块遍地，接口乱飞，看着规整，调起来抓狂。

如何判别是否切得准，存三大准则：

1、高内聚：一模块内功能天然该扎堆。报表模板的增删改查皆置一模块，其共享一数据结构。

2、低耦合：模块间依赖越弱越佳。导出服务无需晓模板咋渲染，仅知你予我渲染后数据即可，此接口即契约。

3、可独立验证：各模块可单独测。模板引擎自个能跑否？导出服务自个能出PDF否？能，即切得准。

三则达标，你交AI的便是四个可独立迭代的模块，绝非一副拼不拢的拼图。

随后才是咋同AI协作。我初用AI写代码时特躁，需求丢进对话框便令其开干，结局是初版看着惊艳，改时想哭。

连踩无数坑后，如今我觉节奏应如此：

首步，令其复述，非令其直写。将设计文档投喂，令其以自身话重述一遍，若其复述跑偏，九成是你描述含糊。此招可揪出九成理解偏差，省下海量的修缺陷辰光。

次步，先跑通能动的壳。莫一上来便令其写齐功能，先跑一最小骨架，数据可存，页面可点，主干链路可通。此壳非用以交付，乃验证设计文档对否，诸多问题脑中查三遍未觉，系统真跑起，一眼便窥破。

三步，单次仅做一个模块。做完一个，测完，无虞再做下一个，前半程看似慢于一次写齐，然实则快于后半程。模块独立，出缺陷范围小，AI重写时上下文亦纯净。一次性生成，初看极爽，维护时痛不欲生。

四步，令其自写测试，自修复。此步极多略过。然恰是此步，划清了Demo与产品的界线。你同AI讲「用户输入为空需报错，不可宕机」，其便自写单测、跑测、察觉败、改码、再跑。此乃令AI替你打工，非仅帮你敲数行代码。

我近来常思一类比，导演与摄像，差异何在？答案是：摄像机谁都会摆，按快门即摄，但拍啥，不拍啥，取何视角，光影咋布，演员站哪——此类决断，方是影片优劣的根源。

我觉于AI编程期，优开发者正由摄像转作导演。他非死磕光圈快门，他脑中盘算的是此幕于全片担何戏份，此镜可否戳中观众情绪，此结局可否令客离场时心绪难平。

写代码本身，确乎愈发廉价，但能想透「究竟该写啥」之人，比往昔更抢手。

此有我近来悟出的一则经验公式，未受严苛论证，未必对，但我私觉大方向无差：

项目品质 = 需求分析的透彻度 × 需求设计的明晰度 × AI执行的效能

前俩因子由人定，你析得越深、设得越明，基数便越广。末个因子由AI定，其决乘数多高。

但若你基数归零，AI再强，乘毕仍归零。

回看Karpathy那话。他道最热语言乃自然语言，我初以为其赞AI强悍，后悟，其言实指人。因自然语言背后，非语法与词汇量。乃你能否将事理清，将矛盾捋顺，将念想落至可执行之地步。

此能耐，与代码无甚瓜葛，然与未来相系。AI难替所有码农，但仅会敲代码、不懂思虑的那类，确乎正加速掉价。