codex的开发范式
在使用 Vibe Coding 的过程中，Codex 应如何规范开发范式?
一句话：在 Vibe Coding 里，Codex 不应只是“写代码机器”，而应被规范成“按契约执行的工程代理（Engineering Agent）”。
1. 先定“角色边界”：Codex 负责产出，人类负责决策
把职责分清楚，效率会高很多：
- 人类负责：需求优先级、架构取舍、风险接受、上线决策
- Codex 负责：代码实现、重构建议、测试补全、文档更新、脚手架
原则：AI 可执行，关键决策必须可追溯到人。
2.用“任务契约”驱动每次生成（不要直接一句话让它开写）
每个任务都给 Codex 一个固定输入模板（像 mini-PRD）：
- 目标（要解决什么问题）
- 范围（做什么 / 不做什么）
- 输入输出契约（API、类型、错误码）
- 约束（性能、安全、兼容性、依赖限制）
- 验收标准（可测试、可观测、可回滚）
- 交付物（代码 + 测试 + 文档 + 迁移脚本）
3. 强制“先设计后编码”
要求 Codex 每次先给：
- 方案摘要（2~3 种，含 trade-off）
- 选型理由
- 影响面清单（模块、接口、数据结构）
- 风险与回滚策略
通过后再开始写代码。
这一步能显著减少“看起来能跑但不可维护”的代码。
4. 开发流程标准化（建议 6 步）
- Plan：Codex 输出实施计划（文件级变更列表）
- Scaffold：先生成接口 / 类型 / 测试骨架
- Implement：分小步提交（每步可运行）
- Verify：单测、集成测试、lint、类型检查
- Explain：生成变更说明 + 风险点 + 使用示例
- Review Gate：人类审批后合并
5. 代码质量“硬门槛”（不可协商）
给 Codex 明确以下 gate，没过就不算完成：
- ✅
lint/format全绿 - ✅ 类型检查全绿（TS / pyright / mypy 等）
- ✅ 关键路径测试覆盖达标
- ✅ 无高危安全问题（注入、密钥泄漏、越权）
- ✅ 性能回归可解释（基线对比）
6. 提示词（Prompt）规范：固定结构，减少随机性
建议团队统一 Prompt 模板：
- 背景与目标
- 当前代码上下文
- 技术约束
- 输出格式（必须含：代码、测试、迁移、文档）
- 禁止事项（如“禁止修改公共接口”“禁止引入新依赖”）
- 验收命令（例如
npm test && npm run lint）
7. 文档与可追溯性
要求 Codex 每次变更同步输出：
CHANGELOG条目- ADR（重要架构决策记录）
- 接口文档更新
- 回滚指南
没有文档的 AI 代码，长期一定会变成维护负担。
8. 常见反模式（要避免）
- ❌ 让 Codex 一次性“重写整个模块”
- ❌ 没有测试就合并
- ❌ 只看“能跑”，不看边界条件和失败路径
- ❌ 让 AI 自行决定需求边界
- ❌ 不做 code review 就上线
9.可直接执行的团队规则（简版）
你可以把下面作为团队规范：
“所有 Codex 任务必须先有任务契约；所有生成代码必须附带测试与变更说明；所有高风险改动必须有人审；未通过质量 gate 禁止合并。”
如果你愿意，我可以进一步给你一份可直接粘贴到团队 Wiki 的《Vibe Coding + Codex 开发规范模板》（包含 Prompt 模板、PR 模板、验收清单）。