同一个包三个人看：客户、开发和运维的三种验收标准

改包这件事，多数时候不是一个人干完就结束。一个包从"改完"到"用上"，中间通常要经过三个人：提需求的那个人、管技术的那个人、负责把它装出去的那个人。

而这三个人，看的是同一个文件，评的是三件不同的事。

提需求的人看"变没变"。他关心名字改了没有、图标换了没有、那个让他不满意的地方还在不在。他打开看一眼，说"对，就是这个"，就算验收完了。

管技术的人看"还能不能再改"。他关心的是：这个包以后还要改怎么办、改过的地方能不能找到、有没有把原来的结构弄乱。他担心的不是你这一版，是下一版。

负责装出去的人看"会不会出事"。他关心装十台会不会有一台装不上、装完出问题能不能回退、包里有没有多要权限、用户会不会看到安全提示。他不关心界面，他关心麻烦。

这三种标准经常打架，而且打得很隐蔽。——因为每个人说"好了"的时候，说的都是自己那一套；而你以为他说的是你那一套。——等到装上十台里坏了两台、或者半年后想再改一版发现改不动的时候，才会发现当时那个"好了"其实是"我看着好了"。

只需说话，就能让应用变成你想要的样子。而"你想要"这三个字，在这个场景里要先被翻译三次：提需求的人想要的、管技术的人想要的、装出去的人想要的。——把它们对齐一次，比改十次都省事。这篇讲的就是怎么对齐。

一、客户眼里的"改好了"：看得见的四处

提需求的人（不管是外部客户还是内部业务方）验收时，其实只看四个地方。这四个地方，恰好都在"打开应用的头十秒"里。

第一处：桌面上那个图标和名字。这是他最先看到、也最先确认的东西。名字对了、图标换了，他的信任就已经建立了一半。——所以这一处做错了，后面做得再好他都会带着怀疑看。

第二处：打开之后的第一屏。这里是他"感觉到变化"的地方。颜色变了、布局变了、多了一行字、少了一个入口——他会立刻注意到。——而这一屏也是最容易"改多了"的地方，因为他只说了"改一下"，你以为他要改一整屏。

第三处：那个让他不满意的地方。——这一处是需求的源头。他之所以要改包，通常是因为某个具体的点在扎他：一个关不掉的弹窗、一句看不懂的提示、一个老是点错的按钮。——而验收的时候，他会直奔那里，看它还在不在。——如果那个点还在，其他地方改得再漂亮，他也会说"没改好"。

第四处：文字。——这一处很微妙：非技术人对文字特别敏感，对技术细节特别不敏感。——他能一眼看出"这里应该叫'客户'不叫'用户'"，但看不出你的布局改了三个像素。——所以和客户打交道，文字比像素重要。

把四处合起来，客户的标准其实很朴素：他要的是"我要的那件事发生了，而且没弄坏我看惯了的东西"。——注意后半句：客户对"没改的地方"是敏感的。——他天天用这个应用，任何一个他没要求的变化，都会被他注意到，而且会被理解成"你顺手动了别的"。——这就是为什么"改多了"在客户那里，和"没改对"一样糟。

补一句关于客户的实用判断：他说"可以了"的时候，最好再问一句"那还有哪里不对吗"。——因为客户的第一句评价通常是"客气的"，第二句才是"真实的"。——而第二句往往很短："就是那个字有点小"、"那个按钮还是不好点"。——这一句如果没被问出来，它会在一周后变成一次返工；问出来了，它无非就是这次改动里顺手多加的一项而已。——而这两者的差别，就是"一次返工"和"一次顺手补上"的差别；再往远说，也是"他下次还找你"和"他下次换了别人"的差别。

二、开发眼里的"改好了"：下一版还改得动

管技术的那个人，看的东西跟客户完全不重叠。他不看界面好不好看，他看"这个包以后还能不能动"。

他关心的第一件事：结构有没有被弄乱。——一个应用解开来，是有结构的：资源按类型分目录、文件按用途命名、配置有固定的位置。——如果改包的时候"顺手整理"了——把文件挪了位置、把名字改了、把用不到的删了——那这个包在技术上就变成了"别人的包"。——表现是：下次要改，他得重新认一遍结构。

第二件事：改动有没有留痕。——他需要知道"这一版动了哪些地方"，而不是"这一版和原版长得不一样"。——因为下次出问题的时候，第一件事就是"最近改了什么"。——如果改动只存在于你的记忆里，那这个包对他来说就是一个黑盒：能用，但不敢碰。

第三件事：有没有引入"看着一样、里面不一样"的东西。——这一条最专业，也最容易被忽略。——比如同一个按钮，原来是"用一张图做背景"，现在变成"用一个色块加圆角"，看起来几乎一样；但对后面要改的人，这是两种完全不同的东西。——他改的时候会按"原来是图"的思路去找，找不到，然后花半小时才发现"已经变成色块了"。

第四件事：这个包还能不能被解开。——有些改动会让下一次反编译变难：比如动了加固的壳、改了资源表的索引、处理了字符串加密。——这些在"能用"这个标准下完全正常，但在"还要再改"这个标准下就是负债。

第五件事：版本号和签名有没有被管起来。——他知道签名换了意味着什么：装不上旧版、回退要卸载、数据会丢。——所以他会问一句"签名是什么"，而这句话在客户听来毫无意义，在他听来是"这东西以后能不能升级"。

把五件事合起来，开发的标准是："这一版改完之后，下一版还是我改，而不是'得重新学一遍'。"——而这个标准，恰好和客户的标准有一个直接的冲突点：客户希望"看起来变化大一点，钱花得值"；开发希望"改动尽量小，以后好维护"。——这个冲突没法消除，只能提前说清"这次改到什么程度"。

三、运维眼里的"改好了"：装出去别出事

负责把它装出去的那个人，看的东西更不一样。他不关心界面，也不关心代码，他关心"麻烦"。

第一件：装得上吗，装几台都一样吗。——一台能装不算，十台都能装才算。——他会想到系统版本、机型、厂家策略这些差异，而这些差异在"你的手机"上永远体现不出来。——如果这批设备里有三台老机器，那"能装"这个结论就要打问号。

第二件：装的时候用户会看到什么。——重新签过名的包，在安装时通常会有提示：来源未知、未经安全检测之类。——他不怕这个提示，他怕"没人提前告诉他会有这个提示"——因为那意味着他要现场解释十遍。——所以他要的不是"没有提示"，是"知道会有什么提示、以及怎么说"。

第三件：权限多了没有。——这一条在很多单位是硬要求：装之前要过安全审查，而审查看的就是权限清单。——如果这次改动顺手多要了一个权限（哪怕是为了某个小功能），那这个包可能过不了审。——所以他会在装之前对一遍权限列表，而这件事，做改包的人往往从来没想过。

第四件：出问题能不能退。——他要的是"万一坏了，我三分钟能把它变回原样"。——而这就要求：原包在手上、回退步骤清楚、数据不会因此丢。——这三样缺一样，他就不敢装第二批。

第五件：占多少空间、卸载干不干净。——改过的包通常会比原包大一点（多了资源、多了新图），这一般不是问题；但如果是给存储紧张的老机器装，就得留个心。——而"卸载干不干净"更多是心理需求：他不希望删了之后还留一堆目录。

把五件事合起来，运维的标准是："这个包我能安稳地装到十台机器上，而且万一出事我能收得回来。"——注意这个标准和客户的标准几乎没有交集：客户要"看起来对"，运维要"装起来稳"。——而做改包的人，往往只跟客户对接，最后被运维卡住。——卡住的原因通常不是技术，是"没人提前告诉他这次要装十台"。

还有一个关于运维的观察，值得单独说：他往往是最后一个能拦住这个包的人。——客户已经点头了，开发已经放行了，包已经打好放在那里——这时候如果运维说"这批不能装"，前面所有的工作就停在这儿。——而他拦的理由，通常不是"做得不好"，是"我不知道会发生什么"。——"我不知道要装几台"、"我不知道要不要卸载"、"我不知道那个弹框是什么"——这四句"不知道"，全都是可以用一句话填掉的。——所以和运维打交道，最有用的不是技术能力，是"提前把能想到的都说了"。——他不需要你保证没问题，他需要你告诉他"可能会有什么"。

四、四种最常见的打架，以及各自的折中点

三种标准放在一起，会出现四组具体的矛盾。每一组都不是"谁对谁错"，而是"两个都对，但只能选一个更偏的"。

第一组：改得多，还是改得少。——客户想"改得多一点"：花了钱、等了几天，如果只是把按钮从蓝的改成绿的，他会觉得不值。——开发想"改得少一点"：改动越小，下一版越好接。——折中点是：改动的"数量"可以少，但"可感知的变化"要明显。——具体做法：不动结构、不动逻辑，只动看得见的那几处，并且把它们改到位（颜色、字号、间距、文案）。——这样客户看到的是"变了"，开发看到的是"没动结构"。

第二组：清不清爽。——客户（尤其是有审美要求的那种）会说"把没用的都去掉，看着清爽"。——开发听到这句话会紧张，因为"没用的"和"看起来没用的"完全是两回事。——折中点是：只隐藏，不删除。——把不想看到的入口收起来、把碍眼的东西挪到二级页，但文件不删、代码不删。——这样界面清爽了，而"东西还在"这件事，只有开发知道，也只有他在意。

第三组：方便，还是合规。——客户会说"这一步太麻烦，能不能免掉"（比如登录、实名、二次确认）。——运维听到这句会直接否掉，因为那些步骤往往对应着审查要求。——折中点是：把步骤做短，但不做没。——把三个输入框合成一个、把两步确认合成一步、把"记住我"打开——这些都是"少一次操作"，而不是"少一道关卡"。——而"记住登录状态"和"去掉登录"，在客户听来差不多，在运维听来是天壤之别。

第四组：换新签名，还是沿用。——做改包的人常常觉得"换套签名最省事"（因为没有原签名）。——运维听到"换了签名"会立刻问三个问题：那装之前要不要卸载？数据会不会丢？以后还能不能覆盖升级？——折中点在"提前说"，而不是"想办法不换"。——因为原签名你通常拿不到，换是必然的；能做的是把后果说清、把回退方案准备好。————这一组的教训是：有些矛盾不能消除，只能"提前暴露"。

四组矛盾看下来，会发现一个规律：客户要的是"感觉上的变化"，开发和运维要的是"事实上的稳定"。——而这两件事并不真的冲突——冲突的是"变化"这个词，在两边指的是不同的东西。——客户说的"变化"是"我看得出来"；开发说的"稳定"是"结构没动"。——而"只改看得见的那几处"，恰好同时满足两个：客户看得出来，结构一动没动。

五、同一件事，三个人分别在问什么

把三种视角落到具体的六件事上，对照着看一眼就很清楚。

六件事看下来，最值得注意的是最后一件。——客户按了取消，运维不知道怎么解释，开发说"跟包没关系"——三个人说的都对，但结果是"装不上"。——而这件事的解法不是技术，是"提前说一句会弹框"。——所以三方对齐这件事，最大的收益不在"避免技术问题"，而在"避免每个人都认为问题不在自己这一环"。

六、十分钟对齐：六个问题，一次问完

三种视角要对齐，不需要开会、不需要文档、不需要流程。只要在动手之前，把这六个问题问一遍。——十分钟，但能挡住后面大部分"改完了发现方向不对"。

问题一：这次改完，谁会看到变化？——这个问题决定"给谁看"。是给提需求的人看一眼就行，还是要给十个同事用？——这两种情况的验收强度完全不同：前者你自己看一眼就够，后者要按第几节那套五个角色走一遍。

问题二：要装几台？什么机型？什么系统版本？——这个问题必须问运维，或者问"谁负责装"。——如果不问，你会得到"在我手机上能装"这个结论，而这个结论在十台机器上可能只对七台。——而"三台装不上"这件事，会让前面所有的工作看起来像没做。

问题三：这一版之后，还会不会再改？——这个问题决定"改动要留多少余量"。——如果这是一次性的（比如只为了一个活动），那可以改得干脆一点；如果以后还要改好几版，那就必须留痕、必须不动结构。——而这个问题，客户通常答不上来，得去问那个管技术的人。

问题四：万一出问题，怎么退回去？——这个问题最不该被跳过，因为它没有"事后补救"。——要问清三件事：原包在谁手上、回退要不要卸载、卸载会不会丢数据。——如果答案是"原包在你手上"，那你要先把它给对方一份；如果答案是"卸载会丢数据"，那这一版的风险等级要往上提一级。

问题五：有哪些东西绝对不能动？——这个问题要三方一起答，因为每个人心里的"不能动"不一样。——客户会说"公司名不能动"；开发会说"包名和 id 不能动"；运维会说"权限不能加"。——三句合起来，就是这次改动的禁区。——而这个禁区如果只写在你心里，那它等于不存在。

问题六：这次"不做什么"，说清了吗？——这一条是反的：前面五个问"要做什么"，这一个问"明确不做"。——因为三方对齐最容易漏的，是"大家都以为对方会做"的那件事。——比如客户以为你会顺带把图换掉（因为"图旧了"是他最早提的），而你理解成"这次只改名"。——一句"这次不改图，图下一版再说"，能省掉一次"你不是说改吗"。

六个问题有一个共同特点：它们都不是技术问题，但每一个都会影响技术决定。——"装几台"决定了你要不要先在某台老机器上试；"还会不会改"决定了你要不要留痕；"什么不能动"决定了需求里要写多少条"不要"。 ——而如果你只跟客户一个人对接，这六个问题里至少有三个你问不出来——因为它们不在客户的视野里。——这也是"三方看同一个包"这件事真正的价值：不是为了迁就三个人，是为了让那三个只有别人答得出来的问题，有人答。

七、两个我们自己吃过的亏

说两个我们自己的。两个都是"技术上没错，但有一方没被问到"。

例子一：巡检应用，第二次装的时候被安全审查卡住了

以前的改法：第一版是给三台机器装的，改的是界面和提示语，很顺。第二版加了一个小功能——为了让"拍照上传"更顺手，我们在需求里写了一句"拍照后自动保存到本地相册"。——改完自己试了，很好用；三台机器装上，也很好用。

然后这批要装到八台，走安全审查，被退了。——原因不是功能，是权限：为了"自动保存到相册"，包里多要了一个写外部存储的权限。而那边的规矩是"权限清单必须和原来一致"。——审查的人不看功能，只看清单。

这件事最难受的地方是：从头到尾没有一个人做错。——客户想要这个功能、我们实现了、三台机器验证通过——每一步都对。——错的只是"没人问过一句：这批包要过审查吗"。

现在的做法：需求里加一条硬约束——"不要新增任何权限，也不要修改权限声明；如果某个功能必须要新权限，先告诉我，我确认之后再改。"——这一句几乎不花成本，但它把"要不要加权限"这个决定，从"实现的时候顺手决定"变成了"提前确认"。

改完怎么验：两步。第一步，装之前先对一遍权限清单——和上一版对比，看有没有多出来的；第二步，如果有多出来的，先别装，先问清楚这批要不要过审。——这两步加起来两分钟，而它挡住的是"整批包被退回"。

例子二：会员卡小工具，半年后没人说得清改了什么

以前的改法：这个工具前后改了四版，都是同一个人改的，每次改完就发出去，没记别的东西。第四版之后那位同事离职了，第五版轮到别人接。——接手的人打开项目目录，看到四个版本的文件，但没有任何一处写着"这一版改了什么"。

于是他做了一件最稳妥也最费时的事：把每一版都装一遍，一版一版对比。——两个下午，只为了搞清"现在这一版是哪来的"。——而这件事本来只需要四行字。

现在的做法：每一版改完之后，在项目目录里留一份"改动说明"，而且这份说明不用手写——因为每一轮的原始需求原话就存在历史里。——要做的事只有一件：把那一轮的原话复制出来，加一行日期，存成文本。——四行字，就是"这一版改了什么"。

改完怎么验：有个很简单的自检——假设明天有个人接手，他能不能只看目录就知道每一版改了什么？——如果不能，那说明"改动"只活在你脑子里。——而一个人脑子里的东西，是这个项目里最脆弱的部分。

这两个亏，各自对应一个动作，而且都只要几分钟。——第一个动作是"问一句这批要不要过审"；第二个动作是"每一版留一行改动说明"。——它们不是流程，也不是制度，就是两个具体动作。

而它们之所以有效，是因为它们各自对准了一个"信息只存在于某个人脑子里"的东西。——"要不要过审"这件事，只存在于运维的脑子里；"这一版改了什么"，只存在于改的人的记忆里。——而只要它没被写出来、没被说出来，它在需要的时候就不存在。

再往深一层看，三方对齐这件事的本质，其实是"把每个人脑子里的约束搬到纸面上"。——客户的约束是"我要的那件事"；开发的约束是"以后还要改"；运维的约束是"装十台别出事"。——三条约束平时各在各的脑子里，互不干扰；只有当它们同时落到一个包上时，才会互相挤压。——而挤压的那个瞬间，就是返工的开始。

所以"对齐"这个动作，说到底是提前把三条约束摆在一起看一眼。——看一眼的目的是什么？不是让谁让步，是发现"原来这里有冲突"。——而冲突在纸上发现，代价是一句话；在装机现场发现，代价是一整天。——这个差价，就是这篇文章想说清的全部意义。

八、三张清单，各写给自己那一方

和三个人打交道，最省事的办法不是准备一份"通用说明"，而是准备三张清单，各自用对方的话说。——因为同一个事实，用三种说法讲，接受度完全不同。

给客户看的（他关心"变没变"）

一、桌面上图标下的名字（告诉他改成什么，让他自己看一眼）；二、打开后的第一屏（附一张改前改后的对照图，两张并排）；三、那个他不满意的地方（单独说一句"这里改了，改成了什么"）；四、哪些地方我没动（这一条最容易省，但它最能建立信任）；五、如果觉得哪里不对，告诉我是哪一步（给他一个具体的反馈方式，而不是"有问题找我"）。

给开发看的（他关心"还能不能改"）

一、这次动了哪些文件（哪怕只是"三个布局文件加一个字符串资源"）；二、这次没动什么（包名、id、权限、接口、启动逻辑）；三、有没有"看着一样但实现变了"的地方（这一条最专业，也最该主动说）；四、这次的需求原话（他下次要知道"为什么改成这样"）；五、这个包用的是哪套签名（决定以后能不能覆盖升级）。

给运维看的（他关心"装出去会不会出事"）

一、装之前要不要卸载（要，因为签名变了）；二、卸载会不会丢数据（要，所以先导出来）；三、装的时候会弹什么提示（来源未知、未检测之类，提前描述一遍）；四、权限清单有没有变化（这一条对要过审的单位是硬要求）；五、出问题怎么退（原包在哪、退回去要几步、要不要再卸载一次）。

三张清单加起来十五行。——而它们覆盖的，恰好是前面那六件事的全部。——也就是说：你不需要开会、不需要流程，只要把这三张清单各自发一次，三方就对齐了。——而这件事的成本，大概二十分钟。比起"改完之后发现方向不对"的一两天，这个投入产出比不用算。

九、一条需求，怎么写得三方都点头

最后给一个完整的例子。同一件事，先看"只跟客户对齐"会写成什么样，再看"三方对齐"写成什么样。

只跟客户对齐的版本："把首页那个'我的订单'改成'订单'，颜色改成蓝色，看着清爽一点，另外把右上角那个没用的图标去掉。"

这个版本能改出来，但会留三个坑：第一，"颜色改成蓝色"——哪个蓝？按下时什么颜色？深色模式下什么颜色？第二，"把图标去掉"——是删掉还是隐藏？删掉之后那段代码还找得到吗？第三，"看着清爽"——这是感受，不是标准，改完他可能还说"不够清爽"。

三方对齐的版本：

对比一下两个版本，差别不在长度，在"每一句都对准了某一方的担心"。——"按下状态和深色模式"对准的是开发（他怕以后维护时踩坑）；"隐藏但不删除"对准的也是开发（他怕找不回来）；"不要改权限"对准的是运维（他怕过不了审）；"装到小屏和旧系统上看一遍"对准的是运维（他怕十台里坏几台）；"这次不改首页其他入口"对准的是客户（他怕你又顺手动了别的）。

而这份需求，客户看了也会点头——因为他关心的三件事都在里面：名字改了、颜色改了、图标不见了。——这就是三方对齐的真实样子：它不是"折中"，是把每个人的担心都写进去，然后让改动本身变得没有歧义。——而"没有歧义"这件事，对三方都是好事。

十、五个具体的问答

问：三方里有一方根本联系不上，怎么办？

答：把他那三个问题，转给最近的那个人代答。——联系不上运维，就问提需求的人："这批要装几台？装的时候会不会有人管？"——他可能不知道准确答案，但他知道"要不要紧"。——而"要不要紧"这个判断，往往已经够用了：如果他说"就我自己用"，那你不需要准备回退方案；如果他说"要给车间十个人装"，那你就该主动去把运维那条线拉进来。——真正危险的不是"没人答"，是"没人问"。

问：客户和开发的要求直接冲突，听谁的？

答：听"后果更重"的那一方，然后把这个理由告诉另一方。——比如客户要"把登录去掉"，开发说"不能动"——那听开发的，因为去掉登录可能导致整个账号体系失效，后果是不可逆的；而客户要的"少一步操作"，可以用"记住登录状态"来满足。——关键是"告诉另一方理由"，而不是"直接按某一方做"。——因为客户听到"去掉登录会让你的数据跟别人混在一起"，他会立刻同意；而如果他只听到"不行"，他会觉得你不配合。

问：运维说权限不能变，但客户要的功能必须要新权限，怎么办？

答：先确认"是不是真的必须要"。——很多"必须有权限"的功能，其实有替代做法：要写文件的，可以写到应用自己的目录（不需要额外权限）；要读相册的，可以让用户手动选一张（系统会临时授权）。——如果确实没有替代，那就把选择权交给他们：明确说"这个功能需要多一个权限，如果你们那边不能过审，这个功能就得砍掉"。————这句话的作用是：把"技术限制"变成"业务取舍"，让该做决定的人做决定。——而你不该替他们决定，也不该偷偷加上去。

问：我只是给自己公司内部改个包，也要三方对齐吗？

答：如果这三方都是你一个人，那"对齐"就变成"自己在纸上写三行"。——第一行：谁会看到变化（同事）；第二行：要装几台（几台、什么机型）；第三行：出问题怎么退（原包在哪）。——写这三行大概五分钟，而它能避免的，是"装到第三台的时候发现装不上"和"出问题的时候发现原包没了"。——所以答案不是"不用"，是"简化成三行"。

问：三方对齐之后需求长了很多，会不会反而更难改？

答：会长，但长的那部分是"约束"，不是"要求"。——"不要改包名、不要动 id、不要加权限"这些句子，不会让改动变难，只会让它变准。——真正会让改动变难的是"要求模糊"：说"清爽一点"，它就得猜；说"按钮背景改成 #0B62D6，文字白色，深色模式下也要能看清"，它就不用猜。——所以需求变长不一定是坏事，关键看长在哪：长在"不要动"和"具体值"上，是好事；长在"再多加点效果"上，才是坏事。

十一、三种视角落到五个环节上

前面讲的都是"看什么"。这一节把它们落到实际动作上——改包这件事有五个环节：提需求、动手改、打包、签名、交付。每个环节上，三个人各自在意的东西都不一样。而"漏",通常漏在某个环节上某一方没被想到。

环节一：提需求。——客户在意"我要的那件事被写进去了"；开发在意"范围有没有说清"；运维在意"会不会加权限"。——这个环节最容易被"赶时间"跳过，而它的成本最低、收益最高。——具体动作：把需求的五块写下来（要做什么、细节、参数、范围与禁区、验收），三方各看一眼。

环节二：动手改。——客户不在意这一步（他看不见）；开发在意"改动是不是最小、有没有留痕"；运维不在意。——这个环节的特点是：只有一方在意，所以最容易被随便做。——而它的后果会在半年后出现——那时候客户还在，运维可能换人了，只有那个"还要再改"的人会难受。——具体动作：只改说好的那几处，其余一律不动；有"看着一样实现变了"的地方，记一句。

环节三：打包。——客户不在意；开发在意"产物干不干净、有没有残留"；运维在意"包多大"。——这一环节最实用的动作是：只留一个最终产物，把中间产物收起来。——因为中间产物发出去，就是"让对方猜"，而猜的结果通常是装错。

环节四：签名。——客户完全不懂；开发在意"以后能不能覆盖升级"；运维在意"要不要卸载、数据会不会丢"。——这是三方认知差距最大的一个环节：客户觉得"签个名而已"，开发知道"这决定了版本路线"，运维知道"这决定了现场要不要停机"。——具体动作：签完之后主动说一句"这是新签名，装之前要卸载，数据会清掉"，不要等别人问。

环节五：交付。——客户在意"我能不能自己装上"；开发在意"以后找不找得到这个版本"；运维在意"出问题怎么退"。——这一环节的动作，前面几篇讲过：一个文件、四句说明、原包留一份、回退写清。——而它之所以重要，是因为它是唯一一个"三方同时在场"的环节——任何一方没被想到，都会在这里暴露。

五个环节看下来，有个很清楚的规律：越靠前的环节，客户的权重越大；越靠后的环节，开发和运维的权重越大。——而"漏"最常发生在"权重刚刚转移"的那两个环节上——也就是动手改和签名。——因为在提需求的时候你一直在听客户，到了签名才突然需要跟运维对话，而这个转换经常没人提醒你。——所以最实用的一句提醒是：拿到需求的第一天，就把运维那三个问题问掉。别等改完。

十二、夹在三个人中间的人怎么说

十三、夹在中间的那个人，其实在做翻译

把这篇收一下。做改包的人，在这个链条里的角色经常被误解成"技术执行"——别人说什么，你改什么。但实际上，你干的活更接近翻译。

客户说的"清爽"，要翻译成"去掉边框、加大间距、减少颜色数量"；开发说的"别动结构"，要翻译成"不改 id、不改包名、不删文件只隐藏"；运维说的"怕出事"，要翻译成"原包留一份、回退步骤写清、权限不能变"。——三种话，三种语言，最后落到同一份需求里。

而翻译这件事的价值，不在于"让三方都满意"，在于"让改动本身变得没有歧义"。——因为三方对齐之后，你会发现需求变具体了：颜色有了具体值、范围有了明确边界、"不要动"有了清单。——而一份没有歧义的需求，改起来最快、返工最少、也最不容易出意外。——这件事的受益者首先是做事的人，其次才是三方。

还有一个反过来的观察：三方对齐做久了，你会发现很多"冲突"其实不存在。——客户要"变化大"，开发要"改动小"，看起来对立，但"只改看得见的那几处"同时满足两个；运维要"别出事"，客户要"少几步操作"，看起来对立，但"记住登录"和"去掉登录"之间，有一条两边都能走的线。——大部分对立，是因为两边在说不同的东西，而不是因为两边真的想要相反的东西。

只需说话，就能让应用变成你想要的样子。而在有三个人在场的场合，这句话要补一句："你想要的样子"，得先被问清是谁想要、想要哪一部分。——问清了，一句话就够了；问不清，说十句也只是在猜。

安卓修改大师智改工坊的产品页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。它接手的是反编译、替换、打包、签名这些环节，而它顺手做的另一件事，恰好对三方对齐有好处：每一轮的需求原话都留在历史里，项目目录也留着——所以"这一版改了什么"这件事，不需要靠谁的记忆。

---