G1-G5 固化Codex自然语言协作规则
这个提交包含在：
@@ -4,7 +4,10 @@
|
||||
|
||||
## 来源
|
||||
|
||||
- OpenAI How OpenAI uses Codex: https://openai.com/business/guides-and-resources/how-openai-uses-codex/
|
||||
- OpenAI Codex AGENTS.md: https://developers.openai.com/codex/guides/agents-md
|
||||
- OpenAI Codex Skills: https://developers.openai.com/codex/skills/
|
||||
- OpenAI Codex Automations: https://openai.com/academy/codex-automations/
|
||||
- OpenAI Agents 文档: https://platform.openai.com/docs/guides/agents
|
||||
- OpenAI Evals 文档: https://platform.openai.com/docs/guides/evals
|
||||
- Anthropic Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents
|
||||
@@ -81,6 +84,91 @@ AGENTS.md 只放硬约束和入口，不复制长规则。
|
||||
|
||||
commit message 使用中文并引用 Issue ID，例如 `R121/A1-A3 沉淀交付事实源`。
|
||||
|
||||
### 8. 自然语言派工是默认入口
|
||||
|
||||
用户不需要按固定提示词派工。可以只发一段自然语言，例如“企业微信里这个页面还是PC布局，先核查并规划后续修复”。agent 必须主动拆解：
|
||||
|
||||
- 意图：缺陷、需求、验收反馈、计划、审查、测试、部署、设计或产品流程优化。
|
||||
- 对象：页面、接口、业务流程、数据、部署环境、文档或自动化。
|
||||
- 约束：是否要求先规划、是否已授权实施、是否涉及公网、企业微信、真实账号或真实数据。
|
||||
- 下一步：核查、建 Issue CSV、给方案等确认、实施、验证、提交、部署。
|
||||
|
||||
当用户说“确认”时，默认表示批准上一条明确方案或 Issue CSV 进入下一阶段。若上下文中存在多个候选方案，agent 才需要反问确认对象。
|
||||
|
||||
### 9. 少反问，先查已有资产
|
||||
|
||||
agent 在声明 blocker 前，必须先查项目内已有资产：
|
||||
|
||||
- `issues/*.csv`、`docs/`、`.agents/skills/hyb-oa-delivery/` 和 `AGENTS.md`。
|
||||
- 已有测试脚本、Playwright 用例、回归脚本、试运行报告和覆盖矩阵。
|
||||
- `artifacts/`、`output/`、手工复核证据、测试样本和历史日志。
|
||||
- 环境变量示例、部署 runbook、可用的公网健康检查和本地启动脚本。
|
||||
|
||||
只有在这些线索不足以安全推进时，才把问题抛回给用户。不能因为没有第一时间看到账号、样本、脚本或历史结论，就直接要求用户重复提供。
|
||||
|
||||
### 10. 何时必须反问或暂停
|
||||
|
||||
以下情况必须暂停确认：
|
||||
|
||||
- 非微小代码改动还没有方案批准，或没有 Issue CSV 执行合同。
|
||||
- 需要删除或重置数据、处理迁移漂移、修改生产配置、重启远程服务。
|
||||
- 需要使用、重置或暴露真实账号密码、密钥、令牌、客户数据。
|
||||
- 用户目标互相冲突，且无法通过现有文档和代码推断优先级。
|
||||
- 验收标准无法推断，且错误实现会造成明显返工或数据风险。
|
||||
|
||||
除此之外，agent 应优先用合理假设继续推进，并在输出中明确假设和验证结果。
|
||||
|
||||
### 11. Codex 的项目角色用法
|
||||
|
||||
同一个 agent 可以按任务临时切换工作视角，但输出必须落到可审计交付物：
|
||||
|
||||
- 产品经理：把一段话拆成业务流程、优先级、Issue CSV、验收标准和下一步建议。
|
||||
- 需求分析：补齐边界条件、角色权限、异常状态、国内同类系统常见处理方式。
|
||||
- 开发：按 Issue 实施后端、前端、脚本或文档变更，并执行对应验证。
|
||||
- 审查：默认先报风险、行为回归、权限泄漏、状态机问题和漏测项。
|
||||
- QA：用接口回归、Playwright、视觉截图、真机/公网 smoke 和人工步骤复核。
|
||||
- 设计师：对齐 `docs/product-design-rules.md`、公司官网视觉和国内 OA 操作习惯。
|
||||
- 用户代理：模拟普通员工、审批人、财务、管理员在 PC、手机、企业微信里的真实路径。
|
||||
|
||||
不需要用户显式写“请扮演某角色”。agent 应根据语义自动选择角色；若任务跨多个角色，先给执行顺序和交接物。
|
||||
|
||||
### 12. 可选短模板
|
||||
|
||||
模板不是强制要求，只用于减少歧义：
|
||||
|
||||
```text
|
||||
缺陷：我看到的问题是... 期望是... 请先核查/直接修复，完成后告诉我是否已部署。
|
||||
需求：我想实现... 影响页面/角色是... 先规划并等我确认/确认后直接实施。
|
||||
测试：请覆盖... 流程，包含PC/手机/企业微信/公网/视觉检查。
|
||||
审查：请 review 最近改动，重点看权限、状态机、数据、体验和漏测。
|
||||
产品优化：请参考国内类似系统，判断当前流程是否合理，并给出可执行建议。
|
||||
```
|
||||
|
||||
如果用户只写普通段落，agent 仍按第 8 条自动识别，不要求用户补模板。
|
||||
|
||||
### 13. 可自动化的工作
|
||||
|
||||
适合自动化或半自动化固化的任务：
|
||||
|
||||
- 每轮 Issue CSV 校验、状态回填检查和未完成项扫描。
|
||||
- 后端 syntax、Prisma validate、核心回归脚本。
|
||||
- 前端 typecheck、build、关键页面 Playwright 和视觉截图。
|
||||
- 公网 `/ready`、企业微信配置、资源版本、核心文案和 live smoke。
|
||||
- 业务流程巡检：报销、发票、请假、审批、票据、附件上传、异步任务终态。
|
||||
- 设计规则巡检：PC 页面误入移动端、原生英文上传控件、内部码值、UUID 主展示、按钮和底部导航异常。
|
||||
|
||||
不适合完全自动化的任务要保留人工验收入口，例如真实企业微信登录、真实账号安全操作、生产数据处理、财务制度决策。
|
||||
|
||||
### 14. 完成口径
|
||||
|
||||
开发类任务完成时，agent 必须说明：
|
||||
|
||||
- 改了什么，关联哪些 Issue ID。
|
||||
- 验证了什么，哪些命令或路径通过。
|
||||
- 是否提交 commit，commit hash 是什么。
|
||||
- 面向用户可测试的改动是否已经部署；未部署时不能说“可以去企业微信测试”。
|
||||
- 哪些风险或后续工作仍未完成。
|
||||
|
||||
## 何时更新本文件
|
||||
|
||||
当连续两轮以上重复提醒同一类 agent 行为，或者同一类遗漏导致返工时，先判断：
|
||||
|
||||
在新工单中引用
屏蔽一个用户