Dolphindb Vectorization Programming

---
name: dolphindb-vectorization-programming
description: >
  在编写、优化、审查 DolphinDB / DolphinScript 代码时使用此向量化工作流。
  适用于向量化编程、性能优化、for 循环改写、逐元素处理改写、逐列逐组脚本改写、
  SQL / 流处理路线选择，以及根据 tag / scene 判定低效模式并给出改写方案。
---

# DolphinDB 向量化编程

本技能帮助你在编写、优化和审查 DolphinDB 代码时，遵循向量化思维，把计算任务从逐元素的脚本控制流转向高层的批量原语、SQL、窗口函数、流引擎或适当的执行层升级。遵循此流程可以显著减少冗余循环、临时变量和语义模糊的表达，使代码更简洁、高效、易维护。

## 使用方式

整个工作流是“判明任务 → 生成初版 → 场景对照优化 → 最终审查”的循环。请严格按以下步骤执行，不要跳过中间的判断和对照步骤。

1. **读取规则与理解任务**  
   首先读取本文件（`SKILL.md`）和核心规则文件 [references/core-rules.md](references/core-rules.md)。重点理解：
   - 编码前的固定判断顺序（对象 → 输出 → 依赖 → 执行层 → 升级）。
   - 第一组：先描述清楚任务的对象、输出形式和结果依赖关系。
   - 第二组：确保数据放在正确的结构（向量、矩阵、表等）中，计算维度与对象形态对齐。
   - 第三组：优先使用专用批量原语，识别条件、序列、查找、整列处理等典型问题。
   - 第四组：当数据已在表中或进入流处理时，优先让 SQL 或流引擎完成工作。
   - 第五组：最后才考虑 JIT、并行或分布式升级。
   明确这些规则后，再开始动手写代码。

2. **初步生成符合规则的代码**  
   基于你对任务的理解，直接生成一版尽可能遵循上述规则的 DolphinDB 代码。即使还不够完美，也应先给出一个清晰的批量表达式或 SQL 路线，而不是先写显式循环再改造。

3. **读取场景索引，定位相关场景**  
   初次生成的代码通常还可以进一步优化。此时阅读 [references/scene-index.md](references/scene-index.md)，根据当前代码的特征（如是否包含低效的模式）找到对应的场景文件 `references/scene-XX-*.md`。这些场景文件包含了常见的低效写法、识别标记（`tag`）和推荐改写方法。

4. **对照场景文档，吸收改写思路**  
   仔细阅读命中的场景文档，重点关注：
   - 该场景下典型的错误模式及命中证据。
   - 提供的改写路线和推荐的函数/语法入口。
   - 案例中展示的改写前后对比。
   然后基于这些信息修改你的代码，使之更符合向量化规范。

5. **输出优化后的代码**  
   将经过场景对照优化后的代码作为结果输出。此时代码应已经过两轮打磨：一轮基于规则生成，一轮基于具体场景案例修正。

6. **再次审查与迭代**  
   输出后再次审视改写后的代码。如果发现仍然存在其他异常模式（例如又命中了另一个 `scene`），则回到第 3 步，继续通过场景文档进行修正，直到不再有可识别的低效模式为止。

## 规则读取

处理任何实质性的编写、优化或审查任务时，都必须先读取 [references/core-rules.md](references/core-rules.md)。该文件是全部判断的总纲。它包含：

- **编码前固定判断顺序**：在写任何代码前，先确定处理对象（向量、矩阵、表、数组向量、流批次等）、输出形式、结果依赖关系和逻辑应当放置的执行层，最后再判断是否需要升级执行层。
- **向量、矩阵、表、数组向量、流数据等对象的路线判断**：规则 03-05 帮你将数据放在合适的数据结构里，并让计算维度对齐。
- **条件、序列、查找、整列处理、窗口、分组、SQL、流处理和执行层升级规则**：规则 06-18 覆盖了从普通批量条件、序列问题、匹配对齐、整列清洗，到窗口定义、分组输出、SQL 优化、流引擎选择，以及最终引入 JIT 或并行、分布式的决策链。
- **规则判断的结束条件**：明确何时可以认为已经完成规则层判断，进入实现或反模式识别阶段。

**关键原则**：不要仅凭函数名称就决定技术路线。始终先回答：“我处理的是什么对象？结果长什么样？结果依赖什么？最适合在哪个执行层完成？”然后在此基础上选择函数、SQL、流引擎、JIT、并行或分布式方案。

## 场景文档

`tag` 和 `scene` 是“事后诊断”的工具，**只在审查已有代码或对初版代码进行二次优化时使用**。

- `scene` 是更大的分类（如“循环误用”“分组后回填”等），每个 `scene` 下可能包含多个具体的 `tag`（低效模式标签）。
- 在使用时，先读 [references/scene-index.md](references/scene-index.md)，根据代码表现出的症状找到对应的 `scene`，再进入对应的场景文档详细分析。
- 不要在没有看到实际代码的情况下凭空使用 `scene` 或 `tag`。

## 输出要求

根据你所处的任务阶段（设计期或审查期）和是否命中低效模式，选择对应的输出格式。

### 设计期路线判断

适用于从零开始设计、尚未有旧代码的情况。输出至少包含：

- **问题类型判断**：用一句话描述任务在向量化框架下属于哪类问题（如“与输入等长的条件赋值”“分组内时间滑动窗口”等）。
- **推荐路线**：应该走批量条件表达式、窗口函数、SQL context by、流引擎流水线，还是其他。
- **推荐函数或语法入口**：给出 1-3 个最可能的内置函数或语法结构。
- **仍需确认的前提**：列出可能影响路线选择但尚未明确的信息（如是否要求分布式、时间窗口的具体语义等）。

此模式不强制给出 `scene`、`tag`、命中证据和改写代码。

### 审查期且命中低效模式

适用于已有代码、且经过场景文档对照，确认代码存在已知低效模式的情况。输出至少包含：

- **主 `scene`**：所属场景分类。
- **主 `tag`**：最匹配的低效模式标签。
- **命中证据**：从原始代码中摘录能证明该模式的典型片段。
- **改写方向**：用自然语言描述重新组织计算的思路。
- **推荐函数或语法入口**：用来替换低效写法的具体内置函数或语法。
- **改写代码**：完整的改写后代码，保证与原逻辑等价。
- **仍需确认的前提**：列出改写时因信息不足做出的假设。

仅当确实存在两个标签竞争、难以立刻确定主次时，才额外给出 **1 个备选 `tag`** 并简要说明竞争理由。

### 审查期且未命中低效模式

如果经过规则和场景文档对照，确认代码已经遵循了向量化规范，且没有已知的低效模式，则直接输出：

```
代码符合向量化规范，无需改写。
```

如果有需要，可以在后面附加一段简短说明，解释为什么当前写法是合理的。此模式下省略 `tag`、命中证据和改写代码。

### 信息不足或环境受限

当任务描述缺失关键信息（如数据规模、是否需要分布式、时间戳是否规整等），或你无法读取本地参考文件时，应当：

- 明确列出缺失的信息。
- 说明由于信息不足，仅完成了基于现有部分的初步判断，无法给出最终代码。

这样可以避免在不确定的情况下强行给出可能误导的答案。