提示词是新的IP——看它如何悄然吞噬你的"业务逻辑"
神译局是36氪旗下编译团队,关注科技、商业、职场、生活等领域,重点介绍国外的新技术、新观点、新风向。
编者按:大多数组织仍将AI项目的资源优先投放在编写应用代码或搭建基础设施工具上,但随着大模型的能力越来越强,提示词的作用正变得越来越关键。文章来自编译。
随着AI模型不断进步,一个有趣的现象正在发生:提示词正逐渐成为企业“业务逻辑”的容器,里面浓缩了领域知识、商业机密等。显然,其关键区别在于,提示词是为机器而非人类编写的。
事实上,越来越多的应用“业务逻辑”正从传统代码转移到提示词之中。头部AI产品的提示词已开始有点像是员工标准操作流程(SOP)或工作手册,而不仅是聊天机器人指令。
如果你发现自己最近在编写更长、更“野心勃勃”的提示词,这正是我所指的趋势。
以Anthropic为Claude 3.7 Sonnet设计的系统提示词为例:该提示词冗长复杂,包含大量“该做”与“不该做”的细节,本质上像一份员工入职文档。随着推理模型改进,提示词承担更多“核心工作”的趋势正在加速——这主要得益于AI执行指令的能力已接近人类水平。
因此,提示词正迅速成为与SOP同等重要的企业资产,且更具杠杆效应——它们可嵌入AI智能体并全天候运行。这些提示词将包含敏感的内部流程、专有信息和关键商业洞察,本质上属于后大语言模型(LLM)时代的核心知识产权。而且比提示词更宽泛,其实质是整个AI的系统架构。
遗憾的是,迄今为止,许多企业仍未意识到这一转变,仍将提示词视为次于应用代码、数据和模型的二等公民。
比方说,大多数机构仍将AI项目视为传统数据科学或机器学习团队项目——优先把时间放在编写应用代码或搭建基础设施工具,而非打磨优质提示词上。在AI模型低效时代,这些属于合理的“旧习惯”,但如今这些东西正迅速贬值,拖累企业效率并增加成本。
因此,本文将:
解释提示词如何“吞噬”业务逻辑;
分析忽视这一转变的企业为何会丧失敏捷性、难以快速创新;
列举企业的典型错误及其高昂代价。
提示词正在“吞噬”业务逻辑
尽管新型AI智能体框架和模型是热议焦点(也占据了AI话题的大部分头脑份额),但近期的真正突破是AI模型理解用户意图与遵循指令的能力。
这种增强的指令遵循能力,极大降低了复杂定制化解决方案的性价比——而这些方案过去是为弥补早期模型缺陷而设计的权宜之计。
一个贴切的类比是:若雇佣未受过教育的人,你需将每个概念分解成小块,并分配简单任务,否则会压垮对方;但若雇佣的是拥有博士学历者,你只需给一本手册并说“去学吧”即可。
同理,更优秀的AI模型减少了让事情行得通所需的定制化繁重工作。随着AI智能体激增,可预见企业应用的代码库规模将缩小,因为业务逻辑正加速围绕新的三位一体(提示词、模型、数据)而非代码整合。
这也意味着AI智能体架构正趋于简化。你不再需要编写复杂的对话树或“智能体军团”来明确声明响应规则。
比方说,2025年3月的时候,你可以用一个文件写出一个AI智能体(参考OpenAI智能体SDK中稍作修改的座位预订示例)。如今,创建一个合格的客服机器人可能只需不到200行代码——大部分“业务逻辑”本质上就是提示词:
f"""
# System context
You are part of a multi-agent system called the Agents SDK..
...
# Your role
You are a seat booking agent. If you are speaking to a customer, you probably were transferred to from the triage agent.
Use the following routine to support the customer.
# Routine
1. Ask for their confirmation number
2. Ask the customer what their desired seat number is.
3. Use the update seat tool to update the seat on the flight.
....
10.
# SOP
Here are the relevant protocol(s) for you.
...
If the customer asks a question that is not related to the routine, transfer back to the triage agent. """
值得注意的是,这类提示词任何人都能用Google文档、Word、Notion等工具编写。它通常包含以下模块:
系统上下文(系统提示)
角色描述(“你的职责”)
标准操作流程(SOP)
除了提示词以外,开发者实际需要编写的代码通常不足200行,甚至少至7行(如下例所示):
seat_booking_agent = Agent[AirlineAgentContext](
name="Seat Booking Agent",
handoff_description="A helpful agent for United Airlines that can update a seat on a flight.",
instructions=PROMPT,
tools=[update_seat],
)
因此,写好提示词即可完成智能体20%-50%的开发工作(具体比例取决于场景)。提示词的权重与用例复杂度及智能体类型直接相关。对于生化研究智能体等复杂垂直领域应用,定制模型和数据集的重要性将显著提升。
核心结论是:
提示词(及整体架构设计)正取代应用代码成为价值驱动因素。
随着编码AI助手与“直觉式”工具普及,应用代码的价值已在缩水。
成功驾驭新范式需要强大的架构设计与系统性思考,而非单纯依赖传统的软件工程能力(后者正加速商品化)。率先认知并适应这一转变的企业将获得持久竞争优势。
遗憾的是,2025年的多数企业仍以传统数据科学项目模式运作AI计划,并为此付出高昂代价。
企业构建AI智能体的常见误区
出于惯性,许多企业错误地将提示词视为纯技术团队职责。这种认知存在根本错误——数据科学或技术团队不应独自承担AI智能体/自动化项目的成败责任。
这种误解还催生糟糕的工程实践,比方说将提示词直接嵌入到代码库(存在安全风险且制造冗余审查)。将提示词禁锢在代码库中,会疏离本应主导其优化的关键业务决策者。
假设将前文所述的客服提示词直接写入后端代码:每次政策或话术更新都需开发人员修改代码并重新部署。这种做法严重拖累了业务敏捷性,并让技术团队承担本不必要的负担。
事实上,开发者并非核心利益方,客服业务总经理才是!总经理应与开发者共同对提示词负责。
将提示词简单视作应用代码管理,实则是将其视为“二等公民”。多数人仍将其看作AI应用的附属组件,而非需要独立管理的核心资产。
这种做法不仅过时低效,更存在安全隐患:
提示词是企业商业知识的结晶,因此总经理、业务主管等应深度参与其设计——毕竟AI智能体放大的是他们的业务价值。可惜当前多数AI项目组与业务专家的协作远远不足。
企业应通过技术/业务方均可访问的独立平台来管理提示词。
问题根源在于工具与文化。尽管已有Langsmith、Braintrust等专业提示词管理工具,但它们多面向开发者设计,业务决策者很少被视为主要用户。
市场亟需促进跨团队无缝协作的工具。Databricks虽在数据血缘产品中引入业务方协作功能,但远未满足实际需求。
这些仅是新兴反模式中的冰山一角。随着LLM日益“智能体化”,忽视提示词核心地位的企业将付出惨痛代价。
提示词的价值分层:如何分配资源
为避免误解:不是所有提示词都一样的重要,正如并非所有业务流程都很关键一样。
优先优化哪些提示词?需明确其商业价值因场景而异:
通用型提示词:客服聊天机器人、FAQ应答、基础翻译等提示词已相对标准化。这类提示词虽需定期优化,但无法创造显著竞争优势。
高价值专有提示词:对冲基金的量化交易策略、销售团队的定价谈判规则、受监管行业的合规流程等直接关联利润中心的提示词,才是企业的“皇冠明珠”。这些提示词需要重金投入、持续迭代、严密保护。
尽早识别高价值提示词,投入顶尖人才与最强安防,严格追踪其结果表现。它们将成为值得全力守护、持续优化的核心竞争壁垒。
最佳实践建议
理解提示词作为新的竞争壁垒只是第一步——如何围绕其构建强大的智能体AI产品?企业至少应采取以下措施:
A) 严格追踪与A/B测试
在测试环境和生产环境对提示词进行A/B测试。随着AI智能体承担“更多职责”,性能监控愈发关键——就像员工需要绩效评估,智能体(及提示词)也需持续审查优化。
当下企业愿意仔细追踪社交媒体互动,却忽视提示词的性能监控。这种状况必须改变,需用科学方法量化提示词对系统输出的影响。
可选用PromptLayer、PromptFoo、Langfuse、LangSmith等工具或任意LLMOps方案。这些工具功能趋同,选择时只需考虑部署方式(开源/托管等),主流云厂商也提供类似工具。
B) 强化安全管控
对关键提示词实施严格访问控制,因其敏感性建议存储在服务端。看似常识——但多数企业误以为存入代码库即安全,实则大错特错。
C) 业务方深度参与
让业务决策者直接参与提示词设计与迭代。随着AI智能体认知能力趋近人类,需由领域专家(而非缺乏专业知识的开发团队或产品经理)承担优化责任。
切勿依赖非领域专家(如产品经理或开发者)完善提示词。尤其当AI智能体具备人类级认知时,业务方必须参与审核。
D) 实施评估驱动开发(EDD)
评估驱动开发(EDD)是个宏大课题,但其核心可概括如下:
开发AI智能体前,需预先定义何为“好结果”与“坏结果”。这些基准(或称测试用例)将成为后续所有智能体修改的对比标准,用于衡量优化方向是否正确。此类基准测试亦称为“评估基准”(evals)。
建立评估基准后,持续迭代提示词,直至其表现超越基准至满意水平(标准可基于人类直觉判断或大语言模型评估)。为避免钻成功标准的空子,需与业务决策者预先明确“成功”的具体定义。
译者:boxi。















