1. 从背模板到让AI自己写一个被逼出来的思路我大概是从去年下半年开始高频使用各类AI编程助手的。最开始那阵子我跟很多人一样收藏夹里塞满了各种万能提示词模板——什么你是一位资深Python工程师请按照以下规范输出代码什么请分步骤思考后再回答诸如此类。每次开新会话第一件事就是翻收藏夹找到对应场景的模板复制粘贴然后再补上自己的实际需求。这么干了两三个月我发现自己陷入了一个很尴尬的循环花在找模板、改模板上的时间比真正解决问题的时间还多。更麻烦的是模板这东西是有保质期的。模型版本一更新之前调得好好的模板可能就不好使了换个任务类型模板又得重新调。我甚至专门建了一个文档按代码生成代码审查文档撰写调试排错分了四大类每类下面又细分了七八个子模板维护成本高得离谱。真正让我下决心换个思路的是有一次我在处理一个比较复杂的重构任务。那个任务涉及跨模块的接口调整我手头的模板没有一个能直接套用。我花了将近二十分钟拼凑提示词结果AI给出的方案还是跑偏了。当时我就想既然AI能理解自然语言为什么我不能让它先帮我生成一版针对当前任务的提示词我再基于这版提示词去执行真正的任务这个想法听起来有点绕但逻辑其实很直接。我把整个流程拆成了两步第一步我用自己的大白话把任务背景、目标、约束条件描述一遍让AI基于这些信息生成一份结构化的、针对这个具体任务的提示词。第二步我检查、微调这份生成的提示词然后把它作为正式输入让AI执行实际任务。说白了就是把写提示词这件事本身也交给AI来做。我不再需要维护一堆通用模板只需要把当前任务的上下文说清楚就行。这个思路跑通之后效果确实有点出乎我的意料。不是说AI生成的提示词有多完美而是它帮我省掉了大量从零组织语言的精力而且它考虑问题的角度有时候比我更全面。下面我就把这套方法的完整操作流程、踩过的坑、以及一些实测有效的技巧尽量详细地拆开讲一遍。2. 让AI写提示词具体怎么操作才不跑偏2.1 核心流程两阶段生成法我把这套方法叫做两阶段生成法因为它本质上就是把一次AI交互拆成了两个阶段。第一阶段是元提示词生成第二阶段是任务执行。先看第一阶段。我不会一上来就让AI帮我写个提示词那样太笼统了它大概率会给我一个泛泛的模板。我的做法是给它一个结构化的元指令包含以下几个要素任务类型这是代码生成、代码审查、架构设计、还是文档撰写背景信息当前项目的技术栈、代码规模、已有的约束条件。目标描述我希望最终得到什么样的输出是一个完整的函数、一份分析报告、还是一组修改建议输出格式要求代码块、Markdown表格、分步骤列表还是纯文本已知的坑我之前在这个任务上遇到过什么问题希望这次避免。举个例子假设我要让AI帮我审查一段数据库查询代码。我不会直接说帮我看看这段代码有没有问题而是先给它这样一段元指令我需要你帮我生成一份用于代码审查的提示词。背景是 - 这是一个基于Python的Web后端项目使用SQLAlchemy作为ORM - 当前要审查的是一个涉及多表联查的查询函数 - 我关心的是N1查询问题、索引使用情况、以及是否存在SQL注入风险 - 输出格式希望是问题列表 每个问题的严重程度 修改建议 请基于以上信息生成一份结构化的审查提示词我会用它来执行实际的代码审查。AI收到这个元指令后会生成一份针对性的审查提示词。这份提示词通常会包含角色设定、审查维度、输出格式要求等。我拿到之后快速扫一遍看看有没有遗漏的维度或者有没有它自己加戏加过头的地方然后做微调。第二阶段就简单了把生成的提示词复制出来附上实际要审查的代码发给AI执行。2.2 为什么这样比直接问效果更好这里面的道理我后来琢磨了一下其实跟人类专家的工作方式很像。你去找一个资深工程师帮忙看代码如果你直接甩一段代码过去说帮我看看他可能就随便扫两眼给你几个不痛不痒的建议。但如果你先跟他说清楚背景、目标、你担心的问题他就能给出更有针对性的反馈。AI也是一样的。直接问的时候模型需要在一次推理中同时完成理解任务和执行任务两件事注意力被分散了。而两阶段生成法把这两件事拆开了第一阶段专门用来理解任务并组织语言第二阶段专门用来执行任务。每个阶段的认知负荷都降低了输出质量自然就上去了。还有一个更实际的好处生成的提示词是可以复用的。如果我发现某个任务类型经常出现比如审查API接口设计我就可以把AI生成的那版提示词存下来下次直接改改背景信息就能用。这比从零开始写模板效率高多了而且这些提示词是长出来的不是抄来的更贴合我自己的项目语境。2.3 元指令的写法要点元指令的写法直接决定了生成提示词的质量。我踩过的坑里最常见的就是元指令太模糊。比如帮我写个提示词用来生成代码这种元指令生成出来的提示词跟网上随便搜的模板没什么区别。我的经验是元指令里至少要包含三个锚点技术栈锚点具体到语言、框架、版本。不要说Python要说Python 3.11 FastAPI SQLAlchemy 2.0。场景锚点具体到业务场景。不要说处理数据要说处理电商订单的批量退款逻辑。约束锚点具体到限制条件。比如不能引入新的第三方依赖必须兼容现有的数据库schema输出代码需要包含类型注解。这三个锚点给得越具体生成的提示词就越有针对性。我实测下来元指令里每多一个具体的约束条件生成提示词的有效信息密度大概能提升20%到30%。这个数字不是精确统计但体感上非常明显。另外元指令里最好明确告诉AI你不需要执行任务只需要生成提示词。否则有些模型会热心地直接把任务也做了生成一堆代码出来反而干扰了第一阶段的输出。3. 实测中那些意外AI写的提示词到底长什么样3.1 它比我更擅长拆解维度我第一次跑通这个流程的时候让AI帮我生成一份代码重构的提示词。我原本脑子里想的维度无非就是可读性、性能、可维护性。结果AI生成的提示词里除了这三个还加了错误处理完整性日志埋点合理性边界条件覆盖度这几个我压根没想到的维度。后来我反思了一下这其实是因为AI在训练过程中见过大量代码审查的案例它对这些维度的覆盖面比我的个人经验更广。我作为一个开发者关注点往往集中在自己踩过坑的地方而AI没有这种偏好它会按照统计上最常见的审查维度来组织。这给我一个启发让AI写提示词本质上是在借用它的广度来弥补我的深度偏好。我的优势在于对具体项目的理解AI的优势在于对通用模式的覆盖。两者结合生成的提示词质量确实比我自己硬憋出来的要高。3.2 它有时候会过度设计当然AI生成的提示词也不是没有毛病。最常见的问题就是过度设计。比如我让它生成一个简单的函数注释生成提示词它给我整了一个包含角色设定、任务分解、输出格式、质量检查、示例演示五大模块的复杂结构洋洋洒洒好几百字。这种提示词用在复杂任务上没问题但用在简单任务上就是浪费token。我后来总结了一个判断标准如果任务本身用一句话就能说清楚那生成的提示词不应该超过三句话。超过这个长度大概率是AI在凑字数。处理办法也很简单在元指令里加一句请控制提示词长度简单任务不超过100字复杂任务不超过300字。这句话加上之后生成结果就收敛多了。3.3 不同模型生成的提示词风格差异很大我手头同时在用几个不同的模型实测下来它们生成的提示词风格差异非常明显。有的模型倾向于生成角色扮演式的提示词开头一定是你是一位资深的XX专家有的模型倾向于生成步骤式的提示词把任务拆成第一步第二步第三步还有的模型喜欢用约束列表的形式把要求一条条列出来。这个差异本身没有好坏之分但不同风格适合不同任务。我的经验是任务类型适合的提示词风格原因代码生成步骤式 约束列表需要明确的执行路径和边界条件代码审查角色扮演式 维度列表需要模型切换到审查者视角架构设计角色扮演式 开放式问题需要模型发挥创造性不宜约束太死文档撰写步骤式 格式模板需要结构化的输出所以我在元指令里会明确指定风格。比如请生成一份步骤式的提示词包含明确的执行步骤和每步的输出要求。这样生成出来的东西就更符合我的预期。3.4 一个让我意外的发现生成的提示词可以迭代这是我觉得最有意思的一点。AI生成的提示词我可以拿回来再喂给它让它基于这份提示词再优化一版。这个迭代过程通常跑两到三轮就能收敛到一个相当不错的版本。具体操作是这样的第一轮生成提示词A我把A发给AI说请评估这份提示词的质量指出可以改进的地方然后生成优化版提示词B。第二轮拿到B之后如果还有明显问题再重复一次。实测下来两轮迭代之后提示词的质量提升幅度大概在40%左右第三轮之后提升就很小了。这个迭代过程之所以有效是因为AI在评估提示词这个任务上跟生成提示词用的是不同的能力。生成的时候它是在创作评估的时候它是在批判。两种模式切换一下确实能发现不少问题。4. 把提示词生成嵌入日常工作流我的实际配置4.1 我现在的操作流程经过几个月的折腾我现在的工作流大概是这样接到任务不管是写新功能、改bug、还是做代码审查先不急着打开AI对话框。写元指令花一两分钟把任务背景、目标、约束条件用大白话写下来。这一步我通常直接在编辑器里写不追求格式想到什么写什么。生成提示词把元指令发给AI让它生成针对性的提示词。这一步通常不超过30秒。快速审阅扫一眼生成的提示词看看有没有明显跑偏的地方做微调。这一步通常也就一两分钟。执行任务把提示词和实际的任务输入代码、文档、数据一起发给AI执行真正的任务。存档如果这个任务类型以后还会遇到把生成的提示词存到一个专门的文件夹里按任务类型命名。整个流程走下来比之前翻收藏夹找模板的方式大概能省一半的时间。而且因为提示词是针对当前任务生成的执行阶段的输出质量也明显更稳定。4.2 存档和复用的小技巧存档这一步看起来简单但有几个细节值得注意。命名规范我用的格式是任务类型_技术栈_日期比如code_review_python_fastapi_20250115。这样一眼就能看出这个提示词是干什么用的、适用于什么技术栈、什么时候生成的。版本管理同一个任务类型如果生成了多个版本的提示词我会在文件名后面加_v1、_v2这样的后缀。不是所有版本都值得存通常只存迭代过两轮以上的版本。定期清理我大概每个月会花十分钟把上个月存的提示词过一遍删掉那些明显不会再用的。这个习惯很重要不然文件夹很快就会变成垃圾场。跨项目复用有些提示词是跟具体项目无关的比如代码审查文档撰写这类通用任务。我会把这些单独放在一个general文件夹里跟项目相关的放在projects文件夹里。这样找起来更方便。4.3 什么情况下不适合用这套方法说了这么多好处也得说说局限性。我实测下来以下几种情况不太适合用让AI写提示词这套方法任务非常简单比如把这个函数改成异步的这种一句话就能说清楚的任务直接问就行了没必要绕一圈。任务非常依赖个人偏好比如帮我写一段符合我代码风格的注释这种任务AI生成的提示词很难捕捉到你的个人风格不如自己写。时间非常紧迫两阶段生成法虽然省时间但毕竟比直接问多了一步。如果是那种五分钟内要出结果的紧急任务直接问可能更快。判断标准很简单如果写元指令的时间超过了直接写提示词的时间那就不值得用这套方法。我自己的经验是任务复杂度大概在需要三句话以上才能描述清楚的时候这套方法就开始有优势了。5. 几个容易踩的坑和对应的解法5.1 元指令里信息给太多反而干扰生成我一开始有个误区觉得元指令里信息给得越多越好。有一次我写了一个将近五百字的元指令把项目背景、技术栈、业务逻辑、历史遗留问题全塞进去了。结果AI生成的提示词反而很散重点不突出。后来我总结出来元指令里的信息要分层。核心信息任务类型、目标、关键约束放在最前面用短句说清楚补充信息背景、历史问题放在后面用补充说明的方式带出来。这样AI在生成提示词的时候会优先抓住核心信息不会被补充信息带偏。5.2 生成的提示词里出现幻觉约束这是比较隐蔽的一个坑。AI在生成提示词的时候有时候会脑补一些我根本没提的约束条件。比如我让它生成一个数据库查询优化的提示词它生成的版本里居然有一条请确保查询结果按创建时间倒序排列——我压根没提过这个要求。这种幻觉约束如果不检查直接拿去执行任务就会导致输出偏离预期。解决办法是在元指令里加一句只包含我明确提到的约束条件不要自行添加。这句话加上之后幻觉约束的出现频率明显降低。5.3 迭代次数过多导致过度拟合前面说了迭代两到三轮效果最好但我也踩过迭代过度的坑。有一次我连续迭代了六轮生成的提示词确实很精致但拿去执行任务的时候发现它变得非常死板只能处理我迭代时提到的那几种情况稍微换个场景就不行了。这个现象我称之为过度拟合——提示词被优化得太贴合元指令里的具体描述反而失去了泛化能力。所以我现在给自己定了个规矩迭代不超过三轮而且每轮迭代都要问自己这个修改是让它更通用了还是更狭窄了。5.4 不同模型之间的提示词不通用这个坑我踩得比较惨。有一次我用模型A生成了一份提示词效果很好然后我直接拿这份提示词去模型B上执行结果输出质量差了一大截。后来我才意识到不同模型对提示词的敏感度是不一样的。模型A可能对角色设定很敏感模型B可能对步骤拆解更敏感。所以我现在如果要在多个模型之间切换会针对每个模型单独生成一版提示词而不是一份提示词到处用。虽然麻烦一点但效果稳定得多。6. 关于token消耗和成本的一点实测数据既然聊到了提示词就绕不开token消耗这个话题。两阶段生成法因为多了一次交互token消耗肯定会增加。我大概统计了一下自己最近一个月的使用数据任务类型直接问的平均token消耗两阶段生成的平均token消耗输出质量提升体感简单代码生成约800约1200不明显复杂代码审查约2500约4000明显架构设计约3000约5500非常明显文档撰写约1500约2200中等从数据上看两阶段生成法的token消耗大概比直接问高出50%到80%。但考虑到输出质量的提升以及后续返工次数的减少这个成本我觉得是值得的。尤其是复杂任务一次生成到位的价值远超过多消耗的那点token。不过如果你的token预算比较紧张我的建议是只在复杂任务上使用这套方法简单任务直接问就行。另外生成的提示词存档之后可以复用长期来看边际成本是递减的。7. 一些零散但实用的经验最后分享几个我在实操中攒下来的零散经验不一定成体系但都挺实用。第一元指令用口语写就行不用追求格式。我一开始总想把元指令写得像正式文档一样后来发现完全没必要。用大白话把事儿说清楚AI理解起来反而更准确。格式太正式有时候会让AI过度解读。第二生成的提示词里如果有示例要特别检查。AI有时候会在提示词里塞一些示例输入输出这些示例如果跟你的实际场景不符会严重干扰执行阶段的输出。我现在的做法是除非我明确要求否则让AI不要生成示例。第三把常用的元指令也存下来。虽然元指令每次都要根据具体任务写但有些结构化的部分是可以复用的。比如背景-目标-约束-输出格式这个四段式结构我每次都是套这个框架只是往里填的内容不同。把这个框架存下来写元指令的速度能快不少。第四注意提示词里的否定表述。AI生成的提示词里经常出现不要做XX这样的否定表述。实测下来否定表述的效果不如肯定表述。比如不要使用递归不如请使用迭代方式实现。所以我在审阅生成的提示词时会尽量把否定表述改成肯定表述。第五定期回顾存档的提示词。我每个月会花点时间翻翻之前存的提示词看看哪些还在用、哪些已经过时了。这个过程经常能发现一些可以合并或简化的地方也能帮我梳理自己的任务类型分布。这套方法我用了大概三四个月最大的感受是提示词工程这件事正在从手工作坊向自动化流水线演进。以前我们花大量时间调模板、背模板现在可以让AI帮我们生成针对性的提示词我们只需要把精力放在说清楚任务这件事上。这个转变本身可能比任何具体的提示词技巧都更有价值。