大模型

# 用 WorkBuddy 整理「失败样本」：按原因分堆而不是按时间 模型用久了会攒一堆失败样本：答非所问、格式崩了、中途截断。多数人把它们按时间堆在一个文档里，复盘时从头翻，翻完也没结论。这次用 WorkBuddy 做了一次重新整理：按原因分堆，而不是按时间。 ## 先定分堆维度 不让它自由

# 用豆包做「反例收集」：让它专挑不合规的输出 调一个输出格式时，人习惯看「正确的样例长啥样」，然后指望模型照着来。问题是边界总在反面：哪些不算合规，往往比正面样例更说明问题。用豆包做一件专找茬的事——反例收集，比堆正面样例更有效。 ## 提要求的写法 ˃ 下面是我定的输出规范。请只生成「违反

# 转赞推荐：从《DeepSeek Harness 插件开发》的示例分层学写提示词 想推荐一个写提示词的姿势，来自 [万象云档](https://www.wanxiangyundang.top/) 收录的《DeepSeek Harness 插件开发从入门到精通》里那种示例分层：最小可跑示例先行，再

# 项目记录：给长文档问答加「引用位置」之后 ## 起因 用模型读长文档、做问答，答案本身能答上来，但有个致命问题：答完不知道依据在原文档的哪一段。要核对时只能从头翻，等于没省事。于是做了一处改动：让回答带「引用位置」。 ## 加的字段 | 字段 | 写什么 | | --- | --- |

# 输出太长时先改「结构要求」，别急着加「请简洁」 觉得模型回答啰嗦，很多人的第一反应是补一句「请简洁一点」。多数情况这没用，因为「简洁」是形容词，没法判定是否做到。结论先给：先检查你的结构要求，而不是加一句情绪词。 ## 两种改法的差别 | 做法 | 是否稳定 | 为什么 | | --- |

推理服务占显存、启动慢、易被打穿，普通部署文档不提。这篇转赞工程文档里的习惯，给三个必调参数与一个健康检查方法。

榜单不测你的任务。这篇讲一个 30 道题的自建评测集怎么建、怎么评分、怎么长期维护。

微调、RAG、提示词不是替代关系，是三种成本结构。这篇给一张判断表和一个永远成立的先后顺序。

算 AI 费用最容易漏的三块：输入、输出、缓存。这篇给出公式与四个降本手段，按性价比排序。

温度与 top_p 不只是“高低”问题，关键是任务配多少。这篇给四个任务的推荐值与一套调试顺序。

# 用豆包做「术语对齐」：把三种叫法收进一张表 同一份需求里，「用户」「账号」「成员」混着用，看起来只是措辞问题，实际会让后续整理和检索都变麻烦。用豆包做一次术语对齐，成本很低：把散落的叫法收进一张表，再逐条定标准。 ## 提要求的写法 ˃ 下面是一段需求文本。请找出指代同一对象的不同叫法，按

# 同一提示词两次结果不同，先别急着改温度 遇到输出忽好忽坏，很多人的第一反应是把温度调低。多数情况下这不是最优解，甚至会掩盖真正的原因。结论先给：先查输入是否含糊、上下文是否漂移、验收标准是否可判定，最后才动参数。 ## 按顺序排查三处 **一、输入里有没有未定义的词。** 「写得专业一点」

# “记得住”和“找得到”：长上下文与检索的边界辨析 窗口越做越大之后，一个常见判断是：既然能一次塞进去，还需要检索吗？跑过几轮真实任务会发现，这两个词说的其实不是一回事，混在一起谈，很容易把方案选错。 ## 两者解决的是不同问题 **长上下文**解决的是“同一份材料里，前后能不能互相照应”。

# 用WorkBuddy整理模型调用日志：把失败原因归成五类 ## 起因 调用日志攒了几千行，出问题只能靠翻。想做点统计，一开始就卡在“失败原因”五花八门：超时、格式不对、没带引用、答非所问、限流……写啥的都有，根本没法归类。 后来先做了一件事：**把原因收敛成五类**，再让工具批量打标。

# 用豆包做“反例改写”：把一段含糊要求改得可判定 “写得简洁一点”“分析得深入些”“别太机械”——这类要求人能懂，程序没法执行，模型也只能靠猜。我用一个固定动作处理：让豆包做**反例改写**，把含糊要求翻成一组能通过/不通过的判据。 ## 提示词 ˃ 下面是一段写作/输出要求：「」。 ˃ 请