我kankan，这个有点诡异，stacktrace 里有个 NPE，但又不是必现的，我还在kan一下是不是路由的问题。

说实话，hen多技术同学写代码挺溜的，但一到汇报就有点懵。要么把领导拉进 条日志里要么就含糊其辞一句“还在排查”。汇报不是给领导上课，geng不是写一篇报告。它是一种把信息压缩后传递给决策者的协作动作。咱就是说搞不好你再厉害，也得被当成“不知道怎么把问题讲清楚”的开发者。

所以啊，别把汇报当成是给自己找乐子的地方。它其实是为了让大家geng快地了解情况、Zuo出决策、解决问题。这跟咱们写代码一样，要注重效率和质量。

// 向上汇报问题与方案模板 订单服务代码耗子高，近三月 例行需求平均延期 周 原因：核心模块 X 耗子高。 本季度还有3个重点项目调起源 按现在进度会延期到 Q4。 A. 全量重构：智人月11台， 风险高，不推荐。 B. 分模块重构：先拆 X， 智人月5台，可启动，推荐。 C. 不动：延期会持续加剧，不推荐。 需下周一前确认 B 方案。 需启动 5个人智，占 sprint %。

// 阶段任务汇报模板@总体状态 主线任务 按期 / 有风险 重点判断：还Neng守住领导关心的 延期 那个里程碑@本周交付 • 可证明的东西：上线、发版、PR 联调通过、问题闭环 • 用数字 / 链接证明事实@下周重点 三条以内，带 owner 和 ddl@风险与诉求 需领导推动的事单独列出 没诉求也要明说“无”

讲完场景后跳出来kan，会发现它们共享三个底层原则：别停在代码层。一个招：五问五答。

打字发给领导前，逋一遇这五问：hen多技术同学写代码hen猛，一到汇报就卡壳。要么把领导拉进条日志里要么只丢一句"还在排查"。汇报不是答辩，geng不是写作文。

**反例**：“stacktrace kan起来是 NPE，调用链走的是 A 服务调 B 服务，B 服务返回了 null，但 A 没处理。我现在在kan A 的代码。”

**Q3：为什么 B 这次返空了？A3**：B 上周发版加了限流，限流后返空。

红线二：不讲评价、只讲事实与动作。“Neng力不够”“不Neng担主力”这种话不要轻易说领导听了会担心你的判断力。说事实：“近三个项目里负责的模块dou被接手”，领导自己会下结论。

现状怎么样

下一步要怎么走

需不需要他推动资源

hen多人Zui大的毛病在于习惯从自己的角度出发去汇报

换个思路想想 ,你的目标不是炫技,而是帮助别人geng好地理解情况