聊天记录翻到烦，我让 DeepSeek Harness给自己写了个插件

本一和他的朋友们 2026-08-14 0 阅读7分钟

从一句牢骚，到一个开源项目，我没离开过聊天窗口。

一、翻聊天记录的第十三分钟

今天下午，我在 DeepSeek Harness（下文简称 DSH）里跟 AI 干活，已经聊了二十多轮。

对话开头它给过一个很妙的建议，我想回去再看一眼。于是我开始往上翻。

翻过一屏又一屏的工具调用卡片，翻过一段段代码块，滚动条细得像根头发。翻到第十三分钟，我承认我烦了——我明明记得那条建议就在那儿，可找到它怎么这么难。

我没去官网提工单，也没打开什么 IDE。我就地打了一行字，发给正在跟我干活的那个 AI：

「我在 chat 的过程中存在一个问题……帮我做一个聊天的目录列表，方便我在不同的聊天中来回切换。」

发完我就后悔了——这要求是不是太越界了？让它改它自己运行的这个工具？

二、它反问我三个问题

但是它的反应有点出乎我的意料。

它反问我三个问题：

1、目录想做成侧边栏面板还是浮动按钮？

2、目录项用提问摘要还是原文？

3、想临时体验还是永久保留？

我盯着这三个选项看了几秒，忽然意识到一件事：它问的不是客套话，是真的在确认需求。 它已经准备好动手了——写它自己身上的插件。

我选了"侧边面板 + 提问摘要 + 先临时体验"，然后它说：先查一下这个平台有哪些界面插槽可以注册。

它没瞎猜，先翻了翻自己家的"能力目录"。

三、按钮出现了，然后崩了

几分钟后，会话标题栏右侧多了一个按钮：☰ 目录 [3]

那个数字 3，正是我这一场对话里提问的次数。我点了下去。

面板弹开的一瞬间，页面报错了。浏览器抛出一串 React #310，面板当场崩溃。

我把报错贴回去，它自己读了自己上一版的源码，回了一句诊断：有个 useState 被放在了"面板未打开就提前 return"的后面——面板一开一关，React 看到的钩子数量对不上。

「这是 React 的铁律，不是平台的坑。」它重发了一版，让我刷新页面。

前后不到一分钟。我在旁边看着，感觉像看一个开发者自查自纠。

四、面板开了，但是空的

第二版稳了。按钮在，面板能开能关，动画丝滑。

但面板里一行目录都没有，只有一句礼貌的空状态文案：「本会话还没有用户提问。」

明明有 3 条提问，按钮上的徽标都数出来了，面板却说没有？

它又去查了一遍平台的接口文档，回来给了我一个让我愣了一下的答案：

入口按钮注册在会话作用域的插槽里，天然拿得到 useSession 这个数据钩子；而浮动面板注册在根作用域的插槽里——按设计，它根本收不到会话数据。

这不是 bug。一个全局浮动层，凭什么默认能读你所有会话的内容？想跨作用域传数据？可以，自己显式建通道。

于是第三版改了架构：按钮负责提取数据、发布到共享状态；面板只管读状态、渲染、跳转。

五、蓝色高亮亮起来的那一刻

刷新页面，点开目录——

每一行一个编号圆点加两行摘要，底部一行小字："点击任意条目可滚动定位到该提问。"

我点了第 1 条——那条我最开始想找的建议。

面板轻轻合上，聊天流自己滚了起来，停在那条消息出现在屏幕正中的位置，一圈蓝色描边亮起，停了一秒半，淡出。

第十三分钟没找到的那条建议，这次用了不到一秒。

从吐槽到这一刻，三轮迭代，我做的事是：回答三个选择题，刷新三次页面。

六、它会不会明天就消失

用着还不错，我想到了一个现实问题：动态插件只活在当前进程里，DSH 一重启，它就没了。

验证想法时这是优点，用顺手了就是遗憾。我问它：能转正吗？

转正路径是现成的。DSH 的整个 Web 界面由 ~/.dsh/profiles/web/ 下的 profile 组合而成——把插件做成一个标准 npm 包，加进 profile 依赖，再往 cordis.patch.yml 里写一行配置，重启即永久生效。

它照做了，我重启了。

按钮没出现。

配置文件语法没错，包也装上了，按钮就是不出现。诊断最后挖出来的原因很妙：这个 patch 文件里，直接写一条插件记录的语义是"按 id 修改已存在的行"——我的 id 是新的，不存在，于是整条被静默跳过。想新增一行，必须用 insert: 包裹。

骂了一句之后我想通了一半：声明式配置没法猜你是想改旧的还是加新的，所以定了明确的语义分工。能把"改配置"做出严格规则的系统，比"随便写都行"的系统可维护得多。

加上 insert:，重启。按钮回来了，这次是永久居民。

七、发到 Gitee 上

既然是永久居民了，干脆让它成为公共财产——开源到 Gitee。

这一步又贡献了两个小故事。

第一个：推送死活 404。查了半天，是我的 Gitee 用户名写错了——本地 git 署名 fudongxin，Gitee 账号是 fudingxin，差一个字母 o。技术问题有时候根本不技术。

第二个：开源最大的恐惧是"我机器上能跑，别人装不上"。它模拟了一个陌生用户，做了四层验证：匿名拉仓库、干净目录装包、把我的真实环境切到远端地址、清理所有本地残留——每层都有明确结果。
过程中还真揪出一个与我无关的坑：pnpm 7 配 Node 18 以上装 git 依赖必崩。顺手写进了 README 的排障小节。

现在，任何 DSH 用户两步装上：

cd ~/.dsh/profiles/web

pnpm add https://gitee.com/fudingxin/dsh-client-chat-outline.git

# cordis.patch.yml 追加（insert: 不可省，别问我怎么知道的）

- insert:

- id: client-chat-outline

name: 'dsh-client-chat-outline'

重启 DSH，目录按钮就来了。

八、这件事说明什么

会写代码的 Agent 很多，支持插件的工具也很多。但把两者接通、让闭环真的跑起来的，我是头一次见：

我用自然语言提了个需求；AI 在它自己运行的这个平台上查接口、写代码、踩坑、自修复、发版；最后产出一个别人也能装的 npm 包。全程没有 IDE，没有 fork，没有一行由我手写的代码。

那个"翻十三分钟找不到一条建议"的痛点，最后变成的不是一条 issue，不是一份等待排期的 Feature Request，而是一个已经跑了几天、任何人两步就能装上的开源插件。

插件本身很小，三百行不到的浏览器代码。但当 Agent 运行的平台对 Agent 本身可编程，用户和工具的关系就变了——

你不再只是提需求的人，你可以是改变工具的人。

你的聊天记录里，是不是也有一条翻很久才能找到的建议？

---

*插件：gitee.com/fudingxin/dsh-client-chat-outline（MIT 协议，欢迎 PR）

掘金上一篇文章看不完所有思考，微信公众号「本一和他的朋友们」是主阵地 —— 每周稳定更新，更深度的连载、配套模板、完整复盘数据都发在那。 公众号三条内容主线（关注前先看看是不是对你胃口）：

• 🤖 AI 重构工作流
• 👔 技术管理
• 🧠 程序员认知

📲 微信里搜索公众号「本一和他的朋友们」即可关注。 下一篇见 👋