5 minute read

12 月问题总结（个人反思记录）

一、表层现象：我每天在处理什么

12 月的大量精力，并没有花在真正的技术演进上，而是反复消耗在：

  • 反复解释已经讨论过、已经留痕过的技术结论
  • 为历史方案“背锅”，被用当下标准否定过去决策
  • 修复或兜底并非由我决策、但由我承担后果的方案
  • 在会议中面对明显的双重标准（同样的事，H5/PC 有价值，SDK 没价值）
  • 为不合理的排期、判断失误、风险低估进行加班式补救
  • 将大量精力投入到“解释为什么不能这样做”，而不是“做正确的事”

整体感受是：高消耗、低成就感、强烈的无力与疲惫。

二、核心矛盾：不是技术问题，而是结构问题

这些问题并非偶发，而是长期稳定出现，背后有清晰的结构性原因：

1. 专业深度与决策权严重不匹配

  • 我承担的是 SDK / 移动端系统级复杂度和风险
  • 决策者对移动端、SDK 的工程复杂度缺乏理解
  • 却仍然在 缺乏细节理解的情况下直接做方向性判断

结果是：

  • 认知不足的一方做决策，
  • 认知充分的一方承担后果。

2. 技术评价体系存在“否定闭环”

在方案讨论中，形成了一个对我无解的评价逻辑：

  • 领导 自认为懂的部分 → 被评价为“简单、没水平”
  • 领导 不懂的部分 → 被评价为“不重要、没意义”

这导致一个事实：

  • 无论我方案质量如何，结论都可以被否定。
  • 这已经不是技术讨论，而是权力驱动下的价值否定。

3. SDK 的“防灾型价值”在组织中被系统性低估

SDK 的大量工作属于：

  • 稳定性
  • 兼容性
  • 屏幕 / 生命周期 / 容器适配
  • 风险兜底
  • 灰度与回滚
  • 系统边界治理

这些工作的特点是：

  • 做对了 → 什么都没发生 → 看不见
  • 做错了 → Crash / 黑屏 / 事故 → 全面背锅

而当前组织更倾向奖励：

  • 可展示的功能
  • 易讲述的目标
  • 有“新意”的概念

这导致：

SDK 的正确工作方式，与组织的价值识别体系不匹配。

三、具体事件反映的问题模式

1. 历史方案被“事后审判”

  • 三年前基于安全优先、设备能力限制设计的二维码方案
  • 当时已明确二维码长度与识别率的技术边界

且为共识方案

如今在业务目标变化后，被直接评价为“方案差劲” 问题本质不是方案错误，而是：

用当下目标，否定历史约束下的专业取舍。

2. 技术目标的双重标准

  • H5 / PC 提“屏幕适配” → 有价值、有意义
  • SDK 提“屏幕 / 容器 / 适配治理” → 没价值、没意义

说明：

评价并非基于问题本身，而是基于“谁在提”。

3. 对 code review、重构、系统性治理的轻视

  • Code review 被视为形式，而非系统级风险控制
  • 重构被理解为“一次性行为”，而非长期演进
  • 编码速度被错误地视为开发瓶颈
  • SDK 的系统复杂度被类比为前端业务复杂度

这导致：

长期技术债被忽视，直到集中爆雷。

四、对我个人的影响

1. 情绪与心理层面

  • 明显感到疲惫、心累、难过
  • 对解释方案产生抗拒
  • 对“被理解”“被认可”不再抱期待

需要刻意压制情绪，才能维持专业输出

2. 专业状态的变化

  • 开始思考是否需要降低情绪投入
  • 开始意识到“认真 ≠ 被尊重”
  • 开始反思：当前环境是否值得长期消耗自己

清楚感知到：这不是短期问题，而是结构性问题

五、阶段性结论

  • 问题不在我的技术能力，也不在方案质量
  • 当前环境对 SDK / 移动端系统工程的理解和尊重严重不足
  • 我正在承担一个“高风险、低话语权、低认可”的位置
  • 长期处在这种结构中，会持续消耗专业自信和热情
  • 需要开始有意识地：
    • 降低情绪投入
    • 做好专业留痕
    • 保护自己的技术判断力不被磨掉

六、给未来自己的提醒

  • 不要再试图用“把事情做得更好”来换取理解。
  • 在不对等的认知结构中，专业只会被当作阻碍。
  • 要开始为“自己的人生和精力”做风险控制。