六月初的一个凌晨，Claude Code 负责人 Boris Cherny 在 X 上发了一句话：“I don‘t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”
不到 24 小时，这条推文播放量接近 70 万次。
紧接着，前 An Anthropic 成员 Pietro Schirano 补了一刀：他不再手写 Codex 的 /goal，而是让 Codex 自己给自己写目标、再为每个子 Agent 各写一份。从头到尾，人类只负责在最开始说出意图。
评论区炸了。
有人感叹：我们好像进入了这样一个时代——我给 AI 一个目标，AI 把这个目标改得更好，然后我礼貌地假装自己一直是那个项目经理。
如果你还在为写一个完美的 System Prompt 绞尽脑汁，还在用“你是一个资深工程师”试图“哄”模型干活，那么很遗憾：你的开发范式可能已经落后了。
这不是危言耸听。Prompt 在 Agent 开发中的权重，已经从原来的 90% 降到了 30% 以下。它现在只是一个 API 调用的参数，不再是核心竞争力。
那剩下的 70% 是什么？是怎么给 Agent 设计“思考指令”——让它自己知道怎么想、怎么做、怎么判断做完没有。
这篇文章，我从一线工程实践出发，拆解为 AI Agent 设计思考指令的 4 个黄金法则。
目录
一、Agent 不需要“咒语”，需要“思考框架”
二、黄金法则一：给目标，不给步骤
三、黄金法则二：把“评估标准”写进指令
四、黄金法则三：分离“规划”与“执行”
五、黄金法则四：设计反馈闭环，而非单次指令
六、一个值得你思考的问题
一、Agent 不需要“咒语”，需要“思考框架”
先讲清楚一个本质变化。
2023 到 2024 年，提示词工程被捧成 AI 时代的硬技能。会写提示词，就好比握住了驾驭模型的关键。那时候大家研究的是：怎么问能让 GPT-3.5 不胡说八道，怎么用“Let‘s think step by step”哄着模型推理。
本质是模型能力不够，需要人类通过话术来“补”推理能力。
但今天不一样了。DeepSeek V3、Claude 4.5 Sonnet 这些模型的意图理解能力已经大幅提升。即使给出粗糙的 Prompt，模型也能大概率领会意图。以前需要几百字加少样本示例才能让 Agent 把会议纪要整理成 JSON，现在一句“转成标准 JSON，字段自行判断”结果基本可用。
模型智商提升了，Prompt 这根“拐杖”自然要换。
那换什么？
换成思考框架。
2026 年最顶级的 AI 使用者不再只是“下指令”，而是在“构建思考框架”。Prompt Engineering 2.0 的本质不是优化 wording，而是设计 Agent 的认知循环——感知、推理、规划、执行、反思、修正。
说白了：以前你教 AI 怎么做，现在你设计一套机制让 AI 自己知道怎么想。
二、黄金法则一：给目标，不给步骤
这是最反直觉的一条。
很多人的第一反应是：指令越详细，Agent 执行越准确。于是把各种约束、规则、Few-shot 示例全塞进 Prompt，指令长达几千 Token。结果呢？难以维护，还经常引发指令冲突。
问题出在哪？
你给的“步骤”限制了 Agent 的“判断” 。
Codex 的 /goal 功能给出一个很好的示范。官方反复强调一件事：目标要写到 Codex 能判断“做完没有”，要避免“优化一下”“完善一下”这种虚词。
注意这个差异：传统 Prompt 给的是“执行路径”，/goal 给的是“完成标准”。
前者告诉 Agent 走哪条路。后者告诉 Agent 什么是终点，路你自己找。
实际效果如何？有开发者实测：给 Codex 一句高层目标，把 BACKLOG.md 里的 18 个功能全部交付，然后人就离开了。Agent 自己拆任务、并行执行、检查进度、迭代推进——人类全程不在场。
核心在于：目标驱动自主决策，步骤驱动机械执行。
对于 Agent 这种具备推理能力的系统，你应该给它“要什么”，而不是“怎么做”。怎么做是它的事。
观点句：给 Agent 指令，本质是定义“完成状态”，而不是“执行路径”。
三、黄金法则二：把“评估标准”写进指令
很多人写 Prompt 只写了一半——只告诉 Agent 要做什么，没告诉它“怎么做算做好了”。
这是一个致命的遗漏。
Codex 的 /goal 之所以能自转，是因为那段文字同时充当两样东西：起始指令，和“完成审计”。Codex 每跑完一轮，就回头对照目标问自己：还该做什么？是不是已经做完了？
这就是评估标准内置在指令里。
没有评估标准的 Agent 会一直做下去——不是因为勤奋，是因为它不知道什么时候该停。
工程上怎么落地？
把“完成条件”显式写进 System Prompt。不是“生成一份报告”，而是“生成一份报告，包含以下三个部分，每部分不少于 200 字，引用至少 5 个数据源，格式为 Markdown”。每个条件都应该是可验证的。
更进一步，可以引入 Reflexion 模式——把执行者、评估者和反思者拆成不同角色。AI 做错了，不只是改个答案，而是用语言把错误总结成经验写进记忆。下次遇到类似情况，它能想起来“上次我在这栽过”。
这套机制让 Agent 拥有了某种“工作流意识”——它知道自己处在一个持续运转的过程里，而不是回答完一个问题就下班。
观点句：没有“完成标准”的指令，本质上是在教 Agent 无限循环。
四、黄金法则三：分离“规划”与“执行”
这是很多 Agent 系统翻车的根源。
大模型擅长制定计划，但长链条执行中容易“迷路”。一个典型场景：供应链 Agent 规划“先查 A 数据库，再查 B 系统”，但 A 数据库返回了含特殊字符的数据，模型生成查询 SQL 时失败，然后陷入死循环。
问题出在哪？
同一个模型既当规划者又当执行者，缺少交叉验证。
正确的做法是：将“制造者”与“检查者”分离。
在指令设计层面，这意味着两件事：
第一，规划阶段和执行阶段使用不同的 Prompt。规划阶段要求 Agent 只输出方案、不写代码，在“只读模式”下分析、起草计划。执行阶段才允许动手。
第二，为“检查者”角色单独设计指令。这个角色的任务是验证执行者的产出——是否符合规划、是否满足约束、是否有遗漏。验证不通过就触发回退。
GitHub 的 AI 团队推崇的规范驱动开发就是这个逻辑：规范成为共享的事实来源，在编写任何代码之前先完善规范。先把计划定死，再让 Agent 执行，而不是边想边干。
本质上是把“思考”和“行动”从时序上强制分离，避免 Agent 在思考不充分的情况下贸然行动。
五、黄金法则四：设计反馈闭环，而非单次指令
这是从 Prompt Engineering 到 Loop Engineering 的核心跨越。
Loop Engineering 的核心主张直接到近乎粗暴：别再手动写 prompt 了，设计一个系统来替你写。你的角色从“每次问一句”变成“设计一个能一直问下去的循环”。
一个工业级的 Loop 系统，需要五个要素：明确的目标、上下文管理、可调用的工具、对产出的评估、判断何时停止的标准。五者组合起来，Agent 就不再是“接收指令、输出结果”的单次调用，而是形成自我迭代、自我修正的闭环。
在指令设计层面，这意味着什么？
你的 Prompt 不再是“一次性指令”，而是“循环体的初始化参数” 。
具体来说：
目标定义要支持“递归”——Agent 完成一轮后能根据结果重新定义子目标
上下文要跨会话持久化——进度、试过的方案、中间产出全部落在外部系统，解决“金鱼记忆”问题
评估结果要作为下一轮指令的输入——形成“执行→评估→调整指令→再执行”的闭环
ReAct 模式提供了一个很好的参考框架：思考（Thought）→ 行动（Action）→ 观察（Observation），循环往复。每一步的观察结果都成为下一步思考的输入。
这套机制比端到端生成靠谱得多——至少给了 Agent 一个自我修正的节拍器。
观点句：Prompt 2.0 的核心不是写更好的指令，而是设计一个让指令不断自我优化的系统。
六、一个值得你思考的问题
说几个 observable 的事实：
第一，Prompt 的权重已经从 90% 降到 30% 以下。
第二，Boris Cherny 说他的工作是写 Loop 而不是写 Prompt。
第三，Addy Osmani 已经正式把 Loop Engineering 定义为“Replacing yourself as the person who prompts the agent”。
第四，有人已经用这套方法跑了近 3000 个 Agent 在生产环境。
这些事实指向同一个方向：为 Agent 设计“思考指令”的能力，正在取代“写 Prompt”的能力，成为新的核心技能。
这不是“提示词技巧”的升级版。这是从“怎么问”到“怎么设计认知系统”的范式转移。
我见过太多团队还在用 2023 年的方法做 2026 年的 Agent——堆 Prompt、调参数、靠运气。结果就是系统不稳定、不可控、不可扩展。
而真正跑通了的团队，已经在设计目标定义规范、评估标准体系、规划-执行分离机制、反馈闭环架构。
这两种做法的差距，不是“写得更好”能弥补的。
最后留一个问题给你：
你现在的 Agent 系统，有没有内置的“完成条件判断”和“执行结果反馈闭环”？如果没有，你觉得它能稳定跑多久？
欢迎在评论区聊聊你的实践和困惑。
