从一个工程方案开始

tp solution list                    # 这台机器上有哪些
tp solution show rtl-repair         # 它引用了什么，以及什么算更好
tp solution init rtl-repair         # 把它的起点复制进你的项目

一个团队要在某一件任务上把模型做好，需要的每一块在这个平台上都已经有了 —— 而这正是问题。一个 recipe、一个环境、两个 benchmark pack、一份 rubric、一套工具链、一种数据形状，是分散在六个地方的七个对象，各自都没错；把它们拼成「我们是这样做 RTL 修复的」，是每个团队都要从头再做一遍的活。他们没法互相抄的，恰恰是最花时间的那一块：验收协议 —— 对哪个基线、怎么留出测试集、至少多少道题、好多少才算更好。工程方案（Solution）就是一份声明：点名那七个，并把第八个写下来。

工程方案不运行任何东西

它不含奖励函数、不含 harness、不含训练代码。里面每一个字段都是一个名字，在安装它的那个部署上解析，平台从不执行包里的任何东西。这条边界和平台其他地方是同一条：控制面负责解析、校验、存储与调度，作业里跑什么属于你的项目或某个插件。一个把 rubric 正文嵌进去的方案，就是那份 rubric 的第二个副本，会和训练真正打分用的那份越走越远。解析不到的名字会被报成缺失，那是运维能据以行动的事实；漂移了的内嵌副本根本无法被发现。

solution.yaml

schema: tuneplane/solution/v1
name: rtl-repair
title: RTL repair and generation
summary: >
  Train a model to write and fix Verilog against a specification, and judge it by compiling the
  result and running the official testbench.
recipe: trl/sft
benchmarks: [verilogeval-v2, rtllm-v2, ifeval]
toolchain: eda-oss
data_format: spec_rtl
keywords: [rtl, verilog, hardware, repair]
acceptance:
  baseline: prompt
  metrics:
    - key: pass@1
      min_delta: 0.05
    - key: syntax_pass
      min_delta: 0.0
    - key: inst_level_strict_acc
      min_delta: 0.0
  sample_min: 120
  split_by: design
  human_review: true

字段	它点名的东西
`schema`	`tuneplane/solution/v1`。其他值一律被拒，并给出这个构建能读的 schema
`name`	叶子名，且必须和放清单的那个目录同名
`title`	必填。列表行显示的就是它
`summary`	可选的说明文字
`recipe`	一次运行从哪个 recipe 起步，`<owner>/<name>`
`environment`	任务需要环境时，`<owner>/<name>@<version>`
`benchmarks`	benchmark pack id。是多个，因为一个数字从来不是全部答案
`rubric`	没有工具能判的那部分所用的 Rubric，`<owner>/<name>`
`toolchain`	验证阶段需要的 Toolchain Profile
`data_format`	九种行形状之一
`template`	`tp solution init` 复制的子目录，默认 `template`
`keywords`	自由标签

既不点名 recipe、也不点名环境的清单会被拒：那样用户就没有任何可以起步的东西。不在九种之内的 data_format 会被拒，并附上完整列表。

每一个官方方案都对着 prompt 基线比

acceptance.baseline 接受一个模型引用，或者字符串 prompt —— 在同一个基座模型上只用提示词的基线。四个随附方案用的都是 prompt，这是刻意的。

如果在基座模型上认真写提示词就已经够用，正确的做法是把它发出去并量出来，而不是跑一次训练。 没有 prompt 基线的协议永远不会让这种情况浮出水面，于是训练任务照样被立项。

协议其余部分的判断标准是一样的：提前老老实实定下来很便宜，事后再老老实实定则不可能。

字段	它决定什么
`baseline`	一个模型引用，或 `prompt`。看过候选分数之后才选的基线不是基线
`metrics[].key`	候选必须推动的那个指标
`metrics[].min_delta`	好多少，是一个变化量而不是绝对下限。下限是对任务难度的断言，而在量出基线之前没人做得出这个断言。`0.0` 是合法的，意思是「不许退步」
`metrics[].direction`	`higher`（默认）或 `lower`。延迟和面积就属于不是越高越好的
`sample_min`	这次比较最少能压在多少道评测题上。四十道题的评测集翻掉一道就动 2.5%，所以低于样本分辨率的 delta 是带小数点的噪声
`split_by`	决定训练/评测怎么切的那个元数据字段，和 `spec.data.quality.group_key` 指的是同一件事
`human_review`	发布前是否必须有人过目。这是一个字段而不是一个假设：testbench 功能通过是证据，一个「看起来对」的 EDA 脚本不是

min_delta 不能为负。「越小越好」的指标用 direction: lower 表达，而不是写一个负的 delta。每个方案都至少声明一个 min_delta: 0.0 的护栏指标。一个在 RTL 通过率上涨、却悄悄丢掉指令跟随的模型并没有变好；它只是把一种能力换成了另一种，而且没有说出来。

随附的四个

tp solution list

方案	起步自	评测集	数据形状	工具链
`rtl-repair`	`trl/sft`	`verilogeval-v2`、`rtllm-v2`、`ifeval`	`spec_rtl`	`eda-oss`
`testbench-generation`	`trl/sft`	`verilogeval-v2-completion`	`testbench`	`eda-oss`
`eda-script-assistant`	`trl/sft`	`humaneval`、`ifeval`	`script`	`eda-oss`
`eda-log-triage`	`trl/sft`	`ifeval`	`log_root_cause`	—

rtl-repair 从「模型答了」到「有工具说它能用」的路径最短，所以在一个新部署上它是第一个值得试的。pass@1 必须比 prompt 基线高 0.05；syntax_pass 和 inst_level_strict_acc 不许退步；至少 120 道题；按 design 切分。 testbench-generation 训练模型写 bench 而不是写设计。它那两个指标故意往相反方向拉 —— 一份 bench 既要接受正确的设计，又要拒绝坏掉的设计，而 assert(1) 单看前一项就能满分。 eda-script-assistant 是公开数据最少、私有数据最多的那一个。它那两个 pack 是护栏、不是度量：它真正被判的是团队自己脚本组成的私有题集，那种东西不可能随官方方案一起发布，只能由安装它的部署自己声明。human_review 在这里是承重的 —— 能跑的脚本不等于对的脚本，它可能悄悄约束错了时钟。 eda-log-triage 不涉及仿真器、也不声明工具链，所以它是这里唯一一个没有 EDA 工具链的部署也能跑的工作流。它按 case 而不是 design 切分：同一个故障被报了两次，是一件事实。

训练之前先读协议

tp solution show rtl-repair

show 会打印这个方案引用了什么、它的数据形状，然后按人必须做决定的顺序打印协议：

baseline                 prompt
pass@1                   at least +0.05
syntax_pass              must not regress
inst_level_strict_acc    must not regress
minimum tasks            120
split by                 design
human review             required

在第一次运行之前把它冻住。这个字段的全部价值，就在于它是先写下来的。

把它搭进你的项目

tp solution init rtl-repair --into ./experiments
tp solution init rtl-repair --force          # 覆盖已存在的目录

init 把方案的 template/ 目录复制到 <into>/<name>，然后就结束了。它不提交、不配置部署，也不写下任何随后归平台所有的东西。文件落在你的仓库里、归你改；没有任何东西被上传，模板在你的容器里运行，信任级别和你自己写的任何代码一样。目标目录已存在时是拒绝而不是合并 —— 一个覆盖了一半的脚手架比两种结果都糟 —— 所以 --force 是你表示「我就是要这么做」的方式。

四个内置方案均包含起始模板。这些文件需要在你的项目中调整，并非完整实验。控制台检查服务端是否有模板目录；本地 CLI 需安装同一方案，才能执行初始化。

这个部署能不能跑某个方案

一个名字只有在有人核对它解析得到才值得发布，而这件核对恰恰是 SDK 做不到的 —— 它知道清单写了什么，却完全不知道这里有哪些。两个只读接口做这件事：

curl -H "Authorization: Bearer $TUNEPLANE_CLIENT_TOKEN" \
  https://tuneplane.your-company.com/api/solutions
curl -H "Authorization: Bearer $TUNEPLANE_CLIENT_TOKEN" \
  https://tuneplane.your-company.com/api/solutions/rtl-repair

列表给出 ready 以及没解析到的那些引用 —— 是点名而不是计数，因为人接下来要做的正是把这些装上。详情再加上每个引用的种类和说明，以及方案声明的那份验收协议。 ready 的意思是每一个名字都解析得到。少一个 benchmark pack 的方案不是「基本就绪」：验收协议点名了那个 pack，所以缺它跑出来的结果是对着别的东西量的。两个路由都是只读。它们列出服务端 SDK 随附的工程方案，加上服务端自己的 TUNEPLANE_SOLUTION_PATH 里的那些；两者都不创建方案。

工具链引用根据已注册的 Toolchain Profile 解析，同时检查是否启用。仅配置沙箱镜像不能满足具名工具链依赖。

使用控制台

打开资产 → 解决方案，点击查看方案。详情展示数据格式、输入要求、引用资产、验收协议及可复制的 CLI 命令。内置摘要提供翻译，团队编写的内容保留原始语言。团队方案使用 our-team/our-rtl-flow 这样的完整名称，详情 API 请求也使用该名称。 方案依赖齐备仅表示本部署能解析方案声明的引用，不代表模型与数据已准备、项目权限已通过、计算资源充足，更不代表已经成功运行。未能解析可能是因为依赖缺失、被停用或暂时无法读取。资产目录链接和工具链说明提供排查入口。日志归因与脚本助手除公开的通用能力评测外，还需要私有业务评测任务及评分标准。通用能力评测通过，不能证明根因判断或脚本行为正确。点击开始使用，查看协议并复制模板初始化命令。模板不存在时，页面会明确说明。 四个内置方案均支持应用到项目，在自己的项目命名空间下保存不可变的方案快照。需要绑定固定版本的基础模型、彼此独立且已加工的训练与验证数据集、私有且已封存的 Harbor 任务集（owner/name@版本，不少于协议规定的样本量，RTL 修复要求 120 个），以及可读取的业务评分标准（owner/name@修订号）。模型和数据集引用须包含平台版本或完整上游提交 SHA。这些检查针对声明的输入，不能证明内容不存在数据泄漏。通过我的项目方案重新打开快照。快照保存协议、配方摘要、输入引用、任务集摘要和评分标准修订摘要。更换输入需要新建方案。项目方案归创建者所有；接受关联作业前会重新检查项目权限，以及当前任务集和评分标准的访问权限。

提交基线作业使用自己的评测代码或镜像。填写 custom/custom 作业规范，指定已绑定的基础模型和 spec.data.taskset，不配置训练数据。独立任务集分发目前需要本地容器后端。推理与评分由自己的评测程序实现，平台不提供日志分诊评测代码。
配置候选训练预填已固定的配方、模型和数据集引用。配置资源与参数后，先解析预览，再明确确认提交。候选训练不会获得评测任务集。
各提交路径复用现有不可变提交包和确认回执。作业包包含 .tuneplane/solution.json，已接受的作业和项目方案保留相同来源信息。重试相同确认不会重复创建作业。

关联作业链接执行日志与产物。候选模型评测可选择成功训练作业或其导出步骤生成的完整 hf_export 或 merged_model。使用自己的评测程序、同一基础模型与任务集，并将 spec.model.init_from 设置为该产物的完整引用。系统拒绝不匹配的产物或执行批次。 EDA 方案还会冻结已启用的工具链配置，要求两个评测作业使用其固定摘要镜像。此检查不认证评测代码，也不在自定义作业内自动执行沙箱配置的网络或资源策略。

验收证据

选择基线和候选评测作业，点击对比当前证据。这是按需计算的结果快照，只读取各作业当前执行批次，要求：

business 轮次覆盖全部已冻结的私有评测任务，任务集和评分标准摘要匹配，split="eval"，模型引用匹配。不能存在未评分、基础设施错误或可用于训练的任务。业务成功率不得下降。
上报 snapshot.requirements 中的全部指标，遵守指定轮次、改善方向及原始单位。比例和变化量使用 0–1，而不是百分数。指标若匹配多个已声明的评测包，须在各匹配轮次分别上报；未匹配指标在业务轮次按原始单位上报。两侧评测轮次的数据集、任务集合、评分器和设置摘要必须一致，且完整评分已声明的任务总体。
复核绑定本次证据摘要。系统保留复核人、意见与证据快照；认可不能覆盖失败指标或缺失证据。重新执行、任务结果更新或资产访问被撤销后，刷新对比时旧复核不再适用。

评测程序通过现有认证观测通道上报事实。将以下代码加入自己的评测程序，在实际推理与评分之后调用。这是观测示例，不是可独立运行的评测器；task_id、actual_status 和 actual_score 来自你的代码：

import hashlib
import json
from pathlib import Path
from tuneplane import report

binding = json.loads(Path(".tuneplane/solution.json").read_text(encoding="utf-8"))
snapshot = binding["snapshot"]
checkpoint = (binding["artifact"]["ref"] if binding["role"] == "candidate_evaluation"
              else snapshot["bindings"]["model"])
report.validation_population("business", len(snapshot["business_task_ids"]))
report.validation_protocol(
    "business", dataset_digest=snapshot["taskset_digest"],
    cohort_digest=snapshot["business_cohort_digest"],
    verifier_digest=snapshot["rubric_digest"],
    settings_digest=hashlib.sha256(b"your-exact-evaluator-settings").hexdigest(),
    split="eval", checkpoint=checkpoint,
)
# After your evaluator has actually classified each task:
report.validation_outcome("business", task_id, status=actual_status,
                          training_eligible=False)
# After your external benchmark harness has computed this metric:
report.validation_metric("ifeval", "inst_level_strict_acc", actual_score, unit="ratio")

每个必需的公开评测轮次也需上报总体、协议、每个任务的分类结果及指标。任务集合摘要的计算方式为：将排序后的任务 ID 列表以 ensure_ascii=False、separators=(",", ":") 序列化成 JSON，按 UTF-8 编码后计算 SHA-256。两侧使用同一设置摘要。同一执行批次内的轮次/指标键不可修改，修正指标须重新评测；任务重试通过递增 trial_attempt 上报。每轮最多比较 10,000 个任务，超出时显示证据不足。 导出证据 JSON包含当前对比及最近 100 条复核记录。未冻结完整证据要求的旧应用需要重新创建。结果仍来自认证后的上报方；平台核验已上报证据的完整性和可比性，不独立证明公开评测实际执行过程或语义层面的数据隔离。

写你自己的

你自己的工程方案是一个目录，而不是一个发布出去的插件。平台只解析它，所以用不着注册中心：把它放进 TUNEPLANE_SOLUTION_PATH 指向的目录，按 <owner>/<name>/ 摆放，每一台需要看到它的机器和服务端都要能读到 —— 共享挂载，或者团队仓库的一份 checkout。

our-team/our-rtl-flow/
├── solution.yaml     # 上面那份清单
├── template/         # 可选：`tp solution init` 复制的起点
└── README.md

export TUNEPLANE_SOLUTION_PATH=/shared/solutions   # 里面有 our-team/our-rtl-flow/
tp solution list                                  # 它现在以 our-team/our-rtl-flow 出现在目录里

两条规则，加载目录时检查：

目录名必须等于 name。 目录叫 rtl-flow、清单里写 name: our-rtl-flow，加载不进去。
内置方案不可被遮蔽。 内置先加载、先写入者胜，所以一个叫 rtl-repair 的目录不会替换随附的那个。两个人跑「同一个」方案却拿到不同协议，对验收协议来说比对 recipe 更糟，因为不一样的那个东西是结果的定义本身。

来自 TUNEPLANE_SOLUTION_PATH 的方案以 <owner>/<name> 引用；内置的保留裸名字。多个目录在 Linux 和 macOS 上用 : 分隔。

工程方案不做什么

在依赖它之前，把边界说清楚。

验收证据不是发布门禁。 控制台对比上报结果并记录复核，不阻止模型晋级或部署。强制执行仍由 spec.evaluation.gates 承担，见运行评测。
split_by 是一个意图声明。 它点名你的切分应当尊重哪个字段。平台不会在提交时替你算泄漏 —— 哪些通了、哪些没通，见数据形状与切分。
控制台编排明确提交的作业。 平台不提供推理或评分代码，也不会自动执行整个流程。
这里没有任何东西在真实硬件上端到端打过分。 面向硬件的那几个方案指向的工具链镜像从未在 CI 里构建过，指向的评测器也没有任何本项目的 runner 跑得起来； RTL 评测写明了哪些没有被证明。

下一步

tp solution 命令参考 · RTL 评测 · 数据形状与切分 · Benchmark pack · 插件

开始

核心概念

训练模型

评测与服务

Agent 环境

扩展平台

协作

集成

参考

帮助

从一个工程方案开始

工程方案不运行任何东西

每一个官方方案都对着 prompt 基线比

随附的四个

训练之前先读协议

把它搭进你的项目

这个部署能不能跑某个方案

使用控制台

验收证据

写你自己的

工程方案不做什么

下一步

​工程方案不运行任何东西

​每一个官方方案都对着 prompt 基线比

​随附的四个

​训练之前先读协议

​把它搭进你的项目

​这个部署能不能跑某个方案

​使用控制台

​验收证据

​写你自己的

​工程方案不做什么

​下一步

工程方案不运行任何东西

每一个官方方案都对着 prompt 基线比

随附的四个

训练之前先读协议

把它搭进你的项目

这个部署能不能跑某个方案

使用控制台

验收证据

写你自己的

工程方案不做什么

下一步