AI Coding 实战指南：基础功比工具更重要

两段视频，同一个判断。一段 18 分钟的演讲讲软件基础功在 AI 时代为什么更值钱，另一段 96 分钟的实战工作坊现场演示从模糊需求到生产代码的完整工作流。作者是 Matt Pocock——Total TypeScript 的创始人、前 Vercel 开发者布道师，现在经营 AI Hero，专门教开发者用 AI 写代码。过去 18 个月他一直在教开发者用 AI 代理编程，这两段视频就是那批经验的浓缩。两段视频都出自 2026 年 4 月的 AI Engineer 大会，目前合计播放超过 280 万次。

阅读目标：读完后你能回答三个问题——为什么 AI 工具越强、软件基础功反而越值钱；从模糊需求到生产代码的四个阶段各自解决什么问题；哪些场景适合这套工作流、哪些不适合。

目录

• 两个极端都有问题
• 为什么上下文越长，AI 越蠢
• 基础功决定你向 AI 提什么要求（含统一语言与审查必要性）
• 从模糊需求到生产代码：完整工作流（含时间轴速查）
• 团队落地 AI Coding 的几条原则
• 什么时候该用，什么时候不该用
• 常见误操作与排查
• 谁该看原视频、读完自测、进阶方向
• 参考资料与视频来源

先说结论：AI 编程工具出现后，软件基础功的价值被放大了，而不是被稀释。 Pocock 在演讲开场的说法更冲：AI 编程工具既被高估，又确实强大——用得好，它强得惊人；用得差，它产出意大利面式代码的速度比任何人类团队都快。差别不在工具，在流程。

两个极端都有问题

Pocock 在演讲里先划掉两个流行的极端。

一个是 vibe coding（氛围编码），凭感觉把需求丢给 AI，然后祈祷它能跑。问题在于失控——你不知道 AI 写了什么，也不知道为什么这么写，改起来是一场灾难。

另一个是 specs-to-code（从规格直接生成代码），把一份详细的规格说明书扔给 AI，让它直接生成整个系统。这派的假设是"代码是廉价的，规格才是珍贵的"。Pocock 偏要唱反调：他在自己的课程里实测过这个模式，结论是每一次跑，代码只会越来越糟。AI 生成的代码和人类手写的代码一样会腐烂、会积累技术债、需要维护。代码从来不廉价，AI 只是让你更快地产出代码，并没有替你思考代码该怎么组织。

他反复强调一句话：代码没有变得更便宜，坏代码反而是有史以来最贵的。工具只放大你已有的流程——好流程放大出好结果，坏流程放大出更坏的结果。瓶颈不在工具，在流程。

为什么上下文越长，AI 越蠢

要理解这套工作流，先得明白大语言模型的一个已知短板。Pocock 把它叫"聪明区与蠢笨区"，工作坊第二章的标题就是 Smart Zone：对一个 Agent（智能体）塞进越多的上下文，它在每个点上的决策质量就越差。上下文短、任务单一的窗口里它表现不错；一旦膨胀到跨文件、跨模块，它的判断就开始漂。

这解释了为什么好的工作流刻意把任务切小。不是仪式感，是顺着模型的物理限制走。下文所有步骤，往回都能追溯到这一条。

基础功决定你向 AI 提什么要求

AI 生成的代码质量，取决于你描述需求的能力。同样一个需求交给不同水平的开发者，结果的差距远超工具本身的差距。

同一个需求，两种提法：

弱描述：帮我写个用户模块。
强描述：实现一个用户注册流程，包含邮箱验证、密码强度校验（8 位以上，大小写加数字），
        用策略模式支持多种验证方式，用仓储模式隔离数据访问。

弱描述换来一套看起来能用的混乱 CRUD（增删改查），可扩展性、安全性、错误处理全都欠考虑。强描述生成的代码层次清晰、职责分明，可以直接进 review。差距来自人的概念能力和抽象思维，AI 只负责执行。

统一语言：让 AI 说代码库的语言

演讲把四样"老东西"点名为 AI 时代更重要的基础功：统一语言、垂直切片、TDD、深模块。这些都是几十年前就成型的设计思想，Pocock 的说法是它们没有失效，只是变得更重要。

其中统一语言（ubiquitous language）出自领域驱动设计（DDD，Domain-Driven Design）：代码、文档和日常沟通共用同一套领域词汇。放到 AI 编程上，这条原则的含义很具体——需求描述、PRD 里的术语、代码里的命名如果是同一套词，AI 的产出就更稳定；同一个概念在三处有三个名字，AI 每次都要重新猜一遍。

AI 生成的代码为什么需要人审查

AI 生成的代码看起来正确，但可能藏着并发问题、不符合团队规范、存在安全漏洞、选错了架构。只有理解这些概念的人才能发现。

更根本的问题在于，当你让 AI 生成了一段自己完全看不懂的代码，你既无法判断它是否正确，无法调试它的行为，也无法重构它的结构。你无法维护你无法理解的代码——这条约束在 AI 时代只会更明显。演讲给出的分工原则是人类掌握接口设计，实现按任务选择性委托。

从模糊需求到生产代码：完整工作流

第二段视频是一场 96 分钟的实战工作坊，从一句模糊的需求开始，一路跑到自动提交的生产功能。Pocock 给的不是玩具演示，是能落地的工程实践。官方时间轴把工作坊切成十个章节，按动作归组是四个阶段。

第一阶段：对齐，而不是直接开写

工作坊的前两章是铺垫：开场之后先讲"聪明区"，再安排一段研究与原型（4:20 起）。真正定义这个阶段的，是 12:16 开始的 Grill Session。

很多人的第一反应是让 AI 直接进"计划模式"，把需求翻译成实施步骤。Pocock 的建议恰恰相反：先让 AI 反过来拷问你。

他开源了一套叫 Grill Me 的 Skill，仓库里的描述很直白：就一份计划或设计接受无休止的访谈，直到设计树的每个分支都有了着落。按官方讲义页的说法，一轮拷问通常在 40 到 100 个问题之间——依赖关系、边界条件、数据模型、异常路径，一条一条把你的模糊想法逼成清晰方案。你答不上来的地方，恰好就是设计方案里还没想清楚的地方。AI 不会替你决策，它只会加速你已经做出的决策；如果自己都没想清楚，加速的只是混乱。

对齐的产物是一份 PRD（产品需求文档），工作坊从 31:27 开始现场写这份文档：用户故事、实现决策、模块划分。这份文档不是用来读的，是用来在后续所有开发回合里当"共同词典"的——它就是统一语言的载体。

第二阶段：把功能切成垂直切片

拿到 PRD 之后，任务被拆成看板上的独立条目（39:37 起），用的是本地 Markdown 而不是某个 SaaS（软件即服务）。拆分的原则是垂直切片，也叫曳光弹（tracer bullet）——每一片都从界面一路打通到数据库，能独立运行、能立刻看到反馈，而不是把所有"水平层"先铺完再对接。

官方简介对切片还有一个量度要求：细到 agent 能独立认领。为什么非要垂直、非要细？因为只有尽早跑通一条端到端的路径，才能尽早暴露问题。如果让 AI 先把所有模型层写完、再写所有接口、最后写所有页面，等于把最大量的验证压力堆到最后一步，一旦出错返工成本极高。

第三阶段：Agent 执行，人盯质量门

进入实现阶段后，Pocock 的比喻是一个人站在战略层、AI 站在战术层。AI 像一名能力很强的基层士兵，负责在代码里具体改动；人负责判断往哪改、改到什么程度、边界在哪里。

落地时几个关键点：

• 单文件生成：一次只让 AI 关注一个文件，把上下文压进"聪明区"。每步生成后由人确认，不批量生成后统一审查。
• TDD（测试驱动开发）当刹车：先写测试再让 AI 实现。测试是给 AI 设质量边界，也是事后能自动验证的验收标准。Pocock 把它当成从 AI 身上榨取价值的关键杠杆，而不是仪式。
• 深层模块：接口设计得窄而清晰，内部实现交给 AI。这个概念出自 Ousterhout 的《A Philosophy of Software Design》，是演讲点名的参考书之一。面向 Agent 的代码库，浅显、直白、边界分明的模块，比层层抽象更好用。

人盯循环跑顺之后，工作坊后半段演示了怎么逐步放手：先是 AFK（away from keyboard，离席）运行——人不在场，agent 自己选任务、写测试、实现代码、提交（53:52 起）；再往后是多 agent 并行（1:29:55 起），把互相独立的切片分给多个 agent 同时开工。放手的顺序不能反：agent 的离席资格，是前一个阶段人盯循环的稳定性换来的。

Pocock 还提到一个细节：实现用一个模型，评审换另一个更强、且必须在新会话里进行的模型。让"代码作者"和"审查者"分开，能少受同一份上下文里的偏见影响。把第三阶段的执行循环写成示例：

人：定边界、定验收标准（测试先行）
  ↓
AI：单文件实现，上下文压在"聪明区"
  ↓
测试：自动验证是否达标
  ↓
人：确认后进入下一片，不通过则退回重改
  ↓
循环稳定后：AFK 离席运行 → 多 agent 并行

第四阶段：审查、QA 与部署闭环

Agent 跑完不是终点。还要做代码审查与人工 QA（1:09:04 起）、部署和监控，把发现的问题反哺回看板，进入下一轮。这里有个容易遗漏的点：文档会腐烂。AI 越能写，代码库变化越快，文档如果不能跟着更新，很快会变成误导人的历史产物。

工作坊时间轴速查

团队落地 AI Coding 的几条原则

Pocock 的视频没有专门讲团队管理，但工作流指向几条落地原则。

建立 AI 使用边界

每个团队应该明确哪些事情允许 AI 做，哪些不允许。

关注负向信号

团队引入 AI 后，自然会盯代码提交频率、Bug 率、审查周期这些正向指标。但几个负向信号同样值得跟踪：AI 生成代码的占比是否持续上升而不回落？返工率是不是上去了？技术债务的增速是不是变快了？这些指标比正向指标更能反映团队用 AI 是否健康。

基础功的投入不能停

AI 工具迭代很快，今天的做法可能半年后就过时。但 SOLID 原则、设计模式、架构风格、测试金字塔这些基础功，不会因为工具变化而失效。团队应该保持评估 AI 工具的节奏，同时继续投入基础功。

什么时候该用，什么时候不该用

这套工作流有清晰的适用边界。

适合的场景：功能模块开发、CRUD 接口实现、单元测试编写、代码重构、样板代码生成。这些任务输入输出清晰，AI 的出错空间可控。

不适合的场景：系统架构设计、安全敏感模块、涉及多团队协调的功能、遗留系统的深度改造。这些任务需要跨层判断和上下文理解，超出 AI 当前的能力边界。

团队选择建议：如果团队里 Senior 开发者比例较高，可以引入这套工作流，因为有人能兜底。如果团队以初级开发者为主，先建立 code review（代码审查）文化，再逐步引入 AI 辅助。

常见误操作与排查

这套工作流里最常见的四类错误，都能从视频里的明确主张反推出来：

1. 批量生成后统一审查。视频的做法是每步生成后由人确认；如果你发现审查时已经看不懂 AI 写了什么，问题出在批量太大，回到单文件生成。
2. 用同一个会话既实现又评审。作者与审查者要分开，评审必须在新会话里进行；评审总是走过场时，先排查这一条。
3. 文档不跟着代码更新。AI 写得越快，文档腐烂越快；发现新人被文档误导，说明第四阶段的文档回写环节被跳过了。
4. 第一天就让 agent 离席跑。工作坊的顺序是人盯循环稳定之后才过渡到 AFK；如果 agent 自主提交的代码没人能讲清思路，说明跳过了人盯阶段，退回去重建循环。

谁该看原视频

读到这里，多数人已经拿到核心判断。但两类人值得补看原片。

第一类是正在搭建团队 AI 工作流的技术负责人。第一段演讲（18 分钟）把"为什么基础功更重要"讲得完整，第二段工作坊（96 分钟）的实操细节——Grill Session 怎么拷、PRD 怎么落、AFK 离席运行怎么逐步放手——是文字很难完整还原的。

第二类是写 TypeScript 的工程师。Pocock 的演示全程用 TypeScript 和 Vercel AI SDK（软件开发包），代码贴近这类读者熟悉的场景，跟看一个陌生技术栈的演示体感完全不同。

其余只想确认"AI 会不会让我失业"的读者，读本文就够了。

读完自测

四个问题检验你是否接住了核心判断。

1. 你能说出上下文变长后 AI 决策质量下降的原因，以及工作流怎么顺应这个限制吗？
2. 你能区分垂直切片和水平分层的差别，并说出为什么前者返工成本更低吗？
3. 你能说出从人盯循环过渡到 AFK 离席运行的前提条件吗？
4. 你能判断手上这个任务该不该交给这套工作流吗？

进阶方向

想动手练习的读者，从配套开源仓库里的 Grill Me skill 入手，拿自己手上的真实需求跑一遍对齐阶段；熟悉 TypeScript 的读者可以直接复用演示里的 Vercel AI SDK（软件开发包）栈。想沿着演讲提到的设计思想往深里走，从 Ousterhout 的《A Philosophy of Software Design》读起最顺——深模块与浅模块的判定标准，书里讲得最系统。

参考资料与视频来源

• Software Fundamentals Matter More Than Ever（AI Engineer 大会演讲，18 分 26 秒，2026-04-23 首发，官方讲义页）
• Full Walkthrough: Workflow for AI Coding（实战工作坊，1 小时 36 分 30 秒，2026-04-24 首发，官方讲义页）
• 频道：AI Engineer（两段视频合计播放超 280 万次，截至 2026-09-19）
• 配套开源仓库：mattpocock/skills（含 grill-me 等技能，MIT 许可）
• 演讲点名参考书：John Ousterhout《A Philosophy of Software Design》、《The Pragmatic Programmer》、Brooks《The Design of Design》