为 Coding Agent 构建训练轨迹Building Training Trajectories for Coding AgentsCoding Agentの学習軌跡を構築する

任务从用户需求开始，涉及表、视图、仪表盘、工作流和权限。Seed 在 Harness 中读取技能、编写参数或脚本、调用 CLI；工具返回进入下一轮上下文。训练数据需要保留这条决策与执行的因果链。Tasks begin with a user request and span tables, views, dashboards, workflows, and permissions. Inside the harness, Seed reads skills, writes parameters or scripts, and invokes the CLI. Tool results become context for the next turn. Training data needs to preserve this causal chain of decisions and execution.ユーザーの要件から始め、テーブル、ビュー、ダッシュボード、ワークフロー、権限を構築する。Harness内でSeedがスキルを読み、引数やスクリプトを書き、CLIを実行する。ツールの返り値は次のターンの文脈となる。この判断と実行の因果関係を学習データに残す。

静态图Static figure静止図

Harness 如何承载一条轨迹How the Harness carries a trajectoryHarness が軌跡を支える仕組み

Online 生成与修复共用执行底座One runtime for Online generation and repairOnline の生成と修復を支える共通実行基盤

Online 包含首次生成、运行时纠偏和评审后的有界重生成；教师监督覆盖每一次执行。这些执行共用同一个 Harness：上下文组装、工具环境、真实回执和检查点。Spec→TodoList 位于规划层，计划指导执行，问题归因更新计划。Offline 接收无需继续重生成的完整轨迹，沿依赖做编辑与核验；发现当前问题需要真实执行时，携问题与证据回流 Online。Online includes initial generation, runtime correction, and bounded regeneration after review; teacher supervision covers each execution. They share one Harness for context assembly, tool environments, actual receipts, and checkpoints. Spec→TodoList provides the planning layer: plans guide execution and attribution updates them. Offline receives complete trajectories that need no further regeneration, edits and verifies dependencies, and returns an issue with evidence to Online when real execution is required.Onlineは初回生成、実行中の修正、評価後の回数制限付き再生成を含み、教師の監督が各実行をカバーする。これらは1つのHarnessで文脈の構築、ツール環境、実際の返却値、チェックポイントを共有する。Spec→TodoListは計画層にあり、計画が実行を導き、原因分析が計画を更新する。Offlineは追加の再生成が不要な完全な軌跡を受け取り、依存関係に沿って編集・検証する。実行が必要な問題は証拠とともにOnlineへ戻す。

静态图Static figure静止図

例如，一条工作流依赖尚未创建的字段：TodoList 应先安排字段创建，再安排工作流；Harness 执行后把真实字段 ID 和返回写入轨迹；Online 在错误决策前恢复可继续执行的上下文与环境，再生成受影响后缀。若只需删除一次无副作用的失败调用并调整后文，Offline 可在核验依赖后局部编辑。涉及状态或返回值变化时，必须有对应的真实执行证据。For example, a workflow may depend on a field that has not been created. TodoList should schedule field creation first; the Harness records the actual field ID and tool response. Online restores a runnable context and environment before the mistaken decision, then regenerates the affected suffix. If the change only removes a failed call with no side effects and adjusts later wording, Offline can edit locally after checking dependencies. Changes to state or returned values require corresponding execution evidence.たとえば、未作成のフィールドにワークフローが依存している場合、TodoList はフィールド作成を先に置く。Harness は実際のフィールド ID と返却値を軌跡に記録する。Online は誤った判断の直前に実行可能な文脈と環境を復元し、影響する後続部分を再生成する。副作用のない失敗呼び出しの削除と後文の調整だけなら、Offline で依存関係を確認して局所編集できる。状態や返却値を変える場合には、対応する実行証拠が必要になる。

一次 Rollout 的执行循环The execution loop within a rollout1 回の Rollout の実行ループ

模型负责选择动作；Harness 负责组装上下文、分派工具调用、回填真实观察，并管理预算、检查点与执行账本。工具环境保存 Skills、脚本和参数文件，Bash 中的 lark-cli 连接云端 Base。下一轮决策同时依赖消息历史和此前已经改变的环境状态。The model selects actions. The Harness assembles context, dispatches tool calls, appends actual observations, and manages budgets, checkpoints, and the execution ledger. The tool environment holds Skills, scripts, and parameter files; lark-cli runs through Bash against the cloud Base. Each new decision depends on both message history and the state left by earlier actions.モデルは動作を選び、Harness は文脈の構築、ツール呼び出しの振り分け、実際の観測の追加、予算・チェックポイント・実行台帳の管理を担う。ツール環境には Skills、スクリプト、引数ファイルがあり、Bash 経由の lark-cli がクラウド Base を操作する。次の判断は、メッセージ履歴と、それまでの動作が残した環境状態の両方に依存する。

静态图Static figure静止図

初始输入包含 ThinkSP、FunctionSP、MainSP、Reminder、原始 Query 和工具 Schema；Skills 正文通过 Read 按需进入上下文。模型能看到的是工具 observation，完整 ToolResponse 和运行元数据另作审计证据。后台任务的完成通知也会补回消息。续跑时，已完成调用按 call ID 和参数哈希复用真实回执；结果不明的写操作停止执行，交给新环境重试。Initial input contains ThinkSP, FunctionSP, MainSP, a Reminder, the original Query and tool schemas. Skill bodies enter context through Read on demand. The model sees tool observations; full ToolResponses and runtime metadata remain separate audit evidence. Background completion notices also enter the message stream. On resume, completed calls reuse actual receipts keyed by call ID and argument hash. Writes with unknown outcomes stop execution and require a fresh environment for retry.初期入力は ThinkSP、FunctionSP、MainSP、Reminder、元の Query、ツール Schema から成る。Skills の本文は必要時に Read で文脈へ入る。モデルが見るのはツールの observation であり、完全な ToolResponse と実行メタデータは別の監査証拠として保存する。バックグラウンド処理の完了通知もメッセージに追加する。再開時は call ID と引数ハッシュで完了済み呼び出しの実際の返却値を再利用する。結果不明の書き込みは実行を止め、新しい環境で再試行する。

这批 Rollout 开放 Bash、Read、Write、Edit 和 present_files：读操作手册、准备文件、执行命令、交付产物。下面的真实案例只用到 Read、Bash、present_files。TodoWrite 等规划与任务管理工具属于另一套线上配置，不能用来解释这批轨迹中的动作。This rollout exposes Bash, Read, Write, Edit, and present_files: tools for reading guides, preparing files, running commands, and delivering artifacts. The case below uses only Read, Bash, and present_files. Planning and task-management tools such as TodoWrite belong to a different production configuration and do not explain actions in this batch.このRolloutで使えるのはBash、Read、Write、Edit、present_filesです。操作手順を読み、ファイルを用意し、コマンドを実行して成果物を渡します。以下の実例はRead、Bash、present_filesだけを使っています。TodoWriteなどの計画・タスク管理ツールは別の本番設定に属し、このバッチの動作には使われていません。

抽象轨迹模型Abstract trajectory model抽象的な軌跡モデル

抽象地看，每一轮都把历史消息与当前环境交给模型，由模型选择动作；Harness 执行工具并回填真实返回，形成下一轮状态。失败时保留回执与成本，在检查点恢复上下文和环境，再选择新的动作。At an abstract level, each step gives the model its message history and current environment. The model selects an action; the Harness executes the tool and appends the actual result to form the next state. A failure keeps its receipt and cost, restores context and environment at a checkpoint, and then selects a new action.抽象的には、各ターンでメッセージ履歴と現在の環境をモデルに渡し、モデルが動作を選ぶ。Harnessがツールを実行して実際の返却値を追加し、次の状態を作る。失敗時も返却値とコストを残し、チェックポイントで文脈と環境を復元してから新しい動作を選ぶ。

静态图Static figure静止図

真实 Case：两次纠偏如何改变执行A real case: how two corrections change execution実際の Case：2回の修正で実行はどう変わるか

选取在线纠偏实验中的一条库存搭建轨迹：模型读取技能，创建产品表与出入库记录表，写入样例，再创建表单、仪表盘并回读交付。实际产生 15 次模型响应，最终保留 13 轮。图中主线是保留轨迹，两次失败在对应检查点旁展开；回退后，模型重新选择动作并继续执行。This inventory-building case comes from the online-correction experiment. The model reads skills, creates product and stock-movement tables, writes examples, adds a form and dashboard, then reads back and delivers the result. Fifteen actual model responses yield thirteen retained turns. The main line shows the retained trace; the two failures branch off at their checkpoints. After rewinding, the model chooses a new action and continues.オンライン修正実験の在庫システム構築を例にする。モデルはスキルを読み、商品・入出庫テーブルを作り、サンプルを登録する。その後フォームとダッシュボードを作成し、読み返して納品する。実際のモデル応答は15回で、最終的に13ターンを保持した。主線は保持された軌跡、2つの側枝は各チェックポイントでの失敗を示す。復元後、モデルは動作を選び直して実行を続ける。

静态图Static figure静止図

第一处纠偏在 T3：数字类型码触发 12 项参数校验错误；回到创建前，模型重写字段定义，采用 text、number、select 等字符串类型，重新执行后拿到创建成功回执。第二处在 T5：--records 不受支持，产品仍为 0 条；恢复 T1–T4 的上下文，并把已有 Base 复制为工作副本、映射资源 ID 后，模型先读 --help，再按 --json / create_records 写入，成功得到 6 个记录 ID。The first correction is at T3: numeric field-type codes trigger 12 schema errors. After returning to the pre-creation state, the model rewrites the field definitions with named types such as text, number, and select, then receives a successful creation response. At T5, the unsupported --records flag leaves the product count at zero. The Harness restores the T1–T4 context, copies the existing Base into a working branch, and maps resource IDs. The model reads --help, then uses --json / create_records and receives six record IDs.最初の修正はT3で起きた。数値の型コードによって12件の引数検証エラーが発生したため、作成前に戻り、モデルがtext・number・selectなどの文字列型名でフィールド定義を書き直し、再実行で作成成功の返却値を得た。T5では未対応の--recordsにより商品は0件のままだった。HarnessがT1–T4の文脈を復元し、既存Baseを作業用分岐へ複製してリソースIDを対応付ける。モデルは--helpを読み、--json / create_recordsを使って6件のレコードIDを取得した。

两次失败尝试保留在审计日志和成本统计中，最终轨迹保留纠偏后的 13 轮。T10、T11 分别回读到 6 条产品和 6 条流水。T13 的“已完成”是模型回复，业务是否满足需求由 Judge 另行判断。这条记录展示了 Online 运行时纠偏的完整过程。Both failed attempts remain in the audit log and cost totals; the final trajectory retains the 13 corrected turns. T10 and T11 read back six products and six stock movements. The completion statement at T13 is a model response; the Judge separately assesses whether the business requirements are met. This record follows the complete Online runtime-correction process.2回の失敗試行は監査ログとコスト集計に残し、最終軌跡には修正後の13ターンを保持する。T10とT11では商品6件と入出庫記録6件をそれぞれ読み返した。T13の完了宣言はモデルの応答であり、業務要件の充足はJudgeが別途判断する。この記録はOnline実行時修正の全過程を示している。

三组 Spec 对照、定向续跑和局部编辑使用各自的固定样本与评审协议，分别报告。The Spec-input comparison, guided continuation, and local editing use their own fixed samples and evaluation protocols and are reported separately.Spec入力の比較、指示付き再実行、局所編集は、それぞれ固定したサンプルと評価方式で個別に報告します。

已做实验：Spec 如何参与规划Experiment: how Specs guide planning実施済みの実験：Specを計画にどう使うか

我们先在同一组 10 个需求上比较三种输入：只有 Query；把 Spec 放进 user 消息；把 Spec 作为非强制 reminder。三组都由 Seed 2.0 Lite 生成，最终产物统一按原始需求验收，评审输入不包含 Spec。We first compared three inputs on the same ten requests: Query only, a Spec in the user message, and a Spec as a non-binding reminder. Seed 2.0 Lite generated all three arms. Final artifacts were evaluated against the original request, without the Spec in the evaluation input.同じ10件の要件で、Queryのみ、userメッセージにSpecを追加、任意参照のreminderとしてSpecを追加、の3条件を比較した。生成はすべてSeed 2.0 Lite。最終成果物は元の要件で評価し、評価入力にSpecは含めない。

产物评审：GPT-5.5 high / Building Mix。同一批 10 题，三组各生成一次；失败 rollout 也保留在分母。token 是整组生成请求累计输入与输出，包含重复上下文，不含 Judge。Artifact evaluation: GPT-5.5 high / Building Mix. One rollout per arm for each of ten requests; failed rollouts remain in the denominator. Tokens sum generation inputs and outputs, including repeated context, but exclude judging.成果物評価：GPT-5.5 high / Building Mix。同じ10件で各条件1回ずつ生成し、失敗したrolloutも分母に残す。token数は生成リクエストの入出力累計で、繰り返し渡す文脈を含み、Judgeは含まない。

Spec 放 user 时，平均分增加 0.43，生成 token 增加 81.3%；逐题为 5 条升分、2 条持平、3 条降分。reminder 的成本低于 user 方案，但产物均分也更低。显式规划增加了可执行细节，也增加了执行长度与约束。Putting the Spec in the user message raised the mean score by 0.43 and generation tokens by 81.3%: five requests improved, two tied, and three declined. The reminder cost less than the user-message variant, but also scored lower. Explicit planning added executable detail alongside a longer execution and more constraints.userにSpecを置くと平均点は0.43上昇し、生成tokenは81.3%増えた。5件で改善、2件で同点、3件で低下した。reminderはuser条件より低コストだが、成果物の平均点も低い。明示的な計画は実行可能な詳細とともに、実行の長さと制約も増やした。

这组实验还暴露了两种质量的差别：部分产物通过验收，但轨迹在当时的过程评审中仍因严重问题得到 2 分。最终功能是否满足需求、执行过程是否适合模仿，需要分别测量。这里的历史轨迹评分不与后文的新评审协议合并。The experiment also separated two kinds of quality: some artifacts passed acceptance, while their trajectories still received 2 under the process rubric used at the time. Task completion and whether the execution is worth imitating need separate measurements. Those historical trajectory scores are kept separate from the later evaluation protocol.この実験では品質の違いも見えた。成果物が合格しても、当時の過程評価では重大な問題により軌跡が2点となる例があった。要求の達成と、模倣に適した実行過程は別々に測る。過去の軌跡スコアは、後述する新しい評価方式と合算しない。

Online：在错误发生处修复Online: repair where the error occursOnline：誤りが生じた位置で修復する

执行中的代码或参数错误，由教师提供指导，回退到错误动作前重新选择。任务结束后，完整轨迹再接受三轮独立评审：同一问题至少两票才纳入归因。语义错误保留原 Query，从错误决策前恢复状态并重新生成后缀。For code or argument errors during execution, a teacher provides guidance and the agent rolls back to choose again before the faulty action. After the task ends, three independent judge passes assess the complete trajectory; an issue needs at least two votes before attribution. Semantic errors keep the original Query and regenerate the suffix from the state preceding the faulty decision.実行中のコードや引数の誤りには教師が助言し、誤った操作の直前に戻って選び直す。タスク終了後は軌跡全体を3回独立に評価し、同じ問題に2票以上あれば原因を分析する。意味上の誤りは元のQueryを維持し、誤判断の直前の状態から後半を再生成する。

静态图Static figure静止図

能力边界问题先检查是否存在保留全部明确要求的等价改写，通过后才从头生成，并继续按原始需求评审。网络、认证等环境故障单独记录。交接给 Offline 的是无需继续重生成的轨迹，以及原 Query、真实回执、评审和修复记录。Capability limits first require an independent check that an equivalent rewrite preserves every explicit requirement. Only then does generation restart, with evaluation still anchored to the original request. Network and authentication failures are recorded separately. Offline receives trajectories that need no further regeneration, together with the original Query, real results, evaluations, and repair history.能力の限界に関わる問題は、すべての明示的な要求を保つ等価な書き換えがあるかを独立に確認する。確認後に最初から生成し、元の要求に基づいて評価する。ネットワークや認証の障害は別に記録する。Offlineには再生成が不要な軌跡と、元のQuery、実際の返り値、評価、修復履歴を渡す。

定向续跑，省下了什么What guided continuation saves指示付きの再実行は何を削減するか

在 10 条问题定向抽样的轨迹中，我们分别从同一错误位置前恢复两个独立环境：一组无指导续跑，一组接收定向指导后续跑。代码与语义各 5 条，使用 GPT-5.6 Luna xhigh，每个条件独立评审三次。For ten trajectories sampled around specific problems, we restored two independent environments immediately before the same error: one continued without guidance, the other with targeted guidance. There were five code cases and five semantic cases. GPT-5.6 Luna xhigh judged every condition independently three times.特定の問題を持つ10軌跡について、同じ誤りの直前から独立した2環境を復元した。一方は指示なし、もう一方は対象を絞った指示付きで再実行した。コード5件、意味上の問題5件で、各条件をGPT-5.6 Luna xhighが独立に3回評価した。

比较关注两个问题：指导能否避免重犯目标错误，以及续跑要花多少生成 token。轨迹按固定的 1–5 分标准评审；成本只计受影响后缀的生成，不包含教师和 Judge。20 个续跑分支中有 5 个耗尽预算，仍计入结果。The comparison asks whether guidance prevents the target mistake from recurring and how many generation tokens continuation takes. Trajectories use a fixed 1–5 grading scheme. Cost covers generation of the affected suffix, excluding the teacher and Judge. Five of the 20 continuation branches exhausted their budgets and remain in the results.比較するのは、指導によって対象の誤りを繰り返さずに済むかと、続行に何tokenかかるかです。軌跡は固定の1〜5段階で評価し、コストには影響を受ける後半部分の生成だけを含め、教師とJudgeは含めません。20分岐のうち予算を使い切った5分岐も結果に含めています。

定向指导减少了重复尝试，但收益要沿具体行为核验：代码组的 5 个目标错误，在原轨迹后段都已经自行修复；指导避免了重犯，其中 4 条仍出现其他参数错误。语义组补好了部分公式和字段，也留下了筛选与余额口径问题。Guidance reduced repeated attempts, but its effect needs to be checked against actual behavior. All five targeted code errors had already self-corrected later in the original trajectories. Guidance avoided repeating them, while four cases still encountered other argument errors. Semantic repairs restored some formulas and fields, but left filtering and balance-definition problems.指示は試行の繰り返しを減らしたが、効果は実際の行動で確かめる必要がある。コードの対象エラー5件は、元の軌跡でも後続で自己修正されていた。指示により再発を防げた一方、4件では別の引数エラーが発生した。意味上の修復では一部の式やフィールドを補えたが、絞り込みと残高定義の問題が残った。

另一个影响读数的因素是问题匹配：同一缺陷可能被三轮 Judge 写成不同描述，拆成单票后漏计。因此表中的小幅分差不作为稳定提质的证据；更少的生成 token 也需与功能保留一起检查。Issue matching also affected the readings: the same defect could receive different descriptions across judges, split into single-vote clusters, and be missed. The small score differences therefore do not establish a stable quality gain. Lower generation tokens also need to be checked alongside preservation of functionality.問題の対応付けも測定に影響した。同じ欠陥がJudgeごとに異なる表現となり、1票ずつの別クラスタに分かれて計上されないことがあった。このため小さな点差から安定した品質向上とは判断しない。生成tokenの削減も、機能が維持されたかと併せて確認する。

Offline：沿依赖关系编辑Offline: edit along dependenciesOffline：依存関係に沿って編集する

Offline 的处理对象是一条已有的完整轨迹。先确定修改会影响哪些资源状态、返回值、控制条件和文字上下文，再选择单 turn 编辑、有限片段编辑或不编辑。四类依赖可以重叠；需要真实执行的问题回流 Online，未知依赖或其他准出失败进入 Pending。Offline starts from an existing complete trajectory. It identifies affected resource states, returned values, control conditions, and textual context, then chooses a single-turn edit, a bounded segment edit, or no edit. The four dependency types can overlap. Issues requiring real execution return to Online; unknown dependencies and other release failures enter Pending.Offlineは既存の完全な軌跡を起点とする。影響を受けるリソース状態、返却値、制御条件、文章文脈を確認し、単一ターン編集、限定区間編集、編集なしから選ぶ。4種類の依存関係は重なり得る。実行が必要な問題はOnlineへ戻し、依存関係不明やその他の受け入れ失敗はPendingに置く。

静态图Static figure静止図

例如，删除一个无副作用的失败调用后，后文的“刚才失败，所以重试”也需要重写；若修改字段创建参数，后续使用的字段 ID、公式和视图也可能受影响。动作变化必须有相应的真实执行证据，不能把失败回执改成成功。清洗同样保留信息时序，不把事后知道的结论提前写入决策。For example, deleting a failed call with no side effects also requires rewriting later statements such as “that failed, so retry.” Changing field-creation arguments may affect field IDs, formulas, and views downstream. Action changes require matching real execution evidence; a failed result cannot simply be rewritten as success. Cleaning preserves information order rather than inserting later knowledge into earlier decisions.例えば副作用のない失敗呼び出しを削除した場合、後の「失敗したので再試行する」という記述も直す必要がある。フィールド作成の引数を変えれば、後続のID、数式、ビューにも影響し得る。操作の変更には対応する実行証拠が必要で、失敗結果を成功に書き換えることはできない。クリーニングでも情報の順序を保ち、後から得た知識を過去の判断に挿入しない。

GPT-5.6 Luna xhigh：两个修前 / 修后配对，加一个未修改原轨迹，共 15 次有效评审。问题计数的变化涉及未修改事实的票数波动，不能直接解释为修好或引入了问题。GPT-5.6 Luna xhigh: two before/after pairs and one unchanged original, totaling 15 valid evaluations. Issue-count changes involved vote variation on unchanged facts; they do not directly measure defects fixed or introduced.GPT-5.6 Luna xhighで、修正前後2組と未変更の1軌跡を合わせて15回の有効評価を得た。問題数の変化には、変更していない事実への投票変動が含まれるため、そのまま修正や新たな欠陥の数とはみなせない。

当前样本主要覆盖文字与简单控制依赖。构造反例进一步发现，换一种说法引用已删除的失败、提前声称未来操作成功，仍可能绕过校验。资源状态和返回值传播将是后续测试的重点。The current samples mainly exercise text and simple control dependencies. Constructed counterexamples showed that paraphrased references to a deleted failure and premature claims of future success could still pass validation. Resource state and propagation of returned values are the next testing priorities.現在のサンプルは主に文章と単純な制御依存を扱う。反例を作ると、削除済みの失敗への言い換えた参照や、将来の操作を先に成功と述べる記述が検証を通る場合があった。今後はリソース状態と返り値の伝播を重点的に試す。

从轨迹到训练样本From trajectories to training examples軌跡から学習サンプルへ

当前准出规则按问题多数票计算分档：有严重问题为 2 分，仅轻微问题为 3 分，无问题为 4 分；无问题且至少两轮效率评审为 high 时为 5 分。4/5 分轨迹再通过真实性与格式检查。评分、产物验收和训练格式承担不同检查职责。The current release rubric aggregates issue-level majority votes: severe issues yield 2, minor-only issues yield 3, and no issues yield 4. An issue-free trajectory earns 5 when at least two efficiency reviews rate it high. Scores 4/5 then require authenticity and format checks. Scoring, artifact acceptance, and training-format validation serve different purposes.現在の受け入れ基準は問題単位の多数決で段階を決める。重大な問題があれば2、軽微のみなら3、問題がなければ4。問題がなく、効率評価が2回以上highなら5となる。4/5点の軌跡にも真正性と形式の確認を行う。スコア、成果物の検収、学習形式の検証はそれぞれ役割が異なる。

训练时，把一条多轮轨迹展开成多道“看到这里，下一步该做什么”的样本。每道样本保留完整历史，只训练当前 assistant 轮；原生思考也只保留当前轮。一批 207 条轨迹按原始 Query 分为 186 条训练与 21 条测试，训练侧展开为 5,458 个目标轮。按 Query 切分可以让同一任务的不同轨迹留在一侧，测试不参与训练或选模型。Training expands each multi-turn trajectory into examples of “given the history so far, what comes next?” Each retains the full history and trains only the current assistant turn, with native reasoning kept only for that turn. A batch of 207 trajectories was split by original Query into 186 training and 21 test trajectories, yielding 5,458 training targets. Grouping by Query keeps variants of one task on the same side; the test set is excluded from training and model selection.学習では、多ターンの軌跡を「ここまでの履歴を見て、次に何をするか」というサンプルに展開します。各サンプルに完全な履歴を残し、現在のassistantターンだけを学習対象にします。ネイティブな思考も現在のターンだけを残します。207軌跡を元のQuery単位で学習186件・テスト21件に分け、学習側から5,458の対象ターンを作りました。同じタスクの別軌跡は片側にまとめ、テストを学習やモデル選択には使いません。

新一轮在线对照从同一 Query 各自 fresh 生成：普通生成，对比教师纠偏及后验修复，先检查 10 对再扩到 100 对。这样可以把重新生成本身的收益，与修复机制的收益分开。接下来的判断标准是：同一需求上的功能保留、可用轨迹比例，以及包含教师和 Judge 的完整成本。The next online comparison starts fresh from the same Query in each arm: ordinary generation versus teacher correction and post-trajectory repair, checking ten pairs before expanding to one hundred. This separates the benefit of regeneration itself from the repair mechanism. The next measures are retained functionality on the same requests, the share of usable trajectories, and full cost including teacher and judge calls.次のオンライン比較では、同じQueryから各条件を新規生成する。通常生成と、教師による修正および全体評価後の修復を比較し、10組を確認してから100組へ広げる。再生成自体の効果と修復機構の効果を分けるためである。今後は同じ要求での機能維持、利用可能な軌跡の割合、教師とJudgeを含む全コストを測る。

方案设计：Spec → TodoListDesign: Spec → TodoList設計：Spec → TodoList

规划工具与普通执行工具共用 Harness 的调用、回执与记录机制。执行返回推动 TodoList 状态更新；Judge–Fix 的归因推动计划修订。需要重新执行的修改进入 Online；已有轨迹中可验证的局部修改按 Offline 处理。TodoList 的完成标记始终要能追到真实动作与回执。The planning tool shares the Harness’s call, receipt, and recording mechanism with execution tools. Tool results update TodoList state; Judge–Fix findings drive plan revisions. Changes requiring new execution go through Online; verifiable local changes to an existing trajectory follow Offline. TodoList completion marks must remain traceable to actual actions and receipts.計画ツールも通常の実行ツールも、Harness の呼び出し・返却・記録の仕組みを共有する。実行結果で TodoList の状態を更新し、Judge–Fix の原因分析で計画を改訂する。再実行が必要な変更は Online、既存軌跡内の検証可能な局所変更は Offline として扱う。TodoList の完了印は、実際の動作と返却値までたどれる必要がある。

Spec 提供业务对象、约束和依赖，TodoList 将其组织成可更新的执行计划。规划工具维护任务顺序、完成状态和执行依据，让计划随真实工具返回更新。这是本方案采用的规划结构；前面的三组实验比较的是 Spec 的输入位置。Specs provide business objects, constraints, and dependencies; a TodoList organizes them into an updatable execution plan. The planning tool tracks task order, completion status, and execution evidence, updating the plan as actual tool results arrive. This is the planning structure adopted in our design; the three-arm experiment above compared where to place the Spec.Specが業務オブジェクト・制約・依存関係を定義し、TodoListが更新可能な実行計画にまとめる。計画ツールでタスクの順序、完了状態、実行の根拠を管理し、実際のツールの返り値に応じて計画を更新する。これが本設計で採用する計画構造であり、先の3条件の実験ではSpecの入力位置を比較した。

静态图Static figure静止図

Judge–Fix 将同时检查计划、实际动作及二者的一致性。例如，工作流依赖的字段尚未建立，就修正 TodoList 的前置任务和执行顺序，并重新生成受影响的执行片段。保留计划修订、工具调用与真实回执，经核验后形成显式规划与执行的训练数据。Judge–Fix would assess the plan, actual actions, and their consistency. If a workflow needs a field that has not yet been created, for example, the repair would revise the TodoList’s prerequisites and task order, then regenerate the affected execution segment. Plan revisions, tool calls, and actual results would be retained and verified as training data for explicit planning and execution.Judge–Fixは計画、実際の操作、両者の整合性を評価する設計とする。例えば、ワークフローが依存するフィールドがまだ作られていなければ、TodoListの前提タスクと実行順序を修正し、影響を受ける実行区間を再生成する。計画の修訂、ツール呼び出し、実際の返り値を保存・検証し、明示的な計画と実行の学習データにする。

验收仍以原始 Query 为准。模型生成的 Spec 和 TodoList 保留为可修订的计划及过程证据，不新增用户要求；完成标记需要对应实际执行。对照实验将比较有无 TodoList 时的任务完成率、依赖与顺序错误、可用轨迹比例及完整成本。这条设计的收益待后续实验验证。Acceptance would remain anchored to the original Query. Model-generated Specs and TodoLists would be revisable plans and process evidence, without adding user requirements; completion marks would need to reflect actual execution. A controlled comparison with and without a TodoList would measure task completion, dependency and ordering errors, usable-trajectory yield, and full cost. The benefits of this design remain to be tested.受け入れ基準は引き続き元のQueryとする。モデルが生成したSpecとTodoListは修正可能な計画および過程の証拠として残し、ユーザー要件を追加しない。完了の印には実際の実行が対応する必要がある。TodoListの有無を比較し、タスク完了率、依存関係や順序の誤り、利用可能な軌跡の割合、全コストを測る。この設計の効果は今後の実験で検証する。