最近在技术社区看到一个挺热的帖子既然AI写代码的能力已经这么强前端开发者是不是真的可以躺平了评论区里一半人说AI已经能替代初级工程师另一半人说它只是高级自动补全。两边吵来吵去倒是有一个名字反复被提到Matt Pocock。如果你不太混英文技术社区对Matt Pocock的印象可能还停留在“那个做TypeScript课程的”。没错他在面向开发者的学习内容上影响力不小尤其擅长把复杂的类型系统讲得接地气。但这两三年他的内容重心明显转向了一个更大的话题当AI能把代码写出来开发者还要具备哪些能力他给的答案跟大多数人预期的不一样。不是教你背提示词模板也不是推荐哪个AI工具而是从代码审查、类型约束、上下文组织、角色定位和工作流设计这五个方面重新定义了AI编程这件事本身。下面我把这五个关键问题一个个拆开讲每个都结合我自己在真实项目里的实操经历。看完你会发现真正重要的不是AI能吐出多少代码而是你怎么给这些代码设计一条靠谱的“生产工艺线”。1. 为什么“提示词技巧”不是AI编程的核心1.1 大多数人学AI编程一上来就跑偏了我见过很多团队开始用AI辅助编码时的状态先是某个人发现用AI写个小函数很快然后全组开始跟风再然后就是各种奇奇怪怪的代码混进仓库。为什么因为大家第一步都在找提示词模板——“你是一名资深工程师请用React实现一个可复用的表格组件”“你是一个懂性能优化的专家帮我分析这段代码”。这类话术确实能让输出质量有所提升但它解决的只是单次生成的问题。真正的工程问题在于AI给你吐了一个页面你怎么确保它能匹配现有的路由结构状态管理用哪种方案错误边界怎么处理测试能不能覆盖性能预算是否达标这些都不是一句提示词能解决的。用Matt Pocock这类专注工程效率的开发者视角来看AI编程的难点从来不在“让AI生成”而在“让AI生成的东西安全地进入你的代码库”。1.2 五个问题覆盖了从生成到上线的完整链路我把从项目的实际反馈中归纳出来的五个关键问题摆在这里你先感受一下这套逻辑第一个问题AI生成的代码到底能不能信——讲验证机制。第二个问题AI会让专业技能贬值吗——讲知识价值。第三个问题为什么AI有时候显得特别笨——讲上下文管理。第四个问题AI会不会取代工程师——讲角色变化。第五个问题怎么把AI编程真正落到日常流程里——讲工作流。这五件事不是并列的零散话题而是一条完整链路。生成之前你需要具备什么知识生成之时你喂给AI什么上下文生成之后你怎么验证长期来看你的岗位责任如何变化最后是团队怎么协作。任何一个环节出现漏洞AI编程都会从“提效工具”变成“事故源头”。我自己就见过不止一个团队跳过了这些环节最后不得不把AI辅助出来的代码全部推翻重写。1.3 这件事值得你现在花时间看的真正原因如果你只是拿AI给自己写点一次性脚本随便用无所谓。但一旦涉及生产代码、多人协作、长期维护的仓库上面每一个问题都会变成线上事故的潜在导火索。更现实的是很多团队现在招聘时已经开始考察候选人“是否具备和AI协作的能力”了。这里的“协作能力”不是说你会不会用工具而是你有没有一套可靠的流程去驾驭它。下面我就按顺序把这些问题掰开揉碎。2. 问题一AI生成的代码到底能不能信2.1 “看着对”和“真的对”之间隔着一整个工程AI生成代码最大的坑不是语法错误而是“看着对”。它生成的函数往往语法正确、逻辑自洽代码风格还像模像样可它没有你项目里的完整背景。它不知道你的代码规范、不知道你的运行时环境、不知道某些历史遗留问题的成因也不会主动告诉你某个边界条件它根本没考虑。我把这个称为“看着对陷阱”。你用眼睛扫过去觉得这段代码没问题代码审查也就是走个过场结果一上线就出问题。在我接触过的团队里这类问题最常见的形式包括忘记处理loading状态、没考虑空数组边界、异常捕获吞掉关键错误、组件卸载之后还去setState。AI不会主动告诉你这些因为它的训练数据里这些场景太多了它只是选了一个“最像样”的模板套上去。2.2 三层校验法类型、测试、人工审查从实际工程经验来看要把AI代码的可信度拉上来需要建立三层校验机制。第一层是类型约束让类型系统成为第一道筛选网第二层是自动化测试把验收条件写成代码AI生成的实现跑不过就是不合格第三层是结构化的人工审查带着问题清单去看AI代码而不是例行公事地扫一眼。这三层缺一不可。类型能拦掉大量低级错误但拦不住业务逻辑错误测试能验证行为但测试本身也可能被AI带偏人工审查最贵但能发现前两层漏掉的设计问题。把这三层建立起来之后AI代码通过率会明显提升更重要的是团队对AI产出物的信心会逐步建立。2.3 直接看一个实例AI写的防抖函数我拿一个最常见的例子来说。有次我让AI写一个防抖函数它给出了这样的第一版// AI 第一版看着完全正常 function debounce(fn: Function, delay 300) { let timer: ReturnTypetypeof setTimeout return function (...args: unknown[]) { clearTimeout(timer) timer setTimeout(() fn(...args), delay) } }乍一看没毛病类型标注也像那么回事。但拿真实项目的三层校验一过立刻暴露问题它没有处理回调里的this绑定如果这个函数被作为对象方法调用this会丢它没有返回取消方法组件卸载后定时器还在跑触发回调后会引发“在已卸载组件上更新状态”的告警它也没有考虑连续触发时的竞态问题。我们逐层修正之后代码变成这样// 改进后处理了 this、取消和竞态 type DebouncedFnA extends unknown[] { (...args: A): void cancel: () void } function debounceA extends unknown[]( fn: (this: unknown, ...args: A) void, delay 300 ): DebouncedFnA { let timer: ReturnTypetypeof setTimeout | undefined let lastThis: unknown const debounced function (this: unknown, ...args: A) { lastThis this clearTimeout(timer) timer setTimeout(() { fn.apply(lastThis, args) timer undefined }, delay) } debounced.cancel () { clearTimeout(timer) timer undefined } return debounced }看到没有AI并不是不能用它只是不知道你的场景里需要这些边界处理。真正让代码能用的是你知道要检查什么、怎么补全。这也是为什么Matt Pocock一直强调“AI不会降低对你的要求它只是把你从写代码的体力劳动里解放出来然后让你把精力放到更高级的判断上”。2.4 审查AI代码时的三个具体盯防点在实际审查AI生成的代码时我给自己定了几条硬规矩。第一凡是涉及异步逻辑的必须检查错误处理和竞态条件。AI特别容易生成“Promise.all直接平铺”的代码不处理失败情况。第二凡是涉及外部接口的必须检查参数校验和响应结构假设。AI常常按它记忆中的接口文档来写而你的后端早就变了。第三凡是涉及状态管理的必须检查生命周期。组件卸载、页面跳转之后的状态更新是AI错误的高发区。这几条听起来像是常识但AI时代反而更容易被忽略。因为人看到AI生成了完整代码本能地就会降低警惕。越是代码看起来完整你越要提醒自己这只是一份需要验证的初稿。3. 问题二AI会让专业技能贬值吗3.1 技能不是不需要了是用途变了每次有人问我“现在AI都能生成TypeScript类型了还有必要学类型系统吗”我都会反问一句那AI生成一个错误类型推断你一眼能看出来吗如果看不出来你怎么知道它错了这就回到了Matt Pocock反复强调的核心观点AI没有减少你需要学的东西它只是把你学到的东西用在一个新地方。以前你需要会写类型现在你需要会“审类型”。以前你需要会写算法现在你需要会判断AI给出的算法在数据量翻一百倍之后会不会崩。以前你需要自己读完整代码库现在你需要快速定位“AI改错了哪一行”。这些能力建立在扎实的语言功底上不是AI施舍给你的。3.2 判断力比记忆力值钱多了我拿我遇到过的真实情境说明。有次让AI给一个接口返回类型补全它生成了一堆看起来非常严谨的联合类型用了一堆as const、satisfies、Exclude之类的关键字。乍看之下很专业。但实际用下来发现它把该用union的地方做成了intersection结果导致接口的实际返回类型被推断成了never。那个问题如果在代码评审环节没被发现线上接口基本就废了。会写对应类型的人可能满大街都是但能看出这个类型设计有问题的人还是少数。因为后者需要理解类型之间的兼容性、需要知道运行时数据到底长什么样、需要能区分“看起来对”和“语义上对”。这些能力没有什么AI工具能直接给你它们来自长期的实践积累。3.3 领域知识成为最后的护城河AI还有一个绕不过去的短板它不知道你的业务。它知道很多常见的用户交互模式但它不知道你的产品为什么这么设计、你的目标用户会在什么场景下使用、你的历史数据包含哪些特殊性。比如我在一个数据可视化项目里让AI生成图表配置它写出来的东西完全符合文档但根本不符合我们业务对数据精度的要求。所以我这几年越来越觉得未来的开发者核心竞争力会从“我能写什么技术”变成“我懂这个业务需要什么技术”。AI能帮你把技术实现做出来但“做什么”和“为什么做”的决策判断依然是人类负责。这也是为什么Matt Pocock在一次分享里把开发者形容成“被AI放大的决策者”——你不是被替代了你是被放大了但前提是你真的有决策能力。3.4 别再把学习计划全砍了现在有一种风气学编程先从怎么用AI开始。我觉得完全反了。AI编程应该是在你已经有了一定基础之后才接触的东西因为你需要一个基本坐标系来判断AI的输出质量。我自己带过一个实习生上手就让他用AI写接口结果他完全无法判断AI返回的ORM查询语句是否高效甚至看不懂生成的错误类型。我的建议是如果你还在学习阶段优先学好语言基础、设计模式、调试技巧。这些是建立判断力的根基。把AI当成“练习题生成器”可以但别当成“作业代写器”。当你发现自己能一眼看出AI代码的问题在哪那才是你真正学会使用AI编程的时刻。4. 问题三为什么AI有时候显得特别笨4.1 上下文质量决定输出质量很多人抱怨AI编程工具“抽象理解能力差”但仔细看使用过程往往是上下文喂得不够。如果你把一个5000行的文件整个丢给AI它反而会糊涂如果你只给它一句话需求它写出来的东西也大概率偏。真正有效的做法是在相关信息和干扰信息之间做取舍。这里有一个生活化类比。你让一个实习生去帮你改一段代码你会怎么做你会把仓库地址给他告诉他改哪几个文件说明白为什么改提醒他哪些地方绝对不能动还要告诉他怎么验证改对了。你绝不会甩一句“你去把这个bug修了”。AI也一样它没有读心术它的能力上限很大程度上由你喂的信息质量决定。4.2 “开小窗”和“给全貌”怎么选在实际操作中上下文给多给少要看任务类型。我一般分成三类来区别对待局部函数修改只给函数签名、相关类型、调用方代码、对应的现有测试。不要给整个模块更不要给整个项目。新建模块给出项目结构概览、技术栈、编码规范、目标接口定义、参考实现示例。让AI知道它身处什么环境。老代码重构给出历史设计文档、公共依赖关系、相关代码负责人注释。重点是让它知道哪些约定不能破坏。这个分类不是拍脑袋定的。局部函数修改如果给了大全局AI会尝试那些它自以为聪明的上下文出现过度设计新建模块如果不给全貌AI又会把项目约定忘掉接口风格和现有代码对不上。上下文管理的本质就是把“AI可能需要知道的信息”和“AI不需要知道的噪音”分开。4.3 一个精简的上下文模板以修bug为例我自己在日常工作中会用一个相对固定的模板目标修复登录按钮在移动端无响应的问题。 限制不要改动后端接口不要改样式主题不要动其他页面。 涉及文件src/components/Login/LoginButton.tsx 涉及依赖LockIcon, useAuth 现有测试src/components/Login/__tests__/LoginButton.test.tsx 复现步骤在iPhone Safari打开登录页点击登录按钮无反应控制台无报错。 期望行为点击后触发onSubmit回调并进入loading状态。这个模板看起来简单但它把任务边界、影响范围、验证方式都说清楚了。AI收到这样的上下文之后输出的代码质量会明显提高因为它不需要在大量无关代码里猜你的意图。这也是Matt Pocock从实战出发强调“约束”的逻辑——你给AI的约束越明确它发挥的余地越小犯错的概率就越低。4.4 上下文是给AI看的也是给队友看的这里还有一层容易被忽略的价值。当你把任务上下文组织得清晰了这些信息对同事也是有用的。它天然形成一个“任务说明书”代码审查的人能快速理解你为什么这样改接手的人能快速进入状态。所以组织上下文这件事不只是“喂AI的”还是“给团队留痕的”。久而久之它会让你的代码评审记录、PR描述、开发文档都变得更有条理这算是AI编程带来的一个意外收益。5. 问题四AI会不会取代工程师5.1 会被取代的是“只会接需求”的角色把话说直接一点如果一个人的全部工作就是拿到需求、照着写代码、跑通、提交那AI确实有能力做掉很大一部分。因为这就是模式匹配AI的学习能力远超人类。但一个真正的工程师岗位远不止这一步。从我对实际岗位的观察来看越靠“执行”的任务被取代的风险越高越靠“判断”的任务价值反而越会上升。需求背后的业务逻辑要不要深挖技术方案的取舍是基于哪些条件线上故障怎么分级响应多人协作时怎么对齐设计意图这些判断和决策当前AI很难替你完成因为它不拥有你的项目历史、团队文化、用户情绪。5.2 角色从“写代码的人”变成“定义问题和验收标准的人”Matt Pocock的解法特别强调一个转变你应该把自己定义为“问题定义者”和“代码评审负责人”而不仅仅是“代码生产者”。如果一个工程师的工作流程是“先把需求搞清楚→定义验收标准→让AI去写初稿→自己把关质量”他其实是非常安全的。因为他的核心价值不再被AI的编码能力追赶而是被自己的判断能力决定。这个变化也直接反映在时间分配上。以前我写一个功能大概八成时间在敲代码两成在想逻辑。现在反过来了。我用AI生成初稿可能只需要半小时但我要花两三个小时去验证它、审查它、修补边界。省下来的时间并没有消失而是转移到了更需要脑子的地方。5.3 团队分工正在发生的实际变化图表对比一下传统开发和AI编程时代的分工变化维度传统开发模式AI编程模式核心产出编写的代码量经过验证的可交付功能核心技能语法熟练、框架知识问题拆分、验证、审查能力失败模式写出错误代码放行AI生成的错误代码时间分配大量时间在“写”大量时间在“验证”和“重构”初级成员定位从写简单模块开始练手从审查AI初稿开始学判断最后一行特别重要。以前初级工程师靠“写代码”练手练的是手感。现在初级工程师可以直接接触大量AI生成的质量参差不齐的代码练的是判断力。如果带教的人能引导好“把AI代码改好”比“自己写一百行”学到的东西更多因为你被迫理解每一行代码背后的为什么。这个转变做好了团队了几年的经验密度可能被压缩到几个月。5.4 一个预防针别把自己骗了这里我要插一句真实感受AI“取代人”的焦虑很多时候不是来自AI能力而是来自工作方式的惯性。我看到一些人让AI写了几乎所有代码自己只做“复制粘贴”最后代码出了问题他完全无法排查因为他根本不知道AI写了什么。这种状态下AI确实取代了他——因为他的位置变成了“传声筒”。所以你真正需要的不是不焦虑而是主动改变自己的工作流把判断和验证的责任抓在自己手里。6. 问题五怎么把AI编程落地到日常工作流6.1 落地时最容易翻车的三个细节很多团队用AI编程失败的案例不是AI不够强而是流程设计有漏洞。我总结出三个最常见的坑。第一没有强制评审AI代码直接进主干。这几乎是灾难级的。AI生成速度太快一旦没有人工关卡仓库会在很短时间里混入大量未经验证的代码而且这些代码之间还会互相依赖等发现问题时已经很难拆解了。第二项目特有的知识存在旧文档里、人的脑子里AI完全接触不到。结果就是AI每一次都在重新猜测你的业务逻辑每次都要你不断纠正同一类型问题。第三团队成员用AI的方式差异太大明明是一个团队产出的代码却来自完全不同的“AI性格”有的太啰嗦有的过度抽象有的完全不用类型。这样“代码的主人”反而成了最不稳定变量。6.2 一套实测下来比较顺的流程我在自己参与的团队里跑过一段时间目前比较稳定的一套流程大概是这样的把需求拆成尽量小的任务每个任务至少有一条可验证的验收条件。写清楚任务目标、边界限制和影响范围也就是把它变成一份AI可读的上下文说明。让AI生成初稿但明确告诉它“这是第一版后续有人工审查”。跑类型检查、Lint、单元测试把机械性能问题先筛掉。如果测试没过把失败信息反馈给AI让它依据报错信息自修正。不要在这里手写修代码让AI再迭代一次。通过之后人工做一次结构化审查重点看边界情况、性能隐患、业务语义是否真的对上。如果有问题把修改后的代码再次回传给AI让AI生成差异说明和新增测试用例让这次修改也留下记录。这套流程最大的好处是AI的产出质量会被持续校准而团队的关键审查责任始终握在人手里。跟“让AI全自动写一堆代码再一起改”相比这种“小步快跑频繁验证”的方式在真实项目中更稳。6.3 给团队协作的三条具体建议如果你在团队里负责推行AI编程我有三个很具体的建议可以实践。第一把编码规范写进一个AI可读的CONTRIBUTING.md并且用清晰的示例说明“符合我们团队风格的代码长什么样”。这样AI在生成代码时就有了显式约束而不是靠猜。第二要求所有AI辅助提交都在PR描述里标注“哪些代码由AI生成哪些是人工修改”。这会在潜意识层面提醒所有人AI代码依然需要过一遍完整评审。第三每周固定收集一次AI出错案例整理成清单下次把这些反问句放入团队的标准上下文模板里。比如“这个功能有没有处理空数组loading状态会不会闪烁组件卸载后会不会有异步回调”AI会越来越贴近你的项目你也会越来越清楚AI的弱点在哪里。6.4 工具选型不是第一优先级很多人落地AI编程第一步卡在工具选型上这个编辑器好还是那个插件好模型用A还是B我的观点很明确在流程没建立之前谈工具没有任何意义。你先把任务拆分方式、评审机制、上下文模板定下来工具只是承载这些流程的容器。就算明天出一个更强的AI只要你流程是完整的你只需要把老工具换掉就行团队能力不会因此断裂。反过来如果流程稀烂换再强的工具也救不了。7. 我在实战中的一些观察与心得写到这里该说的流程和方法都说得差不多了。最后聊点不那么“技术”的东西。我自己真正开始把AI编程当成主力辅助是差不多一年前。最初的感觉确实很爽原来要写半天的工具函数AI几秒就出来了。但用了一周之后我产生了一种新的焦虑不是“怕被取代”而是“怕漏过错误”。因为代码生成速度太快了快到我的审查速度跟不上这种感觉挺奇妙的。后来我慢慢调整了心态。我开始把AI当成一个“写代码风格很像你但记性很差的实习生”。它会做出看起来很懂事的判断但它不一定知道你上个星期刚踩过的坑。你可以让它跑腿、让它出初稿、让它做重复劳动但你必须守好最后一道关。想明白这一点之后AI编程给我带来的效率提升才真正变成正向的。我也重新开始重视那些以前觉得枯燥的基础功夫写清晰的类型、写有意义的测试、拆干净的函数边界。因为AI时代这些基础的“可验证性资产”成了你和AI协作的接口。你的类型越准AI越不可能跑偏你的测试越全AI的每一次回归都会立刻暴露。某种意义上我刚入行时学的那些工程纪律现在全都在AI协作场景里重新变得重要了。如果你刚开始接触AI编程我给你的建议就一条不要追求让AI一次写对一个大功能而是让它一次只写对一个小模块然后建立起验证、修改、再验证的闭环。这个习惯比任何提示词技巧都值钱。这也是Matt Pocock的解法给我最大的启发AI编程的真正主角永远不是AI而是你掌控质量的能力。把这五问想清楚你就不会在AI浪潮里随波逐流而是把工具变成自己的杠杆。
