iomgaa
b02cd233b4
新写诊断解释与实验、诊断预测、诊断实现、修复、核验五份任务提示词；角色提示词与 proposal 只加几句。 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
41 lines
4.2 KiB
Markdown
41 lines
4.2 KiB
Markdown
# 诊断：写解释和实验
|
|
|
|
每一轮提案之前，先对当前基线做一次诊断：你们每人写几条解释和几个实验，程序把合并后选中的实验在一次正式运行里一起跑完，结果放进本轮提案和之后每个任务的材料。你交的东西有三类读者：别的研究者读它给预测，实验员照它写代码，之后写提案的人拿实测结果去对照你的解释。
|
|
|
|
这一步不为拿分。诊断实验的答案不会成为新基线，它的用处是让大家在提案之前知道：这份程序现在卡在哪，哪个方向还剩多少空间。
|
|
|
|
## 诊断问的是剩下的空间在哪
|
|
|
|
不是"上一步的功劳怎么分"。做法是在当前的程序上只动一处，看分数怎么变。动法不同，回答的问题也不同，分数的变化只回答对应的那一问，不往别的问题上推：
|
|
|
|
- **换成明显更强的版本**（不用管它放进正式评测会不会太慢），问的是"这一步后面还藏着多少"。语音转写系统每次只保留少数几个候选句往下搜，把候选数放到很大：错误几乎不变，说明搜索不是瓶颈，该看别处；错误大降，说明空间在这一步里。
|
|
- **拿掉它**，问的是"这一步现在撑着多少"，和上一问是两件事。配送调度里把"同路订单合并"这一步拿掉，分数掉得很少，只说明现在它撑得不多，不说明把它做得更好也没用。
|
|
- **换一种做法**，问的是"同一件事换个做法，结果是不是另一个样"。
|
|
- **放宽一个限制**，问的是"这个限制到底卡了多少"。推荐系统的召回要在 50 毫秒内返回，把时限放宽一倍，看分数动不动。
|
|
|
|
## 先读到什么，再想到什么
|
|
|
|
先读基线的代码、它交出的答案和各项指标，别先有答案再找证据。读完盘点：这份程序分几步，答案受哪些量、哪些限制、多少时间制约，分数可能卡在哪几类地方。每一类都先当作可能，再用你读到的现象收窄到真觉得的那一两条。
|
|
|
|
## 解释：写成能被推翻的
|
|
|
|
每条解释说清三件事：为什么卡在这里，剩下的空间大约在哪，什么样的实测会推翻它。第三件写不出来，说明这条解释还不能被检验，先把它改具体，改到能说出"如果某个实验里看到什么，我就错了"。
|
|
|
|
交一条就够。只有你真有第二个不同的判断才写第二条：你的主判断如果错了，最可能错在哪？答得出来，就写成第二条。读同一份材料，几个人容易想到同一处，和别人不一样很正常。
|
|
|
|
诊断的结论可能很朴素：现有做法已经接近它自己的上限，或者只是某个设定值还有调整的余地。这些都是正常结果，不必预设答案是"换一个大方向"。
|
|
|
|
以前被否掉、挑下来或没采纳的路线，当时给的理由多半没有实测过，只是一种看法。读研究记录和信念本时留意这类理由：哪些有运行结果撑着，哪些只是推理。没测过的那些理由本身就可以设计成一个诊断实验。
|
|
|
|
## 实验：只动一处，能把解释分开
|
|
|
|
**不同解释对它的预测差得远，才值得测。**大家都预测"涨不了多少"的实验，测了也不改变下一步。你们是同一个模型读同一份材料，谁都想得到的实验别人也会交，合并后只算一个；意见可能不一致的地方最值得测，想一想你的解释和别人可能写的解释，在哪个实验上会给出不同的结果。
|
|
|
|
动手写之前，对每个实验先问："如果我的解释错了，这个实验的结果还会不会一样？"会一样，它就分不开你的解释和别的解释，换一个动法。每个实验的几种可能结果，各自排除哪几条解释，在正文里正面写出来；有分不开的部分，也如实写明。
|
|
|
|
**只动一处。**动两处，分数变了就归不到哪一处。想测两件事，写成两个实验。
|
|
|
|
**交出能判分的答案，用时放得进分到的那份时间。**一次运行里的所有实验平分总时限，到时直接被杀；没跑完的实验记"证据不足"，什么也说明不了。"更强的版本"不用顾虑正式评测的时限，但要选一个在分到的时间里跑得完的规模。
|
|
|
|
实验正文里不写自己估的分数，分数在下一步交。
|