prompts: 改第 1 轮开轮到选批这一段的研究者提示词(任务书 14 第一块)
依据参考项目 5 次高分运行第 1 轮的真实记录诊断(同轮撞车、预测锚定前一个候选、 挑刺被要求不谈机制、"罕见"判断无依据、被退回时为过检查改设计、单向偏差提示、 因子依赖与捆绑、角色提示词过长重复)和三份再调研(提案多样性、挑刺与回应、范围预测)。 - researcher.md 瘦身 6836→4386 字:去掉领域相关例子和参考项目经历,三个数改为先看参照、 读路径、对称看往轮偏差,退回时只改原因指出的那一处 - proposal:点明同轮撞车的处境、"同一条改法"的定义、因子依赖那一格、捆绑三种处理 - 两次预测:删掉引导看已交数和"不用推演代码";第二次先说新看到了什么 - critique:先拆成必须成立的几件事对照代码,问题改为值得想的问题,四个不同领域的例子 - response、unification:只凭证据改不改,防让步与护短,采纳要对应到改动 - vocab 字段说明只改措辞(1118→1132 行) 泄露自查关键词搜索无结果;npm run check、npm test(420)通过。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
+16
-25
@@ -1,38 +1,29 @@
|
||||
# 回应挑刺、写定冻结协议
|
||||
|
||||
你的提案成了一个候选,别的研究者对它提了意见(材料"本任务要处理的东西"里有你的原提案和针对它的全部挑刺)。现在要把它写定:答复每一份挑刺,改你认为该改的地方,再把实现拆成一条条条款。写定以后它叫冻结协议,不能再改;之后每位研究者对着它估分数,实验员照着它写代码,核验员照着它逐条核对。
|
||||
你的提案成了一个候选,别的研究者对它提了意见(材料"本任务要处理的东西"里有你的原提案,"本任务要答复的挑刺"里有针对它的每一份挑刺)。现在要把它写定:答复每一份挑刺,改你认为该改的地方,再把实现拆成一条条条款。写定以后它叫冻结协议,不能再改;之后每位研究者对着它估分数,实验员照着它写代码,核验员照着它逐条核对。
|
||||
|
||||
### 采纳还是不采纳
|
||||
## 改还是不改
|
||||
|
||||
答复每一份挑刺之前,先想清楚是采纳、部分采纳还是不采纳。意见可能对,也可能看错了代码。按代码和研究记录判断,不按意见说得多肯定。两头都会坏事:对真问题视而不见,协议就带着洞去跑;把对的提案改错,跑出来的也不再是你想检验的东西——两种都会让这一轮作废。
|
||||
改不改,只看你能不能指出代码、运行记录或协议里的哪一处,证明这条意见对或不对。意见说得多肯定、有几个人提,都不是理由。
|
||||
|
||||
- 采纳的,说改在哪:"采纳:协议的'什么时候停'改为连续 50 轮没有改进或满 2000 轮即停,条款 c3 同步写明。"
|
||||
- 不采纳的,说出依据:"不采纳:意见认为随机种子会随运行变化,但基线代码在入口处固定写死了种子(read_source 可查),两次运行相同,不构成混杂。"
|
||||
- 部分采纳的,说清采纳了哪一半、另一半为什么不改。
|
||||
- 意见指出"停止条件不具体",就在协议和条款里写死判据和上限,不要只在答复里说"会注意"。
|
||||
- 意见说某个因子其实是两件事,你同意就拆成两个因子;拆完超过因子数上限,就把其中一件删掉、留到下一轮再提,不要为了塞进上限又捆回去。不同意,说出它为什么离了另一半就说不通。
|
||||
- 意见说某条保障其实会改分(按系统提示词"因子与保障"一节的拦、补、改去问出来的),先自己把那几个问题再答一遍,读路径读到代码里。同意就把它从保障清单挪进因子清单(写明关掉时换回什么),或者改成真正不改分的写法——修到刚好合法、退回基线、或者报错;不同意,说出你凭什么认为评测本来不收它挡掉的东西、或者它补上去的只是基线做法。上一份研究里,作者以"修复只在罕见情形触发"为由留下了一道零容差门槛,结果它挡掉了一整类评测本来会收的候选。
|
||||
- 意见说某个算出来的数不对,不用验算谁对:把这个数换成由代码按规则算出,答复"采纳:改为由规则……算出"。意见担心运行可能不合法,也不用推算误差:要么加一条保障——只把答案修到刚好合法、或直接报错,不另交一个新答案——要么在协议"什么运行不算数"里写清。
|
||||
两种相反的倾向都要防。一种是被质疑就让步:意见可能看错了代码,顺着改,跑出来的就不再是你想检验的东西。另一种是护着自己写的东西:对真问题视而不见,协议就带着洞去跑。两种都会让这一轮的结论作废,所以每条都回到代码里去看。
|
||||
|
||||
挑刺里标着"(推测)"的判断,你同意也好、不同意也好,它仍是推测:答复里不要把它写成已核实的事实。你核实过了(读了代码、查了运行),就写清核实的是什么。
|
||||
几种常见的意见:
|
||||
|
||||
一份挑刺里如果有几条意见,在同一个答复里逐条说。
|
||||
- 说某个因子其实是两件事:你同意,就拆开;拆完超过因子数上限,把其中一件删掉、留到下一轮再提,不要为了塞进上限又捆回去。不同意,说出它为什么离了另一半就说不通。"受上限约束拆不动"不是不拆的理由。
|
||||
- 说某条保障其实会改分:先自己把系统提示词"因子与保障"那几问再答一遍,读到代码里。同意,就把它挪进因子清单,或者改成真正不改分的写法——修到刚好合法、退回基线、或者报错;不同意,说出你凭什么认为它挡掉的东西评测本来不收、或者它补上的只是基线做法。
|
||||
- 说某个写死的数不对:不用验算谁对,把这个数改成由代码按规则算出。
|
||||
- 担心运行可能不合法:不用推算误差,要么加一条只修到刚好合法、或直接报错的保障,要么在协议"什么运行不算数"里写清。
|
||||
|
||||
### 只交改动了的部分
|
||||
## 只改挑刺指到的地方
|
||||
|
||||
你的原提案就是底稿。改了哪一块,就把那一块整块重写进 `changes`:因子清单(`factors`)要改就写改后的完整清单,保障清单(`safeguards`)要改也写改后的完整清单,指标要改就把 `metrics` 的 `defined` 和 `reused` 一起写成改后的完整清单。改指标时留意"测不到时怎么办":你的协议在某种情形下会让某个指标写 null,就别给它选 `invalidateRun`;改成引用别人登记的指标时,它的档位跟着原登记走(材料的指标清单里写着),对不上就换一个或自己登记一条 `recordMissing` 的。没改的不写;一处都没改就交空对象 `{}`。不在挑刺意见之外借机加新的改动:新想法下一轮另提,否则这一轮检验的就不是大家挑过刺、估过分的那份东西了。
|
||||
你的原提案就是底稿,只把改了的那几块重写进改动里。不在挑刺意见之外借机加新的改动:新想法下一轮另提,否则这一轮检验的就不是大家挑过刺、估过分的那份东西了。你提案时交的作者自评仍然封存着;挑刺以后看法变了,在第二次预测时照新的看法给。
|
||||
|
||||
你提案时交的作者自评三个数不能在这里改,它仍然封存着。挑刺以后你的看法如果变了,在预测那一步你会和别人一样重新给数,那时照你的新看法给。
|
||||
## 条款
|
||||
|
||||
### 条款
|
||||
把实现拆成条款,每条一件实验员要做的事。核验员会逐条对照代码,所以每条都要能单独核:
|
||||
|
||||
把实现拆成条款:每条一件实验员要做的事,写明落在哪个文件。核验员会逐条对照代码,所以每条都要能单独核:
|
||||
- 好:"`router.py:pick_backend`:某台后端最近 30 秒的平均响应时间超过其余后端中位数的两倍时,10 秒内不再给它派新请求。"
|
||||
- 坏:"按提案实现派发改动。"
|
||||
|
||||
- 好:"`solver.py:local_search`:步长初值取可行区域边长的 1/10,连续一轮没有改进就减半,小于 1e-6 时停止。"
|
||||
- 坏:"按提案实现搜索改动。"
|
||||
|
||||
位置写 `"文件"`、`"文件:行号"` 或 `"文件:函数名"`:只写一个行号或一个函数名,不写 `25-36` 这样的范围;文件和函数必须在基线代码里真实存在,拿不准就用 `read_source` 读基线核实。条款之间不能互相矛盾;不要求改任务自带的评分和校验程序,也不要求改最终指标的算法。条款不让实验员运行求解去核对什么。
|
||||
|
||||
## 交什么
|
||||
|
||||
逐条答复(材料"本任务要处理的东西"末尾"本任务要答复的挑刺"列出了针对这个候选的每一份挑刺,每份一条答复,`critique` 照那里的挑刺编号逐字写;研究记录里别的评议提交针对的是别的提案,不用答复)、实现条款(`clauses`,以编号 c1、c2……称呼)、需要时的改动(`changes`)、答复正文(`body`:逐条答复之外要补充的话,没有就写"无")。程序把改动叠到原提案上,得到冻结协议;答复不进冻结协议,原样和它一起给之后预测的人,对照着挑刺原文读。
|
||||
文件和函数拿不准是否存在,用 `read_source` 读基线核实。
|
||||
|
||||
Reference in New Issue
Block a user