还没等我把手里的活干完身边的人已经开始讨论 AI 编程工具里的“自定义指令”到底怎么写才不白写。我起初以为这又是新一轮的玩法概念包装直到自己接手过几个用默认配置跑崩的任务才意识到这东西不是加分项而是能不能把工具用顺手的门槛。尤其是最近几个热点里反复出现的codex 自定义指令和workbuddy 自定义指令推荐本质上都是在做同一件事教工具按你自己的节奏干活而不是让工具用它的默认方式“教育”你。先说清楚一个容易混淆的点自定义指令不是给 AI 套上一层“礼貌用语”也不是在每段对话前复制粘贴一大段背景说明。它是在工作流真正开始之前把你对任务的理解、约束条件、输出预期、甚至踩过的坑用一套结构化的方式提前告诉工具。像给新同事写入职手册你写清楚了它上手就快你含糊了它准保给你交一堆需要返工的东西。下面我抛开那些花里胡哨的“指令模板合集”用自己的实际经验拆一拆自定义指令的核心逻辑是什么哪些场景必须配怎么写才有效以及我在 codex 和 workbuddy 两个工具里反复调出来的实战版本。1. 先搞清楚自定义指令到底在解决什么问题很多人第一次接触自定义指令是从某篇推荐帖里复制了一份“神级配置”粘进去发现效果和自己预期的完全不是一回事。这不是指令本身的问题而是没搞懂它的作用边界。1.1 为什么说它是工具的“工作记忆”大语言模型有个天然短板对话一长前面的内容会慢慢“失忆”。你可以把它理解成一个记忆力不太稳定的实习生你跟它交代了背景它记了几个回合就开始自由发挥。自定义指令就是把这个记忆外置每次任务启动时相当于给这位实习生重新做一次岗前培训而且培训内容是你定的不是它自己脑补的。我用codex跑过一个比较典型的场景让它维护一个多模块的旧项目里面混合着 PyTorch 和纯 Python 脚本还有一些比较老的类型注解风格。默认状态下 codex 经常会把新代码写成新版语法和项目里的旧风格冲突。后来我在自定义指令里明确写了“保持项目的既有代码风格不要主动升级语法除非任务明确要求”这一条就已经干掉了一大半的无效改动。对于workbuddy这类偏工作流管理的工具自定义指令的作用更偏向“角色稳定”。你把它看成你的项目助理这个助理是细心还是莽撞完全取决于你怎么定义它的响应方式。比如我给它定了“所有输出先给结论再给依据涉及数字必须标明来源不确定的信息明确说不知道”从此它就再没给我交过那种“看似什么都说了、其实什么都没说”的汇报。1.2 默认配置和自定义配置的差距在哪默认配置是工具方根据大多数场景调出来的“安全牌”它不会出大错但也很难出彩。就像一个万能模板放在任何项目里都行但也意味着它不会特意照顾你的技术栈、你的协作习惯、你的交付标准。我自己体会最深的差距有三个上下文侧重不同默认配置往往把上下文集中在“怎么完成任务”而自定义配置可以额外强调“什么不能做”。比如我经常给 codex 加“不要修改测试文件除非你打算同步更新对应的测试数据”这在默认配置下完全不会生效。输出粒度的差异默认配置给出的答复通常偏“完整论述”但实际干活的人往往只需要“直接结论 关键证据”。通过自定义指令我可以把汇报格式压缩到框架层面效率提升非常明显。风险偏好的控制默认配置倾向于“做了再说”改动面往往偏大。自定义指令可以明确“小步提交单次只改一个模块”让工具的每一次操作都更可控。如果你现在用的工具还没有自定义指令功能你可以退一步用“系统提示词”或者“项目内约定文档”来模拟效果相似。当然如果你的工具支持全局和项目级两种自定义指令建议优先把通用行为放在全局把约束性强的放项目级后面我会细说这个划分逻辑。2. 设计自定义指令前的三个准备步骤我不建议拿到工具就一头扎进“指令语法”里先想清楚下面三件事你的指令设计才不至于跑偏。2.1 盘点你的高频任务类型打开你最近两周的使用记录把任务分个类。我在实际统计后发现自己 70% 以上的任务就三类写新功能、改老代码、解释别人写的代码。这三类任务的指令配置差异非常大。写新功能时我需要指令强调“先给方案大纲再逐文件落地”防止 codex 闷头把整个模块写完再让我面对一堆改动改老代码时指令必须包含“保持改动范围最小不要顺手重构”这类刹车条款解释代码时指令要强调“按调用层级组织说明先给整体脉络再讲具体实现”。这一步做扎实之后你再看那些网上的“推荐配置”就知道哪些对你适用、哪些是别人的特定场景经验不会盲目照抄。2.2 明确你的“不要清单”很多人写自定义指令时满脑子都是“我要什么”忽略了“我不要什么”。实际上负面约束往往比正面要求更能提升工具的表现。我举几个常见的例子不要编造不存在的 API 或依赖如果不太确定应该提问确认。不要在我没要求的情况下引入新的第三方库。不要一次性改动超过两个文件除非你给出必须这么做的理由。不要在回答里写“如你所见”“显然”这类只会占据篇幅的连接词。这些“不要”条目写起来简单却能在关键时刻帮你避开最重的返工坑。我把它们的优先级排在正面要求之前。2.3 考虑指令的分层全局级、项目级、任务级自定义指令不是越多越好塞得太多工具反而抓不住重点。我的习惯是分三层全局级放你的通用偏好比如“输出使用中文”“代码中注释用中文”“默认不修改测试文件”这类跨项目都成立的规定。项目级放这个项目特有的约束比如“保持既有代码风格”“数据库迁移脚本统一放在 migrations 目录下”“所有时间相关字段使用 UTC 存储”。任务级这是每次对话开始时的临时补充一般只约束当前这一个任务说完即止不会写进长期配置。这个分层逻辑对codex和workbuddy都适用。前者可以作为项目内的指令文件后者可以在任务配置里设置固定的工作区提示。分层清晰之后工具的上下文会更聚焦响应质量也能稳定不少。3. 给 codex 写自定义指令的实战套路codex 在很多场景下表现强劲但也因为它能力比较强跑偏时的破坏力同样不低。给它写自定义指令核心思路就是给出路、画边界、立标准。3.1 一份可以直接复用的基础结构我把自己在几个项目里调过好几轮的 codex 自定义指令拆出来去掉项目特有信息后结构是这样的项目背景 - 这个项目是一句话描述业务方向 - 主要技术栈包括列关键语言和框架 - 项目入口文件是说明从哪开始看 任务执行规则 - 开始之前先列任务拆解确认修改范围 - 执行过程中每一步改动必须对应一个明确目标 - 完成之后用简短清单总结改动点和影响范围 禁止事项 - 不要主动重构与任务无关的代码 - 不要假设环境里面有什么依赖 - 不要一次性提交大段改动而不解释 - 不要使用项目中没有引入过的技术方案 输出格式 - 结论先行 - 修改清单用列表 - 风险点单独标出这套结构看起来简单但我实际用下来发现真正起作用的是“开始之前先列任务拆解”和“修改清单用列表”这两条。前者逼着它动笔前动脑后者让改动对账变得非常轻松。3.2 怎么为旧项目单独定制一份旧项目的坑主要在于代码风格不统一、历史包袱重、配置文件多。给这类项目写自定义指令我会额外加入下面几条先阅读项目 README 和最近的提交记录理解当前状态再开始改动。只在需要改动的函数内部进行修改不要把整个文件重写。如果遇到因为环境差异导致的报错先给出排查步骤而不是直接改代码。有一次我接手一个两年没动过的 Django 项目codex 第一次生成的改动直接跳过了依赖版本兼容问题。后来我在指令里加了“先确认依赖版本再改代码遇到不兼容情况先说明再动手”后续表现明显稳多了。旧项目里指令的真正价值不是让工具做得更多而是让它“少犯自以为是的错”。3.3 迭代技巧把指令当成代码来维护自定义指令不是写一次就结束的。我每跑完一个阶段性的任务都会顺手回看那些“显然不合理”的输出判断是配置问题还是提示词问题。如果是配置问题就把对应的约束补进指令文件。我甚至会把指令放进版本管理里和代码一起提交。好处是每次回退或者换人接手时都能看到这套配置的演进记录而不是只留一个版本在那里。对于团队协作这一步尤其值得做。4. workbuddy 自定义指令推荐写法workbuddy 和 codex 的侧重点不一样它不是纯粹的代码生成工具更偏向把任务整理、执行、反馈串起来。所以 workbuddy 的自定义指令重心会落在“流程管理”和“角色定义”上。4.1 让输出风格变得可复用我在 workbuddy 里最常干的一件事是给它规定“每项任务必须输出一个结构化摘要”摘要里必须包含目标、执行动作、需要确认的问题、下一步建议。这个格式一旦固定后续的任务交接和复盘就会非常省力。你可以理解为给团队里定了个周报模板每次汇报都按这个骨架来看的人不用重新适应格式。workbuddy 的自定义指令在这方面效果拔群因为它很多场景本身就是任务式对话输入输出一致性越高协作体验越顺。4.2 按职能定义不同的指令空间我不建议把一个“万能助手”指令塞给 workbuddy更好的做法是给不同职能定义不同的指令入口。比如项目助理模式侧重于任务拆解、进度跟进、会议纪要整理。数据分析模式侧重于数据来源核实、指标口径统一、结论的可解释性。方案评审模式侧重于风险识别、备选方案比较、明确最终建议。workbuddy 如果支持多套配置快速切换那就把这几套分别保存用的时候按需调用。如果只能维护一套全局指令那就把“按需切换角色”的规则写进指令里让它根据任务关键词自动调整响应模式。4.3 推荐优先配置的几条核心指令根据我自己和其他朋友的使用反馈workbuddy 里最值得优先配置的指令集中在下面几条所有计划类输出必须标注优先级和时间估计。复盘类输出必须区分事实、推断和建议不要混着写。涉及多人协作的任务默认把相关人按角色标记不写具体姓名避免信息过期。每周五下午固定输出本周小结和下周重点格式固定不用额外提醒。这些配置的价值不在一时而在于长期跑下来workbuddy 输出的内容会逐渐贴近你的工作节奏。它不再是通用助手而是你真正常用的那个“工作搭子”。5. 实操过程从写指令到验证效果无论配置写得多漂亮最后都要落到“实际跑一遍”上面。这一节我用一次典型的任务来演示整个流程。5.1 任务背景与目标设定这次的任务是用 codex 给一个内部数据分析项目新增一个导出功能。项目使用的是 Python 3.9 搭配 FastAPI现有代码里已经有几个类似的导出接口风格比较统一。我的目标不是让 codex 从零写一套新方案而是让它照着已有模式扩展一个新接口同时保证参数校验和异常处理和旧接口保持一致性。5.2 自定义指令的落地配置在动手前我先把自定义指令按前面说到的结构写好# 项目级指令 ## 背景 - Python 3.9 FastAPI - 已有导出接口位于 app/export/ 目录 - 所有接口统一使用 Pydantic 做参数校验 ## 执行规则 - 先阅读 app/export/ 下任意一个已有接口理解模式 - 新增接口参考旧接口的结构保持一致的命名和错误处理 - 只在 app/ 目录下修改文件不涉及配置和环境文件 ## 输出格式 - 列出修改的文件清单 - 说明每个文件的核心改动点 - 标注可能的兼容性风险配置完成后我把任务说清楚新增一个导出接口类型为 CSV支持日期范围筛选返回文件流。5.3 实际执行与结果观察codex 第一轮给出的方案基本符合预期它确实先读了一个旧接口然后按类似的结构写出了新接口。不过我发现一个小问题它在参数校验时用了新版 Pydantic 写法和项目里旧接口的写法不一致。我没有直接改代码而是把这个问题写进下一次对话的临时指令里“注意项目里 Pydantic 校验风格是 v1 的写法保持统一。”codex 在后续生成里就修正了这一点。整个过程下来核心代码、测试数据、接口文档的改动都在可控范围内没有出现那种“改一处崩三处”的局面。5.4 关于验证节奏的几句忠告我见过不少人配置完自定义指令第一版输出不错就以为大功告成。实际上建议至少在不同类型的任务上各跑两三次再判断这套指令是否稳定。如果某类任务表现不稳通常不是指令整体问题而是和任务类型相关的几条约束不够具体。6. 常见问题与排查技巧实录聊点实际用的时候容易踩的坑这些问题我在不同工具里都见过遇到别慌。6.1 指令写了但工具好像完全没按指令干活可能原因有几个一是你同时配置了全局和项目级指令项目级没有生效工具优先读了全局二是指令写得太长工具的注意力被分散到后面的内容前面的关键约束反而被无视三是描述里有歧义比如“不要修改测试文件”可能被理解成“测试文件不用管”而不是“禁止修改”。排查建议精简指令把最重要的约束放在开头使用肯定句和否定句结合的方式表达如果工具支持查看生效配置打开确认它到底读了哪些内容。6.2 指令生效了但输出变得太僵化这是一个常见的反向效果。指令约束太强工具可能会变得“缩手缩脚”明明有更高效的方案也不敢提只会在你画的圈子里打转。这不是自定义指令的错而是你没给它留出创新的空间。我的解决办法是在指令里加一条“在不妨碍当前任务目标的前提下可以提出更优的替代方案但要说明理由”。这样既有边界也有弹性不会把一个本来挺聪明的工具管成提线木偶。6.3 不同任务之间的指令冲突当全局指令和项目级指令在某些点上发生冲突时工具往往会选择比较保守的方式。比如全局说“使用最新语法”但项目级说“保持既有风格”生成结果就可能两边都不讨好。处理方式也很简单明确层级优先级。我习惯把项目级指令排到最高优先级因为它代表的是不可变的基础事实。全局指令只是偏好项目级指令必须被遵守这一点我会直接写进配置第一行。6.4 自定义指令的“上下文污染”问题有些工具会把自定义指令长期保留在上下文里和每次对话的内容叠加。如果你上次任务遗留了比较特殊的约束这次任务可能会莫名被影响。遇到这种情况最直接的方案是在一次重要任务开始前主动检查当前生效的指令内容把临时约束清理掉。7. 最后想说的几句实在话自定义指令这个功能真正上手之后你会发现它改的不是工具的能力而是你和工具之间的协作方式。工具还是那个工具但你的工作节奏、交付标准、避坑经历都被揉进了那几段文字里它输出的东西自然会更接近你想要的样子。我个人在实际操作中的体会是刚开始设计指令时别贪心先保持精简把最影响结果的那几条约束写明白再跟着实际推送的效果慢慢迭代。遇到问题先怀疑自己的指令描述而不是先怪工具不聪明。把自定义指令当成一个持续维护的小项目你的收获会远超预期。