上一篇：30-1《文章矩阵：三层漏斗与互相引用》｜ 下一篇：30-3《结营：30 天之外——同态加密内核与论文预告》
源码精读篇：本文为源码/方法论精读，无独立实测；文中数字均引述仓库 docs 的板端实测记录
一句话导读：推理引擎贡献指南：一个工程仓库的寿命取决于协作回路——讲 Issue 要带哪些字段作者才能复现、复现数据为何比复现结论更有价值，以及报告你发现的坑为什么是贡献而不是冒犯。
关键词：手搓推理引擎、大模型推理、贡献指南、Issue、复现数据、协作回路
一个工程仓库的寿命取决于协作回路：作者发布 → 使用者跑 → 使用者反馈 → 作者修。本篇讲反馈端怎么写得专业：Issue 要带哪些字段作者才能复现、“复现数据"为什么比复现结论更有价值、以及"报告你发现的坑”（bug/口径不符）为什么是贡献而不是冒犯。仓库的入口在 README 联系区（220–227 行），docs 清单是反馈的"背景资料"。
1. 知识点：好 Issue 的"可复现三件套"
作者收到一条 Issue，第一反应永远是三个问题：你跑的是什么？你给了什么参数？你看到什么？好 Issue 自带答案：
| 字段 | 内容 | 为什么作者需要 |
|---|---|---|
| 环境 | 板型 / 架构 / 编译方式 / 源码 commit | 29-2 的教训：行为随板画像切换 |
| 复现步骤 | 完整命令 + 模型目录 + 参数 | 缺一步就无法本地复现 |
| 期望 vs 实际 | 你期望什么、实际得到什么（日志贴原文） | 定位是"行为偏差"还是"口径没对齐" |
再加一条最高价值的：你对照 docs 做了什么——因为很多"bug"其实是"文档口径没读全"（28-3 复现差异、25-2 的摘要口径都是这类）。Issue 里先写"我按 docs/xxx 的第 y 节做了 z，结果与文档不符"，作者一眼就能判断是文档 bug、代码 bug 还是操作偏差。
2. 对应代码/文档：反馈回路的两端
输入端（使用者）：README 联系区（220–227 行）——商业授权 / 研究合作 / 复现数据：398152090@qq.com，或 Issues。复现数据请求在 README 里与商业授权并列，说明"复现你的报告"是作者认可的正式诉求（28-3 的附录也声明可按表结构自建或联系作者）。
接收端（作者侧）：docs 四件套就是排障手册——技术文档.md（架构/模块/调试）、RK3588_性能基准报告.md（数字口径）、优化配置与边界说明.md（优化档与边界）、权重保护与可验证推理方案.md（安全防线）。一个规范的 Issue 会在标题写清模块（如[vqf]/[attest]/[bench]），正文引用对应 docs 章节与源码文件——把 Issue 写成一份"微型复现报告"，而不是一句"跑出来不对"。
3. 改动后果：三类反馈的分诊
| 反馈类型 | 例子 | 正确的接法 |
|---|---|---|
| 真 bug | 25-2 的 digest mismatch | 复现 → 定位 → 修复 → 更新 docs（本系列 Day 25 实录） |
| 口径偏差 | “复现不出 2.0s”（实为默认档 vs 优化档） | 先查配置档与 docs §0 复现环境，多数在此解决 |
| 文档不清 | header_canonical 定义漏了 flags 位 | 修文档（这也是真贡献！25-2 的根因就是文档口径不全） |
"报告你发现的坑"为什么是贡献：真 bug 帮作者修代码，文档不清帮作者修文档，口径偏差帮作者知道读者在哪一步摔跤——三类反馈都让下一个使用者少踩一次坑。对比夸赞（Star、转发）带来流量，但只有Issue能带来修复——30-1 说留存层看 Issue/邮件，就是这个原因：它们是"仓库还活着"的运营证据。
4. 学员调试任务
- A 档（动手）：写一条模拟 Issue（不必真的提交到 Gitee，本地存档即可），主题任选：① 你在复现 Day 28 报告时与报告数字有出入；② 你发现某篇教程/docs 的表述与源码对不上；③ 你复现了某个崩溃。按"环境 / 复现步骤 / 期望 vs 实际 / 对照的 docs 章节"四段写，然后自评：作者拿到它能否不追问就复现？
- B 档（思考）：回答：① 为什么 Issue 要写"你对照 docs 做了什么"而不是只写"报错了"？② "复现不出 2.0s 冷启动"这类 Issue，作者最可能先回复什么？（提示：28-3 的配置档/口径差异）③ 你发现文档 bug 但代码是对的，这条 Issue 值不值得发？为什么？（提示：25-2 的 header_canonical 教训）
预期输出：一条四段式模拟 Issue + 三题思考答案，能讲清"反馈回路的质量决定仓库寿命"。
收尾
- 本篇文档点名：README.md（联系区 220–227）、docs/（排障手册清单）
- 开源仓库：Kestrel-LLM (Gitee)（AGPL-3.0-or-later 或商业许可，二选一）
- 下篇预告：最后一篇：30 天之外还有什么？——一个与明文引擎共享基础设施的同态加密研究内核（RNS-CKKS）作为论文预告；以及结营时必须诚实复述的"30 天口径"。
)
