AI编程通关手册：从傻白甜到甩手掌柜！本文基于马特波科克Matt Pocock的AI编程工作坊视频，阐述利用AI高效写代码。核心观点是先做人类主导的“拷问式”规划，再用AI自动执行，把大任务切小，始终保持在AI的“聪明区”干活。
发表日期：2026年5月11日
原文标题：Full Walkthrough Workflow for AI Coding — Matt Pocock
作者背景：Matt Pocock，资深编程教师，TypeScript专家，AI编程工作流讲师
很多人用AI写代码其实在用笨办法
大家好。我是Matt。今天咱们聊点实在的。
先问大伙一个事儿。你用过AI写代码对吧。天天用的也请举手。好。再问一个，被AI气到想砸电脑的请举手。哈哈哈，基本上所有人都举手了。这说明什么？说明AI这玩意儿，好用是好用，但坑也多。
为啥会这样呢？因为很多人压根没搞明白AI的脾气。
AI不是人。它有它自己的毛病。你要是把它当人使唤，它就会给你搞出一堆幺蛾子。我今天就把我过去半年踩过的坑、总结出来的套路，一股脑儿倒给你。
先给你一个核心结论，你记住就行。
用AI写代码的正确姿势是：先花时间让AI把你“拷问”到崩溃，把需求彻底对齐，然后你就可以翘着二郎腿，让AI自己通宵干活。你白天喝茶，它晚上卖命。这才是人过的日子。
是不是听着有点反直觉？别急，我给你掰扯清楚。
AI有两个致命毛病你得先知道
咱们先把AI的底裤扒了看看。
第一个毛病，AI有聪明区和笨逼区。
啥意思呢？你每次开一个新对话，AI就像刚睡醒精神小伙，贼聪明。你问什么它都答得漂漂亮亮。但是，随着你不停往对话里塞东西，它就会越来越笨，直到最后变成一个智障。为啥呢？因为它每次加一个新内容，就要跟之前所有的内容重新“拉关系”，这种关系数量是呈平方级增长的。就像你搞一个足球联赛，每加一支球队，要打的比赛场次不是加一场，而是加好多场。所以AI的脑子就会被撑爆，就开始犯糊涂。
我个人的经验是，大概100K tokens左右，也就是差不多7万到10万个词儿，AI就开始往笨逼区滑了。现在有些AI吹自己有一百万的上下文窗口，但那个窗口是用来“找东西”的，不是用来“写代码”的。你让它在一百万字里翻出一句话，它行。你让它一边记着一百万字一边写代码，它就废了。
所以你记住一个数字：100K。这是AI的黄金工作区。
第二个毛病，AI跟电影《记忆碎片》里那哥们儿一样，记性极差。
你每清空一次对话，它就回到出厂设置。之前聊啥全忘光。但是这个特性反而是个宝贝，你待会儿就明白了。
所以总结一下：AI在100K以内的对话里最聪明，你需要不断地清空对话让它保持聪明，而不是让它一直傻下去。这就引出了咱们的核心打法：把大任务切成小任务，每个小任务都在AI的聪明区里完成。
拷问式规划才能让你和AI想到一块去
好，现在咱们开始干活。
你拿到一个需求，比如老板跟你说：“咱那个学习平台，学生上几节课就跑路了，你给我加点游戏化的东西，搞点积分啊等级啊什么的。”
你是不是脑子里已经开始想代码了？别急。你这时候最需要做的，不是写代码，甚至不是写计划，而是让AI“拷问”你。
啥叫拷问？
我写了一个技能叫“拷问我”。这玩意儿巨短，就几行字。核心意思就是：你给AI一个需求描述，AI会像记者一样，一个问题一个问题地追问你，直到它彻底搞明白你到底要啥。
我给你演示一下。
我清空对话，调用“拷问我”技能，把老板那条消息扔进去。AI立马派出一个探子，把我的代码库翻了一遍。然后回来问我第一个问题。
“积分怎么算？完成什么动作给积分？给多少？”
AI自己还给了一个建议：保持简单，两个积分来源就够了。看完一个视频给多少，做完一个测验给多少。
我说行，听你的。
然后它问第二个问题：“要不要给老用户补积分？他们之前已经上过的课，要不要算？”
这个问题就毒了。你想过吗？肯定没想过。老板也没想过。但如果你不解决，到时候老用户一看，我上了这么多课居然零分，这不公平啊，立马骂娘。
AI给我的建议是不补。我也懒得折腾，就说不补。
它接着问等级曲线怎么定，UI放哪儿，要不要搞连胜奖励。一个接一个，能问出四十到八十个问题。有人甚至被问到过一百个。
这个过程就是让你和AI“对齐”。你俩脑子里的画面得一样。你说“加积分”，你脑子里想的是小红花，它脑子里想的是比特币，那最后做出来能一样吗？
Frederick P. Brooks在《设计的设计》那本书里说过，做任何项目，所有参与者脑子里的“设计概念”得是同一个。这话是几十年前写的，放今天一样管用。你跟AI之间，缺的就是这玩意儿。
所以拷问式规划的价值在这儿：它不是让你写一份没人看的文档，而是让你和AI脑子里那幅画变得一模一样。
这个阶段，你人必须在。你不能甩手。因为只有你才知道真正的业务要啥。但是没关系，这个阶段也就一个小时左右。熬过去，你就解放了。
规划文档不是让你读的是让你存档的
拷问结束之后，你手里就有了一个长长的对话记录。这里面全是宝贝。你们俩对齐的所有细节都在里面。
但是你不能就这么扔给AI让它去写代码。因为你如果把整个对话塞给AI，它马上就进笨逼区了。一百K的额度，可能拷问阶段就用掉了一半了。
所以你需要做一件事：把对话浓缩成一份“产品需求文档”，也就是PRD。
我写了一个“写PRD”的技能。它会自动把刚才的拷问记录，整理成一份结构化的文档。里面包括：问题是什么、解决方案是什么、用户故事有哪些、我们做了哪些技术决策、有哪些测试要点。
这份文档写出来之后，你猜我看不看？
我不看。
为啥？因为AI的总结能力是它最强的地方。我相信它能总结好。而且，我跟AI已经对齐了，我脑子里的画面和它脑子里的画面是一样的。我再去看那份文档，其实是在考验AI的总结能力，而不是在检验需求对不对。那我看它干嘛？
所以PRD这东西，本质上是给AI自己看的“目的地地图”。你不需要在上面花太多功夫。你就当它是存档就行。
但是有一个细节你得注意。PRD里要写清楚“什么不做”。这一点太重要了。因为你不说清楚边界，AI就会放飞自我，给你搞出一堆花里胡哨但是没用甚至有害的东西。
好，现在你有了一个目的地。你知道你要去哪儿了。下一步就是怎么走。
把大任务切成小任务得用切蛋糕的办法
传统的做法是这样的：你让AI给你列一个分阶段计划。第一阶段做数据库，第二阶段做API，第三阶段做前端。然后你按顺序执行。
这个办法是错的。
为啥？因为你到第三阶段才知道整个系统能不能跑通。万一前两个阶段有坑，你到了第三阶段才发现，那就得回去重来。反馈太慢了。
AI最喜欢这种“横着切”的方式，因为这样每个阶段看起来都很整齐。但是这种整齐是假象，是陷阱。
正确的做法是“竖着切”。
啥叫竖着切？就是每个任务都要从数据库一路干到前端，完整地实现一个小功能。比如“在个人主页上显示用户积分”，这是一个完整的竖条。它要改数据库存积分，要写后端逻辑算积分，要在前端页面展示积分。这一刀下去，你就能在浏览器里看到一个完整的、能用的东西。
这叫“曳光弹”。
这个词来自《程序员修炼之道》那本书。原意是说，晚上打飞机，你普通子弹打出去看不见弹道，不知道打没打中。但你要是每隔几发装一发曳光弹，它一边飞一边发光，你就能看见子弹的轨迹了，就知道该怎么调整瞄准了。
做项目也一样。你得尽快看到一条完整的光路。你得尽快知道整个系统能不能跑通。这样你才知道下一步怎么调整。
所以当你把PRD拆成具体任务的时候，你要确保每一个任务都是一个垂直切片，都是一个完整的小功能。这样AI在做一个任务的时候，跑完就能看到成果，就能跑测试，就能给你反馈。你很快就能知道这个任务做对了还是做错了。
我写了一个“拆PRD为任务”的技能。它会自动把PRD拆成垂直切片，还会标明任务之间的依赖关系。哪些任务可以同时做，哪些任务必须等前面的做完。这就是一个看板，跟工厂里生产线上那种看板一样。
这时候你就可以开始真正的“甩手模式”了。
让AI当夜班你可以潇洒下班
任务看板做好了。依赖关系标清楚了。你现在要做的就是把这个看板交给AI，让它自己去干。
我写了一个叫Ralph的循环脚本。名字来自于《辛普森一家》里那个傻乎乎的警长。这个脚本的逻辑特别简单。
第一步，读看板。看当前有哪些任务可以开始做。那些没有被任何任务挡着的，就是可以做的。
第二步，挑一个任务。优先挑修bug、搞基础设施、然后才是做新功能。
第三步，执行任务。AI自己探索代码库，自己写测试，自己实现功能，自己跑测试看跑不跑得过，自己修bug。全部自己来。
第四步，提交代码。然后回到第一步，继续挑下一个任务。
这个循环可以一直跑，直到所有任务做完。
而且你可以同时跑好几个AI，每个做不同的任务。只要任务之间没有依赖关系，它们就可以同时干。这就是并行。效率杠杠的。
我把这个循环放在Docker沙箱里跑，这样AI再怎么折腾也不会把生产环境搞坏。它改的只是一个临时的分支，测试通过了我再合并进来。
这个过程里，你人可以在干别的。喝茶、开会、睡觉都行。因为AI是自己在那儿跑。
当然，你时不时得回来看看。看看它写的代码怎么样，看看功能对不对。但你再也不用坐在那里手把手教它写代码了。
你就成了管理者，而不是搬砖的。
有人说这样搞出来的代码质量不行。我不同意。前提是你要把测试写好。
这就要说到一个关键点：测试驱动开发。
测试是让AI别犯傻的唯一办法
如果你不给AI写测试，它就会放飞自我。
它会写那种“看起来对但实际错的”代码。它会写那种特别取巧的测试，比如直接mock一个结果就完事了，根本不测真实逻辑。它会写出各种匪夷所思的bug。
唯一的办法就是逼它用测试驱动开发，也就是TDD。
TDD的流程是：先写一个肯定会失败的测试，然后写代码让这个测试通过，然后再回头优化代码。红-绿-重构，三步骤循环。
这样做的好处是什么？
第一，AI没法偷懒。因为测试是它先写的，它就知道自己要实现什么目标。它不能随便写个东西糊弄过去。
第二，代码质量有保障。每个功能都有对应的测试。以后再改东西，跑一遍测试就知道有没有搞坏别的地方。
第三，反馈快。AI写一段代码，马上跑测试。没过就改。这种秒级反馈让AI能迅速调整，而不是闷着头往前走然后走到死胡同。
我观察到的一点是：你的反馈循环的质量，直接决定了AI输出的质量。如果你的测试写得一塌糊涂，AI写出来的代码也一塌糊涂。如果你的代码库里连测试都没有，那AI写出来的东西就纯属瞎蒙。
所以，想让AI干活靠谱，先把测试搞好。让每次改动都能被快速验证。这是AI能独立工作的基础。
把代码库搞成AI友好型才省心
讲到这里你可能在想：我这代码库烂得跟屎一样，AI进去肯定也是屎进屎出，怎么办？
你说对了。垃圾代码库只能产生垃圾输出。因为AI不像人类那样能看懂屎山代码里的潜规则。它只能看到表面的逻辑。如果代码库本身就是一坨乱麻，AI进去也会被绕晕。
那什么样的代码库AI最喜欢呢？
John Ousterhout在《软件设计的哲学》那本书里讲过一个概念，叫“深模块”。
深模块的特点是：接口特别简单，但内部功能特别强大。就像一个黑盒子，外面只露出几个按钮，里面是一套复杂精密的机器。
浅模块的特点正好相反：接口特别复杂，暴露一大堆函数，但每个函数干的事儿都特别小。这种代码库全是碎片，东一块西一块。
AI喜欢深模块，因为调用关系简单。不需要翻好几个文件才能搞明白一个功能到底在哪儿。测试也好写，直接对着这个大模块写测试就行，不需要mock一堆乱七八糟的依赖。
浅模块就惨了。AI要搞清楚A文件调用了B文件的函数，B文件又调用了C文件，C文件又引用了D文件的类型。这种依赖网能把AI脑子烧了。
所以我写了一个“改善代码架构”的技能。它会扫描你的代码库，找出那些耦合特别紧的浅模块，建议你把它们合并成深模块。
你可能会担心：把模块做大，我自己理解起来不也费劲吗？
其实不是。你只需要知道这个模块的接口是啥，它干啥用的，你不需要知道它内部是怎么实现的。你可以把实现细节完全委托给AI去写。你只管高层的设计，AI管底层的代码。
这样你既保持了全局视野，又不被细节淹没。你依然是代码库的主人，而不是被AI牵着鼻子走。
日常干活的一套完整流程
咱们把今天讲的东西串起来，看看一天的工作长啥样。
早上你来上班。看一眼看板，还有没做完的任务。你先别急着写代码，先跑一遍“拷问我”。花一小时跟AI对齐需求。这一小时里，你喝茶，AI问你问题，你就答。答完，你俩的脑子就同频了。
然后你用“写PRD”把刚才的对齐结果存档。生成一份产品需求文档。你不用细看，信AI的总结就行。
接着用“拆PRD为任务”把PRD切成垂直切片。这一步可能要花点功夫。你得确保每个切片都是一个完整的小功能，从数据库到前端都能跑通。你要告诉AI哪些切片先做，哪些可以同时做。
好，规划做完了。现在是下午了。你可以把看板扔给循环脚本，让它自己去跑。你去开个会、写个周报、或者干脆早点回家。
第二天早上你回来。脚本已经跑了一整夜。可能完成了四五个任务。你现在要做的就是两件事：测试加审查。
测试是看功能对不对。直接打开页面，点一点，看看积分有没有加上去，等级有没有变化。不对的地方记下来，当作新任务加回看板。
审查是看代码写得好不好。但你不是一行一行看。你主要看模块边界、接口设计、有没有遵循你们团队的约定。具体的实现细节，信AI的就行，因为你写的测试已经证明了逻辑是对的。
测试没过或者审查没过，就开新任务，让AI去改。
测试和审查都过了，就把代码合并进主分支。然后继续让AI跑下一批任务。
你看，这个流程里，你真正动手的时间只有两段：规划阶段和验收阶段。中间的所有实现工作，都是AI在干。
你不是在写代码，你是在管理一个AI工程师团队。你负责想清楚要什么，负责任务拆分，负责验收。具体怎么实现，AI自己搞定。
这就是我说的从“码农”变“包工头”。你不再是一行行敲代码的，而是指挥AI干活的。
几个实战小技巧
最后给你几个马上能用的招。
第一个，在系统指令里加上“跟我说话的时候别管语法，尽量简短”。这个指令能让你读AI的计划时不那么累。因为AI写东西特别啰嗦，你让它简洁点，它会照做。我以前用这个，现在不怎么用了，因为我现在根本不读计划。但你要是还得读，这个很有用。
第二个，AI问问题的时候，直接用语音回答。打字太慢了。我一般对着AI说话，它识别成文字，然后继续问。就像跟人在聊天一样，效率高多了。
第三个，随时看token用量。我每个人工智能对话界面里都开着token计数器。你得知根知底，知道你的对话还有多少额度。一旦发现要接近100K了，立马清空，只保留最核心的系统指令，重新开始。
第四个，用子代理。子代理就是AI派出去干活的“小弟”。主AI分配任务，小弟去执行，然后把结果汇报回来。小弟有自己的token额度，不占用主AI的。这就等于把任务外包了，主AI可以保持轻盈，始终在聪明区里思考。
第五个，别迷信大上下文窗口。现在有人工智能吹自己能记一百万词儿。那玩意儿是用来做检索的，不是用来写代码的。你让它在一百万词里找一段话，它行。你让它记住一百万个词还写代码，它就傻了。所以你的实际工作区还是100K左右。
第六个，把老书的智慧用上。《程序员修炼之道》《重构》《软件设计的哲学》，这些都是十几二十年前的书。但你翻翻，里面全是金子。什么曳光弹、深模块、测试驱动开发，这些概念放到AI时代，恰恰是最有用的。你把它们的核心观点写进提示词里，AI就能用上。
第七个，架构改进这件事，可以单独拿出来让AI干。每周跑一次“改善代码架构”的技能，让它自动扫描代码库，给出合并建议。你不用全盘接受，但它是很好的提示。你看了就知道哪些地方需要整理了。
总结一下你到底学到了什么
咱们从头捋一遍今天的核心打法。
AI有两个毛病。一个是只能在100K的聪明区里好好干活，过了就变弱智。另一个是记性差，清空就全忘光。你得利用这两个毛病，而不是跟它们较劲。
所以你的正确姿势是：每次只给AI一个在小任务，让它在这个任务范围内保持聪明。不要堆太多东西进去。
做任务之前，先花一小时让AI拷问你。把需求彻底对齐。这一步你不能偷懒。你必须在场，因为只有你才知道业务细节。但是就一小时，熬过去就解放了。
对齐之后，让AI帮你写一份PRD。这是一份目的地地图。你不用细看，存档就行。
然后把PRD拆成垂直切片。每个切片都是一个能从数据库跑到前端的小功能。千万别横着切，要竖着切。每个任务做完你都能立刻看到成果，立刻跑测试。
接着把任务看板扔给循环脚本。让AI自己通宵干活。你可以潇洒下班。
回来之后，做两件事：测试加审查。测试不通过或者代码不符合标准，就开新任务让AI去改。改到满意为止。
在这个过程里，你要保持代码库是AI友好的。多搞深模块，少搞浅模块。测试要写扎实。反馈循环要快。架构要定期优化。
做到这些，你就从对着AI骂娘的状态，变成了喝着茶看它干活的状态。你不是在跟AI猜谜语，你是在指挥它干你不想干的活儿。