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

两段视频，同一个判断。一段讲软件基础功在 AI 时代为什么更值钱，另一段用一个多小时现场演示从需求到交付的完整工作流。作者是 Matt Pocock——Total TypeScript 的创始人、前 Vercel 开发者布道师，现在经营 AI Hero，专门教开发者用 AI 写代码。过去 18 个月他一直在教开发者用 AI 代理编程，这两段视频就是那批经验的浓缩。

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

目录

• 两个极端都有问题：vibe coding 与 specs-to-code
• 为什么上下文越长，AI 越蠢（含对比示例）
• 基础功决定你向 AI 提什么要求（含审查必要性）
• 从模糊需求到生产代码：四阶段工作流（含流程示例）
• 团队落地的几条原则（含边界表格）
• 适用边界、常见误操作与排查、读完自测
• 进阶方向与参考

先说结论：AI 编程工具出现后，软件基础功的价值被放大了，而不是被稀释。 这不是保守派对工具的抗拒，而是大量实践里反复出现的规律。

两个极端都有问题

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

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

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

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

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

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

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

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

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

缺少基础功的开发者的做法是：“帮我写个用户模块。“AI 返回一套看起来能用的混乱 CRUD（增删改查），可扩展性、安全性、错误处理全都欠考虑。有基础功的开发者会这样描述：“实现一个用户注册流程，包含邮箱验证、密码强度校验（8 位以上，大小写加数字），用 Strategy 模式（策略模式）支持多种验证方式，用 Repository 模式（即仓库（存储库）模式）隔离数据访问。“AI 生成的代码层次清晰、职责分明，可以直接进 review。两种提法的对比示例：

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

差异来自人的概念能力和抽象思维，AI 只负责执行。

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

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

更根本的问题在于，当你让 AI 生成了一段自己完全看不懂的代码，你既无法判断它是否正确，无法调试它的行为，也无法重构它的结构。你无法维护你无法理解的代码——这条约束在 AI 时代只会更明显。

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

第二段视频是一场 96 分钟的实战工作坊，从一句模糊的需求开始，一路跑到自动提交的生产功能。Pocock 给的不是玩具演示，是能落地的工程实践。拆开看有四个阶段。

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

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

他开源了一套叫 Grill Me 的 Skill，逻辑很简单——动手写代码之前，让 AI 沿着你设计决策树的每个分支往下追问：依赖关系、边界条件、数据模型、异常路径，一条一条把你的模糊想法逼成清晰方案。你答不上来的地方，恰好就是设计方案里还没想清楚的地方。AI 不会替你决策，它只会加速你已经做出的决策；如果自己都没想清楚，加速的只是混乱。

对齐的产物是一份 PRD（产品需求文档），记录的是设计概念：用户故事、实现决策、模块划分。这份文档不是用来读的，是用来在后续所有开发回合里当"共同词典"的。

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

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

为什么非要垂直？因为只有尽早跑通一条端到端的路径，才能尽早暴露问题。如果让 AI 先把所有模型层写完、再写所有接口、最后写所有页面，等于把最大量的验证压力堆到最后一步，一旦出错返工成本极高。

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

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

落地时几个关键点：

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

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

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

第四阶段：审查与 QA 闭环

Agent 跑完不是终点。还要做代码审查、人工 QA，把发现的问题反哺回看板，进入下一轮。这里有个容易遗漏的点：文档会腐烂。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 写得越快，文档腐烂越快；发现新人被文档误导，说明第四阶段的文档回写环节被跳过了。

谁该看原视频

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

第一类是正在搭建团队 AI 工作流的技术负责人。第一段演讲（18 分钟）把"为什么基础功更重要"讲得完整，第二段工作坊（96 分钟）的实操细节——Grill Me 怎么用、PRD 怎么落、Ralph 自动执行循环长什么样——是文字很难完整还原的。

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

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

进阶方向：想动手练习的读者，从配套开源仓库里的 Grill Me skill 入手，拿自己手上的真实需求跑一遍对齐阶段；熟悉 TypeScript 的读者可以直接复用演示里的 Vercel AI SDK（软件开发包）栈。

读完自测：三个问题检验你是否接住了核心判断。

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

参考资料与视频来源

• Software Fundamentals Matter More Than Ever（AI Engineer 大会演讲，约 18 分钟）
• Full Walkthrough: Workflow for AI Coding（实战工作坊，约 96 分钟）
• 频道：AI Engineer
• 配套开源仓库：mattpocock/skills