★ FEATURED ARTICLE “里海是海吗”这个问题我最早是在一个闲聊群里看到的。当时有人随口一问底下争论还挺热闹有人拿出中学地理说“封闭水体就是湖”有人说查了百科也写着湖还有人反问“名字都叫海了你说是不是海”。我本来想划过去结果那天晚上鬼使神差顺着地图、水文数据、相关词条一路翻下去越翻越觉得有意思最后竟然翻出了一整套关于“人怎么给世界下定义”的思考。后来我发现这套思考放在写代码、做产品上意外地好用。先放下结论严格意义上里海不是“海”它是一个不连通全球海洋体系的大型内陆咸水湖但“严格意义”这四个字里藏着非常多的前提。为什么它一直被叫“海”为什么大家默认它是海这背后牵扯的命名、分类、历史习惯和系统设计问题才是真正值得聊的东西。这是一趟从地理问题出发的跨界漫游途经分类学、命名学、代码设计这些看起来八竿子打不着的领域。如果你是写代码的你会发现很多“需求说不清”的根源就是定义问题如果你是做产品、做运营的你会发现“同一个词在不同人眼里根本不是同一个意思”这种事每天都在发生。我尽量把这一路的观察、方法、踩坑都整理出来能帮你省不少冤枉路。1. 里海是海吗先搞清楚什么叫“定义”1.1 地理学教科书里的判据绕不开“连通大洋”这条硬杠区分“海”和“湖”地理学并不是靠面积拍脑袋主流的判据是看这片水体与世界大洋之间是否存在直接的水力联系。海被认为是世界大洋的一部分水体透过海峡、海湾、水道与大洋交换湖则是封闭的陆地水体水循环主要靠入湖河流、降水和蒸发来维持。里海的账很难算清。它的面积大约接近三十八万平方公里比不少边缘海都大看起来完全有“海”的体量。但它的四周被大陆包围没有任何水道与外部大洋相连水量收入靠多条大型河流注入支出主要靠蒸发。这套收支体系完全是湖泊式的。可一旦换到地质构造的视角情况又变了里海盆地在数千万年前属于一片古大洋的残余海域那时候它就是实打实的“海的一部分”只不过后来地壳运动让水体封闭才逐步演变成今天的内陆湖。所以准确的说法是它有海的前世现在过着湖的今生。类似名不副实的水体并不少。死海名字带“海”实际是超咸的封闭湖泊按学术分类它连湖都算得勉强。这种命名的混乱恰恰说明一个规律人类日常语言系统常常比科学分类系统更顽固。叫了几百年的名字想改也没那么容易改。1.2 名字和事实打架时先听懂各自的坐标系“里海是海吗”之所以有争议是因为“海”这个词在不同语境下承担的功能完全不同。日常语言里“海”约等于“特别大的水”直觉上里海当然算海水文学里它不与全球大洋系统连通算内陆湖地质学里它是古大洋的残留又带着“海”的基因。同一片水体在不同学科坐标系里可以拿到完全不同的名分。所以我的建议是问“是不是海”之前先问“你问这个做什么”。如果你要横渡它它叫海叫湖都不影响你晕船如果你要按海洋生态模型预测渔业资源你必须把它当海来做如果你要用一套封闭水体的水量平衡模型那它在你系统里就是湖。同一个词在不同坐标下可以有完全不同的正确答案。这个认知平移到其他领域同样成立。产品经理问“这个功能是给谁用的”本质上是在给“功能”寻找坐标测试同学问“这个异常路径算不算主流程”也是在给“主流程”划边界。坐标没对齐所有讨论都会变成鸡同鸭讲。2. 命名学一个名字能活几千年也能毁掉一次联调2.1 一个名字能活多久比你想的长得多当初的人为什么管里海叫“海”答案很朴素因为它大、它咸、一眼望不到边。在古人眼里一片大到望不见尽头的水不叫“海”叫什么这个命名一旦进入地图、书籍、档案和口耳相传就会一代代沿用下去哪怕后世的科学已经证明它的本质是个湖“海”字依然留在名字里。语言就是这样它有惯性而且惯性大得吓人。这种现象在分类学里有个说法叫“名称的保守性”。生物学里不少物种顶着历史上继承下来的误导性名字分类学家早就想统一但改名的代价太大文献、教材、数据库、商品目录、法规条文里遍布旧名字一旦改动所有引用它的体系都要跟着动。最终大家只能接受“名字仍在括注补丁”的局面。这件事对做系统的人特别有启发。我见过太多线上系统的字段名、目录名、状态值明明和现在的业务含义已经对不上了但没人敢去改。改动一个字段名背后可能是几十个接口、上百条报表的连锁更新。改名的成本往往比“名字不准确”带来的代价还大。所以老练的工程师都会选择“向前兼容”名字继续留文档加注释新代码里启用新名词。这和地理学家保留“里海”的称谓、括注一句“内陆湖”的策略本质上是一回事。命名从来不是技术问题是成本问题。2.2 谁在命名谁就掌握了话语权再往深一层想“里海是海吗”的争论其实也是一场分类主动权的争夺。命名不是一个中性动作谁定义“海”谁就定义了哪些规则适用。这在人类历史里屡见不鲜不同的社会、不同的知识体系对同一片世界进行了各自的切分和命名而这些命名背后都藏着该社会最关心的事物。农业社会的土地词汇划分极细游牧社会关于牲畜的词可以多达几十个沿海社会往往有大量描述水流、风向、潮汐的词。词汇表就是一份社会的需求说明书。这和我写代码时看到的景象一模一样。同一个业务实体在财务系统里叫“应付单”在仓储系统里叫“出库单”在客服系统里叫“工单”底层可能都是同一条数据。每个子系统按照自己的职责切分世界、各自命名集成的时候就会出乱子。你管它叫海还是湖背后站着的是你所在团队的流程边界和考核口径。理解了这一层你就不会再天真地认为“定义是唯一的”。几乎所有定义都是某个视角下的局部最优解。认清这一点沟通时就能少生很多闷气。3. 从“isSea”这个字段聊到需求为什么永远说不清3.1 代码里的 isSea 就是另一个里海程序员很容易在这里看到熟悉的东西变量命名本质上就是在给世界做分类。你写一个 isSea 字段取值只有 true 和 false可“里海”这种对象塞进来的时候isSea 到底填什么填 true地理学家不同意填 false历史学家和普通用户不同意。真实的业务世界里根本不存在那么干净的二值空间。我第一家公司实习的时候遇到过特别典型的例子。系统里有个字段叫 isNew用来标记“这条记录是不是新用户”。一开始逻辑很简单数据库查不到手机号就置 true。后来业务加了规则三个月前注册过、最近又回来的人算“新”吗渠道拉新的单次注册算“新”吗产品经理一周改了三次规则我们跟着改了三次 isNew 的判定逻辑整张表的数据被刷得惨不忍睹。最后痛定思痛把 isNew 这个布尔字段删掉换成一个状态枚举和一个行为时间戳后续一切判断从基础数据里推算系统反而干净了。这个案例和“里海是海吗”异曲同工当真实世界是连续变化的光谱时任何二值分类都必然失真。正确的做法不是去找那个“标准答案”而是把标签拆成可以被查询、被组合、被推导的基础事实让定义像积木一样自己长出来。3.2 需求不清的第一性原理坐标系缺失写代码久了就会发现大多数“需求不清”不是对方故意刁难而是提问方和目标方压根不在同一坐标系里。产品经理说“把用户体验做顺滑一点”你听成“优化交互流畅度”他脑海里想的是“减少从点击到反馈的路径”测试同学理解的是“各设备别闪退卡顿”。三套理解字面上都没错但落到验收标准上完全是三种东西。处理这种问题的核心方法是先把坐标系摆出来。我现在习惯性追问三个问题这个功能服务谁最终用户、内部运营还是两边系统对接这个对象的边界在哪里什么必须算进来什么必须排除出去如果边界模糊默认的处理倾向是什么这三个问题看似简单本质就是在把“它是不是海”翻译成“你想判断它是不是海是为了决定什么事”。一旦“为了什么”明确了定义立刻清晰代码也就写得动了。3.3 画出你的“定义地图”需求评审成功率翻倍我自己实践下来最有效的工具是一张“定义地图”。拿张纸中间写下核心概念比如“订单”然后往外辐射谁创建订单什么状态算有效订单取消单算不算订单售后单算不算订单每条边界都是一个分支每个分支都要落一个明确结论。这张地图画完需求遗漏的概率至少小一半。有次做订单中台项目我就用这个方法把“订单”拆成了六个边界变量其中三个是评审时根本没人提过的。产品同学看完差点跳起来——原来他口中的“订单”和财务口里的“订单”根本不是同一个东西。后来我们把口径对齐联调阶段一次架都没吵过。一张纸比十页需求文档都好使。4. 跨界漫游路线图如何把一个“闲问题”挖成方法论4.1 碎片时间的火花也可以串成知识网很多人问我工作这么忙哪来的时间搞“跨界漫游”我的回答是不需要专门腾时间只需要把日常的碎片时间利用起来。通勤、排队、睡前这些时间原本就是放空的与其刷短视频不如顺着一个问题往下挖一层。我的习惯是用笔记软件随手记问题不管多小都记。问“里海是海吗”的人傻吗不傻。恰恰是这种“大家都觉得显而易见”的问题才藏着真正值得挖的东西因为显而易见的问题是大部分人早已停止思考的问题。每次这种问题冒出来我都会提醒自己这里可能有一层别人没注意到的定义。把它记下来得空再挖挖着挖着问题就串成线索线索织成网最后变成自己的知识版图。4.2 两种跨界阅读姿势顺藤摸瓜和格物致知顺藤摸瓜的读法适合地理、历史这类强叙事领域看到一个陌生的地理名词顺手查它的由来看到地图上一条奇怪的分界线顺便看看它把区域分成了哪两块。就这么一路摸下去地图上的点会慢慢变成有故事的坐标。格物致知的读法适合更抽象的领域遇到一个概念比如“内陆海”去查它的定义、反例、边界情况查的过程中一定冒出新概念再继续追。这种读法很累但产出极高本质上是一次自制的科研训练。我的经验是两个姿势交替用比较好不然容易腻。用顺藤摸瓜培养兴趣用格物致知沉淀知识。当初里海这个问题带着我在地质、水文、语言、分类学之间绕了一大圈最后落在代码的“定义问题”上就是这两种读法交替出来的结果。4.3 别被好奇心绑架跨界也要算投入产出必须泼一盆冷水跨界是会上瘾的但你不必把每条支线都走完。有次我为了弄清楚某个水体的地质成因连板块构造细节都啃了两天最后发现对我的主业几乎没帮助。不是说不能学而是要分清“兴趣”和“资产”——能对你的工作、决策产生复利的知识才是值得深挖的资产纯粹满足好奇心的浅尝辄止就好。我的止损线很简单如果一个问题让我连续三个小时没有产出也没有形成任何可复用的判断框架就先把它放一边。好奇心应该被喂养但不该变成拖延症的遮羞布。5. 我的万能追问框架五步厘清任何“定义纠缠”5.1 五步框架速览一张表讲透最后把这趟漫游沉淀下来的东西收拾成一个可操作的小框架。不管你是面对“里海是海吗”这类知识问题还是在需求评审上面对“这个对象到底算什么”都可以按下面五步走追问问题作用里海示例1. 谁在使用这个定义确定坐标系普通人聊天 vs 地理学教材2. 使用定义要做出什么决策明确目标按哪种生态模型来管理3. 定义在当前数据下成立吗检验证据封闭水体、不连大洋 → 偏湖4. 有哪些反例和边界情况寻找漏洞地质年代里曾是大洋残留5. 若只能二选一哪个错误的代价更小拍板担责日常叫海、科学归湖这个框架我在多个项目里反复用尤其是第 5 问简直是需求会议上的灭火器。两拨人吵得不可开交时把“哪个错误代价更小”摆上桌面讨论立刻从站队变成权衡。5.2 为什么程序员最该拥有这套框架程序员每天都在做定义工作接口返回值的结构、数据表的主外键关系、微服务的拆分边界本质上是同一件事——决定世界如何被切分、被命名、被关联。切法决定了下游所有系统的复杂度和稳定性。我见过最痛苦的一个项目把一个“用户”对象做成了二十多个字段的巨型实体每个接口各取所需字段之间互相矛盾最后连“哪个是主手机号”都说不清。拆掉那天大家才意识到问题的根子不在技术选型而在一开始“用户”这个词的定义没人拉通。所以做程序的人最该先做的其实不是写代码而是把概念模型定清楚。概念模型定了表结构、接口、状态机都是水到渠成的事。这大概是“里海是海吗”这趟漫游最后教会我的最重要的一件事。5.3 定义洁癖要不得较真的三种场合框架好用但别走火入魔。不是所有事情都需要较真到底。日常沟通里A 把某个东西叫“海”B 把它叫“湖”只要不影响一起合租、一起吃饭、一起写代码那就各自叫各自的。定义是为了解决问题而存在的不是为了证明谁更严谨而存在的。真正需要较真的场合对我来说只有三种要写代码了、要跨团队定接口了、要签一锤子买卖的合同了。这些场合“里海是海吗”式的追问都能帮你省下后面大量的返工时间。除此之外保持一点睁一只眼闭一只眼的松弛反而能活得更舒服。最后说点私人体会。我大概永远也忘不了那个晚上从“里海是海吗”出发一路翻到地质、水文、语言、分类学最后落到代码里的字段设计。那种感觉就像在改一个 bug改着改着发现自己其实在重构整个世界观。踩过几次坑之后我现在遇到任何“定义不清”的东西第一反应不是烦躁而是隐隐兴奋——因为我知道这里面大概率藏着一个别人没看见的边界而边界处往往正是价值所在。希望你也能从自己的某个“无聊问题”里挖出一片热闹来。
阅读完成 · 觉得有帮助？
