企业官网建设流程全解析

1. 从一条“鹈鹕骑自行车”说起：为什么我要死磕提示词迭代

2026年9月底，我在调试一个跑在HarmonyOS设备上的智能体，任务很简单——让模型稳定输出“一只鹈鹕骑着自行车穿过城市街道”的画面描述。听起来像个玩笑，但这其实是圈内公认的提示词压力测试：鹈鹕的喙、自行车的结构、骑行的姿态，三者叠加会暴露模型在空间关系和常识推理上的大量漏洞。我前后改了八版提示词，从v1一路推到v8，中间踩的坑比想象中多得多。

这篇笔记就是把这八次迭代的完整过程摊开讲。核心关键词是智能体、提示词工程、LLM、HarmonyOS、小艺开放平台。我会说清楚每一版为什么改、改了什么、实测效果如何，以及哪些思路是可以直接搬到你自己项目里的。适合正在做智能体开发、提示词设计，或者准备接入小艺开放平台的人参考。不管你是刚接触提示词的新手，还是已经写过几十版prompt的老手，这里面的迭代逻辑和避坑经验应该都能用上。

先说结论性的判断：提示词迭代不是“把话说得更清楚”这么简单，它本质是在跟模型的概率分布做博弈。你写的每一个词，都在调整输出空间的权重。理解这一点，后面的所有操作才有依据。

2. 智能体提示词的整体设计思路拆解

2.1 为什么智能体的提示词和普通对话提示词不是一回事

很多人把智能体提示词当成“跟聊天机器人说话”，这是第一个认知误区。普通对话是一次性的，你说一句它回一句，上下文丢了就丢了。但智能体是有持续状态的——它要维护记忆、要调用工具、要在多轮交互中保持角色一致性。这就意味着提示词不只是“指令”，它同时承担了角色定义、行为约束、输出格式规范、异常处理策略四重职责。

我在v1阶段就犯了这个错。当时写的提示词大概是这样：

你是一个图像描述助手，请描述一只鹈鹕骑自行车的场景。

结果模型输出的东西五花八门：有的把鹈鹕画成了鸭子，有的让自行车飞在天上，有的干脆只描述了鹈鹕没提自行车。问题不在于模型能力不够，而在于我根本没告诉它“什么算合格输出”。

2.2 迭代的核心主线：从“描述任务”到“约束输出空间”

八版迭代下来，我总结出一条主线：提示词迭代的本质是逐步收窄输出空间，同时保留足够的灵活性。收得太紧，模型变得死板，换个场景就废；收得太松，输出不可控，没法工程化。

具体到我的项目，约束维度有这么几个：

• 主体约束：鹈鹕的形态特征（长喙、喉囊、体型）
• 动作约束：骑行的姿态（翅膀如何握把、身体如何平衡）
• 空间约束：自行车与鹈鹕的相对位置、透视关系
• 环境约束：城市街道的背景元素
• 格式约束：输出的结构（是否需要分镜、是否需要参数化描述）

每一版迭代，我基本都在调整这几个维度的权重和表达方式。下面这张表是我事后整理的迭代路线，先给个全局视角：

这张表不是事后美化，是我当时真实的迭代记录。接下来逐层拆解。

2.3 方案选型的背后考量：为什么不用微调而用提示词迭代

有人会问：既然模型输出不稳定，为什么不直接微调一个模型？我的考虑有三点。

第一，成本。微调需要标注数据、算力、时间，而我这个项目是快速验证性质的，提示词迭代几小时就能看到效果，微调至少要几天。

第二，可迁移性。提示词是模型无关的，我这套逻辑换到另一个LLM上，改改措辞就能用。微调出来的模型换底座就废了。

第三，可解释性。提示词改了什么、为什么改，一目了然。微调是个黑盒，出了问题很难定位。

当然，微调也有它的场景。如果你的任务高度固定、数据充足、对延迟敏感，微调是更好的选择。但对于大多数智能体开发场景，提示词迭代是性价比最高的路径。

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

3.1 v1到v3：把“主体”说清楚有多难

v1的问题前面说了，输出完全不可控。v2我加了角色设定：

你是一位专业的图像描述专家，擅长用精确的语言描述复杂场景。 请描述一只鹈鹕骑自行车的画面。

效果有改善，但出现了新问题：模型开始“炫技”，输出一堆华丽的形容词，但核心信息还是错的。比如它会写“一只优雅的鹈鹕轻盈地骑着自行车”，但鹈鹕的喙画成了短粗的。

v3我做了关键改动：把主体特征拆解成可验证的要素。

主体是一只鹈鹕，具有以下特征： - 长而直的喙，长度约为身体的三分之一 - 喙下方有明显的喉囊 - 体型较大，翅膀展开时翼展超过两米 - 羽毛以白色为主，飞行羽为黑色

这一版的效果提升很明显。模型开始关注鹈鹕的具体形态，而不是泛泛地描述“一只鸟”。但新的问题来了：动作描述缺失，模型不知道鹈鹕怎么“骑”自行车。

实操心得：描述主体时，不要用形容词堆砌，要用可验证的物理特征。形容词是主观的，物理特征是客观的，模型对客观特征的响应更稳定。

3.2 v4到v5：动作与空间的联合约束

v4我加入了动作约束：

鹈鹕骑自行车的姿态： - 身体直立，重心位于自行车座垫上方 - 翅膀向前伸展，翼尖握住车把 - 双脚（蹼）踩在脚踏上 - 头部朝前，喙指向行进方向

这一版让骑行姿态合理了很多，但空间关系还是乱。模型会把鹈鹕画得比自行车大十倍，或者让自行车悬浮在空中。

v5我引入了空间锚点的概念：

空间关系约束： - 自行车轮胎与地面接触，接触点位于画面下方三分之一处 - 鹈鹕的体型与自行车比例约为1.5:1（鹈鹕略大于自行车） - 鹈鹕的身体中心位于自行车座垫正上方 - 背景为城市街道，建筑物位于画面后方，高度不超过画面顶部

这一版的空间关系准确率大幅提升。但代价是输出变得很机械，像在填表格。

注意事项：空间锚点要选“可量化”的参照物。比如“画面下方三分之一处”比“画面下方”精确，“1.5:1”比“略大”精确。但也不要过度量化，否则模型会陷入数字计算而忽略整体协调性。

3.3 v6到v7：few-shot示例与参数化模板的取舍

v6我加入了few-shot示例，给了三个不同风格的输出样例。效果是格式统一了，但模型开始过拟合——不管什么场景，输出都往示例的风格上靠。

v7我尝试参数化模板：

请按照以下参数生成描述： - 主体：{subject} - 动作：{action} - 空间关系：{spatial} - 环境：{environment} - 风格：{style}

这一版的灵活性最好，但参数边界模糊。比如style填“写实”，模型不知道写实到什么程度。

踩过的坑：few-shot示例不要超过三个，而且示例之间要有足够的差异性。如果三个示例风格太接近，模型会认为这就是唯一正确的风格。参数化模板要配合参数说明使用，每个参数给出取值范围和示例值。

3.4 v8：分层约束与容错机制

v8是我目前最满意的一版。核心思路是分层约束：把提示词分成硬约束层、软约束层和容错层。

硬约束层是必须满足的条件，比如主体特征、基本空间关系。软约束层是尽量满足的条件，比如风格、细节丰富度。容错层是当模型无法满足某些约束时的降级策略。

硬约束（必须满足）： 1. 主体必须是鹈鹕，具有长喙和喉囊 2. 鹈鹕必须骑在自行车上，翅膀握把，脚踩脚踏 3. 自行车必须与地面接触 软约束（尽量满足）： 1. 背景为城市街道 2. 鹈鹕体型略大于自行车 3. 输出包含至少三个环境细节 容错策略： - 如果无法同时满足所有硬约束，优先保证主体特征 - 如果空间关系无法确定，使用“鹈鹕位于自行车上方”的模糊描述 - 如果输出格式不符合要求，重新生成，最多重试三次

这一版的效果最稳定，而且具备了工程化落地的条件。

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

4.1 环境准备与平台接入

我的测试环境是HarmonyOS NEXT SDK（API 12+），通过小艺开放平台接入智能体。如果你要复现，需要准备：

• HarmonyOS NEXT开发环境
• 小艺开放平台账号，创建智能体应用
• 一个可用的LLM后端（我用的是平台内置的模型，你也可以接自己的）

接入流程不复杂，但有几个细节要注意：

1. 权限配置：智能体需要访问网络和存储权限，在config.json里声明。
2. 提示词注入点：小艺开放平台支持在对话初始化时注入系统提示词，这是我们的主战场。
3. 调试工具：平台提供了对话日志和输出预览，迭代时一定要开着，方便对比。

4.2 提示词迭代的完整操作流程

我的迭代流程是这样的：

第一步：定义评估标准。在改提示词之前，先想清楚“什么算好”。我的标准是：主体正确率、动作合理率、空间准确率、格式合规率，各占25%。

第二步：单变量修改。每次只改一个维度，比如这次只改主体描述，下次只改空间约束。这样能准确归因。

第三步：批量测试。每个版本跑20次生成，统计各项指标。样本量不用太大，20次足够看出趋势。

第四步：记录对比。用表格记录每个版本的指标变化，找出提升最大和引入问题最多的改动。

第五步：回滚与合并。如果某个改动引入了新问题，先回滚，再尝试用其他方式实现同样的目标。

4.3 关键参数的计算与选择

在v5引入空间锚点时，我算了一组比例参数。以1920x1080的画面为例：

• 自行车轮胎与地面接触点：y坐标约720（画面下方三分之一处）
• 鹈鹕身体中心：y坐标约540（画面中心）
• 鹈鹕体型与自行车比例：1.5:1
• 背景建筑物高度：不超过y坐标200

这些参数不是拍脑袋定的，是根据透视原理反推的。假设视平线在画面中心（y=540），那么地面接触点在y=720意味着相机略高于自行车，这是常见的街拍视角。

实操技巧：空间参数不要写死在提示词里，用变量代替。这样换一个画面尺寸，只需要改变量值，不用重写提示词。

4.4 实测现场记录

v8版本的实测数据：

提升最明显的是空间准确率，这得益于分层约束中的硬约束优先级设计。动作合理率的提升来自容错策略——当模型不确定时，它会选择更保守的姿态描述，而不是胡乱生成。

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

5.1 模型“选择性失明”：为什么有些约束就是不生效

这是最常见的问题。你明明写了“鹈鹕必须有长喙”，模型还是画了个短喙。原因通常有两个：一是约束位置太靠后，模型的注意力已经衰减；二是约束表述不够“显眼”。

解决方法：把最重要的约束放在提示词的最前面和最后面，中间放次要约束。这是利用LLM的“首因效应”和“近因效应”。另外，用加粗或大写标记关键约束，也能提升注意力权重。

5.2 输出格式漂移：说好的JSON呢

智能体输出格式不稳定，是工程化落地的最大障碍。我的经验是：格式约束要独立成段，并且给出完整的示例。不要只说“输出JSON”，要说“输出以下结构的JSON，包含字段A、B、C，字段A的类型是字符串，字段B的类型是数组”。

如果还是漂移，加一个后处理步骤：用正则表达式提取关键信息，忽略格式噪音。

5.3 多轮对话中的角色遗忘

智能体在多轮对话后忘记自己的角色设定，这是LLM的上下文窗口限制导致的。解决方法是在每轮对话开始时，重新注入角色定义。虽然会增加token消耗，但能保证角色一致性。

避坑技巧：角色定义不要写太长，三句话以内。太长的角色定义会占用上下文空间，反而加速遗忘。

5.4 常见问题速查表

6. 从鹈鹕到通用智能体：这套方法还能怎么用

鹈鹕骑自行车只是个测试用例，这套迭代方法可以迁移到任何智能体提示词开发场景。比如销售智能体、客服智能体、代码生成智能体，核心逻辑是一样的：定义角色、约束输出、分层管理、容错降级。

我在小艺开放平台上还试过用这套方法做客服智能体。把“鹈鹕”换成“产品知识”，“自行车”换成“用户问题”，空间约束换成“回答范围约束”，效果同样明显。关键是要理解：提示词迭代不是写作文，是设计约束系统。

最后分享一个我最近在用的技巧：把提示词版本化管理，像管理代码一样管理提示词。每次改动都记录版本号、改动内容、测试结果。这样当出现问题时，可以快速定位到是哪个版本引入的。我用的是最简单的文本文件加Git，你也可以用任何你顺手的工具。

这个项目后续我打算把v8的分层约束思路做成一个可复用的模板，适配不同的智能体场景。如果你也在做类似的事情，欢迎交流。