从提示工程到循环工程：AI编程协同范式演进与实践指南

1. 从“提示”到“循环”：一次编程思维的范式转移

最近在开发者圈子里，一个观点被反复讨论：Claude Code 的创始人提出了“不再提示 AI 了”。这听起来有点反直觉，对吧？我们好不容易才习惯了用自然语言去“命令”大模型，怎么突然又说要“放弃”它了？但当我深入理解了他所倡导的“循环工程”后，我才意识到，这并非抛弃提示，而是一次编程范式的根本性升级。它意味着我们与AI协作的方式，正在从一次性的、静态的“指令-执行”模式，转向动态的、持续演进的“协同进化”模式。

简单来说，传统的“提示工程”就像是你给一位非常聪明但缺乏背景知识的实习生写一份极其详尽的需求文档。你需要预判所有可能，把边界条件、格式要求、甚至思维链都写进去，然后期待他一次就交给你完美的成品。而“循环工程”则更像是你和这位实习生坐在一起结对编程。你给出一个初步的想法，他快速给出一个草稿；你指出其中的问题，他立刻调整；你引入新的数据，他随之优化逻辑。整个过程是一个快速反馈、持续迭代的循环，最终产出的代码，是你们共同思考、多次碰撞的结果。

这种范式尤其适合两类人：一是追求开发效率和代码质量的资深工程师，他们可以用AI作为超级副驾，将繁琐的调试、重构、测试工作自动化；二是正在学习编程的新手，他们可以通过这种高互动性的方式，直观地理解编程逻辑的构建过程，而不仅仅是背诵语法。接下来，我将结合我近半年的深度实践，拆解Loop Engineering的核心、实操以及那些只有踩过坑才知道的细节。

2. 循环工程的核心：构建人机协同的增强回路

2.1 从线性提示到增强循环

传统的AI编程提示，其思维模型是线性的、开环的。我们输入Prompt A，期望得到输出Result A。如果结果不理想，我们可能会去修改Prompt A变成Prompt A‘，然后重新运行，这本质上还是另一个线性过程。问题在于，每一次尝试都是孤立的，AI并不“记得”上一次为什么失败，你也不得不花费大量精力去描述一个已经讨论过的上下文。

循环工程的核心，是构建一个“增强回路”。这个回路包含四个关键阶段，形成一个闭环：

1. 意图表达与种子生成：开发者用自然语言描述一个相对模糊的初始意图，比如“帮我写一个函数，它需要处理一些用户输入，并检查安全性”。AI基于此生成第一版“种子代码”。这个阶段的关键是“不求完美，但求快速启动”，目的是建立一个可供讨论的具体对象，而不是一份完美的规格书。

2. 协同分析与问题定位：开发者（或自动化工具）审查种子代码，不是简单地看它“对不对”，而是分析其“意图对齐度”、“逻辑完整性”和“潜在缺陷”。这里，开发者扮演的是架构师和代码评审者的角色，而AI可以辅助进行静态分析、复杂度评估。例如，AI生成了一段使用正则表达式过滤输入的代码，你立刻意识到这可能有ReDoS风险，这就是一个需要被定位的“问题节点”。

3. 定向反馈与上下文注入：这是与传统提示最大的区别。你不是回去重写整个需求，而是针对上一步定位的具体问题，给出极其精确的、上下文的反馈。同时，你可以将新的信息“注入”到对话上下文中。例如，你不是说“重写这个安全过滤函数”，而是说：“上一版代码中的正则表达式^[a-zA-Z0-9]+$在处理超长恶意输入时可能有性能问题。这里有一个我们项目的安全编码规范文档（附上链接或关键条目），请参考其中的‘输入验证’章节，使用安全的字符串匹配库xxx来重构这个函数，并添加长度限制。” 这样，反馈是具体的、可操作的，并且丰富了AI的决策上下文。

4. 迭代优化与模式沉淀：AI根据精准反馈和新增上下文，生成优化后的代码。经过几轮这样的循环，不仅单个代码片段被完善，整个对话历史本身形成了一个针对“如何在某项目中编写安全过滤函数”的、富含上下文的知识库。这个知识库（即这个“循环”的完整记录）可以被保存、复用，甚至抽象成一种“模式”，用于指导未来类似的任务。

这个循环的威力在于，它把人的高层设计、领域知识和批判性思维，与AI的快速生成、代码博览和不知疲倦的特性完美结合。最终产出的代码，其质量往往远超任何一方独立完成的结果。

2.2 关键心智模型：AI是“思考伙伴”，而非“代码猴子”

要实践好循环工程，首要的是转变我们对AI角色的认知。别再把它当成一个只会执行死命令的“代码猴子”。把它想象成一个知识渊博但经验尚浅的“思考伙伴”。你的任务不是“命令”它，而是“引导”和“激发”它。

这意味着你需要学会提出好的“半成品”问题，乐于接受一个不完美的初稿，并擅长进行外科手术式的精准反馈。例如，当你想要一个复杂的数据处理流水线时，更好的启动方式是：“我需要处理多种格式的日志文件，提取特定事件，并聚合统计。这是我目前手动的做法（附上一小段示例和痛点）。请先帮我设计一个模块化的架构草图，我们再来讨论每个模块的具体实现。” 这比“写一个日志分析工具”要有效得多，因为它为AI提供了思考的锚点和方向，开启了协同设计的可能性。

3. 循环工程的实战框架与工具流

3.1 构建你的本地循环工作台

依赖一个网页聊天窗口进行复杂的循环工程是低效的。你需要一个集成的本地环境。我的核心工具栈如下：

• 核心AI交互：Cursor IDE或Windsurf。它们将大模型深度集成到编辑器中，支持通过快捷键（如 Cmd/Ctrl+K）直接针对选中代码进行对话、编辑、解释，这是实现快速循环的物理基础。我个人更倾向于Cursor，因为其Agent模式能更好地维持长期对话上下文。
• 上下文管理：这是循环工程的命脉。你需要一个系统来管理“循环”中产生的大量上下文（代码片段、错误信息、文档、之前的讨论）。
  • 核心方法：在对话中，主动地、结构化地注入上下文。例如，当需要AI参考项目结构时，不要只说“看看其他文件”，而是用工具生成一个精简的目录树，并说明：“当前项目结构如下（见附件）。请特别注意/src/utils/下的validation.js，它的模式应该被沿用。”
  • 工具辅助：使用tree命令、rg(ripgrep) 搜索关键代码片段，然后粘贴到对话中。对于复杂项目，可以考虑用一个单独的Markdown文件来维护“项目上下文手册”，在需要时摘要粘贴。
• 验证与测试：循环不能空转，每次迭代都需要验证。
  • 即时验证：在IDE中直接运行生成的代码片段或单元测试。利用Cursor的“快速终端”功能。
  • 自动化测试集成：在循环中，明确要求AI“为这个函数编写对应的Jest/Mocha测试用例”。然后将运行测试作为循环的一个检查点。测试失败的错误信息，本身就是最好的、最具体的反馈。

一个典型的工作流是这样的：我在Cursor中写下一个函数签名和简单的注释（意图表达） -> 用Cmd+K让AI生成初步实现（种子生成） -> 我阅读代码，运行现有的单元测试，发现一个边界情况处理错误（问题定位） -> 我选中出错的代码块，再次Cmd+K：“这里的条件判断没有处理input为null的情况。请修正，并确保它符合我们项目中handleNullable的通用模式。”（定向反馈与上下文注入） -> AI生成修正版 -> 我运行测试通过，并可能要求AI：“很好。现在请为这个修正后的函数补充一个测试用例，专门测试null输入。”（迭代优化）。

3.2 循环的层次：从代码行到系统架构

循环工程可以应用在不同粒度上，形成“循环套循环”的复合结构。

1. 代码行/函数级循环：最常见。针对一个具体算法、一个工具函数进行快速迭代。重点在于逻辑正确性、性能边界和代码风格。
2. 模块/组件级循环：设计一个独立的模块，如一个React组件、一个API控制器。循环的重点是接口设计、状态管理、与外部系统的集成方式。你需要注入更多的设计文档和API契约作为上下文。
3. 架构/系统级循环：这是最高阶的应用。你可以用自然语言描述一个系统需求，让AI生成架构图（如Mermaid代码）、核心模块清单、数据流描述。然后你们可以就“是否应该引入消息队列”、“数据库选型是否合适”等问题进行多轮讨论。每一轮，你都可能要求AI根据讨论结果，重绘架构图或修改模块说明。

注意：越高级别的循环，对开发者自身架构能力的要求越高。AI是一个强大的“想法生成器”和“方案模拟器”，但最终的技术决策和权衡判断必须由你——掌握全局信息和承担责任的工程师——来做出。切勿陷入与AI进行无休止的、空泛的设计辩论，要时刻用具体的约束条件（如“我们的云预算只有每月$500”）来锚定讨论。

4. 高级技巧：让循环变得“聪明”起来

4.1 设计自指提示与元提示

为了让循环更高效，你可以设计一些“关于如何循环”的提示，即元提示。在开启一个长期任务（如“开发一个简易的待办事项后端”）前，我会先给AI设定协作规则：

“我们将以循环工程的方式协作。我提出需求或问题，你给出方案或代码。我可能会指出问题、要求修改或提供新信息。请你始终：1. 在每次回复开头，用一句话总结你理解的我当前的核心指令或问题。2. 如果我的反馈模糊，主动提问澄清。3. 在提供代码后，主动指出其中你认为可能存在风险或值得讨论的假设。4. 保持对话上下文的连贯性。”

这个元提示设定了协作的基本协议，让AI的行为更符合循环工程的需要。它从被动的执行者，变成了一个带有轻微主动性的协作者。

4.2 建立可复用的“循环模板”与知识库

当你通过循环解决了一个典型问题（例如，“如何在本项目中实现分页查询API”），不要关闭对话就了事。将这个成功的“循环”完整记录保存下来。你可以：

• 提炼成模板：将这个循环中关键的意图表达、反馈话术、最终解决方案抽象成一个模板文件。下次遇到类似任务，直接复用模板作为起点。
• 构建项目知识库：将多个重要循环的精华部分（最终确定的代码、关键的决策点、踩过的坑）整理到一个内部Wiki或Markdown文档中。这个知识库会成为未来循环中最重要的上下文来源。你可以直接对AI说：“关于用户权限验证，请参考我们项目知识库中‘RBAC实现V2’的章节。”

4.3 处理循环中的分歧与僵局

循环并非总是一帆风顺。有时AI会“固执己见”，反复生成不符合你核心约束的代码。这时需要策略：

• 降级分解：如果在一个复杂问题上僵持不下，立即停止。将问题分解成更小的子问题，逐个循环击破。例如，不要在“如何设计整个认证系统”上纠缠，先循环完成“如何安全地哈希密码”这个子任务。
• 引入外部裁决：让AI模拟不同角色进行辩论，或者要求它列出当前方案的三个主要替代方案及其利弊，帮助你思考。你可以说：“暂停编码。请分别以‘追求极致性能的工程师’和‘追求可维护性的架构师’的角度，评价我们刚才讨论的这两种缓存策略。”
• 重置与重启：如果上下文已经混乱，AI开始“胡言乱语”，最有效的方法不是继续纠缠，而是果断地开启一个新对话，并将旧对话中已明确、正确的结论作为初始上下文清晰地粘贴进去。这相当于一次“垃圾回收”，成本往往比试图在混乱中厘清要低。

5. 避坑指南：循环工程中的常见反模式

在实践中，我总结出几个必须避免的反模式，它们会让你的循环效率低下甚至失败。

反模式一：反馈过于模糊或宏大。

• 错误示例：“这个函数不好，重写一下。” 或者 “优化一下性能。”
• 问题：AI不知道具体哪里不好，也不知道“好”的标准是什么。它可能盲目地重构，却完全没碰到真正的痛点。
• 正确做法：提供具体、可操作的反馈。“这个函数calculateScore的循环时间复杂度是O(n²)，当users数组很大时可能成为瓶颈。请尝试使用哈希表将其优化到O(n)。这里是输入数据的样例结构（附上）。优先保持代码可读性。”

反模式二：在单次循环中塞入过多任务。

• 错误示例：“请修复这个函数的bug，同时为它添加单元测试，再写一份API文档，并且考虑一下它是否需要用TypeScript重写。”
• 问题：这违反了循环工程的“快速反馈”原则。AI可能只完成其中一两项，或完成的质量都不高。你也不易验证每一项是否正确。
• 正确做法：一次循环，一个焦点。先循环修复bug并验证。然后开启新循环：“现在这个函数已经稳定，请为它编写三个关键的单元测试，覆盖正常路径、边界情况和错误输入。” 完成后再进行下一项。

反模式三：盲目接受AI的第一次优化建议。

• 错误示例：AI说“这里可以用map和filter链式调用更优雅”，你就不假思索地同意。
• 问题：AI的“优雅”建议有时会牺牲微小的性能，或降低某些场景下的可调试性。它不一定符合你的项目特定规范。
• 正确做法：对AI提出的结构性建议保持批判性思考。追问：“链式调用相比原来的for循环，在内存使用上有何不同？如果中间某一步出错，调试栈信息是否清晰？” 根据回答和你的项目实际情况做决定。

反模式四：忽视“循环疲劳”。

• 问题：开发者沉浸在快速迭代的兴奋中，进行了过多轮次的微小调整，追求“绝对完美”，导致时间效益比急剧下降。
• 解决方案：为每个循环设定明确的“出口条件”。例如，“当函数通过所有单元测试且代码审查中无严重缺陷时，即视为完成。” 或者“最多进行5轮迭代，之后必须做出决策（接受当前版本或完全推翻采用新方案）。” 记住，完成比完美更重要，尤其是在早期原型阶段。

从我个人的体验来看，从“提示工程”到“循环工程”的转变，最难的并不是学习新工具，而是克服那种“想要一次性把需求说清楚”的旧习惯。它要求我们更坦诚地面对开发过程中天然存在的不确定性和演进性，并把AI真正纳入到这个探索性的流程中来。这不再是给AI下命令，而是与AI共同面对问题、拆解问题、解决问题的持续对话。当你习惯了这种工作节奏，你会发现，你产出的不仅仅是更好的代码，还有一份记录了整个设计决策过程的、活生生的开发文档。这或许才是“循环工程”带来的、比效率提升更深远的改变。