先说结论：客户的个性化需求，过去只有两条路——要么进版本排期，要么忍着。现在有了第三条：用 DeepSeek Harness 的插件模式，像写一个 Skill 一样，现场给它写一个。

这篇文章不讲概念，讲怎么落地——一套三步走的方法，配一个真实案例：我们标准产品里的"假期余额"。按老规矩要 5 个产研干 3 周的活，1 个人、3 天，交付。产品代码，一行没动。

一个看起来很小、其实很大的需求

做 HR SaaS 这几年，客户问得最多的一句话，不是"你们功能全不全"，而是——"这个，能不能改成我们要的样子？" 

举个具体的例子。

HR 最常用的功能之一：查假期余额。我们的标准产品里，HR 能看到每个员工各类假期的余额，听着挺全。

但客户真用起来，需求马上就来了：

"我能不能看去年剩了多少、今年发了多少？"

"过期的假期，能不能看到明细——到底哪几天、哪几笔过期了？"

"能不能一眼看某个员工所有假期的余额，而不是一个假期一个假期地点开看？"

标准产品里，HR 只能查到一个"当前可请总年假"。去年结转多少、今年发放多少、过期明细，全都藏在黑盒子里。

原标准产品示意图1

调休假更典型。它只能看一个员工整个生命周期的余额——这人入职五年攒下的、用掉的、过期的，全糊在一个数字里。去年的余额是多少？今年加了多少班、换了几天的调休、折了多少加班费？

看不到。

原有标准产品示意图2

你说这需求大吗？不大。说小吗？不小。

以前：一个需求，3-5 个人，2-3 周

放在以前，这是一个标准的产品需求，得走完整流程：需求评审、方案设计、前后端开发、测试、发版。

协调 3-5 个产研，排期 2-3 周——这还是一切顺利的情况。

而且真正的成本不在这一单，在后面的每一单。客户 A 要这样看余额，客户 B 想按部门汇总，客户 C 要导出对账……每一条个性化需求，都是一次完整的产研投入。版本排期越排越长，标准产品越来越臃肿，客户还在等。

这是一道所有做 SaaS 的人都熟的题：个性化需求，永远做不完，也永远不敢不做。

现在：同一个需求，1 个人，3 天

这次换个思路，用的是 DeepSeek Harness 的插件模式。

它到底是什么？打个比方：标准产品就像手机系统，插件就像装一个 App。系统本身一行不用改，装上就多一个功能，想用就打开，不合适就卸掉。

以前那种做法，相当于为了加一个功能去改手机系统——得回炉、得升级、得等版本推送。插件不用：它跑在原产品旁边，只借用它的数据和账号。

写这个插件的过程，就像写一个 Skill：你说清楚要什么，它来写页面、接数据，你看效果、提修改。差别是，最后交付的不是一段回答，而是一个能点、能看、能导出的真页面，就挂在 DeepSeek Harness 的左侧菜单里。（图 3）

案例：如何写一个假期余额插件？

我把"假期余额"这个需求，当成一个正经产品来迭代：没有一步到位提个大而全的需求，而是分了三步走。

第一步：给够 Context，提需求。

开始时，我只跟它说了一句话："帮我写一个页面插件，核心是显示员工的假期余额，类似附件页面。数据通过我们开放的接口获取，计算逻辑我给你。" 

第一次输入提示词

注意这里的"附件"，是两样东西：一张原型示意图，让它知道我要大概长什么样；一份年假余额的计算规则和公式，让它知道数是怎么算出来的。

这就是 Context。它跑起来了，第一版页面直接按假期显示：年假多少、病假多少，按假期类型一列列排开。

假期余额列表-按假期（效果图）

假期余额详情-按假期（效果图）

第二步：看效果，迭代。

第一版能用，但不好用——想看某个员工所有假期的剩余，得一个假期一个假期地切。

于是我说：加一个页签，按人员汇总。一个人一行，后面跟着他全部 12 个假期的余额，最后给个合计。

几轮调试，完成。

新增需求

假期余额列表-按员工（效果图）

假期余额详情-按员工（效果图）

第三步：逻辑不一样的部分，单独写。

调休假跟年假完全是两套逻辑：结余 = 有效时长 - 已调休 - 已结转 - 已过期，还有加班费折算、过期减免开关、按年切换……公式完全不同，只能单独写一遍。

第二次新增需求

写完，它甚至能给每个员工下钻到单条加班记录：哪天加的班、加了多久、还剩多少、怎么算的，一笔一笔列清楚。点开任何一个员工，他去年结转、今年发放、已用、已过期，六张卡片一屏看完。

调休余额统计（效果图）

调休余额明细（效果图）

整个过程，一句话总结：提供 Context → 提需求 → 看效果调试 → 修 bug → 插件上线。跟做一个产品一模一样。只是把"产研团队"，换成了"AI + 你"。

调试问题1

调试问题2

经验：四个最容易卡住人的地方

过程中的细节很多，没法一一说，挑四条最要紧的。

第一，它能看到真实数据，靠的是另一个插件。

它能取到我们系统的真实数据，不是变出来的，是因为我们自研了另一个插件——一个登录我们系统的令牌。必须经过授权，AI 才能以当前登录用户的角色去取数。

这一点特别重要：权限体系一点没破。HR 登录，看到的还是 HR 该看的；老板登录，看到的还是老板该看的。AI 不是绕过了权限，是走在权限里面。

令牌授权

第二，Context 必须给足。

年假怎么算、调休怎么折、过期怎么处理——可以是图片，可以是文档，形式不限，但必不可少。

我的原则是：你给它什么规则，它才算得准什么数。AI 不是用来猜心思的，是用来执行上下文的。哪一版算得不对，十有八九不是它笨，是你漏给了一条规则。

第三，插件位置，随你放。

我这个属于页面插件，放在了 DeepSeek Harness 左侧菜单栏。但它能去的地方远不止这儿：左侧上方的主菜单、左侧下方的副菜单、甚至设置页面里，几乎所有地方都能挂。

这就是它说"一切皆可插件"的原因之一——你的插件页面，可以灵活地放到几乎所有地方。

DeepSeek Harness插件位置示意图

第四，测试调试，千万别让它猜。

我的做法是：全部用真实案例的截图或文档喂给它，告诉它预期结果是什么，现在的结果是什么，让它自己对。

测试调试案例

举个真实的例子。有次我拿一位同事的"自定义年假"去核对，三个数摆在眼前：可用余额 29.72 天，已用 7.5 天，今年应发 48 天，没有已过期。

剩的加用掉的，离应发差了十万八千里。第一眼，就是算错了。

但仔细一看，问题不在数上。他这条假期开了"当前可请按天折算"——可用余额和已用，都是按截至今天折算出来的口径，本身就该小于应发。数据是对的，是它看起来像错的。

这才是真正的麻烦：一个 HR 打开列表，看到剩余 + 已用 ≠ 应发，第一反应是"你们系统算错了"。后面跟着的，就是工单、就是解释、就是信任的损耗。

所以我加的是一条新要求：凡是开了按天折算的假期，必须在列表里做特殊标识，并把折算比例一并说明。同样一组数字，标上"按天折算"，HR 一眼就明白这是口径，不是 bug。

这个坑，靠猜永远猜不到。你只有拿真实数据的对照关系去喂它——预期是什么、现在是什么——它才会知道："数对了"和"看着对"，中间还差一个标识。

写在最后

做 SaaS 产品这几年，最大的问题之一，就是客户个性化需求的有效解决方案。我们也一直在探索不同的路径，但直到 AI 来了，才真正感觉找到了一条路：借助它的力量，低成本、规模化地解决客户的个性化需求。

过程中，我们要做的就是提供合适的平台和工具给客户。DeepSeek Harness 的插件机制，是我们系统插件平台的有效补充——它的灵活性，它的页面可视化能力，真就像给我们的插件平台如虎添翼，跟现有插件平台形成掎角之势，最终更有效地解决客户的个性化需求。

个性化需求不会消失。变的是：响应它的成本，从"一个版本"降到了"一个插件"。

互动一下

留个问题，你猜猜：我做这个"假期余额"插件，共计花费了多少钱？

提示一下：只算真金白银的硬成本，不算我的时间。评论区见，看看谁猜得准。