调了一上午 DeepSeek 参数，我总算弄懂了 temperature 和 Top K 的真实作用

真正查过文档才明白，大模型说话时的脑洞大小由多个参数共同控制。过去一直使用默认值，难怪输出不是太保守，就是过度放飞。

大模型造句，本质上是一场概率抽奖

这件事或许有些反直觉：大模型写作时并不理解自己在写什么。每生成一个词，它都会根据前一个词计算全部候选词的概率，再按规则选出一个。比如说完你好，后面接吗的概率为30%，接啊为20%，接呀为10%，其余许多奇怪的词各占少量概率。模型从候选中选出一个词，再以新词为基础计算下一个。过去我以为它总会选择概率最高的词，后来才知道并非如此；否则每次都选第一名，同一个问题问十遍也只会得到完全相同的死板答案。要让输出既有变化又不胡来，需要temperature与Top K协同控制。

temperature：拉大还是缩小概率差距

先看temperature，也就是温度值，范围通常是0到1。可以把它看作概率放大器：数值越低，高概率词的优势越明显，模型越偏向稳妥、常见的答案；数值越高，候选词之间的概率差距越小，冷门词也更容易入选。仍以班级选代表为例，第一名30票、第二名20票、第三名10票。temperature=0.2时，票数差距被大幅拉开，第一名几乎必胜；temperature=0.8时，差距缩小，第二名和第三名也有较大机会当选，结果因此更随机。我最初把温度调到0.9，希望散文更有灵气，结果写到三句便跑题，原因正是冷门词出现得太频繁，模型逐渐偏离方向。

Top K：先淘汰缺乏竞争力的候选

只有temperature仍不够，还需要Top K参与。Top K的做法更直接：把所有候选词按概率从高到低排列，仅保留前K个，其余直接淘汰；之后无论怎样调整temperature，都只能从这K个词中选择。继续沿用选代表的例子，K=4就意味着只允许前四名参与投票，第五名以后即使温度再高也没有机会。我曾误以为K越大越随机，事实恰好相反：K越大，候选池和冷门词越多，搭配高温度时更容易失控；K越小，池中多是高概率的可靠词，即使温度较高也不易越界。

两个参数配合使用，才是正确方式

说实话我一开始分开调，要么只动 temperature，要么只改 Top K，效果始终差强人意。后来自己试了十几组参数，才摸出点门道 —— 这俩得搭配着来。 当时我把两组参数反过来试了下，效果惨不忍睹，才明白这俩参数不是越大越好，也不是越小越好，得凑对。 亲测好用的搭配就两种： 一种是低温度 + 大 Top K。比如 temperature=0.2，Top K=8。温度低保证了整体风格严谨，不容易胡说；Top K 大一点，又能保证信息量，不会输出干巴巴的套话。这种就适合写代码、写合同、做信息整理这类要准的场景。 另一种是高温度 + 小 Top K。比如 temperature=0.8，Top K=4。温度高能保证创意和灵气，小 Top K 又把边界卡死了，再怎么发挥也都是高概率的靠谱词，不容易跑题。刚好对应我这个散文生成的需求，创意不跑偏。 反过来就很坑：温度高 + Top K 也大，基本等于放飞自我，幻觉满天飞；温度低 + Top K 也小，输出就跟机器人报菜名似的，毫无可读性。

理解参数还不够，业务写作还需要流水线

参数摸明白之后，我写了第一版代码，全是硬编码：prompt 直接写死在字符串里，请求参数拼半天，返回结果还要自己一层层剥对象取 content。 写的时候挺快，改的时候哭了。今天想加个主题变量，明天想换个模型，后天又想加个输出格式校验，每改一次都要在大段字符串里找位置，特别容易改错。 后来想起 LangChain，之前总觉得这玩意儿是玄学，不就是封装了一层接口吗？真用了才知道，香是真的香。

我为什么开始使用 LangChain

其实 LangChain 说穿了，就是个 AI 工作流的编排工具。lang 是语言，chain 是链条，把大模型工作流上的每个节点串起来。 以前我们写 AI 逻辑，是从 prompt 拼接、到调用模型、到解析结果，全写在一个函数里，耦合得一塌糊涂。LangChain 的思路是，把每个环节拆成独立的模块：提示词是一个模块，大模型是一个模块，输出解析是一个模块，然后用 pipe 方法把它们串成一条流水线。 这样做好处太明显了：想换提示词模板，不动模型代码；想换模型，不动解析逻辑；以后想加个工具调用，直接在链条中间插一节就行。

PromptTemplate：把提示词从代码里抽出来

第一个好用的模块就是 PromptTemplate。 以前写 prompt，都是模板字符串里嵌变量，变量多了看着特别乱，而且业务方改 prompt 还要找开发改代码。用 PromptTemplate 就相当于把提示词做成了模板，只留变量占位符，传什么参数进去就生成什么提示词。 我这个散文生成的例子里，主题就是变量，模板里写好风格、字数要求，每次调用传不同的 theme 就行，模板和业务逻辑完全分开，维护起来舒服太多。 说句实在的，做 AI 应用到最后，大部分迭代都是在改 prompt，把模板抽出来单独维护，绝对是越早做越赚的事。

输出解析器：无需再手动拆解返回值

另一个省心工具是输出解析器，例如我使用的StringOutputParser。过去调用大模型接口时，返回的是嵌套很深的对象，必须额外编写处理逻辑res.choices[0].message.content才能取得纯文本；接口结构一变或更换模型厂商，代码还要随之调整。使用StringOutputParser后，这些细节无需再管，它会自动提取模型输出中的纯文本，链条执行完便直接得到字符串，减少大量重复代码。以后若要解析JSON，只需替换解析器，其他部分不必改动。

使用pipe，把整条工作流连接起来

最爽的还是 pipe 方法，把模块按顺序一连，一条工作流就成了。 就像工厂流水线：原料（主题变量）先进提示词模板车间，加工成完整的 prompt；然后送进大模型车间，生成回复内容；最后进解析车间，打包成纯文本出厂。 代码里就三行：prompt.pipe(model).pipe(parser)，清晰得不行，谁看了都知道这条链路是干嘛的。

我已跑通的最小 Demo，可以直接使用

前面讲了不少原理，下面进入实践。这份整理后的最小可运行代码对接DeepSeek，并分别设置创意与严谨两条链路，修改配置即可使用。

import dotenv from 'dotenv';dotenv.config();import { ChatOpenAI } from '@langchain/openai'// 把大模型输出解析成纯文本，不用自己剥对象import { StringOutputParser }from '@langchain/core/output_parsers';// 提示词模板，业务改文案不用动逻辑import { PromptTemplate } from '@langchain/core/prompts';// 创意向模型：温度高+TopK小，有灵气不跑偏const creativeModel = new ChatOpenAI({model: 'deepseek-v4-flash',temperature: 0.8, // 增强创意发散topK: 4, // 仅在前4个高概率词里采样，管住跑偏maxToken: 600,apiKey: process.env.DEEPSEEK_API_KEY,configuration: {baseURL: 'https://api.deepseek.com/v1', // 注意这里要带/v1，我漏写卡了十分钟}})// 严谨向模型：温度低+TopK大，准确又有信息量const preciseModel = new ChatOpenAI({model: 'deepseek-v4-pro',temperature: 0.2, // 保守输出，尽量稳妥topK: 8, // 更大的候选池，保证信息完整度maxToken: 600,apiKey: process.env.DEEPSEEK_API_KEY,configuration: {baseURL: 'https://api.deepseek.com/v1',}})// 提示词模板：只改模板不动逻辑const storyPrompt = PromptTemplate.fromTemplate(`请写一篇短篇散文，主题：{theme}风格温柔治愈，篇幅200字左右，不要分段，文字细腻有画面感。`)// 输出解析器：统一返回纯文本const outputParser = new StringOutputParser();// 创意写作流水线const creativeChain = storyPrompt.pipe(creativeModel).pipe(outputParser)// 严谨写实流水线const preciseChain = storyPrompt.pipe(preciseModel).pipe(outputParser)async function runWriteDemo() {const theme = "秋日山野晚风";console.log('创意写作模式输出：');const creativeText = await creativeChain.invoke({theme});console.log(creativeText);console.log('n严谨写实模式输出：');const preciseText = await preciseChain.invoke({theme});console.log(preciseText);}runWriteDemo().catch(err => console.error(err))

踩坑提醒 有两个坑我替你们踩过了，别再往里跳：

1. baseURL 一定要带上 /v1 后缀，否则会出现404；我盯着配置文件半小时，才发现少了这一段。
2. LangChain 的 ChatOpenAI 类使用驼峰形式的参数名 topK、maxToken，不要写成下划线格式，否则即使传入也不会生效，很容易踩坑。

流程跑通以后，我又查看了源码

其实一开始我对 LangChain 的 pipe 方法挺好奇的，以为有什么黑魔法，特意去翻了下核心源码。 结果挺意外的，没什么复杂的东西，本质就是函数组合。pipe 方法就是把上一个节点的输出，当成下一个节点的输入，依次调用。整条 chain 调用 invoke 的时候，就按顺序把数据传下去，每个节点只管自己的事。 说白了，它就是帮你把 “调用 prompt 模板 -> 调用大模型 -> 解析输出” 这个重复流程给封装好了，同时给所有模块定了统一的输入输出规范。这样不管是官方的模块还是自己写的，只要符合规范，就能往链条里插，扩展性特别好。 以前我觉得这种框架是过度设计，真做业务了才明白，统一规范太重要了。不然每个人写的 AI 逻辑都不一样，维护起来就是灾难。

这些天遇到的坑，希望你们不要重蹈覆辙

说几个实打实的教训，都是我一行行试出来的： 第一个坑，迷信单参数。一开始我以为控制随机性就调 temperature，结果调高调低都不对，后来才知道 Top K 是管边界的，俩是一套组合拳。 第二个坑，参数搭配搞反。我试过 temperature 拉到 0.9，Top K 也开到 20，结果输出直接放飞，主题都抓不住；也试过 temperature0.1，Top K 设成 2，输出干得像说明书。记住：高温度配小 Top K，低温度配大 Top K，基本不会错。 第三个坑，所有逻辑塞一条链。一开始我把创意和严谨模式写在一个函数里，靠传参切换，后来越写越乱。拆成两个 chain 实例，复用同一个 prompt 和解析器，代码干净，扩展也方便。

最后再说几句真心话

捣鼓这几天，最大的感受是，AI 开发不是玄学，很多东西拆开来都有章法。 第一，控制大模型的输出风格，从来不是一个参数的事。temperature 管 “敢不敢冒险”，Top K 管 “有多少选项”，两者配合才能在创意和靠谱之间找到平衡点。 第二，做 AI 应用，解耦很重要。prompt、模型、解析逻辑分开，以后改哪动哪，别全堆在一个函数里，前期省事后期坑。LangChain 这类框架的核心价值，其实就是帮你把这些边界划清楚。 第三，参数不是万能的。别指望靠调 temperature 和 Top K 解决幻觉问题，它俩只能管风格，管不了事实对错。要准确率，该上 RAG 上 RAG，该加工具加工具，参数只是锦上添花。

还有Top P、频率惩罚等许多参数没有展开，但在日常开发中，只要真正掌握temperature和Top K，多数场景已经足够。其余参数可以逐步探索，亲自踩坑反而记得更牢。

你平时调整大模型参数时有什么独门技巧，又遇到过哪些离谱问题？欢迎在评论区分享，也让我增长见识。