Prompt 结构化设计

Q：通常 Prompt 包含哪些结构？

来源：淘宝闪购 AI应用研发 一面

新手答：“角色、指令、示例，三个部分。”

高手答：

生产级 Prompt 远不止三要素。一个完整的 Agent 系统 Prompt 通常包含六层结构，每层有不同的职责和优先级：

1. 身份与角色层（Identity）

定义模型是谁、基本行为准则。放在最开头，优先级最高。

你是一个电商客服助手，服务于XX平台的用户。
你的回答必须准确、礼貌、简洁。

2. 规则约束层（Rules）

硬性限制——模型绝对不能违反的规则。通常用否定句式强调。

- 绝不编造商品信息，不确定时说"我帮您查询"
- 不讨论政治、宗教等敏感话题
- 涉及退款操作必须确认订单号

3. 上下文注入层（Context）

动态注入的背景信息——当前用户画像、历史对话摘要、检索到的知识片段。这一层每次请求都不同。

4. 工具描述层（Tools）

可用工具的定义和使用说明。通过 function calling 接口或 Prompt 内嵌的方式提供。

5. 示例层（Examples）

Few-shot 示例——展示期望的输入输出格式和推理方式。2-3 个示例通常足够，太多会挤占上下文空间。

6. 输出格式层（Output Format）

约束输出的结构——JSON、Markdown、特定模板。放在 Prompt 末尾，离模型输出最近，遵循度最高。

层级之间的优先级：

规则约束 > 身份角色 > 上下文 > 示例 > 输出格式 > 工具描述

当不同层的指令冲突时（比如示例中的行为违反了规则），规则约束应该胜出。在 Prompt 中可以显式声明优先级：“如果以下示例与上述规则冲突，以规则为准。”

工程实践：

生产系统中，这六层通常不是写在一个字符串里，而是用模板引擎动态拼装——身份层和规则层固定，上下文层和工具层按需注入，示例层按任务类型切换。Prompt 版本管理和 A/B 测试也是必要的工程实践。

差距在哪：新手只知道“角色+指令+示例”三件套。高手展示了六层架构——身份、规则、上下文、工具、示例、输出格式——且理解层级间的优先级关系和动态拼装机制。面试官考的是你对 Prompt 的理解是“写一段话”还是“设计一个分层系统”。

---

Q：在调优 Prompt 时，你有哪些实战经验？如何利用 AI 辅助自己优化 Prompt？

来源：字节后端 Agent 开发二面

新手答：“多试几遍，看哪个效果好就用哪个。”

高手答：

Prompt 调优不是「碰运气」，是一个有方法论的工程流程。分两个层面回答：

一、人工调优的实战经验

核心方法论是控制变量 + 快速迭代：

步骤	做法	关键点
1. 建评测集	准备 20-50 条覆盖主要场景的测试 case	包含正常 case + 边界 case + 已知 bad case
2. 单变量调整	每次只改一个要素（角色/约束/示例/格式）	多变量同时改，效果归因不清
3. 定量对比	跑评测集，记录通过率变化	不要凭感觉判断「好像好了一点」
4. 版本管理	每个版本的 Prompt 存档 + 评测结果	方便回退和复盘

高频有效的调优手段（按 ROI 排序）：

1. 加约束条件：从「回答问题」到「用 JSON 格式回答，字段包含 answer 和 confidence」——约束越明确，输出越稳定
2. 加 Few-shot 示例：1-2 个好示例的效果常常超过大段指令描述
3. 拆步骤：把复杂任务拆成「先分析 → 再判断 → 最后输出」，比一步到位成功率高很多
4. 加负面指令：明确说「不要做什么」，比只说「做什么」更能避免常见错误
5. 调整上下文顺序：把最重要的信息放在开头和结尾（避免 Lost in the Middle）

二、AI 辅助优化 Prompt 的方法

方法	做法	适用场景
让 AI 分析 bad case	把失败的输入输出给 AI，问「为什么这个 Prompt 在这个 case 上失败了」	定位单个 case 的失败原因
让 AI 生成变体	给 AI 当前 Prompt + 目标，让它生成 5 个改进版本	快速探索优化方向
让 AI 做评测	LLM-as-Judge，让 AI 对两个 Prompt 版本的输出做偏好排序	评测集太大、人工评判成本高
Meta-Prompting	让 AI 扮演「Prompt 工程师」，输入任务描述，输出优化后的 Prompt	冷启动阶段快速获得基线 Prompt

关键认知：AI 辅助优化 Prompt 的价值不在于「自动变好」，而在于加速迭代循环——人定方向（哪里需要改进），AI 提供候选方案（怎么改），人做最终判断（哪个版本上线）。完全依赖 AI 自动优化容易陷入「过拟合评测集」的陷阱。

差距在哪：新手的「多试几遍」没有方法论，效率低且不可复现。高手展示了控制变量法 + 评测集驱动的工程化流程，且把 AI 辅助定位在加速迭代而非替代判断。面试官考的是你在 Prompt 调优上有没有系统性的工程实践。

---

Q：Harness Engineering 是什么？它如何演进的？

来源：CVTE/AI应用工程师一面 | 更完整的 Harness 专题见 → 概念考察：Harness Engineering

新手答：“不太了解这个概念，是不是跟测试框架有关？”

高手答：

Harness Engineering 是 Claude Code 提出的核心设计理念——用工程化的“线束”约束和增强 Agent 行为，而不是把所有能力都塞进模型本身。

核心思想：模型是引擎，Harness 是方向盘和安全带。

演进路线：

阶段 1（纯 Prompt 时代）：所有行为约束写在 System Prompt 里。问题：Prompt 越写越长，模型遵循率随长度下降。

阶段 2（结构化工具时代）：把能力拆成 Tools / Function Calling，Prompt 只负责决策。问题：工具多了模型选错。

阶段 3（Harness 工程化）：引入三层机制：

• Rules（CLAUDE.md）：静态约束，每次对话都注入
• Skills：可复用的能力单元，按需触发
• Hooks：事件驱动的自动化行为（如 pre-commit 检查）

阶段 4（自适应）：Harness 本身可以被 Agent 修改——Agent 执行任务时发现某个 Skill 不够好，可以自我改进 Skill 定义。形成“使用→评估→改进”的闭环。

和传统 Agent 框架的区别：LangChain 的 Chain 是“预定义执行路径”，Harness 是“约束条件下的自由执行”。Harness 不规定 Agent 怎么做，只规定什么能做、什么不能做、做完怎么验证。

差距在哪：新手不了解这个概念。高手能讲清演进逻辑（为什么从 Prompt 演进到 Harness）和核心区别（约束 vs 规定路径），展示对 Agent 框架设计哲学的深度理解。面试官考的是你对前沿 Agent 工程架构的认知。

---

Q：Skill 的渐进式披露（Progressive Disclosure）怎么实现？Skill 之间的沙箱隔离和通信机制是什么？

来源：蚂蚁AI应用开发二面

新手答：“Skill 加载进去就行了，不需要什么披露策略。”

高手答：

Skill 不是一次性全量加载的——这样会撑爆上下文且干扰模型判断。渐进式披露是按需、分层、递进地注入 Skill 内容：

渐进式披露的三层实现：

层级	加载内容	触发时机
L0 索引层	只加载所有 Skill 的名称 + 一句话描述	会话启动时
L1 摘要层	匹配到的 Skill 加载执行步骤概要	用户意图命中触发条件
L2 完整层	加载 Skill 的全部内容（知识 + 约束 + 示例）	模型确认需要执行该 Skill

这样设计的好处：L0 让模型知道“有哪些能力可用”（几百 token），只有真正需要时才花费完整 Skill 的 token 预算。

沙箱隔离机制：

多个 Skill 同时激活时，需要防止相互干扰：

1. 上下文命名空间：每个 Skill 的注入内容用明确的边界标记（``），模型能区分哪段指令来自哪个 Skill
2. 工具权限隔离：不同 Skill 声明自己可以使用的工具子集——代码审查 Skill 只能读文件，部署 Skill 才能执行 bash 命令
3. 输出作用域：每个 Skill 的输出约束互不覆盖——格式化 Skill 要求 JSON 输出不会干扰到同时激活的分析 Skill

Skill 间通信：

Skill 之间不直接通信（避免耦合），而是通过共享状态层间接交互：

Skill A 执行完 → 将结果写入 shared_context（结构化 JSON）
                → Skill B 启动时从 shared_context 读取前置结果

这和微服务通过消息队列通信是同一个模式——Skill 之间松耦合，通过标准化的数据结构传递结果，而不是直接引用彼此的内部状态。

差距在哪：新手认为 Skill 是”全量加载、互不相关”的。高手理解生产级 Skill 系统需要渐进披露（控制 token 成本）、沙箱隔离（防止冲突）、间接通信（支持组合）三重机制。面试官考的是你能不能把 Skill 从”单个文件”的认知提升到”多 Skill 协作系统”的架构层面。

---

Q：什么是一个好的提示词？如何做好提示词的评估？

来源：科大讯飞AI一面

新手答：”好的提示词就是写得清楚，让模型能理解。”

高手答：

好 Prompt 和差 Prompt 的区别不是”写得多 vs 写得少”，而是约束是否充分且无歧义。一个好的 Prompt 需要满足四个标准：

1. 角色和边界清晰 — 模型知道自己是谁、不该做什么。”你是一个金融合规审核员，只判断是否合规，不提供建议” 比 “帮我看看这段话有没有问题” 好 10 倍。

2. 输出格式可解析 — 下游代码能稳定解析输出。JSON Schema 约束、XML 标签包裹、固定分隔符都是手段。最怕的是”自由格式输出”——每次格式不同，正则也匹配不了。

3. 边界条件有兜底 — 输入为空、输入不在预期范围内、模型不确定时的行为都有明确指令。”如果无法判断，输出 UNKNOWN 而非猜测”。

4. Few-shot 示例锚定风格 — 1-2 个示例比 200 字的描述更有效。示例传递的是隐含规则（格式、粒度、语气），文字描述传递的是显式规则。

提示词评估的方法论：

评估维度	指标	方法
格式稳定性	输出能被下游解析的比例	跑 100 条 query，统计 JSON parse 成功率
任务准确率	答案正确的比例	标注 golden set，自动对比
边界鲁棒性	异常输入下的表现	注入空输入/超长输入/对抗输入
一致性	相同输入多次输出的稳定度	同 query 跑 5 次，计算输出相似度
token 效率	同等效果下的 prompt 长度	A/B 对比精简版 vs 完整版

实际评估流程：

1. 先构建 20-50 条有标注的评测集（覆盖正常/边界/对抗）
2. 改 Prompt → 跑评测集 → 对比指标变化
3. 用 LLM-as-Judge 做初筛（效率高），再人工抽检 bad case（准确高）
4. 记录每次 Prompt 变更和对应指标，形成版本管理

差距在哪：新手觉得 Prompt 好不好靠”感觉”。高手有系统化的质量标准（四个维度）和量化评估方法（评测集 + 多维指标 + 版本管理）。面试官考的是你有没有把 Prompt 当工程问题来做——有标准、有测试、有迭代。