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."`

第二个例子里引用的函数名（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. 待确认的问题

• [ ] 需要更多样本才能判断这是不是真的"高频"问题,还是恰好这次调试过程连续撞见了两次的偶然——建议先观察后续更多次真实运行,而不是急着改提示词。
• [ ] 如果确认是高频问题,根因排查方向：是不是 validator_test_script 节点的提示词本身对"describe vs. output the actual script"这件事表述不够明确？还是跟 self-hosting 场景本身（模型上下文里大量"Work Node/workflow"相关内容）有关,只在自举场景下才容易复现？
• [ ] 要不要在 _test_script_verify_fn 的失败反馈里,除了编译报错本身,再显式加一句"不要描述你做了什么,直接输出脚本原文"这类更直接的纠偏提示,看能不能提高第二次重试的成功率（这是一个相对低成本、可以先试的缓解手段,不需要先confirm根因）。