1. 在提问之前, 必须先弄明白Codex到底在等什么东西。1.1你写的那个东西并不是什么指令, 它本质上是把一段对话给压缩之后所产生的结果。我看到很多同事采取了一种类似使用Codex的方式, 他们会把产品需求文档里面的一些段落直接复制进去, 接着就按回车键去等待程序的结果。当运气比较好的时候, 工具能够理解这些内容, 可是如果运气不好的情况下它会给出一个完全没有办法运行的框架, 导致你需要进行两次的返工操作。其实核心问题并不是说Codex本身不够聪明, 而是你提供给它的输入信息根本不具备足够的可执行性特征。Codex它并不是那种用来做搜索的东西, 而是一个能通过对话来生成内容的东西。当你把一句话扔给它的时候, 它就会基于你给的这句话去揣测你的全部想法。一旦它猜错了, 产生的结果就会完全不对路。反过来说, 如果你给它的是一段结构非常清晰、边界也非常明确、而且验收标准能够被验证的提示, 那么它能给你的代码质量, 会远远超出你平时随便乱问得到的那些答案。说穿了, 提示词其实就是你和它之间的一种类似压缩协议的东西, 把它写得更好一点, 你两之间的交流成本就能变得越来越低。我在我自己一直在做的这个项目里头, 整理出来了一整套提问用的模板。这套模板我自己反复用了挺长的一段时间, 前后加起来一共有七个。除此之外还有怎么把这些模板凑在一起用的组合写法。这些内容全是我在干活的过程中, 遇到各种倒霉问题然后总结出来的经验。我不敢保证这就能算是唯一正确的标准答案, 但是它至少能够帮你解决掉大部分常见的尴尬情况。这种尴尬情况就是你提完问题之后还是不会写代码, 或者是你虽然写出了代码但是根本没法进行修改和后续开发。接下来每一个模板我都已经准备好完整的示例了。这样大家拿到手以后可以直接拿来改成适合自己的版本使用。1.2 对于模板的底层结构而言, 需要关注的是其中的角色构成、具体需求、边界条件以及验收标准。请你先好好地记住这几个词语, 分别是角色、需求、边界以及验收。我在不断地写来写去的过程中发现了这样的情况, 那就是所有好用的模板其实都是这四个要素的不同排列组合的方式所构成的这一种结果。你抓住了这四个东西来进行组合, 那么对于任何提出的问题你都能把它们拆分成实际可行的提示词。下面我将要说到的这七个模板, 其实每一个都能够在这四个要素当中找到相应的影子或者说依据。2. 这七个模板我们是把它一个一个拆开来解释的, 针对每一个模板的情况呢, 我们都已经提供过对应的案例进行了说明, 而我们现在所要说的是第二个部分的第二点小标题下的第一个模板, 也就是受约束的那种生成型的这种提问方式。这种类型的模板主要是拿来从零开始去开发一个新的功能, 或者是用来完成大段的代码重写工作。最令人担忧的情况莫过于允许毫无限制的随意发挥, 导致最终写出来的代码整体风格与你所在的项目要求存在非常大的差异, 完全不对齐。模板结构你是一名精通[语言/框架]的资深工程师。请为以下需求实现一份完整代码需求[一句话说清目标]技术栈[明确语言/版本/框架/包管理方式]约束[必须遵守的限制如“不使用第三方库”“不能改动现有接口”]请输出[代码/伪代码/核心函数]并在结尾给出如何使用的一段简短说明。我举一个具体的例子作为说明, 以前我开发过一个基于命令行的批量文件重命名工具, 那个我在临近下班时间的时候想要赶出一个初版程序, 于是我就直接向系统进行泛化的提问请求, 让系统编写一个可以进行批量文件重命名的应用程序, 当时的结果就是系统给我生成了一款带有人机交互界面的程序版本, 这个版本还依赖了许多杂乱无章的开发库资源, 实际上是完全无法投入使用的, 后来我调整了策略, 采用了通过施加约束条件的方式来引导生成过程。你是一名精通Python标准库的工程师。请实现一个命令行工具批量重命名指定目录下的所有文件把文件名前缀从“IMG_”改成“photo_”原地修改不复制。约束只用argparse、pathlib、re禁止第三方库批量执行前要打印预览清单并让用户确认。输出核心代码和5行以内的用法说明。这一次, 它所提供的这个代码是完全能够运行的, 并且它还自动添加了关于 dry-run 这个参数的逻辑处理。之所以会出现这样的差别, 主要是因为约束条件以及验收项目都一次性给齐全了, 这样一来, 它就不再胡乱发挥了。那个模板, 它是非常适合那些目标明确、但路径不清晰的任务的。如果你在内部的具体实现方式上感到不确定, 那完全没有关系。只要你把外部的边界给划分清楚, 那么系统自己就会进行相应的规划。关于使用方面的注意事项, 咱们最好别在模板里面去写上什么尽可能会简洁这样子的话, 或者是类似优质代码这种比较模糊的修饰性词汇, 因为它们往往会被直接理解为是让你少写一些注释的意思, 或者是干脆就去省略掉那些处理错误情况的代码段落, 而如果你是真的想看到某种特定样式的代码内容的话, 那么最好是直接把自己的具体需求给清楚地定义出来, 也就是说要去规定像代码里必须得包含try catch这样的机制, 又或者是指明其中的注释部分所占的比例最多只能有百分之三十左右之类的、能够真正拿去验证是否做到位的具体标准要求才是对的。2.第二个模板二, 把代码的解释加上, 然后逐行进行拆解。这个模板是被拿来用于读别人写的代码的, 或者是用来读自己一个月之前写了但是完全看不懂的代码的, 它追求的不是单纯的翻译任务, 而是想要把背后隐藏的设计意图给一层层地拆解出来。模板结构请逐段解释下面的[语言]代码重点说明1. 这段代码解决了什么问题2. 核心数据结构/循环/递归的设计思路是什么3. 有没有潜在的性能问题或边界漏掉4. 如果要把[某个行为]改掉应该改哪一行代码[粘贴代码]使用这个模板, 比直接去问“这段代码啥意思”要强很多, 因为你把问题分解成了四个维度, 这样一来, 对方就不能仅仅复述一遍语法内容, 它一定要真正去理解整体逻辑之后, 才能有资格判断哪里存在性能问题, 以及哪里遗漏了边界情况。有一次, 我在重构老项目的时候, 碰上了处理消息队列回调函数的情况, 那段代码里嵌套了三层函数, 还用两次闭包变量来赋值我问它问题的时候, 它只是简单地说了一遍每行在干什么, 这根本没任何用处。改成用这个模板之后, 它直接指出了闭包变量在异步场景下可能会取到旧值的问题, 还顺带给出了改用冻结参数的方案。只输出一条提示词, 就帮我省了好半天调试时间。这里面的核心重点其实是第四问, 要求咱们修改一行代码, 而不是把整个东西重写掉。正确的做法是让Codex首先去确认好影响范围, 然后再进行动手操作。大部分人之所以不敢让人工智能来修改代码文件, 根本原因就是害怕控制不了影响的范围。只要使用这一套模板先把手术刀般的精确度准备妥当, 大家心里自然就会变得踏实稳定下来。2.第3个模板, 也就是叫做Bug定位与根因假设的那个部分。很多人利用Codex来修改错误的操作方式, 存在着特别明显的资源浪费情况: 他们把整段报错日志原封不动地粘贴进入对话框里面, 只发出一句询问哪里出现了问题的简单指令, 然后代码模型给出了三个可能存在的原因供您去进行逐一验证测试, 可是直到你尝试到第二个选项的时候才后知后觉地想起来, 原来还可以继续向它提出更深层次的反问以获取更精准的答案。模板结构我有一段[语言]代码出现了以下问题。现象[报错信息/错误截图描述/错误输出片段]上下文[这个函数在什么场景下被调用、大致的数据流]我已经排查过[排除掉的原因避免它再重复说]请先不要急着给修改建议先列出最可能的3个根因按概率排序每个根因都附上验证方法我确定后再给出修复方案。你是否看到, 核心要点在于明确表述为“请先不要急着提供修改建议”, 这一约束条件极大地降低了那些没有实际作用的回答出现的概率, 因为Codex这类工具在本质上具备一种想要积极地输出内容的倾向, 如果不对它进行压制, 它会直接就给出对代码行的修改内容, 而使用者无法分辨其正确性, 但是只要要求它先进行分类排序或者先进行验证动作, 它就会静下来协助用户进行详细分析。此外, 我还补充了一项更为关键的技巧。那就是在输入提示中加入“我已经排查过”这一内容。通过这种方式, 能够帮我过滤掉大约一半毫无意义的废话。有一次, 那个模型总是重复询问我是否存在时区设置错误的情况。然而, 我已经在预设的模板里明确注明了“已确认采用同一时区, 并且和服务器端进行了对齐”。在此之后, 它马上转变了讨论方向。最终, 经过分析找出了真正的问题所在。那是因为在进行 JSON 序列化处理的时候 , 整数被自动转换成浮点数了。假如说你进行了排查, 但是折腾了半天也没有发现任何线索, 那么你就把“我已经排查过”这句话更改为“目前没有明确的排查方向”, 这样的话它就会改变策略, 首先是让你添加日志以及复现最小案例。这份模板存在的意义, 是让你不再去做那些没有方向的随机试探, 而是去按照概率来进行验证。你甚至能够从这个排序的信息里看出一点门道, 通常情况下排在第三位的缘由, 往往是最不为人所熟知, 但却是绝对真实存在问题的地方。2.4 模板四代码评审与改进建议写代码并不是最终的终点, 而是在完成代码编写之后进行审核和评审, 这一环节才是拉开人与人之间差距的关键所在。我常常使用Codex这个工具把它当作免费的资源, 但是如果直接向它提出是否有bug这样的问题, 它通常只会回答看起来没有问题, 这样的回答根本没有什么作用。相比之下, 如果你给它提供明确的评审维度, 它能够找出很多在你自己都没有想到的地方出现的潜在问题或盲点。模板结构请对以下代码做一次严格的代码评审重点检查1. 正确性有没有边界条件漏处理、返回值错误、并发不安全2. 可维护性函数是否过于冗长、命名是否准确、有没有重复逻辑3. 性能有没有不必要的循环、N1查询、频繁创建对象4. 安全有没有SQL注入、路径穿越、敏感信息硬编码请按严重程度分成必须修改、建议修改、可忽略并在每一条里注明修改思路。代码[粘贴代码]我之前给过它一段用于处理Excel导入的函数代码, 当时我自己心里觉得写得不算差。可是它给出的评价里有一条说: 在循环里面去调用正则需要动态编译的做法是不对的, 应该把这个步骤提到循环的外面去。这确实指的是一个性能方面存在的弊端, 但在我实际运行的时候, 因为处理的数据样本太少, 所以我压根就感觉不到任何差别。随后我把测试数据堆大了一圈, 达到了十万行的规模, 这个时候性能上面产生的巨大差距才真正显露出来。在平常时候写代码, 很难把存在的问题看出来, 但是你让 Codex 按照四个维度的方式去过一遍, 总能够挤出好多“建议修改”来。而且它会把严重程度列出来, 你只需要先看“必须修改”的内容就好, 这样就不会被那些不是主要的问题来带歪节奏。当你正在对别人的代码进行评审的时候, 你可以在这个模板的最后部分再加一句“不要改动代码, 只评论”这样的话。这样一来, 它就会变成一种纯阅读的评审工具。就不会出现这种情况, 就是你复制了代码之后, 它还会自作主张地输出一个被改动过的版本。2.第5个, 也就是称为模板五的这个部分, 其具体的名称是叫做技术方案对比。当你正在对A方案和B方案进行犹豫这种抉择活动的时候, 你可以直接把二选一的任务交给Codex来处理, 它在通常情况下会给出一个基于你的具体场景来决定的回应, 这个回应实际上是没有给出明确答案的, 相反, 如果你对Codex给出明确的对比维度以及本项目的约束条件信息的话, 它将会提供出一张看起来非常像样的决策表格。模板结构我正在设计一个[系统/模块]需要在[方案A]和[方案B]之间做选择。项目背景[规模、并发量、维护团队情况、上线时间约束]请按以下维度做对比实现成本、运行性能、生态成熟度、长期维护难度、坑点。对比完之后给出你的倾向并说明在什么前提下你会推翻这个倾向。需要注意, 最后那个关于“在什么前提下会推翻原有倾向”的追问非常关键。这一部分专门设计出来, 是为了强迫Codex去认真思考边界条件所在的意思, 而不是让它随便给出一个现成的结论。要是只是进行那种没有特定限制的泛泛提问, 人工智能通常容易采取一种两边都不得罪的、和稀泥式的回答方式。但是现在我们加入了这样的具体限定要求以后, 它会自己主动地提出像“假如你们团队里面完全没有精通A语言的人选的话, 那么就直接换成选择B方案”这样具有实际指导意义的建议。之前, 我之前在某些内部工具里头, 一直在纠结, 到底是使用数据库, 还是使用文件存储, 按理来说, 这种简单的选型事项, 我早就应该决定好才对, 可是那个阶段, 我心里头一直动摇不定, 当用它生成的模板去让它把两者的对比情况罗列出来以后, 它提到说, “如果采用数据库的话, 在WAL模式之下, 会出现小概率的繁忙异常现象, 你们若是峰值写入的情况特别猛烈, 就建议采取文件存储加上定时进行全文量入库的方式来负责查询工作”, 它就给出了一个折中调合的解决方案, 这比简单地只做一种选择或者两种选择, 要显得有用许多的多。这个模板还可以被用于像框架选型这样的场景, 也可以被用于像决定是选择用同步ORM还是异步ORM来处理数据库这样的情境。它的核心道理就在于给人工智能提供足够的背景层面的参数信息, 从而避免它在没有充分依据的情况下进行盲目的挑选工作。2.这里有一个模板叫做第六个, 专门讲关于怎么去重新构建的建议, 还有中间是怎么一步步过渡过去的。重构是一件十分让人困扰的事情, 如果你向 Codex 发出“重构这段代码”这样的指令, 它会提供给你一种全新的解决方案, 但是不会跟你说明从旧到新的中间过程是如何进行的。对于目前正在上线运行的项目来说, 任何形式的内容调整都必须充分考虑到兼容性问题。模板结构以下代码承担了[核心职责]现在我希望优化[目标性能/可读性/扩展性]。请给出分阶段重构方案阶段一保持行为完全不变只做结构性调整阶段二引入[新机制/新依赖];阶段三删除旧的[废弃逻辑]。每个阶段都需要附上验证方式测试用例、手动验证步骤并指出哪个阶段风险最大。代码[粘贴代码]我使用这个模板去修改过很久以前开发的一个日志上报模块。原本的设计是依靠单线程来按照顺序的方式发送数据, 而我们进行重构的目标则是改成一种带有缓冲队列功能的异步批量发送手段。Codex所给出的第一阶段工作内容非常简单, 仅仅是将原来的发送函数拆解成了两个独立的函数, 分别叫做发送和冲刷操作, 这一阶段的功能表现没有任何改变, 测试的结果也全都是通过的。直到进入第二阶段的时候才开始真正地对队列逻辑进行修改。到了第三阶段才对旧有的关于重试方面的样板代码实施删除。每个步骤都可以单独进行发布上线, 因此我几乎没有遇到过那种在将项目进行到一半时候发现无法运行的令人感到恐惧的情况。关键之所在, 是使得方案具备阶段化特征, 并且每一个阶段都需要配备相应的验证方式。若它所提供的方案之中, 并未包含任何验证机制, 则我通常情况下不予采纳, 原因在于修改之后, 是否能够顺利运行, 完全依赖于不可控的运气因素。即便仅仅是打印一些日志信息这同样被视作一种有效的验证手段。2.第7个模板, 也就是从自然语言直接生成测试用例的那一个。这个模板是适合用来补全测试覆盖率的, 大多数程序员是不爱去写单一测试的, 其实并不是因为他们懒惰, 而是因为他们不知道应该怎么样才能把所有的边界条件都想得周全才行, Codex在这一点上是意外地擅长一些的, 但是这个有一个前提条件的, 就是用户必须得让它去列出所有的用例, 而绝对不能让它直接去编写那个测试文件。模板结构请根据下面这个函数的核心逻辑列出需要覆盖的测试用例。不必写代码先以表格形式给出用例编号 | 输入 | 预期输出 | 覆盖点要求覆盖正常路径、异常输入、边界值、空值、并发/重复调用如适用。函数说明[粘贴代码或描述函数逻辑]你如果是把它当作测试分析工具来使用的话, 效果就会比自己一个人死脑筋去想象更加全面很多。曾经有那么一次, 我专门负责给一个用来解析 HTTP 头的函数补充测试用例。当时我脑子里面能够想起来的情况根本就没超过十个。结果那个工具一下子给我提供了三十个, 它甚至都覆盖到了诸如头部名称里面的字母大小写是混合存在的, 数值里面是含有逗号的情况, 以及存在多个拥有同样名称的头部这种情况。我是按照那个表格去写的实现代码, 最后跑出来的测试通过率比我之前自己编写的那个版本要高出了好几个档次。它给你把用例交付了之后, 你还能追加一句“把咱们这些个测试用例, 翻译一下做成测试代码呗”, 这样一来, 它就变成一个完全的、啥都包了的测试生成器了。分两步走, 这种做法比直接一步到位要来得效果好得多, 为什么这么说呢?因为先把那个用例一个个给列出来, 是让这个叫Codex的东西能把事情想明白了, 然后再去动手干活, 所以最终生成的那个代码的质量, 会变得更高一些。3. 因为这七个还不够, 所以我们得把重点放在组合写法上面, 这确实是关键所在。具体的做法是遵循第三点一的组合原则, 也就是说第一步需要先去缩小问题域, 然后在第二步再让它动手。单独使用一个模板能够解决单点问题, 但是真实的工作任务往往是复合型的。比如“这段代码里面的Bug非常多, 请你进行重构, 补充测试用例, 还要解释根本原因”, 你把这拆分成三次独立的提问, 效率反而比较高。这就是组合的意义所在。我在使用组合功能时的习惯做法是这样的, 首先我会先去询问那些分析类型的问题, 这里会用到第三套模板和第五套模板, 等我把整体情况都拿到手之后, 接着再去进行那些生成型任务, 这个时候会选用第一套模板和第七套模板, 分析类问题所给出的答案, 是用来对一些约束条件进行补充的以及对验收标准进行完善的, 这样一来等我们进入到了生成阶段以后, Codex就已经清楚地知道你刚才在处理过程中遭遇了哪些困难, 所以它就更加不容易再犯以前出现过的错误。我特意地, 不会在同一个提示词里面, 同时地塞进去太多的需求。有一回, 我自以为是地觉得聪明, 就把bug定位、重构、加上注释、还有补充测试所有这些内容, 全都写进一个只有400个字的提示词里了。结果那个叫做Codex的东西, 的确是全部都去做了, 但是, 每一个部分都是做得非常敷衍了事。比如说, 关于测试的部分, 只是新建了一个文件名而已, 连断言都没有至于重构方面的改动, 仅仅是修改了一下变量名就算完了。当然, bug确实是修复了, 可是却没有对根本原因做出任何解释。后来, 我就吸取教训学乖了, 决定只去专注于每一个单独的目标。3.针对二号题目, 也就是进行组合方面的实战演练, 去演示一段完整的有关提示词的工作流程。假设你眼下拿到一个陈旧的脚本, 你的主要任务是对数据展开清理工作, 可是这个脚本总是会针对某些特殊的符号而崩溃出错。如果我使用组合式的编写方法来处理的话, 通常会按照以下的几个步骤来进行:首先是第一步, 也就是使用模板三来进行定位这个问题的处理。这个清洗脚本在解析包含emoji的文本时会崩溃报UnicodeDecodeError。已知读取文件时用encodingutf-8输入是几个爬虫抓回来的文本。请先列出最可能3个根因按概率排序附验证方式。第2步, 要拿得到的结果去做判断, 要是说清楚了确实是代理编码弄乱了, 那就去把模板二拿出来对清洗过程用到那个正则函数做进一步的分析, 好让Codex能够指出是哪些字符没有被现在的正则表达式给涵盖到。咱们进行到第三步, 把模板一拿出来用它重新描述一下清洗的过程, 不过得加上范围控制的限制条件, 具体就是只管函数, 别的地方都不改动, 保证输出的时候接口还是原来那个样子。在进行到第四步的时候, 需要调用模板七, 让程序针对清洗函数的功能去主动生成测试用例, 这些生成的测试用例的具体内容要能够涵盖像 emoji 表情符号、繁体字这种字符类型, 以及那些控制字符在内的多种情况, 以此来验证清洗效果。按照这四个步骤走一遍, 一个问题就能得到彻底且完整的解决。这样做的直接收益并不只是说最终的回答质量比较高, 而是指每一个阶段的输出内容都能被紧接着的下一步骤直接调用和使用, 从而形成紧密连接的链条结构。如果你在面对技术需求时, 从开始到最后仅仅只发送一条内容为助我修复这个清洗脚本的请求语句, 那么极有可能出现的情况是, 系统给出的第一版解决方案虽然表面上可以正常工作, 但在处理具体场景时会遗漏掉许多边缘情况, 进而导致程序在稍后的时间迅速崩溃。组合写法的真正技巧, 就是要做到让上一轮的答案, 去成为下一轮的约束条件。例如, 在第一步它说根因可能是代理编码不一致的时候, 你在第三步就追加一句像“假设编码不一致是唯一边界条件”这样的话语, 它就不会跑偏。4. 常见翻车现场与排查技巧 4.1 模板给了还是翻车先检查你是不是加了私货我自己把踩过的坑给总结了一遍, 有百分之九十以上的问题并不是因为那个模板不顶用, 反而是因为我在模板的内容外面又多塞进去了几句表达得很模糊的话。举个例子呢, 就在我之前提到的那个模板里面, 我又加进去了“最好”这个词, 又加进去了“优化一下”这几个字, 还加进去了“给力一点”这样的说法, 这些个词语的存在全部都是起到了负面优化的作用。在使用模板的时候, 大家可以把模板当成一个“骨架”, 不过呢千万记得别把它当作是什么不可更改的“圣旨”, 这是因为如果你在一个那种特别明确要求了“只能使用标准库”的模板底下, 又去硬加上一句说“可以用lxml, 因为反正它很方便嘛”, 那整个结构的选择方向会一下子就变得摇摆不定起来, 这一点我是观察到的, 另外我还发现了一个叫做Codex的东西是对上下文里面那些“最近才出现的话”更加敏感的, 也就是说如果你把那句带着个人私下想法的话给放在了模板的后面, 结果就会导致它优先去继承你这个私货, 同时就把最初的模板给忽略掉了。你可以把排查的办法简单理解为, 重新把你之前发的那段原文仔仔细细地看一遍, 然后坚决地把里面那些像是形容词语、模糊不清的动词全都给它删掉, 就比如像“优雅”、“灵活”、“尽量”这样的词统统都不要留, 接着把它们替换成那些能够确切判断出来的词, 比如说什么“不超过XX行”, 或者“必须支持.9”, 乃至“禁止彩色输出”这类非常明确且可以衡量的说法。4.当上下文被污染了的时候, 应该怎么办呢。Codex的生成质量受到上下文的影响很大, 前面讨论过的内容它全都记得住, 但是某些记忆会产生负面影响, 从而干扰后面的输出结果。最常见的情况是当系统在前期推荐了方案A之后, 你在后期要求它对比方案A和B时, 它会下意识地维护自己之前的那个选择。最终表现出来的现象就是系统倾向于认为自己已经撰写过的那些内容更具优势。在这种情况下, 你可以直接使用新建的话术框功能, 然后将之前步骤中所得出的核心要点进行提炼压缩, 把它变成单句的概要描述内容接着粘贴到输入区域中去应用相关的模板设定。需要记住的一点是, 在形成这份概括叙述的时候应当严格地只包括客观真实的验证结果比如明确指出某某特定因素已经被排查剔除掉这一事实状态的信息片段, 同时必须避免加入类似认为某种策略比较可行的带有主观倾向性的评价观点。4.模板弄得太长了, 结果它忽略掉了关键约束。在那一段时间里, 我特别迷信“提示词写得越长, 指令就越精确”这种说法。于是, 我把那七个模板里面所有的要素, 一股脑儿地全部塞进了一单条提示词里头。结果呢, Codex这个系统反倒犯了捡了芝麻、丢了西瓜的错误。它并不是因为读不懂长篇文章, 而是它会按照“信息的显著性”来给内容排个序。如果你在中间埋藏了一条“不要修改数据库表结构”这样的要求, 那么这条要求很有可能会被后面看起来更显眼的“输出完整代码”这些文字给盖过去, 从而不被注意到。目前的情况是这样子的, 那就是我的控制线设定在三百字以内, 因为在这个字数范围内的提示词它的效果是最好的, 一旦超过了这个界限呢, 我就会有意识地去把它拆分成两次提问的动作, 然后第一步是先去询问边界的问题, 接着第二步才是去处理实现层面的内容。你拿到这里给你提供的速查表, 出现以下症状就知道哪里出现问题了的。出现这些症状的具体原因是哪一种, 应该采用什么样的处理办法呢。在对你提到的那个依赖版本这个问题上, 它是属于完全忽略了的情况。这个约束的情况是, 已经被埋在大段的文字内容里面了。把版本相关的约束条件, 放到提示词的最前面, 具体来说是第一行之后的第二行那里。它最终呈现出来的内容, 包括了许多根本不在你先前所提要求之内的一系列功能。并没有针对那个被称为“禁止实现”的具体界限进行明确的划定。明确列出“本次不要做X、Y、Z”它把那个东西分析得井井有条, 可是呢, 并没有给出对应的源代码片段。你把那个“请输出代码”的这个话, 放到了最后面, 然后语气还显得很弱。先把需求弄清楚, 后面再明确说明应该输出的类型具体是什么。那个东西拿出来了三个方向的结论, 可这其中的意思是彼此对立的。在这段的上下文内容之中, 很有可能会混杂着以前进行过的讨论部分。打开一个新的窗口进行重新操作, 并且只在里面贴上摘要的内容。它其实对你本来并没有打算去碰的那些代码, 做了一下修改。在当前的文本里头, 少了一个关于“只修改范围”这样的声明。你仅仅改动xxx函数这个部分内容, 而其余的一切部分都得维持它们在原始状态下面的那种样子。4.关于离线状态下的小笔记部分, 这里提到了有七个模板可以用于快速的查阅和参照。用户提交的这些模板, 其本质是促使你在正式提问之前的那三十秒钟内, 去认真地想清楚自己的确切目标。根据我的个人体会, 投入时间在编写提示词上是绝对不会徒劳无功的, 因为这一行为强制性地要求你将模糊的需求进行明确化和具体化处理, 而这种将需求理清的做法本来就是应该完成的基础工作。如果你选择直接跳过这个步骤而去进行宽泛式的提问, 那么看似为你节省下来的那三十秒时间额度, 最终都会在随后因结果不符合预期而增加的返工环节以及反复调试的成本中, 以加倍的数量偿还给你。 
长河君 · 2026/11/5 5:23:49 · 阅读 1.2k Codex 写代码效率翻倍：7 个提示词模板与组合技巧
1. 在提问之前, 必须先弄明白Codex到底在等什么东西。1.1你写的那个东西并不是什么指令, 它本质上是把一段对话给压缩之后所产生的结果。我看到很多同事采取了一种类似使用Codex的方式, 他们会把产品需求文档里面的一些段落直接复制进去, 接着就按回车键去等待程序的结果。当运气比较好的时候, 工具能够理解这些内容, 可是如果运气不好的情况下它会给出一个完全没有办法运行的框架, 导致你需要进行两次的返工操作。其实核心问题并不是说Codex本身不够聪明, 而是你提供给它的输入信息根本不具备足够的可执行性特征。Codex它并不是那种用来做搜索的东西, 而是一个能通过对话来生成内容的东西。当你把一句话扔给它的时候, 它就会基于你给的这句话去揣测你的全部想法。一旦它猜错了, 产生的结果就会完全不对路。反过来说, 如果你给它的是一段结构非常清晰、边界也非常明确、而且验收标准能够被验证的提示, 那么它能给你的代码质量, 会远远超出你平时随便乱问得到的那些答案。说穿了, 提示词其实就是你和它之间的一种类似压缩协议的东西, 把它写得更好一点, 你两之间的交流成本就能变得越来越低。我在我自己一直在做的这个项目里头, 整理出来了一整套提问用的模板。这套模板我自己反复用了挺长的一段时间, 前后加起来一共有七个。除此之外还有怎么把这些模板凑在一起用的组合写法。这些内容全是我在干活的过程中, 遇到各种倒霉问题然后总结出来的经验。我不敢保证这就能算是唯一正确的标准答案, 但是它至少能够帮你解决掉大部分常见的尴尬情况。这种尴尬情况就是你提完问题之后还是不会写代码, 或者是你虽然写出了代码但是根本没法进行修改和后续开发。接下来每一个模板我都已经准备好完整的示例了。这样大家拿到手以后可以直接拿来改成适合自己的版本使用。1.2 对于模板的底层结构而言, 需要关注的是其中的角色构成、具体需求、边界条件以及验收标准。请你先好好地记住这几个词语, 分别是角色、需求、边界以及验收。我在不断地写来写去的过程中发现了这样的情况, 那就是所有好用的模板其实都是这四个要素的不同排列组合的方式所构成的这一种结果。你抓住了这四个东西来进行组合, 那么对于任何提出的问题你都能把它们拆分成实际可行的提示词。下面我将要说到的这七个模板, 其实每一个都能够在这四个要素当中找到相应的影子或者说依据。2. 这七个模板我们是把它一个一个拆开来解释的, 针对每一个模板的情况呢, 我们都已经提供过对应的案例进行了说明, 而我们现在所要说的是第二个部分的第二点小标题下的第一个模板, 也就是受约束的那种生成型的这种提问方式。这种类型的模板主要是拿来从零开始去开发一个新的功能, 或者是用来完成大段的代码重写工作。最令人担忧的情况莫过于允许毫无限制的随意发挥, 导致最终写出来的代码整体风格与你所在的项目要求存在非常大的差异, 完全不对齐。模板结构你是一名精通[语言/框架]的资深工程师。请为以下需求实现一份完整代码需求[一句话说清目标]技术栈[明确语言/版本/框架/包管理方式]约束[必须遵守的限制如“不使用第三方库”“不能改动现有接口”]请输出[代码/伪代码/核心函数]并在结尾给出如何使用的一段简短说明。我举一个具体的例子作为说明, 以前我开发过一个基于命令行的批量文件重命名工具, 那个我在临近下班时间的时候想要赶出一个初版程序, 于是我就直接向系统进行泛化的提问请求, 让系统编写一个可以进行批量文件重命名的应用程序, 当时的结果就是系统给我生成了一款带有人机交互界面的程序版本, 这个版本还依赖了许多杂乱无章的开发库资源, 实际上是完全无法投入使用的, 后来我调整了策略, 采用了通过施加约束条件的方式来引导生成过程。你是一名精通Python标准库的工程师。请实现一个命令行工具批量重命名指定目录下的所有文件把文件名前缀从“IMG_”改成“photo_”原地修改不复制。约束只用argparse、pathlib、re禁止第三方库批量执行前要打印预览清单并让用户确认。输出核心代码和5行以内的用法说明。这一次, 它所提供的这个代码是完全能够运行的, 并且它还自动添加了关于 dry-run 这个参数的逻辑处理。之所以会出现这样的差别, 主要是因为约束条件以及验收项目都一次性给齐全了, 这样一来, 它就不再胡乱发挥了。那个模板, 它是非常适合那些目标明确、但路径不清晰的任务的。如果你在内部的具体实现方式上感到不确定, 那完全没有关系。只要你把外部的边界给划分清楚, 那么系统自己就会进行相应的规划。关于使用方面的注意事项, 咱们最好别在模板里面去写上什么尽可能会简洁这样子的话, 或者是类似优质代码这种比较模糊的修饰性词汇, 因为它们往往会被直接理解为是让你少写一些注释的意思, 或者是干脆就去省略掉那些处理错误情况的代码段落, 而如果你是真的想看到某种特定样式的代码内容的话, 那么最好是直接把自己的具体需求给清楚地定义出来, 也就是说要去规定像代码里必须得包含try catch这样的机制, 又或者是指明其中的注释部分所占的比例最多只能有百分之三十左右之类的、能够真正拿去验证是否做到位的具体标准要求才是对的。2.第二个模板二, 把代码的解释加上, 然后逐行进行拆解。这个模板是被拿来用于读别人写的代码的, 或者是用来读自己一个月之前写了但是完全看不懂的代码的, 它追求的不是单纯的翻译任务, 而是想要把背后隐藏的设计意图给一层层地拆解出来。模板结构请逐段解释下面的[语言]代码重点说明1. 这段代码解决了什么问题2. 核心数据结构/循环/递归的设计思路是什么3. 有没有潜在的性能问题或边界漏掉4. 如果要把[某个行为]改掉应该改哪一行代码[粘贴代码]使用这个模板, 比直接去问“这段代码啥意思”要强很多, 因为你把问题分解成了四个维度, 这样一来, 对方就不能仅仅复述一遍语法内容, 它一定要真正去理解整体逻辑之后, 才能有资格判断哪里存在性能问题, 以及哪里遗漏了边界情况。有一次, 我在重构老项目的时候, 碰上了处理消息队列回调函数的情况, 那段代码里嵌套了三层函数, 还用两次闭包变量来赋值我问它问题的时候, 它只是简单地说了一遍每行在干什么, 这根本没任何用处。改成用这个模板之后, 它直接指出了闭包变量在异步场景下可能会取到旧值的问题, 还顺带给出了改用冻结参数的方案。只输出一条提示词, 就帮我省了好半天调试时间。这里面的核心重点其实是第四问, 要求咱们修改一行代码, 而不是把整个东西重写掉。正确的做法是让Codex首先去确认好影响范围, 然后再进行动手操作。大部分人之所以不敢让人工智能来修改代码文件, 根本原因就是害怕控制不了影响的范围。只要使用这一套模板先把手术刀般的精确度准备妥当, 大家心里自然就会变得踏实稳定下来。2.第3个模板, 也就是叫做Bug定位与根因假设的那个部分。很多人利用Codex来修改错误的操作方式, 存在着特别明显的资源浪费情况: 他们把整段报错日志原封不动地粘贴进入对话框里面, 只发出一句询问哪里出现了问题的简单指令, 然后代码模型给出了三个可能存在的原因供您去进行逐一验证测试, 可是直到你尝试到第二个选项的时候才后知后觉地想起来, 原来还可以继续向它提出更深层次的反问以获取更精准的答案。模板结构我有一段[语言]代码出现了以下问题。现象[报错信息/错误截图描述/错误输出片段]上下文[这个函数在什么场景下被调用、大致的数据流]我已经排查过[排除掉的原因避免它再重复说]请先不要急着给修改建议先列出最可能的3个根因按概率排序每个根因都附上验证方法我确定后再给出修复方案。你是否看到, 核心要点在于明确表述为“请先不要急着提供修改建议”, 这一约束条件极大地降低了那些没有实际作用的回答出现的概率, 因为Codex这类工具在本质上具备一种想要积极地输出内容的倾向, 如果不对它进行压制, 它会直接就给出对代码行的修改内容, 而使用者无法分辨其正确性, 但是只要要求它先进行分类排序或者先进行验证动作, 它就会静下来协助用户进行详细分析。此外, 我还补充了一项更为关键的技巧。那就是在输入提示中加入“我已经排查过”这一内容。通过这种方式, 能够帮我过滤掉大约一半毫无意义的废话。有一次, 那个模型总是重复询问我是否存在时区设置错误的情况。然而, 我已经在预设的模板里明确注明了“已确认采用同一时区, 并且和服务器端进行了对齐”。在此之后, 它马上转变了讨论方向。最终, 经过分析找出了真正的问题所在。那是因为在进行 JSON 序列化处理的时候 , 整数被自动转换成浮点数了。假如说你进行了排查, 但是折腾了半天也没有发现任何线索, 那么你就把“我已经排查过”这句话更改为“目前没有明确的排查方向”, 这样的话它就会改变策略, 首先是让你添加日志以及复现最小案例。这份模板存在的意义, 是让你不再去做那些没有方向的随机试探, 而是去按照概率来进行验证。你甚至能够从这个排序的信息里看出一点门道, 通常情况下排在第三位的缘由, 往往是最不为人所熟知, 但却是绝对真实存在问题的地方。2.4 模板四代码评审与改进建议写代码并不是最终的终点, 而是在完成代码编写之后进行审核和评审, 这一环节才是拉开人与人之间差距的关键所在。我常常使用Codex这个工具把它当作免费的资源, 但是如果直接向它提出是否有bug这样的问题, 它通常只会回答看起来没有问题, 这样的回答根本没有什么作用。相比之下, 如果你给它提供明确的评审维度, 它能够找出很多在你自己都没有想到的地方出现的潜在问题或盲点。模板结构请对以下代码做一次严格的代码评审重点检查1. 正确性有没有边界条件漏处理、返回值错误、并发不安全2. 可维护性函数是否过于冗长、命名是否准确、有没有重复逻辑3. 性能有没有不必要的循环、N1查询、频繁创建对象4. 安全有没有SQL注入、路径穿越、敏感信息硬编码请按严重程度分成必须修改、建议修改、可忽略并在每一条里注明修改思路。代码[粘贴代码]我之前给过它一段用于处理Excel导入的函数代码, 当时我自己心里觉得写得不算差。可是它给出的评价里有一条说: 在循环里面去调用正则需要动态编译的做法是不对的, 应该把这个步骤提到循环的外面去。这确实指的是一个性能方面存在的弊端, 但在我实际运行的时候, 因为处理的数据样本太少, 所以我压根就感觉不到任何差别。随后我把测试数据堆大了一圈, 达到了十万行的规模, 这个时候性能上面产生的巨大差距才真正显露出来。在平常时候写代码, 很难把存在的问题看出来, 但是你让 Codex 按照四个维度的方式去过一遍, 总能够挤出好多“建议修改”来。而且它会把严重程度列出来, 你只需要先看“必须修改”的内容就好, 这样就不会被那些不是主要的问题来带歪节奏。当你正在对别人的代码进行评审的时候, 你可以在这个模板的最后部分再加一句“不要改动代码, 只评论”这样的话。这样一来, 它就会变成一种纯阅读的评审工具。就不会出现这种情况, 就是你复制了代码之后, 它还会自作主张地输出一个被改动过的版本。2.第5个, 也就是称为模板五的这个部分, 其具体的名称是叫做技术方案对比。当你正在对A方案和B方案进行犹豫这种抉择活动的时候, 你可以直接把二选一的任务交给Codex来处理, 它在通常情况下会给出一个基于你的具体场景来决定的回应, 这个回应实际上是没有给出明确答案的, 相反, 如果你对Codex给出明确的对比维度以及本项目的约束条件信息的话, 它将会提供出一张看起来非常像样的决策表格。模板结构我正在设计一个[系统/模块]需要在[方案A]和[方案B]之间做选择。项目背景[规模、并发量、维护团队情况、上线时间约束]请按以下维度做对比实现成本、运行性能、生态成熟度、长期维护难度、坑点。对比完之后给出你的倾向并说明在什么前提下你会推翻这个倾向。需要注意, 最后那个关于“在什么前提下会推翻原有倾向”的追问非常关键。这一部分专门设计出来, 是为了强迫Codex去认真思考边界条件所在的意思, 而不是让它随便给出一个现成的结论。要是只是进行那种没有特定限制的泛泛提问, 人工智能通常容易采取一种两边都不得罪的、和稀泥式的回答方式。但是现在我们加入了这样的具体限定要求以后, 它会自己主动地提出像“假如你们团队里面完全没有精通A语言的人选的话, 那么就直接换成选择B方案”这样具有实际指导意义的建议。之前, 我之前在某些内部工具里头, 一直在纠结, 到底是使用数据库, 还是使用文件存储, 按理来说, 这种简单的选型事项, 我早就应该决定好才对, 可是那个阶段, 我心里头一直动摇不定, 当用它生成的模板去让它把两者的对比情况罗列出来以后, 它提到说, “如果采用数据库的话, 在WAL模式之下, 会出现小概率的繁忙异常现象, 你们若是峰值写入的情况特别猛烈, 就建议采取文件存储加上定时进行全文量入库的方式来负责查询工作”, 它就给出了一个折中调合的解决方案, 这比简单地只做一种选择或者两种选择, 要显得有用许多的多。这个模板还可以被用于像框架选型这样的场景, 也可以被用于像决定是选择用同步ORM还是异步ORM来处理数据库这样的情境。它的核心道理就在于给人工智能提供足够的背景层面的参数信息, 从而避免它在没有充分依据的情况下进行盲目的挑选工作。2.这里有一个模板叫做第六个, 专门讲关于怎么去重新构建的建议, 还有中间是怎么一步步过渡过去的。重构是一件十分让人困扰的事情, 如果你向 Codex 发出“重构这段代码”这样的指令, 它会提供给你一种全新的解决方案, 但是不会跟你说明从旧到新的中间过程是如何进行的。对于目前正在上线运行的项目来说, 任何形式的内容调整都必须充分考虑到兼容性问题。模板结构以下代码承担了[核心职责]现在我希望优化[目标性能/可读性/扩展性]。请给出分阶段重构方案阶段一保持行为完全不变只做结构性调整阶段二引入[新机制/新依赖];阶段三删除旧的[废弃逻辑]。每个阶段都需要附上验证方式测试用例、手动验证步骤并指出哪个阶段风险最大。代码[粘贴代码]我使用这个模板去修改过很久以前开发的一个日志上报模块。原本的设计是依靠单线程来按照顺序的方式发送数据, 而我们进行重构的目标则是改成一种带有缓冲队列功能的异步批量发送手段。Codex所给出的第一阶段工作内容非常简单, 仅仅是将原来的发送函数拆解成了两个独立的函数, 分别叫做发送和冲刷操作, 这一阶段的功能表现没有任何改变, 测试的结果也全都是通过的。直到进入第二阶段的时候才开始真正地对队列逻辑进行修改。到了第三阶段才对旧有的关于重试方面的样板代码实施删除。每个步骤都可以单独进行发布上线, 因此我几乎没有遇到过那种在将项目进行到一半时候发现无法运行的令人感到恐惧的情况。关键之所在, 是使得方案具备阶段化特征, 并且每一个阶段都需要配备相应的验证方式。若它所提供的方案之中, 并未包含任何验证机制, 则我通常情况下不予采纳, 原因在于修改之后, 是否能够顺利运行, 完全依赖于不可控的运气因素。即便仅仅是打印一些日志信息这同样被视作一种有效的验证手段。2.第7个模板, 也就是从自然语言直接生成测试用例的那一个。这个模板是适合用来补全测试覆盖率的, 大多数程序员是不爱去写单一测试的, 其实并不是因为他们懒惰, 而是因为他们不知道应该怎么样才能把所有的边界条件都想得周全才行, Codex在这一点上是意外地擅长一些的, 但是这个有一个前提条件的, 就是用户必须得让它去列出所有的用例, 而绝对不能让它直接去编写那个测试文件。模板结构请根据下面这个函数的核心逻辑列出需要覆盖的测试用例。不必写代码先以表格形式给出用例编号 | 输入 | 预期输出 | 覆盖点要求覆盖正常路径、异常输入、边界值、空值、并发/重复调用如适用。函数说明[粘贴代码或描述函数逻辑]你如果是把它当作测试分析工具来使用的话, 效果就会比自己一个人死脑筋去想象更加全面很多。曾经有那么一次, 我专门负责给一个用来解析 HTTP 头的函数补充测试用例。当时我脑子里面能够想起来的情况根本就没超过十个。结果那个工具一下子给我提供了三十个, 它甚至都覆盖到了诸如头部名称里面的字母大小写是混合存在的, 数值里面是含有逗号的情况, 以及存在多个拥有同样名称的头部这种情况。我是按照那个表格去写的实现代码, 最后跑出来的测试通过率比我之前自己编写的那个版本要高出了好几个档次。它给你把用例交付了之后, 你还能追加一句“把咱们这些个测试用例, 翻译一下做成测试代码呗”, 这样一来, 它就变成一个完全的、啥都包了的测试生成器了。分两步走, 这种做法比直接一步到位要来得效果好得多, 为什么这么说呢?因为先把那个用例一个个给列出来, 是让这个叫Codex的东西能把事情想明白了, 然后再去动手干活, 所以最终生成的那个代码的质量, 会变得更高一些。3. 因为这七个还不够, 所以我们得把重点放在组合写法上面, 这确实是关键所在。具体的做法是遵循第三点一的组合原则, 也就是说第一步需要先去缩小问题域, 然后在第二步再让它动手。单独使用一个模板能够解决单点问题, 但是真实的工作任务往往是复合型的。比如“这段代码里面的Bug非常多, 请你进行重构, 补充测试用例, 还要解释根本原因”, 你把这拆分成三次独立的提问, 效率反而比较高。这就是组合的意义所在。我在使用组合功能时的习惯做法是这样的, 首先我会先去询问那些分析类型的问题, 这里会用到第三套模板和第五套模板, 等我把整体情况都拿到手之后, 接着再去进行那些生成型任务, 这个时候会选用第一套模板和第七套模板, 分析类问题所给出的答案, 是用来对一些约束条件进行补充的以及对验收标准进行完善的, 这样一来等我们进入到了生成阶段以后, Codex就已经清楚地知道你刚才在处理过程中遭遇了哪些困难, 所以它就更加不容易再犯以前出现过的错误。我特意地, 不会在同一个提示词里面, 同时地塞进去太多的需求。有一回, 我自以为是地觉得聪明, 就把bug定位、重构、加上注释、还有补充测试所有这些内容, 全都写进一个只有400个字的提示词里了。结果那个叫做Codex的东西, 的确是全部都去做了, 但是, 每一个部分都是做得非常敷衍了事。比如说, 关于测试的部分, 只是新建了一个文件名而已, 连断言都没有至于重构方面的改动, 仅仅是修改了一下变量名就算完了。当然, bug确实是修复了, 可是却没有对根本原因做出任何解释。后来, 我就吸取教训学乖了, 决定只去专注于每一个单独的目标。3.针对二号题目, 也就是进行组合方面的实战演练, 去演示一段完整的有关提示词的工作流程。假设你眼下拿到一个陈旧的脚本, 你的主要任务是对数据展开清理工作, 可是这个脚本总是会针对某些特殊的符号而崩溃出错。如果我使用组合式的编写方法来处理的话, 通常会按照以下的几个步骤来进行:首先是第一步, 也就是使用模板三来进行定位这个问题的处理。这个清洗脚本在解析包含emoji的文本时会崩溃报UnicodeDecodeError。已知读取文件时用encodingutf-8输入是几个爬虫抓回来的文本。请先列出最可能3个根因按概率排序附验证方式。第2步, 要拿得到的结果去做判断, 要是说清楚了确实是代理编码弄乱了, 那就去把模板二拿出来对清洗过程用到那个正则函数做进一步的分析, 好让Codex能够指出是哪些字符没有被现在的正则表达式给涵盖到。咱们进行到第三步, 把模板一拿出来用它重新描述一下清洗的过程, 不过得加上范围控制的限制条件, 具体就是只管函数, 别的地方都不改动, 保证输出的时候接口还是原来那个样子。在进行到第四步的时候, 需要调用模板七, 让程序针对清洗函数的功能去主动生成测试用例, 这些生成的测试用例的具体内容要能够涵盖像 emoji 表情符号、繁体字这种字符类型, 以及那些控制字符在内的多种情况, 以此来验证清洗效果。按照这四个步骤走一遍, 一个问题就能得到彻底且完整的解决。这样做的直接收益并不只是说最终的回答质量比较高, 而是指每一个阶段的输出内容都能被紧接着的下一步骤直接调用和使用, 从而形成紧密连接的链条结构。如果你在面对技术需求时, 从开始到最后仅仅只发送一条内容为助我修复这个清洗脚本的请求语句, 那么极有可能出现的情况是, 系统给出的第一版解决方案虽然表面上可以正常工作, 但在处理具体场景时会遗漏掉许多边缘情况, 进而导致程序在稍后的时间迅速崩溃。组合写法的真正技巧, 就是要做到让上一轮的答案, 去成为下一轮的约束条件。例如, 在第一步它说根因可能是代理编码不一致的时候, 你在第三步就追加一句像“假设编码不一致是唯一边界条件”这样的话语, 它就不会跑偏。4. 常见翻车现场与排查技巧 4.1 模板给了还是翻车先检查你是不是加了私货我自己把踩过的坑给总结了一遍, 有百分之九十以上的问题并不是因为那个模板不顶用, 反而是因为我在模板的内容外面又多塞进去了几句表达得很模糊的话。举个例子呢, 就在我之前提到的那个模板里面, 我又加进去了“最好”这个词, 又加进去了“优化一下”这几个字, 还加进去了“给力一点”这样的说法, 这些个词语的存在全部都是起到了负面优化的作用。在使用模板的时候, 大家可以把模板当成一个“骨架”, 不过呢千万记得别把它当作是什么不可更改的“圣旨”, 这是因为如果你在一个那种特别明确要求了“只能使用标准库”的模板底下, 又去硬加上一句说“可以用lxml, 因为反正它很方便嘛”, 那整个结构的选择方向会一下子就变得摇摆不定起来, 这一点我是观察到的, 另外我还发现了一个叫做Codex的东西是对上下文里面那些“最近才出现的话”更加敏感的, 也就是说如果你把那句带着个人私下想法的话给放在了模板的后面, 结果就会导致它优先去继承你这个私货, 同时就把最初的模板给忽略掉了。你可以把排查的办法简单理解为, 重新把你之前发的那段原文仔仔细细地看一遍, 然后坚决地把里面那些像是形容词语、模糊不清的动词全都给它删掉, 就比如像“优雅”、“灵活”、“尽量”这样的词统统都不要留, 接着把它们替换成那些能够确切判断出来的词, 比如说什么“不超过XX行”, 或者“必须支持.9”, 乃至“禁止彩色输出”这类非常明确且可以衡量的说法。4.当上下文被污染了的时候, 应该怎么办呢。Codex的生成质量受到上下文的影响很大, 前面讨论过的内容它全都记得住, 但是某些记忆会产生负面影响, 从而干扰后面的输出结果。最常见的情况是当系统在前期推荐了方案A之后, 你在后期要求它对比方案A和B时, 它会下意识地维护自己之前的那个选择。最终表现出来的现象就是系统倾向于认为自己已经撰写过的那些内容更具优势。在这种情况下, 你可以直接使用新建的话术框功能, 然后将之前步骤中所得出的核心要点进行提炼压缩, 把它变成单句的概要描述内容接着粘贴到输入区域中去应用相关的模板设定。需要记住的一点是, 在形成这份概括叙述的时候应当严格地只包括客观真实的验证结果比如明确指出某某特定因素已经被排查剔除掉这一事实状态的信息片段, 同时必须避免加入类似认为某种策略比较可行的带有主观倾向性的评价观点。4.模板弄得太长了, 结果它忽略掉了关键约束。在那一段时间里, 我特别迷信“提示词写得越长, 指令就越精确”这种说法。于是, 我把那七个模板里面所有的要素, 一股脑儿地全部塞进了一单条提示词里头。结果呢, Codex这个系统反倒犯了捡了芝麻、丢了西瓜的错误。它并不是因为读不懂长篇文章, 而是它会按照“信息的显著性”来给内容排个序。如果你在中间埋藏了一条“不要修改数据库表结构”这样的要求, 那么这条要求很有可能会被后面看起来更显眼的“输出完整代码”这些文字给盖过去, 从而不被注意到。目前的情况是这样子的, 那就是我的控制线设定在三百字以内, 因为在这个字数范围内的提示词它的效果是最好的, 一旦超过了这个界限呢, 我就会有意识地去把它拆分成两次提问的动作, 然后第一步是先去询问边界的问题, 接着第二步才是去处理实现层面的内容。你拿到这里给你提供的速查表, 出现以下症状就知道哪里出现问题了的。出现这些症状的具体原因是哪一种, 应该采用什么样的处理办法呢。在对你提到的那个依赖版本这个问题上, 它是属于完全忽略了的情况。这个约束的情况是, 已经被埋在大段的文字内容里面了。把版本相关的约束条件, 放到提示词的最前面, 具体来说是第一行之后的第二行那里。它最终呈现出来的内容, 包括了许多根本不在你先前所提要求之内的一系列功能。并没有针对那个被称为“禁止实现”的具体界限进行明确的划定。明确列出“本次不要做X、Y、Z”它把那个东西分析得井井有条, 可是呢, 并没有给出对应的源代码片段。你把那个“请输出代码”的这个话, 放到了最后面, 然后语气还显得很弱。先把需求弄清楚, 后面再明确说明应该输出的类型具体是什么。那个东西拿出来了三个方向的结论, 可这其中的意思是彼此对立的。在这段的上下文内容之中, 很有可能会混杂着以前进行过的讨论部分。打开一个新的窗口进行重新操作, 并且只在里面贴上摘要的内容。它其实对你本来并没有打算去碰的那些代码, 做了一下修改。在当前的文本里头, 少了一个关于“只修改范围”这样的声明。你仅仅改动xxx函数这个部分内容, 而其余的一切部分都得维持它们在原始状态下面的那种样子。4.关于离线状态下的小笔记部分, 这里提到了有七个模板可以用于快速的查阅和参照。用户提交的这些模板, 其本质是促使你在正式提问之前的那三十秒钟内, 去认真地想清楚自己的确切目标。根据我的个人体会, 投入时间在编写提示词上是绝对不会徒劳无功的, 因为这一行为强制性地要求你将模糊的需求进行明确化和具体化处理, 而这种将需求理清的做法本来就是应该完成的基础工作。如果你选择直接跳过这个步骤而去进行宽泛式的提问, 那么看似为你节省下来的那三十秒时间额度, 最终都会在随后因结果不符合预期而增加的返工环节以及反复调试的成本中, 以加倍的数量偿还给你。