教会同事自己改包：一次交付，别让自己成为瓶颈

有一种处境，做过几年应用的人都很熟悉：应用本身没什么问题，问题是你变成了它的"人质"。——门店要换一张活动图，找你；加盟商要改一个电话，找你；培训部要把课件里的"第三期"改成"第四期"，还是找你。——而你手上一堆自己的活，这些事每次都只能"晚上弄一下"。

这件事的解法，不是"改得更快"，是"不经过你"。——也就是把改包的能力，交一部分出去。——听起来有点冒险——毕竟这东西一改错，全公司都装不上。但真正做过的人会发现：交出去的风险是可控的，而"不交"的成本是确定的、每天都在发生的。

这篇讲的就是"怎么交"：交哪几件事、留哪几件事、交接之前要固定什么、护栏怎么设、什么时候不该交。——而它有一个前提要先说清楚：交出去的是"操作"，不是"判断"——判断改什么、能不能改、什么时候发，这些永远在你手上。

只需说话，就能让应用变成你想要的样子。而在这个场景里，"你"可能是别人——这就是「安卓修改大师智改工坊」有意思的地方：它的操作门槛低到"会说清楚要改什么"就够了，所以"交给别人"这件事，第一次变得可行。想先看看一句话改一个包的完整流程，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自己的应用试一次，再想"这一步能不能交给别人做"。

一、先认清"瓶颈"长什么样，才知道该交什么

瓶颈这件事，很少被人正面承认。——因为它听起来像"你效率低"，而实际情况恰恰相反：正因为你能改、改得快、改得对，所有事才都来找你。——它是一种"能力导致的拥堵"。

它的表现有三个，都很具体。——第一个是"排队"：一件事从提出到装到机器上，中间要等你空出来——而这个"等"，可能是两天，也可能是一周。——而等待的成本不在你身上，在提需求的人身上：活动已经开始了，图还是旧的。

第二个是"说不清"：别人问你"这个能不能改"，你只能说"我看看"。——因为答案取决于"上次是怎么做的"，而上次是你自己做的，你记得大概，但记不清细节。——于是每个需求都变成一次重新调研，哪怕它和三个月前那个几乎一样。

第三个是"断点"：你一请假、一出差、一忙起来，这条线就断了。——而它断的时候，没有人能接——不是因为难，是因为"只有你会"。——"只有你会"这句话，在绩效上像褒奖，在协作上是负债。

三个表现合起来，指向同一个结论：需要交出去的不是"技术"，是"那几条高频、低风险、重复的操作"。——而判断哪些属于这一类，有一个很朴素的尺子：过去半年里，你改过三次以上的事，就是该交出去的候选。

反过来，过去半年只改过一次、而且每次都要想很久的事，就先别交。——因为低频的事没有"熟练度"，交接的成本比自己做还高。——这也是为什么"把整个应用交出去"这种想法，通常都会失败——它把高频和低频一锅端了。

所以真正可行的第一步，不是"把整件事交出去"，是"先交一件事"。——挑最频繁、最容易验证、最不容易出错的那一件——通常是"换活动图"——把它的完整流程走一遍：他提、他改、他装、他发三张截图。——走通一次之后，第二件第三件会快得多——因为难的从来不是操作，是两个人对"什么算改好了"的标准不一样。——而标准这个东西，只能靠一次真实的交付对齐——说不清，也写不全。

还有一层更细的判断：这件事改错了，后果有多大。——换一张活动图，改错了难看一周，能忍；改一个客服电话，改错了客户打不通，投诉上门；改包名，改错了全员装不上。——所以真正适合交出去的，是"改错代价小、但改的频率高"的那一档——而这一档，往往占了所有改动的七八成。

二、能交的三件事，和不能交的四件事

把"改包"这件整体的事拆开，会发现它其实是三层叠在一起：选素材、改文字、打包发版。——三层里，前两层可以交，第三层只能交一半。

能交的第一件事：选素材。——换哪张活动图、用哪个颜色、封面写哪句话——这些是"商务判断"，业务方本来就应该自己定。——而过去之所以要经过你，只是因为"换图"这个动作需要工具，不需要判断。——现在工具会说人话，这一层就该还给他们。

能交的第二件事：改文字。——活动规则、门店地址、客服电话、公告内容、按钮上的字——这些是"内容"，改错了改回来就是。——而它恰好是过去占用你时间最多的一类：一句话的改动，要重新走一遍打包流程。

能交的第三件事：打包和装机。——这一层可以交"动作"，但要留"规则"。——也就是说：谁都可以点那个"打包"按钮，但用哪份签名、版本号加多少、打完装到哪几台机器上，是定好的、不能临时改。

而不能交的四件事，每一条都对应着一次真实的故障。

不能交的	交出去会发生什么	正确做法
包名	有人觉得"名字不合适"顺手一改，结果变成另一个应用，旧版装不上	只改"桌面显示名"，包名写在操作卡第一行：不许动
签名密钥	每人打自己的签名，装上去互相覆盖不了，现场一片"应用未安装"	密钥由你统一保管，所有人用同一份；不把密钥文件发到群里
版本号规则	两个人各打一版，版本号撞了；或者有人往回改，装不上	约定"谁发版谁加号"，且只往上加；发版前在群里报一句号段
权限与数据相关	把某个入口"藏起来"当权限用，结果换个方式还能进	权限必须在服务端判；界面上的显隐只是"看得清"，不是"管得住"

这张表里最容易被忽视的是最后一行。——因为"把入口藏起来"这个动作，看起来特别像"交出去了"——业务方自己就能做，做完还挺有成就感。——但它不是权限，是遮挡：稍微懂一点的人，换个路径、翻一下页面结构，就进去了。——所以这条要在交接的时候讲明白，否则你会收到一句很难回答的话："我把它藏起来了，为什么他还能进？"

把"能交"和"不能交"分开之后，会发现一个让人安心的事实：不能交的那四条，全都是"一次性设定"——设好之后不用天天动。——而能交的那三条，全都是"天天要动"的。——于是交接的思路就清楚了：把固定的东西钉死，把流动的东西放出去。

三、交之前先钉三颗钉子：母版、签名、命名

交接这件事，最怕"边交边改"。——因为一旦对方在你还没定规矩的时候上手，他会带出自己的习惯——而这些习惯会长在新生成的包里，比他本人留得更久。——所以在把工具给出去之前，先把三颗钉子钉死。

第一颗钉子：母版。——留一份"谁都不许动"的原始安装包，放在一个单独的目录里，文件名前面加"母版"两个字。——它的作用不是"备用"，是"标尺"——任何一次改动之后，如果怀疑改坏了，拿它装一遍对比，就知道是"这次改错了"还是"本来就那样"。

母版这一层还有一个隐蔽的好处：它把"改坏了"和"改丢了"分开了。——"改坏了"能回滚；"改丢了"才是灾难——比如某次改动里顺手删了一张图，后来谁也说不清原来那张长什么样。——而有了母版，任何时候都能拆出来看一眼。

第二颗钉子：签名。——在项目配置里把签名固定下来——用同一份密钥、同一套算法，之后每次打包都不再手动选。——这一颗钉子最不起眼，也最不能省：因为签名一旦在两个人手里变成两种，现场的"应用未安装"就会变成一场排查。

而固定签名这件事，还有一个更实际的理由：它决定了"能不能覆盖安装"。——覆盖安装要三个条件同时成立——同包名、同签名、版本号不低于已装。——这三条里，包名和签名是"设一次、管五年"的，版本号是"每发一次都要动"的。——所以交接的时候，前两个钉死，第三个讲清规则，就够了。

第三颗钉子：命名。——给"改完的包"定一套名字规则，比如"应用名_场景_年月日.apk"。——规则不必漂亮，但必须唯一——因为当三个人各打各的包，最后一定会出现三个都叫"新版.apk"的文件。

名字里带上日期，是一个非常小、但回报很高的习惯。——因为现场反馈问题的时候，第一句话往往是"这个是不是最新的"——而名字里有日期，这句话就能自己回答。——如果还能带上"谁改的"，更好——不是为了追责，是为了"知道该问谁"。

三颗钉子钉完之后，还有一件事要一起定下来：包放在哪。——最省事的做法是"一个共享目录 + 三个子目录"：母版、发布、历史。——母版只读，发布放当前版本，历史按月份归档。——而这一步的意义，是把"找文件"这件事从"问人"变成"翻目录"。

四、两个自家应用的实例：一次交"换图"，一次交"改字"

抽象地讲"交出去"很难判断分寸，落到两个真实的例子上就清楚了。——这两个应用都是我们自家做的，也都真的交出去过——一次交给了区域运营，一次交给了加盟督导。

第一个：门店活动端，交的是"换图"。——这个应用是给门店店员看活动规则、看主推商品、看当日任务的。首页顶部有一张活动图，一个月换两次。

以前怎么做：运营把图发到群里，我看到之后下载、改名、打开项目、替换图片资源、重新打包、签名、传回群里，运营再一台台装。——一次大概四十分钟，一个月两次，一年二十多次。——而最容易被拖的时候，恰好是活动上线前一天——也就是我最忙的时候。

现在一句话怎么做：运营自己在「安卓修改大师智改工坊」里打开这个项目，说一句"把首页顶部的活动图换成这张，标题改成'夏日饮品第二件半价'"。——工具会找到对应位置替换掉，打包、签名走固定配置，产出一个带日期的包。——然后她自己装到那三台演示机上。

改完怎么验证：装到一台"装着旧版"的机器上覆盖安装，看三件事——顶部的图是不是新图、标题文字有没有超长被截、其他页面有没有被连带改坏。——第三步最关键：因为"替换图片"这个动作，有时候会连带影响到同名的其他资源。——所以我们定了一条规矩：每次改完，把首页、列表页、详情页各截一张图发到群里——三张图，比一句"改好了"可靠得多。

第二个：加盟门店端，交的是"改字"。——这个应用给加盟门店用，页面底部有一个"联系店长"的电话，另有一个"售后服务"的电话。——这两处号码，每家门店都不一样。

以前怎么做：督导在群里报"某店换了店长，电话改成 XXX"，我改一次、打一次包、发一次。——一年下来改了三十多次，每次都是一个数字的差别。——而这里有一个很典型的坑：客服电话往往不止一处——首页、关于页、提交成功的提示里，都可能藏着一个。——第一次改的时候我就漏了一处，结果客户打完首页的号码，页面里还显示着旧号。

现在一句话怎么做：督导自己打开项目，说一句"把这个应用里所有的客服电话都改成 400-xxx-xxxx，门店电话改成 021-xxx-xxxx"。——注意这里说的是"所有"——因为在交接的时候，我们已经把"这个应用里电话出现在哪几处"写进了操作卡。——而这一句"所有"，就是从那次漏改里长出来的。

改完怎么验证：装上去之后，把每一处电话都点一遍——不是看它显示什么，是看它拨出去是什么。——因为显示和拨号是两件事：显示改了、拨号链接没改，是最常见的错。——验证完还要做一件事：在这家门店的应用"关于"页上看一眼版本行，确认装的是这一版，不是上一版。

两个实例对照着看，能看出"交什么"的分界线：换图交的是素材选择，改字交的是内容维护——两者都不涉及结构、不涉及权限、不涉及包的身份。——而它们恰好是过去最占用时间的两类：一件事重复二十次，一件事只需要改一个数字，却要走完整条流水线。

五、护栏怎么设：让"改错"变成一件能被发现的小事

把工具交出去，必然有人会改错。——这不是风险，这是概率——做过二十次的人也会改错一次。——所以真正的目标不是"保证不改错"，而是"改错之后，能在十分钟内被发现、能退回上一版"。

第一道护栏：只读的母版目录。——把原始包和"上一版发布包"放在一个只读目录里，任何人都不能覆盖。——为什么是"上一版"也放进去？因为绝大多数"改坏了"的时刻，需要的是"退回上一版"，而不是"退回最初版"。——而上一版往往就在你自己的下载文件夹里，被新文件挤掉了。

第二道护栏：改完必须装一遍。——不是"我打出来了"，是"我装上去了"。——这两句话的差别，是整篇文章里最实际的一条经验：包能打出来，不代表能装上去；能装上去，不代表界面是好的。——而"装上去了"这一步，只有真正装的人才知道。

第三道护栏：三张截图。——改完发三张图到群里：改的那个页面、它的上一级页面、以及一个"看起来不相干"的页面。——第三张图不是形式主义——因为替换资源、批量改文字这类操作，最容易在"看起来不相干"的地方留下痕迹。——而人一旦知道要发三张图，他自然会多看两眼。

第四道护栏：一行台帐。——日期、改了什么、为什么改、谁改的。——四列，一行，三十秒。——它的用处有两个：一是当有人问"这个为什么是这样"的时候能翻；二是当同一件事被两个人改了两遍的时候能看出来。

第五道护栏：发版前报一句号。——谁要发版，在群里说一句"我要发 1.4.7"。——这句话看起来多余，却能挡住一种很难查的事故：两个人同时打包，版本号撞了，一个人装的包被另一个人覆盖，最后谁也不知道自己装的是哪一版。

五道护栏里，前两道是"防错"，后三道是"发现"。——而现实里，"发现"比"防错"更重要——因为防错只能防住你想得到的错，发现能接住你想不到的错。

这些护栏还有一条隐含的好处：它们把"信任"变成了"流程"。——没有护栏的时候，你把工具交出去，靠的是"我相信他不会乱改"；有了护栏，靠的是"改错了也能收回来"。——而后者不需要信任做前提——这恰恰是"能长期交下去"的关键。

六、交出去之后，你的角色变了：从"做的人"变成"定规矩的人"

很多人在交接的第一步就走偏了：他交出的是"操作方法"，留下来的是"审批权"。——结果对方每改一次都要问"这样可以吗"，他还得回，比自己做还累。——真正的交接，交出的是"决定权 + 责任"，留下的是"规则 + 兜底"。

留下的一：包的身份。——包名、签名、版本号的规则，永远在你手上。——因为这三件事一旦被"临时灵活"处理一次，代价就是全部门的卸载重装——而这个代价不会落在改的人身上，会落在装的人身上。

留下的二：发版节奏。——不是"什么时候改"，是"什么时候发"。——改动可以随时，发版最好有个节奏——比如每周一次集中发，或者"急事随时发，不急的攒到下周一"。——因为现场最怕的不是"改得慢"，是"一天变三次"——早上装的版和下午装的版不一样，出了问题谁也说不清是哪个版的问题。

留下的三：兜底。——当他们改坏了、改出了装不上的包、或者改出一个"看着没问题但其实错了"的版本，得有人能接住。——而这个"接住"的能力，靠的不是你记得怎么做，是母版和上一版还在、项目目录还在、配置还在。

角色变了之后，有三件事的处理方式也要跟着变。——第一件：他改错了。——不要第一反应是"我来改"——那等于把权收回来了。——正确的做法是让他自己退回上一版，然后一起看是哪一步错了；下一次他就不需要问你了。

第二件：他改得和你不一样。——比如他用了一个你觉得不好看的颜色、一句你觉得别扭的话。——只要不违反那四条"不能交的"，就让他去——那是他的判断范围。——而"不好看"这件事，很快会在现场自己纠正：门店会说"这个颜色看不清"，比你说十遍有用。

第三件：他改出了一个"更好的做法"。——这是交接里最值得高兴的事，也是最容易错过的事。——因为一个天天在现场的人，会想到你完全想不到的改法——比如"把查询按钮放到键盘上方"、"把最常查的三个字段提到第一行"。——而这类改动，往往比任何一次"功能升级"都更解决问题。

把这三件事串起来看，会发现交接真正的难点不在技术，在心理。——因为"只有我会"这件事，会带来一种很微妙的安全感——它让你显得重要，也让你不敢休假。——而交接的本质，是把这种安全感换成另一种：不是"只有我会"，是"这套规矩谁都照着做都对"。——后者不显眼，但它能让你在休假的时候，手机是安静的。

七、操作卡只写两页：写多了没人看，写少了会出事

交接的时候，最容易被写坏的东西就是"文档"。——有人写了三十页，把反编译原理、资源目录结构、签名算法全写上——结果对方只看了一页。——有人什么都不写，靠讲——讲完当时都懂，一周后全忘。

两页纸，是这两种极端之间最省力的那个点。——第一页写"怎么做"，第二页写"什么时候不能做"。——而这两页的目标读者不是"新人"，是"三个月后偶尔改一次的自己"。

第一页的写法有一个诀窍：不写"步骤"，写"句子"。——因为在这个工具里，真正的操作是"说一句什么"——所以操作卡上最该抄下来的，是那几句已经验证过的话。

比如："把这个应用里所有的客服电话改成 ×××"、"把首页顶部的活动图换成这张"、"把启动页的背景色改成品牌蓝"、"在关于页把版本行加一句'XX 门店专用'"。——四句话，覆盖了八成的日常改动。——而它们的共同点是：说清楚了"改哪里"和"改成什么"，没有一句含糊。

这里有一条反过来的经验：写得含糊的句子，改出来的结果一定含糊。——"把界面弄得清爽一点"、"字体大一点"——这类话改出来的东西，十次有八次不是你要的。——所以在操作卡上，除了"该怎么说"，还要写一句"别这么说"——把那些含糊的说法列出来，比解释一百遍原理有用。

第二页的写法更简单：五条"不许"。——不许改包名；不许换签名；不许把版本号往回改；不许把"藏入口"当权限；不许在没装过的情况下把包发到群里。——每条后面跟一句"为什么"——一句话就够，比如"签名一换，所有人都得卸载重装，聊天记录会没"。

"不许"后面那句"为什么"，比"不许"本身更重要。——因为人不会因为"规定"而不做，只会因为"知道后果"而不做。——而后果说得越具体，越管用——"会出问题"没用，"会装不上、聊天记录会没"有用。

操作卡上还有一行值得写：环境。——哪个系统、装在哪台电脑、项目放在哪个盘、工具装在哪里。——因为交接三个月后最常发生的事，不是"忘了该怎么说"，是"换了台电脑，什么都不在了"。——而这一行只要一句话：Windows 桌面端，项目在 D 盘 apk 目录下，母版在共享盘的只读目录里。——它看起来像废话，实际却是唯一能让"换个地方也能接着做"的信息。

两页纸写完之后，还有一个动作：把它贴在项目目录里，而不是发在群里。——因为群里的文件三天就沉底了，而项目目录里的那张纸，谁打开项目都会看见。——而"看见"这件事，比"收到"重要得多。

八、五个最常被问到的问题

问题一：交给别人之后，他改出来的包和我的不一样，怎么办？

先看"不一样"在哪一层。——如果是文字、图片、颜色不一样——那是他的判断，随他去。——如果是包名、签名、版本号那一层不一样——那是事故，必须停下来。——而判断的方法很直接：把两个包都装一遍，看能不能互相覆盖——能覆盖，说明身份没变，那点不一样无伤大雅；不能覆盖，说明身份变了，要立刻回退。

问题二：只有一台电脑，我和他都要用怎么办？

不要共用同一个项目目录。——因为两个人交替改同一个项目，配置会被互相覆盖——比如他最后换的那份签名会留在配置里，你下次打包就用了他的。——更稳的做法是"一人一份项目"——母版包是同一份，各自建项目，各自改，产出各自带名字的包。——而"统一签名"这件事照旧：两个项目用的是同一份密钥文件，所以产出的包可以互相覆盖。

问题三：他改完没装就发出去了，已经装了五六台，怎么办？

先别慌，按"三步"走。——第一步，确认"坏在哪"——是装不上、还是界面坏了、还是某个功能点不动了。——第二步，如果界面坏了，立刻把上一版拿出来，一台台覆盖安装回去——因为同包名同签名，覆盖安装不用卸载，数据都在。——第三步，等现场都退回去了，再回头查原因。

这里面最值得记住的一句话是"先退回去，再查原因"。——因为人在现场一边等、你一边查，压力会把你推到"赶紧再打一版"的路上——而"再打一版"往往会让问题变成两个问题。

问题四：能不能干脆把工具和母版都拷给他，让他自己全权处理？

可以，但要先想清楚一件事：出了事，谁负责。——如果他是你的同事、用的是公司的账号、改的是公司的应用，那"全权"没问题，只要母版和签名还在你手上。——如果他是外部的人——加盟商、渠道、客户——那就不能"全权"：因为包一旦离开你的控制，它长什么样、传给了谁，你都说不清。

对外的做法，通常是"你改、他选"。——也就是他提需求（要哪张图、要什么文字），你改，改完把包给他。——中间那一步"打包"留在你这边——因为它决定的不是"好不好看"，是"这个包是谁的"。

问题五：交出去之后，我怎么知道他们真的在按规矩做？

不要靠"检查"，靠"顺手能看见"。——三个动作就能做到：让他们改完发三张截图（你能看见界面）、发版前报一句版本号（你能看见号段）、台帐共享一份（你能看见频率）。——而这三样东西都是"顺手就能做"的，不额外增加负担——这一点很重要，因为任何需要"专门去做"的规矩，都会在两周内消失。

五个问题里，其实只有一个共同答案：把"判断"和"操作"分开。——操作可以分散到很多人手上，判断最好集中在一个地方。——而判断集中的方式，不是"都要问我"，是"规矩写下来、母版留着、密钥管住"。

九、有三种情况，最好先别交出去

前面讲的都是"怎么交"，这一节讲"什么时候别交"。——因为交接失败过一次的人，往往会得出一个错误的结论："这东西不能交给别人。"——而真相是：不是不能交，是在那三种情况下，交出去必然失败。

第一种：对方没有"一个稳定的人"。——这一条最容易被忽略，却最致命。——如果那边是"谁有空谁弄"，那这套规矩永远立不住——因为规矩需要记忆，而记忆需要同一个人。——而"谁有空谁弄"的地方，最后一定演变成"谁都不会，还是找你"。

判断的方法很简单：问一句"这件事以后是谁负责"。——如果对方能立刻说出一个名字，可以交；如果对方说"我们轮着来"或者"大家一起"，先别交。——因为"一起"在责任上等于"没人"。

第二种：改动频率低于一个季度一次。——这一条会让人意外——因为它和"我需要减负"的直觉相反。——但对低频的事，交接的成本是"教一遍 + 写两页 + 随时答疑"，而收益是"一年省四次打包"。——而人学会一个"三个月才用一次"的操作，三个月后必然忘——忘了又得问，你还是被占着。

对低频的事，更划算的做法是"模板化"而不是"交接"。——也就是把这件事的做法写成一段固定的话、准备一套固定素材，下次你自己五分钟做完。——而这一步花的时间，比教别人少得多。

第三种：改动涉及钱、权限、或者"必须有留痕"的动作。——比如价格显示、优惠券规则、谁能看到哪个页面、谁能提交什么数据。——这些不是"改包"能解决的问题——它们要么在服务端判，要么根本不该靠改界面来做。

这一条最典型的误区，是"把入口藏起来当权限"。——藏起来这件事，改包能做、谁都做得来，所以看起来特别适合交出去；但它只是"看不见"，不是"进不去"。——而一旦有人"还是进去了"，问题就从"界面"变成"数据"——那时候再解释"我当初只是把按钮藏了"，是解释不通的。

三种情况合起来，其实是一条：交接的前提是"这件事重复、低风险、有人负责"。——三个条件缺一个，交接就会变成"把麻烦搬了个地方"——从"我做"变成"我教别人做，然后收拾他做错的"。

而这三个条件，恰好也解释了为什么"换图"和"改字"最适合交出去：它们高频、改错代价小、而且一定有一个人在负责（运营、督导、店长）。——而"改权限"、"改价格逻辑"、"改包结构"，三条全不满足——所以它们留在你这儿，不是因为你舍不得，是因为它们本来就不该走这条路。

十、一张交接清单：交付那天照着勾一遍

交接最容易出问题的地方，不是"教得不好"，是"漏了一样东西"。——而漏掉的东西，往往在两周后才被发现——那时候你已经不在旁边了。——所以交付那天，最好有一张单子，勾完再走。

交付项	交的是什么	怎么算交到了
母版包	一份原始安装包，放在只读目录	对方能自己找到，且知道"这个不许动"
上一版发布包	当前线上跑的版本，带日期命名	改坏了能立刻拿出来装回去
项目目录	已反编译好的工程，配置里签名固定	打开就能改，不用重新反编译
签名密钥	同一份密钥 + 密码，统一保管	打出来的包能和旧版互相覆盖
两页操作卡	四句固定说法 + 五条"不许"	放在项目目录里，不是发在群里
一张台帐	日期 / 改了什么 / 为什么 / 谁改的	双方都能写，且写了两行以上
一个"能问的人"	出问题时第一个该找谁，电话写清	对方手机里存了这个号

这张表里最容易被漏掉的是最后一行。——因为前面六项都是"东西"，最后一项是"人"。——而现实是：真出事的时候，对方不会去翻操作卡，他会直接打电话。——所以"能问的人"这一项，一定要写成具体的名字和号码，而不是"有问题找我"。

还有一项虽然没写进表里，但值得单独说：交付那天，让对方自己从头做一遍。——不是"看着你做"，是"他自己做，你在旁边不说话"。——他卡住的地方，就是操作卡缺的那句话。——而这一步，是整场交接里性价比最高的二十分钟。

为什么强调"你在旁边不说话"？——因为人在旁边的时候，会忍不住提示——而一提示，那些"本来会卡住"的地方就被掩盖了。——而等你走了，那些地方会一个个冒出来，变成一条条微信消息。

这张表有一个用法上的细节：它是给自己勾的，不是给对方填的。——因为一旦变成"对方填完交给你确认"，它就成了一张审批表——而审批表会让人紧张，紧张会让人不敢动手。——所以更好的做法是：你自己对着它看一遍，缺什么补什么，把补齐的东西放到该在的位置上，然后说一句"可以了"。——而这三个字，比任何一张签过字的表都更能推动这件事。

勾完这张表，交接其实只完成了一半。——另一半在两周后：那时候你要主动问一句"最近改过吗、有没有卡住的地方"。——因为大部分交接不是"没学会"，是"学会了但没敢用"——而一句主动的问，往往就能把这件事推过那道坎。

十一、真正的验收在两周后和三个月后

交接这件事有一个很典型的错觉：交付那天聊得很好，两个人都觉得成了。——而真正的答案，要在两周后和三个月后各看一次。——这两次验收不用开会，看三个信号就够了。

两周后的三个信号。——第一个：他有没有自己改过一次（不是你催的）。——第二个：改完有没有发那三张截图。——第三个：台帐上有没有多出一行。

这三个信号里，第一个最关键。——因为"学过"和"用过"之间，隔着一次"敢不敢自己动手"。——而这一次往往需要一个契机——正好有个活动要换图，正好有个电话要改。——如果没有这个契机，交接就会停在"我知道了"，然后在三个月后彻底忘掉。

所以有一个很实用的小动作：交付之后，主动给他安排"第一次"。——比如"下周那个活动图，你来改吧，我在旁边看着"。——这不是客气，是必要——因为第一次成功了，后面就顺了；第一次卡住了，后面就再也不敢碰。

三个月后的三个信号，判断的是"这套东西有没有真的立住"。——第一个：你被问的次数，是变少还是变多。——第二个：他改出来的包，有没有出现过装不上的。——第三个：现场有没有出现"两个版本对不上"的情况。

第一个信号最容易误判。——因为刚交接完的那两周，问的次数一定上升——这是正常的，是"从学着做变成做着学"。——而三个月后如果还在问同样的问题，说明操作卡缺东西，或者规矩没立住。——而这时候该做的不是"烦"，是回去把那句话补进操作卡。

第二、第三个信号，指向的是"固定项有没有被松动"。——因为三个月足够发生很多事：换电脑、重装系统、清理下载目录、某个人"顺手"改了一下签名。——而这些动作，都会在某一天变成"装不上"。——所以三个月后做一次覆盖安装验证，是很有必要的——十分钟，能提前发现一个可能拖一周的问题。

还有一个更隐蔽的信号：你自己是不是还在"顺手代做"。——因为"顺手"这件事最伤人——对方刚要动手，你说"我来吧，快"——一次两次之后，他就再也不动手了。——而你自己也会觉得"还是我来快"，于是绕回原点。

所以交接真正的验收标准，不是"他会不会"，是"这件事还需不需要我"。——而这一条，只有在你真的忍住不动手的时候，才看得见答案。——而这个答案，往往要等到某一天你请假、他没找你、事情照样办完了——那一刻，交接才算完成。

十二、用过的人怎么说

五条反馈，讲的是五件很具体的事：出差三天被迫放手、一条"装过才许发"、签名统一、该留的那一步别给出去、以及那句"我在旁边一句话不说"。——而它们合起来，正好是这篇文章的骨架：交什么、钉什么、留什么、怎么验。

第三位那句"现场开始出现'你们发的到底是哪个版'"，值得所有做交接的人记一下。——因为这句话描述的，不是技术问题，是"身份"没了——两个包看着一样、装得上、但互相不认。——而这类问题最难查——因为它不出错，只是"对不上"，而"对不上"要等到某一台机器上的数据不对时，才会被发现。

---

只需说话，就能让应用变成你想要的样子。——而"你"是谁，其实可以变——当一句"把客服电话都改一下"连不写代码的人也能说清楚，交接这件事就不再是"把技术教出去"，而是"把一句话交出去"。——剩下的交给安卓修改大师智改工坊：它把反编译、改资源、打包、签名这四步压成一句话，让"交给别人"变成一件真的敢做的事。