敏捷二十年，AI 一年：那些历经考验的核心原则
我的开发者生涯，是伴随着阅读Martin Fowler和Kent Beck的著作度过的。《敏捷宣言》、重构模式、测试驱动开发 —— 这些对我而言，从来都不是被强行灌输的方法论，而是我理解软件质量、团队协作与可持续交付的思维视角。
如今，我将大量时间投入到 AI 编码工具的实践中 —— 从 Vibe Coding、Claude Code 到基于需求规格(SDD)的工作流，一个问题始终萦绕在心头：这些经典的敏捷原则，在当下还适用吗？
在完成一个五万行代码的实战项目后，我得到了答案：适用。不仅如此，其中多项原则更是成为了 AI 增强型开发工作流中不可或缺的核心支柱。
AI 编码的全新设计原则
一个朋友曾对 AI 编码工具和框架展开过系统且深入的研究，最终提炼出七条他称之为 “原生 AI 开发” 的核心原则 —— 这一模式也被视作软件 3.0 的核心，是探讨敏捷原则前必须理解的内容，因为它构建了我们当下的开发新语境：
- 文件即真相：将 AI 的记忆、配置和状态存储在人类可阅读的本地文件中，文件系统是人类与 AI 之间通用的交互接口。
- 状态显式化：AI 必须持续记录自身的操作、所处阶段以及遇到的问题，核心采用 “三文件模式”：
plan.md（计划文件）、status.md（状态文件）、log.md（日志文件）。 - 先规划后执行：将设计决策权与执行权分离，由 AI 生成开发计划，经人类审核通过后，再由 AI 开展开发工作。
- 闭环验证：不盲目信任 AI 的自我评估，搭建基于测试的确定性自动修正循环，红 / 绿测试驱动开发是实现这一原则的核心机制。
- 分层记忆：将 AI 的记忆按易失性上下文（内存）、会话日志和持久化磁盘文件进行分层管理，主动把控需要压缩或舍弃的记忆内容。
- 技能资产化：将 AI 的能力封装为模块化、可复用的技能组件，让 AI 自主完成技能库的扩充。
- 上下文预算化：令牌资源昂贵且稀缺，需按需加载工具、删减冗余输出、缓存提示词，实现资源高效利用。
这些原则的设计十分严谨，但通读之后我发现了一个关键点：其中大部分并非披着 AI 外衣的新想法，而是在 AI 开发的规模化场景下，重新变得至关重要的经典理念。
我对 “文件即真相” 的思考
让我思考最深入的，是 “文件即真相” 这一原则。在传统的敏捷开发中，我们一直秉持代码即真相—— 代码是系统实际功能最清晰、最权威的体现。文档可能存在偏差，需求会随时间推移发生变化，但代码始终能稳定运行。
而原生 AI 开发的思维则做出了反转：将真相留存于文件（需求规格、架构文档、结构化状态）中，由 AI 负责生成具体的代码实现。
我理解这一理念的吸引力：如果不将 AI 锚定在结构化的上下文中，它很容易出现幻觉、偏离需求甚至凭空捏造内容。拥有一份能跨会话留存的标准文档，让 AI 在执行操作前先读取文档，显然比单纯依赖提示词记忆要可靠得多。
但我并不完全认同这种彻底的反转，实现偏差是真实存在的。自然语言文档本身具有固有的模糊性，同一个需求规格，因 AI 的解读角度不同，可能生成差异极大的代码。给予 AI 的实现自由度越高，就越需要验证最终结果是否符合我们的初衷。
我认为，答案并非在 “代码即真相” 和 “文件即真相” 之间二选一，而是要认识到二者可以共存，且必须保持同步。文件定义开发意图，代码是可执行的产物，测试则验证二者是否匹配。但问题在于，AI 生成文档和生成代码一样轻松，若缺乏规范的开发纪律，最终会陷入维护两个快速脱节的 “真相来源” 的困境，且二者之间没有可靠的衔接方式。
而这，正是敏捷原则重新发挥强大作用的场景。
适配 AI 编码的敏捷原则
《敏捷宣言》包含四大核心价值和十二条原则，在此我不逐一列举，仅重点分析与 AI 增强型开发最契合的几条原则，以及我在实践中观察到的具体应用方式。
测试驱动开发：打造闭环验证的核心
测试驱动开发（TDD）一直是我最推崇的开发实践：先编写失败的测试用例，再编写代码让测试用例通过。这一模式要求我们在开始开发前就定义好成功的标准，同时构建一套自动化的验证机制，让我们无需刻意记住 “完成状态” 的具体要求。
在 AI 编码中，TDD 的价值被进一步放大：它是实现闭环验证的核心方式。
AI 富有创造力，但输出结果具有非确定性。若让其自主判断，它可能会实现一个表面上看似正确的功能。而有了明确的失败测试用例，AI 就有了清晰无歧义的目标。更重要的是，AI 可以自行运行测试、观察失败原因，并在无需人工干预的情况下完成自我修正 —— 这正是 “闭环验证” 原则的实际落地，原则本身简洁精妙，而 TDD 是实现它的关键机制。
如果没有测试用例，我们只能通过逐行阅读来审核 AI 生成的代码，这一过程速度慢、易出错，且无法规模化。而有了测试用例，我们的审核问题就从 “这段代码写得对吗？” 转变为 “这段代码能通过测试吗？”，问题的解决难度大幅降低，也更具可操作性。
小迭代、高频交付：迭代单位的重构
这一原则在 AI 时代的重要性进一步提升，唯一的变化是迭代的单位发生了改变。
在传统敏捷开发中，一个迭代周期通常为两周。而在 AI 增强型开发中，有价值的反馈循环可以精细到分钟级别。我在实践中总结出一个实用的经验法则：如果一个任务的完成时间超过五分钟，就应该将其拆分为更小的任务。
背后的原因在于，AI 的上下文窗口存在上限。过长的开发会话会不断累积偏差 ——AI 会逐渐遗忘前期的约束条件、架构决策和开发者明确的偏好。而完成并收尾更短的任务，能让开发过程保持更高的连贯性，同时也能实现更快的人工审核循环，这才是质量控制的核心环节。
这一模式的难点在于把控任务的粒度：任务拆分过细，会产生大量的管理成本，比如频繁的上下文加载和工作交接；任务粒度太粗，则容易出现需求偏离。找到合适的工作单元，是一件极具挑战性的事，而我认为，这将成为资深 AI 开发者的核心技能之一。
结对编程与个体互动：人机协作的尺度平衡
这是我个人认为最贴合实际的敏捷原则，也是让我感受最强烈的矛盾点。
理想状态下的结对编程，是一场持续的思维对话 —— 两个大脑围绕同一个问题碰撞交流，互相发现错误、共享知识，最终打造出比单人开发更优质的成果。它的价值不仅在于产出的代码，更在于整个思考的过程。
在 AI 开发中，也存在一种极具真实感的结对编程形式：我提出粗略的需求，AI 设计解决方案、拆分子任务、搭建原型，我实际使用后给出反馈，随后双方持续迭代。这种模式在 UI 优化、性能调优，以及那些 “我需要看到实际成果，才能明确自己的真实需求” 的场景中，表现得非常出色。
但我也发现了一种失效的场景：过于结构化的开发框架，比如 SpecKit 或高度强调 “先计划后开发” 的工作流，会让人机交互变得过于形式化。开发者最终会把更多精力放在管理文档和审批流程上，而非真正的协作，结对编程本应有的默契和互动感会彻底消失。
我目前的观点是：让人机对话的时长，超出框架的既定要求，抵制过早交接工作的冲动。与 AI 进行结对编程的价值，不仅在于提升开发速度，更在于这种反复的双向沟通，能让我们逐渐明确自己真正想要开发的产品。
重构：更需勇气，而非退缩
重构的核心，始终是管理软件复杂度的不断累积。通过持续做出微小的设计优化，防止架构僵化，最终变成难以维护的状态。
AI 与重构结合的有趣之处在于，AI 让我们更有勇气进行重构，而非变得畏手畏脚。
在传统开发中，重构需要开发者小心翼翼，避免破坏现有功能。集成开发环境（IDE）的工具能提供一定帮助，但也仅限于重命名、代码提取等机械性的改造，任何结构性的重构，都需要开发者对整个代码库有深入的理解。
而借助 AI，我们可以在更高的抽象层级描述结构性的修改，让 AI 在整个代码库中执行修改，大幅降低人为错误的风险。AI 对上下文的理解能力，是单纯的文本替换工具无法比拟的。重构的成本被降低，意味着我们可以更频繁地进行重构，代码库也能始终保持良好的可维护状态。
但与此同时，也出现了相反的风险：放弃重构。如果一味依靠 AI 快速实现一个又一个功能，软件的复杂度会以前所未有的速度累积。如果在十个开发会话中连续实现十个功能，且中间不进行任何重构，最终可能会得到一份人类无法审核的代码 —— 甚至到最后，连 AI 都无法连贯地理清其中的逻辑。
可运行的软件：衡量进度的核心标准
敏捷开发明确指出：可运行的软件，而非文档，是衡量开发进度的首要标准。这一点，与原生 AI 开发中 “以文件和文档为真相” 的核心理念，形成了直接的冲突。
我认为，这种冲突并非无法调和，但需要开发者进行主动的管理。AI 开发中的一大隐患，是文档的过度膨胀。AI 能轻松且高效地生成各类文档，若不加节制，最终会堆积出大量无人维护的需求规格文件、计划文件和状态文件 —— 就连生成这些文档的 AI，也早已进入了其他的开发会话，不再关注这些内容。
我在实践中总结出的规范是：文档应做到极简、结构化，且尽可能通过自动化手段保持同步。比如用一份 CLAUDE.md 文件记录架构决策和开发规范，用测试用例来文档化软件的实际行为，除此之外，尽量减少其他文档的数量。文档越多，出现不一致问题的可能性就越大。
可运行的软件，始终是开发的核心真相，其余的一切，都只是辅助的脚手架。
回顾总结与拥抱变化：让经验持续沉淀
最后这两条原则，存在着紧密的内在联系。敏捷回顾会的核心，是系统性地总结开发中的经验教训，让后续的迭代得以优化；而拥抱变化，则意味着将新的需求视为开发过程的自然组成部分，而非对原有流程的干扰。
在 AI 开发工具中，对应的实践方式也正在逐步形成。SpecKit、OpenSpec 这类工具都有 “成果沉淀” 的概念 —— 将已完成工作中的经验教训，整合到项目的指导原则文件（如 CLAUDE.md）中，这正是形式化的回顾总结。
而 Ralphloop 这类能让 AI 自主迭代解决方案的机制，则是拥抱变化的一种体现，当然，这需要开发者进行严格的监督，避免出现需求范围的失控偏离。
这些实践背后的核心思想始终未变：经验教训应在迭代中持续积累。无论这些经验是记录在回顾文档、更新后的 CLAUDE.md，还是优化后的测试套件中，原则都是相通的：不再重复犯同样的错误。
核心启示
纵观所有适配 AI 编码的敏捷原则，能发现一个共性：敏捷原则的设计初衷，是管理人类规模软件开发中的复杂度和不确定性。而 AI 的出现，并没有消除这些问题 —— 在某些方面，甚至还放大了它们。AI 让代码的生成速度大幅提升，与此同时，对架构的连贯性和结果的验证正确性，要求也同样水涨船高。
一位研究 AI 编码的友人，曾将理想的 AI 开发模式总结为： “文件提供记忆，开发者赋予纪律。” 我深以为然。文件无法实现自我管理，测试用例不会自动生成，重构也不会凭空发生。
AI 真正带来的改变，是将执行环节的成本大幅降低，从而让开发的瓶颈发生了转移。过去，开发的瓶颈是编写代码本身；而现在，瓶颈变成了明确开发目标，并验证开发成果是否符合目标。这些都是需要判断力的问题，而这正是敏捷原则致力于培养工程师所具备的核心能力。
我花了二十年的时间，从书籍和实践中学习这些敏捷原则，如今倍感庆幸。它们不仅在 AI 时代得以留存，更是变得愈发重要。
在 AI 编码的时代，能够脱颖而出的工程师，并非是那些能生成最多代码的人，而是懂得如何打造闭环验证、把控迭代粒度、保持高效人机对话、在合适的时机进行重构，且始终将可运行的软件置于开发核心的人。
而这，正是敏捷开发的核心精髓。
