面试题库

5 天上下文工程

D2 系统提示与指令层次：高度适中、持久指令文件、渐进披露，少即是多

• 系统提示的高度怎么把握？写太具体和写太笼统各会出什么问题？How do you calibrate the altitude of a system prompt, and what goes wrong at each extreme?

  国内高频海外高频进阶#system-prompt#altitude

  分析过程 · 先想清楚再作答

  1. 这题在考你有没有一把可操作的尺子。凡是答「要恰到好处」「要具体但不要太具体」的，都会被归到没做过工程那一类，因为这句话不能指导任何一次具体修改。
  2. 怎么拆：先把两端的病症说清楚。写太具体是把业务逻辑硬编码进了自然语言——七种订单状态写成七条分支，加一个状态就要改提示词，而且没有任何测试会告诉你改漏了。写太笼统是一段读起来无可指摘、删掉之后模型行为却完全不变的话。
  3. 给尺子：你能为这条规则写出一个自动检查它有没有被遵守的断言吗。写不出来说明飞太高；写得出来但断言要列举七种情况说明飞太低；写得出来且断言很短，高度就合适。这把尺子的好处是能当场逐条判定，不需要争论。
  4. 结论加修法：太低的修法是挪走而不是缩写——留下入口规则，把分支细节搬进引用文件按需读取；太高的修法是把它当初对应的那次事故翻译成可核对的规则，而不是直接删掉，否则同一个事故会再来一次。
  5. 可预期的追问：那怎么知道一条规则当初是为什么加的？答：加规则的时候就在旁边记下它是为哪个失败案例加的。没有这句注释，半年后没人敢删任何一条。

  How to reason about it · think before answering

  1. This tests whether you have an operational yardstick. Answering that it should be specific but not too specific fails, because that sentence cannot guide a single concrete edit.
  2. Name both failure modes. Too low means business logic hardcoded into prose: seven order states become seven branches, every new state forces a prompt edit, and no test tells you when you missed one. Too high means text that reads well and changes nothing if deleted.
  3. Give the yardstick: can you write an automated assertion that checks whether the rule was followed? If not, the rule is too high. If the assertion needs to enumerate seven cases, the rule is too low. A short assertion means the altitude is right.
  4. Then the fixes. For too low, relocate rather than shorten: keep the entry rule and push branch detail into a reference file loaded on demand. For too high, translate the incident that produced it into a checkable rule instead of just deleting it, or the incident recurs.
  5. Expect the follow-up: how do you know why a rule was added? Record the failing case beside the rule when you add it. Without that note, nobody will dare delete anything six months later.

  答题要点

  • 高度太低是把业务分支硬编码进自然语言，脆且改漏无人知；太高是删掉也不改变行为的废话。
  • 判据：能不能为这条规则写出一个自动断言，断言写不出或要列举七种情况都是高度不对。
  • 太低的修法是把细节挪进引用文件、主提示只留入口规则；太高的修法是把对应事故翻译成可核对的规则。
  • 每加一条规则就记下它对应的失败案例，这是将来敢不敢删它的唯一依据。

  Key points

  • Too low hardcodes business branches into prose: brittle, and silent when it goes stale. Too high is text that changes nothing when removed.
  • Test: can you write an automated assertion for the rule? No assertion, or one that enumerates seven cases, means the altitude is wrong.
  • Fix too low by relocating detail into on-demand reference files and keeping only the entry rule; fix too high by translating the originating incident into a checkable rule.
  • Record the failing case beside every rule you add; it is the only basis for deleting it later.