本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 自从AI Coding以来我一直在整理 Codex 的 AGENTS.md 、项目规则和 Skills（也同步更新Cursor和Claude）。 最初的做法很直接：遇到问题就往 AGENTS.md 里补一条规则，需要新的任务能力就再加一个 Skill。内容多了以后，哪些规则适用于所有项目，哪些只属于当前项目，开始变得不清楚。做需求、可研或技术方案时应该交付什么，评审结论需要什么证据，任务做到哪里应该停，也需要重新理清。 我把这套做法重新拆分并整理成了 Codex Three-Layer Delivery ： github.com GitHub - alieismy/codex-three-layer-delivery: An unofficial, deliverable-driven rules-and-skills... An unofficial, deliverable-driven rules-and-skills framework for Codex-first software R&D. 项目采用 MIT License，GitHub 仓库公开。这是一个非官方项目，与 OpenAI、Cursor、Anthropic 或仓库提到的其他框架没有隶属或背书关系。 解决什么问题 它主要面向系统设计和专业文档交付，目前覆盖： 需求分析、PRD 和 SRS； 可行性研究，技术与标准研究； 技术方案、概要设计、建设方案和详细设计； 标准规范、技术文章、白皮书、研究报告和独立评审。 编码、代码评审、测试执行、部署和发布由其他工作流负责。Codex 仍然可以做这些事，只是这套规则和 Skills 没有把它们纳入职责范围。 我更关心的是：怎样让 Codex 在长任务结束后，留下可以继续评审、修改和追踪的交付物，而不是一段很长但难以复用的聊天记录。 为什么分成三层 Layer 1 全局指令 ↓ Layer 2 项目级交付规则 ↓ Layer 3 专业 Skills 第一层是个人长期使用的全局规则，对应 ~/.codex/AGENTS.md 。准确性、证据纪律、授权边界和表达偏好等跨项目要求放在这里。 第二层是项目自己的 AGENTS.md ，用于约束项目范围、交付要求、质量门禁、安全边界、MCP 路由和验证方式。换项目时，不需要跟着改个人全局规则。 第三层是按交付物划分的专业 Skills。仓库现在有 8 个可独立使用的专业 Skill： rd-requirement rd-feasibility rd-research rd-solution rd-design rd-specification rd-writing rd-review 另外还有一个负责交付编排的 rd-delivery 。只有用户明确要求多阶段、多文档编排或跨会话交接时，才调用它。 这 9 个 Skill 可以按任务选择，不必从头到尾走一遍。比如，评审一份技术方案可以直接使用 $rd-review ；需要核实外部事实时，再调用 $rd-research 。 范围和证据 一个问题是任务很容易越做越大。原本只是评审一个数据库选型，最后可能一路扩展成架构重构、安全加固、性能专项，再加一套通用 Validator。 有些项目确实需要这些工作，但不应该默认全部展开。这套规则要求先弄清楚当前任务要交付什么，再确定需要查哪些资料、做哪些验证。只有用户明确要求、已经复现问题、存在权威要求或发现实质风险时，才扩大工作范围。如果证据支持保持现状，“不修改”也可以是正常结论。 另一个问题是证据状态经常被混在一起： 文档声明 源码实现 静态配置 最终生成或实际生效配置 运行状态 业务或生产验收 官方文档写着“支持某项配置”，不等于目标机器已经配置正确，也不能证明它正在运行或通过了业务验收。这套规则要求把这些状态分开，结论写到证据实际支持的程度。 中文版和其他客户端适配 英文根目录是仓库的维护基线，简体中文内容放在 zh-CN/ 。仓库也提供 Cursor 和 Claude Code 的可选适配，但 Codex 仍是主要目标。 不同客户端发现规则、调用 Skills 和处理权限的方式并不完全相同，适配文件仍需在目标环境中验证。仓库的静态校验只覆盖已检查的文本、结构和配置契约，不能代替客户端运行验证或业务验收。 怎么开始 先克隆仓库： git clone https://github.com/alieismy/codex-three-layer-delivery.git cd codex-three-layer-delivery 如果主要使用中文，可以先看： zh-CN/README.md zh-CN/codex/ zh-CN/skills/ 已经有自己的 AGENTS.md 时，不建议直接覆盖。先检查现有内容和生效范围，再选择需要的部分合并。这些模板带有明确的工作方式和取舍，不是适合所有人的“最佳配置”。 PowerShell 用户可以用下面的脚本安装中文 RD Skills。脚本会备份已有的同名 Skills，并校验安装结果；加上 -CheckOnly 时只检查，不执行安装。 pwsh -File ./scripts/install-rd-skills.ps1 -Language zh-CN pwsh -File ./scripts/install-rd-skills.ps1 -Language zh-CN -CheckOnly 如果要维护或修改仓库，可以运行静态门禁： python -m pip install -r requirements-validation.txt pwsh ./scripts/validate.ps1 pwsh ./scripts/test-validator.ps1 git diff --check 项目还在继续调整。我比较想听听实际使用 Codex 做需求、可研、方案、设计和评审的佬友怎么评价： 三层拆分是否真的有用； 这些 Skills 的职责有没有重叠或缺口； 哪些规则在真实任务里反而会妨碍交付； Cursor 或 Claude Code 适配是否遇到兼容问题。 发现问题可以直接提 Issue 或 PR： github.com GitHub - alieismy/codex-three-layer-delivery: An unofficial, deliverable-driven rules-and-skills... An unofficial, deliverable-driven rules-and-skills framework for Codex-first software R&D. 致谢 本项目在整理过程中参考了以下公开项目的思路与实践。列出这些项目不代表对方背书、合作、兼容或直接派生，详细归属见 ATTRIBUTION.md 。 Matt Pocock Skills Everything Claude Code GSD Core Rlues Superpowers oh-my-codex Trellis 感谢 LINUX DO 社区为开源项目提供交流与推广空间。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/18 16:37:09