Interview Bank

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

• What problem does each of the four prompt elements — role, task, format, constraints — solve? If you could keep only three, which would you drop and why?角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？

  Common in ChinaCommon overseasIntermediate#prompt-basics#four-elements

  How to reason about it · think before answering

  1. The first half is a warm-up; the second half tests whether you can map each element to a specific way the model would otherwise guess, and rank the cost of each wrong guess.
  2. Map them: role fixes perspective and focus, task fixes the finish line, format decides whether downstream code can consume the output, constraints bound the change surface.
  3. To pick the one to drop, ask whether its absence makes results unstable or unusable. Missing role skews focus but stays usable; missing done-criteria means the model never knows when to stop; missing format breaks parsers; missing constraints lets edits sprawl.
  4. Conclusion: in most engineering settings role is the most droppable, because a specific task plus a strict format already imply the perspective — provided the task states what to care about.
  5. Expect the follow-up 'then why does everyone write a role?' Because it is cheap and compresses many implicit preferences into one line, which pays off in chat-style use where the task cannot be fully specified.

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

  1. 前半句是送分，后半句才有区分度：它在考你是否知道每个要素对应模型的哪一种「猜」，以及哪种猜错的代价最小。
  2. 拆法：把每个要素映射到一个「模型会猜错的地方」——角色对应视角与关注点，任务对应终点在哪，格式对应输出能否被程序消费，约束对应改动范围与不可碰的边界。
  3. 判断哪个可砍：看缺了之后是「结果不稳定」还是「结果不可用」。缺角色多半是关注点偏了但仍可用；缺任务的完成标准会让模型不知何时停；缺格式会让下游解析失败；缺约束会让改动面失控。
  4. 结论：多数工程场景下角色最可砍，因为任务与格式写得足够具体时视角已经被隐含；但要说明前提是任务里已经写清了关注点。
  5. 追问几乎必然是「那为什么大家还都写角色」——答案是它便宜且能一句话压缩大量隐性偏好，在任务没法写得很细的对话场景里性价比最高。

  Key points

  • Role sets perspective; task sets the goal and done-criteria; format makes output mechanically checkable; constraints bound scope with reasons
  • Each element removes one kind of guess the model would otherwise make
  • Role is the most droppable once task and format are specific enough to imply the perspective
  • Done-criteria and checkable format are the least negotiable because downstream code depends on them

  答题要点

  • 角色定视角与关注点；任务定做什么与完成标准；格式定输出形状是否可机械核对；约束定不可碰的边界与理由
  • 每个要素对应模型的一种「猜」，缺哪个就多一种不稳定
  • 可砍的是角色：任务与格式足够具体时视角已隐含，但前提是任务里写清了关注点
  • 任务的完成标准与格式的可核对性最不能省，因为它们直接决定输出能不能被程序消费
• 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

  答题要点

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