你有没有过这种感觉同一个 AI 工具别人输入一小段提示词几十秒后拿到的是结构完整、逻辑清晰、可以直接使用的方案你也输入了一段提示词模型回复了一大堆仔细一看全是正确的废话。不是模型的问题也不是你运气差。真正拉开差距的是 prompt 本身的写法、颗粒度和约束条件。本文会围绕 prompt 工程这个主题把“AI 高手写 prompt”的方式拆开来讲。你会看到普通写法和高手写法在真实场景中的对比也会拿到一套可以直接套用的高质量 prompt 编写框架以及日常使用过程中的常见问题与排查思路。这篇文章适合所有想让大模型真正提升效率的开发者无论你是刚接触 AI 编程还是已经在用各类大模型辅助开发都值得从头到尾读一遍。1. 为什么 prompt 水平会决定 AI 输出质量1.1 大模型不是搜索引擎而是“预测下一句话”的系统很多人使用大模型时习惯像百度搜索一样输入关键词比如“Python 读取 Excel 文件”。如果把它当成搜索词模型确实会给你一段相关答案但如果把它当成一个工程需求来表达你会得到一份更精确、更可执行的代码。这里的关键在于理解大模型的工作原理。无论是 GPT 系列、Claude、还是国产的开源模型底层都是基于海量语料训练的神经网络。当你输入 prompt 时模型做的事情本质上是“根据你已经给出的文字预测最可能接续的内容”。也就是说你的 prompt 越清晰、越具体、越有约束模型越容易预测到你想要的内容你的 prompt 越模糊、越宽泛模型就只能在最“安全”的方向上输出。这也是为什么同一个问题两个不同的人会得到完全不同的结果。高手写 prompt 时会不自觉地把自己变成“项目经理”从背景、角色、目标、格式、约束、示例等多个维度把需求描述清楚。普通人写 prompt 时常常只给出一个目标甚至只给出几个关键词。1.2 普通人和 AI 高手在 prompt 上的核心差距观察过很多同学使用大模型后会发现普通人和 AI 高手之间的差距集中体现在以下几个方面对比维度普通用户写 promptAI 高手写 prompt需求描述“帮我写个爬虫”“帮我写一个 Python 爬虫抓取目标网站的新闻标题和发布时间使用 requestsBeautifulSoup要求异常处理完整输出为 CSV 文件”上下文提供不给背景直接问主动交代任务背景、数据规模、运行环境、可选方案角色设定不用角色根据任务设定“资深后端工程师”“数据分析师”“Oracle DBA”等角色输出格式不作要求明确要求输出 JSON、Markdown 表格、代码块、进阶方案等边界与约束不提限制条件明确说明不要使用某库、不要超出某版本、代码需要兼容 Windows示例参考从不给示例会给一个期望输入的示例和期望输出引导模型模仿错误纠正输出不对就重开对话直接指出错误点让模型重新分析再修改这张表基本可以概括核心差距高手不是在“提问”而是在“写需求文档”。当你能把 prompt 当需求文档来写的时候AI 的输出质量会有一个质的提升。1.3 什么是 prompt engineering为什么现在值得系统学Prompt engineering 被称为提示工程是指通过设计和优化输入文本让大模型更稳定、更准确地完成特定任务的一整套方法。它不是简单的“怎么问问题”而是包含任务拆解、上下文组织、示例设计、格式约束、多轮修正、模型能力边界判断等系统性工程。在 AI 编程工具、AI Agent、RAG检索增强生成等应用越来越普遍的背景下prompt 已经不只是聊天窗口中的一句话而是应用系统中的一个关键组件。比如你用 LangChain 搭建一个文档问答机器人系统提示词直接决定回答的专业性和准确性你用 Cursor 辅助编程prompt 决定它生成的代码是符合项目结构还是天马行空。可以说prompt 水平已经变成了 AI 时代的一项基础能力类似十年前用搜索引擎查资料的能力。2. 普通 prompt 与高手 prompt 的实战对比下面通过五个开发过程中出现频率很高的场景来直观感受一下 prompt 写法的差异。2.1 场景一写一个 Python 函数先来看普通写法帮我写一个 Python 函数用来判断一个字符串是不是合法的 IP 地址。这个 prompt 不够差但也不够好。模型可能会给你一个简单的 split 逻辑但不会考虑 IPv4 和 IPv6 的区别不会考虑前导零、端口号、CIDR 表示法也不会考虑空字符串和 None 的边界情况。如果你是在生产项目里用这个函数大概率要返工。高手会这样写你是一个拥有 10 年经验的 Python 后端工程师。请帮我实现一个函数用于校验字符串是否为合法的 IPv4 地址。 需求如下 1. 函数签名def is_valid_ipv4(ip_str: str) - bool 2. 只校验 IPv4不校验 IPv6 3. 每段取值范围 0-255不允许有前导零如 01.2.3.4 应返回 False 4. 输入可能是 None、空字符串、含空格字符串都要返回 False 5. 不需要处理端口号和 CIDR 后缀 请先给出完整的函数实现然后给出 5 组测试用例包含正常地址、非法地址、前导零地址、空字符串和 None。 输出格式 - 代码使用 python 代码块 - 测试用例使用表格列名为输入 | 期望输出 | 说明看出差别了吗高手把需求文档中的验收标准写进了 prompt函数签名、边界条件、输入类型、输出格式全部明确。模型不再需要猜它的输出自然就更精准、更贴近真实项目要求。2.2 场景二编写并优化一条 SQL 查询普通写法写一条 SQL查询每个部门的平均工资。这个写法在表结构不明确的情况下模型只能编造字段名你拿到手还得改半天。高手会先把表和业务背景交代清楚你是一位熟悉 Oracle 的数据库开发工程师。现有两张表 - employees 表字段包括 emp_id员工ID、emp_name员工姓名、dept_id部门ID、salary工资NUMBER(10,2) - departments 表字段包括 dept_id部门ID、dept_name部门名称 请写一条 SQL查询每个部门的平均工资要求 1. 输出 dept_name 和 avg_salary 两列avg_salary 保留两位小数 2. 只需要统计有员工的部门没有员工的部门不需要出现在结果中 3. 使用表别名可读性要强 4. 如果部门下有多个员工按平均工资从高到低排序 先给出 SQL再用一句话解释这条 SQL 的执行逻辑。如果在真实业务中你还可以要求它用分析函数、要求它评估索引方案、要求它对比 GROUP BY 和窗口函数的性能差异。信息给得越齐全模型的回答越接近一个团队资深 DBA 的水平。2.3 场景三让 AI 帮你总结技术文档普通写法是总结一下这篇文章的内容。如果你只把一段文档原文粘贴进去然后给出这样一个 prompt模型会返回一个泛泛的摘要抓不住重点。如果你是做汇报、写周报、写技术方案这种结果基本没法用。高手会这样写你是一位技术文档分析师。下面是我提供的一篇关于微服务架构中分布式事务方案的技术文章。 请完成以下任务 1. 提取文章的核心观点控制在 5 条以内 2. 对比文章提到的各种方案指出各自的使用场景和优缺点 3. 最后给出一段 100 字左右的总结适合写入技术周报 要求 - 使用中文回答 - 每个核心观点用加粗标题开头 - 不要添加文章中没有提到的信息 - 如果文章内容存在模糊或矛盾之处请明确指出 以下是文章内容 【粘贴文章原文】这种写法最关键的一点是给了模型明确的“输出任务清单”。它不是让模型自由发挥而是让它像完成三项工作一样逐项执行这样生成的内容结构完整还能直接拿去用。2.4 场景四生成一段正则表达式正则表达式是很多开发者觉得头疼的内容也是 AI 很擅长生成的内容。但普通写法同样容易翻车。普通写法给我一个匹配邮箱的正则。这样的结果往往忽略了下划线、域名层级、中文字符等边界情况。而且你没有告诉模型你用的是 Python 还是 JavaScript不同语言的转义和正则引擎行为是有差异的。高手会这样写你是一位正则表达式专家。请帮我写一个用于匹配电子邮件地址的正则表达式运行环境是 Python 3使用 re 模块。 要求 1. 支持常见的邮箱格式用户名域名例如 zhangsanexample.com、zhang.sansub.example.com.cn 2. 用户名部分允许字母、数字、点、下划线和短横线 3. 域名部分至少包含一个点不允许以点开头或结尾 4. 不需要匹配显示名称不需要匹配带注释的复杂格式 请按以下格式输出 1. 正则表达式本体放在 Python 代码块中 2. 一段简短的说明解释这个正则的每一个组成部分 3. 给出 5 个匹配成功和 5 个匹配失败的示例 注意我需要的是完整可运行的 Python 代码不是简化示意。这样写出来的结果不仅能用还能帮你理解每一个字符的含义。下次再遇到类似需求你甚至可以自己修改一部分规则。2.5 场景五用 AI 排查代码报错普通写法代码报错帮我看看 File test.py, line 10, in module result divide(a, b) ZeroDivisionError: division by zero模型当然能看出来是除以零但它不知道你的意图也不知道这段代码在什么场景下运行最后给的建议多半只是“加一个 if 判断”。高手会这样写我遇到一个 ZeroDivisionError这是相关代码 【代码片段】 触发场景用户上传订单金额后系统计算折扣率时出现异常。 我已经尝试在计算前判断分母是否为 0但问题仍然出现。 请按下面步骤帮我排查 1. 分析这段代码的逻辑指出除数为 0 的几种可能触发路径 2. 给出一个修复方案要求不改变原有的业务逻辑 3. 如果使用防御式编程请给出 try-except 和 if 判断两种写法并对比它们的适用场景 4. 告诉我如何补充日志方便以后定位类似问题 代码运行环境Python 3.10Django 4.2。带上场景、环境、已经尝试过的方法模型给出的建议会更有针对性不会从头开始教你写 if 判断。这里面的核心思路是把模型当成团队里一位刚接手你代码的同事你描述得越完整它给出的建议越靠谱。3. 高质量 Prompt 的六个核心要素通过上面的对比可以总结出一个高质量 prompt 的通用框架。熟练掌握这六个要素你就能丢掉网上那些“万能模板”自己根据任务组合出合适的 prompt。3.1 角色Role给模型设定角色相当于告诉它用哪套知识体系和表达习惯来回答。举例“你是一位熟悉 Spring Security 的 Java 架构师”“你是一位有 10 年经验的数据分析师”“你是一位 Oracle 数据库性能优化专家”角色设定不是万能的但它可以明显改变模型的输出风格。设置角色后模型的输出会更加偏向该领域的术语、行文习惯和关注重点对于需要专业性的任务特别有效。3.2 任务Task任务要使用明确的动词比如“实现”“对比”“排查”“解释”“重构”。不要用含糊的“帮我看看”“说一下”这类表达。模糊的任务会得到模糊的结果这是最简单但也最重要的一条原则。判断任务是否清晰的方法很简单把 prompt 中描述任务的句子读出来如果换一个人也能准确完成说明描述足够清晰如果听完之后还一头雾水那就需要继续拆解。3.3 上下文Context上下文是任务之外的背景信息包括运行环境、数据规模、项目架构、技术栈、调用方是谁、最终用户是谁等。对于开发任务建议至少包含编程语言和版本使用的框架和版本操作系统或部署环境涉及的数据表结构或接口定义目前已有的代码逻辑上下文越丰富模型给出的答案越接近你项目的真实情况。但也要注意不要塞入无关信息上下文太长会干扰模型注意力还可能导致 token 超限。3.4 示例Example在 prompt 中给出示例这种技术在提示工程里称为 few-shot learning是提升模型输出稳定性最有效的手段之一。举个例子如果你想让模型把一段产品需求改写成技术任务清单可以在 prompt 中先给出一个“输入…… 输出……”的示例。模型会模仿你给的格式和思路来生成后续内容。对格式一致性要求高的任务示例几乎是必须的。3.5 格式Format明确输出格式是提升 prompt 可用性的关键一步。比如用 Markdown 表格输出对比结果用 JSON 格式输出并给出字段说明用 Python 代码块输出代码用有序列表输出步骤用代码块加注释的方式输出配置文件模型本身非常擅长格式化输出但如果你不告诉它你想要的格式它就会默认选择自己最熟悉的输出方式。对于后续要程序化处理的内容建议在 prompt 中直接定义一个 JSON 结构并说明每个字段的含义。3.6 约束Constraint约束是告诉模型“不要做什么”。常见的约束包括不要使用某个第三方库不要修改现有接口签名不要输出与问题无关的背景知识代码需要兼容 Python 3.8 以下版本不要使用新语法特性回答控制在 500 字以内如果信息不足直接说不知道不要编造约束还有一个重要作用降低大模型的幻觉Hallucination风险。大模型在信息不确定时倾向于生成看起来合理的内容如果你明确要求“不要编造数据”“没有的信息要说明”它会更谨慎地回答问题。4. 一个可以直接套用的 Prompt 模板结合上面六要素下面给出一个适合大多数开发场景的通用模板。你可以把它保存在笔记软件中用时替换占位符。# 角色 你是一位【填写角色如精通 Python 的资深后端工程师】 # 任务 请帮助我【填写具体任务如实现一个带超时控制的重试机制】 # 背景 【这里填写任务背景、使用场景、相关代码、数据结构等】 # 约束 1. 环境Python 3.10Windows 11 2. 不要额外引入第三方依赖 3. 需要处理边界条件包括【填写边界情况】 4. 代码需要添加详细的注释 # 输出格式 1. 完整代码放在 Python 代码块中 2. 使用要点说明使用无序列表 3. 针对边界条件的测试用例使用表格 # 参考示例 输入【示例输入】 输出【示例输出】使用这个模板时不需要每次都填满所有项。简单任务可以省略角色和参考示例复杂任务可以把上下文补充得更详实。关键是养成结构化表达的习惯而不是每次都复制模板却不知道每项的意义。5. 常见问题与排查思路5.1 模型输出太泛泛而谈不够深入这是最常见的现象。可能的原因有两种一是任务描述太宽泛二是没有添加角色和约束。排查时先给模型补充背景信息再把任务拆细。比如“帮我想想怎么优化接口性能”可以改成“我们有一个查询订单列表的接口平均耗时 800ms数据库是 MySQL 8.0单表数据量约 100 万已经加了索引但效果不明显。请从 SQL 优化、缓存策略、分页方式三个角度给出优化方案每个方案要说明原理和适用场景。”5.2 模型给出错误信息或编造内容这就是前面提到的幻觉问题。最直接的处理方式是在 prompt 中明确声明“如果你不确定请直接回答‘信息不足’不要编造数据”。对于重要技术细节还可以要求模型在回答中标注“这部分需要实测确认”或“以官方文档为准”。养成核实关键信息的习惯比任何 prompt 技巧都重要。5.3 提示词太长导致报错或截断大模型的上下文窗口是有限制的。当你粘贴大量文档然后提问时如果超出模型支持的 token 数会出现“conversation too long”“the number of tokens is greater than”之类报错。解决方案有几种先让模型分段总结再合并只粘贴关键段落而不是全文如果使用 API可以利用向量数据库做检索再拼接上下文也可以使用支持超长上下文的模型。另外精简 prompt 本身也能节省 token减少成本。5.4 输出格式不稳定有时 JSON 解析失败这个问题在使用 API 开发应用时特别常见。模型虽然能输出 JSON但偶尔会带上多余的解释文字或者使用不合法转义。解决办法是在 prompt 中给出一个 JSON 示例强制模型只输出 JSON 内容不要输出其他文字。如果问题频繁还可以在代码中加一层解析容错逻辑先提取代码块内容再解析。5.5 多轮对话后模型“忘”了之前的任务多轮对话中模型实际上需要依赖整段上下文。随着对话变长早期的信息权重会降低。如果模型出现“忘记”情况可以在后续 prompt 中重新简述一下任务。对于复杂的长期任务更推荐开启新对话并一次性写好完整 prompt而不是在长对话里一直追加。5.6 Prompt 被安全策略拦截有时候输入的 prompt 因为包含某些敏感词或疑似恶意内容会被模型自身的策略拦截返回类似“your prompt was flagged as potentially violating our usage policy”的提示。这种时候先检查自己的输入是否涉及恶意行为、违法信息、暴力内容等。如果确认没有违规可以改写表达方式把意图描述得更规范再提交。6. 把 Prompt 当代码来管理工程化最佳实践6.1 用版本管理工具保存 Prompt在工作中我发现很多开发者会把好的代码片段保存在 Git 仓库里却把精心调试过的 prompt 随手丢在聊天记录中。等到下次要用时只能重新在对话历史里翻找。更好的做法是把重要 prompt 以文件形式保存下来纳入版本管理。文件格式可以用 Markdown也可以根据使用场景用 JSON、YAML。一个提示词工程项目的目录结构可以参考prompts/ ├── code-review/ │ ├── v1.md │ ├── v2.md │ └── README.md ├── sql-optimization/ │ └── prompt.md ├── doc-summary/ │ └── prompt.json └── templates/ └── common-template.md每次调整 prompt 时保留新旧版本并在 README 中记录调整原因和效果差异。这种做法会在长期使用中带来非常大的收益。6.2 给 Prompt 建立测试集Prompt 和代码一样也可能出现“改了一处影响全局”的问题。如果你正在开发依赖 prompt 的应用建议建一个固定的测试集。测试集包含多组输入和期望输出每次修改 prompt 后都跑一遍测试集观察稳定性和正确率。测试集记录格式可以是这样的 Excel 表格或 JSON[ { id: case_001, task: 根据订单数据生成周报, input: 订单数据本周销售额 120 万元环比增长 15%客单价 230 元, expected: 包含销售额、环比增速、客单价三个核心指标并给出趋势判断 }, { id: case_002, task: 解析用户地址, input: 北京市海淀区中关村大街 1 号, expected: 输出结构化 JSON省份、城市、区县、详细地址字段正确 } ]6.3 把变量和 Prompt 分离在开发 AI 应用时建议把 prompt 模板和具体参数变量分开维护。例如使用 Python 开发时可以这样组织# 文件路径prompts/summary_prompt.py SUMMARY_PROMPT_TEMPLATE 你是一位产品经理。请根据以下内容生成一份项目周报。 输入内容 {document} 要求 1. 总结本周完成的工作 2. 输出风险与待协调事项 3. 全部内容不超过 {max_words} 字 输出格式 ## 本周进展 …… ## 风险与待办 …… 这样设计之后当你需要改变语气、调整输出字段时只需要改模板文件不需要修改业务调用逻辑。如果使用 LangChain 这类编排框架还可以方便地与 RAG、Agent 等模块结合。6.4 记录使用效果持续优化每次使用 Prompt 时记录一下效果比如“代码是否可直接运行”“是否还需要人工大改”“格式是否稳定”。一周下来你就能发现哪些任务的 prompt 需要优化哪些场景的 prompt 已经可以固化复用。持续迭代的重要性甚至比“第一次写好”更重要。6.5 注意隐私与成本边界在使用 prompt 的过程中需要注意数据安全。不要将内部敏感数据、未公开的业务信息、客户隐私数据直接粘贴到线上模型中尤其是通过公网工具聊天窗口使用时。企业开发时如果涉及敏感数据应优先使用私有化部署的模型或通过合规渠道调用。另外长 prompt 会消耗更多 token直接增加 API 调用成本。在实际开发中可以用选择关键上下文代替全文粘贴用精简指令代替啰嗦描述这部分节省下来的成本在规模化调用时非常可观。7. 总结与下一步行动回到最开始的问题你跟 AI 高手的 prompt 水平差距到底有多大答案也许没有你想象中那么大。只要你开始把 prompt 当需求文档来写把角色、任务、上下文、示例、格式、约束六个要素记在脑子里用实战对比中的思路去组织每一次提问你很快就能发现自己拿到的输出质量明显提升。建议你从今天开始做三件小事第一把你最近使用大模型时效果最差的三个问题找出来按本文的框架重写一遍对比前后输出差异第二为自己高频使用的任务编写一个固定的 prompt 模板例如代码审查模板、SQL 优化模板、技术方案模板第三用一段时间积累自己的 prompt 库像整理代码一样整理它们。等你能随手写出信息密度高、约束清晰的 prompt 时你会发现自己使用 AI 的方式已经和以前完全不同了。如果以后写代码、写文档、做数据分析时再遇到大模型输出不符合预期先别急着换工具回到 prompt 本身找原因。绝大多数时候差的不是模型而是我们表达需求的方式。 Prompt工程实战：从普通提问到高手写法的核心方法
你有没有过这种感觉同一个 AI 工具别人输入一小段提示词几十秒后拿到的是结构完整、逻辑清晰、可以直接使用的方案你也输入了一段提示词模型回复了一大堆仔细一看全是正确的废话。不是模型的问题也不是你运气差。真正拉开差距的是 prompt 本身的写法、颗粒度和约束条件。本文会围绕 prompt 工程这个主题把“AI 高手写 prompt”的方式拆开来讲。你会看到普通写法和高手写法在真实场景中的对比也会拿到一套可以直接套用的高质量 prompt 编写框架以及日常使用过程中的常见问题与排查思路。这篇文章适合所有想让大模型真正提升效率的开发者无论你是刚接触 AI 编程还是已经在用各类大模型辅助开发都值得从头到尾读一遍。1. 为什么 prompt 水平会决定 AI 输出质量1.1 大模型不是搜索引擎而是“预测下一句话”的系统很多人使用大模型时习惯像百度搜索一样输入关键词比如“Python 读取 Excel 文件”。如果把它当成搜索词模型确实会给你一段相关答案但如果把它当成一个工程需求来表达你会得到一份更精确、更可执行的代码。这里的关键在于理解大模型的工作原理。无论是 GPT 系列、Claude、还是国产的开源模型底层都是基于海量语料训练的神经网络。当你输入 prompt 时模型做的事情本质上是“根据你已经给出的文字预测最可能接续的内容”。也就是说你的 prompt 越清晰、越具体、越有约束模型越容易预测到你想要的内容你的 prompt 越模糊、越宽泛模型就只能在最“安全”的方向上输出。这也是为什么同一个问题两个不同的人会得到完全不同的结果。高手写 prompt 时会不自觉地把自己变成“项目经理”从背景、角色、目标、格式、约束、示例等多个维度把需求描述清楚。普通人写 prompt 时常常只给出一个目标甚至只给出几个关键词。1.2 普通人和 AI 高手在 prompt 上的核心差距观察过很多同学使用大模型后会发现普通人和 AI 高手之间的差距集中体现在以下几个方面对比维度普通用户写 promptAI 高手写 prompt需求描述“帮我写个爬虫”“帮我写一个 Python 爬虫抓取目标网站的新闻标题和发布时间使用 requestsBeautifulSoup要求异常处理完整输出为 CSV 文件”上下文提供不给背景直接问主动交代任务背景、数据规模、运行环境、可选方案角色设定不用角色根据任务设定“资深后端工程师”“数据分析师”“Oracle DBA”等角色输出格式不作要求明确要求输出 JSON、Markdown 表格、代码块、进阶方案等边界与约束不提限制条件明确说明不要使用某库、不要超出某版本、代码需要兼容 Windows示例参考从不给示例会给一个期望输入的示例和期望输出引导模型模仿错误纠正输出不对就重开对话直接指出错误点让模型重新分析再修改这张表基本可以概括核心差距高手不是在“提问”而是在“写需求文档”。当你能把 prompt 当需求文档来写的时候AI 的输出质量会有一个质的提升。1.3 什么是 prompt engineering为什么现在值得系统学Prompt engineering 被称为提示工程是指通过设计和优化输入文本让大模型更稳定、更准确地完成特定任务的一整套方法。它不是简单的“怎么问问题”而是包含任务拆解、上下文组织、示例设计、格式约束、多轮修正、模型能力边界判断等系统性工程。在 AI 编程工具、AI Agent、RAG检索增强生成等应用越来越普遍的背景下prompt 已经不只是聊天窗口中的一句话而是应用系统中的一个关键组件。比如你用 LangChain 搭建一个文档问答机器人系统提示词直接决定回答的专业性和准确性你用 Cursor 辅助编程prompt 决定它生成的代码是符合项目结构还是天马行空。可以说prompt 水平已经变成了 AI 时代的一项基础能力类似十年前用搜索引擎查资料的能力。2. 普通 prompt 与高手 prompt 的实战对比下面通过五个开发过程中出现频率很高的场景来直观感受一下 prompt 写法的差异。2.1 场景一写一个 Python 函数先来看普通写法帮我写一个 Python 函数用来判断一个字符串是不是合法的 IP 地址。这个 prompt 不够差但也不够好。模型可能会给你一个简单的 split 逻辑但不会考虑 IPv4 和 IPv6 的区别不会考虑前导零、端口号、CIDR 表示法也不会考虑空字符串和 None 的边界情况。如果你是在生产项目里用这个函数大概率要返工。高手会这样写你是一个拥有 10 年经验的 Python 后端工程师。请帮我实现一个函数用于校验字符串是否为合法的 IPv4 地址。 需求如下 1. 函数签名def is_valid_ipv4(ip_str: str) - bool 2. 只校验 IPv4不校验 IPv6 3. 每段取值范围 0-255不允许有前导零如 01.2.3.4 应返回 False 4. 输入可能是 None、空字符串、含空格字符串都要返回 False 5. 不需要处理端口号和 CIDR 后缀 请先给出完整的函数实现然后给出 5 组测试用例包含正常地址、非法地址、前导零地址、空字符串和 None。 输出格式 - 代码使用 python 代码块 - 测试用例使用表格列名为输入 | 期望输出 | 说明看出差别了吗高手把需求文档中的验收标准写进了 prompt函数签名、边界条件、输入类型、输出格式全部明确。模型不再需要猜它的输出自然就更精准、更贴近真实项目要求。2.2 场景二编写并优化一条 SQL 查询普通写法写一条 SQL查询每个部门的平均工资。这个写法在表结构不明确的情况下模型只能编造字段名你拿到手还得改半天。高手会先把表和业务背景交代清楚你是一位熟悉 Oracle 的数据库开发工程师。现有两张表 - employees 表字段包括 emp_id员工ID、emp_name员工姓名、dept_id部门ID、salary工资NUMBER(10,2) - departments 表字段包括 dept_id部门ID、dept_name部门名称 请写一条 SQL查询每个部门的平均工资要求 1. 输出 dept_name 和 avg_salary 两列avg_salary 保留两位小数 2. 只需要统计有员工的部门没有员工的部门不需要出现在结果中 3. 使用表别名可读性要强 4. 如果部门下有多个员工按平均工资从高到低排序 先给出 SQL再用一句话解释这条 SQL 的执行逻辑。如果在真实业务中你还可以要求它用分析函数、要求它评估索引方案、要求它对比 GROUP BY 和窗口函数的性能差异。信息给得越齐全模型的回答越接近一个团队资深 DBA 的水平。2.3 场景三让 AI 帮你总结技术文档普通写法是总结一下这篇文章的内容。如果你只把一段文档原文粘贴进去然后给出这样一个 prompt模型会返回一个泛泛的摘要抓不住重点。如果你是做汇报、写周报、写技术方案这种结果基本没法用。高手会这样写你是一位技术文档分析师。下面是我提供的一篇关于微服务架构中分布式事务方案的技术文章。 请完成以下任务 1. 提取文章的核心观点控制在 5 条以内 2. 对比文章提到的各种方案指出各自的使用场景和优缺点 3. 最后给出一段 100 字左右的总结适合写入技术周报 要求 - 使用中文回答 - 每个核心观点用加粗标题开头 - 不要添加文章中没有提到的信息 - 如果文章内容存在模糊或矛盾之处请明确指出 以下是文章内容 【粘贴文章原文】这种写法最关键的一点是给了模型明确的“输出任务清单”。它不是让模型自由发挥而是让它像完成三项工作一样逐项执行这样生成的内容结构完整还能直接拿去用。2.4 场景四生成一段正则表达式正则表达式是很多开发者觉得头疼的内容也是 AI 很擅长生成的内容。但普通写法同样容易翻车。普通写法给我一个匹配邮箱的正则。这样的结果往往忽略了下划线、域名层级、中文字符等边界情况。而且你没有告诉模型你用的是 Python 还是 JavaScript不同语言的转义和正则引擎行为是有差异的。高手会这样写你是一位正则表达式专家。请帮我写一个用于匹配电子邮件地址的正则表达式运行环境是 Python 3使用 re 模块。 要求 1. 支持常见的邮箱格式用户名域名例如 zhangsanexample.com、zhang.sansub.example.com.cn 2. 用户名部分允许字母、数字、点、下划线和短横线 3. 域名部分至少包含一个点不允许以点开头或结尾 4. 不需要匹配显示名称不需要匹配带注释的复杂格式 请按以下格式输出 1. 正则表达式本体放在 Python 代码块中 2. 一段简短的说明解释这个正则的每一个组成部分 3. 给出 5 个匹配成功和 5 个匹配失败的示例 注意我需要的是完整可运行的 Python 代码不是简化示意。这样写出来的结果不仅能用还能帮你理解每一个字符的含义。下次再遇到类似需求你甚至可以自己修改一部分规则。2.5 场景五用 AI 排查代码报错普通写法代码报错帮我看看 File test.py, line 10, in module result divide(a, b) ZeroDivisionError: division by zero模型当然能看出来是除以零但它不知道你的意图也不知道这段代码在什么场景下运行最后给的建议多半只是“加一个 if 判断”。高手会这样写我遇到一个 ZeroDivisionError这是相关代码 【代码片段】 触发场景用户上传订单金额后系统计算折扣率时出现异常。 我已经尝试在计算前判断分母是否为 0但问题仍然出现。 请按下面步骤帮我排查 1. 分析这段代码的逻辑指出除数为 0 的几种可能触发路径 2. 给出一个修复方案要求不改变原有的业务逻辑 3. 如果使用防御式编程请给出 try-except 和 if 判断两种写法并对比它们的适用场景 4. 告诉我如何补充日志方便以后定位类似问题 代码运行环境Python 3.10Django 4.2。带上场景、环境、已经尝试过的方法模型给出的建议会更有针对性不会从头开始教你写 if 判断。这里面的核心思路是把模型当成团队里一位刚接手你代码的同事你描述得越完整它给出的建议越靠谱。3. 高质量 Prompt 的六个核心要素通过上面的对比可以总结出一个高质量 prompt 的通用框架。熟练掌握这六个要素你就能丢掉网上那些“万能模板”自己根据任务组合出合适的 prompt。3.1 角色Role给模型设定角色相当于告诉它用哪套知识体系和表达习惯来回答。举例“你是一位熟悉 Spring Security 的 Java 架构师”“你是一位有 10 年经验的数据分析师”“你是一位 Oracle 数据库性能优化专家”角色设定不是万能的但它可以明显改变模型的输出风格。设置角色后模型的输出会更加偏向该领域的术语、行文习惯和关注重点对于需要专业性的任务特别有效。3.2 任务Task任务要使用明确的动词比如“实现”“对比”“排查”“解释”“重构”。不要用含糊的“帮我看看”“说一下”这类表达。模糊的任务会得到模糊的结果这是最简单但也最重要的一条原则。判断任务是否清晰的方法很简单把 prompt 中描述任务的句子读出来如果换一个人也能准确完成说明描述足够清晰如果听完之后还一头雾水那就需要继续拆解。3.3 上下文Context上下文是任务之外的背景信息包括运行环境、数据规模、项目架构、技术栈、调用方是谁、最终用户是谁等。对于开发任务建议至少包含编程语言和版本使用的框架和版本操作系统或部署环境涉及的数据表结构或接口定义目前已有的代码逻辑上下文越丰富模型给出的答案越接近你项目的真实情况。但也要注意不要塞入无关信息上下文太长会干扰模型注意力还可能导致 token 超限。3.4 示例Example在 prompt 中给出示例这种技术在提示工程里称为 few-shot learning是提升模型输出稳定性最有效的手段之一。举个例子如果你想让模型把一段产品需求改写成技术任务清单可以在 prompt 中先给出一个“输入…… 输出……”的示例。模型会模仿你给的格式和思路来生成后续内容。对格式一致性要求高的任务示例几乎是必须的。3.5 格式Format明确输出格式是提升 prompt 可用性的关键一步。比如用 Markdown 表格输出对比结果用 JSON 格式输出并给出字段说明用 Python 代码块输出代码用有序列表输出步骤用代码块加注释的方式输出配置文件模型本身非常擅长格式化输出但如果你不告诉它你想要的格式它就会默认选择自己最熟悉的输出方式。对于后续要程序化处理的内容建议在 prompt 中直接定义一个 JSON 结构并说明每个字段的含义。3.6 约束Constraint约束是告诉模型“不要做什么”。常见的约束包括不要使用某个第三方库不要修改现有接口签名不要输出与问题无关的背景知识代码需要兼容 Python 3.8 以下版本不要使用新语法特性回答控制在 500 字以内如果信息不足直接说不知道不要编造约束还有一个重要作用降低大模型的幻觉Hallucination风险。大模型在信息不确定时倾向于生成看起来合理的内容如果你明确要求“不要编造数据”“没有的信息要说明”它会更谨慎地回答问题。4. 一个可以直接套用的 Prompt 模板结合上面六要素下面给出一个适合大多数开发场景的通用模板。你可以把它保存在笔记软件中用时替换占位符。# 角色 你是一位【填写角色如精通 Python 的资深后端工程师】 # 任务 请帮助我【填写具体任务如实现一个带超时控制的重试机制】 # 背景 【这里填写任务背景、使用场景、相关代码、数据结构等】 # 约束 1. 环境Python 3.10Windows 11 2. 不要额外引入第三方依赖 3. 需要处理边界条件包括【填写边界情况】 4. 代码需要添加详细的注释 # 输出格式 1. 完整代码放在 Python 代码块中 2. 使用要点说明使用无序列表 3. 针对边界条件的测试用例使用表格 # 参考示例 输入【示例输入】 输出【示例输出】使用这个模板时不需要每次都填满所有项。简单任务可以省略角色和参考示例复杂任务可以把上下文补充得更详实。关键是养成结构化表达的习惯而不是每次都复制模板却不知道每项的意义。5. 常见问题与排查思路5.1 模型输出太泛泛而谈不够深入这是最常见的现象。可能的原因有两种一是任务描述太宽泛二是没有添加角色和约束。排查时先给模型补充背景信息再把任务拆细。比如“帮我想想怎么优化接口性能”可以改成“我们有一个查询订单列表的接口平均耗时 800ms数据库是 MySQL 8.0单表数据量约 100 万已经加了索引但效果不明显。请从 SQL 优化、缓存策略、分页方式三个角度给出优化方案每个方案要说明原理和适用场景。”5.2 模型给出错误信息或编造内容这就是前面提到的幻觉问题。最直接的处理方式是在 prompt 中明确声明“如果你不确定请直接回答‘信息不足’不要编造数据”。对于重要技术细节还可以要求模型在回答中标注“这部分需要实测确认”或“以官方文档为准”。养成核实关键信息的习惯比任何 prompt 技巧都重要。5.3 提示词太长导致报错或截断大模型的上下文窗口是有限制的。当你粘贴大量文档然后提问时如果超出模型支持的 token 数会出现“conversation too long”“the number of tokens is greater than”之类报错。解决方案有几种先让模型分段总结再合并只粘贴关键段落而不是全文如果使用 API可以利用向量数据库做检索再拼接上下文也可以使用支持超长上下文的模型。另外精简 prompt 本身也能节省 token减少成本。5.4 输出格式不稳定有时 JSON 解析失败这个问题在使用 API 开发应用时特别常见。模型虽然能输出 JSON但偶尔会带上多余的解释文字或者使用不合法转义。解决办法是在 prompt 中给出一个 JSON 示例强制模型只输出 JSON 内容不要输出其他文字。如果问题频繁还可以在代码中加一层解析容错逻辑先提取代码块内容再解析。5.5 多轮对话后模型“忘”了之前的任务多轮对话中模型实际上需要依赖整段上下文。随着对话变长早期的信息权重会降低。如果模型出现“忘记”情况可以在后续 prompt 中重新简述一下任务。对于复杂的长期任务更推荐开启新对话并一次性写好完整 prompt而不是在长对话里一直追加。5.6 Prompt 被安全策略拦截有时候输入的 prompt 因为包含某些敏感词或疑似恶意内容会被模型自身的策略拦截返回类似“your prompt was flagged as potentially violating our usage policy”的提示。这种时候先检查自己的输入是否涉及恶意行为、违法信息、暴力内容等。如果确认没有违规可以改写表达方式把意图描述得更规范再提交。6. 把 Prompt 当代码来管理工程化最佳实践6.1 用版本管理工具保存 Prompt在工作中我发现很多开发者会把好的代码片段保存在 Git 仓库里却把精心调试过的 prompt 随手丢在聊天记录中。等到下次要用时只能重新在对话历史里翻找。更好的做法是把重要 prompt 以文件形式保存下来纳入版本管理。文件格式可以用 Markdown也可以根据使用场景用 JSON、YAML。一个提示词工程项目的目录结构可以参考prompts/ ├── code-review/ │ ├── v1.md │ ├── v2.md │ └── README.md ├── sql-optimization/ │ └── prompt.md ├── doc-summary/ │ └── prompt.json └── templates/ └── common-template.md每次调整 prompt 时保留新旧版本并在 README 中记录调整原因和效果差异。这种做法会在长期使用中带来非常大的收益。6.2 给 Prompt 建立测试集Prompt 和代码一样也可能出现“改了一处影响全局”的问题。如果你正在开发依赖 prompt 的应用建议建一个固定的测试集。测试集包含多组输入和期望输出每次修改 prompt 后都跑一遍测试集观察稳定性和正确率。测试集记录格式可以是这样的 Excel 表格或 JSON[ { id: case_001, task: 根据订单数据生成周报, input: 订单数据本周销售额 120 万元环比增长 15%客单价 230 元, expected: 包含销售额、环比增速、客单价三个核心指标并给出趋势判断 }, { id: case_002, task: 解析用户地址, input: 北京市海淀区中关村大街 1 号, expected: 输出结构化 JSON省份、城市、区县、详细地址字段正确 } ]6.3 把变量和 Prompt 分离在开发 AI 应用时建议把 prompt 模板和具体参数变量分开维护。例如使用 Python 开发时可以这样组织# 文件路径prompts/summary_prompt.py SUMMARY_PROMPT_TEMPLATE 你是一位产品经理。请根据以下内容生成一份项目周报。 输入内容 {document} 要求 1. 总结本周完成的工作 2. 输出风险与待协调事项 3. 全部内容不超过 {max_words} 字 输出格式 ## 本周进展 …… ## 风险与待办 …… 这样设计之后当你需要改变语气、调整输出字段时只需要改模板文件不需要修改业务调用逻辑。如果使用 LangChain 这类编排框架还可以方便地与 RAG、Agent 等模块结合。6.4 记录使用效果持续优化每次使用 Prompt 时记录一下效果比如“代码是否可直接运行”“是否还需要人工大改”“格式是否稳定”。一周下来你就能发现哪些任务的 prompt 需要优化哪些场景的 prompt 已经可以固化复用。持续迭代的重要性甚至比“第一次写好”更重要。6.5 注意隐私与成本边界在使用 prompt 的过程中需要注意数据安全。不要将内部敏感数据、未公开的业务信息、客户隐私数据直接粘贴到线上模型中尤其是通过公网工具聊天窗口使用时。企业开发时如果涉及敏感数据应优先使用私有化部署的模型或通过合规渠道调用。另外长 prompt 会消耗更多 token直接增加 API 调用成本。在实际开发中可以用选择关键上下文代替全文粘贴用精简指令代替啰嗦描述这部分节省下来的成本在规模化调用时非常可观。7. 总结与下一步行动回到最开始的问题你跟 AI 高手的 prompt 水平差距到底有多大答案也许没有你想象中那么大。只要你开始把 prompt 当需求文档来写把角色、任务、上下文、示例、格式、约束六个要素记在脑子里用实战对比中的思路去组织每一次提问你很快就能发现自己拿到的输出质量明显提升。建议你从今天开始做三件小事第一把你最近使用大模型时效果最差的三个问题找出来按本文的框架重写一遍对比前后输出差异第二为自己高频使用的任务编写一个固定的 prompt 模板例如代码审查模板、SQL 优化模板、技术方案模板第三用一段时间积累自己的 prompt 库像整理代码一样整理它们。等你能随手写出信息密度高、约束清晰的 prompt 时你会发现自己使用 AI 的方式已经和以前完全不同了。如果以后写代码、写文档、做数据分析时再遇到大模型输出不符合预期先别急着换工具回到 prompt 本身找原因。绝大多数时候差的不是模型而是我们表达需求的方式。