我的AI编程工作流不是让 AI 帮我写一段代码，而是让它围绕需求、原型、方案、任务、开发、测试、部署、日志和复盘持续运转。

需求判断 → 原型设计 → 技术方案 → 任务拆解 → 前后端开发 → 测试联调 → 代码审查 → 部署上线 → 日志排查 → 复盘沉淀

这不是一个“问一句答一句”的 AI 聊天窗口，而是一个后台开发助理。

它应该能：

每天自动检查项目 发现问题进入 inbox 没有问题自动归档 低风险问题生成修复建议 中高风险问题等待人工确认 PR 自动做风险审查 部署前自动生成检查清单 上线后自动看日志 每周自动生成复盘和技术债

这篇文章就完整拆一件事：

如何把 AI 编程能力放进一个有边界、有触发、有产物、有审批、有复盘的软件工程流水线里。

这不是“全自动开发”。

我的核心判断是：

AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。

AI 不应该直接接管项目，而应该进入有触发、有产物、有审批的流水线。

能自动化的是巡检、整理、初稿、检查和低风险修复；不能自动化的是方向判断、风险审批和上线责任。

真正有价值的 AI 工作流，不是让 AI 多写一点代码，而是让项目过程变得可追踪、可审查、可复盘。

一、先说清楚：这不是普通 AI 工具流

这套系统叫：

AI 项目交付流水线

它不是一个软件，也不是一个插件，而是一套项目组织方式。

项目自己有一套流水线 每个阶段有固定输入 每个阶段有固定产物 每个阶段有触发器 每个阶段有 Skill 每个阶段有风险等级 每个阶段有人工 Gate 每个阶段结束后能沉淀到下一轮

底层用：

Codex Automations Codex / Claude Code Agent Skills AGENTS.md MCP GitHub Actions GitHub PR Review 本地脚本 人工审批

Skill 可以把指令、资源和可选脚本打包成任务专用能力，让 Codex 更稳定地执行某类工作流。

编码Agent 会在开始工作前读取项目里的AGENTS.md，把这些指令作为项目上下文和行为规范。

MCP 定义为连接 AI 应用和外部系统的开放标准，可以让 AI 应用连接本地文件、数据库、搜索引擎、工具和工作流。 同时，MCP Tools 规范也明确建议为了安全和信任，应保留 human-in-the-loop，让用户能够拒绝工具调用，并清楚看到哪些工具暴露给模型。

这套系统的底层原则是：

能只读，就先只读。 能生成报告，就先生成报告。 能进入 inbox，就不要直接改生产。 能人工确认，就不要自动上线。

二、总架构：AI 项目交付流水线的 6 层

先看整体架构。

每一层负责的事情不一样。

普通 AI 编程工具流只停留在 Execution Layer。

这套流水线的重点是：每一次 AI 介入都必须有输入、有输出、有边界、有审批、有复盘。

三、Codex常用功能

1.插件安装

在Codex左上角插件处即可下载以上所有所需的MCP包括computer use，FIgma，Playwright，Github MCP等。

2.自动化工作流安排

在codex的左上角即可进行以上所有工作流的编排，可以自行选择执行时间、重复次数、模型调用和项目所在的工作数分支还是本地执行等。也可以直接将本文放进对话框中后续再进行根据自己的实际情况微调直接执行实现AI编程的工作流。

3.Plan模式

需求分析和分阶段任务的阶段建议使用Plan Mode模式，会给出项目的阶段方案和测试方案等，参考如下：

4.Goal模式

如果你有了具体的Plan想让Codex长时间往一个目标执行任务，你就可以使用Goal模式，他会长时间进行工作直到达到你的目标，参考图如下：

5.关于本文的前端原型图设计

具体可以使用文章提到过的product design和fronted design 以及结合Figma设计前端原型图，参考图如下：

四、先定义三类触发器

成熟的 AI 流水线不是要所有事情都自动化应该有三类触发器

这对应到 AI 项目流水线里，就是：

定时触发：让 AI 定期巡检 事件触发：让 AI 响应项目变化 手动触发：让 AI 处理高价值但需要人确认的节点

一句话：

自动化不是让 AI 自己做决定，而是让 AI 在合适的时间自动收集证据、生成初稿、发现风险，然后把需要人判断的东西推到我面前。

五、再定义五个风险等级

没有风险等级，AI 自动化迟早会失控。

我把任务分成五级：

这个表是整套流水线的安全底座。

每张任务卡都要写：

风险等级：L0 / L1 / L2 / L3 / L4 自动化等级：只读 / 仅生成草稿 / AI 可修改 / AI 可修改但必须审查 / 仅人工处理

比如：

README 更新：L1，draft_only 补单元测试：L2，ai_can_patch_with_review 新增登录接口：L3，ai_can_patch_with_review 修改生产 Nginx：L4，manual_only 数据库迁移：L4，manual_only

这就体现了第一条核心原则：

AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。

六、第一步：搭项目目录

先在项目根目录建这套结构。

project-root/ ├── AGENTS.md ├── .agents/ │ └── skills/ │ ├── 01-idea-review/ │ │ └── SKILL.md │ ├── 02-product-design/ │ │ └── SKILL.md │ ├── 03-tech-spec/ │ │ └── SKILL.md │ ├── 04-task-breakdown/ │ │ └── SKILL.md │ ├── 05-implementation/ │ │ └── SKILL.md │ ├── 06-test-triage/ │ │ └── SKILL.md │ ├── 07-review-gate/ │ │ └── SKILL.md │ ├── 08-deploy-readiness/ │ │ └── SKILL.md │ ├── 09-log-triage/ │ │ └── SKILL.md │ └── 10-postmortem/ │ └── SKILL.md ├── .github/ │ ├── workflows/ │ │ ├── ci.yml │ │ ├── codex-pr-review.yml │ │ └── release-check.yml │ └── codex/ │ └── prompts/ │ ├── pr-review.md │ ├── release-check.md │ ├── deploy-check.md │ └── weekly-review.md ├── ideas/ ├── docs/ ├── prototype/ ├── tasks/ ├── inbox/ ├── reports/ └── deploy/

这套目录是我为了让 AI 工作流可沉淀、可追踪、可复盘设计的项目结构。

核心目的只有一个：

不要让 AI 产物散落在聊天记录里。 所有东西必须落到文件系统。

需求审查进docs/idea-review/。

任务卡进tasks/。

自动巡检结果进inbox/。

部署检查进deploy/。

复盘进reports/。

这就是 Artifact Layer。

七、第二步：写 AGENTS.md，先给 AI 立规矩

没有AGENTS.md，AI 每次进项目都在猜。

先把项目技术栈、命令、风险边界、审批规则先写清楚。

# AGENTS.md ## 项目角色 你是这个项目的后台开发助理。 你可以协助完成： - 想法审查 - 产品原型 - 技术方案 - 任务拆解 - 低风险实现 - 测试联调 - 代码审查 - 部署前检查 - 日志排查 - 每周复盘 在没有人工批准之前，你不能做高风险决策。 ## 项目技术栈 后端： - Java 17 - Spring Boot 3 - MyBatis-Plus - MySQL - Redis 前端： - Vue 3 - TypeScript - Vite - Element Plus 部署： - Docker Compose - Nginx - HTTPS - Cloudflare 或反向代理 ## 常用命令 后端： bash mvn test mvn spring-boot:run 前端： cd frontend npm install npm run build npm run dev Docker： docker compose up -d --build docker compose ps docker compose logs -f backend ## 工作流规则 修改代码前： 1. 先阅读相关文档和文件。 2. 说明你的执行计划。 3. 列出你打算修改的文件。 4. 判断风险等级。 5. 如果任务属于中风险或高风险，必须等待人工确认。 修改代码后： 1. 总结修改了哪些文件。 2. 运行必要的测试。 3. 报告测试结果。 4. 说明剩余风险。 5. 未经过验证，不能声称任务完成。 ## 风险等级 L0：只读分析 - 读取文档 - 读取日志 - 读取 diff - 生成报告 L1：仅生成草稿 - 生成 PRD 初稿 - 生成任务卡 - 生成 README 初稿 - 生成周报 L2：低风险修改 - 文档更新 - 测试补充 - UI 文案调整 - 非生产脚本的小改动 L3：中高风险修改 - 新增 API 接口 - 认证相关逻辑 - 权限相关逻辑 - 数据库访问逻辑 - 业务模块重构 L4：生产高风险 - 生产部署 - 密钥 - 数据库迁移 - Nginx / Docker / CI 变更 - 支付 / 积分 / 扣费逻辑 - 安全策略变更 ## 硬性规则 - 不能提交密钥、API Key、密码、Token 或 `.env` 文件。 - 不能删除测试，除非得到明确批准。 - 不能削弱认证或权限控制。 - 不能擅自修改已经应用过的历史迁移文件。 - 不能把数据库、Redis、Docker API 或内部服务暴露到公网。 - 不能自动部署到生产环境。 - 不能修改生产数据。 - 如果不确定，必须先请求确认。 ## 代码审查关注点 审查变更时，重点关注： - 是否缺少测试 - 是否引入安全回退 - 是否绕过权限 - 是否记录了用户敏感信息 - 是否泄露密钥 - 是否出现 N+1 查询 - 是否存在数据库迁移风险 - 是否存在部署风险 - 是否修改了无关文件

这份文件是整个流水线的“施工规范”。

Codex、Claude Code 会读取AGENTS.md作为项目级指导，把里面的技术栈、命令、风险边界和 Review 规则带入后续任务。

八、第三步：写 10 个 Skill

Skill 的价值是把同类任务的经验固化下来。
注意：这里的路径不要写成skills/xxx/SKILL.md。
Codex 仓库级 Skill 默认应该放在：

.agents/skills/{skill-name}/SKILL.md

1. idea-review-skill(需求分析skill)

路径：

.agents/skills/01-idea-review/SKILL.md

内容：

--- name: idea-review-skill description: 在实现项目之前审查想法。用于判断真实痛点、目标用户、MVP 范围、风险和简历价值。 --- # 想法审查 Skill ## 目标 帮助判断一个想法是否值得进入开发流水线。 ## 输入 - 项目想法描述 - 目标用户 - 开发者背景 - 可投入时间 - 已有替代品，如果有的话 ## 输出 生成一份想法审查报告，包含： 1. 判断结果：执行 / 等待 / 放弃 2. 真实痛点 3. 目标用户 4. 现有替代品 5. MVP 范围 6. 7 天可行性 7. 技术风险 8. 产品风险 9. 简历价值 10. 前 7 天计划 ## 规则 - 不能自动创建开发任务。 - 不能修改源代码。 - 如果缺少证据，标记为“需要调研”。 - 审查要严格。如果想法模糊，优先给出“等待”或“放弃”。

2. product-design-skill（前端原型设计图skill）

路径：

.agents/skills/02-product-design/SKILL.md

内容：

--- name: product-design-skill description: 在前端编码之前，设计产品流程、页面结构、用户状态和交互逻辑。 --- # 产品设计 Skill ## 目标 不要直接生成前端代码。 先设计产品流程、信息结构和页面状态。 ## 输出 1. 用户目标 2. 核心用户流程 3. 页面列表 4. 页面信息结构 5. 核心组件 6. 加载 / 空状态 / 错误 / 成功状态 7. 表单校验规则 8. 危险操作和二次确认 9. 桌面端 / 移动端图片预览 10. 交给前端实现的说明 ## 规则 - 不要编造业务逻辑。 - 不清楚的需求标记为“待确认”。 - 每个页面都必须包含加载、空状态、错误和成功状态。 - 优先使用简单流程，不要一开始设计复杂页面。

3. tech-spec-skill（技术选型和后端架构skill)

路径：

.agents/skills/03-tech-spec/SKILL.md

内容：

--- name: tech-spec-skill description: 把已确认的 PRD 和原型转换成技术方案、接口设计、数据库草案、风险清单和任务边界。 --- # 技术方案 Skill ## 目标 在正式实现之前生成技术方案。 ## 输出 1. 模块设计 2. 后端包结构 3. 前端页面和组件结构 4. API 接口 5. 请求和响应结构 6. 数据库表和索引 7. 认证和权限边界 8. 错误处理 9. 日志和 traceId 10. 缓存策略 11. 限流策略 12. 测试策略 13. 部署影响 14. 风险清单 ## 规则 - 不能修改源代码。 - 不能创建数据库迁移文件。 - 不确定的决策标记为“需要人工确认”。

4. task-breakdown-skill(分阶段实现任务skill)

路径：

.agents/skills/04-task-breakdown/SKILL.md

内容：

--- name: task-breakdown-skill description: 把已确认的技术方案拆成可执行任务卡，包含范围、风险等级、自动化等级和验证命令。 --- # 任务拆解 Skill ## 目标 创建 AI 编码 Agent 可以安全执行的任务卡。 ## 每张任务卡必须包含 1. 任务目标 2. 任务范围 3. 允许修改的文件 4. 禁止修改的文件 5. 验收标准 6. 验证命令 7. 风险等级 8. 自动化等级 9. 人工 Gate ## 自动化等级 - 仅人工处理 - AI 辅助分析 - AI 可以修改 - AI 可以修改但必须审查 ## 规则 - 不能修改源代码。 - 每个任务必须足够小，方便审查。 - 高风险文件必须标记为“仅人工处理”或“AI 辅助分析”。

5. implementation-skill（每阶段开发、测试及验收skill)

路径：

.agents/skills/05-implementation/SKILL.md

内容：

--- name: implementation-skill description: 按已批准任务卡小步执行开发，并输出测试结果和变更摘要。 --- # 开发实现 Skill ## 目标 只实现 `tasks/ready/` 中已经批准的任务。 ## 工作流程 1. 读取 AGENTS.md。 2. 读取任务卡。 3. 读取相关文件。 4. 提出执行计划。 5. 判断风险等级。 6. 如有需要，等待人工确认。 7. 只修改允许修改的文件。 8. 运行验证命令。 9. 总结变更和风险。 ## 规则 - 不能从 backlog 中自行挑任务。 - 不能修改禁止修改的文件。 - 验证没有通过，不能把任务标记为完成。 - 不能自动修改生产配置。

6. test-triage-skill(测试和修复skill)

路径：

.agents/skills/06-test-triage/SKILL.md

内容：

--- name: test-triage-skill description: 运行或分析项目验证检查，并生成测试排查报告。 --- # 测试排查 Skill ## 目标 发现构建失败、测试失败和有风险的 TODO/FIXME 变更。 ## 检查项 1. 后端测试 2. 前端构建 3. Docker Compose 配置 4. 健康检查接口，如果有的话 5. TODO/FIXME 扫描 6. 最近变更文件是否缺少测试 ## 输出 - 状态：自动归档 / 需要查看 / 阻塞发布 / 需要人工处理 - 证据 - 疑似原因 - 最小下一步 - 建议负责人 ## 规则 - 除非明确批准，否则不能修改源代码。 - 如果全部通过，标记为“自动归档”。

7. review-gate-skill（代码合并前审查skill)

路径：

.agents/skills/07-review-gate/SKILL.md

内容：

--- name: review-gate-skill description: 审查 diff 和 PR，关注安全、正确性、测试、部署和无关改动。 --- # 代码审查门禁 Skill ## 目标 在合并前审查变更。 ## 重点关注 1. 安全回退 2. 认证 / 权限绕过 3. 密钥泄露 4. 用户敏感信息日志 5. 删除或削弱测试 6. 数据库迁移风险 7. 部署配置风险 8. 意外的无关改动 9. N+1 查询 10. 缺少错误处理 ## 审查结论 - 可以合并 - 需要继续审查 - 禁止合并 ## 规则 - 除非明确要求，否则不要重写代码。 - 优先关注 P0 / P1 高风险问题。 - 如果涉及部署、认证、数据库、密钥或 CI 变更，至少标记为“需要继续审查”。

8. deploy-readiness-skill(上线前部署skill)

路径：

.agents/skills/08-deploy-readiness/SKILL.md

内容：

--- name: deploy-readiness-skill description: 检查部署准备情况、回滚计划、冒烟测试、端口、密钥、日志和生产风险。 --- # 部署准备检查 Skill ## 目标 准备部署检查清单和回滚计划。不能自动部署。 ## 检查项 1. CI 结果 2. docker-compose.yml 3. Nginx 配置 4. .env.example 5. 暴露端口 6. 数据库迁移 7. 数据卷挂载 8. 日志 9. 备份策略 10. 回滚命令 11. 冒烟测试 12. 安全风险 ## 输出 - deploy-readiness.md - rollback-plan.md - smoke-test.md ## 规则 - 不能部署到生产环境。 - 不能打印密钥。 - 有风险的内容必须标记为“需要人工处理”。

9. log-triage-skill（日志排查skill)

路径：

.agents/skills/09-log-triage/SKILL.md

内容：

--- name: log-triage-skill description: 在部署后或定时任务中分析日志和健康信号。 --- # 日志排查 Skill ## 目标 从日志和健康检查中发现运行问题。 ## 检查项 1. 5xx 错误 2. Nginx 404 / 502 异常增长 3. 认证失败 4. AI 模型超时 5. JSON 解析失败 6. 限流错误 7. PDF 导出失败 8. 容器重启 9. 磁盘 / 内存告警 ## 输出 - 严重程度：信息 / 警告 / 错误 / 严重 - 证据 - 疑似原因 - 建议下一步 - 是否需要人工处理 ## 规则 - 默认只读。 - 不能删除日志。 - 不能修改生产配置。

10. postmortem-skill(复盘和沉淀skill)

路径：

.agents/skills/10-postmortem/SKILL.md

内容：

--- name: postmortem-skill description: 生成周报、发布复盘、技术债、简历表达和面试问题。 --- # 复盘沉淀 Skill ## 目标 把项目活动转化成可复用经验和下一步行动。 ## 输入 - tasks/done - inbox/test - inbox/review - inbox/deploy - inbox/logs - 已合并 PR - 本周提交记录 ## 输出 1. 本周交付了什么 2. 哪些地方失败了 3. 剩余风险 4. 技术债 5. 下周计划 6. AGENTS.md 更新建议 7. Skill 更新建议 8. 简历表达候选 9. 面试问题 10. 博客选题 ## 规则 - 不能修改源代码。 - 区分事实和建议。 - 不确定的结论标记为“需要复查”。

这 10 个 Skill 就是能力层。

九、第四步：写 10 个流水线节点

下面开始搭真正的流水线。

每个节点都要包含：

触发方式 输入 Skill AI 动作 输出 人工 Gate

节点 1：需求判断 Pipeline

目标：不让自己冲动开项目。

触发方式：

手动触发：新建 ideas/xxx.md 定时触发：每周扫描 ideas/

输入：

ideas/*.md

输出：

docs/idea-review/{idea-name}.md

自动化 Prompt：

使用 idea-review-skill。 扫描 ideas/ 目录。 对于每一个还没有在 docs/idea-review/ 里生成审查报告的想法，创建一份想法审查报告。 不能自动创建开发任务。 不能修改源代码。 每个想法都要输出： - 执行 / 等待 / 放弃 - 真实痛点 - 目标用户 - 现有替代品 - MVP 范围 - 7 天可行性 - 简历价值 - 技术风险 - 产品风险 如果没有新的想法，把本次运行标记为“自动归档”。

人工 Gate：

只有我把判断结果改成“执行”，才允许进入 PRD 阶段。

核心判断：

AI 是立项审计员，不是产品老板。

节点 2：原型设计 Pipeline

目标：先把产品流程想清楚，不让 AI 直接写前端。

触发方式：

手动触发

输入：

docs/PRD.md docs/AC.md

输出：

prototype/page-flow.md prototype/DESIGN.md prototype/wireframe.html

自动化 Prompt：

使用 product-design-skill。 读取 docs/PRD.md 和 docs/AC.md。 生成： - prototype/page-flow.md - prototype/information-architecture.md - prototype/states.md - prototype/DESIGN.md - prototype/wireframe.html 不能修改前端源代码。 如果可以使用 browser MCP： - 打开 prototype/wireframe.html。 - 检查主流程是否清晰可见。 - 检查加载、空状态、错误、成功状态是否完整。 - 报告页面布局问题。 最后输出检查清单： - 核心流程是否清晰？ - 所有状态是否覆盖？ - 哪些部分需要人工确认？

人工 Gate：

我确认原型后，才能进入技术方案阶段。

核心判断：

前端自动化不是先写 Vue，而是先生成产品结构和页面状态。

节点 3：技术方案 Pipeline

目标：把产品需求转成可开发的技术合同。

触发方式：

手动触发

输入：

docs/PRD.md docs/AC.md prototype/DESIGN.md 当前代码结构

输出：

docs/tech-spec.md docs/api-spec.md docs/db-schema-draft.sql docs/risk-checklist.md

自动化 Prompt：

使用 tech-spec-skill。 读取： - docs/PRD.md - docs/AC.md - prototype/DESIGN.md - 当前项目代码结构 生成： - docs/tech-spec.md - docs/api-spec.md - docs/db-schema-draft.sql - docs/risk-checklist.md 技术方案必须包含： 1. 模块设计 2. 后端包结构 3. 前端页面和组件结构 4. API 接口 5. 请求和响应结构 6. 数据库表和索引 7. 认证和权限边界 8. 错误处理 9. 日志和 traceId 10. 缓存策略 11. 限流策略 12. 测试策略 13. 部署影响 14. 风险清单 不能修改源代码。 不能创建数据库迁移文件。 所有不确定的决策都标记为“需要人工确认”。

人工 Gate：

未审批 tech-spec.md，不允许拆任务。

核心判断：

技术方案是 AI 开发前的边界合同。没有合同就开工，本质是让 AI 猜架构。

节点 4：任务拆解 Pipeline

目标：把技术方案拆成任务卡，并给每个任务标注风险等级。

触发方式：

手动触发 docs/tech-spec.md 变更后触发

输入：

docs/tech-spec.md docs/api-spec.md docs/risk-checklist.md

输出：

tasks/backlog/*.md

任务卡模板：

# 任务：001-login-api ## 目标 实现用户登录接口。 ## 范围 允许修改的文件： - backend/src/main/java/.../AuthController.java - backend/src/main/java/.../AuthService.java - backend/src/main/java/.../dto/LoginRequest.java - backend/src/main/java/.../vo/LoginResponse.java 禁止修改的文件： - docker-compose.yml - nginx.conf - 生产环境 .env - 已经应用过的历史迁移文件 ## 验收标准 - 正确账号密码返回 accessToken - 错误密码返回统一错误码 - 空字段返回参数校验错误 - 密码不明文存储 - 测试通过 ## 验证命令 ```bash mvn test ``` ## 风险等级 L3：中高风险修改 ## 自动化等级 AI 可以修改，但必须审查。 ## 人工 Gate 需要人工看 diff 后合并。

自动化 Prompt：

使用 task-breakdown-skill。 读取 docs/tech-spec.md、docs/api-spec.md、docs/risk-checklist.md。 在 tasks/backlog/ 下创建任务卡。 每张任务卡都必须包含： - 任务目标 - 任务范围 - 允许修改的文件 - 禁止修改的文件 - 验收标准 - 验证命令 - 风险等级 - 自动化等级 - 人工 Gate 不能修改源代码。

人工 Gate：

只有我把任务从 tasks/backlog 移到 tasks/ready，Codex 才能执行。

核心判断：

AI 不是自动抢任务，而是领取已批准的任务卡。

节点 5：前后端开发 Pipeline

目标：让 AI 小步执行，不接管整个项目。

触发方式：

任务被人工移动到 tasks/ready GitHub issue 加 codex-ready 标签

输入：

tasks/ready/*.md AGENTS.md 相关源码

输出：

branch / worktree diff test result tasks/done/{task}.md

自动化 Prompt：

先读取 AGENTS.md。 从 tasks/ready/ 中选择一个任务。 不要立刻开始写代码。 先输出： 1. 任务摘要 2. 需要读取的文件 3. 计划修改的文件 4. 风险等级 5. 验证命令 6. 是否需要人工确认 如果任务风险等级是 L3 或 L4，必须停止并等待确认。 如果已经批准： - 创建或使用独立 branch / worktree。 - 只修改任务卡允许修改的文件。 - 运行验证命令。 - 写出变更摘要。 - 只有测试通过，才能把任务移动到 tasks/done。

人工 Gate：

所有代码进入 main 前必须 PR。 L3 任务修改前必须确认。 L4 任务 AI 不允许自动执行。

核心判断：

AI 可以执行任务，但不能突破任务卡边界。

节点 6：测试联调 Pipeline

目标：让失败不再沉默。

触发方式：

每日定时 PR 更新 手动触发

输入：

源码 测试命令 构建命令 健康检查接口

输出：

inbox/test/test-report-{date}.md

自动化 Prompt：

使用 test-triage-skill。 运行项目验证检查清单： 1. 后端测试 2. 前端构建 3. Docker Compose 配置验证 4. 如果有健康检查接口，就检查健康接口 5. 扫描 TODO / FIXME 变更 把报告写入 inbox/test/test-report-{today}.md。 如果所有检查都通过： - 标记为“自动归档”。 如果任意检查失败： - 标记为“需要人工查看”。 - 解释失败原因。 - 给出最小修复建议。 - 除非明确批准，否则不能修改代码。

处理规则：

全部通过：自动归档 低风险失败：需要人工查看 影响部署：阻塞发布 涉及安全/数据库：需要人工处理

核心判断：

测试联调的自动化价值，不是让 AI 修所有 Bug，而是让失败不再沉默。

节点 7：代码审查 Pipeline

目标：AI 写的代码必须过 Review Gate。

触发方式：

pull_request opened pull_request synchronize @codex review

输入：

PR diff AGENTS.md review guidelines

输出：

PR review comment inbox/review/pr-{number}.md

Codex GitHub integration 支持在 PR 评论中使用@codex review请求审查，也可以开启 automatic reviews。Codex 会读取仓库里的AGENTS.mdreview guidance，并优先标出 P0/P1 高优先级风险。

PR Review Prompt：

# .github/codex/prompts/pr-review.md 你正在审查一个 Pull Request。 请先读取 AGENTS.md，并遵守其中的代码审查规范。 重点关注： 1. 是否引入安全回退 2. 是否绕过认证或权限 3. 是否泄露密钥 4. 是否记录用户敏感信息 5. 是否删除或削弱测试 6. 是否存在数据库迁移风险 7. 是否存在部署配置风险 8. 是否出现意外的无关改动 9. 是否引入 N+1 查询 10. 是否缺少错误处理 输出： - 结论：可以合并 / 需要继续审查 / 禁止合并 - P0 问题 - P1 问题 - P2 问题 - 必须修复项 - 需要人工确认的问题 除非明确要求，否则不要重写代码。

GitHub Action 示例：

name:Codex PR Reviewon:pull_request:types:[opened,synchronize,reopened]jobs:codex-review:runs-on:ubuntu-latestpermissions:contents:readpull-requests:writesteps:-uses:actions/checkout@v5with:ref:refs/pull/${{github.event.pull_request.number}}/mergefetch-depth:0persist-credentials:false-name:Run Codex Reviewuses:openai/codex-action@v1with:openai-api-key:${{secrets.OPENAI_API_KEY}}prompt-file:.github/codex/prompts/pr-review.mdoutput-file:codex-output.md

GitHub Actions workflow 可以通过pull_request等事件触发，适合把审查、测试、构建等流程接进 PR 生命周期。

人工 Gate：

禁止合并：不能合并 需要继续审查：必须处理 可以合并：仍需人工最终确认

核心判断：

代码审查不是整套系统的全部，它只是 AI 项目流水线里的风险门禁。

节点 8：部署上线 Pipeline

目标：AI 做 readiness，人做 deploy。

触发方式：

release 分支 tag 创建前 手动触发

输入：

CI 结果 docker-compose.yml nginx.conf .env.example migration

输出：

deploy/deploy-readiness.md deploy/rollback-plan.md deploy/smoke-test.md

自动化 Prompt：

使用 deployment-readiness-skill。 检查这个项目是否具备部署条件。 检查： 1. CI 结果 2. docker-compose.yml 3. Nginx 配置 4. .env.example 5. 暴露端口 6. 数据库迁移 7. 数据卷挂载 8. 日志 9. 备份策略 10. 回滚命令 11. 冒烟测试 12. 安全风险 生成： - deploy/deploy-readiness.md - deploy/rollback-plan.md - deploy/smoke-test.md 不能自动部署。 所有有风险的项目都必须标记为“需要人工处理”。

部署前清单：

[ ] 后端构建通过 [ ] 前端构建通过 [ ] Docker Compose 配置通过 [ ] 数据库迁移可回滚或已备份 [ ] Nginx 配置通过 nginx -t [ ] 80/443 暴露合理 [ ] MySQL / Redis 不暴露公网 [ ] .env.example 字段完整 [ ] 生产密钥未进入 Git [ ] 备份可用 [ ] rollback-plan.md 已生成 [ ] smoke-test.md 已生成

人工 Gate：

生产部署必须人工执行。 AI 只能生成检查清单和命令。

核心判断：

AI 可以帮我准备上线，但不能替我承担生产事故。

节点 9：日志排查 Pipeline

目标：上线后让 AI 值班。

触发方式：

每天 9 点 部署后 30 分钟 出现错误激增时

输入：

后端日志 Nginx 日志 AI 调用日志 Docker 日志 健康检查接口

输出：

inbox/logs/log-triage-{date}.md

自动化 Prompt：

使用 log-triage-skill。 分析最近 24 小时日志。 检查： - 5xx 错误 - Nginx 404 / 502 异常增长 - 认证失败 - AI 调用失败 - 模型超时 - JSON 解析失败 - PDF 导出失败 - 容器重启 - 磁盘 / 内存告警 输出： - 严重程度：信息 / 警告 / 错误 / 严重 - 主要发现 - 证据 - 疑似原因 - 建议下一步 - 是否需要人工处理 把报告写入 inbox/logs/log-triage-{today}.md。 不能修改生产配置。 不能删除日志。

处理规则：

信息：归档 警告：进入技术债 错误：进入 inbox 严重：人工处理

核心判断：

上线后，AI 不是继续写代码，而是开始值班。

节点 10：复盘沉淀 Pipeline

目标：把项目过程变成下一轮规则。

触发方式：

每周五 每次 release 后 每次 incident 后

输入：

tasks/done inbox/test inbox/review inbox/deploy inbox/logs merged PR weekly commits

输出：

reports/weekly/weekly-dev-review.md reports/release/release-postmortem.md reports/weekly/resume-bullets.md reports/weekly/interview-questions.md

自动化 Prompt：

使用 postmortem-skill。 生成每周开发复盘。 读取： - tasks/done/ - inbox/test/ - inbox/review/ - inbox/deploy/ - inbox/logs/ - 本周 git commits 输出： 1. 本周交付了什么 2. 哪些地方失败了 3. 还剩哪些风险 4. 下周应该修什么 5. AGENTS.md 哪些规则应该更新 6. 哪些 Skill 应该优化 7. 简历表达候选 8. 面试问题 9. 博客文章选题 不能修改源代码。

核心判断：

复盘不是写总结，而是把一次项目经验重新写进规则、Skill 和下一轮流水线。

十、第五步：配置 Codex Automations（自动化）

Automation 1：Daily Test Triage（24小时测试bug评审）

名称：

Daily Test Triage

频率：

每天 9:00

Prompt：

使用 test-triage-skill。 运行每日验证检查清单： 1. 检查 git status。 2. 如果最近修改了后端文件，运行后端测试。 3. 如果最近修改了前端文件，运行前端构建。 4. 如果修改了部署文件，检查 Docker Compose 配置。 5. 扫描最近 24 小时新增的 TODO / FIXME。 把报告写入 inbox/test/test-report-{today}.md。 如果所有检查通过，标记为“自动归档”。 如果有任何检查失败，标记为“需要人工查看”，并说明最小下一步。 不能修改源代码。

Automation 2：Daily Log Triage（24小时日志审计）

名称：

Daily Log Triage

频率：

每天 10:00

Prompt：

使用 log-triage-skill。 分析最近 24 小时日志。 检查： - 后端错误 - 认证失败 - AI 调用失败 - 模型超时 - JSON 解析失败 - PDF 导出失败 - 容器重启 - Nginx 502 / 404 异常增长 把报告写入 inbox/logs/log-triage-{today}.md。 如果没有明显问题，标记为“自动归档”。 如果存在警告或错误，生成一份简短行动清单。 不能修改生产配置。 不能删除日志。

Automation 3：Weekly Tech Debt Scan（7天技术债务扫描）

名称：

Weekly Tech Debt Scan

频率：

每周五 18:00

Prompt：

扫描项目技术债。 检查： 1. TODO / FIXME 2. 最近变更文件是否缺少测试 3. 文档是否过期 4. tasks/doing 中是否有长期未完成任务 5. 是否存在可疑重复代码 6. README 是否缺少关键部分 7. 部署文档是否和当前配置不一致 8. 风险项是否长期未解决 把报告写入 reports/weekly/tech-debt-{date}.md。 不能修改源代码。 只有当问题明确可执行时，才在 tasks/backlog/ 下创建任务建议。

Automation 4：Weekly Dev Review（7天开发复盘）

名称：

Weekly Dev Review

频率：

每周日 21:00

Prompt：

使用 postmortem-skill。 基于以下内容生成每周复盘： - tasks/done/ - inbox/test/ - inbox/review/ - inbox/deploy/ - inbox/logs/ - 本周 git commits 输出： - 本周交付了什么 - 哪些地方失败了 - 还剩哪些风险 - 下周要做什么 - AGENTS.md 哪些规则应该更新 - 哪些 Skill 应该优化 - 简历表达候选 - 面试问题 - 博客文章选题 写入 reports/weekly/weekly-dev-review-{date}.md。

这 4 个自动化已经能覆盖：

项目有没有坏 PR 能不能合 上线有没有风险 经验有没有沉淀

不要一上来配置 20 个 automation。

自动化越多，越需要治理。先把 MVP 跑通。

十一、第六步：MCP 权限怎么控制

建议安装的 MCP

不要一上来就给 AI：

生产数据库写权限 服务器 root 权限 删除文件权限 部署生产权限 密钥读取权限

应该写清楚边界：

MCP 第一版只读优先。 任何写操作都必须人工确认。 生产环境默认不允许 AI 直连写入。 数据库、密钥、部署、删除、迁移必须标记为仅人工处理。

MCP 的价值不是让 AI 权限更大，而是让 AI 在受控边界内拿到更真实的上下文。有了边界，MCP 才能真正把编码Agent从“写代码工具”变成“后台开发助理”。

最后验收：

真实可用验收清单

搭完以后，不要只看目录有没有创建，要检查是否真的能识别和运行。

[ ] Skill 是否放在 .agents/skills/ 下 [ ] 每个 Skill 是否都有 SKILL.md [ ] 每个 SKILL.md 是否有 name 和 description [ ] 在 Codex 输入 $ 时，是否能看到对应 Skill [ ] Automation Prompt 是否显式使用 $skill-name [ ] Automation 是否选择了正确项目 [ ] Git 仓库里的 Automation 是否优先使用 worktree 隔离 [ ] inbox/ 是否能收到自动化结果 [ ] GitHub PR Review 是使用 @codex review，还是 GitHub Action，二者是否讲清楚 [ ] GitHub Action 是否配置 OPENAI_API_KEY [ ] AGENTS.md 是否写了 Review guidelines [ ] MCP 是否只开放必要权限 [ ] 部署、数据库、密钥、删除操作是否明确标记 manual_only

十二、这套流程怎么写进简历？

不要只写：

熟练使用 Codex / Claude Code / Cursor 辅助开发。

可以写成：

设计并实践 AI 项目交付流水线，基于 Codex Automations、AGENTS.md、Agent Skills、MCP 和 GitHub PR Review，将测试巡检、PR 风险审查、部署前检查、日志排查和复盘沉淀等环节结构化为可触发、可追踪、可审批的工程流程。通过 AI Dev Inbox 统一收口自动化发现的问题，并按“自动归档 / 需要人工查看 / 创建任务 / 需要人工处理”分流，降低 AI 编程中的无序修改、重复排查和上线风险。

如果面试官问：

这不就是会用 AI 工具吗？

可以这样回答：

不是。我做的不是单点 AI 编程，而是把 AI 能力放进软件工程流水线。每个阶段都有输入、触发器、产物、风险等级和人工 Gate。比如测试巡检可以定时触发，PR 审查可以事件触发，部署检查必须人工确认，日志排查会进入 inbox，复盘会反向更新 AGENTS.md 和 Skill。AI 负责重复检查、初稿生成和低风险执行，人负责方向判断、审批和上线结果。

这就不是“会用工具”，这是“会设计 AI 工程流程”。

十三、总结：AI 工作流真正值钱的地方

如果只会让 AI 写代码，门槛会越来越低。

真正有价值的是你能不能回答这些问题：

AI 在什么时候介入？ 它读什么上下文？ 它调用什么工具？ 它输出什么产物？ 它能不能改代码？ 它能改哪些文件？ 它改完怎么验证？ 它什么时候必须停下来等人？ 它的发现进入哪里？ 它的经验怎么沉淀到下一轮？

这就是我理解的 AI 工作流一体化。

不是让 AI 替我从 0 到 1 做完项目。

而是把 AI 放进一个有边界、有触发、有产物、有审批、有复盘的软件工程流水线里。

最后再重复这 4 句话：

AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。

AI 不应该直接接管项目，而应该进入有触发、有产物、有审批的流水线。

能自动化的是巡检、整理、初稿、检查和低风险修复；不能自动化的是方向判断、风险审批和上线责任。

真正有价值的 AI 工作流，不是让 AI 多写一点代码，而是让项目过程变得可追踪、可审查、可复盘。

这就是我这套 AI 项目交付流水线真正的价值。

我是Ryan，记录真实的AI应用工程，下一篇文章分享我用Codex从需求分析到完整构建项目的全流程经验。
个人技术博客：博客
GitHub：RyanCoreAI
上线项目体验：简喵
部署上线和域名绑定全流程：blog
AI 应用生产级护栏实战：blog
简喵AI链路体验：blog
跨境电商客服项目(进行中）：OmniMerchant