本文へ移動
cccskills
無料GitHub で公開

retrospective

任务完成后的反思与经验沉淀。仅在任务非平凡且出现调试、失败修复、反复试错、明显误判或可复用教训时使用;简单执行、查询、常规 CI 通过等无新增经验的任务可跳过。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

任务反思与经验沉淀

触发条件:非平凡任务完成后,且存在可沉淀经验:debug、失败修复、反复试错、明显误判、流程缺口,或用户显式要求。

跳过条件:简单执行、查询、格式调整、常规 CI 通过等没有新增教训的任务,无需执行此 skill。

服务对象:所有 skill。本 skill 的产出是对其他 skill 文件的更新,不产生代码。

核心原则

🚨 对结果要有定力,不要自我欺骗

最大的风险是"觉得差不多了"的幻觉——结果不达标时,找外部原因搪塞然后降低要求宣布完成。

常见的自我欺骗模式:

  • 功能任务:输出不正确时归因于"量化精度不够"、"模型太小"、"这是预期的退化",而不是继续排查实现 bug
  • 性能任务:优化没有效果时归因于"编译器已经优化得很好了"、"已经接近理论极限",而不是继续尝试其他方案

正确做法:

  • 测试目标在开始前就定好,不能中途降低标准
  • 通过标准必须具体、可验证("差不多能用"不算通过)
  • 功能任务:人工验证不通过就是没通过,继续排查实现细节
  • 性能任务:没有达到预期提升就继续优化,用数据证明已到极限而不是猜测

TDD 思维:先定测试再写代码

每个子任务开始前明确三件事:

  1. 通过标准是什么? — 具体的预期输出
  2. 怎么测? — 可执行的测试命令
  3. 什么不算通过? — 明确列出容易自我欺骗的边界情况

执行流程

1. 识别教训

  • 走了哪些弯路?错误假设是什么?
  • 根因是什么?为什么没有第一时间找到?
  • 方法论问题?跳步了?过早下结论了?把 bug 归因为外部原因了?

2. 判断归属

教训类型更新位置
某个 skill 流程中的陷阱该 skill 的 common-pitfalls 或步骤文件
通用工作方法论该 skill 的 SKILL.md 顶层注意事项
跨 skill 通用经验memory 系统

3. 写入原则

  • 只写方法论,不写单次任务的具体细节。 可以附最小测试示例说明如何验证。
  • 放在最显眼的位置。 关键教训放 SKILL.md 顶部,不要埋在子文档末尾。
  • 增加的同时审视现有内容。 显而易见的、能从代码直接推出的指导删掉或精简。单个步骤文件不超过 500 行。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

为 MNN 框架新增算子。包含 Schema 定义、形状计算、几何计算、后端实现、单元测试的完整 TDD 流程。分 5 步执行,每步有独立测试标准。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

bugfix

無料

MNN 各类正确性/回归 bug 的排查入口,按 bug 类别分册组织,本文件只做症状分流。分册:内存别名与生命周期(arena reuse、`MemChunk`、融合引入的别名竞争)、量化误差与导出侧权重损坏(低 bit 打包、导出分块、PyTorch MPS/CUDA 大张量静默错误)、host 侧并发/线程竞争(共享所有权的引用计数被写坏、析构链崩溃、TSAN A/B 与编译期哨兵)、fp16 表示能力不足(长序列复读、position 塌缩,以及「实时计算→预计算查表」重构的三类陷阱)、GPU shader 越界与 command buffer 故障、后端 kernel 隐式假设违反(causal mask、layout 约定)、持久化缓存误信(weight-mmap sync 自我污染、跨模型缓存复用)、逐 run 不同的非确定性(未初始化内存/堆垃圾依赖、多线程动态分发×异构 kernel)。用户报告 MNN 输出乱码/退化、单测或 golden 对不上、改动后回归、换后端结果不同、开某开关才错、结果每次跑都不一样、或崩在析构链上且只在后台线程异步释放时偶现时使用。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

cpu

無料

MNN CPU 后端(ARM / x86_64 / RISC-V 三侧)的总入口,只做分流不承载技术内容。下分 `optimize/`(为什么慢、该改哪一层)与 `kernel/`(这条 kernel 怎么写对、怎么被选中)两个分支,`shared/` 放两者共用的构建测试跑分命令、env 开关注册表与 RISC-V 开发板远端验证纪律。做 CPU 侧的工作但还不确定该进哪个分支,或需要三侧结构差异对照(第二张函数表按什么分、二级表怎么构造、`Precision_Low` 语义、ISA A/B 怎么做——「三侧不同构对照表」全树唯一一份,就在本文件)时读这里。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

MNN CPU 后端 kernel 开发分支(`skills/cpu/` 下,另一分支是 `cpu/optimize` 性能归因)。覆盖标量 oracle → C++ SIMD → intrinsic → 汇编的四级实现阶梯、pack/kernel ABI 契约(tile、cell stride、后处理参数)、CoreFunctions 派发表注册与二级表安全构造、跨 ISA × 精度的正确性门禁,以及 AArch64 / x86_64 / RISC-V 三份实现参考。为 CPU 后端新写或移植 kernel(NEON / SSE / AVX / RVV intrinsic 或 .S 汇编)、新增一层 ISA、改 pack mode 或 tile 参数、把 kernel 挂进函数表时使用。已定位到 kernel 才进本分支。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

MNN CPU 后端性能归因分支(`skills/cpu/` 下,另一分支是 `cpu/kernel` kernel 开发)。按五层(Runtime 线程 / Executor 调度 / Layout 内存 / Dispatch 函数表 / Kernel ISA)定位瓶颈,含 bound 类型判定、op 级实验回路、跨框架 op 对 op 对比、跨层不一致的事后定位,以及 ARM / x86_64 / RISC-V 三侧「我到底跑在哪条 ISA 路径上」的诊断面。CPU 上算子或 LLM prefill/decode 慢、线程数或内存占用异常、出现性能回归、要与外部推理框架逐算子对比时使用。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

MNN Hexagon/HVX/HMX DSP 后端(`source/backend/hexagon`)的优化、重构、构建与回归验证。覆盖设备实测的相位分解、测量纪律、v79/v81 双架构差异、常见瓶颈模式、已否证方向与 cDSP crash 诊断。

日本語の概要は準備中です。原文の説明を表示しています。

alibaba/MNN1.6万2026年10月12日 更新

alibaba のスキルをすべて見る

このスキルの問題を報告する