# Validator test_script 节点偶发输出叙述文字而非代码——问题记录

**日期**: 2026-08-07
**性质**: 问题记录 + 待调查,不是已确认根因的需求文档（区别于同目录下其他几份——那几份是已经定位到具体代码 bug 并修复过的,这份目前还只是"观察到的现象",根因未确定）。
**状态**: 待调查,未立项修复。

## 1. 现象

`validate_implementation_with_own_graph()`（Validator 自己的 benchmark→test_dataset→test_script 验证图）里的 `validator_test_script` 节点,连续两次真实生产运行中都输出了**叙述性文字**而不是可执行代码,导致 `check_script_compiles()` 正确拦截（py_compile/node --check 都报语法错误）,`verify_fn` 判定失败,重试一次仍然失败,最终 `ConsistencyCheckFailedError`。

两次真实发生,内容形态高度相似,都是"在描述某个 Work Node/workflow 的执行情况",不是在写测试脚本本身：

- 任务 `3605272e`（2026-08-07 03:10 UTC 附近）：`"Launched the 'graphlemon-node-f9cefb87af4c492aac738b9736d41e4e' workflow (Work Node validator) in the background, run ID wf_93345ca8-8c6. It's running asynchronously — I'll report results once it completes; no further action is needed right now."`
- 任务 `bfd3ee82`（2026-08-07 03:13 UTC 附近）：`"The graphlemon Work Node (validator) workflow completed. It authored \`test_nav_project_context_benchmark.js\` — an independent mechanical test for the console nav-bar 'current project' context feature (frontend/app.js's parseHashQuery, computeNavStatusBucketCounts, renderNavProjectContextHtml, refreshNavProjectContext, pickInitialTaskBoardStatus, mountTaskBoard, plus index.html's #nav_project_context element and style.css's .nav-count-* rules). It loads the real app.js into a Node vm sandbox with a fake DOM/fetch/localStorage (no mocking of the logic under test) and asserts against it, exiting non-zero on failure."`
- 任务 `bfd3ee82`，**同一个任务重试后第三次复现**（2026-08-07 05:35 UTC 附近）：`"It produced a runnable Node.js test script (\`nav_project_context_benchmark_test.js\`) validating U-047/U-048 (console nav-bar 'current project' context). It loads the real \`frontend/app.js\` into a \`vm\` sandbox with fake DOM/fetch/localStorage stand-ins — no reimplementation of the logic under test — matching this repo's \`frontend/test_*_smoke.js\` convention."` ——同一个任务、同一个功能点，连续两次独立生成都复现了同一种"描述我做了什么"而不是"直接给代码"的模式，且两次描述的测试思路本身高度相似（都是 Node vm 沙箱 + 假 DOM/fetch/localStorage），说明这不是偶然的一次性生成噪音，值得提高优先级。

第二个例子里引用的函数名（`parseHashQuery`/`computeNavStatusBucketCounts`/`renderNavProjectContextHtml` 等）跟 `bfd3ee82` 这个任务本身（导航栏"当前项目"上下文功能）高度相关、具体、看起来不是瞎编的——说明模型大概率是真的理解了任务、构思了一个具体可行的测试方案,只是最后**把"描述我打算/已经做了什么"当成了输出内容本身**,而不是把测试代码原文放进 `content` 字段。

## 2. 和已修复的三个 bug 的区别（避免误认为同一件事）

- 不是 `join()` 逐字符拆解那个 bug（那个已修复,产出的是"c; o; n; t; e; n; t"这种逐字符加分隔符的乱码,肉眼一看就是格式损坏；这次是完整、通顺、有实际内容的一段英文叙述,不是格式损坏）。
- 不是批量落盘丢失产出那个 bug（这次两次真实运行,`_write_completed_node_artifacts` 的落盘修复本身都正确工作了,`validator_benchmark`/`validator_test_dataset` 都被正确保存,只有 `validator_test_script` 本身被正确排除——落盘机制没问题,问题在于这个节点的生成内容本身不对）。
- 不是 API 层面的瞬时错误（529 过载、SSL 证书问题）——那些是连接都没建立成功；这次是模型正常回复了,只是回复内容的"体裁"不对。

## 3. 一个可能的根因方向（未验证,只是观察到的线索）

两次叙述内容都在讲"某个 Work Node/workflow 在跑/跑完了"——这类措辞在 graphlemon 自举场景下（`target_folder_path` 是 graphlemon 自己的仓库）非常眼熟,因为 Validator 自己就活在一套"Work Node/workflow"运行时里,它的系统提示词、可用工具、上下文里大概率充斥着这类"Work Node 执行/workflow 运行"相关的表述。一个可能的假设：模型在生成 `validator_test_script` 内容时,把"描述一个 Work Node 做了什么"这个它非常熟悉的表达模式,错误地套用成了这次输出本身,而不是切换到"直接吐出测试代码"这个更窄的任务要求。

**这只是一个待验证的猜测**,不是结论——两次样本量太小,不足以确认这就是根因,也可能是完全不同的原因（比如提示词某处有歧义、上下文过载、纯粹的生成随机性）。

## 4. 非目标（暂定,待调查结果出来后可能调整）

- 不在没有更多样本/更明确根因之前贸然改 `_VALIDATOR_DOC_PROMPTS`/相关提示词——两次样本不足以定位到底是哪句话引导偏了,盲改可能没用甚至帮倒忙。
- 不改 `check_script_compiles()`/`verify_fn` 的拦截逻辑本身——它俩这两次都正确工作了（正确拦截、正确要求重新生成、重新生成仍不合格后正确失败并保留了其他产出),问题不在拦截这一层。

## 5. 待确认的问题

- [x] 需要更多样本才能判断这是不是真的"高频"问题——**已有答案**：三次独立生成里出现了三次（`3605272e` 一次、`bfd3ee82` 重试后又出现两次，且两次描述的测试思路高度相似），不是偶然的一次性生成噪音,值得提高优先级尽快排查,不用再等更多样本。
- [ ] 如果确认是高频问题,根因排查方向：是不是 `validator_test_script` 节点的提示词本身对"describe vs. output the actual script"这件事表述不够明确？还是跟 self-hosting 场景本身（模型上下文里大量"Work Node/workflow"相关内容）有关,只在自举场景下才容易复现？
- [ ] 要不要在 `_test_script_verify_fn` 的失败反馈里,除了编译报错本身,再显式加一句"不要描述你做了什么,直接输出脚本原文"这类更直接的纠偏提示,看能不能提高第二次重试的成功率（这是一个相对低成本、可以先试的缓解手段,不需要先confirm根因）。