最近常用 Codex 做重复性工作。流程刚跑通，我就会想：下一步要不要把它包装成 Skill？
前段时间，我把给业务部门写的一个脚本改成了 Skill，这样用户就可以通过与智能体对话来完成原来的功能。
流程大致是：用户上传文件，智能体检查、列出可用字段，用户确认后执行计算。沿着这个思路继续往下做，还可以预先兼容更多文件格式、字段命名习惯和异常列名，把可能遇到的分支都写进同一个 Skill。
写着写着，我发现一个问题：Skill 越想覆盖所有可能，就越像一个参数越来越多的函数。
写代码时也会遇到类似的情况。重复出现的逻辑需要封装成函数，才能被反复调用。但当一个函数试图覆盖越来越多的场景时，它的参数、判断和例外也会不断增加。最后，它未必真的变得更加通用，反而可能让下一次调用它的人更难理解它究竟应该怎么用，这里边也包括未来的自己。
这种「为了通用而不断增加复杂度」的问题，并不只存在于函数和 Skill 中。把尺度放大，它同样存在于软件产品的设计中：我们究竟应该先抽象出一套标准流程，再让用户适应它，还是先解决一个个具体问题，再从中寻找真正稳定的共性？
过去，定制开发和长期维护软件的成本很高，因此 SaaS（软件即服务） 通常需要先提炼出一套相对标准的流程，再让大量用户按照这套流程使用，以分摊开发和维护成本。
现在，写代码的成本正在快速下降。面对一个具体需求，先做出一个能够解决问题的工具，已经没有过去那么困难。于是，产品化未必总要从上往下开始：先设计完整产品，再寻找适合它的用户。它也可以从下往上，从许多细小但真实的需求中，逐渐归纳出来。
当产品可以从具体需求中逐渐生长出来，离用户最近的人也就变得更加重要。这或许正是 FDE（前沿部署工程师）越来越受重视的原因。
FDE 身处客户现场，一边解决眼前的具体问题，一边判断其中哪些只是单个客户的特殊情况，哪些已经具有被产品化的价值。
这种判断并不只属于 FDE。自己写 Skill 时，面对的其实是同一个问题：哪些变化应该交给模型临场处理，哪些重复已经值得固化为稳定能力？
现在，我更愿意先把眼前的问题解决好，把输入、输出、风险和验收标准写清楚。需要稳定执行和严格校验的部分，交给脚本；需要结合上下文灵活处理的部分，先让模型判断。等某些情况稳定地出现两三次之后，再考虑把它抽象到 Skill 中。
那些为了预防尚未发生的场景而增加的分支，不必过早写进去。让 Skill 保持具体和简洁。模型会越来越擅长应对临时变化，而眼前面对的需求，才足够真实。