如何使用Gemini构建AI功能：面向开发者的提示工程实用指南
内容提要
本文基于真实应用，探讨了将AI功能从“能返回文本”提升到“用户真正信任”的实践过程。核心观点包括：仅在输入无界且输出需判断时才使用AI；通过具体禁令和反例优化提示词；用规则界定边界、用示例塑造风格；对模型输出进行防御性解析；建立人工QA清单评估质量；并妥善处理模型故障。文章强调，AI功能的质量取决于能否明确识别并记录失败案例。
延伸解读
AI并非万能：先判断是否真的需要模型
文章强调，并非所有功能都需要AI。作者用正则表达式实现主题标签分类，避免了模型调用的延迟、成本和额外故障点。核心判断标准是：输入空间是否无界，输出是否需要判断。只有两者都满足时才值得使用AI，否则传统代码更可靠、更易维护。
提示词工程：从“能返回文本”到“用户信任”
文章指出，提示词工程的关键在于处理模型输出与用户期望之间的差距。通过具体禁令、反例和显式推理步骤，可以显著提升输出质量。例如，禁止“我理解你的感受”等开场白，并展示错误示例，能有效减少模型臆造用户未提及的内容。
防御性解析与优雅降级：处理模型输出的不确定性
模型输出常包含多余内容或格式错误，因此需要防御性解析。文章建议用正则提取JSON，并用try/catch包裹解析，失败时降级为原始文本返回，确保用户始终得到响应。这种策略适用于人类阅读的场景，但若下游代码依赖结构化数据，则应硬失败。
质量评估：手动QA清单与红旗检查
由于AI输出非确定性，自动化测试难以覆盖质量。作者建议建立手动QA清单，包含固定输入和“预期范围”而非精确输出，并列出负面标准（如禁止臆造细节）。同时，通过识别“验证性开场白”“发明细节”等红旗，可快速发现模型漂移。
Q&A
如何判断一个功能是否适合使用AI？
只有当输入空间无界且输出需要判断时才使用AI。如果输入有界或输出是机械性的，应该用代码实现，例如正则表达式。
在提示工程中，如何避免模型生成泛泛而谈或虚构内容的回答？
通过具体禁令和反例来约束模型，例如禁止以“我理解你的感受”开头，并提供包含输入、错误回答和失败原因的反例。同时，明确要求模型只基于用户实际说的内容回应，不要推断未陈述的意图。
如何让AI输出结构化的JSON数据，并安全地解析？
在提示中直接给出JSON的示例结构，并明确要求只返回JSON。解析时使用正则提取JSON部分，用try/catch包裹解析，失败时降级返回原始文本而不是报错。
如何评估AI功能的质量，而不仅仅是正确性？
建立人工QA清单，包含固定输入和明确的通过标准，标准多为负面条件（如不得假设用户未表达的内容），并给出期望范围而非单一输出。清单应基于真实回归案例，并包含症状到原因的映射。
当AI模型调用失败时，应该如何处理？
采用重试和模型降级策略，最多尝试3次，第一次失败后切换到备用模型，并使用指数退避（500ms和1s）。同时，将真实错误记录到日志，向用户显示友好的错误消息。对于安全拦截，将其作为内容处理，而不是异常。
如何防止API密钥泄露到浏览器？
确保API密钥只保存在服务器端，通过环境变量管理，前端通过自己的后端调用AI，而不是直接调用Gemini。在Next.js中，在路由处理程序或服务器操作中调用模型，避免使用NEXT_PUBLIC_前缀。
在提示工程中，规则和示例各自的作用是什么？
规则定义边界，示例塑造风格。规则-only会导致正确但无生气，示例-only会导致有风格但边缘不可预测。两者需要结合，且示例应包含同一输入的不同有效输出，以避免模型复制单一示例。
如何避免提示词中不同部分之间的冲突？
明确每个提示词组件负责的维度，例如角色、长度、语言、个性，并声明它们独立。当多个组件可能影响同一维度时，指定唯一权威，避免冲突。
