SKILL.md 4.96 KB

Edit Raw Blame History



name: work-graph-node-review
description: |
  给任何自规划 Work Graph 节点(Coder/Validator/planner_reviewer 自己规划出的、声明
  judgment.kind="llm" 的节点)判断"这一个节点的产出是不是真的、结构化的、完成了它被要求做的
  事",而不是叙述文字/进度汇报冒充产出。这是节点级判断,不是任务级验收——判断粒度是"这一个
  节点",不是"整个任务"。
version: 1.0.0
tags:


review
judgment
work-graph

  - self-planning
自规划节点产出复核
我在做什么、不做什么
我判断的是 Work Graph 里一个具体节点的产出是否合格——这个节点是 Coder/Validator/
planner_reviewer 自己规划出来的(task_prompt 字段描述它该做什么),不是 Planner 固定文档链
上的 brd/prd/sdd/benchmark(那是 planner-output-review 的职责,判断粒度是整批文档、发生在
Coder 开始之前一次性把关);我也不判断"整个任务是否验收通过"(那是 qa-task-validation 的
职责,任务级)。我的判断只回答一个问题:这一个节点,针对它自己的 task_prompt,给出的
content 是不是真的完成了要求的事。

我是只读判断,不执行代码、不修改文件——如果节点本身需要机械验证(比如脚本是否真的能编译/运
行),那用 judgment.kind="mechanical",不是我;我处理的是 judgment.kind="llm" 的场景,
即"这份内容好不好"只能靠语义判断,没有客观对错的机械检查方式。
判断标准:是不是叙述文字冒充产出
真实反复复现过的一类系统性失败(docs/todo/validator-test-script-narrative-output-issue.md
§6 的完整根因记录):要求"先用工具探索、再产出最终内容"的节点,模型探索完之后的收尾话术天然
倾向"汇报我刚才做了/启动了什么",而不是切换成"直接吐出最终内容"模式——即使节点自己的提示词
已经写了"不要写叙述文字",这句话作为附加在提示词末尾的格式规则,不足以覆盖"多轮工具调用之后
的收尾习惯"这个更底层的行为模式。真实复现过的原文片段:


"Launched the workflow in the background, run ID wf_.... I'll report results once it
completes; no further action is needed right now."
"The workflow completed. It authored test_....js — an independent mechanical test for
..."(描述"我做了什么",不是测试脚本本身的内容)


这些文本的共同特征:在描述"我刚才启动/完成了什么动作",而不是产出该动作本来应该产生的
内容本身。判断时把这个节点的 task_prompt 当作唯一的标尺——它要求的是代码、是测试输出、
是结构化分析,产出就必须直接"是"那个东西,而不是关于"我如何得到那个东西"的说明。单独出现的
词("workflow"、"launched")不构成判断依据本身——判断的是整段内容的性质,不要因为内容里
合理提到了"运行"、"执行"这类词就误判。
定位到具体缺口,不要给笼统判断
ok=false 时,issues 里每一条都要能回答"内容里具体哪一部分不对/缺什么",不是"整体上不够
好"这种不可操作的结论。好的判断形状是:"task_prompt 要求给出可运行的测试脚本,但 content 的
开头三段全是进度汇报式散文,直到第四段才出现看起来像代码的内容,且缺少必要的 import"——具体
到能让重新生成时明确知道该改什么。
措辞上的教训:用条件句,不用断言句
_NARRATION_RETRY_HINT(src/e2e_pipeline.py)在给重试反馈时刻意用"If your previous output
was a narrative description..."这种条件句,不是"Your output was a narrative description"这种
断言句——因为这个判断本身有误判空间:一段内容也可能只是普通的语法笔误导致机械检查失败,不是
真的叙述文字。判断时同样适用这个原则:如果不能确定内容性质就是叙述文字而不是别的问题(比如
格式错误、遗漏字段),issues 里的措辞也应该描述"观察到的具体现象",而不是给出一个可能张冠
李戴的定性指控。
跟 _NODE_REVIEW_JUDGE_PROMPT 的关系
work_graph_plan.py::_NODE_REVIEW_JUDGE_PROMPT 是这份方法论压缩成的、可以直接作为
judgment.judge_prompt 使用的机械提示词常量,被 _CODER_NODE_CATALOG 的 unit_test/
integration_check 条目引用为 suggested_judgment 默认值。这份 skill 不是重复那个常量,而是
它背后"为什么这么判断、真实失败案例长什么样"的方法论沉淀——规划节点时如果需要自己写一个
judge_prompt(而不是直接复用目录里的建议),应该参考这里的判断标准,而不是从零发明一套。
输出格式
ok(布尔)+ issues(字符串列表,ok=false 时每条都指向具体缺口)。不改写节点自己的
content,不建议节点该怎么重新生成——那是 on_fail.action 触发的重试/回退机制的事,我只
负责判断这一次的产出合不合格。