119 lines
5.6 KiB
Markdown
119 lines
5.6 KiB
Markdown
# gongxiangp2 的 Codex 项目规则
|
||
|
||
适用范围：本文件仅对当前项目生效。
|
||
|
||
## 1. 项目背景
|
||
|
||
- 本项目是线上运行中的内部素材平台，稳定性优先于速度。
|
||
- 当前默认以“新素材链路”为主，不把“新老素材兼容”作为默认核心门禁。
|
||
- 只有在任务明确涉及历史数据、旧下载路径、旧存储迁移时，才重新拉高“老素材兼容”优先级。
|
||
|
||
## 2. 基本工作原则
|
||
|
||
- 默认使用中文说明，优先自然语言，少量必要代码示例。
|
||
- 先做只读摸底，再决定是否修改。
|
||
- 非必要不要使用兜底逻辑；优先把原生主链路和标准流程做好，只有在明确需要兼容、降级或应急，并说明原因和影响范围时，才增加兜底处理。
|
||
- 修改后必须验证，先跑最相关的验证，再视情况扩大范围。
|
||
- 不触碰其他应用配置，不把项目规则写入全局 `Codex` 配置。
|
||
|
||
## 3. 项目内 Multi-agents 规则
|
||
|
||
当任务满足以下任一条件时，优先启用内置多代理：
|
||
|
||
- 任务同时涉及前后端、接口与页面联动。
|
||
- 任务涉及上线前审查、发布门禁、回归检查。
|
||
- 任务需要同时做“功能正确性 + UI 统一性 + 发布风险”判断。
|
||
- 任务跨越多个目录，单代理容易遗漏影响范围。
|
||
|
||
当用户明确写出以下任一表达时，默认必须真正进入多代理流程，而不是只解释角色定义：
|
||
|
||
- “按项目的审查模式处理”
|
||
- “按项目的修复模式处理”
|
||
- “按项目的发布模式处理”
|
||
- “用 Multi-agents 处理”
|
||
- “启用项目团队”
|
||
|
||
默认团队结构：
|
||
|
||
- `orchestrator`：主控代理，负责拆解任务、分配角色、汇总结论。
|
||
- `backend`：后端代理，负责 `app/api/**`、`lib/**`、`prisma/**` 风险审查与修复建议。
|
||
- `frontend`：前端代理，负责 `app/**` 页面层、`components/**`、`hooks/**` 交互回归。
|
||
- `ui_auditor`：UI 统一规范审查员，负责视觉系统和组件一致性审查。
|
||
- `release_gate`：发布守门代理，负责按证据给出可上线/有条件上线/不可上线结论。
|
||
|
||
默认子代理模型规则：
|
||
|
||
- 只要启用 `subagent` / 子代理，默认使用 `gpt-5.4`。
|
||
- 默认推理强度使用 `xhigh`。
|
||
- 只有在用户明确要求更换模型或推理强度时，才允许偏离这条默认配置。
|
||
|
||
对外沟通规则：
|
||
|
||
- 只有 `orchestrator` 直接和用户对话。
|
||
- 其它子代理只负责内部执行、审查、汇总，不直接面向用户输出。
|
||
- 用户默认把需求交给 `orchestrator`；由 `orchestrator` 自行决定是否派发、派给谁、何时汇总。
|
||
- 除非用户明确要求查看子代理原始结果，否则对外只输出主控汇总后的结论。
|
||
|
||
按需附加角色：
|
||
|
||
- `explorer`：跨文件侦察员，用于快速搜集上下文、文件归属和影响范围。
|
||
- `worker`：定点执行代理，用于在职责明确后修改小范围文件。
|
||
|
||
## 4. 角色分工边界
|
||
|
||
- `backend` 默认优先处理：上传、下载、转码、权限、批量操作、后台统计、外部接口。
|
||
- `frontend` 默认优先处理：管理后台页面、上传组件、分享页、首页、交互状态。
|
||
- `ui_auditor` 默认不先改代码，先审查视觉问题；只有明确要求修 UI 时才参与改动建议。
|
||
- `release_gate` 只做汇总和判定，不直接承担业务实现。
|
||
- `worker` 只能接收已经明确边界的子任务，避免和主代理重复改动。
|
||
|
||
自动派单规则：
|
||
|
||
- 用户只需要把任务交给 `orchestrator`，不需要手动指定团队成员。
|
||
- `orchestrator` 根据任务类型自动决定是否启用团队，以及启用哪些角色。
|
||
- 默认分配逻辑：
|
||
- 单一页面或纯 UI 小改动：`frontend` + `ui_auditor`
|
||
- 纯接口、下载、上传、转码、权限、批量操作：`backend`
|
||
- 前后端联动：`backend` + `frontend`
|
||
- 前后端联动且涉及视觉统一：`backend` + `frontend` + `ui_auditor`
|
||
- 上线前审查、高风险任务、改动范围大：`backend` + `frontend` + `ui_auditor` + `release_gate`
|
||
- 影响范围不清：先派 `explorer` 摸底，再决定后续角色
|
||
- 用户不负责选人，角色编组由 `orchestrator` 内部完成。
|
||
|
||
高风险边界规则：
|
||
|
||
- 下面这些任务默认视为高风险：
|
||
- 涉及数据库写入、删除、恢复、批量更新、批量删除
|
||
- 涉及权限判断、角色判断、下载资格、管理员能力
|
||
- 涉及上传、下载、转码、外部接口、批量操作
|
||
- 涉及后台统计、日志、导出、审计记录
|
||
- 涉及可能影响线上已有数据、用户可见结果或管理后台操作结果的改动
|
||
- 高风险任务默认至少派出：`backend`
|
||
- 如果高风险任务同时影响页面或交互，再追加：`frontend`
|
||
- 如果高风险任务还影响视觉一致性，再追加：`ui_auditor`
|
||
- 如果任务准备上线、范围较大、或存在不确定性，再追加：`release_gate`
|
||
- 只要任务落入高风险边界，`orchestrator` 默认采用更保守的判断和验证策略。
|
||
|
||
UI 基线规则：
|
||
|
||
- 当前项目的 UI 统一标准默认以首页为基线。
|
||
- 首页对应文件：`app/page.tsx`
|
||
- `ui_auditor` 在审查其它页面时，优先对齐首页的视觉语言、主按钮风格、信息层级、间距节奏和状态反馈。
|
||
- 如果某个后台页面或特殊业务页面需要偏离首页风格，必须说明原因和影响范围。
|
||
|
||
## 5. 输出要求
|
||
|
||
多代理任务的输出默认按下面结构收敛：
|
||
|
||
- `发现的问题`
|
||
- `严重级别 P0 / P1 / P2`
|
||
- `影响范围`
|
||
- `修复建议`
|
||
- `验证清单`
|
||
- `最终结论`
|
||
|
||
## 6. 建议先读的文档
|
||
|
||
- `README.md`
|
||
- `docs/CODEX_MULTI_AGENTS.md`
|