1. 从“提示”到“循环”一场编程范式的静默革命最近一个观点在开发者圈子里激起了不小的波澜“Claude Code 之父”公开表示他个人已经“不再提示 AI 了”。这句话乍一听有些反直觉甚至像是一种倒退。毕竟过去两年我们被灌输的核心思想是提示工程Prompt Engineering是驾驭大模型的必备技能。从写诗作画到生成代码我们都在学习如何用更精准、更结构化的语言去“命令”AI。然而这位深度参与构建了顶尖AI编程助手的大佬却宣布要告别这种交互模式。这背后指向的并非AI的退场而是一种更深刻、更强大的新范式正在浮出水面循环工程Loop Engineering。这不仅仅是换个说法那么简单。如果说“提示”是一次性的、单向的指令发射那么“循环”则构建了一个动态的、双向的、持续演进的协作系统。它标志着我们与AI协作的方式正在从“下达指令”转向“共同构建”。对于每一位开发者、产品经理乃至任何需要创造性解决问题的人来说理解并掌握这种范式可能比当年学习如何写一个完美的 ChatGPT 提示词更为关键。它关乎的不仅是效率的提升更是思维和工作流的根本性重塑。2. “提示工程”的辉煌与局限为什么单向指令不够用了在深入循环工程之前我们有必要先回顾一下提示工程的成就与它天然的天花板。提示工程的出现本质上是为了解决大语言模型LLM作为一个“黑箱”的不可控性问题。通过精心设计的指令、上下文示例Few-Shot、思维链Chain-of-Thought等技术我们试图将人类模糊的意图转化为模型能够稳定、高质量执行的明确任务。在代码生成、内容创作、数据分析等场景它取得了巨大的成功。然而随着应用深入其局限性也日益凸显2.1 信息损耗与意图偏差人类的复杂想法往往是多维、动态且充满潜台词的。当我们试图用一段文本提示来完整封装一个需求时信息损耗不可避免。比如你想开发一个具有特定交互逻辑的UI组件你的脑中可能有清晰的用户体验流、边界状态处理和视觉细节但用文字描述时这些信息会大量丢失或简化。AI基于不完整的“快照”生成的结果自然难以一次命中靶心导致需要多次“提示-修正”的拉锯战。2.2 上下文长度的诅咒尽管模型的上下文窗口在不断增长从4K、128K到如今的数百万token但将整个项目的所有相关代码、文档、需求都塞进一个提示里是不现实且低效的。长上下文不仅成本高昂还会导致模型注意力分散性能下降。提示工程被迫在“信息完整性”和“提示有效性”之间做艰难取舍。2.3 缺乏状态与记忆传统的提示交互是无状态的。每一次对话在理论上都是独立的模型不会主动记住之前的决策逻辑、尝试过的路径或已达成共识的设计。当你发现生成代码的某个部分有问题修正后再次提示时模型无法智能地将其与之前的工作关联可能导致新的生成与已修改部分产生冲突或者重复已经讨论过并否决的方案。2.4 创造性探索的束缚真正的创造性工作尤其是软件开发很少是线性执行的。它更像是一个探索过程有了一个初步构想实现一部分观察效果发现新问题或新灵感然后调整方向。僵化的“提示-执行”模式打断了这种自然流迫使开发者将非线性的思考强行压缩成线性的指令序列抑制了灵感的涌现和方案的优化。正是这些痛点催生了向“循环工程”的演进。循环工程不是否定提示的价值而是将其从一个交互的终点转变为协作循环中的一个环节。3. 解构“循环工程”核心组件与运行机制那么什么是循环工程我们可以将其理解为一个由人、AI Agent、工具和环境共同构成的、具备感知、决策、执行与学习能力的自治系统。在这个系统里你不再需要事无巨细地“提示”而是定义目标、设定规则、提供反馈然后观察并引导系统自主运行。一个典型的循环工程系统包含以下几个核心组件3.1 目标与约束的清晰定义Goal Constraints这是循环的起点也是最重要的“元提示”。你不再说“写一个登录页面”而是定义“构建一个符合WCAG 2.1 AA标准的、支持邮箱/手机号/第三方OAuth登录的React组件。首要目标是安全性防止XSS、CSRF其次是用户体验加载状态、错误提示、密码强度提示。性能预算首次加载时间小于100ms。” 这为AI Agent提供了明确的评判标准和行动边界。3.2 具备工具使用能力的AI Agent这是循环的执行主体。一个强大的Agent不仅能够生成文本/代码还能调用各种工具执行终端命令、运行测试、查询数据库、调用API、静态分析代码、甚至启动一个开发服务器进行实时预览。例如Agent在生成一段数据库查询代码后可以立即调用一个工具在测试数据库上执行它验证结果是否正确性能是否达标。3.3 持续观察与反馈机制Observation Feedback系统需要有能力持续监控运行状态。这包括代码层面静态检查ESLint, TypeScript编译、单元测试覆盖率、依赖安全扫描npm audit。运行时层面控制台错误、网络请求状态、性能指标LCP, FID。业务逻辑层面通过编写特定的验证脚本或断言检查生成代码是否满足了初始定义的目标和约束。 反馈可以是自动化的测试失败触发重构也可以是人工的轻量级干预代码审查中高亮某行评论“这里的错误处理不够健壮”。3.4 迭代与学习循环Iteration Learning基于反馈系统进入下一个迭代周期。高级的循环系统具备一定的学习能力它能记住导致测试失败的代码模式在后续生成中避免它能从人工反馈中提炼出代码风格或架构偏好应用于未来任务。这个循环会一直持续直到所有预设的目标和约束被满足或者达到某个迭代上限。一个简化的工作流对比传统提示工程开发者构思 - 编写长篇提示 - 等待AI生成 - 人工审查 - 发现问题 - 重新构思提示 - 再次生成...循环工程开发者定义目标/约束 - 启动循环 - AI Agent自主规划、编码、测试、调试 - 系统呈现当前结果与状态 - 开发者给予高阶反馈或批准 - 循环继续...在循环中开发者的角色从“微操的指挥官”转变为“设定战略目标的教练”和“关键节点的裁判”。4. 实战推演用循环工程模式开发一个微服务API为了更具体地理解让我们设想一个实战场景开发一个用户订单管理的微服务API。我们将对比传统提示与循环工程两种模式下的不同体验。4.1 传统提示模式下的挣扎你可能会给AI这样一个提示“用Node.js, Express和Mongoose写一个订单管理的RESTful API包含创建、读取、更新、删除订单的功能。订单包含用户ID、商品列表、总价、状态。状态有‘待支付’、‘已支付’、‘配送中’、‘已完成’。要包含数据验证和错误处理。”AI生成代码后你需要手动检查Mongoose Schema定义是否准确。创建测试数据库连接并运行服务。用Postman手动测试每个端点检查返回格式、状态码、错误处理。发现“更新订单状态”的接口没有做权限校验任何用户都能更新他人订单于是回头修改提示或手动改代码。发现缺少分页查询再次补充提示。检查代码风格添加ESLint配置。 整个过程是碎片化、重复且高度依赖人工深度介入的。4.2 循环工程模式下的流畅协作现在我们切换到循环工程范式。你的初始输入即“元提示”变为目标创建一个生产就绪的用户订单管理微服务API。技术栈Node.js, Express, Mongoose。使用TypeScript。核心需求CRUD操作包含字段验证。订单状态机待支付 - 已支付 - 配送中 - 已完成状态转换需符合业务逻辑。权限系统用户只能操作自己的订单管理员可操作所有订单。API响应标准化统一成功/错误格式。包含完整的单元测试Jest和集成测试覆盖率80%。添加请求日志和性能监控中间件。编写清晰的API文档OpenAPI/Swagger。约束代码需通过ESLintAirbnb规则和TypeScript严格模式检查。使用依赖注入提升可测试性。启动循环后AI Agent开始工作规划自动生成项目结构图列出需要创建的模块模型、控制器、服务、路由、测试、中间件。执行-反馈循环Agent生成Order模型Schema并自动调用一个工具运行tsc --noEmit进行类型检查同时用ESLint检查代码风格。如有错误立即自行修正。生成createOrder控制器随后自动生成并运行对应的Jest单元测试模拟请求、验证响应。如果测试失败Agent会分析错误日志调整代码逻辑或测试用例重新运行直到通过。在实现权限中间件时Agent可能会自动查询类似功能的开源项目最佳实践将其整合到代码中。完成所有端点后Agent自动启动一个测试用的MongoDB实例和Express服务器运行一套集成测试脚本验证从创建用户、登录获取Token到操作订单的完整流程。呈现与人工介入循环运行数分钟后系统向你呈现一个可运行的Git仓库链接。一份测试覆盖率报告显示85%覆盖率。一份自动生成的Swagger UI文档地址。一个高亮列表指出几处需要你决策的“歧义点”例如“‘取消订单’状态是否加入业务逻辑是退款还是仅标记”。高阶反馈你不需要去逐行review代码而是直接针对这些“歧义点”做出业务决策。你也可以提出新的高阶目标“很好现在请为这个服务添加一个Dockerfile并编写一个docker-compose.yml使其能连同MongoDB一起容器化部署。”循环继续Agent接收新目标继续执行Docker化任务并确保新配置不影响原有测试的通过。在整个过程中你几乎没有写过一行具体的“提示词”去指挥如何写某行代码。你的工作聚焦于定义“做什么”和“做到什么标准”以及处理那些需要人类商业直觉和创造力的关键决策。繁琐的实现、测试、调试、优化工作由AI Agent在循环中自主完成。5. 构建你自己的循环工具、模式与心法理解了概念和案例你可能会问如何开始实践循环工程目前虽然完全自动化的“终极形态”平台还在发展中但我们完全可以利用现有工具和模式搭建初代的循环工作流。5.1 工具链选型与集成核心AI能力Claude Code、GitHub Copilot Workspace、Cursor的Agent模式、或是利用OpenAI/Anthropic API自建Agent。它们的共同特点是支持较长的上下文、一定的规划能力以及最重要的——可以通过函数调用Function Calling或代码解释器Code Interpreter与外部工具交互。自动化脚本与工具这是循环的“手和脚”。你需要准备测试框架Jest, Pytest, Mocha等并能通过命令行运行。代码质量工具ESLint, Prettier, MyPy, Black等。构建与检查工具Webpack/Vite的构建命令、tsc类型检查、go build编译。容器化工具Docker build run命令。监控脚本用简单的Node/Python脚本监听文件变化、运行测试、收集日志。粘合剂一个Shell脚本如Makefile、一个Python脚本、或更高级的任务运行器如Nx, Turborepo来编排整个流程。它的作用是接收一个高层任务然后顺序或并行地调用AI生成代码、运行工具、检查结果、决定下一步。5.2 可复用的循环模式TDD循环模式先由AI根据需求描述编写测试用例失败然后AI再生成实现代码使测试通过最后进行重构。整个过程由脚本自动化。“修复所有lint错误”模式AI生成代码后自动运行lint工具将错误信息反馈给AI让其自行修正直到通过。“实现并集成”模式AI实现一个独立函数/模块后自动运行单元测试通过后再将其集成到主程序中运行集成测试。“文档与代码同步”模式AI修改代码后自动检查对应的API文档如JSDoc注释、Swagger定义是否需要更新并尝试同步更新。5.3 心态与工作流的转变这是最难也是最重要的一步。实施循环工程要求开发者进行深刻的角色转变从“编写者”到“设计者与评审者”你的核心产出不再是代码行而是清晰、无歧义的需求规格、架构设计、验收标准和约束条件。代码本身成了AI在满足这些规格过程中产生的“副产品”。拥抱“定义问题”而非“解决问题”80%的精力应花在确保问题被完美定义上。一个模糊的问题在循环中会导致混乱和低效而一个清晰的问题则能引导AI高速产出优质解。信任与验证并存你需要信任系统能处理大部分细节但同时要建立强大的自动化验证体系测试、lint、安全扫描作为安全网确保产出的质量底线。与AI进行“高阶对话”反馈的语言要升级。从“这个变量名不好”变为“我们项目的命名约定是使用驼峰式请检查所有新生成代码的合规性”从“这里有个bug”变为“在用户未登录的情况下访问此端点系统应返回401状态码和统一错误格式请修复所有相关端点”。6. 当前边界与未来展望循环工程的挑战与机遇尽管前景诱人但循环工程范式目前仍处于早期阶段面临诸多挑战6.1 技术挑战长程规划与状态管理AI Agent在复杂、多步骤任务中的规划能力仍不稳定容易“遗忘”长期目标或陷入局部优化。工具使用的可靠性与安全性让AI自主执行终端命令、操作数据库存在显著风险。需要精细的权限沙箱和操作确认机制。“幻觉”在循环中的放大在多次迭代中AI前期的一个小错误或误解可能会被后续步骤放大导致整个工作流跑偏且难以诊断。复杂调试当循环自动运行产生错误时调试过程可能比调试人工代码更复杂你需要理解AI的“决策链”。6.2 成本与效率考量持续的AI调用和工具执行会产生可观的计算成本。对于简单任务传统手动编码或简单提示可能更经济快捷。需要找到成本效益的平衡点。6.3 对开发者技能的重塑未来初级开发者“写业务代码”的价值可能会被极大稀释。更重要的能力将集中在系统设计、领域建模、制定高质量测试与验收标准、以及驾驭和调试AI协作系统。这要求开发者具备更高的抽象思维和系统思维。6.4 未来的融合形态可以预见未来的IDE将深度集成循环工程能力。你或许只需在代码注释中用自然语言写下// TODO: 这里需要一个函数输入是A输出是B需要处理C异常然后一个背景运行的Agent就会理解上下文自动实现、测试并将其无缝集成到代码库中并创建一个Pull Request等待你的审查。编程将越来越接近于“与一个超级智能的结对编程伙伴进行持续的高层对话”。“不再提示AI了”这句话的真正含义是我们正在超越那个需要不断向黑箱发送精妙咒语的阶段进入一个与AI共同生长、相互塑造的循环。我们设定目标、提供反馈、做出关键抉择AI负责探索路径、执行细节、验证结果。这种范式不是要取代开发者而是将开发者从重复性、机械性的劳作中解放出来更专注于创造、设计和决策——那些真正属于人类的、更高价值的工作。 从提示工程到循环工程：AI协作编程的新范式演进
1. 从“提示”到“循环”一场编程范式的静默革命最近一个观点在开发者圈子里激起了不小的波澜“Claude Code 之父”公开表示他个人已经“不再提示 AI 了”。这句话乍一听有些反直觉甚至像是一种倒退。毕竟过去两年我们被灌输的核心思想是提示工程Prompt Engineering是驾驭大模型的必备技能。从写诗作画到生成代码我们都在学习如何用更精准、更结构化的语言去“命令”AI。然而这位深度参与构建了顶尖AI编程助手的大佬却宣布要告别这种交互模式。这背后指向的并非AI的退场而是一种更深刻、更强大的新范式正在浮出水面循环工程Loop Engineering。这不仅仅是换个说法那么简单。如果说“提示”是一次性的、单向的指令发射那么“循环”则构建了一个动态的、双向的、持续演进的协作系统。它标志着我们与AI协作的方式正在从“下达指令”转向“共同构建”。对于每一位开发者、产品经理乃至任何需要创造性解决问题的人来说理解并掌握这种范式可能比当年学习如何写一个完美的 ChatGPT 提示词更为关键。它关乎的不仅是效率的提升更是思维和工作流的根本性重塑。2. “提示工程”的辉煌与局限为什么单向指令不够用了在深入循环工程之前我们有必要先回顾一下提示工程的成就与它天然的天花板。提示工程的出现本质上是为了解决大语言模型LLM作为一个“黑箱”的不可控性问题。通过精心设计的指令、上下文示例Few-Shot、思维链Chain-of-Thought等技术我们试图将人类模糊的意图转化为模型能够稳定、高质量执行的明确任务。在代码生成、内容创作、数据分析等场景它取得了巨大的成功。然而随着应用深入其局限性也日益凸显2.1 信息损耗与意图偏差人类的复杂想法往往是多维、动态且充满潜台词的。当我们试图用一段文本提示来完整封装一个需求时信息损耗不可避免。比如你想开发一个具有特定交互逻辑的UI组件你的脑中可能有清晰的用户体验流、边界状态处理和视觉细节但用文字描述时这些信息会大量丢失或简化。AI基于不完整的“快照”生成的结果自然难以一次命中靶心导致需要多次“提示-修正”的拉锯战。2.2 上下文长度的诅咒尽管模型的上下文窗口在不断增长从4K、128K到如今的数百万token但将整个项目的所有相关代码、文档、需求都塞进一个提示里是不现实且低效的。长上下文不仅成本高昂还会导致模型注意力分散性能下降。提示工程被迫在“信息完整性”和“提示有效性”之间做艰难取舍。2.3 缺乏状态与记忆传统的提示交互是无状态的。每一次对话在理论上都是独立的模型不会主动记住之前的决策逻辑、尝试过的路径或已达成共识的设计。当你发现生成代码的某个部分有问题修正后再次提示时模型无法智能地将其与之前的工作关联可能导致新的生成与已修改部分产生冲突或者重复已经讨论过并否决的方案。2.4 创造性探索的束缚真正的创造性工作尤其是软件开发很少是线性执行的。它更像是一个探索过程有了一个初步构想实现一部分观察效果发现新问题或新灵感然后调整方向。僵化的“提示-执行”模式打断了这种自然流迫使开发者将非线性的思考强行压缩成线性的指令序列抑制了灵感的涌现和方案的优化。正是这些痛点催生了向“循环工程”的演进。循环工程不是否定提示的价值而是将其从一个交互的终点转变为协作循环中的一个环节。3. 解构“循环工程”核心组件与运行机制那么什么是循环工程我们可以将其理解为一个由人、AI Agent、工具和环境共同构成的、具备感知、决策、执行与学习能力的自治系统。在这个系统里你不再需要事无巨细地“提示”而是定义目标、设定规则、提供反馈然后观察并引导系统自主运行。一个典型的循环工程系统包含以下几个核心组件3.1 目标与约束的清晰定义Goal Constraints这是循环的起点也是最重要的“元提示”。你不再说“写一个登录页面”而是定义“构建一个符合WCAG 2.1 AA标准的、支持邮箱/手机号/第三方OAuth登录的React组件。首要目标是安全性防止XSS、CSRF其次是用户体验加载状态、错误提示、密码强度提示。性能预算首次加载时间小于100ms。” 这为AI Agent提供了明确的评判标准和行动边界。3.2 具备工具使用能力的AI Agent这是循环的执行主体。一个强大的Agent不仅能够生成文本/代码还能调用各种工具执行终端命令、运行测试、查询数据库、调用API、静态分析代码、甚至启动一个开发服务器进行实时预览。例如Agent在生成一段数据库查询代码后可以立即调用一个工具在测试数据库上执行它验证结果是否正确性能是否达标。3.3 持续观察与反馈机制Observation Feedback系统需要有能力持续监控运行状态。这包括代码层面静态检查ESLint, TypeScript编译、单元测试覆盖率、依赖安全扫描npm audit。运行时层面控制台错误、网络请求状态、性能指标LCP, FID。业务逻辑层面通过编写特定的验证脚本或断言检查生成代码是否满足了初始定义的目标和约束。 反馈可以是自动化的测试失败触发重构也可以是人工的轻量级干预代码审查中高亮某行评论“这里的错误处理不够健壮”。3.4 迭代与学习循环Iteration Learning基于反馈系统进入下一个迭代周期。高级的循环系统具备一定的学习能力它能记住导致测试失败的代码模式在后续生成中避免它能从人工反馈中提炼出代码风格或架构偏好应用于未来任务。这个循环会一直持续直到所有预设的目标和约束被满足或者达到某个迭代上限。一个简化的工作流对比传统提示工程开发者构思 - 编写长篇提示 - 等待AI生成 - 人工审查 - 发现问题 - 重新构思提示 - 再次生成...循环工程开发者定义目标/约束 - 启动循环 - AI Agent自主规划、编码、测试、调试 - 系统呈现当前结果与状态 - 开发者给予高阶反馈或批准 - 循环继续...在循环中开发者的角色从“微操的指挥官”转变为“设定战略目标的教练”和“关键节点的裁判”。4. 实战推演用循环工程模式开发一个微服务API为了更具体地理解让我们设想一个实战场景开发一个用户订单管理的微服务API。我们将对比传统提示与循环工程两种模式下的不同体验。4.1 传统提示模式下的挣扎你可能会给AI这样一个提示“用Node.js, Express和Mongoose写一个订单管理的RESTful API包含创建、读取、更新、删除订单的功能。订单包含用户ID、商品列表、总价、状态。状态有‘待支付’、‘已支付’、‘配送中’、‘已完成’。要包含数据验证和错误处理。”AI生成代码后你需要手动检查Mongoose Schema定义是否准确。创建测试数据库连接并运行服务。用Postman手动测试每个端点检查返回格式、状态码、错误处理。发现“更新订单状态”的接口没有做权限校验任何用户都能更新他人订单于是回头修改提示或手动改代码。发现缺少分页查询再次补充提示。检查代码风格添加ESLint配置。 整个过程是碎片化、重复且高度依赖人工深度介入的。4.2 循环工程模式下的流畅协作现在我们切换到循环工程范式。你的初始输入即“元提示”变为目标创建一个生产就绪的用户订单管理微服务API。技术栈Node.js, Express, Mongoose。使用TypeScript。核心需求CRUD操作包含字段验证。订单状态机待支付 - 已支付 - 配送中 - 已完成状态转换需符合业务逻辑。权限系统用户只能操作自己的订单管理员可操作所有订单。API响应标准化统一成功/错误格式。包含完整的单元测试Jest和集成测试覆盖率80%。添加请求日志和性能监控中间件。编写清晰的API文档OpenAPI/Swagger。约束代码需通过ESLintAirbnb规则和TypeScript严格模式检查。使用依赖注入提升可测试性。启动循环后AI Agent开始工作规划自动生成项目结构图列出需要创建的模块模型、控制器、服务、路由、测试、中间件。执行-反馈循环Agent生成Order模型Schema并自动调用一个工具运行tsc --noEmit进行类型检查同时用ESLint检查代码风格。如有错误立即自行修正。生成createOrder控制器随后自动生成并运行对应的Jest单元测试模拟请求、验证响应。如果测试失败Agent会分析错误日志调整代码逻辑或测试用例重新运行直到通过。在实现权限中间件时Agent可能会自动查询类似功能的开源项目最佳实践将其整合到代码中。完成所有端点后Agent自动启动一个测试用的MongoDB实例和Express服务器运行一套集成测试脚本验证从创建用户、登录获取Token到操作订单的完整流程。呈现与人工介入循环运行数分钟后系统向你呈现一个可运行的Git仓库链接。一份测试覆盖率报告显示85%覆盖率。一份自动生成的Swagger UI文档地址。一个高亮列表指出几处需要你决策的“歧义点”例如“‘取消订单’状态是否加入业务逻辑是退款还是仅标记”。高阶反馈你不需要去逐行review代码而是直接针对这些“歧义点”做出业务决策。你也可以提出新的高阶目标“很好现在请为这个服务添加一个Dockerfile并编写一个docker-compose.yml使其能连同MongoDB一起容器化部署。”循环继续Agent接收新目标继续执行Docker化任务并确保新配置不影响原有测试的通过。在整个过程中你几乎没有写过一行具体的“提示词”去指挥如何写某行代码。你的工作聚焦于定义“做什么”和“做到什么标准”以及处理那些需要人类商业直觉和创造力的关键决策。繁琐的实现、测试、调试、优化工作由AI Agent在循环中自主完成。5. 构建你自己的循环工具、模式与心法理解了概念和案例你可能会问如何开始实践循环工程目前虽然完全自动化的“终极形态”平台还在发展中但我们完全可以利用现有工具和模式搭建初代的循环工作流。5.1 工具链选型与集成核心AI能力Claude Code、GitHub Copilot Workspace、Cursor的Agent模式、或是利用OpenAI/Anthropic API自建Agent。它们的共同特点是支持较长的上下文、一定的规划能力以及最重要的——可以通过函数调用Function Calling或代码解释器Code Interpreter与外部工具交互。自动化脚本与工具这是循环的“手和脚”。你需要准备测试框架Jest, Pytest, Mocha等并能通过命令行运行。代码质量工具ESLint, Prettier, MyPy, Black等。构建与检查工具Webpack/Vite的构建命令、tsc类型检查、go build编译。容器化工具Docker build run命令。监控脚本用简单的Node/Python脚本监听文件变化、运行测试、收集日志。粘合剂一个Shell脚本如Makefile、一个Python脚本、或更高级的任务运行器如Nx, Turborepo来编排整个流程。它的作用是接收一个高层任务然后顺序或并行地调用AI生成代码、运行工具、检查结果、决定下一步。5.2 可复用的循环模式TDD循环模式先由AI根据需求描述编写测试用例失败然后AI再生成实现代码使测试通过最后进行重构。整个过程由脚本自动化。“修复所有lint错误”模式AI生成代码后自动运行lint工具将错误信息反馈给AI让其自行修正直到通过。“实现并集成”模式AI实现一个独立函数/模块后自动运行单元测试通过后再将其集成到主程序中运行集成测试。“文档与代码同步”模式AI修改代码后自动检查对应的API文档如JSDoc注释、Swagger定义是否需要更新并尝试同步更新。5.3 心态与工作流的转变这是最难也是最重要的一步。实施循环工程要求开发者进行深刻的角色转变从“编写者”到“设计者与评审者”你的核心产出不再是代码行而是清晰、无歧义的需求规格、架构设计、验收标准和约束条件。代码本身成了AI在满足这些规格过程中产生的“副产品”。拥抱“定义问题”而非“解决问题”80%的精力应花在确保问题被完美定义上。一个模糊的问题在循环中会导致混乱和低效而一个清晰的问题则能引导AI高速产出优质解。信任与验证并存你需要信任系统能处理大部分细节但同时要建立强大的自动化验证体系测试、lint、安全扫描作为安全网确保产出的质量底线。与AI进行“高阶对话”反馈的语言要升级。从“这个变量名不好”变为“我们项目的命名约定是使用驼峰式请检查所有新生成代码的合规性”从“这里有个bug”变为“在用户未登录的情况下访问此端点系统应返回401状态码和统一错误格式请修复所有相关端点”。6. 当前边界与未来展望循环工程的挑战与机遇尽管前景诱人但循环工程范式目前仍处于早期阶段面临诸多挑战6.1 技术挑战长程规划与状态管理AI Agent在复杂、多步骤任务中的规划能力仍不稳定容易“遗忘”长期目标或陷入局部优化。工具使用的可靠性与安全性让AI自主执行终端命令、操作数据库存在显著风险。需要精细的权限沙箱和操作确认机制。“幻觉”在循环中的放大在多次迭代中AI前期的一个小错误或误解可能会被后续步骤放大导致整个工作流跑偏且难以诊断。复杂调试当循环自动运行产生错误时调试过程可能比调试人工代码更复杂你需要理解AI的“决策链”。6.2 成本与效率考量持续的AI调用和工具执行会产生可观的计算成本。对于简单任务传统手动编码或简单提示可能更经济快捷。需要找到成本效益的平衡点。6.3 对开发者技能的重塑未来初级开发者“写业务代码”的价值可能会被极大稀释。更重要的能力将集中在系统设计、领域建模、制定高质量测试与验收标准、以及驾驭和调试AI协作系统。这要求开发者具备更高的抽象思维和系统思维。6.4 未来的融合形态可以预见未来的IDE将深度集成循环工程能力。你或许只需在代码注释中用自然语言写下// TODO: 这里需要一个函数输入是A输出是B需要处理C异常然后一个背景运行的Agent就会理解上下文自动实现、测试并将其无缝集成到代码库中并创建一个Pull Request等待你的审查。编程将越来越接近于“与一个超级智能的结对编程伙伴进行持续的高层对话”。“不再提示AI了”这句话的真正含义是我们正在超越那个需要不断向黑箱发送精妙咒语的阶段进入一个与AI共同生长、相互塑造的循环。我们设定目标、提供反馈、做出关键抉择AI负责探索路径、执行细节、验证结果。这种范式不是要取代开发者而是将开发者从重复性、机械性的劳作中解放出来更专注于创造、设计和决策——那些真正属于人类的、更高价值的工作。