真正翻过文档后我才明白，大模型说话时的“脑洞大小”原来由多个参数共同控制。此前一直使用默认值，难怪输出不是太保守，就是直接放飞。

大模型“造句”的本质，其实是概率抽奖

这件事听起来可能有些反直觉：大模型写内容时，其实并不理解自己正在写什么。每生成一个词，它都会以之前的词为基础，计算全部候选词的概率，再按照规则选出一个。比如说完“你好”后，接“吗”的概率为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，就足以应对大多数场景。其余内容可以逐步探索，亲自踩过坑反而更容易记牢。

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