企业官网建设流程全解析

1. 为什么“会写提示词”和“提示词工程”是两码事

很多人第一次接触大模型，都是从“帮我写个周报”“解释一下这段代码”开始的。用久了会发现一个尴尬的事实：同样一个模型，有人问出来的答案能直接当交付物，有人问出来的东西连自己都不想看第二遍。差距不在模型，在提示词的组织方式。

我见过太多人把提示词当成“许愿”，一句话丢过去，然后抱怨模型不行。也见过另一类人，他们手里有一套固定的框架，每次遇到新任务，先套框架再填内容，出来的结果稳定得像是流水线生产。后者做的这件事，就是提示词工程。

提示词工程不是玄学，也不是“会说话就行”。它本质上是一套把模糊需求翻译成模型可执行指令的系统方法。你不需要成为算法工程师，但你需要理解模型是怎么“读”你的话的，以及为什么有些结构能让它读得更准。

这篇文章要讲的，就是一套我反复用过、也带着团队新人跑过的5步搭建AI提示词工程框架的方法。它不依赖某个特定模型，DeepSeek、GPT、Claude、通义千问都能套。读完你至少能搞清楚三件事：提示词到底由哪些模块组成、每个模块为什么必须存在、以及怎么用这套框架把“碰运气”变成“可复现”。

适合谁看？如果你已经在用大模型干活，但结果时好时坏；如果你带团队，想让大家的产出质量拉齐；如果你在准备AI相关的比赛或项目，需要一套能写进文档的方法论——这套框架就是给你准备的。

2. 五步框架的整体设计与选型逻辑

2.1 为什么是五步，而不是三步或十步

市面上讲提示词的文章，有的列了十几个技巧，有的只给一个万能模板。技巧多了记不住，模板少了不够用。五步这个粒度，是我在实际项目中反复压缩和扩展之后找到的平衡点。

三步太粗：角色、任务、格式。听起来简洁，但真到复杂场景就崩了。比如你要模型做一份竞品分析，光说“你是分析师，分析一下竞品，输出报告”，它给你的东西大概率是泛泛而谈。因为缺少了约束条件和推理路径这两个关键层。

十步太碎：把“设定角色”拆成“设定身份”“设定语气”“设定知识背景”，把“输出格式”拆成“段落结构”“表格结构”“标点规范”。拆到最后，写提示词比写代码还累，而且很多步骤在简单任务里根本用不上。

五步的划分逻辑是这样的：角色与目标、上下文与约束、推理路径、输出规范、迭代机制。前四步构成一次完整的指令投递，第五步是让这套东西能持续变好的闭环。每一步解决一个特定的失效模式，缺一个都会在某个场景下出问题。

2.2 每一步解决什么核心问题

角色与目标解决的是“模型该用什么知识库和语气来回答”。你不设定，它就默认用通用助手的口吻，什么都知道一点，什么都不深。

上下文与约束解决的是“模型该在什么范围内回答”。没有约束，模型会自由发挥，给你一堆正确但没用的废话。约束包括字数、格式、必须包含的要素、必须排除的内容。

推理路径解决的是“模型该怎么一步步想到答案”。对于复杂任务，直接要结果容易出错，让它先列步骤再给结论，准确率会明显提升。这就是常说的“思维链”思路，但我不喜欢把它神秘化，本质上就是让模型把草稿纸上的过程也写出来。

输出规范解决的是“结果长什么样才能直接用”。很多人忽略这一步，结果拿到一堆文字还要自己重新排版。把格式要求写清楚，模型能直接输出Markdown表格、JSON、代码块，省掉二次加工。

迭代机制解决的是“这次好了，下次怎么更好”。没有复盘和版本管理，每次都是从零开始碰运气。有了迭代机制，你的提示词会像代码一样，越改越稳。

2.3 这套框架和“系统提示词工程”“Skill Agent”的区别

最近热词里经常出现“系统提示词工程”和“Skill Agent”，很多人搞混。简单说，系统提示词工程是平台侧的事，是模型厂商或应用开发者写死在系统里的指令，用户改不了。我们这里讲的是用户侧的提示词工程，是你每次对话时输入的那段话。

Skill Agent则是把提示词和外部工具、工作流打包成一个可调用的技能。比如一个“生成App原型图”的Agent，背后可能调用了墨刀AI的接口，加上一套固定的提示词模板。你如果要做Agent，这套五步框架就是设计Agent内部提示词的基础。先能把单次提示词写好，再谈封装和自动化。

3. 核心细节拆解与每步实操要点

3.1 第一步：角色与目标——别只写“你是专家”

“你是一个资深程序员”——这种角色设定太泛了。模型看到“资深程序员”，脑子里激活的是所有编程相关的语料，包括前端、后端、算法、运维。它不知道你具体要什么。

有效的角色设定要包含三个要素：领域、经验层级、当前任务视角。

比如你要模型帮你审查一段Python代码的性能问题，角色可以这样写：

你是一个有十年经验的Python后端工程师，擅长高并发场景下的性能调优，现在需要以代码审查者的视角，找出下面这段代码中可能导致响应延迟的瓶颈。

领域是“Python后端”，经验层级是“十年”，任务视角是“代码审查者”。这三个信息一给，模型激活的知识范围就收窄了，回答的针对性会明显提升。

目标设定也有讲究。不要写“帮我优化代码”，要写“找出所有时间复杂度高于O(n log n)的操作，并给出替代方案”。目标越具体，模型越不容易跑偏。

实操心得：角色设定不要超过三句话。写多了模型反而会抓不住重点。我试过写一大段角色背景，结果模型在回答里反复提这个背景，反而干扰了核心任务。

3.2 第二步：上下文与约束——给模型画一个圈

上下文是告诉模型“这件事的背景是什么”，约束是告诉模型“你不能做什么”。

上下文包括：数据来源、业务场景、已知条件、相关背景。比如你要模型帮你分析一份销售数据，上下文要写清楚“这是某电商平台过去三个月的订单数据，包含字段有订单号、用户ID、商品类目、金额、下单时间”。

约束包括：字数限制、格式限制、内容边界。比如“不要给出具体的投资建议”“不要引用2023年之前的数据”“回答控制在500字以内”。

这里有个容易踩的坑：约束写得太少，模型会自由发挥；约束写得太死，模型会变得机械。我的经验是，硬约束不超过三条，软约束可以多给。硬约束是必须遵守的，比如“输出必须是JSON格式”；软约束是尽量满足的，比如“尽量用简洁的语言”。

还有一个细节：如果你给模型提供了参考材料，一定要明确告诉它“优先使用以下材料中的信息，如果材料中没有相关内容，明确说明‘材料中未提及’”。否则模型会用自己的知识补全，导致信息失真。

3.3 第三步：推理路径——让模型把草稿纸交出来

对于简单任务，这一步可以省略。但对于需要多步推理的任务，比如数学计算、逻辑分析、方案对比，让模型先写推理过程再给结论，准确率会高很多。

具体怎么写？有两种方式。

一种是显式步骤：直接告诉模型“请按以下步骤思考：第一步，识别问题中的关键变量；第二步，列出可能的解决方案；第三步，对比各方案的优缺点；第四步，给出推荐方案”。

另一种是隐式引导：写“请先分析问题背景，再逐步推导，最后给出结论”。模型会自动展开推理。

我实测下来，显式步骤在复杂任务上更稳，尤其是涉及计算的时候。比如你要模型帮你算一个建模比赛里的参数优化问题，直接写“请先写出目标函数，再写出约束条件，然后给出求解思路，最后给出具体参数值”，比只写“帮我优化参数”效果好得多。

注意事项：推理路径不是越长越好。如果任务本身很简单，强行让模型写一堆步骤，反而会增加出错概率。判断标准是：如果你自己动手做这件事需要打草稿，那就让模型也打草稿；如果你自己心算就能出来，那就不需要。

3.4 第四步：输出规范——让结果直接能用

输出规范是很多人忽略的一步，但它是提升效率的关键。你想想，如果模型输出的东西还要你手动整理成表格，那省下来的时间又还回去了。

输出规范要写清楚：格式、结构、字段、示例。

格式可以是Markdown、JSON、YAML、纯文本。结构可以是“先总结再分点”“先表格再说明”“按时间顺序排列”。字段是如果你要JSON，要明确每个key的名称和类型。示例是给一个输出样例，让模型照着填。

比如你要模型帮你生成一组测试用例，输出规范可以这样写：

请以JSON数组格式输出，每个元素包含以下字段：case_id（字符串，格式为TC-001）、description（字符串，测试场景描述）、steps（字符串数组，操作步骤）、expected（字符串，预期结果）。示例：[{"case_id": "TC-001", "description": "登录成功", "steps": ["输入正确用户名", "输入正确密码", "点击登录"], "expected": "跳转到首页"}]

有了这个规范，模型输出的东西可以直接导入测试管理工具，省掉手工录入的环节。

3.5 第五步：迭代机制——把一次性成功变成可复现

前面四步做完，你大概率能得到一个不错的结果。但下次遇到类似任务，你还能不能得到同样好的结果？不一定。因为模型有随机性，同样的提示词跑两次，结果可能不一样。

迭代机制要解决的就是这个问题。具体做法包括：

版本记录：每次修改提示词，记录改了什么、为什么改、效果如何。可以用简单的文本文件，也可以用Notion、飞书文档。我习惯在提示词末尾加一个注释块，写清楚版本号和修改说明。

A/B测试：同一个任务，准备两版提示词，跑同样的输入，对比输出质量。不要凭感觉判断哪个好，要定标准。比如“信息完整度”“格式正确率”“人工修改耗时”。

失败案例收集：把模型输出不好的案例存下来，分析是哪个模块出了问题。是角色设定不够具体？还是约束条件有遗漏？还是推理路径跳步了？定位到具体模块，改起来就有方向。

参数固化：如果你用的是API，把temperature、top_p这些参数也记录下来。同样的提示词，temperature从0.7调到0.2，输出风格会差很多。找到适合当前任务的参数组合，固定下来。

实操心得：我自己的提示词库是按“任务类型”分类的，每个类型下面有基础模板和若干变体。新任务来了，先找最接近的模板，改几个变量就能用。这样比每次从零写快得多，而且质量有底线。

4. 完整实操流程与关键环节实现

4.1 场景设定：用AI辅助生成App原型图的需求描述

假设你是一个产品经理，需要让AI帮你生成一个“社区团购App”的原型图描述。这个描述后续会喂给墨刀AI或其他原型工具。你的目标是：输出的描述要足够详细，让原型工具能直接生成可用的界面。

这个任务看起来简单，但实际做起来容易出问题。如果你只写“帮我生成一个社区团购App的原型描述”，模型给你的东西大概率是“首页、商品列表、购物车、个人中心”这种级别的概括，原型工具拿到之后只能生成几个空白页面。

用五步框架来拆解这个任务。

4.2 第一步到第四步的具体填写

角色与目标：

你是一个有五年经验的移动端产品经理，擅长社区电商类产品的交互设计。现在需要为一个社区团购App生成一套完整的页面原型描述，目标是让原型工具能够直接根据描述生成可交互的界面。

上下文与约束：

这个App的目标用户是25-45岁的社区家庭用户，核心功能是“今日下单、次日自提”。主要页面包括：首页、商品详情页、购物车、订单确认页、自提点选择页、个人中心。约束条件：每个页面的描述不超过200字；必须包含页面元素的位置关系；必须说明核心交互逻辑；不要涉及支付和物流的具体实现细节。

推理路径：

请按以下步骤生成：第一步，列出每个页面的核心功能点；第二步，描述页面的布局结构，从上到下、从左到右；第三步，说明页面内的交互逻辑，比如点击某个按钮后跳转到哪里；第四步，用一段话总结该页面的设计意图。

输出规范：

请以Markdown格式输出，每个页面一个二级标题，标题格式为“页面名称：XXX”。每个页面下面用无序列表列出布局元素，用有序列表列出交互步骤。最后附一个表格，汇总所有页面之间的跳转关系。

4.3 实际输出与效果分析

按照上面的框架，模型输出的内容大概是这样的（节选）：

页面名称：首页

• 顶部：搜索栏，占满宽度，左侧为定位图标显示当前社区名称
• 中部：轮播图，展示今日爆款商品，高度约为屏幕的三分之一
• 下部：商品分类网格，每行四个图标，包含“蔬菜水果”“肉禽蛋品”“日用百货”等
• 底部：导航栏，包含“首页”“分类”“购物车”“我的”四个标签

交互步骤：

1. 点击搜索栏，跳转到搜索页面
2. 点击轮播图，跳转到对应商品详情页
3. 点击分类图标，跳转到分类商品列表页
4. 点击底部导航“购物车”，跳转到购物车页面

这个输出直接复制到墨刀AI的原型生成功能里，基本能生成一个可用的首页框架。对比没有框架的提示词，输出质量差距非常明显。

我实测过，用框架生成的描述，原型工具一次生成可用页面的比例大概在70%左右；不用框架，这个比例不到30%。差距主要来自布局描述的具体性和交互逻辑的完整性。

4.4 参数选择与调整记录

在这个场景里，我用的模型是DeepSeek-V2，temperature设为0.3。为什么是0.3？因为原型描述需要的是稳定、结构化的输出，不需要太多创意发挥。temperature太高，模型会在布局描述里加入一些不存在的元素；太低，又会导致描述过于死板，缺乏合理的交互联想。

top_p设为0.9，保持一定的多样性，但不过度发散。max_tokens设为2000，因为六个页面的描述加起来大概在1500字左右，留一些余量。

如果你用的是其他模型，参数可能需要微调。但核心原则不变：结构化输出任务，temperature往低了调；创意生成任务，temperature可以适当调高。

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

5.1 模型不按格式输出怎么办

这是最常见的问题。你明明写了“请以JSON格式输出”，模型还是给你一段文字。原因通常有三个：

第一，输出规范写得太靠后。模型在生成时，前面的内容权重更高。如果输出规范放在最后，模型可能已经“忘记”了。解决办法是把格式要求提前，或者在推理路径里也提一句“最后请按XX格式输出”。

第二，格式要求不够具体。只写“JSON格式”不够，要写清楚key的名称、value的类型、嵌套结构。最好给一个完整的示例。

第三，模型能力限制。有些小模型对复杂格式的遵循能力确实弱。如果换了写法还是不行，考虑换模型，或者把格式要求拆成多轮对话，先让模型生成内容，再让它转换格式。

5.2 输出内容太泛、没有深度

模型给你的东西像是从百科里抄的，正确但没用。这通常是上下文和约束没写好。

检查你的提示词里有没有这些信息：具体的业务场景、已知的数据或条件、你期望的分析角度。如果这些都没有，模型只能给你通用答案。

另一个技巧是给反面例子。比如“不要写‘建议优化用户体验’这种空话，要写‘将按钮从右下角移到拇指热区范围内’这种可执行的动作”。模型看到反面例子，会主动避开那些泛泛的表述。

5.3 推理路径导致输出太长

让模型写推理过程，结果它写了2000字的分析，最后结论只有两句话。这在需要快速拿到结果的场景里很烦人。

解决办法是限制推理长度。在推理路径里加一句“推理过程控制在200字以内，直接给出关键判断依据”。或者把推理和输出分开，先让模型在“草稿模式”下推理，你确认后再让它“按结论模式”输出。

我自己的习惯是，对于日常任务，推理路径只写“简要说明判断依据”，不展开。对于复杂决策，才让它完整推理。

5.4 常见问题速查表

5.5 独家避坑技巧

技巧一：用“如果你不确定，请明确说明”代替“不要瞎编”。后者会让模型变得过度保守，该回答的也不回答了。前者给了模型一个安全的退出路径，反而能提高有效回答的比例。

技巧二：把最重要的约束放在提示词的开头和结尾各一次。模型对首尾信息的注意力更高，中间部分容易被稀释。这不是玄学，是注意力机制的特性。

技巧三：迭代时一次只改一个模块。同时改角色和约束，你无法判断是哪个改动起了作用。保持其他模块不变，单独调整一个变量，才能积累出有效的经验。

技巧四：建立自己的“提示词片段库”。把常用的角色描述、约束条件、输出格式存成片段，写新提示词时直接拼装。我自己的片段库里有几十个条目，写新提示词的时间从半小时缩短到五分钟。

6. 从单次提示词到提示词工程体系的扩展

6.1 把五步框架变成团队规范

一个人用这套框架，效率提升是线性的。一个团队用这套框架，效率提升是指数级的。因为提示词可以复用、可以评审、可以版本管理。

具体做法：在团队内部建一个共享的提示词库，按任务类型分类。每个提示词必须包含五步框架的完整结构。新人写提示词，先从库里找最接近的模板，改完提交评审。评审的重点不是“写得好不好”，而是“五步是否完整、约束是否明确、输出是否可直接使用”。

我们团队跑这套流程大概三个月后，新人上手大模型任务的时间从两周缩短到三天。因为不需要从头理解“怎么跟模型说话”，直接套框架就行。

6.2 和AI编程提示词的结合

最近“AI编程提示词”很火，很多人用Cursor、Copilot写代码。其实编程场景特别适合这套框架。

角色设定为“资深XX语言工程师”，上下文里贴入相关代码和报错信息，推理路径要求“先分析报错原因，再给出修改方案，最后说明修改可能影响的其他模块”，输出规范要求“给出完整的修改后代码块，并标注修改行”。

我试过用这套框架让模型帮我重构一段复杂的Python数据处理代码，一次通过率比直接说“帮我优化这段代码”高很多。关键就在于推理路径让模型先分析了依赖关系，避免了改一处崩三处的情况。

6.3 建模比赛中的提示词工程应用

建模比赛里，AI提示词可以帮你做很多事：理解题目背景、查找相关算法、生成论文框架、甚至辅助写代码。

但比赛场景有个特点：时间紧、任务重、不能出错。这时候提示词的稳定性比创意性更重要。我的建议是，比赛前就准备好几套针对常见任务的提示词模板，比如“算法选型分析”“数据预处理方案”“论文摘要生成”。比赛时直接填空，不要现场发挥。

另外，比赛里经常需要处理敏感数据或保密题目，用AI辅助时要注意不要泄露关键信息。可以把数据脱敏后再喂给模型，或者只让模型处理方法论层面的问题，具体数据自己算。

6.4 提示词工程的边界与局限

说了这么多提示词工程的好处，也得说说它的边界。

提示词工程不能让弱模型变成强模型。如果模型本身不具备某种能力，再好的提示词也问不出来。它能做的是把模型已有的能力更稳定地激发出来。

提示词工程也不能替代领域知识。你不懂业务，就写不出好的约束条件；你不懂代码，就判断不了模型给的方案对不对。提示词工程是放大器，不是替代品。

最后，提示词工程不是一劳永逸的。模型在更新，任务在变化，你的提示词库也需要持续维护。把它当成一个需要定期整理的工具箱，而不是一次性的作业。

我个人在实际操作中的体会是，这套五步框架最大的价值不是让你“会写提示词”，而是让你有一套可以跟别人讨论、可以传承、可以改进的方法。以前大家交流提示词，只能说“我试了一个写法，效果不错”，现在可以说“我的约束模块写得不够具体，导致输出泛化，你帮我看看怎么改”。从感觉驱动变成工程驱动，这才是提示词工程真正的意义。