RED 实战：用 AI 把一个想法做成能用的 DSH 插件

[exoticknight]

上一篇 V2EX 帖子： https://www.v2ex.com/t/1241608

这次接着上一篇的方法介绍，直接看它怎样参与一次真实的插件开发：从一个说不清的使用问题开始，让 AI 先研究并做 demo ，看到效果后再进入 E ，最后把确认过的行为整理进 D 。这次不再只讲方法，直接看两轮开发怎样展开。

最近 DSH （ DeepSeek Harness ）挺火，很多人一边拿它做项目，一边研究怎么给它加点东西。用着哪里不顺，顺手做个插件改进一下，也正是它适合折腾的地方。

用 DSH 做项目时，最自然的动作是先选工作区，再让 AI 读代码、改文件。可临时查个资料、问个技术细节，或者只想聊两句时，也得先准备一个项目目录。话题和项目混在一起，操作还多了一步。

在这次使用的 DSH Web 0.1.5-rc.2 中，新对话要先有工作区。想解决的问题很小：加一个入口，点一下就能开始聊天，同时准备好独立的工作目录。

做出来的 dsh-just-chat 首页和侧栏各有一个入口。点击后，它会准备独立工作目录，再打开 DSH 原生对话。

先看成品

本文对应插件 0.1.4 和 DSH Web 0.1.5-rc.2。在已经能正常对话的 DSH 环境中，可以这样安装：

dsh plugin --profile web add [email protected]

安装后重启 DSH 并刷新页面。代码和用法见项目仓库，本地调试见开发指南。

开发时只守一个节奏：不确定就让 AI 研究并做 demo ；看到可用效果，再让它进 E ；用起来发现新问题，就把现象交回去继续查。下面按两轮展开。

第一轮：点开了，但还不能聊

先让入口跑起来

先把想要的体验说出来，技术细节留给 AI 去查：

给 DSH 做个快速对话插件，点一下就能聊，不用先选项目。用 RED 研究一下怎么实现，先做个 demo 看看效果。

入口点下去，页面切到了对话页，但输入框是灰的。这个 demo 把真正的问题暴露出来了：快速对话不只是打开页面，还要一起准备好可用的工作区。

于是继续把现象告诉 AI：

对话是出来了，但输入框还是不能用。你研究一下为什么，改好以后再试。

AI 查到会话已经创建，原生输入框仍然要求先选择工作区。问题从「加一个按钮」变成了「入口打开时，还要把工作区准备好」。

再补上使用时真正需要的规则：

临时聊点别的，每次用一个独立目录。没有工作区的时候也应该能直接开始。

这次 demo 的验收方式就清楚了：从没有工作区的状态点开入口，输入消息，收到回复；再次点击时，创建另一个独立工作区。R 阶段没有急着把所有细节做完，先用结果把需求边界找出来。

主要流程通了，再进 E

看过可用效果后，范围已经足够明确：

这个主要流程可以了，进 E ，把插件完整做出来。首页和侧栏都放入口，其他对话能力沿用 DSH 原生的。

E 里开始处理插件结构、错误情况、入口接入和调试方式。核心行为保持不变：通过入口进入独立目录里的原生对话。

完整做完后，实际点两次入口、发消息，再删除测试工作区重新开始。这里又遇到一个具体问题：

现在没有工作区了，点快速对话没反应。你根据这个现象查一下。

这个问题没有另起一套需求，仍然围绕「没有工作区也能开始」修正。修好后再从空状态点入口，可以输入并收到回复；再次点击，则打开新的独立工作区。

第一轮留下了什么

试用符合预期后，继续告诉 AI：

可以了。把现在的用法和确定的行为整理进文档，后面继续在这个基础上做。

第一轮留下的约定很具体：

• 快速对话从首页和侧栏进入。
• 每次入口创建独立工作目录，继续使用 DSH 原生对话。
• 删除工作区不会连同目录和会话记录一起删除。

下一轮增加设置时，AI 就有了可以依循的起点。新功能要接在现有创建流程上，不能悄悄改变这些行为。

第二轮：能聊了，开始嫌名字和入口不顺

第一轮解决的是「能不能开始对话」。用了一阵子，新的问题变得明显：工作区名字能不能一眼看出创建时间，首页和侧栏的入口也不一定都需要。

先让 AI 研究设置应该怎样接入：

快速对话现在能用了。新工作区的名字要能自定义，比如带日期和时间；首页和侧栏的按钮也能分别开关。你研究一下怎么接到 DSH 的设置里，先做个效果看看。

这次探索的重点从创建流程变成了配置，但独立目录和原生对话仍然要保持。

配置卡片做出来后，继续明确交互：

放在插件自己的配置卡片里。改的时候先显示预览，点保存以后再生效，也要能放弃修改。

再补充名称的影响范围：

新名字只影响后面创建的工作区，之前的不要改。

这样，设置就不只是「能改几个字段」：编辑时是草稿，预览跟着草稿变化，保存后才影响下一次创建，已经存在的工作区保持原样。

这个效果可以，把它做完整

打开 demo 修改模板、选择放弃、保存后新建一次，预览和保存方式符合预期，就进入 E：

这个效果可以，进 E ，按这个做完整。原来的快速对话继续保持现在的行为。

完成后实际用一遍：改成带日期的名字，保存，再点快速对话看新工作区的名称；修改一次但选择放弃，看原值是否还在；关闭侧栏入口，继续从首页开始聊天。

配置效果符合预期后，窄窗口又暴露了一个问题：

窗口缩窄以后按钮跑出去了，你看一下这个布局。

AI 根据这个现象调整布局，再缩窄窗口复查。反馈没有改变功能目标，只补上了一个实际使用场景。

第二轮留下了什么

这轮用顺后，最后说：

可以了，把入口开关和命名模板的用法补进文档，说明只影响新建工作区。

第二轮的约定加入 D：

• 首页和侧栏入口可以分别开关。
• 工作区名称支持模板，保存后只影响之后新建的工作区。
• 修改配置时可以预览、保存或放弃，已有工作区不跟着变化。

下一次再讨论清理功能或修改已有名称，AI 就能先读到这些边界，再判断新需求会不会改变现有行为。

两轮里，RED 实际帮上了什么

这两轮的指令都很普通：研究一下、做个 demo 、这里不能用、这个效果可以、进 E 、把文档整理好。差别在于，每句话都紧跟一次试用结果，下一步不会凭空出现。

	第一轮	第二轮
起点	想省掉选择项目这一步	已经能聊天，想调整入口和名字
demo 暴露的问题	对话页打开了，但输入框不能用	配置需要预览、保存和放弃，窄窗口入口会溢出
需求变清楚后	没有工作区也能开始，每次使用独立目录	草稿保存后才影响新建名称，已有工作区不变
进入 E 后完成	把快速对话做成完整插件	把设置和命名接回原有流程
D 留下的内容	入口、目录和生命周期	开关、模板和配置生效范围

R 负责把还说不清的问题变成可以试的 demo 。E 接住已经看过效果的方向，把它做完整。结果用顺之后，再把后续需要依循的行为整理进 D。

这个项目没有先写一份完整方案，再一次性实现。需求是在点击、输入、保存和缩窄窗口的过程中逐渐清楚的。RED 让这些变化各有位置，AI 也能根据新的现象继续研究，而不是把上一轮的猜测直接当成结论。

先把问题做出来，再把共识留下

dsh-just-chat 从一个很小的使用问题开始：临时聊两句，也要先选工作区。第一个 demo 没能直接输入，反而帮忙找到了真正的需求；主要流程跑通后进入 E ，才有了完整插件；用起来又发现命名、开关和窄窗口布局的问题，第二轮继续在已有结果上推进。

这就是这次实战里 RED 真正参与的地方。人通过效果说明哪里不对、什么可以接受，AI 负责研究、实现和复查；已经确认的行为进入 D ，下一轮从那里继续。

继续使用 RED

如果你想把这套做法放进自己的项目，可以在项目目录运行：

npx -y @exoticknight/red@latest skill install --scope repo

命令会把 RED Skill 安装到 .agents/skills/red。让 AI 先读取 .agents/skills/red/SKILL.md，再开始研究、推进改动，并在确认后整理文档。

• RED 项目与安装说明： https://github.com/exoticknight/red
• 中文方法介绍： https://blog.e10t.net/red/
• 本文插件仓库： https://github.com/exoticknight/dsh-just-chat