mcpField
D
data-systems-coding-lens

data-systems-coding-lens

github.com/robsonrung数据与数据库268 次安装2 天前更新
代码仓库

关于 data-systems-coding-lens

Data Systems Coding Lens 是为编码工作添加数据系统审查步骤的技能，适用于实现、代码审查和架构规划。它聚焦数据事实来源、可重试写入的幂等性，以及存储、分布式行为和故障恢复风险。

主要功能

  1. 01识别数据边界与事实来源
  2. 02检查模型、查询和存储契约
  3. 03审查重试、重复操作与故障处理
  4. 04评估分布式一致性与并发
  5. 05规划迁移、回滚和可观测性

适用场景

  1. 01实现涉及持久数据的功能
  2. 02审查队列或外部服务交互
  3. 03规划数据模型迁移与回滚

安装

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

$npx skills add https://github.com/robsonrung/rar-skills --skill data-systems-coding-lens

安装后在 Claude Code 中输入/data-systems-coding-lens确认已加载。

附带文件evals.json

详细介绍

数据系统编码审查视角

使用此技能，为编码工作增加一轮实用的数据系统审查。目标不是讲解理论，而是在故障模式演变成生产环境 Bug 之前将其发现。

每轮审查都围绕两个关键词展开，并会在下方的检查项中反复出现。事实来源：明确指出每项事实由哪个唯一位置持久保存，这样缓存、索引、读模型等派生副本始终可以从该位置重建。幂等：任何可能重试或重放的写入，第二次执行时都必须产生相同结果——不能重复扣款、发送邮件、创建任务或记录。审查时请明确使用这两个名称。

第一轮审查

首先确定状态边界：

  1. 哪些数据会被创建、读取、更新、删除、缓存、派生或发出？
  2. 事实来源是什么？
  3. 哪些路径是同步、异步、可重试、可重放或对用户可见的？
  4. 哪个不变量一旦被破坏就会导致功能出错，代码又在哪里断言了它？
  5. 哪种故障会悄无声息、代价高昂或难以修复？

如果任务很小，简要完成这轮审查，并将其融入实现过程。如果任务涉及共享数据契约或生产记录，请在编辑前写下答案。

不要对纯 UI 文案、样式、一次性脚本、仅涉及文档的编辑或本地临时工具过度复杂化。对于这些情况，只有当改动涉及持久化数据、后台工作或生产运维风险时，才应用此审查视角。

实现审查视角

修改代码时，按以下顺序检查这些方面。

数据模型与契约

检查架构形状、可空性、枚举扩展、标识符稳定性、时区、所有权、唯一性和向后兼容性。

请思考：

  1. 旧写入方能否与新读取方共存？
  2. 新写入方能否与旧读取方共存？
  3. 是否存在回滚路径？
  4. 迁移默认值对现有数据是否安全？
  5. API 契约对客户端和任务来说是否足够明确？
查询与存储路径

检查查询基数、索引覆盖情况、分页、排序稳定性、缓存键、缓存失效、事务范围和锁行为。

请思考：

  1. 哪些因素会随用户数、租户数、行数、事件数或时间增长？
  2. 代码是否会意外地将一次请求变成多次数据库往返？
  3. 随着数据增长，查询计划是否可能变得糟糕？
  4. 写入在重试时是否幂等？
  5. 同一操作能否与自身发生竞态？
可靠性与故障

检查重试、重复消息、部分写入、超时行为、毒消息、死信处理和面向用户的恢复方式。

检查进程资源：每个文件、句柄、锁、事务、订阅、计时器和套接字都需要明确的所有者，并且在成功、失败和取消时都有清理路径。

请思考：

  1. 两次写入之间发生崩溃会怎样？
  2. 外部服务调用成功但本地写入失败时会怎样？
  3. 本地写入成功但外部服务调用超时时会怎样？
  4. 重试是否会造成重复扣款、发送邮件、发送通知、创建任务或记录？
  5. 运维人员如何检测并修复故障？
  6. 正确性是否依赖隐含的时间顺序？打破这种依赖——通过状态、队列、锁、事务、幂等键或版本检查明确实现顺序。
分布式行为

如果涉及多个进程、工作进程、区域、数据库、队列、缓存或外部系统，请使用本节。拓扑——这些进程组成的 Burns 模式（sidecar、分片、扇出/汇聚、选举还是单例、工作队列）——属于 distributed-systems-patterns。本节关注这些选择在代码层面可能导致的故障模式。

检查顺序假设、陈旧读取、写后读需求、领导者选举、租约、对时钟的依赖、一致性级别、事务边界和协调机制。

请思考：

  1. 正确性是否要求全局顺序？
  2. 对于此用户流程，最终一致性是否可以接受？
  3. 哪些操作需要强一致性，哪些可以稍后协调？
  4. 两个参与方同时更新同一实体时会发生什么？
  5. 是否存在可用于重建派生状态的真实数据源？
演进与维护

检查部署顺序、功能标记、带版本的载荷、架构迁移、回填、重建、可观测性和清理计划。

请思考：

  1. 这项更改能否分多次部署？
  2. 迁移能否暂停后恢复？
  3. 能否根据持久化输入重建派生数据？
  4. 日志、指标和追踪是否足以调试真实的生产路径？
  5. 发布后需要清理哪些旧代码、数据、标记或作业？

在 design-gate 下，使用调用方的规范门禁结果。此结果会取代独立的输出和编辑机制。将特定视角的结论纳入发现项或 review_focus，并使用稳定的发现项 ID。在访谈中，将决策字段补充到现有决策记录中。

输出模式

对于实现工作，在开始编码前酌情添加简短说明：

Data systems lens:
State touched:
Invariant:
Main risk:
Verification:

对于代码审查，先列出具体发现：

Finding:
Why it matters:
Failure case:
Suggested fix:
Verification:

对于架构或规划，使用以下简洁的决策记录：

Decision:
Source of truth:
Consistency requirement:
Failure handling:
Migration path:
Observability:
Open question:

默认验证方式

优先选择能覆盖真实边界的验证方式：

  1. 使用单元测试验证不变量和幂等性。
  2. 使用集成测试验证数据库、队列、缓存和外部 API 边界。
  3. 使用现有数据形态检查迁移。
  4. 使用并发测试检查竞态和重复工作。
  5. 当基数是风险因素时，检查负载或查询计划。
  6. 检查日志、指标、追踪和修复信号等可观测性。

最终回复约定

如果此技能改变了工作内容，请在最终回复中提及价值最高的检查。保持简短：

I also checked the data systems risk: [state or invariant], [main mitigation], [verification].

评论

支持 Markdown