AGENTS.md 更适合写“规则和边界”，而不是写死每一步操作：把审批要求、该用哪个 skill、项目标准写进去，让 Codex 自己判断怎么执行。
AI根据立正公开的文章和视频整理，不是他本人回复。重要的判断，请回到出处核对。
AGENTS.md 用来定规则，不写死流程
材料里的观点立正的做法是在项目根目录的 AGENTS.md 里写清约束，比如“所有对外发布相关内容都需要审批”，然后给 Codex 完整权限，靠这份文件来 gate，而不是去设计一套 rigid 的 custom access control。他的理由是硬编码的权限控制容易挂一漏万，也没法利用 Agent 本身的判断力；先给 full access 加规则约束，出问题再回头改 AGENTS.md 或退回确定性方案1。所以推荐的设置方向是：把“什么必须审批、什么不能做、该调用哪个 skill”写成规则，执行细节交给 Codex。
skill 的调用也可以写进 AGENTS.md
材料里的观点在实操里，他们遇到过 Codex 的 skill 系统没生效的情况，处理办法是不再依赖 Codex 自带的 skill 机制，而是把 skill 系统挪到 AGENTS.md 里说明，通过 AGENTS.md 告诉它以后用哪个2。这段是多人视频、说话人未逐段确认，只能作为具体做法参考，不能确定是谁的判断。可迁移的点是：当某个能力没被自动触发时，与其反复调试工具本身，不如在 AGENTS.md 里明确指定该用哪个 skill。
规则之外，还要给足上下文和标准
AGENTS.md 只是入口之一。更完整的做法是把团队最重要的做事标准——设计规范、代码质量要求、审核 checklist——写成 AI 能理解的规则注入工作流，让 AI 自动拿这些规则做 double check，效果接近让最资深的人出现在每次具体工作里3。同时立正强调不要过度参与，尽量给 Agent 工具、标准和 skill，让它自己把事干好1。所以 AGENTS.md 里除了审批边界，也适合放验收标准和该遵守的规范。
材料只给出 AGENTS.md 的用法思路和零散实操片段，没有一份完整的推荐模板；具体字段和写法需要结合你自己的项目规则来定。
出处
- 1Codex“背着我”发了个帖，但我不怪她…
直接讲了在 AGENTS.md 里写审批规则、给 full access 再 gate 的取舍，是理解设置思路的核心。
- 2课代表和鸭哥工作的实况 | how the sausage is made
展示了把 skill 系统写进 AGENTS.md 的具体做法，适合核对“skill 不生效怎么办”。
- 3你团队的 AI 效果不好，问题不在模型，在 Context
说明规范注入和 AGENTS.md 在 context 架构里的位置，适合理解规则该放什么。
你也有想问的？
卡住的时候，问问立正：回答只从立正讲过、写过的东西里来，每一段都能点回原文。
问类似的问题也可以接着问：
别人还问了
- 高内聚低耦合的架构原则对于AI来说make sense吗？
部分成立：AI 让“耦合”从代码模块之间转移到了 context 与工具之间，内聚的对象变成了喂给 AI 的那份上下文。
- 换工作的时候，长期来看，考虑的优先级应该是什么
长期看，优先级是行业与增长空间、公司平台和业务、直属老板，最后才是薪资；薪资差距超过三成时才需要单独权衡。
- 我想学 LLM，但不知道如何开始，你可以给我建议吗？
学 LLM 最有效的起点不是先啃完理论，而是选一个真实小任务，边做边补概念，让卡住的地方告诉你该学什么。
- 什么场景/团队/项目用MCP/Skills什么时候不用
MCP 和 Skills 不是按场景二选一，而是先看结果、再看它是否真省 context：官方 MCP/CLI 简单但结果杂乱、几轮就撑满窗口时，才值得自己做成 Skill。
- 如何用 AI 辅助 产品设计
用 AI 做产品设计，关键不是让 AI 画图或写代码，而是把 AI 放进产品运行过程里承担任务，并把自己的判断标准写成 AI 能读的上下文。
- 什么是创意？创意也是对现有元素的组合排列吗？是的话，在这种情况下，怎么判断一个点子是否是真正创新的创意？最后如何获得创意？
创意可以看成对现有元素的重新组合，但判断它是否真创新，要看它是否解决了一个此前没被满足的真实需求；获得创意的路径是靠近真实问题、快速交给现实修正，而不是坐在房间里凭空想点子。