DSH 插件化开发:新时代的正确 Vibe Code 姿势

DeepSeek Harness 横空出世，我是很兴奋的。试用着琳琅满目的开源插件，好像自己离“梦想”又近了一步。

此前也用 LangChain 从头 vibe code 过一个 Agent 平台，不提设计和审美，随着功能不断的增多，代码互相牵扯，隔一阵就得做一次大重构，耐心被重构、回滚一次次磨没。

我花了一整天跟大模型讨论，理想情况下我的业务平台该长什么样。

我以为我的平台分分钟就搭建起来了。

然后。。。第一个功能就跪了，漏洞百出。。。

走了不少弯路，最后还是摸索到了正确的开发姿势。文末会附上我最终版的 AGENTS.md。

先把一个功能做出来

我一度怀疑是不是框架选错了。像这种要深度定制的业务平台，要不要试试 PI、Claude SDK？甚至只能从头撸？

回头 review 代码，发现两个核心问题：

1. 开源插件看着炫酷，真要适配我的业务，改起来并不省事。
2. 大模型接到需求，看到哪改哪，一会儿改框架，一会儿改插件。

于是我先把理想方案放一放，一个功能一个功能做：

• 先让大模型在网上找参考，但实际插件还是基于需求从头写。
• 一次只做一个小功能，改动尽量收在一个插件里。

就这么一点一点做，虽然跟最开始的理想型还有差距，但按我的标准，已经有 90 多分了。

Deepseek Harness，真香！

一切都是插件

DSH 的口号是 Everything is a Plugin。随着不断开发迭代，我才体会到它的威力，它强迫我开发前先考虑清楚这个功能放在哪个插件里。

在 vibe code 时代，大模型产出代(shi)码(shan)的能力越来越强。需求再明确、文档再清楚，人也很难逐行 review。代码越堆越多，改一处牵出好几处，项目到后期很难维护。

代码看不过来，就把功夫花在拆模块上。每个插件尽量只做一件事，人只需要明确模块之间的边界，无需关注其内部实现。

最后附上我的 AGENTS.md，大家可以直接复制到自己的项目下面。

# DSH 开发约定## 讨论和范围- 先讨论功能、优先级和验收方式，确认后再动手。以用户最新决定和已确认的项目文档为准。- 用户说“先讨论”时，等明确开始开发再改代码。用户反馈问题时，先说清原因和改法。修改方法明确的小改动、小修复直接做。- 只做满足当前需求的改动。会改变使用方式或扩大范围的决定先确认。## 插件和框架- 一次只做一个小功能。开工前梳理清楚功能实现放在哪个插件、用哪些现有接口、怎么验收，改动尽量收在这个插件里。- 业务功能走 DSH 框架的扩展点。确实绕不开框架改动，先说清缺什么接口，再跟用户讨论，要不要做，能不能舍弃，有没有替代方案。- 优先用 DSH 框架原生能力。开发插件前，先参考三方插件学习其实现，如果功能与用户需求高度匹配可以直接使用合适的第三方插件，否则优先按需求自研。切勿使用现成框架大改。- 业务数据可以用样本。会话、持久化、资源归属和权限按实际运行方式实现，服务端负责检查权限。## 文档和交付- 确认过的结论更新到对应文档。插件的职责、配置和用法放在它的 README，根目录的 AGENTS.md 只放约定和索引。小改动无需按轮次记流水账。- 跑与本次修改有关的检查、测试或构建。说清验证结果和需要人工验收的部分，样本跑通只记为样本验证。- 按项目已有的方式安装、构建或热加载。服务启停和页面验收由用户负责。提交、推送和发布都等用户明确授权。