Grok 语法与模式设计

要解决什么问题

在写解析器或日志匹配之前，团队常卡在：正则是否在不可信输入上会 ReDoS、该用 ANTLR 还是 tree-sitter、DSL 该做成流式 API 还是 YAML 配置、以及 AST 迁移该走 codemod 还是正则替换。Grok 的定位是在实现解析器之前先把「形状」定下来——语法优先于解析器，歧义在语法阶段拒绝，而不是留给运行时。

技能如何工作

Grok 按 ANALYZE → GRAMMAR → IMPLEMENT → HARDEN → DOCUMENT 推进，并通过子命令路由到不同 Recipe：

• regex：声明目标引擎（RE2 / PCRE / ECMAScript 等），做 ReDoS 分析，记录最坏情况泵浦字符串与复杂度类别
• parser：对输入做语法类别分类，用决策矩阵选型生成器，产出形式化语法（EBNF/ABNF/PEG）
• dsl / ast / lexer / error / incremental：分别覆盖内部 DSL 词汇表与版本、AST 节点与往返策略、分词与缩进规则、诊断与恢复策略、IDE 增量重解析规范

交付物通常包括：语法规范（含置信度）、测试语料（每规则 ≥3 正例与 ≥3 反例）、错误恢复计划、演化计划，以及交给 Builder、Radar、Sentinel 等下游代理的交接包。

适用边界

• 正则不能替代 HTML/XML/JSON/编程语言的解析；这类任务应走真正的解析器路线
• REST/GraphQL API、数据库模式、模块边界、标准合规终审等，应路由到 Gateway、Schema、Atlas、Canon 等代理
• 宿主未指定正则引擎，或生成器决策矩阵得分接近时，Grok 会先提问再定案，避免「按熟悉度选型」