dolphindb-vectorization-programming

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

DolphinDB 向量化编程

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

使用方式

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

1. 读取规则与理解任务
   首先读取本文件（SKILL.md）和核心规则文件 references/core-rules.md。重点理解：

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

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

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

4. 对照场景文档，吸收改写思路
   仔细阅读命中的场景文档，重点关注：

   • 该场景下典型的错误模式及命中证据。
   • 提供的改写路线和推荐的函数/语法入口。
   • 案例中展示的改写前后对比。 然后基于这些信息修改你的代码，使之更符合向量化规范。

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

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

规则读取

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

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

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

场景文档

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

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

输出要求

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

设计期路线判断

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

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

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

审查期且命中低效模式

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

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

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

审查期且未命中低效模式

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

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

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

信息不足或环境受限

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

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

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