DeepSeek Harness 创造模式：AI 写插件-知了AI

一句话做插件，DeepSeek Harness 把这件事做到了什么程度

2026 年 11 月初，DeepSeek 给它开源的智能体平台 DeepSeek Harness 上线了一个叫 Creator Mode（创造模式）的能力。官方演示里，用户只输入一行自然语言，智能体在约 5 分半钟内完成了一个浮动番茄钟插件的读取运行时、编写文件、安装插件、热重载验证全过程，刷新页面之后侧边栏就多了一个能用的入口。

这件事值得单独写一篇长文，不是因为它”炫”，而是因为它在架构层面有支撑。DeepSeek Harness（下文简称 DSH）基于 Cordis 的”一切皆插件”设计——工具是插件，技能是插件，界面组件也是插件。既然界面组件本身就是插件，那么”让智能体给自己加一个侧边栏入口”就不再是黑魔法，而是在既有扩展点上做一次正常交付。这跟很多产品里那种”给你个 iframe 挂个网页”的做法完全不同。

但我要先把话说在前面：“一句话做插件”是真的，但”一句话做一个你想象中的插件”多半是假的。官方自己也说明，公开的几个场景里有相当一部分是经过多轮对话反复打磨出来的，直接复制单条提示词，未必能得到演示视频里一模一样的效果。所以这篇文章不会只教你写一句漂亮的需求，而是要把整个协作流程拆成五步，讲清楚每一步在做什么、为什么这么做、哪里会出问题。

为什么 DeepSeek Harness 的这次更新值得认真研究，而不是看过就算了

过去我们要给一个编辑器或工作台加功能，路径是：找文档、读 API、写代码、调构建、装插件、调试。这条路径对非工程师是关死的，对工程师也是几小时起步的体力活。DeepSeek Harness 的 Creator Mode 把其中”找文档、读 API、写代码、调构建、装插件”这五件事压进了智能体侧，人只需要做两件它做不了的事：决定要什么，以及判断做出来的东西对不对。

这意味着能力边界从”你会不会写 TypeScript”转移到了”你会不会把需求说清楚、会不会验收”。这两件事看起来简单，实际上绝大多数人第一条就栽了。我在后面单独用一节讲”大多数人做错的地方”，因为这部分比任何操作步骤都值钱。

读者定位：这篇教程适合谁

如果你是产品经理、内容运营、研究者、剪辑师，平时重度使用 AI 工具，但不会写代码——这篇是写给你的，你会得到一套可以直接照抄的流程和话术。如果你是工程师，你可能更关心插件交付物的形态、运行时依赖解析和卸载清理——第四、第五节会正面回答这些。两条线我都保留，因为它们对应的是同一个流程的两个视角。

第一步：选对模式，为什么必须是 Creative 而不是 Standard

DSH 有四种模式，很多人第一次打开 Creator Mode 失败，根本原因不是提示词写得不好，而是压根没切模式。Standard 是默认模式，能力很全，但它没有运行时检视、没有插件开发指导、也没有插件安装与市场能力。你让 Standard 里的智能体”给我做个侧边栏插件”，它能给你写出文件，但装不进去，也读不到运行时里真实的 API 签名。

四种模式的能力差异到底在哪

先把四种模式摆清楚，这张表建议你保存下来，以后切换模式时对着看。

模式	核心定位	工具与技能	特殊能力	典型使用场景	是否适合做插件
Standard（默认）	通用智能体	全工具 + Skills + 子代理 + 工作流	无运行时检视、无插件安装	日常问答、文档处理、代码修改、资料检索	不适合，能写文件但装不进
PTC（程序化工具调用）	批量处理	以 TypeScript 程序通过 run_code 循环、分支、并发调用工具	工作流工具被禁用	批量重命名、批量抽取、大规模数据处理	不适合，工作流受限且无插件指导
Minimal（极简）	最小可用	仅终端 + 图片	无 Skills、无规划、无待办	快速执行单条命令、应急排查	绝对不适合
Creative（创造）	插件创作	全能力 + 运行时检视 + 插件开发指导 + 插件安装与市场	可读运行时、写插件、装插件、同会话热重载	自定义侧边栏工具、界面改造、工作台搭建	唯一适合

Creative 模式比 Standard 多出来的三样东西

多出来的是运行时检视，不是”更强的模型”

很多人以为切模式是换了个更聪明的模型，这是误解。DeepSeek Harness 的四种模式本质上是工具集与权限集的不同组合，模型还是同一个。Creative 模式下智能体多了一个关键能力：可以在写代码之前先读取运行时，看到当前 Profile 里已加载的插件、可用的服务、真实的 API 形态。

这一点决定成败。没有运行时检视，智能体只能靠训练记忆去猜 API——猜对了运气好，猜错了你就要经历”代码能提交但跑不起来、报错信息还看不懂”的痛苦循环。有了运行时检视，它写出来的代码大概率第一次就能过。

多出来的是插件开发指导

插件开发指导听起来虚，实际上是很有价值的东西：它告诉智能体这个平台里”一个插件长什么样””入口怎么注册””侧边栏位置怎么声明””热重载走什么机制”。这相当于把平台作者写给插件作者的那份说明，直接塞进了智能体的上下文。开发指导不是文档的复述，而是把规范约束成了智能体可以照着执行的结构。

多出来的是安装与市场

这是最硬的一处差异。Creator Mode 提供 Plugin Manager，六个操作分别是 list_plugins、list_bundles、set_plugin、set_bundle、install_bundle、remove_bundle。注意这几个名字：bundle。安装的不是一个散装文件，而是一个 Bundle。这一点在第五节会展开，因为它直接决定了”插件做完了”和”插件真的交付了”之间的差距。

v0.1.6-alpha.2 的一个关键变化，很多人没注意到

在 v0.1.6-alpha.2 里，Creator Mode 移除了旧的 Cordis 动态定义与执行工具，改为通过 Plugin Manager 安装持久化插件。这个问题被很多人忽略，但它实质上改变了交付物的定义。

旧的方式是”在会话里动态定义一个东西，用完就没了”——听起来方便，但你的成果挂靠在会话上，关掉就散。新的方式是生成的能力成为 Profile 中持久的 Bundle，也就是说 manifest、默认值、构建脚本审批、卸载行为都变成了交付物的一部分。你不再只是”做了一个插件”，你是在维护一个需要长期存在、可以被启用禁用、可以被干净卸载的软件单元。

这个变化是好是坏？我的判断是明确的好，但门槛被抬高了。以前你只要让它在当前会话跑起来就算成功；现在你得考虑”下次打开还在不在””卸载之后有没有残留”。第五节整节就是在处理这个门槛。而大部分人恰恰在这个环节交出一堆半成品，还以为自己做完了。

第二步：写需求，一句话里必须交代的四件事

官方演示的那句单行请求之所以有效，不是因为它短，而是因为它信息密度高。一句话里塞进了入口位置、核心能力、交互方式和边界约束四类信息。如果你只说了”做一个番茄钟”，智能体能做出来，但做出来的可能是一个全屏的、需要点按钮跳转的、和你想象完全不一样的番茄钟。

DeepSeek Harness 需求描述的构成与顺序

建议的顺序是：入口位置 → 核心能力 → 交互方式 → 边界约束。这个顺序不是随便排的，它对应智能体构建插件时的思考顺序：先确定挂在哪，再确定做什么，再确定怎么用，最后处理”哪里不能碰”。

入口位置：左侧边栏、右侧边栏，还是会话内

DeepSeek Harness 的插件入口大致有三种位置：左侧边栏（导航级入口，适合独立工具）、右侧边栏（辅助面板，适合伴随式工具）、会话内（浮动或内嵌，适合轻量交互）。官方七个案例里，著名地标 3D 画廊用的是左侧边栏入口，论文阅读器用的是右侧边栏入口，番茄钟演示用的是浮动窗口。位置不同，代码结构差别很大，所以必须说清楚。

在 DeepSeek Harness 里，如果你自己也不确定该放哪，有一个简单判断：需要独占视野、长时间使用的放左侧；需要一边看对话一边操作的放右侧；用完即走、不占地方的用浮动。

核心能力：一句话说清”它能干什么”

核心能力要具体到可验证。 “做一个统计工具”太虚，”展示总 token 消耗、会话数量、按 token 估算成本与预算”就足够具体。具体的标准是：你写完之后，能不能自己判断”做出来的东西是否满足”。

交互方式：怎么触发、怎么操作、结果怎么呈现

交互方式是最常被遗漏的一环。同样是”读论文”，交互方式不同，做出来是两个东西：是点开就渲染全文，还是选中文字弹悬浮菜单？是鼠标悬停高亮，还是需要按住快捷键？这些必须写。

官方论文阅读器案例里有一个非常值得学习的设计点：选中文字后弹出悬浮菜单，包含”高亮 / 添加笔记 / 在会话中提问”三项，并且默认提问语言与界面语言一致。这是一个典型的”交互方式 + 边界约束”组合表达——它既规定了怎么操作，又预防了”用户界面是中文、提问却是英文”这种默认行为错误。

边界约束：写清楚”哪里不能碰”

这是四要素里最容易被跳过、但收益最高的一项。Transformer 交互式 3D 演示游戏的案例里，官方对白中明确要求”面板标题与工具栏避开 macOS 原生窗口按钮，防止重叠”。这句话的价值在于，它把一个本该在验收阶段才暴露的问题，提前到了需求阶段。

常见的边界约束有哪些？我总结四类：

系统级避让：避开 macOS 原生窗口按钮、避开系统菜单栏、不要遮挡输入框
视觉保真：保留原始排版、保留原始字体、保留原始图片（论文阅读器案例的核心要求）
风格一致：官网同款着色器背景、官网同款英文字体（海报设计工作台案例的要求）
状态保持：不要改变现有会话行为、不要修改其他插件的设置

需求描述四要素模板

直接复制下面这个模板，把方括号内容替换掉。我把它写成了一段连续的句子，因为 DeepSeek Harness 的智能体对连续的自然语言段落响应更好，碎片化的分点描述有时候反而会让它误解主次。

【入口位置】在[左侧边栏 / 右侧边栏 / 会话内浮动]新增一个入口，名称叫「[插件名]」，
图标用[简单描述]。

【核心能力】这个插件要能[一句话说清楚它能干什么]，具体包括：
（1）[功能点一，要可验证]
（2）[功能点二，要可验证]
（3）[功能点三，要可验证]

【交互方式】打开后[如何呈现]、[用户如何操作]、[结果如何展示]。
关键路径是：[第一步] → [第二步] → [第三步]。

【边界约束】
- [系统级避让要求，例如：面板顶部操作区避开 macOS 原生窗口按钮]
- [视觉保真要求，例如：阅读视图保留原始排版、字体和图片]
- [风格一致要求，例如：背景配色跟随官网主题，使用官网同款英文字体]
- [状态保持要求，例如：不修改现有会话的任何行为]

【验收标准】做完后我会这样验证：[刷新页面后侧边栏是否出现入口]、
[核心功能是否真的能跑通]、[[具体数据或交互]是否符合预期]。

写 DeepSeek Harness 插件需求时注意最后那段”验收标准”。这一条不是给智能体看的，是给你自己看的。把它写下来，你在第三步之后就不会陷入”好像能用但又说不上哪里不对”的纠结。

官方七个场景的需求构成拆解

官方公开了 7 个可复现场景及其原文提示词。我把每个场景按四要素拆开，你会发现一个规律：越复杂的场景，约束条件写得越多，入口位置也越明确。

场景	入口位置	核心能力	交互方式	边界约束	复杂度
著名地标 3D 画廊	左侧边栏	3D 模型展示埃菲尔铁塔、长城、紫禁城 + 一座自选地标	画廊式浏览与切换	未特别强调，主要靠模型资源	中
Transformer 交互式 3D 演示游戏	会话内	以 3D 形式演示 Transformer 结构	交互式游戏式探索	面板标题与工具栏避开 macOS 原生窗口按钮，防止重叠	中高
Style Lab 换肤	设置或工具栏入口	切换整个应用的视觉风格，提供 5 种，含像素风	选择即切换，全局生效	5 种风格各自成立，不互相污染	中
海报设计工作台	独立工作台	可改标题正文、调背景配色	表单式编辑 + 实时预览	官网同款着色器背景、官网同款英文字体	中
视频剪辑工作台	独立工作台	支持上传多个视频、剪辑、导出	预览器在上占主体、时间轴在下；且支持在会话中用自然语言剪辑	深色界面、布局比例固定	高
论文阅读器	右侧边栏	阅读论文全文	选中文字弹悬浮菜单：高亮 / 添加笔记 / 在会话中提问	完整保留原始排版字体图片；默认提问语言与界面语言一致	高
会话统计插件	面板或侧栏	总 token 消耗、会话数量、成本估算与预算、token 时间线、各会话用量与成本、CPU 运行与占用	数据看板式展示	基于真实会话数据，不做假数据	中

这张表最有价值的信息不在最后一列，而在倒数第二列。你看两处高复杂度的案例——视频剪辑和论文阅读——它们的边界约束写得最细。”深色界面、预览器在上占主体、时间轴在下”这种描述，本质上是在替智能体做布局决策。而布局恰恰是智能体最容易做出和你预期不符决定的地方。

官方 7 个提示词的中文参考写法

下面是根据官方公开场景整理的中文提示词写法，可以直接复制到 DeepSeek Harness 的 Creative 会话里改。注意最后一段的说明。

# 场景 1：著名地标 3D 画廊
请在左侧边栏新增一个「地标画廊」入口。打开后以 3D 画廊的方式展示
四座著名地标：埃菲尔铁塔、长城、紫禁城，以及你再自行选择一座有代表性
的地标。用户可以在画廊中浏览和切换这几座地标，每个地标有独立的 3D
模型和简洁说明。请先读取运行时确认可用的渲染能力，再开始写。

# 场景 2：Transformer 交互式 3D 演示游戏
请做一个 Transformer 的交互式 3D 演示游戏。用 3D 场景呈现 Transformer
的结构，用户可以交互式地探索各个部分。注意：面板标题与工具栏必须避开
macOS 原生窗口按钮的位置，避免重叠遮挡。

# 场景 3：Style Lab 换肤
请做一个 Style Lab，可以切换整个应用的视觉风格。至少提供 5 种风格，
其中一种必须是像素风。切换后全局生效，不只是当前面板。

# 场景 4：海报设计工作台
请做一个海报设计工作台。背景使用官网同款的着色器效果，英文字体使用
官网同款字体。用户可以在工作台里修改海报的标题和正文，并调整背景配色。
要求标题和正文的编辑是所见即所得的。

# 场景 5：视频剪辑工作台
请做一个视频剪辑工作台，深色界面。布局要求：预览器在上方并占据主体
区域，时间轴在下方。支持上传多个视频、对视频片段进行剪辑、并导出成片。
另外，我需要能在会话里用自然语言剪辑，比如我说"把第二段再剪短一点"，
你要能直接作用到时间轴上。

# 场景 6：论文阅读器
请在右侧边栏新增一个「论文阅读」入口。打开后阅读论文全文，必须完整
保留原始的排版、字体和图片，不要做任何重排或简化。选中文字时弹出
悬浮菜单，提供三项操作：高亮、添加笔记、在会话中提问。其中"在会话中
提问"的默认提问语言要与界面语言保持一致。

# 场景 7：会话统计插件
请做一个会话统计插件，数据必须来自真实会话数据。需要展示：总 token
消耗、会话数量、按 token 估算的成本与预算、token 随时间变化的曲线、
每个会话的用量与成本明细、以及 CPU 运行与占用情况。

【重要说明】
以上 7 个场景是 DeepSeek Harness 官方公开的可复现场景，我按中文使用
习惯做了表述整理。官方明确指出：其中部分插件是经过多轮对话反复打磨
出来的，直接复制单条提示词，不一定能得到演示视频里一模一样的效果。
把它当作起点，而不是当作配方。

第三步：看它读运行时，这一步为什么不能打断

需求提交之后，Creative 模式下的 DeepSeek Harness 会先做一件事：读取运行时。你会看到它的操作轨迹里出现浏览 Profile、列出已安装插件、查看可用服务、确认 API 形态之类的动作。这个过程可能持续几十秒到一两分钟。

很多人的第一反应是”怎么还没开始写”，然后就补充一句”快点开始吧”。这一句话可能让整个插件报废。原因很简单：你打断的不是等待，是它正在建立的假设。

运行时检视到底在建立什么

智能体写插件，本质是在一堆不确定的 API 里做选择。它需要确认：侧边栏入口的注册方式是什么样、热重载由谁触发、插件 manifest 需要哪些字段、数据持久化走哪个接口。每确认一项，它就少一次猜测。

一旦你打断它提前进入编码阶段，它就会开始用”看起来合理”的方式写代码。在别的平台上，这种猜测有 50% 概率蒙对；在”一切皆插件”的架构里，插件之间的依赖关系更细，蒙对的概率更低。结果就是代码能生成、能落盘、但激活时静默失败，或者干脆报一个你读不懂的错。

怎么判断它是在读运行时，还是已经卡住了

正常的运行时检视会有明确的阶段性动作：列举、查看、匹配。如果它的输出在两三分钟内毫无新动作，那可能是卡住了；如果它还在持续产生新的读取动作，就继续等。判断标准是”有没有推进”，不是”过了多久”。

另一个判断信号是：它在读完之后，通常会先给你一段简短的理解——”我确认了侧边栏入口的注册方式，接下来我会……”。这段理解本身就是价值，你可以据此提前发现它理解偏了。

发现它理解偏了，这时候怎么办

这是很多人会犯的第二种错误：发现理解偏了，不去纠正，而是等它做完再说。

更有效的做法是在它读完运行时、给出理解之后、开始写代码之前，插入一次短纠正。比如它理解成”你要一个独立窗口”，你就补一句”是侧边栏入口，不是独立窗口，打开后占据右侧面板”。纠正的时机很关键——在假设阶段纠正，成本是一句话；在交付阶段纠正，成本是重写。

# 运行时检视后的短纠正话术（时机：它给出理解、尚未动手时）
我确认一下你的理解：入口要放在[左侧边栏 / 右侧边栏 / 会话内浮动]，
不是[它理解错的那个位置]。核心功能再强调一点：[最关键的一条能力]。
其他按你先前的理解继续。

同会话热重载对 DeepSeek Harness 用户意味着什么

DeepSeek Harness 的 Creator Mode 有一个很实际的设计是：插件安装之后，可以在同一个会话里热重载。也就是说，你改完需求，不需要关掉对话、重开、重新进入，插件会在同一次会话中重新加载，你刷新页面就能看到效果。

这个机制改变了迭代的节奏。以前做插件是”改一次代码、重装一次、重启一次”，反馈周期以分钟计；现在反馈周期被压缩到秒级，你可以像对话一样调插件。也正因为如此，第五步里的”迭代”才不会变成一件让人崩溃的事。

但 DeepSeek Harness 的热重载也有一个容易被忽略的副作用：热重载成功不代表卸载干净。如果插件在加载时注册了定时器、监听了事件、建立了网络连接，热重载可能会重复挂载，你会看到重复的定时器在跑、日志在翻倍。这个问题我们放到第五节细说。

第四步：验证与迭代，刷新之后才是真正的开始

插件装完之后，智能体会告诉你”已完成”。这时候千万别急着下结论。刷新页面，这是整个流程里最重要的一个动作，没有之一。

在 DeepSeek Harness 里，刷新页面之所以关键，是因为它同时验证了三件事：入口有没有真的注册进侧边栏、插件能不能在冷启动时正常加载、持久化有没有生效。很多插件在会话内看起来一切正常，刷新之后就没了——原因往往是它只在会话上下文里定义了组件，而没有真正写进 Profile 的 Bundle。

验收的三层检查

第一层：入口层——DeepSeek Harness 侧边栏里有没有它

打开侧边栏，看你要求的位置上是否出现了目标入口，图标和名称是否符合预期。如果没有，先不要怀疑功能，先怀疑挂载点。常见原因是入口注册的位置和你说的位置不一致，或者注册了但没有被 Profile 加载。

第二层：功能层——核心能力是否真的能跑

点进去，把你在”验收标准”里写的那几条逐一走一遍。番茄钟就实际计时一次；统计插件就核对它显示的总 token 消耗和你看到的历史是否大致对得上；论文阅读器就打开一篇带图带公式的论文，看排版有没有被破坏。

这一层最容易出现的情况是”看起来对，但数字不对”。比如会话统计插件，如果它拿的是估算值而没有真正读会话数据，界面依然漂亮，但数字没有意义。官方那个案例特别强调”基于真实会话数据”，就是因为这是最容易偷懒的一环。

第三层：热重载层——改动能立即可见吗

提一个小的修改要求，看它在同会话内热重载之后是否立即生效。如果每次都要重启会话才生效，说明热重载机制没接对，这个插件后续迭代会非常痛苦，值得在第一次就解决。

不满意怎么补充，而不是重开对话

这是我最想强调的一件事。重开新对话，等于把智能体对这个插件的全部上下文清零。它不知道刚才为什么这么写、不知道哪些地方你已经确认过、不知道上次改动踩了什么坑。重开之后你会发现又要重新读一遍运行时，而且新版本很可能把之前已经做对的部分改坏。

正确的做法是在同一个会话里做增量补充。补充分两种：

缺陷型补充：某个地方不对，直接指出”哪里不对 + 期望是什么”，不要附带解释和猜测
增量型补充：现有功能没问题，想加东西，说清楚”加在哪里 + 和现有部分的关系”

迭代补充话术模板

下面四组话术覆盖了迭代中最常见的四种情况。注意每一组都刻意避免了”我觉得””是不是””可能”这类模糊表述——对智能体而言，模糊表述等于把决策权交回给它。

# 话术 A：局部缺陷修正（最常用）
[位置]不对：现在是[现状]，我要的是[期望]。
其余部分保持不变，改动后热重载给我看。

# 话术 B：功能增补
在现有基础上加一个[新功能]，入口放在[位置]，
它和[现有功能]的关系是[独立 / 联动 / 替代]。
不要改动已经确认正常的部分。

# 话术 C：视觉与约束调整
[某个区域]的[视觉属性]要改：[具体要求]。
约束不变：[重申最关键的一条边界约束，例如"仍然避开 macOS 原生窗口按钮"]。

# 话术 D：性能与稳定性返工
现在[具体现象]，我怀疑是[方向，可留空让智能体自己查]。
请先检查[定时器 / 事件监听 / 网络连接]在卸载和重载时是否被清理，
修完在会话内热重载并说明你改了什么。

话术 D 值得单独说一句。很多人遇到”越用越卡””日志重复打印”这类问题，第一反应是重开对话让智能体重做。其实这类问题的根因多数在生命周期管理上，重做一遍还是一样。话术 D 把排查方向直接指过去了，效率高得多。

什么时候该重开，什么时候不该重开

我并不是说永远不该重开。有三种情况重开是合理的：

方向性推翻：你要的其实是完全不同的东西，比如从”番茄钟”改成”待办清单”，那留着旧上下文反而是负担
上下文已经污染：连续多轮修改后，智能体开始”记住”一些错误的中间结论，越改越乱
插件已经严重损坏：文件结构乱了、manifest 错了，修不如重做

但即便如此，重开之前也有个更有性价比的做法：让智能体自己写一份交接说明。”请把你当前这个插件的结构、已确认的设计决策、已知问题整理成一段说明，我要用它在新会话里继续。” 然后在新会话里把这段说明贴进去。这样你既清了上下文，又没丢记忆。

第五步：收尾，从”能用”到”交付”

DeepSeek Harness 的插件跑起来，很多人就收工了。但在 v0.1.6-alpha.2 之后的 DeepSeek Harness 里，这不是交付，这是半成品。因为 Creator Mode 已经把插件从”会话内的动态定义”改成了”Profile 中持久的 Bundle”，它现在是一个需要长期存在的软件单元。

Bundle 交付物里到底有什么

当你通过 Plugin Manager 的 install_bundle 装上一个插件，交付物至少包含四部分：

manifest：插件的身份证

manifest 是插件的元信息声明，决定了它怎么被识别、怎么被加载、依赖什么。它最容易出问题的地方是默认值——如果一个插件在 manifest 里写了默认配置，那这个默认配置就是用户第一次打开时看到的样子。你要确认这个默认值是你想要的，而不是智能体随手填的占位值。

审批：构建脚本与危险权限为什么必须过

在 DeepSeek Harness 里，Plugin Manager 的变更会跨 Session 持久化。注意这句话的意思：一次安装，所有会话都受影响。所以 DeepSeek Harness 对这类操作要求 danger-full-access，或者走显式审批。

如果某个插件涉及外部依赖或构建脚本，你会遇到审批环节。不要一气之下全部批准，也不要一律拒绝。看它在装什么：如果是一个纯前端的界面插件，它需要的依赖应该很有限；如果它要装的依赖列表长得离谱，说明智能体选了一条很重的实现路径，这时候更合理的做法是退回一步问”能不能不用这些依赖”。这个对话往往能省下后面一堆麻烦。

DeepSeek Harness 六个 Plugin Manager 操作的实际用途

理解这六个操作的语义，你在收尾和排错时会快很多。

操作	语义	典型使用时机
list_plugins	列出当前所有插件	排错第一步：确认插件是否真的在列表里
list_bundles	列出所有 Bundle	确认交付物是否已成为持久 Bundle
set_plugin	设置单个插件的状态或配置	启用、禁用某个插件
set_bundle	设置 Bundle 的状态或配置	批量调整一组插件
install_bundle	安装 Bundle	插件构建完成后的正式安装
remove_bundle	卸载 Bundle	清理试错产物、回滚

这六个操作里，最应该被养成习惯的是 list_bundles。每次插件”做完了”，先让它 list 一遍，确认这个插件确实出现在 Bundle 列表里。如果没有，说明你拿到的只是一个会话内的临时产物，刷新就没了。

卸载验证：插件开发者最容易忽略的一课

DeepSeek Harness 官方对插件开发者有一句提醒很关键：插件不能假设进程退出就是清理路径。

这句话背后的场景是这样的：你开发插件时，测试方式是”改完代码、重启进程、再看效果”。重启进程当然能把一切清干净，所以你在开发阶段永远看不到清理问题。但插件在真实使用中不是被”重启进程”清掉的，而是被 disable、被热重载、被卸载的。这时候，如果插件的定时器没停、watch 没关、网络连接没断、事件监听器没注销，它们就会在后台继续跑。

更隐蔽的是重新启用时的重复挂载。插件被禁用再启用，如果加载逻辑没有做幂等处理，你会看到同一个定时器跑了两遍、同一个事件被响应了两次、同一份数据被写了两回。表面上一切正常，实际上在慢慢制造脏数据。

收尾阶段必须验证的四项清理

在宣布插件完成之前，让 DeepSeek Harness 逐项自查。下面这份清单可以直接当话术用。

# 插件验收清单（可直接作为提示词发给 DeepSeek Harness）
插件功能已经正常。现在做交付前检查，逐项确认并回答"是/否/不适用"：

【持久化】
1. 这个插件已经作为 Bundle 存在于当前 Profile 中（不是会话内临时定义）
2. 刷新页面后，侧边栏入口仍然存在且功能正常
3. manifest 中的默认值是有意设置的，不是占位值

【清理】
4. 插件被禁用或卸载时，所有定时器都已停止
5. 所有 file watch 已关闭，没有残留监听
6. 所有网络连接已断开，没有后台心跳
7. 所有工具与事件监听器都已注销

【幂等】
8. 插件被禁用后重新启用，不会重复挂载（定时器只有一个、事件只响应一次）
9. 会话内热重载后，没有出现重复的任务或重复的日志

【权限】
10. 插件声明的权限与实际使用的一致，没有多余权限
11. 如果引入外部依赖或构建脚本，已明确告知我并得到确认

请对每一项给出你的判断依据，不要只说"已确认"。

最后那句话很重要——”不要只说已确认”。智能体在收尾阶段有一种倾向：为了让你满意，倾向于报告成功。要求它给出判断依据，能筛掉一批”其实没查但说查了”的情况。

真实边界：一句话能做多少，做不了多少

前面五步讲的是流程，这一节讲的是判断。同一套流程，用在对的地方事半功倍，用错地方就是浪费时间。

DeepSeek Harness 创造模式的成功率与复杂度关系

从 DeepSeek Harness 官方七个案例和社区反馈来看，DeepSeek Harness 创造模式的成功率大致呈现下面这个梯度（这是经验性判断，不是官方数据）：

插件类型	典型例子	单次成功率	失效主因	建议策略
计数、计时、简单状态记录	番茄钟、倒计时、简单打卡	高	基本不会失效	一句话直接做，做完验收
数据展示面板	会话统计、用量看板	较高	取了估算值而非真实数据	务必在需求里写”基于真实数据”
视觉风格类	Style Lab 换肤	较高	只改局部没做全局	强调”整个应用”而非”当前面板”
含 3D 或着色器的界面	地标画廊、海报工作台	中	资源加载、性能、布局碰撞	预留 2-3 轮迭代
含富内容渲染	论文阅读器	中偏低	排版保真、图片字体缺失	把”保真”写成硬约束，逐项核对
含媒体处理链路	视频剪辑工作台	偏低	解码、时间轴、导出、性能	拆成多阶段，先预览后导出

这张表不是要劝退你，而是帮你分配预期。做会话统计面板，你可以期待一两轮搞定；做视频剪辑工作台，你要做好多轮打磨的准备——官方自己都说部分插件是反复打磨出来的，这句话的分量要掂量清楚。

什么样的需求适合交给它

我总结了一个简单的判断法则，叫“三可”法则：

可描述：你能用一段话把界面长什么样、操作怎么走说清楚，而不是”你懂我意思吧”
可验证：做完了你能自己判断对错，不需要专业知识去鉴别
可回滚：做坏了不影响现有工作，卸载掉就回到原样

三条都满足，放心交给 DeepSeek Harness 的创造模式。满足两条，可以试，但要有心理准备。只满足一条，我建议你换个思路。

什么样的需求建议自己写

有四类需求我明确建议不要指望一句话解决：

涉及核心数据一致性的插件

比如一个要修改会话记录、改写历史消息、或者其他插件依赖其输出的插件。这类插件的错误不是”界面难看”，而是”数据被写坏了”，而数据损坏往往在你发现之前已经扩散了。

依赖大量外部服务的插件

需要特定第三方 API、需要复杂鉴权、需要处理各种异常返回的插件。智能体有耐心写异常处理，但它不了解你那家服务商的怪癖。这类插件的调试成本主要不在写代码，而在打通信道。

对性能有硬约束的插件

比如要在长会话（几百轮）里实时统计、要处理大体量视频、要做高频渲染的插件。智能体写出来的第一版通常是”能跑”，不是”跑得快”。性能优化需要反复 profile，这不是一句话能完成的。

需要长期维护、要进 DeepSeek Harness 插件市场的团队级插件

如果是给整个团队用、要进插件市场、要长期演进的插件，我建议自己写或者至少自己审一遍。因为长期维护的关键不是第一版能不能跑，而是代码结构是否可读、责任边界是否清晰、依赖是否可控。这些恰好是”AI 生成 + 多轮修改”最容易变糟的地方。

大多数人做错的地方

这一节是我认为整篇文章里最该反复读的部分。上面五步流程，几乎每个人看完都能照着做；但下面这七个坑，几乎每个人都会踩至少三个。

错误一：把”一句话”理解成”越短越好”

官方演示之所以用一句话，是因为那句话信息密度高，不是因为它字少。很多人看完演示，回头就输入”帮我做个笔记插件”五个字，然后抱怨效果差。

这里的反常识在于：对 DeepSeek Harness 这样会先读运行时的智能体来说，需求描述的长度和成功率不是线性关系，但需求描述的信息密度和成功率是强线性关系。你要追求的是”每一句都在提供决策信息”，而不是”总共几个字”。

一个简单的检验方法：把需求里任何一句删掉，如果智能体还能做出一样的东西，那这句就是废话；如果删掉之后结果会变，那这句就是必要信息。按这个标准筛一遍，你会发现很多话其实不用写，很多关键的话却漏了。

错误二：在它读运行时的时候催它

前面讲过怎么判断运行时检视是否正常，这里只补充一点最容易踩的具体现象。这是最典型的”手比脑快”错误：你看到它在读一堆东西，觉得它在磨洋工，于是补一句”直接开始写吧”。

这一句话的代价是：它提前进入编码，用猜测的 API 写出的代码在安装阶段静默失败，然后你开始和一堆看不懂的报错搏斗，最后怀疑”这功能是不是吹的”。实际上它本来可以一次做对，是你把它的信息优势掐掉了。

错误三：一不满意就重开对话

这个错误的普遍程度超乎想象。我见过有人在半小时里重开了十几次会话，每次都从零开始描述需求，每次的结果都不满意，最后得出”这玩意儿不行”的结论。

真相是：插件是一轮一轮磨出来的，不是一次一次抽出来的。把它当成抽卡，你会很痛苦；把它当成协作，你会很顺。官方演示里那个视频剪辑工作台，之所以能支持”在会话中用自然语言剪辑”，恰恰是因为在同一个会话里反复迭代，智能体已经理解了时间轴的数据结构。重开对话，它连这个结构都不记得。

错误四：只看会话内效果，不刷新页面

会话内看起来像插件的东西，可能不是插件。它可能只是一个在会话上下文里渲染的组件，关掉就散。而 v0.1.6-alpha.2 之后，DeepSeek Harness 的交付标准是”成为 Profile 中持久的 Bundle”。

所以刷新页面不是可选项，是验收的第一步。刷新之后入口还在、功能还能跑，才算过第一关。

错误五：把”能用”当成”做完”

能用和做完之间，差的是生命周期管理。定时器有没有停、监听有没有解、重载有没有重复挂载、权限有没有多要——这些在演示视频里看不出来，在你日常使用中会慢慢暴露。

尤其是以”越用越卡”形式暴露的那种。一个每秒钟跑一次却没被清理的定时器，单看没什么，装上五个插件之后，DSH 就开始发烫、掉帧。这时候你会怪平台重，实际是插件没收拾干净。

错误六：忽略”部分插件是打磨出来的”这句免责说明

这句话官方写得很克制，很多人直接滑过去了。但它是解读整场演示的钥匙。官方的七个场景是成果展示，不是复现承诺。你的期望如果是”复制提示词、得到视频同款”，那你一定会失望；你的期望如果是”复制提示词、得到一个可以继续打磨的起点”，那它非常靠谱。

这里的判断是：把官方提示词当成需求写法的范本，比当成直接可用的配方，收益高一个数量级。

错误七：从不卸载试错产物

试错过程中会留下大量半成品 Bundle。这些没被卸载的插件，每一个都在占用加载时间、注册监听、可能还在后台跑东西。久了之后，你会开始怀疑 DeepSeek Harness 变慢了。

养成一个习惯：每个试错会话结束后，问一句”这次安装了哪些 Bundle，哪些是废弃的，请 list 出来让我确认后清理。” 这一步花不了两分钟，但能让你的 Profile 一直保持干净。

把 DeepSeek Harness 创造模式放进日常工作流

最后聊一点使用节奏上的事。Creator Mode 不是一个”想起来了用一次”的玩具，它真正的价值在于改变了你和工具的边界。

从”适应工具”到”改造工具”

过去我们用任何一个 AI 产品，默认前提是”工具长什么样你就用什么样”。你可以提需求、等更新，但你改不了它。DeepSeek Harness 的创造模式第一次把”改工具”这个动作交到了非工程师手上。

DeepSeek Harness 创造模式的意义不在于你能做多少个插件，而在于你脑子里那些”要是它能……就好了”的念头，终于有了落地通道。一个每周出现三次的重复动作，以前你会忍，现在你可以花十分钟做一个插件。

值得优先交给 DeepSeek Harness 的三类插件

如果不知道从哪个开始，我建议按这个顺序：

高频低复杂度：你每天都要用、但功能特别简单的东西。番茄钟、计数、快速笔记。成功率极高，一次就能建立信心
观察类：会话统计这种。它不改变你的工作流，只让你看见原本看不见的东西，风险低，收益直观
伴随类：右侧边栏的阅读器、参考资料面板。它和你的主工作流并行，做坏了也不影响主线

相反，不要一上来就做视频剪辑、做换肤、做任何一个”要替代你现有工具”的插件。那类需求的多轮打磨成本，足以让一个新手在第 3 轮放弃。

什么时候该停止用智能体做插件

我的判断标准是：当你开始需要向它解释”为什么会这样”超过三次的时候。

正常的迭代不需要你解释原理，你只需要说现象和期望。一旦你发现自己在教它底层逻辑、在纠正它对平台的理解、在帮它排查环境问题，说明这件事已经超出了”一句话做插件”的设计边界，继续投入的性价比会掉得很快。这时候要么自己写，要么简化需求，看看能不能砍掉那部分。

一个反常识的收尾判断

最后说一个我觉得很多人不愿意接受的观点：DeepSeek Harness 创造模式的最大价值，很可能不是帮你做出插件，而是帮你认清需求的边界。

你要做一个插件，写完需求、看它读运行时、看它第一版做出来，你往往会突然想明白：”哦，我其实不需要这么多。” 这个过程本身就在帮你把模糊的念头收敛成一个清晰的产品定义。至于最后那个插件装不装进侧边栏，反而不那么重要了。

而这，恰恰是过去只有产品经理和工程师才能获得的训练。

常见问题

问：我在 Standard 模式里让它做个插件，代码写出来了但侧边栏没有入口，是哪里出了问题？

大概率是模式选错了。Standard 模式的全工具能力里不包含运行时检视、插件开发指导和插件安装能力，所以它能写文件，但没法把文件真正装进 Profile。换到 Creative 模式重新发起这个需求，并在提示词里明确说”请先读取运行时确认侧边栏入口的注册方式，再开始写”。需要提醒的是，DeepSeek Harness 的四种模式本质上是工具集与权限集的不同组合，不是换模型，所以同一需求在不同模式下的体验差异会非常明显。

问：官方演示 5 分半做出番茄钟，为什么我做了半天还没成？

先检查是不是三个原因之一：一，需求写得太模糊，智能体反复猜你的意思；二，中途打断了它的运行时检视；三，你不断重开对话。官方也明确说过，部分插件是经过多轮对话反复打磨出来的，直接复制单条提示词，不一定能得到演示视频里一模一样的效果。DeepSeek Harness 创造模式的”一句话”是一个起点，不是一份保证书。

问：插件刷新页面就没了，怎么办？

说明它没有被安装成持久 Bundle，只是一个会话内产物。在 v0.1.6-alpha.2 里，Creator Mode 已经移除了旧的动态定义与执行工具，改为通过 Plugin Manager 安装持久化插件，生成的能力应该成为 Profile 中的 Bundle。你可以让智能体执行 list_bundles，看这个插件在不在列表里。如果不在，请它用 install_bundle 正式安装，装完再刷新一次页面验证。

问：插件越用越卡，日志还会重复打印，是什么原因？

典型的生命周期管理问题。DeepSeek Harness 官方对 Plugin Manager 有一段提醒：变更会跨 Session 持久化，所以安装这类操作需要 danger-full-access 或显式审批；而对插件开发者，官方强调运行时依赖解析与卸载——插件不能假设进程退出就是清理路径，必须验证定时器、watch、网络连接在卸载时停止，工具与事件监听器注销，重新启用时不重复挂载。”越用越卡”和”日志重复”正是热重载或禁用再启用时重复挂载的表现。让智能体按验收清单里的”清理”和”幂等”两组逐项自查即可。

问：哪些插件适合交给 DeepSeek Harness 一句话做，哪些建议自己写？

简单说看三条：可描述、可验证、可回滚。计数计时、数据展示面板、风格切换这类高频低复杂度的插件，非常适合交给它，成功率很高。涉及核心数据一致性、依赖大量外部服务、有硬性性能约束、或者要给整个团队长期维护的插件，建议自己写或至少自己审一遍。视频剪辑和论文阅读这类复杂插件介于两者之间——可以做，但要预留多轮打磨的时间，别指望一次成型。

问：七个官方提示词我直接抄了，结果和演示不一样，是我操作有问题吗？

不一定。DeepSeek Harness 官方的说明本身就很清楚：这些场景里有相当一部分是多轮打磨出来的。原文提示词的正确用法是当作需求写法的范本——学习它如何交代入口位置、核心能力、交互方式和边界约束——而不是当作可以直接复制的配方。建议你抄过来之后，先对照”四要素”检查一遍哪些信息对你自己的场景需要改写，尤其是边界约束，因为那是每个环境都不一样的地方。这样你得到的不会是一个”和演示不像”的插件，而是一个”符合你自己工作方式”的插件。

THE END

AI写作教程
# deepseek # AI插件