我以前会比较自然地把工程师的工作理解成“实现”。
需求来了，分析一下，拆成模块，写代码，联调，上线。这个路径没错，但做项目越久，我越觉得，真实工作里很大一部分价值，其实不是实现本身，而是翻译。
这里的翻译，不是语言翻译，而是把不同世界里的表达方式互相转过去。
把业务语言翻译成系统结构
业务方描述需求时，通常不会直接说接口、状态机、数据模型。他们说的是业务目标、流程感受、管理要求、风险顾虑。
如果工程师只是机械地把这些话对应成几个页面和几个接口，很多时候会做偏。因为业务语言里隐藏着很多没被显式说出来的前提。
比如业务方说“这个过程要能监管”，背后可能意味着：
- 全程要有记录
- 关键节点不能跳过
- 异常要能追溯
- 后台要能看到过程信息
- 结果不能只看前端提交
这些东西如果没被翻译出来，技术实现很容易只停留在“做一个可操作流程”，但业务真正关心的其实是“做一个可信流程”。
把技术约束翻译成业务方案
反过来也一样。
很多时候技术上做不到，或者不是不能做，而是代价过高、稳定性不够、风险太大。这个时候如果工程师只是直接说“这个做不了”，其实沟通还没完成。
更有效的方式是把技术约束翻译成业务能理解的方案语言。
比如不说“这个 API 不支持并发场景”，而是说“如果坚持这个方案，录制和转写同时进行时稳定性会受影响，我们建议把实时展示和最终结果拆成两个层次，先保证留痕和结果可靠”。比如不说“前端状态太复杂”，而是说“如果这个页面同时承担确认、输入、监督三种职责，用户理解成本会明显变高，建议拆成两个阶段”。
当工程师能把技术限制转成业务判断依据，协作就会顺很多。
工程能力里，表达能力其实很重要
这也是为什么我现在越来越重视文档、方案、结构化表达这些能力。
有些人会觉得这些东西不够“硬核”，但真实项目里，很多关键决策都不是在代码层产生的，而是在代码之前就被决定了。你能不能把问题讲清楚，能不能把约束表达准确，能不能让别人理解你的判断依据，这些都会直接影响项目结果。
从这个角度看，工程师并不只是生产代码的人，也是把模糊需求和现实约束翻译成可执行路径的人。
为什么这件事在复杂业务里更明显
业务越复杂，翻译这件事越重要。
因为复杂业务往往不缺想法，缺的是把想法转成系统的能力。也不缺技术能力点，缺的是把技术点拼成业务能接受路径的能力。
尤其是 ToB 场景里，很多问题既不是纯业务问题，也不是纯技术问题，而是两边语言不一致的问题。工程师如果能在中间把这层翻译做好，很多项目推进会顺很多。
结语
现在我越来越觉得，工程师做的不只是实现，也是翻译。
把业务翻译成结构，把技术翻译成方案，把模糊目标翻译成可执行路径。很多看起来不是“写代码”的工作，其实恰恰构成了真实项目里最重要的工程价值。
代码当然重要，但在代码之前，先把事情说清楚，往往更重要。