转赞推荐：读《DeepSeek Harness 插件开发从入门到精通》，理解模型能力的“外部延伸”

在 万象云档 里翻到《DeepSeek Harness 插件开发从入门到精通》，本来是抱着“查一下怎么写插件”的心态点开的，读完反而把一个更基础的问题想明白了：模型本身不会的东西，到底是怎么被补上的？

这篇文章推荐给所有用过大模型、却总觉得“它挺聪明但干不了实事”的人。

一个容易被忽略的分界

模型擅长的是理解意图、组织语言、做有限推理；它不擅长的是拿到实时数据、执行确定性的操作、访问你本地的文件。这两类能力之间有一道很清楚的线。插件、工具调用、外部接口，本质上都是在这道线上搭桥——不是让模型变得更聪明，而是让它能把手伸到外面去。

文章里给我启发最大的，是它把这件事讲成了“能力边界的划分”，而不是“功能清单”。按这个视角看，很多纠结就迎刃而解了：

• 模型算不准的地方，不要靠提示词硬抠，交给一个确定的函数；
• 模型不知道的地方，不要让它猜，给它一个能查的接口；
• 模型容易发挥过头的地方，用结构化参数把输入收窄。

为什么这对普通用户也有用

你未必会写插件，但这个视角能直接改善日常用法。举个我自己改掉的习惯：以前让模型“帮我看看这份资料里有哪些过时的说法”，它给的答案总是很笼统。后来我改成两步——先让它列出需要核对的字段清单，再用工具或人工把字段的真实值查回来，最后让它只做比对。准确率立刻不一样了。

差别不在模型，在我不再要求它做本来就不属于它的那部分工作。

文章里另外两个值得记下的点

一是接口描述要写给“读者”看。 工具的名称、参数说明、返回值含义，其实都是给模型读的文档。写得含糊，模型就会用错；写得像一份合格的技术文档，调用成功率自然上来。这点跟写给人看的文档是相通的，可以配合 前端 Wiki 里关于注释与分层的章节 一起体会。

二是失败要能被看见。 工具调用失败时返回什么、模型怎么知道失败、要不要重试，这些边界比“正常路径怎么走”更影响实际体验。我自己做小工具时也踩过：静默失败最耽误时间。

一点延伸

顺着这篇往下读，很容易接到同站的《DeepSeek Harness 必装的 MCP 推荐》和官方文档，那一组材料讲的是“桥”有哪些现成搭法。建议顺序是先看这篇建立边界感，再去看工具清单，否则容易变成装了一堆插件却说不清各自补的是哪块能力。

小结

这篇文档的价值不在教你怎么写完一个插件，而在于帮你建立一张地图：哪些事交给模型、哪些事交给确定性的代码、中间用什么连接。想清楚这个，大模型很多“不好用”的瞬间，其实都能定位到具体该补的那一环。