365五步法（Codex 版）：给非技术用户的轻量开发治理层

问题：我想用 Codex 开发，但我不想读代码

很多业务负责人有一个真实的困境：他们清楚自己要什么，也能判断结果对不对，但中间那段「Codex 怎么写、怎么测、怎么提交」完全是黑箱。要么全程放手，要么每一步都要问——两种极端都跑不顺。

365五步法（Codex 版）的定位很清楚：作为 Codex 外层的轻量业务治理，不是第二套开发流程。 Codex 原生能做的规划、编码、调试、审查、测试、Git 交付，全部交给 Codex 自己；这个技能只管「业务上什么该批、什么该验、什么时候该停」。

目标胶囊：一次对齐，全程有效

从一个请求出发，自动推导或确认五个字段：

• Business outcome（业务结果）
• Requested delivery level（交付边界：local / commit / push / PR / merge / deploy）
• Exact protected target and effect（受保护的目标和实际效果）
• Acceptance evidence（验收证据）
• Stopping condition（停止条件）

用户已经明确说了动作、目标和业务结果，就等于形成了「目标级授权」。同目标的预检、技术修复、安全回滚、传播监控和串行继续，不重复询问。只有目标、范围、实际后果或权限边界实质变化时才重新确认。

A/B/C 风险分级：按真实影响，不是按领域名词

关键原则：数据库代码、迁移文件、权限实现、支付流程代码、提交本身，不等于 C 级。要看是否真的触及在线效果或尚未解决的业务风险。

五步执行：Research → Plan → Implement → Review → Verify

1. Research — 读最近的 AGENTS.md、相关源码、测试和最小必要运行手册；建立当前行为、影响人群、最小一致变更、已知事实、假设和未解决的业务决策。
2. Plan — 目标胶囊足够时直接当计划用；只有 outcome、scope、acceptance、rollback 或多里程碑归属仍有实质分歧时，才读取需求简报。
3. Implement — 交给 Codex 和当前项目最具体的专业技能；复用现有契约、增量验证、避免无关清理、保持当前任务隔离可归因。
4. Review — 对照业务结果审 diff：需求覆盖、意外行为、范围膨胀、数据/权限/隐私/兼容性风险、失败路径、回滚、证据缺口、交付完整性。
5. Verify — 每个重要业务结果映射到观察证据；区分 passed、failed、not verified。优先真实受影响流程，而不是实现声明。

已就绪的受保护执行

当目标胶囊已经命名了受保护动作、准确目标和结果，且项目提供了已审源码、受保护操作员、回滚和回读时：

• 跑一次完整预检（绑定目标、审过源码、凭据边界、回滚、验收证据）
• 消费当前目标授权，不加等价的二次审批
• 执行一次串行受保护尝试
• 回读目标并关闭成功，或执行固定安全回滚并报告终端结果

不盲目重试，不并发执行受保护变更。

安装方式

bash git clone https://github.com/laojin1900/365Skill.git ./install.sh 365-five-step-dev-codex

仓库链接：github.com/laojin1900/365Skill/tree/main/skills/365-five-step-dev-codex