From 231db310bb40929d48100613dab203dbf179a9e2 Mon Sep 17 00:00:00 2001 From: WuYongJie <549727955@qq.com> Date: Wed, 23 Sep 2026 18:43:30 +0800 Subject: [PATCH] docs: remove obsolete Codex multi-agent rules --- AGENTS.md | 102 +---------- README.md | 5 +- docs/CODEX_MULTI_AGENTS.md | 345 ------------------------------------- 3 files changed, 10 insertions(+), 442 deletions(-) delete mode 100644 docs/CODEX_MULTI_AGENTS.md diff --git a/AGENTS.md b/AGENTS.md index 663108b..734ec5b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -15,89 +15,15 @@ - 非必要不要使用兜底逻辑；优先把原生主链路和标准流程做好，只有在明确需要兼容、降级或应急，并说明原因和影响范围时，才增加兜底处理。 - 修改后必须验证，先跑最相关的验证，再视情况扩大范围。 - 不触碰其他应用配置，不把项目规则写入全局 `Codex` 配置。 +- 数据库写入、删除或恢复，权限与下载资格，上传、下载、转码、外部接口、批量操作，后台统计、日志、导出与审计，以及影响线上数据或用户可见结果的改动，按高风险任务核对影响范围并加强验证。 -## 3. 项目内 Multi-agents 规则 +## 3. 界面基线 -当任务满足以下任一条件时，优先启用内置多代理： +- 品牌中心实际入口是 `/workspaces/dashboard/core-metrics`；`app/page.tsx` 只负责登录和权限跳转。界面改动以 `DESIGN.md`、`components/department-dashboard/DepartmentShell.tsx` 和对应页面的现状为准。 +- 品牌中心采用深色导航轨与浅色内容区；素材资产库按其独立工作壳处理。 +- 项目不挂载 `.dark` 主题类，新代码不要添加无效的 `dark:` 变体。 -- 任务同时涉及前后端、接口与页面联动。 -- 任务涉及上线前审查、发布门禁、回归检查。 -- 任务需要同时做“功能正确性 + UI 统一性 + 发布风险”判断。 -- 任务跨越多个目录，单代理容易遗漏影响范围。 - -当用户明确写出以下任一表达时，默认必须真正进入多代理流程，而不是只解释角色定义： - -- “按项目的审查模式处理” -- “按项目的修复模式处理” -- “按项目的发布模式处理” -- “用 Multi-agents 处理” -- “启用项目团队” - -默认团队结构： - -- `orchestrator`：主控代理，负责拆解任务、分配角色、汇总结论。 -- `backend`：后端代理，负责 `app/api/**`、`lib/**`、`prisma/**` 风险审查与修复建议。 -- `frontend`：前端代理，负责 `app/**` 页面层、`components/**`、`hooks/**` 交互回归。 -- `ui_auditor`：UI 统一规范审查员，负责视觉系统和组件一致性审查。 -- `release_gate`：发布守门代理，负责按证据给出可上线/有条件上线/不可上线结论。 - -对外沟通规则： - -- 只有 `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 基线规则（2026-08-15 更新）： - -- 平台主体已切换为「由壹点·品牌中心」看板，UI 统一标准以**看板首页**为基线（`app/page.tsx`）。 -- 基线语言：Zen Minimal × Future Organic 白皮书风（白纸 #fafafa / 墨字 #1a1c1d / 发丝线 / 编号索引 / 柔紫光晕点缀 / 无阴影平面化），完整令牌见 `DESIGN.md`。 -- **全站浅色单主题**：深色主题已废弃（`tailwind darkMode: 'class'` 且不挂 `.dark`，`dark:` 变体全部失效）；新代码不得再写 `dark:` 类。 -- logo 双版本：浅底表面用 `loginLogoUrl`（深色图案），黑底遗留表面用 `headerLogoUrl`。 -- `ui_auditor` 在审查其它页面时，优先对齐上述语言；遗留页面（admin/profile/share/edit 与组织架构页旧壳）按「逐页统一」节奏迁移。 -- 如果某个后台页面或特殊业务页面需要偏离基线风格，必须说明原因和影响范围。 - -## 5. 前端体验与 Impeccable 规则 +## 4. 前端体验与 Impeccable 规则 - 凡涉及页面、组件、样式、布局、交互、响应式、可访问性或其它前端体验的工作，默认必须优先调用并严格遵循 `$impeccable` Skill；除非用户明确要求跳过。 - 开始修改前，先读取项目现有代码、视觉规范、组件库和产品上下文，并判断当前页面属于 `Operate`、`Persuade`、`Read` 还是 `Experience` 模式。 @@ -105,24 +31,12 @@ UI 基线规则（2026-08-15 更新）： - 实现后必须检查桌面端与移动端实际页面，并处理层级、间距、字体、颜色、溢出、空状态、错误状态、交互反馈、响应式和可访问性问题。 - 交付前执行与任务匹配的 `$impeccable critique`、`$impeccable audit` 或 `$impeccable polish` 流程，并保留必要的验证证据。 -## 6. 输出要求 - -多代理任务的输出默认按下面结构收敛： - -- `发现的问题` -- `严重级别 P0 / P1 / P2` -- `影响范围` -- `修复建议` -- `验证清单` -- `最终结论` - -## 开发进度同步 +## 5. 开发进度同步 - 可说明的工作提交后，运行 `npm run progress:sync -- ... --apply`，按真实证据使用 `code_complete`、`testing` 或 `done`。 - 仅同步 Git 元数据；目录匹配不唯一就停止，同步失败不得阻断 Git 与生产发布。 -## 7. 建议先读的文档 +## 6. 建议先读的文档 - `README.md` -- `docs/CODEX_MULTI_AGENTS.md` - `.private\gongxiangp2-完整敏感接管清单-2026-08-13.md` diff --git a/README.md b/README.md index 87b02e3..36e5a5e 100644 --- a/README.md +++ b/README.md @@ -82,12 +82,12 @@ gongxiangp2/ │ ├── organization/ # 组织管理（人员架构顶层页） │ ├── register/ # 注册页 │ ├── share/ # 分享页 -│ └── page.tsx # 品牌中心看板首页（登录落点） +│ └── page.tsx # 登录与权限跳转至实际工作面 ├── components/ # 通用组件、后台组件、上传组件、看板壳（board/） ├── lib/ # 业务工具、上传/下载/转码/权限逻辑 ├── prisma/ # Prisma schema ├── scripts/ # 运维/修复/清理脚本 -├── docs/ # 网络、团队协作等项目文档 +├── docs/ # 网络、接口与部署等项目文档 ├── uploads/ # 本地上传与处理中间文件 └── README.md ``` @@ -367,7 +367,6 @@ npm run start - `docs/部署规范.md`：当前部署规范 - `docs/Git增量部署方案.md`：Git 增量部署方案 - `docs/生产存储桶接入信息.md`：当前 MinIO / uploads 存储事实 -- `docs/CODEX_MULTI_AGENTS.md`：项目内 Codex 团队协作规则 - `docs/外部接口文档.md`：当前对外接口说明 ## 说明 diff --git a/docs/CODEX_MULTI_AGENTS.md b/docs/CODEX_MULTI_AGENTS.md deleted file mode 100644 index 7974e6c..0000000 --- a/docs/CODEX_MULTI_AGENTS.md +++ /dev/null @@ -1,345 +0,0 @@ -# Codex Multi-agents 团队方案 - -本文件只服务当前项目，不写入全局配置。 - -## 1. 团队目标 - -把 Codex 的内置多代理能力用于本项目的协作流程，重点解决： - -- 任务拆分更准 -- 审查范围更全 -- UI 统一性有专门审查 -- 发布前有明确门禁 -- 输出格式统一，方便复核 - -## 2. 团队结构 - -### 核心 5 角 - -1. `orchestrator` - - 拆解任务 - - 选择需要出动的角色 - - 汇总冲突意见 - - 给最终执行顺序 - - 作为团队唯一对外接口，直接和用户沟通 - -2. `backend` - - 审查接口、数据、存储、转码、权限、日志链路 - - 重点目录：`app/api/**`、`lib/**`、`prisma/**` - -3. `frontend` - - 审查页面交互、状态流、用户路径 - - 重点目录：`app/**`、`components/**`、`hooks/**` - -4. `ui_auditor` - - 审查颜色、字体、间距、圆角、阴影、组件状态一致性 - - 默认优先输出问题，不直接主导业务改动 - -5. `release_gate` - - 汇总所有角色输出 - - 按证据判定： - - `可上线` - - `有条件上线` - - `不可上线` - -## 2.1 对话方式 - -- 用户默认只和 `orchestrator` 对话。 -- `orchestrator` 负责理解需求、追问缺口、决定是否派发子代理。 -- 子代理默认不直接对用户说话，只向 `orchestrator` 回传结果。 -- `orchestrator` 对外输出的内容应是整理后的统一结论，而不是把子代理原文直接堆给用户。 - -### 辅助 2 角 - -6. `explorer` - - 适合先做跨文件摸底、找影响范围、找入口文件 - - 不承担最终结论 - -7. `worker` - - 适合在边界明确后，处理单一子任务的修改 - - 不能替代主控做总调度 - -## 3. 三种工作模式 - -### A. 审查模式 - -适用场景： - -- 上线前检查 -- 大改前摸底 -- 不确定该不该动代码 - -推荐编组： - -- `orchestrator` -- `backend` -- `frontend` -- `ui_auditor` -- `release_gate` - -### B. 修复模式 - -适用场景： - -- 已经确定问题所在，需要定点修改 -- 既要修功能，也要看 UI 回归 - -推荐编组： - -- `orchestrator` -- `explorer` -- `backend` 或 `frontend` -- `worker` -- 需要时追加 `ui_auditor` - -### C. 发布模式 - -适用场景： - -- 发版前最终门禁 -- 需要形成可复核结论 - -推荐编组： - -- `orchestrator` -- `backend` -- `frontend` -- `ui_auditor` -- `release_gate` - -## 4. 调度规则 - -本项目默认采用“用户只对 `orchestrator` 提需求，由 `orchestrator` 自动派单”的方式。 - -### 自动派单总原则 - -- 用户不需要手动指定角色。 -- `orchestrator` 负责判断是否启用团队，以及需要出动哪些角色。 -- 如果任务很小，允许不启用完整团队。 -- 如果任务高风险、影响范围大、或准备上线，优先扩大编组。 - -### 仅后端类任务 - -例如： - -- 下载 -- 上传 -- 转码 -- 批量删除 -- 外部接口 -- 管理后台统计接口 - -推荐角色： - -- `orchestrator` -- `backend` -- 必要时加 `release_gate` - -### 仅前端类任务 - -例如： - -- 首页 -- 分享页 -- 上传弹窗 -- 管理后台页面 - -推荐角色： - -- `orchestrator` -- `frontend` -- `ui_auditor` - -### 全链路联动任务 - -例如： - -- 上传后展示异常 -- 后台统计与页面表现同时改 -- 下载接口和前端下载入口一起变 - -推荐角色： - -- `orchestrator` -- `backend` -- `frontend` -- `ui_auditor` -- `release_gate` - -### 影响范围不清的任务 - -例如： - -- 不确定问题在前端还是后端 -- 不确定影响几个目录 -- 只是看到现象，还没看到根因 - -推荐角色： - -- `orchestrator` -- `explorer` - -说明： - -- 先摸底，再扩编 -- 避免一开始全员出动造成重复劳动 - -## 5. 每个角色的标准输出 - -### `orchestrator` - -- 任务目标 -- 角色分派 -- 依赖关系 -- 验收标准 -- 风险分级 - -### `backend` - -- 发现的问题 -- P0 / P1 / P2 -- 影响接口或数据范围 -- 修复建议 -- 验证清单 - -### `frontend` - -- 发现的问题 -- P0 / P1 / P2 -- 影响页面和交互路径 -- 修复建议 -- 验证清单 - -### `ui_auditor` - -- 视觉一致性问题 -- 组件一致性问题 -- 页面级问题 -- 必须统一项 -- 可迭代项 - -### `release_gate` - -- 门禁汇总 -- 是否可上线 -- 阻塞项 -- 上线前必须完成项 -- 上线后观察项 - -## 6. 发布判定规则 - -- 任一 `P0` 未关闭：`不可上线` -- 关键链路未验证：`不可上线` -- 只有可控 `P1`，且有回滚方案：`有条件上线` -- 无阻塞项，验证通过：`可上线` - -## 6.2 默认门禁严格度 - -- 当前项目默认采用“偏严格”的发布门禁。 -- 原因： - - 项目已经在线上运行 - - 任务经常跨前后端和 UI - - 用户默认不是程序员，应该尽量减少“技术上能上线、实际很难判断风险”的情况 - -默认解释如下： - -- `严格拦截` - - 只要有 `P0` - - 只要关键链路没验证 - - 只要没有明确回滚路径 - - 结论就是 `不可上线` - -- `有限放行` - - 如果只有少量 `P1` - - 且不影响核心链路 - - 且有明确回滚方案和后续跟踪项 - - 可以给 `有条件上线` - -- `正常放行` - - 没有 `P0` - - 核心链路验证通过 - - UI 没有明显破坏统一性的问题 - - 就给 `可上线` - -## 6.3 高风险边界 - -当前项目默认把下面这些改动视为高风险： - -- 数据类 - - 数据库写入 - - 批量更新 - - 批量删除 - - 数据恢复 - - 会影响现有线上数据结果的逻辑调整 - -- 权限类 - - 登录后权限判断 - - 角色判断 - - 管理员能力 - - 下载资格 - - 外部接口访问控制 - -- 批量与资源类 - - 上传 - - 下载 - - 转码 - - 批量操作 - - 外部接口 - - 后台导出 - - 操作日志与审计记录 - -对应规则： - -- 命中高风险边界时，`orchestrator` 默认至少启用 `backend` -- 同时影响页面体验时，追加 `frontend` -- 同时影响视觉统一时，追加 `ui_auditor` -- 需要上线判断、范围大、或风险不清时，追加 `release_gate` -- 高风险任务默认采用更保守的门禁和验证要求 - -## 6.1 UI 基线 - -- 当前项目的 UI 统一标准默认以首页为基线。 -- 基线文件：`app/page.tsx` -- `ui_auditor` 审查其它页面时，默认对齐以下维度： - - 视觉语言 - - 主按钮样式 - - 标题与信息层级 - - 间距与留白节奏 - - loading / empty / error / success 状态反馈 -- 如果某个页面因为管理后台密度、特殊业务流程或设备限制必须偏离首页风格，需要单独说明理由，不默认视为统一标准。 - -## 7. 推荐用法 - -进入本项目后，如果要启用内置多代理，建议以当前项目目录启动，并在任务里明确写出采用哪种模式。 - -当用户明确写出下面这些触发语时，`orchestrator` 默认应真正派发子代理，而不是只停留在口头说明： - -- “按项目的审查模式处理这次改动” -- “按项目的修复模式处理这次任务” -- “按项目的发布模式做门禁” -- “用项目团队处理” -- “启用 Multi-agents” - -示例表达： - -- “按项目的审查模式处理这次改动。” -- “按项目的修复模式先拆任务，再定点修改。” -- “按项目的发布模式做一次完整门禁。” - -如果当前 `Codex` 会话未启用多代理能力，可在启动时临时开启，不写入全局： - -`codex --enable multi_agent -C "D:\AI Code\gongxiangp2"` - -## 8. 目前还不能自动决定的四件事 - -这些问题我已经预留好团队位置，但还需要你和我一个一个定： - -1. UI 统一标准到底以哪套页面为基线 -2. 发布门禁的阈值要多严格 -3. 哪些任务必须全队出动，哪些只需要局部编组 -4. 数据、权限、批量操作的高风险边界怎么划 - -当前已确定第 1 项：UI 基线默认以首页为准。 -当前已确定第 2 项：发布门禁默认采用偏严格标准。 -当前已确定第 3 项：用户只和 `orchestrator` 对话，由 `orchestrator` 自动派单。 -当前已确定第 4 项：数据、权限、批量操作、资源链路相关改动默认视为高风险。