Agentic SDLC · 工作流状态机

AI Agent 开发工作流

一份「人机双读」规范:飞飞看得懂,Codex / Claude Code 也能当执行契约照着跑。

你问它该叫啥 —— 三个词分清楚:
· 整套开发方式叫 Agentic SDLC 智能体软件开发生命周期
· 给 Agent 读的规范文件,业界标准文件名就叫 AGENTS.md(Codex/Claude/Cursor 都认它)
· 给人看的这张图叫 工作流状态机 / 流程图(workflow state machine)—— 不是"进度图"

01  核心心法 · 哑铃结构

左端 · 出方案

最强模型设计

Fable 5 出方案初版 → GPT-5.6 Sol 纠错定稿。越大的方案越吃模型智力。

Agent
挂机执行
右端 · 保质量

严格测试 + 四端同步

测试 / CI / 上线验收 + 洁癖.skill 让代码·文档·规则·记忆四端统一。

写代码已经不是瓶颈了。钱和精力砸在 两头 ——出好方案 + 建好测试;中间执行交给 Agent 挂机跑。

02  完整流程 · 18 步状态机

A · 设计阶段(哑铃左端)
1
需求 INTENT飞飞
语音口述需求,不用整理,把意图说清楚就行。
2
出方案初版Fable 5
把需求丢给它出方案,约 20 分钟出稿。
⚠ Claude 爱丢细节,只能当初版
3
纠错定稿GPT-5.6 Sol · 极高
复制"需求+方案v0"过去,说"这是隔壁同事做的,详细审查一下"。常能挑出隔离/耦合的严重问题。
✓ 严重问题清零 → 最终方案 v1
B · 执行阶段(Codex 目标模式挂机)
4
启动目标模式Codex
左下角加号→目标模式,一句话目标即可,然后去睡觉。(小任务别开目标模式,直接按流程跑)
5
理解并核实Agent
复述+核实,确认无歧义。
6
建隔离环境Agent
新建独立分支 + 工作区,跟主线隔离,改坏也不影响正式代码。
7
开发修改Agent
按最终方案 v1 写代码。
C · 验证与上线
8
自动测试 VERIFYAgent + CI
跑测试,必要时回测或检查页面。
✓ 全绿放行;红灯 → 回第 7 步修复
9
推分支 + 建 PRAgent
把通过测试的分支提交"改动申请单"。
10
CI 自动验收GitHub 托管机器
质检流水线把全套测试再跑一遍。
✓ 绿灯才放行
11
合并主线Agent
并进 main 正式代码。
12
部署上线 RELEASEAgent
推到真实服务器,用户能用了。
13
查线上效果 MONITORAgent
自己去尝一口真实出品,确认符合预期。
D · 收尾(含人工确认)
14
四端同步 DOCS洁癖.skill
代码 · 文档 · 规则 · 记忆 四端统一 + 复盘经验。
15
汇报Agent → 飞飞
把全流程结果报给你。
16
确认飞飞
你点头 OK / 或打回。
17
清理Agent
删分支 / 工作区 / 临时数据库,环境归零。
18
结束 / 迭代
任务归档,进入下一轮。
并行度:可同时挂 6~7 个任务——这是人脑确认的极限,超了你自己就成了瓶颈。

03  我的 stack · 18 步工具映射

每一步对号入座:用你现有的哪个 skill/工具,缺不缺,是自动还是手动。
✅ 有 · ⚠ 有但半手动,该自动化 · ❌ 缺 · ➖ 该保留手动

#步骤你的工具 / skill状态
1需求你口述(Hermes / TG 输入)➖ 手动
2出方案初版brainstorming + writing-plans + codebase-design(或直接让强模型出)✅ 有
3纠错定稿codex-cross-review(Codex / GPT 复核)✅ 有
4启动执行goal =目标模式✅ 有
5理解核实Agent 默认行为(brainstorming 可兜)✅ 内建
6建隔离环境using-git-worktrees✅ 有
7开发修改test-driven-development / executing-plans✅ 有
8自动测试/verify + verification-before-completion + TDD⚠ 常手动跑
9推分支 + PRfinishing-a-development-branch + requesting-code-review✅ 有
10CI 自动验收GitHub-hosted runner(已有多项目运行)⚠ 待全套标准化
11合并主线git(finishing-a-development-branch✅ 有
12部署上线/run + 你的 wrangler 部署⚠ 半手动
13查线上效果/verify + webapp-testing + screenshot✅ 有
14四端同步neat-freak(洁癖)✅ 有
15汇报Hermes / TG 推送✅ 有
16确认你拍板➖ 手动
17清理finishing-a-development-branch✅ 有
18结束 / 迭代session-closure(可选)✅ 有
当前主缺口 第 10 步 · CI 自动验收——多个项目已有 GitHub Actions,当前缺口是把跨项目 Gate 标准化并补齐尚未接入的项目。此前默认目标是自建 CI / Spark。 Spark 只为未来确实需要本地模型或大算力的评测保留 Hybrid 选项。第 8、12 步(测试、部署)仍有半手动环节,是自动化的两个重点。其余 14 步你都有现成 skill,够用。
需要换的?其实不用换 被点名"过时"的 executing-plans / subagent-driven-development 不是过时,是可选:大任务用 goal 目标模式替代更省心,小任务才用它们。留着,按任务大小挑。

04  前置投入 · 这套能跑起来的地基

01

先建测试流程

前期把大量 token 砸这。覆盖率做到舒服区间,Agent 才敢在你睡觉时放手写。

02

GitHub 托管 CI

已有项目继续用 GitHub-hosted runner;下一步统一 Gate 并补齐缺项。原计划普通 CI 默认自建 / 不用 GitHub Runner。 只有未来真吃本地模型或大算力的评测,才按需路由到 Spark。

03

四端同步机制

每个任务收尾自动同步四端。你这边对应 neat-freak(洁癖)skill。

05  费曼解读 · 这些"测试"到底是啥

把整个开发想成 一家餐厅出一道新菜,你就全懂了:

独立分支 / 工作区branch / worktree

给新菜单独开个小灶试做,不动正在营业的大厨房。做砸了也不影响客人。

自动测试 / 单元测试unit test

提前写好的一堆"小尝味勺"。菜一改,自动一勺勺尝过去,看咸淡对不对、有没有把别的料弄洒——不用人工每次全尝一遍

测试覆盖率test coverage

这道菜有多少比例被"尝味勺"盯着。覆盖率高=大部分地方改坏了立刻被抓;低=很多地方没勺子,坏了没人知道。

回测 / 回归测试regression test

专门确认"以前做得好的老菜,现在还是那个味"。防止你改新菜时手一抖,把隔壁招牌菜的配方也动了。

检查页面 / 端到端E2E test

尝味勺尝不出"摆盘好不好看",所以真去点一下页面、走一遍完整流程看效果。

PR · 改动申请单Pull Request

新菜做好,写张"申请上正式菜单"的单子,先送审、别直接端给客人。

CI · 持续集成Continuous Integration

一条自动质检流水线。申请单一交,自动把所有尝味勺+老菜回测全跑一遍,全绿才亮灯放行。普通测试跑 GitHub-hosted runner;原先设想专门跑一台自建服务器。 Spark 只在未来真需要本地模型或大算力评测时接入。

合并主线 / 部署上线merge / deploy

质检亮绿 → 新菜写进主菜单(合并);菜单印出来摆到每张桌上,客人真能点(上线)。

目标模式goal mode

你只告诉厨师"把这桌菜做到完美再端上来,中间别烦我",厨师不达标不停手。你去睡觉,起床收菜。

测试就是让机器替你反复尝味、反复回头检查老菜——这样 Agent 才敢在你睡觉时放手改代码,因为改坏了流水线会亮红灯自动打回,坏东西上不了线。

飞飞 · AI Agent 开发工作流人类可读派生视图 · 唯一 operational SSOT:dev-flow/references/workflow.md