5 小时 29 分 17 秒,
从一句话到可玩的单机 Web 5v5 MOBA 原型
这不是一个带动画的普通网页,而是一套同时运行地图、战斗、AI、兵线、建筑、经济、界面与表现层的浏览器实时系统。
凌晨 01:31,用户只给出一句目标:“开发一个类似王者荣耀、最终能够正常玩的游戏。”39.6 秒内,四个范围问题把技术、模式、地图和操控定了下来。到 07:00,浏览器已经走完选将、对线、技能、装备、AI 推进、攻塔、摧毁水晶、结算和重开。中间经历 10 次 Worker 接力,以及小兵堵路、终局僵持、基地贴墙和发光性能四次硬修复。首个模型请求到最后一条账单请求的锚点跨度为5小时29分17秒;完整证据过滤窗口为01:30–07:01,共5小时31分。
阅读口径:“开发窗口”固定指2026-08-09 01:30≤时间<07:01(Asia/Shanghai);“复算”表示读者可以用公开代码、日志、CSV、JSON和媒体哈希重新得到同一数字。会话ID、Run、工具ID、时间与SHA-256把过程记录、最终代码和运行画面连接起来。
标准入口从5名英雄选将开始;自动演示入口直接进入由脚本驱动的5v5对局。
最终版运行画面:河道多人及兵线交战
画面内可见 5 名英雄,并显示技能冷却遮罩、小地图、双方小兵、河道水面与草丛;这张静态图不单独证明 10 名英雄同时出现在同一画面。
开局选将界面:5 英雄卡片
亚瑟/后羿/妲己/牛魔/兰陵王,每张卡片含定位、三个技能名与简介;选中高亮、"锁定"进入对局。素材来源声明(不构成法律意见):本产物为本地学习原型;现有代码和运行记录显示地图、模型、特效与 UI 为程序化生成,音效由 WebAudio/TTS 路径产生,未发现官方美术、音频或模型文件。项目仍直接使用《王者荣耀》名称、英雄名称及玩法参照;这段声明不等同于商标、著作权或其他法律合规结论。
这次交付了什么
最终产物是一个纯静态的单机 Web 5v5 MOBA 原型:Three.js 负责 3D 峡谷与锁定视角,玩家与 9 个 AI 英雄共享战斗状态,三路兵线、野区、18 座防御塔、经济成长、装备、技能、HUD 和结算在同一主循环里推进。它不需要包管理器或构建步骤,测试运行中也没有加载外部 HTTP 素材;运行仍依赖浏览器、Python 启动器、操作系统能力和本地 vendored Three.js。难点不在任何一个单独功能,而在这些系统必须以正确顺序共同工作。
一句话之后,先把“能玩”定义清楚
这次开发不是从代码开始,而是从四个范围选择开始。39.6秒内确定技术、模式、地图与操控,随后才把目标写成16条可验收合同。
先看最终画面,再沿着需求、选择和启动链向后追。这里回答的是“交付从哪里来”,不是用一排数字制造声势。
数据:E01 / E12 / E18 / 用户消息 + DESIGN.md + 冻结代码 + V01–V12 + 录屏|图中结论:需求经过确认、实现、运行和复验形成可玩原型
查看来源与复算数据
- 数据来源
- 用户消息 + DESIGN.md + 冻结代码 + V01–V12 + 录屏
- 复算口径
- 需求经过确认、实现、运行和复验形成可玩原型。
图中指标
- 全部Run11
fact.run.total - Worker Run10
fact.run.workers - LLM started878
fact.llm.started - 工具调用968
fact.tools.total
数据:E01 / E12 / E18 / verification.json + 证据账本 E01–E42|图中结论:核心规模可由公开证据分别复算
查看来源与复算数据
- 数据来源
- verification.json + 证据账本 E01–E42
- 复算口径
- 核心规模可由公开证据分别复算。
图中指标
- 账单请求877
fact.bill.requests - 运行完成873
fact.llm.completed - 工具成功951
fact.tools.success - 工具错误17
fact.tools.error
范围确定后,四个选择被写进DESIGN,再由启动脚本真正拉起浏览器。
数据:E01 / E12 / E18 / provenance.json + 数据库 + 视频元数据|图中结论:开发统计严格限定到01:30–07:01,窗口外材料单列
查看来源与复算数据
- 数据来源
- provenance.json + 数据库 + 视频元数据
- 复算口径
- 开发统计严格限定到01:30–07:01,窗口外材料单列。
图中指标
- 证据窗口5:31:00
- 首末请求锚点5:29:17
- 日志首条01:30:01.516
- 窗口外层3
数据:E01 / E12 / E18 / 最终代码 + G01–G16 + 运行截图|图中结论:玩法、英雄、操控、AI、UI、视觉和工程入口均有代码与证据
查看来源与复算数据
- 数据来源
- 最终代码 + G01–G16 + 运行截图
- 复算口径
- 玩法、英雄、操控、AI、UI、视觉和工程入口均有代码与证据。
图中指标
- 第一方文件19
fact.code.firstPartyFiles - 第一方代码行7,979
fact.code.firstPartyLines - src模块17
fact.code.modules - 本地导入边39
fact.code.importEdges
数据:E01 / E12 / E18 / interaction_requests + 会话消息|图中结论:四项用户选择均有原始选项、响应和落库时间
查看来源与复算数据
- 数据来源
- interaction_requests + 会话消息
- 复算口径
- 四项用户选择均有原始选项、响应和落库时间。
图中指标
- 问题4
- 候选方案10
- 选择4
- 总响应39.561s
数据:E01 / E12 / E18 / db/interaction-requests-20260809-0130-0701.json|图中结论:四条elicitation具有独立创建、决定和响应原值
查看来源与复算数据
- 数据来源
- db/interaction-requests-20260809-0130-0701.json
- 复算口径
- 四条elicitation具有独立创建、决定和响应原值。
图中指标
- Q18.585s
- Q28.916s
- Q34.957s
- Q417.103s
数据:E01 / E12 / E18 / 用户选择 + DESIGN.md + G01–G16 + 代码符号|图中结论:每项选择可追到规范、源码和直接验收证据
查看来源与复算数据
- 数据来源
- 用户选择 + DESIGN.md + G01–G16 + 代码符号
- 复算口径
- 每项选择可追到规范、源码和直接验收证据。
图中指标
- 用户选择4
- 合同条款16
- 验收编号12
- 证据账本43
数据:E01 / E12 / E18 / 用户消息#2 + start.command + lsof实测|图中结论:启动器探测端口并选择可用地址,21个占用端口场景通过
查看来源与复算数据
- 数据来源
- 用户消息#2 + start.command + lsof实测
- 复算口径
- 启动器探测端口并选择可用地址,21个占用端口场景通过。
图中指标
- 占用端口样本21
- 固定候选端口8
- 系统回退bind(0)
- 验收标题KING_OK
0.1 全程关键时间锚点(多源交叉定位) 日志 数据库
TABLE-01 · 原始表格 · 对应 RUN-V01
| 时刻(+08) | 事件 | 来源 |
|---|---|---|
01:26:20 | 会话创建(工作目录 ~/Desktop/dev/project/king) | DB sessions.created_at = 2026-08-08T17:26:20Z |
01:31:15 | 收到主需求;同一秒发起第一次模型调用(turn 1) | DB 首条用户消息;观测日志首行 llm_call_started |
01:32:05 | 账单 CSV 首个计费请求(输入 17,387 / 输出 1,581 tokens) | CSV 按时间升序首行 |
01:32 | AskUserQuestion 发出 4 项确认,用户全选推荐项 | 会话消息记录(全程仅 1 次,与工具统计互证) |
01:34:59 | 安全审计日志首条(Bash_2 环境探测) | security-audit 日志首行 |
01:39:58 | R01 子 Agent 启动(阶段1:地基与 3D 地图,提示词 2,697 字符) | 观测日志第 13 行 subagent_started |
02:09:58 | 用户消息 #2:端口冲突预警;同一秒 R01 触 30m 时限交付 | DB;观测日志 run_termination_summary |
02:12:10 → 05:06:33 | R02–R06:战斗核心 → AI → 三次攻坚修复,05:06:33 起 3/3 局分出胜负 | 观测日志逐条 subagent 事件(PART 4 账本) |
05:07:33 → 06:52:45 | R07 UI → R08 视觉 → R09 发光/性能修复 → R10 隔离上下文的同系统 QA Worker | 观测日志 |
06:53 → 07:00:32 | 协调者最终验收:死亡/重生、播报、完整对局(红方胜)、结算、再来一局 | 会话消息记录;CSV 末行 07:00:32 |
0.2 交付清单 实测
TABLE-02 · 原始表格 · 对应 CASE-V04
| 维度 | 交付内容 | 证据 |
|---|---|---|
| 玩法 | 5v5 三路推塔 MOBA:上/中/下三路兵线、9+9 防御塔(T1→T2→T3 顺序无敌)、水晶基地(解防规则+梯度减伤+脱战回血)、红蓝 BUFF/小野/暴君/主宰、草丛隐身、回城/重生/泉水 | 对局实测(PART 7);代码 src/game/* |
| 英雄 | 5 个英雄各有 3 个主动技能,并实现强化普攻、自动加点及部分被动:亚瑟(战士)/后羿(射手)/妲己(法师)/牛魔(坦克)/兰陵王(刺客,含隐身被动) | src/game/skills.js(485 行) |
| 操控 | 王者荣耀式屏幕虚拟摇杆 + 普攻大按钮 + 技能按钮(冷却遮罩/拖动瞄准)+ 闪现/恢复召唤师技能;键盘 WASD/QWER/空格/B/H/G 回退 | src/engine/input.js、src/ui/hud.js |
| AI | 9 个 AI 英雄状态机(分路/对线/打野/团战/撤退/回防/GROUP_PUSH/ASSAULT),会买装备、会打龙、会经基地门径攻水晶 | src/game/ai.js(920 行) |
| UI | 选将界面、小地图、技能 CD、装备商店(12 件/一键推荐)、击杀播报(第一滴血…五连绝世)、TTS 中文播报、合成音效、结算界面/再来一局 | src/ui/*(1,172 行) |
| 视觉 | 程序化 3D:峡谷地形/河道/草丛/树木、5 英雄专属模型与武器、技能粒子特效、弹道拖尾、防御塔激光、跟随式阴影与雾 | src/world/*、src/engine/vfx.js |
| 工程 | 纯静态站点:vendored Three.js r160、ES Modules、无构建;?demo/speed/hero 测试钩子;window.__errors 错误收集;document.title boot 状态;端口自适应启动脚本 | index.html、start.command |
三条阅读路径
TABLE-03 · 原始表格 · 对应 CASE-V04
| 路径 | 读者 | 路线 |
|---|---|---|
| 90 秒 | 只看结果 | 卷首数字 → PART 7 验收与画廊 → PART 9 结论 |
| 5 分钟 | 关注方法 | + PART 4 执行账本 → PART 5 中断接续 → PART 6 调试攻坚 |
| 全展开 | 审查者 | 顺序阅读 + 点击左侧"展开完整底稿模式"(所有 details 强制展开)+ 按附录 A.2 逐条复算 |
需求怎么定下来:2 条消息、4 项确认、1 条硬约束
用户第一句话就定下了合作方式:"动手前所有不确定的问题都要先跟我确认,给我多个独立方案让我选择;开始写代码以后就不要再问我"。协调者严格按此执行:写代码前发起唯一一轮 4 项确认(AskUserQuestion 在 968 次工具调用中恰好出现 1 次,日志可证);此后 5 个多小时全自动决策,直到交付。
1.1 用户消息原文(窗口内全部非工具类用户输入,共 2 条) 数据库
你可以开发一个类似王者荣耀的游戏么?我希望页面越逼真越好,不需要考虑版权问题,因为我只是本地用于学习,帮我开发一个这样的游戏,跟王者荣耀越像越好,最终需要正常能玩没有明显功能 bug,你在开始动手前所有不确定的问题都要先跟我确认,给我我多个独立方案让我选择。但是在你开始写代码以后,就不要再问我了,都要自动选择能正常落地而且能尽量逼真效果的方案,不要选择注册网站单独购买等方案2026-08-09 01:31:15 (+08) · 用户消息 #1(主任务)· db/session-messages.json 首行
记住,最终真实验证的时候,本地有多个端口已经在用,要先检测没在用才可以,避免端口冲突。2026-08-09 02:09:58 (+08) · 用户消息 #2(约束补充)· 此后该规则写入 DESIGN.md 并下达给每个 worker
口径说明:窗口内 DB 共 117 条 user 角色记录,其中 115 条为工具结果/worker 通知的系统封装,真实人类输入即以上 2 条——"确认一次、补充一次,然后全程放手"本身就是本案例的需求治理证据。
1.2 唯一一轮需求确认原账(AskUserQuestion,4 项全选推荐) 记忆 数据库
TABLE-04 · 原始表格 · 对应 CASE-V05
| 问题 | 候选(按展示顺序,含推荐理由) | 用户选择 |
|---|---|---|
| Q1 技术方案 | Three.js 3D 锁视角(推荐:浏览器打开即玩、逼真度上限最高、无需安装几个 GB 的编辑器)| Canvas 2D 俯视角 | Unity 3D 工程 | Three.js 3D锁视角 (推荐) |
| Q2 对战模式 | 单机 5v5 对 AI(推荐:完整团战体验;联机需网络同步,稳定性风险大)| 单机 1v1/3v3 | 局域网联机 | 单机5v5对战AI (推荐) |
| Q3 地图规模 | 完整三路王者峡谷(推荐:上中下三路+野区+草丛+大小龙,完整还原)| 简化版地图 | 完整三路王者峡谷 (推荐) |
| Q4 操控方式 | 虚拟摇杆+技能按钮(推荐:与王者荣耀操作完全一致;键盘作为回退)| 键鼠操控 | 手机屏幕式虚拟摇杆+技能按钮 (推荐) |
回答对象原文:{"q1":"Three.js 3D锁视角 (推荐)","q2":"单机5v5对战AI (推荐)","q3":"完整三路王者峡谷 (推荐)","q4":"手机屏幕式虚拟摇杆+技能按钮 (推荐)"}(会话消息记录可查)。
1.2b 交互原账(interaction_requests 表原值:4 项确认历时 39.6 秒) 数据库
TABLE-05 · 原始表格 · 对应 CASE-V06
| 时刻(UTC) | 类型 | 内容 | 响应 | 思考耗时 |
|---|---|---|---|---|
| 17:32:05.003 | elicitation | Q1 技术方案(3 候选) | "Three.js 3D锁视角 (推荐)" | 8.6s |
| 17:32:13.594 | elicitation | Q2 对战模式(3 候选) | "单机5v5对战AI (推荐)" | 8.9s |
| 17:32:22.514 | elicitation | Q3 地图规模(2 候选) | "完整三路王者峡谷 (推荐)" | 5.0s |
| 17:32:27.475 | elicitation | Q4 操控方式(2 候选) | "手机屏幕式虚拟摇杆+技能按钮 (推荐)" | 17.1s |
从 Q1 创建(01:32:05.003 +08)到 Q4 决定落库(01:32:44.579 +08)历时 39.6 秒。开发窗口内只有以上 4 条 elicitation,权限请求为 0;当前活动数据库后来继续增长,因此正文不再引用可变的全库总数。开发窗口外的报告制作交互不进入公开开发证据。
Q1 的 prompt_json 完整原值(含全部候选与推荐理由,逐字未改)
{
"options": [
{
"label": "Three.js 3D锁视角 (推荐)",
"value": "Three.js 3D锁视角 (推荐)",
"description": "浏览器直接打开即玩,3D场景+锁定斜45°视角(和王者荣耀视角一致),带光影/粒子特效/小地图,画面最逼真"
},
{
"label": "Canvas 2D俯视角",
"value": "Canvas 2D俯视角",
"description": "纯2D俯视角,开发更快更稳定,但画面表现力明显弱于3D,不像王者荣耀"
},
{
"label": "Unity 3D工程",
"value": "Unity 3D工程",
"description": "画质上限最高,但需要你安装几个GB的Unity编辑器,工程配置复杂,周期长"
}
],
"question": "技术方案选哪种?(决定画面逼真度的上限)"
}1.3 端口硬约束的落地 实测
TABLE-06 · 原始表格 · 对应 CASE-V08
| 落地动作 | 内容 | 证据 |
|---|---|---|
| 本机端口扫描 | 实测 21 个被占端口:5000 5173 7000 8000 8080 8440 8451 8787 8791 8931 13564 17890 49443 49445 49449 50065 53743 53746 54029 56510 63278 | lsof 输出(会话记录) |
| 写入开发规范 | DESIGN.md"端口规则(强制)"章节:任何服务启动前必须 lsof 确认空闲,优选 9201–9499;随提示词下达给每个 worker(R05 提示词原文可见此条,PART 4.4) | assets/king/DESIGN.md |
| 启动脚本自适应 | start.command 自动扫描 9201/9202/9203/9301/9302/9417…首个空闲端口,全部占用时回退系统随机端口,并自动打开浏览器(全文见附录 A.3) | assets/king/code/start.command |
19 个第一方文件、7,979 行的单机 Web 5v5 MOBA 原型
index.html、17 个 src/*.js 与 13 行启动器合计 19 个第一方文件、7,979 行;不计启动器时为 18 个文件、7,966 行。完整代码快照另含 2 个 vendored Three.js 文件,共 21 个代码文件。测试运行的 performance resource entries 均为 localhost,未发现外部 HTTP 资源请求。
一个MOBA原型,复杂在系统必须同时运转
地图、战斗、AI、兵线、建筑、经济、HUD和表现层都要共享同一份实时状态。17个模块与39条本地导入边,只是这张运行图的骨架。
真正值得看的,是状态如何穿过模块边界,以及一处规则改变会同时牵动多少系统。
数据:E02 / E25 / E31 / assets/king/code + verification.json.code|图中结论:7,979行按game/world/engine/ui/config/main/utils可复算
查看来源与复算数据
- 数据来源
- assets/king/code + verification.json.code
- 复算口径
- 7,979行按game/world/engine/ui/config/main/utils可复算。
图中指标
- 第一方文件19
fact.code.firstPartyFiles - 第一方代码行7,979
fact.code.firstPartyLines - src模块17
fact.code.modules - 本地导入边39
fact.code.importEdges
文件规模只是入口。继续往下看,设计合同如何落到依赖边界和具体运行符号。
数据:E02 / E25 / E31 / 逐文件字节/行数/SHA-256 + 原项目聚合哈希|图中结论:证据副本与原始king运行文件逐字节一致
查看来源与复算数据
- 数据来源
- 逐文件字节/行数/SHA-256 + 原项目聚合哈希
- 复算口径
- 证据副本与原始king运行文件逐字节一致。
图中指标
- 第一方19
- vendored2
- 完整快照21
- 原项目文件57
数据:E02 / E25 / E31 / DESIGN.md + config/state/ai/skills/ui|图中结论:地图、单位、技能、AI、经济、UI、终局都有对应代码入口
查看来源与复算数据
- 数据来源
- DESIGN.md + config/state/ai/skills/ui
- 复算口径
- 地图、单位、技能、AI、经济、UI、终局都有对应代码入口。
图中指标
- DESIGN条款16
- 源码模块17
- 验收编号12
- 状态语义3
数据:E02 / E25 / E31 / index.html + importmap + vendored Three.js + start.…|图中结论:无需包管理器、构建步骤或运行时外部HTTP资源
查看来源与复算数据
- 数据来源
- index.html + importmap + vendored Three.js + start.command
- 复算口径
- 无需包管理器、构建步骤或运行时外部HTTP资源。
图中指标
- 构建步骤0
- 外部HTTP素材0
- src模块17
- vendored库2
2.1 源码逐文件清单(行数 / 字节 / SHA-256 截断,可独立复算) 实测
TABLE-07 · 原始表格 · 对应 SRC-V01
| 文件 | 行数 | 职责 |
|---|---|---|
index.html | 321 | 入口:importmap、全局错误收集(window.__errors)、boot 状态写入 document.title、HUD 根节点与全部 UI 样式 |
src/main.js | 186 | 启动装配、固定步长主循环(30Hz 逻辑 + rAF 渲染)、?demo/speed/hero 测试参数 |
src/config.js | 362 | 全部数值表:地图坐标/兵线路径点/塔位/基地门坐标、英雄属性、技能数值、小兵/野怪/装备/AI 参数 |
src/utils.js | 88 | 数学工具、对象池、事件总线 |
src/engine/renderer.js | 134 | WebGL 渲染器、ACES 色调映射、跟随式阴影相机、锁定 55° 俯视角跟随相机 rig |
src/engine/input.js | 139 | 虚拟摇杆(Pointer Events 多点触控)、WASD/QWER/空格/B/H/G 键盘映射 |
src/engine/audio.js | 169 | WebAudio 程序化合成音效(攻击/技能/击杀/塔毁/回城/胜负)、speechSynthesis 中文播报 |
src/engine/vfx.js | 836 | 粒子系统、弹道拖尾、地面指示圈、受击闪红壳层、死亡消散、BUFF 光环、升级光柱 |
src/world/map.js | 840 | 峡谷地形 Canvas 纹理、河道、三路、基地围墙与门、防御塔/水晶/泉水模型、草丛、龙坑、装饰 |
src/world/models.js | 730 | 程序化角色工厂:5 英雄专属模型(武器/配色/体型)、3 种小兵、野怪,走路/攻击/施法动作 |
src/game/state.js | 1,309 | 核心:单位系统、伤害结算、死亡/重生、塔/水晶无敌规则、泉水、回城、闪现/恢复、玩家操作入口 |
src/game/skills.js | 485 | 5 套英雄技能、弹道(直线/指向/追踪)、Buff/Debuff(眩晕/沉默/击飞/隐身/护盾/灼烧) |
src/game/ai.js | 920 | 小兵仇恨、野怪 leash、英雄 AI 状态机(分路/对线/打野/团战/撤退/回防/GROUP_PUSH/ASSAULT)、基地门路由 |
src/game/spawner.js | 158 | 三路兵波次(30s/波、炮车每 3 波)、超级兵、野怪与暴君主宰刷新、经验金币分配 |
src/game/shop.js | 117 | 12 件装备数据、6 格装备栏、推荐出装自动购买 |
src/ui/hud.js | 525 | 技能按钮(CD 遮罩/拖动瞄准)、普攻/召唤师技能/回城键、血条蓝条 DOM 覆盖层、伤害飘字 |
src/ui/minimap.js | 229 | Canvas 小地图:地形底图、双方单位点、塔图标、相机框、点击视察 |
src/ui/screens.js | 418 | 选将界面、中央横幅播报、击杀条、结算界面与"再来一局" |
start.command | 13 | 双击启动器:自动挑选空闲端口(9201–9499→系统随机)、自动开浏览器 |
| 合计 | 7,979 | 另有 lib/three.module.js(1,272,972 字节,Three.js r160 官方构建 vendored)与 lib/BufferGeometryUtils.js(31,906 字节) |
2.1b 交付代码完整文件清单(21 个文件:字节数 + SHA-256 前 12 位)
| 文件(相对 assets/king/code/) | 字节 | SHA-256(前12位) |
|---|---|---|
index.html | 20,500 | d01c23203c26… |
lib/BufferGeometryUtils.js | 31,906 | 9be041e96308… |
lib/three.module.js | 1,272,972 | 76dea8151bc9… |
src/config.js | 16,846 | 31799805e7be… |
src/engine/audio.js | 7,318 | 4e5d9a39b829… |
src/engine/input.js | 5,300 | 0b4249617161… |
src/engine/renderer.js | 5,459 | 4873c45ccad1… |
src/engine/vfx.js | 33,230 | 9ec1ebe7060f… |
src/game/ai.js | 35,715 | 7c25f41b3a7a… |
src/game/shop.js | 4,947 | c87e8d090554… |
src/game/skills.js | 20,113 | 95a7c5f3087c… |
src/game/spawner.js | 6,666 | ab2d1b2cada8… |
src/game/state.js | 51,881 | 56b8fb582f52… |
src/main.js | 7,232 | 45008e2175ae… |
src/ui/hud.js | 21,211 | 0e8870a93f7f… |
src/ui/minimap.js | 7,929 | 735150b4e439… |
src/ui/screens.js | 17,845 | 2db4df42faaa… |
src/utils.js | 2,532 | e4300613d4be… |
src/world/map.js | 35,187 | 3b0ab72fcc53… |
src/world/models.js | 30,158 | 48e30d1747c2… |
start.command | 541 | ff573ec33659… |
完整 64 位哈希见 assets/king/SHA256SUMS.txt;复核命令见附录 A.2。
2.1c 系统耦合证据:17 个模块不是 17 个孤岛 实测
src/ 中 17 个 JavaScript 模块共发出 39 条本地相对导入边;其中 38 条连接第一方 src 模块,1 条由 world/map.js 指向本地 vendored lib/BufferGeometryUtils.js。统计只计算静态 import/export ... from 与副作用导入,不计裸模块 three,由验证脚本直接扫描源码生成。main.js:10 个顶层依赖的装配点
入口同时接入 renderer、input、vfx、audio、map、state、hud、minimap、screens 与 config,把渲染、输入、玩法状态和 UI 放进同一个固定步长逻辑循环与逐帧渲染循环。
state.js:玩法状态的汇合点
核心状态继续连接 config、utils、models、skills、spawner、ai 与 shop;伤害、死亡、技能、兵线、AI、装备和世界对象因此不是独立演示模块,而是在共享状态中互相产生可见结果。
PRE-02 · 原始代码/日志 · 对应 KING-V03
输入/技能 → GameState 伤害与状态 → AI/兵线/经济推进
↓ ↓
模型与特效反馈 HUD/小地图/结算同步这张依赖图能证明最终代码形成了跨系统运行结构,也能解释为什么难点不只是“生成 7,979 行”。它本身不能证明代码质量、自动测试覆盖率、数值平衡或商业游戏成熟度;这些需要另外的测试与长期运行数据。
2.2 玩法系统配置(摘自开发规范 DESIGN.md,逐项落地) 记忆 实测
地图(200×200 世界坐标)
蓝方基地 (-72,-72)、红方 (72,72);河道为对角线 z=-x;三路兵线共享路径点(红方反向);每方每路 3 塔共 18 座(T1→T2→T3 顺序无敌);水晶一路全破或存活塔≤3 解除无敌;草丛 14 片隐身规则;暴君 (-22,22)、主宰 (22,-22) 龙坑;基地围墙带 3 个门(BASE_GATES,I3 修复产物)。
经济/经验
首波兵 t=10s,每 30s 一波(3 近战+2 法师,每 3 波加炮车);一路全破后该路附加超级兵;12:00 后小兵每分钟 +8% 成长;击杀英雄 200 金+助攻 80;被动金币 2/s(2:00 起);经验共享半径 14;等级 1–15;重生 8s+2s×等级。
技能样例(后羿)
S1 炙热之风:4s 普攻三连发(每发 60%AD);S2 燎原箭雨:6 半径区域 240+0.8AD+减速 30%;Ult 灼日之矢:60 距离直线弹道,命中英雄眩晕 0.5–2.5s(随距离)+400+1.0AD。
装备
12 件(铁剑 300/+25AD … 破军 2200/+180AD、霸者重装 2000/+1500HP+5%回血/s),6 格栏位;每英雄预设推荐出装,UI 一键购买、AI 回泉自动购买。
2.3 开发规范 DESIGN.md 全文(协调者撰写,10 个 worker 共用的事实源;5,925 字符)
# 《王者峡谷》Web 版设计文档(内部开发规范)
> 目标:本地运行的类王者荣耀 5v5 MOBA。Three.js 3D 锁视角,单机对 AI。
> 纯静态站点:ES Modules + 本地 vendored three.js,无构建步骤,无外部素材,无网络依赖。
> 运行方式:项目根目录 `python3 -m http.server 8787`,浏览器打开 `http://localhost:8787`。
## 技术约束(所有阶段必须遵守)
- three.js 已 vendored 在 `lib/three.module.js`(r160),import 方式:`import * as THREE from '../lib/three.module.js'`(相对路径按文件位置调整)。index.html 中用 importmap:`{"imports": {"three": "./lib/three.module.js"}}`,业务代码统一 `import * as THREE from 'three'`。
- 禁止任何外部 URL 素材(贴图/模型/音频/字体)。所有视觉资源程序化生成(几何体 + Canvas 纹理 + 粒子)。音效用 WebAudio 合成;播报用 `speechSynthesis`(zh-CN),失败静默降级。
- 一切素材缺失时游戏必须能正常玩(健壮性优先)。
- 性能:低模 + 共享材质 + 对象池(粒子/飘字/血条 DOM)。60fps 目标。同屏单位约 60 个。
- 调试钩子:所有 console error 收集到 `window.__errors`;`window.__game` 暴露游戏主对象;页面加载成功 boot 完成后设 `document.title='KING_OK'`;失败设 `'KING_ERR: '+msg`。供自动化验证用。
- 代码注释用中文,适度即可。不引入任何 npm 依赖。
## 文件结构
```
index.html 入口,importmap,全屏canvas容器,UI根div
start.command 双击启动脚本 (cd 到目录 && python3 -m http.server 8787)
lib/three.module.js
src/config.js 全部数值配置(地图/英雄/小兵/塔/装备/AI参数),常量表,禁止魔法数字散落
src/utils.js 数学/对象池/事件总线
src/engine/renderer.js 场景/灯光/雾/相机rig(锁定跟随,俯仰55°,固定朝向敌方基地),阴影
src/engine/input.js 虚拟摇杆(指针事件)+键盘WASD/QWER回退+技能按钮事件分发
src/engine/audio.js WebAudio合成音效(攻击/技能/击杀/塔毁/胜利),TTS播报
src/engine/vfx.js 粒子系统/弹道拖尾/地面指示圈/范围箭头/受击闪白/死亡消散
src/world/map.js 地形/河道/草丛/防御塔与水晶模型/野区装饰/基地/泉水
src/world/models.js 程序化角色模型工厂(英雄5种/小兵3种/野怪),简单骨骼式摆动动画
src/game/state.js GameState:单位表/队伍/时间/比分/事件;单位基类(移动/血蓝/伤害/死亡)
src/game/skills.js 5套英雄技能定义+施放逻辑+弹道+Buff系统
src/game/spawner.js 小兵波次/英雄重生计时/野怪刷新/经验金币分配
src/game/ai.js 英雄AI(分路/对线/打野/团战/撤退/回城/买装)+小兵仇恨
src/game/shop.js 装备数据+购买逻辑+推荐出装
src/ui/hud.js 血条蓝条DOM覆盖/技能按钮(冷却/拖动瞄准)/普攻键/召唤师技能/回城/飘字
src/ui/minimap.js Canvas小地图(地形底图+单位点+塔+视野框)
src/ui/screens.js 选英雄界面/击杀横幅(第一滴血..五连绝世)/记分板/胜利失败结算
src/main.js 启动/主循环(fixed timestep 逻辑 30Hz + 渲染)/模块装配
```
## 地图(王者峡谷,世界坐标 x∈[-90,90], z∈[-90,90],y 向上)
- 蓝方基地 (-72,-72),红方基地 (72,72)。河道为对角线 z=-x(左上-右下),宽 14,水面半透明蓝色。
- 三条兵线(路径点,双方共用,红方反向行走):
- 中路: [(-70,-70), (0,0), (70,70)](对角直线)
- 上路: [(-70,-70), (-80,-40), (-80,40), (-40,80), (40,80), (70,70)](左边缘→上边缘)
- 下路: [(-70,-70), (-40,-80), (40,-80), (80,-40), (80,40), (70,70)](下边缘→右边缘)
- 防御塔每方每路 3 座(外塔T1→中塔T2→高地塔T3),塔在兵线旁。蓝方塔位(红方中心对称取负):
- 中路: (-46,-46) (-28,-28) (-12,-12)
- 上路: (-80,-10) (-80,28) (-80,58)
- 下路: (-10,-80) (28,-80) (58,-80)
- 水晶(基地核心): 各方基地内侧,无敌直至本方任意一路 3 塔全破。泉水在水晶后方,每秒回 20% 血蓝;敌方进入泉水每秒受 2000 真实伤害。
- 野区: 河道两侧各 2 块野区的对角象限。每方: 红BUFF营(-30,10)附近 / 蓝BUFF营(10,-30)附近(红方对称),小野营 2 处。龙坑: 暴君(-22,22) 河道左上侧, 主宰(22,-22) 河道右下侧。
- 草丛: 河道两岸与各路边共约 14 片(2x4 单位绿色半透明草块)。单位在草丛内对敌方不可见(AI 与普攻不锁定其中单位,进入草丛的敌方显形)。
- 装饰: 野区树木(圆锥+圆柱)约 120 棵、石头、基地围墙、旗帜。地面 Canvas 纹理 2048²:草地底色+路线上土路+河道+基地石台+野区深色。
## 数值体系
- 伤害公式: 实际伤害 = 面板 × 100/(100+对应抗性)。暴击默认 200%。
- 英雄: 5 级属性成长, 1-15 级。移速 6.4~7.2 u/s。近战攻击距离 2.6, 射手 9.5, 法师 9。
- 英雄池(玩家开局 5 选 1,其余由 AI 补位,红蓝双方各 5 英雄不重复):
1. 亚瑟·战士(近战): 被动无。S1 誓约之盾:3s 移速+30% 并强化下次普攻(额外 120+0.6AD 伤害+沉默1s)。S2 回旋打击:3s 内每秒对半径4内敌人造成 90+0.5AD。Ult 圣剑裁决:跃向 8 内目标造成 350+1.0AD+目标已损生命 12% 伤害。
2. 后羿·射手(远程): S1 炙热之风:4s 内普攻三连发(每发 60%AD)。S2 燎原箭雨:对 6 半径区域 240+0.8AD 伤害+减速30% 2s。Ult 灼日之矢:直线超远(60)弹道,命中英雄眩晕 0.5~2.5s(随距离)+400+1.0AD。
3. 妲己·法师(远程): S1 灵魂冲击:弹道 280+0.75AP。S2 偶像魅力:弹道命中眩晕 1.2s+180+0.5AP。Ult 女王崇拜:5 团狐火自动追踪 10 内敌人(优先英雄)每团 160+0.45AP。
4. 牛魔·坦克(近战): S1 咆哮之斧:横扫 200+0.7AD+减速25%。S2 横行霸道:冲锋 8 距离击退路径敌人+220+0.6AD。Ult 山崩地裂:半径 5 击飞 1s+300+0.8AD+自身 500 护盾 3s。
5. 兰陵王·刺客(近战): 被动 脱战 3s 后隐身(草丛/攻击破隐)。S1 秘技·分身:召唤分身普攻 3 次(60%AD)。S2 秘技·影蚀:掷匕 260+0.7AD+标记,3s 内再受兰陵王伤害触发 180+0.5AD。Ult 秘技·暗袭:突进至 9 内目标身后,400+1.2AD。
- 技能加点自动:6/11/15 级点大招前…改为 4/8/12 级点大招,其余按 S1>S2 交替。技能 CD: S1 8s, S2 10s, Ult 40s(基础,随等级减)。
- 召唤师技能: 玩家带 闪现(位移 8,CD 120s) + 恢复(8s 回 25% 血,CD 90s)。AI 只用恢复。
- 小兵: 近战兵 HP1300 AD42 射程2; 法师兵 HP850 AD65 射程9; 炮车 HP2600 AD130 射程10 对塔 2 倍伤害。每波 3 近战+2 法师,每第 3 波加 1 炮车。首波 t=10s,之后每 30s。三路同时出兵。金币: 近战42/法师36/炮车90(击杀者),经验共享半径 14。
- 防御塔: HP6500 AD320 射程12 攻速0.8,优先小兵;若敌英雄在塔范围内攻击我方英雄则转火该英雄;对同一英雄连击每次+30%(最多+90%)。必须按 T1→T2→T3 顺序摧毁(前塔未破后塔无敌)。破塔全队+200 金。
- 水晶: HP10000,缓慢回血 1%/s。
- 野怪: 红BUFF(击杀者获得:普攻附带 40+0.2AD 灼烧+减速15%,持续60s) HP4000; 蓝BUFF(CD-20%+回蓝,60s) HP4000; 小野 HP2200。野怪 60s 刷新,脱战回营满血。暴君(8:00 首刷,击杀后 3:00 刷新):全队+150 金+经验。主宰(10:00 首刷):击杀方三路下一波兵变为强化主宰先锋(属性×1.8)。野怪只主动攻击 3.5 范围内敌人。
- 升级: 击杀小兵/野怪/英雄得经验,1-15 级经验表递增;击杀英雄 200 金+助攻 80 金;被动金币 2/s 从 2:00 开始。
- 重生: 8s+2s×等级。回城: 引导 8s(被打断进入 CD 8s),回泉水。
- 装备(6 格,价格/属性简化): 铁剑300(+25AD) 攻速匕400(+25%攻速) 法典500(+40AP) 布甲300(+25护甲) 抗魔斗篷300(+25魔抗) 神速之靴300(+0.8移速) 破军2200(+180AD) 无尽战刃2100(+120AD+25%暴击) 博学者之怒2300(+240AP) 红莲斗篷1800(+120护甲+800HP) 魔女斗篷1800(+120魔抗+800HP) 霸者重装2000(+1500HP+5%回血/s)。推荐出装每英雄预设 6 件,UI 提供"一键购买"逐件购入;AI 有钱自动按推荐买。
## 英雄 AI(ai.js)
状态机: LANE(守线,跟己方小兵推进,塔下猥琐,残血撤退) / FARM_JUNGLE(打野位清野) / TEAMFIGHT(4s 内附近发生≥3 英雄交战则前往支援,15 半径) / PUSH(敌方塔可打且己方兵线优势时推塔) / RETREAT(HP<30% 撤向泉水,安全则回城) / DEFEND(己方塔/水晶被攻时回防)。
- 分路: 双方各 1上1中2下+1打野。
- 技能使用: 敌人进射程且 CD 好就放;Ult 留给英雄目标或团战。普攻锁定最近敌人(英雄优先权重×1.5)。
- 买装: 回泉水时按推荐顺序购买。
- 难度目标: AI 能互相击杀、会推塔,平均对局 8-15 分钟结束。
## UI(王者荣耀式横屏布局,DOM 实现,Pointer Events)
- 左上: 小地图(方形 canvas,地形简图+蓝/红点+塔图标+相机框)。右上: 击杀播报条+比分/时间/FPS。
- 左下: 虚拟摇杆(按下拖动控制移动方向)。右下: 大普攻按钮(按住连续攻击),S1/S2/Ult 技能按钮(冷却遮罩+拖动出现瞄准指示器[方向箭头/范围圈],松开施放;点按=自动瞄准最优目标),闪现/恢复小按钮,回城按钮。
- 底部中央: 血条蓝条/等级/金币/KDA/装备栏(6格)/商店按钮(打开装备面板,含一键购买)。
- 中央横幅: 第一滴血/双杀/三连决胜/四连超凡/五连绝世/团灭/防御塔被摧毁/胜利/失败,配 TTS 播报与合成音效。
- 开局选英雄界面: 5 张英雄卡片(程序化头像:对应配色的几何拼脸/图标)+技能简介,点击"锁定"进入。结算界面: 胜/负、KDA、时长、伤害统计、"再来一局"。
- 桌面调试: WASD 移动,Q/W/E/R 放技能,空格普攻。所有按钮支持鼠标。
## 端口规则(强制)
- 本机有多个端口被占用(已知占用:5000 5173 7000 8000 8080 8440 8451 8787 8791 8931 13564 17890 49443 49445 49449 50065 53743 53746 54029 56510 63278)。**启动任何 HTTP 服务前,必须先用 `lsof -iTCP:<port> -sTCP:LISTEN -P -n` 检测端口空闲,空闲才能用**;优先从 9201~9499 范围挑选。已验证空闲:9201 9202 9301 9417。
- 若 8787 上已有本项目遗留的 python http.server 在跑,可直接复用,不必重复启动。
## 验证标准(每阶段完成前自查)
1. 按上述端口规则起服后可访问,`document.title==='KING_OK'`,`window.__errors` 为空。
2. 无 404/跨域报错;无任何外部资源请求(DevTools network 全为 localhost)。
3. 阶段定义的玩法验收点全部通过,截图存档到 scratchpad 对应目录。2.4 运行方式 实测
PRE-04 · 原始代码/日志 · 对应 SRC-V04
# 方式一:双击 start.command(自动选空闲端口并打开浏览器) # 方式二:手动 cd king && python3 -m http.server 9201 # 端口需先 lsof 确认空闲 # 浏览器打开 http://localhost:9201 → 选将界面 → 锁定 → 开局 # 测试钩子:?demo=1&hero=arthur&speed=8(自动演示+8倍速)
为什么这不是一个“带动画的普通网页”
最终产物同时维持地图、固定步长仿真、10 名英雄、四类 AI、兵线与建筑、技能状态、经济装备、HUD、小地图、音效和特效。下面 26 张图只使用冻结代码、运行截图与验收记录,逐层解释这些系统如何在同一局游戏里互相影响。
A. 系统规模与代码结构 最终代码
PRE-05 · 原始代码/日志 · 对应 KING-V04
state = new GameState({ scene: engine.scene, mapData, vfx }); 源码画面与代码对应:最终画面同时消费地图、单位状态、AI结果、HUD和表现层输出。
画面与代码对应:玩法不是若干孤立演示,而是通过调用、共享状态和事件形成闭环。
画面与代码对应:17个模块形成可静态复算的跨领域运行结构。
画面与代码对应:核心玩法、世界和引擎合计占主要代码体量,产物不是单页UI拼装。
B. 战场与世界生成 配置+画面
画面与代码对应:地图同时承担路线、建筑、资源、视野和基地攻防拓扑。

PRE-06 · 原始代码/日志 · 对应 KING-V06
const tex = new THREE.CanvasTexture(cv); 源码
画面与代码对应:地图画面能与坐标配置、Canvas纹理及Three.js构建代码逐项对应。

PRE-07 · 原始代码/日志 · 对应 KING-V07
isCrystalInvuln(crystal) { 源码画面与代码对应:“推水晶”依赖建筑顺序、守卫减伤、AI目标和导航同时成立。

PRE-08 · 原始代码/日志 · 对应 KING-V08
this.objectives = this.camps.filter(c => c.id === 'tyrant' || c.id === 'overlord'); 源码
画面与代码对应:野区并非装饰,它通过刷新、Buff、团队奖励、视野和AI决策改变战局。
C. 实时仿真主循环 运行代码
画面与代码对应:玩法时间与显示刷新被明确分离,并提供补步上限和加速验收入口。
画面与代码对应:每个逻辑步不是单一动画更新,而是十类相互依赖的世界演算。
画面与代码对应:不同单位共享结算基础,但生成、奖励、重生和终局语义不同。
D. 5v5与多类AI 最终代码
画面与代码对应:运行时确实装配蓝4+红5共9个AI英雄,验收也读到双方各5名英雄。
画面与代码对应:9名AI英雄不只是“向前走”,而是在生存、回防、团战、资源与终局之间按优先级分流。
画面与代码对应:兵线同时连接时间、AI、经济、建筑无敌、终局和防卡死机制。
画面与代码对应:同一局中存在四套不同AI规则,并通过共享空间查询与伤害状态互相作用。
E. 英雄、技能与战斗 最终代码
画面与代码对应:15项技能并非仅更换名称,而是包含不同瞄准、弹道、控制、状态和位移实现。
画面与代码对应:技能输入与空间目标至少覆盖六类不同语义,HUD、玩家和AI都需适配。
画面与代码对应:一次施法横跨输入、固定tick、技能系统、状态结算和表现层,不是单个CSS动画。
画面与代码对应:伤害结果继续驱动控制、死亡、经济、等级、统计、重生与胜负。

PRE-09 · 原始代码/日志 · 对应 KING-V18
hud.onSkill = (slot) => state.queueAction(slot); 源码
画面与代码对应:截图中可见对象能逐项定位到冻结代码,画面不是与源码脱节的宣传渲染。
F. 成长、经济与完整对局 代码+验收


PRE-10 · 原始代码/日志 · 对应 KING-V21
showResult() { 源码画面与代码对应:选将与结算均有冻结画面,最终验收还记录水晶胜负和重开成功。
画面与代码对应:金币经验不是装饰数字,而会修改技能、英雄面板、装备和推进能力。
画面与代码对应:一局比赛由多个长短时间轴并行推进,测试终局必须等待或使用受控倍速。
G. 程序化表现、界面与工程路线 最终代码
画面与代码对应:现有代码未依赖外部模型、贴图、音频或字体URL,画面和声音主要由代码生成。

PRE-11 · 原始代码/日志 · 对应 KING-V24
minimap.update(state, dt); 源码
画面与代码对应:HUD不只是静态皮肤,它读取共享状态并把玩家输入送回固定逻辑循环。
画面与代码对应:现有单机原型已经接通跨系统运行链,并在指定浏览器路径完成终局验收。
ZhikunCode 的工程运行时:这次会话观测到了什么
本章把证据分成三层:本次会话日志直接观测、窗口前固定源码快照中的机制、以及二者对应后形成的架构归因。协调者-Worker编排、上下文治理、工具生命周期、时限接力与浏览器反馈都有可复算记录;没有在本案出现的产品能力不会被写成成功原因。
Kimi负责生成,ZhikunCode负责让工作继续
模型请求只是其中一层。协调循环、工具管线、上下文治理、浏览器反馈与持久化共同把一次回答变成数小时的工程过程。
本节把平台源码机制与窗口内日志放在同一张剖面上,让请求循环、工具执行、上下文治理和浏览器反馈逐层对齐。
数据:E26 / E27 / E28 / E29 / LLM事件 + 工具日志 + WebBrowser记录|图中结论:模型推理、运行时执行和真实浏览器观察形成多轮闭环
查看来源与复算数据
- 数据来源
- LLM事件 + 工具日志 + WebBrowser记录
- 复算口径
- 模型推理、运行时执行和真实浏览器观察形成多轮闭环。
图中指标
- Kimi请求878
fact.llm.started - 工具调用968
fact.tools.total - WebBrowser376
fact.browser.calls - 原子写入267
fact.controls.atomic
数据:E26 / E27 / E28 / E29 / 用户消息 + 平台源码 + 冻结日志|图中结论:角色职责可由输入、MDC agent字段、工具和证据记录区分
查看来源与复算数据
- 数据来源
- 用户消息 + 平台源码 + 冻结日志
- 复算口径
- 角色职责可由输入、MDC agent字段、工具和证据记录区分。
图中指标
- 责任层6
- 根Run1
- Worker Run10
- 证据域7
循环能够持续,还要回答上下文如何控制、工具如何闭合、平台源码与本次日志如何互证。
数据:E26 / E27 / E28 / E29 / ea0170c QueryEngine.java + 878 started事件|图中结论:源码八步循环与多轮模型/工具记录时间上对应
查看来源与复算数据
- 数据来源
- ea0170c QueryEngine.java + 878 started事件
- 复算口径
- 源码八步循环与多轮模型/工具记录时间上对应。
图中指标
- 源码步骤8
- started878
fact.llm.started - completed873
fact.llm.completed - cancelled5
fact.llm.failed
数据:E26 / E27 / E28 / E29 / ContextCascade日志 + context_cascade_evaluation|图中结论:878次调用前均评估预算
查看来源与复算数据
- 数据来源
- ContextCascade日志 + context_cascade_evaluation
- 复算口径
- 878次调用前均评估预算;26次轻量折叠释放2,029字符。
图中指标
- 评估878
fact.context.evaluations - 轻折叠26
fact.context.collapses - 峰值240,202
- 阈值650,000
数据:E26 / E27 / E28 / E29 / ea0170c ToolExecutionPipeline + 冻结应用日志|图中结论:968个复合键均有Stage1、Stage5和完成记录
查看来源与复算数据
- 数据来源
- ea0170c ToolExecutionPipeline + 冻结应用日志
- 复算口径
- 968个复合键均有Stage1、Stage5和完成记录。
图中指标
- Stage1968
- Stage5968
- 完成记录968
- 错误17
fact.tools.error
数据:E26 / E27 / E28 / E29 / ea0170c七个类 + 日志组件名 + Git时间边界|图中结论:七个运行时类在窗口前提交中已存在,多项同名出现在日志
查看来源与复算数据
- 数据来源
- ea0170c七个类 + 日志组件名 + Git时间边界
- 复算口径
- 七个运行时类在窗口前提交中已存在,多项同名出现在日志。
图中指标
- 固定源码类7
- 窗口前提交ea0170c
- 窗口后提交74aef15
- 运行构建SHA缺失
控制面让每类故障留下明确终态,也让后续循环知道从哪里接。
数据:E26 / E27 / E28 / E29 / observability-events-20260809-0130-0701.jsonl|图中结论:LLM、进程、Worker、终止和输入事件均有类型化记录
查看来源与复算数据
- 数据来源
- observability-events-20260809-0130-0701.jsonl
- 复算口径
- LLM、进程、Worker、终止和输入事件均有类型化记录。
图中指标
- 事件总数2,003
- LLM开始878
- LLM终态878
- Worker终态10
数据:E26 / E27 / E28 / E29 / AtomicFileWriter + CheckpointService + MCP日志|图中结论:267次原子写入、157次Checkpoint保存和60组重连可复算
查看来源与复算数据
- 数据来源
- AtomicFileWriter + CheckpointService + MCP日志
- 复算口径
- 267次原子写入、157次Checkpoint保存和60组重连可复算。
图中指标
- Atomic write267
fact.controls.atomic - Checkpoint157
fact.controls.checkpoint - 重连配对60
fact.controls.reconnectPairs - 实际Checkpoint恢复0
数据:E26 / E27 / E28 / E29 / 冻结SQLite导出|图中结论:会话、消息、活动和交互请求通过sessionId形成可查询关系
查看来源与复算数据
- 数据来源
- 冻结SQLite导出
- 复算口径
- 会话、消息、活动和交互请求通过sessionId形成可查询关系。
图中指标
- sessions1
- messages229
- activities113
- interactions4
数据:E26 / E27 / E28 / E29 / 安全审计 + interaction_requests + 工作目录|图中结论:开发窗口权限请求为0,工具在指定工作目录和既有授权内运行
查看来源与复算数据
- 数据来源
- 安全审计 + interaction_requests + 工作目录
- 复算口径
- 开发窗口权限请求为0,工具在指定工作目录和既有授权内运行。
图中指标
- 开发permission请求0
- 安全日志行116
- 工作目录1
- GitHub发布0
3.1 协调者-Worker 运行时(实测协议全链路) 日志 数据库
TABLE-09 · 原始表格 · 对应 PLAT-V02
| 环节 | 本次会话的真实记录 | 证据位置 |
|---|---|---|
| ① 任务下发 | 协调者调用 Agent 工具,附完整自包含提示词(1,606–3,046 字符)与 DESIGN.md 路径 | db/session-messages.json 中 10 个 tool_use:Agent 块原文 |
| ② 指纹登记 | 平台记录 promptLength 与 promptFingerprint(SHA-256),可检验公开提示词与运行记录是否一致;该本地指纹不构成第三方不可抵赖证明 | observability 的 subagent_started 事件(PART 4.3 指纹表) |
| ③ 独立会话 | 每个 Worker 获得独立 childSessionId(subagent-agent-64f62e42 等),Token 按会话独立归账 | 观测事件 data.childSessionId;PART 4.2 分账表 |
| ④ 时限看护 | 单次运行 30 分钟边界:6 次 run_termination_summary: deadline_exceeded 精确到秒(1800.0s,与 activities 表 duration 毫秒值互证) | 观测事件;activities 表 |
| ⑤ 结果回传 | Worker 结束以 <task-notification> XML 回传:task-id/status/summary/result/usage(duration_ms) | db/session-messages.json(user 角色封装) |
| ⑥ 协调者复核 | 协调者不照单全收:另开验收步骤,用 WebBrowser 实测后再决定续作/换将;这是同一系统内的隔离上下文复核,不是第三方独立审计 | PART 6 的 4 个阻塞或高影响问题记录 |
task-notification 协议实例(R02 战斗核心 Worker 的回传原文节选)
<task-notification>
<task-id>agent-1c86cd96</task-id>
<status>completed</status>
<summary>t=55.8 三路全部交战、0 错误。截图 1(小兵交战):</summary>
<result>t=55.8 三路全部交战、0 错误。截图 1(小兵交战):</result>
<usage><duration_ms>1799990</duration_ms></usage>
</task-notification>
# 注意 duration_ms=1,799,990 ≈ 1800.0s:Worker 在时限边界被回收,summary 停在"截图1"——
# 协调者随后在同系统内复测确认成果可继续使用(PART 4 时间线)。status=completed 由平台终态机给出,
# 与"汇报被截断"并存:这正是需要协调者二次验收的原因。3.1b Kimi × ZhikunCode 运行时 × 浏览器反馈:三层闭环 日志 推断
① Kimi K3
观测事件记录本次 LLM 调用的模型为 kimi-k3、提供方为 Moonshot;会话消息保留了推理、代码生成请求和工具调用上下文。
② ZhikunCode 运行时
协调者把任务拆给 10 次 Worker 运行,负责工具执行、独立子会话、30 分钟边界、轮次上限、中断接续、落盘与最终汇总。
③ 真实浏览器反馈
应用日志按 sessionId + runId + toolUseId 去重后包含 376 次 WebBrowser 调用;376个复合键又分别对应一个唯一Java→Python下游请求ID,用于打开游戏、读取状态、执行断言和截图复核。
PRE-13 · 原始代码/日志 · 对应 PLAT-V01
Kimi 生成与分析 → ZhikunCode 编排并执行 → 浏览器运行与观测
↑ ↓
└──────────── 定向修复与复验 ────────────┘这条闭环解释了代码为何能够持续收敛:Kimi生成与分析,ZhikunCode负责拆解、执行和保存,376次唯一WebBrowser调用把真实页面状态送回后续轮次。平台级成功率与成本稳定性将在重复任务基准中继续量化。
3.1bb 标识符级追溯:从根 Run 到 Python 请求的七层血缘链 日志实测 复合键
冻结应用日志不是靠时间猜测归属。MDC 字段把协调者、Worker、轮次、模型请求、工具调用与下游请求串成一条可重建链;下面使用 01:55:36 的真实 WebBrowser_26 调用,不使用示意ID。
TABLE-10 · 原始表格 · 对应 LOG-V01
| 原始字段 | 报告别名 | 关联用途 | 字段口径 |
|---|---|---|---|
sid | sessionId | 区分根会话与10个Worker子会话 | 本地会话主键 |
rid | runId | 区分一次Agent Loop执行 | 同一会话可随时间出现不同Run |
prid | parentRunId | 把10个子Run直接连回根Run | -表示该日志行没有父Run |
agent=query|subagent | 执行角色 | 区分协调者与Worker | 角色来自MDC;观测事件的agentType=general-purpose不用于角色判定 |
turn | Agent轮次 | 把模型与工具放回具体循环轮次 | 轮次不是质量评分 |
llm / data.requestId | llmRequestId | 配对LLM started与唯一终态 | 失败后新requestId不是同一请求重试 |
MDC tool / 正文toolUseId | toolUseId | 与sessionId、runId组成工具复合键 | 裸序号会跨Run复用 |
Python日志requestId | downstreamRequestId | 连接Java工具与Python浏览器服务 | 与浏览器返回值和验收断言配合使用 |
画面与代码对应:冻结窗口可重建11个会话、11个Run、10条父子关系;此浏览器调用可从根Run追到唯一Python请求与终态。
3.1c 为什么能完成:平台机制与本案观测逐项对应 源码机制 日志实测 架构归因
四份平台说明材料最有价值的用途,不是再罗列“40+工具”或其他产品总量,而是帮助解释冻结日志中已经观测到的类、管线和控制点。下面这张图只画本案例实际留下记录的路径:
QueryEngine · 多轮 Agent Loop
TABLE-11 · 原始表格 · 对应 PLAT-V03
| 源码机制 | 本案直接观测 | 工程作用 | 本次运行口径 |
|---|---|---|---|
QueryEngine 8步循环 | 878 started / 873 completed / 5 failed | 任务由多轮模型与工具循环推进,不是一次提示直接生成 | 内部条件分支由固定源码快照补充定位 |
ContextCascade | 878次唯一评估,与878次模型启动一一对齐 | 每次模型调用前均执行了上下文预算治理 | 最高上下文低于阈值,重型恢复链本次无需启动 |
ToolExecutionPipeline | 968次调用均有验证、实际调用和完成记录 | 工具经过统一、可审计的生命周期 | 完成记录继续区分951次error=false与17次error=true |
SubAgentExecutor | 10次Worker启动、独立childSessionId和终止事件 | 专业分工由真实子会话和独立Agent Loop执行 | 本案记录1次自然完成、6次期限回收、3次轮次回收 |
WebBrowser | 376次唯一工具调用 | 真实页面观察进入了实现和复验闭环 | 376是唯一调用数;验收通过项由V01–V12单独统计 |
CheckpointService | 157次保存 | 长任务持续产生可恢复状态点 | 157次保存;开发窗口内Checkpoint恢复事件为0 |
源码结构与执行记录在这里形成同一条解释链:模型负责生成和判断,运行时负责持续执行,浏览器负责返回真实环境状态;三层贡献的定量拆分留给后续消融实验。
3.1d 超长任务为什么没有失去上下文:878轮治理实测 日志实测 可复算
冻结应用日志包含878 次唯一上下文评估,恰好对应878次 llm_call_started。每轮均尝试轻量 ContextCollapse:50轮没有候选、802轮没有净收益、26轮实际产生正收益,合计释放2,029 个字符。最高估算为240,202 tokens,仍低于650,000阈值,因此没有触发 AutoCompact、CollapseDrain、ReactiveCompact 或413恢复。
上下文治理覆盖全部878轮模型调用,并执行了26次轻量折叠。最高估算为240,202 tokens,低于650,000阈值,因此本次任务无需启动重型压缩与413恢复链。
3.1e 源码类名与日志组件同名:版本锚点与边界 源码机制 版本边界
开发窗口前最近的仓库提交是 ea0170c(2026-08-09 00:42:02+08)。窗口后的下一次提交是 74aef15(12:04:07+08),只修改README与三份架构/能力说明文档;下列运行时源码在两提交之间逐字节不变:
循环、上下文与工具
这些类名不是报告事后杜撰:它们存在于窗口前源码快照,其中多项类名还直接出现在冻结日志中。不过本案日志没有写入运行二进制的Git SHA;所以 ea0170c 是“时间上对应、相关源码随后未变”的高可信快照,不是对当时运行二进制的密码学认证。机器复核见 verification.json.platformSnapshot。
3.2 可观测事件流(2,003 条结构化事件的解剖) 日志
事件信封结构
PRE-14 · 原始代码/日志 · 对应 PLAT-V07
2026-08-09T01:31:15.223+08:00 {
"eventType":"llm_call_started",
"runId":"eb2e9ba2-6975-4c83-9e83-8eebcb7f1b10",
"data":{"model":"kimi-k3","provider":"moonshot",
"sessionId":"b8f86099-...","turn":1,
"requestId":"llm-f32308a5-..."}}本地时间前缀 + UTC occurredAt 双时间戳;runId 串联一次运行,requestId 串联 started/completed 配对。
事件类型全景(复算命令见附录 A.2-5)
llm_call_started 878 / completed 873 / failed 5;subagent_started 10 / completed 7 / failed 3;process_started/finished 各 104;run_termination_summary 6;run_input_applied 1。started 与 completed 的差值(5)恰好等于 failed 数——事件账自洽。
3.2b 持续写入、Checkpoint 与 MCP 连接恢复 日志 实测
TABLE-12 · 原始表格 · 对应 PLAT-V08
| 观测机制 | 窗口内精确数量 | 日志证据 | 运行口径 |
|---|---|---|---|
| 原子文件写入 | 267 次成功原子写入 | AtomicFileWriter - Atomic write successful | 267次成功事件逐条留痕;文件去重和内容校验由代码快照与SHA清单另行完成 |
| 运行Checkpoint | 157 次 Checkpoint 保存 | CheckpointService - Checkpoint saved | 157次保存逐条留痕;本次开发通过落盘产物与后续轮次接续,Checkpoint恢复事件为0 |
| MCP连接恢复 | 60 组完整配对:60次断线、60次成功重连、0个未配对事件 | zhipu-websearch connection lost → reconnected successfully | 60次断线均出现后续成功重连;开发效率影响留给单独性能分析 |
配对方法:验证脚本按冻结应用日志的原始顺序扫描;每条 connection lost 必须由下一条同服务器成功重连闭合,且不允许嵌套断线、孤立重连或窗口结束后仍有未闭合断线。三个数字均来自本案例开发窗口内的实际记录。
3.2c 成功来自容错攻坚,而不是一次收敛 日志实测 边界
TABLE-13 · 原始表格 · 对应 LOG-V03
| 局部故障或终止 | 窗口内记录 | 随后可确认的事实 |
|---|---|---|
| 模型调用失败 | 878次started中5次failed、873次completed;5次均为cancelled/status 0/attempt 1 | 事件账按requestId闭合为878=873+5;失败点后仍出现新的全局请求或协调者活动,但后续活动使用新的requestId |
| 工具结构化错误 | 968次完成记录中17次 error=true | 错误没有从执行账中消失,后续Agent Loop仍能继续读取结果和调用工具 |
| Worker边界 | 1次自然完成、6次30分钟期限、3次最大轮次 | 协调者读取已落盘成果并另起续作Worker,最终完成统一验收 |
| MCP连接波动 | 60次断线、60次成功重连、0个未闭合事件 | 后台连接按日志顺序逐次恢复;不推断其对开发效率的影响 |
| 中间状态保护 | 267次原子写入、157次Checkpoint保存 | 持续写入和保存事件存在;没有证据表明本案实际执行过Checkpoint恢复 |
3.2d 局部故障如何留下终态,并由后续轮次接续 日志实测 因果边界
画面与代码对应:故障、错误和运行边界没有被成功叙事抹去;终态可以分类并复算,之后仍有全局模型调用、续作和最终验收活动。
3.3 持久化拓扑(SQLite 四层,本次会话实测行数) 数据库
TABLE-14 · 原始表格 · 对应 PLAT-V09
| 层 | 表 | 本会话行数 | 内容 |
|---|---|---|---|
| 会话层 | sessions | 1 | 创建时间/模型/工作目录/Token 累计字段 |
| 消息层 | messages | 229(窗口冻结) | 完整对话:用户输入、协调者回复与工具调用、Worker 通知 |
| 活动层 | activities | 113(窗口冻结) | 每次工具调用:时刻/耗时毫秒/决策/结果原文/变更文件 |
| 交互层 | interaction_requests | 4(窗口冻结) | 4 项需求确认;开发窗口内 permission 为 0 |
四层交叉:messages 的 Agent 调用 ↔ observability 的 subagent_started ↔ activities 的 1800.0s duration,三个本地记录面可以核对同一事件。它们由同一套本地系统产生,属于共享信任域,交叉一致能发现偶发缺失或统计错误,但不等同于三个独立第三方来源。
3.4 权限与安全门控 数据库
TABLE-15 · 原始表格 · 对应 PLAT-V10
| 时刻(+08,撰写期) | 工具 | 风险级 | 原因原文(摘要) | 决策 | 范围 | operationHash(前 16 位) |
|---|---|---|---|---|---|---|
| 09:55:44 | Bash_119 | safe | Read access requires confirmation(ls 项目外目录) | allow | session | a104c7ae78fdc12e… |
| 09:55:46 | Bash_120 | safe | Read access requires confirmation(ls -R 素材目录) | allow | session | 5502cbd20013f90d… |
| 09:56:25 | Read_121 | guarded | Read outside Project(读规范文档) | allow | session | 5d48d2cc380cdcf4… |
| 09:57:07 | Agent_126 | guarded | Agent exact invocation(启动子 Agent) | allow | once | ac31055052341761… |
| 09:57:22 | Read_2 | guarded | Read outside Project | allow | once | 8e4fb7e727313cee… |
| 09:57:30 | Read_3 | guarded | Read outside Project(同 hash 复授权) | allow | session | 8e4fb7e727313cee… |
| 09:59:23 | Read_15 | guarded | Read outside Project | allow | session | a01211cb4528a6db… |
表中 7/7 均为用户本人批准;完整窗口外冻结补充中的 9 条 permission 状态均为 answered。operationHash 对操作内容做指纹(同操作复授权时 hash 相同,第 5/6 行可见)。开发窗口内另有 security-audit 日志 116 行逐工具审计。
3.5 工具门控的实测证据(本报告撰写期真实发生) 记忆
撰写本报告时,协调者连续 3 次用 Edit 修改案例 HTML 被平台拦截:"请先使用 Read 工具读取文件内容"——强制"先读后改"的门控在真实工作流中触发并被记录。同一晚,游戏开发期的 Edit 调用 59 次全部遵循该约束。
3.6 连接活性(WebSocket 心跳) 日志
应用日志窗口首行(01:30:01)与末行(07:00:41)均为同一会话的 push(pong) to principals=1, sessionId=b8f86099-… 心跳记录,会话标识 5.5 小时保持不变。(审计注记:本报告早前版本曾断言"全程无重连"——该断言未经全量日志逐行验证,已撤除,仅保留可复核的首末行事实。)
10 个子 Agent 汇入同一个项目
协调者(主会话)负责需求确认、撰写开发规范 DESIGN.md、逐阶段同系统复测与一次直接代码修复;10 个子 Agent 按"地基→玩法→AI→攻坚×3→UI→视觉→修复→QA"接力执行。所有起止时间取自观测事件日志,精确到秒;每个 Agent 的 Token 消耗按 childSessionId 分账。
十次Worker不是十段宣传语,而是十条可追踪运行
一个根Run先后接住10个Worker:只有1次自然完成,6次到达期限,3次到达最大轮次。项目依靠落盘成果和后续复验继续向前。
时间轴保留停顿、回收和接续,可以直接看到一次复杂攻坚如何在十次Worker之间向前接力。
数据:E03 / E16 / E24 / E39 / 关键时间表 + Run/Token/预算/接续五组原账|图中结论:共享时间轴可显示阶段、运行边界、资源投入和交付演进
查看来源与复算数据
- 数据来源
- 关键时间表 + Run/Token/预算/接续五组原账
- 复算口径
- 共享时间轴可显示阶段、运行边界、资源投入和交付演进。
图中指标
- 全部Run11
fact.run.total - Worker Run10
fact.run.workers - LLM started878
fact.llm.started - 工具调用968
fact.tools.total
数据:E03 / E16 / E24 / E39 / logs.traceability.mappings|图中结论:11个session、11个run和10条parentRun边均可复算
查看来源与复算数据
- 数据来源
- logs.traceability.mappings
- 复算口径
- 11个session、11个run和10条parentRun边均可复算。
图中指标
- sessions11
fact.run.total - runs11
fact.run.total - parent edges10
fact.run.workers - root1
有了父子DAG,再把时长、Token、提示词和交付物放回同一时间轴,就能看见接力的真实投入。
数据:E03 / E16 / E24 / E39 / 10份Agent提示词 + 产物谱系|图中结论:地图、战斗、AI、终局、UI、视觉、性能和QA任务依次接力
查看来源与复算数据
- 数据来源
- 10份Agent提示词 + 产物谱系
- 复算口径
- 地图、战斗、AI、终局、UI、视觉、性能和QA任务依次接力。
图中指标
- Worker10
- 责任域6
- 构建阶段5
- 修复/QA5
数据:E03 / E16 / E24 / E39 / observability按childSessionId归账|图中结论:11个执行体的调用、输入、输出和占比可精确求和
查看来源与复算数据
- 数据来源
- observability按childSessionId归账
- 复算口径
- 11个执行体的调用、输入、输出和占比可精确求和。
图中指标
- 执行体11
- 运行输入82,300,554
- 运行输出670,170
- 终态类型3
数据:E03 / E16 / E24 / E39 / subagent_started promptLength/promptFingerprint + D…|图中结论:10份提示词均有长度和SHA-256指纹,后期引入时间预算
查看来源与复算数据
- 数据来源
- subagent_started promptLength/promptFingerprint + DB原文
- 复算口径
- 10份提示词均有长度和SHA-256指纹,后期引入时间预算。
图中指标
- 提示词10
- 最短1,606
- 最长3,046
- 唯一指纹10
阶段谱系使用日志、文件和截图中能够直接定位的锚点。
数据:E03 / E16 / E24 / E39 / 日志 + 会话消息 + 代码快照 + 截图|图中结论:八个里程碑可关联产出Run和锚点证据
查看来源与复算数据
- 数据来源
- 日志 + 会话消息 + 代码快照 + 截图
- 复算口径
- 八个里程碑可关联产出Run和锚点证据。
图中指标
- 里程碑8
- 构建Run3
- 修复Run6
- Git阶段快照0
数据:E03 / E16 / E24 / E39 / db/activities-20260809-0130-0701.json|图中结论:协调者执行环境探测、浏览器复验、直改、轮询和收口
查看来源与复算数据
- 数据来源
- db/activities-20260809-0130-0701.json
- 复算口径
- 协调者执行环境探测、浏览器复验、直改、轮询和收口。
图中指标
- activities113
- 工具类型9
- 全部工具968
- 窗口01:30–07:01
数据:E03 / E16 / E24 / E39 / activities + 会话消息 + DESIGN.md|图中结论:先确认范围、探测目录/工具/CDN,再本地化依赖和启动R01
查看来源与复算数据
- 数据来源
- activities + 会话消息 + DESIGN.md
- 复算口径
- 先确认范围、探测目录/工具/CDN,再本地化依赖和启动R01。
图中指标
- 范围确认39.561s
- Preflight跨度8m53s
- CDN 2002
- R01启动01:39:58
4.0 Preflight:承诺方案前先验证依赖(01:31–01:39,8 分钟) 日志 记忆
TABLE-16 · 原始表格 · 对应 RUN-V08
| 时刻(+08) | 动作 | 结果与证据 |
|---|---|---|
| 01:31:15 | 收到需求 → 同一秒发出唯一一轮确认(4 项) | DB 首条消息;observability 第 1 行 turn=1 |
| 01:32:05–01:32:44 | 用户完成 4 项选择(首项创建至末项决定落库 39.6 秒) | interaction_requests 窗口冻结导出中的 4 条 elicitation(PART 1.2b) |
| 01:34:55 | 项目目录勘察:ls -la king/ → 空目录;确认 python3/node/npx 可用 | activities 表 Bash_1(duration 4,189ms,决策 approved) |
| ≈01:35 | CDN 双源可达性实测:curl -sI jsdelivr 与 unpkg 的 three.js r160 | 双双 HTTP 200 → 决策:vendored 本地化(lib/three.module.js 1,272,972 B);测试运行中无需外部 HTTP 资源(G01 锚点) |
| 01:36–01:39 | 撰写 DESIGN.md 开发规范 → 01:39:58 启动 R01 | DESIGN.md(2.3 全文);observability 第 13 行 |
意义:技术方案不是"选出来的"而是"验证过的"——先证明 three.js 可离线落地,再向用户承诺 3D 锁视角方案;先确认端口占用实况,再把端口规则写进规范。
4.1 逐 Run 执行账本 日志
TABLE-17 · 原始表格 · 对应 RUN-V01
| Run | Agent ID | 任务 | 开始 → 结束 | 持续 | 终态 | 关键产出 |
|---|---|---|---|---|---|---|
| R01 | agent-64f62e42 | 阶段1:地基与 3D 地图 | 01:39:58 → 02:09:58 | 30m00s | 30m 运行边界 | 项目骨架、王者峡谷全图、相机/摇杆、可行走英雄;1,777 行 |
| R02 | agent-1c86cd96 | 阶段2:战斗核心 | 02:12:10 → 02:42:10 | 30m00s | 30m 运行边界 | 单位/小兵波次/防御塔/5 英雄技能/弹道/特效;4,017 行 |
| R03 | agent-1c9d320a | 阶段3:英雄 AI 与野区 | 02:47:40 → 03:17:40 | 30m00s | 30m 运行边界 | 9 个 AI 英雄、野怪/BUFF/龙、装备自动购买;ai.js 704 行 |
| R04 | agent-ea473eef | 修复1:小兵堵路 | 03:22:34 → 03:52:34 | 30m00s | 30m 运行边界 | 路径点放宽+横向偏移+卡死自救;小兵峰值 113→46 |
| R05 | agent-bf99fd68 | 修复2:终局僵持 | 03:59:35 → 04:29:35 | 30m00s | 30m 运行边界 | 超级兵/小兵成长/GROUP_PUSH;推塔提速 |
| R06 | agent-6b9d1e29 | 修复3:英雄攻不进基地 | 04:41:25 → 05:06:33 | 25m08s | 正常收尾 | 门径路由+ASSAULT 模式+水晶梯度减伤;3/3 局分出胜负 |
| R07 | agent-596000a2 | 阶段4:完整 UI/音效/播报 | 05:07:33 → 05:35:06 | 27m33s | 轮次上限 | 选将/小地图/商店/播报/TTS/结算;自报 17 分钟完整对局验证 |
| R08 | agent-392c10e7 | 阶段5:视觉打磨与性能 | 05:38:41 → 06:08:41 | 30m00s | 30m 运行边界 | 5 英雄模型重做、特效升级;留下发光 bug 与 FPS 问题 |
| R09 | agent-9b527904 | 修复4:发光 bug+性能 | 06:10:19 → 06:32:05 | 21m46s | 轮次上限 | 闪红改独立壳层(杜绝共享材质污染)、DOM 血条节流;FPS 6→31.8 |
| R10 | agent-adc6f86f | 阶段6:隔离上下文的同系统 QA | 06:33:42 → 06:52:45 | 19m03s | 轮次上限 | 逐项验收;发现"塔攻击无音效事件"等小问题(列入遗留清单 L5) |
口径:起止时间取自 observability-events 的 subagent_started/completed/failed 事件(PART 8.6 有带行号的摘录)。"30m 运行边界"= 触平台单次运行时限(run_termination_summary: deadline_exceeded,共 6 次);协调者检查落盘产物后决定续作或换将,后续运行继续使用了这些产物。本表不含本报告撰写期的模板分析 Agent(在证据窗口外)。
4.2 每个 Agent 的 Token 消耗(按 childSessionId 从观测日志归账) 日志
TABLE-18 · 原始表格 · 对应 RUN-V04
| 执行体 | LLM 调用 | 输入 Tokens | 输出 Tokens | 输入占比 |
|---|---|---|---|---|
agent-392c10e7(R08 视觉) | 89 | 14,306,471 | 79,050 | 17.4% |
agent-596000a2(R07 UI) | 99 | 11,419,635 | 71,347 | 13.9% |
agent-9b527904(R09 修复) | 99 | 10,409,207 | 44,254 | 12.6% |
agent-6b9d1e29(R06 门径) | 79 | 7,558,607 | 60,844 | 9.2% |
| 协调者主会话(b8f86099) | 112 | 7,386,868 | 58,959 | 9.0% |
agent-bf99fd68(R05 僵持) | 68 | 7,072,446 | 57,965 | 8.6% |
agent-1c9d320a(R03 AI) | 63 | 6,097,161 | 63,680 | 7.4% |
agent-64f62e42(R01 地基) | 76 | 5,462,430 | 65,610 | 6.6% |
agent-adc6f86f(R10 QA) | 99 | 4,791,026 | 31,223 | 5.8% |
agent-ea473eef(R04 堵路) | 51 | 4,587,665 | 52,969 | 5.6% |
agent-1c86cd96(R02 战斗) | 38 | 3,209,038 | 84,269 | 3.9% |
| 合计(=观测日志全量) | 873 | 82,300,554 | 670,170 | 100% |
交叉验证:协调者主会话的 7,386,868 / 58,959 与 DB messages 表 assistant 消息 Token 合计逐数字一致。这是同一套本地系统的两个记录面(运行时观测与持久化层)之间的一致性检查,不构成两个独立信任源。
4.3 提示词指纹(subagent_started 事件原值) 日志
TABLE-19 · 原始表格 · 对应 RUN-V05
| Agent | promptLength | promptFingerprint(SHA-256 前 32 位) |
|---|---|---|
agent-64f62e42 | 2,697 | 09c80cd95868ddaef0094b42c6b0ac5e… |
agent-1c86cd96 | 2,733 | 46fd448559af24dd3ee0dafcf5508263… |
agent-1c9d320a | 2,285 | e883a6d430072945478c59e7f119b5f9… |
agent-ea473eef | 1,720 | ebe6ee5a8321b92d2b754dc865531582… |
agent-bf99fd68 | 1,757 | 6b42a0f6e80dce7936423fc3bf64a5be… |
agent-6b9d1e29 | 1,782 | cd24bda635b5c7bc6e584ccb4e1adb26… |
agent-596000a2 | 3,046 | 9f5a260f2f97cf913d15a689c5727255… |
agent-392c10e7 | 1,970 | c8b49670a301e3602b70f0a8f78f329e… |
agent-9b527904 | 1,606 | 8f29c1e3b9eaa0e93f3b435e4dd023e9… |
agent-adc6f86f | 1,842 | 70ed9a2c5db5cd4ecf86015833eb9059… |
提示词全文保存在会话消息记录(db/session-messages.json 的 assistant 工具调用块)中,可与指纹逐字校验。
4.4 提示词原件示例:R05"修复终局僵持与推水晶"完整提示词(1,757 字符,与指纹 6b42a0f6… 对应)
这是一个 Web 版"王者荣耀"MOBA 项目(Three.js,本地静态站点,项目目录 <PROJECT_ROOT>/)的终局玩法修复任务。游戏已有完整 5v5、三路小兵、防御塔、野区、技能、AI。前一个修复解决了小兵堵路,现在兵线和推塔正常,但**终局僵持**:实测一局 4 倍速跑到 t=1350s(22.5 分钟),红方 9 塔全破、蓝方 14:6 领先,但红水晶满血 10000,比赛不结束。 ## 实测证据 - 12 个蓝方小兵已进入红方基地区域(pos.x>40 且 pos.z>40),但红水晶 HP 10000/10000 毫发无损——**小兵在敌方基地里不打水晶**(可能:水晶不在小兵目标筛选内/水晶无敌判定条件未随塔全破而解除/基地围墙挡住寻路)。 - 蓝方水晶反而被打到 7650:双方互相推基地但都无法终结,AI 在"回防-推线-回城"里死循环。 - 水晶对象上没有任何 vulnerability/shield 相关字段,无敌逻辑很可能写在伤害函数里。 ## 必读 1. 设计文档:<REPO_ROOT>/backend/.zhikun/scratchpad/b8f86099-452d-4ba6-89c2-c3fee8f4b422/DESIGN.md(水晶规则:任意一路 3 塔全破后水晶解除无敌;摧毁水晶=胜利) 2. 代码:src/game/state.js(伤害/无敌/死亡判定)、src/game/ai.js(小兵目标筛选与英雄 AI 状态机)、src/game/spawner.js(波次)、src/world/map.js(基地围墙碰撞体)、src/config.js。 ## 修复要求 1. **打通推水晶链路**:塔全破一路后水晶可被选中和攻击;小兵/炮车进基地后正确锁定水晶;基地围墙不能堵死进水晶的路(留门或调整碰撞)。 2. **终局加速机制(让比赛在 10-18 分钟分出胜负)**: - 一路 3 塔全破后,该路出兵附加"超级兵"(每波 1 个,HP/攻击约为炮车 1.5 倍,优先打塔和水晶)。 - 12:00 后小兵属性随时间成长(每分钟 +8% HP/AD)。 - 英雄 AI:敌方水晶已解防且己方存活 ≥3 人时进入 GROUP_PUSH 状态(集合推水晶),优先级高于打野/带线;守方在水晶被攻击时全员回防。避免无限"换家"僵持。 3. 保持零报错;不要破坏已有玩法(技能/野区/装备)。 ## 验证环境 - 服务:先 `lsof -iTCP:8787 -sTCP:LISTEN -P -n` 检查,8787 已有本项目 python 服务则复用;新起服务从 9201~9499 选并先确认空闲(本机端口紧张)。 - 验证:WebBrowser,`document.title==='KING_OK'`,`window.__errors` 为空;`window.__game.state`:units 是 Map,**单位存活用 `u.alive===false` 判断(没有 dead 字段)**;`?speed=4` 加速。evaluate 单次不要超过 25 秒,长等待用多轮 Sleep+短 evaluate。 ## 验收标准(全部满足) 1. `?demo=1&hero=arthur&speed=4` 连跑 2 局、再跑 `?demo=1&hero=daji&speed=4` 1 局:**3 局全部分出胜负**(state.winner 非空),游戏时间均在 10-18 分钟内。 2. 每局终局:胜方拆塔 ≥9 座+水晶;全程 `window.__errors` 为空;任意时刻单方存活小兵 <60。 3. 记录每局:终局时间、比分、双方拆塔数、水晶是如何被打掉的(小兵/英雄)。 4. 正常速度截图 2 张(超级兵推进、水晶被攻击场景)存 scratchpad p4fix/。 ## 汇报格式 根因(实际代码原因,文件:行号)、修复清单、3 局对局数据、截图路径、遗留问题。
审计注记:这里按证据原样保留了提示词中的 units 是 Map,但最终 state.js 实际将 units 定义为数组(this.units = [])。这是提示词里的陈旧类型说明,不是最终代码事实;u.alive===false 的存活判断仍与最终代码一致。公开这一处偏差,避免把原始提示词静默改写成“事后正确”。
4.5 交付汇报示例:R06"修复英雄攻不进基地"汇报原文(根因/修复清单/传送实验/对局数据照录;遗留问题段有删节)
修复完成。最终构建 3/3 局全部在验收窗口内分出胜负、英雄击杀水晶、零报错。 ## 根因(多层叠加,缺一不可) 1. **英雄永不选水晶为目标** — `src/game/ai.js` `_selectTarget`(原 ~437 行):`enemiesInRange` 默认 `structures:false`,交战索敌排除建筑;`GROUP_PUSH` 又"塔先水晶后"(有任何存活敌塔就走全图去拆塔)。实测传送红亚瑟到蓝水晶旁 11 单位,它无视水晶、走 56 单位去拆边塔。 2. **围墙卡死** — `src/world/map.js` 墙段碰撞体 r=1.9、间距 5.08(英雄需 2.8 净空,段间仅 1.28 → 等效连续墙);`_moveTo` 直线走法 + 0.5s 随机侧向绕行很难对准 3 个固定门(蓝方 45°/101.5°/−14°)。实测英雄贴墙原地不动。 3. **水晶数学上打不动** — `state.js dealDamage`:有存活塔即 ×0.1,叠加**战斗中持续回血** 100/s(原 ~1159 行每 tick 无条件 heal):单人 102/s×0.1≈10/s vs 回血 100/s → 永久满血。 ## 修复清单(最小侵入,均对称作用于双方 AI) | 文件 | 修改 | |---|---| | `src/config.js:87-118` | 新增 `BASE_GATES`:与 map.js 围墙缺口同几何算出每方 3 个门坐标(蓝 mid/top/bot ≈ (-57,-57)/(-76,-51)/(-51,-76),红方中心对称) | | `src/config.js:242` | 水晶守卫减伤:固定 ×0.1 → 每座存活塔 −8%(下限 30%)梯度 | | `src/config.js:340` | `GROUP_PUSH_MIN` 3→2 | | `src/game/ai.js:825-851` | 新增 `_gateRoute`:目标与自身分处任一基地围墙内外两侧 → 先走总程最短门点(3.2 内视为到门口直穿) | | `src/game/ai.js:854-855, 892-906` | `_moveTo` 接入门点路由;硬卡死自救:2s 位移<0.5 → 禁用当前门 4s 换门 + 侧向抖动 | | `src/game/ai.js:415-426` | 新增 `ASSAULT` 模式:水晶解防且自身在敌基地圈(WALL_R+2)内 → 水晶优先于缠斗(撤退/回防仍在更前面) | | `src/game/ai.js:438-451` | `GROUP_PUSH` 改水晶优先;索敌半径缩到贴脸 `max(4, range*0.8)`,不再被守军吸住 | | `src/game/state.js:443-447` | dealDamage 水晶守卫梯度实现 | | `src/game/state.js:1158-1160` | 水晶脱战 5s 后才回血(战斗中不再边打边回) | ## 传送实验(最终构建) - **基地内**:红亚瑟传送至蓝基地内 (-66,-66) → `ASSAULT` 模式,站定攻击,水晶 10000→8572 稳定掉血 ✓ - **墙外非门方向**:蓝后羿从 (55,88)(旧证据贴墙点)→ 自动选门 (51,76) → dBase 23.8→13.7 进入 → 攻击水晶 ✓ - 出基地(回城方向)同样走门,全程无卡死 ✓ ## 对局数据(`?demo=1&hero=arthur&speed=8`,最终构建 3 局) | 局 | 终局时间 | 比分(蓝:红) | 胜方 | 水晶击杀者 | __errors | | 1 | 18:47 (1127s) | 10:9 | red | 英雄·亚瑟 | [] | | 2 | 13:47 (827s) | 17:8 | red | 英雄·后羿 | [] | | 3 | 13:53 (833s) | 6:10 | red | 英雄·兰陵王 | [] | 回归检查:t=6min 时野营被清 3/10、打野等级/金币正常领先、推塔节奏 4:1 正常;终局帧 AI 模式分布 ASSAULT/GROUP_PUSH/DEFEND/TEAMFIGHT/RETREAT 齐全——推塔/野区/回防行为未破坏。 ## 遗留问题 - 终局(水晶解防后)GROUP_PUSH 优先于打龙,暴君/主宰在解防后基本不再被攻击——AI 选择了更直接的获胜路径,可接受但值得知晓。 - AoE/指定目标技能(如后羿箭雨)按 DESIGN 规则不打建筑——普攻是拆建筑主输出,已验证链路。
该汇报中的 3 局数据与传送实验随后由协调者在同系统内复核(PART 7.2);这不是第三方独立验收。
4.6 协调者自己做了什么 记忆 数据库
① 把模糊需求变成工程规范
撰写 DESIGN.md(5,925 字符):世界坐标与三路路径点/塔位数值表、5 英雄技能数值、装备表、AI 状态机定义、UI 布局规范、验证标准、端口规则。10 个 worker 的提示词全部引用同一份规范(全文见 2.3)。
② 每个阶段亲自验收
不照单全收 worker 汇报:亲自用 WebBrowser 打开游戏,读取 window.__game.state 断言玩法事实(小兵交战数、塔血量、比分、存活数),截图核验画面。4 个阻塞或高影响问题均由协调者复核阶段首次发现(PART 6)。
③ 一次直接代码修复
终局僵持诊断中,协调者直接修改 state.js 的 isCrystalInvuln:水晶解除无敌条件从"一路 3 塔全破"放宽为"一路全破 或 存活塔≤3"。改完即测,代码注释留证(PART 6 · I2)。
④ 验收取证方法
总结并贯彻稳定验收手法:单次 evaluate 不超过 25 秒(超时断连)、长等待用 Sleep+短轮询、DOM 按钮需派发 pointerdown、单位存活用 alive===false 判定——写入后续每个 worker 提示词(4.4 原件可见)。
⑤ "继续 vs 新建"的决策规则实战
平台规则:已终止的 Worker 上下文不可复用(SendMessage 仅对存活 Worker 有效)。实战应用:R03/R04/R05/R08 中断后全部新建续作 Worker,提示词只写"已有成果 + 剩余范围"并附坐标级证据包(堵车聚类数据/贴墙坐标/根因假设);R06 成功后不按惯性让它顺手做 UI,而是另起 R07——避免把攻坚上下文带入新阶段。从不写"基于你的发现"这类把理解工作外包给 Worker 的提示词。
4.7 代码量增长曲线 日志 记忆
R01/R02 行数为当时 wc -l 实测值;R03–R07 为推算(推断);最终值 7,979 为交付目录逐文件复算。
4.8 协调者工具活动流(activities 表窗口内 113 条) 数据库
逐小时分布(窗口 01:30–07:01)
06 时段最忙(30 条:R08 验收 + R09 + R10 + 最终验收挤在同一小时);01:30–02:00 的 5 条含 AskUserQuestion(duration 51,589ms,含用户阅读与作答时间)。
字段解剖(每条的记录粒度)
PRE-17 · 原始代码/日志 · 对应 RUN-V07
{"id":"Bash_1","operation_type":"command_execute",
"summary":"执行 ls -la …/king/ …",
"status":"completed","timestamp":1786210495682,
"duration":4189,"decision":"approved",
"tool_result_json":"{\"content\":\"total 0…\"}"}时刻(epoch 毫秒)、耗时(毫秒)、权限决策、工具结果原文全部落库——本报告的许多数字可从 activities 层单独复算。
耗时榜:开发窗口冻结导出的 113 条 activities 中,10 次 Agent 调用全部在列(1,507.6s–1,839.2s,其中多次接近 1,800s 的平台期限)。活动数据库在报告编写后仍会增长,因此不再引用可变的全表总数;窗口外活动不得并入本图。
4.9 产物谱系 M0–M7 日志 记忆
TABLE-20 · 原始表格 · 对应 RUN-V06
| 里程碑 | 内容 | 产出 Run | 锚点证据 |
|---|---|---|---|
| M0 | 项目骨架:index.html/importmap/错误收集/主循环 | R01 | 01:39:58–02:09:58;1,777 行实测 |
| M1 | 王者峡谷 3D 地图 + 相机 + 摇杆 + 可行走英雄 | R01 | phase1-map 六图(SHA 可核) |
| M2 | 战斗核心:单位/兵波/塔/水晶/5 英雄技能/弹道特效 | R02 | 4,017 行实测;t=55.8s 三路交战 |
| M3 | 英雄 AI + 野区 + 装备自动购买 | R03 | ai.js 704 行实测;AI 击杀 4:0 |
| M4 | 可终结性:堵路修复 + 僵持修复 + 门径/ASSAULT | R04–R06 | 3/3 局分出胜负(PART 7.2 表) |
| M5 | 完整 UI:选将/小地图/商店/播报/TTS/结算 | R07 | 选将与 HUD 截图;12 横幅自报 |
| M6 | 视觉与性能:模型重做/特效/壳层闪红/FPS 修复 | R08–R09 | I4 前后对照截图;FPS 6→31.8 |
| M7 | 隔离上下文的同系统 QA + 协调者全链路终验 | R10 + 协调者 | V01–V12 记录为通过;验收观察窗口内未记录错误 |
4.10 提示词工程演进:时间预算条款的引入 数据库
TABLE-21 · 原始表格 · 对应 RUN-V01
| Run | 提示词长度 | 验收/自检条款 | 时间预算条款 | 终态 | 中断点位置 |
|---|---|---|---|---|---|
| R01 | 2,697 | 有 | 无 | deadline | 验证期(截图归档中) |
| R02 | 2,733 | 有 | 无 | deadline | 验证期(截图只存 1 张) |
| R03 | 2,285 | 有 | 无 | deadline | 验证期(轮询中) |
| R04 | 1,720 | 有 | 无 | deadline | 验证期(验收局刚开) |
| R05 | 1,757 | 有 | 无 | deadline | 验证期(验收局刚开) |
| R06 | 1,782 | 有 | 有(实现≤15min/验证≥12min) | 正常收尾 | —(时限内完成) |
| R07 | 3,046 | 有 | 有(≤18min/≥10min) | max_turns | 收尾期(删未用 import,验证已完成) |
| R08 | 1,970 | 有 | 有(≤17min/≥10min) | deadline | 诊断期(查 emissive) |
| R09 | 1,606 | 有 | 有(≤15min/≥10min) | max_turns | 收尾期(调像素比,验证已完成) |
| R10 | 1,842 | 无(清单式) | 无 | max_turns | 深查期(查塔音效事件) |
演进事实:前 5 个 Run 均在 30 分钟期限处被回收,部分验证由协调者接手;时间预算条款自 R06 起引入("必须留 12 分钟以上验证")。R07/R09 的回传记录表明其在验证或调参收尾后触发轮次上限;R06 是唯一自然收尾。样本只有 1 个自然收尾,这里只陈述时间关联,不把提示词条款写成因果。全部提示词原文与长度/指纹见 db/session-messages.json 与 PART 4.3。
9 次中断、9 次接续:长程执行的恢复全景
10 个子 Agent 中只有 1 个在时限内自然收尾(R06,25m08s);其余 9 次都在 30 分钟边界或轮次上限处被回收。后续由平台终态记录、落盘产物、协调者同系统复测与范围化续作完成收口。本章只陈述本案例可复核的中断与接续,不把它推广成对所有任务的普遍保证。
5.1 逐次中断-接续账本 日志 记忆
TABLE-22 · 原始表格 · 对应 RUN-V01
| Run | 终态/时长 | 中断点(Worker 最后动作) | 协调者接续动作 | 结果 |
|---|---|---|---|---|
| R01 | deadline 30m00s | "最终检查网络请求与错误,然后归档截图"——截图归档前被回收 | 协调者复测:6 张阶段截图已存 scratchpad、页面 KING_OK、当次 window.__errors 为空、未发现外部 HTTP 资源 → 放行 P2 | 成果可继续使用 |
| R02 | deadline 30m00s | "t=55.8 三路全部交战、0 错误。截图 1"——验证截图只存 1 张 | 亲自跑 67s/211s 两轮实测:兵线交战正常但发现演示玩家偏保守;记录为遗留观察 → 放行 P3 | 成果完整 |
| R03 | deadline 30m00s | "bot T1 has fallen… Continuing to poll"——加速局轮询中被回收 | 亲自跑 4 倍速 13 分钟,发现 100 兵堵车 bug(I1) → 启动 R04 专项修复 | 藏雷被挖出 |
| R04 | deadline 30m00s | "重开新局正式测量(改动需刷新生效)"——验收局刚开 | 亲自复测:堵车消失(峰值 113→46),但跑到 t=1350s 发现终局僵持(I2) → 直改 isCrystalInvuln + 启动 R05 | 修复有效但暴露新雷 |
| R05 | deadline 30m00s | "重跑验收局 1(arthur)"——又停在验收起点 | 亲自复跑:推塔恢复但 t=1087s 发现英雄贴墙卡死(I3) → 整理贴墙坐标证据包启动 R06 | 再挖一雷 |
| R06 | 正常收尾 25m08s | —(时限内完成实现+3 局验收+传送实验) | 复核 3 局对局数据与传送实验 → 关闭 I2/I3,进入 UI 阶段 | 唯一自然收尾 |
| R07 | max_turns 27m33s | Worker 自报:"17 分钟完整对局完成、12 横幅、16 击杀条、零报错",随后在清理未用 import 时被回收 | 协调者同系统复测选将/HUD/商店/播报链路 → 记录为通过 | 成果可继续使用 |
| R08 | deadline 30m00s | "亚瑟全身橙红(疑似又被闪红)…先查当前 emissive 状态"——正在诊断 | 截图确认发光 bug 实证 + FPS=6 → 整理根因假设(共享材质污染)启动 R09 | 半成品暴露两雷 |
| R09 | max_turns 21m46s | "daji 25s 后 FPS 31.8(335 calls)——过线但余量小。把像素比 0.55 降到 0.5"——调参收尾中被回收 | 实测修复后画面:亚瑟细节恢复;FPS 21–31.8 达标(软渲染口径)→ 关闭 I4 | 成果完整 |
| R10 | max_turns 19m03s | "玩家在塔下 4 秒掉血 1262…但 tower 的 basicAttack 事件为 0"——深查音效事件 | 协调者亲自完成最终全链路验收(V01–V12);音效事件问题降级为遗留 L5 | 验收收口 |
5.2 韧性机制拆解 记忆
平台层
30m 时限/轮次上限的终态机保证 Worker 必被回收且状态可查(deadline_exceeded/max_turns 精确记录);成果落盘为文件与 scratchpad,不随会话消亡;task-notification 把残句也带回("截图 1(小兵交战):"这种半句正是现场证据)。
物证级细节:scratchpad 中 p4fix/、p5/ 两个空目录保留原样——它们是 R05/R08 的 Worker"准备存截图"时被时限回收的现场(目录已建、文件未写)。
协调者层
三条纪律:①不照单全收——每次中断后亲自实测再决策;②续作不重做——新 Worker 提示词写明"已有成果+只做剩余范围"(R04–R06 提示词均附上一轮的实测证据包);③经验下传——alive 判定/25s 轮询/pointerdown 等踩坑条款写入后续提示词(4.4 原件可见)。
规范层
DESIGN.md 作为跨 Worker 唯一事实源:接口、数值、端口规则、验证标准不在对话里漂流,而是落盘成文、逐版增补(端口规则章即为 02:09 用户补充后追加)。
模型调用层
873次completed之外有5次llm_call_failed(0.6%),均为cancelled/status 0/attempt 1。878个started requestId各有且只有一个终态;失败点之后仍有新的请求或后续协调者活动,不是同一requestId自动重试成功。未观察到这些失败点导致会话永久终止,但不能绝对断言中间生成内容毫无损失。
四次调试攻坚:从"能跑"到"能玩"
Worker 自报"完成"不等于可玩。协调者在同系统复核中连续发现 4 个阻塞或高影响问题,每个都有"实测证据→根因→修复→回归验证"闭环。以下 evaluate 输出取自当时返回值,完整记录见 db/session-messages.json。
从能跑到能结束一局,差的是四次硬修复
小兵堵路、终局僵持、基地贴墙和发光性能问题都曾阻断体验。每次修复都从浏览器状态取证开始,再回到具体代码。
每份调试案卷都按“浏览器观察→状态取证→代码修改→回归结果”展开,冻结素材与最终实现分层标注。
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / I1–I4日志、代码、截图和回归记录|图中结论:四个高影响问题均有发现、根因、修复和复验链
查看来源与复算数据
- 数据来源
- I1–I4日志、代码、截图和回归记录
- 复算口径
- 四个高影响问题均有发现、根因、修复和复验链。
图中指标
- 高影响问题4
- 专项Worker4
- 协调者直改1
- 终局长局3
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / R03/R04日志 + ai.js/config.js|图中结论:t=780约100兵聚集,修复后峰值113→46
查看来源与复算数据
- 数据来源
- R03/R04日志 + ai.js/config.js
- 复算口径
- t=780约100兵聚集,修复后峰值113→46。
图中指标
- 观察聚集≈100
- 修复前峰值113
- 修复后峰值46
- 坐标(-80,60)
前两个问题发生在规则层;后两个问题分别把路径规划和渲染表现推到浏览器里检验。
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / 协调者evaluate + state.js isCrystalInvuln|图中结论:旧规则与实际推进不匹配
查看来源与复算数据
- 数据来源
- 协调者evaluate + state.js isCrystalInvuln
- 复算口径
- 旧规则与实际推进不匹配;协调者修改解防条件并复测。
图中指标
- 观察时间1350s
- 协调者Edit1
- 关键函数isCrystalInvuln
- 最终结果可终结
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / 贴墙坐标 + BASE_GATES + _gateRoute + ASSAULT|图中结论:三门坐标、路由函数和终局强攻模式形成修复链
查看来源与复算数据
- 数据来源
- 贴墙坐标 + BASE_GATES + _gateRoute + ASSAULT
- 复算口径
- 三门坐标、路由函数和终局强攻模式形成修复链。
图中指标
- 基地门3
- 关键函数_gateRoute
- AI模式ASSAULT
- 终结对局3/3
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / 事故截图 + vfx.js + hud.js + R09性能记录|图中结论:截图证明发光/FPS事故
查看来源与复算数据
- 数据来源
- 事故截图 + vfx.js + hud.js + R09性能记录
- 复算口径
- 截图证明发光/FPS事故;代码与复测支持壳层和节流修复。
图中指标
- 事故FPS6
- 修复后范围21–31.8
- 截图联证2
- 代码责任3
数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / I1–I4证据 + R06三局 + V01–V12|图中结论:每项修复都有运行状态、截图或完整对局复验
查看来源与复算数据
- 数据来源
- I1–I4证据 + R06三局 + V01–V12
- 复算口径
- 每项修复都有运行状态、截图或完整对局复验。
图中指标
- 问题4
- 专项Worker4
- 协调者直改1
- 证据列6
100 个小兵在地图拐角永久"堵车"
实测- 发现
- ≈03:21,R03 后协调者 4 倍速跑局验收,t=780s:蓝方存活小兵 113 个 vs 红方 32 个;18 座塔全部满血。
- 现象
- 聚类分析发现约 100 个蓝兵挤死在 (-80,60)——上路"左边缘→上边缘"的拐角路径点,样本全部
moving:true, wp:2, target:none。 - 根因
- 路径点到达判定过严 + 单位圆形碰撞互相推挤 → 拐角处集体卡死;兵线堆积又导致推塔链路整体停摆。
- 修复(R04)
- 路径点到达半径放宽到 6–8;小兵出生即固定横向随机偏移(±2.5)避免同轨叠加;3 秒位移<1 判定卡死并自救(跳过路径点/侧向瞬移)。
- 回归
- 复测 t=340s:双方小兵 46/32(有界),最大聚集 11,比分 4:2 有来有回——堵车消失。
实测原始记录(协调者 evaluate 返回原文,t=780s;另见 db/session-messages.json)
{"time":780,"towers":[{"t":"b","lane":"mid","hp":6500,"dead":false},{"t":"r","lane":"mid","hp":6500,"dead":false},……共 18 座全部 6500/6500……],"heroes":[……10 英雄在位……],"minions":{"b":113,"r":32}}
# 聚类分析(同一轮验收的第二次 evaluate,原文):
{"blueClusters":[["-80,60",100],["-60,-60",6],["-60,-80",6],["-80,-60",5],["60,-80",4],["0,0",4]],
"sample":[{"pos":[-75,58],"tgt":"none","moving":true,"wp":2},{"pos":[-81,63],"tgt":"none","moving":true,"wp":2},
{"pos":[-84,59],"tgt":"none","moving":true,"wp":2},{"pos":[-77,56],"tgt":"none","moving":true,"wp":2},
{"pos":[-84,61],"tgt":"none","moving":true,"wp":2}],
"redTowerSample":{"lane":"mid","hp":6500,"tgt":"none","atkTimer":0}}
# 20 单位网格聚类:(-80,60) 一格聚了 100 个蓝兵;样本全部 moving:true、wp:2、无目标——卡在拐角终局僵持:22.5 分钟分不出胜负
实测- 发现
- ≈03:58,I1 修复后协调者复跑,t=1350s(22.5 分钟):蓝方 14:6 领先、红方 9 塔全破,但红水晶 10000/10000 满血。
- 根因(三层)
- ① 设计规则"一路 3 塔全破才解除水晶无敌"在 AI 分散拆塔时永不满足——协调者直接改
isCrystalInvuln增加"存活塔≤3"分支;② 水晶战斗中持续回血 100/s,单挑输出打不动(R06 改为脱战 5s 后才回血);③ 有存活塔时水晶受伤固定 ×0.1(R06 改为每座存活塔 -8% 的梯度减伤)。 - 修复(R05+协调者)
- 超级兵机制(一路全破后该路每波附加)+ 12:00 后小兵每分钟 +8% 成长 + GROUP_PUSH 集合推水晶 + 上述规则修改。
- 回归
- 协调者复跑确认拆塔恢复(t=751 时 9 座塔已毁、中路双塔激战 5079/1702;t=1109 时比分 2:14、红方 6 塔已破),但比赛仍不终结——引出 I3。
实测原始记录(evaluate 原文)与协调者直改代码原文
# t=1350s 僵持现场(原文): {"time":1350,"winner":null,"score":{"blue":14,"red":6},"towersAlive":{"b":3,"r":0}, "crystals":[{"t":"b","hp":7650,"alive":true},{"t":"r","hp":10000,"alive":true}],"errs":0} # 同一轮验收:基地 proximity 检查(原文)——12 个蓝兵已在红方基地,红水晶满血: {"blueMinions":34,"blueNearRedBase":12,"redMinions":9,"redCrystalKeys":[], "heroes":[{"n":"亚瑟","t":"b","pos":[-74,-83]},{"n":"牛魔","t":"b","pos":[72,67]}, {"n":"后羿","t":"r","pos":[-58,-68]},{"n":"牛魔","t":"r","pos":[-71,-83]},……]} # 协调者直改(state.js:911-925,注释即证据): /** 水晶无敌:本方任意一路 3 塔全破,或存活塔 ≤3(≥6 塔被破)→ 解除无敌 * 修复(终局僵持):原规则仅"一路全破",AI 分散拆塔时三路各剩 1-2 座会永久无敌, * 实测 22 分钟无法分出胜负。增加存活塔总数条件保证比赛必然可终结。 */ isCrystalInvuln(crystal) { let aliveTotal = 0; for (const t of this.towerUnits) { if (t.team === crystal.team && t.alive) aliveTotal++; } if (aliveTotal <= 3) return false; for (const lane of ['mid', 'top', 'bot']) { ... } return true; }
英雄攻不进基地:全部贴墙卡死在门外
实测- 发现
- 04:36,协调者复跑至 t=1087s:双方水晶均已解防(红方 0 塔存活/蓝方 5 塔),但全部满血。
- 现象
- 红方 AI 亚瑟 (-60,-86)、后羿 (-61,-74) 就站在蓝方基地墙外十几单位处,不进也不打;蓝方镜像。
- 根因
- 英雄 AI 的
_moveTo直线走法被基地围墙碰撞体挡住(墙段间隙等效连续墙);交战索敌默认排除建筑、GROUP_PUSH"塔先水晶后"——英雄永远不把水晶选为目标。实测传送红亚瑟到蓝水晶旁 11 单位,它无视水晶走 56 单位去拆边塔。 - 修复(R06)
- 新增
BASE_GATES每方 3 个门坐标 +_gateRoute门径路由;硬卡死 2s 换门+侧向抖动;水晶解防且在敌基地圈内进入ASSAULT模式;GROUP_PUSH 改水晶优先。 - 回归(最严)
- 连跑 3 局全部分出胜负:18:47(10:9,红胜,亚瑟斩水晶)/ 13:47(17:8,红胜,后羿)/ 13:53(6:10,红胜,兰陵王);三次记录中的
window.__errors均为空。完整汇报见 4.5。
实测原始记录(t=1087s 贴墙证据,evaluate 原文)
{"time":1087,
"towersAlive":[{"t":"b","lane":"mid","tier":1},{"t":"b","lane":"mid","tier":2},{"t":"b","lane":"mid","tier":3},
{"t":"b","lane":"top","tier":1},{"t":"b","lane":"top","tier":2},{"t":"b","lane":"top","tier":3},
{"t":"r","lane":"bot","tier":1},{"t":"r","lane":"bot","tier":2},{"t":"r","lane":"bot","tier":3}],
"invuln":{"b":false,"r":false}, // 双方水晶均已解防(蓝方下路 3 塔先被全破;红方存活塔≤3)
"heroes":[{"n":"亚瑟","t":"b","pos":[62,67]},{"n":"牛魔","t":"b","pos":[-62,-86]},
{"n":"兰陵王","t":"r","pos":[65,66]},{"n":"亚瑟","t":"r","pos":[-60,-86]},
{"n":"后羿","t":"r","pos":[-61,-74]},{"n":"妲己","t":"r","pos":[76,68]},{"n":"牛魔","t":"r","pos":[68,67]}]}
// 红方 亚瑟(-60,-86)、后羿(-61,-74) 距蓝方基地 (-72,-72) 仅十几单位,贴墙不进;蓝方 亚瑟(62,67) 在红方基地外镜像对峙亚瑟变"橙色发光团" + FPS 只有 6
实测- 发现
- 06:09,R08 视觉打磨后协调者截图验收:亚瑟施放 1 技能后整个模型变成饱和橙红色团(细节全失,见 PART 7 画廊"事故现场");同帧 FPS 计数为 6。
- 根因
- 受击闪红/技能光效直接修改共享材质的 emissive,恢复逻辑在战斗刷新计时下遗漏 → 永久发光;FPS 主因是百余单位的 DOM 血条每帧 transform 更新 + 软渲染像素比过高。
- 修复(R09)
- 闪红/光环改为独立叠加壳层 mesh,不触碰单位任何材质,到期自动隐藏(vfx.js 注释原文:"杜绝共享材质污染/恢复遗漏");小兵血条受伤后显示 3s;软渲染像素比下调。
- 回归
- 亚瑟恢复蓝金盔甲+大剑细节;headless 软渲染 FPS 6→31.8(daji 场景,335 draw calls)——GPU 浏览器预期 60(推断,未实测 GPU 环境,列入 L4)。
6.1 验收方法论小插曲(诚实记录) 记忆
"0 座塔被摧毁"虚惊
协调者一度用 u.dead 判定塔毁,连续观测到"hp:0 但 dead:false"怀疑新 bug——实际是单位用 alive===false 标记,9 座塔早已正常摧毁。教训写入了后续所有 worker 提示词(4.4 原件可见该条款)。
点不动的"锁定"按钮
选将界面锁定按钮监听 pointerdown 而非 click,自动化首测"点击无反应";派发 PointerEvent 后正常进局。这类真实交互差异只有端到端实测才能暴露。
验证:全链路验收、43 张截图、5 段录屏映射
最终验收由协调者执行(隔离上下文的同系统 QA Worker 达轮次上限后):选将→进局→操控→死亡→重生→播报→完整对局→结算→再来一局,逐项断言并留证。43 张截图中有 42 份唯一图像内容;5 份录屏原件以 SHA-256 登记,页面播放的是可公开托管的 H.264 派生预览。
KING_OK 且显示5张英雄卡,?demo=1&hero=arthur&speed=8 进入对局后检测到蓝/红各5名英雄、HUD、小地图和已连接的WebGL2 Canvas,window.__errors=[],资源请求均为localhost。平台机制增强后复验三层闭环与宽表响应式。最终产品图谱复验确认:KING-V01–V26共26个figure/26张SVG,56/56个全页图片元素(含7组联证中的8个图片元素)均加载,热点点击、Enter、空格、详情检查器和截图灯箱有效,E01–E38搜索与12个底稿折叠项正常;移动端20个宽图仅在各自图框内滚动,页面无横向溢出,控制台仍为0条warning/error。源码级重绘后以PC为主基线再次复验:26张1200px工程画布含1,239个直接标签与273个检查节点,1280×720下26/26个图框均无内部横向滚动、页面无溢出,六张截图覆盖图以约912px全宽呈现且旁证卡保持三列;390×844仅把20张宽图的滚动隔离在图框内,不改变桌面SVG画布和构图。完整环境与四次结果见 browser-verification.json;这些窗口外本地回归与07:00的冻结验收记录分层保存,共同覆盖报告版式、媒体、交互与最终游戏路径。游戏是否成立,最终要回到画面与完整对局
结构化状态回答“系统在做什么”,截图和录屏回答“玩家看到了什么”。两者同时成立,才能支持可玩原型的结论。
43张截图、5份原视频和20帧派生故事板按来源和时间分层;窗口外的最终运行与云端试玩不会倒算进开发统计。
数据:E11 / E12 / E13 / E14 / E15 / index.html + window.__game/__errors + 查询参数|图中结论:启动、错误、状态、倍速和交互钩子支持可重复验收
查看来源与复算数据
- 数据来源
- index.html + window.__game/__errors + 查询参数
- 复算口径
- 启动、错误、状态、倍速和交互钩子支持可重复验收。
图中指标
- WebBrowser376
fact.browser.calls - 下游requestId376
- 验收编号12
- 控制台最终窗口错误0
数据:E11 / E12 / E13 / E14 / E15 / G01–G16原表|图中结论:16项合同均关联规范条目、代码符号和运行证据
查看来源与复算数据
- 数据来源
- G01–G16原表
- 复算口径
- 16项合同均关联规范条目、代码符号和运行证据。
图中指标
- 需求条款16
- 验收步骤12
- 证据账本43
- 状态类型3
数据:E11 / E12 / E13 / E14 / E15 / 协调者最终验收消息 + 浏览器断言|图中结论:启动到重开、离线资源和多英雄回归均有记录
查看来源与复算数据
- 数据来源
- 协调者最终验收消息 + 浏览器断言
- 复算口径
- 启动到重开、离线资源和多英雄回归均有记录。
图中指标
- 验收步骤12
- 状态阶段6
- 英雄选项5
- 运行英雄10
接下来把三局终局、43张截图和5份录屏放回对应验收路径,直接看代码如何变成可见体验。
数据:E11 / E12 / E13 / E14 / E15 / skills.js + models.js + 选将/回归证据|图中结论:五种定位、15技能和六种aim语义存在于冻结代码
查看来源与复算数据
- 数据来源
- skills.js + models.js + 选将/回归证据
- 复算口径
- 五种定位、15技能和六种aim语义存在于冻结代码。
图中指标
- 英雄5
- 主动技能15
- aim模式6
- 逐项穷举0
数据:E11 / E12 / E13 / E14 / E15 / R06回归日志|图中结论:三局均出现胜方、水晶击杀者且错误为0
查看来源与复算数据
- 数据来源
- R06回归日志
- 复算口径
- 三局均出现胜方、水晶击杀者且错误为0。
图中指标
- 对局样本3
- 红方胜3
- 蓝方胜0
- 平衡结论无
数据:E11 / E12 / E13 / E14 / E15 / screenshots目录 + 报告原始图注 + SHA-256|图中结论:43个文件/42份唯一内容逐张呈现,并标明序号、时间锚点、执行角色和阶段
查看来源与复算数据
- 数据来源
- screenshots目录 + 报告原始图注 + SHA-256
- 复算口径
- 43个文件/42份唯一内容逐张呈现,并标明序号、时间锚点、执行角色和阶段。
图中指标
- 截图文件43
fact.media.screenshots - 唯一图像42
fact.media.uniqueScreenshots - 原视频5
- 派生帧20
数据:E11 / E12 / E13 / E14 / E15 / 截图SHA-256清单|图中结论:唯一重复对已明确披露,其余42份内容哈希不同
查看来源与复算数据
- 数据来源
- 截图SHA-256清单
- 复算口径
- 唯一重复对已明确披露,其余42份内容哈希不同。
图中指标
- 截图文件43
fact.media.screenshots - 唯一内容42
fact.media.uniqueScreenshots - 重复组1
- 重复文件2
媒体补足了静态代码看不到的体验,录制时间与派生关系也在同一图中对齐。
数据:E11 / E12 / E13 / E14 / E15 / release-assets.json|图中结论:每个预览都能追到原件、速度、编码、大小和SHA
查看来源与复算数据
- 数据来源
- release-assets.json
- 复算口径
- 每个预览都能追到原件、速度、编码、大小和SHA。
图中指标
- 原视频5
- 预览5
- HEVC原片5
- H.264预览5
数据:E11 / E12 / E13 / E14 / E15 / video-storyboards.json + 5份预览|图中结论:五份视频各按15/38/62/85%抽取四帧,20帧全部可见并登记时间码、倍速与SHA-256
查看来源与复算数据
- 数据来源
- video-storyboards.json + 5份预览
- 复算口径
- 五份视频各按15/38/62/85%抽取四帧,20帧全部可见并登记时间码、倍速与SHA-256。
图中指标
- 视频泳道5
- 每条派生帧4
- 总帧20
- 时间码口径预览+原片近似
数据:E11 / E12 / E13 / E14 / E15 / 视频分类 + browser-verification.json|图中结论:开发窗口与两份窗口外运行补充按时间和用途清楚分层
查看来源与复算数据
- 数据来源
- 视频分类 + browser-verification.json
- 复算口径
- 开发窗口与两份窗口外运行补充按时间和用途清楚分层。
图中指标
- 统计层1
- 窗口外运行层2
- 开发日志行38,641
fact.logs.lines - 在线入口2
7.0 验证基础设施与方法学(先于结果的可验证性设计) 实测
TABLE-23 · 原始表格 · 对应 QA-V01
| 设施/纪律 | 设计 | 在本次验收中的作用 |
|---|---|---|
| 启动门禁 | boot 成功 document.title='KING_OK'、失败 'KING_ERR: '+msg(index.html:303-312) | 每轮验收第一断言;所有 worker 统一执行 |
| 错误收集 | window.__errors 捕获 error/unhandledrejection/console.error | 用于限定说明“最终验收记录覆盖的观察窗口内未发现错误”,不外推到未观察时段 |
| 状态暴露 | window.__game 暴露 state/units/player/skills | 全部玩法断言的数据源(兵线数/塔血/比分/AI 模式) |
| 加速仿真 | ?speed=4|8 固定步长多倍速;?demo=1 自动演示;?hero= 指定英雄 | 8 倍速下 2-4 分钟跑完一整局——全局面验收在工程上可行 |
| 轮询纪律 | evaluate 单次 <25s(超时断连),长等待 Sleep+短断言轮询 | 02:42 起写入所有 worker 提示词,杜绝验收工具自身超时 |
| 交互真实化 | DOM 按钮派发 pointerdown(click 不触发)、单位存活用 alive===false | 两条都是实测踩坑后固化的条款(PART 4.1) |
| 传送实验 | evaluate 直改运行时状态(传送英雄进基地/置残血)做 10 秒级假设验证 | I3 根因确认、V06 死亡重生测试的关键手段 |
7.0b 验收合同矩阵(G01–G16:需求 → 规范 → 代码符号 → 直接证据) 实测
TABLE-24 · 原始表格 · 对应 QA-V02
| ID | 验收项 | 规范条目 | 代码符号(文件:行号) | 直接证据 | 状态 |
|---|---|---|---|---|---|
| G01 | 离线 Three.js 3D 锁视角 | Q1 选择;DESIGN 技术约束 | lib/three.module.js(1,272,972 B vendored);renderer.js 相机 rig | V12 资源全 localhost;R01 截图 | 通过 |
| G02 | 完整三路王者峡谷 | Q3 选择;DESIGN 地图节 | world/map.js(840 行)+ config.js MAP/路径点/塔位 | R01 六图:河道/塔/草丛/基地/龙坑 | 通过 |
| G03 | 5 英雄 × 3 技能 + 被动 | DESIGN 英雄池数值 | skills.js(485 行);models.js HERO_STYLE:460/createHumanoid:90 | 选将界面技能文案;V11 四英雄回归 | 通过 |
| G04 | 三路兵波次/炮车 | DESIGN 小兵数值 | spawner.js:88 spawnWave | t=67s 蓝 22 vs 红 20 实测 | 通过 |
| G05 | 防御塔 T1→T3 顺序无敌 | DESIGN 防御塔节 | state.js:905 isTowerInvuln | 9 塔被毁实测 + 终局塔数统计 | 通过 |
| G06 | 水晶解防/摧毁=胜利 | DESIGN 水晶节(I2 修订) | state.js:914 isCrystalInvuln(协调者直改) | 3/3 局分出胜负 + winner 字段 | 修复后通过 |
| G07 | 英雄 AI 状态机 | DESIGN AI 节 | ai.js(920 行;ASSAULT:422/_gateRoute:827) | 终局 AI 模式分布实测 | 通过 |
| G08 | 野区/暴君/主宰/BUFF | DESIGN 野怪节 | spawner.js 刷新 + ai.js 打龙时机 | R06 回归:野营被清 3/10、打野发育领先 | 通过 |
| G09 | 虚拟摇杆+技能按钮操控 | Q4 选择;DESIGN UI 节 | input.js:30 pointerdown / :118 getMoveVector | V02 进局操控实测 | 通过 |
| G10 | 装备商店/一键推荐 | DESIGN 装备节 | shop.js:80 buy / :95 buyRecommended | V04:面板弹出 itemCount=12 | 通过 |
| G11 | 小地图 | DESIGN UI 节 | minimap.js:17 class Minimap | HUD 截图(单位点/塔标/相机框) | 通过 |
| G12 | 击杀播报/横幅/TTS | DESIGN UI 节 | screens.js:247 _bannerCount++ | V07:bannerCount 1→3 递增 | 通过 |
| G13 | 死亡/重生/回城 | DESIGN 数值节 | state.js:932 tryRecall / :943 tryFlash | V06:deaths=1 → 泉水复活 | 通过 |
| G14 | 结算界面/再来一局 | DESIGN UI 节 | screens.js:372 showResult | V09/V10:字段 JSON + 重开实测 | 通过 |
| G15 | 选将界面 5 选 1 | Q1-Q4 汇总;DESIGN UI 节 | screens.js 选将模块 | 截图 06/07 + 锁定进局玩家正确 | 通过 |
| G16 | 端口冲突硬约束 | 用户消息 #2;DESIGN 端口规则 | start.command 自动挑端口 | lsof 实测 21 端口被占下正常起服 | 通过 |
矩阵纪律:每项同时给出规范出处、代码符号与运行证据;G06 是"初版规则不成立 → 修订规范 → 修复 → 回归"的合同样本(PART 6 · I2/I3)。
7.0c 测试仪器本身也要被测试(两次仪器失灵实录) 记忆
失灵 ①:播报验证拿到假"0"
为验证 TTS 播报,协调者给 speechSynthesis.speak 挂了调用计数器——多次击杀后计数为 0;又用 MutationObserver 监听横幅 DOM 的节点新增——还是 0。先怀疑游戏,再怀疑仪器:真相是横幅实现为复用固定 DOM 元素、只切 style.display(没有节点新增),且第一轮计数器初始化后根本没挂上观察者。正解:改读 screens 模块的自检计数器 _bannerCount,实测 1→3 递增(V07)。
失灵 ②:误导性报错催生的轮询纪律
单次 evaluate 超过约 25 秒会断连,且报错文本是误导性的 "Browser automation unavailable. Ensure playwright is installed: pip install playwright..."(浏览器其实正常,是等待超时)。由此固化"Sleep+短 evaluate 轮询"纪律并写入后续全部 Worker 提示词(4.4 原件可见该条款)。
这两条是"证据纪律"的反面教材:仪器拿到 0 不等于被测对象为 0——验收探针本身也要被验证。
7.1 端到端验收结果 实测
TABLE-25 · 原始表格 · 对应 QA-V03
| # | 验收项 | 方法与实测结果 | 状态 |
|---|---|---|---|
| V01 | 启动 | 无参数打开 → document.title==='KING_OK'、window.__errors 为空 | 通过 |
| V02 | 选将 | 5 张英雄卡完整;点选亚瑟高亮 → 派发 pointerdown 锁定 → 进局玩家确为亚瑟 | 通过 |
| V03 | HUD | 小地图单位点/比分/计时/金币齐备;技能 CD 数字滚动(E 6s、Q 2s 实测帧) | 通过 |
| V04 | 商店 | 商店面板弹出、12 件装备齐全(实测 itemCount=12) | 通过 |
| V05 | 兵线交战 | t=67s:蓝 22 兵 vs 红 20 兵、18 塔 2 水晶齐备、玩家 lv3 | 通过 |
| V06 | 死亡/重生 | 后羿残血传送敌方区域 → deaths=1 → 泉水复活走回战线(pos (-5,-7)) | 通过 |
| V07 | 播报 | _bannerCount 随击杀 1→3 递增(第一滴血等横幅确认触发) | 通过 |
| V08 | 完整对局 | 8 倍速一局:红方胜,水晶被摧毁,state.winner='red' | 通过 |
| V09 | 结算界面 | 标题"失 败"、比分 3:3、时长 09:23、"你的战绩 0/0/0 补刀 30 等级 11"、双方 KDA 表、"再来一局"按钮可见 | 通过 |
| V10 | 再来一局 | 点击后重开新局(demo URL 自动锁原定英雄),t=101s 运行正常;该次观察中 window.__errors 为空 | 通过 |
| V11 | 多英雄回归 | ?hero=arthur/daji/houyi/lanlingwang 分别跑局均无报错(含刺客隐身机制) | 通过 |
| V12 | 资源离线 | performance resource entries 全部 localhost,无外部请求 | 通过 |
7.1b 结算界面的原始断言输出(协调者 evaluate 返回)
{"rsElements":[
{"cls":"rs-box","vis":true,"txt":"失 败\n 3 : 3\n"},
{"cls":"rs-title lose","vis":true,"txt":"失 败"},
{"cls":"rs-score","vis":true,"txt":"3 : 3\n 09:23"},
{"cls":"rs-time","vis":true,"txt":"09:23"},
{"cls":"rs-me","vis":true,"txt":"你的战绩:0/0/0 补刀 30 等级 11"},
{"cls":"rs-table","vis":true,"txt":"英雄 K/D/A 补刀 等级……"},
{"cls":"rs-again","vis":true,"txt":"再来一局"}],
"againBtn":{"cls":"rs-again","vis":true}}
// 重开后(另一次 evaluate 原文):{"title":"KING_OK","heroSelectVisible":false,"gameTime":101,"errs":0}
// —— demo 参数自动锁原定英雄直接开局7.2 R06 修复的完整对局数据(3/3 局分出胜负) 日志
TABLE-26 · 原始表格 · 对应 QA-V05
| 局 | 终局时间 | 比分(蓝:红) | 胜方 | 水晶击杀者 | 报错 |
|---|---|---|---|---|---|
| 1 | 18:47(1,127s) | 10:9 | 红 | 英雄·亚瑟 | 0 |
| 2 | 13:47(827s) | 17:8 | 红 | 英雄·后羿 | 0 |
| 3 | 13:53(833s) | 6:10 | 红 | 英雄·兰陵王 | 0 |
均为 ?demo=1&hero=arthur&speed=8 自动演示局(玩家由演示脚本操控)。三次回归加一次最终验收均为红方获胜;这4局用于验证水晶、结算和重开路径。阵营平衡将在对称控制、更多随机种子与显著性分析中单独评估。
7.2b 视觉演进三联对照(同场景,三时期) 实测

只有世界:空峡谷 + 可行走英雄
地形/塔/光影已就位,无任何玩法元素。
有了战斗:兵线交战 + 初版 HUD
小兵/血条/技能按钮进场,模型还是"方块人"阶段。
完整形态:模型/特效/CD 遮罩/小地图
五英雄可辨认、技能特效、完整 HUD。7.3 截图证据全量画廊(43 个文件 / 42 份唯一图像内容) 实测 日志
图注口径:协调者亲自截取并目检的标 实测;worker 自验存档的标 日志 并如实注明“未逐帧目检”。文件名 epoch 只作为本地元数据换算时刻,不是受信任时间戳。phase2-combat/1_minion_clash.png 与 screenshot_subagent-agent-1c86cd96_1786214519805.png 的 SHA-256 相同,明确计作一份内容的两个存档位置。
R01 地基与 3D 地图(worker 按 DESIGN.md 验证标准存档)(6 张)

R01 自验 · 泉水出生点
基地石台、发光泉水、出生保护罩。
R01 自验 · 己方 T1 塔
摇杆行走、相机跟随、防御塔层叠结构+顶部水晶。
R01 自验 · 河道龙坑与草丛
河道水面、龙坑地形、半透明草丛块。
R01 自验 · 敌方防御塔
红方配色塔身,兵线路径沿线布置。
R01 自验 · 敌方基地水晶
红方基地全景:围墙、石台、水晶核心。
R01 自验 · 河道中心全景
对角河道+三路土路+野区树木草丛的全图层次感。R02 战斗核心(worker 自验原始存档,1 张)

R02 自验 · 三路小兵交战
Worker 记录 t=55.8s 三路全部交战且当次错误数组为空;与 agent-1c86cd96 所截图为同一内容,SHA 相同。R02 战斗核心(重复存档披露,1 张)

R02 自验 · 小兵交战(原始存档)
与 phase2-combat/1_minion_clash.png 哈希一致——同一截图的两个存档位置,如实保留。协调者同系统复核(逐张经协调者目检)(6 张)

协调者验收 · 阶段2对线期
技能按钮(誓约/回旋/圣剑)、攻/回城键、金币计时齐备;同步断言 22 vs 20 兵线交战数据通过。
协调者验收 · 选将界面
5 英雄卡片完整渲染:定位、三技能名与简介。
协调者验收 · 锁定亚瑟
点选后金色选中框;随后派发 pointerdown 锁定进局,玩家确为亚瑟。
协调者验收 · 完整 HUD
小地图/比分/计时/血蓝条/装备 6 格/商店/召唤师技能/回城——全部就位。
I4 事故现场 · 亚瑟橙红发光团
1 技能后共享材质 emissive 被污染,模型细节全失;同帧 FPS=6。
协调者验收 · 修复后河道团战
亚瑟恢复蓝金盔甲+大剑;技能 CD 遮罩滚动(E 6s/Q 2s)、伤害飘字、模型配色区分。R07 UI 阶段(worker 自验)(8 张)

Worker 自验截图 · 05:23:18
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:24:08
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:24:45
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:26:22
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:28:43
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:29:28
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:30:19
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:30:57
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。R06 门径修复验证(含英雄攻击水晶)(2 张)

Worker 自验截图 · 04:56:36
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 05:05:36
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。R08 视觉打磨(worker 自验)(7 张)

Worker 自验截图 · 05:59:48
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:01:31
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:02:06
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:02:50
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:04:20
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:05:14
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:07:35
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。R09 发光修复与性能验证(worker 自验)(9 张)

Worker 自验截图 · 06:16:29
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:23:30
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:24:08
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:25:26
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:26:27
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:27:01
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:30:08
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:30:59
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:31:38
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。R10 隔离上下文的同系统 QA(worker 自验)(3 张)

Worker 自验截图 · 06:35:00
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:43:53
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。
Worker 自验截图 · 06:48:07
该帧由子 Agent 在自验中截取存档,协调者未逐帧目检;文件哈希见附录清单。7.4 过程与部署录屏(5 份原件映射 + 5 份派生预览) 实测
892f7f5dfdb1fffd…;按录制时刻与会话起始重合关系归类,阶段归属为推断。832097e80aa3af06…;阶段归属为推断。9c914b654bc4d77f…;阶段归属为推断。63fa7c8b1d12cee9…,不得计入 01:30–07:01 开发证据。6d5aef9c…65c388,作为11:53的窗口外在线部署验证,与开发窗口材料分层记录。页面视频均为派生预览,经过加速、缩放、压缩和改名,不能与原件做字节级等同。五份 HEVC 原件保持不变,完整路径、时长、编码、大小、SHA-256 与未来 Release URL 见 release-assets.json;当前 Release URL 为空,表示尚未在用户人工确认前发布。录屏未做逐帧事实标注,画面内容应与日志/代码证据分开评价。
把 Token、日志、数据库和哈希摊开
账单 CSV、运行时观测与会话数据库从不同记录面描述同一过程,适合做逐项一致性检查。账单是提供方导出,运行日志与数据库则同属本地系统;三者均未附第三方可信时间戳或密码学签名。因此这里证明的是“公开材料相互一致且可复算”,不是“任一来源不可能被伪造”。
把规模写成数字不难,把每个数字对回原记录才难
账单、运行事件、数据库、公开日志、代码、图片和视频分别回答不同问题。报告只在这些证据交叉处下结论。
公开审计层保留原表、原命令和完整口径。正文图表负责解释关系,读者需要时再下钻到原始记录。
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / CSV + observability + messages|图中结论:873个完成请求Token元组逐条匹配
查看来源与复算数据
- 数据来源
- CSV + observability + messages
- 复算口径
- 873个完成请求Token元组逐条匹配;各口径用途和粒度不同。
图中指标
- 账单请求877
fact.bill.requests - 逐条匹配873
fact.llm.completed - 账单侧差异4
- failed事件5
fact.llm.failed
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / request_log_part_0001.csv|图中结论:877请求可按小时聚合并与阶段时间轴对齐
查看来源与复算数据
- 数据来源
- request_log_part_0001.csv
- 复算口径
- 877请求可按小时聚合并与阶段时间轴对齐。
图中指标
- 账单请求877
fact.bill.requests - 输入Token82,906,205
fact.bill.inputTokens - 缓存Token80,468,224
fact.bill.cachedTokens - 输出Token673,938
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 账单CSV cached_tokens|图中结论:总输入、缓存和非缓存可直接复算,小时采样透明
查看来源与复算数据
- 数据来源
- 账单CSV cached_tokens
- 复算口径
- 总输入、缓存和非缓存可直接复算,小时采样透明。
图中指标
- 总体缓存率97.059%
fact.bill.cachePercent - 非缓存输入2,437,981
- 请求877
fact.bill.requests - 金额推算不做
Token和缓存只能说明调用规模。工具生命周期、日志合并和数据库关系才解释这些数字怎样形成。
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 复合键工具统计|图中结论:13类工具分布可由日志按复合键去重
查看来源与复算数据
- 数据来源
- 复合键工具统计
- 复算口径
- 13类工具分布可由日志按复合键去重。
图中指标
- 工具调用968
fact.tools.total - 工具类别13
- WebBrowser376
fact.tool.WebBrowser - 裸序号422
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / ToolExecutionPipeline冻结日志|图中结论:每次调用均有验证、实际调用和完成
查看来源与复算数据
- 数据来源
- ToolExecutionPipeline冻结日志
- 复算口径
- 每次调用均有验证、实际调用和完成;17次error=true分类公开。
图中指标
- Stage1968
- Stage5968
- error=false951
fact.tools.success - error=true17
fact.tools.error
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / redaction-report.json + 两份源日志|图中结论:30,948+7,678块顺序合并,38,641行
下载并复算38,641行公开合并日志查看来源与复算数据
- 数据来源
- redaction-report.json + 两份源日志
- 复算口径
- 30,948+7,678块顺序合并,38,641行;技术ID保留。
图中指标
- 首段块30,948
- 续段块7,678
- 合并块38,626
fact.logs.blocks - 物理行38,641
fact.logs.lines
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 公开合并日志逐分钟聚合|图中结论:首末时间、每分钟密度和最大37.890秒无日志间隔可复算
查看来源与复算数据
- 数据来源
- 公开合并日志逐分钟聚合
- 复算口径
- 首末时间、每分钟密度和最大37.890秒无日志间隔可复算。
图中指标
- 窗口分钟331
- 时间块38,626
fact.logs.blocks - 最大静默37.890s
- 组件带8
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / db/*.json + provenance查询|图中结论:sessionId和时间窗口双重限定后导出行数可复算
查看来源与复算数据
- 数据来源
- db/*.json + provenance查询
- 复算口径
- sessionId和时间窗口双重限定后导出行数可复算。
图中指标
- 导出文件4
- messages229
- activities113
- 窗口内interactions4
最后把七个证据域放在一起,检查哪些结论由多种格式共同约束,哪些仍停留在本地信任域。
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 代码/日志/DB/账单/截图/视频/浏览器验收|图中结论:产物、过程、成本和终态由不同材料交叉约束
查看来源与复算数据
- 数据来源
- 代码/日志/DB/账单/截图/视频/浏览器验收
- 复算口径
- 产物、过程、成本和终态由不同材料交叉约束。
图中指标
- 证据域8
- 日志+事件40,644
- 媒体文件53
- 第三方可信时间戳0
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 证据账本E01–E42|图中结论:42条案例证据分别连接来源、位置与核验方式
查看来源与复算数据
- 数据来源
- 证据账本E01–E42
- 复算口径
- 42条案例证据分别连接来源、位置与核验方式。
图中指标
- 证据编号42
- 证据分域6
- 来源类型8
- 复算矩阵1
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 核心主张与证据对应表|图中结论:二十条核心结论分别连接最强证据和可确认结果
查看来源与复算数据
- 数据来源
- 核心主张与证据对应表
- 复算口径
- 二十条核心结论分别连接最强证据和可确认结果。
图中指标
- 核心主张20
- 最强证据列1
- 可确认结论列1
- 公开证据编号42
数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / verify-king-case.mjs + SHA256SUMS|图中结论:公开证据可完成统计、引用、SVG、媒体、密钥和哈希验证
查看来源与复算数据
- 数据来源
- verify-king-case.mjs + SHA256SUMS
- 复算口径
- 公开证据可完成统计、引用、SVG、媒体、密钥和哈希验证。
图中指标
- 验证路径2
- Schemav7
- SVG91
- 秘密命中0
8.1 Token 三口径对账 日志 数据库
TABLE-27 · 原始表格 · 对应 AUDIT-V01
| 口径 | 来源文件 | 请求/消息数 | 输入 Tokens | 输出 Tokens | 说明 |
|---|---|---|---|---|---|
| 账单口径 | bill/request_log_part_0001.csv | 877 请求(全部落在窗口内) | 82,906,205 | 673,938 | 含 Cached Tokens 80,468,224(缓存命中率 97.1%);kimi-k3 / moonshot |
| 运行时口径 | logs/observability-events-…jsonl | 878 started / 873 completed / 5 failed | 82,300,554 | 670,170 | 873 个 completed 的 input/output token 元组与账单中的 873 行逐条精确匹配 |
| 消息口径 | db/session-messages.json | 229 条(窗口内) | 7,386,868 | 58,959 | assistant 消息粒度:input 为当轮全量上下文(历史重复计入);与观测日志中协调者 run 的合计逐数字一致(见 PART 4.2) |
8.2 逐小时 Token 分布(账单 CSV 复算) 日志
TABLE-28 · 原始表格 · 对应 AUDIT-V02
| 小时 | 请求数 | 输入 Tokens | 输出 Tokens | 缓存 Tokens | 对应阶段 |
|---|---|---|---|---|---|
| 01:00–02:00 | 34 | 1,744,149 | 61,248 | 1,579,776 | 需求确认 + R01 地基 |
| 02:00–03:00 | 119 | 8,610,920 | 136,459 | 8,298,752 | R01 收尾 + R02 战斗 |
| 03:00–04:00 | 123 | 11,250,967 | 106,424 | 10,854,144 | R03 AI + R04 堵路修复 |
| 04:00–05:00 | 137 | 12,886,735 | 110,393 | 12,550,656 | R05 僵持修复 + R06 门径修复 |
| 05:00–06:00 | 191 | 21,442,413 | 155,579 | 20,570,624 | R06 收尾 + R07 UI + R08 视觉 |
| 06:00–07:00 | 269 | 26,597,581 | 102,629 | 26,242,560 | R08 收尾 + R09 修复 + R10 QA + 最终验收 |
| 07:00–07:01 | 4 | 373,440 | 1,206 | 371,712 | 窗口边缘收尾 |
| 合计 | 877 | 82,906,205 | 673,938 | 80,468,224 | — |
8.3 878个LLM请求的双向账本与耗时审计 日志实测 requestId闭合
验证脚本以 data.requestId 建立开始账和终态账,而不是只数成功响应:878个唯一started requestId全部且仅有一个终态,873个completed、5个failed;缺失、孤立和重复终态均为0。
画面与代码对应:878个started requestId各自有且只有一个终态;873个完成请求耗时可由公开事件逐条复算。
8.4 工具调用分布(968 次,13 种,按“sessionId+runId+toolUseId”复合键去重) 日志
复核命令见附录 A.2 第4条。为什么必须用复合键:968个 sessionId+runId+toolUseId 只对应422个裸工具序号;序号会跨Run复用,直接按裸ID去重会低估。376个WebBrowser复合键又与376个唯一Python POST requestId 一一对应(缺失0、重复0)。这证明浏览器请求真实进入执行链,不把调用数解释为376项相互独立且全部通过的测试。
8.4b 968次工具调用的完整生命周期 日志实测 源码机制
error=falseerror=true验证脚本以 sessionId + runId + toolId 为复合键重建每个调用。结果精确为968 / 968 / 968次验证、实际调用和完成:968个调用全部各有一条三段记录,没有孤立Stage或重复完成。其中951 次返回 error=false,17 次返回 error=true,前者占98.244%。
TABLE-29 · 原始表格 · 对应 AUDIT-V05
返回 error=true 的工具 | 次数 | 应如何解读 |
|---|---|---|
| Edit | 6 | 这些是工具管线明确记录的错误结果,证明本案不是“零错误”。完整生命周期让错误可被后续循环读取和处理;但仅凭完成记录,不能断言17次错误都被自动修复。 |
| WebBrowser | 5 | |
| Agent | 3 | |
| Bash | 2 | |
| CodeIntel | 1 |
这组数据比“工具很多”更能解释平台为什么能承载长任务:重要的不是工具数量,而是调用、失败和结果都进入同一个可追踪循环。98.244%只是本会话完成记录中 error=false 的比例,不是ZhikunCode产品总体可靠率。
8.5 日志证据(窗口过滤,保留原始行格式) 日志
TABLE-30 · 原始表格 · 对应 AUDIT-V06
| 文件 | 行数 | 内容 | SHA-256(截断) |
|---|---|---|---|
logs/app-session-20260809-0130-0701.public.log | 38,641 | 应用全量日志(两段已捕获轮转日志按时间窗口过滤后顺序合并,保留同毫秒不同事件与多行续行) | ba3220722af426d9… |
logs/observability-events-20260809-0130-0701.jsonl | 2,003 | 结构化观测事件(llm_call/subagent/process/run 终止摘要) | 8a9b0248996bf2ea… |
logs/security-audit-20260809-0130-0701.log | 116 | 工具调用安全审计事件 | 17c57520f9b7d939… |
8.6 日志原文摘录(带行号,可对照原件核验)
# observability 第 1 行(窗口内第一次模型调用,01:31:15) 1:2026-08-09T01:31:15.223+08:00 {"eventType":"llm_call_started","runId":"eb2e9ba2-6975-4c83-9e83-8eebcb7f1b10","data":{"model":"kimi-k3","provider":"moonshot","schemaVersion":1,"runId":"eb2e9ba2-...","sessionId":"b8f86099-...","requestId":"llm-f32308a5-...","occurredAt":"2026-08-08T17:31:15.223048Z","attemptCount":0,"turn":1}} # observability 第 13 行(R01 启动,01:39:58) 13:2026-08-09T01:39:58.931+08:00 {"eventType":"subagent_started","runId":"eb2e9ba2-...","data":{"isolation":"none","childSessionId":"subagent-agent-64f62e42","promptLength":2697,"agentId":"agent-64f62e42",...}} # observability 第 1190/1683/1943 行(3 个 max_turns 终态:R07/R09/R10) 1190:2026-08-09T05:35:06.570+08:00 {"eventType":"subagent_failed",...,"agentId":"agent-596000a2","status":"max_turns"...} 1683:2026-08-09T06:32:05.553+08:00 {"eventType":"subagent_failed",...,"agentId":"agent-9b527904","status":"max_turns"...} 1943:2026-08-09T06:52:45.292+08:00 {"eventType":"subagent_failed",...,"agentId":"agent-adc6f86f","status":"max_turns"...} # observability 末行(窗口内最后一次调用完成,07:00:32) 2003:2026-08-09T07:00:32.541+08:00 {"eventType":"llm_call_completed",...,"inputTokens":93678,...} # app-session 首行(01:30:01,WebSocket 心跳:会话存活证据) 1:2026-08-09 01:30:01.517 INFO [clientInboundChannel-3] [sid=- ...] c.a.websocket.WebSocketController - push(pong) to principals=1, sessionId=b8f86099-... # security-audit 首行(01:34:59,Bash_2 环境探测的审计事件) 1:2026-08-09 01:34:59.854 INFO [zhiku-tool-Bash] [sid=b8f86099-... tool=Bash_2 llm=llm-ce24f1c1-...] security-audit - [SECURITY-AUDIT] event=...
8.7 数据库证据 数据库
TABLE-31 · 原始表格 · 对应 AUDIT-V08
| 导出文件 | 内容 | 关键事实 |
|---|---|---|
db/session-row.json | sessions 表本会话完整行 | 创建 2026-08-08T17:26:20Z(=01:26:20+08)· 模型 kimi-k3 · working_dir=<PROJECT_ROOT> |
db/session-messages.json | messages 表窗口内 229 行(117 user / 112 assistant;含协调者全部提示词、工具调用、worker 通知原文) | 首条 01:31:15(用户需求原文)→ 末条 07:00:32;与日志/截图逐条互证 |
db/activities-20260809-0130-0701.json | 按会话 ID 与窗口双重限定的 activities 113 行 | 工具活动、耗时、决策和变更文件的不可变公开快照 |
db/interaction-requests-20260809-0130-0701.json | 窗口内 4 条 elicitation | 需求确认原值;开发窗口内 permission=0 |
重要口径:sessions.total_input_tokens 与 total_output_tokens 在冻结行中均为 0,说明这两个会话汇总字段当时未填充,不能拿来否定或替代逐消息/逐调用统计。Token 事实以 messages、observability 与账单 CSV 为准。活动数据库在报告编写后仍会增长,因此只引用上述窗口冻结导出,不引用“当前全库总数”。
8.8 证据账本(E01–E42:每条核心声明 → 来源 → 位置 → 核验方式) 实测
TABLE-32 · 原始表格 · 对应 AUDIT-V10
| ID | 声明 | 来源 | 位置/核验 |
|---|---|---|---|
| E01 | 墙钟 5:29:17(01:31:15→07:00:32) | DB messages 首末行 + CSV 首末行 | db/session-messages.json;CSV 第 1/877 数据行 |
| E02 | 19 个第一方文件 / 7,979 行(含 13 行启动器) | wc -l 逐文件复算 | 附录 A.2-2 命令;PART 2.1 表 |
| E03 | 10 个子 Agent:事件字段 completed=7/failed=3;终止语义为 1 自然完成/6 deadline/3 max_turns | 观测事件 subagent_* + run_termination_summary | observability;PART 4.1 账本与 PART 5 |
| E04 | 877 请求 / 输入 82,906,205 / 输出 673,938 | 账单 CSV 复算 | 附录 A.2-3 命令(应输出 877 82906205 673938 80468224) |
| E05 | 缓存命中率 97.1% | CSV Cached 80,468,224 ÷ 输入 82,906,205 | 同上命令 |
| E06 | 运行时口径 873 次 / 82,300,554 输入 | 观测事件 llm_call_completed | 附录 A.2-5 命令 |
| E07 | 协调者 Token 两个本地记录面逐数字一致(7,386,868/58,959) | DB assistant 消息合计 = 观测日志主会话 run 合计 | PART 4.2 表注;两文件可分别复算但共享本地信任域 |
| E08 | I1:约 100 兵堵死在 (-80,60) | 协调者 evaluate 返回(t=780s) | session-messages.json;PART 6 · I1 实录 |
| E09 | I2:t=1350s 僵持(红 0 塔/水晶满血) | 协调者 evaluate 返回 | session-messages.json;PART 6 · I2 实录 |
| E10 | I3:英雄贴墙坐标(-60,-86)/(-61,-74) | 协调者 evaluate 返回(t=1087s) | session-messages.json;PART 6 · I3 实录 |
| E11 | 3/3 局分出胜负(18:47/13:47/13:53) | R06 汇报 + 协调者复核 | PART 4.5 汇报原件;PART 7.2 表 |
| E12 | 最终验收 __errors 为空 | 多轮 evaluate window.__errors | V01–V12 表;session-messages.json |
| E13 | 结算界面字段(失败 3:3 09:23 / 战绩 0/0/0 / 补刀 30 / 等级 11) | 协调者 evaluate 返回 | PART 7.1b 实录 |
| E14 | 43 张截图全量公开 | screenshots/ 目录 | 附录 A.1b 逐张清单(时刻/字节/SHA-256) |
| E15 | 5 份录屏原件(3 份窗口内、2 份窗口外补充)及 5 份派生预览 | release-assets.json + videos/previews/ | PART 7.4;原件/预览 SHA-256 映射 |
| E16 | 提示词指纹 10 组(promptLength+SHA) | 观测事件 subagent_started.data | PART 4.3 指纹表;提示词原文在 DB 可逐字校验 |
| E17 | 工具调用968次/13种;422个裸工具序号不足以唯一定位 | app.log按sessionId+runId+toolUseId复合键去重 | 附录A.2-4命令;PART 8.4分布 |
| E18 | 4 项需求确认:首项创建至末项决定落库 39.6 秒 | interaction_requests created_at/decided_at | PART 1.2b 窗口冻结原账 |
| E19 | 开发窗口内 permission=0;窗口外补充含 9 条 permission,状态均 answered | 两份 interaction_requests 冻结导出 | PART 3.4;窗口外补充文件 |
| E20 | 门径修复符号:BASE_GATES / _gateRoute / ASSAULT | 最终代码 | config.js:118;ai.js:827;ai.js:422 |
| E21 | 协调者直改 isCrystalInvuln | 最终代码注释自证 | state.js:911-925(PART 6 · I2 引文) |
| E22 | FPS 6 → 31.8(软渲染) | R09 汇报 + 事故/修复后截图 | 截图 ≈06:09 事故帧 FPS=6;PART 6 · I4 |
| E23 | 闪红壳层化(不污染共享材质) | 最终代码 | vfx.js:18 SHELL_POOL / :191-192 注释 |
| E24 | 9 次中断后均有接续记录(6 deadline + 3 max_turns) | 观测事件 + activities duration | PART 5.1 账本;observability 行号 1190/1683/1943 |
| E25 | 17 个 src/*.js 模块 / 39 条本地相对导入边(38 条第一方、1 条 vendored) | 最终源码静态解析 | PART 2.1c;verification.json.code.moduleGraph |
| E26 | 267 次原子写入成功 / 157 次 Checkpoint 保存 / MCP 60 组断线重连配对 | 冻结应用日志按组件与消息文本复算 | PART 3.2b;verification.json.logs.executionControls |
| E27 | ea0170c为窗口前最近提交;7个相关运行时源码到窗口后文档提交均未改变 | Git提交时间、差异文件与逐文件SHA-256 | PART 3.1e;verification.json.platformSnapshot |
| E28 | 878次上下文评估 / 26次轻量折叠 / 释放2,029字符 / 峰值240,202低于650,000阈值 | 冻结应用日志中的ContextCascade与ContextCollapseService事件 | PART 3.1d;verification.json.logs.contextGovernance |
| E29 | 968次工具调用均具备验证、调用、完成三段;951次error=false、17次error=true | ToolExecutionPipeline日志按sessionId+runId+toolId复合键重建 | PART 8.4b;verification.json.logs.toolLifecycle |
| E30 | 独立平台旁证:SWE-bench Lite 168/300 resolved、284/300非空补丁 | 公开results、300行all_preds、metadata与技术报告 | 附录A.3d;verification.json.externalBaseline |
| E31 | 第一方7,979行的领域构成与17模块/39边运行图 | 冻结代码逐文件行数与静态import解析 | PART 2B · KING-V01–V04;verification.json.code.productComplexity.sourceLineDomains |
| E32 | 180×180地图:3路、18塔、14草丛、10营地、2水晶/泉水、6基地门、120树/46石 | config.js与spawner.js静态复算 | PART 2B · KING-V05–V08;verification.json.code.productComplexity.mapTopology |
| E33 | 30Hz固定逻辑、最大5次补步与GameState十阶段更新顺序 | main.js/state.js最终代码 | PART 2B · KING-V09–V11;verification.json.code.runtimePipeline |
| E34 | 1名玩家+9名AI英雄,Hero/Minion/Tower/Monster四类规则AI | main.js/ai.js与最终浏览器单位断言 | PART 2B · KING-V12–V15;verification.json.code.aiTopology |
| E35 | 5英雄、15项主动技能、6种aim语义与跨模块施法链 | skills.js静态定义及最终交战截图 | PART 2B · KING-V16–V20;verification.json.code.productComplexity.combat |
| E36 | 选将→对局→水晶→结算→重开闭环与经济时间系统 | 首尾截图、V08–V10验收及config/state/shop代码 | PART 2B · KING-V21–V23;verification.json.code.productComplexity.progression |
| E37 | Canvas/程序化模型/WebAudio与1024/48/12/10/12特效池;完整HUD联证 | map/models/vfx/audio/ui最终代码与HUD截图 | PART 2B · KING-V24–V25;verification.json.code.presentationPipeline |
| E38 | 26张专题级SVG:1,239个图内直接标签、273个可聚焦节点、6张截图覆盖联证图;7组截图—代码绑定 | 每图的密度、源码符号、引用、热点、工程范围、截图SHA-256与代码摘录均由验证脚本校验 | PART 2B · KING-V01–V26;verification.json.productVisualizationRichness |
| E39 | 38,626条MDC行可重建11个会话、11个Run与10条Worker父子关系 | 冻结应用日志的sid/rid/prid/agent字段逐行解析 | PART 3 · LOG-V01;verification.json.logs.traceability |
| E40 | 968个复合工具键仅有422个裸工具序号;376个WebBrowser键与376个Python请求ID一一对应 | ToolExecutionPipeline MDC与PythonCapabilityAwareClient POST记录交叉 | PART 3/8 · LOG-V01;verification.json.logs.toolIdentity |
| E41 | 878个LLM requestId终态闭合;873个completed总耗时16,005,982ms,中位7,652ms、P95 61,546ms | 冻结观测事件按data.requestId配对并以nearest-rank复算 | PART 8 · LOG-V02;verification.json.logs.llmAudit |
| E42 | 5次模型取消、17次工具错误、6次deadline、3次maxTurns和60组MCP重连均有独立终态 | 观测事件与冻结应用日志按类型、复合键和时序复算 | PART 3 · LOG-V03;verification.json.logs.failureContinuation |
8.8b 核心主张—最强证据—可确认结论 工程结论
TABLE-33 · 原始表格 · 对应 AUDIT-V11
| 核心主张 | 最强证据 | 可确认结论 |
|---|---|---|
| 首末模型请求/账单锚点跨度5小时29分17秒 | E01:DB消息首末时刻与账单时间锚点 | 冻结记录覆盖01:31:15至07:00:32,共5:29:17 |
| 交付了可运行的单机Web 5v5 MOBA原型 | G01–G16验收合同、V01–V12、E12/E15、代码快照 | 指定浏览器和已测路径中存在3D地图、双方英雄、战斗、推进、HUD与终局流程 |
| 17个模块形成跨系统集成 | E25:源码静态解析与模块依赖链 | 17个模块发出39条本地相对导入边,入口与核心状态连接多个子系统 |
| 最终产物是多系统实时耦合仿真,而非静态页面拼装 | E31–E33:领域代码构成、地图拓扑、双时钟与十阶段世界更新 | 地图、输入、AI、技能、兵线、建筑、经济与UI在同一GameState和固定tick中持续交换状态 |
| 游戏难度来自多类自主单位与战斗规则同时运行 | E34/E35:9名AI英雄、四类AI规则、15项技能与六种瞄准语义 | 最终源码存在不同目标选择、状态机、技能、弹道、控制和结构攻防路径 |
| 最终画面可以与实现代码逐项对应 | E38:7组冻结截图—SVG热点—源码摘录绑定 | 地图、基地、龙坑、战斗、选将结算和HUD中的可见对象均有具体源码入口 |
| 26张产品图没有扩大原型的能力边界 | E38与KING-V26的三层范围图 | 报告明确区分有代码及运行证据、有限路径观察和未实现能力 |
| ZhikunCode编排了10次Worker运行 | E03/E16:subagent事件、childSessionId与提示词指纹 | 本地运行时记录了10个隔离子会话及其任务、时限和终态 |
| 执行链可以沿标识符重建 | E39/E40:11个会话与Run、10条parentRun映射、968个工具复合键、376个下游请求ID | 具体工具可归属到Worker会话、子Run、父Run、轮次、LLM请求及Python请求,不依赖并发时间猜测 |
| 请求级Token与耗时具备复算审计价值 | E04/E06/E41:873条账单匹配、878个requestId终态闭合和durationMs分布 | 开始/终态数量、Token元组及873个完成请求的总计、均值、中位数、P95和最大值可独立复算 |
| 浏览器反馈进入了开发闭环 | E17:968次工具调用中WebBrowser为376次;会话中的evaluate与截图记录 | 协调者和Worker大量调用真实浏览器观察运行状态并据此复验 |
| 长任务期间存在持续保存与连接恢复 | E26:267次原子写入、157次Checkpoint保存、60组MCP配对 | 相应成功保存和连接恢复事件在窗口内逐条存在且可复算 |
| 长上下文在每轮调用前受到治理 | E28:878个唯一ContextCascade事件与878次llm_call_started对齐 | 每轮模型调用前都执行预算评估;26轮轻量折叠合计释放2,029字符 |
| 工具调用经过统一生命周期 | E29:968个复合键均有Stage 1、Stage 5和完成记录 | 调用及错误结果完整进入可追踪管线;951次error=false、17次error=true |
| 局部失败没有阻断最终交付 | E03/E24/E26/E29:模型失败、工具错误、Worker终止、MCP重连与保存事件 | 这些局部事件之后仍有后续调用、续作Worker和最终验收记录 |
| 平台源码机制与日志组件交叉一致 | E27:窗口前源码快照、固定类链接、窗口后文档提交差异 | 相关类在窗口前已存在,且多项同名组件出现在冻结日志 |
| 运行事件和模型账单高度一致 | E04/E06:873条completed与873条账单Token元组逐条匹配 | 两份公开记录中的873组输入/输出Token数精确对应,另有4条账单差异已定位 |
| 最终版本通过本地验收并完成云端访问验证 | E12/E15、PART 7窗口内验收、窗口外浏览器回归与阿里云在线试玩录屏 | 指定时刻、环境和演示路径中页面可运行,窗口外曾通过HTTPS在线访问 |
| 同一平台还存在仓库级编码基线 | E30:SWE-bench Lite自运行产物、300行预测与结果文件 | 另一配置使用qwen3.7-max和六工具闭集取得168/300 resolved、284/300非空补丁 |
8.9 缓存 Token 专题(只陈述 CSV 可证明的范围) 日志 推断
账单口径输入 82,906,205 tokens 中,Cached Tokens 列合计 80,468,224,差值为非缓存输入 2,437,981,缓存占输入 97.059%。CSV 没有价格、折扣、缓存写入费用或结算币种,因此不能从这些列推出实际节省金额,也不能把非缓存 token 直接称为“等价计费输入”。长上下文共享前缀可能解释高缓存占比,但这是基于常见缓存机制与调用形态的推断,不是 CSV 自身提供的因果字段。
TABLE-34 · 原始表格 · 对应 AUDIT-V03
| 采样(每小时首个请求) | 单轮输入 Tokens | 其中缓存命中 | 命中率 |
|---|---|---|---|
| 01:32:05(首个请求) | 17,387 | 0 | 0% |
| 02:00:07 | 69,654 | 69,376 | 99.6% |
| 03:03:12 | 81,147 | 73,216 | 90.2% |
| 04:04:28 | 58,108 | 49,408 | 85.0% |
| 05:01:29 | 115,715 | 114,432 | 98.9% |
| 06:00:05(峰值) | 182,227 | 178,176 | 97.8% |
| 07:00:32(窗口内最后请求) | 93,678 | 93,440 | 99.7% |
采样显示单轮输入从 17K 增至峰值 182K,多数采样行的 Cached Tokens 占比较高。它支持“长上下文调用与高缓存占比同时出现”的相关性描述;不支持“计费输入近似恒定”或具体成本倍数。采样方法:账单 CSV 按时间升序取每小时首行 + 窗口末行,复算见附录 A.2-3。
口径声明:本报告只公开精确 token 数和比例,不估算金额、节省倍数或无缓存反事实成本。若要做成本分析,必须另行公开 2026-08-09 当时适用的提供方计费规则。
8.10 外置哈希清单与机器复核结果 实测
为避免 HTML 内嵌清单与外部文件产生双重事实源,本版不再复制整份哈希清单。仓库内证据文件以 SHA256SUMS.txt 为唯一哈希清单;五份不进入普通 Git 历史的原始视频由 release-assets.json 单独登记原始 SHA-256、媒体信息与派生预览映射。
机器复核输出见 verification.json,来源、时间窗口、导出 SQL 与信任边界见 provenance.json。清单和结果由 node scripts/verify-king-case.mjs --write 在定稿后生成,避免人工复制导致陈旧。
这次任务说明了什么
TABLE-35 · 原始表格 · 对应 META-V01
| 能力命题 | 直接证据 | 证据位置 |
|---|---|---|
| 一句话需求→可玩复杂原型 | 19 个第一方文件、7,979 行的单机 Web 5v5 MOBA 原型;V01–V12 在记录的验收路径中通过,观察窗口内未记录错误 | PART 0/2/7 |
| 需求治理:先确认后自动 | 唯一一轮 4 项确认(AskUserQuestion=1 次与日志互证);开始编码后系统未再向用户提问,用户仅在 02:09 主动补充端口约束 | PART 1/8.4 |
| 多 Agent 长程编排 | 10 个子 Agent 接力;6 次达到 30 分钟期限后,落盘产物经复核并由后续运行继续使用;统一规范与提示词指纹均已公开 | PART 4/5 |
| 同系统复核发现高影响问题 | 4 个阻塞或高影响问题由协调者复测发现(堵车/僵持/贴墙/发光);这是隔离步骤,不是第三方独立 QA | PART 6 |
| 修复必须带回归 | I3 修复连跑 3 局全部分出胜负才关闭;每处修复有前后对照数据 | PART 6/7.2 |
| 全过程可复算 | 873 条运行时 completed 与账单逐条精确匹配;本地日志、DB、代码与截图可按脚本复算,信任边界明确披露 | PART 8/附录 |
这个案例已经展示什么,下一步向哪里走
结果值得认可,不是因为调用次数多,而是多系统产物、失败后的接续、真实浏览器反馈和可复查材料同时存在。
最后把本案例已经展示出的能力和下一阶段路线放在一起,给出清楚、直接的工程判断。
数据:E01 / E25 / E26 / E30 / E38 / E42 / 产物 + 运行链 + 复验 + E01–E42|图中结论:平台把通用模型转化为能持续执行、接续和复验的软件工程系统
查看来源与复算数据
- 数据来源
- 产物 + 运行链 + 复验 + E01–E42
- 复算口径
- 平台把通用模型转化为能持续执行、接续和复验的软件工程系统。
图中指标
- 能力维度6
- Run11
fact.run.total - 工具968
fact.tools.total - 证据编号42
数据:E01 / E25 / E26 / E30 / E38 / E42 / 已知限制原表|图中结论:当前原型的功能完成面与十一项下一阶段工程路线同时列出
查看来源与复算数据
- 数据来源
- 已知限制原表
- 复算口径
- 当前原型的功能完成面与十一项下一阶段工程路线同时列出。
图中指标
- 下一阶段事项11
- 路线分类5
- 当前原型1
- 明确验证项11
原型已经完成核心闭环;下一阶段路线把它如何继续走向更完整产品写得同样具体。
数据:E01 / E25 / E26 / E30 / E38 / E42 / 质疑应答区 + 证据账本|图中结论:十个关键问题均由现有代码、日志、账单和验收材料给出直接回答
查看来源与复算数据
- 数据来源
- 质疑应答区 + 证据账本
- 复算口径
- 十个关键问题均由现有代码、日志、账单和验收材料给出直接回答。
图中指标
- 关键问题10
- 证据回答10
- 证据类型7
- 核心闭环1
数据:E01 / E25 / E26 / E30 / E38 / E42 / assets/king目录 + 文件系统统计|图中结论:109个仓库文件与5个待发布Release原件均有路径、字节数和SHA-256映射
查看来源与复算数据
- 数据来源
- assets/king目录 + 文件系统统计
- 复算口径
- 109个仓库文件与5个待发布Release原件均有路径、字节数和SHA-256映射。
图中指标
- 仓库文件109
- Release原件5
- 截图43
- 代码快照22
当前实现与下一阶段 工程路线
TABLE-36 · 原始表格 · 对应 META-V02
| # | 当前实现 | 运行事实与下一步 |
|---|---|---|
| L1 | 五英雄镜像阵容 | 当前5个英雄支撑10个上场位;下一步扩充英雄池并加入非镜像阵容回归 |
| L2 | 水晶解防后转集团推进 | GROUP_PUSH在终局阶段优先直接推进;下一步对长局龙区资源利用进行数值采样 |
| L3 | 技能与建筑采用分开结算 | AoE/指向技能处理单位,普攻处理塔与水晶;下一步增加逐技能×建筑回归矩阵 |
| L4 | headless软渲染21–31.8 FPS | 已记录335 draw calls和软渲染帧率;下一步在GPU、多分辨率和多设备上建立帧时基准 |
| L5 | 防御塔伤害链已运行 | R10 QA实测塔315/s伤害正常;下一步为防御塔攻击增加独立音效事件 |
| L6 | 结算界面正确定格终局 | 界面显示09:23终局时刻;下一步在结算状态同步暂停state.time |
| L7 | 程序化低模视觉 | 几何、Canvas地表和粒子特效在无外部运行时素材下形成统一风格;下一步可引入正式美术管线 |
| L8 | 五份录屏已分层登记 | 3份属于开发窗口,2份为窗口外补充;预览版已记录倍速、编码、时长和SHA,下一步增加逐帧事件标注 |
| L9 | 四局终局路径已跑通 | 3局回归加1局终验均为红胜,已完成水晶、结算和重开验收;下一步进行阵营互换、多随机种子的大样本平衡测试 |
| L10 | 音频事件链已连接 | bannerCount递增和audio.play绑定已通过headless代码路径验证;下一步在有声环境完成听觉QA |
| L11 | 公开哈希清单已建立 | SHA-256用于核对发布后字节一致;下一步使用签名标签与外部时间戳完成公开存证 |
9.1 十个关键问题:从证据直接回答 实测
TABLE-37 · 原始表格 · 对应 META-V03
| 质疑 | 回应(均指向报告内证据) |
|---|---|
| "演示局全是红方赢,是不是 AI 失衡?" | 现有 4 局样本不足以下结论,且蓝方玩家位由演示脚本而非完整 AI 状态机操控。报告只确认这些路径能够结束比赛;阵营平衡需要对称控制、更多随机种子和统计检验。见 PART 7.2 与 L9。 |
| "10个Worker的终态如何?" | 1次自然完成、6次到30分钟期限、3次到最大轮次。每次终态都被记录,已落盘产物由协调者复测、整合并继续分派,最终完成交付。 |
| "最终全链路验收由谁完成?" | R10是隔离上下文的同系统QA Worker,运行19m03s后到轮次上限;协调者按同一清单补完余下项,并把两段验收记录同时保留。 |
| "截图和数据如何交叉核对?" | 43个截图文件对应42份唯一内容,5份原视频登记SHA-256,38,641行应用日志可重建开发窗口,873条运行时Token元组与账单逐条一致。这些材料通过时间、Run、工具ID和哈希相互定位。 |
| "为什么不给费用估算?" | 账单 CSV 不含单价字段。本报告只公开精确 Token 量(输入 82,906,205 / 输出 673,938 / 缓存 80,468,224),读者可按自己掌握的 kimi-k3 当时费率复算——宁可缺一个数字,也不造一个数字(PART 8.1 口径声明)。 |
| "窗口(01:30–07:01)之外有没有混入内容?" | 有,但均隔离标注:09:21 最终运行录屏、11:53 阿里云在线试玩录屏、模板分析、窗口外 12 条报告编写/审计交互,以及本报告与验证元数据。开发日志、观测事件、消息/活动/需求确认统计仍严格限定在窗口内;窗口外素材只作补充,不进入开发耗时和行为统计。 |
| "为什么没有 git 提交历史?" | 项目未初始化 git 仓库——这是事实而非隐瞒。演进证据用三重替代:各阶段 wc -l 实测行数、产物哈希清单、Worker 交付汇报原文(PART 4.3/4.4/4.5)。 |
| "游戏是否用了《王者荣耀》的素材?" | 现有代码和资产扫描未发现官方美术、音频或模型文件;视觉资源为程序化几何/Canvas/粒子,音效路径为 WebAudio/TTS。项目仍使用游戏名称、英雄名称和玩法参照,因此这里只是素材来源陈述,不是法律合规意见。 |
| "报告发布后发现过错误吗?" | 有。v5 证据级审计继续修正了文件数、Agent 终止语义、交互历时、数据库动态总数、工具复算命令、账单差异、缓存成本外推、图片说明、平衡性、录屏映射及证据真实性边界。保留这段更正史,是为了让后续审查者区分原始记录与报告解释。 |
证据快照、派生预览与核验方法
仓库内证据位于 assets/king/。代码、日志、账单、数据库冻结导出和截图保持内容不变;视频同时保留五份原始审计母版与五份明确标注的派生预览。高置信度密钥扫描覆盖私钥、常见云访问密钥、provider secret、GitHub/Slack token 与 JWT,当前为 0 命中;账单中的 API Key ID 和项目 ID 是标识符,不是可直接用于鉴权的密钥值。
A.1 素材目录树 实测
PRE-23 · 原始代码/日志 · 对应 META-V04
assets/king/ ├── SHA256SUMS.txt # 仓库内证据的唯一哈希清单(原始大视频另见 release-assets.json) ├── DESIGN.md # 协调者撰写的开发规范(10 个 worker 共用,5,925 字符) ├── template-analysis.md # 本报告编写期的模板解剖报告(吃鸡.html/淘宝.html,窗口外产物) ├── code/ # 21 个代码文件的最终快照 + Three.js MIT 许可证 ├── screenshots/ # 43 个截图文件 / 42 份唯一图像内容 ├── videos/ # 5 份 HEVC 审计母版(普通 Git 忽略)+ previews/5 份 H.264 派生预览 ├── logs/ # 3 个日志文件,40,760 行(窗口 01:30–07:01 过滤) ├── db/ # session/messages + 113 activities + 4 窗口内交互 + 窗口外补充 ├── provenance.json # 来源、窗口、导出 SQL 与信任边界 ├── verification.json # 机器可读复算结果 ├── release-assets.json # 5 份原视频与预览映射;Release URL 待人工确认 └── bill/ # 877 条数据 + 1 条表头,共 878 个物理行
A.1b 43 张截图逐张清单(文件名 · 截取时刻 · 字节数 · SHA-256 前 12 位)
| 文件(相对 assets/king/screenshots/) | 时刻 | 字节 | SHA-256 |
|---|---|---|---|
phase1-map/shot1_spawn_fountain.png | 152,800 | 74e5521f1890… | |
phase1-map/shot2_walking_lane_tower.png | 634,620 | b1824471bcf4… | |
phase1-map/shot3_river_pit_brush.png | 460,303 | 28ef594d935e… | |
phase1-map/shot4_enemy_tower.png | 683,219 | 12321ef7de75… | |
phase1-map/shot5_enemy_base_crystal.png | 128,414 | f6e4a5de7193… | |
phase1-map/shot6_overview_river_center.png | 985,021 | 815a9c23b57f… | |
phase2-combat/1_minion_clash.png | 622,242 | 9ace684e4575… | |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786214784060.png | 02:46:24 | 610,651 | 520b128d280d… |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786224926438.png | 05:35:26 | 461,017 | dd90687c376e… |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786224971688.png | 05:36:11 | 475,925 | cdefd9f3ad93… |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786225061947.png | 05:37:41 | 192,858 | 42a4cfe4fe0f… |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786226976445.png | 06:09:36 | 572,350 | a11244f38f0f… |
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786228379180.png | 06:32:59 | 452,585 | bf7fb809cceb… |
screenshot_p5b_1786227389921.png | 06:16:29 | 596,506 | 3b96e9f41105… |
screenshot_p5b_1786227810671.png | 06:23:30 | 491,386 | 26e6dcbe4e48… |
screenshot_p5b_1786227848467.png | 06:24:08 | 545,684 | b69746ab3023… |
screenshot_p5b_1786227926106.png | 06:25:26 | 545,027 | 6d725df1717e… |
screenshot_p5b_1786227987623.png | 06:26:27 | 550,902 | 43ceca8b7369… |
screenshot_p5b_1786228021255.png | 06:27:01 | 470,976 | f1aa019c89ca… |
screenshot_p5b_1786228208808.png | 06:30:08 | 369,208 | a6fa8cf4f1a9… |
screenshot_p5b_1786228259525.png | 06:30:59 | 471,466 | 0b44431cf03d… |
screenshot_p5b_1786228298367.png | 06:31:38 | 522,165 | fe1ee9659858… |
screenshot_qa_1786228500285.png | 06:35:00 | 469,896 | 3f317e81814f… |
screenshot_qa_1786229033812.png | 06:43:53 | 421,972 | b0494d729e3a… |
screenshot_qa_1786229287687.png | 06:48:07 | 445,414 | 0ad8494dc876… |
screenshot_subagent-agent-1c86cd96_1786214519805.png | 02:41:59 | 622,242 | 9ace684e4575… |
screenshot_subagent-agent-392c10e7_1786226388657.png | 05:59:48 | 59,568 | 014ff5c8cabb… |
screenshot_subagent-agent-392c10e7_1786226491632.png | 06:01:31 | 574,962 | e0bc9236eae2… |
screenshot_subagent-agent-392c10e7_1786226526581.png | 06:02:06 | 217,304 | 9e382edbde32… |
screenshot_subagent-agent-392c10e7_1786226570166.png | 06:02:50 | 420,060 | 4a0e15728815… |
screenshot_subagent-agent-392c10e7_1786226660395.png | 06:04:20 | 194,239 | 859177a28346… |
screenshot_subagent-agent-392c10e7_1786226714869.png | 06:05:14 | 247,677 | 588701d8ec23… |
screenshot_subagent-agent-392c10e7_1786226855742.png | 06:07:35 | 355,847 | cfd52ddd282e… |
screenshot_subagent-agent-596000a2_1786224198927.png | 05:23:18 | 461,016 | d649635e8e30… |
screenshot_subagent-agent-596000a2_1786224248465.png | 05:24:08 | 192,937 | 765f9b0b4cc3… |
screenshot_subagent-agent-596000a2_1786224285049.png | 05:24:45 | 232,330 | 86abc79918dc… |
screenshot_subagent-agent-596000a2_1786224382375.png | 05:26:22 | 268,090 | 753a8690085a… |
screenshot_subagent-agent-596000a2_1786224523468.png | 05:28:43 | 432,962 | b2043a962742… |
screenshot_subagent-agent-596000a2_1786224568019.png | 05:29:28 | 566,298 | 97ba226d38af… |
screenshot_subagent-agent-596000a2_1786224619323.png | 05:30:19 | 262,109 | 0bd74cfc99ef… |
screenshot_subagent-agent-596000a2_1786224657609.png | 05:30:57 | 687,749 | a76c0e9f9620… |
screenshot_subagent-agent-6b9d1e29_1786222596187.png | 04:56:36 | 675,782 | 3e27d35a9426… |
screenshot_subagent-agent-6b9d1e29_1786223136843.png | 05:05:36 | 692,047 | eb77dcc3709f… |
A.2 独立复核方法
PRE-24 · 原始代码/日志 · 对应 AUDIT-V12
# 1. 核验素材哈希(在 docs/case-studies/assets/king/ 下) shasum -a 256 -c SHA256SUMS.txt # 应全部 OK,0 失败 # 2. 复算代码行数 find code -type f \( -name "*.js" -o -name "*.html" -o -name "*.command" \) | grep -v '/lib/' | LC_ALL=C sort | xargs wc -l # 19 文件,合计 7,979 # 3. 复算账单 Token python3 -c "import csv;r=list(csv.DictReader(open('bill/request_log_part_0001.csv',encoding='utf-8-sig')));print(len(r),sum(int(x['输入 Tokens']) for x in r),sum(int(x['输出 Tokens']) for x in r),sum(int(x['Cached Tokens']) for x in r))" # 应输出:877 82906205 673938 80468224 # 4. 复算工具调用分布 grep -oE 'sid=[^ ]+ rid=[^ ]+[^]]*tool=[A-Za-z]+_[0-9]+' logs/app-session-20260809-0130-0701.public.log | sed -E 's/.*sid=([^ ]+) rid=([^ ]+).*tool=([A-Za-z]+)_([0-9]+).*/\1 \2 \3 \4/' | sort -u | awk '{print $3}' | sort | uniq -c | sort -rn # 应输出:376 WebBrowser / 185 Edit / 162 Read / 102 Bash / 61 Sleep / 37 Write / 20 Grep / 11 TodoWrite / 10 Agent / Snip·Glob·CodeIntel·AskUserQuestion 各 1(合计 968) # 5. 复算观测事件 python3 -c "import json,collections;evs=[json.loads(l[l.find('{'):]) for l in open('logs/observability-events-20260809-0130-0701.jsonl')];print(collections.Counter(e['eventType'] for e in evs))" # 6. 运行统一机器复核(在仓库根目录) node scripts/verify-king-case.mjs # 应同时输出:trace 11/11/10;tool identity 968/422与browser 376/376;LLM 878/873/5、总耗时16005982ms;context 878/26/2029/240202;tool lifecycle 968/968/968、951/17 # 7. 直接运行游戏 cd code && python3 -m http.server 9201 # 打开 http://localhost:9201
A.3 start.command 全文(端口自适应启动器)
PRE-25 · 原始代码/日志 · 对应 SRC-V04
#!/bin/bash
# 王者峡谷 Web 版启动器——自动挑选空闲端口,避免与本机其他服务冲突
cd "$(dirname "$0")"
PORT=""
for p in 9201 9202 9203 9301 9302 9417 9418 9419; do
if ! lsof -iTCP:$p -sTCP:LISTEN -P -n >/dev/null 2>&1; then PORT=$p; break; fi
done
if [ -z "$PORT" ]; then
PORT=$(python3 -c 'import socket; s=socket.socket(); s.bind(("",0)); print(s.getsockname()[1]); s.close()')
fi
echo "启动王者峡谷: http://localhost:$PORT"
( sleep 1; open "http://localhost:$PORT" ) &
python3 -m http.server "$PORT"A.3b 案例互链(同仓库案例矩阵)
TABLE-39 · 原始表格 · 对应 META-V04
| 案例 | 文件 | 关系 |
|---|---|---|
| 黄金监控双工具对比审计 | zhikuncode-codex-gold-monitor-audit.html | 同仓库前序案例(含 evidence.json + 哈希清单同构方法) |
| 12306 候补可视化双工具对比 | zhikuncode-codex-12306-audit.html | 同仓库前序案例(README 载复核方法) |
| 本案例参考模板(未入库文档) | docs/zhikun/吃鸡.html、docs/zhikun/淘宝.html | 结构模板来源(模板解剖报告见 assets/king/template-analysis.md) |
平台的其他公开评测单独收录于SWE-bench技术报告;本案例正文只使用王者荣耀原型自身的代码、运行记录与验收素材。
A.4 发布与素材说明
① 证据窗口:开发日志、观测事件、messages、activities 与需求确认导出严格限定为 2026-08-09 01:30:00(含)至 07:01:00(不含,Asia/Shanghai)。09:21最终运行录屏和11:53阿里云试玩录屏均为窗口外补充,单独标注且不进入开发统计。
② 生成方式:本报告由开发会话的协调者在任务结束后基于上述素材撰写;"记忆"标签内容来自协调者会话记录(均可在 session-messages.json 中复核原文)。
③ 利益声明:本案例由 ZhikunCode 项目相关方整理,未经独立第三方复核。公开的是可复算素材与方法,不是中立第三方背书。
④ 完整性边界:SHA-256 只能证明文件相对于清单未变化;文件名时间戳不是可信时间戳,本地日志/DB/截图共享信任域,账单 CSV 也没有提供方数字签名。
⑤ 素材与法律边界:现有资产未发现官方美术、音频或模型文件,但项目使用《王者荣耀》名称、英雄名和玩法参照。本报告不提供商标、著作权或其他法律意见。
⑥ 安全扫描边界:自动扫描覆盖高置信度密钥格式并得到0命中;发布前再对新增文件进行一次人工复看。