项目效果
RoboDojo评测服务
本轮留下3项需要接续的问题，均沿原事项处理。已解决与已暂停的保留原状态。
项目材料：2026/10/15 04:00:00 · case 材料：2026-10-15（原快照日期）
总体完成情况
各类型 case 的完成情况
| case 类型 | 总数 | 初评达成 | 部分达成 | 受阻 | 待核 | 初评达成占比 |
|---|---|---|---|---|---|---|
| 评测执行 | 3 | 2 | 0 | 1 | 0 | 2 / 3 · 67% |
| 实验分析 | 4 | 2 | 2 | 0 | 0 | 2 / 4 · 50% |
| 信息说明 | 3 | 3 | 0 | 0 | 0 | 3 / 3 · 100% |
| 平台工程 | 2 | 2 | 0 | 0 | 0 | 2 / 2 · 100% |
case 汇总表
| case／展开依据 | 类型 | 完成情况（初评） | 结果摘要 | 人的 Review | 核对时间／用时 | token／账号 |
|---|---|---|---|---|---|---|
C16 公开OpenWAM60k首次全量回归目标与验收：核权重/seed/54配置2100局与6300视频；历史只在真实可比范围对照 完成判断原文：较好：结果及审计原文齐，平台基准仍待完善。 结果：过程交代资源等待、兼容修改、实际并发、有效进度和尾部；最终报告含逐能力/任务成绩、同权重25局配对、布局替补与独立审计。最终报告：https://qcnatfwzm13g.feishu.cn/docx/MHYedtYuiofWFWxovuRcg29DnNe 人的反馈：正常选型/接口问题；未见完成后的明确质量评价 Skill：缺少使用证据 证据缺口：已读原话题与完整最终报告；本轮整理未重跑审计。相同权重不等于全部运行条件相同：单会话→合批、release/model revision均变；不能把−4pp归因于训练。原话题链接在原话题字段。 来源 1 ↗ 完整记录 | 评测执行 | 初评达成交付评价 | 2100局完成；Score17.01，提交至完成2小时14分。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 北京时间10月13日14:23要求试跑；14:51获准回收旧模型；14:59:32提交，14:59:43首worker，17:13:23终态，17:33报告送达。提交到终态2h13m52s；交办到报告约3h10m（消息分钟精度）；初始排队11s。准备/换模/许可等待含在交办总时长，不能全算推理耗时；累计GPU小时缺测。 关联话题末次用量 2026/10/14 23:16:59 | case 待关联关联话题 15,250,697 token（近7天，共享范围）历史计费账号未记录 |
C27 Track4World60k固定600与2000局目标与验收：准确标权重、固定600和50配置2000范围，区分基础设施异常与模型失败 完成判断原文：较好（依据报告通知）：不将2000改称54配置全量，600恢复见C06。 结果：过程输出指出节点探针超时、真实进程核对、结果回收阻塞，后续明确恢复证据。600报告：https://qcnatfwzm13g.feishu.cn/docx/WUFndjDCNo4FdOx8yvycV5Minsg 2000报告：https://qcnatfwzm13g.feishu.cn/docx/YfN8dkaMdo3vCMxn3K6cPRROnod 人的反馈：有故障及身份反馈，未见对最终报告质量的明确评价 Skill：缺少使用证据 证据缺口：已读两份最终报告和原结果话题；纹理缓存错误对画面影响仍缺专项核验，独立产物审计不证明视觉语义正常。两份Run完整身份在报告；实际GPU小时和完整交办时长尚缺。C06作为本Run尾部事件保留。 来源 1 ↗ 完整记录 | 评测执行 | 初评达成交付评价 | 600与2000局均完成；分别耗时1小时33分、3小时1分。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 北京时间10月12日600提交11:58:17→终态13:31:49，1h33m32s；13:41报告。2000提交12:45:29→终态15:46:38，3h01m09s；16:09报告。2000墙钟含排队、NAS协调、回传和3次恢复，纯计算及各停顿时长未完整分离；原交办起点尚未核，不能拿11:53话题建立当起点。 | case 待关联历史计费账号未记录 |
C30 HDR-track4world评测及多模型任务维度比较目标与验收：指定HDR与正确历史基线在共同任务对比，给分项与欠缺样本/seed差异 完成判断原文：混合：补充需求后展开，不能以总分优于公开替代目标基线比较。 结果：输出停止快照、排队/执行区分、swap_T故障持续及修复；最终报告同文档保留停止历史和续跑结果。另按共同50配置/40任务比较4模型，单seed对历史三seed均值仅描述差异。报告：https://qcnatfwzm13g.feishu.cn/docx/I2dldcMrvoiFeYxSFEyc24FdnEc 人的反馈：任务维度补充、非明确差评 Skill：缺少使用证据 证据缺口：已读原结果话题和含续跑的完整报告；最终审计通过但纹理专项核验、实际合批/缓存效率未知；资源清理实绩未核，不填已释放。 来源 1 ↗ 完整记录 | 实验分析 | 部分达成交付评价 | 2000局完成；总耗时5小时34分，含约2小时依赖等待。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 北京时间10月12日17:06:53提交；17:16:34停止；17:25续跑但等待Ego；19:31:33放行、19:31:38执行；22:40:52终态、22:53报告。提交→终态5h33m59s；放行执行→终态约3h09m14s；续跑等待约2h06m。含故障与等待，非纯推理；17:07提交确认→22:53报告约5h46m。 关联话题末次用量 2026/10/12 22:39:51 | case 待关联关联话题 2,635,146 token（近7天，共享范围）历史计费账号未记录 |
C32 V0.5-5后训练12k：固定600与完整2100送检目标与验收：提交阶段：确认权重SHA/训练来源与recipe、checkpoint格式、预处理与动作/输入输出契约；注明复用或新建的适配登记及真实校验结果；报告模型服务和评测服务的资源容量、节点选择、部署状态；给对应范围的真实Run与首批有效执行证据。完成阶段：逐个核对请求范围、有效局数/异常、产物、正式计分与完整报告。历史样例中的硬件、54配置、2100局/seed不能直接套到新任务。 完成判断原文：仅能确认已回应交办，不能确认已提交或完成。 结果：已核提交确认、统一报告登记、启动故障诊断与恢复进展；暂无最终评测成绩。原任务：https://index.jiujianian.dev/?session=913b58880c031249ee26560fbeaaa31f&tab=sessions 人的反馈：酒嘉年12:03Z追问状态和卡顿、12:10Z要求恢复，详见F44；人的正式Review仍待审，未见满意确认。 Skill：缺少使用证据 证据缺口：本轮已从转发追到原执行会话，读取真实工具回执与用户消息；证据截止12:17:33Z。未介入正在进行的恢复，不把计划中的清理未启动记录当作完成；分数仍待该阶段成果及人审。 来源 1 ↗ 完整记录 | 评测执行 | 受阻提交后启动受阻；恢复进行中（12:17Z快照） | 两组已提交；截至10月15日20:17核查，尚无有效结果。 | 待审 | 材料 2026-10-152026-10-15定向补入的转发证据；分别保留10月3日和10月15日原消息时点。不是原10月12日至15日试点全量窗口的刷新。 原会话UTC：11:09:18交办，11:18:49回复两组已提交（约9m31s，非精确API提交时间）；12:02:56首阶段结论（距交办53m38s）；12:17:33报告服务恢复但有未启动派发（距交办1h08m15s）。尚无首个有效局/计算结束/最终报告时间；这些等待不能报模型吞吐。 关联话题末次用量 2026/10/16 02:47:21 | case 待关联关联话题 78,521,844 token（近7天，共享范围）历史计费账号未记录 |
C28 Ego/UMI与Standard双模型迁移效果比较目标与验收：双模型两范围均完成，baseline重算共同50配置，回写原研究表，不作单seed因果结论 完成判断原文：较好（依据原回写回执）：两组比较与研究表已补齐；仅一seed、有预训练起点和实际布局混杂，不作因果结论。 结果：两组原600/2000局评测及原研究表回写已交。10月12日20:50回执：两行全维度补齐并回读，baseline由54重算共同50配置，UMI ΔScore+0.133/ΔSR−0.067pp；Standard −0.601/+0.040pp。 人的反馈：范围澄清与基础设施问题 Skill：缺少使用证据 证据缺口：已读原结果话题；同letterbox/20%12k并不能消除预训练起点和布局差异，单seed不作因果推断。 来源 1 ↗ 完整记录 | 实验分析 | 初评达成交付评价 | 两份后训练权重完成对比，结论回填原研究表。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 10月12日13:40提交话题→20:50原研究表回写，约7h10m观察跨度，非精确交办或纯运行用时；Standard两报告19:11/19:41送达。 关联话题末次用量 2026/10/14 17:12:25 | case 待关联关联话题 6,576,844 token（近7天，共享范围）历史计费账号未记录 |
| 实验分析 | 初评达成交付评价 | 同权重修复前后配对：UMI312局、Standard282局。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 整次交办总时长本批未完整核得，不以两条报告发布时间相减。 关联话题末次用量 2026/10/13 01:57:16 | case 待关联关联话题 66,039,223 token（近7天，共享范围）历史计费账号未记录 | |
| 信息说明 | 初评达成交付评价 | 说明RoboCasa接入所需接口与剩余工作。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 实际耗时无可靠完整计时。 关联话题末次用量 2026/10/14 21:06:20 | case 待关联关联话题 3,963,554 token（近7天，共享范围）历史计费账号未记录 | |
| 信息说明 | 初评达成交付评价 | 解释从接单、运行到报告的完整评测链路。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 已知原说明22:16交付，完整起止未核。 关联话题末次用量 2026/10/14 22:16:03 | case 待关联关联话题 4,720,891 token（近7天，共享范围）历史计费账号未记录 | |
| 信息说明 | 初评达成交付评价 | 澄清两类60k权重身份及state/action语义。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 10月14日17:04/17:06给身份与语义，17:12给另一基准；不是总任务耗时。 关联话题末次用量 2026/10/14 17:12:25 | case 待关联关联话题 6,576,844 token（近7天，共享范围）历史计费账号未记录 | |
| 实验分析 | 部分达成阶段评价 | 8卡独占实测：600局54分33秒，2000局2小时29分。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 含启动和尾部、不含模型冷启；不同release限制横向解释。 关联话题末次用量 2026/10/13 05:17:03 | case 待关联关联话题 22,186,903 token（近7天，共享范围）历史计费账号未记录 | |
| 平台工程 | 初评达成交付评价，限定配方 | 三权重跨Run补位实测通过，9次补位延迟0.06—1.82秒。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 只给局部补位延迟；无整次交办统一墙钟，不能当整轮速度。 关联话题末次用量 2026/10/15 11:08:32 | case 待关联关联话题 65,837,543 token（近7天，共享范围）历史计费账号未记录 | |
| 平台工程 | 初评达成交付评价，限定配方 | Public60k实测按3→2→1→0回收，末尾回收约10—13秒。 | 待审 | 材料 2026-10-152026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。 末worker结束后回收约10–13秒；无整个请求耗时/成本。 关联话题末次用量 2026/10/15 11:08:32 | case 待关联关联话题 65,837,543 token（近7天，共享范围）历史计费账号未记录 |
需要关注什么，以及下一步做什么
NAS：生产使用尚未验收 需原事项接续，优先
发现依据与判断
原最新话题只合PR3，未生产切换；小文件互读不够。
建议采取的行动
沿原部署事项核对实际视频生成、读取与无本地副本使用。已有容量复查继续复用。
行动后的结果
当前材料未提供已执行结果，需回原工作核对。
来源 1 ↗每日回归：缺少首轮运行证据 需原事项接续，优先
发现依据与判断
方案明确，原话题尚无脚本首轮与两任务让资源验收；Public60k生命周期部分依赖已解。
建议采取的行动
沿原规则脚本事项补齐基线、资源让出与恢复的实跑验收。
行动后的结果
当前材料未提供已执行结果，需回原工作核对。
来源 1 ↗默认配置：两份说明口径冲突 认知冲突需维护
发现依据与判断
现行规范OpenWAM全系；B8历史测量文档仍写已测QZZ范围。
建议采取的行动
现行规范已覆盖 OpenWAM 全系；旧文档的窄口径仍需标成历史，避免下次误用。
行动后的结果
当前材料未提供已执行结果，需回原工作核对。
来源 1 ↗项目认识、覆盖范围与原材料
一次性试点，范围为具身评测讨论群、干活群在北京时间10月12日04:00至15日04:00的已获准来源。42条为归并后的反馈／认知主题，不是42个独立故障或原始反馈人数；31个案例独立收集。下面是截至窗口末的核对判断，处理状态以原任务最新记录为准；列为优先关注不表示已开工。本次没有新增定时扫描。人审尚未完成，沉默不计为满意。
- 沿正式运行范围和实际通知需要生成报告，不把全量完成作为所有报告的前提。
- 核对相同范围、总体与分项比较、单位、图表及原结果页入口。
- 保留原停止和术语澄清，具体新诊断沿新的明确目标。
来源：项目与反馈 · 原数据 2026/10/12 20:43:30 · 已同步
人的反馈与处理结果
先测之前那几个进程没问题，但感觉其他 4/8 进程的设计也可以写一下让我先 review，这样节奏不拖
先测之前那几个进程没问题，但感觉其他 4/8 进程的设计也可以写一下让我先 review，这样节奏不拖
Agent 的分析
原生评测方案的128路、配置矩阵及标准平台反馈/决定；原Session仍执行且已有最新预算确认，不在复盘中重启评测；不是FIP版本批准。
已记录的改动
尚无核实的修改结果
后续建议
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
来源 1 ↗这俩是不是太少了？我们之前是不是有一些相对致信的测试，说单进程环境效率比较高的是 24 环境左右，我感觉 16 环境以下的这些都可以跳过了。另外 24 环境的配置（1x24 & 2x12）感觉还是可以
这俩是不是太少了？我们之前是不是有一些相对致信的测试，说单进程环境效率比较高的是 24 环境左右，我感觉 16 环境以下的这些都可以跳过了。另外 24 环境的配置（1x24 & 2x12）感觉还是可以加上。这些流程感觉可以直接开启验证了。
Agent 的分析
原生评测方案的128路、配置矩阵及标准平台反馈/决定；原Session仍执行且已有最新预算确认，不在复盘中重启评测；不是FIP版本批准。
已记录的改动
尚无核实的修改结果
后续建议
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
来源 1 ↗这个效果还是不错的。 然后我想补一个另外的可视化，就是首先任务类型那里，你内外就不用颜色区分了，因为你已经写文字说明了嘛，也很直接。 但是我觉得后面底下的单元格背景色也可以做一些修改，就是咱们也讨
这个效果还是不错的。 然后我想补一个另外的可视化，就是首先任务类型那里，你内外就不用颜色区分了，因为你已经写文字说明了嘛，也很直接。 但是我觉得后面底下的单元格背景色也可以做一些修改，就是咱们也讨论了，其实是有五种成功率的分布。也就是百分之七十以上，二十到七十，还有后面几种，加上那个缺结果嘛。 然后我理解缺结果你留白色就行，但其他的四个，你可以规则的生成排序一下，我理解可以用红橙黄绿来表达四种类型。 这样的话也能直观地发现哪一部分任务明显是成功率很高，哪一些成功率就低了非常多。 然后先看一下这个样子好不好看，但是我觉得肯定是非常花花绿绿，所以说你那个背景色用浅色的那种。
Agent 的分析
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
已记录的改动
尚无核实的修改结果
后续建议
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
来源 1 ↗我觉得这个表的结构基本上是我想要的，但是它缺乏一个总计的那个值。 对于其他的每一个子表，其实也是一个逻辑，带一个总计其实都会有助于我看他们大概的任务，就是因为你每个任务有高有低。 但是最终在某一个
我觉得这个表的结构基本上是我想要的，但是它缺乏一个总计的那个值。 对于其他的每一个子表，其实也是一个逻辑，带一个总计其实都会有助于我看他们大概的任务，就是因为你每个任务有高有低。 但是最终在某一个具体的场景下，无论是总体还是说一个具体的方向，大家的成功率高低都可以看一下。能不能相当于为每张表都加这一行？然后另外一点就是我觉着可以对每一行的最高最低都标一下数，可能最高的标一个绿，最低的标一个红，这样。
Agent 的分析
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
已记录的改动
尚无核实的修改结果
后续建议
评测表要求总计和可视化；第二条明确认可前次效果，再提出浅色分档。局部肯定不是所有评测验收。
来源 1 ↗这个诊断可以先暂停了，因为我们得出结论可能就是 ActionSpace 那边设置的问题，跟我们评测本身没有太大关系。 所以说他们那边修改以后，分数也基本恢复了，所以我们就可以暂时不用考虑了。
这个诊断可以先暂停了，因为我们得出结论可能就是 ActionSpace 那边设置的问题，跟我们评测本身没有太大关系。 所以说他们那边修改以后，分数也基本恢复了，所以我们就可以暂时不用考虑了。
Agent 的分析
ActionSpace问题已有外部修复，要求暂停该次诊断；不把这条历史停止授权覆盖别的新故障。
已记录的改动
尚无核实的修改结果
后续建议
保留原停止和术语澄清，具体新诊断沿新的明确目标。
来源 1 ↗那要不然咱们现在实现一下。我理解这个事没有那么复杂，就是咱们在那个评测提交群。写好相关的 prompt 引导就可以了。 然后你把这些机制流程做成一个 prompt ，然后或者说 skill ，它自己
那要不然咱们现在实现一下。我理解这个事没有那么复杂，就是咱们在那个评测提交群。写好相关的 prompt 引导就可以了。 然后你把这些机制流程做成一个 prompt ，然后或者说 skill ，它自己知道完成这个监控或者开个新 session 啥的。 监控一下就行，我们不是有那个定时 task 机制逻辑嘛，然后也能写一些规则脚本，你就让他用那个机制来触发，其实我觉得就够了，不用做非常复杂。
Agent 的分析
明确要求简单接通自动报告；原串记有真实触发/回读说法。本轮只复用，不冒称事前FIP版本批准。
已记录的改动
尚无核实的修改结果
后续建议
沿正式运行范围和实际通知需要生成报告，不把全量完成作为所有报告的前提。
来源 1 ↗我觉着倒也不用考虑那么多，咱们以后就用那个固定的文档结构发就行。不一定限制那么严，但是基本的原则我都已经加到那个文档了。 其实我觉得短期暂时够用，先让大家使用着看看体验再说。 然后就是通知机制，我
我觉着倒也不用考虑那么多，咱们以后就用那个固定的文档结构发就行。不一定限制那么严，但是基本的原则我都已经加到那个文档了。 其实我觉得短期暂时够用，先让大家使用着看看体验再说。 然后就是通知机制，我想一下就固定到我们那个评测的群里边。然后谁发的这个任务，我们就艾特谁。 然后一句话结论，你自己想想总结，然后可能也附一张图，剩下的东西我们就扔文档。
Agent 的分析
报告沿既有结构、结果群通知实际发起人；原Bot回复已确认调整，通知规则和真送达分开。
已记录的改动
尚无核实的修改结果
后续建议
沿正式运行范围和实际通知需要生成报告，不把全量完成作为所有报告的前提。
来源 1 ↗我思考这个事反而有点相对来说严苛了，没必要一定要是一个完整局的跑，只要他确定，明确是一个正式的运行，或者说明确要求结果通知，咱们就可以完成这个评测。 哎，这样相对来说命中的概率大一点，大家也未必一定
我思考这个事反而有点相对来说严苛了，没必要一定要是一个完整局的跑，只要他确定，明确是一个正式的运行，或者说明确要求结果通知，咱们就可以完成这个评测。 哎，这样相对来说命中的概率大一点，大家也未必一定要非得把所有的结果跑完的才需要关注比较嘛，对吧？
Agent 的分析
正式运行/明确结果通知即可纳入报告，不以跑满2025局为前提；原串已解释并调整，不扩评测重跑授权。
已记录的改动
尚无核实的修改结果
后续建议
沿正式运行范围和实际通知需要生成报告，不把全量完成作为所有报告的前提。
来源 1 ↗有一些分析是不是稍微有些重复？ 咱们现在就是我理解其实是这样，就是说咱们要比的就是两个部分，一个是总体的比较，一个是分任务的比较。 但是呢，我们的比较都是基于现在咱们运行的这一轮评测，它到底跑多少任
有一些分析是不是稍微有些重复？ 咱们现在就是我理解其实是这样，就是说咱们要比的就是两个部分，一个是总体的比较，一个是分任务的比较。 但是呢，我们的比较都是基于现在咱们运行的这一轮评测，它到底跑多少任务，然后我们摘跟历史同样大小，以及公开搜探同样大小的那一部分的比较。 所以说你现在东西感觉就是比较了很多，但每一个都比较得不完整。 所以说咱们其实按理说是不是就比两个图，或者说三个图，就是一个是总体的，本轮同族搜塔比较，以及五类能力分拆的，这三个比较，再加上一个本轮与旧部署的。 仔细比较就够了。那这个信息塞得很多，但其实有效的信息量都比较类似。
Agent 的分析
重复比较但每份不完整；原串已统一三张主图和比较范围，不重排原文档。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗感觉这个不需要罗列了，我们那个页面其实有相关信息。但感觉页面和文档应该是双向连接的，这样不至于找不到
感觉这个不需要罗列了，我们那个页面其实有相关信息。但感觉页面和文档应该是双向连接的，这样不至于找不到
Agent 的分析
明细放结果页并双向入口；原串记已补，不重复创建报告或页面。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗官方的口径没有细粒度的拆分吗？我们能不能把官方结果拉下来然后看一下官方和我们重叠的 2025 局是什么结论
官方的口径没有细粒度的拆分吗？我们能不能把官方结果拉下来然后看一下官方和我们重叠的 2025 局是什么结论
Agent 的分析
要求按实际评测范围与官方对齐；原串已区分配置均值与同一逐局样本。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗这个表本身不错，我觉得有必要，但等价的图是不是也可以画一个，我们看大家反馈决定最终留哪个或者都要留
这个表本身不错，我觉得有必要，但等价的图是不是也可以画一个，我们看大家反馈决定最终留哪个或者都要留
Agent 的分析
先图表并留后按读者反馈选；不能把无人再评论当最终选择。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗是不是实际上就是 pp? 感觉用单位比较可读
是不是实际上就是 pp? 感觉用单位比较可读
Agent 的分析
差值用pp（百分点）提高可读性；原串已修单位。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗感觉这种开宗明义的结论部分可以画个图？你觉得这里怎么画比较合适？我感觉可以比三个： 1. 自己 2. 同族基准 3. SOTA 然后全量和分类比较都做？ 你觉得这个合理吗？咱们要不整一波
感觉这种开宗明义的结论部分可以画个图？你觉得这里怎么画比较合适？我感觉可以比三个： 1. 自己 2. 同族基准 3. SOTA 然后全量和分类比较都做？ 你觉得这个合理吗？咱们要不整一波
Agent 的分析
建议本轮/同族/SOTA图；原串已画图并保留匹配范围边界。
已记录的改动
尚无核实的修改结果
后续建议
核对相同范围、总体与分项比较、单位、图表及原结果页入口。
来源 1 ↗