游戏开发教程同时包含自然语言解释、代码示例、运行时 API、编辑器操作和跨章节学习路径。教程中的问题既可能让代码无法运行，也可能让示例虽然正确，读者却无法理解或继续完成后续任务。LLM 可以扩大检查范围，但它会遗漏、误判，也无法仅凭文本确认真实运行结果。因此，本项目研究的不是如何让模型生成更长的审查报告，而是如何让 Agent 发现问题后继续核实，并留下能够复查的结果。
项目将教程审查分成两条路线。客观路线检查代码、API、工具命令和运行时行为：能够通过代码与 API 资料判断的问题先进行静态检查，无法确定的疑点再进入真实编辑器实验。主观路线结合目标读者已经学过的内容，检查概念是否解释清楚、章节是否衔接，以及教程能否支持读者完成后续任务；系统先寻找候选问题，再由独立会话逐项复查，必要时查询前后章节。两条路线分别运行并分别输出结果，外层程序负责启动任务、检查输出格式、保存运行记录和处理中断。
实验持续改变了系统方案。受控教学缺陷实验达到 5/5 检出；26 个主观候选问题经过独立复查后，11 项成立、11 项不成立、4 项材料不足，说明扫描结果不能直接作为最终结论。两轮共享扫描实验的成本分别比主客观独立运行增加约 11% 和 32.5%，覆盖也没有形成稳定优势，因此当前系统保留两套独立扫描。知识记忆、重型报告格式和持续叠加 Prompt 等方案也经过实验，但没有表现出足以抵消其复杂度的稳定收益，因而没有进入当前流程。
当前程序已经可以接收一份教程文档，自动运行主观和客观两条审查路线，并分别保存结果。项目已经跑通一个真实章节的四阶段审查，也完成了一次覆盖 8 个修改块的 Diff 审查，并在电脑中断后重新冻结环境、重启会话并完成任务。这些结果说明端到端流程已经能够运行，但还不能代表生产级准确率；下一步需要通过人工标注建立固定评测集，进一步评估系统对真实问题的确认率、召回能力、稳定性和人工处理成本。
关键词：LLM Agent；教程质量审查；真实编辑器；主观审查；客观验证；增量审查
本项目面向一套游戏状态同步编辑器教程。教程按章节引导读者学习 Lua、运行时 API、客户端与服务端协作、场景对象、数据存储和完整玩法开发。它既是知识文档，也是用户实际开发时依赖的操作入口。
这类教程不仅要保证文字通顺，还要保证代码、API 和操作步骤能够在真实编辑器中成立。代码插入位置没有说明，可能让读者逐字复制后仍然报错；概念虽然在后续章节出现，如果当前读者尚未学到，仍然会造成理解断层。
因此，“没有错别字”和“代码没有报错”都不足以代表教程质量。系统需要同时检查事实可靠性、操作可复现性和教学质量。
人工逐章阅读并在编辑器中复现，能够发现最贴近真实读者的问题，也是项目最初采用的方法。但教程包含二十余章，代码、API、编辑器状态和跨章关系持续变化。一次完整复核需要反复搭建环境、运行代码并检查结果，难以在每次文档更新后重新进行。
人工判断也会受到经验影响。熟悉引擎的开发者可能自动补全教程没有写出的步骤，初学者则可能把自己的操作错误归因于文档。教学评价尤其容易停留在“感觉不清楚”，不同审查者也难以复查彼此的判断。
LLM 能够快速阅读大量文档、搜索相关资料、生成实验代码并整理结果，适合扩大审核规模。但模型可能依据过时知识作答，也可能遗漏部分章节，不能直接充当最终裁判。项目的目标不是让模型替代人工，而是让模型扩大问题发现范围，再通过代码检查、真实编辑器实验和人工判断确认结论。
正式立项时，项目便将教程质量拆成两个问题：“讲得对不对”和“讲得好不好”。两类问题的判断依据不同，不能直接使用同一套方法。
| 路线 | 回答的问题 | 主要判断依据 |
|---|---|---|
| 客观路线 | 代码、API、命令和运行结果是否正确 | API 资料、代码检查和真实编辑器实验 |
| 主观路线 | 教程是否让目标读者理解并完成任务 | 读者此前学过的内容、当前教程、前后章节和学习任务 |
项目早期的实际工作主要集中在客观排错，之后两条路线分别建立自己的审查方法。等两边方案趋于稳定后，项目才进一步研究它们能否共享扫描过程，以及两份结果应当如何配合使用。
系统从项目开始便考虑了两种输入情况。
全量审查以教程全文为输入，用于首次建立问题基线。当前阶段首先对二十余章教程进行完整检查，同时建立验证方法和可复用资料，为后续判断提供可靠起点。
Diff 审查以一次文档修改为主要入口，用于基线建立后的日常更新。系统不仅检查新增、修改和删除的文字，还要根据引用关系、概念依赖、代码和 API 的影响范围，找到需要重新检查的相关章节。
全量与 Diff 不是两套互相排斥的系统。前者负责建立基线，后者在复用基线的基础上降低后续审查成本。
项目真正关注三个结果：能否发现更多有效问题、结论是否可靠，以及别人能否复查判断过程。报告长度、问题数量、格式合规、Token 和耗时可以帮助分析，但不能单独证明方案更好。
重要方案修改都尽量遵循同一过程：
观察 → 解释 → 假设 → 验证 → 结果 → 决策
每项实验都应当能够改变方案选择。单轮结果只用于发现现象，重要结论需要重复验证；如果结果不一致，就如实报告波动，而不是选择最符合预期的一轮。
本项目包含客观和主观两条路线。两者面对的问题不同，因此不能使用同一套指标评价。
客观路线：新章节没有一份标出全部问题的标准答案，也不能把任一模型的输出直接当作答案。项目让模型对同一内容进行多轮检查，再将重复或含义相同的发现合并，得到这组实验已经发现的问题集合 U。某次模型运行 m 的相对覆盖指标为：
其中，Fm 是该次运行发现的问题。这个指标回答的是“本轮覆盖了多少已经被其他轮次发现的问题”，不能发现所有模型共同遗漏的内容，因此不是准确率。它主要用于比较不同模型或不同运行的遗漏情况，以及一次方案修改是否带来了新的有效发现。
主观路线：教学质量没有现成的标准答案。项目采用配对实验：保留一份教程原文，同时制作一份只删掉或破坏某项教学作用的修改版本，例如删去完成后续任务所需的关键解释。两个版本分别在隔离会话中接受审查，再比较模型能否发现修改版本中新增的问题。
实验前先写清楚改了什么，以及模型指出哪些内容才算命中。实验后还要确认这次修改确实造成了预期影响：如果读者仍能从其他内容中学会相同知识，就说明目标问题并未真正出现，不能据此判定模型漏检。最终分别统计输出格式是否正确、引用能否在原文中找到，以及模型是否真正发现了目标问题。
项目最初没有复杂的 Agent 架构。审查者以不熟悉 Lua 和游戏开发的读者身份逐章阅读教程，并尽可能把代码放进编辑器执行。对初学者而言，最容易判断的信号是代码是否报错、日志是否出现，以及对象和画面是否发生预期变化。因此，最早记录的问题主要来自构造器报错、资源 ID 静默失败和客户端与服务端消息丢失等可观察现象。
出现问题后，人工继续操作编辑器，并让开发协作 LLM 帮助分析原因、编写测试代码，由此形成早期 Bug 记录。这个阶段证明教程值得进行系统审核，也暴露了更困难的问题：观察到“跑不通”并不难，难的是判断问题究竟来自哪里——教程、API 版本、运行端、加载时机和当前地图状态都可能改变结果。
将模型引入审查时，项目有两个目标。第一，人工主导、Opus 协助形成的早期 Bug 记录可以作为部分参照，用来观察审计模型能否重新发现已知问题，并补充尚未记录的新问题。第二，项目让 Opus 以独立审查者身份逐章审核和实测，从第 2 至 12 章形成一组报告，希望它们能够逐步接近可用的参考答案。
实际过程不是强模型一次生成标准答案，而是Opus 一边发现新问题，一边在后续章节和复盘中推翻旧记录及自身方法。模型确实能够发现 Bug、编写测试代码并解释异常，但“能够发现 Bug”和“能够给出可靠答案”是两回事。资料版本、运行环境和实验设计都可能影响结论；未经复核的旧 Bug 记录如果继续提供给模型，还会把错误带入下一轮审查。
这一阶段从第 2 至 12 章共形成11 份实测报告。重新检查最早的16 条历史记录后，有7 条存在结论错误、归因错误或章节对应错误。具体问题包括把自己的调试代码记成教程原文、同一缺陷重复登记、契约中找不到便判运行时不存在、pcall 成功便判功能生效，以及对照同时改变多个变量。
这次复核推翻了一个关键假设：更强的模型可以扩大调查范围，却不能天然成为其他模型的裁判。早期 Bug 记录和 Opus 逐章报告都只能提供候选问题，最终结论仍然需要围绕教程中的具体主张重新检查。
如果继续让模型逐章运行，项目会获得更多报告，却无法判断哪些结论值得信任。因此，项目暂停以章节数量为目标的扩张。客观路线首先需要解决：当 API 资料、历史记录和编辑器行为彼此矛盾时，一项技术结论怎样才算得到验证；主观路线则需要解决：没有唯一答案的教学判断应当如何结合读者背景进行检查。等两条路线分别建立稳定方法后，再恢复全量审查。
Opus 逐章审核和复盘时，推翻了早期记录中的一部分结论。进一步检查发现，错误并不只来自模型：API 契约、派生文档、历史记录和编辑器实际行为可能彼此矛盾，编辑器本身还可能在不报错的情况下静默失败。因此，无论资料中“找不到”，还是代码“没有报错”，都不足以直接形成结论。
例如，API 契约中搜索不到某个接口，不能直接证明它在运行时不存在；pcall 返回成功，也不能证明接口产生了预期效果。前者可能受到资料版本和检索范围影响，后者可能只是编辑器没有抛出错误，或者调用没有产生实际作用。
项目因此为客观结论确定了两条核心约束：
资料和运行结果需要互相检查；没有正确对照的真实运行，同样可能产生错误结论。
在这两条约束完全形成之前，项目已经先用 editor-cli 跑通一条最小闭环：启动试玩、执行短 Lua、读取日志或对象状态，再停止试玩并保存结果。随着逐章审核不断暴露无效对照和静默失败，这条闭环进一步成为验证技术结论的主要手段，而不是在事后从零建设一套大型平台。
编辑器在可见、最小化和被其他窗口完全遮挡时分别保持约60.2、60.1 和 58.7 fps，逻辑帧和物理模拟继续运行。截图实验则得到相反的工具结论：跨两个试玩会话取得的6 张游戏截图，在场景已经发生已知变化后仍逐字节相同。因此，screenshot game 返回成功不能证明画面已经刷新。
这些结果证明 Agent 可以在无人观看时操作真实编辑器，但这不是无需前置状态的“真无头”：机器仍需有效的 Windows 图形会话，编辑器必须已经登录并打开地图，控制程序还要发现当前可用的 CLI 端口。它不能直接放进完全无图形环境的普通容器，也不能仅凭游戏截图判断视觉结果。
编辑器不是纯函数。模型会修改 Lua、同步地图、启动试玩、生成日志、留下临时对象并改变连接。如果下一轮沿用这些状态，模型差异就会与环境差异混在一起。
后续多模型和报告格式实验进一步暴露了三类环境事故：超过 1.5 GB 的历史日志混入新实验；模型连接到嵌套副本或错误地图；模型已经完成并写出报告，但控制进程仍然没有退出。这些事故会让不同轮次使用不同的输入、日志和地图状态，实验结果因此无法比较。
项目没有继续把排障要求堆进 Prompt，而是逐步将确定性操作交给外层控制程序：运行前冻结输入并检查地图，运行中划定本轮日志范围，结束后保存结果、停止试玩，并恢复受管理的实验脚本和基线状态。程序只承诺恢复它明确管理的状态，不把整个编辑器假定为可以完全回滚。
LLM 负责发现疑点、设计实验和解释现象；程序负责输入与地图身份、日志边界、完成状态、结果归档和受管理基线的恢复。
随着早期审核推进，项目逐渐积累了两类可复用经验：一类是教程和编辑器中已经发现的缺陷，另一类是模型在审核过程中犯过的错误，例如把“资料中没有找到”写成“运行时不存在”，或者把“没有报错”写成“功能已经生效”。
项目最初假设，如果 Agent 能够记住这些经验，并在未来遇到类似问题时主动调用，就可以减少重复排查和相同误判。因此，项目尝试建设一套长期记忆系统，将验证方法、错误案例、事实来源和运行规则拆成结构化 YAML，供模型读取和使用。
实际建设很快暴露出三个问题。首先，经验已经保存，不代表模型知道什么时候应该使用；它可能读过某条规则，却没有意识到当前问题正好需要这条规则。其次，API、教程和编辑器会持续变化，过去正确的经验可能已经过时，需要识别冲突并及时淘汰。最后，如果让模型自己新增、修改和合并记忆，还需要判断它保存的是可复用经验，还是一次实验中的错误归因。
结构化整理并非完全没有价值。重构过程修正了多处判据问题，并自动发现4 处 Benchmark 正负样本冲突。但随着内容增加，知识库接近三万 Token，文件、字段和维护脚本持续增长，许多脚本最终只是将拆开的 YAML 重新拼成自然语言。
第 6 章 GLM baseline 用完整执行版检查最关键的问题：信息已经给足后，模型是否会在正确位置使用？这轮输入本身存在答案泄漏，执行清单直接指出了一个第 6 章已知问题，因此该项命中不能算作独立发现。评分时剔除这项污染结果后，剩余 3 个已知问题中，GLM 漏掉 2 个。
唯一命中的问题也只完成了一半归因：模型观察到计时器未调用 Start() 时 IsRunning=true，便解释为“计时器已经自动启动”，却没有继续检查这个字段是否始终为真、能否区分运行状态。它得到了真实数据，但没有设计足以区分两种解释的对照，因此可信口径下完整归因正确率为 0/1。相关规则已经被模型读到，却没有在需要时转化为实验动作。
这不等于模型没有提供任何增量价值：它还提出了 Benchmark 之外的一条服务端日志线索，后续人工配对实验确认该现象在当时环境中成立。实验真正否定的是“把完整经验放进上下文，模型就会稳定调用”这一假设。
当前方案没有观察到足够的审核收益，却引入了检索、更新、冲突处理和过期淘汰等额外成本，因此项目主动停止继续扩建 YAML 记忆系统。较稳定的经验被拆成独立 Markdown 文件，由 build.py 生成按工作顺序排列的执行清单：常驻规则直接进入清单，按需经验只提供路径和适用情况，仍由审计模型在遇到对应问题时主动读取。经验与代码一样接受版本管理和实际测试；如果后续反复出现可由历史经验避免的问题，再分别研究调用、更新和淘汰机制。
Agent 记忆的难点不是“把经验存下来”，而是决定该记什么、什么时候想起，以及什么时候不再相信它。
知识组织稳定后，新的问题是：相同任务和资料下，不同模型只是覆盖数量不同，还是会采用不同的调查方式？本阶段比较的是 Qwen 3.8 Max、DeepSeek V4 Flash、GLM 5.2 和 GPT-5.6 Luna；结论只描述这些版本在当前任务中的表现。
第 19 章的五轮报告合并出 29 个问题主题，初步显示不同模型的覆盖和深挖方向并不相同。但各轮判据、运行过程和人工介入没有完全对齐，因此这组数据只用于提出假设，不用于严格排名。
第 17 章随后在更接近的条件下复测。18 个归一化问题主题中，Qwen 覆盖 18 个，DeepSeek 覆盖 15 个，GLM 覆盖 13 个，Luna 覆盖 7 个。
Qwen 的全章覆盖和对照最完整；DeepSeek 在本轮沿强信号发现了高价值时序问题；GLM 能完成常规检查，但主动扩展不足；Luna 完成较快，但覆盖和深度明显不足。这些是实验中观察到的工作倾向，不是模型家族的固定能力边界。
第 21 章出现了相反结果：DeepSeek 的发现池覆盖为 80%，Qwen 为 70%，但 DeepSeek 存在一次重要的过度推断；Qwen 覆盖的外围主题较少，关键问题的对照却更可靠。这说明覆盖最多、单点分析最深和综合质量最好不是同一件事。
成本也影响工程选择。在 Provider 当时返回的记录中，第 17 章 Qwen 与 DeepSeek 分别约为¥7.71 和 ¥0.38，第 21 章分别约为¥5.55 和 ¥0.29。这些价格不能推广到其他模型版本或计费条件，也不替代质量判断；但 DeepSeek 连续两章内容质量第二、记录成本显著更低，使它适合承担可重复的深入核实。
因此，项目没有只保留单次排名最高的模型，而是常规实验保留 Qwen 和 DeepSeek，必要时使用 GLM，不再为 Luna 单独扩建 Prompt。后续实验继续验证两者是否适合承担不同角色，而不是把当前观察直接写成固定分工。
执行清单虽然已经写明原样运行、阳性对照和状态读取等方法，但模型读过清单，不代表它在每个问题上真正执行。自由 Markdown 通常在实验结束后一次性写成，人工难以快速判断模型做的是教程原文还是替代实验，也难以比较不同报告中的同类问题。
项目因此尝试严格的原子结论卡，并要求模型在实验过程中持续更新。每张卡分别记录教程原文、是否原样执行、实际修改、运行上下文、对照、直接观察和结论适用范围。这个版本后来被称为“重型结论卡”。
这套设计有两个目标：一是让验证过程能够被复查，并方便程序对齐和统计不同报告；二是检验这些字段能否反过来约束模型，使它更主动地补充对照、区分原样运行与替代实验，并减少超出实际观察的结论。
结构化 v1 与旧交付对照时，Qwen 的运行时间从42 分 39 秒增加到 77 分 41 秒，工具调用从61 次增加到 118 次；DeepSeek 的运行时间从18 分 01 秒增加到 64 分 18 秒，工具调用从77 次增加到 204 次。
Qwen 的调查范围达到其三轮样本中的最高水平，结论卡从 13 张增加到 18 张；但增加量既包含新主题，也包含旧复合结论的拆分，同时还有两个旧主题消失，卡片数量不能直接当作覆盖提升。DeepSeek 的结论从 13 项降到 12 项，覆盖明确有所收缩。
结构化卡片确实让一些问题更加透明。Qwen 会逐项说明没有原样执行的部分，DeepSeek 也会记录运行端、对照和结论范围。报告更容易复查，后续程序也更容易拆分和统计问题。
但重新检查旧 Session 后发现，没有结论卡规则的 Qwen 和 DeepSeek 原本就会进行原样运行、变量隔离、阳性对照和状态读取，并能在实验结束后一次性写出完整报告。重型结论卡主要让这些过程更容易被看见，没有证明严谨实验是由报告字段产生的。严格编号、重复填写公共上下文和频繁更新文件，反而明显增加了报告维护。
项目没有从 v1 直接跳到轻量报告，而是先设计结构化 v2：允许先建骨架、按一批实验结果集中回填，并简化静态结论。Qwen 的耗时降到39 分 29 秒，只进行 3 次 write 和 2 次 edit，质量与成本更加均衡；DeepSeek 仍耗时40 分 51 秒、调用工具 209 次，并把大量预算投入 LogService，最终形成 9 张卡。v2 说明减少写作频率可以降低部分维护成本，却不能解决覆盖分配和单点深挖。
项目随后设计轻量 v3，删除本地 ID、证据等级、空严重度、严格原子化和强制增量写作，只保留教程原文、实际验证、非原样修改、必要的运行上下文、对照、直接结果和结论适用范围。Qwen 与 DeepSeek 各完成两轮后，四轮都保持了较低的报告维护成本，严谨实验仍然能够出现；覆盖范围、停止时机和格式遵循则继续波动。
DeepSeek 首轮受约 563 MB 跨会话旧日志干扰，漏掉稳定缺陷并错误判断项目日志不存在；清理日志后的复验恢复了该缺陷，也纠正了日志结论。因此，首轮退化不能归因于删除重型字段。实验支持的是：轻量格式可以降低写作成本，但不会自动解决覆盖、停止判断和环境污染。
这组实验最终支持的不是“报告格式能够让模型变得严谨”，而是：
结构化交付的主要价值，是让验证过程和结论范围更容易复查。只保留复查结论真正需要的信息；编号、同义问题合并、格式统一和统计由程序在模型完成调查后处理。
| 遇到的问题 | 做了什么实验 | 实验结果 | 最终决策 |
|---|---|---|---|
| 历史经验不断增加，模型能否在需要时主动调用 | 建设约三万 Token 的 YAML 记忆系统，并进行第 6 章 GLM baseline | 剔除泄题命中后，3 个已知问题漏掉 2 个；唯一命中也没有完成正确归因 | 停止扩建 YAML；改用 Markdown 保存经验，并继续单独研究经验触发 |
| 不同模型是否只是覆盖数量不同 | 在第 17、21 章比较四个模型 | Qwen 综合质量最高；DeepSeek 能深入核实且记录成本较低；覆盖数量不能代表最终质量 | 保留 Qwen 和 DeepSeek，必要时使用 GLM，停止为 Luna 单独优化 |
| 更多报告字段能否让验证更严谨 | 依次测试结构化 v1 和 v2 | 验证过程更容易复查，但耗时、调用和维护成本显著增加；减少写作频率仍未解决覆盖和深挖 | 保留直接结果、关键对照和结论范围，删除机械填表要求 |
| 删除重型字段是否会损害严谨性 | Qwen、DeepSeek 各运行两轮轻量 v3 | 四轮都保持低维护成本，严谨实验仍能出现；覆盖、停止和格式继续波动 | 正式采用轻量报告；编号、合并和统计交给程序后处理 |
原样运行、阳性对照和结论范围能够减少轻率判断，也可能让模型把严谨理解成“只要还有变量，就应该继续调查”。DeepSeek 容易沿强信号持续追查根因；Qwen 虽然更倾向先扩大范围，也会追加不能改变教程修改方向的实验。
项目将实验深度分成三层：先判断教程说法是否成立，再取得足以修改教程的关键对照，最后才研究引擎为什么产生这种行为。默认在已经知道教程应当怎样修改时停止；只有结果冲突、无法判断或根因会改变修改建议时，才继续深挖。执行清单同时要求递归、反馈链等危险实验必须限制次数。
DeepSeek 首轮在 12 分 19 秒内安全结束；复验运行 22 分 08 秒，输出加推理 Token 从 50,064 增加到 128,907，并触发服务端 512 MB OOM。
复验约在第 4.48 分钟已经用有界探针证明 LogService 的反馈链，随后却移除次数限制并在约第 5 分钟触发 OOM。恢复调查后，约第 7.43 分钟取得的对照已经足以支持教程修改，模型仍围绕同一问题调查到约第 17.4 分钟。新增实验强化了根因解释，却没有改变修改建议。
Qwen 在相同规则下连续两轮使用有界探针，没有出现 OOM，说明“反馈实验必须限制次数”这类具体动作更容易被执行；但抽象的“修改依据充分后停止”仍只得到部分遵守，覆盖主题也继续变化。
停止规则保留为低成本提醒，但不能保证模型及时停止。减少深挖也不会自动带来更高覆盖，因此覆盖需要单独实验。
轻量交付和停止实验都暴露出同一个问题：同一模型在相同章节中发现的问题仍会明显变化。项目因此提出新的假设：模型虽然读过“完整检查全章”的要求，但这条抽象要求没有转化成具体搜索动作。如果要求它在运行时实验前，将准备调查的小节、代码、命令、事实声明和跨章节关系逐项写进 Todo，可能迫使它主动寻找更多候选问题。
回看八轮轨迹后发现，八轮模型都完整读取了执行清单，Qwen 四轮也都在首次运行时实验前建立 Todo。但多数事项只是“整体走读”“六项文档审查”或“检查事实声明”。模型可以将这些总括任务标记完成，同时遗漏跨章节事件错位、未解释的测试标记和前后矛盾。
项目只小幅修改现有规则：表示调查范围的 Todo 必须对应具体小节、代码段、命令、事实声明或跨章节引用；Todo 只作为 Session 内的工作记忆，不进入最终报告，也不要求固定格式或机械清零。
实验前由人工记录三个已知问题，只在运行结束后用于检查覆盖，不提供给模型。第一轮 Qwen 建立 12 项 Todo，命中其中 2 项；第二轮建立 14 项，却命中 0 项。第一轮甚至已经搜索到相关事件名称，却没有继续比较第 9 章与第 21、22 章的实际事件名，说明遗漏还会发生在看到线索后的比较和判断阶段。
两轮并非简单的全面好坏关系：第二轮重新发现了第一轮遗漏的 LogService 自反馈，但三个覆盖检查项全部迁移消失。Todo 的确改变了计划粒度和部分搜索路径，却没有稳定形成完整候选范围。
Todo 可以把模型已经注意到的方向转化成具体调查动作，但不能保证它一开始就注意到所有重要问题。项目保留 Todo 作为低成本工作记忆，不再继续增加提示词约束。
Todo 实验之后，项目不再要求单个模型同时保证发现范围和实验深度，而是先拿掉编辑器和运行时反馈，只让 Qwen 阅读完整章节、静态检索相关资料并设计后续核实任务。扫描阶段不连接编辑器、不运行 Lua，也不提前判断问题正确、缺陷或未决。
两轮 Qwen 静态扫描分别用时 10 分 37 秒和 12 分 30 秒，形成 9 项和 11 项任务。两轮任务都足够具体，成本明显低于完整审计，但候选仍然迁移：两轮都没有稳定发现跨章节事件错位，第二轮还提出了可能产生递归反馈的危险实验。静态扫描能够低成本形成候选任务，不能保证一次扫描得到完整答案，也不能替执行者决定实验是否安全。
为了验证最小分工是否可行，项目没有合并两轮任务，也没有人工改写或预先分批，而是原样冻结第一轮的 9 项清单，完整交给一个 DeepSeek Session。连续两轮都完成 9/9，越界新增为 0，没有因单项深挖而放弃后段任务。这证明一个执行者可以整单完成当前粒度的冻结任务，没有必要为了保证任务完成而提前建设分批调度。
执行者也会修正扫描者。Qwen 将 [TEST:END] 视为来源不明，DeepSeek 继续检查 QA 资料，确认工具链中确实存在该机制，最终把问题收窄为“教程没有解释或提供链接”。扫描阶段提交的是待核实疑点，不是结论。
职责分工没有解决所有问题。LogService 危险模式在两轮核实中 2/2 触发 512 MB OOM；第二轮推理 Token 为第一轮的约 2.20 倍，任务完成率却相同。因此，两阶段流程稳定了任务交接和既定范围，没有稳定候选完整性、执行成本或单项内部安全。
两阶段 Markdown 流程跑通后，项目单独验证了机器可读交付。第一步只把 DeepSeek 的最终报告等价改成 JSON：同样完成 9/9，文件能够解析并通过 Schema，耗时和总处理 Token 落在两轮 Markdown 样本之间，没有观察到明显格式负担。
随后 Qwen 静态扫描也改为最小 JSON，两轮分别生成 9 项和 10 项合法任务。第一轮的 9 项 JSON 任务再原样交给 DeepSeek，模型完成 9/9 并生成合法结果 JSON，证明“第一阶段 JSON 任务 → 第二阶段 JSON 结论”的完整链路不会阻塞实验或丢失既定任务。
严格的“一任务一结论”也暴露出问题：DeepSeek 在核实过程中独立发现 LogService 自反馈，却只能把它埋进已有任务。最终契约因此保留与输入任务数量、顺序一致的 findings，另增 additional_findings，用于记录核实过程中直接发现、无法归入旧任务且已经具备完整结果的新问题。Schema 和工具已经验证这一结构，模型能否稳定使用该数组仍需后续实验。
JSON 可以确定性检查语法、字段、枚举和任务数量，不能判断实验是否被错误推广，也不能发现一句结论中的语义矛盾。项目还研究过更复杂的任务账本、自动门禁和第三轮复核，但这些方案主要改善流程治理，不能直接扩大候选覆盖，还可能重新引入重型结论卡的维护成本，因此没有进入当前主线。
当前主线保持轻量：Qwen 负责形成候选范围，DeepSeek 负责逐项核实，程序只承担 JSON 校验、输入注入、归档和环境恢复。
| 遇到的问题 | 做了什么实验 | 实验结果 | 最终决策 |
|---|---|---|---|
| 模型会围绕单个问题持续深挖 | 加入停止提醒，并限制危险实验的执行次数 | 具体的次数限制更容易执行；抽象的停止原则不稳定，DeepSeek 复验仍触发 512 MB OOM | 保留具体安全限制；停止提醒只作为软约束 |
| 同一模型每轮发现的问题不同 | 要求 Qwen 在实验前建立具体 Todo | 两轮分别建立 12 项和 14 项 Todo，预先记录的三个问题分别命中 2 项和 0 项 | Todo 只作为工作记忆，不再依靠提示词保证覆盖 |
| 发现问题和深入实验互相争夺时间 | 将静态扫描与真实核实拆成两个阶段 | Qwen 形成任务后，DeepSeek 连续两轮都完成 9/9；但候选范围和实验安全仍不稳定 | 保留“Qwen 扫描、DeepSeek 核实”的两阶段分工 |
| Markdown 交接难以由程序检查 | 将任务和结果改成最小 JSON | 完整链路完成 9/9，Schema 能检查结构，不能判断结论是否正确 | JSON 只负责交接和程序校验，不承担语义判断 |
早期读者反馈中反复出现的，并不都是代码错误：“哪儿有 meta 契约？”“为什么要这样做，不告诉原因吗？”“editor-cli 在哪儿执行？”“示例应该放进哪个文件？”这些问题很难通过 API 契约或真实运行判断，却会直接妨碍读者理解和操作。
因此，主观路线没有让模型笼统评价“写得好不好”，而是把问题改写为：
给定目标读者此前已经学过什么，他能否只依靠当前可以取得的教程材料，理解本章内容、完成示例和练习，并把学到的方法用于相近任务？
围绕这个问题，系统从六个方向寻找疑点：
| 检查方向 | 具体检查什么 |
|---|---|
| 阅读衔接 | 术语、指代、文件位置和操作步骤是否需要读者猜测 |
| 知识顺序 | 一个概念是否在首次使用前得到介绍 |
| 解释程度 | 是否说明是什么、为什么使用、何时使用和有哪些限制 |
| 示例质量 | 示例是否完整，运行结果是否可以观察 |
| 学习迁移 | 读者能否把方法用于稍有变化的任务，而不只是照抄 |
| 内容节奏 | 当前内容是否过早、过晚或打断了主要学习目标 |
这六项只是帮助模型寻找问题，不是评分表，也不要求每章必须找齐六类缺陷。
项目首先制作了一个受控版本：删除一段集中解释身份、类型、频率、业务条件和结果下发五类校验的文字，同时保留代码、术语和练习。实验前的预期是，模型应当指出“练习要求读者完成五类校验，但正文没有充分解释”。实际运行却返回了空列表。
这个结果不能直接解释为模型漏报，因为还存在另一种可能：虽然集中说明被删除了，读者仍然可以从保留的代码或其他章节中理解部分内容。
因此，这次实验确定了两条基本规则：模型没有报告问题，不代表教程没有问题；人工植入了缺陷，也不代表人工预期天然正确。
后续判断必须分别查看当前章节实际写了什么、读者此前从其他章节学过什么，以及相关 API 在契约或真实编辑器中的行为。三类材料不能互相替代：API 可以运行，不代表当前章节已经讲清楚；教程多次使用某个 API，也不能证明它在编辑器中确实成立。
第 9 章的缺陷版本删除了全章唯一一处对原点、Anchor 和 Position 含义的解释，但保留了学习目标、Position 示例和验收要求。读者仍然需要使用这些概念，却失去了理解它们的集中说明。
最初的整章审查连续运行两次，模型都没有准确指出这三项基础解释被删除，结果为 0/2。这里的命中标准不是笼统地说“坐标讲得不够清楚”，而是明确指出读者缺少原点、Anchor 和 Position 的基础含义。
项目首先提出一个假设：
模型可能具备判断能力，只是自由阅读时没有沿着教学目标检查到概念解释和练习要求。
第一项改进没有告诉模型“坐标存在问题”，而是要求它对六个检查方向分别追踪以下过程：
章节目标 → 概念首次使用 → 正文解释 → 读者应用 → 练习或验收模型还要留下每个方向的检查记录，以便区分“检查过但没有问题”和“根本没有检查到”。
在章节、缺陷和基础模型不变的情况下，目标问题从 0/2 提高到 2/2。但两次运行中只有 1/2 完全遵守输出要求，另一次虚构了正文中不存在的小节标题；平均耗时也增加了 56.1%。
这个结果只能说明：明确规定阅读顺序，可能改变模型在单个样本中的探索结果。它还不能证明方案已经稳定，因为收益只出现在一个缺陷上，而且同时带来了格式错误和明显的时间成本。
项目随后提出第二个假设：
会不会是同时检查六个方向分散了注意力？如果只检查解释是否充分，模型是否能够更稳定地找到这类问题？
因此，第二项改进另开全新会话，只检查解释问题，不再同时处理阅读衔接、示例、迁移和节奏。当前章节全文仍然保留，只将辅助材料压缩为读者前置知识摘要、带编号的小节目录和输出规则，请求文件比上一版缩小约 87.5%。
第 9 章采用“原文两轮、缺陷版本两轮”的配对方式。四次输出格式全部有效，报告中的 43 条引用也都可以定位，但两次缺陷版本仍然没有准确指出被删除的三项坐标含义，精确目标依然是 0/2。
原文和缺陷版本都报告了比较宽泛的坐标教学问题。这说明模型能够感觉到这一部分可能讲得不够好，却没有识别人工删除带来的具体差异。因此，宽泛意见不能算缺陷被命中。四次运行的平均模型处理量仍达到 26,695.8 Token，缩小请求文件也没有明显降低模型的实际处理量。
为了排除“第 9 章原文本身就存在宽泛坐标问题，导致对照不够干净”，项目又换用第 11 章的 UpdateAsync 并发理由复测。
第一次运行先暴露了输入裁剪问题：前置知识摘要漏掉此前章节已经教授的事件和玩家生命周期，模型因此把已学内容误报为缺失。补齐摘要后，原文和缺陷版本各运行一次，两次输出及 18 条引用全部有效。
但缺陷版本只笼统提出“需要解释并发差异”，没有指出这个实验预先设定的具体缺口：旧结果可能覆盖新结果，以及 UpdateAsync 如何处理并发冲突。因此目标结果仍为 0/1，平均模型处理量为 25,467 Token。
| 实验 | 精确目标命中 | 主要观察 |
|---|---|---|
| 第 9 章整章审查 | 0/2 | 自由阅读没有找到坐标解释缺口 |
| 加入逐项检查顺序 | 2/2 | 单一样本改善，但一次虚构正文标题，耗时增加 56.1% |
| 第 9 章只查解释 | 0/2 | 缩小任务范围和辅助上下文后仍然漏报 |
| 第 11 章换题复测 | 0/1 | 只给出宽泛建议，没有指出具体并发风险 |
这些实验没有证明 Prompt 改进完全无效，但说明它们没有形成稳定、可重复的召回收益。继续增加检查规则还会提高运行时间和上下文维护成本，手工压缩上下文甚至会制造新的前置知识误报。
项目因此停止继续堆叠 Prompt，转而解决一个更基础的问题：最终没有报告问题时，怎样区分模型是没有发现疑点，还是发现以后判断它不成立。这直接引出了下一节将寻找疑点和判断疑点拆开的设计。
新的流程使用两个独立阶段。扫描阶段阅读当前章节和课程目录，尽量提出可能妨碍学习的疑点，但不急于给出最终结论；程序保存全部疑点和本次输入信息，防止候选在后续处理中被遗漏或悄悄合并；核验阶段逐项查阅当前章节、其他教程章节以及必要的 API 资料，将每个疑点判断为成立、不成立或材料不足。
核验阶段可以发现并补充新问题，但不能让原有疑点无结果消失。这样设计不是因为扫描结果一定正确，而是为了保留完整调查过程：后续人员能够看到模型提出过什么、为什么保留或驳回，以及判断时缺少什么材料。
两阶段最早的两次运行并没有立即提高召回，却证明了拆分的诊断价值。第一次扫描找到了目标问题，但自动交接文件损坏，因此不能算完整运行；第二次正常生成了 11 个疑点，却没有目标问题，因此可以确定遗漏发生在扫描阶段，而不是后续核验阶段。以前只能看到“最终没报问题”，现在可以继续定位是哪一步出了问题。
项目把这种检查方法称为“最小作答”：不让模型笼统评价教程讲得够不够，而是要求它只依据教程材料，写出一个刚好能够完成练习或验收的答案，并标明每一步可以从哪里学到。无法从教程中写出的部分，才是需要继续调查的缺口。
面对五类校验练习，模型实际还原读者要完成的任务后发现：身份校验可以从 player.UserId 得到，类型校验可以从 type(payload) == "table" 得到，频率限制可以从 ADD_COOLDOWN 得到，结果下发可以从 FireClient 得到；只有业务条件缺少完整说明——reason 被发送，但服务端没有使用，也没有解释判断边界。
这个结果既找到了真正缺少的内容，也纠正了最初“删除集中说明后，五类校验全部无法学习”的过宽人工预期。
早期方案曾计划为每章维护完整的读者知识、工程状态和章节依赖关系。实验发现，这套设计维护成本很高，而且容易把两件事混在一起：读者可以继承前面章节已经学过的知识，但不能被默认拥有前面章节创建的代码、文件和场景对象。
项目最终没有继续建设完整知识图，而是保留当前章节全文、程序生成的课程目录、可以按需搜索的其他教程章节，以及可以按需查询的完整 API 资料库。课程目录只帮助模型判断“可能去哪里查”，不能直接证明某个知识已经教过。
一次实验向模型开放了 286 份、约 1.99 MB 的 API 文档，模型没有遍历全部文件，而是根据问题只读取了 RemoteEvent、World 和 Player 三份资料。这说明完整资料可以保持可访问，由 Agent 根据当前疑点按需选择。
锁定流程后，项目在三类章节中植入了五种单一缺陷，包括删除公共事件定义、提前插入高级协议、把练习改成纯复制、删除核心类型介绍，以及制造配置字段前后不一致。扫描阶段命中 5/5。
随后，两个章节共生成 26 个疑点，核验结果如下：
| 章节 | 成立 | 不成立 | 材料不足 | 完成核验 |
|---|---|---|---|---|
| 概念引入章节 | 6 | 6 | 2 | 14/14 |
| 配置数据流章节 | 5 | 5 | 2 | 12/12 |
| 合计 | 11 | 11 | 4 | 26/26 |
5/5 只能说明这五个受控问题被找到，不能等同于自然问题召回率为 100%。同样，26/26 表示所有疑点都完成了交接和核验，不表示它们全部成立。事实上，11 项被驳回，说明第二阶段不是替扫描结果背书，而是在真正重新判断。
配置字段缺陷展示了具体判断过程：配置声明使用 EffectName，后文却读取 item.EffectUnitName。读者照首表创建配置、再照后文读取时会得到 nil，随后触发非空断言，无法找到特效。这个问题不依赖外部 API 推断，沿着教程自己的数据流即可确认。
主观路线由此形成阶段方案：扫描负责扩大可能存在的教学问题，程序保证疑点不会在交接中消失，核验结合读者此前学过的内容和相关资料，逐项确认、驳回或保留未决。
主观路线和客观路线分别完成早期实验后，都形成了“先扫描、后核验”的结构。两边的扫描任务都要完整阅读同一章，也都会查看示例、变量、函数、数据流和跨章引用。区别在于，主观路线寻找妨碍读者学习的问题，客观路线提取需要检查的代码、API、命令和运行时主张。
这产生了一个合理的架构假设：如果让一个模型只阅读一次章节，同时生成主观疑点和客观核验任务，能否减少重复工作，并让两种视角互相补充？
实验开始前便确定了决策标准：如果共享扫描能够稳定保留两边的重要发现，同时减少并行运行时间或成本，就进入主线；如果只是偶尔增加一些发现，却造成另一边遗漏，或者运行得更慢、更贵，就继续保持两次独立扫描。
实验选择教程第 8 章。该章同时包含概念解释、客户端和服务端代码、完整数据流、API 主张、练习与验收要求，而且没有被此前的主观受控实验或客观扫描反复调优，适合同时观察两种扫描任务。
实验使用 Qwen 3.8 Max，建立三组相互隔离的新会话：
三组使用完全相同的章节内容和默认思考强度。A 与 B 可以并行，C 单独运行。比较内容包括重要问题覆盖、实际完成时间、人民币成本和输出是否合法。完整实验重复两轮，避免根据一次随机结果决定架构。
两轮 C 都成功生成了主观和客观两类合法结果，没有发生其中一边整体失败。下表中的 A+B 时间是两组并行后的实际完成时间，不是两次耗时相加：
| 轮次 | A+B 并行完成时间 | C 完成时间 | A+B 成本（元） | C 成本（元） | 观察 |
|---|---|---|---|---|---|
| Qwen 第一轮 | 约 12 分钟 | 约 22 分钟 | 3.4589 | 3.8487 | C 高约 11%，漏掉一项多参数传递疑点 |
| Qwen 第二轮 | 约 15 分钟 | 约 23 分钟 | 3.4841 | 4.6180 | C 高约 32.5%，重新发现首轮遗漏 |
第一轮中，B 单独发现了“多个参数能否完整传递”的客观疑点，C 没有发现；第二轮 C 又重新发现了它。与此同时，第一轮看似由 C 带来的新增问题，第二轮也可能被 A 或 B 单独发现。
因此，C 不是 A 与 B 的稳定合集。共享任务确实改变了模型的注意力分配，有时会新增问题，有时也会漏掉独立任务找到的问题，但没有稳定扩大覆盖。它还在两轮中分别比并行 A+B 慢约 10 分钟和 8 分钟，人民币成本高约 11% 和 32.5%。
项目又用 GLM 5.3 重复三组任务，观察结论是否只适用于 Qwen。GLM 能够生成合法的共享结果，但主观独立任务两次耗尽默认 32K 输出预算，需要提高到 64K 才完成，因此不能与 Qwen 做严格的成本和耗时对照。即便如此，GLM 的共享任务仍明显慢于并行独立任务，也不是 A+B 的完整合集，没有改变共享扫描不进入主线的判断。
实验没有支持把主观判断和客观判断塞进同一次模型推理。项目继续保留四个独立任务：
主观结果和客观结果继续保存在各自的 JSON 中，不合并成一份统一结论。程序和后续展示只把指向同一章节、同一段教程或同一技术主张的结果放在一起，方便下游看到它们是否互相支持或发生冲突。
例如，主观路线可能同时提出两个疑点：某个 API 无法使用，以及教程没有解释它的用途。真实编辑器如果证明 API 可以运行，前一个事实判断应当撤回；但“教程没有解释用途”仍然需要单独判断。反过来，教程写得很清楚，也不能证明其中的 API 一定正确。
双方意见冲突时，不增加第三个模型投票。能够通过当前资料或真实实验判断的，就依据实际结果修正对应判断；暂时无法判断的，就保留未决。
实验最终否定的是共享扫描，而不是主客观协作。两条路线继续独立发现和判断问题，只在展示与后续处理时互相补充。
全量审查读取一篇完整文档，从头寻找问题；Diff 增量审查读取本次修改内容，同时保留修改后的完整文档作为上下文，只检查变化及其影响范围。这里的“全量”是完整检查当前输入文档，不是宣称整个教程项目已经完成生产级审计。
当前程序已经能够接收一篇教程文档，自动准备输入、启动主观和客观扫描、检查扫描结果、继续执行两边的核验任务，最后保存两份结果。
全量流程包含四个独立任务：
当前配置由 Qwen 完成两边扫描和主观核验，DeepSeek 完成客观核验与真实编辑器实验。这是当前模型分工，不是架构必须绑定这些模型。
外层程序贯穿整个过程：保存输入版本，启动和监控任务，检查 JSON 格式和候选是否全部得到处理，记录 Session、Token、耗时与日志，并在客观实验结束后恢复受管理的实验环境。
主观结果和客观结果始终保存在各自的 JSON 中。页面可以把指向同一段教程的结果放在附近，方便阅读和标注，但不会自动把它们合并成一个答案。
如果教程只修改了几段内容，每次重新扫描整篇文档会重复支付大量成本，也可能重新报告与本次修改无关的旧问题。
Diff 流程以 Git Diff 为入口。程序将新增、修改和局部删除的文字整理为 changes.json，为每个变动分配固定编号；模型同时读取修改后的完整文档，避免只看几行变化而误解上下文。changes.json 只是程序整理出的变动清单，不是模型判断结果。
小规模 Diff 已经由修改位置缩小了搜索范围，因此主观和客观各用一个独立会话，直接完成“理解变化、查找相关内容、给出结果”，不再机械重复全量流程的四次交接。
完整旧文档不重复进入上下文，但局部删除的旧文字会保存在对应变动中。需要检查其他章节时，由模型根据当前变动继续查找，程序只负责确认每个变动是否得到处理。
当前简化流程只验证过小规模章节修改。整章删除、文件重命名和大规模移动可能影响其他章节，暂时不进入这条流程；Diff 路线的跨轮稳定性也仍需继续验证。
| 角色 | 负责什么 |
|---|---|
| LLM Agent | 阅读教程、发现疑点、选择需要查找的资料、设计和解释实验、判断问题是否成立 |
| 外层程序 | 准备输入、启动任务、检查 JSON、保证候选或变动没有遗漏、记录 Session 与耗时、归档并恢复受管理环境 |
| API 资料与真实编辑器 | 提供当前签名、代码行为、日志和实际运行结果 |
| 人工 | 处理仍有分歧或材料不足的问题，决定教程是否修改以及怎样修改 |
程序可以检查 JSON 是否完整，不能判断教学问题是否成立。模型可以解释运行结果，但不能用自己的推断替代真实编辑器的直接观察。主观和客观意见冲突时，程序只负责把相关结果放在一起，不自动将它们合并成一个答案。
项目没有为了统一流程而另造一套通用 Agent 平台。只有当真实运行反复暴露某个问题，并且程序控制能够明确改善可靠性或恢复能力时，才增加新的自动化机制。
共享扫描被否定后，系统已经形成四个独立任务。EXP-002 要验证的不是扫描能否找到更多问题，而是：四个任务能否使用同一篇文档连续运行，扫描结果能否完整交给核验，客观核验能否操作真实编辑器，最后能否得到两份结构完整的结果。
实验选择教程第 8 章。四份 JSON 均可解析，扫描清单经过程序检查后原样交给各自的核验模型，每个候选和客观任务都得到处理。
| 任务 | 模型 | 耗时 | 交付 |
|---|---|---|---|
| 主观扫描 | Qwen 3.8 Max | 9:30 | 15 个候选 |
| 客观扫描 | Qwen 3.8 Max | 15:50 | 10 个任务、21 条原文主张 |
| 主观核验 | Qwen 3.8 Max | 26:44 | 2 个成立、13 个不成立 |
| 客观核验 | DeepSeek V4 Flash | 26:21 | 3 个缺陷、7 个正确 |
全流程输出加推理共 233,128 Token，人民币成本约 10.6037 元。两次扫描并行、两次核验并行时，纯任务阶段约 42 分 35 秒；从首次启动到最后退出实际约 54 分 47 秒，其中还包括扫描交接和编辑器预检。这些数字说明运行规模和工程成本，不代表审查质量。
主观和客观结果分别保存。将两份最终结果放在一起查看并去除重复后，共涉及四个不同问题：
FireAllClients(scores[player.UserId]) 没有说明插入位置，独立照抄时 player 不在作用域；FireServer”直接称为错误，但两次试玩均成功送达。当前实验只能说明这项强断言缺少依据，不能证明所有加载顺序都安全。这四个问题仍然分别存在于主观和客观 JSON 中，不是把两个 JSON 合并成了一份报告。
主观扫描提出 15 个疑点，核验只确认 2 个，说明当前扫描为了扩大搜索范围，给后续核验带来了较高的过滤成本。由于还没有人工真值集，2/15 不能直接称为系统精确率；但它至少说明，候选数量增加不等于高价值问题增加。两项确认问题在 EXP-001 的旧扫描中已经出现，客观扫描也漏掉了旧实验曾单独提出的一些问题。
完整运行还暴露了模型之外的工程问题。教程使用 CRLF，而 JSON 引用使用 LF，程序最初把同一段文字误判为引用不一致；后来改为统一换行符后再比较。客观实验如果从 workspace/ 执行代码同步，CLI 又会向上找到外层 eggy.json，得到错误地图 ID；DeepSeek 当时自行发现并改从 workspace/project/ 执行，且没有向错误地图推送。这要求外层程序固定代码同步的工作目录。
EXP-002 证明了工程闭环可以工作，但没有证明覆盖提升。四阶段交接、真实编辑器实验和两份最终 JSON 已经跑通；新增候选是否真正扩大有效覆盖，仍需人工标注和更多章节验证。
基于第 9.2 节确定的小规模 Diff 流程，EXP-003 使用第 7 章的 8 个真实变动块进行首次端到端验证。主观任务约用时 13 分 38 秒，客观有效重跑约用时 36 分 48 秒。两个 Agent 都处理了全部变动，JSON 合法，也没有扩张到与本次修改无关的旧问题。
第一次并行运行时，主观任务正常完成，客观任务因电脑关机在交付前中断。中断只留下本地实验代码，地图仍保持基线状态。旧运行目录被完整保存；电脑重启后，程序重新确认编辑器、日志起点和工作区，并使用全新 Session 完成客观任务。这次事故实际验证了运行记录保存、环境检查和中断后重跑的流程。
主观路线沿第 6 章的预告和第 22 章的项目要求，发现删除阵营分配与出生点教学后出现了跨章节衔接断裂；但它依据过时的生成 API 资料，又错误判断 camp:GetPlayers() 和 camp.PlayerAdded 不可使用。
客观路线把新代码原样写入真实服务端文件并随试玩加载，直接观察到：
Camps:GetCamps() 返回 50 个阵营；camp:GetPlayers() 可以正常遍历；camp.PlayerAdded 会在自动分营时触发；AssignCamp(player) 返回阵营 ID；GetCampSpawnPoint(player, campId) 返回非空值。当前 EggyAPI.lua 也声明了这些成员。因此，客观路线纠正了“新 API 不可用”的事实误判，同时发现教程错误地声称 AssignCamp 和 GetCampSpawnPoint 不属于当前作者 API。主观路线则解释了删除原有教学后，第 6、7、22 章的学习安排为什么会断裂。
EXP-003 展示了双线设计的实际价值：客观路线确定技术事实，主观路线解释它对教程结构和读者学习造成的影响；两边各自保留结果，又能在出现冲突时互相纠正。
当前只验证了一次小规模章节 Diff。它证明流程可行，不证明跨轮稳定；整章删除、文件移动和大范围概念影响仍需要单独实验。
| 实验或问题 | 原始假设 | 关键结果 | 形成的决策 |
|---|---|---|---|
| 静态基线与真实编辑器 | 静态代码和 API 资料足以判断教程正确性 | API 资料、编辑器行为和历史记录互相矛盾，编辑器还存在静默失败 | 客观结论必须区分静态判断与真实运行；建立可恢复的编辑器实验流程 |
| YAML 经验记忆 | 保存历史缺陷和模型错误，可以帮助后续判断 | 记忆是否调用、何时淘汰都难以控制；上下文超过三万 Token 后仍有漏检 | 停止建设复杂记忆系统，改用面向动作的 Markdown 资料并按需读取 |
| 模型比较与客观分工 | 选出一个最强模型即可完成全部审查 | Qwen 更容易扩大检查范围，DeepSeek 更适合操作工具和深入验证 | Qwen 负责扫描，DeepSeek 负责逐项核验 |
| 报告格式实验 | 更严格、更完整的报告格式能够提高结论质量 | 格式更统一，但覆盖没有稳定提高，模型还会把精力花在填表上 | 模型只提交复查结论需要的信息，编号、合并和统计交给程序 |
| 停止规则与具体 Todo | 明确停止条件和详细计划可以控制探索并提高覆盖 | 停止提醒没有阻止 512 MB OOM；过细 Todo 使隐藏主题覆盖从 2/3 降到 0/3 | Prompt 只提供提醒，Todo 只作工作记忆；安全和交接由外层程序负责 |
| 第一个主观受控缺陷 | 删除集中解释后，模型应当报告五类内容全部缺失 | 模型返回空列表；进一步检查发现四类内容仍能从代码恢复，只有业务条件缺少支撑 | 模型结果和人工测试题都必须接受检查；引入最小作答 |
| 更强主观 Prompt | 逐项检查或只查解释能够稳定减少漏报 | 单一样本从 0/2 提高到 2/2，但耗时增加 56.1%；换题后仍为 0/2、0/1 | 停止继续堆叠 Prompt，拆分疑点发现与逐项判断 |
| 主观两阶段与按需检索 | 锁定候选并开放资料搜索，可以让遗漏位置和判断过程可见 | 五个受控缺陷命中 5/5；26 个候选全部完成核验，其中 11 项成立、11 项驳回、4 项材料不足 | 保存全部扫描候选；核验不能静默删除；课程目录加按需搜索替代完整知识图 |
| EXP-001 共享扫描 | 一次阅读同时生成主观和客观结果，可以减少成本并产生协同 | 两轮共享扫描分别贵约 11% 和 32.5%，更慢，也不是独立结果的稳定合集 | 保持主观、客观独立扫描，两份结果只在展示和后续处理时互相补充 |
| EXP-002 四阶段全量审查 | 四个独立任务能够完成交接并接入真实编辑器 | 四阶段完整运行，成本约 10.6037 元，最终涉及四个不同问题；但没有证明覆盖提高 | 保留四阶段全量流程，进入试审和人工标注 |
| EXP-003 小规模 Diff | 小规模修改可以由主观、客观各用一个会话直接审查 | 8/8 变动得到处理；电脑关机后恢复并重跑；客观实验纠正事实误判，主观路线保留教学影响 | 保留单阶段 Diff 方案，但继续验证稳定性，不扩展到整章删除和移动 |
当前系统已经形成能够自动运行、生成两份结果并进入人工检查的试审基线，但还没有人工确认的真实问题集。
人工标注不是为了替代 Agent，而是为它提供稳定的比较基准。模型和 Prompt 可以更换，但同一批人工确认的问题能够判断新方案是否真的改善了结果。
本项目处理的不是一种教程问题，而是两类需要不同方法的问题：客观路线检查代码、API 和运行时行为是否正确，主观路线检查教程是否让目标读者能够理解并继续学习。真正的难点也不是调用一次模型生成报告，而是模型、参考资料和编辑器本身都可能出错，因此模型提出的结论仍然需要检查。
实验持续改变了系统方案。客观路线发现，仅凭静态资料无法解决资料冲突和编辑器静默报错，因此必须进入真实编辑器实验，并区别对待肯定结论和否定结论。主观路线发现，一次审查既可能漏掉问题，也可能提出无法成立的判断，因此改成先扫描候选问题，再由独立会话逐项复查，需要时查询前后章节。共享扫描没有带来稳定收益，最终系统保留主观、客观两套扫描和两份结果，交给下游并列判断。
目前，受控教学缺陷实验达到5/5 检出；系统完成了一次真实章节的四阶段全流程运行，也完成了一次覆盖8 个修改块的 Diff 审查，并在电脑中断后重新冻结环境、重启会话并完成任务。当前程序已经可以接收一份教程文档，自动运行两条审查路线，并分别保存主观和客观结果。这些结果说明端到端流程已经能够运行，但不等同于生产级准确率。
下一步需要通过人工标注建立固定评测集，判断系统在真实问题上的确认率、召回能力、稳定性和人工处理成本。这个项目最终交付的，不是一份由大模型直接生成的审查意见，而是一套能够提出疑点、进入真实环境验证、保留不同判断、从中断中恢复，并继续接受人工校准的教程质量审查流程。