别再只写提示词了：你该设计 AI 循环
这是一篇关于 AI 工作流的中文改写：真正的能力不在一次提示词，而在目标、上下文、执行、反馈与评估组成的循环。
本文为中文改写与评论，原文作者 Aftab，原文发布于 AI Advances，时间为 2026 年 6 月 9 日，原文链接：You Shouldn’t Be Prompting AI Anymore. You Should Be Designing Loops.。本文保留原文核心观点，并结合中文读者的 AI 工作流实践做了重新组织。
AI 工作的关键正在从“写一个更聪明的提示词”，转向“设计一个会持续运行、反馈和改进的系统”。
过去两年，很多人学习 AI 的方式很直接：找一个模型，写一段提示词，把上下文塞进去，然后等结果。提示词越清楚，输出越好；上下文越完整，错误越少。于是“会不会写 prompt”变成了一种新技能。
但到 2026 年，这个阶段正在过去。Claude Code、Codex、OpenClaw 以及类似的 agent 系统已经不只是回答问题。它们可以读代码、调用工具、运行测试、写文件、提交修改、保留状态，甚至连续工作很长时间。瓶颈不再只是“这一句话怎么问”，而是“我能不能设计一个系统，让 agent 知道下一步该做什么”。
提示词只是入口，不是系统
提示词仍然重要，但它更像一次启动指令。你告诉模型现在要做什么，它根据当前上下文给出结果。问题是，大多数真实工作并不是一次性任务。
写代码不是只生成一个函数，而是理解需求、修改实现、运行测试、修复失败、检查边界情况、写说明、发 PR。做研究也不是只问一个问题，而是找到资料、交叉验证、整理证据、生成结构、补充遗漏、更新结论。
如果每一步都靠人手动发 prompt，人就成了循环的发动机。agent 只是循环里的一个工具。真正的变化发生在你把这个循环交给系统之后。
什么是 AI 循环
这里说的循环，不是代码里的 for 循环，而是一套完整的工作机制。一个好的 AI 循环通常包含这些环节：
| 环节 | 作用 |
|---|---|
| 触发条件 | 系统知道什么时候该开始工作，例如每天早上、CI 失败、客户发来请求，或某个 issue 被创建。 |
| 上下文注入 | 循环自动收集必要信息，例如最近提交、失败日志、项目规范、用户历史、相关文档。 |
| agent 执行 | 模型调用工具完成任务，可能包括读写文件、搜索资料、运行命令、生成报告。 |
| 验证与评估 | 系统检查结果是否合格，例如测试是否通过、格式是否正确、事实是否有来源、指标是否达标。 |
| 状态与记忆 | 记录这次做了什么、哪里失败、哪些结论要保留，下次运行时不从零开始。 |
| 后续动作 | 如果成功，就打开 PR、更新任务、发送邮件；如果失败，就重试、降级或交给人处理。 |
这就是“设计循环”的意思：不是替每一步写一个 prompt，而是设计一个能反复处理某一类工作的机器。
为什么循环比提示词更重要
第一个原因是可复用。一个好提示词解决一次任务，一个好循环解决一类任务。比如你每天都要检查产品反馈、整理竞品动态、生成日报、修复测试失败，那就不该每天从零开始问模型。你应该把输入、上下文、输出格式和验收标准固定下来。
第二个原因是可验证。软件开发特别适合 agent，因为代码能编译、测试、运行。结果好不好，不完全靠人感觉判断。只要你能给系统一个明确的检查点，agent 就可以反复尝试，直到通过，或者知道自己需要升级给人类。
第三个原因是可扩展。一个人手动 prompt，只能串行工作。一个循环可以并行创建多个工作分支：一个 agent 分析问题，一个 agent 写修复，一个 agent 做 review，一个 connector 负责更新工单和通知团队。人不再处理每个动作，而是设计边界、标准和升级路径。
OpenClaw 给行业上的一课
原文用 OpenClaw 作为重要例子。很多人把它理解成“能操作电脑的 Claude”，但更准确地说，OpenClaw 展示的是一套 agentic AI 的参考架构：技能、通道、记忆、工具调用、状态管理、安全边界，以及不断执行的 agent 循环。
其中最值得中文读者注意的，是它对“记忆”和“技能”的处理。技能不是临时提示词，而是可复用的过程说明；记忆也不是无限塞进上下文窗口，而是把重要事实沉淀到持久文件里。这样系统在下一轮运行时能接着做，而不是每次都像失忆一样重新理解世界。
这也是为什么很多新一代 agent 平台都在强调 skills、state files、connectors、sub-agents。它们不是装饰功能，而是循环能够长期运转的基础设施。
循环不是放手不管
一个常见误解是：既然 agent 能自己跑，人是不是就不重要了？恰恰相反。循环设计对人的要求更高。
你必须知道什么才算“好结果”。你必须知道哪些失败可以自动重试，哪些失败必须停下来。你还要理解领域里的隐含标准：代码质量、客户语气、事实可靠性、合规边界、品牌风格。你不了解的工作，不能指望通过一个循环 magically 变好。
糟糕的提示词只会生成一次糟糕结果；糟糕的循环会把错误放大。它可能在你睡觉时消耗大量 token，修改错误文件，提交看似合理但实际危险的 PR，或者把错误信息同步到多个系统。循环带来杠杆，也带来放大器。
从个人使用到团队流程
对个人开发者来说，下一阶段的技能不是背更多 prompt 模板，而是学会把任务拆成可验证步骤。例如：
- 每天自动读取失败的测试和最新 issue。
- 让 agent 为每个值得处理的问题创建隔离工作区。
- 修改代码后自动运行测试和 lint。
- 把失败原因写入状态文件，下一轮继续处理。
- 只有当不确定、风险高或测试无法覆盖时，才交给人。
对团队来说，变化更大。过去的生产力问题是“谁来写代码”；现在越来越多时候是“谁能定义正确的问题，谁能判断结果是否正确”。一个优秀工程师设计的循环，可能把自己的判断力扩展到十几个 agent；但一个不了解业务的人设计的循环，也会用同样的速度制造混乱。
Prompt Engineering 没死，只是位置变了
这并不是说 prompt engineering 没用了。提示词仍然是循环里的核心部件。只是它不再是全部。
过去我们问：“我该怎么写这段提示词，让模型给我最好的答案？”
现在更好的问题是：“这个任务是否会重复？它需要哪些输入？结果怎么验证？失败时怎么办？哪些状态要保存？什么时候交给人？”
提示词是指令，循环是操作系统。真正的 AI 工作流，会把提示词、工具、记忆、评估器和交付动作串起来。
你可以怎样开始
如果你现在还没有自己的 AI 循环，可以从一个很小的重复任务开始，不要一上来做全自动系统。
- 选一个你每周至少做三次的任务。
- 写清楚合格输出长什么样，最好有例子。
- 把输入来源固定下来，例如邮件、表格、GitHub issue、日志或网页。
- 设计一个检查清单，让 agent 自查，也让你复查。
- 记录每次失败原因，把它变成下一次的规则或记忆。
- 等流程稳定后，再接入自动发布、通知或提交动作。
这也是我为什么一直关注 Dobby 这类智能体平台：它们的价值不只是提供一个更大的聊天框，而是把目标、工具、记忆、反馈和交付组织成可复用的工作循环。
结语
2024 年和 2025 年，AI 使用者之间的差距，常常来自谁更会写提示词。到了 2026 年，新的差距会来自谁更会设计循环。
你不只是让 AI 回答一个问题。你是在设计一套机制，让 AI 找到工作、理解上下文、执行任务、验证结果、保存经验，并在下一次做得更好。
这就是从“提示 AI”到“设计 AI 工作流”的转变。
