本文是「学习方法与效率」系列第 1 篇，用 20 个问题拆解业务与技术之间的翻译，覆盖需求、指标、SLA、领域模型和取舍。可按目录跳读。
Q1. 什么是业务到技术的翻译能力？
业务到技术的翻译，是把模糊的业务目标拆成可执行的技术方案、数据口径和验收标准。它不是把需求原话转给开发，而是补全背景、边界、约束和度量。
翻译的产物通常包括领域模型、接口、状态流转、数据表、指标定义和风险清单。业务听得懂，技术也做得出来。
项目里业务说“提升复购”，我要翻译成新老客分层、复购周期、触达渠道、实验指标和系统改造点。翻译能力决定需求落地会不会变形。翻译要做到三件事：业务听得懂、技术做得出、上线能验证，缺一项都会在落地时走样。
Q2. 拿到模糊需求，第一步做什么？
第一步不是写代码，而是确认问题、目标和边界。要问清楚谁遇到问题、发生在什么场景、现在怎么解决、期望变成什么样。
然后确认不做什么、什么时候要、成功怎么衡量。模糊需求最怕直接开工，做完才发现方向错了。
项目里我会先写一页需求理解，列出目标、范围、假设、风险和待确认项，再和业务逐条对齐。把模糊点显性化，是翻译的起点。待确认项要写清负责人和截止时间，不要用“大概”“应该”推进，清单要逐条关闭，关闭前不开工。
Q3. 怎么把业务目标拆成技术指标？
先把业务目标拆成可观测的用户行为和业务结果，再落到系统指标。比如“提升下单体验”可以拆成下单转化率、下单耗时、支付成功率和客诉率。
技术指标要能采集、能归因、能对比。转化率对应埋点和漏斗，耗时对应链路监控，成功率对应错误码和支付回调。
项目里每个目标至少配一个业务指标、一个技术指标和一个 guardrail 指标。指标口径要写清楚，否则上线后各说各话。指标还要能拆到可行动的最小单元，比如转化率下降能定位到步骤、渠道和人群。
Q4. 业务说“快”，怎么翻译成 SLA？
“快”要先拆成谁在什么场景下等多长时间。用户点击到首屏、下单到支付、报表生成到返回，标准完全不同。
然后把感受翻译成可测指标，比如首字延迟、P95 响应时间、批处理完成时间。再定目标值、统计窗口和降级策略。
项目里我会把“快”写成“核心接口 P95 小于 300ms，首字延迟小于 1s，超时降级返回缓存”。没有数字的“快”不是需求。SLA 还要写统计口径、采样方式和排除项，否则无法验收，而且要能监控。
Q5. 业务说“稳”，怎么翻译成可用性？
“稳”要拆成可用性、数据一致性、故障恢复和容错能力。可用性用 SLA 表达，比如 99.9% 或 99.99%，对应每年允许的停机时间。
还要定义故障等级、恢复时间 RTO、数据恢复点 RPO，以及降级时哪些功能可以牺牲。不同业务对“稳”的要求不同。
项目里交易链路按高可用设计，报表可以容忍短时不可用。把“稳”翻译成具体等级和降级预案，才算可执行。可用性不是越高越好，每提升一个 9，成本可能翻倍，要和业务收益匹配。
Q6. 怎么识别需求中的真实问题和伪需求？
先问需求背后的目标，而不是直接接受方案。业务说“要加一个按钮”，真实问题可能是流程太绕、找不到入口或权限不对。
可以用五个为什么、用户访谈、数据验证和现场观察。看用户实际怎么做，而不是只听他们怎么说。
项目里我会区分“用户提出的方案”和“用户遇到的问题”。能解决真实问题的简单方案，往往比复杂功能更有价值。伪需求常来自模仿竞品或个别声音，要用数据和场景验证，验证不了就先做小实验，小实验比争论便宜。
Q7. 怎么和业务对齐术语？
业务和技术对同一个词常有不同理解，比如“订单”“用户”“活跃”“退款”。要先建术语表，写清定义、口径和边界。
术语表要覆盖同义词、反义词和易混淆概念。评审时遇到歧义，停下来对齐，不要带着假设往下做。
项目里医疗场景的“科室”“机构”“指标”都有多种口径，必须先统一字典再开发。术语对齐是翻译的基础设施。术语表要进知识库，新人和新系统引用同一份，评审前先对齐能省一半沟通；术语表还要有人维护。
Q8. 怎么把业务流程画成领域模型？
先画业务流程，标出角色、动作、状态和异常分支。再把名词抽成实体，把动词抽成服务或状态转移。
领域模型要能回答：谁创建、谁修改、什么状态、什么条件下流转、失败怎么办。不要一开始就画数据库表。
项目里订单从创建、支付、发货到完成，每个状态都要有事件、守卫和补偿。领域模型对了，表结构和接口才不会反复改。画模型时先别考虑数据库和框架，先把业务语言表达清楚，再谈实现。模型要经得起业务追问，追问就是验收。
Q9. 怎么把业务规则落到状态机和表结构？
业务规则先写成“当什么条件满足时，允许什么动作，产生什么结果”。再把规则映射到状态、事件、守卫和副作用。
状态机适合流程固定、需要审计的场景；表结构要支持状态、版本、时间和操作人。规则不要散落在 if-else 里。
项目里审批、订单和工单都用状态机表达，表里存状态和版本号，流转时校验前置状态。这样规则可测试、可回放、可审计。状态机要覆盖非法流转和重复提交，表结构要留版本和审计字段，规则要能配置，不能写死。
Q10. 怎么处理业务口径冲突？
口径冲突通常来自部门目标不同、统计范围不同或历史定义不同。先让各方把定义写下来，再逐项对比差异。
差异要落到字段、过滤条件、时间窗口和去重规则。能统一的统一，不能统一的就分口径并注明适用范围。
项目里两个报表对不上，我会先查订单状态、退款口径和时间窗口，而不是先改数据。口径冲突本质是组织问题，技术只能提供证据。先对齐目标，再对齐定义，最后才讨论数据，顺序反了会陷入细节争论。口径要对齐到能签字，否则会反复。
Q11. 怎么把技术限制翻译回业务语言？
不要对业务说“做不了”，要说“在当前约束下，做到什么程度需要什么代价”。把限制翻译成时间、成本、风险和替代方案。
比如高并发下强一致做不到，可以解释为“峰值时可能看到几秒延迟，但不会丢单”。业务才能判断是否接受。
项目里我会给业务三个选项：快但功能少、全但周期长、稳但成本高。让业务在信息充分的情况下做取舍。翻译限制时要给替代方案和时间成本，业务需要的是选择，不是拒绝。方案要能比较，代价要写清，不能只说不。
Q12. 怎么评估需求的技术成本？
技术成本包括开发、测试、联调、部署、运维和后续维护。要拆到模块和依赖，识别不确定性和外部依赖。
可以用故事点、人天或 T 恤码估算，但要说清假设。新技术和新链路要留缓冲，不能按最乐观情况排期。
项目里我会把成本拆成“确定要做”和“可能踩坑”两部分，并标出需要调研的点。成本评估不是报一个数，是暴露不确定性。估算要留缓冲，尤其是新依赖、新链路和跨团队协作。假设要写下来，估算要标不确定性，方便复盘，要留缓冲。
Q13. 怎么给业务排优先级？
优先级要看业务价值、紧急程度、实现成本、依赖关系和风险。可以用 RICE、MoSCoW 或简单的价值/成本矩阵。
不要所有需求都标 P0，也不要把“谁声音大”当优先级。要让业务参与排序，并明确取舍。
项目里我会把需求分成必须做、应该做、可以做和暂不做，并说明每个档位的理由。优先级是资源配置，不是情绪排序。要能解释为什么做 A 不做 B，资源有限时，不做也是决策。取舍要记录，方便复盘，要记取舍，要能解释，要能复盘。
Q14. 怎么把非功能需求翻译成架构约束？
非功能需求包括性能、可用性、安全、合规、可维护性和成本。要先把它们量化，再映射到架构决策。
比如“支持万级并发”要落到连接数、线程模型、缓存、限流和压测目标；“数据不能出内网”要落到部署和网络架构。
项目里非功能需求会写进设计文档的约束章节，作为选型和评审依据。没有约束的架构图只是示意图。约束要写成可验证的条款，比如并发数、保留期限和恢复时间，评审时逐条确认，不能只写形容词，要能验证，要逐条评审。
Q15. 怎么用原型帮助业务确认需求？
原型可以是一张流程图、一个可点击页面或一个假数据接口。目的是让业务看到具体交互，而不是在抽象描述上争论。
原型要聚焦关键路径和边界，不要一开始做全量。确认后再投入正式开发，避免返工。
项目里我会用低保真原型对齐流程，用假数据验证字段和状态，再决定是否进入开发。原型是沟通工具，不是交付物。原型要明确验证什么问题，有时间盒，验证完记录结论和下一步，验证完就停，不要无限迭代，要有时间盒，也要能丢弃，要能停。
Q16. 怎么处理业务临时变更？
先判断变更是修正错误、补充遗漏还是新增范围。修正和补充可以走快速通道，新增范围要走变更评审。
变更要评估影响：排期、成本、风险、已完成的代码和数据。不能口头答应，事后让技术背锅。
项目里变更会记录原因、影响和决策人，能延期的延期，能拆分的拆分。临时变更不可怕，失控才可怕。变更要有唯一入口和记录，影响评估要包含数据和回滚，频繁变更说明需求没想清。变更要从源头治理，不能只靠加班，也要复盘变更频率，要复盘。
Q17. 怎么把数据指标翻译成埋点？
先定义指标口径，再拆成事件、属性和上报时机。事件要覆盖用户行为、系统结果和异常，属性要能支持分群和归因。
埋点要统一命名、版本和校验，避免重复上报和漏报。上线前要验收，上线后要监控数据量。
项目里下单漏斗会埋曝光、点击、加购、下单和支付，每个事件带用户、商品、渠道和实验分组。埋点是指标的原材料。埋点要版本化，字段变更要兼容旧报表，缺失和重复要告警。埋点要和业务对账，要验收，要能追溯，要抽样，要能对账。
Q18. 怎么在评审中暴露假设和风险？
评审不是展示方案，是找问题。要主动列出假设、依赖、取舍和风险，让评审人挑战。
可以用“如果这个假设不成立，会发生什么”来引导讨论。把未验证的点标成待办，而不是藏在心里。
项目里设计评审会先讲业务目标和约束，再讲方案和备选，最后讲风险和回滚。评审的价值在于提前发现问题，不是走过场。材料要提前发，现场聚焦分歧，会后要有结论和行动项。评审要敢提反对意见，行动项要跟踪关闭，要记录决策和复盘，要敢反对，要闭环。
Q19. 怎么衡量翻译是否成功？
看三件事：业务是否听懂并确认，技术是否按预期实现，上线后指标是否改善。三者缺一不可。
如果业务确认了但指标没变，可能是翻译错了目标；如果技术实现了但业务不用，可能是场景没对齐。
项目里我会在需求上线后回看目标指标和用户反馈，复盘翻译环节哪里偏了。翻译的终点不是文档，是业务结果。业务采用率低、返工多，都说明翻译没对齐。要回访用户、看返工率、复盘翻译环节，形成闭环，要能迭代，要看采用率，要能闭环。
Q20. 项目里怎么实践业务技术翻译？
项目里先写需求理解，再画流程和领域模型，然后定接口、数据和指标。每个环节都和业务确认，避免自嗨。
LingShu 的医疗问答要把“问诊”翻译成意图、证据、护栏和拒答；SuGuangMall 的推荐要把“懂用户”翻译成召回、排序和多样性指标。
翻译能力不是语言技巧，是业务理解、技术判断和沟通的结合。能把复杂问题讲清楚，才能把复杂系统做正确。每次复盘都更新术语、模板和验收标准，翻译能力才会积累。翻译要落到文档、模型和验收标准，不能只停留在会议里。