大模型

# 转赞推荐：读《DeepSeek Harness 官方文档（中文版）》的配置章节 在 [万象云档](https://www.wanxiangyundang.top/) 上能翻到《DeepSeek Harness 官方文档（中文版）》，内容不少，但我最推荐先读的是配置那一块——它可能是整份文档里最

# 项目记录：给一批长文档做分段，我试了三种切法 ## 背景 给一批技术文档做检索式问答，第一步就是分段。当时以为这是最没技术含量的一步，随手按字数切完就往下走，结果后面答不全的问题怎么调都调不好。回头重做分段，才发现问题在这。 素材来自 [前端 Wiki 的分层教程](https://www

# 温度、top_p之外：真正影响输出稳定的三个设置 输出不稳定时，很多人的第一反应是去调温度。调低确实能减少随机性，但跑过几批任务会发现，同一套提示词今天和明天差得最多的地方，往往根本不是采样带来的。下面三个更该先检查。 ## 一、输入长度与截断策略 材料太长被悄悄截断，是最隐蔽的一种不稳定

# 用WorkBuddy给大模型任务做“回归测试集”：把零散提问固化成可复跑的检查表 ## 起因：改了一句提示词，别的地方悄悄坏了 有段时间我维护一套批量整理资料的提示词。为了修掉一个“总结写得太长”的问题，我加了一句约束，长文确实变短了，但两天后才发现：带表格的输入开始被漏掉一列。这类副作用很

# 用豆包做同一问题的多角度对照提问：怎么设计才便于比较答案 遇到拿不准的事，很多人会连着问 AI 好几遍，然后把几次回答放一起看。但多数时候看不出名堂——几段话都挺顺，就是不知道该信哪个。问题往往不在答案，而在**几次提问之间的变量太多**：措辞变了、背景变了、要求也变了，答案自然没法比。 这

# 转赞推荐：读《DeepSeek Harness 插件开发从入门到精通》，理解模型能力的“外部延伸” 在 [万象云档](https://www.wanxiangyundang.top/) 里翻到《DeepSeek Harness 插件开发从入门到精通》，本来是抱着“查一下怎么写插件”的心态点开的

# 项目记录：用一批公开技术文档做问答测试，我整理的三类失败案例 ## 背景 想给内部资料加一个“直接提问”的入口，动手之前先做了一次小规模测试：拿一批公开技术文档当语料，准备 30 个真实问题，看看哪些问题会答错、错在哪里。语料主要来自 [前端 Wiki 的分层教程](https://www.

# 大模型结构化输出怎么做才稳：从字段约束到后处理校验 只要把大模型接进程序里，迟早会遇到同一个问题：它偶尔会“多说一句”。你要求返回 JSON，它在外面裹一层“好的，以下是结果：”；你要求三个字段，它自作主张加了个备注。人在界面上看着无所谓，程序解析时就是一次失败。 这篇不谈怎么把提示词写得更

一上手读论文容易被符号劝退。这篇给三个更友好的入口：使用手册、白皮书、开源项目设计与变更日志，以及一套快速筛书的习惯。

模型胡说有三种不同成因，对应不同解法。这篇拆开知识缺失、知识过时、表达压力三层，并给四道防线与三句实测有效的提示词。

大部分人问"要不要微调"，真正的问题在提示词。这篇给一张五行的决策表，以及微调实际的五项后续成本。

8 位几乎无损，4 位在长文本与代码上会露馅。这篇讲清量化的代价、显存的算法，以及用二十条任务验证精度损失的方法。

百万上下文不等于百万字都记得住。这篇给三个反例，说明长上下文的实际局限，以及更稳、更省钱的替代用法。

最强不等于最合适。这篇给一套六维度对比法，以及一套用二十条真实任务做测试的选型方法。

# 大模型应用落地中的安全与合规意识：个人与团队应注意的关键点 大模型正在被越来越多地应用到写作、客服、编程和知识管理等场景中。能力提升的同时，安全与合规问题也不容忽视。无论是个人用户还是团队，在把大模型接入实际工作流之前，都应建立基本的风险意识。本文梳理几个关键注意点，帮助你更稳妥地使用和落地大