前言Prompt Engineering没有死它只是进化了2023年Prompt Engineering横空出世大家争先学习如何跟AI说话。2024年有人宣布Prompt Engineering已死说以后的模型足够聪明不需要精心设计提示词。2026年现实给出了答案提示词工程没有死但它的边界已经从写一句话让AI输出结果扩展到了设计一套让多个AI协同工作的工程体系。Vibe Coding和Agentic Engineering是这个演进方向上的两个代表词前者描述了用自然语言驱动代码生成的新范式后者代表了用工程化方法设计AI系统的更高抽象。这篇文章我会从基础到进阶系统梳理2026年Prompt Engineering的完整知识体系——不是那种列出10条技巧就完事的文章而是告诉你每种技术为什么有效在什么场景下选哪个踩过什么坑。一、基础层你以为自己懂其实没懂的几个概念1.1 System Prompt vs User Prompt不是格式问题是权重问题很多人认为System Prompt只是告诉模型它的角色User Prompt才是真正的任务。这个理解在2023年还勉强正确但现在已经完全不够用。System Prompt的本质在模型处理每条消息之前建立一套持久的约束体系——包括输出格式、行为边界、领域知识、工具调用规则。它的权重在大多数模型中高于User Prompt这意味着如果两者冲突System Prompt通常胜出。importanthropic clientanthropic.Anthropic()# 错误示范把所有东西堆在User Prompt里bad_responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1000,messages[{role:user,content:你是一个Python代码审查专家只关注安全问题 用JSON格式输出不要废话审查以下代码 def login(username, password): query fSELECT * FROM users WHERE name{username} AND pwd{password} return db.execute(query) }])# 正确示范System Prompt承载稳定约束User Prompt专注于任务输入good_responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1000,system你是一位专注于安全漏洞识别的Python代码审查专家。 你的工作规则 1. 只输出发现的安全问题不做其他评论 2. 输出格式必须是JSON结构如下 {vulnerabilities: [{type: 漏洞类型, line: 行号, description: 描述, severity: high/medium/low, fix: 修复建议}]} 3. 如果代码没有安全问题输出 {vulnerabilities: []} 4. severity等级SQL注入/RCE/认证绕过为high信息泄露/越权为medium其他为low 不要输出JSON以外的任何内容包括markdown代码块标记。,messages[{role:user,content:请审查以下代码 python def login(username, password): query fSELECT * FROM users WHERE name{username} AND pwd{password} return db.execute(query) }])# 为什么第二种更好# 1. System Prompt的约束在多轮对话中持续有效User Prompt每次都要重复# 2. 格式约束放在System Prompt里模型更可能始终遵守# 3. User Prompt只需要关注这次的输入是什么降低认知负荷踩坑记录我曾经在一个生产系统里把输出格式要求放在User Prompt里结果发现在长对话中模型偶尔会忘记格式要求输出了普通文本。把格式约束迁移到System Prompt后这个问题消失了。1.2 温度Temperature和Top-P不是创意程度那么简单Temperature和Top-P是两个经常被混淆的参数大多数教程只会说temperature越高越有创意。这个描述虽然没错但在工程场景下完全不够用。Temperature的精确定义控制输出概率分布的平坦程度。Temperature0时模型总是选择概率最高的Token完全确定性Temperature1时按原始概率分布采样Temperature1时概率分布被拉平低概率选项被更多机会选中。# 不同场景下的Temperature选择# 场景1代码生成、数据提取、格式化输出# → 用低Temperature需要确定性和可重复性code_responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens500,temperature0.1,# 接近0代码生成不需要创意messages[{role:user,content:写一个Python函数计算列表的中位数}])# 场景2文案创作、头脑风暴、故事生成# → 用中等Temperature需要多样性但不能太离谱creative_responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens500,temperature0.7,# 适中平衡创意和连贯性messages[{role:user,content:为一款健康食品App写3个不同风格的宣传语}])# 场景3数学推理、逻辑分析# → 用极低Temperature甚至0# 注意不是所有模型都支持temperature0有些最低只能到0.0001math_responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens500,temperature0,# 数学题不需要任何随机性messages[{role:user,content:证明sqrt(2)是无理数}])# 踩坑提示# 很多人设置temperature0之后发现模型还是偶尔输出不同结果。# 这是因为现代LLM在推理时会使用并行采样等技术# temperature0只是尽量确定不保证100%可重复。# 如果需要完全可重复应该同时设置seed参数部分模型支持。二、进阶层真正提升输出质量的三大技术2.1 Chain-of-ThoughtCoT让模型先想后说CoT的原理很简单显式要求模型在给出最终答案之前先展示推理过程。研究表明这种方式能显著提高模型在复杂推理任务上的准确率有时提升幅度超过30%。但很多人用CoT的方式是错的——他们只是在Prompt末尾加了一句请一步步思考然后期待奇迹发生。# 粗糙的CoT写法效果一般basic_cot_prompt 分析这份代码性能瓶颈在哪里。请一步步思考。 代码{code} # 结构化CoT写法效果更好structured_cot_prompt 请分析以下代码的性能瓶颈。按照以下步骤进行分析 **第一步理解代码功能** 先描述这段代码做了什么输入输出是什么。 **第二步识别时间复杂度** 对每个主要函数分析其时间复杂度O(n)、O(n²)等。 **第三步识别空间复杂度** 分析内存使用模式是否有不必要的数据复制或缓存缺失 **第四步定位具体瓶颈** 基于以上分析指出1-3个最主要的性能瓶颈按影响程度排序。 **第五步给出优化方案** 对每个瓶颈给出具体可执行的优化建议并估计优化后的性能提升幅度。 代码 {code} # 为什么结构化CoT更好# 1. 明确的步骤迫使模型按逻辑顺序推进而不是跳步# 2. 每一步的输出成为下一步的输入形成推理链# 3. 如果某一步出了问题容易在输出中定位到错误位置2.2 Few-Shot Prompting用例子比用描述更有效有时候与其花500字描述你想要的输出格式不如直接给3个例子。模型的In-Context Learning能力非常强优质的示例往往比详尽的描述更有效。# 场景让模型将非结构化的客户反馈提取为结构化的工单# 零样本Zero-Shot版本 - 效果不稳定zero_shot_prompt 将以下客户反馈提取为结构化工单包含问题类型、紧急程度、客户情绪、建议行动。 反馈{feedback} # 少样本Few-Shot版本 - 效果更可预测few_shot_prompt 将客户反馈提取为结构化工单。以下是格式示例 ---示例1--- 反馈我昨天买的键盘空格键按不下去发货才3天就坏了我要退款 工单 - 问题类型产品质量缺陷 - 紧急程度高在保期内 - 客户情绪愤怒 - 建议行动立即联系客户道歉启动7天无理由退款流程同时记录产品缺陷 ---示例2--- 反馈请问你们的会员积分是怎么算的我买了1000块但积分没有到账。 工单 - 问题类型积分系统咨询/异常 - 紧急程度中 - 客户情绪困惑尚未愤怒 - 建议行动查询订单号对应积分入账记录24小时内给出解释或补录积分 ---示例3--- 反馈谢谢你们的快速配送东西很好下次还来买。 工单 - 问题类型正面反馈 - 紧急程度低无需紧急处理 - 客户情绪满意 - 建议行动记录为好评案例可回复感谢并推送会员优惠 ---正式任务--- 反馈{feedback} 工单 # 关键技巧# 1. 示例要覆盖不同类型的边界情况不要全是正常情况# 2. 示例之间用清晰的分隔符隔开防止模型混淆# 3. 示例的格式要与你期望的输出格式完全一致# 4. 一般3-5个示例效果最好超过10个边际效益递减2.3 结构化输出控制让模型输出你能直接使用的数据在工程场景里AI的输出通常不是给人直接看的而是要被代码解析、存入数据库、触发下游流程。这要求输出必须是精确的格式。importjsonfrompydanticimportBaseModelfromtypingimportList,Optional# 方法一在Prompt中精确描述JSON Schema# 优点简单直接缺点模型可能偶尔不遵守defextract_with_schema(text:str)-dict: 为什么要在Prompt里写完整的Schema而不是只说输出JSON 输出JSON会让模型自己决定字段名和结构每次可能不一样。 写完整Schema能把格式固定下来让下游代码可以稳定解析。 promptf 从以下文本中提取产品信息严格按照以下JSON Schema输出不要添加任何字段 Schema {{ product_name: string产品名称, price: number价格元如果没有价格信息则为null, category: string产品类别从以下选项中选择电子产品/服装/食品/其他, features: [string数组产品特点最多5条], in_stock: boolean是否有货如果未提及则为true }} 只输出JSON对象不要包含任何其他文字不要使用markdown代码块。 文本{text}responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens500,temperature0,# 结构化提取用最低温度messages[{role:user,content:prompt}])result_textresponse.content[0].text.strip()# 防御性解析处理模型可能输出的各种格式污染# 踩坑经历即使明确说不要代码块模型有时还是会输出json...ifresult_text.startswith():linesresult_text.split(\n)result_text\n.join(lines[1:-1])# 去掉第一行和最后一行的try:returnjson.loads(result_text)exceptjson.JSONDecodeErrorase:# 记录原始输出便于调试print(fJSON解析失败原始输出\n{result_text}\n错误{e})raise# 方法二使用Anthropic的工具调用Tool Use# 优点格式保证更强模型专门为填写参数优化缺点需要多一步tool_result处理defextract_with_tool_use(text:str)-dict: 工具调用方式的输出格式保证性更强。 原理模型在tool_use模式下会把输出当作函数参数来填写 而不是自由生成文本因此对结构的遵守程度更高。 适用场景对格式一致性要求极高的生产系统 tools[{name:save_product_info,description:保存从文本中提取的产品信息,input_schema:{type:object,properties:{product_name:{type:string,description:产品名称},price:{type:[number,null],description:价格元},category:{type:string,enum:[电子产品,服装,食品,其他],description:产品类别},features:{type:array,items:{type:string},maxItems:5,description:产品特点列表},in_stock:{type:boolean,description:是否有货}},required:[product_name,category,features,in_stock]}}]responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens500,toolstools,tool_choice{type:tool,name:save_product_info},# 强制使用此工具messages[{role:user,content:f请从以下文本中提取产品信息\n\n{text}}])# 从响应中找到tool_use类型的blockforblockinresponse.content:ifblock.typetool_use:returnblock.inputraiseValueError(模型没有调用工具)三、顶层Agentic Engineering——把Prompt变成工程到了Agentic Engineering层面Prompt已经不只是一段文字而是一套系统设计包括工具定义、状态传递、错误处理、人机协作接口。3.1 Vibe Coding是什么为什么它改变了软件开发Vibe Coding是2025年Andrej Karpathy前OpenAI研究总监提出的概念描述的是这样一种开发模式开发者用自然语言描述需求AI生成代码开发者的角色从写代码变为审代码 描述需求。这不是夸张在实际项目中我们团队已经实现了超过70%的代码由AI初稿# Vibe Coding的核心学会写意图驱动的Prompt而不是步骤驱动的Prompt# 传统方式步骤驱动bad_vibe_prompt 1. 创建一个Python类 2. 类名叫UserAuthenticator 3. 有一个login方法接收username和password参数 4. 查询数据库验证用户 5. 生成JWT token 6. 返回token字符串 # 这种方式的问题你在告诉AI怎么做而不是做什么# 导致AI照你说的一步步实现但可能错过很多工程最佳实践# Vibe Coding方式意图驱动good_vibe_prompt 我需要一个用户认证模块用于一个中等规模的Python Web API。 业务需求 - 用户用邮箱密码登录 - 登录成功后颁发JWT有效期24小时 - 连续5次失败锁定账号15分钟 - 密码在数据库中必须是哈希存储 技术约束 - 使用SQLAlchemy作为ORMUser模型已有email, password_hash, failed_attempts, locked_until字段 - JWT库使用PyJWT - 兼容FastAPI的依赖注入系统 质量要求 - 包含类型注解 - 关键路径要有错误处理数据库连接失败、token生成失败等 - 函数有docstring 请按照Python最佳实践实现如果有我没考虑到的安全问题请在代码注释中指出。 3.2 CLAUDE.mdAgentic Engineering的宪法文件在使用Claude Code等终端AI编程工具时CLAUDE.md文件扮演了类似项目宪法的角色——它告诉AI这个项目的技术栈、编码规范、禁区和偏好在每次对话开始时自动加载。# CLAUDE.md 示例放在项目根目录 ## 项目概述 这是一个基于FastAPI的电商后端API使用PostgreSQL Redis部署在K8s上。 ## 技术栈 - 语言Python 3.12 - Web框架FastAPI 0.110 - ORMSQLAlchemy 2.0使用async模式 - 认证JWTPyJWTAPI Key用于服务间调用 - 缓存Redis通过aioredis - 测试pytest pytest-asyncio ## 编码规范 - 所有函数必须有类型注解 - 数据库查询使用async/await禁止同步查询 - 错误处理业务错误用自定义Exception类不要直接raise HTTPException - 日志使用structlog禁止使用print() ## 禁区AI不要自作主张修改的地方 - /app/core/security.py - 安全模块修改前必须人工审查 - alembic/versions/ - 数据库迁移文件不要自动生成或修改 - 任何涉及支付的代码 ## 当前技术债 - UserService中有几个同步数据库调用还未迁移到async已知问题暂时保留 - 部分旧接口还在使用Pydantic v1语法迁移中 ## 代码生成偏好 - 优先使用依赖注入而非全局变量 - Repository Pattern数据库操作放在repository层不要在router里直接写SQL - 新功能都要有对应的单元测试为什么CLAUDE.md很重要没有它每次开启新对话AI对项目的理解都是零。有了它AI就像一个读过所有项目文档的新队友——它知道哪里有技术债、哪里不能动、代码风格是什么。四、2026年Prompt Engineering速查手册场景推荐技术Temperature关键要素代码生成Few-Shot 结构化CoT0~0.1意图驱动给技术约束数据提取Tool Use Schema0精确的字段定义和枚举内容创作Zero-Shot 风格描述0.6~0.9目标受众、语气、长度代码审查CoT 优先级排序0.1明确关注点安全/性能/可读性复杂推理结构化CoT 步骤验证0让模型显示每步推理Multi-Agent编排System Prompt Tool Use0~0.2清晰的角色定义和边界总结Prompt Engineering在2026年已经从技巧进化成了工程纪律。入门的边界是学会区分System/User Prompt选对Temperature用Few-Shot代替啰嗦的描述。进阶的边界是用CoT让模型显示推理用工具调用锁定输出格式用结构化Schema替代输出JSON这种模糊指令。顶层的边界是用CLAUDE.md等项目级配置让AI理解你的系统用Agentic Engineering的视角把Prompt设计提升到系统架构层面。最后说一句Prompt的质量本质上反映的是你对任务的理解深度。写不好Prompt往往不是AI的问题而是你还没想清楚自己真正要什么。