我不是纯技术极客，也不是纯产品经理。我把自己定位为 60% 技术型 + 40% 产品型 的工程师——既理解技术的实现边界，也会追问"这东西用户会不会用、值不值得做"。
用一句话概括我的角色：掌舵者，而非划桨人。
一位机器人行业的前辈把工程师分成三类，我很认同：
我处在技术型和产品型之间。无论哪一类，我都认为沟通与写作能力和技术能力同等重要——写技术文档、定产品计划、把想法清晰表达给协作者（包括 AI 工具），靠的都是表达。
我对自己的能力有清醒的分层认知（详细清单见技能矩阵）：
精通意味着能重写 BSP、设计框架；熟练意味着能独立交付完整方案；基础意味着能评估、能协作、知道边界在哪。
从想法到可用的阶段是我最有动力的部分——技术选型、原型验证、系统架构、团队搭建。产品跑通进入维护期后，我会主动寻找下一个增长点。
我习惯从"整台机器怎么运转"的视角看问题，而不是"填一个函数"。从 MCU 固件到 Linux 系统到 OTA 方案到生产工具，习惯把链路拉通。做系统方案时，我考虑的不只是"芯片能不能跑"，还有"研发人员能不能接入、文档能不能跟上、未来换平台怎么办"。
不只问"技术能不能实现"，还追问"值不值得做"。做功能时会同步考虑安全、量产可行性和用户体验，发现原方案量产不可行时会自己推倒重来。
觉得底层方案不靠谱，就基于更可靠的根基重写，而不是修修补补凑合用。这是我反复验证过的做事方式。
消费级无人机（大疆）→ 家电（Keurig Dr Pepper）→ 新能源（正浩）→ 激光 SLAM（赛尔），每一段经历都在拓宽上下游：从只做 MCU 应用层，到接触 Linux、系统架构和团队管理。
我不只是用工具，而是拆开、理解、改造。觉得工具不够好就自己加功能、造管道，不凑合。
我认为工程问题大于 AI 本身：LLM 是万能函数，但边界在工程方法。该用就用，该脱敏就脱敏，不盲目追热潮。
技术上：
工作上：
| 情境 | 我的典型反应 |
|---|---|
| 遇到技术瓶颈 | 先查一手资料，不行就做实验验证 |
| 团队协作阻塞 | 主动介入，拉双方一起 profiling、排查 |
| 产品方向不确定 | 从技术可行性角度给建议，同时追问业务价值 |
| 重复性工作 | 造工具自动化 |
| 学新领域 | 敢上手，快速出活 |
| 现有工具不好用 | 改造它，而不是忍着 |