一个功能从立项到交付的端到端链路。AGENTS.md 有 always-on 骨架;本页给详细判据、实例与配套更新规则。
当前主干只覆盖游戏自动化功能(已验证场景:OpenAndEnterGame);但 §4 提 PR 的两仓协同适用所有涉及测试仓改动的开发(backend / 重构 / UI / 模型等只要动了测试仓代码都走这套,不限游戏自动化)。bug 修复 / 性能 / UI / 模型等其他类型见文末「其他类型」,后续补。
流程主干采用团队共识的 superpowers(brainstorming → writing-plans → TDD → review → finishing-a-branch);本页只讲本项目在各阶段要插入的项目特定动作。
以 OpenAndEnterGame(打开并登录游戏) 为实例。
触发:新增或改变游戏画面、可交互元素时(纯逻辑 / 算法 / 配置改动不用)。按 zzz-od-dev-screen-onboarding skill:
- 截图 →
analyze_screen客观识别(匹配画面 / area / 全量 OCR)。 - 主观理解 → 建画面文档
docs/game/screens/<screen>.md(子态 / 特征 / 可交互元素 / 识别快照)。 - 缺口分析 → 主动建模图形 / 图标按钮(模板 / CV),经 CRUD 工具入 screen_info。
- 归档代表截图到测试仓
screens/<screen>/<state>.webp(测试 fixture + 文档溯源)。
OpenAndEnterGame 实例:登录各子态(ready / 登录服务器中 / 登录成功 / 加载画面 / 大世界)逐一建档 + 建模(含图形按钮如登录页 ◀ 后退)+ 归档 webp。
做成 Application(放 src/zzz_od/application/,经 ApplicationFactory 接入)+ Operation 节点编排 flow;复用现有配置体系(YAML / YamlConfig)与界面(setting card / YamlConfigAdapter)。架构细则见 AGENTS.md「功能开发优先路径」。
OpenAndEnterGame 实例:
OpenAndEnterGame是一个编排OpenGame+EnterGame的 Operation(被 app 调用进入游戏);OpenGame负责启动游戏进程(及相关系统设置),EnterGame负责屏幕驱动,详见 zzz/enter_game.md。
用留档截图在测试仓补流程测试(多帧 / 轮询 / 重试 / 恢复分支)用 FixtureController(MockController 子类);单节点识别用简单 mock。规范见 testing/。
OpenAndEnterGame 实例:
test_enter_game_flow.py用FixtureController跑EnterGame自动登录全流程(ready → 点进入 → 登录服务器中 → 登录成功 → 加载 → 大世界)。
本步两仓协同适用所有涉及测试仓改动的开发,不限游戏自动化功能。下文以游戏自动化为例,但「同分支 / 配对提交 / 关联 PR / 合并顺序」对 backend / 重构 / UI / 模型等任何动测试仓的改动同样强制(非游戏流程改动也常漏开测试仓 PR,见 AGENTS.md「提交流程与协作边界」)。
跨仓 PR 顺序:先建测试仓 PR,再建主仓 PR:
- 测试仓改动先提交、推送、开 PR(
git -C zzz-od-test),拿到测试仓 PR 链接。 - 主仓开 PR,描述里带上测试仓 PR 链接(reviewer 可跳转看测试改动);主仓与测试仓用同分支名(CI 按分支名 clone 测试仓)。
- assign DoctorReid / ShadowLemoon,按
zzz-od-dev-pr-finishingskill 走 review(逐条回复 / 修正、清 unresolved thread、处理 CodeRabbit);关联 PR 一起收尾、合并顺序(测试仓先)见该 skill §6。
想让 PR 合并前进入
test分支给人试用:为 PR 添加test-branch标签,或手动触发 Update Test Branch 并填写 PR 列表。
| 产出 | 何时做 | 在哪 |
|---|---|---|
| 开发文档 | 代码 / 架构变化 → 总要 | docs/develop/ |
| 游戏知识库 | 画面 / 玩法变化 | docs/game/(画面建档时同步) |
| 模型 | 涉及 YOLO 检测 | yolo 训练仓 + dataset(见 相关仓库) |
| 使用说明(blog) | 用户可见的功能 / 操作变化(新功能、改用法、GUI 变化) | blog 仓;纯内部重构 / 性能 / 无感 bug → 不用 |
尚无足够实例,流程待补;不提前臆造。已知方向:
- bug 修复:
systematic-debugging(定位)→zzz-od-dev-deciding-a-fix(定修法)→ 改 → 回归测试 → PR。 - 性能优化:定位瓶颈 → 改 → benchmark 验证 → PR。(待实例)
- UI / GUI:复用 Fluent widgets / setting card → 视觉 / 交互验证 → PR。(待实例)
- 模型 / 识别:跨 yolo / dataset 仓训练 → release → 主仓消费。(待实例)