“自定义指令”这四个字最近在AI编程圈和效率工具圈里出现的频率高得吓人。Codex火起来之后Workbuddy自定义指令也成了社区里的热门搜索词原因其实很简单同一个模型有人能让它一口气改完一个模块有人却连让它老老实实输出一段不跑题的代码都费劲。差距基本不在模型本身而在于你有没有花时间告诉它“按我的方式来干活”。所谓自定义指令就是把这套“我的方式”固化下来让AI助手在每次对话开始时自动加载不再需要你反复把同样的要求粘贴一遍。这篇东西写给所有被AI默认行为折磨过的人尤其是重度使用编程助手的开发者、需要用AI处理日常工作的运营和产品同学以及想在团队里把AI用法沉淀下来的团队负责人。1. 自定义指令是什么为什么Codex和Workbuddy都靠它1.1 默认行为与真实需求的差距从哪来我先举几个真实到扎心的场景。我最初接触Codex的时候让它补一个接口它一口气给我写了一大坨代码新增了一个服务改了两个文件还给每段都配上了详实的注释。我其实只是想让它在某个已有的函数里补上缺失的参数类型。还有前端项目里团队规范是单引号它默认给我双引号让它生成提交信息它写“完成了XX功能的开发”而组里要求的是符合Conventional Commits的规范格式更气人的是它遇到不确定的库时不去查文档直接编了一个看起来很合理的API跑起来报错才暴露。这些问题的原因不是模型能力不够而是它不知道你的偏好、不知道你项目的潜规则。你看到一个新来的工程师是什么体验Codex一开始就是什么体验能力强但不懂事。默认模型的行为是“通用最优”它面向的是所有用户所以只能折中无法贴合任何一个人的具体习惯。你让它写代码它就按最主流的风格来你让它做分析它就按最保险的结构来。问题不在于“AI不够聪明”而在于它缺一份专属于你的说明书。1.2 为什么不能靠每次对话时说清楚有人会问我不是可以在每次提问时把这些要求写在提示词里吗可以但这是一件反人性的事。你一天开几十个会话每次都要重复“单引号、严格模式、只给我改动部分”先不说累你总有忘记的时候一旦忘了输出质量就滑坡。更麻烦的是每个会话都是全新的上下文窗口你上一轮说的话并不会自动带到下一轮。团队协作场景里还有一个死穴每个人对同一个规则的描述都不一样有人只说“代码风格好看点”有人写“用ESLint的规则”最后AI的行为完全不可控。自定义指令的价值就在这里它把“每次都要唠叨一遍”的内容固化成一个文件、一份配置工具在启动时自动加载稳定、可复现、可传承。你可以把它理解为浏览器的默认设置而不是每次开网页都重新填一遍表单这个类比我一直觉得很贴切。同时它也让团队里的“隐性知识”第一次有了显式的载体以前新人来了要靠老员工口口相传的项目背景现在AI和人都能看同一份指令文件沟通成本降一大截。1.3 到底哪些人最需要自定义指令简单列一下你可以对号入座。第一类是重度使用编程助手的开发者这类人每天和AI交互几十次几行指令能换来每天少说几十句重复表达收益最直接。第二类是用AI做运营、日报、汇报文档的职场人Workbuddy自定义指令推荐的帖子下面不少评论就是这个人群他们的核心诉求往往是“输出别啰嗦、结构固定、语言流畅”这些偏好不固化的话每次都得现写。第三类是技术负责人或团队管理员把项目技术栈、代码规范、工具链版本写进项目级指令文件AI就成了一个入职就能遵守团队规范的新成员。第四类是折腾AI自动化的人把常用工作流的判断逻辑和输出格式定死自动化才谈得上稳定。这几类人的痛点不一样但解法是同一个把偏好沉淀成指令。用户类型核心痛点自定义指令的解法开发者代码风格、输出格式不一致固定命名规范、缩进、类型要求运营/产品回复冗长、结构不稳定限定输出结构、字数、语言团队负责人规范难以传承项目级规则文件自动加载自动化爱好者工作流不稳定固定每一步逻辑与输出格式2. 指令放在哪里、怎么写才有效2.1 项目级指令和全局指令怎么分工配置入口方面我建议你先建立两层概念项目级和全局级。项目级指令是放在仓库根目录的Markdown文件最常见的叫法是AGENTS.mdCodex在处理项目代码时会自动读取它类似的命名还有RULES.md、.cursorrules之类具体取决于你用的工具支持哪些。这个文件跟着代码仓库走团队每个人拉下来都能看到非常适合放团队约定技术栈、目录结构、代码风格、测试要求、禁止操作等等。全局级指令则存在你本机的工具配置目录里放的是只属于你个人的偏好比如“默认用中文回复、代码用diff展示、不要输出解释性废话”这种与具体项目无关的习惯。这样分工的好处是项目相关的规则不会污染你个人的全局配置而个人的表达习惯也不会混进团队文件。如果你用的工具没有明确的全局配置入口比如某些像Workbuddy这类偏工作流管理的助手那就看它设置里有没有“默认指令”或者“通用预设”之类的选项本质上是一样的只是入口换到了界面里。2.2 一份可直接抄的指令模板无论工具是Codex还是Workbuddy指令内容的组织逻辑都差不多我个人习惯按四段来写角色定位、技术栈或领域背景、输出格式要求、禁止事项。下面这份是我在真实项目里用过的模板改改项目名就能用。# 角色 你是本项目的资深前端工程师熟悉TypeScript、Vue 3和Vite。 # 技术栈 - 框架Vue 3 Composition API不用Options API - 语言TypeScript启用严格模式 - 样式Tailwind CSS禁止内联style # 代码风格 - 缩进2空格 - 字符串单引号 - 组件命名PascalCase文件名必须与组件名一致 - 类型要求不要用any避免使用隐式类型 # 输出格式 - 修改代码时只返回改动部分用diff块展示 - 不做解释、不给“以下为修改后代码”这类废话 - 如果一行能说清楚就不要写三行 # 禁止事项 - 不要修改package.json中未被要求的依赖 - 不要假定API返回类型先确认接口定义 - 不要把业务逻辑写进组件render函数这份模板为什么有效因为它把要求写得具体、可验证。注意我特意写了“资深前端工程师”这种身份设定其实作用有限真正起作用的是后面那些“单引号、2空格、不要用any”的硬规则。写自定义指令最大的误区就是把形容词当规范模型能理解的是动作和条件不是感觉。我自己踩过这个坑之后每一条指令都会问一句这句话能不能让另一个人一眼判断出遵守了没有能留下不能就删。2.3 优先级与冲突怎么处理实际操作中你会发现项目级和全局级指令不是二选一的关系而是叠加的关系。正常情况下两者同时生效冲突时多数工具会以更具体的项目级指令优先。但光靠默认行为是不稳妥的我建议你在全局指令末尾加一句话“如果项目级指令有与本规则冲突的条款一律以项目级指令为准。”这句话能让模型在遇到冲突时有明确依据而不是靠猜。另外如果你们团队的AGENTS.md里有和历史遗留代码不一致的规则别急着删旧规则写成“历史模块允许暂时保持旧风格新代码一律按新规范”这种带场景边界的指令实战中特别好用它避免AI在旧代码上大动干戈。规则边界这个东西写得越清楚模型就越不需要“自由发挥”而自由发挥恰恰是大多数失误的源头。2.4 判断指令好坏的三个标准最后给一套自我检查的标准。第一是可验证性任何一条指令你必须能通过输出判断它是不是被遵守了“代码要干净”不行“禁止任何any类型”就可以。第二是无歧义性不用形容词不用相对描述给出具体的值或格式。第三是精简性我强烈不建议一个指令文件超过300行超过的部分模型处理起来费劲还占用上下文窗口得不偿失。这三条标准看起来简单真写起来每条都需要有意识地克制尤其写多了之后会觉得“多写点更安全”其实恰恰相反。3. 实战复现Codex与Workbuddy的自定义指令配置流程3.1 Codex配置从零到一的完整步骤先说Codex这边整个过程不长。第一步是确认你要放项目级还是全局级通常建议两个都建。项目级的话在仓库根目录新建一个AGENTS.md文件把上面那份模板粘进去再按你们项目的实际情况改全局的话编辑Codex的全局配置文件不同版本位置略有差异一般在你用户目录下的.codex文件夹里。第二步是写入个人偏好比如“回答使用中文、代码diff展示、不要输出解释性废话”。第三步是启动一个全新的会话不要让旧会话里残留之前的上下文直接跑到项目目录下打开Codex开始验证。第四步是验证拿一个你们项目里最典型的任务去跑比如“帮我修掉这个接口的类型问题”观察它有没有按指令来。如果项目里已经有一堆其他工具生成的规则文件或者存在多个命名类似的规则文件我建议你先把AGENTS.md建好再在文档里写清楚“项目规则以AGENTS.md为准其他文件中的冲突描述忽略”。这段声明在团队场景里尤其重要因为AI可能同时读到README、CONTRIBUTING和AGENTS.md如果你不从源头压住优先级后面排查冲突会让你怀疑人生。3.2 用Workbuddy这类工作助手时怎么配指令如果你用的是Workbuddy这类偏工作流管理的AI助手配置入口一般在设置面板里名字可能叫“自定义指令”“自定义规则”或者“偏好预设”本质上和Codex的AGENTS.md是一回事。操作上直接在它的设置界面新建一条指令把角色、任务、输出格式填清楚保存之后在对话里选中或者让它自动加载就行。这类工具的指令更偏“场景化”而非“代码化”所以语言要更贴近业务。这里我放一份“运营日报输出指令”是可以拿过去改一改直接用的推荐写法你是一名资深互联网运营专家擅长数据分析和复盘。 每次我提交周报数据时严格按下面顺序输出 1. 本周核心数据变化用表格列出指标、数值、环比 2. 值得关注的异常点最多3条每条不超过一句话 3. 结论下周建议优先做的3件事 硬性要求 - 全程中文 - 总字数不超过600字 - 不要重复粘贴我提供的原始数据直接给结论 - 数据缺失时明确标注“数据缺失”不要猜测这份指令好用的原因是它同时管住了定义、结构、长度和边界。你仔细看最后一条“数据缺失时明确标注”其实是在给模型一个“承认不知道”的许可很多指令没写这条模型就会硬编一个数据出来这种情况在运营场景里比代码写错更致命。另外Workbuddy这类UI配置不像文件系统那么直观改完记得导出备份别等换电脑的时候才想起来没存。3.3 如何验证指令真的生效指令配完不是结束验证才是关键。我自己习惯的做法是准备一份典型任务清单大概三到五个你平时最常给AI布置的任务比如“按规范提交本次改动”“分析这组数据并给结论”“重构这个函数”。然后在配置指令前后各跑一遍同一个任务对比输出差异。如果差异明显说明指令生效了如果你发现某一条始终不生效把它单独抽出来改成更具体的肯定句。这里有个迭代节奏的经验一次只改一条跑完后记录结果再改下一条。一次性改五条你会完全分不清哪条有效哪条是摆设。我自己那份指令文件迭代了七八个版本第一版写了一大堆“不要”什么“不要解释、不要寒暄、不要编造”结果模型反而不知道到底什么能做后来改成“只返回代码、用diff展示、给出数据来源标注”效果立刻不一样。原因并不玄学肯定句给了模型一个明确动作否定句只给了它一堆禁忌一旦动作太多互相牵制输出就会变得奇怪。这个认知算是玩了很久自定义指令之后最值钱的一条心得。3.4 把指令做成团队模板库当你手头的指令稳定下来之后别让它烂在自己电脑里。我见过做得好的团队会专门建一个templates目录把团队不同角色的指令模板都收进去前端AGENTS.md、后端AGENTS.md、数据端AGENTS.md、周报助手指令、代码Review指令等等。新项目启动时直接复制对应的模板改一改就能用。这里有个细节要注意不同项目之间的差异往往比想象中大模板库只能给“骨架”具体的技术栈、目录结构、认证方式这些还是要人工校对不能指望AI自己判断。还有版本管理指令文件属于配置文件是有版本演进的建议你在主文件里放一个changelog区每次改了什么简单记两行不然三个月后再看你会完全忘记某条规则是为什么加进来的。4. 指令不生效常见问题与排查技巧实录4.1 最常见的五类失效原因先给结论指令不生效的时候不要急着怀疑工具坏了九成以上是下面几个原因。第一是文件命名或位置不对很多人以为放一个AGENT.md就行实际上得是AGENTS.md而且必须在项目根目录放深一层AI都读不到。第二是加载优先级问题项目里同时存在多个规则类文件时工具会按自己的机制加载你的指令可能会被另一个文件覆盖。第三是措辞太模糊写“回复要专业简洁”等于没写模型每次还是按自己的风格来。第四是上下文被截断指令文件太长模型只看到了前面一截后面的规则自然全失效。第五也是最容易被忽略的就是你改了配置却没有重新开个会话旧会话里仍然沿用之前的配置你当然感觉“改了没用”。排查的时候我习惯按顺序过一遍先看文件在不在正确位置再看有没有冲突文件然后看措辞是否具体最后才怀疑工具本身。因为绝大多数情况都是前三个造成的工具本身对指令加载一般是很可靠的。4.2 问题排查速查表现象可能原因解决动作指令完全不生效文件名/路径写错确认是AGENTS.md且位于项目根目录部分指令生效与其他规则文件冲突合并规则文件显式声明优先级输出还是太啰嗦只写了“简洁”这种形容词改成“只返回代码不要任何解释”改动配置无变化未重新加载会话关掉旧会话开一个新会话验证长指令后段失效上下文窗口被占满精简指令到300行内核心规则前置多个规则互相打架多文件碎片化合并成一个AGENTS.md统一管理这张表我自己打印出来贴过一阵排查的时候一条条对照效率高很多。顺带说一句如果你在团队里共用同一个仓库改完AGENTS.md一定要告诉其他人重新开会话不然大家会来问你“为什么指令没生效”其实只是忘了刷新会话。这类问题在团队协作中出现的频率远比你想象的高。4.3 上下文占用与指令瘦身聊一个很多人忽略的副作用自定义指令不是白给的。它加载之后会占用模型上下文窗口的一部分指令写得越长留给实际任务的空间越少。我自己见过有人把团队Wiki整本塞进AGENTS.md结果模型反而变得迟钝连基本代码都写不利索了。所以指令应该像飞机行李有免费额度超重一定影响飞行。常规建议是核心规则控制在150行以内文件总长尽量不超过300行如果团队规范实在很多拆成一个主文件和几个按需加载的模块主文件里只写高频且必须遵守的事项低频的通过引用标记或每次临时传入的方式加载。比如把单元测试的规范单独放一份test_rules.md主文件里只写一句“涉及测试代码时遵循test_rules.md”使用时再手动引入。这样既保住了规范覆盖面又不拖累单次任务的表现。4.4 安全与合规的底线自定义指令里很容易夹带敏感信息这一点必须单独强调。我见过有人把数据库连接串、API key、内部域名直接写进AGENTS.md然后这个仓库是公开的等于把密钥送上了门。就算后来删掉Git提交记录的历史版本里还能翻出来很多人就是在这上面栽了跟头。所以无论你配多详尽的指令有一条红线不能碰任何密钥、token、密码、生产环境的连接信息都不得写入指令文件。另外如果仓库会对外开源指令里也不要写公司内部项目的真实命名和敏感业务细节。还有一个习惯从网上抄别人的“高效指令”回来之前先从头到尾读一遍别有用心的人完全可以通过指令诱导模型输出不该输出的信息这条不仅关乎质量更关乎安全。工具在手里怎么用是你的自由但配置落盘之后它就成了文件文件一旦离开你的控制范围风险就跟着来了。最后说点实践之外的体会。自定义指令这件事表面上是配置本质上是在整理自己的工作方式。你什么都不写AI就是一个通用工具你写清楚了它才可能成为你的专属助手。我见过不少朋友第一版就憋了个超长指令跑了一周又全部删掉太贪心反而没效果。我自己现在保持一个习惯每次觉得AI输出不对劲第一反应不是骂它而是回去改指令把这次的教训加进去下次就不再踩。这种小步迭代的节奏比一次性憋大招好用得多。如果你正打算开始先列三条最让你难受的点配上跑两天你会很快感受到差别。