微信扫码
添加专属顾问
提示词工程无疑是开发 LLM 原生应用程序中最关键的技能之一,因为精心设计的提示词可以显著提升应用程序的性能和可靠性。
在过去的两年里,我一直在帮助组织为实际应用场景构建和部署数十个 LLM 应用程序。这段经历让我对有效的提示词技术有了宝贵的见解。
本文基于LLM 三角原则,提出了八大实用提示词工程技巧,以提升你的 LLM 提示词能力。
“LLM 原生应用程序中,10% 是复杂模型,90% 是基于数据驱动的实验性工程工作。”
在本文中,我们将使用“着陆页生成器”示例来展示如何应用每个技巧来提升真实世界中的 LLM 应用程序。
你也可以查看着陆页生成器示例的完整脚本以全面了解。注意: 这是一个简化的、非生产环境的示例,旨在说明这些技巧。代码和提示词故意简单化,以突出讨论的概念。
首先为每个代理或提示词定义目标。坚持每个代理只处理一种认知过程类型,例如:构思着陆页、选择组件或为特定部分生成内容。
保持清晰的边界有助于在 LLM 交互中保持重点和清晰度,这与LLM 三角原则的工程技术顶点相一致。
“我们的流程中的每一步都是必须发生的独立过程,以完成我们的任务。”
例如,避免在同一个提示词中组合不同的认知过程,这可能会产生次优结果。相反,将这些过程分解为独立且专注的代理:
def generate_landing_page_concept(input_data: LandingPageInput) -> LandingPageConcept:
"""
根据输入数据生成着陆页概念。
该功能专注于着陆页概念的创造性过程。
"""
pass
def select_landing_page_components(concept: LandingPageConcept) -> List[LandingPageComponent]:
"""
根据概念选择着陆页的适当组件。
此功能仅负责选择组件,不负责生成其内容或布局。
"""
pass
def generate_component_content(component: LandingPageComponent, concept: LandingPageConcept) -> ComponentContent:
"""
为特定的着陆页组件生成内容。
此功能专注于根据组件类型和整体概念创建适当的内容。
"""
pass
通过为每个代理定义清晰的边界,我们可以确保工作流程中的每一步都针对特定的思维任务进行定制。这将提高输出的质量,并使调试和优化变得更加容易。
定义明确的输入和输出结构,以反映目标并创建明确的数据模型。这一做法涉及LLM 三角原则的工程技术和上下文数据两个顶点。
class LandingPageInput(BaseModel):
brand: str
product_desc: str
campaign_desc: str
cta_message: str
target_audience: str
unique_selling_points: List[str]
class LandingPageConcept(BaseModel):
campaign_desc_reflection: str
campaign_motivation: str
campaign_narrative: str
campaign_title_types: List[str]
campaign_title: str
tone_and_style: List[str]
这些 Pydantic 模型定义了我们输入和输出数据的结构,并为代理设定了明确的边界和期望。
设置验证机制以确保 LLM 输出的质量和适度性。使用 Pydantic 非常适合实施这些防护措施,我们可以利用它的本机功能来实现这一点。
class LandingPageConcept(BaseModel):
campaign_narrative: str = Field(..., min_length=50)
tone_and_style: List[str] = Field(..., min_items=2)
@field_validator("campaign_narrative")
@classmethod
def validate_campaign_narrative(cls, v):
"""
使用另一个 AI 模型验证广告活动叙述是否符合内容政策。
"""
response = client.moderations.create(input=v)
if response.results[0].flagged:
raise ValueError("提供的文本违反了内容政策。")
return v
在此示例中,通过定义两种类型的验证器来确保应用程序的质量:
**Field** 定义简单的验证规则,如语气/风格属性至少有2个,叙述内容至少有50个字符。**field_validator** 来确保生成的叙述符合我们的内容审核政策(使用 AI)。通过将复杂任务分解为逻辑顺序的较小步骤来构建 LLM 工作流程,以模仿人类的认知过程。要做到这一点,请遵循LLM 三角原则的 SOP(标准操作程序) 指导原则。
“没有 SOP,即使是最强大的 LLM 也无法始终如一地交付高质量的结果。”
在我们的示例中,我们希望模型返回 LandingPageConcept 作为结果。通过要求模型输出某些字段,我们引导 LLM 模仿人类营销人员或设计师在创建着陆页概念时可能采取的思维方式。
class LandingPageConcept(BaseModel):
campaign_desc_reflection: str
campaign_motivation: str
campaign_narrative: str
campaign_title_types: List[str]
campaign_title: str
tone_and_style: List[str]
LandingPageConcept 结构鼓励 LLM 遵循类人类的推理过程,反映专家可能本能地进行的隐性认知“跳跃”,就像我们在 SOP 中建模的那样。
对于复杂任务,将过程分解为多个步骤,每个步骤由单独的 LLM 调用或“代理”处理:
async def generate_landing_page(input_data: LandingPageInput) -> LandingPageOutput:
concept = await generate_concept(input_data)
selected_components = await select_components(concept)
component_contents = {
component: await generate_component_content(input_data, concept, component)
for component in selected_components
}
html = await compose_html(concept, component_contents)
return LandingPageOutput(concept, selected_components, component_contents, html)
多代理过程代码的示意图。这种多代理方法与人类解决复杂问题的方式一致——通过将其分解为较小的部分。
YAML 是一种流行的人类友好的数据序列化格式。它设计为易于人类阅读,同时仍然易于机器解析——这使得它非常适合 LLM 使用。
我发现 YAML 对于 LLM 交互特别有效,并且在不同模型中产生了更好的结果。它将 token 处理集中在有价值的内容上,而不是语法上。
YAML 还具有很高的跨不同 LLM 提供商的可移植性,并允许你保持结构化的输出格式。
async def generate_component_content(input_data: LandingPageInput, concept: LandingPageConcept, component: LandingPageComponent) -> ComponentContent:
few_shots = {
LandingPageComponent.HERO: {
"input": LandingPageInput(
brand="Mustacher",
product_desc="Luxurious mustache cream for grooming and styling",
),
"concept": LandingPageConcept(
campaign_title="Celebrate Dad's Dash of Distinction",
tone_and_style=["Warm", "Slightly humorous", "Nostalgic"]
),
"output": ComponentContent(
motivation="The hero section captures attention and communicates the core value proposition.",
content={
"headline": "Honor Dad's Distinction",
"subheadline": "The Art of Mustache Care",
"cta_button": "Shop Now"
}
)
},
}
sys = "Craft landing page component content. Respond in YAML with motivation and content structure as shown."
messages = [{"role": "system", "content": sys}]
messages.extend([
message for example in few_shots.values() for message in [
{"role": "user", "content": to_yaml({"input": example["input"], "concept": example["concept"], "component": component.value})},
{"role": "assistant", "content": to_yaml(example["output"])}
]
])
messages.append({"role": "user", "content": to_yaml({"input": input_data, "concept": concept, "component": component.value})})
response = await client.chat.completions.create(model="gpt-4o", messages=messages)
raw_content = yaml.safe_load(sanitize_code_block(response.choices[0].message.content))
return ComponentContent(**raw_content)
注意我们如何使用少样本学习的示例来“展示而非说明”预期的 YAML 格式。这种方法比在提示词中明确说明输出结构更为有效。
仔细考虑如何对数据进行建模和展示给 LLM。这个技巧是LLM 三角原则的上下文数据顶点的核心。
“即使是最强大的模型也需要相关且结构良好的上下文数据才能发挥光彩。”
不要抛弃你对模型的所有数据。相反,向模型提供与您定义的目标相关的信息。
async def select_components(concept: LandingPageConcept) -> List[LandingPageComponent]:
sys_template = jinja_env.from_string("""
Your task is to select the most appropriate components for a landing page based on the provided concept.
Choose from the following components:
{% for component in components %}
- {{ component.value }}
{% endfor %}
You MUST respond ONLY in a valid YAML list of selected components.
""")
sys = sys_template.render(components=LandingPageComponent)
prompt = jinja_env.from_string("""
Campaign title: "{{ concept.campaign_title }}"
Campaign narrative: "{{ concept.campaign_narrative }}"
Tone and style attributes: {{ concept.tone_and_style | join(', ') }}
""")
messages = [{"role": "system", "content": sys}] + few_shots + [
{"role": "user", "content": prompt.render(concept=concept)}]
response = await client.chat.completions.create(model="gpt-4", messages=messages)
selected_components = yaml.safe_load(response.choices[0].message.content)
return [LandingPageComponent(component) for component in selected_components]
在此示例中,我们使用 Jinja 模板来动态构建我们的提示词。这种方法优雅地为每次 LLM 交互创建了集中且相关的上下文。
“数据为 LLM 原生应用程序的引擎提供动力。上下文数据的战略设计解锁了它们的真正潜力。”
少样本学习是提示词工程中必不可少的技术。为 LLM 提供相关示例显著提高了其对任务的理解。
注意在我们下面讨论的两种方法中,我们重用了 Pydantic 模型来进行少样本学习——这一技巧确保了示例与我们的实际任务之间的一致性!不幸的是,这是我通过艰难的方式学到的。
看看 5 节中的 few_shots 字典。在这种方法中:示例作为单独的用户和助手消息添加到 messages 列表中,然后是实际的用户输入。
messages.extend([
message for example in few_shots for message in [
{"role": "user", "content": to_yaml(example["input"])},
{"role": "assistant", "content": to_yaml(example["output"])}
]
])
messages.append({"role": "user", "content": to_yaml(input_data)})
通过将示例作为 messages 放置,我们与指令模型的训练方法保持一致。它允许模型在处理用户输入之前查看多个“示例交互”——帮助它理解预期的输入输出模式。
随着应用程序的发展,你可以添加更多的少样本学习示例来涵盖更多的用例。对于更高级的应用程序,可以考虑实现动态少样本学习选择,其中根据当前输入选择最相关的示例。
此方法使用与当前任务直接相关的示例在提示词本身中。例如,此提示词模板用于生成额外的独特卖点:
Generate {{ num_points }} more unique selling points for our {{ brand }} {{ product_desc }}, following this style:
{% for point in existing_points %}
- {{ point }}
{% endfor %}
通过将示例直接包含在提示词中而不是作为单独的消息,这为特定内容生成任务提供了有针对性的指导。
虽然像“思维树”或“思维图”这样的复杂提示词工程技术很吸引人,尤其是在研究方面,但我发现它们在生产中实际上相当不切实际,往往过于复杂。对于真实的应用程序,重点是设计适当的 LLM 架构(即工作流工程)。
这也适用于在 LLM 应用程序中使用代理。理解标准代理和自主代理之间的区别至关重要:
代理: “通过执行 XYZ 将我从 A → B。”
自主代理:“
通过某种方式将我从 A → B,我不在乎怎么做。”
虽然自主代理提供了灵活性和更快的开发速度,但它们也可能引入不可预测性和调试挑战。谨慎使用自主代理——仅当好处明显超过可能的控制损失和复杂性增加时使用。
持续的实验对于改进 LLM 原生应用程序至关重要。不要被实验的想法吓倒——它们可以小到调整提示词。正如《构建 LLM 应用程序:清晰的分步指南》中所概述的那样,建立基准并根据基准跟踪改进非常重要。
就像“AI”中的其他一切一样,LLM 原生应用程序需要研究和实验心态。
另一个很棒的技巧是将你的提示词尝试在比你打算在生产中使用的更弱的模型上(如开源的 8B 模型)——在较小的模型上表现“还可以”的提示词在较大模型上表现会更好。
这八大技巧为 LLM 原生应用程序中的有效提示词工程提供了坚实的基础。通过在提示词中应用这些技巧,你将能够创建更可靠、高效和可扩展的 LLM 原生应用程序。
记住,目标不是创建最复杂的系统,而是构建在现实世界中可行的东西。继续实验、学习和构建——可能性是无穷无尽的。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-07-01
从 Prompt 到 Skill:专业工作流的结构升级
2026-07-01
别让 AI 写的文档误导用户:从单次 Prompt 到高可信文档工程化实践
2026-06-30
网传 Karpathy 的 CLAUDE.md 曝光,10条铁律管住Claude Code!
2026-06-29
AI Coding 的底层框架:一切优化都是在对抗熵增
2026-06-29
给模型写方法论:拆解一个跨法域隐私审计Skill
2026-06-28
别再手工调 prompt 了,让 Agent 自己改自己的"操作系统"
2026-06-26
OpenAI工程师首次公开!教大家榨干 Codex
2026-06-22
用AI拆解WBS:我把3天的活缩到了10分钟出框架+2小时调
2026-04-21
2026-04-07
2026-04-25
2026-04-14
2026-05-02
2026-04-20
2026-04-19
2026-04-14
2026-05-25
2026-04-18
2026-06-17
2026-05-23
2026-05-16
2026-04-14
2026-02-28
2026-02-12
2026-02-12
2026-02-08
欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。
在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。
一、 定义
本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。
会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。
知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。
二、 账号注册与登录
登录方式:本网站支持以下登录方式,您可根据实际情况选择:
微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。
手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。
账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。
实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。
未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。
三、 服务内容与规范
知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。
服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。
禁止行为:您在使用服务时不得实施以下行为:
利用技术手段批量爬取、下载、转存知识库内容;
将知识库内容用于商业目的或未经授权地向第三方传播;
干扰本网站正常运行或侵犯其他用户合法权益;
发布违法违规信息或从事违反公序良俗的活动。
四、 知识产权声明
权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。
有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。
侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。
五、 个人信息保护
我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。
您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。
您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。
六、 免责声明
内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。
不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。
第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。
七、 违约责任
如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。
如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。
八、 法律适用与争议解决
本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。
因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。
九、 其他
本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。
本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。
我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。