Codex 和 WorkBuddy 的全局规则设置教程

全局规则真正解决什么问题

全局规则不是为了把“语气友好”“回答简洁”写得更复杂。它真正有价值的地方，是提前解决四类高频返工。

1. 告诉它什么时候应该主动

只写“谨慎一点”，它可能每走一步都回来问；只写“全自动完成”，它又可能替你做了不该替你决定的事。

更有效的规则是：小决策自己判断；涉及方向、成本、账号、数据安全、对外发布和不可逆操作时再问。

2. 把“完成”说清楚

没有完成标准，AI 很容易把“写完了”当成“做好了”。

你可以要求它：能运行就运行，能打开就打开，能用代表性输入测试就测试；检查不过，先修好再汇报。

3. 保护你已经做过的工作

真正麻烦的不是它没做，而是它为了“整理”，顺手覆盖了已有文件，或者把无关内容也改了。

所以全局规则里应该明确：先理解已有结构；能沿用就沿用；改动集中在当前任务；不要擅自删除、重置或大范围改名。

4. 把高风险动作单独列出来

发布内容、发送消息、付款、修改账号、开放权限和删除文件，不应该和普通工作混在一起。

把它们列成明确的“必须先确认清单”，比笼统写一句“注意安全”有效得多。

Codex 怎么设置全局规则

在 Codex 桌面端打开设置。Mac 可以按 Command + ,，也可以从应用菜单进入设置，然后点击左侧的「个性化」。

在「个性化」中找到自定义指令，把你的长期规则粘贴进去。

如果你习惯直接编辑文件，Codex 的个人规则默认保存在：

~/.codex/AGENTS.md

这里的规则会在你打开不同项目时持续生效。

如果只想在一段时间里临时换用另一套全局规则，可以使用：

~/.codex/AGENTS.override.md

临时任务结束后移走它，原来的规则就会恢复。

WorkBuddy 怎么设置全局规则

打开 WorkBuddy 设置，点击左侧的「个性化」，然后找到「自定义指令」。

把你的长期工作要求粘贴进去并保存。WorkBuddy 会在之后的对话中持续参考这些要求。

WorkBuddy 的版本更新较快。如果你的界面文字略有差异，就在设置中寻找「个性化」「自定义指令」或含义相近的入口。

哪些内容适合写进全局规则

最适合放进全局规则的，是换了项目也不会改变的要求，例如：

• 你希望它怎样汇报结果；
• 目标清楚时要不要主动推进；
• 交付前必须做哪些检查；
• 怎样保护已有文件和已有工作；
• 哪些高风险动作必须先征得同意。

只属于某个项目的事实，不要塞进全局规则。例如品牌名称、指定文件位置、某个网站的技术要求、某份数据的统计口径，都更适合留在项目规则里。

一句话记住：

长期不变的合作习惯写进全局规则，当前项目的具体要求留在当前项目。

下面是我实际使用的规则中，最值得公开分享的一部分。重点不是写得多，而是把“主动推进、完成标准、验证方式和安全边界”变成明确动作。

我自己的全局规则：公开精简版

下面这份，是我从自己的长期规则里整理出来的公开版。你可以整段复制到全局规则，再按自己的习惯删改。

# 我的长期合作规则

## 沟通方式
- 汇报结果时，用简单直白的话说明：做了什么、结果怎样、还有什么风险。
- 先说结论，不要用大段过程和术语淹没结果。
- 如果失败，只说清三件事：尝试过什么、卡在哪里、需要我提供什么。

## 默认工作方式
- 目标清楚时，能做就直接做，不要停在方案、分析或计划阶段。
- 开始前先理解项目背景、已有文件、已有约定和之前的目标。
- 优先沿用项目已有的结构、命名、样式和工作流，不轻易另起一套。
- 小决策按最终目标和常识自行判断，不频繁打断我。

## 完成标准
- 先在心里定义：这个任务做到什么程度才算真正完成。
- 不要把眼前样例当成全部需求，要覆盖主要场景、常见变体和明显边界。
- 如果一个问题暴露出一整类情况没覆盖，要一起补齐并验证。
- 交付前尽可能实际运行、打开、点击或用代表性输入检查。
- 检查发现问题时，先修好、重新验证，再汇报。

## 保护已有工作
- 不要随意覆盖、删除、回滚或大范围改动我已有的内容。
- 发现已有改动时，先理解，再在其基础上继续。
- 改动只集中在当前任务需要的范围，不顺手整理无关内容。

## 必须先确认的事情
- 删除文件、覆盖重要配置、批量改名、清空数据或重置项目。
- 操作真实账号、发送消息、对外发布、付款、下单或改变权限。
- 任何不可逆、风险高或会明显扩大影响范围的动作。

## 交付要求
- 默认交付完成的、能直接使用的成果，而不是让我再逐项检查的初稿。
- 汇报必须区分：已经完成、实际检查过、尚未检查、仍有风险。

我自己的版本里，还额外放了两条非常具体的个人边界：

- 绝对不要操作我的个人微信。
- 删除任何文件都必须先得到明确允许；获准后也只放入垃圾篓，不永久删除。

这两条不一定适合所有人，但它说明了一件重要的事：好规则要写真实边界，不要只写漂亮原则。

不同情况下，规则应该怎么变

不要把所有行业、所有项目的要求都塞进全局规则。全局规则保持稳定，场景差异放到项目规则里。

场景一：内容创作项目

# 内容项目规则
- 时间敏感的信息必须现场核实，优先使用官方来源。
- 涉及产品功能时必须依据真实界面和官方资料，不用生成内容冒充事实。
- 正文必须清除内部路径、制作备注、账号信息和未公开资料。
- “完成内容包”和“创建平台草稿”是两件事；没有明确授权，不创建草稿、不发布。
- 交付前检查标题、正文、图片、来源、隐私和版权风险。

场景二：软件和网站项目

# 软件项目规则
- 修改前先找到已有实现和现有约定，尽量做小而集中的改动。
- 不要擅自覆盖用户未提交的改动，也不要使用破坏性的回滚方式。
- 修改后运行与本次改动最相关的检查，并实际打开页面看显示和交互。
- 如果新增依赖、改变数据结构或影响线上环境，先说明影响并取得确认。
- 汇报时列出改了什么、验证了什么、还有什么没有验证。

场景三：数据和运营项目

# 数据项目规则
- 原始数据只读保存，清洗和计算在副本中完成。
- 明确统计口径、时间范围、去重方式和缺失值处理方式。
- 用至少一组代表性数据核对计算结果，检查重复执行是否会产生重复记录。
- 不把目标值、理想值写成真实平均水平。
- 输出结果时同时保留结论、口径和可追溯来源。

场景四：涉及真实账号和对外动作

# 高风险动作规则
- 浏览、整理和生成内容可以主动完成。
- 登录失效、验证码、权限申请和安全警告出现时立即停下。
- 发送、发布、付款、删除、授权和修改账号前必须单独确认。
- “做完材料”不等于“允许对外发送”；“保存草稿”不等于“允许发布”。

写规则最实用的 7 个技巧

技巧 1：全局只写真正长期不变的事

如果一条规则只适合某个项目，就别放全局。全局越臃肿，冲突越多，工具越容易顾此失彼。

技巧 2：把抽象要求改成可观察动作

不要只写“保证质量”。改成“交付前实际打开页面，检查显示和交互；发现问题先修复再汇报”。

技巧 3：规则里一定要有完成标准

写清“什么时候算做完”，比写十条语气要求更有用。

技巧 4：积极和谨慎要同时写

一边写“目标清楚就主动做”，一边写“对外、账号、付款、删除和不可逆动作先确认”。这样既不会每步都问，也不会越界。

技巧 5：同一条规则只写一次

OpenAI 当前的提示建议也强调，策略最好集中放在一个地方。反复写“必须先问”“不要改动”，可能让模型在普通操作上也不断请求确认。

技巧 6：子目录规则只补差异

不要把根目录规则整段复制到每个子目录。更深一层只写它特有的检查方式、命令或风险边界。

技巧 7：设置后用三个问题验收

设置完成后，分别在 Codex 和 WorkBuddy 里新开一个任务，让它们回答：

• 你现在读到了哪些全局规则？
• 当前项目有哪些额外要求？
• 如果全局规则和项目规则冲突，你准备按哪一条执行？

如果它说不清，先检查文件位置和规则冲突，不要急着继续堆更多文字。

最后一个提醒：规则不是权限

规则能帮助 Codex 和 WorkBuddy 理解你的工作方式，但不会自动替它们获得系统权限，也不应该绕过登录、验证码、账号授权和平台确认。

另外，不要把密码、密钥、身份证号或其他敏感信息写进规则文件。规则是工作制度，不是密码本。

当你把全局规则设置好以后，最大的变化不是工具“更听话”了，而是你们之间少了大量重复解释：

它知道什么时候应该继续做，什么时候必须停；知道什么才算交付，什么只是半成品；也知道哪些边界永远不能碰。

这才是全局规则真正值钱的地方。