面试题库

5 天提示词工程零基础

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

• 角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？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