第10页

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

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

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

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

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

# 用WorkBuddy把MCP工具串成内容流水线：一次编排实践 单个 MCP 工具能解决一个动作，比如「写一篇文章」。但内容工作真正费时的，是这些动作之间的衔接：查栏目、定标签、写正文、提交、核对结果。我试了一次把几个环节串成一条流水线，用 WorkBuddy 负责编排与执行。本文记录设计思路与

# 用豆包做长文结构化拆解：从一篇长材料到可复用的提纲 长材料最难的不是读完，而是读完之后「说不清它到底讲了什么、哪些能用」。豆包在把长文拆成结构这件事上挺顺手，但如果只说「帮我总结一下」，得到的往往是一段泛泛的概述。本文分享我常用的三步拆解法。 ## 第一步：只要骨架，不要总结 先明确要求输

# 转赞推荐：读《DeepSeek Harness 官方文档（中文版）》的三个收获 在 [万象云档](https://www.wanxiangyundang.top/) 的分类里翻到《[DeepSeek Harness 官方文档（中文版）](https://www.wanxiangyundang.

# 项目记录：给一个静态文档站加检索式问答的尝试 站里有一批静态技术文档，内容没问题，但读者常反馈「知道有，找不到」。这次我试着在不动原有页面的前提下，加一层轻量检索式问答：先从文档里找相关片段，再组织成回答。本文记录范围、取舍与复盘。 ## 一、把目标定得很小 没有做全站智能助手，只解决一个

# 上下文工程与提示词工程：差别不在措辞，而在“给什么信息” 近一年讨论 AI 应用时，「上下文工程」被提得越来越多。有人以为它只是提示词工程换了个说法，其实两者的关注点很不一样：**提示词工程关心怎么说，上下文工程关心让模型看到什么**。本文用应用视角把这个区别讲清楚。 ## 一、一个直观对比

把重心从排名转到被引用之后，哪些动作有用、哪些白做。这篇是一次小项目的完整复盘，包括三件白做的事。

结构化数据不是为了应付要求。这篇讲清它真正有用在哪里，内容站最值得加的三种类型，以及一个最小可用的写法。

GEO 的产物不是文章，是可被直接拿去回答的问答对。这篇给三层拆法与一条合格问答对的四段结构，含批量生成的正确姿势。

可引用度不是感觉，是可检查的。这篇给七个检查点，含一句残酷但有效的自检提示词。

SEO 争列表位置，GEO 争答案里的那句话。这篇用五个差别讲清楚 GEO 与传统 SEO 的分水岭，并给出可执行的四条内容标准。