Pull Request已成功合入, 合并人@CANN-robot
（感谢 sijiaali 的贡献）
sijiaali
Hi @sijiaali, welcome to submitting your first PR to cannbot-knowledge!
PR Merge Steps
1. CLA Signing
If the current PR label includes cann-cla/yes, it means you have signed the CLA and can proceed to the next step. If the label includes cann-cla/no, please sign the CLA first. If you have any questions, please refer to the FAQ.
2. CI Check
Please comment /compile to trigger the CI pipeline check. If the CI run is successful, the PR will be tagged with ci-pipeline-passed and you can proceed to the next step. If the CI run fails, the PR will be tagged with ci-pipeline-failed, please check the CI logs to fix the issues in the PR. If you have any questions, please refer to the FAQ.
3. Code Review
After CI passes, please refer to the PR Approval Progress and proactively @ the committers in the table to review the code. After approval, committers will comment /lgtm and /approve. Once the lgtm and approved labels are successfully added, the PR will be merged automatically.
Thanks for your pull-request.
The full list of commands accepted by me can be found at here.
You can get sig-info at here.
You can self-configure the PR merge rules for this repository. For more details, please refer to Here.
For more, you also can visit HICANN.
PR Approval Progress
✅ Congratulations! All modules have met the lgtm and approve requirements.
Module Approval Details
| module | lgtm status | approve status |
|---|---|---|
| repo-cann/cannbot-knowledge | ✅ wangsj0012, qq_41667743 (2/2) | ✅ wangsj0012 (1/1) |
💡 Tip:
- Committer can comment
/approveor/lgtm- Commenting
/approveimplies both code review (lgtm) and intent to merge (approve)
CLA Signature Pass
sijiaali, thanks for your pull request. All authors of the commits have signed the CLA. 👍
/check-cla
CLA检查已通过，详情可参考这里
整体看了一遍，check.sh 是绿的，schema、来源链接可达性这些硬门槛都没问题。有几处个人觉得值得修一下的地方，返修后合入应该没问题，供参考：
-
Playbook 的 description：以 a1_fp32_intermediate 为例，description 只有一句「本 Playbook 为强制流程」，没有主题信息——description 是检索主键，这句话检索时等于空。我粗看了一下，好像不少 Playbook 都是这句模板，index 的导航摘要也一并被带成这句了。建议统一改写成「做什么、适用什么场景」的一句话，可以复用对应策略卡的 description。
-
platforms 与正文：d5_bf16_special_handling 这张，frontmatter 标的 a2，但正文写了 910B/910_93/910_95/310P/kirin 多个平台的差异行为。按仓里的约定 platforms 应该只填实际验证过的，或者把未验证的标注为可迁移推断。类似的卡（比如 p108，整卡就是按 NpuArch 在 A2/A3/950 之间路由）可能也有同样情况，建议顺手过一遍。
-
交叉引用：p120 里写「退回 P42/P39 向量化（判定见 P13）」，我查了一下全集里没有 P39 这张，P42 和 P13 还都是 deprecated 状态，stable 卡把读者导向不存在和已废弃的策略，容易误导。另外还有引用 references/discovered/disc_X17~X20 这种不在仓里的路径（p128~p131 一带），以及 p53 把 P18 写成 P17 的小错，建议一起核一遍引用。
-
p9 疑似拼接错乱：标题和核心思想讲的是多核确定性输出，但代码骨架贴的是双输出量化的读写代码，「关键修改点」里又只有一句预期收益，感觉像是上游原卡内容拼接错了，建议回源仓核对一下。
另外几条小建议：deprecated 的十几张卡（p6/p13/r1-r8 等）建议在正文里补一句废弃原因或去向；L1 常驻复用那个主题 p18/p53/p83 三张有些重叠，建议互链说明下取舍；「专家实现」「lingxi-code」这类内部称谓出现在不少文件里，迁入公共库的话建议换成可公开溯源的说法；PR 描述里的数字和 log 日期跟实际 diff 对不上（实际是 308 新增 + 2 修改），也请顺手更新一下。
最后顺便确认一个口径：contrib/ascendc/runbooks 这批卡需不需要遵循 ops/runbooks 的正文契约（适用场景节、验证信号标平台和证据等级）？目前 lint 好像不扫 contrib，存量卡也没有这个节，不确定是盲区还是有意豁免，想听下维护者的说法，方便后续批次对齐。
整体看了一遍，check.sh 是绿的，schema、来源链接可达性这些硬门槛都没问题。有几处个人觉得值得修一下的地方，返修后合入应该没问题，供参考：
Playbook 的 description：以 a1_fp32_intermediate 为例，description 只有一句「本 Playbook 为强制流程」，没有主题信息——description 是检索主键，这句话检索时等于空。我粗看了一下，好像不少 Playbook 都是这句模板，index 的导航摘要也一并被带成这句了。建议统一改写成「做什么、适用什么场景」的一句话，可以复用对应策略卡的 description。
platforms 与正文：d5_bf16_special_handling 这张，frontmatter 标的 a2，但正文写了 910B/910_93/910_95/310P/kirin 多个平台的差异行为。按仓里的约定 platforms 应该只填实际验证过的，或者把未验证的标注为可迁移推断。类似的卡（比如 p108，整卡就是按 NpuArch 在 A2/A3/950 之间路由）可能也有同样情况，建议顺手过一遍。
交叉引用：p120 里写「退回 P42/P39 向量化（判定见 P13）」，我查了一下全集里没有 P39 这张，P42 和 P13 还都是 deprecated 状态，stable 卡把读者导向不存在和已废弃的策略，容易误导。另外还有引用 references/discovered/disc_X17~X20 这种不在仓里的路径（p128~p131 一带），以及 p53 把 P18 写成 P17 的小错，建议一起核一遍引用。
p9 疑似拼接错乱：标题和核心思想讲的是多核确定性输出，但代码骨架贴的是双输出量化的读写代码，「关键修改点」里又只有一句预期收益，感觉像是上游原卡内容拼接错了，建议回源仓核对一下。
另外几条小建议：deprecated 的十几张卡（p6/p13/r1-r8 等）建议在正文里补一句废弃原因或去向；L1 常驻复用那个主题 p18/p53/p83 三张有些重叠，建议互链说明下取舍；「专家实现」「lingxi-code」这类内部称谓出现在不少文件里，迁入公共库的话建议换成可公开溯源的说法；PR 描述里的数字和 log 日期跟实际 diff 对不上（实际是 308 新增 + 2 修改），也请顺手更新一下。
最后顺便确认一个口径：contrib/ascendc/runbooks 这批卡需不需要遵循 ops/runbooks 的正文契约（适用场景节、验证信号标平台和证据等级）？目前 lint 好像不扫 contrib，存量卡也没有这个节，不确定是盲区还是有意豁免，想听下维护者的说法，方便后续批次对齐。
- Playbook description：101 份占位 description（"本 Playbook 为强制流程"等两种模板）已全部替换为对应策略卡的真实 description；其余 41 份已有具体描述的不动。索引摘要随 sync-indexes 一并更新。
- platforms：口径按约定收紧——frontmatter 只保留实测平台 a2；正文涉及其他平台的容量值/阈值/路由描述逐处补「跨平台参考值 / 可迁移推断，未实测」注记，d5、p108 及同类共 10 处。
- 交叉引用：p120 的「退回 P42/P39（判定见 P13）」改指现存有效卡 P102/P94/P95；p128-p131 的 references/discovered 仓外路径已改为仓内相对链接（X 系列 89 卡已随本 MR 迁入 optimizations/evolution_strategies/discovered/）；p53 的 P17
笔误已改 P18。全集已无不存在的引用目标。 - p9 拼接错乱：确认是上游原卡错乱，已以其 Playbook 为权威来源重建正文。排查同类问题时发现 p8 同样错乱（标题 UB 分区、内容 BF16 中间计算），已一并重建。
- deprecated 去向：13 张全部补废弃原因；P6→A2、P42→P85、P82→P19、R6→P68 另补 replaced_by 指针。
- p18/p53/p83：三卡已互链并写明取舍（P83 通用判定框架 → P18 MLA 7-buffer 配方 → P53 单 buffer 最小形态）。
/compile
| 🚀 CI 流水线已启动 |
|---|
| 📋 执行详情: 点击查看流水线 |
/approve
Pull Request 说明
变更说明
knowledge/contrib/ascendc/optimizations/evolution_strategies/（161 卡，10 个主题 section + 各级 index.md）knowledge/contrib/ascendc/runbooks/performance/（142 Runbook + index.md）knowledge/contrib/ascendc/index.md、optimizations/index.md（补直接子级导航）logs/2026-10-10.md变更记录变更类型
验证