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

前言

最近 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

不用一蹴而就，这本就是需要时间和经验慢慢打磨的能力。