AI初创公司通常会积累大量充满矛盾和模糊性的提示词，因为团队会持续添加指令。像对待产品和代码一样对待提示词，为其设置模块化分区来涵盖背景、行为和输出，可以提升智能体质量、减少回退现象，并降低成本。

为何全球顶尖AI初创公司会写出糟糕的提示词（以及如何改进）

要点速览

• 大多数提示词质量不佳，因为提示词的演变往往是累加式的：我们只会不断添加，却从不删减。这导致了“面条式提示词“，充满矛盾与模糊性，对业务产生实质影响。

• 我们需要将提示词变更视为产品变更（因为智能体行为就是产品），并将提示词当作代码对待（模块化、MECE原则以及其他你熟悉的缩略词；必要时重构并积极维护）。

• 结构清晰的提示词能让团队更快迭代、避免回退问题，并打造更优秀的智能体。我在文末提出了一种非常简单的结构。

提示词决策就是产品决策，运用结构来创建清晰、可维护的提示词，对于打造卓越智能体至关重要。本文将指导你如何实现这一点。

背景

我认为自己拥有世界上最棒的工作之一。作为OpenAI初创团队在EMEA和APAC地区的应用AI工程负责人，每周我都能接触到全球顶尖AI初创公司的内部运作。我经常与他们的工程师并肩工作，共同优化智能体——从提示词到评估到微调等各个方面。

这些初创公司非常先进。有些公司的年经常性收入已达数亿美元，有些拥有自己的数据标注团队，甚至有些训练自己的模型。

因此令人惊讶的是，当我深入了解时，发现他们的提示词常常存在逻辑问题。这并非关乎文字优美或格式规范，而是那些导致智能体犯错的逻辑错误。

这不是对这些初创公司的批评——实际上，他们比我曾创办过的任何公司都更成功，团队中也都是全球顶尖的工程师。与他们合作非常愉快。

但他们错失了巨大提升空间。仅通过几天重写智能体提示词，我见过一些初创公司将智能体速度提升50%；有些将7日留存率提高40%；还有些将成本降低30%。这些成果适用于它们使用的所有供应商的LLM。当涉及数百万美元的年经常性收入和LLM开支时，这影响相当显著。

不信？可以看看这位Loveable工程师的帖子，他如何通过修复提示词中的不一致和重复内容，每年减少2000万美元的LLM开支。

正是因为他们如此出色，我才决定撰写此文。因为显然，即使你确实是世界级的团队，我们当前的提示词范式仍会导致次优结果。

因此，我希望通过这篇文章，将我的影响力扩展到直接合作的初创公司之外。首先，我将分析为何顶尖初创公司会写出糟糕的提示词；然后，分享我的提示词理念；最后，提供一个提示词模板。

（阅读时，不妨将这篇文章链接发给你的编程智能体，请它对照建议审查你的代码库，并生成一份Markdown格式的审查报告，这样你读完时报告就准备好了！）

糟糕的提示词

既然这种情况如此普遍，显然存在导致提示词质量低下的普遍倾向。两个主要问题是矛盾和模糊性。

当前提示词工作流程具有累加性，导致矛盾

大多数提示词都这样演变：第一个构建智能体的工程师写下一个简单的文本提示词。随着初创公司发展，智能体需要完成更多任务，他们便不断向提示词添加内容。出现错误后，他们再添加几行来修复。

提示词只会越来越长。

几乎没有人会完整审视整个提示词。这几乎总是会导致提示词内部出现矛盾，因为当你添加新内容时，旧的、表述不同的内容却被保留了下来。

隐含知识导致模糊性

即使工程师确实完整审查了提示词，他们也往往不是真正“阅读“它。当你解读一句话时，你不仅使用页面上的文字，还会调用所有已有知识来理解这些文字。这就是问题所在——你往往知道这句话想要表达什么，于是就读取了这个“想要表达的含义“，而非其实际字面意思。

这就是具体性不足的问题：提示词并未真正说明我们希望智能体做什么，因为我们没有明确无误地指定它。例如，假设我告诉智能体“在输出中永不提及竞争对手“。这对该初创公司的工程师来说显而易见，因为他们每天都在思考自家公司和竞争对手。但对于没有这些隐含知识的智能体来说，这极其模糊——竞争对手是谁？那些我们有时也合作的部分竞争对手呢？我们并未明确说明具体期望。

条件提示词使问题复杂化

上述问题因条件提示词而加剧——根据场景注入不同的提示词内容。不同工程师在不同文件中负责不同部分。这意味着即使每个团队/工程师审查了自己的提示词是否矛盾和具体，也没人审查完整内容。

结果如何？

我们得到了“面条式提示词“。数千行内容，段落间存在交互效应，几乎无法完整审查，因为读到最后一句时，大多数人早已忘记第一句内容。或者干脆放弃阅读。

这导致智能体频繁“犯错“，行为不符合团队预期。

但以上也正是我能快速为这些初创公司创造价值的原因：我会完整阅读提示词，见过数百家公司的共性问题，且不带他们团队的隐含知识，因此能发现模糊性，并以新鲜视角天真地追问“这到底是什么意思“。

当我与团队完整梳理提示词后，会出现一个美妙的“拟人化时刻“。我们发现许多矛盾，并厘清大量模糊之处。工程师们常常暗自失笑，觉得自己可能对LLM过于苛刻，并向它“道歉“。

但到目前为止我只列举了问题。而且坦率地说，这些初创公司已经做得非常出色，那么解决方案是什么？这真的值得他们投入时间吗？

我之前提到的财务收益不言自明，但我真心相信我们可以帮助初创公司更快发展并构建更好的产品——这是创业的终极目标。

我的原则：开始将提示词视为产品，并将提示词视为代码。 解决方案：创建MECE（相互独立、完全穷尽）的结构化提示词，使其可维护。

提示词决策即产品决策

智能体是产品体验的核心。在基于聊天的产品中，智能体就是整个产品。智能体输出的格式就是UI。例如，它应该输出项目符号还是Markdown？应该始终用英文回复，还是使用用户消息的语言？

这仅仅是输出部分。智能体行为是产品决策：应该优先快速响应，还是进行全面研究让用户等待？这是产品问题。应该调用工具要求用户确认，还是直接执行？这同样是产品问题。

一切都是产品。

因此，编写提示词的人必须理解你期望的用户体验，因为即使他们不编写UI，他们也在全面改变用户的交互方式。

不仅他们需要理解，还必须能够明确表达这种体验。

我在与顶尖初创公司合作时，审视具体错误轨迹时常问：“你实际希望智能体在这里做什么？“回答往往是：“嗯，这是个好问题。”

如果你无法指定期望的产品体验，就不能指望LLM提供这种体验。对人类也同样如此（或不应如此）。

每次工程师修改提示词，或因未修改而保留模糊性时，他们都在做出产品选择。因此，明确选择对连贯的产品体验至关重要。

提示词即代码

我们使用人类可读语言来让计算机完成我们想做的事。这对编程语言成立，对当前LLM的提示词同样适用。此外，我们已拥有数十年管理代码库（指定我们需求的文本集合）的经验，代码库随功能增加而不断增长。听起来很熟悉？因此我们可以借鉴一些相关原则。

使用MECE分区构建结构

工程师们请原谅我使用咨询术语，但这确实相关。MECE意为相互独立（Mutually Exclusive）、完全穷尽（Collectively Exhaustive），基本含义是覆盖所有相关内容（CE）且无重复（ME）。当我们思考提示词分区时，这恰好解决了前述问题。

• 完全穷尽：你的提示词分区共同全面覆盖（指明）了期望的行为。

• 相互独立：每个提示词分区应独立完整，无重叠。

这形成了DRY（Don’t Repeat Yourself，不重复）提示词，更易维护和审查。当你修改时，只需改动一个特定分区，无需担心与其他内容产生交互——就像修改模块化良好的代码一样。这也消除了期望行为中的模糊性。

尽可能分离关注点。模块化代码是好代码；模块化提示词是好提示词。

例如，我们会有关于智能体通用背景、期望行为和输出的分区。这三者无重叠，共同涵盖了智能体运行前的背景、运行时的行为以及运行结束时的处理——即MECE。

追求编程般的精确性

工程师编写代码时，对需求非常精确。如果是这样，就那样做。但一旦变成文本形式，这些人就变得不那么精确了。相反，应将其视为代码。

例如，你可能仍想使用IF ELSE逻辑。比如描述智能体如何使用网络搜索工具时，你可能希望它仅在特定主题上使用网络搜索。如果是主题X，则使用web_search；否则使用内部知识。或者你希望它总是搜索。无论你的期望是什么，都要明确说明。

目标不是“编程“每种情况——否则你就不需要用LLM了。但你确实需要指明在用户请求的核心分支上期望的行为，或者执行特定操作的标准。

分离后端与前端

上文我提到了行为分区和输出分区。在我将提示词视为产品/代码的框架中，我喜欢将其视为分离后端和前端的关注点。

• 行为：这是智能体在准备输出时的行为方式。包括它使用工具的方式、与更广泛系统交互的方式、规划方式（或不规划）。换言之，就像后端；涵盖逻辑，用户不应看到这部分。

• 输出：这是前端，是智能体面向用户的部分。智能体输出可以完全独立于其思考过程。例如，我们可能希望它以非常理性、结构化的方式思考，但输出优美的散文。或者总是使用代码进行数据分析，但从不向用户展示代码。

我们分离了关注点，这意味着我们可以在各种情况下更一致地指定期望。

定期重构

即使有最好的意图，提示词也可能变得混乱。投入时间偿还“提示词债务“。如果有新的相关分区，就添加；如果某些分区过于庞大，就拆分。

良好提示词模板：背景、行为、输出

因此我们需要一个结构良好、MECE的提示词，尽可能分离关注点。以下是一个非常通用的模板，你可以直接使用。

层次化、MECE的提示词结构，有助于保持提示词可维护和无歧义

层次化、MECE的提示词结构，有助于保持提示词可维护和无歧义

你会注意到这是层次化组织的，像一棵树。这有助于实现MECE，也让你能更快找到分区。同时，如果你使用IDE（毕竟现在是2025年👀），在查找相关内容时，可以轻松折叠不相关分区。

假设我的智能体输出Markdown，而我想要XML输出。很简单——只需在“输出格式“分区修改一行内容。

修改位置明确无误。

关于评估的简要说明

我比普通人更重视评估。大多数时候，当智能体出错时，简单的评估就能帮助修复。我认为上述内容是核心原因。

Hamel（每个人都应阅读他关于评估的文章）强调，评估的很大价值实际上来自你阅读跟踪记录的过程。很多时候，你在编写评估之前就发现了错误并意识到修复方法。这完全正确。

但我要补充一个额外好处：评估迫使你决定自己想要什么。

当你创建评估时，无论是使用确定性真值还是评判标准，你都必须指定期望行为。很多时候，你意识到自己从未在提示词中明确说明这种期望——它只是你脑海中的潜在上下文，而非提示词中的明确表述，或者你甚至自己都没完全理清。

评估强迫你清晰化，从而迫使你做出清晰的产品决策。

（去读Hamel的其他文章，了解评估的无数其他好处吧）

结构化提示词的好处

更少矛盾

采用MECE分区，审查提示词变得很容易。每个分区独立完整，你无需记住数百行内容来查找矛盾，只需审查该分区。此外，如果该分区未穷尽你期望的行为，只需在此处添加行即可。

更快更安全的迭代

分离关注点让你能极快地迭代。发现问题时，只需在一个特定分区添加一行内容，因为它与其他部分的交互应最小化。这让你能更快推进。

更快的搜索

在“面条式提示词“中，你必须记住提示词中的关键短语或文件名来找到要修改的部分。而在层次化组织的提示词中，查找相关分区的过程快得多（这是树搜索），因此可以快速迭代。

人人皆可编写提示词

许多前瞻性的初创公司希望团队所有人都能编写提示词。这很有道理：如果你在金融领域工作，你的前银行家比大多数工程师更了解银行家的需求。记住，提示词就是产品。

使用MECE结构化提示词，你可以获得这些好处，同时不必担心没有工程背景的人会做出导致“面条式提示词“的修改。因为审查提示词变更极其容易：

• 他们是否将其放在了正确分区？

• 它是否与分区内其他内容矛盾？无需痛苦地审查整个提示词的交互效应（或者干脆不审查——许多团队的实际做法），你只需审查几行内容，因为分区是独立的。

更快的模型升级

当新模型发布时，测试其默认值变得更容易。

• 也许所有“示例“都不再需要，因为新模型更聪明了。只需5秒找到示例分区并删除即可。

• 也许之前的模型总是输出长破折号，因此你需要在输出分区添加一行说明，而新模型不会。这只需删除一行，节省几个token。

综上所述：你获得了一个产品，其中