Prompt Engineering 从 Prompt 之前开始

很多人一听到 Prompt Engineering，首先想到的仍然是措辞、角色描述、XML 标签、Prompt 模板，或者特别详细的 System Instructions。一个很典型的开场可能是：

“You are a world-class senior software architect …”

过去几年，围绕 Prompt 逐渐形成了一套自己的“小学科”，有时甚至让人产生一种印象：一个普通 AI 回答和一个优秀 AI 回答之间，最关键的区别主要就在于是否找到了正确的语言公式。

这种理解并不完全错误。结构有帮助，示例有帮助，清晰的语言也有帮助。当前的 Model Guidance 仍然会描述具体的 Prompting 技巧。

但在我实际使用 Coding Agent 的工作里，这已经只是问题中相对较小的一部分。

来看一句完全可以理解的话：

给我做一个用户管理功能。

从语言上几乎挑不出什么毛病。这个任务很短，也很明确，而且没有不必要的术语。

但真正实现它所需要的信息，几乎全部缺失。

有哪些类型的用户？他们有哪些角色？谁可以创建用户？用户能不能修改自己的数据？有没有邀请流程？认证怎么做？哪些数据必须保存？重复 E-Mail 怎么处理？是否已经存在 Identity Provider？现有系统的哪些部分可以修改？遵循什么架构？哪些错误场景属于 Scope？哪些内容明确不属于这个任务？以及最后，我们到底用什么标准判断这个 Feature 已经正确实现？

在原来的任务前面加一句：

You are a world-class senior software architect.

并不会解决这些问题。

一个表达得很好但本身不清楚的任务，依然是不清楚的任务。 真正的 Engineering 因此并不是从“怎样把同一个任务说得更漂亮”开始，而是从识别那些尚未补齐的决策和信息开始。

为什么这篇文章必须接在前几篇之后

这个结论其实是前面几篇文章一步步推出来的。

第 4 篇讨论了 Context、Memory、Agent Files、Skills 和 Tools。我们把 Context 描述为当前模型处理时真正放在“桌面上”的内容。Memory、Agent Files、Skills 和项目文档都可以为这个 Context 提供信息，但它们承担的角色并不相同。尤其重要的是，我们区分了长期存在的项目知识和当前这个具体工作任务。

这已经直接带来一个关于 Prompt 的结论：一个实现 Prompt 不需要每次都重新解释整个 Repository 是怎么工作的。

如果项目里长期规定 Presentation 不能直接访问 Infrastructure，那就不应该每个 Ticket 都重新写一遍。如果某个测试策略长期有效，如果 Naming Rules 已经确定，如果 Layering 是强制约束，这些决策就应该有一个长期存在的位置。

简化来看：

Agent Files / Skills / Memory / 文档
=
长期工作知识

实现 Prompt
=
当前 Task 的具体任务说明

近期的一些实践报告也支持这种区分。Anthropic 将 Context Engineering 描述为持续选择“最相关的 Context”，而不是尽可能大的 Context，并建议 Agent 使用 Just-in-Time Retrieval。OpenAI 也在自己的 agent-first 软件项目中指出，一个巨大的、单体式的 AGENTS.md 会把当前 Task、代码和真正相关的文档挤出 Context；规则容易过时，而过多 Guidance 也会失去优先级。因此他们更倾向于让一个较短的 Agent 文件充当入口，引导模型访问更深层、版本化的 Repository 文档。

第 5 篇则讨论了另一个特点：Agent 会构造自己的解决路径。它读取文件、调用 Tools、评估观察结果，然后在已经被这些操作改变过的 Context 上继续做决定。因此，同一个任务并不保证得到完全相同的实现路径。

如果我们不打算把整个路径完全确定性地写死——而对 Agent 来说，这往往也失去了意义——那么至少要定义清楚：哪些决策仍然属于可接受范围。

第 6 篇又加入了下一层风险：一个看起来合理的路径，也可能建立在错误假设上。这个假设可能变成代码修改，被 commit，并在未来反过来成为 Repository 里的本地证据。这样，单个错误决策就可能进一步发展为 Drift。与此同时，我们也看到 Generation 和 Verification 是两个不同的任务。

因此，我们几乎不可避免地会走到 Requirements 这里。

我们写详细的实现 Prompt，并不是因为 Agent 需要尽可能多的文字，而是因为 Context 有限、Agent 拥有决策空间，而看起来合理的方案仍然可能是错的。

所以，第一个问题不是简单地问：

我怎样才能写出一个更好的 Prompt？

而是：

到底必须满足什么？

真正的 Prompt 出现在最后

因此，我现在的工作方式通常不会从“写实现 Prompt”开始。

一开始往往只有一个 Idea、一个 Ticket，或者一个观察。然后才进入 Discovery。

一个简化的 mental model 可以是：

Idea / Ticket
↓
Discovery
↓
追问
↓
Alternatives
↓
业务决策
↓
技术决策
↓
Constraints
↓
Acceptance Criteria
↓
实现 Prompt
↓
Agent
↓
Verification

这绝对不是一个我会逐项打勾的 Process Model。在我的日常工作里，并不存在一个正式状态叫“Discovery 完成”。

有些任务五分钟以后就已经足够清晰，有些则需要多轮讨论。Legacy 系统里，往往还要先调查代码；有时正是在这个过程中，才发现缺失了一个业务决策。另一些情况下，一个现有的参考实现就足够回答绝大多数技术问题。

我的做法更接近 80/20：只要我已经理解和决定到足以让“下一步”可以被控制地执行，就可以继续。我并不会试图提前回答所有未来可能出现的问题。

Discovery 足够完成的标准，是下一步已经能够作为一个可控步骤合理开始。

这也意味着 Requirements 永远不会突然变成“完整”。实现过程中可能出现新信息，已有假设可能被证伪，某个现有 Contract 可能与预期不同，或者某个业务 Edge Case 只有在真正走一遍 Data Flow 以后才会暴露出来。

继续补充和收紧 Requirements，并不是 Discovery 失败，而是 Discovery 的一部分。

把 LLM 当作 Requirements Sparring Partner

在这个阶段，一个强大的 LLM 对我来说承担的是与后面 Coding Agent 不同的角色。

它不应该只是回答我的问题。

它应该反过来问我问题。

当我描述一个 Feature Idea 时，我希望它能帮我发现：里面还藏着哪个尚未做出的决定？哪个假设没有被明确说出来？缺了哪个错误场景？哪些角色受到影响？“删除”在业务上到底意味着什么？一个开发者还需要知道哪些信息，才能避免自己擅自做 Product 决策？哪些行为只是我个人的临时想法，而哪些才是真正的 Requirement？

例如可以问：

这个 Requirement 还有哪里不清楚？

我们目前有哪些隐含假设？

还缺哪些 Edge Cases？

哪些业务决策还没有做？

哪些内容明确不属于 Scope？

可能会影响哪些现有 System Boundaries？

之后我们如何判断实现是正确的？

一个好的 Planning Model 不只是回答问题，它还会让那些缺失的问题显现出来。

这并不只是理论上的 LLM 用法。关于 LLM-assisted Requirements Elicitation 的研究已经明确开始研究“为 Stakeholder 生成追问”这一类任务。2025 年一篇关于 Software Requirement Patterns 的论文就指出，LLM 生成 Elicitation Questions 在原则上是可行的，但同时会出现重复、Out-of-Scope 问题，而且仍然需要大量 Expert Assessment。2026 年 8 月的一篇 Systematic Mapping Study 分析了 74 篇论文，也呈现出类似趋势：在发现潜在 Requirements 这一步，Automation 已经相对常见；但一旦进入 Consolidation，尤其是 Stakeholder Validation，自动化程度就明显下降。

这和我实际使用 Planning Model 的定位非常吻合：它是 Sparring Partner，而不是 Requirements Owner。

到底谁有权做这个决定？

软件开发者习惯了解决问题。也正因为如此，在 Discovery 里我们很容易不知不觉开始做一些实际上并不属于自己权限范围的决定。

从技术上看，增加一个状态也许更优雅；另一个 Data Flow 也许更一致；多加一个流程步骤也许能消除某个 Edge Case；改变 Authorization Logic 也许能让实现更简单。

但这并不意味着我们有权这么做。

真实项目里有 Product Owner、业务部门、客户、Domain Expert 或其他承担业务责任的人。如果一个 Ticket 没有明确说明用户能否重新打开某个流程，那么“技术上最漂亮的方案”并不会自动变成正确答案。

Requirements Engineering 也意味着：不要在自己没有决策权限的地方替别人做决定。

这条原则对人和 Agent 都一样。

Planning Model 可以整理选项、解释后果、暴露冲突、比较 Alternative，但真正的决定依然应该留在承担业务责任的人那里，因为技术正确并不自动等于业务正确。

在 Legacy 系统里，Discovery 会变得非常技术化

在 Greenfield 项目里，很多技术决策可以直接描述。但在 Legacy 系统中，一开始我往往自己也不知道系统的真实状态。

这时，我会在 Planning Model、Coding Agent 和 Repository 之间来回传递任务。

Planning LLM
↓
Exploration Task
↓
Coding Agent 调查 Repository
↓
Findings
↓
回到 Planning
↓
新的决策

它和普通 Coding Task 的核心区别在于目标不同：Exploration Prompt 不是用来实现东西的，而是用来调查，比如：有没有类似 Flow？项目里实际上用了哪些 Pattern？哪些组件受影响？当前 Data Flow 到底怎么走？一个计划中的修改会碰到哪些 Dependencies？

这种 Task 可以非常窄：

调查这个 Feature 中类似 Create Flow
目前是如何实现的。

不要实现任何内容。

请报告：
- 相关文件
- 重复出现的 Patterns
- 差异
- 使用中的 Dependencies
- Open Questions

如果存在多个互相竞争的 Pattern，
不要自行决定未来应该采用哪一个。

于是 Repository 本身也成为 Discovery 的一部分。

这在长期演进的系统里尤其重要，因为文档和真实代码并不一定讲的是同一个故事。OpenAI 在其内部 Data Agent 的实践里也描述了类似机制：仅凭 Metadata 不足以理解数据，因此系统会主动读取代码，理解数据真正的语义和来源。团队的一条经验可以大致概括为：真正的含义往往存在于执行代码里，而不只是存在于它的描述中。

对 Legacy Software，我会把这个结论再扩大一点：

在 Legacy 系统里，Requirements 不只来自对话，其中一部分必须从现有系统中被“挖出来”。

在这个阶段，Coding Agent 首先是 Exploration Tool，而不是 Implementer。

Discovery 可以发散，Implementation 应该收敛得多

在 Discovery 阶段，我确实希望 Planning Model 有创造力。

它可以提出 Alternatives，可以质疑一个想法，可以建议另一条 Data Flow，也可以指出我的第一种方案为什么过度复杂。在这个阶段，更大的 Solution Space 是有价值的，因为我还在试图理解到底有哪些可能性。

但一旦业务行为、架构和 Coding Style 都已经决定，任务的性质就会变化。

Discovery
=
打开 Solution Space

Decision
=
评估选项

Implementation
=
关闭 Solution Space

本系列后面会有一篇文章专门讨论这个模式。这里先保留一个来自我个人实践的观察就够了：创造力并不是在每个阶段都同样有价值。

如果一个项目已经决定 Slice 如何组织、Dependencies 如何流动、State 如何建模、Naming 如何统一，我不希望 Agent 每做一个新 Feature 就重新发明一种“也很合理”的做法。

我现在的个人标准是：

整个项目应该读起来像是同一个开发者写出来的。

这并不意味着每个开发者都会写出完全相同的代码，而是意味着 Repository 应该保持一致性。不能从架构上轻易看出哪个 Feature 是哪个 Agent 或哪个模型做的。

在 Coding Style、Layering、Naming 和 Dependency Rules 上，额外的创造力通常不是优势。

它只是新的 Varience。

那么，实现 Prompt 到底是什么？

在这样的背景下：

做 Feature X。

对我来说通常并不算真正的实现 Prompt。

对于一个很小的 POC，这完全可以合理；一个很小的修正，也不需要五页 Specification。如果我本来就想看看 Agent 会自己发展出什么方案，那么 Task 也可以故意保持开放。

但如果是在现有系统里做一个真正涉及业务含义的修改，我的任务描述会详细得多。

一个完整的实现 Prompt 可能包含：

• 目标和业务目的
• Scope 和 Non-goals
• Discovery 中得到的关键发现
• 受影响的 Slice 或 Module
• 已经做出的业务决策
• 相关 Architecture Boundaries
• 现有 Reference Patterns
• Data Flow 和 State Flow
• Error Cases 和 Edge Cases
• Acceptance Criteria
• 必需的 Tests
• Verification Steps
• Stop Conditions
• 如果有必要，一套合理的实现顺序

这样的 Prompt 确实更像是一份多页技术规格说明，而不是一句聊天消息。

实现 Prompt 不是对 Agent 随口喊一句任务。它是对问题及其边界进行压缩后的 Specification。

当前 OpenAI 面向 agentic models 的 Guidance 也明确指向类似方向：不是把每一步都写死，而是定义 Outcome、Success Criteria、Constraints、可用 Evidence 和 Stop Rules。对于 Coding Workflow，还会额外强调 Acceptance Criteria、Tests，以及 Agent 什么时候可以继续自主工作、什么时候应该请求帮助。

这和“Prompt Engineering 就是把同一句任务写得更长”完全不是一回事：多出来的内容必须有功能。

每一部分都应该减少一种风险

为什么需要这些内容？

不是因为 Agent 喜欢长文本，而是因为任务描述中的不同部分分别限制了不同类型的错误。

部分	它减少了什么风险？
Goal	Agent 不会优化一个技术上有趣、但其实错误的问题。
Relevant Context	Task-specific 知识不会自动存在。
Scope	看似合理的附加功能不会悄悄进入任务。
Constraints	可接受的 Solution Space 被收紧。
Existing Patterns	相关 Local Evidence 会比随机找到的示例更突出。
Non-goals	修改不会无意义地扩张。
Acceptance Criteria	“看起来合理”与“满足任务”被区分开。
Verification	生成出来的结果不会自己成为自己的质量证明。
Stop Conditions	当关键假设被打破时，Agent 不会悄悄做新的根本性决定。

到这里，前几篇文章又重新汇合了：Context 有限，Solution Path 存在 Varience，而 Plausibility 并不足以作为质量标准。

因此，Prompt 中每新增一部分，都应该减少一个具体风险，而不是单纯让 Prompt 更长。

长 Prompt 并不自动意味着好 Prompt

前面的论证很容易让人得出一个错误结论：如果详细 Prompt 比模糊 Prompt 好，那更长的 Prompt 应该更好。

事实并不是这样。

一个巨大的 Task 可能很难 Review，也可能自相矛盾；旧决定可能和新决定混在一起；真正重要的 Rule 会淹没在无关细节里。更关键的是，它很容易变成一个特别大的工作包：Agent 长时间持续工作，而人或其他 Verification Step 要到很晚才能看到结果。

这样就拉长了可能出现 Drift 的距离。

因此我的实践是，把更大的任务主动切成更小的 Work Packages：

Discovery
↓
Work Package 1
↓
Review / Verification
↓
Work Package 2
↓
Review / Verification
↓
Work Package 3

更小的 Work Packages 会缩短 Generation 与 Verification 之间的距离。

这个原则也可以在当前 Agent Harness 中看到。Anthropic 在 Long-running Software Development 的实践中既描述了将任务拆成 manageable units，也描述了显式 Contracts：一个 Work Package 到底什么时候算 “done”，以及如何验证这个状态。更有意思的是，在同一个实验后期，随着更强模型出现，其中一部分 Sprint Structure 又被移除了。说明这种结构不是 Dogma，而是在特定 Task、不确定性和模型能力约束下的一种应对方式。

我对自己的 Work Packages 也是同样理解：不存在理想文件数量，不存在理想 Prompt 长度，也不存在通用的 Acceptance Criteria 数量。Package Size 应该跟着不确定性走。

Bug 是一个特殊情况

在 Bug 上，这个差异会更加明显。

做 Feature Implementation 时，更多细节可以降低不确定性，因为很多决策其实已经做过；但对未知错误来说，同样高的细节密度反而可能把 Investigation 引向错误方向。

假设一个列表只有在离开页面再回来之后才会更新。如果我直接告诉 Agent：

问题是 Store X
在 Update 之后没有被 invalidated。

在这里加一个 Reload。

我可能已经替它做出了最重要的判断：Root Cause。

如果我的假设错了，Agent 现在完全可能对一个错误诊断做出非常优秀的实现。

所以对于 Bug，我往往先描述：

Observed Behavior
Expected Behavior
Reproduction Conditions
Known Observations
Relevant Constraints

先调查 Root Cause。
在真正理解实际 Flow 之前，
不要实现解决方案。

细节应该在“决策已经做完”的地方降低不确定性，而不是在 Agent 仍然需要调查的地方替它提前做决定。

这看起来好像和“详细 Prompt”矛盾，实际上仍然是同一条规则。

我们不是要尽可能多地固定内容，而是要定义合适的 Decision Space。

Agent 追问，并不意味着 Prompt 失败

即使经过详细 Discovery，Coding Agent 在实现过程中依然可能遇到之前没人看到的东西。

这是正常的。

预期中的 API 也许不存在；相邻 Feature 的行为也许和文档不一致；两个 Pattern 也许互相矛盾；计划中的方案也许只有在违反一个此前没发现的 Architecture Boundary 时才可实现。

这时 Agent 不应该因为“一个好 Prompt 就不应该再问问题”这种错误观念而被迫猜测。

追问本身就是工作模型的一部分。

OpenAI 描述内部 Data Agent 时也提到了类似做法：当 Instructions 不清晰或不完整时，系统会主动提问；对低风险缺口则可以使用合理 Defaults。背后的 Principle 比具体实现更重要：并不是每一种不确定性都具有相同风险。

对琐碎决定，Agent 可以拥有 Autonomy；对业务或架构层面的决定，则可以设置 Breakpoint。

Stop Conditions 定义了 Autonomy 的终点

因此，显式 Stop Conditions 已经成为我最常用的 Prompt 组件之一。

例如：

如果找不到这个场景下
已有的 Architecture Pattern：

STOP。

报告发现。

不要自行做一个新的全局
Architecture Decision。

或者：

如果预期中的 API 不存在，
或者它的 Contract 与描述的行为
存在明显差异：

STOP。

记录差异，并提出
可能的下一步。

其他 Breakpoint 还可以包括：

• 缺少必要 Contract
• Ticket 与真实现有行为冲突
• 目标实现会违反既定 Dependency Rule
• 某个业务状态未定义
• 实现需要比 Scope 中描述的大得多的修改

不是每个不确定性都必须提前解决，但我们可以定义允许的决策空间在哪里结束。

因此 Stop Conditions 和其他 Constraints 一样，并不是在规定完整路径，而是在限制 Solution Space。

当前 OpenAI Guidance 也已经明确提到这种 Stopping Conditions，并将它们和 Success Criteria、缺少 Evidence 时的规则放在一起。这已经和早期“Prompt 有一个神奇句式”的想象相去甚远。

长期决策不应该只存在于某一个 Task

实现过程中仍然可能出现新的根本性决定。

也许我们发现某一类 Feature 以后统一使用一个 Mapper 更合理；也许出现一条新的 Dependency Rule；也许 Naming 被重新定义；也许一个之前只是隐式存在的 Architecture Pattern 第一次被明确决定。

这个决定一开始当然属于当前工作 Context。

但接下来应该再问一个问题：

下一个 Feature 来时，这个决定应该在哪里？

如果答案是“在上周二那个 Prompt 里”，那就有问题。

长期规则必须有长期归宿。根据内容不同，它可以进入 Agent File、Skill、项目文档、ADR、Architecture Test 或其他自动化规则。

Task-specific
→ 实现 Prompt

可复用 Workflow
→ Skill

长期 Project Rule
→ Agent File / Documentation / ADR

机械可验证 Rule
→ Test / Linter / Architecture Rule

不同 Agent System 的边界并不完全相同，重要的是目的。

Task-specific 决策属于实现 Prompt；长期项目决策需要长期存在的位置。

这直接连接回第 4 篇文章，也同时避免了第 6 篇里讨论的一个问题：一个重要决策不应该只是因为某段代码曾经被 commit，就偶然变成 Pattern；它应该被明确地决定和记录。

我现在几乎不再亲自写实现 Prompt

这会带到我个人工作方式里一个可能有点不寻常的部分。

短的 Correction Prompt，我依然会直接写。如果任务很小、很明确，就没必要引入更多流程。

但对于更大的 Feature，我会非常主动地处理 Requirements、Scope、决策、架构问题和 Acceptance Criteria；最终那份详细的实现 Prompt，我却经常不再自己完整写，而是让 LLM 来生成。

我现在几乎不再亲自写实现 Prompt。我主要负责把它里面应该包含的内容想清楚。

对我来说，这是一个非常重要的区别。

我不希望把注意力浪费在“第三节应该叫 Constraints 还是 Technical Boundaries”。真正重要的是：到底哪条 Boundary 适用。

强模型非常擅长把已经澄清的信息转成结构化的 Task：它可以消除重复，把相关决策归组，把 Acceptance Criteria 显式化，并把多轮对话整理成一致的 Execution Briefing。

真正关键的边界在别处：

AI 可以替我写 Prompt，但它不应该在没人注意的情况下替我发明 Requirements。

如果 Planning Model 碰到缺失的 Product Decision，随手选择了一个“看起来合理”的 Variant，然后又非常自信地把它写进 Implementation Prompt，我们没有得到任何真正的改进。我们只是把“这个决定是谁做的”隐藏了起来。

Anthropic 最近对大约 40 万次 Claude Code Session 的分析提供了一个很有意思的实践视角。这些 Session 来自 2025 年 10 月到 2026 年 4 月。在其基于 Classifier 的评估中，人类平均做出大约 70% 的 Planning Decisions，而 Claude 则做出大约 80% 的 Execution Decisions。Anthropic 将其解释为一种相对清晰的劳动分工：人类更多决定“要构建什么”和“什么时候算完成”，Agent 则更多承担具体执行。这不是 Agentic Work 的普遍定律，但它和我自己实际形成的工作方式非常接近。

OpenAI 在自己的 agent-first 软件项目中也描述了类似转变：人的工作逐步转向构建环境、定义 Intent、设计 Feedback Loops，而 Codex 则负责生成代码。

我的简化说法是：

人不一定亲自 authored Prompt，但人需要 authored Requirements。

把 Prompt 看成一种“编译后的工作产物”

可以把这个过程——明确说，只是一个 Metaphor——想象成一个小型 Compiler。

Intent
↓
Requirements
↓
Decisions
↓
Constraints
↓
LLM
↓
Execution Prompt
↓
Agent
↓
Artifact

“Prompt Compiler” 这个词在技术上当然并不精确：LLM 并不会像 TypeScript Compiler 那样确定性地把 Requirements 编译成输出。

但作为 mental model，我仍然喜欢这个比喻，因为它把价值产生的位置移动了。

Prompt 不是某种神奇的 Source Code，不是写完以后 Feature 就凭空出现。

它只是把之前已经思考、澄清和决定过的内容，压缩成 Agent 可执行的形式。

这也解释了为什么最终 Prompt 可能非常长，但我却很少花时间纠结它的具体措辞。

真正的工作早就发生在前面了。

同样的模式也适用于写作

这种工作方式并不只适用于 Software Development。

比如这整个文章系列，并不是从一句：

写一篇关于 Hallucination 的文章。

开始的。

一开始更多是一个观点或一个观察。然后才有对话：概念被拆分，过强的陈述被修正，研究被查找，互不可比的数字被丢弃，个人经验被放回合适的位置。只有经过这些过程，我们才逐渐知道哪些观点是真正站得住的，哪些只是“听起来很好”。

直到这时，才会生成一个详细的 Generation Prompt。

初始观点
↓
讨论
↓
研究
↓
反问
↓
决策
↓
Narrative Thread
↓
Generation Prompt
↓
Draft
↓
Editorial Review

Generation Prompt 这时可能已经包含标题、中心观点、Sources Framework、Examples、明确禁止说什么、希望怎样过渡，以及和其他文章的连接。

从外面看，这像是一个“很会写 Prompt”的结果。

实际上，它只是更长 Discovery 的最后一个可见阶段。

Generation Prompt 不是创造力的起点，而是之前思考过程的结果。

当然，第一个 Draft 也依然不是最终文章；Generation 和 Editorial Work 仍然是两个不同步骤。

图像生成也是同一个模式

做图时也是一样。

我当然可以直接对 Image Model 说：

做一张关于 Architecture Drift 的 Infographic。

也许最后甚至会得到一张挺好看的图。

但真正重要的工作仍然发生在前面。

这张图究竟要解释什么？什么关系必须让人一眼看懂？我需要的是 Process、Comparison，还是一个 Spatial Metaphor？它不能错误暗示什么？哪些 Text 必须准确出现？哪些元素具有语义意义，哪些只是装饰？

这些问题澄清后，才需要把 Intent 翻译成 Image Model 能很好理解的 Prompt。

表达目标
↓
Visual Concept
↓
声明边界
↓
Visible Content
↓
Style
↓
Image Prompt
↓
Image Model

同样，人并不一定要成为最擅长写 Image Prompt 的人。

最重要的是知道：

这张图到底应该表达什么。

之后可以由专门的模型或另一个 LLM，把这个 Intent 转换成更适合 Image Model 的 Prompt。

Prompt Engineering 正在变成“Prompt 之前的 Engineering”

这也改变了我对 Prompt Engineering 这个词的理解。

Prompt Engineering 并没有消失。具体措辞当然依然重要；结构、Examples、Priorities 和清晰 Instructions 都会影响模型行为。

但在真实 Agentic Work 中，这只是更大问题的一部分。

Anthropic 在技术层面把这种趋势称为从 Prompt Engineering 转向 Context Engineering：不再只是优化单个句子的写法，而是管理模型在某个时刻能访问到的整体 Information State。OpenAI 的实践则给出了类似经验：过度僵硬、过度规定过程的 Prompt 反而可能效果更差；更稳健的方法是定义目标和关键边界，然后让模型自己确定具体路径。

对我的工作来说，我愿意再往前走一步：

Prompt Engineering 正在从“写 Prompt”，转向 Engineering 那些最终会生成 Prompt 的信息和决策。

Discovery、Requirements、Context Selection、Architecture Rules、Acceptance Criteria、Verification，以及“哪些事情 Agent 可以自己决定”——这些全部属于这个过程。

Prompt 并不是起点。

它实际上已经处在相当后面。

Requirements 是第一道边界

这就回到了这篇文章在整个系列中的真正作用。

第 5 篇说明了：一个任务可以存在多个看起来都合理的 Solution Path。我们并不打算彻底消除这种性质。Agent 可以自己决定先读哪个文件，也可以在现有架构内部选择某种局部实现方式。

但第 6 篇同时说明了：Plausible 并不等于 Correct。

所以我们需要边界。

Requirements 首先定义：

最后到底必须满足什么？

它们回答例如：

哪些业务状态允许存在？什么算 Success？什么算 Error？哪些用户可以执行哪些操作？哪些内容属于 Scope？哪些属性不可协商？实现完成后，哪些条件必须能够被观察和验证？

Requirements 定义了哪些结果才有资格被认为是可接受的。

它们并不会自动决定完整 Solution Path，而是描述可接受的 Outcome Space。

这个区别非常重要。

Requirements 还不是架构

即使这样，还缺一层。

例如一个 Requirement：

用户只能修改自己的数据。

这描述的是业务或安全层面的行为。

而一个 Architecture Rule 可能是：

Presentation 不得直接访问
Infrastructure。

这两条都在限制方案，但它们限制的是不同层面。

Requirements 主要描述 必须满足什么。

Architecture Constraints 更多描述 实现时不能跨越哪些结构性边界。

当 Agent 开始自主修改系统中更大范围的代码时，这个区别会变得越来越重要，因为一个在业务上完全正确的结果，在结构上依然可能是一个很差的解决方案。

Prompt 其实在更早之前就开始了

当我今天把一份多页 Implementation Prompt 交给 Coding Agent 时，最重要的工作往往已经完成了。

我们已经提过问题，已经调查 Repository，已经把业务决策和技术决策分开，已经定义 Scope 与 Non-goals，已经确认哪些事情由谁负责，已经设定 Agent 可以自主决定到什么程度，也已经明确最终结果怎样 Verification。

直到这时，才生成 Prompt。

Prompt Engineering 从 Prompt 之前开始。 第 4 篇说明 Agent 需要 Relevant Context；第 5 篇说明它在这个 Context 中仍然可能选择不同 Solution Path；第 6 篇说明一个 Plausible Path 仍可能建立在错误假设上。第 7 篇因此补上下一层结论：我们必须更明确地定义，哪些结果可以接受，以及 Decision Space 在哪里结束。

Requirements 是第一道边界，但它还不够。即使业务上已经完全清楚 必须满足什么，仍然还有一个问题：

我们怎样保证这个解决方案在结构上也真正属于现有系统？

这就是下一篇文章要讨论的内容。

Requirements 限制业务上可接受的结果。下一步，我们要用同样的方式限制系统结构。

来源与说明

• OpenAI – Model Guidance / Prompting Best Practices，更新至 2026 年 9 月。 当前 GPT-5.5 Guidance 建议在 agentic tasks 中定义 Outcome、Success Criteria、Constraints、Available Evidence 和显式 Stopping Conditions，同时避免不必要的 Process Micromanagement。这是产品级 Guidance，而不是通用 Prompt 理论。Model guidance
• OpenAI – Inside OpenAI’s in-house data agent，2026 年 1 月。 该实践报告描述了多层 Context、在 Instructions 不清晰或不完整时主动追问、合理 Defaults，以及 “Guide the Goal, Not the Path” 这一经验。同时还描述了如何主动读取代码，将其作为语义证据来源。Inside OpenAI’s in-house data agent
• OpenAI – Harness engineering: leveraging Codex in an agent-first world，2026 年 2 月。 报告描述了一个内部 agent-first 软件项目，其中人的工作明显转向 Intent、Environment Design 和 Feedback Loops。大型单体 AGENTS.md 被证明存在问题，因此更短的 Agent 文件被用于引导进入一个版本化 Knowledge Base。Harness engineering
• Anthropic – Effective context engineering for AI agents，2025 年 9 月。 Anthropic 将 Context 描述为有限资源，并把关注点从单独优化 Prompt 措辞转向“模型在什么时候应该看到哪些信息”。Effective context engineering for AI agents
• Anthropic – Agentic coding and persistent returns to expertise，2026 年 6 月。 基于隐私保护和 Classifier 的分析，覆盖约 40 万次 Claude Code Session，时间范围从 2025 年 10 月到 2026 年 4 月。在典型 Session 中，人类大约承担 70% 的 Planning Decisions，而 Claude 大约承担 80% 的 Execution Decisions。这描述的是某一具体产品的使用模式，不是 Agentic Work 的普遍定律。Agentic coding and persistent returns to expertise
• Anthropic – Harness design for long-running application development，2026 年 3 月。 该实践报告讨论 Planner / Generator / Evaluator Structures、Sprint Contracts 和可测试标准。特别有意思的是后期简化：使用 Opus 4.6 后，Sprint Decomposition 可以移除，但 Evaluator 在模型能力边界附近仍然有价值。Harness design for long-running application development
• Franch et al. – Leveraging Requirements Elicitation through Software Requirement Patterns and LLMs, REFSQ 2025。 研究表明，LLM 生成 Stakeholder Questions 在原则上可行，但会出现重复和 Out-of-Scope Questions，并且仍然需要大量 Expert Assessment。Publication entry
• Eltahier et al. – Automated Software Requirements Elicitation: A Systematic Mapping Study，2026 年 8 月。 该研究整理了 2021 至 2025 年的 74 篇 Peer-reviewed Papers。74 篇全部涉及 Identification Automation；其中 51% 到达 Structuring，23% 到达 Consolidation，只有 8% 实现技术集成的 Stakeholder Validation。Information 17(8), 777
• Pasquale et al. – Exploring the Use of LLMs for Requirements Specification in an IT Consulting Company, IEEE RE 2025。 工业案例表明，LLM 可以帮助标准化 Requirements Specification 并支持其生成，但质量依然强烈依赖 Input，而且仍然需要人的业务和技术 Review。IEEE DOI