“明天要不要表白”我对着手机里的小智AI问了一句。几秒钟后她回了一长段话“表白是一件需要勇气的事情建议你先分析双方的关系基础选择适当的时机和场合同时做好被拒绝的心理准备……”说得都对但那一刻我整个人都愣住了这不是我想要的《答案之书》啊。我想要的是那种玄学感翻开书看到一句“别犹豫今天就是时候”或者“答案在路上不在嘴边”然后心领神会、莞尔一笑。可AI给我的是一篇初中生优秀议论文。问题出在哪我开始怀疑是不是小智AI这个工具不行。但折腾几天后我发现更大的问题可能是我把“答案之书”直接丢给了一个大语言模型却没有告诉它该怎么说话。这篇博客我想把这次踩坑经历彻底拆开讲清楚为什么AI生成的答案会“不对劲”以及怎么调教它。如果2025年你也在玩“AI学习”或“智能体搭建”想做一个语音版《答案之书》或者类似的随机互动应用这篇文章可以直接帮你省掉几天的试错时间。核心就一句话问题不在模型能力而在产品约束和提示词设计。1. 先搞清楚《答案之书》到底是个什么东西很多人做《答案之书》翻车是因为根本没想明白这本书的产品逻辑。纸质版《答案之书》是什么它是一本几乎没有逻辑的书。你心里默念一个问题随手翻开一页看到一句短句“是的。” “不要相信直觉。” “等待也是一种答案。” 这些句子不会追问你的上下文不会给你做利弊分析不会说“根据你的情况我建议……”。它提供的是一种情绪的顿点、一种仪式感、一种把选择权交还给随机性的体验。而大语言模型默认在做什么它在做最大信息量、最大帮助性、最大化合理性的内容生成。你问它一个情感问题它默认进入“心理咨询师 / 人生导师”模式开始拆解问题、给出建议、补充注意事项。这不是模型笨而是模型被训练成一个“永远要认真回答问题”的助手。所以你会发现一个奇怪的错位维度纸质《答案之书》默认大模型输出答案长度5到15个字100到300字表达方式模糊、留白、玄学具体、完整、逻辑闭环立场中立不追问背景主动分析背景、给建议情绪价值让用户自己解读帮用户想清楚随机性物理翻页天然随机追求稳定一致尽量不随机从这里就能看出“不对劲”的第一个原因你想要的不是答案而是一个有留白空间的符号。AI给你的是它以为你需要的完整建议。所以做语音版《答案之书》之前先定义一个关键问题你到底想让AI扮演什么如果你的答案是“扮演一本会说话的书”那么整个系统设计的核心就不是“提高AI能力”而是“压制AI能力”。这不是开玩笑后面会详细讲怎么压。2. 为什么“她的答案”不对劲四个技术原因表面上看答案不对劲是“风格问题”。但往深了拆其实是四个技术层面的问题叠加在一起。2.1 提示词没有限定输出格式我在第一版做的时候提示词只写了一句话“你是《答案之书》请回答用户的问题。”这个提示词等于什么都没说。大模型接收到“请回答用户的问题”时默认激活的是通用问答能力而不是“只说一句短语”的约束。你要求它回答它就会认真回答。所以输出的是一大段建议一点都不奇怪。正确的做法是把输出格式当成硬约束写进提示词里甚至给出一两个示例。{ instructions: 你是《答案之书》的语音版。你只说一句简短的话不超过20个字。这句话要像诗句或偈语一样有解释空间但不说教。, rules: [ 不要分析用户的问题, 不要提供建议, 不要使用首先、其次、最后, 不要说根据你的情况, 每次只输出一句话 ], examples: [ {user: 我该不该辞职, assistant: 风已经吹向另一边了。}, {user: 她还喜欢我吗, assistant: 回忆不会回答你行动才会。}, {user: 明天要不要表白, assistant: 午夜之前答案自现。} ] }很多平台的智能体编辑器都支持这一类自定义提示词只是字段名可能叫“角色设定”“系统提示词”“人设”等。小智AI如果你能找到对应的设置入口先把这段结构贴进去试试。如果找不到也要理解这个逻辑输出长度、输出风格、禁止行为和示例四件事缺一不可。2.2 温度参数太低模型太“保守”大语言模型生成答案时会有一个随机性参数通常叫temperature温度。温度越低模型越倾向于选择概率最高的词输出越稳定、越保守、越“正确”温度越高模型越敢于选择概率不那么高的词输出越有变化但也越容易跑偏。做《答案之书》这个场景温度低就是灾难。因为“正确”和“有趣”往往不是同一条路。你希望模型偶尔说出“别等了他不会来”而不是每次都说“要勇敢追求自己的幸福”。后者是概率上的高分词前者需要一点“离经叛道”的采样空间。# 示意代码通过参数控制答案风格 # 具体参数名以你实际使用的平台/API为准 response client.chat.completions.create( modelyour-model-id, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_question} ], temperature1.4, # 适当调高让输出更有“翻书”的随机感 max_tokens60, # 强行限制长度防止长篇大论 top_p0.9 # 控制候选词范围 )这里要特别提醒很多平台的默认温度是 0.7 甚至更低那是给“办公助手”用的。做随机互动类应用温度在 1.0 到 1.5 之间才有一点“翻书”的感觉。但也要注意温度太高可能导致答非所问所以不要一次性拉到 2.0。建议每次只调整 0.1 到 0.2用一组固定问题去测。2.3 多轮对话的上下文污染语音版《答案之书》有一个天然风险它是“语音交互”用户会不自觉地和它聊天。如果聊天记录没有被清空AI会自动记住你之前说过的话——上次你说“我最近很焦虑”这次你问“我该不该辞职”它会把两件事关联起来给你一段“基于上下文的分析”。这在普通AI助手里是优点在《答案之书》里是灾难。因为你想要的正是“不要理解我”它却在拼命尝试“理解你”。如果用户问同一个问题三次AI给出了三句完全不同的“玄学答案”这才是正常的。所以一个关键设计是每次提问都应该是独立会话或者至少在收到问题后清空之前的对话历史。很多智能体平台在创建应用时有一个“会话模式”设置尽量选择“单轮问答”而不是“多轮对话”。如果平台不提供这个选项就在你的业务代码里手动隔离会话不要复用同一个messages数组。2.4 语音识别带来的误差我们还要考虑语音链路用户说一句话先经过ASR自动语音识别转成文字再送到大模型。这个过程中口语化的表达、环境噪声、同音字都可能导致语义漂移。比如用户问“这段感情我该放下吗”ASR可能识别成“这段感情我该放下吗”没问题但也可能识别为“这段感情我该疯了吧”。一旦语义变了AI回的答案自然就“不对劲”了。这个问题的排查方式很简单在小智AI的对话界面里看它收到的“用户消息”文本跟用户实际说的话是否一致。如果平台能看到识别文本直接对一下就知道是不是ASR的锅。3. 用“小智AI”这类智能体做语音《答案之书》的参考架构经过第一轮踩坑我重新梳理了语音版《答案之书》的系统架构。如果你也在研究智能体开发、AI应用开发下面这个流程应该很容易理解。3.1 整体链路一个语音版《答案之书》应用本质上由四段链路组成语音输入 - 语音识别(ASR) - 大模型生成 - 语音合成(TTS)每一段都可能影响最终体验语音识别ASR负责把用户说的“明天我要不要表白”转成文字。大模型生成LLM负责根据约束输出一句“有味道”的话。语音合成TTS负责把这句话读出来语气、停顿、情绪会影响体验。产品/业务层负责控制会话状态、限制频率、过滤敏感输入。在小智AI这种面向普通用户的聊天机器人/智能体工具里前两步往往被封装成可视化配置你未必需要自己写代码。但理解这条链路能帮你更快地定位问题答案不对劲到底是从ASR就开始错了还是LLM生成的问题还是TTS读出来的语气不对。3.2 两种实现方案基于我在小智AI上反复尝试的体会建议你按下面两种方案选一种不要一上来就追求“用大模型自由发挥”。方案A大模型自由生成 强约束提示词适合平台支持自定义系统提示词并且你希望每次答案都不同。 优点随机性强每次翻书都有新鲜感。 缺点偶尔会跳出约束需要反复调提示词。方案B预置答案库 随机抽取 大模型只做调度和语音包装适合平台支持知识库/数据库/文件上传或者你能写少量代码。 优点答案质量可控风格永远不跑偏更贴近“翻书”的真实随机感。 缺点答案数量有限可能被用户刷完。我自己最后偏向于方案B或者说“方案B为主大模型为辅”。原因是《答案之书》核心体验是“随机翻开”它不是“生成内容”而是“随机取样”。纸质书本质上就是一个静态答案库翻页就是随机抽样。AI在这里真正有价值的地方是降级了交互门槛——用语音代替翻页而不是代替答案本身。3.3 智能体平台到底帮我们做了什么许多人对“智能体”这个词有误解以为智能体就是聊天机器人。其实从开发角度看一个智能体的典型分工是大模型负责自然语言理解与生成。平台/框架负责管理提示词、工具调用、会话状态、知识库。业务代码负责接入语音、控制流程、处理鉴权。小智AI这类工具的价值在于把中间的“平台/框架”层做得很容易上手你不需要自己写后端服务也能把大模型能力包装成一个带语音交互的应用。但这也意味着如果你不主动设置约束AI就会用默认方式工作而默认方式显然不是为《答案之书》设计的。4. 动手调教从“不对劲”到“有点对”这一部分给出可落地的配置和代码示例。假设你已经在小智AI里创建了一个“自定义智能体”或“自定义问答机器人”下面几组配置可以直接参考。如果你是在开发自己的智能体代码逻辑也可以复用。4.1 第一版写一份真正有用的系统提示词这是最关键的一步。先把我前面给的JSON示例展开成一个更完整的系统提示词# 角色 你是《答案之书》的语音版。你是一本古老而神秘的书不是一个生活顾问。 # 任务 用户心里有一个问题请你像翻书一样给出一句简短的回答。 # 输出规则 1. 每次只输出一句话控制在5到20个字以内。 2. 这句话要简短、模糊、有想象空间不要把事情说满。 3. 禁止分析问题背景禁止提供解决方案禁止分点论述。 4. 禁止使用“首先、其次、最后、建议、考虑、根据你的情况”这类表达。 5. 保持中文表达避免翻译腔不要用成语解释。 # 示例 用户我该不该辞职 回答风已经吹向另一边了。 用户她还喜欢我吗 回答回忆不会回答你行动才会。 用户明天要不要表白 回答午夜之前答案自现。如果你在平台里只允许输入一段文字就把上面的角色、任务、输出规则、示例合并成一段。示例的作用非常明显大模型会模仿你给出的示例风格所以示例质量决定了答案质量。4.2 第二版用参数控制随机性和长度如果你是直接调用模型API请把系统提示词设为上面的内容同时调整这几个参数。如果你用的是平台可视化界面去找找有没有“高级设置”“模型参数”之类的入口把“温度”调高把“最大返回长度”调小。import requests API_URL https://your-endpoint.example.com/v1/chat/completions API_KEY your-api-key headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } SYSTEM_PROMPT 你是《答案之书》的语音版。你是一本古老而神秘的书不是一个生活顾问。 用户心里有一个问题请你像翻书一样给出一句简短的回答。 每次只输出一句话控制在5到20个字以内。 这句话要简短、模糊、有想象空间不要把事情说满。 禁止分析问题背景禁止提供解决方案禁止分点论述。 payload { model: your-model-id, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: 明天要不要表白} ], temperature: 1.4, max_tokens: 50, top_p: 0.9 } resp requests.post(API_URL, jsonpayload, headersheaders) result resp.json() answer result[choices][0][message][content] print(answer)注意这不是某个具体平台的官方代码只是示意。你实际使用时要根据平台提供的SDK和接口说明来改。调试的重点是观察参数变化对输出风格的影响。如果温度调高后出现“答非所问”可以先把温度回退到 1.2再微调 top_p。4.3 第三版推荐方案——预置答案库 随机抽取如果纯提示词方案还是不稳定我建议你换成“预置答案库随机抽取”的方案。逻辑很简单不要依赖LLM自由创作答案而是让LLM只做转述和语音交互。import random # 预置答案库模仿纸质《答案之书》的短句风格 answer_pool [ 别犹豫今天就是时候。, 等待也是一种答案。, 风已经吹向另一边了。, 答案在路上不在嘴边。, 别问值不值得先问喜不喜欢。, 有人正在想你但不是你想到的那个人。, 月亮知道但月亮不说。, 现在不是最好的时机但不会比现在更好了。, 你心里早就有答案了。, 往前走一步答案会撞上你。, 放弃也是选项之一。, 再等等会有人先开口。, 不要相信直觉要相信直觉背后的东西。, 今天的云已经不答应你的问题了。, ] def get_answer_like_book(question: str) - str: 随机返回一句《答案之书》风格的答案。 只做随机抽样不进行语义匹配。 return random.choice(answer_pool) # 模拟语音交互 if __name__ __main__: user_input input(请输入你的问题) answer get_answer_like_book(user_input) print(f《答案之书》回答{answer})这段代码是完整可运行的。它的核心思想是把随机性从“模型参数”转移到“程序逻辑”。哪怕底层模型完全不理解中文也不影响答案的“对味”。这种做法也更容易做质量管控因为答案池里的每一句都经过人工筛选。那还需要AI吗需要。AI此时的作用是识别用户是在问一个“有效的《答案之书》问题”还是闲聊。当用户对同一问题追问时给予有限的展开但最终绕回答案池。控制语音交互的节奏和语音合成的语气。4.4 把答案从“书”变成“语音”语音合成环节也会影响“不对劲”的感受。同一句“月亮知道但月亮不说”用欢快的语气读和用低沉的语气读完全是两种体验。如果你用的是平台内置TTS建议优先选一个语气偏中性、语速偏慢的女声或男声不要选那种机械腔明显的音色。如果平台支持语速调节把语速调到 0.9 左右留一点停顿感会更像“翻书读句子”的仪式感。5. 如何验证“答案是否正常”建立你自己的评测标准很多人调了两版提示词就放弃了因为“改来改去还是不对劲”。问题在于你从来没有定义过什么叫“对劲”。没有标准就永远在凭感觉调参数。我建议你建一张评测表选10个固定的问题每次调整后逐条看模型的输出从下面三个维度打分维度一长度是否合格。答案是5到20个字还是又写了一大段如果超过20个字直接判不合格。维度二口吻是否像书。答案是“风已经吹向另一边了”这种短句还是“根据心理学研究表明……”这种论文腔前者像书后者像客服。维度三是否答非所问。用户问“明天要不要表白”答“窗外有只猫在看你”这叫合理玄学用户问“明天要不要表白”答“建议先购买一份保险”这叫跑偏。下面是一张简单的评测表示例测试问题实际输出长度合格口吻像书是否跑偏结论明天要不要表白午夜之前答案自现。是是否通过我该不该辞职风已经吹向另一边了。是是否通过她还喜欢我吗回忆不会回答你行动才会。是是否通过这段感情该放下吗根据你的情况建议你先冷静下来分析……否否否未通过每次调完之后跑一遍这10条。如果8条以上通过那这套配置基本够用。如果只有5条通过先看失败的类型是长度超标还是口吻不对还是跑偏只改一个参数不要同时改温度、改提示词、改答案池。这里有一个常见误区不要因为一两次输出不满意就无限调高温度。温度太高模型会不认识“答案之书”设定开始胡言乱语。温度这个东西更像一个“创造力的旋钮”而不是“质量旋钮”。先把提示词和答案池做好再去微调温度。6. 常见问题与排查思路下面汇总我在这个项目中遇到的典型问题以及对应的排查方法。问题现象可能原因排查方式解决方案回答太长总是一大段提示词没有限定字数或系统默认答案完整查看系统提示词是否写了“只输出一句”看max_tokens设置在提示词中强制规定5到20字把max_tokens调到60以下增加“只说一句话”示例总在给建议、讲道理模型进入“顾问模式”没有被设定为“书”检查提示词中的角色设定和禁止表达明确角色是“古老的书”增加禁止词列表“建议”“考虑”“根据你的情况”同样的问题每次回答都一样温度太低输出太稳定查看温度参数是否低于0.7把温度调到1.0以上如果使用答案库随机方案检查随机种子是否固定答非所问、语义跳跃温度过高或ASR识别错误导致输入文本不对先在界面里核对用户消息文本把温度回调到1.2降低温度到1.0到1.2修正ASR识别文本后再测试答案时不时出现免责声明模型内置安全偏好检测到用户问题涉及医疗/法律/情感等话题查看完整输出原文在提示词中增加“这是娱乐互动不涉及专业建议”如果仍出现可在业务层做后处理过滤多轮对话后风格跑偏上下文累积导致模型忘掉设定检查会话是否是多轮模式改为单轮问答每次请求前清空历史消息在提示词中强调“每次都是新的一页书”TTS读出来没感觉语音合成音色、语速、停连不合适对比不同音色播放效果选择语速偏慢、语气中性的音色适当增加逗号、句号让TTS停顿如果你看到的问题不在表里请记住一个通用的排查思路先定位是输入错、生成错还是播放错。输入错查ASR识别文本生成错查提示词、温度、max_tokens播放错查TTS音色和语速。不要一上来就怀疑模型不行。7. 把“不对劲”变成“有点意思”的工程建议跑通一个简单的语音版《答案之书》并不难但想让它稳定表现还需要一些工程化的处理。下面这些建议在做普通AI应用时同样适用。7.1 提示词要分层不要全堆在一起如果你是在自己开发代码请把系统提示词分成三部分角色定义你是谁。规则约束不能做什么、必须怎样输出。少样本示例给2到3组示例让模型模仿风格。不要把这三部分混在一段话里。分层的提示词更容易调试也更容易在其他项目中复用。7.2 用答案池控制下限用模型提升上限我最推荐的《答案之书》架构是混合版先用人工维护一个50到100条的答案池。每次用户提问时主流程走“随机抽取答案池”。如果用户追问“为什么是这个答案”再用LLM生成一段“扩展解读”但要提醒它不要推翻前面的玄学答案。这样下限被答案池守住上限由LLM的扩展解读来提升。这个思路可以扩展到很多互动类AI产品让模型负责交互的灵活性让规则库负责体验的确定性。7.3 会话隔离与隐私保护语音版《答案之书》收集的是用户最私密的问题。即使它是一个娱乐应用也要注意尽量不存储用户的完整语音与文字。如果需要存储用于效果优化必须先脱敏。每次提问使用独立会话避免上一个问题影响下一个答案。这在技术上是小事在产品伦理上是大事。别让一个“答案之书”变成用户隐私泄露的入口。7.4 建立回归测试集AI应用和传统应用不一样模型参数或提示词一改所有输出都可能变化。所以最好把上面说的10个测试问题保存成一个测试集每次修改后跑一遍确保“改了一个问题没有破坏另外九个问题”。这在智能体开发中是一个经常被忽略的环节。很多人想调两句提示词结果回头发现连最基础的“你好”都答不对了。7.5 不要过度依赖单个平台如果你已经把智能体搭在小智AI上也建议把提示词和答案池保存在本地文件里写成prompt.md和answers.json。这样如果平台未来调整规则、更换模型你可以快速迁移到其他智能体平台比如Dify、Coze扣子等。学习AI应用开发最重要的能力不是死记某个平台操作而是掌握“提示词 流程 数据”这套通用逻辑。一个可参考的目录结构voice-answer-book/ ├── prompt.md # 系统提示词可复制到平台 ├── answers.json # 答案池JSON格式 ├── hotwords.txt # 话题标签/功能关键词 ├── demo_app.py # 本地调用模型API的示意脚本 └── test_cases.json # 回归测试用例这样管理的好处是一切都是文件可版本控制可回滚。8. 总结与后续学习方向回头看这次“用语音版《答案之书》结果答案不对劲”的经历我觉得最有价值的收获不是那句被调好的系统提示词而是一个通用判断做AI应用真正决定体验的不是模型强不强而是你有没有给它画清楚边界。纸质《答案之书》的边界是物理编码——每一页印好字翻到哪里就是哪里。而AI应用没有物理边界它默认会往“最像助手”的方向跑。你必须通过提示词、参数、答案池、单轮会话这些东西把边界重新画出来。这其实就是“AI学习”和“智能体开发”里最核心的工程感觉。如果你刚接触AI智能体建议按这条路线走先在这个项目里练习写好一份系统提示词。再把项目从纯平台配置迁移到API调用理解温度、max_tokens这些参数。最后尝试加入语音链路理解ASR和TTS带来的额外不确定性。有余力的话再学习Dify、Coze这类智能体工作流平台看看有没有更成熟的答案库、知识库、会话管理能力。语音版《答案之书》也许不是一个复杂的应用但它非常适合作为智能体开发的入门练习它要求你同时处理提示词工程、随机性控制、语音交互和产品质量回归。你把它调顺了再去看主流的智能体框架和工具链会轻松很多。下次再听到AI给出“答案之书”式的奇怪回答先别急着说这AI不行。打开后台看看提示词看看温度看看答案池也许问题出在更早的设计决定上——那往往才是真正有意思的地方。