1. 从“一次性指令”到“持续对话”：AI编程范式的根本性转变
最近在AI编程的圈子里，一个观点开始被越来越多的人讨论：传统的“提示词工程”正在走向终结，而一种被称为“Loop Engineering”的新范式正在崛起。作为一个长期混迹于开发一线、尝试过各种AI编程工具的老兵，我对这个转变的感受尤为深刻。过去，我们和AI编程助手（比如早期的GitHub Copilot）的交互，更像是在玩一个“猜谜游戏”——你需要绞尽脑汁，用最精确、最无歧义的英文或中文，一次性描述清楚你的需求，然后祈祷AI能理解并生成正确的代码。这个过程，就是典型的“提示词工程”。它的核心是“一次性交付”，成败很大程度上取决于你第一次提问的质量。
然而，随着Claude Code、Cursor这类新一代“智能体式”AI编程工具的出现，游戏的规则彻底改变了。它们不再满足于当一个被动的代码补全工具，而是试图成为一个能与你持续对话、共同思考、甚至主动推进项目的“结对编程伙伴”。这时，你和AI的交互不再是单次的“提问-回答”，而是一个动态的、多轮的、不断演进的“循环”。你需要引导它、纠正它、与它讨论设计、让它解释代码、甚至让它自己发现并修复错误。这个引导AI在复杂任务中持续、有效工作的过程，就是“循环工程”。它的核心是“过程管理”和“状态维护”，关注的是如何在一个漫长的对话中，始终保持目标的清晰和上下文的连贯。
为什么说这是“称王”的转变？因为软件开发本身就是一个高度迭代、充满反馈循环的过程。从需求分析、架构设计、编码实现、调试测试到重构优化，没有哪个环节是可以一蹴而就的。传统的提示词工程试图用一次完美的指令来匹配这个复杂过程，本质上是“削足适履”。而循环工程，则承认并拥抱了这种复杂性，它提供的是一套与软件开发天然契合的协作方法论。这不仅仅是工具能力的升级，更是我们与AI协作思维的革命。
2. 循环工程的核心：构建与AI的“认知飞轮”
理解循环工程，关键在于理解它如何构建一个正向的、不断增强的“认知飞轮”。这个飞轮由几个关键环节构成，它们循环往复，推动项目向目标前进。
2.1 状态共享与上下文管理
这是循环工程区别于提示词工程的第一道分水岭。在传统模式下，每次对话基本都是独立的，AI没有“记忆”你之前的对话历史和项目全貌（除非你手动把大量代码粘贴进去，很快就会触及上下文长度限制）。而在循环工程中，工具（如Cursor）会主动为你管理整个项目的上下文。当你打开一个项目文件并开启“Chat”模式时，AI已经“看到”了你的目录结构、相关文件，并能理解它们之间的关联。
实操要点：不要一上来就扔出一个模糊的需求。正确的做法是，先让AI“熟悉环境”。你可以这样开始对话：“我现在正在开发一个基于FastAPI的用户认证模块，项目结构如下（简要描述）。当前打开了auth.py和models.py文件。请先理解一下现有的代码结构。” 这个操作的目的，是让AI和你建立起共同的“认知基线”，为后续的精准协作打下基础。
注意：即使工具能自动感知部分上下文，主动进行清晰的“上下文初始化”仍然是高效协作的关键。这能避免AI基于错误或片面的信息进行推理。
2.2 目标分解与任务规划
面对一个复杂需求（例如，“为我们的电商系统添加一个优惠券功能”），循环工程不鼓励你直接让AI生成几百行代码。相反，它倡导将大目标分解为一系列可验证、可执行的小任务。
我的常用分解框架：
- 数据模型设计：优惠券需要哪些字段（ID、名称、折扣类型、面值/折扣率、使用条件、有效期等）？与用户、订单的关系是什么？
- API接口设计：需要哪些端点（创建、发放、核销、查询）？请求/响应体如何定义？
- 核心业务逻辑实现：核销时的条件校验（最低消费、适用范围、有效期、使用次数）如何实现？折扣计算逻辑是什么？
- 数据库迁移与集成：如何创建或修改数据库表？如何与现有订单流程集成？
你可以将整个规划过程与AI讨论：“为了实现在线商城的优惠券功能，我计划分四个阶段进行。第一阶段，我们先来设计数据模型。你认为Coupon这个模型应该包含哪些核心字段？请考虑多种折扣类型（固定金额、百分比、免运费）和复杂的条件（品类限制、用户等级限制）。”
通过这种方式，AI从一个被动的代码生成器，转变为了一个共同制定计划的协作者。它可能会提出你没想到的边界情况，比如“是否考虑同一订单叠加使用多张优惠券的策略？”。
2.3 迭代式开发与即时反馈
这是循环工程最体现价值的环节。你不再需要等待AI生成一大段代码后再去费力审查。而是可以以极小的步幅前进，并立即获得反馈。
典型的工作流：
- 你提出一个小任务：“根据我们刚才讨论的模型，在
models.py中创建Coupon和UserCoupon两个SQLAlchemy模型。” - AI生成代码。
- 你审查并提出修改：“
valid_from和valid_to字段用DateTime类型很好，但请为它们加上索引，因为我们经常会按有效期查询。另外，discount_value字段应该用Numeric类型来精确存储金额。” - AI根据反馈修改代码，并可能解释：“已添加索引。使用
Numeric(10,2)来存储，确保小数点后两位精度，适用于货币。” - 你继续推进：“很好。现在，请在
auth.py旁边创建coupon.py服务文件，实现一个validate_coupon(coupon_code, user_id, cart_amount)的函数骨架，先写出参数和返回值定义。”
这个过程就像真正的结对编程，你扮演着“导航员”的角色，不断微调方向；AI则是“驾驶员”，负责具体执行，并随时汇报进展和遇到的问题。任何理解偏差都能在几轮对话内被迅速纠正，避免了在错误的方向上浪费大量时间。
2.4 调试与根因分析
当代码出现Bug或行为不符合预期时，循环工程的优势更加明显。你不再需要自己埋头苦读错误栈，或者费劲地向AI重新描述问题。
高效的调试对话：
- 你：“运行测试时，
test_apply_percentage_coupon失败了，报错是‘Division by zero’。这是测试用例和生成的apply_discount函数。” - AI：“我看到问题了。在
apply_discount函数中，当discount_type为 ‘percentage‘ 时，计算折后价的公式是price * (1 - discount_value)。这里discount_value是百分比的小数表示（如0.2代表20%）。测试用例传入的discount_value是20，导致1 - 20 = -19，虽然不会除零，但逻辑错误。根本原因是模型字段discount_value存储的是原始值（如20），而业务逻辑层期望的是小数（0.2）。我们需要统一数据表示层或修改业务逻辑。” - 你：“分析得对。我们不应该修改数据模型，因为存储原始整数20比存储0.2更直观，也避免浮点数精度问题。请修改
apply_discount函数，在处理百分比时，先将discount_value除以100。”
AI不仅能定位到具体的出错行，更能分析出导致错误的根本原因——数据模型与业务逻辑之间的约定不一致。这已经超越了简单的语法检查，进入了软件设计协同的层面。
3. 实战：用循环工程思维开发一个微服务端点
让我们通过一个更具体的例子，感受一下循环工程的全流程。假设我们要为一个任务管理系统添加一个“批量归档旧任务”的端点。
3.1 第一阶段：需求澄清与上下文建立
我的操作：在项目根目录打开终端，启动 Cursor，并打开主要的task_service.py和相关的task_model.py文件。
我对AI说：“你好，我们正在维护一个任务管理微服务。当前项目结构是典型的FastAPI应用，使用SQLAlchemy和PostgreSQL。现有Task模型包含id,title,description,status（枚举：pending, in_progress, completed, archived）,created_at,updated_at等字段。现在需要增加一个功能：提供一个API端点，允许管理员将超过一定天数且状态为 ‘completed‘ 的任务自动归档（即 status 改为 ‘archived‘）。请先熟悉一下现有代码，特别是Task模型和相关的CRUD操作模式。”
AI的回应：“我已查看当前代码。我看到Task模型定义清晰，有一个update_task函数用于更新任务状态。项目使用asyncpg驱动。为了创建这个归档端点，我们需要：1. 确定天数阈值如何传递（查询参数？请求体？）。2. 编写一个服务函数，查询符合条件的任务并批量更新。3. 添加新的API端点。我们从哪里开始？”
这个开场白建立了共享的上下文，并让AI主动提出了下一步的计划选项。
3.2 第二阶段：协同设计与决策
我：“很好。我倾向于将天数作为查询参数，比如GET /tasks/archive?older_than_days=30。但这是一个会修改数据的操作，用GET方法不合适。你认为用POST /tasks/archive并在请求体中接收{“older_than_days“: 30}如何？另外，批量更新需要考虑性能，直接使用SQLAlchemy的ORM循环更新可能较慢。”
AI：“同意使用POST方法更符合RESTful语义。关于性能，我们可以使用SQLAlchemy Core的批量更新，或者直接执行一条UPDATE SQL语句。考虑到我们已经有ORM模型定义，使用async_session.execute(update(Task).where(...).values(status=‘archived‘))的方式会更高效。同时，这个操作应该在一个数据库事务中完成，并且需要记录哪些任务被归档了，返回给调用者。是否需要添加一个archived_at时间戳字段？”
我：“非常好的建议。增加archived_at字段对于审计很有帮助。请先修改task_model.py，为Task模型添加一个可空的archived_at(DateTime) 字段。然后，我们再讨论服务层和API层的实现。”
在这个阶段，我和AI就API设计、性能优化、数据模型演进等进行了多轮讨论，共同做出了更优的设计决策，而不是我单方面下达指令。
3.3 第三阶段：迭代实现与代码审查
AI：“已添加archived_at字段。以下是迁移脚本的草稿（使用Alembic）。接下来，我将在task_service.py中创建bulk_archive_tasks函数。函数的逻辑是：接收older_than_days参数，计算截止日期，在事务中执行批量更新，设置status=‘archived‘和archived_at=utcnow()，最后返回被归档的任务ID列表。我现在生成这个函数的第一版代码吗？”
我：“生成吧。注意，查询条件要同时满足status == ‘completed‘和updated_at < cutoff_date。另外，为了防止归档正在进行中的任务，再加一个条件status != ‘in_progress‘作为安全护栏。更新后，请同时生成对应的Pydantic响应模型BulkArchiveResponse，包含archived_count和task_ids字段。”
AI生成代码后，我逐行审查。我发现它生成的查询中，cutoff_date的计算用的是datetime.utcnow() - timedelta(days=older_than_days)。我立刻指出：
我：“这里的时间计算有问题。updated_at是带时区的吗？我们的数据库存储的是UTC时间吗？如果updated_at是naive datetime（假设是UTC），而datetime.utcnow()也是naive UTC，这样比较是可行的。但为了更健壮，显式使用datetime.now(timezone.utc)来获取感知时区的时间。请修改。”
通过这种即时的、基于具体代码行的反馈，AI迅速修正了潜在的问题，代码质量在编写过程中就得到了提升。
3.4 第四阶段：测试、边界情况与部署考量
函数实现后，我要求AI为我编写一个测试用例。
我：“请为bulk_archive_tasks函数编写一个pytest异步测试。需要覆盖的场景：1. 正常情况，有任务满足条件被归档。2. 没有任务满足条件。3. 传入的older_than_days为负数或零时的边界处理。4. 确保事务性，即如果更新中途失败，所有更改回滚。”
AI生成测试后，我们一同审查测试的完备性。AI主动提出：“我们是否还应该添加一个权限检查？这个端点可能只允许管理员角色调用。我注意到项目中有get_current_user依赖项，我们可以修改端点，注入当前用户，并在服务函数开头检查用户角色。”
我：“非常好的补充。这正是一个生产级API必须考虑的。请修改端点的依赖项，添加角色检查。另外，考虑到可能一次归档大量任务，为了避免请求超时，我们可以将端点改为异步触发一个后台任务（例如使用Celery或RQ），立即返回一个任务ID，允许客户端轮询结果。这个我们可以作为第二阶段优化。现在，我们先完成基础的同步版本并确保其正确性。”
整个流程下来，从需求到可测试、可部署的代码，我和AI完成了一次深度协作。我始终掌控着方向和架构决策，而AI承担了大部分细节实现、代码编写、逻辑审查和补充建议的工作。这远比我自己写提示词、复制代码、调试错误要流畅和高效得多。
4. 循环工程下的工具链与心智模型
要玩转循环工程，仅仅理解概念还不够，还需要适配的工具和全新的工作习惯。
4.1 工具选择：Cursor vs. Claude Code vs. 传统IDE插件
目前，最能体现循环工程思想的工具是Cursor和Claude Code。它们都将聊天界面深度集成到了编辑器中，并且具备强大的项目上下文感知能力。
- Cursor：更像是“ChatGPT + VSCode”的深度融合体。它的“Chat”面板可以引用具体代码块，自动理解项目结构，支持编辑器中直接应用AI建议的代码更改。其“Composer”功能允许你通过自然语言描述来生成或修改整个文件，非常适合在循环中快速创建原型或重构代码。
- Claude Code： Anthropic推出的产品，理念类似，强调与Claude模型的深度集成，在代码理解和长上下文对话方面可能有其独特优势。
相比之下，传统的IDE插件（如早期的Copilot）主要提供行内或函数级的代码补全，虽然高效，但缺乏对项目级上下文和复杂任务流程的支持，本质上还是“增强型的提示词工程”。
我的选择：目前我主要使用Cursor。它的流畅度、与VSCode生态的融合度以及快速的迭代更新，让我感觉它更像是为“循环工程”量身定做的。Claude Code同样值得关注，特别是对于深度依赖Claude系列模型的团队。
4.2 必备的心智模型转变
- 从“指挥官”到“导航员”：放弃那种“你，AI，给我写出完美代码”的指挥官心态。把自己想象成副驾驶或导航员，你的任务是设定目的地（目标）、规划路线（任务分解）、关注路况（审查代码）、并在必要时纠正方向（提供反馈）。
- 拥抱小步快跑：不要追求一个提示词解决所有问题。将任务拆解成AI可以轻松消化和执行的小步骤。每一步都有明确的输入、输出和验收标准。
- 上下文是燃料：主动管理对话上下文。及时总结共识，澄清模糊点。当对话轮数变多时，可以有意识地说：“让我们回顾一下目前达成的共识：1. … 2. … 接下来我们要解决的是…”。这能帮助AI（和你自己）保持思路清晰。
- 利用AI的推理能力：多问“为什么”、“你怎么看”、“这里有哪些潜在风险”。让AI成为你的思考伙伴，而不仅仅是代码打字机。它的价值不仅在于生成代码，更在于其分析、设计和排查问题的能力。
- 最终责任在你：AI生成的代码，无论看起来多完美，都必须经过你的严格审查。你仍然是代码质量、系统安全和业务逻辑正确性的最终负责人。循环工程提升的是效率和质量的下限，但上限和责任依然在你手中。
4.3 常见陷阱与避坑指南
即使掌握了循环工程的方法，在实际操作中还是会踩一些坑。以下是我总结的几个常见问题及应对策略：
陷阱一：上下文污染与注意力分散当对话轮数非常多，涉及多个不同文件或主题时，AI可能会“忘记”早先的约定，或者将不同任务的上下文混淆。
- 应对策略：对于大型、独立的新功能，可以考虑开启一个新的聊天会话（New Chat），从头建立干净的上下文。或者，在长对话中，定期进行关键决策的总结，并以“系统指令”的形式重申给AI，如：“【重要前提】我们始终使用SQLAlchemy 2.0的异步API，所有数据库操作必须在
async_session上下文内进行。”
陷阱二：AI的“过度自信”与错误坚持有时AI会基于错误的理解生成代码，并在你指出错误时，试图用复杂的解释来维护其错误，而不是承认并改正。
- 应对策略：不要陷入哲学辩论。直接给出明确的指令和证据。例如：“这个函数签名是错误的。请参考本项目
user_service.py第45行的get_user_by_id函数，它使用了AsyncSession作为参数类型，而不是Session。请按照同样的风格修改。” 引用具体的项目代码作为规范，比抽象描述更有效。
陷阱三：陷入琐碎细节，丢失宏观视野在循环中，很容易和AI一起钻进某个函数实现的细节里，忘了整体的架构和设计目标。
- 应对策略：在开始一个开发循环前，用注释或文档先写下简单的设计概要。在对话中，时不时跳出来问AI：“从架构上看，我们目前实现的这个模块，与之前完成的
payment模块之间的耦合度是否合理？有没有发现潜在的接口问题？” 引导AI切换视角，从实现者变回设计评审者。
陷阱四：对生成代码的测试覆盖不足AI生成的代码，尤其是业务逻辑复杂的部分，可能隐藏着边界条件错误。
- 应对策略：将“编写测试用例”作为循环中的一个强制性步骤。不仅可以要求AI为你生成测试，更可以要求它“针对这个函数，列出所有你认为应该测试的边界情况和异常场景”。然后你再让它或你自己来实现这些测试。测试驱动开发（TDD）的思想与循环工程结合，能极大提升代码可靠性。
5. 未来展望：循环工程将把我们带向何方？
循环工程不仅仅是一种使用AI工具的技巧，它很可能预示着软件开发范式的又一次演进。当AI智能体不仅能理解单次指令，还能管理长期任务状态、记忆复杂上下文、主动规划并执行子任务时，“编程”的定义可能会被拓宽。
我们可能不再需要亲手编写每一行实现细节的代码，而是将更多精力投入到更高层级的活动中：定义问题领域、制定系统约束、设计组件交互、设定验收标准、以及进行高层的逻辑与安全审计。软件开发将变得更像“系统工程”或“产品设计”，而AI则是将这些高层设计自动转化为可靠代码的超级执行引擎。
当然，这并不意味着程序员会被取代。相反，对程序员的要求会更高。你需要有更扎实的架构能力、更敏锐的业务洞察力、更严谨的审查和测试思维，以及最重要的——驾驭AI这个强大伙伴的能力。你不会再被简单的语法错误或繁琐的样板代码所困，但你需要成为更好的规划者、沟通者和质量守门员。
“提示词工程已死”或许有些绝对，但它作为一种主导范式的时代确实正在过去。未来属于那些懂得如何与AI建立有效、深度、持续协作的开发者。循环工程，就是开启这扇大门的钥匙。它不是关于如何一次性问对问题，而是关于如何与一个强大的智能体共同成长，一起构建复杂而美妙的数字世界。从这个角度看，称王的不只是某种工程方法，更是人机协同这一不可阻挡的未来趋势本身。
