打包产品的配置界面有一个很尖锐的问题：运营配完之后不知道自己配出了什么。这和营销规则的情况类似，但比它更严重——营销规则至少能算出一个价格，而打包产品可能压根卖不出去。
原因是打包产品的可售性是各子项可售性的交集，而子项之间还有联动关系：机票的到达日必须等于酒店的入住日、酒店的退房日必须等于返程机票日期、门票日期要落在入住区间内、人数到房间数不是等量换算。这些关系配错了，包依然能保存成功，但它永远不可售——而且没有任何提示。
第一版就是这样：运营选几个子项、填一个打包价、保存、上线。然后发现这个包在前台压根搜不到，或者搜到了点进去显示不可售。排查一次要跨好几个系统看，运营自己完全搞不定，每次都要找技术。
所以三个设计。
第一是把「包内角色」显式化。去程机票和返程机票都是机票品类，但它们在包里的角色不同、联动规则也不同。第一版没有角色概念，靠子项的顺序隐式表达，结果运营调整顺序后联动关系就错了。改成显式选择角色（去程 / 返程 / 住宿 / 门票 / 接送），联动规则挂在角色上。
第二是把联动关系做成可配置且可视校验。界面上明确展示「到达日 = 入住日」「退房日 = 返程日」这些约束，并且在配置时就校验它们是否成立。人数到房间数的换算尤其要可视——「3 人 → 1 间三人房」这个换算结果要显示出来给运营确认，因为这里最容易错（我们在后端也踩过把人数直接当房间数的坑）。
第三，也是最关键的：内置试算。运营在配置页里选一个具体的出行日期与人数，实时看到「这个组合在这一天可售吗、打包价是多少」。可售性和价格都调服务端算，和试算器不能自己在前端算一套是同一个道理。
而试算最重要的输出不是「可售 / 不可售」，是「不可售的原因定位到具体子项」。只告诉运营「不可售」他什么也做不了；告诉他「第三天酒店 A 无余量」，他就知道该换酒店还是改日期。这一条和营销试算器「要给优惠明细而不是只给总价」是完全同一条原则。
最后是发布前的完整性与联动一致性校验：必选角色是否齐全（有去程没返程）、联动关系是否自相矛盾（门票日期落在入住区间外）、人数换算是否有解。把这些拦在发布前，而不是让运营上线后靠前台表现去发现。
试算的可售性调服务端，代价是每次改配置都要一次网络往返，而打包可售性的查询本身就比单品慢。前端算不可能——可售性要查多个供应商的实时库存，这本来就是服务端的能力。所以真正的取舍是「试算的粒度」：是每改一个字段就试算，还是让运营手动点「试算」。我们选了防抖后自动试算，理由是「手动触发的试算会被跳过」——运营配完直接保存，试算按钮形同虚设。自动试算的代价是请求量，缓解手段是防抖加序号丢弃，而不是改回手动。
不可售原因定位到子项，这是试算价值的关键，也是对后端接口的要求。前端要能展示原因，前提是后端在返回不可售时必须带上「是哪个子项、什么原因」——如果后端只返回一个布尔值，前端做不出这个能力。所以这个模块的一部分工作是推动接口把「求交时哪个子项挡住了」这个信息返回出来（后端那边也确实做了这个记录，用于运营选品分析）。这里的经验是：前端的诊断能力上限取决于接口给了多少信息，遇到这类需求要先去谈接口，而不是在前端猜。
联动关系做成显式配置而不是硬编码。硬编码更简单（代码里写死「到达日等于入住日」），但打包产品的形态会变——有的包是「先玩后住」、有的包含多段行程，硬编码撑不住。显式配置的代价是配置界面更复杂、运营要理解联动的概念。缓解手段是给常见包型提供模板（机加酒模板自带标准联动），运营从模板开始改。这个取舍的依据是：业务形态还在演进时，把规则做成数据比写进代码更能承受变化。
踩过的坑：包内角色靠子项顺序隐式表达，运营调顺序后联动全错。运营为了让界面上的展示顺序更合理，把返程机票拖到了住宿前面，联动规则按索引匹配，于是「到达日等于入住日」这条约束绑到了错误的子项上，包变成永久不可售，运营完全不知道为什么。修法是显式角色，联动规则挂在角色上。教训是：任何有语义的关系都不能靠位置表达——这和「列表键不能用数组下标」是同一个错误的另一种形态，我在这个题库里已经遇到过好几次。
踩过的坑二：人数直接当房间数，配出了住不下的包。配置界面让运营填「人数」，系统按人数当房间数传给酒店子项，三人行只订了一间大床房，用户到店才发现。修法是把换算结果显示出来给运营确认——「3 人 → 1 间三人房」或「3 人 → 2 间标准间」。教训是：涉及换算的字段，界面必须把换算结果显示出来，让人能在配置阶段发现换算规则不符合预期，而不是等到用户到店。
踩过的坑三：试算只返回「不可售」，运营拿着这个结果无法行动。试算功能上线后运营反馈「知道不可售但不知道改什么」，还是要找技术查。修法是推动接口返回具体子项与原因，界面上定位展示。教训和营销试算器完全一样：诊断类工具的价值在于指出原因而不是给出结论——只给结论会让用户陷入试错循环，而且工具做了等于没做。
踩过的坑四：只支持单日试算，运营要一天天点。运营真正的问题是「这个包在下个月哪些日期可以卖」，而单日试算要点三十次，实际上没人这么干，大家还是靠上线后观察。修法是支持按日期区间批量试算并用日历形式展示可售日期。教训是：工具要匹配用户真正的问题，而不是匹配问题的最小单元——单日试算只解决了问题的三十分之一。
没做的部分：没做打包产品的自动选品建议（根据历史可售率与转化推荐子项组合）。运营提过，需要数据与模型支持。也没做子项的批量替换（把某个包里的酒店换成另一家，同时更新所有相关包），只支持单包编辑，连锁场景下有痛点。
「配了但不可售」的包数量：最该报的数字。报发布后被发现不可售的包数量，改造前后对比，并说明发现路径的变化（改造前是上线后前台搜不到才发现，改造后是配置时试算就发现）。路径变化比数量更有说服力。
发布前校验拦截：报被阻断的发布次数与原因分布（角色不全、联动矛盾、人数换算无解）。分布很有价值——如果「人数换算无解」占大头，说明换算规则的界面表达还不够清楚。
试算使用率：报发布前触发过试算的包占比。因为我们选了自动试算，这个比例应该很高；如果做的是手动试算按钮，这个数字会很低——这正是我们选自动的理由。
试算的可行动性：报试算返回不可售后运营实际修改了配置的比例。这个数字度量的是「原因定位是否有用」——如果运营看到不可售后什么都不改就保存了，说明原因还是没帮到他。
批量试算的使用：报批量试算与单日试算的使用比例。批量占多数才说明我们做对了——它证明运营真正的问题是「哪些日期能卖」而不是「这一天能不能卖」。
竞态与联动：确定性验证——连续快速修改配置检查试算结果始终对应最后一次配置；调整子项顺序检查联动关系不变（这是踩坑后固化的用例）。
不要报「打包产品可售率提升 N%」。可售率主要由供应商库存决定，不是这个配置界面的成果。正确表述是「配了但不可售的包数量与发现路径的变化、发布前校验拦下的类型分布、试算的使用率与可行动性、联动关系不受顺序影响由用例保证」。
国际业务的内容运营有一个别的业务没有的负担：同一条内容要维护多个语言版本。一个酒店的名称、描述、政策说明、房型介绍，每一项都要有八种语言。
第一版把它当成一个很自然的问题处理：每个语言一个页签，运营切换页签分别编辑。这个做法的问题在上线后集中爆发。
第一是看不出缺失。运营编辑完中文和英文就发布了，其他六种语言是空的，而界面上完全看不出来——每个页签单独看都很正常。结果前台在小语种地区展示时，有值的字段显示当地语言、没值的字段回退到英文，出现了中英混排、或者德语页面里夹着英文段落。用户反馈过来才发现。
第二是源文改了不知道译文过期。运营改了中文描述，八种语言的译文全都还是旧的，而界面上没有任何提示。译文和源文不一致这件事，只能靠运营自己记得「我改了中文，得去改其他语言」——而这是记不住的。
第三是专有名词译法不一致。同一个品牌名在名称字段里译成一种、在描述字段里译成另一种；房型名「大床房」在不同地方译得不一样。这在国际业务里是很实际的品牌问题。
所以四个设计。
第一是并排对照编辑：左边源语言、右边目标语言，同一个字段上下对齐。运营不用来回切页签，而且缺失的字段一眼就能看出来（右边是空的）。这个改动很朴素，但它解决了「看不出缺失」这个最大的问题。
第二是逐字段的翻译状态，这是这个模块的核心。状态有四个：缺失（还没有译文）、机翻待校（机器翻译了但没人审）、人工已校（人看过了）、源文已变待重译（译文存在但源文改过了）。
关键是最后一个状态：源文变更时自动把所有目标语言的对应字段标记为「待重译」。这一条把「靠运营记住」变成了「系统主动标记」。这是整个模块收益最大的一改。
第三是术语库一致性校验：维护一份专有名词的标准译法（品牌名、地名、房型名），编辑时校验译文里的这些词是否用了标准译法，不一致就提示。这不是强制替换（有时上下文确实需要变体），而是提示。
第四是发布前拦截：关键语言缺失直接阻断发布（哪些语言是关键的按业务配置），非关键语言给警告。同时对富文本做结构一致性校验——译文里的标签数量、占位符数量必须和源文一致，否则会出现「译文里少了一个占位符导致前台显示成字面量」这类问题。
逐字段状态 vs 整条内容一个状态，这是这个模块最实质的建模选择。整条内容一个状态（比如「德语版已完成」）实现简单，但它表达不了真实情况——实际是「名称译好了、描述没译、政策说明是机翻」。逐字段状态的代价是状态数据量是「字段数 × 语言数」，界面也更复杂。但没有它，「源文变更导致哪些译文过期」这个最核心的需求压根做不到——源文改的是某个字段，只有字段级状态才能精确标记受影响的范围。判断依据是：状态的粒度必须匹配变更的粒度。
术语校验做提示而不做强制替换。强制替换能保证绝对一致，但语言不是查找替换能处理的——同一个词在不同语法位置需要不同形态，某些上下文里标准译法反而不通顺。强制替换会产生比不一致更奇怪的文案。所以做提示，把判断权交给懂这门语言的人。这和「机器判不准就交给人」是同一个取向：在有语言学判断的地方，机器只做发现不做决定。
机翻的定位是「给人一个起点」而不是「产出终态」。直接用机翻结果上线成本最低，但旅游内容里的机翻错误很致命（把房型名译错、把政策条款译得意思相反）。所以机翻结果一律标记为「机翻待校」，而且这个状态在发布前拦截里算不算缺失是可配的——重点语言要求人工校对，长尾语言可以接受机翻上线。取舍依据是「这个语言的用户量和内容出错的代价」，不是一刀切。
踩过的坑：其他语言缺失导致前台中英混排，用户反馈才发现。运营编辑完中英文就发布，其他六种语言是空的，而页签式界面里每个页签单独看都很正常；前台在小语种地区展示时有值的字段用当地语言、没值的回退英文，出现了德语页面里夹着英文段落。修法是并排编辑加缺失可见加发布前拦截。教训是：多版本数据的编辑界面必须让「版本之间的差异」可见，而不是让用户逐个版本看——分页签是最自然的设计，也是最容易掩盖缺失的设计。
踩过的坑二：改了中文源文，八种译文全部过期而没有任何提示。运营更新了酒店政策的中文描述，其他语言还是旧政策，用户按旧政策的译文下单，到店发现规则不一样。修法是源文变更自动标记所有目标语言的对应字段为「待重译」，并提供按状态筛选。教训是：派生数据（译文是源文的派生）必须能感知源数据的变更——不能依赖人记住去更新派生数据，这在缓存、索引、译文、报表上是同一条。
踩过的坑三：译文里少了一个占位符，前台显示成字面量。富文本里有一个「{城市名}」的占位符，译员在翻译时把它删掉了，前台渲染时那个位置显示了原始的花括号文本，用户看到一串莫名的符号。修法是发布前校验译文的标签与占位符数量必须与源文一致。教训是：带结构的文本在翻译流程里会被破坏结构，必须有结构层面的校验——只校验「有没有内容」是不够的。
踩过的坑四：某些语言的译文太长撑破了前台布局。德语和俄语的译文明显比中文长，房型名在卡片上被截断成看不懂的样子。修法是在并排编辑里显示各语言的字符数差异，并让预览用真实前台渲染以便看出布局问题。教训是：国际化的布局问题必须在内容生产阶段就暴露，等到前端去做「自适应截断」是治标，因为被截断的内容本身就传达不了信息。
没做的部分：没做翻译记忆库（同样的句子之前译过就复用），需要句级切分与相似匹配，工作量不小而且我们的内容重复度不算高。也没做译员协作流程（分配任务、审校流转），当时翻译由外部服务完成，我们只管内容的状态与校验。
语言缺失导致的混排：报相关用户反馈或工单的数量，改造前后对比。工单数是外部可核查的证据，比自述的「缺失率下降」有说服力。同时报发布前拦截关键语言缺失的次数。
译文过期：报「源文已变待重译」状态被触发的次数与后续被处理的比例。前者证明这类情况是常态而不是偶发（这一点支撑了自动标记的必要性），后者说明闭环在运转。
结构校验：报发布前拦下的结构不一致次数（标签或占位符数量不匹配）。这个数字如果不小，正好说明「翻译流程会破坏结构」不是我们臆想的风险。
术语一致性：报术语校验提示的触发次数与运营采纳修改的比例。采纳率很重要——如果提示了但运营从不采纳，说明术语库本身有问题（标准译法不合适），该去修术语库而不是加强提示。
编辑效率：用操作次数描述——改造前要在八个页签之间切换、逐个对照；改造后并排一屏可见。不要编一个「效率提升 N%」，翻译工作的耗时主要取决于译员而不是界面。
布局撑破：报因译文过长导致的前台展示问题数量，改造前后对比。这类问题在字符数提示与真实预览之后应该显著减少。
不要报「多语言完整率 100%」。长尾语言的内容完整度取决于翻译资源投入，不是这个界面能决定的；而且我们的设计本来就允许非关键语言缺失（回退英文）。正确表述是「关键语言缺失由发布前拦截、源文变更导致的过期由自动标记暴露、结构不一致拦下多少次、术语提示的采纳率」——把系统责任和内容生产责任分清。
这个界面服务的是实体归一里「机器判不准」的那一档（相似度落在双阈值中间的候选对）。它的定位很明确：不是让审核员做数据录入，是让他做判断。所以界面的唯一目标是让判断所需的信息一屏可得，让判断动作的成本尽可能低。
第一版完全没想清这一点：把两条记录的所有字段原样并列展示，审核员自己看。问题很快暴露。
第一是审核员要自己逐字段比对。两条记录各有二十来个字段，大部分是相同或相近的，真正有区分力的就那么两三个，但界面对所有字段一视同仁，审核员的眼睛要在两列之间来回扫。一天判几百对之后疲劳极了，而疲劳直接导致误判。
第二是关键信息不在同一屏。判断「是不是同一家酒店」最有用的两样东西是地图位置和照片，而第一版这两样都要点开新页面看。审核员要在三四个页面之间跳转才能判一对，跳转本身的时间比判断的时间还长。
第三是审核员不知道机器为什么判不准。界面只给两条记录，不给相似度得分、不给命中了哪些特征。审核员看到两条很像的记录，不知道机器是「名称像但坐标远」还是「坐标近但名称差异大」——而这个信息恰恰是判断的关键线索。
第四是操作要用鼠标点。每一对都要移动鼠标找按钮点击，一天几百对就是几百次鼠标移动，而这个操作本质上只有三个选项（合并 / 排除 / 存疑）。
所以四个设计。
第一是差异高亮：相同的字段淡化，不同的字段标出来。审核员的注意力直接被引导到有区分力的字段上。这一条是收益最大的改动——它把「自己找差异」变成「差异已经摆在眼前」。
第二是一屏聚合：地图并排定位（两个点画在同一张图上并标注距离）、照片并排展示、关键字段对照，全部在一屏内，不跳页。
第三是展示机器的判断依据：相似度得分、以及命中了哪些特征、哪些特征不匹配。让审核员理解机器为什么犹豫，他就能把注意力放在真正模糊的地方。这是「机器辅助人」而不是「机器把问题丢给人」的区别。
第四是键盘流加预加载：三个操作绑定快捷键，判完自动进入下一对，而下一对的数据（包括地图和照片）提前预加载。这一条把「等待」从流程里去掉。注意这里和直播中控台的判断相反——那里刻意不给高危操作快捷键，这里恰恰要给，因为这里的操作是可撤销的、而且高频。
另外两件事：界面里要有误合并的定点拆分与撤销入口（发现之前判错了要能立刻改）；判定结论与理由要回流成样本用于阈值调优——没有回流的人工审核是纯人力消耗，系统永远不会变好。
差异高亮的取舍在于「怎么定义差异」。严格的字符级差异会把「北京市朝阳区」和「朝阳区，北京」标成完全不同，而它们语义上是一样的；太宽松又会把真正的差异淡化掉。我们的做法是按字段类型用不同的比较方式：名称做归一化后比较（去品牌后缀、全半角、空格）、地址分层比较（门牌号权重最高）、坐标算距离、电话去格式后比较。代价是每种字段类型都要单独实现比较逻辑，但这部分逻辑和后端归一化用的是同一套规则，所以实际是复用而不是重写——这一点很重要，如果前端自己搞一套比较规则，高亮出来的差异和机器判定用的差异就不一致，会误导审核员。
给快捷键的决定，和高危处置场景完全相反，依据是「操作是否可逆」。直播处置里我们刻意不给切断和封禁做快捷键，因为快捷键让操作与「确认自己在看什么」解耦；这里恰恰要给，因为合并与排除都是可撤销的，而且频次是一天几百次。同一个工具（快捷键）在不同场景是正资产还是负资产，取决于操作的可逆性和频次——这个判断我认为比记住「后台要加快捷键」这类结论有用得多。
展示机器的判断依据，代价是对后端接口的要求。前端要展示「相似度得分与命中特征」，前提是接口必须把打分的中间结果返回出来，而不只返回一个分数。这需要和后端一起改（后端那边也确实需要这些信息做阈值调优）。经验和打包试算一样：前端的诊断能力上限取决于接口给了多少信息，遇到这类需求要先谈接口。
踩过的坑：把两条记录原样并列，审核员一天判几百对之后误判率明显上升。界面对二十来个字段一视同仁，审核员的眼睛要在两列之间来回扫，而真正有区分力的只有两三个字段。修法是差异高亮。教训是：给人做判断辅助的界面，核心工作是「减少无关信息」而不是「展示全部信息」——把所有字段都摆出来看起来最负责，实际是把筛选信息的工作推给了人。
踩过的坑二：关键信息要跳页看，跳转时间比判断时间还长。地图和照片各在一个新页面，判一对要在三四个页面间跳转，审核员的实际做法是「跳得太麻烦就不看地图了，只看名称判」——而这正好丢掉了最有区分力的信息，误判自然多。修法是一屏聚合。教训是：如果获取某个信息的成本太高，用户就会跳过它，而不是费力去拿；所以「重要信息」和「易得信息」必须是同一批。
踩过的坑三：前端自己实现了一套字段比较逻辑，高亮的差异和机器判定用的不一致。前端按字符级比较高亮，把「北京市朝阳区」和「朝阳区，北京」标成完全不同，而机器归一化后认为它们一致，审核员看到「地址完全不同」就排除了，而机器其实认为地址是匹配的。这直接造成了误判。修法是前端复用后端的归一化规则做比较。教训又回到同一条：同一个业务判断不能有两份实现——这次的形态是「高亮用的比较规则」和「判定用的比较规则」分叉。
踩过的坑四：审核结论没有回流，队列越来越长而机器一点没变好。审核员每天判几百对，判完就存个结果，第二天来的还是同样类型的争议。修法是结论落成正负样本、样本累积后调阈值、高频争议模式反哺归一化规则（比如发现大量争议来自「大厦/广场/中心」这类通用词干扰，就把它们加进停用词）。教训是：任何「机器判不准转人工」的设计都必须带一条从人回到机器的反馈路径，否则人工是纯消耗、系统的准确率永远停在上线那天。
没做的部分：没做多人协同判定（同一对由两人独立判定后比对，用于质量抽检）。质量抽检的机制在后端那一侧，界面上只做了「存疑转他人」。也没做批量判定（把明显同类的多对一起处理），因为批量在这里风险太高——误合并的代价大，一次批量错就是一批错。
单对处理的操作次数：最该报的效率指标，而且用操作次数而不是耗时——「从跨三四个页面跳转、鼠标点击，变为一屏内键盘完成」。操作次数与人的熟练度无关，可核查；耗时依赖审核员个人差异，不同人差几倍。
误判率：这个要靠抽检来测——由资深审核员复核一批已判定的对，报复核发现的误判数（绝对数）与抽检量。要分开报「误合并」和「漏合并」，因为两类错误的代价严重不对称（误合并是用户订错店的恶性事故）。
疲劳效应：报误判率随连续判定数量的变化。这个数据很有说服力——如果判到第两百对时误判率明显上升，正好支撑了「提示休息」和「减少无关信息」这两个设计。
信息的实际使用：报地图与照片的查看率，改造前后对比。改造前跳页成本高、查看率低（审核员跳过了最有区分力的信息），改造后一屏可见、查看率接近全部。这个数字直接证明「重要信息必须易得」。
回流效果：报回流样本量、由此触发的阈值调整次数、以及中间档（进人工）比例的变化。中间档比例下降是回流真正生效的标志——机器判得准了，进人工的就少了。
纠错的使用：报撤销与定点拆分被使用的次数。这证明纠错入口不是摆设，同时撤销次数偏高说明快捷键可能太容易误触，是个需要关注的信号。
不要报「审核效率提升 3 倍」或「判定准确率 99%」。前者分母不清（对比谁、什么条件），后者依赖抽检方式与样本构成，而且掩盖了两类错误的不对称性。正确表述是「单对操作次数的变化、抽检发现的误合并与漏合并各多少、地图与照片查看率的变化、回流样本带来的阈值调整次数与中间档比例变化」。
没有匹配的内容，换个关键词试试。
项目拆解 · 打包产品与多语言内容后台（Vue）· 共 3 个模块 · 数字均为示例，需替换成自己项目的真实数据