CHAPTER 01这场活动是什么

   2026年4月24日，AI 开发工具厂商 Cladwell 在其伦敦总部举办了一场面向开发者的线下 workshop，主题为 “AI Coding Workshop”。活动邀请了 Matt Pocock——一位从 Web 开发教育者转型为 AI 编程布道者的资深工程师，现场做了一场约 1.5 小时的完整演示。 

   Matt Pocock 同时也是这场活动的联合主办方之一。他此前因在 YouTube 和 Twitter 上分享大量 AI 编程实操经验而闻名，尤其擅长把传统的软件工程原则（模块化、TDD、代码审查）和 AI 工具结合在一起。 

   活动的形式是：Matt 现场从零开始，用一个课程管理平台的项目，完整演示他日常使用 AI 编程的真实工作流。观众可以跟着一起动手，也可以纯看。现场座无虚席，活动同步直播到了另一个房间。 

CHAPTER 02Matt Pocock 说了什么：AI 编程的核心工作流

整场演讲的核心论点非常清晰——AI 并不改变软件工程的基础知识，真正重要的是如何把你的工程经验适配到 AI 的工作方式上。

   Matt 提出了一个他认为是整场演讲最重要的概念：LLM 有一个 Smart Zone（聪明区）和一个 Dumb Zone（愚蠢区）。

   当你开始一个全新的对话，Context 为空时，LLM 的表现是最好的。随着你不断往 Context 里添加内容（每次添加 token），它就像往足球联赛增加球队一样——球队数量增加，比赛场次以平方级增长，注意力关系越来越复杂。 

   大约在 Context 达到 40% 左右（大约 100K tokens），无论你的模型是 200K 还是 100 万 Context Window，LLM 就会开始变蠢，开始做出愚蠢的决定。 

   Matt 提到了一个很多人都在用的操作：Compacting（压缩）——把对话历史压缩成摘要，以便继续对话。但他明确表示他讨厌这个做法。 

   他更喜欢的方式是：Clear（清除）。直接清空 Context，从头开始。 

   为什么？因为 Compact 之后的状态是不确定的——压缩会丢失信息，你永远不知道 AI 基于这个摘要的理解是否准确。而 Clear 之后的状态是始终一致的——回到系统提示符，从零开始。 

   他把这个比喻成电影 《记忆碎片》（Memento）：主角每次都从基础状态重新开始。这才是正确的方式。 

   Matt 在演讲中演示了如何用一个叫做 “Grill Me” 的 Skill，对一个产品需求进行”拷问”。 

   过程是这样的：你把一个粗略的产品想法（甚至只是一条 Slack 消息）发给 AI，让 AI 不断追问、挑战你的模糊之处，直到把所有不确定性都敲定清楚。这个过程结束之后，你会得到一份详细的 PRD。 

   但关键在下一句——“我想扔掉这份 PRD。”

   Matt 提到了一个软件实践叫 Ralph Wiggum（以《辛普森一家》里的角色命名）。 

   这个模式的做法是：写一个 PRD，然后反复告诉 AI “做一个小改动，让我们离目标更近一点”，不断循环直到完成。 

   他承认这个方式”能用”，但他更喜欢更多的结构感——把大任务分解成多个有依赖关系的 Issues，用 Kanban 管理，AI 逐个完成。 

   Matt 被问到”如何用 AI 做前端”时，给出了一个很诚实的回答： 

AI 目前做不了成熟代码库中的精细前端工作。 它可以生成粗糙的原型，但无法保证像素级还原设计。 

   他的解决方案是：用 AI 生成多个原型选项，放到一个可交互的路由里让人选择，把选中的设计反馈回 Grill Session，再推进开发。原型不是终点，而是获取人类反馈的工具。 

   这是一个反直觉但非常重要的洞见： 

   当你让 AI 写代码，然后在同一个 Context 里让 AI 审查自己的代码——审查者是在 Dumb Zone 里运作的，比编写者更笨。 效果会很差。 

   Matt 在演讲中强烈推荐 TDD（测试驱动开发）。 

   核心做法：先写一个失败的测试（Red），然后让 AI 去让测试通过（Green），最后重构（Refactor）。

   为什么对 AI 特别有效？ 

• AI 写完代码就写测试，而不是事后补测试，测试质量更高
• 测试在代码之前建立反馈循环，没有测试 = AI 完全在盲目编码
• 有了测试，AI 作弊（写虚假测试通过）的难度更高

   Matt 引用了 John Ousterhout 的《软件设计哲学》中的概念： 

• Shallow Modules（浅层模块）
  
  ：大量小文件，每个文件暴露很多接口，依赖关系复杂。AI 很难理解，人类也很难测试。
• Deep Modules（深层模块）
  
  ：每个模块有小接口 + 大功能。依赖关系简单，容易写测试，容易让 AI 理解。

   Matt 发现 AI 默认会生成浅层模块，如果你不控制它，最终代码库会变成一团乱麻。他的做法是在 PRD 阶段就明确指定要修改哪些模块，保持对代码库结构的控制。 

   Matt 最后展示了他自己开发的一个工具 Sandcastle，用于在 Docker 容器中并行运行多个 AI 编程循环。 

工作流是：

• Planner
  
  ：扫描 Kanban 面板，选择一批可并行处理的 Issues
• Implementer
  
  ：为每个 Issue 在独立沙盒中运行 AI 实现
• Reviewer
  
  ：在新 Context 中审查实现结果（确保 Smart Zone 审查）
• Merger
  
  ：合并所有分支

   他用的模型组合：Sonnet 用于实现，Opus 用于审查（因为审查需要更多智能）。 

SUMMARY总结：Matt Pocock 的 AI 编程原则