企业官网建设流程全解析

我见过太多AI项目死在“架构完美”这四个字上。

做了这几年AI工程化落地，最深的体会是：大多数业务场景根本不需要微服务、不需要Agent编排、不需要多层抽象，你缺的只是一条把提示词写透的命脉。这个行业有个很奇怪的现象，大家一边喊着“提示词工程已死”，一边又在没有任何业务沉淀的情况下，用LangGraph堆出五层深的Agent拓扑图。结果呢？上线两周，维护成本直接吞掉收益，最后连提示词里一个标点符号都不敢改，因为一改就崩。

这篇内容我不谈高深理论，就聊聊怎么把“完美架构”拉下神坛，让提示词回归它该有的位置。文章会覆盖方案选型背后的真实考量、提示词怎么写才能扛住工程化考验、什么时候必须要上框架、以及我踩过的那些坑。适合正在做AI应用落地、被复杂架构折腾得够呛、想把提示词基本功打扎实的团队和个人。

1. 内容整体设计与思路拆解

1.1 为什么“完美架构”是个陷阱

先说个真实经历。去年有个做智能客服的团队找我做技术评审，他们用LangGraph搭了一套相当完整的Agent系统：有意图识别路由、多轮对话状态管理、外部工具调用、记忆持久化，甚至还做了基于向量数据库的长期记忆模块，架构图画了整整三页A3纸。但你猜上线后最大的问题是什么？

不是架构不够先进，而是用户问一句“我的订单什么时候到”，系统愣是绕了三轮工具调用才回答出来，延迟从800ms飙到3200ms，而且答非所问的概率高达17%。

问题出在哪？团队成员花了90%的精力在编排Agent的节点流转上，写的提示词却只有可怜巴巴的几十个字。模型根本不知道什么情况下该直接回答，什么情况下才需要调API，更不知道如何从调用结果里提取用户真正关心的信息。

这就是典型的“架构崇拜症”。框架本身没有错，但当你用复杂的工程手段去掩盖提示词设计的懒惰时，系统复杂度会指数级上升，而效果提升却可能是负数。

我并不是反对复杂架构，而是反对无脑复杂。一个成熟的做法是：先用最简单的结构把业务流程跑通，确认提示词本身能稳定产出预期结果，之后再根据真实的瓶颈点决定是否引入更重的组件。大多数团队的问题在于，他们跳过了验证提示词的阶段，直接冲进了框架的深水区。

1.2 提示词的本质是“交互契约”而不是“咒语”

很多人把提示词工程神话化了，觉得写提示词就像念咒语，得找到某种特定的措辞才能解锁模型的能力。这种认知偏差导致团队里永远在“试prompt”，试出一个效果不错的就当宝贝一样藏着，但换个场景、或者模型底座一升级，立刻失效。

我个人的观点是：提示词的本质是一份你与模型之间的“交互契约”。你需要在有限上下文中，明确告诉模型四个问题：

1. 我（用户）是谁、我需要解决什么问题
2. 你（模型）扮演什么角色、具备什么能力边界
3. 我给你什么输入、期待你返回什么格式和内容
4. 有哪些边界条件、禁区、兜底策略必须遵守

把提示词当成契约来写，思路就完全不一样了。你不会再去堆砌华丽的辞藻，而是会像一个认真的产品经理写PRD一样，逐条核对边界条件，用结构化模板固定输出，甚至为模型设计好“不知道怎么办”时的预案。

契约化提示词还有一个附带好处：可测试性大幅提升。因为你是按照业务需求拆解出条款的，所以每条条款都能转化为独立的测试用例。这为后续的回归测试、效果评估、模型切换都打下了基础。

1.3 工程化的真正门槛是“确定性”，不是“复杂度”

回到“AI工程化”这个词本身。很多人一听到工程化，第一反应就是上框架、搞编排、做微服务。但工程化的核心追求其实是确定性——无论用户怎么变化输入，系统都能稳定输出符合预期格式和内容的结果。

但大模型本身就是概率系统，同一个输入，温度参数没动，输出的措辞都可能有细微差异。你没法让模型绝对确定，但可以通过提示词结构、参数配置、输出校验等环节，把不确定性压缩到可控范围。

这就是为什么说提示词才是工程化落地的最小单元。每一个提示词模板都是一份可维护、可版本管理、可测试的代码资产。你连这个资产都做不扎实，在上面搭建的任何架构都是沙地起楼。

2. 核心细节解析与实操要点

2.1 写提示词的“三层建筑”结构

我把一个工程级提示词拆成三层：角色与目标层、流程与规则层、输出与兜底层。你用这三层去审视自己的提示词，会发现很多失效问题都能立刻定位到具体哪一层没写透。

第一层：角色与目标层。这一层用一两句话说清楚模型的身份设定和核心任务。比如“你是一个订单查询助手，你的工作是根据用户输入的订单号，调用查询工具获取物流状态，并用简洁清晰的中文反馈给用户。”这里的关键是“身份”和“目标”要双明确，不能让模型既当客服又当推荐算法工程师，它会精神分裂。

第二层：流程与规则层。这层负责约束模型的行为路径，包括先做什么、再做什么、哪些情况下必须触发工具调用、哪些情况下可以直接回答。实际经验是，这层写得越接近“决策树”，模型的稳定性越高。比如，对于订单查询场景，我会明确写“当且仅当用户提供了完整订单号时，才调用查询工具；缺乏订单号时，直接向用户索要，不得臆造订单信息。”

第三层：输出与兜底层。这层定义输出格式模板，以及模型遇到模糊输入、识别失败、权限不足等边缘情况时的兜底回复。输出格式建议用严格的模板语法（JSON或XML都可以），并明确字段含义。兜底回复最好提供参考话术，避免模型自己发挥出一些“不专业”的表达。

注意：这三层不是让你机械拼凑，而是引导你的思考方向。真正动手写的时候，三者的比例取决于具体场景的复杂度。规则密集的流程型场景，第二层占比最高；创意发散型场景，第一层的角色设定则要更精细。

2.2 上下文管理的四个“黄金准则”

提示词工程里最容易被忽视的就是上下文管理。很多人只关注了“提示词怎么写”，却忘了提示词只是整个对话上下文的一部分。系统的历史消息、工具返回结果、用户多轮输入，都在抢占有限的上下文窗口。

实战中我遵守四个准则：

准则一：把系统提示词当“宪法”而不是“散文”。核心规则要精炼、无歧义、优先级清晰。如果规则之间有冲突，模型会无所适从。比如你既说“必须调用工具获取最新数据”，又说“当数据缺失时可直接基于常识回答”，这就矛盾了，模型会在不同请求下随机执行一条，你还没法归因。

准则二：历史消息做裁剪与摘要，而不是全量塞入。上下文窗口再大也扛不住无限增长。我的策略是，保留最近两轮完整对话，更早的历史消息通过一个专门的摘要Agent（也可以用固定提示词+模型完成）压缩成结构化小结。这个步骤能显著降低token消耗，同时减少模型被无关历史干扰的概率。

准则三：工具返回结果要二次加工，不能直接拼接给模型。工具返回的原始内容往往包含大量噪声，直接丢给模型会稀释关键信息。正确的做法是在代码里做字段提取、格式转换，甚至先让一个小模型做一次提炼，再把精炼后的结构化数据交给主模型。

准则四：核心指令放置在系统提示词的开头和结尾。这个跟前段时间热门的“Lost in the Middle”现象有关，Transformer架构对长上下文中间位置的信息利用率偏低。所以我会把最重要的约束放在开头，把输出格式要求放在结尾，中间部分放次重要的背景说明和参考资料。

2.3 让输出从“开放作文”变成“填空题”

在业务系统里接大模型，最让人头疼的就是输出解析。模型返回的东西稍微偏离你预期的JSON结构，整个下游流程就全崩了。

所以我在设计提示词时，会刻意把它从“开放作文”变成“填空题”。核心手段就是输出格式的强约束与配套的解析容错。

具体做法是，在提示词末尾给出一个非常明确的输出模板，例如：

输出要求： 请严格按照以下JSON结构输出，不要输出任何额外解释、注释或Markdown代码块标记： {"intent": "目标意图分类，取值只能是query_order/consult_others/ambiguous中的一种", "order_id": "从用户消息中提取的订单号，如果没有提取到输出null", "reply": "你对用户的直接回复内容，使用自然中文"}

这个模板表面上很简单，但需要注意几个细节：枚举值必须提前在提示词正文里定义好，否则模型可能自创你从未见过的分类；字段的含义要写清楚，避免模型把“null”当成字符串；告诉模型“不要输出Markdown代码块标记”这一点，能省掉你大量清洗的工作。

即使做到这个程度，我依然建议在代码层做一层schema校验和字段兜底。模型毕竟是概率模型，偶尔不听话是正常的。校验不通过时，可以设计一次自动重试，比如在下次请求时把上次的错误原因附加到提示词中，让模型自行修正。这比单纯在代码里写正则解析要稳健得多。

3. 实操过程与核心环节实现

3.1 场景定义：把“模糊需求”变成“明确输入输出”

为了把上面的思路具体化，我拿一个常见的提效场景来完整演示一遍：售后工单分类与优先级判断助手。这个场景特别适合说明提示词的工程化写法，因为它既包含分类、又包含信息提取、还涉及决策建议，非常考验提示词的结构设计。

业务方最初给我的需求是这样的：“帮我们写个提示词，自动识别用户提交的售后问题是什么类型，重不重要，并给出处理建议。”

听着很模糊对吧？第一步要做的是需求澄清，把它转换成工程化的输入输出定义：

• 输入：用户在售后工单系统里填写的文本，可能包含订单号、故障描述、期望诉求等，也可能只有一句话，甚至是包含错别字的句子。
• 输出：包含工单类型（分为物流类、质量类、退货退款类、咨询类、其他）、紧急程度（高/中/低）、关键实体（订单号、商品名称、具体问题摘要）、以及给客服人员的处理建议。
• 约束：如果信息缺失，不能臆造；如果信息模糊，类型标记为“其他”并备注原因；紧急程度的判断必须考虑时效性表述（如“明天要开会用”就是高优先级信号）。

这步非常关键，因为提示词的每一条规则，都应当能从需求文档里追溯来源。没有经过这一步的提示词，写出来就是无根之水，效果好坏全凭运气。

3.2 编制提示词模板：从“能用”到“好维护”

定义清楚输入输出后，我按三层结构写出如下模板（节选核心部分）：

[角色与目标] 你是一名资深售后客服质检专家。你的任务是根据用户提交的工单文本，完成工单分类、紧急程度评估、关键信息提取和处理建议输出。 [流程与规则] 1. 首先通读用户工单全部内容，识别用户意图。 2. 判断工单分类：如果用户提到物流时效、配送异常、签收问题等，分类为“物流类”；如果提到商品破损、性能故障、描述不符等，分类为“质量类”；如果明确提出退货、退款、换货等诉求，分类为“退货退款类”；如果只是一般咨询或表达不满但无具体诉求，分类为“咨询类”；其余无法明确归类的，分类为“其他”。 3. 判断紧急程度：当且仅当工单中出现如下信号之一时，标记为高优先级：A. 用户明确说明时间紧迫（如“明天就要用”）；B. 问题涉及安全或健康隐患；C. 用户已经表现出强烈负面情绪（如多次投诉、愤怒用语）。若同时存在多项信号，在“紧急原因”字段汇总说明。 4. 提取关键实体时，订单号必须按用户原文完整提取，不得补齐位数；商品名称可从上下文推断，不确定时输出null。 [输出与兜底] 严格按照以下JSON结构输出，不要输出任何额外解释、注释或Markdown代码块标记： {"ticket_category": "分类结果，只能取物流类/质量类/退货退款类/咨询类/其他", "urgency": "紧急程度，只能取高/中/低", "order_id": "订单号，未提取到则输出null", "product_name": "商品名称，无法确定则输出null", "issue_summary": "一句话说清问题核心，不超过30个字", "suggestion": "给客服的处理建议，不超过50个字"} 当用户工单内容为空或完全无法理解时，ticket_category输出“其他”，urgency输出“中”，suggestion输出“该工单信息不明确，建议客服联系用户确认具体问题”。

这个模板看着不复杂，但每一句都有讲究。分类规则里给出了具体的语义映射词（“如果提到...则...”），这是为了减少模型对分类标准的自行发挥。紧急程度的判断规则用了“当且仅当”以及明确的信号枚举，这基本杜绝了模型把“用户说了一句狠话”就标记为高优先级的情况。

3.3 参数选择与循环优化流程

提示词写完之后不是终点，参数配置和优化迭代才是真正拉开效果差距的地方。

温度参数方面。工单分类和紧急程度判断属于确定性要求极高的任务，温度建议调到0或者0.1。有些团队担心温度过低会导致模型重复输出，但实际上对于这种填空式任务，低温度带来的稳定性收益远大于多样性损失。如果做创意文案生成，温度才需要调到0.7以上。

评估集方面。没有评估集，就没有提示词工程。我在上线前一定会整理一份覆盖各种场景的测试工单样本集，通常50到100条，里头既要有典型的正常样本，也要有刁钻的边缘样本（比如缺订单号的、全是大白话的、包含错别字的、故意引导模型臆造信息的）。每次调整提示词后，都跑一遍全量样本，对比输出差异。

这里推荐一个比较“土”但非常有效的方法：把历史工单中人工客服的最终处理结果作为参考答案，用LLM作为裁判（或者人工抽检）评估模型输出的准确率。当一次修改导致某几类样本的准确率明显下降时，就需要慎重考虑是否回滚。

版本管理也不能忽视。提示词的每一版修改都要记录变更原因和效果对比，我习惯用Git管理提示词文件，提交信息里写明“把紧急程度判断规则从关键词匹配改为语义信号枚举，物流类准确率从72%提升至89%”。这份记录是你最宝贵的团队资产。

4. 常见问题与排查技巧实录

4.1 模型不遵守输出格式，怎么办

这是被问得最多的问题，也是压垮很多人的最后一根稻草。排查顺序我建议是：

• 第一步：确认你在提示词里是否给出了无歧义的模板。很多人只是写了“输出JSON格式”，但没给模板结构，模型就会自由发挥。解决方法是给出具体的JSON示例，并明确说明“严格按该结构输出”。
• 第二步：检查是否是模型能力问题。小参数模型对复杂格式的遵循能力确实弱一些。如果你用的模型本身就不擅长指令跟随，那么除了换大模型，还可以考虑在代码层做一次“格式修正调用”，让模型修正自己的输出，而不是靠分析日志去调提示词。
• 第三步：检查是否输出内容超出了上下文窗口。有时候模型在生成过程中上下文被截断，导致JSON不完整。这种情况可以在代码层做截断保护，并显式要求模型先输出一个合法JSON，再补充其他解释。

4.2 加规则后效果反而变差，怎么回事

这很常见，我就遇到过。一开始提示词只有简单角色和输出模板，准确率75%；为了提升效果，我增加了一大堆细化规则，结果准确率掉到68%。原因很简单：规则之间互相干扰，模型被前后矛盾的内容搞晕了。

排查方法也直接：把新增规则逐条回滚，每次只保留一条新规则并跑评估集，找到那个拉低准确率的元凶。通常出问题的规则是“特殊例外”型描述，比如“除非用户要求加急，一般按常规流程处理”。这种例外描述会让模型在判断时过度发散，尤其在低温度下容易形成隐秘的偏见。我的建议是核心场景少写例外，把例外留到提示词下方的“边界情况说明”区域集中描述，并确保每条例外都有明确触发条件。

4.3 同一套提示词，换了模型底座就崩，正常吗

太正常了。不同模型对指令的理解能力、措辞敏感度、学习到的对齐偏好完全不同。同一个提示词在GPT模型上表现优秀，换到开源模型可能直接词不达意。

这个问题没有一劳永逸的解法，只能靠流程来缓解。我的做法是：在提示词文件里记录“目标模型版本”字段，一旦更换模型底座，必须重新过一遍评估集，把不达标的样本找出来，逐条对比新旧模型的输出差异，然后针对性调整措辞。通常来说，规则越具体、越接近“你认为你应该怎么做”的表述，跨模型的迁移能力越强；而那些过于依赖模型自身世界知识的隐晦表达，迁移时最容易出问题。

4.4 如何用最小成本做出“评测集”

很多人一提评测集就头疼，觉得是很大的工程。其实起步阶段不需要搞多复杂的平台，一个Excel或者在线表格就够用。

我给团队的建议是，维护一个四列的表格：编号、测试输入、期望输出、实际输出。期望输出这一列先人工标注。每天把模型的结果跑出来填到第四列。每周汇总一次，看看哪类样本的错误率最高，再针对性修改提示词。这个流程跑上一个月，你对模型和业务的理解深度会远超那些迷信复杂评测系统的人。

表格的规模控制在50条以内就够起步了。关键是覆盖面和持续更新，而不是一开始就追求上千条样本。

4.5 实操心得：让提示词和代码共同演进

最后说一个容易被忽略的工程化准则：提示词不是孤立的文本文件，它是整个代码系统的一部分，应该和代码一起演进。当业务逻辑调整时，同步修改提示词里的规则；当输出字段变化时，同步更新解析校验模块；当发现某个错误是因为提示词边界不清晰时，把它固化成一条新的测试样本。

这样做的好处是，你永远不会出现“代码看起来没问题，但效果就是不对”的尴尬情况，因为你已经把提示词质量监控嵌入到了正常的开发流程里。

5. 工具选型解析与架构取舍心得

5.1 何时该上框架，何时不该上

关于要不要用LangChain、LangGraph或者别的Agent编排框架，我给自己定了一个判断标准，称为“三问”：

一问：你的流程是否真的是DAG（有向无环图）式的固定流转？如果是，框架的节点编排能力才有意义。如果只是“判断一下→调用一次模型→返回结果”这样的一跳路径，用框架纯属增加复杂度。

二问：团队里每个人是否都能理解“提示词+上下文”这种朴素的交互模型？如果让一个没接触过底层概念的新人直接面对框架抽象出来的Agent状态机，调试一个bug可能要花掉数天时间，而且问题往往最后还是会归结到某个节点内部提示词写得不好。

三问：你当前的瓶颈究竟是“流程编排复杂性”还是“单点效果不足”？绝大多数场景，瓶颈是后者——模型调用一次就不够准，你再怎么编排也无济于事。

我在实际项目里见过的最理想形态，往往是薄框架、厚提示词。也就是用最少的代码胶水把流程串起来，把绝大部分脑力投入到提示词设计、上下文管理和结果校验上。这套组合在大多数提效工具类、客服类、知识库问答类场景里，都是性价比最高的选择。

5.2 架构设计的一个更优解：能力原子化

如果你想给自己的AI应用增加一点工程化色彩，又不想陷入复杂框架的泥潭，我建议从“能力原子化”入手。

所谓能力原子化，就是把一个完整的AI应用拆成若干个独立的“原子能力”，每个原子能力内部由一条或几条提示词模板、必要的预处理逻辑、输出校验逻辑组成，对外暴露一个稳定的函数接口。

比如一个售后客服AI应用，可以拆成：工单分类能力、紧急度评估能力、回复生成能力、情绪安抚话术能力、工单摘要能力。这些能力各自独立开发和测试，上层业务逻辑只是把它们按顺序组装。

这套架构的好处是：

• 你可以单独优化某一个能力，而不会影响其他环节。
• 每个能力的提示词都放在同一个目录下管理，谁出了问题一目了然。
• 后续如果要引入更复杂的编排框架，这些原子能力可以直接作为框架节点复用，不存在推倒重来的问题。

我个人非常建议团队内部先按这套思路落地，哪怕最终不需要框架，也有人能把这个架构讲清楚。

5.3 别和高层技术概念较劲，回归场景本身

我遇到过一些团队，特别执着于向老板或客户展示自己用了多少新技术——Agent、多模态、向量数据库、RAG全套，仿佛技术名词越多，项目就越高级。

但到了交付阶段，客户问的第一句话永远是有没有解决我的问题。你架构图上画的每个节点，在客户眼里都可能变成一个故障率更高的风险点。技术选型的首要标准永远是业务契合度，而不是简历好看程度。

这也是为什么我特别推崇“回归提示词本质”。复杂的架构可以带来效率的倍增，但它必须以扎实的提示词基本功为前提。先让模型在简单结构里稳定输出，再用架构解决问题，这个顺序不能反。

最后分享一个小技巧

把提示词当作代码一样对待，而不是当作“写在文本框里的一句话”之后，很多麻烦会不攻自破。每个提示词模板都要有版本记录，每次修改都要跑一遍你的迷你评测集，每次上线前都要检查一遍：角色目标是否清晰、规则是否互相矛盾、输出模板是否有歧义、兜底逻辑是否到位。

这些工作听起来琐碎，但正是这些琐碎，决定了你的AI应用和其他人的AI应用之间，隔着的到底是纸面架构还是真实能跑的工程成果。