改包这门活的回头客：第一次之后你留下了什么

做改包这类活，第一次和第二次之间的差别，比想象中大得多。

第一次，靠的是"你能做"。他有个包要改，问了几个人都不会，你会，于是就找你。这一次的成交几乎不涉及信任，只涉及"有没有人会"。

第二次就不一样了。他会做一件事：在脑子里比较"再找你"和"换个人"的成本。——而比较的内容，基本不是"上次改得好不好"，是"上次跟这个人打交道累不累"。

"累不累"这件事，拆开看是三样东西：他有没有重新解释一遍需求、你多久能给他、出问题的时候你什么反应。——而这三样，全都不取决于你的技术水平，取决于你第一次做完之后"留下了什么"。

这篇讲的就是这三样。以及一个有点反直觉的判断：真正让人决定"下次还找你"的时刻，往往不是你交得漂亮的那一次，而是出了问题的那一次。

只需说话，就能让应用变成你想要的样子。而在"回头客"这件事上，这句话还有半句：如果每一轮他都得重新说一遍，那这句话对他来说是"每次都要说"，而不是"说一次就行"。——而"说一次就行"，恰恰是这门活里最值钱的东西。

一、先看清：回头客不是因为"改得好"

这句话听起来有点刺耳，但它是有道理的。因为"改得好"这件事，客户的判断力有限——他没法判断你的实现质量，他只能判断"我要的那件事有没有发生"。——而"那件事发生了"是一个门槛，不是一条阶梯：过了就是过了，再好他也感知不到。

所以真正决定他会不会再找你的，是另外三件事。

第一件：他下次要不要重新解释一遍。——如果他下次说"还是上次那个应用，再改个地方"，你能直接接上，那成本很低；如果他得从头说"我这个应用是干什么的、上次改了什么、现在是什么样"，那他会想"换个人是不是也这样"。——注意这一条的关键：他不是嫌麻烦，他是嫌"这件事没有积累"。——而"没有积累"会让人觉得"上次那笔钱只是一次交易"。

第二件：他要等多久。——第一次你花了半天，他觉得正常；第二次同样一个小改动你还是花半天，他会开始算。——而如果你能"十分钟就给他"，他会有一种很具体的感受：这个人手里有我的东西。————这种感受跟技术无关，跟"有没有留东西"有关。

第三件：出问题时你的反应。——这一条最重，因为它发生在他最不安的时候。——而人在不安的时候记住的东西，比在顺利的时候记住的深得多。——你处理得干脆，他会记很久；你推诿一次，他也会记很久。

三件事有一个共同点：它们都是"第一次做完之后"才成立的。——也就是说，第一次交付不是终点，是"你开始积累"的起点。——而大多数人在这里犯的错是：把包发出去，这件事就结束了——需求没存、目录没整理、说明没写。——于是第二次来的时候，你和一个新人没有区别。

补一段为什么是"之后那三分钟"，而不是"之后那三天"。——因为三分钟之内，你手上还热着：文件在下载目录里、需求在输入框里、刚才改的那一处你闭着眼都能说出来。——而三天之后，这三样东西都凉了：文件不知道存哪了、需求只记得大意、改的那一处你要打开界面才想得起来。————于是"留东西"这件事，从"照着抄一遍"变成了"考古"；而人不会为一件考古工作付出三分钟。

这也解释了为什么大部分人的"项目目录"都是一团乱：不是懒，是每次想整理的时候，都已经过了那个"顺手就能整理好"的窗口。——而窗口只有三分钟。——所以这篇里所有的建议，都指向同一个时机：交出去的那一分钟，别关电脑，先把三件事做完。

二、第一样要留的东西：需求的原话

先说最容易被忽略、也最省事的一样：把每一轮说的那句话，原封不动地留着。

注意是"原话"，不是"总结"。——很多人会留一个"改动清单"：改了按钮颜色、隐藏了图标、加大了字号。——这个清单有用，但它丢了两样东西：一是"边界"（原话里通常有"别的都不要动"），二是"语气"（原话里能看出他到底在意哪一点）。

举个例子。原话是："把首页那个'我的订单'改成'订单'，颜色也换一下，要不太显眼，别的地方别动。"——总结可能写成"改文案+改颜色"；而原话里有三件事：改什么（文案）、改成什么感觉（不太显眼）、不许动什么（别的地方）。——下次他说"再改一下那个订单"，你翻出原话，就知道"不太显眼"是他的偏好——这一条是总结里没有的。

这类工具通常会把每一轮的原话存下来——它留的是你打进输入框的那段文字本身，一轮一条，按顺序往上加。所以"留原话"这件事，很多时候你不需要额外做什么，只要别把历史清掉。——而这里有个很实际的提醒：清历史就是删记录，删掉之后找不回来。所以如果某个项目还要改，就别动它。

留原话的用法，具体有三种。

用法一：下次直接复制、改几个字。——这是最省力的用法。第二次的需求，通常和第一次有七成相同（同样的应用、同样的禁区、同样的风格要求），只有三成要改。——而复制过来改，比重新写省一半时间，而且不会漏掉"不要动"那一串。

用法二：出问题时对账。——他说"我要的不是这个"，你把原话调出来念一遍，两个人立刻就回到了同一个起点。——而"念原话"这个动作，比"我记得你说的是"有说服力得多——因为它不带情绪，只带事实。

用法三：交接给别人。——如果你要休假、或者这个活要转给同事，一串原话就是最好的交接材料。——他不需要问"这个应用之前改过什么"，往上翻就行。——而这件事的意义在"回头客"这个话题里很实际：一个能交接的活，才是一个能持续的活。

最后说一个反过来的好处：原话留多了之后，你会开始写得更清楚。——因为你知道它会一直被留着，而且会被未来的自己翻出来——那种"三个月后要能看懂"的压力，会让你的需求从一开始就写得完整。——而写得完整这件事，本身就能省掉一轮返工。

三、第二样：项目目录本身

第二样东西比第一样"重"，但它带来的差别也更大：把整个项目目录留着。

为什么重要：因为一个项目目录里装的不只是文件，是"这个应用的现状"。——包括反编译出来的内容、这一轮的配置、打包的产物、日志。——而"下次再改"这个动作，本质上是在这个现状上再动一次——如果现状没了，你就得从"导入原始包"重新开始。

而"从原始包重新开始"和"在现状上改"，差别有多大？——举个具体的：如果上一次改了十处，这次要在那十处的基础上再改一处。——没有项目目录的话，你得先把那十处重说一遍（因为原始包里没有），再叠上第十一处。——而"重说一遍"这件事，几乎必然会有遗漏——而遗漏的那一处，就是你这次要背的锅。

所以第二样东西的真正价值是：它让"第二次"变成"接着做"，而不是"重做一遍"。——而这个区别，直接体现在你回复他的那句话上："好，十分钟。"还是"我看看，明天给你。"

留项目目录有三个要点，都很具体。

要点一：别放在"临时"的地方。——临时目录会被清理，桌面会被整理，下载文件夹会被一键清空。——这些地方都适合"临时放一下"，但项目目录不是临时的——它是一个要活几个月的目录。————具体放哪儿？一个固定的、你自己知道的地方，比如工作盘的一个"项目"目录下面。

要点二：一个应用一个目录，名字用应用名。——不要用"客户A"、"第一个活"这种名字。——因为三个月后你只记得"那个巡检的应用"，不记得"客户A"是谁。——而"巡检"这个词，是你能顺着找到它的唯一线索。

要点三：每隔一段时间，整个目录拷一份到别的地方。——不用很勤，一两个月一次就够。——因为硬盘坏、系统重装、手滑删掉，这三件事都发生过；而它们的共同点是：发生了就没法补救。——而一次拷贝，成本几乎是零。

三个要点都不难，难的是"第一次做完的时候有没有想到"。——因为第一次做完，你满脑子都是"终于交了"，很少有人会在那个时刻想"三个月后我还要用它"。——而回头客这件事，恰好就发生在三个月后。

四、第三样：那份没人看的交付说明

第三样东西是四句话。它可能是这三样里"看着最没用"的一样——因为它不是技术活，也不影响包能不能跑。——但它在"回头客"这件事上的作用，往往比前两样更大。

先说清它为什么有用。——因为客户拿到一个 apk 文件的时候，其实是有三个疑问的：这个装哪儿？装之前要不要做什么？装完怎么知道成了。——如果这三句没人说，他会自己去试；试的过程中出任何一点岔子，他就会停下来，然后开始怀疑这个文件。——而"怀疑文件"这件事一旦发生，他下次就更倾向于"换个人"。

四句话长这样：

四句话，不到一百字。——而它覆盖的，恰好是他自己试的时候最容易卡住的四处。——注意第二条那半句"卸载会清掉数据"：这句话说出来，会让他觉得你在替他考虑；不说出来，等他发现数据没了，那就是另一件事了。

而这四句话还有第三个作用，很少有人想到：它是一份"这次交付的凭据"。——因为在四句话里，你把"装什么"、"有什么后果"、"怎么算成功"都写清了。——万一后面有争议，这份说明就是双方共同的起点；而没有它，争议只能靠回忆。

还有一个更实际的用法：把它做成模板。——第一份写完之后存下来，以后每次只改文件名和第四句（"装完怎么确认"），其余三句基本不变。————因为"要卸载"、"会弹提示"这两件事，只要签名换了就永远成立。——于是第二十次交付的时候，你只需要三十秒。

顺便说一句"版本命名"这件事，它属于同一类。——文件名里带上"改了什么"和"日期"，成本是十几个字，收益是"他打开下载目录就知道哪个是新的"。——而这个收益会以另一种方式回来：他不会再问你"哪个是最新的"，你也不用再回一次。————这些小事加起来，就是"跟这个人打交道不累"。

五、真正决定回头的那一次，是出问题的那一次

这一节讲一件我认为最重要的事。

顺利交付十次，客户对你的印象是"还行"；出一次问题并处理干净，印象会变成"这个人靠得住"。——原因很朴素：顺利的时候，他没机会看你怎么做事；出问题的时候，他看到了。

而出问题时，人只有三种反应。

第一种：推。——"这个不是我改的地方"、"你手机的问题"、"可能是系统版本太老"。——这些话可能都是真的，但它们的效果是一样的：对方感到"你不打算管"。——而"你不打算管"这个印象一旦形成，他下次就会先找别人。

第二种：拖。——"我看看"，然后三小时没消息。——拖的问题不是"慢"，是"没有回音"。——因为他在那个三小时里什么都做不了——不知道要不要先停用、不知道要不要通知别人、不知道该不该找别人帮忙。——而"不知道"比"坏消息"难受得多。

第三种：接。——接的具体做法是两句话："我现在看"，和"半小时后不管有没有结果，我都回你一句"。——第一句让他知道你开始处理了；第二句让他可以去做别的事。————而"不管有没有结果都回一句"这件事，是这三种反应里唯一一个"不需要你聪明"的动作。

接完之后，第二句话该问什么？——不要问"怎么坏的"，要问"你是在哪一步发现不对的"。——因为"怎么坏的"问的是原因，他答不上来；"哪一步"问的是动作，他答得上来。——而拿到"我打开之后点了积分那一栏，显示的是中文"这句话，你就有了一个可以查的东西。

最后说清一件事：接，不等于"承认是自己的错"。——它只等于"这件事我来处理"。——而这两件事在客户那里的区别很小，在你这里区别很大——因为如果你把"接"理解成"认错"，你就会本能地去推。————而推的代价，往往比那个错本身大得多。

再补一个很实在的细节：这四句话怎么写，对方才真的会看。——三个原则。——第一，编号，不要写成一段话。——因为一段话会被跳过，编号会被一条条照着做。——第二，第一行就是"装哪个"，把文件名加粗。——因为绝大部分人打开消息只找一件事：装哪个。——第三，别用技术词。——"签名不同"可以写成"这个包和旧版不是同一套签名，所以系统不认旧的"——后者长一点，但它能让人明白"为什么必须卸载"。————而"明白为什么"这件事很重要：一个人如果不知道为什么，他会在某一步自己发挥；而自己发挥的结果，往往是装不上。

六、两个我们自己的例子，一个好一个坏

说两个我们自己的。一个是"留了东西"的，一个是"没留"的；两件事几乎同时发生，结果完全不同。

例子一：巡检应用，第二次只花了十分钟

第一次的做法：改的是"首页那句提示语往上挪、字号加大"。改完我们做了三件事（当时只是顺手）：把需求原话留在历史里、把整个项目目录留在项目列表里没删、发了一份四句话的说明。

第二次来的时候，是两周后："再帮我改一下，那个提示语位置对了，但字还是小了点，而且我想让它颜色深一些。"——如果我们没留东西，这时候要做的是：重新导入原始包（因为原始包已经不知道在哪了）、重新说"挪位置+加大字号"、再叠上"再大一点+颜色深一点"。——而三段叠加的需求，最容易出的问题是"改完发现原来的挪位置没保住"。

实际做的是：打开原来那个项目，把上次的原话复制出来，在后面加一句"字号再加大一档，颜色改成 #334155"。——打包，装上，并排看两版，发出去。——从收到消息到发出去，十分钟。

后面的三次，全是这个模式。——而那位对接人后来跟别人介绍我们的时候说了一句话："他们手上有我们的东西，改起来特别快。"——这句话我记了很久，因为它一句都没提"技术"。

改完怎么验（这个例子里我们的固定动作）：第一步，并排看上一版和这一版——确认"原来挪的位置还在、只变了字号和颜色"；第二步，装到那台旧机器上看一眼——因为字号这件事在小屏上最容易出问题；第三步，把这一版的原话存好——它是下一次的起点。

例子二：会员卡工具，第二次要重做一遍

第一次的做法：改的是"首页按钮颜色和圆角"。改完我们只做了一件事：把包发过去。——项目是当场建的，改完觉得"这个活完了"，就从项目列表里删掉了；需求是打字说的，没有另外存；说明也没写，因为"他看着界面就知道装哪个"。

一个月后第二次来："再改一下，那个按钮再显眼点，另外首页那个广告位想挪到下面。"——这时候我们发现：原始包找不到了（当时是从邮件附件里直接导入的，附件后来过期了）、改了什么记不清了（只记得颜色和圆角，具体色值不记得）、项目目录已经删了。

于是只能从"要一份原始包"开始。——而对方给我们的第一句话是："你们那边没有存吗？"——这句话没有责怪的意思，但它说明了一件事：在他的预期里，做过一次的人应该存着。

最后这个活重做了一遍，花的时间比第一次还多——因为要同时满足"上次改的那两处"和"这次新加的两处"，而我们只记得上次改了"颜色和圆角"，具体是什么颜色已经说不清。——而"说不清"的直接后果是：新版的按钮和上一版不一样，对方问了一句"是不是改坏了"。

这个客户后来没再找过我们。——我不确定是不是因为这件事，但我知道在第二次那个时刻，我们和一个新人没有区别——甚至更差，因为我们还得先解释"为什么没有存"。

两个例子放在一起，差别不在技术，也不在报价，只在"第一次做完之后那三分钟"。——三分钟做的事是：不删项目、留一句原话、写四句话。——而它们决定的，是三个月后你是"十分钟"还是"重做一遍"。————这件事的投入产出比，在我做过的所有事里大概是最高的。

顺带说一句：这三分钟不是"额外工作"，它其实是"把已经做过的事记下来"。——文件已经打好了、需求已经说过了、说明已经想过了——你只是没有让它们留下痕迹。——所以它不增加工作量，只增加"不丢失"。——而这两件事的差别，在第二次、第三次、第五次的时候会越拉越大，而且拉开的不是速度，是"到底敢不敢接"。——因为"敢接"这件事，本质上其实并不是自信，是"知道上次的东西还在"。而这一步，其实就是那三分钟的全部意义所在。

七、五个具体的问答

问：留这些东西要占多少空间、花多少时间？

答：空间上，一个项目目录跟你导入的那个包有关——包越大，反编译出来的内容越多。——时间上，第一次做完之后的三件事（不删项目、留一句原话、写四句话）加起来大概三分钟。——而三分钟换来的是下次省半天。————真正的成本不在磁盘，在"记得做"。——所以更实际的办法是：把它写进你的收尾动作里——"打包、签名、装一次、发文件、不走"这五步，"不走"就是不去点那个删除。

问：客户换了对接人，留的东西还有用吗？

答：正好是最有用的时候。——新对接人最怕的是"这个应用的来龙去脉没人说得清"。——而你手上有三样东西：一串原话（为什么改、改成了什么）、一个目录（现在的状态）、一份说明（怎么装、怎么退）。————把这三样整理成一页发过去，你在他心里的位置就定了：不是"一个外包"，是"这个东西的知情人"。——而这件事的成本，只是把已有的东西拼一下。

问：客户说"就改这一次，以后不管了"，还要留吗？

答：要。——原因很实在："就这一次"这句话，大部分时候是"目前为止就这一次"。——而且这句话有一个很具体的反面：如果真的只改一次，那这一次的包里就有"改过的痕迹"，而这个痕迹三个月后可能会被别人问起。————那时候你手上有没有东西，决定了你是"能答上来"还是"说不清"。——再说一句：留东西的成本是三分钟，而"说不清"的成本没有上限。

问：怎么跟客户说清"什么算一次改动"？

答：按"轮"算，不按"处"算。——一轮的意思是：说一次需求、改一次、打一次包、交付一次。————为什么按轮？因为一轮里的"处"是可变的：改一处和改三处，打包、签名、装机、验证这些动作是一样的，成本差得不多。——而按处算，会出现一个很别扭的局面：客户觉得"就改一个字"，你觉得"又要走一遍全流程"。——提前说清"一次交付算一轮"，双方对"贵不贵"的判断就一致了。——顺带说：这个定义对客户也是好事——因为一轮里他可以提三处，而不用不好意思。

问：要不要主动去问"还要不要改"？

答：要，但只在三个时间点问，而且不要问"还要不要改"。——三个时间点是：交付后第二天、一周后、一个月后。——第二天问的是"装上了吗，有没有哪里不对"（这是最有用的一次，因为问题通常在这一天暴露）；一周后问的是"用着还顺吗"；一个月后可以顺带说一句"最近有新版本要发吗"。————注意都别问"还要不要改"：这句话把"要不要花钱"摆到了台面上，对方会本能地说"暂时不用"。——而"装上了吗"、"用着还顺吗"这两个问题，问的是关心，答案是真实的。

八、做过很多回头客的人怎么说

九、收尾三分钟：一份具体到动作的清单

"留东西"这件事最大的障碍不是不知道留什么，是"交完之后就忘了"。所以要把它变成一串具体动作，动作不需要记，只需要照做。

动作一：打包完，把最终那个文件重命名。——命名格式："应用名-改了什么-日期"。——这一步顺便解决了另两个问题：下次不用猜哪个是最新的；发出去之后对方也知道这是什么。——耗时十五秒。

动作二：把文件发出去，旁边附四句话。——不要发一个光秃秃的文件。——四句话的模板第一次写完就存着，以后只改文件名和"怎么确认"那一句。——耗时一分钟（第一次三分钟）。

动作三：回到软件里，确认那个项目还在列表里。——就"看一眼"这个动作。——因为很多人是在"清理"的时候顺手删掉的，而不是在交付的时候。而"看一眼"会让你在下一次想清理的时候犹豫一下。——耗时五秒。

动作四：确认这一轮的需求原话在历史里。——如果软件自动存了，你只需要"别去删"；如果你习惯另外记一份，那就复制一行到项目目录里。——耗时十秒。

动作五：在心里（或者记事本上）写一行"下次要注意什么"。——比如"这台机器是小屏，字号别再往上加"、"那个图标是客户公司名，不能动"。——这一行东西看起来最没用，但它是"这个客户的特殊性"。——而"特殊性"正是"换个人做不出来"的部分。——耗时二十秒。

五个动作加起来不到三分钟。——而它们有一个共同点：全都是"确认"和"命名"，没有一个是需要判断的。——这一点很重要：因为交付完成的那一刻，是你最想"关掉一切"的时刻，而这个时候你只做得动"照做"的事。————所以清单要短、要具体、要不费力。任何需要你"想一想"的收尾动作，最后都会变成"下次再说"。

十、还有一样不算"东西"的东西：你说话的方式

前面三样都是可以存的。但回头客这件事里，还有一样存不下来、却每次都在起作用的东西：你怎么跟他说话。

它具体表现为三种时刻。

时刻一：他说了一个模糊的要求，你的第一反应是什么。——两种反应："行，我知道了"（然后自己猜），和"你说的'清爽'，是指东西少一点，还是颜色淡一点？"——前者快，但会返工；后者慢十秒，但不返工。——而客户记住的是后者——因为被问清的那一刻，他会觉得"这个人在认真对待我的要求"。

时刻二：他提了一个技术上做不到或者不该做的要求，你怎么说。——两种说法："这个做不了"，和"这个能做，但会带来一个问题，我建议换个做法"。——前者是拒绝，后者是方案。————而"做不了"这三个字，会被记住很久；"我建议"这三个字，也会被记住很久。

时刻三：你说"好了"的时候，有没有顺带说一句"这次我没动什么"。——这句话特别小，但它做了一件大事：它告诉对方"我知道你在意什么"。——而"知道你在意什么"这件事，是任何技术能力都替代不了的。

三种时刻加起来，其实是一件事：让他觉得"这件事有人在管"。——而"有人在管"这个感觉，是回头客的全部理由。——因为改包这个活，客户真正的焦虑从来不是"改得好不好"，是"改完之后出了事找谁"。————而一个每次都问清、每次都说明、每次都说"这次我没动什么"的人，答案很明显。

十一、有时候该劝他"这次别改"

这一节说一个反直觉的判断：有些时候，最有利于回头客的做法是"劝他这次别改"。

什么情况下该劝？三种。

第一种：改完之后必须卸载，而里面存着很重要的数据，且他没准备导。——这时候最该说的不是"我可以改"，是"改之前先把数据导出来，不然会丢"。————而这句话可能让这一单延后，但它避免了一次"改完之后数据没了"的事故。——而一次这样的事故，足以让这个客户永远不再来。

第二种：他要改的东西，是他自己应用的核心逻辑，而他不确定要不要改。——比如"把登录去掉"、"把某个功能删了"。——这时候该说的是"这个改动我不能替你决定，因为它影响的是你后面怎么用"。————注意这不是推责任，是把决定权还给他；而"替客户做决定"这件事，事后最容易变成"都怪你"。

第三种：这个包已经改了很多轮，而每一轮都在同一处反复。——这时候该说的是"我们先别改了，你把'最终想要的样子'截一张图给我，或者找一个你喜欢的应用给我看"。————因为反复改同一处，说明问题不在执行，在目标不清楚；而继续改，只会多出几个版本，不会更接近。

为什么"劝他别改"反而有利于回头客？因为它的潜台词是"我不只想赚这一单"。——而这句话不用说出来，对方能感觉到。————尤其是当他已经被别人"什么都答应、什么都做不好"坑过一次之后，这种"会说不"的人反而更可信。

当然，说"不"也要有分寸：说的是"这一种做法有风险"，不是"你这个想法很蠢"。——前者是专业判断，后者是评判人。——而大部分客户能接受前者，接受不了后者。————具体说法可以是这样："这个能做，但我得先告诉你一个后果，你决定要不要做。"——一句话，把风险摆出来，把决定权还给他。

十二、一个客户一个目录：把三样东西放在一处

三样东西如果散在三个地方，那它们等于不存在。所以最后要讲的是"放在哪儿"。

一个够用的结构是这样的：工作盘上有一个"项目"目录，下面一个应用一个子目录，子目录里三样东西各就各位。

这个结构的关键不在整齐，在"一个客户一个入口"。——因为三个月后，你脑子里只剩下一个词：那个巡检的应用。——而"巡检"就是目录名，所以你打开"项目"目录，一眼就找到了。————如果你用的是"2026年10月客户A"这种名字，你得先想"那是几月"、"客户A 是谁"——而这两个问题你都答不上来。

还有一个小细节值得说：当前这一版只放一个 apk。——其他的全进"历史"。——因为"打开目录看到一堆文件"和"打开目录看到一个文件"，是两种完全不同的体验：后者不需要判断，前者要判断。——而判断这件事，在赶时间的时候最容易出错（这一点我们在上一篇文章里说过很多）。

另外两个小习惯，都和这个结构配套。

习惯一：说明.txt 里写"这一次"的确认方法。——因为"装完怎么确认"这一句每次都不一样：这次是"首页第二行应该是英文"，下次可能是"按钮应该在左边"。——而这一句是最容易被忘的，因为它只在"这一次"有效。

习惯二：每加一个新客户，先建目录再动手。——不要"先改，改完再整理"。——因为"改完再整理"这件事，八成不会发生——改完你只想交出去。————而"先建目录"只要十秒，而且它顺便逼你想一件事：这个应用叫什么名字（也就是三个月后你会用什么词找它）。

十三、反过来说：什么时候该放掉一个客户

讲"回头客"很容易讲成"什么活都接、什么人都留"。但实际做久了会发现：精力是有限的，而一个消耗你的客户，会挤掉两个好客户。

有三种情况，值得考虑放掉。

第一种：反复改不出结果，而且拒绝提供参照。——你说"能不能截个图"，他说"你自己看着办"；你说"能不能找个你喜欢的应用给我看看"，他说"你专业你定"。————而"你专业你定"这句话听起来是信任，实际上是"我不承担判断"。——结果是：你定了，他不满意，然后重来。而这个循环没有终点，因为标准不在任何地方。

第二种：要求越过了授权边界。——比如"这个应用是别人做的，你帮我把它里面的验证去掉"、或者"帮我把它改成我的名字发出去"。——这一类没有讨论空间。————而且要注意：这种人往往会在你说"不行"之后，去找下一个说"行"的人。所以放掉他不是损失，是止损。

第三种：把"随时能找到你"当成默认。——凌晨发消息、周末打电话、每次都说"很急"，而"很急"的原因永远是他自己拖到最后。————这一类不一定要放掉，但一定要立规矩：说清"我什么时候在、多久回"。——而如果他连这个都不接受，那就是第四种了。

放掉的方式，也不需要撕破脸。——最省事的做法是"不再主动"：交付完不问"装上了吗"，一个月后不发那句"有新版本要发吗"。————因为回头客是"被主动维护出来的"；不维护，它自然就淡了。而这个淡，对双方都不伤。

为什么这件事要放在"回头客"这篇里讲？因为它是一枚硬币的另一面。——你之所以能对好客户做到"十分钟就给他"，是因为你没有把时间花在那些永远改不完的活上。————换句话说：你能不能积累，不只取决于你留了什么，还取决于你把时间给了谁。

十四、这门活能积累下来的，只有三样东西

把这篇收一下。改包这件事，从外面看是"一次一次的交易"；从里面看，能积累的东西只有三样。

一样是"他说过的话"，一样是"这个应用现在的样子"，一样是"交付时那四句说明"。——三样都很轻：一句原话、一个目录、一百个字。——而它们加起来，就是这个活里唯一能滚起来的东西。

因为改包这个活有个特点：它的产出物是一个文件，而这个文件是可以被复制、被转发的。——所以"我改过什么"这件事，如果不能被你复述出来，那它在世界上只存在于那个文件里——而文件本身不会说话。——三样东西的作用，就是让那个文件有话说。

再往深一层说，回头客这件事的本质，是"降低对方的启动成本"。——他第二次找你的时候，心里想的不是"上次那活干得怎么样"，是"我要花多少力气把这件事重新说一遍"。——而你要做的，就是把这个成本压到接近零：不用重说、不用等、出了问题有人在。————这三件事，恰好对应前面那三样东西。

还有一个反过来的观察：这三样东西，同时也是"你自己"的保险。——因为你需要它们的时候，往往不是客户来找你，是你自己需要——比如半年后要改一版、比如要跟别人解释当时为什么这么改、比如要判断"这个 bug 是不是我改出来的"。————而那时候你手上有没有东西，决定了你是"翻一下"还是"重新猜"。

只需说话，就能让应用变成你想要的样子。而在这门活里，最值钱的那句话其实是："上次那个，再改一下。"——因为这句话说明，他不需要重新解释，你也不需要重新理解。——而这一句话能成立，全靠第一次做完之后那三分钟。

安卓修改大师智改工坊的产品页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。它把"留东西"这件事变成了默认行为：项目留在列表里就是一个目录，每一轮的需求原话存在历史里，配置跟着项目走。——所以你要做的不是"记得存"，是"别去删"。

---