mit einem Klick
kdit-debug
// 系统化调试工作流:当现象不明确、根因未知时,强制执行"信息收集 → 假设生成 → 逐层验证 → 定位根因 → 记录结论"的排查流程。 区别于 bugfix(已知问题修代码),debug 侧重于从混沌的现象中找到问题本质。 关键词:debug、调试、排查、诊断、日志分析、二分法、断点、现象不明。
// 系统化调试工作流:当现象不明确、根因未知时,强制执行"信息收集 → 假设生成 → 逐层验证 → 定位根因 → 记录结论"的排查流程。 区别于 bugfix(已知问题修代码),debug 侧重于从混沌的现象中找到问题本质。 关键词:debug、调试、排查、诊断、日志分析、二分法、断点、现象不明。
在编码或架构设计前强制执行"需求澄清 → 可行性分析 → 结构设计 → 测试设计 → 编码实现 → 校验 → 文档同步"的七步流程。 适用于功能开发、重构、新模块创建、架构讨论与设计评审等需要先设计后实现的场景。 关键词:development spec、先设计后编码、架构讨论、设计评审、需求确认、结构体设计、单元测试先行、vibe testing。
kDiT 架构知识库:全局架构图、数据流、Node/Pipeline/Generator/Adapter 子系统设计、 PinHub 沙箱机制、PoolKey 间接寻址、DeviceInfo/NodeContext 规范。 关键词:architecture、架构、Node、Pipeline、Generator、Adapter、Engine、Executor、PinHub、Pool。
kDiT 编码规范:Import 风格(方案 B)、Python 3.10+ 类型注解、Key 类型体系、 Node/Tensor API 开发约束、异常处理规则、类命名规范。 关键词:standards、规范、import、类型注解、Key、异常处理、命名。
kDiT 质量保障与交付验收:单元测试规范(*_test.py 命名、tests/kdit/ 镜像结构)、 pre-commit 格式检查(black 120字符、ruff)、pytest vs ruff 维度差异、文档同步规则。 关键词:quality、测试、test、pytest、pre-commit、ruff、black、验收。
Bug 修复工作流:修复 bug 时强制执行"根因分析 → 反思测试缺口 → 修复代码 → 补充单元测试 → 验证"流程。 确保每次 bug 修复都附带回归测试,并反思为什么现有测试没能覆盖到。 关键词:bug fix、修复、regression、回归测试、测试缺口。
kDiT 代码评审技能:除常规 CR 项(安全漏洞、格式规范、逻辑正确性)外,重点基于项目 .skills/ 中的架构设计 和编码规范进行评审,确保代码不违背设计原则和约束。 关键词:code review、CR、评审、review、架构合规。
| name | kdit-debug |
| description | 系统化调试工作流:当现象不明确、根因未知时,强制执行"信息收集 → 假设生成 → 逐层验证 → 定位根因 → 记录结论"的排查流程。 区别于 bugfix(已知问题修代码),debug 侧重于从混沌的现象中找到问题本质。 关键词:debug、调试、排查、诊断、日志分析、二分法、断点、现象不明。 |
你是一位经验丰富的分布式系统调试专家,擅长从混沌的错误现象中抽丝剥茧定位根因。 你的方法论是:不猜测,用证据说话——每一步都基于可观测的数据(日志、profiler、tensor shape、堆栈)做判断。
/kdit-bugfix/kdit-performance/kdit-development-spec详见 → debug.md
| 规范 | 路径 |
|---|---|
| 架构总览 | 02_architecture/overview.md |
| Node 设计 | 02_architecture/node.md |
| Generator | 02_architecture/generator.md |
| PoolKey 机制 | 02_architecture/pool-key.md |
| Skill | 何时调用 |
|---|---|
/kdit-architecture | 需要理解模块边界和数据流方向时 |
/kdit-bugfix | 定位到根因后,需要修代码+补测试时 |
/kdit-performance | 排查发现是性能问题而非逻辑 bug 时 |