面试题库

5 天上下文工程

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

• 系统提示越写越长是怎么发生的？你会怎么止住这个过程？How do system prompts keep growing, and how would you stop it?

  国内高频海外高频基础#prompt-bloat#maintenance

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

  1. 这题看着像吐槽题，其实在考流程意识。能答出成因的人不少，能给出一条可执行的止损机制的人很少。
  2. 怎么拆：先讲成因，它是一条单向棘轮。每次线上出问题，最快的止血手段就是往系统提示里加一句；加的人当时知道为什么加，但没写下来；半年后没人敢删，因为删了万一那个事故重来一次，责任在删的人身上。于是只进不出。
  3. 再指出成因里最隐蔽的一层：很多规则是为了绕过某一代模型的具体毛病写的。模型换代之后它们不但没用，还在继续消耗每一轮的输入预算，而且没有任何信号提示你它们已经过期。
  4. 结论给三条机制：一是加规则时强制记录它对应的失败案例，这是将来敢删的唯一依据；二是最小起步——先用最少的规则跑一批真实用例，按观察到的失败逐条加，而不是上线前把能想到的都写上；三是定期做一次逐条判定，用「能不能写出断言」当尺子，并在换模型之后重跑一次。
  5. 可预期的追问：删规则的风险怎么控？答：把每条规则对应的失败案例沉淀成回归用例，删之前先跑一遍。没有用例支撑的规则，本来就没有资格待在那里。

  How to reason about it · think before answering

  1. It sounds like a complaint prompt but it tests process thinking. Many can name the cause; few offer a mechanism that actually stops the growth.
  2. The cause is a one-way ratchet. Every production incident is fastest to patch by appending a sentence to the system prompt. The person who added it knew why but did not write it down. Six months later nobody dares delete it, because if the incident recurs the blame lands on whoever deleted it.
  3. Name the subtle layer too: many rules exist to work around a specific model generation's quirks. After a model upgrade they are useless yet still consume input budget every turn, and nothing signals that they expired.
  4. Give three mechanisms. Record the failing case beside each rule when adding it. Start minimal and add rules only for observed failures rather than writing everything imaginable before launch. Periodically re-audit rule by rule using the can-you-write-an-assertion test, and re-run that audit after every model upgrade.
  5. Expect the follow-up: how do you de-risk deletion? Turn each rule's originating failure into a regression case and run it before deleting. A rule with no supporting case never earned its place.

  答题要点

  • 成因是单向棘轮：出事就加一句，加的理由没记录，之后没人敢删。
  • 隐蔽的一层：很多规则是为绕过某代模型的毛病写的，换代后过期却没有任何信号。
  • 止损三招：加规则时记录对应失败案例、最小起步按失败驱动增加、定期用断言尺子逐条重判。
  • 删除风险靠回归用例控制：每条规则对应的失败案例应沉淀成用例，删前先跑。

  Key points

  • The cause is a ratchet: incidents are patched by appending a line, the reason is never recorded, and nobody dares delete it later.
  • Subtle layer: many rules work around one model generation's quirks and silently expire after an upgrade.
  • Three fixes: record the originating failure with each rule, start minimal and add only for observed failures, and re-audit periodically with the assertion test.
  • Control deletion risk with regression cases derived from each rule's originating failure.