面试题库

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