夜雨聆风
万物皆可 AI 后，回报率最高的工作是“重构”。
在AI编程时代，最稀缺、最有价值的能力，不是你掌握了多少新潮的 AI 工具或提示词技巧，而是那些被我们快要遗忘的、老掉牙的传统软件工程学。
这个观点，来自于 Matt Pocock（TypeScript 开发者）。在一场长达两小时的 Workshop 里，他几乎没怎么谈具体的 AI 技术细节，而是用一个完整的项目开发流程，反复论证：顶级的软件工程实践，就是顶级的 AI 协同实践。
很多人觉得，AI 来了，我们这些写代码的要被“优化”了。于是乎，大家疯狂追逐最新的模型，研究提示词，仿佛掌握了某种咒语，就能让 AI 吐出完美的代码。
但 Matt 告诉我们，别做梦了。AI是一个极其强大，但又极其“愚蠢”和“健忘”的工具。你不能指望它像一个资深架构师那样深思熟虑，你必须为它创造一个“傻瓜式”的工作环境，让它想犯错都难。而打造这个环境所需要的一切，都写在《程序员修炼之道》、《重构》、《设计模式》这些经典著作里。
要和 AI 高效合作，首先要深刻理解它的两个根本性缺陷，Matt 称之为“诡异的约束”。
第一个约束是“智能区”与“愚蠢区”。
Matt 引用了一个比喻：LLM 的表现能力和上下文长度有关，但不是线性关系。在一个全新的会话开始时，上下文最短，LLM 处于“智能区”，此时它的表现最好。随着你不断添加信息、代码、对话，上下文窗口被逐渐填满，LLM 内部的注意力关系呈二次方级别增长，计算负担越来越重，它就会开始“变笨”，进入“愚蠢区”。它会开始忘记之前的指令，犯一些低级错误。
这和你用的是 200K 还是 1M 的上下文窗口关系不大，这个衰减的临界点始终存在，Matt 认为目前大约在 100K token 左右。
我们以为更大的上下文窗口等于更强的能力，可以把整个代码库都扔进去。但现实是，你把整个代码库扔进去，大概率是直接把它推进了“愚蠢区”，然后为它生成的大量无用 token 付费。
第二个约束是“《记忆碎片》式遗忘”。
LLM 是没有状态的，它就像电影《记忆碎片》的主角，每隔几分钟记忆就清零，只能依赖身上写的字条（当前的上下文）来理解世界。为了解决这个问题，一些工具会“压缩”，就是把之前的长篇对话总结成一小段历史记录，再放回上下文中。很多开发者喜欢这样做，觉得保留了历史。
但 Matt 指出，他讨厌“压缩”。因为“压缩”本身会引入信息损失和偏差，而且每次压缩后的状态都是不确定的。他更喜欢让 AI 像《记忆碎片》主角那样彻底遗忘——每次都通过“清空上下文”（Clear Context）回到最初的、最干净的系统提示（System Prompt）状态。
因为这个初始状态是恒定且可预测的。一个永远可以回到确定起点的系统，远比一个拖着一长串模糊历史的系统更容易驾驭。
这两个约束，就是我们与 AI 协作的“物理定律”。所有工作流的设计，都必须围绕着这两个定律展开。我们的核心任务，就是把庞大、模糊、长周期的开发任务，切分成一个个独立的、能在“智能区”内完成、并且可以随时“从零开始”的小任务。
这不是什么新鲜理论。“保持任务小而美” ，这不就是Martin Fowler在《重构》里苦口婆心劝我们的话吗？这不就是敏捷开发的核心思想吗？只不过在 AI 时代，违反这个原则的惩罚变得前所未有的直接和昂贵。
理解了 AI 的“愚蠢”本质，我们再来看如何与它沟通。业界流行一种“规格到代码”（Specs-to-Code）的理念，就是写一个完美的 PRD（产品需求文档），扔给 AI，它就能生成代码；如果代码有问题，就回去改 PRD，如此循环。
Matt 不喜欢这种做法。因为这种方式忽略了代码本身，把代码当成了一个黑箱。而代码，才是我们战斗的阵地。
他提出的解决方案，不是一个更好的 PRD 模板，而是一个叫做“Grill Me”（拷问我）的技能（Skill）。
这是一个极简但极其强大的 Prompt，核心思想是：“在我给你一个模糊的需求后，请不要急着给我计划或代码，而是像一个最挑剔的领域专家一样，无情地、深入地、逐一地拷问我关于这个需求的每一个细节，直到我们达成共同的、深刻的理解。”
比如，在把“为平台增加游戏化功能以提高用户留存”这个模糊需求扔给 AI 后，AI 没有马上生成一堆任务列表，而是开始提问：
“我们应该奖励哪些用户行为？完成课程？观看视频？每次奖励多少积分？”
“积分系统是否需要回溯？我们是否要给老用户已经完成的课程补发积分？”
“等级系统应该如何设计？升级曲线是线性的还是指数的？”
“游戏化功能的 UI 应该放在哪里？是单独页面还是嵌入在仪表盘？”
这些问题，个个都切中要害，很多都是人类开发者在初期规划时容易忽略的魔鬼细节。Matt 把这个过程，称为与 AI 共同建立一个“共享的设计概念”，这个词来自 FrederickBrooks的《设计原本》。
这才是 AI 时代沟通的真正价值所在。我们需要的不是一个被动执行指令的码农，而是一个能帮助我们穷尽思考、发现盲点的“思维伙伴”。“Grill Me”的核心，是强迫人类把模糊的想法具体化、结构化。你不是在教 AI，而是 AI 在逼着你把事情想清楚。
这个过程的产物，远比一份冷冰冰的 PRD 文档更有价值。那份长长的问答记录，才是真正的、活的“需求文档”。
当这个“拷问”环节结束后，再让 AI 生成 PRD，就成了顺理成章的水到渠成之事。而且 Matt 提到，他从不仔细审查这份 AI 生成的 PRD。因为他知道自己和 AI 已经通过“拷问”环节达成了高度对齐。这份 PRD 只是一个总结性的产物，是那场深度对话的快照。
只要他相信 AI 的总结能力（这恰恰是 LLM 最擅长的），他就不需要在这个文档上浪费时间。他真正在乎的，是那个“对齐”的过程。
好了，现在我们有了一份（未经详细审查的）PRD，一个明确的“目的地”。接下来是怎么走过去？
传统的做法，是让 AI 生成一个多阶段的计划，比如：第一步，建数据库表；第二步，写后端 API；第三步，做前端页面。这是一个线性的、一步接一步的计划。
Matt 再次否定了这种做法。他认为，这种计划有两个致命弱点：
无法并行：只有一个 Agent 能在上面工作，因为第二步依赖第一步。
反馈周期太长：AI 喜欢水平分层编程，它会先把所有数据库的活干完，再干所有 API 的活。这意味着直到最后第三步集成时，你才能发现之前两步可能存在的集成问题。这在软件工程里是灾难性的。
他的解决方案，是借鉴《程序员修炼之道》中的“追踪弹”或称“垂直切片”思想。
所谓“垂直切片”，就是你的第一个任务，就应该贯穿从数据库到前端的完整流程。哪怕功能极简，比如只实现“用户完成一节课，数据库里积分加一，前端页面上能看到积分+1 的提示”。这个任务虽小，但它打通了所有技术栈，像一发曳光弹，在黑夜中划出一条清晰的弹道，让你能立即验证整个系统的连通性。
基于这个思想，Matt 让 AI 把 PRD 分解成一个“看板”，上面的任务都是独立、可抓取、并标注了依赖关系的。比如：
任务A：实现积分模型与服务（AFK，无依赖）
任务B：实现连胜追踪逻辑（AFK，依赖 A）
任务C：在课程完成时发放积分（AFK，依赖 A 和 B）
任务D：在仪表盘显示积分和连胜（AFK，依赖 C）
这个看板，本质上是一个有向无环图（DAG）。它清晰地展示了哪些任务可以并行处理。一旦任务 A 完成，B 和 C 就可以被两个不同的 Agent 同时领取并开发。
这又是一个软件工程思想在 AI 时代的复兴。我们不再把 AI 当成一个单独的开发者，而是把它看作一个可以无限扩充的“劳动力池”。人类工程师的角色，变成了架构师和项目经理，负责设计出能够最大化并行、最小化依赖的任务结构。你分解任务的能力，直接决定了你的项目能跑多快。
现在，我们把一个个设计精良的“垂直切片”任务交给了 AI Agent 去执行。这是不是就可以躺着等结果了？
还差最后，也是最关键的一环：你的代码库本身是否“AI 友好”？
Matt 强调，一个糟糕的代码库，会催生出糟糕的 Agent。如果你的代码库混乱不堪、测试缺失、模块耦合严重，那么无论你的提示词写得多好，AI 产出的代码也只会是垃圾。
那么，什么样的代码库是“AI 友好”的？Matt 提出了两个核心要素。
第一，无处不在的快速反馈闭环。
AI 编码时是“盲人”，它看不见运行结果。你必须给它一根“盲杖”，就是自动化测试和类型检查。Matt 极力推崇测试驱动开发（TDD）。他会让 AI 遵循“红-绿-重构”的循环：先写一个会失败的测试（红），然后写最简单的实现让测试通过（绿），最后再重构代码。
TDD 强迫 AI 在写实现之前，就必须思考代码的接口和行为，这极大地约束了它“随心所欲”的倾向，也让它很难在测试上“作弊”。一个拥有良好测试覆盖率的代码库，等于为 AI Agent 提供了一个高质量的“模拟器”，让它在提交代码前就能知道自己干得怎么样。你的反馈闭环的质量，就是 AI 产出代码质量的上限。
第二，清晰的“深模块”架构。
这个概念来自 John Ousterhout 的《软件设计的哲学》。他把模块分为“深模块”和“浅模块”。
浅模块：接口复杂，实现简单。比如一个工具函数文件，暴露了 50 个小函数。
深模块：接口简单，实现复杂。比如一个 VideoEncoder 类，只暴露 encode() 和decode() 两个方法，但内部封装了极其复杂的视频编解码逻辑。
Ousterhout 认为，好的系统应该由“深模块”构成。为什么？因为深模块隐藏了复杂性，提供了清晰的抽象。
Matt 发现，AI 极度偏爱在“深模块”的代码库中工作。因为一个深模块，职责单一，接口清晰，非常容易围绕它编写测试。AI 不需要理解模块内部纷繁复杂的实现细节，只需要通过它简单的接口进行交互和测试。相反，在一个由无数“浅模块”构成的“大泥球”项目中，文件之间依赖关系错综复杂，AI 根本无法理清头绪，很容易改一处而崩全局。
这引出了下一个观点：未来软件工程师的核心竞争力，是“架构品味”。
你的工作不再是逐行编写业务逻辑，而是设计和重构你的代码库，使其充满“深模块”。你要像一个城市规划师，把混乱的贫民窟改造成一个个功能分区明确、道路清晰的现代化社区。一旦这个“AI 友好”的架构搭建完成，具体的实现细节，完全可以委托给 AI 去填充。
Matt 甚至为此做了一个叫“Improve CodebaseArchitecture”的技能，让 AI 扫描整个代码库，找出那些耦合在一起的“浅模块”集群，并建议如何将它们重构为“深模块”。
这给了我们一个全新的视角来看待“技术债”。在过去，技术债只是拖慢了人类开发者的速度；在未来，一个糟糕的架构所欠下的技术债，可能会让 AI 根本无法在你的项目上工作，相当于让你的团队无法利用这个时代最强大的生产力工具。偿还技术债，进行架构重构，从未像现在这样具有如此高的回报率。
通过 Matt Pocock 的整个工作流，我们看到了一位新型软件工程师的画像：
他不再是一个单纯的“码农”，而是一个“系统设计师”。这个“系统”包含了三个层面：
沟通系统：通过“Grill Me”这样的模式，设计与 AI 的交互方式，确保思想的高度对齐，而不是低效的指令传递。
工作流系统：通过“垂直切片”和“看板”，设计出可并行、可度量、反馈快速的任务分解与执行流程。
代码架构系统：通过“深模块”和“TDD”，设计出易于测试、易于理解、AI 乐于工作的代码库结构。
在这三个系统中，人类工程师的核心价值，体现在“对齐”、“分解”和“品味”上。我们把最需要创造力、大局观和审美判断的工作留给自己，而把那些重复性的、细节性的实现工作，放心地交给 AI 这个虽然“愚蠢”但不知疲倦的伙伴。
这听起来是不是有点熟悉？这不就是几十年来，软件工程大师们一直在倡导的“关注点分离”、“高内聚低耦合”、“整洁架构”吗？
AI 的出现，并没有颠覆这些黄金法则。恰恰相反，它