面试题库

5 天提示词工程零基础

D1 提示词是什么、不是什么：模型如何读指令；角色 / 任务 / 格式 / 约束四要素

• 提示词工程到底在工程什么？它和写需求文档、写技术方案有什么本质区别？What exactly is being engineered in prompt engineering, and how does it differ from writing a requirements doc or a design spec?

  国内高频海外高频基础#prompt-basics#mental-model

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

  1. 这题在筛「有没有理解模型是在补全而不是执行」。答成「用巧妙的措辞让模型听话」会被判为只会用聊天产品；答出「系统性补齐模型缺少的上下文」才算入门。
  2. 拆法：先问自己「读者是谁」。需求文档的读者是有项目背景的人，可以依赖共享默认；提示词的读者是一个没有任何项目背景、也不会停下来提问的补全器，所有默认信息都得显式写出。
  3. 再落到「工程」二字：可复现、可测试、可版本化。提示词写完要能跑测试集、要进仓库、要能对比两版差异——这才是它区别于「写一段话」的地方。
  4. 结论：提示词工程是把隐性上下文显式化、并把这段文本当代码一样管理的工程活动；措辞技巧只是其中很小的一部分。
  5. 可预期的追问：那和写给外包团队的需求说明有什么区别？答案是外包会反问，模型不会，所以提示词对完整性的要求更高，且要在没有反馈回路的前提下自带完成标准。

  How to reason about it · think before answering

  1. The screen here is whether the candidate knows the model completes text rather than executes commands. 'Clever wording that makes the model obey' signals chat-app experience only.
  2. Start from the reader: a spec is read by people who share project context; a prompt is read by a completer with zero context that never asks a clarifying question, so every implicit default must be spelled out.
  3. Then justify the word engineering: reproducibility, testability, versioning. A prompt should run against a test set, live in the repo, and diff cleanly between versions.
  4. Conclusion: prompt engineering is making implicit context explicit and managing that text like code; phrasing tricks are a small part.
  5. Likely follow-up: how is that different from a brief for an outsourced team? The team pushes back with questions; the model does not, so a prompt must carry its own completion criteria.

  答题要点

  • 模型在补全一段文本而不是执行命令，提示词是给它的上下文，写得越具体可能的下文越窄、输出越稳
  • 工程的对象是「模型缺的信息」：视角、完成标准、输出形状、边界与理由，也就是四要素
  • 区别于需求文档：读者没有共享背景、不会反问，所以完整性要求更高、必须自带完成标准
  • 「工程」意味着可测试、可版本化、可对比，而不是一次性的巧妙措辞

  Key points

  • The model completes text rather than executing commands; a prompt is context, and specificity narrows the plausible continuations
  • What gets engineered is the missing information: perspective, completion criteria, output shape, boundaries with reasons
  • Unlike a spec, the reader shares no background and never asks back, so completeness and explicit done-criteria matter more
  • Engineering implies testable, versioned, comparable artifacts, not one-off clever phrasing
• 角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？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?

  国内高频海外高频进阶#prompt-basics#four-elements

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

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

  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.

  答题要点

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

  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.

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

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

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

  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.

  答题要点

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

  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