AI时代,为什么 Skills 是业务人员最后不被优化的护城河?

01 ）

我们也不是技术大拿，只是被现实逼着往前试

坦白说，FTP金融科技实验室一开始做 AI 和 Agent，也没有什么“技术大厂背景”。

我们不是底座模型厂商。
不是算法团队。
也不是那种动不动就讲 RAG、向量库、微调、SFT、MCP、复杂多智能体编排的技术流团队。

更真实一点说，我们更像一个“小团队”“草台班子”：
懂银行业务，懂风险管理，懂客户痛点，但一开始对 AI 工程化也没有那么笃定。

我们做这件事的起点，其实非常朴素：

客户问了，我们就想办法做；业务需要，我们就先试；能跑起来，再慢慢优化。

一开始，我们也走过不少弯路。

做过提示词模板。
做过风险报告生成。
做过贷后巡检 Agent。
做过业务监测报告智能体。
也尝试过用大模型去总结材料、生成建议、解释指标、输出分析报告。

刚开始确实觉得很神奇。

过去一个人写几个小时的材料，现在几分钟能出初稿；
过去要翻很多制度、字段和案例，现在可以让大模型先帮你梳理；
过去一份风险分析报告要反复组织语言，现在至少能先有一个像样的框架。

但做着做着，我们很快发现一个问题：

大模型会写，但不一定会做；

会总结，但不一定懂业务；

会说得很完整，但不一定能落地。

它特别擅长把话写圆。
但一旦进入真实风控场景，问题就来了。

什么叫高风险？
看哪个字段？
字段口径是什么？
阈值怎么定？
命中以后谁来处理？
是提醒、关注、复核，还是冻结额度？
哪些动作不能自动执行？
哪些结论必须人工确认？

这些问题，大模型不会天然知道。

你不给它，它就只能猜。
你给得模糊，它就写得漂亮但落不了地。
你给错了，它还可能一本正经地帮你放大错误。

这时候我们才慢慢意识到：

真正难的不是让 AI 生成文字，

而是让 AI 按业务逻辑稳定地做

02 ）

后来我们发现，Skills 可能是对业务人员最友好的入口

在不断试错的过程中，我们逐渐发现一个特别有意思的东西：Skills。

一开始我也没有把它看得那么重。
觉得不就是一个小文件夹、一套说明、一段提示词、一些规则配置吗？

但真正把它放到风控场景里之后，我发现：

Skills 可能是 AI 时代对业务人员最友好的知识入口。

为什么？

因为它不像底层模型训练那么遥远。
不像 RAG、向量库、微调、SFT 那么偏技术。
也不像复杂 Agent 工程那样，一上来就需要大量开发能力。

Skills 最核心的东西，其实不是代码，而是业务逻辑。

一个好的 Skill，要回答的不是“怎么写程序”，而是：

这个场景是什么？
需要哪些输入？
依据什么规则判断？
输出什么结果？
后面接什么动作？
为什么这么判断？
哪些地方必须人工复核？
这个 Skill 适用于什么边界？

你看，这些问题恰恰不是技术人员最擅长的。
这些问题，真正应该由业务人员来回答。

比如一个贷后预警 Skill。

技术人员可以帮你搭平台、接数据、配置文件、跑测试。
但他未必知道：

逾期几天开始有风险意义；
征信查询次数高到什么程度才异常；
新增非银贷款是正常周转还是资金紧张；
高风险客户应该先电话核查，还是直接冻结额度；
哪些动作会引发客户投诉；
哪些规则会误伤优质客户。

这些判断来自业务现场，来自一线经验，来自长期踩坑。

所以我现在越来越确信：

未来业务人员真正的机会，不是和 AI 比谁更会写材料，

而是把自己的经验写成 AI 能执行的 Skills。

03 ）

用好了 Skills，业务人员不但不会被踢出局，反而可能弯道超车

很多业务人员现在对 AI 有焦虑。

这个焦虑很正常。

因为很多重复性工作确实会被优化：

写报告初稿，
整理会议纪要，
生成普通分析材料，
归纳制度条款，
整理客户资料，
输出标准话术。

这些事情，未来一定越来越便宜。

但我反而觉得，对真正懂业务的人来说，AI 也是一次很大的机会。

关键在于，你要不要从“被 AI 替代的人”，变成“训练 AI 做业务的人”。

这两类人的差别很大。

前者只是把 AI 当工具，问一句、用一下、复制一段。
后者会把自己的业务经验拆出来，沉淀成结构：

场景、输入、判断、输出、动作、解释。

前者只是让 AI 帮自己写材料。
后者是在教 AI 按自己的业务逻辑做事。

前者的经验仍然停留在脑子里。
后者的经验开始变成组织可以复用的能力包。

这就是 Skills 的价值。

它不是一个技术热词。
它更像一个转换器：

把个人经验，转成组织资产；

把业务判断，转成系统能力；

把风控直觉，转成 AI 可执行逻辑。

所以我才说，Skills 很可能是业务人员最后不被优化的护城河。

更准确地说：

AI 会替代那些只会重复执行的人，

但会放大那些能把业务经验结构化的人。

04 ）

有人说Skills不就是Prompt 的升级版吗？

我回答：Absolutely not！

很多人会把 Prompt 和 Skills 混在一起。

觉得会写 Prompt，就等于会写 Skills。

不是。

Prompt 是一次性指令。
Skills 是可复用、可测试、可治理的业务能力包。

Prompt 更像“怎么问”。
Skills 更像“怎么干”。

比如你写一句 Prompt：

这当然有用。

但它解决的是一次性输出问题。

今天你这样问，它这样答。
明天换个人换个说法，它可能又变了。
如果输入字段不稳定、判断规则不稳定、输出格式不稳定，就很难进入风控系统和业务流程。

而 Skill 要解决的是另一件事：

以后遇到这类任务，系统应该稳定地按这套逻辑执行

所以一个成熟的 Skill，通常包括：

Prompt 是 Skill 的一部分。
但 Skill 绝不只是 Prompt。

这也是很多 AI 项目做不深的原因。

它们停在了“提示词工程”这一层，
没有继续往下沉淀成“业务能力工程”。

对于个人使用，Prompt 可以提效。
但对于银行风控，光靠 Prompt 不够。

银行真正需要的是：

稳定、可解释、可复核、可追溯、可持续优化

这就是 Skills 的价值。

05 ）

为什么通用 Skills 不够用？

市面上以后一定会出现很多通用 Skills 包。

比如：

这些有没有价值？

有。

它们可以帮助你理解结构，帮助你快速入门，帮助你看到一个基本样板。

但它们很难直接成为你们机构真正可上线的版本。

原因很简单：

风控没有完全通用的业务现场

同样是小微贷款，不同银行差异很大。

有的银行更看重税票数据；
有的银行更依赖流水；
有的银行外部数据接得比较全；
有的银行只能用内部还款表现；
有的银行产品客群偏轻资产；
有的银行客群主要是个体工商户；
有的银行风险偏好更保守；
有的银行为了增长会接受一定灰度。

如果你直接拿一个通用 Skill 来用，很可能会出现三个问题：

先写一个小场景，跑起来，再迭代