深入解析LLM温度参数:从Softmax原理到工程实践
1. 项目概述为什么Temperature是LLM的“创作灵魂”如果你用过ChatGPT或者任何大语言模型的API一定见过一个叫temperature的参数。它通常被描述为“控制生成文本的随机性”默认值可能是0.7或1.0。但你是否真的理解当你把滑块从0调到1模型内部到底发生了什么翻天覆地的变化为什么调低它回答就变得千篇一律、像个“老实人”为什么调高它模型就开始“放飞自我”甚至胡言乱语今天我们不谈那些高深莫测的数学公式就从最底层的“选择题”逻辑出发把LLM生成下一个词的过程掰开揉碎了讲清楚。我会带你走一遍模型“思考”的完整路径从模型输出一堆原始分数logits到如何把这些分数转换成概率softmax最后如何根据temperature这个“调控旋钮”决定最终选哪个词。你会发现temperature远不止是一个简单的“随机性”参数它本质上是在控制模型“创造力”与“确定性”之间的平衡是决定生成文本“灵魂”的关键。无论你是刚入门的新手想彻底搞懂API调用还是有一定经验的开发者希望精细控制模型输出以满足产品需求理解temperature背后的原理都至关重要。它能让你从“凭感觉调参”进化到“知其所以然地调参”避免很多莫名其妙的生成结果。2. 核心原理拆解从logits到token的“选择题”全流程要理解temperature我们必须先回到大语言模型生成文本的基本单位Token。你可以把Token理解为模型词汇表里的一个“词”或“词片段”。模型生成文本就是一次又一次地从庞大的词汇表中选出下一个最合适的Token。这个过程本质上是一个超大规模的“选择题”。而temperature就是这道选择题的“评分标准”和“抽奖规则”的调节器。2.1 第一步模型输出的原始分数——Logits当模型接收到你的输入Prompt后经过内部复杂的神经网络计算最终会为词汇表中的每一个可能的Token通常是几万到几十万个计算出一个原始分数这个分数就是Logits。你可以把Logits想象成一次考试后老师给每个选项打的“原始卷面分”。这个分数有正有负绝对值可能很大。它代表了模型基于当前上下文认为每个Token作为下一个词出现的“可能性”或“匹配度”。分数越高模型就越“偏爱”这个Token。但这里有个问题这些原始分数Logits并不是概率。它们的大小没有直接的可比性总和也不为1。我们无法直接根据分数高低来决定选谁因为不同模型、不同层的输出尺度可能完全不同。所以我们需要一个“标准化”的步骤。2.2 第二步将分数转化为概率——Softmax函数为了把Logits变成我们可以理解的“概率”并且让所有候选Token的概率之和为1我们需要请出机器学习里的“老熟人”Softmax函数。Softmax的公式看起来有点吓人但它的作用非常直观它把一组任意大小的数字压缩成一组总和为1、范围在0到1之间的概率值并且保持原始的大小顺序。具体来说对于词汇表中的第i个Token其概率P(i)的计算方式是P(i) exp(Logits_i) / Σ(exp(Logits_j))对所有j求和这个公式做了两件事指数化 (exp)先对每个Logits取指数函数exp(x)。这是一个非常“激进”的操作它会放大高分和低分之间的差距。比如Logits为2和1的两个Token经过exp后会变成约7.4和2.7差距从1拉大到了约4.7。归一化 (/ Σ)将所有指数化后的值加起来得到总和然后用每个Token的指数值除以这个总和。这样就保证了所有概率加起来等于1。经过Softmax之后我们就得到了一组漂亮的概率分布。概率最高的那个Token就是模型“最想选”的下一个词。如果到这里就结束那么模型永远只会选择概率最高的那个Token生成的结果将是完全确定、毫无新意的。注意Softmax函数是理解整个采样过程的核心。它的“放大效应”意味着即使两个Token的原始Logits分数相差不大经过Softmax转换后高分的Token可能会占据绝大部分概率导致模型几乎总是选择它。这也是为什么需要temperature来干预这个过程。2.3 第三步引入调控因子——Temperature的魔法现在主角temperature正式登场。它并不是在Softmax之后才起作用而是在Softmax计算之前介入到Logits中。引入temperature记为T后Softmax公式变成了P(i) exp(Logits_i / T) / Σ(exp(Logits_j / T))这个小小的/ T操作带来了巨大的影响当 T 1 时公式退化为标准的Softmax不产生任何影响。这就是API的常见默认值代表一种“标准”的随机性。当 T → 0 时例如 T0.1Logits_i / T会变得非常大因为除以一个很小的数。经过exp函数的放大最高分和次高分的差距会被急剧拉大。最终概率几乎全部集中到原始Logits最高的那个Token上其他Token的概率趋近于0。结果模型变得极其“确定”几乎总是选择它认为最好的那个词。生成文本非常保守、连贯但也容易重复和缺乏新意。当 T 1 时例如 T1.5Logits_i / T会变小因为除以一个大于1的数。这相当于把原始的Logits分数“压缩”了高分和低分之间的差距被缩小了。经过exp放大后差距依然被缩小了。原本概率很低的Token现在获得了相对更高的概率。结果概率分布变得更加“平坦”。模型的选择不再集中于头部几个Token而是给了更多“非主流”选项机会。生成文本变得多样、有创意但也可能不连贯或偏离主题。一个生活化的类比想象一下你要从一群候选人中选一个获奖者。Logits是评委给每个人的原始打分。Softmax是把这些打分转换成获奖概率的规则高分者概率高。Temperature0.1就像是强调“必须严格按分数来分高者几乎必赢”结果是评选毫无悬念。Temperature1.5就像是说“别只看最高分也给其他有特色的人一些机会”结果可能爆冷但也可能选出让人惊喜的黑马。2.4 第四步基于概率的抽样——选出最终Token得到了经过temperature调整后的概率分布最后一步就是“开奖”。通常有两种方式贪婪采样 (Greedy Sampling)直接选择概率最高的那个Token。这相当于temperature0的极限情况。它高效、确定但文本容易陷入循环比如不断重复“好的好的好的”。随机采样 (Random Sampling / Categorical Sampling)根据计算出的概率分布随机抽取一个Token。概率高的被抽中的几率大但概率低的也有机会。这是最常用的方式也是temperature发挥作用的舞台。此外在API中你常看到的top_p核采样参数是另一种控制多样性的方法它和temperature经常配合使用。top_p会动态截断概率分布只从累积概率达到p的最高概率Token集合中采样。这可以防止选中那些概率极低、可能出错的Token。3. Temperature的实战影响与参数设置心得理解了原理我们来看看在实际应用中调整temperature到底会带来什么肉眼可见的变化以及如何根据你的场景来设置它。3.1 不同Temperature值的典型输出对比假设我们给模型一个开头“夏天的午后我坐在窗前看到...”Temperature 0.1输出可能非常稳定例如“...一只猫在阳光下睡觉。” 每次生成都差不多。适合代码生成、事实问答、翻译、需要严格一致性的任务。Temperature 0.7 (常见默认值)输出富有变化例如“...一只橘猫慵懒地打着哈欠。” 或者 “...梧桐树的影子被拉得很长。”适合创意写作、对话生成、头脑风暴、大多数聊天场景。在创造性和连贯性之间取得了较好的平衡。Temperature 1.2 或更高输出可能天马行空例如“...云朵变成了棉花糖一只会说话的麻雀向我问好。” 甚至可能跑题。适合需要极高创意的诗歌生成、故事构思、获取非常规想法。风险是可能产生无意义或不符合逻辑的内容。3.2 核心应用场景与参数配置指南根据我的经验temperature的设置绝非一成不变必须紧密结合你的使用场景场景一事实性问答与信息提取目标获取准确、唯一的答案。建议值0.1 - 0.3理由低温度迫使模型聚焦于它认为最确定的事实减少“可能”、“也许”这类模糊表述和事实错误。例如问“法国的首都是哪里”你只想要“巴黎”这个确定答案。实操心得对于知识库问答我通常从0.2开始测试。如果发现模型过于死板漏掉了某些合理的同义表述可以微调到0.3。场景二代码生成与逻辑任务目标生成正确、可运行、符合规范的代码。建议值0.1 - 0.5理由代码语法和逻辑是高度结构化的。低温度有助于生成最主流、最正确的代码模式避免引入奇怪的语法或无效的API调用。对于复杂的算法题稍高的温度如0.4可能有助于探索不同的实现思路。实操心得这是最容易因温度设置不当而踩坑的地方。温度过高生成的代码可能编译都通不过。我的黄金法则是首次生成用0.2确保正确性如果代码风格单一再尝试0.4进行优化重构。场景三创意写作与内容生成目标产生新颖、多样、有趣的内容。建议值0.7 - 1.0理由这是默认值区间能很好地平衡惊喜和可控性。模型会在合理的范围内发挥创意生成不同的比喻、情节走向和表达方式。实操心得不要盲目追求高温度。对于长文本生成如写小说章节我通常将温度设置在0.8并配合top_p0.9使用。这样既能保证段落间的连贯性又能在句子层面有足够的多样性。场景四开放式对话与聊天目标使对话自然、生动、拟人化避免机械感。建议值0.7 - 0.9理由人类对话本身就有一定的随机性和跳跃性。这个温度区间能让模型的回复不那么 predictable可预测更像真人交流偶尔会有出彩的幽默或洞察。实操心得对于社交陪伴类AI我倾向于使用0.85。同时务必设置max_tokens最大生成长度上限防止模型在“兴奋”时滔滔不绝。场景五头脑风暴与创意构思目标获取大量、差异化的点子不求立即可用。建议值1.0 - 1.2理由鼓励模型跳出常规思维框架提出一些看似“离谱”但可能有启发性的想法。可以从这些想法中筛选和提炼。实操心得这是一个“广撒网”的策略。通常我会用高温度生成10-20个点子然后人工筛选再让模型用低温度对筛选后的点子进行深化和细化。重要警告温度高于1.2时生成内容质量会急剧下降 nonsense无意义内容大量出现慎用。3.3 与Top-p核采样的协同使用temperature和top_p是控制生成多样性的“黄金搭档”但它们的作用层面不同temperature全局调节概率分布的形状。影响所有Token的选择概率。top_p局部限制候选池的范围。只从概率累积到p的头部Token中采样直接砍掉长尾的低概率Token。我的常用组合策略追求高质量、可控temperature0.8 top_p0.95。这是很多生产环境的默认组合在保持创意的同时杜绝了极低概率的垃圾Token。追求高度确定性temperature0.2 top_p1.0或0.99。专注于头部最佳选择几乎不用top_p做限制。追求极端多样性实验性temperature1.0 top_p0.9。让模型在相对广阔的“优质候选池”里随机挑选。一个关键提示官方通常建议不要同时大幅调整temperature和top_p只调整其中一个通常是temperature另一个保持默认值如top_p1.0。因为两者同时作用的效果可能难以预测。我的经验是先调temperature达到基本的多样性水平如果发现仍有非常离谱的Token出现再引入一个较高的top_p如0.9进行过滤。4. 实操在代码中观察Temperature的作用理论说再多不如亲手跑一段代码看得明白。我们用一个极简的模拟例子来看看temperature是如何改变概率分布的。假设在一个极简的词汇表中只有4个Token[去, 吃, 大餐, 睡觉]。模型为下一个Token预测的原始Logits为[2.0, 1.0, 0.5, -1.0]。我们来计算不同temperature下的softmax概率import numpy as np def softmax_with_temperature(logits, temperature1.0): # 应用温度系数 scaled_logits logits / temperature # 减去最大值以提高数值稳定性这是一个常用技巧不影响结果 exp_logits np.exp(scaled_logits - np.max(scaled_logits)) # 计算概率 probs exp_logits / np.sum(exp_logits) return probs logits np.array([2.0, 1.0, 0.5, -1.0]) tokens [去, 吃, 大餐, 睡觉] print(原始Logits:, logits) print(- * 40) temperatures [0.1, 0.5, 1.0, 2.0] for T in temperatures: probs softmax_with_temperature(logits, T) print(fTemperature {T}:) for token, prob in zip(tokens, probs): print(f {token}: {prob:.4f}) # 模拟一次随机抽样 chosen_idx np.random.choice(len(tokens), pprobs) print(f 模拟抽样结果: {tokens[chosen_idx]}) print(- * 40)运行结果分析每次随机抽样结果会不同但概率分布趋势稳定原始Logits: [ 2. 1. 0.5 -1. ] ---------------------------------------- Temperature 0.1: 去: 0.9999 吃: 0.0001 大餐: 0.0000 睡觉: 0.0000 模拟抽样结果: 去 (几乎100%是“去”) ---------------------------------------- Temperature 0.5: 去: 0.8164 吃: 0.1491 大餐: 0.0328 睡觉: 0.0017 模拟抽样结果: 大概率是“去”偶尔是“吃” ---------------------------------------- Temperature 1.0: 去: 0.5038 吃: 0.2487 大餐: 0.1841 睡觉: 0.0634 模拟抽样结果: “去”和“吃”都有不小机会“大餐”也有可能 ---------------------------------------- Temperature 2.0: 去: 0.3275 吃: 0.2793 大餐: 0.2361 睡觉: 0.1571 模拟抽样结果: 四个选项概率相差不大选择非常随机这个模拟清晰地展示了temperature的威力T0.1时“去”的概率接近1模型几乎变成确定性输出。T1.0时概率分布相对平滑头部选项“去”仍有优势但其他选项也有机会。T2.0时分布非常平坦甚至原本分数最低的“睡觉”也有了15%的概率生成结果会非常随机。在实际调用OpenAI或类似API时你只需要在参数中设置即可# 以OpenAI API为例 response openai.chat.completions.create( modelgpt-3.5-turbo, messages[{role: user, content: 写一首关于春天的诗}], temperature0.8, # 在这里设置温度 max_tokens100, top_p0.9, # 可以配合使用top_p )5. 常见问题与深度排查指南在实际使用中关于temperature的困惑和问题非常多。我整理了几个最典型的问题和我的排查思路。5.1 为什么我的模型总是重复输出症状生成的文本陷入循环比如“好的那么好的那么好的那么...”或者不断重复同一个观点。根本原因这通常是低温度T 0.3和贪婪采样或beam search共同作用的结果。模型每次都会选择概率最高的那个Token而特定的上下文可能导致某个Token如“好的”始终概率最高形成死循环。解决方案提高temperature这是最直接有效的方法尝试提高到0.7-0.9。引入随机性确保你使用的是随机采样do_sampleTrue在某些库中而不是贪婪采样。使用repetition_penalty参数许多库如Hugging Facetransformers提供该参数它可以降低已出现Token的概率有效打破重复。将其设置为1.1到1.2通常效果显著。检查Prompt有时是Prompt本身引导了重复。尝试修改你的提问方式。5.2 温度调高了为什么生成的内容变得荒谬或脱离主题症状当temperature 1.0时生成内容可能逻辑混乱、包含虚构事实或完全偏离Prompt。根本原因高温度赋予了低概率Token过高的选择机会。这些Token可能本身在训练数据中就是噪音、错误关联或非常规用法。解决方案降低temperature立即调回0.7-1.0的安全区间。启用top_p设置top_p0.9或0.95可以直接剔除那些概率极低的“长尾”Token保留质量较高的候选池。使用top_k采样类似top_p但它是直接限制只从概率最高的k个Token中采样。设置top_k50是个不错的起点。加强Prompt约束在Prompt中更明确地指定格式、风格和边界。例如加上“请确保回答逻辑清晰、基于事实”。5.3 Temperature和随机种子seed是什么关系关系temperature控制概率分布的形状而seed控制随机数生成器的起点。如果temperature 0且没有固定seed每次生成结果都不同。如果固定了seed即使temperature 0每次运行也会得到完全相同的随机抽样序列从而实现结果的可复现。这对于测试和调试至关重要。如果temperature 0模型使用贪婪采样选择是确定的此时seed不起作用。实操建议在开发调试阶段务必设置一个固定的seed。这样当你调整Prompt或其他参数时能清晰地看到temperature带来的变化而不是被随机性干扰。在生产环境如果需要多样性则不应固定seed。5.4 对于不同的模型Temperature的设置需要变化吗需要而且很重要。不同模型因为训练数据、架构和初始校准的差异其Logits的数值分布范围可能不同。一些开源小模型它们的Logits输出可能“信心不足”分布比较集中。此时即使设置temperature1.0可能也显得比较保守。你可能需要尝试更高的温度如1.2来获得足够的多样性。强大的商用模型如GPT-4通常经过精心校准在temperature0.7~0.9下表现最佳。盲目调高到1.2以上反而容易引发问题。我的测试方法对于一个新模型我会用一个固定的创意Prompt如“写一个关于机器人的短故事开头”以0.2为间隔从0.2到1.4测试多个温度值快速观察其输出质量和多样性变化找到该模型的“甜点区间”。5.5 在流式生成Streaming中Temperature能动态调整吗这是一个高级技巧。理论上你可以在生成每个Token时动态改变temperature但这需要底层API的支持。常见的应用模式是开头高后面低在生成开头时使用较高的温度如1.0激发创意随后逐渐降低温度如到0.7以保证后续内容的连贯性和质量。基于内容调整检测到模型开始重复或偏离主题时临时调高温度以“跳脱”当前状态当模型回到正轨时再调回正常温度。目前大多数标准API不支持在单次请求中动态修改temperature。实现这种效果通常需要更复杂的工程架构例如将生成分段进行并对每一段使用不同的参数重新调用API。这属于更精细化的生成控制策略。

相关新闻

基于人脸关键点与行为时序分析的睡岗识别系统实战指南

基于人脸关键点与行为时序分析的睡岗识别系统实战指南

1. 项目概述:从“睡岗”到智能值守的跨越“睡岗识别”这四个字,对于任何一个涉及生产安全、质量控制或服务监督的现场管理者来说,都像一根敏感的神经。它背后指向的是一个长期存在且难以根治的现场管理痛点:在需要人员持续保持警觉…

2026/9/24 14:16:03 阅读更多 →
01-05-运行时-JIT优化全景-内联去虚拟化边界检查消除

01-05-运行时-JIT优化全景-内联去虚拟化边界检查消除

JIT 优化全景:内联、去虚拟化、边界检查消除 系列:C#与常用数据结构源码剖析 运行时底层剖析 阅读时间:约 45 分钟 前置知识:JIT 编译管线、IL 基础 一、引言 前一篇文章介绍了 RyuJIT 的完整编译管线——20 个阶段从 IL 到机器…

2026/10/4 19:37:01 阅读更多 →
SaaS产品AI赋能实战:智能客服、ChatBI与辅助生成的场景化落地

SaaS产品AI赋能实战:智能客服、ChatBI与辅助生成的场景化落地

1. 项目概述:当SaaS遇上AI,一场效率与体验的静默革命如果你在SaaS行业待过几年,大概会和我有同样的感受:产品功能越来越同质化,客户对“智能”的期待却越来越高。几年前,给SaaS加个“AI”标签可能还是锦上添…

2026/10/12 12:19:21 阅读更多 →

最新新闻

Hadoop与Spark选型指南:从性能对比到落地实践

Hadoop与Spark选型指南:从性能对比到落地实践

1. 先聊两句:为什么总有人拿他俩做对比但凡接触过大数据,几乎都绕不开同一个问题:Hadoop和Spark到底选哪个?我在不少技术群里见过类似的争论,有人觉得Spark快,所以Spark一定更好;也有人觉得Hado…

2026/10/15 18:32:46 阅读更多 →
“如果没有Windows,英伟达根本不会诞生!”黄仁勋放话,全球最值钱公司因Windows才存在?

“如果没有Windows,英伟达根本不会诞生!”黄仁勋放话,全球最值钱公司因Windows才存在?

当整个科技行业都在把注意力投向云端大模型、AI 数据中心和 Agent 入口时,英伟达 CEO 黄仁勋却在微软的活动上,把英伟达的起点拨回了 1992 年:“英伟达是因为 Windows 才创立的……如果没有 Windows,英伟达根本不会诞生。”近日&a…

2026/10/15 18:32:46 阅读更多 →
仓颉 std.binary 包实战指南:大小端字节序列转换与字节序反转接口详解

仓颉 std.binary 包实战指南:大小端字节序列转换与字节序反转接口详解

人工智能AI 技能文档开发工具 【免费下载链接】DocAgent 项目地址: https://gitcode.com/Cangjie-SIG/DocAgent 点击查看 免费下载 std.binary 是仓颉标准库中专用于处理字节序(Endianness)的包,它把仓颉基础数据类型&#xff08…

2026/10/15 18:32:46 阅读更多 →
YADR dotfiles:一站式整合 Vim、Git、Zsh 插件与配置的开发者工作流

YADR dotfiles:一站式整合 Vim、Git、Zsh 插件与配置的开发者工作流

开发工具 【免费下载链接】dotfiles YADR - The best vim,git,zsh plugins and the cleanest vimrc youve ever seen 项目地址: https://gitcode.com/gh_mirrors/dotfil/dotfiles 点击查看 免费下载 导读 YADR(Yet Another Dotfile Repo)是…

2026/10/15 18:32:46 阅读更多 →
双酚类化合物潜在危害与个人减少暴露的5个方法

双酚类化合物潜在危害与个人减少暴露的5个方法

什么是双酚类化合物双酚类化合物是一类含有两个酚基团的有机化合物,核心结构是两个酚基团通过一个连接基团(常见的亚甲基基团)连接起来,其中广受关注的双酚A(Bisphenol A, BPA)化学结构是两个苯酚基团通过2…

2026/10/15 18:32:46 阅读更多 →
NLog 项目贡献指南:从 Issue 报告、多目标编译到 CI 构建的完整实战手册

NLog 项目贡献指南:从 Issue 报告、多目标编译到 CI 构建的完整实战手册

后端运维观测 【免费下载链接】NLog NLog - Flexible and Structured Logging for various .NET Platforms 项目地址: https://gitcode.com/gh_mirrors/nl/NLog 点击查看 免费下载 本文档是 NLog 开源仓库(.NET 平台灵活的结构化日志框架)中…

2026/10/15 18:31:45 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/15 16:18:54 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/15 13:48:15 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 9:49:14 阅读更多 →