[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-916":3,"consumer-news-interaction-916":39,"consumer-news-related-916":42},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:916","news","NEWS_ARTICLE",916,"资讯","经常用 Codex 后，我发现 AGENTS.md 只该管一件事","博客园","让 Codex 少走弯路：一份全局 AGENTS.md 的取舍 Codex GPT-5.6、Claude Fable 这一代模型变强后，我反而开始删 Prompt。 以前总怕 AI 理解错。 恨不得把“先看什么、再搜什么、怎么改、最后怎么回复”，一条条写进全局 AGENTS.md。 结果呢？ 规则越","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1001668\u002F202608\u002F1001668-20260830114848294-1139249921.png","","\u002Fnews\u002F916",[18],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"程序员徐公","2026-08-30T11:50","2026-09-02T20:37:56","https:\u002F\u002Fwww.cnblogs.com\u002Fgdutxiaoxu\u002Fp\u002F22761146","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","让 Codex 少走弯路：一份全局 AGENTS.md 的取舍\n\u003Cp>\u003Cimg alt=\"一条清晰的路线，把 AI 的执行从混乱提示词带到明确目标与边界\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F1001668\u002F202608\u002F1001668-20260830114848294-1139249921.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>Codex GPT-5.6、Claude Fable 这一代模型变强后，我反而开始删 Prompt。\u003C\u002Fp>\n\u003Cp>以前总怕 AI 理解错。\u003C\u002Fp>\n\u003Cp>恨不得把“先看什么、再搜什么、怎么改、最后怎么回复”，一条条写进全局 AGENTS.md。\u003C\u002Fp>\n\u003Cp>结果呢？\u003C\u002Fp>\n\u003Cp>规则越来越长，模型却经常被过期的项目细节、互相打架的要求拖住。\u003C\u002Fp>\n\u003Cp>说白了，模型已经能自己判断很多执行细节。你再把每一步写死，等于让它一边解决问题，一边翻一本过期操作手册。\u003C\u002Fp>\n\u003Cp>现在我最常给 AI 的，反而只有两样东西：\u003Cstrong>目标\u003C\u002Fstrong>，以及一份能落地的\u003Cstrong>技术方案\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>全局 AGENTS.md 呢？\u003C\u002Fp>\n\u003Cp>\u003Cstrong>我只让它管一件事：边界\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch2>不是 Prompt 越短越好，是别替模型做它会做的事\u003C\u002Fh2>\n\u003Cp>先说清楚。\u003C\u002Fp>\n\u003Cp>我不是说“Prompt 越短越厉害”。\u003C\u002Fp>\n\u003Cp>一个模糊的目标，丢给再强的模型，也只会得到一堆看起来很努力的猜测。\u003C\u002Fp>\n\u003Cp>该说清的，还是要说清。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>比如你要改什么功能、技术方案准备怎么走、不能碰哪些文件、最后怎么验收\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>这些不是束缚。\u003C\u002Fp>\n\u003Cp>这是把施工图交给 AI。\u003C\u002Fp>\n\u003Cp>但“先读哪个目录”“每一步都要先问我”“只许用某一个命令”这类规则，一旦只对某个项目成立，就不该常驻在全局 AGENTS.md 里。\u003C\u002Fp>\n\u003Cp>项目换了，规则可能就错了。\u003C\u002Fp>\n\u003Cp>模型能力越强，越应该把两件事分开：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>目标和技术方案，跟着当前任务走；\u003C\u002Fli>\n \u003Cli>安全边界和协作习惯，放进全局规则里。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这才是我这次改造的核心。\u003C\u002Fp>\n\u003Ch2>全局规则，到底该留下什么？\u003C\u002Fh2>\n\u003Cp>我最后只保留四类内容。\u003C\u002Fp>\n\u003Cp>第一类，是协作习惯。\u003C\u002Fp>\n\u003Cp>比如默认用中文、表达直接一点、事实和判断要分开。它们不随项目变化，放全局最合适。\u003C\u002Fp>\n\u003Cp>第二类，是目标驱动。\u003C\u002Fp>\n\u003Cp>除非我明确说只要分析或方案，否则 AI 应该推进到一个可以交付、可以验证的结果，而不是做完一半停下来问“要不要继续”。\u003C\u002Fp>\n\u003Cp>第三类，是真实性和验证。\u003C\u002Fp>\n\u003Cp>不知道就说不知道；可能变了就去核验；改过代码就做和风险相称的检查。\u003C\u002Fp>\n\u003Cp>第四类，是安全边界。\u003C\u002Fp>\n\u003Cp>这个最重要。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>AI 可以主动做事，但不能主动把你的工作区清空。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>项目命令、目录结构、依赖版本、业务术语和临时故障补丁，我都不放这里。\u003C\u002Fp>\n\u003Cp>它们该去项目根目录的 \u003Ccode>AGENTS.md\u003C\u002Fcode>，或者某一个只在特定任务触发的 Skill。\u003C\u002Fp>\n\u003Cp>强制限制则更不能只靠文字提醒。\u003C\u002Fp>\n\u003Cp>该用权限、沙箱、CI、Hook 的地方，还是要交给工具。\u003C\u002Fp>\n\u003Ch2>一条规则该放哪？问自己三个问题\u003C\u002Fh2>\n\u003Cp>我以前写 AGENTS.md，最大的毛病就是舍不得删。\u003C\u002Fp>\n\u003Cp>看到一条“挺有用”的经验，就想记进去。\u003C\u002Fp>\n\u003Cp>后来才发现，问题不是这条经验有没有用，而是它应该由谁记住。\u003C\u002Fp>\n\u003Cp>现在我会先问三个问题。\u003C\u002Fp>\n\u003Cp>第一，它换个项目还成立吗？\u003C\u002Fp>\n\u003Cp>还成立，才有资格放全局。\u003C\u002Fp>\n\u003Cp>比如“高风险删除先确认”“别编造验证结果”，换什么仓库都成立。\u003C\u002Fp>\n\u003Cp>第二，它是不是只在一类任务里出现？\u003C\u002Fp>\n\u003Cp>写文章、接口联调、发版检查，这些都有一套固定流程，应该做成 Skill。需要的时候再加载，不需要时别占着全局 context。\u003C\u002Fp>\n\u003Cp>第三，它能不能只靠模型自觉？\u003C\u002Fp>\n\u003Cp>不能。\u003C\u002Fp>\n\u003Cp>像禁止强制推送、限制生产写入、保护密钥，这些该交给权限、沙箱、CI 或 Hook。文字规则负责提醒，工具规则负责拦住。\u003C\u002Fp>\n\u003Cp>翻译成人话就是：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>每个项目都成立的原则，放全局 AGENTS.md；\u003C\u002Fli>\n \u003Cli>只属于某个仓库的事实，放项目根目录的 \u003Ccode>AGENTS.md\u003C\u002Fcode>；\u003C\u002Fli>\n \u003Cli>只在某个动作触发的步骤，放 Skill；\u003C\u002Fli>\n \u003Cli>绝不能出错的红线，交给工具强制执行。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cimg alt=\"四层规则分工：全局原则、项目事实、任务 Skill 与工具强制边界\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F1001668\u002F202608\u002F1001668-20260830114848211-1437238058.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>比如 Android 项目里的索引工具、Gradle 命令、模块划分，确实好用，但它们不是所有项目的常识。\u003C\u002Fp>\n\u003Cp>给它们加“只在 Android 项目命中时启用”的条件，或者直接下放到项目里，才不会让一个前端仓库也背着 Android 的说明书。\u003C\u002Fp>\n\u003Cp>这一层分工做完，AGENTS.md 才会轻下来。\u003C\u002Fp>\n\u003Ch2>这是我这次改造后的全局版本\u003C\u002Fh2>\n\u003Cp>下面这份，是我基于上面的思路整理出的可公开版本。\u003C\u002Fp>\n\u003Cp>重点看“文件系统安全”这一段。\u003C\u002Fp>\n\u003Cp>以前我以为 AI 的风险，是它做得不够快。\u003C\u002Fp>\n\u003Cp>现在越来越觉得，风险是它做得太快，而且替你做了你根本没授权的事。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Global AGENTS.md\n\n这里记录的是我跨项目都要用的协作习惯、行动边界和收尾方式。\n系统要求、用户本次任务，以及离目标文件更近的项目规则，优先级更高。\n\n## 协作与目标\n\n- 没有特别说明时，用中文沟通；另有语言要求时跟随用户。\n- 用清楚、可执行的说法回答，并把事实、判断和未知之处区分开,不要一味讨好我。\n- 围绕任务目标和验收结果做判断，不照着固定流程生搬硬套。\n- 本次技术方案、命令、目录和技术栈，听当前项目的说明。\n\n## 执行与验证\n\n- 动手前，先看和目标直接相关的项目说明、代码、测试与文档。\n- 能沿用已有脚本、依赖和工程约定时，不另起一套。\n- 改动控制在解决问题所必需的范围内，不顺手清理或猜测性重构。\n- API、命令、路径、配置、运行结果和验证结论都不能凭空补全。\n- 改完要做与风险匹配的检查；做不了就说明原因和还剩什么不确定性。\n\n## 文件系统安全\n\n- 工作区内正常修改可直接执行；递归、批量、目录、未跟踪文件或未明确涉及的删除，必须先确认。\n- 跨工作区修改仅限用户明确指定的目标；删除、递归移动或覆盖前，展示真实绝对路径、影响数量和相关 Git 状态。\n- 禁止递归删除 `\u002F`、`$HOME`、`~\u002F.codex` 及系统目录；不得借助环境变量、符号链接或挂载点绕过边界。\n- `rm -rf`、`git clean`、`git reset --hard`、`find -delete`、`xargs rm` 和通配符删除，只有用户明确提出并确认目标后才能执行。\n- 不得为通过构建或测试擅自删除文件，也不得削弱沙箱、审批或权限配置。\n\n## 必须先确认的边界\n\n- 删除重要数据、不可逆迁移、重写 Git 历史、强制推送。\n- 生产部署、生产写入、公开发布。\n- 权限、凭证、DNS、计费或付费资源变更。\n- 明显扩大范围，或改变关键行为、兼容性和架构的高风险选择。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cimg alt=\"AI 在安全闸门前等待授权：危险操作被拦住，明确授权的工作继续向前\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F1001668\u002F202608\u002F1001668-20260830114848275-1935758144.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>这一份不长。\u003C\u002Fp>\n\u003Cp>但它解决的不是某一次开发的问题，而是每一次让 AI 干活时最容易踩的坑。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>如果你是 Android 开发者，或者有自己常用的 IDE 索引工具，可以在项目规则里加一个“满足某些条件才启用”的小节\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>别把它塞进所有项目都加载的全局文件。\u003C\u002Fp>\n\u003Ch2>我现在最常用的组合：目标 + 技术方案\u003C\u002Fh2>\n\u003Cp>全局 AGENTS.md 定边界。\u003C\u002Fp>\n\u003Cp>具体任务怎么推进，我现在更常用的是这四行：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>目标：这次要解决什么，最后交付什么。\n技术方案：准备改哪些模块，按什么路径实现。\n验收：怎么证明它真的完成了。\n边界：哪些文件、行为或外部操作不能碰。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>这就像出门开车。\u003C\u002Fp>\n\u003Cp>AGENTS.md 是交通规则：红灯别闯，不能把车开到人行道上。\u003C\u002Fp>\n\u003Cp>技术方案才是导航：今天去哪，走哪条路，到了怎么确认。\u003C\u002Fp>\n\u003Cp>两份东西混在一起，导航会越来越厚，交通规则也会越来越乱。\u003C\u002Fp>\n\u003Cp>拆开以后，反而省心。\u003C\u002Fp>\n\u003Cp>每次新任务，我只需要把目标和方案说清；AI 再去读当前项目真正相关的规则、代码和文档。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>人负责定方向和边界，AI 负责把方案推进到底。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>放到哪里？最简单的办法，是直接丢给 AI\u003C\u002Fh2>\n\u003Cp>我把个人全局规则维护在 \u003Ccode>~\u002F.codex\u002FAGENTS.md\u003C\u002Fcode>，项目特有规则则放在项目根目录的 \u003Ccode>AGENTS.md\u003C\u002Fcode>。\u003C\u002Fp>\n\u003Cp>不同客户端和项目的加载方式可能不同，第一次别靠记忆猜。\u003C\u002Fp>\n\u003Cp>先让 AI 读取它当前加载了哪些规则文件，再决定改哪里。\u003C\u002Fp>\n\u003Cp>其实最简单的方法，就是把你旧的配置和下面这段话一起丢给 AI：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>请读取我现有的全局 AGENTS.md。\n\n目标：把它精简成跨项目长期有效的协作规则。\n保留：协作偏好、目标驱动、真实性、验证标准、文件系统安全。\n移出：项目命令、单一技术栈、临时故障补丁和具体业务细节。\n\n请先输出三样东西：\n1. 建议删除、保留、下放到项目 AGENTS 或 Skill 的内容；\n2. 一份完整的新版本；\n3. 与原文件的差异摘要。\n\n不要直接覆盖原文件。等我确认后再修改。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>让 AI 先分类，再改文件。\u003C\u002Fp>\n\u003Cp>这一步很值。\u003C\u002Fp>\n\u003Cp>因为最容易出问题的，从来不是它不会写，而是你不知道它准备删什么。\u003C\u002Fp>\n\u003Ch2>最后说两句\u003C\u002Fh2>\n\u003Cp>好的 AGENTS.md，不替 AI 思考。\u003C\u002Fp>\n\u003Cp>它只确保 AI 思考时，不会跑偏，也不会越界。\u003C\u002Fp>\n\u003Cp>模型变强以后，我们不需要再把它训练成一个只会照流程办事的实习生。\u003C\u002Fp>\n\u003Cp>把目标说清，把技术方案给到，把危险边界划好。\u003C\u002Fp>\n\u003Cp>剩下的，让它去做。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>全局规则解决的是：让 AI 在你的项目里稳定推进，又不越界\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>经常用 Codex 的人，还会碰到另一件事：重置信号什么时候出现，很多时候得自己去 X 上翻动态。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>我做的「徐公 AI 雷达」，主要盯着 Tibo 是否在 X（Twitter）发出 Codex 重置相关信号。它会把值得留意的公开信号及时捞出来\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>如果你经常用 Codex，可以关注一下。少刷几次动态，在该关注的时候看到它就够了。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"image\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F1001668\u002F202608\u002F1001668-20260830114959248-795014901.png?w=720&quality=65&strip=all\">\u003C\u002Fp>","让 Codex 少走弯路：一份全局 AGENTS.md 的取舍 Codex GPT-5.6、Claude Fable 这一代模型变强后，我反而开始删 Prompt。 以前总怕 AI 理解错。 恨不得把“先看什么、再搜什么、怎么改、最后怎么回复”，一条条写进全局 AGENTS.md。 结果呢？ 规则越来越长，模型却经常被过期的项目细节、互相打架的要求拖住。 说白了，模型已经能自己判断很多执行细节。你再把每一步写死，等于让它一边解决问题，一边翻一本过期操作手册。 现在我最常给 AI 的，反而只有两样东西：目标，以及一份能落地的技术方案。 全局 AGENTS.md 呢？ 我只让它管一件事：边界。 不是 Prompt 越短越好，是别替模型做它会做的事 先说清楚。 我不是说“Prompt 越短越厉害”。 一个模糊的目标，丢给再强的模型，也只会得到一堆看起来很努力的猜测。 该说清的，还是要说清。 比如你要改什么功能、技术方案准备怎么走、不能碰哪些文件、最后怎么验收。 这些不是束缚。 这是把施工图交给 AI。 但“先读哪个目录”“每一步都要先问我”“只许用某一个命令”这类规则，一旦只对某个项目成立，就不该常驻在全局 AGENTS.md 里。 项目换了，规则可能就错了。 模型能力越强，越应该把两件事分开： 目标和技术方案，跟着当前任务走； 安全边界和协作习惯，放进全局规则里。 这才是我这次改造的核心。 全局规则，到底该留下什么？ 我最后只保留四类内容。 第一类，是协作习惯。 比如默认用中文、表达直接一点、事实和判断要分开。它们不随项目变化，放全局最合适。 第二类，是目标驱动。 除非我明确说只要分析或方案，否则 AI 应该推进到一个可以交付、可以验证的结果，而不是做完一半停下来问“要不要继续”。 第三类，是真实性和验证。 不知道就说不知道；可能变了就去核验；改过代码就做和风险相称的检查。 第四类，是安全边界。 这个最重要。 AI 可以主动做事，但不能主动把你的工作区清空。 项目命令、目录结构、依赖版本、业务术语和临时故障补丁，我都不放这里。 它们该去项目根目录的 AGENTS.md，或者某一个只在特定任务触发的 Skill。 强制限制则更不能只靠文字提醒。 该用权限、沙箱、CI、Hook 的地方，还是要交给工具。 一条规则该放哪？问自己三个问题 我以前写 AGENTS.md，最大的毛病就是舍不得删。 看到一条“挺有用”的经验，就想记进去。 后来才发现，问题不是这条经验有没有用，而是它应该由谁记住。 现在我会先问三个问题。 第一，它换个项目还成立吗？ 还成立，才有资格放全局。 比如“高风险删除先确认”“别编造验证结果”，换什么仓库都成立。 第二，它是不是只在一类任务里出现？ 写文章、接口联调、发版检查，这些都有一套固定流程，应该做成 Skill。需要的时候再加载，不需要时别占着全局 context。 第三，它能不能只靠模型自觉？ 不能。 像禁止强制推送、限制生产写入、保护密钥，这些该交给权限、沙箱、CI 或 Hook。文字规则负责提醒，工具规则负责拦住。 翻译成人话就是： 每个项目都成立的原则，放全局 AGENTS.md； 只属于某个仓库的事实，放项目根目录的 AGENTS.md； 只在某个动作触发的步骤，放 Skill； 绝不能出错的红线，交给工具强制执行。 比如 Android 项目里的索引工具、Gradle 命令、模块划分，确实好用，但它们不是所有项目的常识。 给它们加“只在 Android 项目命中时启用”的条件，或者直接下放到项目里，才不会让一个前端仓库也背着 Android 的说明书。 这一层分工做完，AGENTS.md 才会轻下来。 这是我这次改造后的全局版本 下面这份，是我基于上面的思路整理出的可公开版本。 重点看“文件系统安全”这一段。 以前我以为 AI 的风险，是它做得不够快。 现在越来越觉得，风险是它做得太快，而且替你做了你根本没授权的事。 Global AGENTS.md 这里记录的是我跨项目都要用的协作习惯、行动边界和收尾方式。 系统要求、用户本次任务，以及离目标文件更近的项目规则，优先级更高。 ## 协作与目标 - 没有特别说明时，用中文沟通；另有语言要求时跟随用户。 - 用清楚、可执行的说法回答，并把事实、判断和未知之处区分开,不要一味讨好我。 - 围绕任务目标和验收结果做判断，不照着固定流程生搬硬套。 - 本次技术方案、命令、目录和技术栈，听当前项目的说明。 ## 执行与验证 - 动手前，先看和目标直接相关的项目说明、代码、测试与文档。 - 能沿用已有脚本、依赖和工程约定时，不另起一套。 - 改动控制在解决问题所必需的范围内，不顺手清理或猜测性重构。 - API、命令、路径、配置、运行结果和验证结论都不能凭空补全。 - 改完要做与风险匹配的检查；做不了就说明原因和还剩什么不确定性。 ## 文件系统安全 - 工作区内正常修改可直接执行；递归、批量、目录、未跟踪文件或未明确涉及的删除，必须先确认。 - 跨工作区修改仅限用户明确指定的目标；删除、递归移动或覆盖前，展示真实绝对路径、影响数量和相关 Git 状态。 - 禁止递归删除 `\u002F`、`$HOME`、`~\u002F.codex` 及系统目录；不得借助环境变量、符号链接或挂载点绕过边界。 - `rm -rf`、`git clean`、`git reset --hard`、`find -delete`、`xargs rm` 和通配符删除，只有用户明确提出并确认目标后才能执行。 - 不得为通过构建或测试擅自删除文件，也不得削弱沙箱、审批或权限配置。 ## 必须先确认的边界 - 删除重要数据、不可逆迁移、重写 Git 历史、强制推送。 - 生产部署、生产写入、公开发布。 - 权限、凭证、DNS、计费或付费资源变更。 - 明显扩大范围，或改变关键行为、兼容性和架构的高风险选择。 这一份不长。 但它解决的不是某一次开发的问题，而是每一次让 AI 干活时最容易踩的坑。 如果你是 Android 开发者，或者有自己常用的 IDE 索引工具，可以在项目规则里加一个“满足某些条件才启用”的小节。 别把它塞进所有项目都加载的全局文件。 我现在最常用的组合：目标 + 技术方案 全局 AGENTS.md 定边界。 具体任务怎么推进，我现在更常用的是这四行： 目标：这次要解决什么，最后交付什么。 技术方案：准备改哪些模块，按什么路径实现。 验收：怎么证明它真的完成了。 边界：哪些文件、行为或外部操作不能碰。 这就像出门开车。 AGENTS.md 是交通规则：红灯别闯，不能把车开到人行道上。 技术方案才是导航：今天去哪，走哪条路，到了怎么确认。 两份东西混在一起，导航会越来越厚，交通规则也会越来越乱。 拆开以后，反而省心。 每次新任务，我只需要把目标和方案说清；AI 再去读当前项目真正相关的规则、代码和文档。 人负责定方向和边界，AI 负责把方案推进到底。 放到哪里？最简单的办法，是直接丢给 AI 我把个人全局规则维护在 ~\u002F.codex\u002FAGENTS.md，项目特有规则则放在项目根目录的 AGENTS.md。 不同客户端和项目的加载方式可能不同，第一次别靠记忆猜。 先让 AI 读取它当前加载了哪些规则文件，再决定改哪里。 其实最简单的方法，就是把你旧的配置和下面这段话一起丢给 AI： 请读取我现有的全局 AGENTS.md。 目标：把它精简成跨项目长期有效的协作规则。 保留：协作偏好、目标驱动、真实性、验证标准、文件系统安全。 移出：项目命令、单一技术栈、临时故障补丁和具体业务细节。 请先输出三样东西： 1. 建议删除、保留、下放到项目 AGENTS 或 Skill 的内容； 2. 一份完整的新版本； 3. 与原文件的差异摘要。 不要直接覆盖原文件。等我确认后再修改。 让 AI 先分类，再改文件。 这一步很值。 因为最容易出问题的，从来不是它不会写，而是你不知道它准备删什么。 最后说两句 好的 AGENTS.md，不替 AI 思考。 它只确保 AI 思考时，不会跑偏，也不会越界。 模型变强以后，我们不需要再把它训练成一个只会照流程办事的实习生。 把目标说清，把技术方案给到，把危险边界划好。 剩下的，让它去做。 全局规则解决的是：让 AI 在你的项目里稳定推进，又不越界。 经常用 Codex 的人，还会碰到另一件事：重置信号什么时候出现，很多时候得自己去 X 上翻动态。 我做的「徐公 AI 雷达」，主要盯着 Tibo 是否在 X（Twitter）发出 Codex 重置相关信号。它会把值得留意的公开信号及时捞出来。 如果你经常用 Codex，可以关注一下。少刷几次动态，在该关注的时候看到它就够了。",3364,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":38},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":40,"likeCount":41,"commentCount":41,"contentLikeCount":41,"contentCommentCount":41,"sourceLikeCount":41,"sourceCommentCount":41},false,0,[43,52,58,65,73,80,86,93],{"id":44,"kind":7,"title":45,"summary":46,"image":47,"href":48,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":50},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[51],"人工智能",{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":57},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":59,"kind":7,"title":60,"summary":61,"image":62,"href":63,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":64},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":66,"kind":7,"title":67,"summary":68,"image":15,"href":69,"meta":70,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":71},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[72],"软件开发",{"id":74,"kind":7,"title":75,"summary":76,"image":77,"href":78,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":79},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":81,"kind":7,"title":82,"summary":83,"image":15,"href":84,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":85},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":87,"kind":7,"title":88,"summary":89,"image":90,"href":91,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":92},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[51],{"id":94,"kind":7,"title":95,"summary":96,"image":15,"href":97,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":98},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]