提示工程与循环工程：开发者指南

对许多开发者来说，AI工作流程大致是这样的：编写提示词，获取响应，复制有用的部分，然后继续下一项任务。

这种方式涵盖了令人意想不到的广泛任务，从总结文档到起草电子邮件，再到解释一段代码。

但当任务涉及多个步骤、外部数据或依赖于模型刚返回结果而做出的决策时，这种工作流程就开始失效了。你最终不得不手动重新提示、手工修补输出，并承担那些本应由系统完成的工作。

到了这个节点，单一提示词不再是合适的工具，设计一个运行多个提示词的系统才成为真正的工作重点。

有两个术语用来描述这两种工作模式。

1. 提示词工程是指你如何与模型进行一次对话：你所使用的措辞、结构和示例，以获取有用的回应。

2. 循环工程是指设计一个能够反复与模型交互、评估结果并决定下一步操作而无需人工介入的系统的实践。

本指南涵盖这两种方式。你将了解到哪些情况下精心设计的提示词确实足够了，哪些情况下采用循环是更佳选择，以及如何在不使其过度复杂的前提下着手构建一个循环。提示词工程并不会在循环中消失，而是成为一切运行的基础。

目录

• 提示词工程与循环工程详解

• AI工作流程的演变

• 如何选择正确的方法

• 循环工程的真实成本与风险

• 提示词工程与循环工程：三个现实案例

• 如何着手构建你的第一个循环

• 最后的思考

提示词工程与循环工程详解

提示词工程是指你如何与模型进行一次对话。措辞、结构、包含的示例——所有这些都决定了返回结果的质量。

一个精心设计的提示词可以极大地改变模型生成的内容，掌握这项技能仍然是一项真正有用的能力。这就是大多数人在谈论开放循环时所提到的：一种单次交互，由人决定每次响应后的下一步操作。

循环工程则在这一对话基础上更进一步。不再是一次交互，而是设计一个系统，能够多次与模型对话、检查结果并决定后续行动。

这个循环中的每一步都可能涉及不同的提示词、工具调用、API请求或三者的组合，由系统自行决定下一步操作，而非等待你的介入。这就是闭循环在实践中的表现。

但需要再次强调的是，当你构建循环时，提示词工程并不会消失。循环中的每一次模型调用仍然依赖于编写良好的提示词。循环是架构，而提示词是使循环中每一步正常运转的关键。大多数团队都是在他们的单提示词工作流程无法跟上工作需求时，才意识到这一点的。

AI工作流程的演变

早期的AI使用大多是事务性的。团队构建内部提示词库，尝试不同的措辞，并将精心调校的提示词本身视为一种交付物。其价值在于把措辞写对、合理组织上下文，并知道如何提问。

像CI失败分析、问题分类和文档更新这类任务，需要模型读取内容、做出决策、执行操作，并检查操作是否有效。如果使用单个提示词，每一步决策都交还给人类，这意味着在任何一个包含多个动态环节的工作流中，人类都会成为瓶颈。

这就是“开环”与“闭环”之间的区别：开环中，每一步都由人类决定下一步做什么；闭环中，系统自行完成这些决策。

GitHub的Agentic Workflows于2026年6月11日进入公开预览，它是展现闭环带来何种变化的最清晰的例证之一。

在智能体工作流出现之前，开发人员通常使用AI助手来发现CI失败，然后手动检查日志、对问题进行分诊，并推送修复。而借助GitHub Agentic Workflows，团队可以用纯Markdown文件定义自动化目标，让编码智能体在GitHub Actions中自主处理完整的操作序列。

早期采用者之一Carvana直接指出：以前需要数小时手动工程工作的任务，现在几分钟就能完成。Carvana工程与分析高级副总裁Alex Devkar将这描述为“将智能体扩展应用于大规模的真实工程工作”，包括跨越多个仓库的变更。

但并非所有任务都需要这种级别的机制，选择正确的方法与知道如何构建同样重要。

选择正确的方法

当任务有明确的输入，并且能产生人类可以立即使用的有用输出时，提示词就是正确的工具。回复支持工单、概括拉取请求描述、解释堆栈跟踪，这些都是单次交互就能产生价值的任务。为它们添加循环只会引入复杂性，却不会为结果增添任何有意义的内容。

当任务涉及多个步骤、每一步都依赖前一步的结果，或者每次手动执行的成本高于一次性构建系统时，循环就能发挥良好作用。整个仓库的问题分类、监控流水线并响应故障，或按计划从实时数据生成报告，这些都属于循环能迅速体现价值的问题。

一个实用的判断方法：如果你发现自己经常把一个提示词的输出复制粘贴到下一个提示词的输入中，那么这一系列操作就是一个等待被构建的循环。

大多数团队从提示词开始，随着相同任务的重复出现，逐步升级到循环。这种演进是正常的，早期没有必要过度设计。构建循环的最佳时机是，当工作流的手动版本开始比自动化版本更耗时耗力时。

循环工程的实际成本与风险

一个设计良好的循环能够处理需要人类花费数小时才能完成的工作，按计划运行，并标记任何需要注意的事项。这确实非常有用，但循环是软件系统，它们与投入生产但未经充分测试的任何其他软件系统一样，都承担着相同的风险。

以下正是循环带来真正价值的地方：

• 它们自主处理多步骤任务，无需人类在每个决策点介入。

• 它们按计划可靠运行，使重复性工作流保持一致且可复现。

• 它们扩展了原本需要成比例增加人力才能执行的工作量。

而以下则是循环引入风险的地方：

• 调试更加困难：一个单一的提示词只会向你展示一个输入和一个输出。一个跨越多个步骤和工具调用的循环则需要日志记录和追踪才能理解发生了什么。

• 错误会不断累积：第二步中的一个错误输出会成为第三步的输入，当循环结束时，你可能会得到一个看似合理但实际上已经悄悄出错的整体结果。

• 循环可能会陷入停滞：定义不佳的停止条件、模糊的成功标准或未处理的API故障可能导致循环无限运行，消耗令牌和时间却不产生任何有用的结果。

从一开始就应构建的护栏：

• 记录每一步，而不仅仅是最终输出。

• 在编写循环之前而不是之后定义成功与失败的条件。

• 对每次外部调用设置速率限制和最大重试次数。

• 对任何触及生产环境或影响真实用户的操作添加人工审查检查点。

将循环视为一个会做决策的cron任务，而不是一个自行运行的提示词。以下是跨三个真实工作流的具体表现。

提示词工程与循环工程：三个真实世界的示例

为了使一切具体化，这里有三个示例，展示仅提示词和基于循环的方法如何以不同方式处理相同的任务。

示例1：邮件摘要

每天早上，你打开三个客户收件箱，手动挑出看似重要的邮件，将其粘贴到模型中，然后等待摘要。摘要生成得足够快，但围绕它的所有操作却需要20分钟，而且无论你的提示词多么出色，这个比例都不会有太大改善。

围绕同一个提示词构建的循环会按计划获取新邮件，按发件人、主题行和关键词过滤，对每批邮件运行摘要提示词，标记任何标记为紧急的内容，并在你打开笔记本电脑之前直接将摘要发布到Slack。

模型所做的仍然是它一直做的工作。但如今，循环正在完成人类过去围绕它所做的一切。

示例2：PR审核

你团队中的一位开发人员在一个下午内打开了三个拉取请求。你将第一个diff粘贴到Claude中，得到一份可靠的审核回复，手动将评论复制到GitHub中，然后继续下一个。

到了第三个PR时，你正在复制粘贴之前已经写过十几次的相同类型的评论，标记相同类别的问题，并且所做的工作遵循着足够清晰的模式，不应再需要你在每一步都参与其中。

围绕该模式构建循环意味着，评审流程在拉取请求（PR）打开的那一刻便已启动。该循环负责拉取差异（diff），从代码库中检索相关上下文，执行评审提示词，并直接将评论发布到PR上，无需人工复制任何内容。任何涉及身份验证、支付或系统敏感部分的内容，都会在循环继续之前被标记为需要强制人工评审。

玛莎百货（Marks & Spencer）是GitHub Agentic Workflows的早期采用者之一，他们在整个仓库目录中构建了这种可复用的工作流。该工作流覆盖了漏洞修复、依赖维护，以及安全、质量和交付流水线中的日常变更评审。

示例3：内容运营

一个内容团队需要每周发布三篇技术文章。撰稿人提示模型生成初稿，手动编辑，再运行一个单独的提示词获取SEO建议，进行修改后发送给编辑。每篇文章都要耗费一整天反复沟通，而其中一半时间花在了每次都必须遵循相同检查清单的步骤上。

针对该流程构建的循环会从实时来源抓取信息来研究主题，生成初稿，然后将其传递给第二个模型调用，由该调用根据既定的风格指南对初稿进行评判。随后，模型根据反馈进行修改，针对目标关键词执行SEO检查，并在发布前将最终版本排队等待人工审批。撰稿人仍然参与其中负责需要判断的决策，而循环则处理其余所有工作。

如果上述三个示例中有任何一个与你目前正在手动执行的工作相似，那么构建你的第一个循环就是合理的下一步。

如何开始构建你的第一个循环

大多数团队犯的错误是试图一次性自动化太多内容。更好的起点是为单个任务创建一个循环，并在编写第一行代码之前明确定义"完成"的标准是什么。

• 识别重复性的多步骤任务：寻找你或你的团队定期手动完成的工作。如果步骤是可预测的，且输出遵循某种模式，那么它就是循环的候选对象。

• 预先定义成功与失败的标准：好的输出是什么样子的？什么情况应该导致循环停止、重试，或升级给人工处理？在构建之前回答这些问题，可以在之后节省大量调试时间。

• 设计序列：规划出每一步：循环需要获取什么，每一步运行什么提示词，在继续前进之前需要检查什么，以及什么会触发下一个操作。

• 逐步添加工具：先从单独的模型开始，然后一次添加一个API调用、数据库读取或代码执行。每增加一个都是一个新故障点，逐步引入可以让调试变得可控。

• 从一开始就构建安全性：记录每一步。对每次外部调用设置速率限制和最大重试次数。为任何写入生产环境或影响真实用户的操作添加人工审核检查点。

• 迭代与监控：先在小型数据集上运行循环。在让其无人监督运行之前，手动检查输出。将第一个版本视为草稿，而不是最终系统。

每一步内部的提示词仍然很重要。一个提示词编写不佳的循环，会在规模化运行时产生不可靠的输出，这比单个错误响应更难调试。好的提示词工程和好的循环设计不是两种独立的技能，而是相互依存的关系。

为了将这些步骤付诸实践，这里有一个用Python和Mistral API构建的简单PR审查循环，它严格遵循这一模式。完整的代码可在GitHub上获取。

审查提示

一切始于精心编写的系统提示词。这就是提示工程在循环中仍然至关重要的原因。一个薄弱的提示词会导致大规模的低质量审查。

SYSTEM_PROMPT = """You are an experienced code reviewer. You will be given a git diff. Review it for bugs, security issues, unclear code, and missed edge cases. Only comment on things that matter - skip style nitpicks and praise. If the diff looks fine, return an empty comments list."""

循环结构

该循环有四个步骤：加载差异、检查敏感区域、调用模型并发布评论。

def review(diff_text: str) -> None:
    if not diff_text.strip():
        print("Empty diff - nothing to review.")
        return

    sensitive_reasons = find_sensitive_matches(diff_text)
    if sensitive_reasons:
        flag_for_human_review(sensitive_reasons)
        return

    client = Mistral(api_key=os.environ.get("MISTRAL_API_KEY"))
    comments = get_ai_review(client, diff_text)
    post_comments(comments)

如果diff触及敏感区域，循环不会调用模型。它会停止，将其标记为人工审查，然后退出。此检查在任何API调用之前运行。

实践中的护栏

敏感区域检查会扫描文件路径和已更改的行，查找像auth、login、password、token、payment和api_key这样的关键词。如果匹配到任何一个，循环就会短路：

SENSITIVE_PATH_KEYWORDS = [
    "auth", "login", "logout", "session", "password", "credential",
    "token", "jwt", "oauth", "payment", "billing", "stripe",
]

SENSITIVE_CONTENT_KEYWORDS = [
    "password", "secret", "api_key", "private_key",
    "authenticate", "authorize", "permission",
]

这意味着，如果diff涉及auth/login.py，循环在任何API调用之前就会停止。该标志会打印到控制台，由团队中的某人手动处理审查。

运行循环

我们可以针对包含一个带有故意SQL注入漏洞的get_user_by_name函数的diff来测试这个循环：

+def get_user_by_name(name):
+    query = "SELECT * FROM users WHERE name = '" + name + "'"
+    return db.execute(query)

针对此差异运行循环将产生以下输出：

[CRITICAL] app.py:13 - SQL injection vulnerability: The query is constructed 
using string concatenation with user-provided input (`name`). This allows 
an attacker to inject malicious SQL code. Use parameterized queries inhttps://cdn.hashnode.com/uploads/covers/629e46c5a6bfa05457952a41/26da1a9c-4180-4ae4-89d3-6574e119a0d9.pngstead.

[WARNING] app.py:14 - The function `get_user_by_name` does not handle the 
case where no user is found. It should return `None` or raise a specific 
exception to be consistent with `get_user`.

它捕获了两个真实问题，均附有具体的文件引用、行号、严重级别和可操作的建议。这个循环发现了人工审查者本会发现的问题，而无需任何人复制粘贴任何内容。

最终思考

提示工程和循环工程并非相互竞争的方法。每个循环都依赖于每个阶段良好的提示，而把其中一项做好会让另一项更有价值。

如果你的任务是一次性的或仍在摸索中，精心设计的提示就是合适的工具。如果相同的任务反复出现、涉及多个步骤，或需要系统根据自身输出采取行动，那么围绕它构建一个循环是值得的。

从一个任务开始，定义成功的标准，然后在此基础上构建。

📌 相关推荐

GraphRAG 是推理问题，而非数据库问题

2026/8/30

构建市场时光机：使用 Python 和 WebSocket 重放交易会话

2026/8/30

如何自行基准测试LLM推理：值得信赖的数字设计标准

2026/8/30