指标产品化：catalog、参数说明与 DSL 最小化
很多量化平台做“指标库”时，容易陷入一个误区：
只要指标够多、公式够全，就算完事。
但在团队交付场景里，指标库的真正价值不在“数量”，而在“产品化程度”：
- 能不能被非作者正确使用？
- 参数有没有中文说明与默认值？
- 不同策略之间能不能复用同一个指标定义？
- 策略 DSL 会不会越用越臃肿、难维护、难复现？
结论先行：EasyQuant 把指标当作产品资产来治理：用 catalog 管理指标与参数，用最小化 DSL 保证可维护与可复现，并把“解释与排障”能力嵌入到指标层。
一、指标产品化要解决的三件事
1）可理解：参数不是“period=14”这么简单
参数如果没有中文说明，团队会出现两类问题：
- 新人不会用，只能抄模板
- 老人也会用错：同名参数在不同指标里含义不一致
指标产品化的最低要求：
- 指标中文名 + 一句话解释
- 每个参数的中文说明 + 合理默认值 + 取值范围/校验
2）可复用：指标要成为“一等公民”
如果每个策略都在 DSL 里重复定义一遍 MA/RSI/BOLL，最终你会得到：
- 重复与漂移：同名指标参数不一致
- 难以治理：无法统一升级或修复指标实现
- 难以复现：策略导出后无法确认指标实现版本
因此指标应被 catalog 化：可引用、可复用、可版本化（至少实现应可追踪）。
3）可维护：DSL 必须“最小化”
很多系统的 DSL 会出现“冗余膨胀”：
- 策略 JSON 里带着大量未引用的指标定义
- 参数重复出现在多个地方（既写常量又写 ref）
- 导出/导入后体积越来越大，最终难以阅读与排障
EasyQuant 的方向是：DSL 只保留被引用、且对运行有影响的最小集合。
二、catalog：把指标从“代码列表”变成“产品菜单”
从产品视角，一个好用的指标 catalog 至少包含：
- 指标标识（key）：稳定、可引用
- 指标中文名（nameZh）与说明（descZh）
- 参数列表：每个参数的中文名、含义、默认值、范围、单位
- 输出：返回什么（线、带、上下轨、信号值）
- 典型用法：适用场景与常见组合（可选）
用户在 UI 上应该能够“选指标 → 看懂参数 → 一键生成策略片段”，而不是去翻文档或问作者。
三、参数治理：默认值是一种“团队共识”
默认值不是随便填的，它会直接影响策略行为与团队讨论口径：
- RSI 14 vs 30：信号频率完全不同
- BOLL 20/2 vs 50/2：波动判断尺度不同
- MA 5/10/20：趋势定义不同
平台应该鼓励“默认值可用，但可被显式记录与对比”。
这会与 provenance（见 04）形成闭环：
讨论策略时，先对齐参数与默认值口径。
四、DSL 最小化：为什么它能提升可解释与可复现？
当 DSL 过大、过冗余时：
- 用户看不懂：不知道哪段才是生效的
- 系统难诊断：错误上下文不清晰
- 复现困难：导出后很难核对“运行时用的到底是哪部分”
最小化 DSL 的产品收益是：
- 策略更像“可读的配置”，而不是堆砌的 JSON
- 运行快照（provenance）更干净，差异对比更清晰
- 诊断错误更聚焦（ENGINE_ERROR/参数校验/引用缺失等）
一句话：越少的噪声，越强的治理能力。
五、指标层如何支撑“为什么没信号/没下单”？
把指标产品化后，可解释性会更容易落地：
- 参数校验错误可以直接归类为 ENGINE_ERROR，并提示“哪个参数不合法”
- 指标 lookback 不足可以归类为 NO_BARS（或数据不足），提示需要更长窗口
- 指标输出异常（NaN/Infinity）可以归类为数据质量问题
这些都能让 03 的 Blocking Reasons 体系更准确、更可操作。
六、一个验收：让非作者也能正确配置并跑通
你可以用一个很实用的验收方法判断指标产品化是否到位：
- 让一个非策略作者的人，在 UI 里从 catalog 新建一个策略（MA 或 BOLL）
- 只依赖中文说明与默认值完成配置
- 跑一次回测，并能解释：参数如何影响信号频率、为什么会/不会触发
如果这条验收能稳定通过，说明你的指标库从“技术资产”升级为“产品资产”。
结语：指标越多不等于越强，能被正确使用才是价值
团队交付的关键是：降低误用与沟通成本，让策略配置成为可协作、可复现、可诊断的资产。
catalog、中文参数说明、DSL 最小化，就是把指标库从“代码集合”变成“产品能力”的三件套。
下一篇（09）我们进入执行链路：paper 执行为什么要做风控预检、通道抽象与账本更新，并且拒绝也要可解释。