mcpField
R
regex-chess

regex-chess

github.com/letta-ai开发15238 次安装4 周前更新
代码仓库

关于 regex-chess

该技能指导使用正则表达式匹配和替换 FEN 等棋盘表示，以实现国际象棋走法生成器。它强调逐步构建模式，并检查匹配结果和转换后的局面。

主要功能

  1. 01映射 FEN 棋盘表示
  2. 02设计基于正则的走法模式
  3. 03逐步实现不同棋子走法
  4. 04验证棋盘转换结果
  5. 05利用捕获组调试

适用场景

  1. 01构建仅使用正则的走法生成器
  2. 02逐步添加各棋子的走法
  3. 03排查错误的棋盘转换

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/letta-ai/skills --skill regex-chess

安装后在 Claude Code 中输入/regex-chess确认已加载。

详细介绍

Regex Chess

概述

此技能为仅使用正则表达式实现国际象棋走法生成器提供策略指导。这类任务需要通过模式匹配和替换来转换棋盘状态（通常采用 FEN 表示法），而不是使用传统编程结构。

核心方法

阶段 1：了解字符串表示形式

编写任何模式之前，请先彻底了解棋盘的表示方式：

  1. 解析 FEN 结构：FEN 表示法按第 8 横排到第 1 横排（从上到下）编码棋盘；每一横排内的纵线按 a 到 h 排列（从左到右）
  2. 将坐标映射到字符串位置：展开数字占位符（例如，将「8」变为「........」）后，确定每个格子的确切字符索引
  3. 记录顺序：明确列出展开后的字符串中各个格子的排列顺序
阶段 2：从简单开始——先处理一种走法

关键：先彻底实现一种走法，再增加复杂度。

建议顺序：

  1. 从单步兵前进开始（例如 e2-e4）
  2. 验证模式能否正确匹配
  3. 验证替换能否生成正确输出
  4. 只有完成以上步骤后，才添加更多兵的走法
  5. 只有所有兵的走法都正常后，才添加马（不具备滑行能力，是最简单的棋子）
  6. 逐步添加其他棋子
阶段 3：坐标标注策略

为简化模式匹配，可以考虑在展开后的棋盘上添加坐标标注：

Original: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR
Expanded with labels: R8:a8r.R8:b8n.R8:c8b...R1:h1R.

这样可以让模式更易读懂，并减少坐标混淆。

阶段 4：模式结构

对于每个走法模式：

  1. 用于保留上下文的捕获组：使用分组保留周围的棋盘状态
  2. 起始格模式：匹配棋子所在的起始位置
  3. 目标格模式：匹配目标位置（空格或敌方棋子）
  4. 替换字符串：重建棋盘，将棋子移到目标位置，同时保留所有其他状态

验证策略

测试每个转换步骤
  1. 模式匹配验证：确认模式能匹配预期输入
  2. 替换输出验证：确认替换结果正确
  3. 往返验证：确认输出的 FEN 有效，并表示预期走法
渐进式测试流程
For each new move pattern:
1. Test on known position with expected outcome
2. Verify exactly ONE move is generated
3. Verify the move is the CORRECT move
4. Only then add to the full pattern set
调试输出格式

调试时，请输出中间状态：

  • 匹配前展开后的棋盘字符串
  • 匹配到的模式
  • 捕获组及其值
  • 压缩前的替换字符串
  • 最终 FEN 输出

常见陷阱

坐标顺序错误

问题：格子在 FEN 字符串中按特定顺序排列（先第 8 横排，再第 7 横排，依此类推）。匹配两个格子时，字符串中哪个格子更靠前取决于坐标，而非它们在走法中的作用。

解决方案：当模式需要匹配起始格和目标格时，应根据坐标确定哪个格子在字符串中靠前，而不是根据哪个是起始位置、哪个是目标位置。

分组编号混淆

问题：在替换中使用 \1、\2 等时，没有记录每个分组对应棋盘的哪个区域。

解决方案：为每个模式添加注释，明确标出分组对应关系：

# Group 1: everything before source square
# Group 2: source square piece
# Group 3: everything between source and dest
# Group 4: destination square
# Group 5: everything after destination
过早生成模式

问题：在确认基础设施可用之前就生成数千个模式。

解决方案：逐步生成模式。先验证 1 个模式可用，再验证 10 个，然后 100 个，依此类推。

放弃部分可用的解决方案

问题：某个方案部分可用时，却重新开始采用所谓「更好」的方法，结果把一切都弄坏。

解决方案：取得阶段性成功时（例如，某个测试局面的 3/3 步走法均正确），请保留可用代码。在此基础上扩展，不要将其替换掉。

格式问题与逻辑问题

问题：核心逻辑还不能正常工作，就在输出格式（尾随空格、走法计数器）上花费过多时间。

解决方案：先确保棋盘转换正确。格式调整应作为最后一步。

测试模式匹配但不进行替换

问题：验证模式是否“匹配”，却不验证替换结果是否正确。

解决方案：始终检查两点：（1）是否匹配？（2）替换结果是否正确？

实现检查清单

运行完整测试前：

  • 一次简单的移动（例如 e2-e4）可以端到端正常运行
  • 所有兵的单步前进都正常
  • 兵的吃子正常
  • 马的移动正常（没有滑行的复杂情况）
  • 象／车／后的滑行移动正常
  • 王的移动正常
  • 边界情况：靠近棋盘边缘的移动

通常会延后实现的功能（请核对需求）：

  • 移动合法性（移动后王没有被将军）
  • 王车易位及正确的权限跟踪
  • 吃过路兵
  • 兵升变
  • 兵双步前进时更新吃过路兵目标格

调试工作流

移动有误时：

  1. 隔离失败案例：只用这一个模式进行测试
  2. 打印展开后的棋盘：确认输入符合预期
  3. 打印捕获组：确认每个组都包含预期内容
  4. 打印原始替换结果：在进行任何压缩或格式化之前
  5. 与预期结果比较：必要时逐字符比较

避免：

  • 不隔离问题就反复运行完整测试套件
  • 未修复现有模式就添加更多模式
  • 明明调试就能解决，却从头重写

评论

支持 Markdown