关于 building-with-llms
面向产品团队和开发者的 LLM 应用构建技能，内容涵盖提示词、上下文与架构、评估、迭代以及 AI 工具使用，并汇集从业者经验。
主要功能
- 01诊断提示词、上下文和模型问题
- 02应用提示词模式
- 03设计上下文与模型架构
- 04系统评估输出
- 05借助 AI 工具迭代和调试
适用场景
- 01构建聊天机器人或 Agent
- 02用示例改善模型回复
- 03为 AI 功能建立评估
- 04排查不稳定的输出
MCP 相关
该技能指出，模型决策不佳时可通过 MCP 或 RAG 提供更好的上下文；未说明它是 MCP 服务或客户端。
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/building-with-llms确认已加载。
附带文件references/guest-insights.md
详细介绍
使用大模型构建应用
运用 60 位产品负责人和 AI 从业者的实用技巧，帮助用户构建高效的 AI 应用。
如何提供帮助
当用户询问如何使用大模型构建应用时：
- 了解他们的用例——询问他们正在构建什么（聊天机器人、Agent、内容生成、代码助手等）
- 诊断问题——帮助判断问题是与提示词、上下文还是模型选择有关
- 应用相关技巧——分享具体的提示词模式、架构方法或评估方法
- 指出常见错误——反对过度依赖直觉、跳过评估，或为任务选择了错误的模型
核心原则
提示词
少样本示例胜过文字描述
Sander Schulhoff：“如果只能推荐一种技巧，那就是少样本提示——提供你想要的示例。与其描述你的写作风格，不如贴出几封以前的邮件，然后说‘照这样写’。”
提供你的观点
Wes Kao：“分享我的观点能让输出好得多。不要只问‘你会怎么说？’要告诉它：‘我想拒绝，但也希望维持这段关系。我理想中的做法是……’”
将复杂任务拆解
Sander Schulhoff：“问‘需要先解决哪些子问题？’列出清单，逐一解决，然后综合起来。不要让模型一次性解决所有问题。”
自我批评能改善输出
Sander Schulhoff：“让大模型检查并批评自己的回答，然后改进。只要提示模型去检查，它们就能发现自己的错误。”
角色设定有助于控制风格，而非提升准确性
Sander Schulhoff：“‘扮演一位教授’之类的角色设定对准确性任务没有帮助，但很适合控制创意类工作的语气和风格。”
将上下文放在开头
Sander Schulhoff：“把较长的上下文放在提示词开头。这样可以缓存（成本更低），而且模型处理时不会忘记任务。”
架构
上下文工程 > 提示词工程
Bret Taylor：“如果模型做出了糟糕的决定，通常是因为缺少上下文。要从根源解决——通过 MCP 或 RAG 提供更好的数据。”
RAG 质量 = 数据准备质量
Chip Huyen：“最大的提升来自数据准备，而非向量数据库的选择。将源数据改写成问答形式，并添加注释，补充人类习以为常的上下文信息。”
分层使用模型以增强稳健性
Bret Taylor：“让 AI 监督 AI 很有效。将认知步骤分层——一个模型生成内容，另一个模型审核。这能让准确率从 90% 提升到 99%。”
针对专门任务使用专用模型
Amjad Masad：“我们用 Claude Sonnet 编写代码，用其他模型进行批评。由不同角色组成的‘模型社会’胜过单一通用模型。”
200ms 是延迟阈值
Ryan J. Salva（GitHub Copilot）：“实时建议的理想延迟约为 200ms。更慢会让人觉得被打断。围绕这一限制设计架构。”
评估
评估必不可少，不是可选项
Kevin Weil（OpenAI）：“编写评估正成为一项核心产品技能。可靠率为 60% 的模型，需要与可靠率为 95% 或 99.5% 的模型不同的 UX。不了解准确率，就无法进行设计。”
二元评分 > 李克特量表
Hamel Husain：“用通过／不通过，而不是 1-5 分。量表会产生‘3.7’这类毫无意义的平均分。二元评分迫使你做出明确判断。”
从直觉测试开始，再逐步转向评估
Howie Liu：“对于新颖的产品，先进行开放式直觉测试。只有在用例趋于一致后，才转向正式评估。”
验证你的大模型评判者
Hamel Husain：“如果使用大模型作为评判者，就必须评估这套评估。衡量它与人类专家的一致程度，并不断迭代，直到两者一致。”
构建与迭代
失败时重试——模型具有随机性 Benjamin Mann（Anthropic）：“如果失败了，就用完全相同的提示词再试一次。重试的成功率远高于继续沿用行不通的方法。”
大胆提出需求 Benjamin Mann：“高效和低效的 Claude Code 用户之间的区别在于：是否敢于提出大胆的需求。要求进行大改动，而不是一点点微调。”
不同模型之间交叉借鉴 Guillermo Rauch：“迭代 100 多次仍然卡住时，把代码复制到另一个模型中（例如，从 v0 转到 ChatGPT o1）。全新的视角能帮你突破瓶颈。”
复利式工程 Dan Shipper：“每完成一项工作，都要让下一项工作变得更容易。保存有效的提示词，建立一个库。团队使用 AI 的成效会不断累积。”
使用 AI 工具
学会阅读和调试，而不是死记语法 Amjad Masad：“AI 能放大编程的效用，因此编程的投资回报率每 6 个月就翻一倍。专注于阅读代码和调试——语法交给 AI 处理。”
用聊天模式理解问题 Anton Osika：“使用‘聊天模式’让 AI 解释其逻辑。问：‘你为什么这么做？我遗漏了什么？’把它当作导师。”
Vibe 编码是一项真正的技能 Elena Verna：“我把 Vibe 编码写进了简历。在交给工程团队之前，先用自然语言构建功能原型。”
帮助用户思考的问题
- “你正在构建什么？要解决的核心用户问题是什么？”
- “模型最常在哪些方面出错？”
- “你是在系统地衡量成功，还是仅凭感觉？”
- “模型可以访问哪些上下文？”
- “你试过少样本示例吗？”
- “重试失败的提示词会有什么结果？”
需要指出的常见错误
- 永远只凭感觉——最终你需要真正的评估，而不只是“感觉不错”
- 只关注提示词——问题往往出在上下文不够好，而不是提示词不够好
- 所有任务都用同一个模型——不同模型各有所长
- 失败一次就放弃——随机性系统需要重试
- 跳过人工审核——AI 输出需要人工验证，尤其是在早期阶段
深入了解
有关 60 位嘉宾分享的全部 110 条见解，请参阅 references/guest-insights.md
相关技能
- AI 产品策略
- AI 评估
- Vibe 编码
- 评估新技术