pattern-detection

模式检测

何时使用此技能

• 主要任务是查找重复形态或可疑异常，而不是立即全面解释或修复。
• 用户需要针对代码、日志／事件、遥测数据或指标表格进行可复用的扫描、整理候选项清单、分组候选集或异常初筛。
• 即使提示中没有出现“模式检测”一词，实际询问的也是**“哪些模式反复出现？”、“哪些地方看起来不对劲？”或“我们应该先检查什么？”**。
• 用户需要的是置信度说明、误报风险或最快的验证步骤，而不是一大堆未经整理的命中结果。
• 请求提到了模式、异常、离群值、重复故障、可疑峰值、异常群组、规则包、特征标记、代码异味、反模式、欺诈信号或反复出现的问题类别。

以下情况下，不要将此技能作为主要工作流：

• 实际任务是根据日志或追踪数据重建事件根因 → log-analysis
• 实际任务是为决策提供依据的 KPI 解读、实验分析或利益相关者报告 → data-analysis
• 实际任务是追踪代码库、查找负责人或搜索指标定义 → codebase-search
• 实际任务是安全修复、策略设计或漏洞加固 → security-best-practices 或 code-review
• 实际任务是告警调优、遥测覆盖或事件运维 → monitoring-observability

核心理念

pattern-detection 应该像一个检测任务包路由器，而不是一大堆正则表达式。

1. 将提示归一化为一个主要检测任务包。
2. 选择能够发现可信候选项的成本最低的证据模式。
3. 返回分组后的发现，并附上置信度和误报说明。
4. 给出一个最快的验证步骤。
5. 一旦瓶颈转为诊断、解释、修复或运维，就果断转交其他技能。

选择任务包前，请阅读以下支持文档：

• references/intake-packets-and-route-outs.md
• references/detection-modes.md
• references/confidence-and-false-positive-checklist.md

说明

步骤 1：归一化请求

先将提示转换为以下接收格式：

pattern_detection_packet:
  primary_packet: text-prefilter | structural-code-rule | log-event-pattern | metric-anomaly
  evidence_shape: code | configs | logs | events | telemetry | tables | time-series | mixed | unknown
  detection_goal: repeated-shape | risky-structure | noisy-family | suspicious-spike | drift | outlier | rule-draft | shortlist
  grouping_key: file-path | symbol-shape | error-family | event-name | build-version | environment | browser-device | cohort | metric-segment | unknown
  trust_risk: broad-match | parser-drift | instrumentation-change | denominator-gap | seasonality | sample-size | none | mixed | unknown
  route_after: stay-here | log-analysis | data-analysis | codebase-search | security-best-practices | monitoring-observability | code-review

为本次运行选择一个主要任务包。如果有两个选项都合理，请选择能最快减少不确定性的那个。

步骤 2：选择任务包

任务包	适用情况	最适合的场景	典型输出
text-prefilter	需要以较低成本进行初筛，缩小较大的范围	TODO/FIXME 集中出现、重复字符串、可疑配置值、大范围错误类别	候选文件／行、数量，以及下一任务包建议
structural-code-rule	语法或调用形态比纯文本更重要	高风险 API 用法、重复的分支／错误形态、迁移候选项、规则草案	分组后的匹配类别、排除项、可复用的规则思路
log-event-pattern	日志或事件记录中反复出现信号	噪声重试、浏览器／构建环境差异、重复错误、可疑事件类别	分组后的集群、分布／数量背景、可能的细分键
metric-anomaly	模式出现在聚合数据或时间窗口中	KPI 峰值／下降、留存或漏斗异常、可疑的支出或遥测变化	可疑的细分群体／时间窗口、基线说明、置信度和注意事项

任务包规则：

• 如果最快的收获是以较低成本缩小搜索范围，优先选择 text-prefilter。
• 如果纯文本匹配噪声太多，或无法识别真实代码形态，优先选择 structural-code-rule。
• 如果相比阅读单行内容，数据量、分布、解析器质量或群组划分更重要，优先选择 log-event-pattern。
• 如果用户关注峰值、漂移、群组或时间窗口异常，优先选择 metric-anomaly。

第 3 步：先缩小证据范围，再判断是否存在模式

解释结果前，至少采用一种缩小范围的方法：

• 按文件、路径或语言范围筛选
• 按时间窗口、部署窗口或实验窗口筛选
• 按一个稳定键分组：消息类别、事件名称、异常类、浏览器／设备、构建版本、群组、指标细分
• 将一个嘈杂来源与广泛的多来源分布区分开
• 将可疑窗口与基线窗口进行比较
• 留意解析器、架构或埋点的变化是否可能主导信号

按数据包划分的实用启发式方法：

• text-prefilter → 深入判断前，先统计数量并列出有代表性的示例
• structural-code-rule → 起草规则前，先用文字描述代码形态
• log-event-pattern → 区分数量与分布，并隔离群组／环境差异
• metric-anomaly → 判断异常前，先补充分母、基线和细分背景

第 4 步：呈现分组后的候选项，而非原始命中列表

按以下顺序组织：

1. 候选类别 — 存在哪种重复模式或异常？
2. 重要性 — 对正确性、可靠性、安全性、成本、用户体验或玩家／产品有何影响？
3. 置信度 — 高／中／低
4. 误报风险 — 什么因素可能造成误导？
5. 后续检查 — 最快的验证方式或转交方向

不要悄然将检测扩展为完整诊断、代码重写、仪表板备忘录或告警部署。

第 5 步：采用数据包专属启发式方法

对于 text-prefilter

• 仅将其用作低成本的初筛。
• 记录数量和有代表性的示例，而非每个命中项。
• 明确指出何时仅凭纯文本不足以判断语法／上下文。
• 当匹配结果噪声过多时，升级到 structural-code-rule 或 log-event-pattern。

对于 structural-code-rule

• 使用工具前，先用文字描述代码形态。
• 按类别对匹配项分组，而非按文件顺序排列。
• 指出可能的排除项和误报。
• 确认类别后，将实际修复或安全加固任务转交出去。

对于 log-event-pattern

• 先统一一种分组单位：错误类别、事件名称、异常类、浏览器、构建版本、区域、功能标志或租户。
• 区分重复出现的后续影响与可能的主要类别。
• 明确指出解析器或埋点的变化。
• 当用户需要了解实际事件经过时，将根因重建任务转交给 log-analysis。

对于 metric-anomaly

• 说明基线窗口与对比窗口。
• 结合分母背景比较绝对变化和相对变化。
• 检验异常是普遍存在，还是集中在某个细分群体。
• 暗示业务意义前，指出季节性、样本量偏小或埋点变更等因素。
• 将深入解释、建议或实验解读任务转交给 data-analysis。

第 6 步：返回一份精简的检测简报

默认回复格式：

## Detection brief
- Packet: text-prefilter | structural-code-rule | log-event-pattern | metric-anomaly
- Scope: [files / logs / rows / metrics / time window]
- Grouping key: [file family / symbol shape / error family / cohort / segment]
- Trust level: high | medium | low

## Candidate findings
1. [pattern family or anomaly]
   - Why it matters: ...
   - Confidence: high | medium | low
   - False-positive risk: ...
   - Next check: ...
2. ...

## Route-out
- stay here | log-analysis | data-analysis | codebase-search | security-best-practices | monitoring-observability | code-review

保持精简。重点是为用户提供尽可能短且可信的候选清单，而不是一份冗长的实施备忘录。

第 7 步：及时转交

当下一步工作不再属于初步检测时，切换方向：

• 根因分析、事件或故障重建 → log-analysis
• KPI 解释、实验结果解读或业务叙述 → data-analysis
• 代码库追踪、所有权查询或指标定义查找 → codebase-search
• 安全修复或加固设计 → security-best-practices
• 需要大量判断的补丁／PR 审查 → code-review
• 告警路由、遥测覆盖、事件运维或监控策略 → monitoring-observability

如果证据不足：

1. 将置信度标为低
2. 仅在必要时询问最少的缺失依据：范围、时间窗口、分组键或基线
3. 不要根据一段嘈杂的摘录或过少的样本假装确定

示例

示例 1：重复出现的高风险代码模式

提示词：

扫描此代码库，查找重复出现的高风险错误处理模式，并告诉我应该优先检查什么。

理想的响应形式：

• 选择 text-prefilter 或 structural-code-rule
• 按类别归组匹配项
• 包含置信度和误报说明
• 将修复工作交由审查、重构或安全技能处理，而不是当场修复所有问题

示例 2：KPI 激增分类

提示词：

我们的 CSV 导出中出现 KPI 激增。这属于模式检测还是数据分析？

理想的响应形式：

• 选择 metric-anomaly 进行初步检测
• 说明基线、分母和可信度检查
• 将原因说明和建议交由 data-analysis 处理

示例 3：游戏遥测异常值

提示词：

查找昨天更新后可疑的游戏遥测异常值。

理想的响应形式：

• 选择 log-event-pattern 或 metric-anomaly
• 按构建版本、群组、地区或物品／职业细分
• 说明埋点方面的注意事项
• 保持在检测模式，不承诺彻底解决平衡性问题

示例 4：告警还是异常？

提示词：

我们不断收到某项指标嘈杂的异常告警；我应该调试阈值、检查模式，还是撰写仪表板摘要？

理想的响应形式：

• 从 metric-anomaly 入手，判断是否存在真实的可疑时段，还是只有告警噪声
• 指出季节性、历史数据不足和分母方面的风险
• 将告警调优交由 monitoring-observability 处理，将 KPI 说明交由 data-analysis 处理

最佳实践

1. 从证据单位和分组键入手，而不是工具名称。
2. 升级处理前，先使用成本最低且可信的分析包。
3. 始终包含置信度、误报风险和一项后续检查。
4. 将发现归入候选类别，而不是列出原始命中项。
5. 区分检测与诊断、修复、说明和告警运维。
6. 将解析器、埋点、季节性和分母问题视为首要注意事项。
7. 同一模式可能再次出现时，优先考虑可复用的规则思路。

参考资料

• ripgrep 指南
• ast-grep 简介
• Semgrep 模式语法
• CodeQL 概览
• Datadog 正则表达式／grok 解析指南
• OpenSearch 异常仪表板
• scikit-learn 异常值检测