提示词即代码：AI业务逻辑生成的工程化实践指南

1. 从“会聊天”到“会写逻辑”提示词凭什么算代码上个月我在评审一个订单金额校验模块的合并请求。AI生成的代码看起来几乎没有问题final_amount original_amount - discount只是一行普通的减法。直到测试同学拿着一组“最终金额是负数”的用例找过来我才意识到问题出在哪——我的提示词里只写了“帮我算一下订单最终金额”却忘了告诉模型一条关键业务规则折扣金额不能超过原订单金额。这个场景放大来看就是今天想聊的核心话题提示词即代码。它不是一句口号而是一套工程规范。过去半年我所在的团队把用于生成业务逻辑的提示词当作正式代码一样管理——有版本、有测试、有评审、有负责人。效果非常直接AI输出的业务逻辑质量明显提升返工率下降了几成。很多人觉得“提示词不就是跟AI聊天吗”但真正做过业务逻辑的人会明白聊天式提问和结构化提示词之间的差距相当于口头交代和需求文档之间的差距。这篇文章就是想把这种差距讲清楚并给出可复现的方法。1.1 代码的本质是“对行为的精确约束”提示词也一样写代码这么多年我一直觉得代码最重要的不是“让计算机运行”而是“精确描述期望行为”。一个函数、一个条件分支、一个异常处理本质上都是在告诉机器什么情况下做什么什么情况下不能做什么边界在哪里。提示词面对的对象虽然是AI但原理完全一致。你在提示词里写的每一句规则、每一个示例、每一种输出格式要求都是在划定模型的行为边界。边界画得越清楚模型输出的结果就越稳定边界模糊模型就会自由发挥而自由发挥在业务逻辑场景里往往意味着隐藏bug。我用一个生活化的类比来解释你去餐厅吃饭如果只说“做点吃的”厨师大概率会按自己的理解上菜可能不是你想要的。但如果你说“不要香菜、不要辣、牛肉七分熟、配菜只要西兰花”厨师即使不认识你也能做出接近预期的菜。提示词就是这份“点菜单”写得多细结果就有多可控。1.2 口语指令和业务指令的差距究竟有多大我经常在团队里做一个实验拿同一条业务需求分别用两种方式让AI处理。一种完全是口语化表达另一种是结构化提示词。输出结果的差异非常明显。维度口语化指令结构化提示词示例“帮我看看这个订单有什么问题”“校验订单金额。规则1订单金额必须大于0规则2折扣不能超过原订单金额。按JSON输出错误码和字段名”模型行为自由判断、随意输出文字逐条规则比对、按固定格式返回结果可预期性低每次输出都可能不同高字段和错误码稳定可测试性几乎为零可以建立测试用例集口语化指令更适合闲聊、写文案、头脑风暴但一旦进入“校验金额、计算积分、生成合同条款”这类业务逻辑口语化指令就非常危险。因为模型不知道你的业务规则是什么它只能靠“常识”猜。而业务系统的常识和模型的常识往往不是一回事。1.3 这篇文章解决什么、适合谁看如果你是一名业务开发工程师经常用AI生成代码片段但总感觉不靠谱如果你是一名产品经理想让AI按业务规则输出方案但苦于说不清楚如果你是一名测试工程师想给AI生成的逻辑建立回归测试如果你是一个小团队的技术负责人想让大家用统一的方式使用AI辅助开发——这篇文章就是为你准备的。我会把提示词的六大要素、工程化的四个阶段、六个实战技术、以及一套完整的翻车排查链路全部拆开讲。没有玄学只有可以抄作业的方法。2. 拆解“机器可执行的指令”提示词六大要素写提示词不是写作文。如果把它当成代码来分析一个高质量的提示词至少要包含六个要素。这六个要素就像函数的六个部分入参、逻辑、出参、异常处理、边界声明、验收条件。2.1 角色设定先告诉AI“你是个什么人”角色设定看起来像是一种话术但它实际上是在给模型设定默认行为模式。同一套业务规则让AI扮演“严谨的财务审核员”和让AI扮演“文案助手”输出质量和风格会完全不同。举个实际例子。我们团队在做一个内部报销系统业务规则包括“发票金额不能大于报销单金额”。一开始提示词里没有角色设定AI偶尔会给出比较容忍的结果比如“金额接近可忽略”。后来加了角色设定你是一个严谨的财务审核员。你的工作准则是宁可报错不能放过可疑数据。所有数额必须精确到分所有比较必须按原始数字进行禁止四舍五入。加了这段之后模型在边界判断上的表现明显变严格了。原因也不玄乎角色设定改变了模型输出的先验分布它会倾向使用更接近该角色的措辞和判断习惯。注意角色设定不是必需品。如果业务逻辑非常简单比如只是“把中文金额转成阿拉伯数字”角色设定反而会引入多余的内容。判断标准是——这个场景是否需要特定的专业判断风格。2.2 任务描述用“动词 操作对象 约束条件”说话任务描述是提示词的核心也是最容易被写废的部分。很多人习惯写“帮我处理一下订单数据”这种描述里没有动词边界、没有约束条件模型根本不知道“处理”到底指什么。我认为比较可靠的任务描述模板是动词 操作对象 输入数据 约束条件 输出目标。举一个例子。错误的描述是帮我看一下这个订单有没有问题。正确的描述是校验订单对象中的金额字段。订单金额必须大于0折扣金额不能大于订单金额。如果订单不合法输出错误码和对应字段名如果合法输出 SUCCESS。发现区别了吗正确版本里“校验”是明确的动词“订单金额必须大于0”是约束条件“输出错误码和字段名”是输出目标。模型不需要猜测你想干什么它只需要按规则执行。2.3 上下文与示例给模型装一个“坐标系”大模型本质上是一个基于统计的生成器它非常擅长“模仿”。所以如果你希望模型按某种格式输出最好的方式不是反复强调而是直接给它一两个示例。这就是 few-shot 的作用。我在团队里推过一个原则每个提示词至少包含两个示例一个正常分支一个异常分支。比如订单校验的提示词里我会写示例1 输入{order_amount: 100, discount: 20} 输出{result: SUCCESS} 示例2 输入{order_amount: 100, discount: 150} 输出{result: ERROR, error_code: DISCOUNT_EXCEEDED, field: discount}不要小看这两个示例。模型只要看到一次“输入-输出”的配对就能推断出格式规律和判断标准。比在文字里反复强调“请按JSON格式输出”有效得多。甚至有些复杂的业务规则文字描述半天讲不清给一个正例一个反例模型立刻就明白了。2.4 输出格式把“自由发挥”变成“结构化交付”业务逻辑场景里最忌讳的就是AI给你一堆散文式的回答。不是说散文不好而是散文没法接入下游系统。如果想让AI输出的结果直接被代码解析就必须在提示词里定义严格的输出格式。最常见的做法是要求输出JSON并且明确字段名、字段类型、取值范围{ result: SUCCESS 或 ERROR, error_code: string当result为ERROR时必填, field: string出错字段名无错误时为空字符串 }这段JSON定义本身就是提示词的一部分。我会把它直接复制进提示词然后补充一句“只能输出JSON对象不要输出任何解释性文字”。格式定义还有一个隐藏作用它让模型在生成阶段就进入“结构化模式”而不是“散文模式”。很多人在实测后会问为什么定义了JSON还经常解析失败大概率是因为格式定义不够详细或者给了模型太多自由发挥的余地。2.5 边界与禁忌告诉模型什么“不能做”业务逻辑和通用聊天最大的区别在于业务规则通常有明确的底线。比如“缺失字段时不能自己脑补”“金额为负数时不能自动取绝对值”“没有授权记录时不能默认通过”。这些底线如果不写进提示词模型很可能会根据自己的“常识”帮你做决定。我给提示词加禁忌条款的标准写法是禁止事项不得自行推导或补全输入数据中缺失的字段发现缺失时返回 DATA_MISSING。不得修改任何输入数据所有计算必须基于原始输入。不得在输出中追加解释、建议或注意事项。注意禁忌条款不是越多越好。写几十条“不要”模型反而会变得畏手畏脚。正确做法是只写那些真正会致命的禁忌每条禁忌最好配合一个正向的替代指令。比如“不要修改输入数据”其实是“如果输入数据有误返回错误码而不是自行修正”的简化表达。2.6 验收标准让AI理解“什么叫做完、做好”很多提示词写了任务、写了规则却在最后缺了一个关键环节——验收标准。所谓验收标准就是在提示词里要求模型在输出结果前先做自检或者输出一个自检签名。我常用的办法是让模型在返回业务结果前先输出一个“检查清单”字段。比如在输出最终结果之前请依次执行以下自检是否逐条比对了所有业务规则是否检查了所有输入字段的边界值是否在违反规则时返回了正确的错误码 如果自检不通过先修正再输出。这种“自检指令”看起来有点多余但它对模型的纠错效果非常明显。原理可以理解为模型在生成完整文本的过程中最后一个部分会受到前面所有内容的影响。如果让它再“想一遍”规则它相当于多一次推理机会很多明显错误会在这个阶段被修正。3. 从“一段话”到“一套逻辑”提示词工程化的四个阶段很多团队用AI生成业务逻辑只是把需求从口头搬到提示词框里没有版本、没有测试、没有迭代流程。这就像一个人写代码从不进版本库、不写测试一样短期可以跑长期必然出事。我把提示词的工程化分成四个阶段团队里每个人都按这个流程走。3.1 草稿阶段把业务规则完整“翻译”出来我观察到的第一个高频问题是很多业务规则没有“写全”。需求评审会上可能讨论了几十条规则最后记录到文档里只有十几条再转成提示词只剩几条。业务规则丢失的过程是逐层衰减的。所以草稿阶段的核心任务不是写提示词而是把业务规则完整收集起来。我们团队在需求评审后会额外开一个“规则翻译会”把所有业务规则逐条列成一张检查表每条规则必须能回答三个问题——输入是什么、判断条件是什么、违反时输出什么。比如积分计算规则不能只写“下单送积分”而要写清楚基础积分实付金额每满1元送1积分不满1元不计。新用户首单额外赠送100积分。退款订单发生退款时扣除对应积分如果积分已使用扣除后允许负数。草稿写完之后才把它翻译成提示词。这个阶段不需要追求格式完美但一定要追求逻辑完整。3.2 结构化阶段模块化、变量化、加标签草稿阶段的提示词通常是一大段文字混在一起。进入结构化阶段后我会把它拆成四个固定模块系统指令、业务规则、输入数据、输出规范。模块之间用明确的分隔符隔开。实践中比较推荐这样的结构【系统指令】 你是一个严谨的订单审核员只依据以下规则判断禁止引入外部常识。 【业务规则】 - 规则1订单金额必须大于0。 - 规则2折扣金额不能大于订单金额。 - 规则3若数据缺失返回 DATA_MISSING。 【输入数据】 { order_amount: 100, discount: 150 } 【输出规范】 只能输出JSON对象格式如下 { result: SUCCESS 或 ERROR, error_code: string, field: string }用方括号、分隔符或者XML标签都可以关键是让模型能清楚区分“规则”“输入”“输出”三类信息。这样的结构化提示词无论是调试还是版本对比都远比一大段口语文字好用。3.3 版本化阶段像管理代码一样管理提示词提示词一旦进入稳定运行阶段就要纳入版本管理。我们团队的做法是把每个业务提示词放在项目仓库的prompts/目录下命名规则是“业务模块 版本号”比如prompts/order_amount_checker/ v1.md v2.md README.md每个版本的变更记录写在文件头部# order_amount_checker v2 ## 变更记录 - v2: 增加规则2折扣金额不能大于订单金额。 - 原因线上出现负数订单根因是提示词未约束折扣上限。 - 影响范围订单金额校验接口。 ## 当前规则 ...版本化最大的好处是当AI输出的业务逻辑出问题时可以快速定位“当前提示词是从哪个版本开始出错的”。没有版本管理的提示词排查问题只能靠猜非常被动。3.4 测试与迭代阶段回归测试、边界测试、评分体系提示词也需要测试而且需要有回归测试。我们团队为每个业务提示词建了一个测试集里面至少包含30个用例覆盖正常分支、异常分支、边界分支。每次修改提示词后都要跑一遍这30个用例。测试用例长这样用例编号输入期望输出TC01{amount: 100, discount: 20}SUCCESSTC02{amount: 100, discount: 150}ERROR, DISCOUNT_EXCEEDEDTC03{amount: 0, discount: 0}ERROR, AMOUNT_INVALIDTC04{amount: abc, discount: 0}ERROR, TYPE_INVALID因为大模型输出存在随机性同一个用例跑十次可能不会全部成功所以不能只盯“通过/失败”还要引入一个评分体系。我常用四个维度评分准确率结果是否正确、格式合法率JSON是否可解析、错误码覆盖率是否覆盖测试集中的错误码、平均通过率每条用例多次执行的稳定性。当平均通过率低于某个阈值时这个提示词不能上线。4. 精准指挥AI的六个实战技术前面讲了要素和流程这一节是真正动手时的六个技术。这些技术在业务逻辑场景里非常有效也是我平时用得最多的手段。4.1 分段指令替代一段式长命令把一个大任务拆成多个小步骤让模型按顺序执行。比如第一步解析输入JSON提取 order_amount、discount 字段。 第二步检查字段是否存在。任一字段缺失直接返回 DATA_MISSING。 第三步检查 order_amount 是否大于0。 第四步检查 discount 是否大于 order_amount。 第五步按输出规范返回结果。分段指令的好处是降低模型的理解负担。大段长命令里规则之间的逻辑关系很容易被模型混淆拆成步骤后每一步只做一个判断出错的概率明显降低。这背后其实和人类处理复杂任务的原理一样——工作记忆有限拆解就能提高精度。4.2 问句链让模型自己当一回测试工程师我前面提过“自检”而问句链是它的进阶版。做法是在提示词末尾加一组问题在给出最终输出前请回答以下问题输入中是否存在缺失字段order_amount 是否大于0discount 是否大于 order_amount所有答案检查完毕后再输出最终JSON。模型生成文本的过程是“逐字生成”的前面生成的内容会影响后面。让它先思考问题再输出结果就等于给了它一次“推理缓冲”。实测下来这一步能纠正掉相当一部分规则遗漏问题。4.3 用伪代码描述业务规则如果业务规则比较复杂直接用自然语言写可能不够精确。这时我会在提示词里嵌入伪代码效果往往更好。比如IF order_amount 0 THEN RETURN ERROR(AMOUNT_INVALID) IF discount order_amount THEN RETURN ERROR(DISCOUNT_EXCEEDED) IF discount 0 THEN RETURN ERROR(DISCOUNT_INVALID) RETURN SUCCESS伪代码的优势是确定性强。模型对代码模式的掌握比口语化描述更扎实把业务规则写成伪代码相当于直接给模型一张“施工图”它只需要翻译成目标语言不需要自己重新设计逻辑。但要注意伪代码风格要统一否则模型可能跟着你的风格“跑偏”。4.4 否定指令压缩错误范围而非吹嘘绝对正确在提示词里加“不要做”确实有用。比如“不要返回非JSON内容”“不要忽略缺失字段”这些否定指令能明显压缩模型的错误空间。但也要清楚否定指令只是辅助手段它不能替代正向规则。一个常见的反效果是否定指令太多模型会过度保守该下判断的时候犹豫不决。比如你写了“不要在不确定时给出结论”模型可能真的就只返回“不确定”导致业务处理停滞。所以我的经验是每条否定指令都要配备一条正向指令告诉模型它应该怎么做。4.5 温度参数控制创造力的开关温度参数直接影响了模型输出的随机性。业务逻辑场景和创意文案场景对温度的需求正好相反。场景推荐温度范围原因业务逻辑、规则判断、代码生成0.0 ~ 0.3需要稳定、可复现的输出文案、创意、方案发散0.7 ~ 0.9需要多样性、跳出常规很多人误以为温度设为0.0模型就不会随机了。但实际上即使温度是0模型在采样时仍可能存在一定随机性尤其是复杂推理场景。所以无论在哪个配置下下游解析和校验层都不能省。4.6 结果解析与校验把AI输出接回业务系统所有大模型输出都不能直接当作可信数据进入业务系统。正确做法是在模型和业务系统之间加一层“解析与校验网关”专门处理AI的输出。我习惯在解析层做三件事检查是否为合法JSON不是则重试一次。检查字段名和数据类型是否符合预期。检查字段值是否在业务允许的范围内。如果重试后仍然解析失败就走人工告警。网上很多说AI“不稳定”的抱怨其实一半是提示词问题另一半是缺少解析兜底。只要这层网关足够健壮模型的偶发输出异常就不会直接冲击业务。5. 业务逻辑“翻车”后的完整排查链路提示词写得再好也会有翻车的时候。关键不是赌它不翻车而是建立一套从“复现”到“修复”的排查流程。5.1 一个真实复现订单金额变成负数回到开头那个案例。AI生成的代码看起来正常但业务逻辑漏了“折扣不能大于原订单金额”这条规则。完整的排查过程是这样的第一步复现。我手动构造了一组输入order_amount100, discount150调用AI生成的校验逻辑果然返回了final_amount-50没有报错。第二步最小化用例。把输入精简成只含两个字段金额和折扣。这能排除其他字段干扰。第三步检查提示词原文。我把当时的提示词重新读了一遍发现里面只写了“计算订单最终金额”完全没有提到折扣上限。问题不在模型而在提示词规则缺失。第四步修改提示词。在规则区加入“折扣金额不得大于订单金额如果违反返回错误码 DISCOUNT_EXCEEDED”并加上一个反例。第五步回归测试。把这条用例加入测试集跑完所有相关提示词的测试用例确认没有影响其他规则。这一步看似简单但关键习惯是不要一翻车就归咎于模型先检查提示词是否完整描述了业务规则。80%的业务逻辑翻车根因是提示词本身的规则缺失。5.2 上下文污染长对话让逻辑悄悄漂移另一个常见的翻车原因是上下文污染。有一次同事在同一个会话里连续问了十几个问题前一个问题涉及“优惠券不能叠加”后面的问题本意是“计算订单实付金额”结果模型把优惠券规则也带了进去。解决方案是把对话式调用改成“单轮独立调用”。每次调用只传入当前业务所需的上下文不传历史记录。尤其在生产环境永远不要在同一个会话里堆叠多个业务请求。你省下的那点上下文成本远不及一次逻辑串味带来的排查损失。5.3 输出格式不稳定解析层必须兜底即使提示词里反复要求“只能输出JSON”模型偶尔还是会犯错。我遇到过的格式问题包括JSON里带注释、字段名带了前缀、缺少必填字段、把数字输出成字符串。这些问题的共同点是它们无法100%靠提示词消除。所以我在解析层做得很保守先尝试一次标准json.loads失败后清理注释再试一次如果还失败返回“格式错误请重新生成”。这套兜底策略把格式问题导致的上线事故降到了很低的水平。5.4 小样本陷阱与注意力稀释给模型的规则太少模型学不会给太多模型会“注意力稀释”尤其是放在中间位置的规则很容易被模型忽略。这有点像人类做阅读理解时记不住长文中间细节一样。我建议的规则排序策略是最重要的规则放在提示词开头和结尾次要规则放中间。如果有超过十条规则考虑拆成多个小提示词分别处理再用最后一道步骤汇总结果。规则重要性放置位置示例致命规则开头 末尾重复强调金额不能为负、折扣不能超过原价普通规则中间税率四舍五入到分边缘规则单独的分支指令会员等级不同积分倍数6. 落地配置与个人经验提示词工程化的最后一公里流程和方法都讲完了这一节分享一套可以直接复制的基础模板以及我们在团队落地过程中的一些经验。6.1 一套可复用的基础提示词模板下面是我目前在带团队时默认使用的基础模板几乎所有业务逻辑提示词都从它扩展而来【角色与目标】 你是一个严格的业务规则执行器。你不对规则做任何增删只按给定的规则输出结果。 【输入数据】 (此处填入JSON数据) 【业务规则】 规则1必填字段缺失时返回 DATA_MISSING。 规则2(具体规则) 规则3(具体规则) 【输出格式】 只能输出JSON对象不要输出多余文字。 { result: SUCCESS 或 ERROR, error_code: stringERROR时必填, field: string出错字段名无错误时为空字符串 } 【示例】 示例1输入(一个正常用例) - 输出(期望输出) 示例2输入(一个异常用例) - 输出(期望输出) 【自检清单】 输出前请确认是否逐条检查了所有业务规则缺失字段是否已返回 DATA_MISSING模板的意义不是给你一个银弹而是提供一个大家都能遵循的共同起点。模板定下来后不同团队成员的提示词至少结构一致评审和测试都会轻松很多。6.2 团队协作提示词要有Owner、评审和变更单提示词工程化最大的阻力不是技术而是习惯。很多人习惯了随手粘贴一段话不愿意走评审流程。所以我在团队里定了一条规矩凡是进入生产环境、影响业务结果的提示词必须有Owner、有评审、有变更单。Owner负责这个提示词的业务正确性评审时至少拉上一位业务方、一位后端开发、一位测试变更单记录改动内容、原因、影响范围。改动一个提示词就像改动一段代码不能拍拍脑袋就上。一开始流程会显得繁琐但当你经历过一次因为提示词随手修改导致线上逻辑损坏的事故后就会发现这些流程全是护身符。6.3 线上日志反哺提示词提示词的迭代不能只靠评审还要靠线上日志反哺。我们的做法是每天抽看线上AI调用的异常返回把出错样本按类别归拢是规则缺失、格式异常、还是上下文污染。每积累一批问题就统一更新提示词和测试集。比如我们曾通过日志发现许多订单的 discount 字段没有传但模型居然默认 discount0 继续计算。我们当时没有在提示词里定义“字段缺失”的处理方式模型就用常识脑补了。后来在规则1里补充“缺失字段返回 DATA_MISSING”这个问题当场解决。6.4 我个人的一点心得最后分享一个我踩过很多次坑之后形成的认知也是这个标题的最终答案“提示词即代码”的真正含义是把提示词当成一种需要精确管理、持续维护、有生命周期的软件资产。我最开始也把模型当成一个“什么都知道的业务专家”后来发现它更像一个执行力很强、但需要明确需求的初级工程师。你给它多少确定性它还你多少可靠性。那些看起来“很聪明”的AI回答在业务逻辑场景里往往是风险源而那些稳定、无趣、严格按照规则输出的结果才是真正能上生产线的逻辑。所以我的建议是不要追求让AI“懂你”要追求让AI“不用懂你也能做对”。这份确定性就藏在每一版提示词的细节里。