Skip to content

Commit 93f71d9

Browse files
CanYouTeachMeHowToCodeclaude
CanYouTeachMeHowToCode
and
claude
committed
Mark V4 Milestone 1 done and add its results
The owner confirmed on 2026-10-16 that V4 M1, the failure attribution prototype, is done. - research/failure_attribution/results.md (in Chinese, for the owner) covers what was delivered and the seven owner-checked recordings, with the results: - all 141 HUD failure events correct, none missed; - on recordings never used for tuning, the move behind a failure is the top candidate in 36 of 41 failures (88%) and in the top three in 38 (93%). It also lists the method, the owner's rules, the limits, and the next step. - The plan is marked done. - ROADMAP.md and ROADMAP.zh-CN.md mark M1 done, with a Delivered list. - CLAUDE.md sections 3 and 53 now name V4 Milestone 2, reliability validation, as current. The code is on feature/failure-attribution, waiting for its merge into dev. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 parent 52d96aa commit 93f71d9

5 files changed

Lines changed: 101 additions & 5 deletions

File tree

‎CLAUDE.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -156,7 +156,7 @@ V4 answers:
156156

157157
> **What happened during the fight without requiring the player to manually enter everything?**
158158
159-
Start with V4 Milestone 1: the failure attribution prototype on local Genichiro recordings (section 38). The V3.1 research in `research/ground_truth/` is its input: the owner-approved move catalog, the AI chains, and the dev-menu recordings, which double as labelled reference data.
159+
V4 Milestone 1, the failure attribution prototype on local Genichiro recordings, is done (owner confirmed, 2026-10-16). Its code and tools are in `research/failure_attribution/`, its results in `research/failure_attribution/results.md`: an owner-checked answer set of 7 castle recordings, all HUD failure events correct, and the move behind a failure the top candidate in 88% and among the top three in 93% of the failures in recordings never used for tuning. Current: V4 Milestone 2, reliability validation on more independent recordings (section 38). The V3.1 research in `research/ground_truth/` remains the input: the owner-approved move catalog, the AI chains, and the dev-menu recordings, which double as labelled reference data.
160160

161161
**Numbering.** The combat ground-truth stage was first planned as V4. It mainly added a research foundation and a Genichiro content update to the V3 product, so it became V3.1 and shipped as `v3.1.0` (owner decision, 2026-10-15). The later stages moved down by one: automated gameplay analysis is V4 and the multi-game platform V5. Commits, PR #23 and research notes written before that date use the old names.
162162

@@ -1646,8 +1646,8 @@ Examples currently not justified by default:
16461646
V3 and V3.1 are released. V4 order (section 38):
16471647

16481648
```text
1649-
1. Failure attribution prototype on local recordings (V4 Milestone 1) — current
1650-
2. Reliability validation on independent recordings (V4 Milestone 2)
1649+
1. Failure attribution prototype on local recordings (V4 Milestone 1) — done (2026-10-16)
1650+
2. Reliability validation on independent recordings (V4 Milestone 2) — current
16511651
3. Video upload and failure report (V4 Milestone 3)
16521652
4. Public deployment (V4 Milestone 4)
16531653
```

‎ROADMAP.md‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -888,7 +888,7 @@ Practice Suggestions
888888

889889
---
890890

891-
## V4 Milestone 1 — Failure Attribution Prototype
891+
## V4 Milestone 1 — Failure Attribution Prototype ✅
892892

893893
The first V4 goal is narrow: in the player's own recordings, find each failure and the boss move that caused it.
894894

@@ -916,6 +916,14 @@ Recordings made for V3.1 carry the dev-menu animation labels, so they double as
916916

917917
Output: one recording → one failure report a person can check.
918918

919+
Delivered (owner confirmed, 2026-10-16; `research/failure_attribution/results.md`):
920+
921+
- one command per recording: HUD events (damage, posture break, death by the death screen, Wolf's deathblow, resurrection), boss tracking by the lock-on dot, the moves behind the failures, merged by the owner's rules
922+
- a local review page: events, the three candidate moves per failure, merging, failures per move, processing progress
923+
- dev-menu recordings read into observations with one command, checked against the AI chains, and used as answers and as the reference library
924+
- an owner-checked answer set of 7 castle recordings: 141 events, 82 failures
925+
- all 141 events correct with none missed; on recordings never used for tuning, the move behind a failure is the top candidate in 36 of 41 (88%) and among the top three in 38 of 41 (93%)
926+
919927
---
920928

921929
## V4 Milestone 2 — Reliability Validation

‎ROADMAP.zh-CN.md‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -884,7 +884,7 @@ V4 利用 V3.1 的真实数据目录，减少甚至取消手动记录尝试。
884884

885885
---
886886

887-
## V4 Milestone 1 — 失败归因原型
887+
## V4 Milestone 1 — 失败归因原型 ✅
888888

889889
V4 的第一个目标很窄：在玩家自己的录像里，找出每一次失败，以及导致失败的 Boss 招式。
890890

@@ -910,6 +910,14 @@ V4 的第一个目标很窄：在玩家自己的录像里，找出每一次失
910910

911911
V3.1 录的录像带有开发者菜单的动画标签，所以同时也是带标注的参考数据。训练或评估时要把编号区域遮掉，避免模型直接读编号。
912912

913+
已交付（项目负责人在 2026-10-16 确认；`research/failure_attribution/results.md`）：
914+
915+
- 每段录像一条命令：从界面读出失败事件（扣血、被打崩、以"死"字为准的死亡、狼的忍杀、回生），用锁定点跟踪 Boss，按项目负责人的规则合并，并给每次失败配上招式
916+
- 本地核对页面：事件、每次失败的三个候选招式、合并、按招式统计失败次数、处理进度
917+
- 开发者菜单录像一条命令读入 observations，用 AI 链核对，同时作为答案和参考库
918+
- 项目负责人核对过的答案集：7 段天守阁录像，141 个事件、82 次失败
919+
- 141 个事件全部正确、没有漏检；在从没用来调参数的录像上，失败的招式第一候选正确 36/41（88%），前三里有正确答案 38/41（93%）
920+
913921
产出：一段录像对应一份可以人工核对的失败报告。
914922

915923
---

‎research/failure_attribution/plan.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,7 @@
11
# V4 M1 计划：本地录像的失败归因原型
22

3+
**状态：已完成**（你在 2026-10-16 确认）。结果见 [`results.md`](results.md)。
4+
35
范围：原版 1.06，天守阁苇名弦一郎三个阶段（和 `v3.1.0` 一致）。路线图见 `ROADMAP.zh-CN.md` 的 V4 Milestone 1，CLAUDE.md 第 37–38 节。
46

57
## 做完是什么样子

‎research/failure_attribution/results.md‎

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
# V4 M1 结果：本地录像的失败归因原型
2+
3+
**状态：已完成**（项目负责人在 2026-10-16 确认）。计划和你定的规则见 [`plan.md`](plan.md)，脚本清单见 [`README.md`](README.md)。范围是原版 1.06、天守阁苇名弦一郎三个阶段，2560×1440 录像。
4+
5+
## 交付了什么
6+
7+
- **一条命令出失败报告**：`scripts/hud_pipeline.py <录像>` 读 HUD，找出扣血、被打崩、死亡、狼的忍杀和回生，跟踪 Boss，再给每次失败配上招式。开发者菜单录像的答案直接来自叠加层，其他录像给出前三个候选，同一次出招的几下自动合并成一次失败。
8+
- **核对页面**：`scripts/review_events.py`，在 Chrome 或 Edge 里打开 http://127.0.0.1:8770。
9+
- "事件"视图：逐条核对检测到的事件，补漏检。
10+
- "招式"视图：点候选按钮确认招式，可以把被拆开的两次失败合并；右边按招式统计失败次数，这就是失败报告。
11+
- `/progress`：处理进度。
12+
- **新的开发者菜单录像**：`scripts/overlay_run.py` 一条命令读出叠加层的动画编号，导出到 `research/ground_truth/observations/`，用 AI 链核对动作衔接（衔接不上的地方就是可能读错的地方），再生成招式答案。读出的录像同时扩充认招式的参考库。
13+
- **答案集**：7 段录像的每个事件、每次失败的招式都经你核对，存在 `research/ground_truth/annotations/vanilla/genichiro/`。
14+
15+
## 用到的录像
16+
17+
| 录像 | 类型 | 时长 | 事件 | 失败 | 结果 |
18+
|---|---|---|---|---|---|
19+
| 2026-10-09-castle | 开发者菜单（V3.1） | 412 s | 35 | 21 | 三阶段战死 |
20+
| 2026-10-13-castle | 开发者菜单（V3.1） | 450 s | 29 | 20 | 赢 |
21+
| 2026-10-16-castle-1 | 无菜单测试 | 273 s | 18 | 9 | 赢 |
22+
| 2026-10-16-castle-2 | 无菜单测试 | 299 s | 21 | 13 | 赢 |
23+
| 2026-10-16-castle-3 | 无菜单测试 | 235 s | 12 | 5 | 赢 |
24+
| 2026-10-16-castle-4 | 开发者菜单 | 378 s | 12 | 7 | 赢 |
25+
| 2026-10-16-castle-5 | 开发者菜单 | 268 s | 14 | 7 | 赢 |
26+
| 合计 | | 39 分钟 | 141 | 82 | |
27+
28+
"事件"包括扣血、被打崩、死亡、回生和忍杀；"失败"是按你的规则合并之后的次数。
29+
30+
## 结果
31+
32+
**失败事件检测**：141 个事件你全部核对为正确，没有漏检。检测规则是边看测试录像 1、2 的问题边改的；没参与修改的测试录像 3 和第 4、5 段（38 个事件）也全对。
33+
34+
**认招式**，只算参数从没在上面调过的录像，参考库是开发者菜单录像：
35+
36+
| 录像 | 第一候选正确 | 正确答案在前三 |
37+
|---|---|---|
38+
| 测试录像 1 | 9/9 | 9/9 |
39+
| 测试录像 2 | 12/13 | 13/13 |
40+
| 测试录像 3 | 3/5 | 3/5 |
41+
| 第 4 段（只用别的录像做参考） | 6/7 | 6/7 |
42+
| 第 5 段（只用别的录像做参考） | 6/7 | 7/7 |
43+
| **合计** | **36/41（88%）** | **38/41（93%）** |
44+
45+
第 1、2 段（参数在上面调过，所以偏乐观）：只用别的录像做参考时，第一候选 35/40、前三 37/40。
46+
47+
**合并**：自动把同一次出招的几下合成一次失败，你一次都没需要手动合并。
48+
49+
## 方法要点
50+
51+
- **HUD 在不在**：看狼血条右端的灰色端盖。空血槽是半透明的，残血时的红色暗角和闪光会骗过颜色判断，端盖不会。
52+
- **扣血**：从挨打前的稳定血量算起（闪光和樱花会让读数瞬间往上跳）；画面淡出黑屏时 Boss 血条也一起变暗，不算挨打。
53+
- **死亡**：以画面中央的"死"字为准。血量读到 0 不一定是死：一击可能留下读不出来的一丝血。
54+
- **被打崩**：认崩条那一帧，躯干条变成一根两倍宽的细亮红线。**狼的忍杀**：Boss 血量一帧清空、清掉的部分变成浅色残影；忍杀时狼的躯干条会自动清空，不算被打崩。
55+
- **认招式**：以 Boss 身上的白色锁定点为中心截图，用 DINOv2 提特征，减去前后 0.5 秒的平均值（去掉场景和光线的影响），把掉血前 1.5 秒到后 1.0 秒的画面，和参考库里每次攻击判定开始时刻的同一段比较，按当前阶段的产品招式排序。
56+
- **看不到致命一击的死亡**：在"死"字出现前 1.6–2.9 秒的窗口里识别（你核对过的死亡里，致命一击都在这个范围）。
57+
58+
## 你定的规则（2026-10-16）
59+
60+
- 每一次扣血都算一次失败；被打崩和死亡单独统计。
61+
- 被打崩：躯干条满或接近满，没完美格挡，被打出硬直，躯干条随后彻底清空；看崩条那一帧。躯干条清空时要检查是不是狼自己的忍杀。
62+
- 打崩之后硬直中的追击并入这次打崩，算打崩躯干的那一招。
63+
- 3068 单独打中也算飞渡浮舟；飞渡浮舟起手两刀没接 3092 时，答二连横砍也算对。
64+
- 拼刀反斩和强弹反斩动作基本一样，答哪个都算对。
65+
66+
## 局限
67+
68+
- 样本小：独立测试只有 41 次失败，准确率的误差还比较大。
69+
- 认不准的集中在两类：三阶段贴身、画面模糊的时候（横砍、二连横砍）；以射箭开头、要看后续才能分清的招式（涨潮、退潮、巴之雷）。
70+
- 致命一击在血条上看不出来时，只能估计时间，候选也不稳。
71+
- 第 4、5 段的叠加层读数没有逐条人工核对，只核对了 AI 链标出的可疑处（说明在各自的 `observations/.../README.md`）。
72+
- 只覆盖天守阁弦一郎原版 1.06、2560×1440、16:9 的录像。
73+
74+
## 下一步：M2 可靠性验证
75+
76+
- 用更多独立录像（不开开发者菜单）测失败检测和认招式的准确率与召回率，结果仍由你核对。
77+
- 改进认招式：加上计划里的 AI 链时间约束，专门针对三阶段和射箭开头的招式；多录三阶段的开发者菜单录像扩充参考库。
78+
- 之后是 M3：网站上的录像上传和失败报告。

0 commit comments

Comments
 (0)