上一篇 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 dsh-just-chat@0.1.4 安装后重启 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 ，才有了完整插件；用起来又发现命名、开关和窄窗口布局的问题，第二

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/17 13:50:31