InfoRSI/docs/调研/提示词.md

提示词怎么写：调研结论

2026-10-03 第零轮两次真实测试后，监督者为改提示词派子 Agent 做了两次调研。一次查同类系统"让模型提出方向"那一步的提示词怎么写，一次查写得好的 skill 和系统提示词。这里只记结论和出处。

出处路径相对 /home/iomgaa/Projects/RivalBits/reference/（参考项目克隆的同类系统源码和论文），只读。参考项目自己早先的同类调研在 /home/iomgaa/Projects/RivalBits/research-wiki/reference/ 下：调研_提示词写作准则.md、调研_人写的提示词与skill.md、调研_skill写法范例与现状体检.md、调研_让研究者真正独立.md。

一、第零轮测出来的教训（本项目自己的证据）

问题	证据	改法
提示词里的例子会被照抄	写入口的提示词里唯一的"好例子"，本身就是一条好路线（固定圆心求半径）。3 次运行 9 位研究者，第 1 个入口都照它写，连句式都一样	例子换成和题目无关的领域，而且给几个类型不同的
提示词泄露解法	研究者角色提示词和提案、挑刺、解释、收尾等任务提示词里，写满了参考项目跑填圆时的具体做法（线性规划、结构起点、扰动后重跑优化、多起点 SLSQP）。5 条关键想法泄露了 4 条	全部换成别的领域，或者写成和领域无关的抽象说法
唯一一个"没人站的路"的例子，会把所有人推到那条路上	讨论提示词举的是"没人去看评测"，结果每次运行都有人写评测入口	只描述形状，不点名方向
去掉泄露和锚点后，模型自己想得到好方向	改提示词后，"联合优化"3 次都出现在入口里（改前 0 次）	—
模型偏爱自己写的东西	6 次运行 18 位研究者，认领时都把自己写的入口排第一	记作现象；入口不约束后面的提案，暂不改方法

二、同类系统怎么写"提出方向"

• 例子一律用别的领域，或者不给。
  • OpenEvolve、ShinkaEvolve、alpha-research 的格式示例都是矩阵乘法（openevolve/openevolve/prompt/templates.py:48-60、ShinkaEvolve/shinka/prompts/prompts_diff.py:22-37）。
  • CodeEvolve 用 exp 函数，并写"Avoid Over-fitting … The goal is a new perspective"（codeevolve/src/codeevolve/prompt/template.py）。
  • AlphaEvolve 的填圆提示只有题目、接口、判定和时限，没有方法提示和示例（alphaevolve_repository_of_problems/.../packing_circles_max_sum_of_radii.ipynb 第 11 个 cell）。
  • AI-Scientist v1 把种子例子当作"你已经提过的"放进存档，例子变成了"别再重复"的清单（AI-Scientist/ai_scientist/generate_ideas.py:19-23, 99-102）。
  • 只写一句"别照抄例子"不够（papers/AnchoringLLM-Lou_2412.06593.pdf："Ignoring Anchor Hints … not sufficient"）。
• 先盘点有哪几类做法，再挑。
  • EvoX 要求"span at least two distinct approach families. Don't anchor on one paradigm"（skydiscover/.../evox/utils/variation_operator_generator.py:25-125）。
  • AdaEvolve 先问"决策变量是什么、连续还是离散、彼此怎么依赖"，再要求几个想法"DIFFERENT types, NOT variations of the same approach"（skydiscover/.../adaevolve/paradigm/generator.py:361-403, 528-541）。
  • DeepScientist 先发散 6–12 个，"If all surviving candidates belong to the same mechanism family, widen once"（DeepScientist/src/skills/idea/SKILL.md:343-344）。
  • 证据最强的是"先列一长串，再改得不一样"的分步写法（papers/PromptingDiverseIdeas-Meincke_2402.01727.pdf）。
  • 越线的反例：EvoX 那段写着"The FULL joint optimization over all these variables is the real problem"，AdaEvolve 的示例写着"Use scipy.optimize.minimize with SLSQP"。这两处已经是在给答案，我们不能这样写。
• 框定直接决定方法族。
  • OpenEvolve 第一阶段要求"写显式构造，不要写迭代搜索"，卡在 2.377；第二阶段改成"trying fundamentally different approaches"才到 2.634（openevolve/examples/circle_packing/config_phase_1.yaml:24-34、config_phase_2.yaml:24-35）。
• 几个人用同一个模型时怎么拉开。
  • co-scientist 每次随机抽推理方式（第一性原理、类比、反事实……）（open-coscientist-agents/.../reasoning_types.py:4-14）。
  • ShinkaEvolve、ThetaEvolve 随机抽系统提示（ShinkaEvolve/shinka/prompts/prompts_full.py:35-153）。
  • DMAD 证明"给不同的推理方法"比"只换人设"有效（papers/DMAD-BreakingMentalSet_ICLR2025.pdf）。
  • 先闭门写能减少锚定（papers/DiversityCollapseMAS-Ideation_2604.18005.pdf）。

三、写得好的 skill 和系统提示词的共同原则

1. 先讲处境和目的，再讲要求。 说清这一步在做什么、交给谁读、做得好是什么样（system_prompts_leaks/Anthropic/anthropic-interviewer.md:4-10；skills/skills/frontend-design/SKILL.md:9）。
2. 讲为什么，讲对读者的后果。 模型能从解释里自己推到没写到的情形（theory/anthropic_prompting-best-practices.md:69-85；system_prompts_leaks/Anthropic/claude-science.md:57）。
3. 少用大写、"必须"和加粗（skills/skills/skill-creator/SKILL.md:302："If you find yourself writing ALWAYS or NEVER in all caps … that's a yellow flag"）。
4. 要发散，就点出"模型默认会走的路"，不给目标答案。 点名时只写"默认是哪种形状"，不写具体内容，否则被点名的内容会变成新的汇聚点（skills/skills/frontend-design/SKILL.md:38-45, 53；theory/anthropic_prompting-best-practices.md:1069-1071）。
5. 一个具体例子就是一个锚。 例子要么不给，要么给几个互相不同的（theory/anthropic_prompting-best-practices.md:94；Interviewer :30："enough information to set the scope … but not so much that you influence the responses"）。
6. 写法跟着失败的类型走。 判断类、"写成什么样"类的问题，用正面描述怎么做；只有"明知该做、有压力时偷懒"的纪律类问题，才用禁令和"红旗"念头表。禁令用在"写成什么样"的问题上反而更糟，也不要加"除非……"的例外从句（superpowers/skills/writing-skills/SKILL.md:461-476）。
7. "何时做 / 何时不做"成对写，并给默认值（skills/skills/discernment-nudge/SKILL.md:72-78；superpowers/skills/brainstorming/SKILL.md:86）。
8. "做不到、不知道"写成正常结果，说清谁接手（superpowers/skills/subagent-driven-development/implementer-prompt.md:76-90）。
9. 自由度和任务的脆弱程度相配。 开阔的判断任务给方向，窄桥式的任务给具体步骤（papers/web/skills-best-practices.md:60-133）。
10. 自查写成问题，放在动手之前或最后，不要求写出来（skills/skills/frontend-design/SKILL.md:53）。
11. 精简：只写模型不知道的；读真实运行的记录，删掉让模型白费力气的句子（skills/skills/skill-creator/SKILL.md:300）。

四、放到本项目时要注意

• 角色模型是 glm-5.3，上面的结论大多是在 Claude 上测的。改完要用真实运行验证，不能只凭写法。
• 研究者子会话不加载 skill（src/agents/session.ts 会核对并拒绝）。所以正文的写法可以照搬，"描述写成何时触发""详见某文件、按需读"这类机制用不了。角色提示词每个任务都整份发，等价的按需加载只能由程序按任务挑内容。
• "现在交什么"由程序从 vocab 的字段说明生成（src/materials/prompts.ts 的 closing）。字段怎么写放在 vocab 的字段说明里，任务提示词不再写一遍。
• 子会话里没有人可问。别人的"问用户、等批准"要改成"在提交里写明不确定的地方，或者不交并写清原因"。
• 不泄露解法：提示词里不出现任何任务的具体做法、具体数值或参考项目跑出来的具体经历。真实教训改写成不带领域细节的形状。检查办法：用这个任务的关键词搜一遍全部提示词（填圆的关键词：半径、圆心、线性规划、SLSQP、扰动、六角、布局、摆法、结构起点、compute_max_radii 等），搜不到才算过。