AI绿皮书学习之路（四）-理解大模型开发

一、AI不等于大模型

1、AI不等于大模型

许多人误以为人工智能（AI）就等于像 DeepSeek 或豆包这样的大语言模型，但实际上大模型只是 AI 领域中的一个分支。AI 的诞生可以追溯到 1956 年，其核心目标是让机器展现出模拟人类智能的行为。

2、AI 发展的两次历史浪潮

在 AI 的演进过程中，前两次浪潮奠定了基础。第一次浪潮是符号主义 AI（50 年代至 80 年代），它依赖人类手工编写的逻辑规则（如 if-then 语句）来解决问题，但由于世界太复杂而无法穷举所有规则。第二次浪潮是机器学习 AI（80 年代至 2010 年），研究者转变思路，不再手工写规则，而是让机器通过大量样本数据自动学习规律，比如早期的垃圾邮件分类和商品推荐系统。

3、深度学习与大模型的定位

第三次浪潮（2012 年至今）迎来了深度学习 AI，它革命性地让神经网络自己学习特征，不再需要人工设计特征。而当前备受瞩目的大语言模型（LLM），实际上只是深度学习在自然语言处理领域下的一个分支，它具有规模巨大、具备通用涌现能力（无需专门训练即可做翻译、写代码等）以及基于 Transformer 架构这三个核心特征。像计算机视觉（图像识别）、语音识别、推荐系统和强化学习（如 AlphaGo）等技术，都属于不依赖大模型的其他 AI 分支。

4、大模型开发的现状与选型

如今 AI 应用开发高度向大模型集中，主要是因为大模型 API 的出现极大地降低了开发门槛，让开发者可以像调用简单函数一样快速构建应用。在实际开发中，如果任务涉及自然语言的理解与生成，大模型是首选；但如果不涉及自然语言，或者对实时决策（如自动驾驶）、精确计算、物理交互和成本有极高要求，传统 AI 技术或专业模型则是更好的选择。此外，大模型可能也只是 AI 走向通用智能的一个过渡形态。

5、抖音推荐算法案例

作为非大模型 AI 技术的典型代表，抖音的推荐算法由四层技术架构组成。它首先通过双向召回模型快速筛选候选视频，再利用 Wide&Deep 模型兼顾用户的明确偏好与潜在兴趣，接着通过多目标建模综合评估点赞、完播等多个指标，最后依靠底层 Monolith 引擎实现毫秒级的实时训练与推荐。这种精准的正反馈循环向我们展示了大模型之外的 AI 世界。

6、总结

核心观点在于澄清“AI 等于大模型”的认知误区。AI 是一个涵盖符号推理、机器学习、深度学习等多种技术的广阔领域，而大模型只是其当前阶段在自然语言处理上的一个高效实现手段。开发者在面对具体业务场景时，应当理清大模型的能力边界，根据任务属性在语言生成与传统 AI 技术之间做出理性的选型。

二、理解大模型开发（一）-理论篇

1、大模型的三个本领

大模型在做软件开发时主要有三个核心能力。第一是“听得懂人话”，能把大家平时说的、模糊的普通话变成程序能看懂的结构化表格数据；第二是“能写内容”，可以根据给定的数据生成好玩有趣的广告文案、文章或者代码；第三是“会推理诊断”，能像专家一样分析问题，比如帮程序员找出代码在服务器上报错的原因并给出解决办法。

2、AI应用的两大流派

一类叫“AI当老大”的应用，大模型是整个产品的灵魂，如果没有大模型，这个产品就根本不存在了。比如各种聊天助手、AI画画工具和AI写代码软件，它们的价值完全靠大模型撑起来。

另一类叫“传统业务当老大”的应用，整个系统的核心还是传统的买卖、上课或看病流程，AI只是一个用来锦上添花的“高级插件”。比如电商网站去掉AI客服，大家依然能正常下单买东西，它只是让系统变得更聪明了一点。

3、大模型在传统系统里的定位

在普通的业务系统里，大模型不应该用来包揽所有事情，而是应该被看作一个“外包的聪明助手”，就像短信通道或支付接口一样，只有在需要理解复杂人话或者生成内容时才喊它。

因为现在的AI并不擅长做那些一分一毫都不能错的硬核工作，比如算价格、扣余额、改订单状态或者存用户信息。这些确定性的死板工作，依然必须由传统的数据库和代码来做，才能保证系统不崩溃、不出错。

4、哪些地方该用AI，哪些地方不该用

要判断一个功能该不该用AI，有四个简单的照妖镜：如果逻辑可以用“如果...就...”这种固定规则写死，就用传统技术，写不死才考虑AI；如果这个功能绝对不允许出错（比如算钱）用传统技术，允许有一点点误差（比如推荐商品）才用AI；如果不需要理解语义或者编造内容，用传统技术；最后，如果这个功能每天要被点击调用上百万次，用传统技术，因为每次调AI的API都非常贵，高频调用会迅速烧光公司的钱。

所以在实际的软件中，90%的稳定工作（如注册登录、查库存、付款）都该用传统技术，只有10%需要理解模糊语义的地方（如智能客服、自动写商品文案、分析好评差评）才让AI上。

5、总结

大模型不是万能灵药，它擅长处理没有固定规则的“理解和生成”任务，但在精细计算和事务处理上很不靠谱。开发软件的核心原则是“能不用AI就不用AI”，只有在传统技术实在解决不好的模糊场景下，才把AI当作外部插件引入，通过“90%传统架构+10%AI增强”的黄金组合，才能做出既稳定又聪明的实用产品。

三、理解大模型开发（二）-实战篇

1、智能客服的“四棒接力赛”混合架构

在真实系统中，大模型最适合用来做“理解”和“生成”这类模糊、需要创造性的工作，但不适合做需要百分之百准确的“确定性计算”。为了兼顾成本和准确度，最好的方案是让 AI 和传统技术接力协作：第一棒由 AI 理解用户的自然语言并判断其意图（例如识别出用户想“查询订单”）；第二棒由传统技术（如正则表达式）精准提取订单号等关键信息；第三棒由传统技术直接去数据库查询真实数据，确保结果绝对准确、不走样；第四棒再交回给大模型，将冷冰冰的数据库信息“翻译”成用户听起来更亲切、更友好的自然语言回复。

2、大模型的两种接入方式及选择策略

接入大模型主要有“调用 API”和“自建模型”两种路线。调用 API 就像去餐厅吃饭，省时省力，不需要购买昂贵的 GPU 服务器，零基础设施投入且按需付费，非常适合个人开发者、小团队或创业公司用来快速验证产品，但缺点是调用量极大时成本高、数据传到云端有隐私风险。自建模型则像自己在家做饭，需要下载开源模型并部署在自己的服务器上，虽然前期硬件和技术门槛投入极大，但它能保证数据不出本地、隐私安全，且可以深度定制，适合医疗、金融等数据敏感行业或每天调用量达百万次以上的巨型企业。在实际应用中，许多公司会采用混合方案，即日常标准的任务用自建模型省成本，复杂任务调用顶级 API 保质量。

3、从确定性到概率性的思维方式转变

使用大模型开发应用，最核心的挑战在于从传统编程的“确定性世界”跳跃到 AI 的“概率性世界”。传统编程输入 10 乘以 3 永远等于 30，逻辑完全可控可预测；而大模型是在概率分布中采样来生成内容，即使输入完全相同的提示词，每次生成的文本也可能由于概率而有所不同。因此，开发者需要转变三种观念：一是接受不完美，因为大模型偶尔会胡说八道，必须在系统中建立验证和重试的兜底机制；二是学会“引导”而非“控制”，不能硬性规定生成恰好多少个字，而是要通过优化提示词去引导它靠近期望；三是持续监控和迭代，像照料花园一样不断根据用户反馈微调提示词或更换更强的模型。这种概率性带来的不确定性，恰恰也是 AI 拥有创造力的源泉。

4、核心总结

大模型并不是万能的，在落地开发时必须将 AI 的“概率性智能”与传统技术的“确定性逻辑”有机结合，通过混合架构各展所长。开发者在面对技术落地时，不仅要学会根据业务规模和数据安全要求在“调用 API”与“自建模型”之间做权衡，更需要彻底改变传统编程绝对控制的思维，学会以引导、容错和持续迭代的概率性思维去跟大模型协作。

四、准备工作与环境搭建

1、大模型 API 的商业模式

网页端或 APP 上的大模型通常免费提供给普通用户体验，目的是吸引用户和扩大影响力。但是，如果开发者想要通过 API 接口将大模型接入到自己的应用或产品中，则必须按照使用量进行付费。这种 API 调用的高成本，主要是由于每次运行大模型都需要消耗大量的显卡算力，属于实打实的硬件支出。

2、国内外主流大模型服务商特点

国外三巨头中，OpenAI 的 GPT-5 系列是行业标杆，其 API 格式已成为行业半标准；Google Gemini 原生支持百万级上下文和视频理解，前端 UI 审美极高；Anthropic Claude 在编程开发赛道占据绝对优势，其 Coding Agent 备受程序员好评。

国内服务商中，智谱 AI 适合跑长程 Agent 任务；DeepSeek 作为价格屠夫，提供超大上下文且完全开源，性价比极高；阿里通义千问模型家族丰富，生态完善且注册送额度；字节跳动豆包多模态能力强，更适合多媒体与语音交互。

3、AI 应用开发的两种学习路径

第一种路径是付费使用 API，这是绝大多数初学者的现实选择。由于国内大模型 API 价格已经非常低廉，每月只需少量投入即可作为交互式学习成本，但需要注意自动多轮推理的智能体（Agent）耗费 Token 极快。

第二种路径是自己购买显卡搭建服务器并部署开源模型，这种方式没有后续的 API 调用费，但前期硬件投入大、技术门槛高，适合有专业背景或公司资源的开发者。

4、环境搭建与现代化 AI 编程方式

进行 API 开发前，需要准备好服务商平台（如阿里云百炼或 DeepSeek 开放平台）的 API 密钥，并确保本地安装了 Python 3.10 或更高版本以及 NodeJS 环境。由于国内主流模型兼容 OpenAI 的接口风格，因此开发时直接安装 openai 库即可。在现代化开发中，强烈建议使用 Qoder、TRAE、Cursor 等 AI 编程助手来自动安装库、配置环境、生成并直接运行代码，无需再像传统方式那样机械地手写命令或频繁切换编辑器与终端。

5、核心总结

API 调用付费是大模型商业化的核心模式，初学者应优先选择性价比高的国内模型（如通义千问、DeepSeek）通过兼容 OpenAI 接口的方式进行付费调用。同时，现代 AI 开发已不再依赖繁琐的传统手工环境配置，利用 AI 编程助手进行自然语言交互、自动生成并运行代码，才是 AI 时代最高效的全新开发范式。

五、第一次API调用与核心参数

1、第一次API调用与配置

要通过代码调用大模型，我们需要在代码中导入OpenAI的库，并配置两个基础参数：一是“api_key”（你的专属密钥），二是“base_url”（大模型的服务器地址）。基础的自测调用代码如下：

Python

from openai import OpenAI

client = OpenAI(
    api_key = "sk-qwen-xxxxxxxx", # 你的Qwen密钥
    base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1" # Qwen地址
)

resp = client.chat.completions.create(
    model = "qwen3.6-plus",
    messages = [{"role": "user", "content": "你好，请简单介绍你自己"}]
)
print(resp.choices[0].message.content)

2、认识model参数（如何选模型）

“model”参数用于指定具体要使用的AI模型。以通义千问3.6系列为例，模型被分成了不同的型号以应对不同的应用场景：

对于复杂任务，可以使用能力最强的 Max 版本：

Python

model = "qwen3.6-max-preview"

对于日常任务或智能体，可以使用效果、速度、成本均衡的 Plus 版本：

Python

model = "qwen3.6-plus"

对于简单高频任务，可以使用速度快、成本低的 Flash 版本：

Python

model = "qwen3.6-flash"

3、对话式API的核心：带着历史聊天

大模型的API是“对话式”的，它和传统的“一次性请求”接口不同。它需要历史信息来理解你的新问题，所以上一次调用和下一次调用是有关联的。在连续对话中，你必须手动把之前的聊天历史打包一起发送过去，否则AI就无法理解带有代词（如“它”、“这两个”）的连续追问。

4、messages参数与三种角色

承载聊天历史的容器叫做“messages”，它是一个按时间先后顺序排列的数组。数组里的每一条消息都是一个字典，必须包含两个核心字段：role（角色类型）和content（消息内容）。

其中 role 参数有三种取值：

system（系统角色）：通常放在最开头，用于设定AI的“人设”与行为规则，最高优先级并贯穿整个对话。

user（用户角色）：代表人类输入的问题，至少需要有一条。

assistant（助手角色）：代表AI的历史回复，在多轮对话中必需手动传入以维持上下文。

完整结合系统角色（system）并要求返回结构化结果的调用示例如下：

Python

messages = [
    {
        "role": "system",
        "content": "你是一个专业的AI助手。请仅以JSON格式返回结果。字段：intro（简短自我介绍），capabilities（列出3项能力）。"
    },
    {
        "role": "user",
        "content": "请介绍你自己，并说明你能做什么。"
    }
]

5、总结

通过代码示例讲解了第一次调用大模型API的方法。大模型开发的基础在于理解“对话式API”的运作机制：它不是孤立的单次请求，而是需要通过传递一个包含系统设定（system）、用户提问（user）和历史回复（assistant）的连续时间序列数组（messages），来维持多轮对话的上下文连贯性，并根据任务的复杂度与预算挑选合适的模型版本（model）。

六、多轮对话与上下文管理实战

1、大模型API的本质区别

传统API在调用时必须传入预定义的、精确的参数值和固定的枚举值，如果写错就会直接报错。

而大模型API则允许开发者使用自然语言来模糊地表达需求和设置参数。这种方式使得开发者不再需要死记硬背复杂的参数名，AI会自动理解并适应日常语言的描述，这是自然语言开发的重要趋势。

2、多轮对话的角色与机制

在大模型的多轮对话中，API需要通过一个消息数组（messages）不断累积并携带完整的对话历史，包括用户的所有提问（user）和AI的所有历史回复（assistant），以此来让AI理解上下文。

其中一共有三种角色：system用于在开头设置一次稳定的角色设定、规则或输出格式；user代表用户的真实输入，每轮必需；assistant用于记录AI的历史回复，是多轮对话的必需项。

3、上下文管理的三种策略

随着对话轮次的增加，历史记录变长会导致超出模型窗口上限、Token成本飙升以及响应变慢的问题，因此需要进行上下文管理。

策略一是近期优先，即只保留最近3到5轮的完整对话，删掉更早的记录。

策略二是历史摘要，利用大模型将早期的多轮对话压缩成一句话的要点总结，放入assistant或system消息中，从而大幅节省Token。

策略三是规则前置，把身份设定、禁止项等稳定不变的规则固定在system中，避免在user消息中重复强调。

4、历史摘要的实战逻辑

利用AI来压缩早期对话是解决长对话成本和性能问题的核心思路。

在实际开发中，可以先提取需要压缩的早期对话，让大模型生成一句话摘要。随后重组发送给API的messages数组，将“系统规则 + AI生成的历史摘要 + 最近几轮的完整对话 + 当前新问题”拼接到一起发送，这样可以优化掉高达60%以上的文字长度，显著节省成本。

5、返回结果Response的解析

大模型API返回的Response对象除了包含AI的回复文本（choices[0].message.content）和Token消耗数（usage.total_tokens）之外，还包含一个关键字段叫finish_reason（结束原因）。

开发者在正式项目中务必检查这个字段：值为'stop'代表模型认为回答已完成，属于正常结束；值为'length'代表达到了长度限制，内容被强制截断，需要增大max_tokens或提示用户分段提问；值为'content_filter'则代表触发了安全审核机制，内容被过滤。

6、智能翻译器实战与System角色优化

基于大模型API可以轻松构建实用的智能翻译器。基础版本只需直接在user提示词中要求AI翻译指定文本即可。

如果想让工具更专业，可以利用system角色来定义AI的翻译行为和特定风格。以下是支持风格控制的专业翻译器核心代码示例：

Python

from openai import OpenAI
import os

api_key = os.getenv("DASHSCOPE_API_KEY") or "sk-xxxxxxxxxxxx"
client = OpenAI(api_key=api_key, base_url="https://dashscope.aliyuncs.com/compatible-mode/v1")

def translate_pro(text, style="日常"):
    messages = [
        {
            "role": "system",
            "content": f"你是专业翻译，负责将中文翻译成英文。\n\n翻译要求：\n- 风格：{style}\n- 保持原文的语气和情感\n- 符合目标语言的表达习惯\n- 只返回翻译结果，不要添加任何解释"
        },
        {
            "role": "user",
            "content": text
        }
    ]
    response = client.chat.completions.create(
        model="qwen3.6-plus",
        messages=messages
    )
    return response.choices[0].message.content

通过这种规则前置的优化方式，传入相同的文本，只要调整system中的style参数（如“文学风格，充满诗意”或“口语化，简洁通俗”），就能让AI输出完全不同笔调的专业译文。

7、总结

本节内容聚焦于大模型API在多轮对话与上下文管理中的实战应用。核心在于理解大模型依靠messages数组中的历史记录来维持上下文，并详细阐述了面对长对话时如何通过近期优先、历史摘要和规则前置三种策略来优化Token成本和响应速度。同时，通过解析返回对象中的finish_reason字段来保证业务健壮性，并最终演示了如何利用system角色进行行为约束，开发出支持风格控制的专业智能翻译器。

七、流式输出与长度控制

1、流式输出（Streaming）

流式输出是一种用来显著提升用户感知速度和体验的技术。在非流式状态下，用户输入内容后必须干等AI生成完整个结果才能一次性看到，而流式输出则像打字机一样，让AI每生成一小段内容（Chunk）就立即返回并逐字显示。虽然它不会加快AI的实际生成速度，但能让“感知等待时间”大大缩短。

在代码中，我们只需将API参数 stream 设置为 True，并结合 for 循环遍历响应块，同时配合 flush=True 来强制刷新终端缓存，即可实现实时显示。

Python

response = client.chat.completions.create(
    model="qwen3.6-plus",
    messages=[{"role": "user", "content": "翻译这段文本..."}],
    stream=True  # 启用流式输出
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

2、长度控制（max_tokens）

max_tokens 参数用于限制AI模型生成的最大Token数量，这个限制不包括用户输入的文本，且其最大值受到模型自身上下文窗口的限制。默认情况下该参数无限制，由模型自行决定何时停止。如果生成的回复因为达到了设置的Token上限而被截断，API返回的响应中 finish_reason 字段的值会显示为 length。

在实际使用中，短文本翻译通常设置 max_tokens=200 即可；长文章翻译可以根据“中文1个汉字≈1个Token、英文1个单词≈1.3-1.5个Token”的技巧进行粗略估算，一般建议为原文预留1.5倍的空间；如果是写摘要，则可以限制在50-100以内以强制其精简。

Python

response = client.chat.completions.create(
    model="qwen3.6-plus",
    messages=[{"role": "user", "content": "翻译：今天天气真好..."}],
    max_tokens=100  # 最多生成100个Token
)

# 检查是否被截断
if response.choices[0].finish_reason == 'length':
    print("翻译结果被截断，请增加max_tokens或缩短输入")
else:
    print(response.choices[0].message.content)

3、总结

本次内容聚焦于大模型API开发中的两个核心参数调节。通过开启 stream=True 并使用流式循环接收数据，可以完美解决长文本处理时用户等待时间过长的体验痛点；而通过合理配置 max_tokens 参数并结合 finish_reason 状态检测，则能有效控制模型输出长度，避免回复被无故截断或产生不必要的 Token 成本消耗。这两者共同构成了构建高可用、高体验AI应用的基础。

八、创意控制与专业翻译器

1、温度参数（temperature）控制翻译风格

这个参数用来调整 AI 选词的随机性和创意性，取值范围在 0.0 到 2.0 之间，默认值是 1.0。

它不会改变翻译的质量，而是改变翻译的风格。当参数较低（如 0.3）时，AI 的输出非常确定和一致，适合需要直译、逐字对应的技术文档或法律合同；当参数较高（如 2.0）时，AI 的表达会非常灵活且富有创意，适合需要意译的文学作品或营销文案。

Python

# temperature=0.0 时倾向于直译
response = client.chat.completions.create(
    model="qwen3.6-plus",
    messages=[{"role": "user", "content": "翻译成英文：今天天气真好，我们去公园散步吧。"}],
    temperature=0.0
)
# 输出：Today's weather is really good, let's go to the park for a walk.

2、核采样参数（top_p）精细控制多样性

这个参数通过动态选择累积概率达到 p 的候选词范围来控制输出，取值范围在 0.0 到 1.0 之间，默认值是 1.0。

在实际使用中，通常建议优先调整 temperature。除非需要极其精细的控制，否则不建议同时调整这两个参数，因为它们会相互影响，让输出结果变得难以预测。

3、流式输出中的 Token 统计配置

在默认情况下，使用流式输出（stream=True）是看不到 Token 消耗统计的。如果需要获取 Token 统计信息，必须显式配置 stream_options 参数。

Python

response = client.chat.completions.create(
    model="qwen3.6-plus",
    messages=[{"role": "user", "content": "翻译这段文本..."}]
    stream=True,
    stream_options={"include_usage": True} # 在流式输出中包含Token统计
)

4、理解最大 Token 数（max_tokens）的计算范围

如果发现将 max_tokens 设置得比总 Token 消耗还要小（例如设置为 50，而总消耗有 104），模型依然能够正常输出而没有被截断，这是因为 max_tokens 只限制模型实际输出的文本 Token 数量，并不包含输入的提示词部分。

5、总结

这段内容核心讲解了如何通过调节大模型 API 的关键参数（temperature 和 top_p）来控制专业翻译器的直译与意译风格，并介绍了在流式输出中如何通过配置获取 Token 消耗统计，以及明确了 max_tokens 参数只对模型输出部分生效的计算规则。

九、Prompt基础与必要场景

1、什么是提示词（Prompt）

提示词简单来说就是对AI说的话。提示词的质量直接决定了AI回答的质量。设计提示词是一门平衡的艺术：给得太少，AI会答非所问；给得太多，不仅浪费Token，还会干扰AI思考，降低回答质量。好的提示词应当明确而不啰嗦、结构清晰、关键信息优先并避免歧义。

2、什么是提示词工程（Prompt Engineering）

提示词工程是指如何设计和优化提示词，以精准控制AI输出的技术。它包括如何清晰表达需求、提供背景信息、规范输出格式以及引导AI思考。研究表明，优秀的提示词能让普通模型的效果超越顶级模型，且优化成本远低于模型训练。

3、不需要提示词工程的场景

日常的知识问答、闲聊或获取灵感等场景，完全不需要过度设计提示词。因为AI本身就很擅长解释基础知识，直接用自然语言提问就是最好的方式，复杂的提示词反而会增加AI的思考成本。

4、必须使用提示词工程的场景

当需要精确控制AI的输出时，提示词工程就至关重要。主要包含三大场景：第一是多模态生成（如图像、视频），其试错和时间成本高，极其依赖精准的提示词控制；第二是代码生成，清晰的约束能让AI写出包含错误处理和日志的高质量代码；第三是应用系统集成，需要严格控制AI返回结构化的数据格式（如JSON），以防程序解析出错。

以下是精准控制代码生成的提示词示例：

Python

# 优秀Prompt：
使用httpx库编写一个HTTP API调用函数，要求：
1. 支持GET/POST方法
2. 超时时间30秒
3. 失败重试3次，指数退避
4. 记录详细日志（请求/响应/错误）
5. 返回JSON数据，异常时抛出自定义异常
6. 添加类型注解和docstring
----------------------------
import httpx
logger = logging.getLogger(__name__)

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10))
def call_api(url: str, method: str = "GET", data: Dict[str, Any] = None) -> Dict[str, Any]:
    """
    HTTP API调用函数，支持重试和日志记录
    Args:
        url: API地址
    Returns:
        JSON响应数据
    Raises:
        APIError: API调用失败
    """
    try:
        logger.info(f"请求 {method} {url}, data={data}")
   
    except httpx.HTTPError as e:
        logger.error(f"API调用失败: {e}")
        raise APIError(f"API调用失败: {e}") from e

5、总结

本文主要阐述了提示词及提示词工程的核心定义，并明确划分了其适用场景。提示词工程是一门精准控制AI输出的平衡艺术，在日常问答中无需过度设计，但在多模态生成、高质量代码编写以及应用系统集成等需要精确格式控制的专业场景下，它是不可或缺的开发必修课。

十、Prompt五要素

1、角色与任务

在设计提示词（Prompt）时，首先要明确“角色”和“任务”。角色是告诉人工智能它当前扮演什么身份（例如资深架构师或文案撰稿人），这能让其自动调整语气、专业度和调取相关知识。任务则是清晰、具体地说明需要它做什么。任务的描述可以遵循 SMART 原则，即做到具体（Specific）、可衡量（Measurable）、可实现（Achievable）、相关性（Relevant）以及有时限（Time-bound），以此避免模糊不清的输出。

2、上下文与约束

“上下文”负责提供必要的背景信息。由于人工智能并不了解用户的具体场景，充分的背景交代（如目标用户、使用场景、核心优势等）能大幅提升回答的准确性与相关性。而“约束”则是为人工智能划定边界，明确规定什么不能做、必须遵守什么规则。常见的约束包括字数限制、禁止输出个人观点、限制返回的格式或语言，以及限定知识范围等，这能有效防止回答偏离主题。

3、格式规范

“格式”要素用于明确输出的结构要求。清晰的格式规范不仅便于人类阅读，也方便程序进行后续的数据处理。常见的输出格式包括 Markdown 列表、表格以及 JSON 格式。在需要结构化报告或程序解析的场景中，规范的格式必不可少。

如果需要让 AI 进行代码审查并按特定结构输出，一个包含核心要素的 Python API 调用及提示词示例如下：

Python

import openai

# 示例：融合角色、任务、格式与约束的 Prompt 设计
prompt = """
你是一位资深的Python代码审查专家。请分析以下代码的问题。

输出格式要求：
问题列表：
1. [问题类型] 问题描述（所在行号）

约束条件：
- 只返回问题列表和修改建议，不要输出任何寒暄或解释
- 必须使用中文回答
"""

4、总结

网页内容核心围绕“Prompt 五要素”展开，系统性地介绍了设计优秀提示词的核心框架：角色（Role）、任务（Task）、上下文（Context）、格式（Format）和约束（Constraints）。掌握这五个要素并灵活组合，能够帮助开发者或用户精确控制人工智能的输出质量、作答风格和返回结构，是提示词工程中的基础且核心的理论知识。

十一、结构化输出与常用模板

1、两种让AI输出JSON的方法与区别

在开发过程中，如果需要AI精确返回JSON格式的数据以便程序处理，通常有两种方法。

方法一是只在提示词中要求AI返回JSON。这种方式就像口头叮嘱，AI虽然大部分时候会照做，但往往会“热心”地附带一些大白话或Markdown代码块标签。这会导致程序在解析时频繁报错，需要开发者编写复杂的清洗代码去剔除冗余文本。因此，这种方法更适合需要兼顾“人读”和“机器读”的临时场景。

方法二是使用API参数强制JSON模式。通过在代码中配置参数 response_format = {"type": "json_object"}，可以从底层直接锁死AI的输出格式。在这种模式下，AI会隐去所有寒暄和解释，只输出纯粹、标准的JSON字符串。这种方法稳定性极高，不需要任何预处理即可直接被程序解析，是构建生产系统和批量处理时的首选。

2、底层强制JSON模式的代码实现

在实际开发中，使用支持JSON模式的模型（如示例中的qwen3.6-plus）时，可以直接在调用参数中加入格式约束，核心实现代码如下：

Python

response = client.chat.completions.create(
    model="qwen3.6-plus",
    messages=[
        {
            "role": "system",
            "content": """请分析以下代码，以JSON格式返回结果：
            {
                "complexity": "复杂度等级（高/中/低）",
                "issues": [...],
                "suggestions": [...]
            }
            """
        },
        { "role": "user", "content": "分析这段代码：[your code]" }
    ],
    response_format = { "type" : "json_object" } # 核心参数：底层强制锁定JSON格式
)

3、编写复杂提示词的常用模板与技巧

为了提高AI在特定场景下的表现，通常会使用结构化的提示词模板。最基础的是通用五要素模板，包含角色、任务、背景信息、输出要求和约束条件。此外还有专门针对写代码的代码生成模板，以及针对摘要或改写的文本处理模板。在实际应用中，不应死板地照搬模板，而需要根据具体的业务场景、数据特点和特殊要求添加细节。

在组织复杂的提示词时，推荐使用Markdown语法进行排版。用标题进行区域划分、用列表梳理硬性约束、用代码块包裹示例。这样做不仅能让大模型利用其在海量Markdown文档中训练出的结构识别能力更精准地理解重点，还能使内容的边界更加清晰、减少歧义，同时也极大方便了团队成员之间的协作与复用。

4、总结

网页主要介绍了在AI编程应用开发中，如何通过结构化输出和提示词模板来确保结果的精确与稳定。核心要点在于：机器读取数据时应通过API参数强制开启JSON模式以消除多余文本干扰，而面对复杂的业务需求时，则应善用Markdown语法去组织和定制提示词模板，从而降低输出的随机性，提升程序的健壮性。