作者继上一篇DSH插件实操后，继续总结写插件的两个卡点：不知道写什么、不知道怎么写。从选题方法到动手路径，分享了三个真实案例和两套方法论，帮你把内部需求变成可复用的插件。

上一篇讲完怎么用 DeepSeek Harness 插件，解决客户个性化需求？（后面简称 DSH 插件）解决客户的个性化需求之后，我们也在做自己的客户端，让内部小伙伴和客户一起上手玩。

真要推广开、让每个人都写一款插件时，两个问题把小伙伴卡住了：不知道写什么，也不知道怎么写。

这两个问题看着像一回事，其实是两回事。一个卡在“选什么题”，一个卡在“怎么下手”，得分开治。

第一个问题：不知道写什么

方法论是一句话：

角色 +（最小）场景 + 数据/能力 +（极简）页面 = 一款插件

比如我写的第一款插件“假期余额”：角色是考勤 HR，最小场景是核查假期余额，数据从现有 SaaS 系统的开放接口取，页面只呈现 HR 真正关心的那几列。

插件入口

假期余额插件

四个词，我一个个拆。

一是“角色”。起心动念要写插件的时候，你脑子里必须先站一个人。大白话说：这款插件，你给谁做的？

二是“最小场景”。我特意加了“最小”两个字，因为这是新人最大的坑。

很多人一上来就想大而全，恨不得把一个角色所有的活都装进去，觉得不酷、拿不出手。结果往往是战线越拉越长，最后无疾而终。

这个坑我自己踩过。写第二款插件时，我想做的是“考勤 HR 工作台”——每日出勤、异常考勤、出勤预警、工时统计、报表管理、考勤确认、假期余额、大批量数据处理……刚画原型我就发现不对：功能越列越多，一个人根本做不完研发和测试，数据缺口也越来越大。项目最后无疾而终。

果断放弃，重新开始。

我从里面挑出标准产品目前最缺的一环——“每日出勤”，单独做成一个插件，只解决一件事：让考勤 HR 一眼看清员工的今日出勤情况、每日出勤明细，以及出勤合规预警。

每日出勤1

每日出勤2

每日出勤3

到第三款插件“工资追算器”，我只用 1 小时就写出了第一版。它针对薪酬 HR，解决一个很小但很烦的问题：某个工资项到底是怎么算出来的。

工资追算器

前一个项目一事无成，这一个 1 小时出版本。差别不在能力，在于我把“最小”两个字真正放进去了。

三是“数据”，四是“极简页面”。这两个词其实是一回事，都在提醒你要懂得舍弃。

数据解决“从哪来”——做插件就像做饭，得先买菜，产研团队在这个链条里就是“蔬菜运营商”，缺菜直接找他们要。极简页面解决“呈现什么”——繁杂而作用有限的设计全部砍掉，只服务于那个最小场景。

比如工资报表有几十张、几百个字段，日常真正要核查的可能就 10 项。那就只给一个列表，默认显示这 10 项，剩下的让用户自己勾选。

所以，不知道从哪下手的时候，就顺着这四个词往下问自己：

1. 你要为谁写（即角色）？
2. 如果只能替他解决一件事，你选哪件（即最小场景）？
3. 这件事要的数据和能力，是不是已经现成（即数据/能力）？
4. 如果只有一个页面，这个页面最该放什么（即极简页面）？

第二个问题：不知道怎么写

题选好了，接下来是最容易劝退人的一段。

我猜你拿到客户端的第一反应也是这样：打开，新建，光标在输入框里闪，半天打不出一个字。不是不会打字，是不知道第一句该说什么、说多少、说到什么程度才算够。

方法论也是一句话：

需求 + 上下文 + 调试 = 写好一款插件

第一步：先把需求说出来

能说清楚最好，说不清也没关系，只是多耗些时间。别因为怕说错就迟迟不开始——第一句话的目标不是“说对”，是“发出去”。

假期余额插件，我第一句话是这么说的：

“帮我写一个页面插件，核心是显示员工的假期余额，类似附件页面。数据通过我们开放的接口获取，计算逻辑我给你。”

第一款插件——假期余额

每日情况插件，我是提供了一个原型给它，并这么跟它说：

“基于我这个HTML的原型，帮我开发一个页面插件，核心是面向xx考勤HR，辅助他们可以完成对自己所负责权限范围内的员工，进行出勤结果的查看、跟进以及统计，快速定位异常员工等”

第二款插件-每日情况

工资追算器插件，我第一句说这么说的：

“你帮我写一个页面插件，名字叫工资追算器，目的是解决用户在使用xx系统的工资模块时，对某个工资项（比如税前工资合计、税后实发、应补（退）税额等）字段有疑问时，可以直接点击某个员工的数字追查它的公式，以及对应公式里的每个数字的值。要求是：我们必须基于xx真实员工数据进行核算，页面设计上，可以每次只看一个月的报表数据，而报表数据我们可通过接口方式直连xx系统的已归档报表（全数据表是最全的逻辑），至于计算公式与逻辑，我稍后给你提供”

第三款插件——工资追算器

就这一句。没有需求文档，没有原型规范，没有字段清单。

第二步：把上下文喂进去

这一步非常关键。你提供的上下文质量，决定了它能输出给你的效果。

打个比方：你把任务交给一个刚毕业的北大实习生，第一版能做成什么样，八成取决于你表达得清不清楚、背景给得够不够，而不是取决于他。

我一般给三样东西：长什么样（一张效果草图）、数怎么算（规则和公式）、从哪取数（接口和字段）。

假期余额插件给的是一张手绘草图和一份年假计算规则；工资追算器给的是系统里几百个工资项的计算公式——直接截图，一条一条，不翻译、不精简。

假期余额-提供示意图

工资追算器-提供公式

第三步：在调试里把它磨出来

这一步最关键，没有之一。

因为插件是“一人团队”的模式：需求、设计、研发、测试全是你自己。你既是参赛的运动员，又是判分的裁判——一边比赛，一边判断结果，反复调，直到把它磨成一个能用的东西。

工资追算器：描述需求、给上下文、调出一个大致能看的页面，前后 1 小时。真正把它调到基本可用，花了 2 天多。

调试过程1

这 2 天翻了十几次车，但真正改变我打法的只有一句话。有一回我刚修完一个括号显示的 bug，用户说：

“你重新过一遍，看看是否还有哪些字段的公式遗漏？不能我说哪个你改哪个，终究会有遗漏。”

AI 犯的错是成批同构的——你修好一个括号，后面还排着十个。所以调试不是“用户指哪你打哪”，是一次性把全部规则过一遍。

回头看，管用的三条经验

经验一：先初调页面效果，再精调数据准确性，最后再精调页面效果。

先易后难。打个比方，你要让一只猴子站上 5 米高的台子演讲，你下意识的动作是先搭台子，而不是先教猴子说话。

初步调试效果

这么排是有过教训的。工资追算器上线前，我发现同一账号2026年1月实际有65人，却只能查到5个人？

如果我那时候已经在抠页面样式，这个问题根本浮不出来。

最后是用一句话把它定死的： “活动月也应该以报表为准，因为我当前登录的人只有对应 60 人的权限。”

一句话，定下了整个插件的数据架构。因为“哪个口径才是对的”这种事，AI 不知道，我也不知道，只有每天用它的人知道。

经验二：一图胜千言，示例胜千言。

说不清楚就上图，草图、截图、原型都可以。做不出“年份和月份一起选”的筛选组件，我截一张现有系统的图给它；不方便把手册里的公式敲给它，就截图。

调试插件图1

调试插件图2

而真正让我记住这条的，是一次翻车。某个类别取不到值时，我用“报表值减去其余项”倒挤出一个数填进去，候选字段里冒出一堆名字很像的项，加起来正好等于差额。用户的反应是：

“你这是瞎凑数，只要凑够 500 即可，是吗？”

调试插件图3

倒挤会把“未知”伪装成“已知”——页面上漂漂亮亮一个数字，背后其实是凑出来的。

这一个问题改了六版都没解决。最后不是靠又改一条规则，而是把东西摊开：已归类项合计打出来，候选字段明细打出来，版本号放在页面上。让用户和我看到同一份数据。

从那以后我才明白：“示例”不只是喂给 AI 的素材，也是你跟用户对账的方式。

经验三：不要追求大而全，也不要追求完美。

它叫插件，不叫产品，区别就在这份灵活：专注解决某一个问题。假期余额只解决查看和管理余额，每日出勤只解决核查出勤，工资追算器只解决核算工资。

一人团队做插件，追大而全，基本等同于失败——需求越做越多，时间越拖越长，最后要么放弃，要么交不出来。

工资追算器最后停在 0.17.18，65 个测试用例，仍然有没解决的问题：平台项来源、万人导出、部门维度。但它已经能用——页面上每个数字都能说清楚是怎么来的，或者明明白白告诉你“这部分我还没识别出来”。

有意思的是，当我围绕 HR 做的插件越来越多，那没做成的工作台，自己长开始慢慢出来了。把这些插件“缝”在一起，它就是 HR 工作台。

写在最后

两句话收个尾。

插件写什么：角色 + 最小场景 + 数据 + 极简页面。

插件怎么写：需求 + 上下文 + 调试。

但写完这几款插件，我最深的体会不在公式里。

这段过程里真正难的，不是写页面、写接口、写分页。难的是：调试过程中，如何确保功能的完整性，以及数据的准确性。

所以如果只用一句话总结：

插件不是把页面做出来就完了，是要让用户相信页面上的数字，是真正能解决用户的问题。

让每个人都写一款插件，目的不是让大家都变成程序员，而是让最懂业务的人，第一次有了自己动手的资格。