找到问题的本质在于找到本质的问题

前言

最近 VC 玩多了，回来聊聊工程问题

找到问题的本质在于找到本质的问题

这句话乍看之下是打机锋，但却是提高工程质量的一个切实方法。很多时候，真正阻碍质量提升的不是缺少答案，而是问错了问题。 一个线上接口变慢了，我们问：“怎么优化这个接口？”
这不是个好问题，应该继续追问：
1.为什么只有管理用户慢？
2.为什么只在每天 9 点半到 11 点慢？
3.为什么数据库没有变慢，但接口耗时增加了？
4.为什么缓存命中率下降没有触发告警
...

现象不是问题

工程现场最常见的误判，是把现象当成问题。 比如：页面白屏了。 此时简单的修复可能是单纯地拉长等待时间或者给个兜底值。

但如果我们继续追问：
1.是所有用户白屏，还是部分用户？
2.是首次加载白屏，还是路由跳转后白屏？
3.是前端资源加载失败，还是运行时报错？
4.是发布后立刻出现，还是某个接口返回特定数据后出现？

问题会逐渐变形，从最开始我们以为是渲染问题，逐渐会发现真正的问题，它可能是： 某个接口新增字段为 null，前端组件没有做空值防御，导致渲染阶段抛错，中断了整个应用挂载流程。 这时，解决方式也从“看看页面为什么白屏”，变成了更精确的技术动作，比如补充字段兼容逻辑，收敛接口契约，增加边界数据测试，增加前端错误隔离,后台增加数据校验等...

好问题会缩小搜索空间

比如在我最近开发的一个基于 tauri 桌面端 AI 插件里，最容易出现的一个问题就是 为什么回写结果不稳定？

这个问题太大了，整个项目成千上万个文件，它把全部可能性都混在一起，根本无从下手。

更精确的问题应该是：

为什么第三方系统调用 /api/task/assist 进入辅助模式后，用户点击“确认同步”已经产生了 record-confirmed 事件，但第三方系统回执后页面没有更新为同步成功，而且只发生在同一对象多次打开、请求里没有传 sessionId / visitId 这类唯一上下文标识的场景？

这种问题一下子就把搜索空间（上下文）缩小了。

拿这个问题举例拆解一下边界：
1 。 时间边界：用户点击“确认同步”之后，第三方系统回执之后
2. 入口边界：本地 Bridge 的 /api/task/assist
3. 流程边界：辅助模式，不是完整流程，也不是独立窗口
4. 事件边界：已产生 record-confirmed，问题只在回写阶段
5. 数据边界：同一对象多次打开、缺少唯一上下文标识
6. 排除项：不是远端模型接口、不是网络认证、不是生成响应慢
7. 可能方向：结果事件匹配、回执更新、旧会话缓存污染

此时排查链路就变得非常明确

第三方系统 /api/task/assist
→ 前端进入 AI 辅助模式
→ 用户确认同步
→ 生成 record-confirmed
→ 第三方系统处理同步内容
→ 第三方系统调用 feedback 回执
→ 桌面端按上下文 ID 更新页面状态

最后发现本质的问题是 ： 在同一对象多次打开的场景下，如果第三方系统没有传唯一上下文标识，桌面端会回退使用对象 ID 作为匹配锚点（我又来吐槽 codex 的兜底习惯了，这时候要你兜底吗！），导致不同会话共享同一个结果匹配键，旧会话的结果或回执可能误命中新会话。

于是解决方案也清晰了： 所有入口都优先传入唯一上下文标识；文档中明确“同一对象多次打开”必须传会话级 ID ；联调时用会话 ID 串起整个调用链，验证每一步的上下文 ID 是否一致。

这个挖掘过程能很好的说明一个好的问题是一个边界清楚的问题，它把“结果同步不稳定”收敛成一个可验证可修复的“没有严格透传一个会话级主键”

别猜，要体系化地追问

我刚入行时，我领导经常教育我，排查问题别靠猜，后来我把他的排查思路固化成一个实用的追问模型，这里直接用 gpt 生成一个图片来解释，大家可以拷贝去多看多想：

⚠️ 与 ✅

技术判断中有三个危险信号

第一 问题描述里只有情绪，没有量化事实，例如：
很慢/老是失败/不稳定
这类描述需要被指标化：
从原先耗时多少到现在耗时多少，慢了多少
失败率有多少
什么场景下必现失败
与哪个版本对比

第二 过早给出原因
肯定是数据库问题/应该是缓存没生效/可能是网络抖动
经验有价值，但经验也会制造偏见。更稳妥的方式是把判断写成假设，然后验证它。

第三，只问“怎么修”，不问“为什么存在”。
如果一个问题反复出现，说明它不是单点问题，而是系统机制问题。
比如重复出现字段兼容 bug ，真正要做的可能不是继续补判空，而是建立接口契约、类型生成、mock 数据、回归测试和灰度验证。

一个判断本质问题的标准

在工程里，一个问题是否接近本质可以看它是否满足以下三点：
1.能解释当前现象
2.能预测类似现象
3.能指导结构性改进

举个后端同学常见的例子：
这次接口慢是因为 SQL 没加索引
但更本质的问题是：
当前没有针对高频查询建立性能基线和索引评审机制，导致数据量增大后性能风险只能在线上暴露。
前者解决当前故障，后者还能避免后续发生

结语

定义一个问题在当下更是一个核心能力，这篇文章希望能对大家后续日常编程或者 VibeCoding 时有帮助，前者省时，后者省 token
不用一蹴而就，这本就是需要时间和经验慢慢打磨的能力。