AI自主编程循环实践：从零构建完整后端项目的Loop Engineering工作流

1. 项目概述：当AI学会“自我驱动”编程

最近在折腾AI编程工具链的朋友，可能都听过一个词叫“Loop Engineering”，或者更直白点，叫“AI自主编程循环”。这玩意儿听起来有点科幻，但核心思想其实很朴素：我们能不能给AI一个高层次的、像产品经理提需求那样的指令，然后让它自己拆解任务、写代码、调试、测试，最终交付一个能跑起来的完整项目？而不是像传统Copilot那样，我们写一行，它补一行。

我花了近一个月的时间，深入实践了基于/goal命令的Loop Engineering工作流。这个/goal不是什么新框架的专属命令，而是一种工作模式的抽象。你可以把它理解为向AI下达的“终极任务书”。比如，你不再说“帮我写一个登录函数”，而是说“/goal: 构建一个具备用户注册、JWT登录、权限管理的后端API服务，使用FastAPI和SQLAlchemy，并包含完整的单元测试”。然后，你就能端着咖啡，看着AI像一位不知疲倦的全栈工程师，从搭建项目骨架、设计数据库模型、编写业务逻辑，到处理边界条件和编写测试用例，一步步把项目构建出来。

这不仅仅是效率的提升，更是一种范式的转变。它把开发者从繁琐的、重复性的代码搬运工角色中解放出来，让我们能更专注于架构设计、核心算法和产品逻辑这些真正创造价值的部分。当然，这个过程绝非一帆风顺，AI会“犯傻”、会陷入逻辑循环、会写出看似合理实则漏洞百出的代码。但正是通过解决这些问题，我们才能摸清AI编程的边界，建立高效的人机协作模式。接下来，我就把自己趟过的路、踩过的坑，以及最终跑通的实战经验，毫无保留地分享给你。

2. Loop Engineering 核心思路与工具选型

2.1 什么是真正的“循环工程”？

很多人把Loop Engineering简单理解为“让AI反复执行某个任务”，这其实只对了一半。真正的核心在于“感知-决策-执行-验证”的闭环。AI需要像人类工程师一样，能够理解当前代码库的状态（感知），根据最终目标制定或调整下一步计划（决策），执行具体的代码修改（执行），然后运行测试或检查来验证修改是否正确（验证）。如果验证失败，它需要分析原因，重新决策和执行，直到成功。

/goal命令就是这个循环的启动器。它不是一个具体的函数调用，而是一个包含以下要素的提示词（Prompt）工程范式：

1. 终极目标：清晰、无歧义的最终交付物描述。
2. 约束条件：技术栈、代码规范、性能要求、安全要求等。
3. 成功标准：如何判定项目已完成？是测试全部通过，还是特定功能可用？

2.2 主流工具链深度对比

目前市面上并没有一个官方的、名为“Loop Engineering”的框架。实践它，需要组合使用现有的AI编程工具。我主要深度测试了三类方案：

方案一：纯ChatGPT + 手动上下文管理这是最原始但也最灵活的方式。你需要在同一个聊天会话中，持续给ChatGPT（特别是GPT-4）提供完整的上下文，包括项目文件树、当前文件内容、错误信息等。

• 优点：零成本入门，无需额外工具，对项目结构无要求。
• 缺点：上下文长度限制是致命伤。大型项目很快会耗尽token，导致AI“失忆”。手动复制粘贴文件内容效率极低，且极易出错。无法自动化执行验证步骤（如运行测试）。
• 适用场景：小型脚本、单个文件的修改或学习概念验证。

方案二：Cursor + 自定义工作流Cursor编辑器内置了强大的AI能力，并支持.cursorrules文件来定义AI行为。你可以通过精心设计的Prompt，让Cursor在编辑单个文件时具备一定的“循环”意识，比如“请先分析现有代码，然后实现XX功能，最后检查语法”。

• 优点：与编辑器深度集成，操作流畅。可以利用项目级的上下文（虽然也有限制）。对于文件内的迭代修改非常高效。
• 缺点：本质上仍是文件粒度的操作，跨文件的复杂任务协调能力弱。自动化验证依然需要手动触发。
• 适用场景：中小型项目的特性开发、代码重构和bug修复。

方案三：Claude + 自制智能体（Agent）工作流（我最终采用的方案）这是目前实现完整Loop Engineering体验最强大的方式。核心是利用Claude API（特别是Claude 3.5 Sonnet）强大的长上下文和推理能力，搭配一个自制的中控调度程序。这个程序负责：

1. 管理项目文件系统（读取、写入）。
2. 在需要时，将相关文件内容组织成Prompt提供给Claude。
3. 执行Claude返回的Shell命令（如运行测试、安装依赖）。
4. 解析命令执行结果，并将其作为新一轮的上下文反馈给Claude。

• 优点：真正实现了自动化闭环。AI可以自主运行命令、看到结果、并基于结果进行下一步操作。不受单一文件限制，具备全局视角。
• 缺点：实现门槛较高，需要一定的脚本编程能力。需要谨慎处理AI生成的Shell命令，存在安全风险。API调用有成本。
• 适用场景：中大型项目的从零到一构建、复杂的多模块开发任务。

注意：安全第一。在任何允许AI执行Shell命令的方案中，必须在沙箱环境（如Docker容器、虚拟机）中进行，切勿在生产环境或存有敏感数据的机器上直接运行。我的所有实验均在隔离的Docker容器内完成。

我选择方案三，因为它最贴近“AI自主工程师”的愿景。下面的实战解析也将基于这个方案展开。你可以根据自身情况选择起点，但理解了这个最复杂的方案，其他方案便触类旁通。

3./goal命令的实战设计与拆解

3.1 一个高信息密度的/goal命令模板

直接给AI丢一句“做个博客系统”是注定会失败的。一个有效的/goal命令，本身就是一个微型的产品需求文档。下面是我经过多次迭代总结出的模板：

/golang: 项目目标：构建一个[项目类型，如：个人博客后端API]。 技术栈要求： - 后端框架：[例如：Python FastAPI] - 数据库：[例如：PostgreSQL with SQLAlchemy ORM] - 身份验证：[例如：JWT] - 测试框架：[例如：pytest] 核心功能清单： 1. 用户管理：注册、登录（JWT）、个人信息查看。 2. 文章管理：创建、编辑、删除、发布、列表查询（分页）、详情查看。文章支持Markdown格式。 3. 评论功能：对文章发表评论（需登录）、评论列表。 交付标准： - 项目结构清晰，符合[例如：PEP 8 / 行业通用]规范。 - 所有API接口均有对应的Pydantic模型进行请求/响应验证。 - 数据库操作使用异步Session（async_session）。 - 为所有核心业务逻辑编写单元测试，测试覆盖率不低于80%。 - 提供详细的`README.md`，包含项目设置步骤和API接口文档。 请从初始化项目开始，逐步完成以上目标。在每一步，请先说明你的计划，再执行具体操作。如果遇到错误，请分析错误信息并尝试修复。

这个模板包含了目标定义、技术约束、功能清单、质量标准和过程指令。它让AI从一开始就明确了“做什么”、“用什么做”、“做到什么程度”以及“怎么去做”。

3.2 智能体中控程序的核心逻辑

要让Claude理解并执行这个/goal，我们需要一个Python脚本作为“大脑”和“手脚”。这个脚本的核心循环如下：

# 伪代码，展示核心逻辑 import os import subprocess from anthropic import Anthropic class CodingAgent: def __init__(self, api_key, project_path): self.client = Anthropic(api_key=api_key) self.project_path = project_path self.conversation_history = [] # 保存对话历史，维持上下文 def run_goal(self, goal_prompt): system_prompt = """你是一个经验丰富的全栈软件工程师。你将通过在一个现有项目目录中工作来完成用户的目标。你可以执行命令来查看文件、运行测试、安装依赖等。请严格按照以下步骤工作： 1. 首先，评估当前项目状态（通过`ls`, `find`等命令）。 2. 然后，制定一个清晰的、逐步的计划来实现目标。 3. 对于每一步，先解释你要做什么，然后执行必要的命令或创建/编辑文件。 4. 如果命令执行失败，分析错误并调整你的方法。 5. 持续进行，直到目标达成或无法继续。""" full_prompt = f"项目根目录：{self.project_path}\n\n用户目标：{goal_prompt}" self.conversation_history.append({"role": "user", "content": full_prompt}) while not self.is_goal_achieved(): # 需要自定义判断目标是否达成的逻辑 # 1. 调用Claude API，获取AI的回复（包含思考和命令） response = self.get_ai_response(system_prompt, self.conversation_history) # 2. 解析AI回复：分离出“思考部分”和“要执行的命令部分” thought, commands_to_run = self.parse_response(response) print(f"\n[AI思考]: {thought}") # 3. 安全地执行AI返回的命令（在沙箱中） for cmd in commands_to_run: if self.is_safe_command(cmd): # 安全检查！ result = self.execute_command(cmd) print(f"[执行]: {cmd}\n[结果]: {result}") # 将结果作为上下文，加入到下一轮对话中 self.conversation_history.append({"role": "user", "content": f"命令 `{cmd}` 执行结果：\n{result}"}) else: print(f"[拒绝执行危险命令]: {cmd}") # 4. 将AI的回复也加入历史 self.conversation_history.append({"role": "assistant", "content": response})

这个循环的关键在于：AI的每次输出，不仅包含代码，更包含它的“思考过程”和“行动意图”（即Shell命令）。中控程序负责执行这些命令，并将结果反馈回去，从而形成闭环。

4. 实战全流程解析：从零构建一个博客后端

现在，让我们看一个完整的、缩略版的实战过程。假设我们在一个空的/tmp/blog_project目录下，启动智能体并输入上述的/goal命令。

4.1 第一阶段：项目初始化与骨架搭建

AI思考与行动：

1. 感知：AI首先运行ls -la，发现是空目录。
2. 决策：决定初始化一个Python项目，创建虚拟环境，安装基础依赖。
3. 执行：

   python -m venv venv source venv/bin/activate pip install fastapi sqlalchemy pydantic pytest httpx

4. 验证：运行pip list确认安装成功。然后创建基础项目结构。

   mkdir -p app/{api, models, schemas, crud, tests} touch app/__init__.py app/main.py app/database.py touch requirements.txt

   并将当前依赖写入requirements.txt。

实操心得1：依赖管理的坑。初期我让AI直接pip install，它有时会安装不兼容的版本组合。后来我在/goal中明确加入了“请使用pip freeze > requirements.txt来锁定版本”的指令，并在项目开始时提供一个基础的requirements.txt模板，大大提高了环境一致性。

4.2 第二阶段：数据库模型与核心配置

AI思考与行动：

1. 感知：AI读取已创建的app/database.py和app/main.py文件内容（中控程序会将这些文件内容在Prompt中提供）。
2. 决策：根据功能清单，需要User、Article、Comment三个模型。决定使用SQLAlchemy的Declarative Base，并配置异步引擎和会话。
3. 执行：编写app/models.py，定义三个模型及其关系（一对多等）。编写app/database.py，配置数据库连接URL（从环境变量读取），创建异步引擎和会话工厂。
4. 验证：AI会尝试运行一个简单的Python脚本来测试数据库连接是否正常，或者直接导入模型检查是否有语法错误。

# AI生成的 app/models.py 可能片段 from sqlalchemy import Column, Integer, String, Text, DateTime, ForeignKey from sqlalchemy.orm import relationship from app.database import Base class User(Base): __tablename__ = "users" id = Column(Integer, primary_key=True, index=True) username = Column(String(50), unique=True, index=True, nullable=False) email = Column(String(100), unique=True, index=True, nullable=False) hashed_password = Column(String(200), nullable=False) articles = relationship("Article", back_populates="author") comments = relationship("Comment", back_populates="author")

实操心得2：AI的“想当然”错误。AI在定义hashed_password字段长度时，最初可能随意写个String(100)。但如果你使用的是bcrypt，哈希后的密码长度是固定的60位。我需要在/goal的约束中明确指定：“密码哈希使用passlib[bcrypt]，数据库字段长度至少为60字符”。这提醒我们，对关键细节必须给出精确约束。

4.3 第三阶段：API路由与业务逻辑实现

AI思考与行动：

1. 感知：检查app/api目录和现有的模型、数据库配置。
2. 决策：按照功能模块划分路由：auth.py,articles.py,comments.py。每个路由文件对应相应的CRUD操作和Pydantic模型（在app/schemas中）。
3. 执行：
   • 创建app/schemas/user.py，定义UserCreate,UserLogin,UserResponse等Pydantic模型。
   • 创建app/crud/user.py，编写通过用户名查询用户、创建新用户的数据库操作函数。
   • 创建app/api/auth.py，实现/register和/login端点。在登录端点中，集成python-jose来生成JWT令牌。
   • 创建依赖项app/api/deps.py，编写一个从请求头提取并验证JWT令牌的依赖函数，用于保护需要认证的路由。
   • 类似地，完成文章和评论的CRUD操作、路由和模型。

# AI生成的 app/api/deps.py 关键片段 from fastapi import Depends, HTTPException, status from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials from jose import JWTError, jwt from app.crud.user import get_user_by_username async def get_current_user(credentials: HTTPAuthorizationCredentials = Depends(HTTPBearer())): token = credentials.credentials try: payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM]) username: str = payload.get("sub") if username is None: raise HTTPException(...) except JWTError: raise HTTPException(...) user = await get_user_by_username(username) if user is None: raise HTTPException(...) return user

4.4 第四阶段：测试、调试与收尾

这是Loop Engineering最能体现价值，也最容易出问题的阶段。

AI思考与行动：

1. 感知：AI运行pytest --collect-only来查看当前有哪些测试。
2. 决策：为每个核心路由和CRUD函数编写测试。需要创建测试数据库，使用pytest-asyncio处理异步测试。
3. 执行：
   • 创建tests/conftest.py，配置测试用的异步数据库引擎和会话夹具。
   • 编写tests/test_auth.py，测试用户注册、登录的成功和失败场景（如重复用户名、错误密码）。
   • 编写tests/test_articles.py，测试文章的创建、查询、更新、删除，并验证JWT认证保护是否生效。
4. 验证与循环：AI运行pytest。
   • 如果测试通过：AI继续完成README.md的编写，然后判断目标已达成，循环结束。
   • 如果测试失败：AI会收到pytest的错误输出。它会分析堆栈跟踪，定位到具体的失败测试和代码行，然后尝试修复。例如，如果测试显示“外键约束失败”，AI会去检查模型关系定义和数据库迁移顺序（如果使用了Alembic）。这个“运行-失败-分析-修复”的循环会一直进行，直到测试通过或AI无法解决（此时需要人工介入）。

5. 常见问题、陷阱与应对策略实录

在实际操作中，AI会犯各种令人啼笑皆非或抓狂的错误。下面是我整理的“避坑指南”。

5.1 问题一：AI陷入无限循环或无效操作

• 现象：AI反复执行同一个命令（如反复pip install同一个包），或者在不相关的文件上做微小修改，无法推进项目。
• 根因：AI的“决策”部分出现了逻辑混乱，或者它没有从命令执行结果中得到有效的反馈来更新它的计划。
• 解决方案：
  1. 增强系统提示词：在系统指令中明确强调“避免重复操作”、“如果某一步失败超过两次，请尝试完全不同的方法”。
  2. 人工干预：当检测到循环时，中控程序可以自动向对话历史插入一条强引导信息，如：“检测到重复操作。请重新评估当前项目状态，并列出剩余的三个最高优先级的任务。”
  3. 提供更结构化的上下文：在每一轮，不仅提供命令结果，还主动提供当前项目关键文件的摘要（如main.py的路由列表、models.py的模型清单），帮助AI刷新认知。

5.2 问题二：生成的代码存在隐蔽的逻辑缺陷或安全漏洞

• 现象：代码能跑，测试也能过，但存在业务逻辑问题。例如，在用户注册时没有检查邮箱格式，在删除文章时没有验证操作者是否是作者。
• 根因：AI基于模式匹配生成代码，对深层次的业务规则和安全边界理解不足。
• 解决方案：
  1. 在/goal中明确非功能性需求：不要只说“实现删除功能”。要说“实现删除文章功能，必须先验证当前登录用户是该文章的作者，否则返回403错误”。
  2. 编写针对性的验收测试：在/goal的“交付标准”里，加入具体的测试用例描述。例如，“必须包含测试：非作者用户尝试删除文章应收到403状态码”。AI在编写测试时，就会被迫考虑这个场景，从而在实现代码时也将其涵盖。
  3. 事后人工代码审查必不可少：Loop Engineering不是完全取代开发者，而是增强。最终生成的代码，尤其是核心业务逻辑和安全相关的部分，必须经过人工仔细审查。

5.3 问题三：依赖冲突与环境问题

• 现象：pip install失败，或者运行时出现ImportError、AttributeError（由于库版本不兼容）。
• 根因：AI对Python生态内复杂的版本依赖关系掌握不精确。
• 解决方案：
  1. 锁定基础环境：在项目开始前，提供一个requirements.txt或pyproject.toml的基线。在/goal中指令“在此基础上添加新依赖”。
  2. 指令AI使用兼容性模式：在系统提示词中加入“安装依赖时，优先选择广泛兼容的稳定版本，例如sqlalchemy<2.0如果项目是异步的，请注意其与asyncpg的版本匹配”。
  3. 赋予AI修复能力：当安装失败时，中控程序将详细的错误信息反馈给AI。训练有素的AI（如Claude 3.5）通常能看懂版本冲突信息，并给出降级或升级特定包的建议命令。

5.4 问题四：项目结构“跑偏”

• 现象：AI创建的文件结构混乱，或者采用了与团队规范不符的编码风格。
• 根因：/goal中的约束不够具体。
• 解决方案：
  1. 提供参考模板：在项目开始时，可以手动创建几个关键文件（如main.py、database.py）的雏形，并在其中展示你期望的导入风格、注释规范和项目布局。AI具有很强的模仿能力。
  2. 集成代码检查工具：在中控程序中加入一个步骤：在AI每次提交一批代码更改后，自动运行black（格式化）、isort（排序导入）和flake8（语法检查）。将检查结果反馈给AI，让它自行修正。这不仅能保证代码风格，还能让AI在过程中学习你的规范。

6. 效能评估与未来展望

经过多个项目的实践，我对这种工作流的效能有了直观感受：

• 效率提升：对于一个类似博客后端的标准CRUD项目，从零到具备基础API和测试，人工开发可能需要6-8小时。在AI辅助下，这个时间可以缩短到1-2小时，其中还包括了人工审查和微调的时间。效率提升主要体现在代码的初始生成速度和样板代码的编写上。
• 质量波动：AI生成的代码在语法正确性和基础模式上通常很好，但业务逻辑的严谨性需要把关。测试代码的生成是一个巨大亮点，它能覆盖很多开发者容易忽略的边缘情况。
• 最佳定位：目前，它不是取代，而是超级增强。它最适合：
  1. 项目启动阶段的“搭架子”。
  2. 实现标准化、模式固定的功能模块（如增删改查接口）。
  3. 编写单元测试和集成测试。
  4. 编写技术文档（如API文档、README）。

我个人最大的体会是，Loop Engineering的成功，五分靠AI能力，五分靠人的引导和设计。一个模糊的指令只会得到混乱的结果。而一个精心构思的/goal命令、一个稳健的中控程序、一套明确的项目规范，再加上开发者关键时刻的监督和纠偏，才能将AI的潜力真正转化为稳定可靠的生产力。这不再是简单的“问答”，而是升级为一种需要精心设计的“人机协同编程流程”。未来，随着AI代码能力的持续进化，以及专门为AI编程循环设计的开发工具（如更强大的智能体框架）出现，这种工作模式很可能从极客的玩具，变成每个开发者的标配。