ZHIKUNCODE王者工程实录 GitHub
ZHIKUNCODE · 工程案例档案 · https://github.com/zhikunqingtao/zhikuncode证据窗口 2026-08-09 01:30–07:01 (Asia/Shanghai) · 会话 b8f86099
开发日期 · 2026-08-09 凌晨 · 本地单机 Web 游戏 · 模型 Kimi K3(moonshot)

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把过程记录、最终代码和运行画面连接起来。

CLOUD DEMO · LIVE BUILDKING_OK
阿里云在线试玩录屏派生帧
11:53 云端部署验证 · 窗口外材料选将 / 对线 / AI推进 / 技能 / HUD
最终产物 · 阿里云 HTTPS现在就能在浏览器里运行

标准入口从5名英雄选将开始;自动演示入口直接进入由脚本驱动的5v5对局。

最终版游戏画面:河道多人及兵线交战
主证据截图 · 06:32

最终版运行画面:河道多人及兵线交战

画面内可见 5 名英雄,并显示技能冷却遮罩、小地图、双方小兵、河道水面与草丛;这张静态图不单独证明 10 名英雄同时出现在同一画面。
选将界面
主证据截图 · 05:35

开局选将界面:5 英雄卡片

亚瑟/后羿/妲己/牛魔/兰陵王,每张卡片含定位、三个技能名与简介;选中高亮、"锁定"进入对局。

素材来源声明(不构成法律意见):本产物为本地学习原型;现有代码和运行记录显示地图、模型、特效与 UI 为程序化生成,音效由 WebAudio/TTS 路径产生,未发现官方美术、音频或模型文件。项目仍直接使用《王者荣耀》名称、英雄名称及玩法参照;这段声明不等同于商标、著作权或其他法律合规结论。

PART 0 · 交付概览与时间锚点

这次交付了什么

最终产物是一个纯静态的单机 Web 5v5 MOBA 原型:Three.js 负责 3D 峡谷与锁定视角,玩家与 9 个 AI 英雄共享战斗状态,三路兵线、野区、18 座防御塔、经济成长、装备、技能、HUD 和结算在同一主循环里推进。它不需要包管理器或构建步骤,测试运行中也没有加载外部 HTTP 素材;运行仍依赖浏览器、Python 启动器、操作系统能力和本地 vendored Three.js。难点不在任何一个单独功能,而在这些系统必须以正确顺序共同工作。

开场

一句话之后,先把“能玩”定义清楚

这次开发不是从代码开始,而是从四个范围选择开始。39.6秒内确定技术、模式、地图与操控,随后才把目标写成16条可验收合同。

先看最终画面,再沿着需求、选择和启动链向后追。这里回答的是“交付从哪里来”,不是用一排数字制造声势。

运行记录冻结源码复算或推断窗口外材料
CASE-V01一句话需求到可玩原型的证据链
一句话需求到可玩原型的证据链最终结果从哪里来? 需求经过确认、实现、运行和复验形成可玩原型。开场 · 需求与结果最终结果从哪里来?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收最终河道交战 · 真实运行截图 · SHA bf7fb809cc12341一句话需求类《王者荣耀》单机Web 5v5原型24项范围确认技术 / 模式 / 地图 / 操控3DESIGN v1G01–G16验收合同410次Worker地图 → 战斗 → AI → QA517个模块39条本地相对导入边6V01–V12浏览器运行复验1过程链11 Runs / 878 LLM / 968工具observability + public log2产物链7,979行 / 5英雄 / 15技能frozen code snapshot3验收链43截图 / 5原视频 / 云端补充media hashes + browser audit

数据:E01 / E12 / E18 / 用户消息 + DESIGN.md + 冻结代码 + V01–V12 + 录屏|图中结论:需求经过确认、实现、运行和复验形成可玩原型

查看来源与复算数据
数据来源
用户消息 + DESIGN.md + 冻结代码 + V01–V12 + 录屏
复算口径
需求经过确认、实现、运行和复验形成可玩原型。
图中指标
  • 全部Run11fact.run.total
  • Worker Run10fact.run.workers
  • LLM started878fact.llm.started
  • 工具调用968fact.tools.total
CASE-V02关键数字不是孤立KPI
关键数字不是孤立KPI读者如何快速把规模、过程和证据放在一起? 核心规模可由公开证据分别复算。开场 · 需求与结果读者如何快速把规模、过程和证据放在一起?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收产物冻结代码中的可运行系统1第一方代码7,9792模块/导入边17 / 393英雄/技能5 / 15执行模型、Run与工具生命周期1Run1+102LLM终态873+53工具968反馈浏览器、截图与视频观察1WebBrowser3762截图43/423视频5+5审计日志、账单与证据账本1日志行38,6412账单请求8773证据账本E01–E42实现→执行证据→审计运行观察记录复算

数据:E01 / E12 / E18 / verification.json + 证据账本 E01–E42|图中结论:核心规模可由公开证据分别复算

查看来源与复算数据
数据来源
verification.json + 证据账本 E01–E42
复算口径
核心规模可由公开证据分别复算。
图中指标
  • 账单请求877fact.bill.requests
  • 运行完成873fact.llm.completed
  • 工具成功951fact.tools.success
  • 工具错误17fact.tools.error

范围确定后,四个选择被写进DESIGN,再由启动脚本真正拉起浏览器。

CASE-V03开发窗口与补充材料边界尺
开发窗口与补充材料边界尺哪些材料属于5小时31分证据窗口,哪些只作窗口外补充? 开发统计严格限定到01:30–07:01,窗口外材料单列。开场 · 需求与结果哪些材料属于5小时31分证据窗口,哪些只作窗口外补充?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收严格证据窗口与窗口外补充共用同一时间比例事件标记保留真实时间位置;紧邻事件用错层引线展开,避免把1分15秒画成宽间隔。5小时31分证据过滤窗口5小时29分17秒首末请求锚点跨度01:30:00开发窗开始统计下界01:31:15首个LLM请求llm_call_started07:00:32最后账单请求窗口内终验07:01:00开发窗结束统计上界09:21:55最终运行录屏窗口外补充11:53:36阿里云试玩窗口外部署1窗口内01:30≤time<07:01 · 5h31mprovenance.developmentWindow2请求锚点01:31:15→07:00:32 · 5:29:17LLM start + bill row3窗口外09:21最终运行 / 11:53云端试玩final-run + cloud-deployment

数据: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
CASE-V04七维交付不是单页动画
七维交付不是单页动画最终交付覆盖哪些相互依赖的系统? 玩法、英雄、操控、AI、UI、视觉和工程入口均有代码与证据。开场 · 需求与结果最终交付覆盖哪些相互依赖的系统?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收七个代码系统汇入同一真实运行帧 · SHA bf7fb809cc1234567世界坐标共享状态输入反馈画面输出1世界 · 地图世界180×180 · 18塔 · 10营地src/world/map.js2仿真 · 英雄战斗10英雄 · 15技能src/game/state.js3仿真 · 多类AI9英雄AI · 3类单位AIsrc/game/ai.js4交互 · 成长经济12装备 · 15级src/game/shop.js5交互 · 输入与HUD摇杆 · 技能 · 小地图src/ui/hud.js6表现 · 程序化表现几何 · Canvas · VFXsrc/world/models.js7表现 · 运行工程30Hz逻辑 · WebGL渲染src/main.js1结构证据17模块 · 39条相对导入边E31 / moduleGraph2运行画面英雄、兵线、HUD、地图同帧可见SHA bf7fb809ccebfb3工程定位多系统实时耦合的可玩单机MOBA原型E38 / claim matrix

数据:E01 / E12 / E18 / 最终代码 + G01–G16 + 运行截图|图中结论:玩法、英雄、操控、AI、UI、视觉和工程入口均有代码与证据

查看来源与复算数据
数据来源
最终代码 + G01–G16 + 运行截图
复算口径
玩法、英雄、操控、AI、UI、视觉和工程入口均有代码与证据。
图中指标
  • 第一方文件19fact.code.firstPartyFiles
  • 第一方代码行7,979fact.code.firstPartyLines
  • src模块17fact.code.modules
  • 本地导入边39fact.code.importEdges
CASE-V05四项需求选择与被排除方案
四项需求选择与被排除方案为什么最终采用单机Three.js 5v5完整三路? 四项用户选择均有原始选项、响应和落库时间。开场 · 需求与结果为什么最终采用单机Three.js 5v5完整三路?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收Q1 · 技术方案选哪种?(决定画面逼真度的上限)interaction d5f82331-c · 8.585sThree.js 3D锁视角 (推荐)用户选择Canvas 2D俯视角明确排除Unity 3D工程明确排除Q2 · 对战模式怎么设计?interaction 9a28a02f-0 · 8.916s单机5v5对战AI (推荐)用户选择单机1v1或3v3明确排除局域网联机对战明确排除Q3 · 地图和玩法规模?interaction 157dfc23-2 · 4.957s完整三路王者峡谷 (推荐)用户选择简化版地图明确排除Q4 · 操控方式选哪种?interaction 62a014fb-5 · 17.103s手机屏幕式虚拟摇杆+技能按钮 (推荐)用户选择键鼠操控明确排除

数据:E01 / E12 / E18 / interaction_requests + 会话消息|图中结论:四项用户选择均有原始选项、响应和落库时间

查看来源与复算数据
数据来源
interaction_requests + 会话消息
复算口径
四项用户选择均有原始选项、响应和落库时间。
图中指标
  • 问题4
  • 候选方案10
  • 选择4
  • 总响应39.561s
CASE-V0639.6秒需求确认原账
39.6秒需求确认原账四次决定按什么顺序发生? 四条elicitation具有独立创建、决定和响应原值。开场 · 需求与结果四次决定按什么顺序发生?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收创建→决定→响应:四条独立数据库记录上方横向距离按真实时间比例;下方卡片分别保留响应耗时、interactionId和runId前缀。Q1 技术方案选哪种?(决Q2 对战模式怎么设计?Q3 地图和玩法规模?Q4 操控方式选哪种?8.585s8.916s4.957s17.103s1Q1 · 8.585sinteraction d5f82331-cd7…run eb2e9ba2-6975-4c2Q2 · 8.916sinteraction 9a28a02f-004…run eb2e9ba2-6975-4c3Q3 · 4.957sinteraction 157dfc23-211…run eb2e9ba2-6975-4c4Q4 · 17.103sinteraction 62a014fb-537…run eb2e9ba2-6975-4c

数据: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
CASE-V07选择如何落成可验收合同
选择如何落成可验收合同需求没有停留在聊天层 每项选择可追到规范、源码和直接验收证据。开场 · 需求与结果需求没有停留在聊天层1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收用户选择DESIGN合同源码符号运行V证据证据账本Three.js 3DThree.js 3DG01/G08renderer.js/ map.jsV01/V04E31/E38单机5v5 AI单机5v5 AIG07state.js /ai.jsV06/V09E34完整三路地图完整三路地图G02/G03config.js /map.jsV02/V05E32摇杆+技能键摇杆+技能键G09/G10input.js /hud.jsV03/V08E351源码实现冻结代码/数据库直接对应source+db2运行验收指定浏览器路径内观察browser acceptance3完整覆盖合同、代码与验收证据三层对齐claim matrix

数据:E01 / E12 / E18 / 用户选择 + DESIGN.md + G01–G16 + 代码符号|图中结论:每项选择可追到规范、源码和直接验收证据

查看来源与复算数据
数据来源
用户选择 + DESIGN.md + G01–G16 + 代码符号
复算口径
每项选择可追到规范、源码和直接验收证据。
图中指标
  • 用户选择4
  • 合同条款16
  • 验收编号12
  • 证据账本43
CASE-V08端口冲突硬约束的工程落地
端口冲突硬约束的工程落地已有服务占用端口时如何仍能启动? 启动器探测端口并选择可用地址,21个占用端口场景通过。开场 · 需求与结果已有服务占用端口时如何仍能启动?1 · 需求确认2 · DESIGN合同3 · 多系统实现4 · 浏览器验收1启动器进入cd 到脚本目录2候选端口序列9201/9202/920…3lsof探测LISTEN→继续;空闲→…4全部占用?socket绑定系统随机端口5启动HTTP服务python3 -m ht…6浏览器验收KING_OK / win…真实占用端口样本 · 21个该样本来自协调者Bash活动;启动器本身探测固定候选列表,二者不可混同。50005173700080008080844084518787879189311356417890494434944549449500655374353746540295651063278start.command · 空闲端口分支if ! lsof -iTCP:$p ...; then PORT=$p; break; ficode/start.command:6–8start.command · 回退与启动s.bind(("",0)) → open URL → python3 -m http.server "$PORT"code/start.command:9–14

数据: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/kingDB 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:32AskUserQuestion 发出 4 项确认,用户全选推荐项会话消息记录(全程仅 1 次,与工具统计互证)
01:34:59安全审计日志首条(Bash_2 环境探测)security-audit 日志首行
01:39:58R01 子 Agent 启动(阶段1:地基与 3D 地图,提示词 2,697 字符)观测日志第 13 行 subagent_started
02:09:58用户消息 #2:端口冲突预警;同一秒 R01 触 30m 时限交付DB;观测日志 run_termination_summary
02:12:10 → 05:06:33R02–R06:战斗核心 → AI → 三次攻坚修复,05:06:33 起 3/3 局分出胜负观测日志逐条 subagent 事件(PART 4 账本)
05:07:33 → 06:52:45R07 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.jssrc/ui/hud.js
AI9 个 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.htmlstart.command

三条阅读路径

TABLE-03 · 原始表格 · 对应 CASE-V04
路径读者路线
90 秒只看结果卷首数字PART 7 验收与画廊PART 9 结论
5 分钟关注方法+ PART 4 执行账本PART 5 中断接续PART 6 调试攻坚
全展开审查者顺序阅读 + 点击左侧"展开完整底稿模式"(所有 details 强制展开)+ 按附录 A.2 逐条复算
01
PART 1 · 需求治理

需求怎么定下来: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.003elicitationQ1 技术方案(3 候选)"Three.js 3D锁视角 (推荐)"8.6s
17:32:13.594elicitationQ2 对战模式(3 候选)"单机5v5对战AI (推荐)"8.9s
17:32:22.514elicitationQ3 地图规模(2 候选)"完整三路王者峡谷 (推荐)"5.0s
17:32:27.475elicitationQ4 操控方式(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 63278lsof 输出(会话记录)
写入开发规范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
02
PART 2 · 产物解剖

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条本地导入边,只是这张运行图的骨架。

真正值得看的,是状态如何穿过模块边界,以及一处规则改变会同时牵动多少系统。

运行记录冻结源码复算或推断窗口外材料
SRC-V0119个第一方文件的职责Treemap
19个第一方文件的职责Treemap代码体量集中在哪里? 7,979行按game/world/engine/ui/config/main/utils可复算。源码 · 峡谷工程蓝图代码体量集中在哪里?模块 · 符号 · 运行边界二维Treemap:面积严格等于19个第一方文件的物理行数上下两行高度与行数总量成比例;窄块显示编号,完整文件名、行数、字节和SHA列在下方。src/game/state.js1,309src/game/ai.js920src/world/map.js840src/engine/vfx.js836src/world/models.js730src/ui/hud.js525src/game/skills.js485src/ui/screens.js418src/config.js362103211122912131415161701src/game/state.js1,309game · 51,881B · SHA 56b8…02src/game/ai.js920game · 35,715B · SHA 7c25…03src/world/map.js840world · 35,187B · SHA 3b0…04src/engine/vfx.js836engine · 33,230B · SHA 9e…05src/world/models.js730world · 30,158B · SHA 48e…06src/ui/hud.js525ui · 21,211B · SHA 0e8870…07src/game/skills.js485game · 20,113B · SHA 95a7…08src/ui/screens.js418ui · 17,845B · SHA 2db4df…09src/config.js362config · 16,846B · SHA 31…10index.html321entry · 20,500B · SHA d01…11src/ui/minimap.js229ui · 7,929B · SHA 735150b…12src/main.js186main · 7,232B · SHA 45008…13src/engine/audio.js169engine · 7,318B · SHA 4e5…14src/game/spawner.js158game · 6,666B · SHA ab2d1…15src/engine/input.js139engine · 5,300B · SHA 0b4…16src/engine/renderer.js134engine · 5,459B · SHA 487…17src/game/shop.js117game · 4,947B · SHA c87e8…18src/utils.js88utils · 2,532B · SHA e430…19start.command13entry · 541B · SHA ff573e…

数据: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可复算。
图中指标
  • 第一方文件19fact.code.firstPartyFiles
  • 第一方代码行7,979fact.code.firstPartyLines
  • src模块17fact.code.modules
  • 本地导入边39fact.code.importEdges

文件规模只是入口。继续往下看,设计合同如何落到依赖边界和具体运行符号。

SRC-V02逐文件指纹与完整快照
逐文件指纹与完整快照如何确认报告使用的代码就是最终产物? 证据副本与原始king运行文件逐字节一致。源码 · 峡谷工程蓝图如何确认报告使用的代码就是最终产物?模块 · 符号 · 运行边界21文件快照指纹条码左右两列使用同一字节比例尺;每行分别显示文件、字节条、物理行和SHA-256前缀。lib/three.module.js1.27M·53,044L76dea815src/game/state.js50.7K·1,309L56b8fb58src/game/ai.js34.9K·920L7c25f41bsrc/world/map.js34.4K·840L3b0ab72fsrc/engine/vfx.js32.5K·836L9ec1ebe7lib/BufferGeometryUtils.…31.2K·1,375L9be041e9src/world/models.js29.5K·730L48e30d17src/ui/hud.js20.7K·525L0e8870a9index.html20K·321Ld01c2320src/game/skills.js19.6K·485L95a7c5f3src/ui/screens.js17.4K·418L2db4df42src/config.js16.5K·362L31799805src/ui/minimap.js7.7K·229L735150b4src/engine/audio.js7.1K·169L4e5d9a39src/main.js7.1K·186L45008e21src/game/spawner.js6.5K·158Lab2d1b2csrc/engine/renderer.js5.3K·134L4873c45csrc/engine/input.js5.2K·139L0b424961src/game/shop.js4.8K·117Lc87e8d09src/utils.js2.5K·88Le4300613lib/THREE-LICENSE.txt1.2K·24L03a673601原项目聚合57 files · 1efe5f9c…/project/king只读复核2证据快照21运行文件assets/king/code3字节一致逐文件SHA-256与聚合哈希双重核对SHA256SUMS

数据:E02 / E25 / E31 / 逐文件字节/行数/SHA-256 + 原项目聚合哈希|图中结论:证据副本与原始king运行文件逐字节一致

查看来源与复算数据
数据来源
逐文件字节/行数/SHA-256 + 原项目聚合哈希
复算口径
证据副本与原始king运行文件逐字节一致。
图中指标
  • 第一方19
  • vendored2
  • 完整快照21
  • 原项目文件57
SRC-V03DESIGN规格到实现覆盖图
DESIGN规格到实现覆盖图5771字符规格怎样约束跨系统实现? 地图、单位、技能、AI、经济、UI、终局都有对应代码入口。源码 · 峡谷工程蓝图5771字符规格怎样约束跨系统实现?模块 · 符号 · 运行边界DESIGN源码V01–V12截图/视频覆盖类型G01条款存在符号定位运行观察媒体佐证全链对应G02条款存在符号定位运行观察代码/日志全链对应G03条款存在符号定位运行观察代码/日志全链对应G04条款存在符号定位指定路径媒体佐证路径验收G05条款存在符号定位指定路径代码/日志路径验收G06条款存在符号定位运行观察代码/日志全链对应G07条款存在符号定位运行观察媒体佐证全链对应G08条款存在符号定位运行观察代码/日志全链对应G09条款存在符号定位运行观察代码/日志全链对应G10条款存在符号定位指定路径媒体佐证路径验收G11条款存在符号定位指定路径代码/日志路径验收G12条款存在符号定位指定路径代码/日志路径验收G13条款存在符号定位指定路径媒体佐证路径验收G14条款存在符号定位运行观察代码/日志全链对应G15条款存在符号定位指定路径代码/日志路径验收G16条款存在符号定位运行观察媒体佐证全链对应1全链对应代码+运行路径直接连接G/V/E crosswalk2路径验收英雄/技能的实际运行记录acceptance scope3下一步逐英雄×逐技能组合回归test roadmap

数据: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
SRC-V04离线运行依赖边界
离线运行依赖边界为什么浏览器打开即可运行? 无需包管理器、构建步骤或运行时外部HTTP资源。源码 · 峡谷工程蓝图为什么浏览器打开即可运行?模块 · 符号 · 运行边界1index.htmlimportmap + U…2ES Modules17个src模块3本地vendoredthree r160 + …4浏览器能力WebGL/WebAudi…5启动器Python静态HTTP6运行边界外部HTTP资源=0import map"three": "./lib/three.module.js"code/index.htmlmain入口import * as THREE from 'three';code/src/main.js本地启动python3 -m http.server "$PORT"code/start.command1不需要npm / bundler / build stepsnapshot inspection2仍依赖浏览器 / Python / 本地Three.jsruntime boundary3不会声称“零依赖”或“无系统要求”claim boundary

数据: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.html321入口:importmap、全局错误收集(window.__errors)、boot 状态写入 document.title、HUD 根节点与全部 UI 样式
src/main.js186启动装配、固定步长主循环(30Hz 逻辑 + rAF 渲染)、?demo/speed/hero 测试参数
src/config.js362全部数值表:地图坐标/兵线路径点/塔位/基地门坐标、英雄属性、技能数值、小兵/野怪/装备/AI 参数
src/utils.js88数学工具、对象池、事件总线
src/engine/renderer.js134WebGL 渲染器、ACES 色调映射、跟随式阴影相机、锁定 55° 俯视角跟随相机 rig
src/engine/input.js139虚拟摇杆(Pointer Events 多点触控)、WASD/QWER/空格/B/H/G 键盘映射
src/engine/audio.js169WebAudio 程序化合成音效(攻击/技能/击杀/塔毁/回城/胜负)、speechSynthesis 中文播报
src/engine/vfx.js836粒子系统、弹道拖尾、地面指示圈、受击闪红壳层、死亡消散、BUFF 光环、升级光柱
src/world/map.js840峡谷地形 Canvas 纹理、河道、三路、基地围墙与门、防御塔/水晶/泉水模型、草丛、龙坑、装饰
src/world/models.js730程序化角色工厂:5 英雄专属模型(武器/配色/体型)、3 种小兵、野怪,走路/攻击/施法动作
src/game/state.js1,309核心:单位系统、伤害结算、死亡/重生、塔/水晶无敌规则、泉水、回城、闪现/恢复、玩家操作入口
src/game/skills.js4855 套英雄技能、弹道(直线/指向/追踪)、Buff/Debuff(眩晕/沉默/击飞/隐身/护盾/灼烧)
src/game/ai.js920小兵仇恨、野怪 leash、英雄 AI 状态机(分路/对线/打野/团战/撤退/回防/GROUP_PUSH/ASSAULT)、基地门路由
src/game/spawner.js158三路兵波次(30s/波、炮车每 3 波)、超级兵、野怪与暴君主宰刷新、经验金币分配
src/game/shop.js11712 件装备数据、6 格装备栏、推荐出装自动购买
src/ui/hud.js525技能按钮(CD 遮罩/拖动瞄准)、普攻/召唤师技能/回城键、血条蓝条 DOM 覆盖层、伤害飘字
src/ui/minimap.js229Canvas 小地图:地形底图、双方单位点、塔图标、相机框、点击视察
src/ui/screens.js418选将界面、中央横幅播报、击杀条、结算界面与"再来一局"
start.command13双击启动器:自动挑选空闲端口(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.html20,500d01c23203c26…
lib/BufferGeometryUtils.js31,9069be041e96308…
lib/three.module.js1,272,97276dea8151bc9…
src/config.js16,84631799805e7be…
src/engine/audio.js7,3184e5d9a39b829…
src/engine/input.js5,3000b4249617161…
src/engine/renderer.js5,4594873c45ccad1…
src/engine/vfx.js33,2309ec1ebe7060f…
src/game/ai.js35,7157c25f41b3a7a…
src/game/shop.js4,947c87e8d090554…
src/game/skills.js20,11395a7c5f3087c…
src/game/spawner.js6,666ab2d1b2cada8…
src/game/state.js51,88156b8fb582f52…
src/main.js7,23245008e2175ae…
src/ui/hud.js21,2110e8870a93f7f…
src/ui/minimap.js7,929735150b4e439…
src/ui/screens.js17,8452db4df42faaa…
src/utils.js2,532e4300613d4be…
src/world/map.js35,1873b0ab72fcc53…
src/world/models.js30,15848e30d1747c2…
start.command541ff573ec33659…

完整 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倍速)
2B
PART 2B · 最终产物系统图谱

为什么这不是一个“带动画的普通网页”

最终产物同时维持地图、固定步长仿真、10 名英雄、四类 AI、兵线与建筑、技能状态、经济装备、HUD、小地图、音效和特效。下面 26 张图只使用冻结代码、运行截图与验收记录,逐层解释这些系统如何在同一局游戏里互相影响。

阅读重点:复杂来自实时状态和跨系统反馈,而不是单纯来自7,979行代码。图中的实线表示直接调用,青色线表示共享状态,金色虚线表示事件反馈;运行质量、终局路径和浏览器表现由后续验收章节单独给出。
26 张专题级 SVG结构、世界、时钟、AI、战斗、成长与工程路线1,239 个图内直接标签尽量把值、符号和条件放在关系上273 个可聚焦检查节点点击或键盘查看冻结代码职责7 组截图—代码联证6组直接覆盖标注,选将/结算使用首尾状态图

A. 系统规模与代码结构 最终代码

KING-V01最终产物全景:一帧画面背后的十二个系统代码+运行截图
最终版河道多人及兵线交战,画面内可见五名英雄 最终产物全景:一帧画面中的实时系统九个源码标注把截图中的小地图、英雄、兵线、血条、技能、经济、特效与固定步长状态联系起来。 1战术压缩视图ui/minimap.js:update200px Canvas · 0.25s节流2五名可见英雄models.js:createHeroModel程序化轮廓+阵营圈3三路兵线交战ai.js:updateMinion索敌·脱离·推进43D世界血条hud.js:updateWorldBarsworld→screen DOM投影5共享战场状态state.js:GameState单位·战斗·经济·终局6技能与普攻输入hud→main→queueAction指针矢量在30Hz消费7粒子与弹道反馈vfx.js:update / burst对象池每帧复用8等级金币与装备state.js + shop.js + hud.js收益反向改写面板9双时钟调度main.js:loop30Hz逻辑 + rAF渲染● 绿点=画面直接可见 ● 金点=源码规则对应,不由单帧独立证明
地图 / map.js河道、三路、野区、基地和碰撞
输入 / input.jsPointer Events、虚拟摇杆与键盘
状态 / state.js单位、伤害、死亡、重生和终局
AI / ai.js英雄、小兵、塔与野怪行为
技能 / skills.js15个主动技能、弹道和Buff
生成 / spawner.js兵线、野怪、经济和重生
商店 / shop.js12件装备和推荐出装
表现 / models+vfx程序化模型、动作与特效
界面 / ui/*HUD、小地图、选将与结算
装配 / main.js同一循环中协调全部系统
选择图中热点查看对应代码职责;默认展示的是截图能直接观察到的系统。
PRE-05 · 原始代码/日志 · 对应 KING-V04
state = new GameState({ scene: engine.scene, mapData, vfx }); 源码

画面与代码对应:最终画面同时消费地图、单位状态、AI结果、HUD和表现层输出。

KING-V02十二个运行子系统的数据与事件连接源码结构
直接调用共享状态事件反馈
十二个运行子系统的数据、命令与反馈图区分顶层装配、共享状态、固定逻辑、逐帧表现和界面回调,并直接标出冻结源码符号。 RUNTIME COUPLING12个子系统不是并排页面——它们共享同一场战斗实线=调用 青线=状态数据 虚线=事件/反馈;节点可聚焦查看冻结源码职责 BOOT + LOOPmain.js 装配根boot() 创建顶层对象loop() 分流逻辑/渲染src/main.js:26–151 SHARED STATEGameState 事实中心1,309 Lunits / towers / crystals / timedamage / death / economy / winnergame/state.js:GameState Input键盘·指针·摇杆engine/input.js HUD血条·CD·技能矢量ui/hud.js Minimapworld→200px Canvasui/minimap.js Screens选将·商店·结算ui/screens.js HeroAI9名AI·9种modegame/ai.js:HeroAI SkillSystem15技能·弹道·Buffgame/skills.js Spawner / Shop兵线营地·金币装备spawner.js / shop.js Rendererscene·camera·WebGLengine/renderer.js Map180×180·碰撞·环境world/map.js Models英雄·小兵·野怪world/models.js VFX / Audio对象池·WebAudio·TTSvfx.js / audio.js move vector / inputqueueActionstate snapshothero/result/shopai.update(dt)skills.update(dt)spawn/economyrender framecolliders / environmentsyncModelevents → feedback COUPLING CONTRACTmain负责生命周期;GameState保有玩法真值;UI和表现层从状态读取并通过回调写入命令。new GameState(...) · state.update(LOOP.STEP, move) · minimap.update(state, dt) FROZEN SOURCEsrc/main.js · src/game/state.js · src/game/ai.js · src/game/skills.js · src/ui/hud.js
选择节点查看它在同一运行图中的职责。

画面与代码对应:玩法不是若干孤立演示,而是通过调用、共享状态和事件形成闭环。

KING-V0317个模块、39条本地相对导入边静态解析
17个模块、39条本地相对导入边的完整拓扑按engine、game、world和ui分组展示17个模块,并把main.js的10条顶层依赖与state.js的7条玩法汇合边单独标出。 STATIC MODULE GRAPH17模块 / 39条相对导入边38条连接第一方src模块;1条指向vendored BufferGeometryUtils;裸导入 three 不计入 COMPOSITION ROOTmain.js10 edgesboot() / startGame() / loop() ENGINE · 4renderer.jssrc/engine/renderer.jsinput.jssrc/engine/input.jsaudio.jssrc/engine/audio.jsvfx.jssrc/engine/vfx.js GAME · 57 EDGESstate.jsskills·spawner·ai·shopGameStateai.jssrc/game/ai.jsskills.jssrc/game/skills.jsspawner.jssrc/game/spawner.jsshop.jssrc/game/shop.js WORLD · 2map.jsCanvas·几何·碰撞buildMap()models.js英雄·单位·动画createHeroModel() UI · 3 + ROOT · 3hud.jssrc/ui/hud.jsminimap.jssrc/ui/minimap.jsscreens.jssrc/ui/screens.jsconfig.jssrc/config.jsutils.jssrc/utils.js 玩法核心再汇合 config / utils / models / skills / spawner / ai / shop EDGE ACCOUNT39relative imports38first-party1vendored edgescripts/verify-king-case.mjs FROZEN SOURCEsrc/**/*.js 静态解析 · import/export ... from · side-effect import
选择 main 或 game 分组查看汇合点口径。

画面与代码对应:17个模块形成可静态复算的跨领域运行结构。

KING-V047,979行第一方代码分布:复杂度集中在哪里逐文件 wc -l
7,979行第一方代码的领域、模块与职责分布面积表示领域规模,条形表示17个JavaScript模块的行数,并把入口index.html与start.command单独列示。 SOURCE COMPOSITION7,979行不是一个大文件,而是分散在玩法、世界、引擎与界面的运行图19个第一方文件口径:index.html + 17个src/*.js + start.command GAME · 37.5%2,989 linesstate 1,309 · ai 920 · skills 485spawner 158 · shop 117state.js1,309ai.js920 WORLD · 19.7%1,570 linesmap.js840models.js730 ENGINE · 16.0%1,278 linesvfx 836 · renderer 134input 139 · audio 169vfx.js836others442 UI · 14.7%1,172 lineshud.js525screens.js418minimap.js229 ROOT LOGIC · 8.0%636 linesconfig 362 · main 186 · utils 88config.js362main.js186 ENTRY + LAUNCHER334 linesindex.html 321 · start.command 13python3 -m http.servervendored Three.js不纳入第一方行数 FROZEN SOURCEwc -l 固定口径 · 17个src/*.js · index.html · start.command
选择领域查看逐模块构成。

画面与代码对应:核心玩法、世界和引擎合计占主要代码体量,产物不是单页UI拼装。

B. 战场与世界生成 配置+画面

KING-V05180×180峡谷坐标蓝图config.js静态复算
180×180峡谷的可执行坐标蓝图按config.js中的真实坐标绘制三路、对角河道、18座塔、10个营地、14片草丛、2座水晶、2个泉水和6个基地门。 WORLD COORDINATE BLUEPRINT一张地图同时约束移动、索敌、视野、攻防顺序和AI导航世界坐标 x,z ∈ [-90,90];绘图为等比例策略蓝图,不是游戏截图 C1C2C3C4C5C6C7C8暴君主宰 BLUE BASERED BASE 3 LANES3mid 3节点top/bot 各6节点MAP.LANES STRUCTURES2818塔·2水晶·2泉水6个基地门TOWERS_BLUE + mirror VISION1414草丛攻击破隐1sMAP.BRUSHES SCENERY120棵树·46块岩石2048²地表纹理TREE_COUNT / ROCK_COUNT JUNGLE108普通营地2中立目标Spawner.camps COLLISION活动边界±86塔/水晶/围墙MAP.PLAY_BOUND BASE GATES63路交点动态求解基地内外绕门_baseGates() RIVERz = -x宽14·长262RIVER_WIDTH/LEN FROZEN SOURCEsrc/config.js:MAP · src/config.js:BASE_GATES · src/world/map.js:buildMap
选择地图统计查看源码口径。

画面与代码对应:地图同时承担路线、建筑、资源、视野和基地攻防拓扑。

KING-V06程序化地图:从坐标表到WebGL画面代码+R01截图
R01河道中心全景程序化地图:由配置、Canvas纹理、Three.js几何和碰撞体合成的WebGL场景八个标注区分截图可见地物与源码生成责任。 12048² Canvas地表map.js:createGroundTexture草地/土路/基地石台2对角河道MAP.RIVER_WIDTH = 14水面网格+波纹纹理3龙坑几何map.js:createPit石环/符文/碎石4塔与静态碰撞createTower + colliders几何与玩法半径共存5120树 + 46岩石TREE_COUNT / ROCK_COUNT确定性伪随机散布614片草丛map.js:createBrush可见模型+视野区域7实时环境更新mapData.update(dt,elapsed)河水/环境逐帧动画8渲染器合成renderer.js:render()scene + camera + WebGL● 绿点=画面直接可见 ● 金点=源码规则对应,不由单帧独立证明
1 · config.js世界尺寸、路径、塔位和装饰数量
2 · Canvas 2D草地噪点、三路、河床、基地和营地
3 · Three.js地面、水面、建筑、装饰和碰撞体
4 · renderer.js光照、雾、阴影、俯视相机与WebGL输出
选择画面热点查看生成阶段。
PRE-06 · 原始代码/日志 · 对应 KING-V06
const tex = new THREE.CanvasTexture(cv); 源码

画面与代码对应:地图画面能与坐标配置、Canvas纹理及Three.js构建代码逐项对应。

KING-V07基地攻防:塔序、水晶解防与三门路由代码+基地截图
R01敌方基地水晶与围墙基地攻防:画面背后的塔序、水晶守卫、围墙门与AI防卡死七个标注将敌方基地截图与config/state/ai/map中的攻防规则联系起来。 1水晶实体state.js:crystals[team]HP 10000 · ARMOR/MRES 1002解除无敌条件isCrystalInvuln()一路清空 或 存活塔≤33梯度塔守卫TOWER_GUARD_PER = .08受伤下限30% · 脱战回血426段基地围墙WALL_SEGMENTS = 26三路缺口半角15°5三门导航BASE_GATES[team]基地内外切换先经门点6硬卡死换门HeroAI._moveTo()2s检测·临时禁用当前门7泉水高危区FOUNTAIN.ENEMY_DPS2000真实伤害/s● 绿点=画面直接可见 ● 金点=源码规则对应,不由单帧独立证明
T1 → T2 → T3前塔存活时后塔无敌
水晶解防任一路清空,或全队只剩≤3塔
梯度守卫每座存活塔使水晶受伤降低8%,最低承受30%
三门导航基地内外切换先过门;2秒硬卡死换门
选择基地热点查看攻防规则。
PRE-07 · 原始代码/日志 · 对应 KING-V07
isCrystalInvuln(crystal) { 源码

画面与代码对应:“推水晶”依赖建筑顺序、守卫减伤、AI目标和导航同时成立。

KING-V08野区、龙坑与草丛视野生态代码+R01截图
河道龙坑与草丛野区、龙坑与草丛视野的共同生态标注暴君、主宰、普通营地、leash回营、草丛显隐和AI对中立资源的安全判断。 1中立目标坑Spawner.objectivestyrant + overlord2暴君收益TYRANT_TEAM_GOLD/EXP全队+150金/+100经验3主宰收益OVERLORD_WAVE_MULT下波三路兵×1.84草丛显隐state.js:targetable()同草丛/破隐1s5河道战略通道MAP.RIVER_WIDTH连接双方野区与两龙坑68个普通营地Spawner.camps双方红/蓝/2小野7野怪脱离返场updateMonster()leash 9 · 回营满血8AI安全开龙HeroAI._findObjective()血量+附近敌方英雄检查● 绿点=画面直接可见 ● 金点=源码规则对应,不由单帧独立证明
8个普通营地双方各红、蓝BUFF和2个小野营
2个中立目标暴君团队金币经验;主宰强化下一波兵×1.8
60秒普通刷新野怪越过9单位leash后回营满血
14片草丛影响AI、普攻与技能目标可见性
选择龙坑、草丛或河道查看玩法作用。
PRE-08 · 原始代码/日志 · 对应 KING-V08
this.objectives = this.camps.filter(c => c.id === 'tyrant' || c.id === 'overlord'); 源码

画面与代码对应:野区并非装饰,它通过刷新、Buff、团队奖励、视野和AI决策改变战局。

C. 实时仿真主循环 运行代码

KING-V09双时钟主循环:30Hz逻辑与逐帧渲染main.js
双时钟主循环:30Hz确定逻辑与逐帧渲染并行展示requestAnimationFrame、dt封顶、accumulator、最大5次补步、GameState固定更新与表现层逐帧更新的完整分工。 DETERMINISTIC SIMULATION LOOP帧率可变,但战斗规则用固定步长推进main.js:loop(ts) 使逻辑与渲染同居一帧,又不把数值结果绑死在显示器帧率上 WALL CLOCK / requestAnimationFramets → dtmin(0.25, Δt)main.js:124DEMO SPEEDacc += dt × speeddemo ? 4 : 1ACCUMULATOR累积未消费逻辑时间accSUBSTEPSwhile acc ≥ 1/30sub < 5DROP BACKLOG防止死亡螺旋MAX_SUB=5 FIXED LOGIC CLOCK · 30HzSTEP = 0.0333s Input snapshotmoveVec + attackHeldinput.getMoveVector()GameState.update10阶段玩法更新state.update(STEP, move)Simulation factstime·units·damage·winnershared state while (acc >= LOOP.STEP && sub < LOOP.MAX_SUB) {state.update(LOOP.STEP, input.getMoveVector());acc -= LOOP.STEP; sub++;} VARIABLE RENDER CLOCK · EVERY FRAME state.animate(dt)model.userData.updateminimap.update(state,dt)0.25s内部节流vfx.update(dt)对象池动画mapData.update(dt,elapsed)环境动画engine.update(dt)相机跟随engine.render()WebGL合成hud.update()DOM状态投影 WHY THIS IS HARDER THAN ANIMATION渲染帧可丢,但技能CD、兵线、AI、伤害和金币必须按稳定时钟推进;卡顿时最多补5步,避免无限追帧。requestAnimationFrame(loop) · LOOP.STEP=1/30 · LOOP.MAX_SUB=5 · dt≤0.25 FROZEN SOURCEsrc/config.js:LOOP · src/main.js:loop · src/game/state.js:update
选择时钟节点查看稳定性设计。

画面与代码对应:玩法时间与显示刷新被明确分离,并提供补步上限和加速验收入口。

KING-V10GameState.update()的十阶段世界推进顺序state.js:1121
GameState.update()的十阶段严格顺序以固定逻辑tick为单位,按生成、技能、视野、玩家、英雄AI、单位AI、泉水、分离、碰撞同步和清理的顺序更新。 GAMESTATE PIPELINE每个33.3ms逻辑片段都要把十类子系统按固定顺序推进顺序本身是行为契约:生成的单位可在同tick被AI读取,死亡后在末尾统一清理 01 · Spawner兵线·营地·被动金spawner.update(dt)02 · SkillSystem弹道·延迟·Buffskills.update(dt)03 · Brush visibility草丛进出·破隐updateBrushState()04 · Player actions移动·普攻·动作队列_actionQueue05 · Hero AI ×9撤退·回防·团战·推进ai.update(dt)AI writes actions06 · Unit AI小兵·塔·野怪·分身updateMinion/Tower/Monster07 · Fountain友方回复·敌方真伤FOUNTAIN08 · Separation单位间软推挤_separate()09 · Collision sync静态碰撞·边界·模型colliders + syncModel10 · Cleanup清理_purge单位units.filter ORDER-SENSITIVE CONSEQUENCES 技能延迟效果先于AI决策结算玩家动作队列在固定tick统一消费英雄AI先于小兵/塔/野怪泉水伤害可引发死亡/奖励链碰撞同步在位移之后修正延迟清理避免迭代中移除 FROZEN SOURCEsrc/game/state.js:1121–1303
选择阶段查看这一顺序影响的状态。

画面与代码对应:每个逻辑步不是单一动画更新,而是十类相互依赖的世界演算。

KING-V11单位生命周期:从生成到奖励、重生或清理state+spawner+ai
英雄、小兵、野怪与建筑的单位生命周期用四条并行生命线展示生成、移动、索敌、攻击、受伤、死亡、奖励、重生或清理的差异。 UNIT LIFECYCLE MATRIX同一Unit抽象,四种不同的终止语义英雄需要重生;小兵和召唤物需要清理;野怪按营地刷新;建筑死亡会改写攻防规则 HEROcreateHerospawnHeroAI / playeractperformAttack / skillscombatonUnitDieddeath8+2×level 重生nextMINIONspawnWavespawnupdateMinionactpush / self-defendcombat_purge=truedeath下一波30snextMONSTERspawnCampspawnupdateMonsteractaggro / leash / returncombatcamp.respawnAtdeath普通60s·龙单独nextSTRUCTUREconstructorspawnupdateTower / staticacttier/invuln/aggrocombatdisable colliderdeath塔不重生·水晶终局next Unit.die()只是入口;GameState.onUnitDied()根据kind分发金币、经验、Buff、塔奖励、重生计时或winner。 FROZEN SOURCEsrc/game/state.js:Unit · src/game/state.js:onUnitDied · src/game/spawner.js · src/game/ai.js
选择单位类型查看死亡后的不同分支。

画面与代码对应:不同单位共享结算基础,但生成、奖励、重生和终局语义不同。

D. 5v5与多类AI 最终代码

KING-V125v5阵容装配:1名玩家+9名AI英雄main.js+验收断言
1名玩家 + 9名AI的5v5阵容装配展示双方上路、中路、下路双人和打野五个角色,以及玩家英雄选择后的镜像英雄池限制。 ROSTER ASSEMBLY一场比赛同时维护10名英雄,其中9名由独立HeroAI控制setupAI()创建蓝方4名队友AI和红方5名敌方AI;玩家占用蓝方一个角色位 BLUE TEAM · PLAYER + 4 AI5TOP · 牛魔role=top controller=AIsetupAI('blue', ...)MID · 妲己role=mid controller=AIsetupAI('blue', ...)BOT CARRY · 后羿role=bot controller=AIsetupAI('blue', ...)BOT SUPPORT · 亚瑟role=bot2 controller=AIsetupAI('blue', ...)JUNGLE · 兰陵王role=jungle controller=PLAYER / AIsetupAI('blue', ...) RED TEAM · 5 AI5TOP · 牛魔role=top controller=HeroAIsetupAI('red', ...)MID · 妲己role=mid controller=HeroAIsetupAI('red', ...)BOT CARRY · 后羿role=bot controller=HeroAIsetupAI('red', ...)BOT SUPPORT · 亚瑟role=bot2 controller=HeroAIsetupAI('red', ...)JUNGLE · 兰陵王role=jungle controller=HeroAIsetupAI('red', ...) MIRRORED HERO POOL LIMIT双方使用同一组5人英雄池;这能支撑职业分工与技能差异,但不是10个不同英雄,也不是阵容系统。HEROES = { arthur, houyi, daji, niumo, lanlingwang } FROZEN SOURCEsrc/config.js:HEROES · src/game/state.js:setupAI · src/main.js:startGame
选择玩家位查看与AI英雄的控制差异。

画面与代码对应:运行时确实装配蓝4+红5共9个AI英雄,验收也读到双方各5名英雄。

KING-V13英雄AI优先级:每个tick都在做取舍ai.js · HeroAI.update
英雄AI的九层优先级状态机按HeroAI.update中的真实判定顺序展示锁定、撤退、恢复、回防、强攻、团战、集团推进、中立目标和默认分路/打野。 HERO AI PRIORITY MACHINE不是“走向最近敌人”,而是一条会被高优先级短路截断的决策链每个AI英雄每个固定tick评估生存、防守、终局、团战、目标和分路条件 01 · LOCK / RECALL回城引导或控制状态立即短路返回u.channel / isLocked()02 · RETREATHP &lt; 30%;安全时回城,泉水回到85%RETREAT_HP / RETURN_HP03 · HEAL低血且近3s参战,恢复术可用castHeal()04 · DEFEND己方塔近4s被攻;水晶被攻全员回防_findDefense()priority fallthrough05 · ASSAULT敌水晶解防且已进基地,强攻水晶isCrystalInvuln()06 · TEAMFIGHT15半径内≥3英雄近4s交战_findTeamfight()07 · GROUP_PUSH水晶解防且己方存活≥2,集团推进_shouldGroupPush()08 · OBJECTIVE血量门槛+龙坑附近无敌方英雄_findObjective()09 · LANE / JUNGLE默认分路跟兵或最近邻营地路线_lane() / _jungle() TARGETING SUBROUTINE_selectTarget(radius): score = distance / (hero ? 1.5 : 1) → 排除建筑/非反击野怪/敌方泉水 → 越塔时检查己方兵线掩护 FROZEN SOURCEsrc/game/ai.js:HeroAI.update · src/config.js:AI_CFG
选择决策节点查看触发阈值和模式。

画面与代码对应:9名AI英雄不只是“向前走”,而是在生存、回防、团战、资源与终局之间按优先级分流。

KING-V14小兵AI:一条兵线也包含状态、仇恨和终局规则ai.js+spawner.js
小兵AI:三路路径、索敌脱离、推塔和防卡死展示一只小兵在生成、路径偏移、索敌、攻击、脱离、路点到达、塔后超级兵和主宰强化之间的决策。 MINION DECISION PIPELINE兵线是一个持续生成、持续索敌、持续推进的自治系统每30s双方三路同时出兵;每只小兵都保持lane、pathIndex、target、laneOffset和卡死观测状态 WAVE CONSTRUCTION3刀兵WAVE.MELEE=32法师兵WAVE.MAGE=2每3波+1炮车CANNON_EVERY=3一路三塔全破+1 super主宰奖励next wave ×1.8 updateMinion(unit,state,dt) 01 有效目标?alive·targetable·leash≤14MINION_LEASH_R02 重新索敌aggro radius = 8nearestEnemy()03 射程内攻击1/aspeed · face targetperformAttack() 04 跟随路点laneOffset ≤ 2.5path[pathIndex]05 到达判定distance ≤ 7MINION_WP_ARRIVE_R06 终点策略3.5内自卫,否则水晶MINION_SELF_DEFEND_R no / invalidtargetout of range → move stuck window: 3s · moved < 1 → pathIndex++ / nudge路点到达半径从塔碰撞尺寸推导,并增加轨道偏移与卡死检测,避免兵线在拐角塔堆积。 STRUCTURE CONSEQUENCES炮车 / 超级兵对塔×2towerMult = 2config.js:MINIONS一路破塔 → 超级兵laneCleared(team,lane)spawner.js12:00后时间成长HP/AD 每分钟+8%MINION_GROWTH FROZEN SOURCEsrc/game/ai.js:updateMinion · src/game/spawner.js:spawnWave · src/config.js:MINIONS/WAVE
选择兵线阶段查看触发条件。

画面与代码对应:兵线同时连接时间、AI、经济、建筑无敌、终局和防卡死机制。

KING-V15四类AI与三种环境规则共同决定战局规则拼图
四类AI与全局规则的多智能体拼图对比英雄、小兵、防御塔和野怪四套不同行为规则,并展示草丛、泉水、建筑无敌和共享伤害结算如何跨类型影响决策。 MULTI-AGENT RULE TOPOLOGY四套专用AI在同一GameState中竞争目标、空间和伤害结果“AI”指可执行规则控制器,不指机器学习模型 SHARED WORLDGameState1 truthtargetable / nearestEnemy / dealDamageunits / colliders / time / eventsgame/state.js STRATEGICHeroAI × 99 modes·组团·打龙·买装越塔掩护·基地门导航HeroAI.update() LANEMinionAI × N路点·索敌·脱离·推塔炮车·超级兵·卡死修正updateMinion() DEFENSETowerAI × 18兵线优先·英雄仇恨窗口对同一英雄连击累加updateTower() JUNGLEMonsterAI3.5主动范围·9距离leash回营满血·营地刷新updateMonster() move / cast / attacklane targetaggro / projectileaggro / leash CROSS-CUTTING RULES草丛targetable泉水heal / true dmg建筑无敌tier / crystal软推挤_separate ONE SETTLEMENT POINTdealDamage()护甲/魔抗·护盾·水晶守卫·死亡source → target → onUnitDied → reward/event FROZEN SOURCEsrc/game/ai.js · src/game/state.js · src/config.js:AI_CFG
选择AI或环境规则查看它改变的目标选择。

画面与代码对应:同一局中存在四套不同AI规则,并通过共享空间查询与伤害状态互相作用。

E. 英雄、技能与战斗 最终代码

KING-V16五英雄×三主动技能:15条不同战斗路径skills.js
五英雄×三主动技能的十五条战斗路径对每个技能直接标出名称、瞄准模式、基础冷却和关键效果,展示五个职业的不同实现路径。 SKILL IMPLEMENTATION MATRIX15项技能不是15个同形按钮:它们展开为弹道、延迟区域、Buff、位移、分身和控制基础CD:S1=8s、S2=10s、Ult=40s;大招每级-3s;技能基础伤害每级+12% 亚瑟 · 战士Q · 誓约之盾self · 8s移速+30%·强化普攻·沉默SKILLS.arthur.s1E · 回旋打击around · 10s3s环绕DoT·r=4SKILLS.arthur.s2R · 圣剑裁决target · 40s跃击·已损生命12%SKILLS.arthur.ult后羿 · 射手Q · 炙热之风self · 8s4s三连普攻·每箭60%ADSKILLS.houyi.s1E · 燎原箭雨area · 10sr=6·0.4s延迟·减速SKILLS.houyi.s2R · 灼日之矢line · 40srange=60·距离眩晕SKILLS.houyi.ult妲己 · 法师Q · 灵魂冲击line · 8srange=11·直线弹道SKILLS.daji.s1E · 偶像魅力target · 10srange=10·追踪+眩晕SKILLS.daji.s2R · 女王崇拜around · 40s5团狐火自动寻敌SKILLS.daji.ult牛魔 · 坦克Q · 咆哮之斧around · 8sr=3.5·范围减速SKILLS.niumo.s1E · 横行霸道dash · 10srange=8·冲锋击退SKILLS.niumo.s2R · 山崩地裂around · 40sr=5·击飞+自护盾SKILLS.niumo.ult兰陵王 · 刺客Q · 秘技·分身self · 8s分身追击3次·60%ADSKILLS.lanlingwang.s1E · 秘技·影蚀target · 10srange=9·标记二段伤害SKILLS.lanlingwang.s2R · 秘技·暗袭target · 40srange=9·突进至目标身后SKILLS.lanlingwang.ult COMMON: mana 50/60/100 · scale = base×(1+12%×(skillLevel-1)) + ratio×AD/AP · cooldown affected by blueBuff CDR FROZEN SOURCEsrc/game/skills.js:SKILLS · src/config.js:SKILL_COMMON
选择英雄行查看三项技能的不同机制。

画面与代码对应:15项技能并非仅更换名称,而是包含不同瞄准、弹道、控制、状态和位移实现。

KING-V17六种技能瞄准模型SKILLS[*].aim
六种技能瞄准模型与空间校验展示self、around、target、area、line和dash六类瞄准几何,并标出15项技能的分布、范围、目标选择与HUD指针输入。 AIMING GEOMETRY一个技能按钮背后至少有六种空间语义HUD把点按/拖拽转成slot+direction;SkillSystem.cast再根据def.aim解析施法者、单位、地点、方向或位移 SKILLSself · 3亚Q·后Q·兰Q无空间目标;自身Buff/分身def.aim === 'self'HUD vector → SkillSystem.cast → range / targetableSKILLSaround · 4亚E·妲R·牛Q/R以施法者为圆心;r=3.5/4/5/10def.aim === 'around'HUD vector → SkillSystem.cast → range / targetableSKILLStarget · 4亚R·妲E·兰E/R可锁定敌方单位;range=8–10def.aim === 'target'HUD vector → SkillSystem.cast → range / targetableSKILLSarea · 1后E12距离地点;r=6;0.4s延迟def.aim === 'area'HUD vector → SkillSystem.cast → range / targetableSKILLSline · 2后R·妲Q方向弹道;range=60/11def.aim === 'line'HUD vector → SkillSystem.cast → range / targetableSKILLSdash · 1牛E方向位移8;路径击退def.aim === 'dash'HUD vector → SkillSystem.cast → range / targetable AUTO-AIM FALLBACK点按没有拖拽方向时,根据瞄准类型选取最近合法目标或面向方向;超范围、死亡、不可见目标在cast中拒绝。hud._endAim() → state.queueAction({skill,dir}) → skills.cast(caster,slot,targetOpt) FROZEN SOURCEsrc/game/skills.js:SKILLS/cast · src/ui/hud.js:aim handlers · src/game/state.js:targetable
选择瞄准类型查看对应技能。

画面与代码对应:技能输入与空间目标至少覆盖六类不同语义,HUD、玩家和AI都需适配。

KING-V18一次技能施放跨越八个代码环节端到端调用链
一次技能施放跨越十个代码环节从键盘或指针输入、HUD瞄准、动作队列、状态门控、SkillSystem资源检查,到弹道、延迟、Buff、伤害和多通道反馈。 END-TO-END SKILL TRANSACTION从人机交互到伤害数值,再回到画面、声音和HUD命令在固定tick消费;施放前失败是结构化分支,而不是直接播放动画 01 · INPUTpointer / Q E Rinput.js + hud.js02 · AIMslot + directionHUD._endAim()03 · QUEUE动作进固定tickstate.queueAction04 · STATE GATEalive / lock / recalltryCastSkill05 · CASTABLElevel / CD / manaSkillSystem.cast06 · TARGETaim / range / visibilitytargetable07 · EXECUTEbuff / projectile / delaydef.cast08 · SETTLEAD/AP → resistancedealDamage09 · EVENTskillCast / deathEventBus.emit10 · FEEDBACKVFX / Audio / HUDupdate/render EARLY-EXIT BRANCHES• 技能未加点 • cooldown > 0 • mana不足• stun / silence / knockup • 施法者死亡• target失效/超范围/不可见 • 对局overreturn false → HUD保留当前状态 VISIBLE CONSEQUENCESvfx弹道/预警/冲击波audio音调/噪声/播报hudCD遮罩/血条/飘字model朝向/位移/发光壳 FROZEN SOURCEsrc/ui/hud.js · src/main.js · src/game/state.js · src/game/skills.js · src/engine/vfx.js · src/engine/audio.js
选择环节查看输入如何变成可见战斗结果。

画面与代码对应:一次施法横跨输入、固定tick、技能系统、状态结算和表现层,不是单个CSS动画。

KING-V19战斗结算:数值、状态、死亡与奖励在同一点汇流state.js+skills.js
战斗结算:从技能面板值到死亡、奖励与终局展示AD/AP缩放、暴击与建筑倍率、护甲魔抗、水晶守卫、护盾、控制、死亡分发和金币经验统计的统一流水线。 COMBAT SETTLEMENT伤害不是“扣一个HP”,而是会改写控制、隐身、仇恨、经济、等级、重生和胜负的事件GameState.dealDamage()是统一结算点;onUnitDied()再根据unit.kind分发后果 DAMAGE INPUTS普攻AD·攻速·暴击performAttack技能base·level·AD/AP ratioscale()状态DoT·mark·empowerbuff update单位倍率炮车/超级兵对塔×2towerMult终结倍率已损生命12%arthur.ult dealDamage(source,target,amount,opts) 01 目标门控alive·targetable·building invulnisBuildingInvuln()02 类型与抗性AD→armor·AP→mres100/(100+resist)03 特殊修正crit·towerMult·guardopts / target.kind 04 护盾吸收shield先于HPtarget.shield05 状态副作用combatT·assist mark·reveallastCombatT / marks06 可见反馈floatText·VFX·hit eventvfx / events actual = amount × 100 / (100 + max(-80,resist))target.hp -= max(0, actual - shieldAbsorb) → hp ≤ 0 ? onUnitDied(target, source) onUnitDied(unit,killer)MINION补刀金·范围经验·_purgekind=minionMONSTER金/经验·红蓝BUFF·龙奖励kind=monsterHERO200击杀·80助攻·KDA·重生kind=heroTOWER全队+200金·关闭碰撞kind=towerCRYSTALendGame(winner)·结算kind=crystal 控制/Buff状态:stun·silence·knockup·knockback·slow·stealth·dot·mark·empower·multishot·aura_dot·foxfire·dashskills.js Buff update ⇄ state.js dealDamage / Unit.addBuff / Unit.isLocked FROZEN SOURCEsrc/game/state.js:dealDamage/onUnitDied · src/game/skills.js:scale/Buffs · src/config.js:ECON/CRYSTAL_CFG
选择结算节点查看它影响的后续状态。

画面与代码对应:伤害结果继续驱动控制、死亡、经济、等级、统计、重生与胜负。

KING-V20河道交战“画面—代码”联证最终截图+七个源码入口
最终版河道交战河道交战的画面—代码联证图十个直接标注把画面中的战术信息、世界实体、AI决策、状态投影和输入回调连到冻结源码。 1小地图视图minimap.js:update/render地形·塔·单位·相机框2比分与计时state.score / state.time固定tick累计同步3英雄模型组合models.js:createHeroModel身体·武器·阵营圈4兵线双方交战ai.js:updateMinion索敌·攻击·推进5世界血条投影hud.js:updateWorldBars3D position → screen DOM6HeroAI决策ai.js:HeroAI.update团战/回防/集团推进7伤害与控制state.js:dealDamage抗性·护盾·死亡分发8命中特效对象池vfx.js:burst/tracer弹道·环·飘字9技能动作队列hud→main→queueActionQ/E/R方向在30Hz消费10经济成长面板shop.js + hud.js等级·金币·KDA·6格装备● 绿=截图直接可见 ● 金=冻结源码推导 实线=画面实体 虚线=行为规则
1 · minimap.update战术态势压缩到200px Canvas
2 · state.time / score固定tick累计并同步界面
3 · createHeroModel阵营与英雄轮廓可辨
4 · updateMinionAI/HeroAI兵线和英雄共享战场
5 · HUD projection世界状态映射到DOM
6 · queueAction输入在逻辑tick内消费
7 · Shop/HUD经济变成面板和装备
选择编号查看画面对象的真实代码入口。
PRE-09 · 原始代码/日志 · 对应 KING-V18
hud.onSkill = (slot) => state.queueAction(slot); 源码

画面与代码对应:截图中可见对象能逐项定位到冻结代码,画面不是与源码脱节的宣传渲染。

F. 成长、经济与完整对局 代码+验收

KING-V21完整对局状态机:从选将到“再来一局”两端画面+终局代码
五英雄选将界面
失败结算与再来一局按钮
入口可见5张英雄卡、定位、技能简介和锁定按钮
中段可运行对线、野区、团战、推塔、装备和重生
终局可达水晶死亡写入winner并延迟显示结果
闭环可重启结算表、KDA、补刀、等级和“再来一局”
从选将到水晶结算再回到新对局的状态机展示选择英雄、建立GameState、分路发育、资源争夺、团战、推塔、水晶死亡、结算表和重新开始的完整控制流。 MATCH STATE MACHINE可玩闭环不是“能走动”,而是从入口到终局再回到入口上方两张冻结图像分别观测选将和结算;中段路径由代码、对局录屏与验收记录共同支撑 ENTRY选将界面5张英雄卡定位·技能摘要Screens.showSelect锁定英雄onSelect(heroId)startGame(heroId)建立世界Map·VFX·GameState1 player + 9 AIHUD·Minimap·Screensnew GameState(...) RUNNING MATCH · state.over = false 01 对线三路兵线·补刀·发育Spawner/HeroAI02 野区8营地·红蓝BUFFSpawner.camps03 资源8:00暴君·10:00主宰_findObjective04 团战回防·支援·死亡重生_findTeamfight05 推塔T1→T2→T3·超级兵isTowerInvuln06 强攻水晶解防·守卫减伤·泉水isCrystalInvuln start TERMINAL + RESTART水晶死亡kind=crystalonUnitDied写入胜方over=true·winner=teamendGame()结算表KDA·补刀·等级Screens.showResult()再来一局reload / restartrestart buttonwinner restart → 新的GameState,不复用上一局单位状态 EVIDENCE BINDING选将图像:screenshot_qa_1786228500285.png · 结算图像:screenshot_qa_1786229287687.pngstate.js:endGame → main.js:state.events.on('gameOver') → screens.js:showResult FROZEN SOURCEsrc/ui/screens.js · src/main.js:startGame · src/game/state.js:endGame
流程图与两端运行截图共同限定“可玩闭环”的范围。
PRE-10 · 原始代码/日志 · 对应 KING-V21
showResult() { 源码

画面与代码对应:选将与结算均有冻结画面,最终验收还记录水晶胜负和重开成功。

KING-V22经济成长闭环:战斗结果会改变下一次战斗config+state+shop
经济与成长:一次战斗如何改变下一次战斗展示补兵、英雄击杀、助攻、破塔、暴君主宰和被动收入,如何转换为金币经验、等级技能和12件装备,再反馈到推进。 ECONOMY FEEDBACK LOOP战斗结果被持久化为英雄成长,成长又改变下一次结算这个正反馈回路是MOBA“发育→滚雪球→终局”的基础,也是最需平衡的部分 INCOME EVENTS小兵补刀36 / 42 / 90 / 120金MINIONS英雄击杀killer +200金/+200经验HERO_KILL助攻助攻者+80金ASSIST破塔全队每人+200金TOWER_TEAM暴君全队+150金/+100经验TYRANT主宰下波兵×1.8OVERLORD被动金2:00后 2金/sPASSIVE PERSISTENT HERO STATEGold购买时扣除·上限未设giveGold / Shop.buyExperience → Level 1–15半径14共享·14段EXP_TABLEgiveExp / levelUpSkill levels1级自带S1·4/8/12大招SKILL_ORDERStatsHP/MP/AD/AP/armor/mresHEROES.growth 12 ITEMS / 6 SLOTS基础攻击铁剑300·攻速匕400ITEMS基础法术/防御法典500·布甲/斗篷300ITEMS移速神速之靴300ITEMS高级物理破军2200·无尽2100ITEMS高级法术博学者之怒2300ITEMS高级防御红莲/魔女1800ITEMS续航霸者2000·HP+1500ITEMS rewardbuy战斗力提升 → 更快清线/推塔/抢目标 → 更多收益 FROZEN SOURCEsrc/config.js:ECON/EXP_TABLE/HEROES · src/game/state.js:giveGold/giveExp/levelUp · src/game/shop.js:ITEMS/Shop
选择收益、等级或装备查看反馈方向。

画面与代码对应:金币经验不是装饰数字,而会修改技能、英雄面板、装备和推进能力。

KING-V23一局比赛里并行运行的时间系统配置时间轴
一局比赛中并行推进的长短时间系统展示首波兵线、周期出兵、被动金、暴君、主宰、小兵成长,以及技能CD、回城、Buff、召唤师技能、重生和多杀窗口。 MATCH TIME SYSTEM一个time值同时驱动出兵、收入、资源、成长、重生和冷却时间系统并行,并不是简单按顺序播放的演示时间轴 LONG MATCH CLOCK · seconds00:00建立英雄/建筑state.time=000:10首波兵线WAVE.FIRST00:30+每30s出兵WAVE.INTERVAL02:00被动金2/sPASSIVE_GOLD08:00暴君首刷TYRANT_FIRST10:00主宰首刷OVERLORD_FIRST12:00+小兵每分钟+8%MINION_GROWTH SHORT COMBAT TIMERSS1 / S2 / ULT8 / 10 / 40s,大招每级-3s回城8s引导;受伤打断恢复 / 闪现90s / 120s红蓝BUFF60s;红灼烧2ticks多杀 / 团灭8s窗口 / 存活数检查 RESPAWN / RECOVERY TIMERS英雄重生respawnAt = time + 8 + 2×level1级10s → 15级38sRESPAWN.BASE/PER_LEVEL野怪刷新普通60s暴君180s·主宰240sJUNGLE.RESPAWN脱战回复英雄5s后0.6%/s水晶5s后1%/slastCombatT FROZEN SOURCEsrc/config.js:WAVE/ECON/JUNGLE/RESPAWN · src/game/spawner.js:update · src/game/state.js:update
选择里程碑查看它启动的系统。

画面与代码对应:一局比赛由多个长短时间轴并行推进,测试终局必须等待或使用受控倍速。

G. 程序化表现、界面与工程路线 最终代码

KING-V24没有外部运行时素材,画面与声音仍要被“造出来”map+models+vfx+audio
程序化表现管线:地表、模型、特效与声音如何被实时造出来展示Canvas 2D地表纹理、Three.js程序化模型、对象池VFX、WebAudio和speechSynthesis如何与WebGL、DOM和Canvas UI合成。 PROCEDURAL PRESENTATION PIPELINE无外部HTTP素材的程序化表现系统地图、角色、特效和声音都由本地代码与vendored Three.js在浏览器合成 INPUT ASSETS配置数据 + 简化几何 + 程序化材质config.js · map.js · models.js · vfx.js · audio.js 2048² TEXTURECanvas MAP2048²草地/土路/河床/石台河水波纹/龙坑符文CanvasTexture → planemap.js:createGroundTexture THREE.JS GEOMETRYMODEL FACTORY5英雄·4小兵·5野怪身体/头饰/武器/阵营圈userData.update 驱动动作models.js:create*Model OBJECT REUSEVFX POOLS1,106particles 1024 · tracers 48shock 12 · pillar 10 · shell 12burst/ring/beam/arrow/glowvfx.js:VFX SYNTHESISAUDIOoscillator tone · noise · arpWebAudio攻击/技能音speechSynthesis中文播报audio.js:AudioEngine BROWSER COMPOSITORWebGL Scene+  DOM HUD / world bars / banners+  Canvas minimap+  WebAudio / TTSengine.render() · hud.update() · minimap.update() · vfx.update() · audio.play()/speak() FROZEN SOURCEsrc/world/map.js · src/world/models.js · src/engine/vfx.js · src/engine/audio.js · src/ui/hud.js
选择表现通道查看它如何生成资源。

画面与代码对应:现有代码未依赖外部模型、贴图、音频或字体URL,画面和声音主要由代码生成。

KING-V25HUD“画面—代码”联证:十一类信息同时同步最终HUD截图
协调者验收时的完整HUDHUD画面—代码联证:十一类信息与输入同步十一个直接标注将小地图、比分、时间、世界血条、生命法力、等级金币、装备、商店、技能、召唤师技能、回城和普攻连接到数据源。 1小地图minimap.update(state,dt)200px·0.25s节流2比分 / 计时state.score / state.time固定tick事实3世界血条hud.updateWorldBars3D坐标投影DOM4英雄面板hud.update()等级·HP/MP·KDA·金币56格装备栏Shop.slots → HUD购买后立即刷新属性6商店入口screens.js:showShop12件装备+推荐购买7Q / E / R技能HUD._bindAimButtonCD遮罩·蓝耗·拖拽方向8恢复 / 闪现onHeal / onFlash90s / 120s独立CD9回城state.tryRecall()8s引导·受伤中断10普攻按钮state.setAttackHeld按住追击·统一结算11飘字 / 播报hud.floatText / bannerdamage·heal·level·kill绿点=画面可见元素 金点=交互/状态规则 HUD不是静态皮肤:它同时读取状态并写入命令
Canvas小地图独立绘制
DOM overlay世界血条、伤害飘字、横幅
Action callbacks技能、回城、恢复、闪现和商店
Cooldown masks每帧读取技能与召唤师技能状态
Camera projection3D单位坐标转屏幕坐标
Shop binding金币、装备槽与推荐出装同步
选择HUD区域查看其数据源和交互入口。
PRE-11 · 原始代码/日志 · 对应 KING-V24
minimap.update(state, dt); 源码

画面与代码对应:HUD不只是静态皮肤,它读取共享状态并把玩家输入送回固定逻辑循环。

KING-V26已交付能力与下一阶段工程路线交付路线
最终产物的已交付能力、实测范围与下一阶段四层工程图把已运行能力、指定路径验收、静态源码结构和下一阶段能力放在同一张路线图中。 DELIVERY / ENGINEERING ROADMAP从已交付原型到完整产品的工程分层运行验收、源码结构与下一阶段目标分别列示,读者可以快速定位当前完成度 STRONGEST CLAIMA · 代码 + 运行证据共同支持implemented单机3D峡谷·10名英雄·三路兵线·塔/水晶·技能/装备·HUD/小地图选将→对局→水晶胜负→结算/重开;最终观察窗口无控制台错误code snapshot + screenshots + recordings + acceptance BOUNDED RUNTIMEB · 已完成的指定路径验收observed4个英雄回归·4局自动演示·12件商店物品·指定浏览器与观察窗口下一轮验收:技能组合、长稳、跨浏览器、平衡性与性能基线browser-verification.json + QA screenshots STRUCTURAL EVIDENCEC · 静态源码结构可复算reproducible17模块·39导入边·7,979行·180×180地图·15技能·9英雄AI·对象池运行图与模块职责可复算;质量由浏览器验收与后续测试继续度量verify-king-case.mjs + frozen code OUT OF SCOPED · 下一阶段产品能力not built联网多人·房间匹配·帧同步/重连·账号云存档·反作弊·服务器扩缩工业级美术动作音频·海量英雄·长期数值、赛事和运营体系accurate label: 单机Web 5v5 MOBA原型 FROZEN SOURCEsrc/config.js · src/main.js · src/game/state.js · E31–E38 · verification.json schema v4
选择分层查看已交付能力、实测范围和下一阶段路线。

画面与代码对应:现有单机原型已经接通跨系统运行链,并在指定浏览器路径完成终局验收。

最终产物复杂度结论:难点不是“页面看起来像游戏”,而是让地图空间、固定时钟、四类AI、15项技能、兵线建筑、经济成长和多层界面在同一共享状态上持续推进,并在水晶摧毁后正确进入结算与重开。26张图把这些系统的代码职责、运行关系和画面结果逐项连接起来。
03
PART 3 · 平台机制实证

ZhikunCode 的工程运行时:这次会话观测到了什么

本章把证据分成三层:本次会话日志直接观测窗口前固定源码快照中的机制、以及二者对应后形成的架构归因。协调者-Worker编排、上下文治理、工具生命周期、时限接力与浏览器反馈都有可复算记录;没有在本案出现的产品能力不会被写成成功原因。

运行时

Kimi负责生成,ZhikunCode负责让工作继续

模型请求只是其中一层。协调循环、工具管线、上下文治理、浏览器反馈与持久化共同把一次回答变成数小时的工程过程。

本节把平台源码机制与窗口内日志放在同一张剖面上,让请求循环、工具执行、上下文治理和浏览器反馈逐层对齐。

运行记录冻结源码复算或推断窗口外材料
PLAT-V01Kimi × 运行时 × 浏览器反馈闭环
Kimi × 运行时 × 浏览器反馈闭环模型为什么不是一次性吐出代码? 模型推理、运行时执行和真实浏览器观察形成多轮闭环。运行时 · 执行系统剖面模型为什么不是一次性吐出代码?模型请求Agent运行时真实工程环境1Kimi K3878个请求启动llm_call_start…2QueryEngine上下文→模型→工具ea0170c3工具执行968个完整生命周期public log4浏览器反馈376次唯一调用WebBrowser+Pyt…5原子写入267次成功写入AtomicFileWrit…6复验接续错误→后续轮次terminal events后续请求读取工具/浏览器结果,闭环继续真实调用链 · 01:55:36Worker childSession→childRun→turn 11→LLM request→WebBrowser_26→Python request97ad9951…→3,244ms完成1模型层推理与代码生成请求observability2运行时层编排/期限/工具/持久化ea0170c + log3环境反馈层真实浏览器与WebGL状态376 downstream IDs

数据:E26 / E27 / E28 / E29 / LLM事件 + 工具日志 + WebBrowser记录|图中结论:模型推理、运行时执行和真实浏览器观察形成多轮闭环

查看来源与复算数据
数据来源
LLM事件 + 工具日志 + WebBrowser记录
复算口径
模型推理、运行时执行和真实浏览器观察形成多轮闭环。
图中指标
  • Kimi请求878fact.llm.started
  • 工具调用968fact.tools.total
  • WebBrowser376fact.browser.calls
  • 原子写入267fact.controls.atomic
PLAT-V02六方责任分层
六方责任分层谁负责决定、生成、执行、复核和留痕? 角色职责可由输入、MDC agent字段、工具和证据记录区分。运行时 · 执行系统剖面谁负责决定、生成、执行、复核和留痕?模型请求Agent运行时真实工程环境六方责任泳道 · 共用真实时间轴责任按输入、MDC agent字段、工具和持久化记录区分;“同系统QA”不是组织独立第三方。用户Kimi K3协调者10个Worker工程环境证据系统878请求编排/复验/收口R01R02R03R04R05R06R07R08R09文件/Bash/浏览器日志/DB/事件/账单1用户范围选择与任务授权interaction_requests2协调/WorkerMDC agent=query|subagentpublic log3证据系统串起代码、日志、账单和媒体DB/log/bill/media

数据:E26 / E27 / E28 / E29 / 用户消息 + 平台源码 + 冻结日志|图中结论:角色职责可由输入、MDC agent字段、工具和证据记录区分

查看来源与复算数据
数据来源
用户消息 + 平台源码 + 冻结日志
复算口径
角色职责可由输入、MDC agent字段、工具和证据记录区分。
图中指标
  • 责任层6
  • 根Run1
  • Worker Run10
  • 证据域7

循环能够持续,还要回答上下文如何控制、工具如何闭合、平台源码与本次日志如何互证。

PLAT-V03QueryEngine八步长任务循环
QueryEngine八步长任务循环878轮如何不断推进而不是停在回答? 源码八步循环与多轮模型/工具记录时间上对应。运行时 · 执行系统剖面878轮如何不断推进而不是停在回答?模型请求Agent运行时真实工程环境1组装上下文Step 12ContextCascadeStep 23调用模型878 started4解析响应Step 45工具验证Step 56工具执行968 calls7写回结果Step 78继续/终止873+5终态LLM请求账本 · 同一requestId唯一终态started与completed/failed是同一计数单位,873+5=878。started878completed873cancelled5工具调用账本 · 968条完整三阶段生命周期复合工具键在验证、调用和完成记录中各出现968次。Stage 1验证968Stage 5调用968完成记录968同一Agent循环可产生0..n次工具调用;不是守恒流

数据:E26 / E27 / E28 / E29 / ea0170c QueryEngine.java + 878 started事件|图中结论:源码八步循环与多轮模型/工具记录时间上对应

查看来源与复算数据
数据来源
ea0170c QueryEngine.java + 878 started事件
复算口径
源码八步循环与多轮模型/工具记录时间上对应。
图中指标
  • 源码步骤8
  • started878fact.llm.started
  • completed873fact.llm.completed
  • cancelled5fact.llm.failed
PLAT-V04ContextCascade上下文治理曲线
ContextCascade上下文治理曲线超长任务为什么没有在窗口内触发重型溢出? 878次调用前均评估预算;26次轻量折叠释放2,029字符。运行时 · 执行系统剖面超长任务为什么没有在窗口内触发重型溢出?模型请求Agent运行时真实工程环境878次上下文评估 · 按模型调用序号曲线使用全部878个tokensBefore值;金色短线标记26次collapseExecuted=true。650,000487,500325,000162,5000tokensBefore650,000阈值模型调用序号 1→878估算tokens1峰值240,202 < 650,000ContextCascade2轻量折叠26次 / 释放2,029字符collapseExecuted3未触发重型压缩 / 413恢复 = 0window events

数据:E26 / E27 / E28 / E29 / ContextCascade日志 + context_cascade_evaluation|图中结论:878次调用前均评估预算

查看来源与复算数据
数据来源
ContextCascade日志 + context_cascade_evaluation
复算口径
878次调用前均评估预算;26次轻量折叠释放2,029字符。
图中指标
  • 评估878fact.context.evaluations
  • 轻折叠26fact.context.collapses
  • 峰值240,202
  • 阈值650,000
PLAT-V05ToolExecutionPipeline三段生命周期
ToolExecutionPipeline三段生命周期968次工具如何统一进入可审计管线? 968个复合键均有Stage1、Stage5和完成记录。运行时 · 执行系统剖面968次工具如何统一进入可审计管线?模型请求Agent运行时真实工程环境复合工具键 · 968Stage 1验证 · 968Stage 5调用 · 968error=false · 951error=true · 1717次结构化错误按工具拆分错误被记录并返回Agent Loop;不能自动宣称17次全部被修复。Edit6WebBrowser5Agent3CodeIntel1Bash2

数据:E26 / E27 / E28 / E29 / ea0170c ToolExecutionPipeline + 冻结应用日志|图中结论:968个复合键均有Stage1、Stage5和完成记录

查看来源与复算数据
数据来源
ea0170c ToolExecutionPipeline + 冻结应用日志
复算口径
968个复合键均有Stage1、Stage5和完成记录。
图中指标
  • Stage1968
  • Stage5968
  • 完成记录968
  • 错误17fact.tools.error
PLAT-V06源码类名与日志组件交叉一致
源码类名与日志组件交叉一致平台机制是事后编出来的吗? 七个运行时类在窗口前提交中已存在,多项同名出现在日志。运行时 · 执行系统剖面平台机制是事后编出来的吗?模型请求Agent运行时真实工程环境1QueryEngine源码类名与日志组件交叉ea0170c/QueryEngine.java2ContextCascade源码类名与日志组件交叉ea0170c/ContextCascade.ja…3ToolExecutionPipeline源码类名与日志组件交叉ea0170c/ToolExecutionPipe…4SubAgentExecutor源码类名与日志组件交叉ea0170c/SubAgentExecutor.…5AgentConcurrencyController源码存在;本案无直接事件ea0170c/AgentConcurrencyC…6CheckpointService源码类名与日志组件交叉ea0170c/CheckpointService…7BestEffortObservabilityRecorder源码类名与日志组件交叉ea0170c/BestEffortObserva…00:42:00ea0170c窗口前源码快照01:30:00开发窗口运行构建SHA缺失07:01:00窗口结束冻结证据12:04:0074aef15只改四份说明文档

数据:E26 / E27 / E28 / E29 / ea0170c七个类 + 日志组件名 + Git时间边界|图中结论:七个运行时类在窗口前提交中已存在,多项同名出现在日志

查看来源与复算数据
数据来源
ea0170c七个类 + 日志组件名 + Git时间边界
复算口径
七个运行时类在窗口前提交中已存在,多项同名出现在日志。
图中指标
  • 固定源码类7
  • 窗口前提交ea0170c
  • 窗口后提交74aef15
  • 运行构建SHA缺失

控制面让每类故障留下明确终态,也让后续循环知道从哪里接。

PLAT-V072,003条观测事件的事件河流
2,003条观测事件的事件河流长任务留下了哪些结构化终态? LLM、进程、Worker、终止和输入事件均有类型化记录。运行时 · 执行系统剖面长任务留下了哪些结构化终态?模型请求Agent运行时真实工程环境2,003条观测事件 · 分钟级事件河流所有事件按occurredAt所在分钟聚合;七条线共享同一时间顺序,不把数量当质量。118630llm:startedllm:completedprocess_startedprocess_finishedsubagent_startedsubagent_completedsubagent_failed01:31 → 07:00(有事件分钟)每分钟事件数1LLM878 started / 873 completed /…observability JSONL2进程104 started / 104 finishedprocess events3Worker10 started / 10终态subagent events

数据: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
PLAT-V08持续写入、保存与连接恢复
持续写入、保存与连接恢复局部波动时中间状态如何保留? 267次原子写入、157次Checkpoint保存和60组重连可复算。运行时 · 执行系统剖面局部波动时中间状态如何保留?模型请求Agent运行时真实工程环境运行控制事件按真实时间对齐单个事件以短竖条表示;60次loss与60次reconnect按日志顺序配对。Atomic writeCheckpointMCP lossMCP reconnect1原子写入267次成功替换AtomicFileWriter2Checkpoint157次保存;实际恢复=0CheckpointService3MCP60 loss / 60 reconnect / 0孤立McpClientManager

数据:E26 / E27 / E28 / E29 / AtomicFileWriter + CheckpointService + MCP日志|图中结论:267次原子写入、157次Checkpoint保存和60组重连可复算

查看来源与复算数据
数据来源
AtomicFileWriter + CheckpointService + MCP日志
复算口径
267次原子写入、157次Checkpoint保存和60组重连可复算。
图中指标
  • Atomic write267fact.controls.atomic
  • Checkpoint157fact.controls.checkpoint
  • 重连配对60fact.controls.reconnectPairs
  • 实际Checkpoint恢复0
PLAT-V09SQLite四层持久化拓扑
SQLite四层持久化拓扑执行历史如何落为可查询证据? 会话、消息、活动和交互请求通过sessionId形成可查询关系。运行时 · 执行系统剖面执行历史如何落为可查询证据?模型请求Agent运行时真实工程环境sessions1b8f86099-452d-4ba6messages229117 user / 112 assistantactivities113协调者工具活动interaction_requests4四项需求选择session_idsession_idsession_id冻结SQL口径session_id = :root AND created_at >= start AND created_at <endprovenance.jsonToken字段边界sessions.total_input_tokens = 0; token事实来自messages/events/billdb/session-row.json

数据:E26 / E27 / E28 / E29 / 冻结SQLite导出|图中结论:会话、消息、活动和交互请求通过sessionId形成可查询关系

查看来源与复算数据
数据来源
冻结SQLite导出
复算口径
会话、消息、活动和交互请求通过sessionId形成可查询关系。
图中指标
  • sessions1
  • messages229
  • activities113
  • interactions4
PLAT-V10权限与信任边界
权限与信任边界自主执行为什么仍有范围控制? 开发窗口权限请求为0,工具在指定工作目录和既有授权内运行。运行时 · 执行系统剖面自主执行为什么仍有范围控制?模型请求Agent运行时真实工程环境本案实际进入的工作域实线连接本案真实观测;虚线标出平台具备、但本次任务没有调用的机制。Project工作目录/project/king01用户范围确认4项需求选择02工具验证管线968完整生命周期03安全审计开发窗口116行04发布授权窗口外;GitHub未执行1本案工作面Project/工具/审计/授权logs+db2本次未调用Team/Swarm/Artifact发布runtime scope3关键结果开发与发布权限分层记录security audit

数据: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 块原文
② 指纹登记平台记录 promptLengthpromptFingerprint(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
原始字段报告别名关联用途字段口径
sidsessionId区分根会话与10个Worker子会话本地会话主键
ridrunId区分一次Agent Loop执行同一会话可随时间出现不同Run
pridparentRunId把10个子Run直接连回根Run-表示该日志行没有父Run
agent=query|subagent执行角色区分协调者与Worker角色来自MDC;观测事件的agentType=general-purpose不用于角色判定
turnAgent轮次把模型与工具放回具体循环轮次轮次不是质量评分
llm / data.requestIdllmRequestId配对LLM started与唯一终态失败后新requestId不是同一请求重试
MDC tool / 正文toolUseIdtoolUseId与sessionId、runId组成工具复合键裸序号会跨Run复用
Python日志requestIddownstreamRequestId连接Java工具与Python浏览器服务与浏览器返回值和验收断言配合使用
LOG-V01一次真实调用的七层血缘链38,626条MDC行 · 01:55:36实录
LOG-V01 一次真实WebBrowser调用的七层标识符血缘链 从根会话与根Run,经Worker子会话与子Run、Turn 11、LLM请求、WebBrowser工具、Python请求,到3244毫秒完成记录。右侧解释复合键与字段来源。 01:55:36 · WebBrowser_26 / navigate · 标识符级血缘 每一层都来自同一冻结日志行的MDC或正文键值;箭头表示字段直接关联,不是时间近邻猜测。 SEVEN-LEVEL TRACE 1ROOT SESSION + ROOT RUNsid b8f86099-452d-4ba6-89c2-c3fee8f4b422rid eb2e9ba2-6975-4c83-9e83-8eebcb7f1b10 · agent=query 2WORKER SESSION + CHILD RUNsid subagent-agent-64f62e42 · rid b11d33bb-4d08-477b-88fa-977ddfba67c9prid eb2e9ba2-6975-4c83-9e83-8eebcb7f1b10 · agent=subagent 3TURN 11QueryEngine循环位置 · 01:55:32.269开始模型流 4LLM REQUESTllm-72c74176-a7d6-49e0-adb2-7f16dc9a1045 · kimi-k3HTTP 200 → tool_use块;工具终态由完成记录继续闭合 5TOOL USEWebBrowser_26 · stage 1 validation → stage 5 call复合键 sid + rid + toolUseId;裸WebBrowser_26会在其他Run复用 6JAVA → PYTHON REQUESTPOST /api/browser/navigate · requestId 97ad9951-84cb-4b7a-8c5e-a1458a3c2c9fattempt=1 · bodyLength=124 · bodyFingerprint=608925d6… 7TERMINAL RECORDTool WebBrowser completed in 3244ms (error=false)01:55:39.514 · ToolExecutionPipeline GLOBAL TRACE GRAPH 11 sessions11 runs10 parent-child edges10个Worker均有独立childSession + childRun全部prid直接指向根Run eb2e9ba2… WHY COMPOSITE KEYS MATTER 968复合工具键422裸工具序号裸序号唯一性仅422 / 968 376 ↔ 376WebBrowser复合键 ↔ Python requestIdmissing 0 · duplicate 0 · unique 376 FROZEN SOURCElogs/app-session-20260809-0130-0701.public.log · lines 1202–1226 · verification.json.logs.traceability / toolIdentity
点击或聚焦任一层,可查看该字段如何把真实调用串回根Run。

画面与代码对应:冻结窗口可重建11个会话、11个Run、10条父子关系;此浏览器调用可从根Run追到唯一Python请求与终态。

3.1c 为什么能完成:平台机制与本案观测逐项对应 源码机制 日志实测 架构归因

四份平台说明材料最有价值的用途,不是再罗列“40+工具”或其他产品总量,而是帮助解释冻结日志中已经观测到的类、管线和控制点。下面这张图只画本案例实际留下记录的路径:

Kimi K3878 次模型调用启动 · 推理、代码生成与工具选择

QueryEngine · 多轮 Agent Loop

ContextCascade878 次上下文预算评估
ToolExecutionPipeline968 / 968 / 968 次验证、调用、完成
SubAgentExecutor10 次专业 Worker 运行
WebBrowser376 次真实浏览器反馈
AtomicFileWriter267 次成功原子写入
CheckpointService157 次保存
Observability / DB日志、事件、消息与活动持续留痕
账单对账873 条 completed 与账单 Token 元组逐条匹配
错误进入下一轮模型失败与工具错误均有显式事件
实现 → 运行 → 观察 → 修复 → 复验最终形成17个模块、39条本地相对导入边的可玩3D MOBA原型
TABLE-11 · 原始表格 · 对应 PLAT-V03
源码机制本案直接观测工程作用本次运行口径
QueryEngine 8步循环878 started / 873 completed / 5 failed任务由多轮模型与工具循环推进,不是一次提示直接生成内部条件分支由固定源码快照补充定位
ContextCascade878次唯一评估,与878次模型启动一一对齐每次模型调用前均执行了上下文预算治理最高上下文低于阈值,重型恢复链本次无需启动
ToolExecutionPipeline968次调用均有验证、实际调用和完成记录工具经过统一、可审计的生命周期完成记录继续区分951次error=false与17次error=true
SubAgentExecutor10次Worker启动、独立childSessionId和终止事件专业分工由真实子会话和独立Agent Loop执行本案记录1次自然完成、6次期限回收、3次轮次回收
WebBrowser376次唯一工具调用真实页面观察进入了实现和复验闭环376是唯一调用数;验收通过项由V01–V12单独统计
CheckpointService157次保存长任务持续产生可恢复状态点157次保存;开发窗口内Checkpoint恢复事件为0

源码结构与执行记录在这里形成同一条解释链:模型负责生成和判断,运行时负责持续执行,浏览器负责返回真实环境状态;三层贡献的定量拆分留给后续消融实验。

3.1d 超长任务为什么没有失去上下文:878轮治理实测 日志实测 可复算

878次唯一上下文评估
26次轻量 ContextCollapse 实际执行
2,029个字符被轻量折叠释放
240,202观察到的最高 Token 估算
650,000本次日志记录的压缩阈值
0AutoCompact / 越阈值 / 413恢复事件

冻结应用日志包含878 次唯一上下文评估,恰好对应878次 llm_call_started。每轮均尝试轻量 ContextCollapse:50轮没有候选、802轮没有净收益、26轮实际产生正收益,合计释放2,029 个字符。最高估算为240,202 tokens,仍低于650,000阈值,因此没有触发 AutoCompactCollapseDrainReactiveCompact 或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 successful267次成功事件逐条留痕;文件去重和内容校验由代码快照与SHA清单另行完成
运行Checkpoint157 次 Checkpoint 保存CheckpointService - Checkpoint saved157次保存逐条留痕;本次开发通过落盘产物与后续轮次接续,Checkpoint恢复事件为0
MCP连接恢复60 组完整配对:60次断线、60次成功重连、0个未配对事件zhipu-websearch connection lostreconnected successfully60次断线均出现后续成功重连;开发效率影响留给单独性能分析

配对方法:验证脚本按冻结应用日志的原始顺序扫描;每条 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 局部故障如何留下终态,并由后续轮次接续 日志实测 因果边界

LOG-V03局部故障、终态与接续证据泳道5类信号 · 发生、终态与后续活动分列
LOG-V03 局部故障、终态和后续活动泳道 五条泳道分别展示模型取消、工具结构化错误、Worker期限和轮次终止、MCP断线重连、原子写入与Checkpoint。每条泳道分开记录发生、终态和随后可确认活动。 失败不是被剪掉的噪声:每类事件有独立终态 列方向:发生记录 → 明确终态/配对 → 随后可确认活动;新请求与新轮次使用独立标识符。 SIGNALOBSERVED FAILURE / INTERRUPTIONRECORDED TERMINALLATER OBSERVATION LLM5 cancelled5 × llm_call_failedcancelled · status 0 · attempt 1878 = 873 + 5每个requestId恰有一个终态后续出现新requestId后续活动使用新的requestId TOOLS17 errorsEdit 6 · Browser 5 · Agent 3Bash 2 · CodeIntel 1968 completion records951 false · 17 true后续Loop继续调用17次错误保留在账本中 WORKERS10 runs6 deadline · 3 maxTurns9次由运行边界回收1 natural / 6 / 3终止原因可按childRun归属协调者另起续作使用已落盘产物继续 MCP60 losseszhipu-websearch connection lost60次 · 无重叠pending60 reconnect pairsorphan 0 · unclosed 0连接机制恢复效率影响单独分析 STATE267 / 157267 Atomic write successful157 Checkpoint saved保存事件持续存在中间产物可被后续读取Checkpoint恢复事件 0本案接续依赖落盘产物与后续轮次 AUDIT CONCLUSION五类局部故障均有明确终态;协调者和后续轮次继续读取落盘产物,最终完成浏览器验收。 SOURCE observability-events + app-session log · verification.json.logs.failureContinuation · causalRecoveryInferred=false
选择泳道,检查该类故障的发生数、终态和后续活动。

画面与代码对应:故障、错误和运行边界没有被成功叙事抹去;终态可以分类并复算,之后仍有全局模型调用、续作和最终验收活动。

3.3 持久化拓扑(SQLite 四层,本次会话实测行数) 数据库

TABLE-14 · 原始表格 · 对应 PLAT-V09
本会话行数内容
会话层sessions1创建时间/模型/工作目录/Token 累计字段
消息层messages229(窗口冻结)完整对话:用户输入、协调者回复与工具调用、Worker 通知
活动层activities113(窗口冻结)每次工具调用:时刻/耗时毫秒/决策/结果原文/变更文件
交互层interaction_requests4(窗口冻结)4 项需求确认;开发窗口内 permission 为 0

四层交叉:messages 的 Agent 调用 ↔ observability 的 subagent_started ↔ activities 的 1800.0s duration,三个本地记录面可以核对同一事件。它们由同一套本地系统产生,属于共享信任域,交叉一致能发现偶发缺失或统计错误,但不等同于三个独立第三方来源。

3.4 权限与安全门控 数据库

窗口内事实:游戏开发全程(01:30–07:01)权限请求 0 次(interaction_requests 的窗口冻结导出只有 4 条 elicitation)。下表是窗口外 09:55–09:59 的首批 7 条报告撰写期权限记录,仅作为门控形态补充;冻结的窗口外补充文件当前共有 12 条交互,其中 9 条 permission、3 条 elicitation,绝不并入开发统计。
TABLE-15 · 原始表格 · 对应 PLAT-V10
时刻(+08,撰写期)工具风险级原因原文(摘要)决策范围operationHash(前 16 位)
09:55:44Bash_119safeRead access requires confirmation(ls 项目外目录)allowsessiona104c7ae78fdc12e…
09:55:46Bash_120safeRead access requires confirmation(ls -R 素材目录)allowsession5502cbd20013f90d…
09:56:25Read_121guardedRead outside Project(读规范文档)allowsession5d48d2cc380cdcf4…
09:57:07Agent_126guardedAgent exact invocation(启动子 Agent)allowonceac31055052341761…
09:57:22Read_2guardedRead outside Projectallowonce8e4fb7e727313cee…
09:57:30Read_3guardedRead outside Project(同 hash 复授权)allowsession8e4fb7e727313cee…
09:59:23Read_15guardedRead outside Projectallowsessiona01211cb4528a6db…

表中 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 小时保持不变。(审计注记:本报告早前版本曾断言"全程无重连"——该断言未经全量日志逐行验证,已撤除,仅保留可复核的首末行事实。)

04
PART 4 · 执行过程

10 个子 Agent 汇入同一个项目

协调者(主会话)负责需求确认、撰写开发规范 DESIGN.md、逐阶段同系统复测与一次直接代码修复;10 个子 Agent 按"地基→玩法→AI→攻坚×3→UI→视觉→修复→QA"接力执行。所有起止时间取自观测事件日志,精确到秒;每个 Agent 的 Token 消耗按 childSessionId 分账。

编排

十次Worker不是十段宣传语,而是十条可追踪运行

一个根Run先后接住10个Worker:只有1次自然完成,6次到达期限,3次到达最大轮次。项目依靠落盘成果和后续复验继续向前。

时间轴保留停顿、回收和接续,可以直接看到一次复杂攻坚如何在十次Worker之间向前接力。

运行记录冻结源码复算或推断窗口外材料
RUN-V011个根Run+10个Worker Run:5小时29分17秒首末请求轨迹
1个根Run+10个Worker Run:5小时29分17秒首末请求轨迹11个Run、Token、终态、产物和接续如何同轴阅读? 共享时间轴可显示阶段、运行边界、资源投入和交付演进。编排 · 五小时二十九分十七秒首末请求轨迹11个Run、Token、终态、产物和接续如何同轴阅读?01:3007:01同轴Gantt:1个根Run+10个Worker Run横向距离按真实时间;颜色编码自然完成/30分钟期限/最大轮次,条高不编码Token。ROOT 协调者R01 地图地基R02 战斗核心R03 AI野区R04 堵路修复R05 终局僵持R06 基地门径R07 UI音效R08 视觉表现R09 性能修复R10 QA终验协调/复验/收口R01 deadlineR02 deadlineR03 deadlineR04 deadlineR05 deadlineR06 naturalR07 max_turnsR08 deadlineR09 max_turnsR10 max_turns5.46M3.21M6.1M4.59M7.07M7.56M11.42M14.31M10.41M4.79M1终止语义1 natural / 6 deadline / 3 maxTurnsterminal events+duration2接续父Run在每个Worker后继续活动public log3时间口径5:29:17是首末请求锚点跨度time window

数据:E03 / E16 / E24 / E39 / 关键时间表 + Run/Token/预算/接续五组原账|图中结论:共享时间轴可显示阶段、运行边界、资源投入和交付演进

查看来源与复算数据
数据来源
关键时间表 + Run/Token/预算/接续五组原账
复算口径
共享时间轴可显示阶段、运行边界、资源投入和交付演进。
图中指标
  • 全部Run11fact.run.total
  • Worker Run10fact.run.workers
  • LLM started878fact.llm.started
  • 工具调用968fact.tools.total
RUN-V02根Run与10个Worker运行DAG
根Run与10个Worker运行DAG多Agent协作能否沿标识符重建? 11个session、11个run和10条parentRun边均可复算。编排 · 五小时二十九分十七秒首末请求轨迹多Agent协作能否沿标识符重建?01:3007:01ROOT session / runS b8f86099-452d-R eb2e9ba2-6975-parentRunId = ROOTR01 · deadlineS subagent-ageR b11d33bb-4d0R02 · deadlineS subagent-ageR ed87ec42-4c4R03 · deadlineS subagent-ageR 1c2a6bb7-b0eR04 · deadlineS subagent-ageR 65db84b4-29aR05 · deadlineS subagent-ageR 338682fe-2e1R06 · naturalS subagent-ageR 8a3c0a29-db3R07 · max_turnsS subagent-ageR 01262f8f-d97R08 · deadlineS subagent-ageR 4a2529cd-726R09 · max_turnsS subagent-ageR ede81716-cf7R10 · max_turnsS subagent-ageR 3cc33bb6-415

数据:E03 / E16 / E24 / E39 / logs.traceability.mappings|图中结论:11个session、11个run和10条parentRun边均可复算

查看来源与复算数据
数据来源
logs.traceability.mappings
复算口径
11个session、11个run和10条parentRun边均可复算。
图中指标
  • sessions11fact.run.total
  • runs11fact.run.total
  • parent edges10fact.run.workers
  • root1

有了父子DAG,再把时长、Token、提示词和交付物放回同一时间轴,就能看见接力的真实投入。

RUN-V0310个Worker的工程责任图
10个Worker的工程责任图专业分工怎样汇入同一代码库? 地图、战斗、AI、终局、UI、视觉、性能和QA任务依次接力。编排 · 五小时二十九分十七秒首末请求轨迹专业分工怎样汇入同一代码库?01:3007:01地图/world战斗/stateAI/spawnerUI/HUD视觉/VFX浏览器QAR01 地图地基主责任/直接活动读取/联调读取/联调R02 战斗核心主责任/直接活动读取/联调读取/联调读取/联调R03 AI野区读取/联调读取/联调主责任/直接活动读取/联调R04 堵路修复读取/联调读取/联调主责任/直接活动主责任/直接活动R05 终局僵持主责任/直接活动主责任/直接活动主责任/直接活动R06 基地门径读取/联调读取/联调主责任/直接活动主责任/直接活动R07 UI音效主责任/直接活动读取/联调主责任/直接活动R08 视觉表现读取/联调主责任/直接活动主责任/直接活动R09 性能修复读取/联调读取/联调主责任/直接活动主责任/直接活动主责任/直接活动R10 QA终验读取/联调读取/联调主责任/直接活动读取/联调主责任/直接活动1主责任提示词任务域+对应工具活动subagent prompt/log2联调读取/浏览器/跨模块验证tool records3责任视图主责文件、联调文件与交付物分层展示prompt + tool map

数据:E03 / E16 / E24 / E39 / 10份Agent提示词 + 产物谱系|图中结论:地图、战斗、AI、终局、UI、视觉、性能和QA任务依次接力

查看来源与复算数据
数据来源
10份Agent提示词 + 产物谱系
复算口径
地图、战斗、AI、终局、UI、视觉、性能和QA任务依次接力。
图中指标
  • Worker10
  • 责任域6
  • 构建阶段5
  • 修复/QA5
RUN-V04时长、调用与Token投入分布
时长、调用与Token投入分布哪些阶段消耗了最多上下文和模型轮次? 11个执行体的调用、输入、输出和占比可精确求和。编排 · 五小时二十九分十七秒首末请求轨迹哪些阶段消耗了最多上下文和模型轮次?01:3007:010m82.3m164.6m247m329.3mROOTR01R02R03R04R05R06R07R08R09R10时长(分钟)输入Token1X轴真实执行时长terminal.durationMs2Y轴完成请求输入Token归账llm completed3气泡面积输出Token平方根比例outputTokens

数据:E03 / E16 / E24 / E39 / observability按childSessionId归账|图中结论:11个执行体的调用、输入、输出和占比可精确求和

查看来源与复算数据
数据来源
observability按childSessionId归账
复算口径
11个执行体的调用、输入、输出和占比可精确求和。
图中指标
  • 执行体11
  • 运行输入82,300,554
  • 运行输出670,170
  • 终态类型3
RUN-V05提示词长度、指纹与预算条款
提示词长度、指纹与预算条款Worker任务如何可识别、可比较? 10份提示词均有长度和SHA-256指纹,后期引入时间预算。编排 · 五小时二十九分十七秒首末请求轨迹Worker任务如何可识别、可比较?01:3007:01prompt字符指纹验收条款预算条款终态R01 地图地基269789%09c80cd95868阶段验收未见显式deadlineR02 战斗核心273390%46fd448559af阶段验收未见显式deadlineR03 AI野区228575%e883a6d43007阶段验收未见显式deadlineR04 堵路修复172056%ebe6ee5a8321阶段验收未见显式deadlineR05 终局僵持175758%6b42a0f6e80d阶段验收未见显式deadlineR06 基地门径178259%cd24bda635b5阶段验收显式预算naturalR07 UI音效3046100%9f5a260f2f97阶段验收显式预算max_turnsR08 视觉表现197065%c8b49670a301阶段验收显式预算deadlineR09 性能修复160653%8f29c1e3b9ea阶段验收显式预算max_turnsR10 QA终验184260%70ed9a2c5db5清单式QA未见显式max_turns1可识别10份长度+SHA-256指纹subagent_started2可比较验收条款与预算条款逐项对照DB messages3实际用途确认十次任务分派并非重复记录prompt fingerprints

数据: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

阶段谱系使用日志、文件和截图中能够直接定位的锚点。

RUN-V06M0–M7产物谱系
M0–M7产物谱系最终产物如何逐阶段形成? 八个里程碑可关联产出Run和锚点证据。编排 · 五小时二十九分十七秒首末请求轨迹最终产物如何逐阶段形成?01:3007:01M0规范与骨架ROOT · DESIGN.md / indexM1地图可游走R01 · map/models/configM2战斗技能R02 · state/skills/shopM3AI与野区R03 · ai/spawnerM4可终结性攻坚R04–R06 · 堵路/水晶/门径M5HUD与音效R07 · hud/screens/audioM6视觉性能R08–R09 · models/vfx/DOMM7QA终验R10+ROOT · V01–V12日志、文件活动与截图锚点组成的阶段接力工程阶段谱系M0–M7由Worker启动/终态、首次文件活动、截图与最终代码交叉重建。1阶段任务每个里程碑都连接对应Runlogs+messages2交付文件最终文件与首次活动锚点file activities3画面进展截图和视频标记可运行阶段media anchors

数据:E03 / E16 / E24 / E39 / 日志 + 会话消息 + 代码快照 + 截图|图中结论:八个里程碑可关联产出Run和锚点证据

查看来源与复算数据
数据来源
日志 + 会话消息 + 代码快照 + 截图
复算口径
八个里程碑可关联产出Run和锚点证据。
图中指标
  • 里程碑8
  • 构建Run3
  • 修复Run6
  • Git阶段快照0
RUN-V07113条协调者活动流
113条协调者活动流协调者不仅派任务,还做了什么? 协调者执行环境探测、浏览器复验、直改、轮询和收口。编排 · 五小时二十九分十七秒首末请求轨迹协调者不仅派任务,还做了什么?01:3007:01113条协调者activities · 按活动ID前缀复算9类工具长度编码真实计数:WebBrowser 54、Sleep 18、Bash 12、Agent 10、Read 10、Grep 4、Write 2、Edit2、AskUserQuestion 1。WebBrowser54Sleep18Bash12Agent10Read10Grep4Edit2Write2AskUserQuestion1113条完整活动时间胶片每个标记仍保留原始id、summary、时间和duration;分类不删除自由文本摘要。1协调者视图ROOT会话113条活动activities export2分类键按活动ID前缀精确归类id /^([A-Za-z]+)/3全体视图Worker与协调者合计968次工具composite tool keys

数据:E03 / E16 / E24 / E39 / db/activities-20260809-0130-0701.json|图中结论:协调者执行环境探测、浏览器复验、直改、轮询和收口

查看来源与复算数据
数据来源
db/activities-20260809-0130-0701.json
复算口径
协调者执行环境探测、浏览器复验、直改、轮询和收口。
图中指标
  • activities113
  • 工具类型9
  • 全部工具968
  • 窗口01:30–07:01
RUN-V08编码前8分钟Preflight
编码前8分钟Preflight为什么不是先承诺再碰运气? 先确认范围、探测目录/工具/CDN,再本地化依赖和启动R01。编排 · 五小时二十九分十七秒首末请求轨迹为什么不是先承诺再碰运气?01:3007:01编码前Preflight · 真实时间比例先确认范围,再探测项目目录、Python/Node、CDN可用性、本地化依赖和端口约束。01:31:05需求到达一句话目标01:32:444项确认完成39.561s01:34:57目录/工具探测Bash_101:35:03CDN双源200jsDelivr+unpkg01:39:06DESIGN落盘Atomic write01:39:58R01启动地图地基Bash_1环境探测ls -la project/king; which python3; which node; which npxdb/activities:Bash_1Bash_2依赖探测curl jsDelivr → HTTP/2 200; curl unpkg → HTTP/2 200db/activities:Bash_2

数据: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:35CDN 双源可达性实测: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 启动 R01DESIGN.md(2.3 全文);observability 第 13 行

意义:技术方案不是"选出来的"而是"验证过的"——先证明 three.js 可离线落地,再向用户承诺 3D 锁视角方案;先确认端口占用实况,再把端口规则写进规范。

4.1 逐 Run 执行账本 日志

TABLE-17 · 原始表格 · 对应 RUN-V01
RunAgent ID任务开始 → 结束持续终态关键产出
R01agent-64f62e42阶段1:地基与 3D 地图01:39:58 → 02:09:5830m00s30m 运行边界项目骨架、王者峡谷全图、相机/摇杆、可行走英雄;1,777 行
R02agent-1c86cd96阶段2:战斗核心02:12:10 → 02:42:1030m00s30m 运行边界单位/小兵波次/防御塔/5 英雄技能/弹道/特效;4,017 行
R03agent-1c9d320a阶段3:英雄 AI 与野区02:47:40 → 03:17:4030m00s30m 运行边界9 个 AI 英雄、野怪/BUFF/龙、装备自动购买;ai.js 704 行
R04agent-ea473eef修复1:小兵堵路03:22:34 → 03:52:3430m00s30m 运行边界路径点放宽+横向偏移+卡死自救;小兵峰值 113→46
R05agent-bf99fd68修复2:终局僵持03:59:35 → 04:29:3530m00s30m 运行边界超级兵/小兵成长/GROUP_PUSH;推塔提速
R06agent-6b9d1e29修复3:英雄攻不进基地04:41:25 → 05:06:3325m08s正常收尾门径路由+ASSAULT 模式+水晶梯度减伤;3/3 局分出胜负
R07agent-596000a2阶段4:完整 UI/音效/播报05:07:33 → 05:35:0627m33s轮次上限选将/小地图/商店/播报/TTS/结算;自报 17 分钟完整对局验证
R08agent-392c10e7阶段5:视觉打磨与性能05:38:41 → 06:08:4130m00s30m 运行边界5 英雄模型重做、特效升级;留下发光 bug 与 FPS 问题
R09agent-9b527904修复4:发光 bug+性能06:10:19 → 06:32:0521m46s轮次上限闪红改独立壳层(杜绝共享材质污染)、DOM 血条节流;FPS 6→31.8
R10agent-adc6f86f阶段6:隔离上下文的同系统 QA06:33:42 → 06:52:4519m03s轮次上限逐项验收;发现"塔攻击无音效事件"等小问题(列入遗留清单 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 视觉)8914,306,47179,05017.4%
agent-596000a2(R07 UI)9911,419,63571,34713.9%
agent-9b527904(R09 修复)9910,409,20744,25412.6%
agent-6b9d1e29(R06 门径)797,558,60760,8449.2%
协调者主会话(b8f86099)1127,386,86858,9599.0%
agent-bf99fd68(R05 僵持)687,072,44657,9658.6%
agent-1c9d320a(R03 AI)636,097,16163,6807.4%
agent-64f62e42(R01 地基)765,462,43065,6106.6%
agent-adc6f86f(R10 QA)994,791,02631,2235.8%
agent-ea473eef(R04 堵路)514,587,66552,9695.6%
agent-1c86cd96(R02 战斗)383,209,03884,2693.9%
合计(=观测日志全量)87382,300,554670,170100%

交叉验证:协调者主会话的 7,386,868 / 58,959 与 DB messages 表 assistant 消息 Token 合计逐数字一致。这是同一套本地系统的两个记录面(运行时观测与持久化层)之间的一致性检查,不构成两个独立信任源。

4.3 提示词指纹(subagent_started 事件原值) 日志

TABLE-19 · 原始表格 · 对应 RUN-V05
AgentpromptLengthpromptFingerprint(SHA-256 前 32 位)
agent-64f62e422,69709c80cd95868ddaef0094b42c6b0ac5e…
agent-1c86cd962,73346fd448559af24dd3ee0dafcf5508263…
agent-1c9d320a2,285e883a6d430072945478c59e7f119b5f9…
agent-ea473eef1,720ebe6ee5a8321b92d2b754dc865531582…
agent-bf99fd681,7576b42a0f6e80dce7936423fc3bf64a5be…
agent-6b9d1e291,782cd24bda635b5c7bc6e584ccb4e1adb26…
agent-596000a23,0469f5a260f2f97cf913d15a689c5727255…
agent-392c10e71,970c8b49670a301e3602b70f0a8f78f329e…
agent-9b5279041,6068f29c1e3b9eaa0e93f3b435e4dd023e9…
agent-adc6f86f1,84270ed9a2c5db5cd4ecf86015833eb9059…

提示词全文保存在会话消息记录(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.jsisCrystalInvuln:水晶解除无敌条件从"一路 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 后(地基)
1,777 行
R02 后(战斗)
4,017 行
R03 后(AI/野区)
≈5,200 行(game 目录实测 2,980 行推算)
R04–R06 后(攻坚)
≈6,000 行
R07 后(UI)
≈7,600 行
R08–R10 后(视觉/QA)
7,979 行(最终逐文件复算)

R01/R02 行数为当时 wc -l 实测值;R03–R07 为推算(推断);最终值 7,979 为交付目录逐文件复算。

4.8 协调者工具活动流(activities 表窗口内 113 条) 数据库

逐小时分布(窗口 01:30–07:01)

01:30–02:00
5
02:00
21
03:00
19
04:00
13
05:00
22
06:00
30
07:00–07:01
3

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/错误收集/主循环R0101:39:58–02:09:58;1,777 行实测
M1王者峡谷 3D 地图 + 相机 + 摇杆 + 可行走英雄R01phase1-map 六图(SHA 可核)
M2战斗核心:单位/兵波/塔/水晶/5 英雄技能/弹道特效R024,017 行实测;t=55.8s 三路交战
M3英雄 AI + 野区 + 装备自动购买R03ai.js 704 行实测;AI 击杀 4:0
M4可终结性:堵路修复 + 僵持修复 + 门径/ASSAULTR04–R063/3 局分出胜负(PART 7.2 表)
M5完整 UI:选将/小地图/商店/播报/TTS/结算R07选将与 HUD 截图;12 横幅自报
M6视觉与性能:模型重做/特效/壳层闪红/FPS 修复R08–R09I4 前后对照截图;FPS 6→31.8
M7隔离上下文的同系统 QA + 协调者全链路终验R10 + 协调者V01–V12 记录为通过;验收观察窗口内未记录错误

4.10 提示词工程演进:时间预算条款的引入 数据库

TABLE-21 · 原始表格 · 对应 RUN-V01
Run提示词长度验收/自检条款时间预算条款终态中断点位置
R012,697deadline验证期(截图归档中)
R022,733deadline验证期(截图只存 1 张)
R032,285deadline验证期(轮询中)
R041,720deadline验证期(验收局刚开)
R051,757deadline验证期(验收局刚开)
R061,782有(实现≤15min/验证≥12min)正常收尾—(时限内完成)
R073,046有(≤18min/≥10min)max_turns收尾期(删未用 import,验证已完成)
R081,970有(≤17min/≥10min)deadline诊断期(查 emissive)
R091,606有(≤15min/≥10min)max_turns收尾期(调像素比,验证已完成)
R101,842无(清单式)max_turns深查期(查塔音效事件)

演进事实:前 5 个 Run 均在 30 分钟期限处被回收,部分验证由协调者接手;时间预算条款自 R06 起引入("必须留 12 分钟以上验证")。R07/R09 的回传记录表明其在验证或调参收尾后触发轮次上限;R06 是唯一自然收尾。样本只有 1 个自然收尾,这里只陈述时间关联,不把提示词条款写成因果。全部提示词原文与长度/指纹见 db/session-messages.json 与 PART 4.3。

05
PART 5 · 运行韧性

9 次中断、9 次接续:长程执行的恢复全景

10 个子 Agent 中只有 1 个在时限内自然收尾(R06,25m08s);其余 9 次都在 30 分钟边界或轮次上限处被回收。后续由平台终态记录、落盘产物、协调者同系统复测与范围化续作完成收口。本章只陈述本案例可复核的中断与接续,不把它推广成对所有任务的普遍保证。

5.1 逐次中断-接续账本 日志 记忆

TABLE-22 · 原始表格 · 对应 RUN-V01
Run终态/时长中断点(Worker 最后动作)协调者接续动作结果
R01deadline 30m00s"最终检查网络请求与错误,然后归档截图"——截图归档前被回收协调者复测:6 张阶段截图已存 scratchpad、页面 KING_OK、当次 window.__errors 为空、未发现外部 HTTP 资源 → 放行 P2成果可继续使用
R02deadline 30m00s"t=55.8 三路全部交战、0 错误。截图 1"——验证截图只存 1 张亲自跑 67s/211s 两轮实测:兵线交战正常但发现演示玩家偏保守;记录为遗留观察 → 放行 P3成果完整
R03deadline 30m00s"bot T1 has fallen… Continuing to poll"——加速局轮询中被回收亲自跑 4 倍速 13 分钟,发现 100 兵堵车 bug(I1) → 启动 R04 专项修复藏雷被挖出
R04deadline 30m00s"重开新局正式测量(改动需刷新生效)"——验收局刚开亲自复测:堵车消失(峰值 113→46),但跑到 t=1350s 发现终局僵持(I2) → 直改 isCrystalInvuln + 启动 R05修复有效但暴露新雷
R05deadline 30m00s"重跑验收局 1(arthur)"——又停在验收起点亲自复跑:推塔恢复但 t=1087s 发现英雄贴墙卡死(I3) → 整理贴墙坐标证据包启动 R06再挖一雷
R06正常收尾 25m08s—(时限内完成实现+3 局验收+传送实验)复核 3 局对局数据与传送实验 → 关闭 I2/I3,进入 UI 阶段唯一自然收尾
R07max_turns 27m33sWorker 自报:"17 分钟完整对局完成、12 横幅、16 击杀条、零报错",随后在清理未用 import 时被回收协调者同系统复测选将/HUD/商店/播报链路 → 记录为通过成果可继续使用
R08deadline 30m00s"亚瑟全身橙红(疑似又被闪红)…先查当前 emissive 状态"——正在诊断截图确认发光 bug 实证 + FPS=6 → 整理根因假设(共享材质污染)启动 R09半成品暴露两雷
R09max_turns 21m46s"daji 25s 后 FPS 31.8(335 calls)——过线但余量小。把像素比 0.55 降到 0.5"——调参收尾中被回收实测修复后画面:亚瑟细节恢复;FPS 21–31.8 达标(软渲染口径)→ 关闭 I4成果完整
R10max_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自动重试成功。未观察到这些失败点导致会话永久终止,但不能绝对断言中间生成内容毫无损失。

一句话:9/10 的 Run 在时限处被切断;后续通过"Worker 实现 → 中断 → 协调者同系统复测 → 定向续作"处理剩余工作。该流程展示的是本案例对运行边界的恢复能力,不应等同于第三方独立验收。
06
PART 6 · 调试攻坚

四次调试攻坚:从"能跑"到"能玩"

Worker 自报"完成"不等于可玩。协调者在同系统复核中连续发现 4 个阻塞或高影响问题,每个都有"实测证据→根因→修复→回归验证"闭环。以下 evaluate 输出取自当时返回值,完整记录见 db/session-messages.json

攻坚

从能跑到能结束一局,差的是四次硬修复

小兵堵路、终局僵持、基地贴墙和发光性能问题都曾阻断体验。每次修复都从浏览器状态取证开始,再回到具体代码。

每份调试案卷都按“浏览器观察→状态取证→代码修改→回归结果”展开,冻结素材与最终实现分层标注。

运行记录冻结源码复算或推断窗口外材料
DBG-V01四次调试攻坚总因果图
四次调试攻坚总因果图为什么“能跑”离“能玩”还有很远? 四个高影响问题均有发现、根因、修复和复验链。攻坚 · 调试案卷为什么“能跑”离“能玩”还有很远?事故现场状态取证代码责任回归结果I11问题小兵堵路2运行取证长局≈100兵聚集3根因/符号ai.js路径/分离4修改主体R045回归证据峰值113→46I21问题终局僵持2运行取证1350s水晶不可攻击3根因/符号state.isCrystalI…4修改主体协调者Edit5回归证据水晶可终结I31问题基地贴墙2运行取证英雄无法进基地3根因/符号ai._gateRoute/AS…4修改主体R065回归证据3/3对局终结I41问题发光/FPS2运行取证共享材质污染+DOM压力3根因/符号models/vfx/hud4修改主体R08/R095回归证据6→21–31.8 FPS

数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / I1–I4日志、代码、截图和回归记录|图中结论:四个高影响问题均有发现、根因、修复和复验链

查看来源与复算数据
数据来源
I1–I4日志、代码、截图和回归记录
复算口径
四个高影响问题均有发现、根因、修复和复验链。
图中指标
  • 高影响问题4
  • 专项Worker4
  • 协调者直改1
  • 终局长局3
DBG-V02I1:100个小兵堵在拐角
I1:100个小兵堵在拐角路径、群体碰撞和卡死自救如何共同修复? t=780约100兵聚集,修复后峰值113→46。攻坚 · 调试案卷路径、群体碰撞和卡死自救如何共同修复?事故现场状态取证代码责任回归结果峡谷坐标证据观察点(-80,60)附近出现小兵聚集;图示坐标来自报告冻结状态,不伪造修复前代码。≈100聚集点 (-80,60)最终实现的三层防卡死只展示冻结最终代码:路径点推进、脱离检测、局部分离;修复前源码未冻结。路径推进updateMinion(state, m, dt) → wpIndex / pathcode/src/game/ai.js卡死自救检测位移/计时 → 跳过或重定位路径点code/src/game/ai.js修复前峰值113修复后峰值46

数据: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)

前两个问题发生在规则层;后两个问题分别把路径规划和渲染表现推到浏览器里检验。

DBG-V03I2:22.5分钟终局僵持
I2:22.5分钟终局僵持红方塔已破为何水晶仍满血? 旧规则与实际推进不匹配;协调者修改解防条件并复测。攻坚 · 调试案卷红方塔已破为何水晶仍满血?事故现场状态取证代码责任回归结果观察到的旧行为最终规则证据类型存活防御塔>0水晶无敌水晶无敌/减伤代码符号存活防御塔=0仍可能无敌水晶可选中/可伤害代码符号AI到达基地无有效目标锁定水晶代码符号对局时间=1350s僵持观察终局规则复验长局状态最终水晶无敌判断isCrystalInvuln(crystal) { ... surviving towers ... }code/src/game/state.js:914AI目标过滤if (u.kind === 'crystal' && state.isCrystalInvuln(u))continue;code/src/game/ai.js:28

数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / 协调者evaluate + state.js isCrystalInvuln|图中结论:旧规则与实际推进不匹配

查看来源与复算数据
数据来源
协调者evaluate + state.js isCrystalInvuln
复算口径
旧规则与实际推进不匹配;协调者修改解防条件并复测。
图中指标
  • 观察时间1350s
  • 协调者Edit1
  • 关键函数isCrystalInvuln
  • 最终结果可终结
DBG-V04I3:英雄贴墙进不了基地
I3:英雄贴墙进不了基地基地门径如何进入AI导航? 三门坐标、路由函数和终局强攻模式形成修复链。攻坚 · 调试案卷基地门径如何进入AI导航?事故现场状态取证代码责任回归结果基地门径坐标与路由三门路由把英雄从墙外导向入口,再切换ASSAULT;坐标来自最终ai.js。贴墙英雄3个基地门AI状态与代码责任路径点路由解决几何入口,ASSAULT解决解防后目标优先级。_gateRoute(x,z)计算最近基地门 → 中间路点 → 基地内部目标code/src/game/ai.js:827ASSAULTthis.mode = 'ASSAULT'; → enemyCrystalcode/src/game/ai.js:419–4221观察事实英雄贴墙/基地外徘徊长局浏览器状态2最终实现_gateRoute + ASSAULTai.js3回归R06三局均能终结结果记录

数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / 贴墙坐标 + BASE_GATES + _gateRoute + ASSAULT|图中结论:三门坐标、路由函数和终局强攻模式形成修复链

查看来源与复算数据
数据来源
贴墙坐标 + BASE_GATES + _gateRoute + ASSAULT
复算口径
三门坐标、路由函数和终局强攻模式形成修复链。
图中指标
  • 基地门3
  • 关键函数_gateRoute
  • AI模式ASSAULT
  • 终结对局3/3
DBG-V05I4:共享材质污染与FPS 6
I4:共享材质污染与FPS 6画面故障和性能故障如何被拆成两条根因? 截图证明发光/FPS事故;代码与复测支持壳层和节流修复。攻坚 · 调试案卷画面故障和性能故障如何被拆成两条根因?事故现场状态取证代码责任回归结果事故观察:发光/性能问题 · SHA 014ff5c8ca12最终运行:独立外壳+节流后 · SHA bf7fb809cc12共享材质污染clone/material isolation per heroinstancecode/src/world/models.js独立发光壳层shell mesh + own material lifecyclecode/src/engine/vfx.jsDOM节流HUD/bars update cadence reducedcode/src/ui/hud.js事故窗口6修复后低值21修复后高值31.8

数据: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
DBG-V06四次修复的回归闭环矩阵
四次修复的回归闭环矩阵修完后怎样避免只凭一句“应该好了”? 每项修复都有运行状态、截图或完整对局复验。攻坚 · 调试案卷修完后怎样避免只凭一句“应该好了”?事故现场状态取证代码责任回归结果发现主体状态/日志代码符号修改主体截图长局回归I1 堵路ROOT≈100/113updateMinionR0446峰值I2 僵持ROOT1350sisCrystalInvulnROOT Edit状态可终结I3 贴墙ROOT坐标/模式_gateRouteR063/3I4 发光/FPSR08/ROOT6 FPSmodels/vfx/hudR08/R09前后21–31.81运行事实坐标/状态/FPS/终局结果browser/log2代码责任最终符号可定位frozen source3性能推断相关修复≠严格基准因果boundary

数据:E08 / E09 / E10 / E20 / E21 / E22 / E23 / I1–I4证据 + R06三局 + V01–V12|图中结论:每项修复都有运行状态、截图或完整对局复验

查看来源与复算数据
数据来源
I1–I4证据 + R06三局 + V01–V12
复算口径
每项修复都有运行状态、截图或完整对局复验。
图中指标
  • 问题4
  • 专项Worker4
  • 协调者直改1
  • 证据列6
I1

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、无目标——卡在拐角
I2

终局僵持: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;
  }
I3

英雄攻不进基地:全部贴墙卡死在门外

实测
发现
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) 在红方基地外镜像对峙
I4

亚瑟变"橙色发光团" + 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 后正常进局。这类真实交互差异只有端到端实测才能暴露。

07
PART 7 · 验证体系

验证:全链路验收、43 张截图、5 段录屏映射

最终验收由协调者执行(隔离上下文的同系统 QA Worker 达轮次上限后):选将→进局→操控→死亡→重生→播报→完整对局→结算→再来一局,逐项断言并留证。43 张截图中有 42 份唯一图像内容;5 份录屏原件以 SHA-256 登记,页面播放的是可公开托管的 H.264 派生预览。

窗口外发布前回归(2026-08-09 12:53、13:47、15:22、16:22 +08):在 Codex 内置 Chrome 151、Mac/Apple M1 Pro、1280×720、WebGL 2 环境复验。首次回归中,报告桌面端与 390×844 移动端均无横向溢出,当时的48/48个图片元素加载成功,5/5个H.264预览可解码,搜索及12个底稿折叠项交互正常,控制台无warning/error;游戏选将页为 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帧派生故事板按来源和时间分层;窗口外的最终运行与云端试玩不会倒算进开发统计。

运行记录冻结源码复算或推断窗口外材料
QA-V01可观测游戏验收基础设施
可观测游戏验收基础设施浏览器如何断言一个实时游戏? 启动、错误、状态、倍速和交互钩子支持可重复验收。验收 · 运行画面与终局浏览器如何断言一个实时游戏?运行断言 · 截图 · 录屏 · 终局1本地HTTP服务空闲端口启动2真实浏览器WebGL 2.03window.__game读取实时GameState4window.__errors收集console err…5加速仿真?demo=1 / tim…6evaluate断言标题/单位/终局/HUD启动门禁document.title = 'KING_OK'code/src/main.js运行状态window.__game = { state, engine, hud,... }code/src/main.js错误收集window.__errors.push(error)code/index.html1结构状态单位/塔/水晶/比分/时间window.__game2画面状态截图/WebGL Canvas/HUDWebBrowser3反馈闭环状态断言与可见画面同步复验browser acceptance

数据:E11 / E12 / E13 / E14 / E15 / index.html + window.__game/__errors + 查询参数|图中结论:启动、错误、状态、倍速和交互钩子支持可重复验收

查看来源与复算数据
数据来源
index.html + window.__game/__errors + 查询参数
复算口径
启动、错误、状态、倍速和交互钩子支持可重复验收。
图中指标
  • WebBrowser376fact.browser.calls
  • 下游requestId376
  • 验收编号12
  • 控制台最终窗口错误0
QA-V02G01–G16验收合同覆盖图
G01–G16验收合同覆盖图每项需求是否同时有规范、代码和直接证据? 16项合同均关联规范条目、代码符号和运行证据。验收 · 运行画面与终局每项需求是否同时有规范、代码和直接证据?运行断言 · 截图 · 录屏 · 终局DESIGN原文代码符号V验收E证据媒体状态G01逐字保留src/map.jsV01E31截图/视频全链对应G02逐字保留src/state.jsV02E32代码/日志全链对应G03逐字保留src/ai.jsV03E33代码/日志全链对应G04逐字保留src/skills.jsV04E34截图/视频路径验收G05逐字保留src/hud.jsV05E35代码/日志路径验收G06逐字保留src/map.jsV06E36代码/日志全链对应G07逐字保留src/state.jsV07E37截图/视频全链对应G08逐字保留src/ai.jsV08E38代码/日志全链对应G09逐字保留src/skills.jsV09E31代码/日志全链对应G10逐字保留src/hud.jsV10E32截图/视频路径验收G11逐字保留src/map.jsV11E33代码/日志路径验收G12逐字保留src/state.jsV12E34代码/日志路径验收G13逐字保留src/ai.jsV01E35截图/视频路径验收G14逐字保留src/skills.jsV02E36代码/日志全链对应G15逐字保留src/hud.jsV03E37代码/日志路径验收G16逐字保留src/map.jsV04E38截图/视频全链对应1全链对应指定环境与路径内代码+运行对应G/V/E2路径验收已运行英雄/技能/终局路径acceptance records3下一步英雄×技能×设备组合回归test roadmap

数据:E11 / E12 / E13 / E14 / E15 / G01–G16原表|图中结论:16项合同均关联规范条目、代码符号和运行证据

查看来源与复算数据
数据来源
G01–G16原表
复算口径
16项合同均关联规范条目、代码符号和运行证据。
图中指标
  • 需求条款16
  • 验收步骤12
  • 证据账本43
  • 状态类型3
QA-V03V01–V12端到端验收旅程
V01–V12端到端验收旅程最终验收覆盖了哪些用户可见路径? 启动到重开、离线资源和多英雄回归均有记录。验收 · 运行画面与终局最终验收覆盖了哪些用户可见路径?运行断言 · 截图 · 录屏 · 终局V01启动KING_OK / __er…V02选将5英雄可见V03入局玩家+9 AIV04HUD技能/金币/小地图V05地图三路/塔/水晶V06兵线生成/交战/推进V07野区营地/目标V08战斗伤害/CD/VFXV09长局AI推进V10终局水晶摧毁V11结算胜负界面V12重开状态重置入局与系统检查完成后进入战斗、长局、终局和重开V01–V12是一条状态旅程,不是12张孤立截图启动→选择→对局→战斗→终局→重开;每一步保留对应代码、截图或日志入口。1结构断言window.__game与DOM状态evaluate2视觉证据WebGL Canvas/HUD截图screenshots3观察窗口启动→对局→终局→重开全程记录browser verification

数据:E11 / E12 / E13 / E14 / E15 / 协调者最终验收消息 + 浏览器断言|图中结论:启动到重开、离线资源和多英雄回归均有记录

查看来源与复算数据
数据来源
协调者最终验收消息 + 浏览器断言
复算口径
启动到重开、离线资源和多英雄回归均有记录。
图中指标
  • 验收步骤12
  • 状态阶段6
  • 英雄选项5
  • 运行英雄10

接下来把三局终局、43张截图和5份录屏放回对应验收路径,直接看代码如何变成可见体验。

QA-V04五英雄与15项主动技能覆盖图
五英雄与15项主动技能覆盖图英雄差异是否只是改名? 五种定位、15技能和六种aim语义存在于冻结代码。验收 · 运行画面与终局英雄差异是否只是改名?运行断言 · 截图 · 录屏 · 终局Q / S1E / S2R / ULTaim覆盖亚瑟 · 战士誓约之盾self回旋打击around圣剑裁决targetself/around/target后羿 · 射手炙热之风self燎原箭雨area灼日之矢lineself/area/line妲己 · 法师灵魂冲击line偶像魅力target女王崇拜aroundline/target/around牛魔 · 坦克咆哮之斧around横行霸道dash山崩地裂aroundaround/dash兰陵王 · 刺客秘技·分身self秘技·影蚀target秘技·暗袭targetself/target1代码事实5英雄×3主动技能=15skills.js2aim模式self/around/target/area/line/…skill defs3运行覆盖选择与回归路径见QA记录QA scope

数据:E11 / E12 / E13 / E14 / E15 / skills.js + models.js + 选将/回归证据|图中结论:五种定位、15技能和六种aim语义存在于冻结代码

查看来源与复算数据
数据来源
skills.js + models.js + 选将/回归证据
复算口径
五种定位、15技能和六种aim语义存在于冻结代码。
图中指标
  • 英雄5
  • 主动技能15
  • aim模式6
  • 逐项穷举0
QA-V05R06三局回归小多图
R06三局回归小多图门径修复后比赛能否结束? 三局均出现胜方、水晶击杀者且错误为0。验收 · 运行画面与终局门径修复后比赛能否结束?运行断言 · 截图 · 录屏 · 终局Game 1红方获胜水晶摧毁/结算R06 回归记录 · 样本1局Game 2红方获胜水晶摧毁/结算R06 回归记录 · 样本1局Game 3红方获胜水晶摧毁/结算R06 回归记录 · 样本1局三局终局回归:红方3/3获胜本轮目标是验证水晶、结算和重开链路;阵营与英雄平衡留给随机种子、阵营互换和大样本专项测试。1已经跑通三局均进入水晶与结算路径R06 run record2本轮观察三局结果均为红方获胜run outcomes3下一项测试随机种子×阵营互换×大样本balance test plan

数据:E11 / E12 / E13 / E14 / E15 / R06回归日志|图中结论:三局均出现胜方、水晶击杀者且错误为0

查看来源与复算数据
数据来源
R06回归日志
复算口径
三局均出现胜方、水晶击杀者且错误为0。
图中指标
  • 对局样本3
  • 红方胜3
  • 蓝方胜0
  • 平衡结论
QA-V0643张截图的全量时间胶片
43张截图的全量时间胶片画面如何从空峡谷演进为完整交战? 43个文件/42份唯一内容逐张呈现,并标明序号、时间锚点、执行角色和阶段。验收 · 运行画面与终局画面如何从空峡谷演进为完整交战?运行断言 · 截图 · 录屏 · 终局01 · 9ace684e · DUP02 · 520b128d03 · 3e27d35a04 · eb77dcc305 · d649635e06 · 765f9b0b07 · 86abc79908 · 753a869009 · b2043a9610 · 97ba226d11 · 0bd74cfc12 · a76c0e9f13 · dd90687c14 · cdefd9f315 · 42a4cfe416 · 014ff5c817 · e0bc923618 · 9e382edb19 · 4a0e157220 · 859177a221 · 588701d822 · cfd52ddd23 · a11244f324 · 3b96e9f425 · 26e6dcbe26 · b69746ab27 · 6d725df128 · 43ceca8b29 · f1aa019c30 · a6fa8cf431 · 0b44431c32 · fe1ee96533 · bf7fb80934 · 3f317e8135 · b0494d7236 · 0ad8494d37 · 74e5521f38 · b182447139 · 28ef594d40 · 12321ef741 · f6e4a5de42 · 815a9c2343 · 9ace684e · DUP1文件数43张全部可见screenshots/2唯一内容42份;1对完全重复SHA-256 grouping3时间定位日志、Run和媒体记录组合定位timestampBasis

数据:E11 / E12 / E13 / E14 / E15 / screenshots目录 + 报告原始图注 + SHA-256|图中结论:43个文件/42份唯一内容逐张呈现,并标明序号、时间锚点、执行角色和阶段

查看来源与复算数据
数据来源
screenshots目录 + 报告原始图注 + SHA-256
复算口径
43个文件/42份唯一内容逐张呈现,并标明序号、时间锚点、执行角色和阶段。
图中指标
  • 截图文件43fact.media.screenshots
  • 唯一图像42fact.media.uniqueScreenshots
  • 原视频5
  • 派生帧20
QA-V0743文件/42内容的哈希关系
43文件/42内容的哈希关系重复截图是否被冒充成两份独立证据? 唯一重复对已明确披露,其余42份内容哈希不同。验收 · 运行画面与终局重复截图是否被冒充成两份独立证据?运行断言 · 截图 · 录屏 · 终局43个文件 → 42份唯一图像内容每个圆点代表一个文件SHA;唯一文件各自连到独立内容节点,重复的一对汇入同一SHA节点。1234567891011121314151617181920212223242526272829303132333435唯一重复组 · 两个路径共享完全相同SHA-2569ace684e4575e292402a35cde95a5a19screenshots/screenshot_subagent-agent-1c86cd96_1786214519805.png9ace684e4575e292screenshots/phase2-combat/1_minion_clash.png9ace684e4575e292同一内容节点1内容分组43个文件对应42份唯一图像SHA grouping2重复文件保留反映两个真实存档来源asset provenance3可追踪关系文件名、SHA与所属阶段完整登记screenshot manifest

数据:E11 / E12 / E13 / E14 / E15 / 截图SHA-256清单|图中结论:唯一重复对已明确披露,其余42份内容哈希不同

查看来源与复算数据
数据来源
截图SHA-256清单
复算口径
唯一重复对已明确披露,其余42份内容哈希不同。
图中指标
  • 截图文件43fact.media.screenshots
  • 唯一内容42fact.media.uniqueScreenshots
  • 重复组1
  • 重复文件2

媒体补足了静态代码看不到的体验,录制时间与派生关系也在同一图中对齐。

QA-V08五份原视频与预览映射
五份原视频与预览映射原件、派生预览和窗口分类如何对应? 每个预览都能追到原件、速度、编码、大小和SHA。验收 · 运行画面与终局原件、派生预览和窗口分类如何对应?运行断言 · 截图 · 录屏 · 终局101-开发过程-4x.mp4SHA 892f7f5dfdb1 → b25e6373212b原片 66.72MiB · 418.1s · hevc预览 2.1MiB · ×4 · h264DEVELOPMENT_WINDOW202-玩法开发-2x.mp4SHA 832097e80aa3 → ca16651dba81原片 65.89MiB · 279.3s · hevc预览 5.01MiB · ×2 · h264DEVELOPMENT_WINDOW303-视觉修复-1x.mp4SHA 9c914b654bc4 → 06cc772589d4原片 13.16MiB · 119.9s · hevc预览 1.2MiB · ×1 · h264DEVELOPMENT_WINDOW404-最终运行-4x.mp4SHA 63fa7c8b1d12 → b39746b77e7c原片 144.2MiB · 608.7s · hevc预览 7.31MiB · ×4 · h264OUTSIDE_DEVELOPMENT_WINDOW_FINAL_RUN_SUPPLEMENT505-阿里云在线试玩-2x.mp4SHA 6d5aef9c2400 → 21612bdf0d09原片 102.33MiB · 207.1s · hevc预览 7.68MiB · ×2 · h264OUTSIDE_DEVELOPMENT_WINDOW_CLOUD_DEPLOYMENT_SUPPLEMENT1金条原片字节/最大原片比例ffprobe+stat2青条H.264预览字节/同一比例尺preview metadata3派生关系每份预览均连接原片、倍速、编码与SHArelease-assets

数据:E11 / E12 / E13 / E14 / E15 / release-assets.json|图中结论:每个预览都能追到原件、速度、编码、大小和SHA

查看来源与复算数据
数据来源
release-assets.json
复算口径
每个预览都能追到原件、速度、编码、大小和SHA。
图中指标
  • 原视频5
  • 预览5
  • HEVC原片5
  • H.264预览5
QA-V09五份录屏的20帧派生故事板
五份录屏的20帧派生故事板不播放视频时能否快速理解录像内容? 五份视频各按15/38/62/85%抽取四帧,20帧全部可见并登记时间码、倍速与SHA-256。验收 · 运行画面与终局不播放视频时能否快速理解录像内容?运行断言 · 截图 · 录屏 · 终局15% · 15.7s · 原≈62.7s38% · 39.7s · 原≈158.9s62% · 64.8s · 原≈259.2s85% · 88.9s · 原≈355.4s15% · 20.9s · 原≈41.9s38% · 53.1s · 原≈106.1s62% · 86.6s · 原≈173.1s85% · 118.7s · 原≈237.4s15% · 18s · 原≈18s38% · 45.6s · 原≈45.6s62% · 74.3s · 原≈74.3s85% · 101.9s · 原≈101.9s15% · 22.8s · 原≈91.3s38% · 57.8s · 原≈231.3s62% · 94.3s · 原≈377.4s85% · 129.3s · 原≈517.4s15% · 15.5s · 原≈31.1s38% · 39.4s · 原≈78.7s62% · 64.2s · 原≈128.4s85% · 88s · 原≈176.1s1 · 01-开发过程-4x.mp42 · 02-玩法开发-2x.mp43 · 03-视觉修复-1x.mp44 · 04-最终运行-4x.mp45 · 05-阿里云在线试玩-2x.mp4

数据: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
  • 时间码口径预览+原片近似
QA-V10本地开发、最终运行与云端验证分层
本地开发、最终运行与云端验证分层开发窗口、本地最终运行与阿里云部署验证如何分层? 开发窗口与两份窗口外运行补充按时间和用途清楚分层。验收 · 运行画面与终局开发窗口、本地最终运行与阿里云部署验证如何分层?运行断言 · 截图 · 录屏 · 终局开发窗口内01:30–07:01本地开发 / 浏览器验收 / 日志 / 账单INCLUDED · 5h31m evidence window最终运行补充09:21最终运行版录屏OUTSIDE WINDOW · LOCAL阿里云 HTTPS · 最终产物可在线运行11:53 录屏 + 当前在线复验1标准试玩5名英雄选将 → 锁定 → 手动操作https://king.zhikun.xin/2自动演示跳过选将 → 亚瑟脚本自动运行https://king.zhikun.xin/?demo=1OUTSIDE WINDOW · SAME BUILD + demo=11唯一统计层01:30≤time<07:01provenance.developmentWindow2标准试玩选将→手动操作onlineDeployment.standard3自动演示跳过选将→脚本运行onlineDeployment.demo

数据:E11 / E12 / E13 / E14 / E15 / 视频分类 + browser-verification.json|图中结论:开发窗口与两份窗口外运行补充按时间和用途清楚分层

查看来源与复算数据
数据来源
视频分类 + browser-verification.json
复算口径
开发窗口与两份窗口外运行补充按时间和用途清楚分层。
图中指标
  • 统计层1
  • 窗口外运行层2
  • 开发日志行38,641fact.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 相机 rigV12 资源全 localhost;R01 截图通过
G02完整三路王者峡谷Q3 选择;DESIGN 地图节world/map.js(840 行)+ config.js MAP/路径点/塔位R01 六图:河道/塔/草丛/基地/龙坑通过
G035 英雄 × 3 技能 + 被动DESIGN 英雄池数值skills.js(485 行);models.js HERO_STYLE:460/createHumanoid:90选将界面技能文案;V11 四英雄回归通过
G04三路兵波次/炮车DESIGN 小兵数值spawner.js:88 spawnWavet=67s 蓝 22 vs 红 20 实测通过
G05防御塔 T1→T3 顺序无敌DESIGN 防御塔节state.js:905 isTowerInvuln9 塔被毁实测 + 终局塔数统计通过
G06水晶解防/摧毁=胜利DESIGN 水晶节(I2 修订)state.js:914 isCrystalInvuln(协调者直改)3/3 局分出胜负 + winner 字段修复后通过
G07英雄 AI 状态机DESIGN AI 节ai.js(920 行;ASSAULT:422/_gateRoute:827终局 AI 模式分布实测通过
G08野区/暴君/主宰/BUFFDESIGN 野怪节spawner.js 刷新 + ai.js 打龙时机R06 回归:野营被清 3/10、打野发育领先通过
G09虚拟摇杆+技能按钮操控Q4 选择;DESIGN UI 节input.js:30 pointerdown / :118 getMoveVectorV02 进局操控实测通过
G10装备商店/一键推荐DESIGN 装备节shop.js:80 buy / :95 buyRecommendedV04:面板弹出 itemCount=12通过
G11小地图DESIGN UI 节minimap.js:17 class MinimapHUD 截图(单位点/塔标/相机框)通过
G12击杀播报/横幅/TTSDESIGN UI 节screens.js:247 _bannerCount++V07:bannerCount 1→3 递增通过
G13死亡/重生/回城DESIGN 数值节state.js:932 tryRecall / :943 tryFlashV06:deaths=1 → 泉水复活通过
G14结算界面/再来一局DESIGN UI 节screens.js:372 showResultV09/V10:字段 JSON + 重开实测通过
G15选将界面 5 选 1Q1-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 锁定 → 进局玩家确为亚瑟通过
V03HUD小地图单位点/比分/计时/金币齐备;技能 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
终局时间比分(蓝:红)胜方水晶击杀者报错
118:47(1,127s)10:9英雄·亚瑟0
213:47(827s)17:8英雄·后羿0
313:53(833s)6:10英雄·兰陵王0

均为 ?demo=1&hero=arthur&speed=8 自动演示局(玩家由演示脚本操控)。三次回归加一次最终验收均为红方获胜;这4局用于验证水晶、结算和重开路径。阵营平衡将在对称控制、更多随机种子与显著性分析中单独评估。

7.2b 视觉演进三联对照(同场景,三时期) 实测

7.3 截图证据全量画廊(43 个文件 / 42 份唯一图像内容) 实测 日志

图注口径:协调者亲自截取并目检的标 实测;worker 自验存档的标 日志 并如实注明“未逐帧目检”。文件名 epoch 只作为本地元数据换算时刻,不是受信任时间戳。phase2-combat/1_minion_clash.pngscreenshot_subagent-agent-1c86cd96_1786214519805.png 的 SHA-256 相同,明确计作一份内容的两个存档位置。

R01 地基与 3D 地图(worker 按 DESIGN.md 验证标准存档)(6 张)

R02 战斗核心(worker 自验原始存档,1 张)

R02 战斗核心(重复存档披露,1 张)

协调者同系统复核(逐张经协调者目检)(6 张)

R07 UI 阶段(worker 自验)(8 张)

R06 门径修复验证(含英雄攻击水晶)(2 张)

R08 视觉打磨(worker 自验)(7 张)

R09 发光修复与性能验证(worker 自验)(9 张)

R10 隔离上下文的同系统 QA(worker 自验)(3 张)

7.4 过程与部署录屏(5 份原件映射 + 5 份派生预览) 实测

预览 1 · 开发窗口内 · 4× 加速 · H.264 960×540 | 原件 01:31:11 / 418.085s / SHA-256 892f7f5dfdb1fffd…;按录制时刻与会话起始重合关系归类,阶段归属为推断。
预览 2 · 开发窗口内 · 2× 加速 · H.264/AAC 960×540 | 原件 05:43:10 / 279.277s / SHA-256 832097e80aa3af06…;阶段归属为推断。
预览 3 · 开发窗口内 · 原速压缩 · H.264/AAC 960×540 | 原件 06:09:09 / 119.910s / SHA-256 9c914b654bc4d77f…;阶段归属为推断。
预览 4 · 窗口外最终运行补充 · 4× 加速 · H.264 960×540 | 原件 09:21:55 / 608.717s / SHA-256 63fa7c8b1d12cee9…,不得计入 01:30–07:01 开发证据。
预览 5 · 窗口外阿里云部署验证补充 · 2× 加速 · H.264/AAC 960×540 | 原件 11:53:36 / 207.127s / SHA-256 6d5aef9c…65c388,作为11:53的窗口外在线部署验证,与开发窗口材料分层记录。

页面视频均为派生预览,经过加速、缩放、压缩和改名,不能与原件做字节级等同。五份 HEVC 原件保持不变,完整路径、时长、编码、大小、SHA-256 与未来 Release URL 见 release-assets.json;当前 Release URL 为空,表示尚未在用户人工确认前发布。录屏未做逐帧事实标注,画面内容应与日志/代码证据分开评价。

08
PART 8 · 工程审计

把 Token、日志、数据库和哈希摊开

账单 CSV、运行时观测与会话数据库从不同记录面描述同一过程,适合做逐项一致性检查。账单是提供方导出,运行日志与数据库则同属本地系统;三者均未附第三方可信时间戳或密码学签名。因此这里证明的是“公开材料相互一致且可复算”,不是“任一来源不可能被伪造”。

复核

把规模写成数字不难,把每个数字对回原记录才难

账单、运行事件、数据库、公开日志、代码、图片和视频分别回答不同问题。报告只在这些证据交叉处下结论。

公开审计层保留原表、原命令和完整口径。正文图表负责解释关系,读者需要时再下钻到原始记录。

运行记录冻结源码复算或推断窗口外材料
AUDIT-V01账单、运行事件、失败事件与消息的请求级对账
账单、运行事件、失败事件与消息的请求级对账账单、运行事件和消息为何数字不同? 873个完成请求Token元组逐条匹配;各口径用途和粒度不同。复核 · 证据账本账单、运行事件和消息为何数字不同?原始记录标识符关联统计复算工程结论三种记录口径并排对账,不把不同单位画成守恒流账单与completed事件可按Token元组逐条匹配;failed事件和根会话messages分别属于不同记录口径。账单CSV请求877提供方记录逐条Token元组匹配873input/output完全对应账单侧差异4四条窗口内记录运行completed87311个Run完成事件运行failed5cancelled终态根会话messages229公开消息记录873匹配逐项一致记录域边界:229条messages不参与请求数守恒唯一可以直接逐项连接的关系877条账单中873条与873个completed事件的输入/输出Token元组一致;其余口径只做并列说明。

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / CSV + observability + messages|图中结论:873个完成请求Token元组逐条匹配

查看来源与复算数据
数据来源
CSV + observability + messages
复算口径
873个完成请求Token元组逐条匹配;各口径用途和粒度不同。
图中指标
  • 账单请求877fact.bill.requests
  • 逐条匹配873fact.llm.completed
  • 账单侧差异4
  • failed事件5fact.llm.failed
AUDIT-V02逐小时Token与阶段叠加
逐小时Token与阶段叠加投入在哪些阶段增长最快? 877请求可按小时聚合并与阶段时间轴对齐。复核 · 证据账本投入在哪些阶段增长最快?原始记录标识符关联统计复算工程结论逐小时账单:请求、输入、缓存、输出每个小时使用同一Token比例尺;缓存为输入Token的子集,输出单独标注。01:0034 req · in 1.74Mcache 1.58M · out 61,24802:00119 req · in 8.61Mcache 8.3M · out 136,45903:00123 req · in 11.25Mcache 10.85M · out 106,42404:00137 req · in 12.89Mcache 12.55M · out 110,39305:00191 req · in 21.44Mcache 20.57M · out 155,57906:00269 req · in 26.6Mcache 26.24M · out 102,62907:004 req · in 0.37Mcache 0.37M · out 1,2061蓝色每小时输入Tokenprovider CSV2青色每小时Cached Tokensprovider CSV3计费口径公开Token量,费率由读者按当时价格换算provider CSV

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / request_log_part_0001.csv|图中结论:877请求可按小时聚合并与阶段时间轴对齐

查看来源与复算数据
数据来源
request_log_part_0001.csv
复算口径
877请求可按小时聚合并与阶段时间轴对齐。
图中指标
  • 账单请求877fact.bill.requests
  • 输入Token82,906,205fact.bill.inputTokens
  • 缓存Token80,468,224fact.bill.cachedTokens
  • 输出Token673,938
AUDIT-V03缓存命中与上下文增长
缓存命中与上下文增长97.059%缓存比例如何形成? 总输入、缓存和非缓存可直接复算,小时采样透明。复核 · 证据账本97.059%缓存比例如何形成?原始记录标识符关联统计复算工程结论877请求缓存比例曲线横轴为按时间升序的账单记录;曲线使用全部877行。1007550250单请求缓存率%请求序号 1→877缓存率%同序列输入上下文规模下图只画输入Token;与缓存率分开比例,避免双轴误读。263,829197,872131,91565,9570输入Token请求序号 1→877输入Token1147293439585731877

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 账单CSV cached_tokens|图中结论:总输入、缓存和非缓存可直接复算,小时采样透明

查看来源与复算数据
数据来源
账单CSV cached_tokens
复算口径
总输入、缓存和非缓存可直接复算,小时采样透明。
图中指标
  • 总体缓存率97.059%fact.bill.cachePercent
  • 非缓存输入2,437,981
  • 请求877fact.bill.requests
  • 金额推算不做

Token和缓存只能说明调用规模。工具生命周期、日志合并和数据库关系才解释这些数字怎样形成。

AUDIT-V04968次工具调用Treemap
968次工具调用Treemap真实工程操作集中在哪些能力? 13类工具分布可由日志按复合键去重。复核 · 证据账本真实工程操作集中在哪些能力?原始记录标识符关联统计复算工程结论13类工具调用排名 · 全部类别使用同一比例尺条长严格等于调用数/376;所有13类均直接显示名称、计数和占968次调用的比例。WebBrowser37638.84%Edit18519.11%Read16216.74%Bash10210.54%Sleep616.3%Write373.82%Grep202.07%TodoWrite111.14%Agent101.03%AskUserQuestion10.1%Glob10.1%CodeIntel10.1%Snip10.1%1最大类别WebBrowser 376次38.84% of 9682代码修改Edit 185 / Write 37tool distribution3工作结构观察、编辑、读取与命令执行共同推进tool distribution

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 复合键工具统计|图中结论:13类工具分布可由日志按复合键去重

查看来源与复算数据
数据来源
复合键工具统计
复算口径
13类工具分布可由日志按复合键去重。
图中指标
  • 工具调用968fact.tools.total
  • 工具类别13
  • WebBrowser376fact.tool.WebBrowser
  • 裸序号422
AUDIT-V05工具生命周期与17次错误
工具生命周期与17次错误错误是否被“成功故事”隐藏? 每次调用均有验证、实际调用和完成;17次error=true分类公开。复核 · 证据账本错误是否被“成功故事”隐藏?原始记录标识符关联统计复算工程结论复合工具键 · 968Stage1 · 968Stage5 · 968error=false · 951error=true · 17Edit · 6WebBrowser · 5Agent · 3CodeIntel · 1Bash · 21完整生命周期968/968/968;缺失或重复=0public log composite key2错误透明17条结构化错误拆到5类工具completed error=true3后续读取完成记录进入后续Agent Loop继续处理subsequent activity

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / ToolExecutionPipeline冻结日志|图中结论:每次调用均有验证、实际调用和完成

查看来源与复算数据
数据来源
ToolExecutionPipeline冻结日志
复算口径
每次调用均有验证、实际调用和完成;17次error=true分类公开。
图中指标
  • Stage1968
  • Stage5968
  • error=false951fact.tools.success
  • error=true17fact.tools.error
AUDIT-V06两份应用日志的合并与最小脱敏
两份应用日志的合并与最小脱敏公开日志为什么完整又可关联? 30,948+7,678块顺序合并,38,641行;技术ID保留。复核 · 证据账本公开日志为什么完整又可关联?原始记录标识符关联统计复算工程结论轮转gzip30,94830954行 · 01:30:01.516→06…已捕获续段gzip7,6787687行 · 06:19:29.725→07:…完整时间块过滤+顺序拼接38,626不去重;同毫秒不同事件全部保留最小脱敏1,356HOME路径替换;技术关联ID保留公开合并日志38,641SHA ba3220722af426d91边界事件06:19:29.725有5个不同块merge provenance2路径替换1,356处;不记录原值redaction report3秘密扫描高置信度命中0postScan

数据: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,626fact.logs.blocks
  • 物理行38,641fact.logs.lines
AUDIT-V075小时31分日志密度与静默间隔
5小时31分日志密度与静默间隔日志是否在窗口中间出现断层? 首末时间、每分钟密度和最大37.890秒无日志间隔可复算。复核 · 证据账本日志是否在窗口中间出现断层?原始记录标识符关联统计复算工程结论331分钟日志密度+组件活动每格为有时间块的分钟;亮度按时间块数/该窗口最大值,描边颜色标出主要组件。01:30 1201:31 3301:32 7501:33 1201:34 6001:35 5001:36 1201:37 1301:38 1201:39 8901:40 13101:41 1201:42 1201:43 1201:44 1201:45 1401:46 3001:47 6001:48 6201:49 4701:50 1201:51 6701:52 4601:53 4201:54 11901:55 30301:56 8301:57 29701:58 15201:59 22302:00 9702:01 3002:02 31702:03 20802:04 23602:05 18802:06 15102:07 15402:08 24002:09 22402:10 25002:11 5602:12 54702:13 3302:14 1202:15 1202:16 1202:17 1202:18 1502:19 3002:20 1202:21 1202:22 1202:23 1202:24 3202:25 8402:26 12202:27 15102:28 602:29 2102:30 2402:31 5502:32 4502:33 5602:34 11902:35 9602:36 10102:37 5602:38 11902:39 2002:40 7802:41 17502:42 20602:43 17802:44 6502:45 2502:46 15202:47 18702:48 32302:49 1902:50 602:51 2102:52 9102:53 11102:54 4402:55 1902:56 602:57 7302:58 602:59 1903:00 603:01 1903:02 803:03 10803:04 19603:05 13303:06 15803:07 25103:08 17903:09 13003:10 12703:11 10103:12 10903:13 8803:14 5903:15 13103:16 10603:17 19303:18 4803:19 10503:20 3803:21 13403:22 21803:23 803:24 7003:25 2403:26 1903:27 603:28 1903:29 603:30 14703:31 23403:32 20003:33 12603:34 10203:35 2703:36 8703:37 4303:38 17003:39 5803:40 8603:41 9403:42 6803:43 2403:44 10403:45 603:46 7803:47 9103:48 8803:49 603:50 8703:51 9003:52 12603:53 603:54 8503:55 8103:56 7103:57 2103:58 12803:59 23204:00 904:01 1904:02 604:03 3904:04 15704:05 12304:06 10704:07 5604:08 804:09 15704:10 604:11 1904:12 604:13 20504:14 21704:15 17204:16 15704:17 16004:18 12904:19 15604:20 9104:21 13604:22 604:23 5504:24 4304:25 18404:26 9304:27 8604:28 7404:29 18104:30 804:31 3904:32 9104:33 1704:34 7204:35 20304:36 1604:37 2804:38 1704:39 2704:40 8804:41 30504:42 2704:43 1704:44 804:45 13004:46 19404:47 12204:48 6004:49 5104:50 804:51 28504:52 26504:53 20704:54 11104:55 15704:56 21604:57 10704:58 2404:59 20305:00 2305:01 5105:02 6605:03 13605:04 15005:05 27305:06 8105:07 34205:08 14105:09 1805:10 2605:11 5405:12 15405:13 33905:14 4705:15 3605:16 4505:17 13005:18 6605:19 1805:20 10205:21 7505:22 15905:23 33005:24 35205:25 24605:26 22105:27 18405:28 25305:29 23805:30 27205:31 21805:32 20205:33 1205:34 6305:35 32005:36 26705:37 32805:38 27005:39 12805:40 1205:41 1205:42 8205:43 15705:44 1405:45 1205:46 1205:47 4905:48 7005:49 20805:50 1205:51 1205:52 4905:53 20305:54 6705:55 16605:56 16305:57 20105:58 28105:59 22806:00 21706:01 18506:02 25506:03 8506:04 15206:05 20306:06 11906:07 18506:08 11206:09 14106:10 32706:11 14806:12 11406:13 8406:14 13906:15 6306:16 13506:17 6106:18 27906:19 24106:20 5106:21 14706:22 29306:23 16706:24 21906:25 25306:26 22106:27 25806:28 13306:29 15406:30 18906:31 23906:32 19106:33 19306:34 34006:35 24306:36 25206:37 26306:38 16406:39 8706:40 23206:41 20406:42 23206:43 29806:44 9306:45 6806:46 23706:47 17306:48 23306:49 8606:50 5806:51 17506:52 24506:53 17006:54 23306:55 14906:56 1906:57 606:58 12306:59 26607:00 1681首末01:30:01.516→07:00:41.483public log2最大静默37.890秒timestamp diff3活动密度331个分钟格展示记录强度与组件分布public log

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 公开合并日志逐分钟聚合|图中结论:首末时间、每分钟密度和最大37.890秒无日志间隔可复算

查看来源与复算数据
数据来源
公开合并日志逐分钟聚合
复算口径
首末时间、每分钟密度和最大37.890秒无日志间隔可复算。
图中指标
  • 窗口分钟331
  • 时间块38,626fact.logs.blocks
  • 最大静默37.890s
  • 组件带8
AUDIT-V08四份数据库导出的冻结关系
四份数据库导出的冻结关系动态数据库如何变成不可变窗口证据? sessionId和时间窗口双重限定后导出行数可复算。复核 · 证据账本动态数据库如何变成不可变窗口证据?原始记录标识符关联统计复算工程结论session-row.json1b8f86099-452d-4ba601messages.json229session_id+created_at窗口02activities…json113timestamp毫秒窗口03interaction…json44项需求确认消息/交互查询session_id=:root AND created_at>=start AND created_at<endprovenance.json活动查询timestamp>=unixepoch(start)*1000 ANDtimestamp<unixepoch(end)*1000provenance.json

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / db/*.json + provenance查询|图中结论:sessionId和时间窗口双重限定后导出行数可复算

查看来源与复算数据
数据来源
db/*.json + provenance查询
复算口径
sessionId和时间窗口双重限定后导出行数可复算。
图中指标
  • 导出文件4
  • messages229
  • activities113
  • 窗口内interactions4

最后把七个证据域放在一起,检查哪些结论由多种格式共同约束,哪些仍停留在本地信任域。

AUDIT-V09七类证据域交叉图
七类证据域交叉图哪些核心主张有不止一种材料支持? 产物、过程、成本和终态由不同材料交叉约束。复核 · 证据账本哪些核心主张有不止一种材料支持?原始记录标识符关联统计复算工程结论核心主张产物/过程/成本/终态代码21 files应用日志38,641行观测事件2,003行数据库4 exports账单877 rows截图43/42视频5原片+5预览浏览器376调用1交叉复核同一结论由不同格式与链路对照evidence ledger2外部口径提供方账单与浏览器运行记录bill/browser3本地证据链日志、数据库、代码与媒体相互定位local evidence graph

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 代码/日志/DB/账单/截图/视频/浏览器验收|图中结论:产物、过程、成本和终态由不同材料交叉约束

查看来源与复算数据
数据来源
代码/日志/DB/账单/截图/视频/浏览器验收
复算口径
产物、过程、成本和终态由不同材料交叉约束。
图中指标
  • 证据域8
  • 日志+事件40,644
  • 媒体文件53
  • 第三方可信时间戳0
AUDIT-V10E01–E42证据网络
E01–E42证据网络42条证据如何支撑过程、产物和工程结论? 42条案例证据分别连接来源、位置与核验方式。复核 · 证据账本42条证据如何支撑过程、产物和工程结论?原始记录标识符关联统计复算工程结论时间/需求E01–E06E1E2E3E4E5E6Worker/运行E07–E15E7E8E9E10E11E12E13E14E15账单/工具E16–E23E16E17E18E19E20E21E22E23平台机制E24–E30E24E25E26E27E28E29E30产品复杂度E31–E38E31E32E33E34E35E36E37E38执行追溯E39–E42E39E40E41E42主张—来源—核验—结论所有E01–E42汇入可复算核心矩阵

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 证据账本E01–E42|图中结论:42条案例证据分别连接来源、位置与核验方式

查看来源与复算数据
数据来源
证据账本E01–E42
复算口径
42条案例证据分别连接来源、位置与核验方式。
图中指标
  • 证据编号42
  • 证据分域6
  • 来源类型8
  • 复算矩阵1
AUDIT-V11二十条核心结论与最强证据
二十条核心结论与最强证据如何防止可视化把事实画得过头? 二十条核心结论分别连接最强证据和可确认结果。复核 · 证据账本如何防止可视化把事实画得过头?原始记录标识符关联统计复算工程结论核心主张最强证据可确认结论5:29:17跨度5:29:17跨度日志/账单/DB首末请求锚点精确对应可玩原型可玩原型代码+截图+视频指定路径完成真实运行17模块耦合17模块耦合39条导入边形成跨系统运行图10次Worker10次Worker11个session/run父子执行链可逐次重建376浏览器调用376浏览器调用复合键+PythonID运行反馈持续进入开发闭环878次模型请求878次模型请求started/terminal每个请求都有唯一终态968次工具调用968次工具调用三段生命周期验证、执行和完成记录闭合故障接续故障接续5+17+6+3局部故障后项目继续推进873条账单匹配873条账单匹配Token元组逐条运行事件与账单精确对应最终验收最终验收V01–V12选将、对局、终局和重开走云端试玩云端试玩11:53录屏HTTPS部署后可在线访缓存97.059%缓存97.059%账单CSV缓存Token比例可逐条复算原子写入267原子写入267应用日志持续保护落盘产物Checkpoint 157Checkpoint157应用日志长任务持续生成恢复点MCP重连60组MCP重连60组顺序配对每次断线都有成功重连上下文评估878次上下文评估878次ContextCascade每轮调用前持续治理上下文代码副本一致代码副本一致逐文件SHA证据代码与最终项目一致43/42截图43/42截图SHA分组重复关系完整公开5份视频5份视频原片/预览哈希原片与派生预览一一映射平台能力平台能力本案+源码旁证展示复杂长任务工程能力

数据:E04 / E05 / E06 / E17 / E29 / E40 / E41 / E42 / 核心主张与证据对应表|图中结论:二十条核心结论分别连接最强证据和可确认结果

查看来源与复算数据
数据来源
核心主张与证据对应表
复算口径
二十条核心结论分别连接最强证据和可确认结果。
图中指标
  • 核心主张20
  • 最强证据列1
  • 可确认结论列1
  • 公开证据编号42
AUDIT-V12私有源重建与公开复算的双路径验证
私有源重建与公开复算的双路径验证第三方如何在干净检出中复算? 公开证据可完成统计、引用、SVG、媒体、密钥和哈希验证。复核 · 证据账本第三方如何在干净检出中复算?原始记录标识符关联统计复算工程结论私有源完整重建模式源日志存在时,从字节冻结开始重跑过滤、顺序合并、脱敏、统计与公开哈希。1两段捕获日志rotated gzi…2时间块过滤01:30≤time<…3最小脱敏技术ID保留4公开日志38,641行GitHub公开复算模式只依赖公开证据:代码/日志/JSON/CSV/媒体哈希;不需要访问私有路径。1公开证据code/log/db…2统计复算schema v73引用/符号HTML/SVG检查4SHA清单全覆盖公开派生物交汇1共同终点秘密扫描/HTML哈希/SHA256SUMSverify-king-case.mjs2私有源模式源日志到公开派生全过程重建source logs present3公开复算模式依靠仓库内证据重现关键统计public evidence

数据: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.csv877 请求(全部落在窗口内)82,906,205673,938含 Cached Tokens 80,468,224(缓存命中率 97.1%);kimi-k3 / moonshot
运行时口径logs/observability-events-…jsonl878 started / 873 completed / 5 failed82,300,554670,170873 个 completed 的 input/output token 元组与账单中的 873 行逐条精确匹配
消息口径db/session-messages.json229 条(窗口内)7,386,86858,959assistant 消息粒度:input 为当轮全量上下文(历史重复计入);与观测日志中协调者 run 的合计逐数字一致(见 PART 4.2)
最强的跨记录面对账:运行时 873 条 completed 与账单 873 行的 input/output token 元组逐条一致。账单另外 4 行合计 605,651 输入 / 3,768 输出,时刻为 02:09:59、03:17:41、03:52:34、06:08:41,均靠近 Worker 期限结束点。时间关联可以支持“可能与期限回收有关”的推断,但现有素材不足以证明因果。
费用口径声明:账单 CSV 不含单价、缓存折扣或当时计费规则,本报告不估算金额或“等价处理量”。可复算事实仅为:输入 82,906,205、输出 673,938、缓存 80,468,224、非缓存 2,437,981、缓存占输入 97.059%。缓存为何形成属于机制解释,不是该 CSV 能独立证明的事实。

8.2 逐小时 Token 分布(账单 CSV 复算) 日志

TABLE-28 · 原始表格 · 对应 AUDIT-V02
小时请求数输入 Tokens输出 Tokens缓存 Tokens对应阶段
01:00–02:00341,744,14961,2481,579,776需求确认 + R01 地基
02:00–03:001198,610,920136,4598,298,752R01 收尾 + R02 战斗
03:00–04:0012311,250,967106,42410,854,144R03 AI + R04 堵路修复
04:00–05:0013712,886,735110,39312,550,656R05 僵持修复 + R06 门径修复
05:00–06:0019121,442,413155,57920,570,624R06 收尾 + R07 UI + R08 视觉
06:00–07:0026926,597,581102,62926,242,560R08 收尾 + R09 修复 + R10 QA + 最终验收
07:00–07:014373,4401,206371,712窗口边缘收尾
合计87782,906,205673,93880,468,224

8.3 878个LLM请求的双向账本与耗时审计 日志实测 requestId闭合

验证脚本以 data.requestId 建立开始账和终态账,而不是只数成功响应:878个唯一started requestId全部且仅有一个终态,873个completed、5个failed;缺失、孤立和重复终态均为0。

LOG-V02878个LLM请求的双向账本requestId闭合 · nearest-rank P95
LOG-V02 878个LLM请求终态闭合与873个完成请求耗时分布 上半部展示878个started按requestId闭合为873 completed和5 failed,缺失、孤立、重复均为零。下半部展示六档耗时直方图及均值、中位数、P95、最大值。 REQUEST LEDGER · started = completed + failed配对键:observability data.requestId;耗时只统计873个completed事件的durationMs。 START BOOK878llm_call_startedunique requestId 878 COMPLETED TERMINAL873input/output token元组逐条可对账 FAILED TERMINAL5cancelled · status 0attemptCount 1 BIDIRECTIONAL INTEGRITY CHECK 878 ↔ 878unique start IDs ↔ unique terminal IDsmissing0orphan0duplicate terminal0 COMPLETED DURATION DISTRIBUTION · milliseconds · n=873 0100200300400 209<5s 3395–10s 23210–30s 4630–60s 2760–120s 20≥120s RECOMPUTED LATENCY 总耗时16,005,982 ms 均值18,334.458 ms 中位数7,652 ms P95 nearest-rank61,546 ms 最大值745,910 ms FROZEN SOURCElogs/observability-events-20260809-0130-0701.jsonl · verification.json.logs.llmAudit
选择账本节点、柱形或统计量,查看复算口径和边界。

画面与代码对应:878个started requestId各自有且只有一个终态;873个完成请求耗时可由公开事件逐条复算。

8.4 工具调用分布(968 次,13 种,按“sessionId+runId+toolUseId”复合键去重) 日志

WebBrowser
376 · 打开游戏/evaluate 断言/截图的实测循环
Edit
185
Read
162
Bash
102
Sleep
61 · 加速跑局的等待轮询
Write
37
Grep
20
TodoWrite
11
Agent
10 · 与子 Agent 账本一一对应
AskUserQuestion
1 · 唯一一轮需求确认(PART 1)
Snip / Glob / CodeIntel
各 1

复核命令见附录 A.2 第4条。为什么必须用复合键:968个 sessionId+runId+toolUseId 只对应422个裸工具序号;序号会跨Run复用,直接按裸ID去重会低估。376个WebBrowser复合键又与376个唯一Python POST requestId 一一对应(缺失0、重复0)。这证明浏览器请求真实进入执行链,不把调用数解释为376项相互独立且全部通过的测试。

8.4b 968次工具调用的完整生命周期 日志实测 源码机制

968Stage 1 · 输入与调用验证
968Stage 5 · 实际调用
968完成记录
951error=false
17error=true
0缺失或重复的三段生命周期

验证脚本以 sessionId + runId + toolId 为复合键重建每个调用。结果精确为968 / 968 / 968次验证、实际调用和完成:968个调用全部各有一条三段记录,没有孤立Stage或重复完成。其中951 次返回 error=false17 次返回 error=true,前者占98.244%。

TABLE-29 · 原始表格 · 对应 AUDIT-V05
返回 error=true 的工具次数应如何解读
Edit6这些是工具管线明确记录的错误结果,证明本案不是“零错误”。完整生命周期让错误可被后续循环读取和处理;但仅凭完成记录,不能断言17次错误都被自动修复。
WebBrowser5
Agent3
Bash2
CodeIntel1
这组数据比“工具很多”更能解释平台为什么能承载长任务:重要的不是工具数量,而是调用、失败和结果都进入同一个可追踪循环。98.244%只是本会话完成记录中 error=false 的比例,不是ZhikunCode产品总体可靠率。

8.5 日志证据(窗口过滤,保留原始行格式) 日志

TABLE-30 · 原始表格 · 对应 AUDIT-V06
文件行数内容SHA-256(截断)
logs/app-session-20260809-0130-0701.public.log38,641应用全量日志(两段已捕获轮转日志按时间窗口过滤后顺序合并,保留同毫秒不同事件与多行续行)ba3220722af426d9…
logs/observability-events-20260809-0130-0701.jsonl2,003结构化观测事件(llm_call/subagent/process/run 终止摘要)8a9b0248996bf2ea…
logs/security-audit-20260809-0130-0701.log116工具调用安全审计事件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.jsonsessions 表本会话完整行创建 2026-08-08T17:26:20Z(=01:26:20+08)· 模型 kimi-k3 · working_dir=<PROJECT_ROOT>
db/session-messages.jsonmessages 表窗口内 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_tokenstotal_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 数据行
E0219 个第一方文件 / 7,979 行(含 13 行启动器)wc -l 逐文件复算附录 A.2-2 命令;PART 2.1 表
E0310 个子 Agent:事件字段 completed=7/failed=3;终止语义为 1 自然完成/6 deadline/3 max_turns观测事件 subagent_* + run_termination_summaryobservability;PART 4.1 账本与 PART 5
E04877 请求 / 输入 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 表注;两文件可分别复算但共享本地信任域
E08I1:约 100 兵堵死在 (-80,60)协调者 evaluate 返回(t=780s)session-messages.json;PART 6 · I1 实录
E09I2:t=1350s 僵持(红 0 塔/水晶满血)协调者 evaluate 返回session-messages.json;PART 6 · I2 实录
E10I3:英雄贴墙坐标(-60,-86)/(-61,-74)协调者 evaluate 返回(t=1087s)session-messages.json;PART 6 · I3 实录
E113/3 局分出胜负(18:47/13:47/13:53)R06 汇报 + 协调者复核PART 4.5 汇报原件;PART 7.2 表
E12最终验收 __errors 为空多轮 evaluate window.__errorsV01–V12 表;session-messages.json
E13结算界面字段(失败 3:3 09:23 / 战绩 0/0/0 / 补刀 30 / 等级 11)协调者 evaluate 返回PART 7.1b 实录
E1443 张截图全量公开screenshots/ 目录附录 A.1b 逐张清单(时刻/字节/SHA-256)
E155 份录屏原件(3 份窗口内、2 份窗口外补充)及 5 份派生预览release-assets.json + videos/previews/PART 7.4;原件/预览 SHA-256 映射
E16提示词指纹 10 组(promptLength+SHA)观测事件 subagent_started.dataPART 4.3 指纹表;提示词原文在 DB 可逐字校验
E17工具调用968次/13种;422个裸工具序号不足以唯一定位app.log按sessionId+runId+toolUseId复合键去重附录A.2-4命令;PART 8.4分布
E184 项需求确认:首项创建至末项决定落库 39.6 秒interaction_requests created_at/decided_atPART 1.2b 窗口冻结原账
E19开发窗口内 permission=0;窗口外补充含 9 条 permission,状态均 answered两份 interaction_requests 冻结导出PART 3.4;窗口外补充文件
E20门径修复符号:BASE_GATES / _gateRoute / ASSAULT最终代码config.js:118ai.js:827ai.js:422
E21协调者直改 isCrystalInvuln最终代码注释自证state.js:911-925(PART 6 · I2 引文)
E22FPS 6 → 31.8(软渲染)R09 汇报 + 事故/修复后截图截图 ≈06:09 事故帧 FPS=6;PART 6 · I4
E23闪红壳层化(不污染共享材质)最终代码vfx.js:18 SHELL_POOL / :191-192 注释
E249 次中断后均有接续记录(6 deadline + 3 max_turns)观测事件 + activities durationPART 5.1 账本;observability 行号 1190/1683/1943
E2517 个 src/*.js 模块 / 39 条本地相对导入边(38 条第一方、1 条 vendored)最终源码静态解析PART 2.1c;verification.json.code.moduleGraph
E26267 次原子写入成功 / 157 次 Checkpoint 保存 / MCP 60 组断线重连配对冻结应用日志按组件与消息文本复算PART 3.2b;verification.json.logs.executionControls
E27ea0170c为窗口前最近提交;7个相关运行时源码到窗口后文档提交均未改变Git提交时间、差异文件与逐文件SHA-256PART 3.1e;verification.json.platformSnapshot
E28878次上下文评估 / 26次轻量折叠 / 释放2,029字符 / 峰值240,202低于650,000阈值冻结应用日志中的ContextCascade与ContextCollapseService事件PART 3.1d;verification.json.logs.contextGovernance
E29968次工具调用均具备验证、调用、完成三段;951次error=false、17次error=trueToolExecutionPipeline日志按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
E32180×180地图:3路、18塔、14草丛、10营地、2水晶/泉水、6基地门、120树/46石config.jsspawner.js静态复算PART 2B · KING-V05–V08;verification.json.code.productComplexity.mapTopology
E3330Hz固定逻辑、最大5次补步与GameState十阶段更新顺序main.js/state.js最终代码PART 2B · KING-V09–V11;verification.json.code.runtimePipeline
E341名玩家+9名AI英雄,Hero/Minion/Tower/Monster四类规则AImain.js/ai.js与最终浏览器单位断言PART 2B · KING-V12–V15;verification.json.code.aiTopology
E355英雄、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
E37Canvas/程序化模型/WebAudio与1024/48/12/10/12特效池;完整HUD联证map/models/vfx/audio/ui最终代码与HUD截图PART 2B · KING-V24–V25;verification.json.code.presentationPipeline
E3826张专题级SVG:1,239个图内直接标签、273个可聚焦节点、6张截图覆盖联证图;7组截图—代码绑定每图的密度、源码符号、引用、热点、工程范围、截图SHA-256与代码摘录均由验证脚本校验PART 2B · KING-V01–V26;verification.json.productVisualizationRichness
E3938,626条MDC行可重建11个会话、11个Run与10条Worker父子关系冻结应用日志的sid/rid/prid/agent字段逐行解析PART 3 · LOG-V01;verification.json.logs.traceability
E40968个复合工具键仅有422个裸工具序号;376个WebBrowser键与376个Python请求ID一一对应ToolExecutionPipeline MDC与PythonCapabilityAwareClient POST记录交叉PART 3/8 · LOG-V01;verification.json.logs.toolIdentity
E41878个LLM requestId终态闭合;873个completed总耗时16,005,982ms,中位7,652ms、P95 61,546ms冻结观测事件按data.requestId配对并以nearest-rank复算PART 8 · LOG-V02;verification.json.logs.llmAudit
E425次模型取消、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,38700%
02:00:0769,65469,37699.6%
03:03:1281,14773,21690.2%
04:04:2858,10849,40885.0%
05:01:29115,715114,43298.9%
06:00:05(峰值)182,227178,17697.8%
07:00:32(窗口内最后请求)93,67893,44099.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 在定稿后生成,避免人工复制导致陈旧。

09
PART 9 · 结论

这次任务说明了什么

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 个阻塞或高影响问题由协调者复测发现(堵车/僵持/贴墙/发光);这是隔离步骤,不是第三方独立 QAPART 6
修复必须带回归I3 修复连跑 3 局全部分出胜负才关闭;每处修复有前后对照数据PART 6/7.2
全过程可复算873 条运行时 completed 与账单逐条精确匹配;本地日志、DB、代码与截图可按脚本复算,信任边界明确披露PART 8/附录
判断

这个案例已经展示什么,下一步向哪里走

结果值得认可,不是因为调用次数多,而是多系统产物、失败后的接续、真实浏览器反馈和可复查材料同时存在。

最后把本案例已经展示出的能力和下一阶段路线放在一起,给出清楚、直接的工程判断。

运行记录冻结源码复算或推断窗口外材料
META-V01本案例实际证明的ZhikunCode能力
本案例实际证明的ZhikunCode能力为什么这个案例有说服力? 平台把通用模型转化为能持续执行、接续和复验的软件工程系统。判断 · 工程结论为什么这个案例有说服力?把事实、证据和工程判断放在同一张桌面上Kimi + ZhikunCode复杂长任务工程闭环需求治理4项确认/39.561sinteraction DB多Agent编排1 root + 10 Work…trace DAG真实工具执行968生命周期public log浏览器反馈376/376下游IDtool trace故障接续5+17+6+3/60组terminal events可验证交付代码/日志/账单/媒体E01–E421评价方式直接展示本案可复算事实verification2能力结论多源产物+执行链+失败接续+验收cross-domain3下一步评测用重复任务统计成功率与成本benchmark roadmap

数据:E01 / E25 / E26 / E30 / E38 / E42 / 产物 + 运行链 + 复验 + E01–E42|图中结论:平台把通用模型转化为能持续执行、接续和复验的软件工程系统

查看来源与复算数据
数据来源
产物 + 运行链 + 复验 + E01–E42
复算口径
平台把通用模型转化为能持续执行、接续和复验的软件工程系统。
图中指标
  • 能力维度6
  • Run11fact.run.total
  • 工具968fact.tools.total
  • 证据编号42
META-V02当前原型与下一阶段工程路线
当前原型与下一阶段工程路线从当前可玩原型继续走向产品,还要建设什么? 当前原型的功能完成面与十一项下一阶段工程路线同时列出。判断 · 工程结论从当前可玩原型继续走向产品,还要建设什么?把事实、证据和工程判断放在同一张桌面上L1非镜像英雄阵容下一步:阵容互换测试L2长局资源策略下一步:长局数值采样L3技能与建筑覆盖下一步:逐技能建筑矩阵L4多策略野区AI下一步:多种AI种子L5联网与匹配架构下一步:后端与同步系统L6生产化构建与测试下一步:CI与自动测试L7多设备图形基准下一步:硬件分层采样L8帧时间稳定性下一步:帧时间分布L9音频体验验收下一步:人工听测L10阵营与英雄平衡下一步:阵营互换大样本L11外部签名与存证下一步:发布版本签名功能工程性能体验证据1当前版本单机可玩MOBA原型已经闭环current product2五类路线功能/工程/性能/体验/证据roadmap groups3十一项建设每项都对应具体测试或工程工作next-step plan

数据:E01 / E25 / E26 / E30 / E38 / E42 / 已知限制原表|图中结论:当前原型的功能完成面与十一项下一阶段工程路线同时列出

查看来源与复算数据
数据来源
已知限制原表
复算口径
当前原型的功能完成面与十一项下一阶段工程路线同时列出。
图中指标
  • 下一阶段事项11
  • 路线分类5
  • 当前原型1
  • 明确验证项11

原型已经完成核心闭环;下一阶段路线把它如何继续走向更完整产品写得同样具体。

META-V03十个关键问题,一页读懂案例
十个关键问题,一页读懂案例读者最关心的十个问题,现有材料分别给出什么答案? 十个关键问题均由现有代码、日志、账单和验收材料给出直接回答。判断 · 工程结论读者最关心的十个问题,现有材料分别给出什么答案?把事实、证据和工程判断放在同一张桌面上Q01 · 产物真的能运行吗?最强证据:视频+window.__game+代码真实浏览器中完成选将、对战、终局和重开Q02 · 过程是一轮生成吗?最强证据:878 LLM/968工具/10 Worker五个多小时里持续实现、观察、修复与复验Q03 · 媒体如何对应过程?最强证据:43/42哈希+5份录屏截图、录屏、Run和代码符号形成可追踪关系Q04 · Worker怎样接力?最强证据:1 natural/6 deadline/3 maxTurns终态全部留痕,协调者继续整合落盘产物Q05 · 浏览器调用做了什么?最强证据:376复合键+376下游ID把真实运行状态持续送回开发循环Q06 · Token怎样核对?最强证据:873条逐项账单匹配运行事件与提供方账单逐请求对应Q07 · 缓存数据是什么?最强证据:97.059%缓存比例877条账单可复算缓存与非缓存TokenQ08 · 三局回归验证了什么?最强证据:R06三局结果三局都走完水晶、结算和重开路径Q09 · 开发与部署如何分开?最强证据:三层时间分区09:21最终运行与11:53云端试玩独立标为窗口外Q10 · 平台为什么能完成?最强证据:本案日志+运行时源码模型、Agent运行时、工具和浏览器形成工程闭环

数据:E01 / E25 / E26 / E30 / E38 / E42 / 质疑应答区 + 证据账本|图中结论:十个关键问题均由现有代码、日志、账单和验收材料给出直接回答

查看来源与复算数据
数据来源
质疑应答区 + 证据账本
复算口径
十个关键问题均由现有代码、日志、账单和验收材料给出直接回答。
图中指标
  • 关键问题10
  • 证据回答10
  • 证据类型7
  • 核心闭环1
META-V04证据资产地图:109个仓库文件+5个Release原件
证据资产地图:109个仓库文件+5个Release原件哪些资料直接在仓库中,哪些原件等待Release发布? 109个仓库文件与5个待发布Release原件均有路径、字节数和SHA-256映射。判断 · 工程结论哪些资料直接在仓库中,哪些原件等待Release发布?把事实、证据和工程判断放在同一张桌面上证据资产地图:109个仓库文件 + 5个Release原件面积按字节编码;金色单元是待人工发布的原视频映射,不属于普通Git文件。release-originals411,352,574videos24,986,723screenshots19,495,826logs13,972,814109仓库文件 + 5 Release原件 · 114个可追溯单元12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311401release-originals5392.3MiB02videos2523.83MiB03screenshots4318.59MiB04logs313.33MiB05code221.56MiB06visualization-data.json10.93MiB07db40.38MiB08visualization-manifest.json10.22MiB09bill10.13MiB10verification.json10.12MiB11template-analysis.md10.05MiB12provenance.json10.01MiB13video-storyboards.json10.01MiB14DESIGN.md10.01MiB15release-assets.json10.01MiB16browser-verification.json10.01MiB17redaction-report.json10MiB18zhikuncode开发王者荣耀.html.sha25610MiB

数据: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/指向技能处理单位,普攻处理塔与水晶;下一步增加逐技能×建筑回归矩阵
L4headless软渲染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 终止语义、交互历时、数据库动态总数、工具复算命令、账单差异、缓存成本外推、图片说明、平衡性、录屏映射及证据真实性边界。保留这段更正史,是为了让后续审查者区分原始记录与报告解释。
作者判断:本案例清楚展示了ZhikunCode如何把通用模型组织成持续数小时、可调用真实工具、可通过浏览器反馈修复问题并留下审计记录的工程执行系统。下一阶段将用重复任务基准继续量化平均成功率、成本稳定性和生产成熟度。
读到这里,可以直接检验最终产物亲自运行峡谷、选将和自动对局
APPENDIX · 素材包与复核指引

证据快照、派生预览与核验方法

仓库内证据位于 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.png152,80074e5521f1890…
phase1-map/shot2_walking_lane_tower.png634,620b1824471bcf4…
phase1-map/shot3_river_pit_brush.png460,30328ef594d935e…
phase1-map/shot4_enemy_tower.png683,21912321ef7de75…
phase1-map/shot5_enemy_base_crystal.png128,414f6e4a5de7193…
phase1-map/shot6_overview_river_center.png985,021815a9c23b57f…
phase2-combat/1_minion_clash.png622,2429ace684e4575…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786214784060.png02:46:24610,651520b128d280d…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786224926438.png05:35:26461,017dd90687c376e…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786224971688.png05:36:11475,925cdefd9f3ad93…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786225061947.png05:37:41192,85842a4cfe4fe0f…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786226976445.png06:09:36572,350a11244f38f0f…
screenshot_b8f86099-452d-4ba6-89c2-c3fee8f4b422_1786228379180.png06:32:59452,585bf7fb809cceb…
screenshot_p5b_1786227389921.png06:16:29596,5063b96e9f41105…
screenshot_p5b_1786227810671.png06:23:30491,38626e6dcbe4e48…
screenshot_p5b_1786227848467.png06:24:08545,684b69746ab3023…
screenshot_p5b_1786227926106.png06:25:26545,0276d725df1717e…
screenshot_p5b_1786227987623.png06:26:27550,90243ceca8b7369…
screenshot_p5b_1786228021255.png06:27:01470,976f1aa019c89ca…
screenshot_p5b_1786228208808.png06:30:08369,208a6fa8cf4f1a9…
screenshot_p5b_1786228259525.png06:30:59471,4660b44431cf03d…
screenshot_p5b_1786228298367.png06:31:38522,165fe1ee9659858…
screenshot_qa_1786228500285.png06:35:00469,8963f317e81814f…
screenshot_qa_1786229033812.png06:43:53421,972b0494d729e3a…
screenshot_qa_1786229287687.png06:48:07445,4140ad8494dc876…
screenshot_subagent-agent-1c86cd96_1786214519805.png02:41:59622,2429ace684e4575…
screenshot_subagent-agent-392c10e7_1786226388657.png05:59:4859,568014ff5c8cabb…
screenshot_subagent-agent-392c10e7_1786226491632.png06:01:31574,962e0bc9236eae2…
screenshot_subagent-agent-392c10e7_1786226526581.png06:02:06217,3049e382edbde32…
screenshot_subagent-agent-392c10e7_1786226570166.png06:02:50420,0604a0e15728815…
screenshot_subagent-agent-392c10e7_1786226660395.png06:04:20194,239859177a28346…
screenshot_subagent-agent-392c10e7_1786226714869.png06:05:14247,677588701d8ec23…
screenshot_subagent-agent-392c10e7_1786226855742.png06:07:35355,847cfd52ddd282e…
screenshot_subagent-agent-596000a2_1786224198927.png05:23:18461,016d649635e8e30…
screenshot_subagent-agent-596000a2_1786224248465.png05:24:08192,937765f9b0b4cc3…
screenshot_subagent-agent-596000a2_1786224285049.png05:24:45232,33086abc79918dc…
screenshot_subagent-agent-596000a2_1786224382375.png05:26:22268,090753a8690085a…
screenshot_subagent-agent-596000a2_1786224523468.png05:28:43432,962b2043a962742…
screenshot_subagent-agent-596000a2_1786224568019.png05:29:28566,29897ba226d38af…
screenshot_subagent-agent-596000a2_1786224619323.png05:30:19262,1090bd74cfc99ef…
screenshot_subagent-agent-596000a2_1786224657609.png05:30:57687,749a76c0e9f9620…
screenshot_subagent-agent-6b9d1e29_1786222596187.png04:56:36675,7823e27d35a9426…
screenshot_subagent-agent-6b9d1e29_1786223136843.png05:05:36692,047eb77dcc3709f…

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/吃鸡.htmldocs/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命中;发布前再对新增文件进行一次人工复看。

放大查看