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_days30。但这是一个会修改数据的操作用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_atutcnow()最后返回被归档的任务ID列表。我现在生成这个函数的第一版代码吗”我“生成吧。注意查询条件要同时满足status ‘completed‘和updated_at cutoff_date。另外为了防止归档正在进行中的任务再加一个条件status ! ‘in_progress‘作为安全护栏。更新后请同时生成对应的Pydantic响应模型BulkArchiveResponse包含archived_count和task_ids字段。”AI生成代码后我逐行审查。我发现它生成的查询中cutoff_date的计算用的是datetime.utcnow() - timedelta(daysolder_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建立有效、深度、持续协作的开发者。循环工程就是开启这扇大门的钥匙。它不是关于如何一次性问对问题而是关于如何与一个强大的智能体共同成长一起构建复杂而美妙的数字世界。从这个角度看称王的不只是某种工程方法更是人机协同这一不可阻挡的未来趋势本身。 从提示词工程到循环工程：AI编程协作新范式实战解析
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_days30。但这是一个会修改数据的操作用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_atutcnow()最后返回被归档的任务ID列表。我现在生成这个函数的第一版代码吗”我“生成吧。注意查询条件要同时满足status ‘completed‘和updated_at cutoff_date。另外为了防止归档正在进行中的任务再加一个条件status ! ‘in_progress‘作为安全护栏。更新后请同时生成对应的Pydantic响应模型BulkArchiveResponse包含archived_count和task_ids字段。”AI生成代码后我逐行审查。我发现它生成的查询中cutoff_date的计算用的是datetime.utcnow() - timedelta(daysolder_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建立有效、深度、持续协作的开发者。循环工程就是开启这扇大门的钥匙。它不是关于如何一次性问对问题而是关于如何与一个强大的智能体共同成长一起构建复杂而美妙的数字世界。从这个角度看称王的不只是某种工程方法更是人机协同这一不可阻挡的未来趋势本身。