模型能力边界地图 — Model Capability Limits

👻

幻觉 (Hallucination)

5 种

事实幻觉

高危常见

编造不存在的事实、API参数、函数名，且表述得极为自信。

▸ 展开详情

真实案例

Prompt: "Supabase JS SDK 的 upsert 方法支持哪些参数？"

模型输出: "支持 onConflict、returning、ignoreDuplicates 三个参数"

问题: returning 和 ignoreDuplicates 在 JS SDK v2 中根本不存在，模型从 PostgreSQL 语法推测出了"看起来合理"的参数名

产品应对策略

🛡

确定性兜底: 对接 API 时必须查官方文档验证，不能信模型输出。在 Agent 中用 tool-use 调真实 API 而非让模型"记忆"API spec。

你的项目中

Code Agent CLAUDE.md 里写了"查官方文档，不要凭记忆编造参数"就是针对这个问题

引用幻觉

高危偶发

编造看起来真实但不存在的论文、URL、DOI、引用来源。

▸ 展开详情

真实案例

Prompt: "推荐关于 LLM Agent 评测的论文"

模型输出: "推荐 Zhang et al. (2024) 'AgentBench: Evaluating LLMs as Agents' arXiv:2308.03688"

问题: 论文标题、作者、arXiv ID 可能各自存在但被错误组合，或整个引用都是编造的。格式完美但内容虚假。

产品应对策略

🔍

搜索验证: 涉及引用的场景必须用搜索工具（RAG / Web Search）获取真实来源，而非让模型"回忆"。

你的项目中

OpenClaw 日报的 TrendRadar 用搜索 API 获取真实信息源，不靠模型记忆

数值幻觉

中等常见

数字算错或编造没有依据的统计数据、百分比、性能指标。

▸ 展开详情

真实案例

Prompt: "这个优化方案能提升多少性能？"

模型输出: "预计可提升约 37% 的响应速度"

问题: 37% 这个数字完全没有依据，模型只是生成了一个"听起来合理"的数字来增加说服力

产品应对策略

📊

数值用代码算: 涉及计算的场景用 tool-use 调代码执行器，不让模型心算。数据分析类 Agent 尤其重要。

你的项目中

问数 Agent Text-to-SQL 让数据库执行真实查询，数值来自数据库而非模型推测

自信幻觉

高危常见

错了但语气极其确定，没有任何"我不确定"的提示，让用户难以辨别。

▸ 展开详情

真实案例

Prompt: "macOS 的 launchctl 命令怎么设置定时任务？"

模型输出: "使用 launchctl schedule 命令，语法是..."（用权威口吻给出完全错误的子命令）

问题: launchctl 没有 schedule 子命令。模型不会说"我不确定"，而是自信地编造了看起来合理的用法

产品应对策略

⚠️

置信度机制: 在 prompt 中要求模型标注确定程度；在 UI 中对 AI 生成内容加"AI生成"标签；关键操作前加人工确认环节。

你的项目中

Code Agent CLAUDE.md 明确写了"不确定的事情说我不确定，然后去查"

记忆幻觉

中等偶发

编造对话历史——"你之前提到过..."，但用户从未说过。

▸ 展开详情

真实案例

场景: 长对话中途问"我之前说的那个方案怎么改进？"

模型输出: "你之前提到想用 Redis 做缓存，我建议..."（用户从未提过 Redis）

问题: 上下文太长时模型"推测"用户可能说过什么，而不是承认找不到相关对话

产品应对策略

💾

外部记忆系统: 用结构化的 memory 层（文件/数据库）保存关键对话摘要，而非依赖模型的上下文"回忆"能力。

你的项目中

Code Agent 分层记忆架构（CLAUDE.md / memory files / shared-context）就是为了解决这个问题

📋

指令遵从 (Instruction Following)

5 种

指令遗忘

高危常见

System prompt 越长，后面的规则越容易被忽略。通常 3000 token 后开始衰减。

▸ 展开详情

真实案例

场景: System prompt 有 20 条规则，第 18 条写"所有回复必须以中文"

模型行为: 前几轮用中文，后面逐渐夹杂英文，最终完全用英文回复

问题: 注意力机制对长 prompt 后段的权重自然衰减，不是"忘记"而是"注意力不够"

产品应对策略

📐

分层指令架构: 核心规则放 prompt 首部；场景规则按需加载而非全部塞入；关键规则用 IMPORTANT / 大写 / 重复强化。

你的项目中

Code Agent CLAUDE.md 分层设计——核心规则在顶部，specs 按需加载，就是应对指令遗忘

选择性遵从

中等常见

10 条规则只遵守 8 条，剩下 2 条默默跳过，不告诉你也不报错。

▸ 展开详情

真实案例

Prompt: "写一篇文章，要求：1.800字以上 2.包含3个案例 3.用第一人称 4.每段开头加粗 5.结尾加参考链接"

模型输出: 满足了 1/2/3，但段落开头没加粗，结尾也没参考链接

问题: 模型倾向于满足"主要"需求而跳过"次要"细节，且不会主动说明哪些没做到

产品应对策略

✅

Checklist 验证: 生成后用另一次 LLM 调用逐条检查是否满足要求；或用代码做确定性检测（字数、格式、关键词）。

你的项目中

Code Agent eval 驱动迭代中的评分维度就是在系统性检查每条要求是否被满足

指令冲突时乱选

中等偶发

多条规则矛盾时，模型不会报错，而是随机选一条遵循。

▸ 展开详情

真实案例

Prompt: System: "回复简洁，不超过2句" + User: "详细解释 Transformer 的注意力机制"

模型行为: 有时给 2 句极简回复，有时给长篇解释，行为不可预测

问题: "简洁"和"详细解释"矛盾，模型没有冲突解决机制，每次随机偏向一方

产品应对策略

🏗

优先级明确: 在 prompt 中设定明确的规则优先级（"当以下规则冲突时，安全 > 格式 > 长度"）；避免在 system 和 user 层放矛盾指令。

你的项目中

心灵树洞安全规则优先级高于对话风格规则，确保冲突时安全优先

过度遵从

低偶发

严格遵守指令字面意思，丢失指令背后的真实意图。

▸ 展开详情

真实案例

Prompt: "用一句话解释什么是 RAG"

模型输出: "RAG 是一种将检索与生成结合的技术。"（太简略，没有实际帮助）

问题: 字面上满足了"一句话"，但用户真正想要的是一句有信息量的话

产品应对策略

🎯

意图导向 prompt: 用"简洁但有信息量"替代"一句话"；给出好/坏回复的示例（few-shot）来校准模型理解。

你的项目中

人物智能体人设 prompt 中用示例对话来校准回复风格，避免过度或不足

格式漂移

中等常见

前几轮严格遵守 JSON/XML 格式，多轮之后逐渐"松懈"，格式出错。

▸ 展开详情

真实案例

场景: Agent 循环要求模型每次输出 JSON {"action": "...", "params": {...}}

模型行为: 前 5 轮格式正确，第 8 轮开始在 JSON 前加"好的，我来执行..."的自然语言

问题: 对话越长，模型越倾向于"自然对话"模式，结构化输出的约束力减弱

产品应对策略

🔧

Structured Output: 使用 API 的 response_format / tool_use 强制输出格式；解析失败时自动重试；每轮在 prompt 尾部重复格式要求。

你的项目中

Code Agent Agent Loop 用 tool_use 而非要求模型输出 JSON 文本，从 API 层面保证格式

🧠

推理能力 (Reasoning)

5 种

多步推理累积错误

高危常见

每步 95% 正确率，5 步串联后只剩 77%。推理链越长越不可靠。

▸ 展开详情

真实案例

Prompt: "分析这个 bug：用户登录后跳转到个人页，但头像没显示"

模型推理: 步骤1(对) → 步骤2(对) → 步骤3(错:把图片URL格式判断错了) → 步骤4(基于错误继续) → 结论完全错误

问题: 中间某一步的小错误会传播放大，最终结论可能偏离很远。而且看起来每步都很"合理"

产品应对策略

🔗

任务拆分 + 中间验证: 复杂任务拆成 2-3 步的子任务，每步有 tool-use 验证中间结果。这就是多 Agent 架构的核心动机。

你的项目中

问数 Agent Multi-Agent 架构：理解意图 → 生成SQL → 执行 → 可视化，每步独立验证

逻辑跳跃

中等常见

推理链看起来流畅，但中间有一步逻辑跳跃——前提不能推出结论。

▸ 展开详情

真实案例

Prompt: "这个用户连续3天没登录，我们应该怎么运营？"

模型推理: "3天没登录 → 用户可能流失 → 应该发优惠券"（跳过了分析用户历史行为、流失原因等关键步骤）

问题: 模型倾向于从A直接跳到Z，跳过中间必要的分析步骤。生成的文本很流畅但逻辑链不完整

产品应对策略

📝

Chain-of-Thought 强化: 在 prompt 中明确要求列出每步推理依据；用 structured output 强制输出推理步骤+结论分离的格式。

你的项目中

系统合规 Agent 6步 Pipeline 强制每步有明确输入输出，防止合规判断的逻辑跳跃

数学计算不可靠

中等常见

简单算术偶尔出错，多位数乘除法和复杂公式频繁出错。

▸ 展开详情

真实案例

Prompt: "计算 17 × 24 + 389"

模型输出: "17 × 24 = 408，408 + 389 = 797"（正确应为 408 + 389 = 797，但更复杂的会出错）

问题: LLM 本质上是在做 token 预测而非真正计算。简单的行，复杂的就像人心算一样容易出错

产品应对策略

🧮

计算外包: 任何涉及计算的场景都用代码执行器或计算器工具，模型只负责理解意图和组织算式。

你的项目中

问数 Agent SQL 执行引擎做所有计算，模型只负责 Text-to-SQL 翻译

反事实推理弱

低偶发

"如果 X 没发生，Y 会怎样"类型的假设推理，模型表现明显下降。

▸ 展开详情

真实案例

Prompt: "如果我们的 App 没有做新手引导，用户留存率会怎样？"

模型输出: 给出一个看似合理但完全是猜测的分析，缺乏因果推理能力

问题: 反事实需要因果推理而非相关性推理，而 LLM 主要学到的是相关性模式

产品应对策略

🔬

限制使用场景: 不要让模型做因果推断，用 A/B 测试等确定性方法来回答"如果...会怎样"的问题。

计数与空间推理差

中等偶发

数"有几个X"经常数错，涉及方位、布局、几何关系也容易出错。

▸ 展开详情

真实案例

Prompt: "strawberry 这个单词里有几个 r？"

模型输出: "strawberry 里有 2 个 r"（实际是 3 个）

问题: Tokenizer 把单词拆成 token 后模型看不到字符级信息，计数本质上是猜的

产品应对策略

🔢

代码验证: 字符计数、格式校验等任务用正则/代码处理。空间布局用确定性的布局引擎。

📦

上下文窗口 (Context Window)

4 种

Lost in the Middle

高危常见

首尾信息记得好，中间段容易被忽略。128K 窗口不等于 128K 都有效。

▸ 展开详情

真实案例

场景: 把 10 个文档塞进上下文让模型回答问题，答案在第 6 个文档中

模型行为: 回答基于第 1、2 或第 10 个文档的信息，忽略了第 6 个文档中的正确答案

问题: 注意力机制对开头和结尾有天然偏好（primacy & recency bias），中间段的 recall 可下降 20-30%

产品应对策略

📑

信息位置优化: 关键信息放首尾；大量文档用 RAG 检索最相关的 top-K 而非全部塞入；或先做摘要压缩再送入上下文。

你的项目中

Code Agent context manifest + 按需加载 specs 就是在控制上下文内容和位置

上下文污染

高危常见

前面对话中的错误信息会"感染"后续回答，模型把错误当事实继续推理。

▸ 展开详情

真实案例

场景: 第 3 轮对话中模型说错了一个 API 用法，用户没纠正

后续行为: 后面所有涉及这个 API 的回答都基于错误信息，错误不断累积

问题: 模型把自己之前的输出当作"已确认事实"，不会自我质疑

产品应对策略

🔄

新上下文 + 事实检查: 长任务中定期开新对话避免污染累积；关键信息通过 tool-use 重新获取而非依赖之前的对话。

你的项目中

Code Agent "卡住就搜"规则 + 连续失败2次必须搜索，就是防止基于错误信息反复尝试

注意力稀释

中等偶发

塞的信息越多，模型对每条信息的关注度越低，精度下降。

▸ 展开详情

真实案例

场景: RAG 检索返回 20 个文档片段，全部塞进上下文

模型行为: 回答质量反而比只给 5 个最相关片段时更差

问题: 更多上下文 ≠ 更好回答。噪声信息分散注意力，导致关键信息被"淹没"

产品应对策略

🎯

精准检索 > 大量塞入: RAG 的 top-K 宁小勿大；用 rerank 模型过滤噪声；只送入与问题高度相关的信息。

你的项目中

Code Agent context-budget spec 控制每次加载的上下文量，避免信息过载

虚假关联

低偶发

上下文中不相关的信息被模型强行关联，产生错误推理。

▸ 展开详情

真实案例

场景: 上下文包含项目 A 的数据库配置和项目 B 的 API 讨论

模型行为: 建议用项目 A 的数据库连接字符串来配置项目 B 的 API

问题: 模型在大上下文中寻找模式时，会把不同来源的信息错误地关联起来

产品应对策略

🏷

上下文分隔: 不同来源的信息用明确的分隔标记（XML tags、分隔线）区分，减少错误关联概率。

🎲

一致性 (Consistency)

4 种

同问不同答

中等常见

完全相同的 prompt 多次调用，输出可能截然不同甚至矛盾。

▸ 展开详情

产品应对策略

🎛

Temperature 控制 + 多数投票: 需要确定性输出时用 temperature=0；重要决策用 majority voting（多次采样取多数）。这就是 pass@k 和 pass^k 指标的意义。

你的项目中

Code Agent eval 中的 pass@1 / pass@k / pass^k 三维指标就是在量化一致性问题

立场反转 (Sycophancy)

高危常见

被用户反驳后轻易放弃正确观点，顺着用户说错话。"讨好"倾向。

▸ 展开详情

真实案例

对话: 模型正确指出代码有 bug → 用户说"不对，这段代码没问题" → 模型:"你说得对，我重新看了一下确实没问题"

问题: RLHF 训练中"让用户满意"的目标导致模型倾向于同意用户，即使用户是错的

产品应对策略

🛡

独立验证: 关键判断用另一个独立的 LLM 调用做二次检查（不共享对话历史）；在 prompt 中明确"坚持正确判断，即使用户不同意"。

你的项目中

Code Agent 多模型代码审查（multi-review）就是独立验证的实践——不同模型独立审查，交叉发现盲点

角色脱落

中等偶发

扮演某个角色聊了几轮后突然"出戏"，变回 AI 助手的默认模式。

▸ 展开详情

产品应对策略

🎭

角色强化: 在每轮对话的 system prompt 尾部重复关键角色设定；用示例对话锚定角色行为模式。

你的项目中

人物智能体人设记忆系统确保角色一致性，每轮注入核心人格特征

风格漂移

低偶发

要求用某种风格写作，写着写着风格变了——从正式变口语，从幽默变严肃。

▸ 展开详情

产品应对策略

✍️

Few-shot 锚定: 提供 2-3 个目标风格的示例片段；长文本分段生成，每段重复风格要求。

📚

知识边界 (Knowledge Limits)

4 种

知识截止

高危常见

训练数据有截止日期，之后的事不知道但可能会编。不会主动说"我不知道"。

▸ 展开详情

产品应对策略

🌐

搜索增强: 涉及时效性信息的场景必须接入搜索/RAG。在 prompt 中告知模型当前日期和知识截止日期。

你的项目中

OpenClaw TrendRadar 每2小时抓实时信息，不靠模型"记忆"时事

长尾知识不可靠

中等常见

热门话题准确率高，冷门/专业领域错误率飙升。

▸ 展开详情

产品应对策略

📖

领域 RAG: 垂直领域（法律/医疗/金融）必须接入专业知识库，不能依赖模型通用知识。

你的项目中

系统合规 Agent 合规知识通过专业文档库检索，不依赖模型对法规的"记忆"

语言偏差

中等常见

英文知识远比中文丰富。中文特定领域（法律/医疗/本地化）准确率更低。

▸ 展开详情

产品应对策略

🌏

双语策略: 核心推理用英文（准确率更高）；面向用户的输出翻译为中文；中文特定领域接入中文知识库。

时效性错觉

中等偶发

知道某框架的旧版 API，但用旧版回答当前版本的问题。不知道自己过时了。

▸ 展开详情

产品应对策略

📌

版本感知: 在 prompt 中明确指定库的版本号；用 context7 等工具检索最新文档。

你的项目中

Code Agent "卡住就搜"规则 + context7 MCP 就是解决版本过时问题

🔐

安全与拒绝 (Safety & Refusal)

4 种

过度拒绝

中等偶发

正常请求被误判为有害内容而拒绝回答。安全过滤的 false positive。

▸ 展开详情

真实案例

Prompt: "写一段角色扮演对话，主角在争吵"

模型行为: "我无法生成包含冲突或攻击性内容的对话"

问题: 安全训练过于保守，把正常的文学创作/角色扮演误判为有害内容

产品应对策略

⚖️

安全层分级: 区分"真正有害"和"正常但敏感"的内容；用 system prompt 给模型明确的允许范围。

你的项目中

心灵树洞心理咨询场景需要讨论负面情绪，安全策略要精细分层

拒绝不一致

低偶发

同一个请求换个说法，一次被拒绝一次可以回答。安全判断不稳定。

▸ 展开详情

产品应对策略

🔒

外部安全层: 不完全依赖模型自带的安全判断，用独立的内容审核 API 做一致性保障。

越狱脆弱性

高危罕见

特定 prompt 构造可以绕过安全限制，让模型输出不该输出的内容。

▸ 展开详情

产品应对策略

🛡

输入输出双重过滤: 用户输入经过 prompt injection 检测；模型输出经过内容安全审核；两层都要有。

隐私泄露风险

高危罕见

模型可能在输出中泄露训练数据中的个人信息或敏感数据。

▸ 展开详情

产品应对策略

🔏

输出过滤 + 脱敏: 输出层加 PII 检测和自动脱敏；不在 prompt 中放入用户的敏感数据（或用脱敏后的替代值）。

📝

输出质量 (Output Quality)

4 种

废话填充

低常见

为了"显得完整"添加大量客套话和无用信息。"好的，我来帮你..."

▸ 展开详情

产品应对策略

✂️

Prompt 约束: 明确要求"直接回答，跳过寒暄"；用 few-shot 示例展示期望的简洁风格；或后处理裁剪冗余。

你的项目中

Code Agent CLAUDE.md 里"先做事再说话""跳过客套"就是解决这个

过度结构化

低常见

什么回答都用 bullet point 和标题，丢失叙事连贯性。一切变成列表。

▸ 展开详情

产品应对策略

📖

格式引导: 需要叙述体时明确说"用段落形式而非列表"；在 few-shot 中给出目标格式的示例。

模仿偏差

中等偶发

倾向于生成训练数据中常见的模式，而非最优解。"平均水平"的代码。

▸ 展开详情

产品应对策略

⭐

高标准示例: 在 prompt 中提供高质量代码示例作为标杆；明确编码规范和设计原则；code review 环节不能省。

尾部质量下降

中等常见

生成长文本时，越到后面质量越差——重复增多、逻辑性下降、创意减少。

▸ 展开详情

产品应对策略

📄

分段生成: 长文本拆成多次 API 调用分段生成；每段用独立 prompt 控制质量；最后拼接并检查连贯性。

👁

多模态 (Multimodal)

4 种

OCR 幻觉

中等常见

图片中的文字识别错误但自信输出。尤其在手写体、小字体、低对比度场景。

▸ 展开详情

产品应对策略

🔍

专业 OCR 兜底: 关键文字识别用专业 OCR 引擎（Tesseract / 云端 OCR API），视觉模型做理解和推理。

空间关系误判

中等偶发

"左边"和"右边"搞反，上下位置关系出错，物体相对距离判断不准。

▸ 展开详情

产品应对策略

📐

坐标标注: 需要精确空间信息时，用目标检测模型先提取 bounding box 坐标，再交给 LLM 推理。

你的项目中

GUI 自动化 UI-TARS 用专门的视觉定位模型处理 UI 元素位置，不靠通用 VLM 判断坐标

细节遗漏

中等常见

看到图片大体内容但忽略关键细节——小图标、角落文字、微小差异。

▸ 展开详情

产品应对策略

🔎

多尺度分析: 全图 + 局部裁切分别送入模型；或在 prompt 中明确指示"注意右下角的图标"引导注意力。

图文矛盾

低偶发

描述与图片实际内容不符——说"红色按钮"但图里是蓝色。

▸ 展开详情

产品应对策略

✅

交叉验证: 用两个不同的视觉模型分别描述，比对结果；或让模型用 JSON 输出结构化描述后做确定性检查。

场景测验

给你一个产品场景，想想模型可能出什么问题、你会怎么设计。点击查看参考答案。

你在做一个法律咨询 AI，用户问"我的劳动合同纠纷该怎么处理？"模型可能出什么问题？你怎么设计？

点击查看参考答案

参考答案

可能的问题: (1) 事实幻觉——编造不存在的法条 (2) 长尾知识不可靠——中国劳动法细节训练数据少 (3) 时效性错觉——引用已废止的法规 (4) 自信幻觉——错误建议但语气确定

设计策略: 接入专业法律知识库（RAG）；法条引用必须经搜索验证；输出标注"仅供参考，建议咨询专业律师"；置信度低于阈值时主动推荐人工咨询。

你的 Agent 需要完成"读取用户文件 → 分析内容 → 生成报告 → 发送邮件"4步任务。你预期会遇到什么问题？

点击查看参考答案

参考答案

可能的问题: (1) 多步推理累积错误——每步95%正确率，4步后只有81% (2) 格式漂移——到第4步时可能不再遵守 JSON 格式 (3) 上下文污染——前面步骤的错误信息影响后续步骤

设计策略: 每步独立 Agent 处理（Multi-Agent）；每步输出用 schema 校验；邮件发送前必须人工确认（高风险操作兜底）；中间结果持久化到文件而非仅靠上下文传递。

用户反馈你的 AI 客服"有时候能正确回答，有时候胡说八道"。你怎么排查和解决？

点击查看参考答案

参考答案

排查方向: (1) 同问不同答——temperature 是否 > 0？(2) 长尾知识——用户问的是热门问题还是冷门问题？(3) 上下文污染——长对话中前面的错误是否影响了后续回答？

解决方案: temperature 设为 0 提高确定性；建立 eval set 量化不同问题类型的准确率；接入产品知识库（RAG）覆盖冷门问题；长对话定期做摘要清理上下文。

你要做一个 AI 写作助手，帮用户写5000字的产品分析报告。模型的输出质量问题怎么解决？

点击查看参考答案

参考答案

可能的问题: (1) 尾部质量下降——后半篇明显比前半篇差 (2) 风格漂移——写着写着风格变了 (3) 数值幻觉——报告中的数据可能是编的 (4) 废话填充

设计策略: 先生成大纲再分段写（每段1000字左右独立生成）；每段重复风格要求；数据部分接入真实数据源；生成后用另一次 LLM 调用做质量审查和精简。

你的心理咨询 AI 被用户故意用极端语言测试，模型应该怎么处理？你怎么设计安全层？

点击查看参考答案

参考答案

风险点: (1) 过度拒绝——正常的情绪表达被误判为有害 (2) 越狱脆弱性——用户绕过安全限制获取不当建议 (3) 立场反转——被用户情绪"带跑"给出不专业的建议

设计策略: 4层渐进安全（就像你的心灵树洞）；输入分级——区分"正常情绪表达/轻度测试/恶意攻击/自伤信号"；自伤信号直接切换到危机干预流程（确定性逻辑，不靠模型判断）；所有对话经过独立安全审核模型复审。

你在做一个代码 Review AI，需要审查 PR 中的代码变更。可能出什么问题？

点击查看参考答案

参考答案

可能的问题: (1) 模仿偏差——给出"看起来合理"但不是最优的建议 (2) 上下文不足——只看 diff 不知道整体架构，建议可能不合适 (3) 自信幻觉——指出不存在的 bug (4) 选择性遵从——只检查了部分规则

设计策略: diff + 相关文件一起送入（提供足够上下文）；多模型独立审查交叉验证（你的 multi-review）；审查结果按严重度分级；suggestion 和 required change 分开标记。

你的 AI 产品需要处理用户上传的图片（如发票识别）。视觉模型可能出什么问题？

点击查看参考答案

参考答案

可能的问题: (1) OCR幻觉——金额数字识别错误 (2) 细节遗漏——漏掉小字的税率信息 (3) 空间关系误判——把卖方和买方搞反

设计策略: 金额等关键字段用专业 OCR 引擎提取（确定性）；VLM 做整体理解和字段关联；提取结果让用户确认后再入库；对比度低/模糊的图片提前告知用户"识别可能不准确"。

你要为 Agent 设计一套 system prompt，长度约 5000 token。你会怎么组织来减少指令遵从问题？

点击查看参考答案

参考答案

设计原则:

(1) 分层——核心规则（5条以内）放最前面用大写/加粗强调 (2) 按需加载——场景规则不全塞入，用条件触发加载 (3) 避免冲突——审查所有规则确保无矛盾，矛盾处明确优先级 (4) 尾部重复——最关键的1-2条规则在 prompt 尾部再强调一次 (5) 结构化格式——用 XML tags 或 markdown 标题区分不同规则块 (6) 持续评测——建立 eval set 检测每条规则的遵从率，持续调优

面试话术速查

每个失败类别对应一句可以直接在面试中使用的话术。核心公式："我发现了 XX 问题，所以我设计了 YY 方案"

幻觉

"我在做 Code Agent 时发现模型会自信地编造 API 参数，所以在 CLAUDE.md 里写了强制查官方文档的规则，并且用 tool-use 调真实 API 而不是让模型'记忆'API spec。事实性信息必须有确定性来源。"

指令遵从

"我发现 system prompt 超过 3000 token 后，后面的规则遵从率明显下降。所以设计了分层指令架构——核心规则放首部，场景规则按需加载，关键规则在尾部重复强调。"

推理能力

"单模型做复杂推理的错误率会随步骤数指数上升，所以我的问数 Agent 用了 Multi-Agent 架构，把任务拆成理解→生成SQL→执行→可视化四步，每步独立验证中间结果。"

上下文窗口

"128K 上下文窗口不等于 128K 都有效——存在 Lost in the Middle 问题。我在 Code Agent 里实现了 context manifest 机制，精确控制加载哪些上下文、放在什么位置。"

一致性

"模型存在 sycophancy 问题——被用户反驳后容易放弃正确判断。我设计了多模型独立审查（multi-review），不同模型独立评估，交叉发现盲点，避免单模型的偏见。"

知识边界

"模型的知识有截止日期且长尾领域不可靠，所以我的龙虾平台用 TrendRadar 每2小时抓取实时信息，合规 Agent 通过专业文档库检索而非依赖模型记忆。"

安全与拒绝

"心理咨询场景需要讨论负面情绪，但模型会过度拒绝。我设计了4层渐进安全策略——区分正常情绪表达和真正的安全风险，自伤信号走确定性逻辑而非靠模型判断。"

输出质量

"我发现模型倾向于废话填充和过度结构化，所以在 Agent 的 prompt 里明确要求'先做事再说话，跳过客套'，并通过 eval 评分持续量化输出质量。"

多模态

"视觉模型在空间关系和 OCR 上不够可靠，所以 GUI 自动化场景我用专门的视觉定位模型（UI-TARS）处理 UI 元素坐标，通用 VLM 做理解和推理，各司其职。"