Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D4 Model Integration and System Prompts: a Multi-Provider Abstraction With Fallback, Overriding the Default Persona (dg P03/P04/M04)

• What does the system prompt do in an agent, and why not rely on the framework default?系统提示词（system prompt）在 Agent 里起什么作用？为什么不能用框架默认的？

  Common in ChinaCommon overseasIntermediate#prompt-engineering#system-prompt

  How to reason about it · think before answering

  1. The first half is a warm-up; the discriminating half is why the default is dangerous.
  2. State the role: it is the one instruction block whose weight stays stable across dozens of turns, setting identity, capability boundaries and output format.
  3. Then give three concrete consequences rather than 'not customized enough': it does not know your business boundary so it happily answers off-topic questions; it does not constrain output format so stray Markdown headings break your UI; and worst, it changes when the framework updates — your tested behavior rests on invisible text, and the bug appears with zero code changes.
  4. Land on practice: a production system prompt is assembled from a template — persona, capability boundary, output requirements, dynamic context — with the last part rebuilt per request.
  5. Expect: what gets forgotten in dynamic context? The current time. Models have no clock; without today's date they cannot resolve 'the order I placed three days ago'.
  6. Second follow-up: how do you test a prompt? Treat it as configuration, not code — store it, version it, roll it out to a percentage, because you cannot unit-test 'the tone got friendlier'.

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

  1. 前半句是送分题，后半句才是区分度所在——很多人答得出 system prompt 是干什么的，答不出「默认值有什么坑」。
  2. 先说作用：它是唯一一段在整段对话里权重稳定、不会被后续几十轮稀释的指令，用来设定身份、能力边界和输出格式。
  3. 再答「为什么不能用默认的」，要给出三条具体后果而不是泛泛说「不够定制」：一是它不知道你的业务边界，用户问业务外的问题它会热情地答；二是它不约束输出格式，前端样式会被冷不丁冒出的 Markdown 标题打乱；三是最要命的——它会随框架升级而变化，你测好的所有行为建立在一段看不见的文本上，出 bug 时你的代码一行没动，极难排查。
  4. 结论落到工程做法：生产环境的 system prompt 是拼出来的模板，结构是「人设 + 能力边界 + 输出要求 + 动态上下文」，最后一块每次请求现拼。
  5. 可以预期的追问：动态上下文里最容易漏什么？答「当前时间」——模型没有时钟，不告诉它今天几号，它算不出「三天前下的单」是哪天。这个细节很能体现有没有真做过。
  6. 第二个追问：prompt 怎么测试？答案是把它当配置而不是代码——存库、加版本号、支持按比例灰度，因为你没法写单元测试断言「模型语气变友好了」。

  Key points

  • The system prompt sets identity, capability boundaries and output format, and keeps stable weight across turns
  • A default persona does not know your business boundary and will cheerfully answer off-topic questions
  • It does not constrain formatting, so stray Markdown can break your UI
  • Most dangerous: defaults change on framework upgrades, producing behavior regressions with no code change
  • Production practice: assemble it explicitly, treat it as versioned configuration, and roll changes out gradually

  答题要点

  • system prompt 设定身份、能力边界与输出格式，是对话里权重最稳定、不被后续轮次稀释的一段指令
  • 框架默认人设不知道你的业务边界，会热情回答业务外的问题，浪费 token 且跑题
  • 默认人设不约束输出格式，模型可能吐出 Markdown 标题打乱前端样式
  • 最危险的是默认值会随框架升级而变化，代码一行没动却出现行为回归，极难排查
  • 生产做法：显式拼模板（人设 + 能力边界 + 输出要求 + 动态上下文），当作配置存储、加版本号、可灰度

Prompt Engineering From Scratch in 5 Days

D1 What a Prompt Is, and Isn't: How the Model Reads Instructions; the Four Elements of Role / Task / Format / Constraints

• Why do rules belong in the system prompt rather than the user message? Cover adherence, control, and cost, and name what the system prompt cannot guarantee.为什么规则要放系统提示而不是用户消息？请从遵从度、管控和成本三个角度说明，并指出系统提示做不到什么。

  Common in ChinaCommon overseasIntermediate#system-prompt#prompt-basics

  How to reason about it · think before answering

  1. The tell is whether you cover all three angles and name a limitation. 'System prompts carry more weight' alone reads as memorized.
  2. Adherence: user turns get diluted as the conversation grows, the system prompt stays in force. Control: the backend assembles the system prompt and users cannot touch it, so rules apply uniformly. Cost: prompt caching matches on prefixes, and the system prompt is the most stable prefix.
  3. The limitation is the differentiator: higher adherence is not a guarantee, prompt injection can still steer the model, so security boundaries need code-level enforcement outside the model.
  4. Conclusion: rules go in the system prompt for stability, consistency and cost, but it is a strong suggestion, not a hard constraint.
  5. Follow-ups: can the system prompt go last? Possible but unwise — models weight early instructions more and it breaks the cache prefix. What should stay out? Per-request task details, which would bust the cache and hurt reuse.

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

  1. 题眼在「三个角度」和「做不到什么」。只答「系统提示权重高」是背概念，面试官要看的是你有没有在生产里拼过系统提示。
  2. 拆法：遵从度看多轮稀释——用户消息会被后续对话淹没，系统提示全程生效；管控看谁能改——系统提示由后端统一拼装、用户碰不到，规则放这里才能对所有用户一致；成本看缓存——提示缓存按前缀命中，系统提示是最稳定的前缀。
  3. 「做不到什么」是区分度所在：系统提示遵从度高不等于绝对，提示注入可以让模型跑偏，所以安全边界不能只靠系统提示，要在模型外用代码兜底。
  4. 结论：规则进系统提示是为了稳定、一致、省钱；但它是「强建议」不是「硬约束」，硬约束必须在代码层实现。
  5. 追问方向：系统提示可以放在对话末尾吗？可以但不推荐——多数模型对靠前指令更敏感，且会破坏缓存前缀；另一个追问是「哪些内容不该进系统提示」，答案是每次都变的任务细节，放进去会让缓存失效且难以复用。

  Key points

  • Adherence: user turns get diluted over a long conversation, the system prompt stays in force
  • Control: the backend assembles it and users cannot edit it, so rules apply to everyone
  • Cost: prompt caching matches prefixes, so stable content in the system prompt maximizes cache hits
  • Limit: it is not a security boundary; prompt injection can bypass it, so enforce hard rules in code

  答题要点

  • 遵从度：用户消息会被多轮对话稀释，系统提示全程生效
  • 管控：系统提示由后端统一拼装，用户碰不到，规则才能对所有人一致
  • 成本：提示缓存按前缀命中，系统提示是最稳定的前缀，不变的内容集中在这里最省钱
  • 做不到的：它不是安全边界，提示注入可以绕过，硬约束必须在代码层兜底

D5 Migrating Across Models: Differences Between Claude / GPT / Domestic Chinese Models, Organizing the System Prompt; Where to Go Next — the Claude Course or the Codex Course

• How should a system prompt be organized so it ports across models, and how do you decide which block a given sentence belongs to?系统提示应该怎么组织才方便跨模型复用？怎么判断某一句该放哪一块？

  Common in ChinaCommon overseasIntermediate#system-prompt#model-migration

  How to reason about it · think before answering

  1. It looks structural but tests whether you have maintained one prompt across vendors. 'Just write it clearly' means no; experienced people start with blocks.
  2. Three blocks, one question each. Common rules — would this sentence still hold on another vendor? Role, task, done-criteria, reasoned constraints, schema. Vendor adaptation — is this true for one vendor only? Input wrapping, example style, length hints, refusal wording, structured-output switch; one per vendor, swapped wholesale. Task variables — does this change per call? Make it a parameter.
  3. Two self-checks are the differentiator: delete the vendor block entirely and see if what remains is still a readable prompt; grep the common block for any vendor-specific token — tag names, API parameter names, style preferences.
  4. Conclusion: the payoff goes beyond migration — the common block is the longest, most stable prefix, so leading with it maximizes prompt-cache hits; vendor block fixed per vendor; variables last. It extends the D1 principle of keeping stable content in the system prompt.
  5. Follow-up: where do few-shot examples go? Their content is common, their rendering (wrapping tags, code-block style) is vendor-specific, so split examples into content plus rendering, or at least keep vendor tags out of them.

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

  1. 这题看似问结构，实际在考「有没有维护过多家模型共用的一份提示词」。答「写清楚一点就能通用」的人没维护过；维护过的人会先说分块。
  2. 拆法：三块各回答一个问题。通用规则——这一句换一家模型还成立吗，成立放这里（角色、任务、完成标准、带理由的约束、schema）；厂商适配——这一句是不是只对某一家成立，是的放这里（输入包裹方式、示例风格、长度提示、拒答边界表述、结构化输出开关），每家一份整块替换；任务变量——每次调用都在变吗，是的做成参数。
  3. 两条自检是区分度：把厂商块整块删掉，剩下的还是不是一份能读懂的提示词；通用块里搜有没有任何一家的专属词（标签名、API 参数名、风格偏好）。
  4. 结论：分块的收益不只是迁移——通用块是最长最稳定的前缀，放最前面缓存命中最高；厂商块每家固定；任务变量放最后。这跟 D1 讲系统提示要放稳定内容是同一条原则的延伸。
  5. 追问：few-shot 示例算哪一块？示例的内容属于通用规则，示例的书写风格（包裹标签、代码块风格）属于厂商适配，所以示例最好也拆成「内容 + 渲染」两层，或者至少不带厂商专属标签。

  Key points

  • Three blocks: common rules that hold across vendors, a per-vendor adaptation block swapped wholesale, and per-call task variables
  • Two deciding questions: does it still hold on another vendor; does it change every call
  • Self-checks: the prompt stays readable with the vendor block removed; no vendor-specific tokens in the common block
  • Order common, vendor, variables so the most stable prefix leads and cache hits are maximized

  答题要点

  • 三块：通用规则（换模型仍成立）、厂商适配（每家一份整块替换）、任务变量（每次调用的参数）
  • 判据是两个问题：换一家还成立吗；每次调用都在变吗
  • 自检：删掉厂商块剩下的仍可读；通用块里没有任何一家的专属词
  • 顺序通用、厂商、变量，最稳定的前缀在前，缓存命中最高

Mastering Claude: From Conversation to Claude Code in 5 Days

D1 Advanced Prompting and Claude's "Personality": System Prompt, XML Tags, Letting the Model Think First, Structured Output

• What belongs in a system prompt and what doesn't? If the model keeps ignoring one rule, what do you check first?system prompt 应该放什么、不该放什么？如果一条规则模型总是不遵守，你会先检查什么？

  Common in ChinaCommon overseasBasic#system-prompt#prompt-design

  How to reason about it · think before answering

  1. The question tests boundaries, not writing skill. Naming what to exclude, and why, is what separates a strong answer.
  2. Give the rule: the system prompt is a fixed premise resent on every request, so it holds only what is true for the whole conversation — role, constraints as prohibitions, output style. Anything that varies per turn belongs in the user message.
  3. Then the anti-patterns: obvious conventions, pasted API docs, and per-turn material dilute the important rules and also invalidate the prompt-cache prefix on every call.
  4. Debug order for an ignored rule: check length first and prune, then check for ambiguity or conflicting rules, and only then add emphasis. If the rule is a must-run action, move it to a deterministic gate instead of adding more words.
  5. Likely follow-up: can system go last? Possible but unwise — earlier instructions carry more weight and a moving prefix breaks caching.

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

  1. 这题考的是「职责边界」而不是「会不会写」。答成「放角色和要求」是及格线，能说出「不该放什么」以及「为什么」才有区分度。
  2. 先给一条判据：system prompt 是每次请求都重发的固定前提，所以只放整场对话都成立的东西——角色、边界（禁止项）、输出风格；每次都变的（时间、用户名、本轮材料）放 user 消息。
  3. 再说反面：把模型本来就知道的常识（「写干净的代码」）、大段 API 文档、每轮都不一样的材料塞进 system，只会稀释真正重要的规则，还会让 prompt caching 的前缀每次都变。
  4. 「规则总是不遵守」的排查顺序：先看 system 是不是太长导致规则被淹没（删到不能再删），再看规则是否含糊或与别的规则冲突，最后才考虑加强调；如果是「每次必须执行」的动作，应该改成程序层面的门禁而不是继续加规则。
  5. 可预期的追问：system 放最后行不行？可以但不推荐——模型对靠前的指令更敏感，且会破坏缓存前缀。

  Key points

  • Include role, prohibitions, and output style — premises that hold for the whole conversation
  • Exclude volatile facts, common sense the model already has, and long pasted docs
  • The system prompt is resent every request: longer means costlier and rules get buried
  • For an ignored rule: prune first, disambiguate second, emphasize last; must-run actions become deterministic gates

  答题要点

  • 放：角色、边界（写禁止项）、输出风格；整场对话都成立的固定前提
  • 不放：会变的信息（时间、用户名、本轮材料）、模型本来就知道的常识、大段文档
  • system 每次请求重发，越长越贵，也越容易让关键规则被淹没
  • 规则不被遵守先删再改再强调；「每次必须做」的动作改成程序门禁

Context Engineering in 5 Days

D2 System Prompts and the Instruction Hierarchy: the Right Altitude, Persistent Instruction Files, Progressive Disclosure, Less Is More

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

  Common in ChinaCommon overseasIntermediate#system-prompt#altitude

  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.

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

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

  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.

  答题要点

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