给客户演示的那个包：演示数据、隐藏入口和一句免责话

给客户演示一套系统，最尴尬的时刻不是被问住，而是点开之后里面全是别人的数据：别的公司的名字、别的门店的单据、别的项目的进度。演示的人一边讲，一边飞快地把窗口挪开，客户的眼神已经变了。

另一种尴尬更常见：演示到一半，某个入口点进去要账号，某个按钮点下去直接报错，某个页面转圈转到放弃。这些东西在正式环境里都是正常的，因为正式环境有数据、有权限、有网络。演示现场什么都没有。

这一篇讲演示用的那个包：它和正式包差在哪三处、数据怎么准备、不该出现的入口怎么处理、演示完怎么收，以及为什么演示包最危险的用法，是被人当成正式版发出去。官网是 www.apkeditor.cn。

一、演示包和正式包，是两个目的

很多人把演示包理解成「功能少一点的正式包」，于是拿正式包删几个按钮就上，结果现场处处露馅。两者的目的根本不同：正式包要让真实用户完成真实任务，演示包要让一个陌生人在十分钟内看懂这套东西能干什么。

目的不同，取舍就不同。正式包追求完整，每个边缘情况都有处理；演示包追求顺畅，只要主路径不卡，边缘情况可以直接不给入口。正式包的数据要真，演示包的数据要「像真的但一眼能看出是假的」。正式包要考虑安全和权限，演示包要考虑客户拿到手会不会误操作。

所以我们内部的演示包，从来不是从正式包上删东西，而是另起一条线：同一份代码，换一套配置，换一批素材，换一个身份。改的地方不多，但每一处都是为了让它在别人手里不出事。

这条线一旦建立，好处是长期的。下一次演示不用重新准备，只需要更新数据和素材；不同行业的客户可以各有一份，互不干扰；演示过的东西不会污染正式环境。它像一份可以反复使用的道具，而不是每次临时凑的东西。

代价是要多维护一份。这个代价值得付，因为演示是获客链路里唯一一次「客户完全以你的节奏看你的东西」的机会。这十分钟里出一次岔子，前面所有的沟通都要打折。

还有一层现实：演示往往发生在最不方便的时候——客户的会议室、酒店的桌子、展会现场的一角。没有你的显示器，没有你的网络，没有你的调试工具。演示包必须假设「一切外部条件都不可靠」。

把这个前提记住，后面每一条做法都顺理成章：数据要假、入口要收、网络要能不依赖、出错要能圆过去。

二、要改的三处：数据、入口、身份

一份能拿出去的演示包，改的无非三处。说清楚这三处，剩下的都是细节。

第一处是数据。打开就要有内容，而且内容要能支撑你要讲的那个故事。空列表是最没说服力的演示，因为客户看不到「用起来是什么样」。所以演示包里带的不是零数据，是一批精心挑过的数据：数量适中、字段填满、名字看不出真实主体。

第二处是入口。正式包里有几十个入口，演示只走三条主路径。其余的入口不该被删掉，而应该被挪到主路径之外——删掉会在某个角落留下死链，挪走只是让客户不容易误点。

第三处是身份。应用的名字、图标、启动画面、关于页里的公司信息。演示给不同客户时，这些往往要换：给 A 客户看的时候不希望他看到 B 客户的名字，也不希望他看到你自己公司的品牌压过一切。这一处最简单，也最容易被忘。

三处之外还有一处隐性改动：版本号。演示包必须有自己独立的版本号，而且要比正式包低一档，一眼能看出「这不是发出去的那个」。否则某天有人把它当成正式包传出去，谁也分不清。

为什么强调「独立版本号」？因为演示包和正式包同名同图标同包名的时候，它们在同一台手机上会互相覆盖。你今天装演示包，明天客户装正式包，两个包在客户手机上打架，最后留下的那个可能是演示数据那一份。这个后果比演示当场出错严重得多。

所以三处改动的顺序是：先定身份（名字、图标、包名、版本号），再定入口，最后铺数据。反过来做，数据白铺一遍。

三、演示数据：三十条能讲故事的，比三千条真的有用

演示数据最容易走两个极端：一种是空的，一种是直接从正式库导的。两种都不行。

空的演示，客户看不到价值。他看到的是一堆「暂无数据」的界面，只能靠你嘴说。而人对空界面的想象力很差，你说「这里以后会有两百个工单」，他脑子里出现的是一张表格，不是他真正关心的那个画面。

直接导真实数据的演示，风险在别处。客户名单、手机号、金额、合同编号，这些东西出现在别人公司的会议室屏幕上，本身就是一次泄露。哪怕对方是同行业，哪怕只是扫一眼，也是一次不该发生的事。

所以演示数据要单独造。造的标准有四条。第一，数量适中。列表页一屏能看满、翻两页还有，就够了。三十条上下，既能体现「量」，又不至于让人翻到烦。第二，字段填满。空字段会让界面显得没做完，尤其是备注、标签、附件这几栏，它们恰恰是最能体现产品细节的地方。

第三，名字看得出是假的，但不要假得太假。「测试001」「张三李四」会让人觉得这个产品没被认真对待过。「华东仓储」「城西二店」这种名字，既有真实感，又能让客户明白这是示例。第四，故事要连贯。列表里的第一条，应该正好是你待会儿要点进去讲的那一条；它的时间、状态、金额，要和后面几屏能对上。

第四条最容易被忽略，也最影响观感。演示的人点开一条工单，看到的状态是「待处理」，然后说「这个已经完成了」，客户会立刻发现不对。这种小矛盾不致命，但它会让人对整个产品产生一种「不太靠谱」的印象，而这种印象说不清、也改不掉。

具体怎么造？三个做法。一是从一个真实项目里脱敏复制：结构照搬，把名字、号码、金额换掉。二是手工写十条最有代表性的，让它们覆盖你打算讲的三个场景。三是用一份固定的种子数据，每次演示前重置一次，保证每次打开都是同一个状态。

第三条最重要。演示最怕的是「上一次演示留下的痕迹」：被人改过的状态、被删掉的记录、被点进去又退出的页面。每次演示前重置一次，等于把道具摆回原位。这个动作只要十秒，但它决定了你打开应用的第一眼是不是干净。

四、演示账号还是假数据：两种做法各管一段

演示包里怎么让客户看到内容，有两条路。选哪条，取决于演示现场有没有网、以及你愿不愿意让客户碰。

第一条路是演示账号。包里还是正式逻辑，只是自动登录一个专门 prepared 的账号，这个账号在服务端有一套独立的演示数据。好处是数据是活的：点按钮会真的提交，状态会真的变，看起来完全像在用。坏处是它依赖网络和服务端，现场网不好就直接废了。

第二条路是本地假数据。包里带一份本地数据，不走网络，打开就有。好处是断网也能演示，速度快，不会被现场网络拖累。坏处是交互是死的：点提交可能只是本地加一行，客户如果细看会发现没有真的发生什么。

两条路各管一段。如果你要演示「流程能跑通」，用演示账号；如果你要演示「界面和体验」，用本地假数据。大多数售前演示其实是后者——客户在十分钟里看的是「这东西长什么样、能不能解决我的问题」，不是「数据库写没写进去」。

现实中更好的做法是两条都准备：主用演示账号，网络不行的时候切到本地。这个切换要提前做好，不能在现场临时找。切换的入口可以藏在一个不明显的地方，比如连点版本号五次，或者一个只有你知道的手势。

还有一个折中方案值得提：本地数据加一次性提交。列表和详情走本地，只有最关键的那一个动作（比如「提交审批」）真的发一次请求。这样既有速度，又有一个「真的发生了」的瞬间。演示里最打动人的，往往就是那个瞬间。

不管选哪条，有一条底线：演示过程中不要出现「网络错误」「登录已过期」「无权限」这三种提示。它们会让客户把注意力从产品转移到环境上，而一旦开始讨论环境，这十分钟就废了。

五、不该出现的入口：挪走，不要删

正式包里有几十个入口，演示只走三条路。其余那些怎么办？最常见的做法是删掉，而这恰恰是错的。

删掉的第一个问题是有死链。某个页面里有一句「去设置里看看」，删了设置入口，这句话就变成了一个点了没反应的文字。演示的时候客户正好点了它，你就得解释「这个我们演示版没有」。一句解释，气势就掉一半。

第二个问题是删不干净。入口往往不止一处：首页有一个、个人中心有一个、某个弹窗里还有一个。删了两处漏一处，那一处就是现场最容易被点到的。因为客户不知道哪条是主路径，他点的地方永远和你预期的不一样。

所以正确做法是挪，不是删。挪的意思是：让它还在，但不在主路径上。具体做法有三种。第一种，把入口从首页挪到二级甚至三级页面；第二种，把它放在一个需要登录、而演示账号没有权限的位置，点了会提示「无权限查看」，比「功能不存在」体面得多；第三种，给它加一个「演示版暂未开放」的提示页，页面本身做得像样一点。

三种里，第二种最省事，但要看你的产品有没有权限体系。第三种最稳，但要提前做页面。第一种最自然，适合入口本来就多的产品。

还有一个技巧：把演示路径做短。正式版里点四次才能到的页面，演示版可以放一个快捷入口在首页。客户不需要知道真实路径有多长，他需要看到结果。这一点不算作假，因为真实用户用熟之后也会用快捷方式。

有一条不能碰的底线：不要为了演示顺畅，把「加载中」「失败重试」「空状态」这些页面全删掉。它们恰恰是产品成熟度的体现。客户问「如果没网怎么办」，你能当场点开一个失败页给他看，比说十句「我们有处理」有用。

六、演示版最怕的两件事

演示包做得好，是一种资产；管不好，是一种风险。风险就两件，但每一件都够麻烦。

第一件，被当成正式版发出去。演示数据出现在真实客户面前，客户以为自己看到的是自己的数据，或者更糟——他发现自己看到的是别人的数据。这种事一旦发生，解释起来非常被动，因为从外观上它就是一个正常的应用。

第二件，被客户留在手机上。演示结束，客户说「这个我先留着看看」，于是演示包长期躺在他的设备里。他下次打开，看到的是三个月前的假数据，然后得出「你们这个东西不更新」的结论。

两件事的根源是同一个：演示包和正式包长得太像。所以解法也很直接——让它一眼就能被认出来。

四个动作。一是名称带标识，比如名字后面加一个「演示」或「体验」。二是图标加角标，右上角一个小色块，远看就知道不是正式版。三是启动页写一句「本应用为演示版本，数据为示例」，两秒，但把话说清了。四是版本号独立，并且明显低于正式版。

四个动作里，第一个和第三个最有效。名称带标识，装的时候就分得清；启动页写清楚，用的时候就分得清。后两个是补充。

还有一条管理动作：演示包要有回收清单。发给了谁、什么时候发的、什么时候该收。不回收的演示包会一直活着，而它带着的那批假数据，迟早会在某个不合时宜的场合出现。

我们内部的做法是：演示包一律走一个固定的分发链接，链接在演示结束后失效。已经装上的收不回来，但至少不会再有人从旧链接下载。能管住的部分管住，管不住的部分至少让它显眼。

七、第一个实例：同一天见三家客户，界面要各不一样

我们自己维护的门店经营管理平台，去年年底有个情况：一天之内见三家客户，一家连锁便利店、一家社区生鲜、一家区域药店。三家的行业术语、单据名称、主推功能都不一样。

最开始的想法是「讲同一套，术语顺手改口说」。试了一次就放弃了。便利店客户听到「处方复核」，第一反应是「这跟我们有什么关系」。那不是术语问题，是「你根本不懂我这个行业」的问题。

后来的做法是一个行业一个演示包。同一个应用，改三处：应用名换成行业化的名字、首页的三个快捷入口换成这个行业最常做的三件事、演示数据按行业造。代码一行没动，改的全是资源和配置。

三处的具体差别。名称上，便利店那份叫「门店助手」，药店那份叫「药房台账」。入口上，便利店首页放「补货申请」「临期处理」「盘点」，药店放「处方登记」「库存核对」「近效期预警」。数据上，商品名、单据类型、金额量级全部按行业习惯来。

效果很明显。客户打开的第一反应从「你这个系统挺全的」变成了「你怎么知道我们临期要单独处理」。这一句问出来，后面的沟通就完全不一样了。

成本呢？第一个行业花了半天，后两个各花两小时。因为改的是同一套结构，只是换了内容。真正花时间的是「想清楚这个行业最常做的三件事」，那部分跟改包无关，是售前该做的功课。

这件事让我们改了一个习惯：以前是先做包再想怎么讲，现在是先定「讲哪三件事」，再倒推包里要放什么。顺序反过来之后，演示包反而更好做，因为它有了明确的目标。

八、第二个实例：那批演示数据被当成了真数据

另一个实例是现场巡检端。有一次给客户演示，结束后客户说想再自己看看，于是我们把演示包留在了他的手机上。当时说好一周后回收。

两周后，客户打电话过来，语气不太好：「你们这个巡检数据不对，我上周明明查了十二个点，系统里只有三个。」

我们查了半天，最后发现他打开的是演示包。演示包和正式包名字一模一样，图标一模一样，桌面上并排放着两个，他点错了。而演示包里那批数据，是他从来没有巡过的点位。

这件事的教训不在于「他点错了」，而在于我们没给他任何可以分辨的东西。两个图标一样、名字一样、打开之后界面一样，凭什么是他的错？

后来改了三处。演示包名字后面加「演示」两个字；图标右上角加一个橙色角标；启动页加一行「示例数据，仅供演示」。三处改完，同样的情况再没发生过。

还有一处管理上的改动：演示包不再直接发给客户，而是现场演示完当场卸载。客户想自己看，就给他一个限时的体验链接，链接二十四小时失效。这样「留在手机里」这件事从源头就没有了。

回头看，这两件事的成本都不高，但都需要在「演示之前」想到。演示这件事的特点是：现场只有一次机会，而所有的补救都发生在事后。所以能提前做的，尽量提前做完。

九、演示前一晚，七件事逐项过

演示这件事，成败往往在出发前一晚就定了。下面七项是我们内部的检查单，每一项都对应过一次现场事故。

第一项最容易被简化成「装上了就行」。冷启动和热启动是两个体验，而客户看到的一定是冷启动。等十秒，看它从点击到首屏用了多久、中间有没有白屏、有没有闪一下再变。这十秒是客户对这个产品的第一次判断，而且是不受你影响的判断。

第四项的关键是「数点击次数」。你熟悉路径，所以不觉得多；客户不熟悉，每多一次点击就多一次犹豫。把三条主路径各走一遍，数一数点了几下。超过四次的，考虑在演示版里加一个快捷入口。

第五项最容易漏，也最容易发现真问题。不要凭记忆想「哪些入口可能有问题」，就照着界面上能看见的东西，一个一个点。图标、文字、卡片、横幅、底部标签，全部点一遍。十分钟，能排掉现场八成的意外。

第七项看起来是管理动作，其实是风险控制。记下发给了谁，才知道该向谁回收。没记录的演示包，等于发出去了就再也找不回来。

十、现场没有网：离线演示怎么准备

客户的会议室、工厂的车间、展馆的角落，经常没有可用的网络。而演示最忌讳的一句话是「这里网不好，稍等一下」。

离线演示的核心只有一条：把「打开就能看到」这件事做到极致。具体是四层准备。

第一层，数据本地化。列表、详情、图片全部随包带。图片要压缩，不然包会很大，安装和首次打开都变慢。一屏列表的缩略图，加起来别超过两兆。

第二层，请求超时要短。如果某个页面确实要联网，把超时设成三到五秒，失败立刻给提示，不要转圈三十秒。转圈是最糟的等待形态，因为它不告诉你还要等多久。

第三层，关键页面双份。最核心的两三屏，做一份本地兜底：网络拿不到就用本地那份。客户看不出区别，但他能看到内容。

第四层，准备好「没有网也能讲」的话术。有些功能确实要联网才能演示，那就不要在没网的时候点它。提前知道哪几个按钮不能点，比现场手忙脚乱强。

还有两个现场技巧。一是自带热点，用自己手机开一个，比赌客户会议室的网靠谱。二是提前把要演示的页面预热一遍，让缓存在演示前就填满，现场点开就是秒开。

这两条都是经验，不是技术。但它们决定的那十分钟，恰恰是技术被看见的唯一十分钟。

十一、演示结束之后：那份包怎么处理

演示结束，故事还没完。演示包身上带着三样东西：假数据、独立的身份、一个比正式版低的版本号。这三样在演示之后，每一样都可能变成麻烦。

第一件事，客户机上那份。能当场卸就当场卸，卸的时候顺手说一句「这个是我们演示用的版本，回去给您装正式版」。这句话有两个作用：一是让客户知道刚才看的不是最终形态，二是给他一个「还会有正式版」的预期。很多人演示完什么都不说，客户以为那个就是产品。

第二件事，自己机上那份。演示机上的旧版本要清掉。下一次演示前一定要重装最新的一份，因为你在两次演示之间可能改过东西，而手机上那份还是旧的。「我明明改过了」这句话，在演示现场说出来是没有意义的。

第三件事，分发链接。限时链接到点就失效，长期链接要能随时下线。下线这件事要有一个明确的人负责，不能是「大家都以为别人会关」。

还有一件容易被忘的：演示过程中客户提的修改意见，要落在下一次的正式版里，而不是落在演示包上。演示包是一个道具，不是产品分支。一旦开始往演示包里加功能，它就变成了第二个产品，而你没有人力维护两个。

我们内部有一条硬规矩：演示包不许加功能，只许换内容。客户说「这里能不能加个导出」，回答是「正式版里会有」，然后记到需求里。演示包只负责让人看懂，不负责让人满意所有细节。

这条规矩听起来不近人情，但它保护的是长期的交付能力。一个每次演示都长一点的演示包，最后会变成一个谁都说不清的分支。

十二、七个问题，都是演示前真被问过的

问题一：能不能直接拿正式包演示？能，前提是正式环境里有一个干净的演示账号，而且你的数据里没有别人的东西。只要有一条不满足，就别省这一步。

问题二：演示包要不要跟着正式版更新？要，但不是每次。做法是正式版每发一个大版本，演示包跟一次；小改动不必跟，因为演示看的是主路径。不跟的代价是「界面和客户后来装的不一样」，这个代价在签约之后才会显现。

问题三：演示数据放多少条合适？列表两屏、每屏十到十五条，够了。太多会让人觉得杂乱，太少会显得空。关键是第一条要能撑起你要讲的那个故事。

问题四：能不能让客户自己操作？可以，但要在你看着的时候。客户自己点，点到的往往是你没准备的地方，这正是发现问题的好机会。但如果让他拿走自己玩，那就是另一回事了。

问题五：演示包要不要联网？要能两栖。联网时用活的，断网时用本地的。两条都准备，切换方式要事先想好。

问题六：客户要安装包，给不给？给限时的体验版，不给演示包。演示包里那批假数据一旦流出去，你解释不清。体验版可以用正式包加一个演示账号来做。

问题七：一个客户一个包，维护得过来吗？三五个能，十个就难了。做法是把差异收敛到「配置」这一层：名称、图标、首页三个入口、一份数据。差异只在这四处，就能批量做；一旦差异进了代码，就维护不动了。

十三、把「做个演示版」写成一句能执行的话

「下次见客户前做个演示版」——这句话谁都会说，但做出来的东西每次都不一样。差别不在能力，在这句话里没有信息。

一句能执行的话：这次给药店客户做一个演示包，名称叫「药房台账演示」，图标加橙色角标，包名沿用正式包但版本号低一档；首页三个快捷入口换成处方登记、库存核对、近效期预警，其余入口从首页移除；带三十条演示数据，覆盖近效期预警、库存差异、处方复核三个场景，每次演示前重置；断网也能完整走完三条主路径；演示结束当场卸载，不发给客户。

这句话里有六个信息，每一个都不能省。第一，叫什么、图标什么样，这是「一眼可辨」的基础。第二，版本号怎么定，决定它会不会和正式包打架。第三，首页放哪三个入口，这一条直接决定演示讲什么。第四，数据造多少、覆盖哪几个场景，决定现场有没有东西可看。第五，断网能不能走通，决定现场网络不好时会不会翻车。第六，结束怎么处理，决定它会不会流出去。

还可以补两条。一是「谁来做、什么时候要」，因为演示包通常卡在时间上，不卡在难度上。二是「改动只许在资源和配置层」，这一条是给做的人划边界，避免他顺手改了代码，导致以后每次发版都要合一次。

我们内部现在把这类需求写成一张五行的小单子：名称与图标、版本号、首页三入口、数据场景、结束处理。五行填完，做的人不用再问。写这张单子十分钟，能省掉一轮来回。

十四、三句话，把这件事收住

第一句：演示包不是正式包的简化版，它是另一个目的下的一次改包。目的不同，取舍就不同。想清楚「这十分钟要让客户看到什么」，比想清楚「要删哪些功能」重要得多。

第二句：数据要假得可信，入口要挪不要删，身份要一眼可辨。三处改完，一个能拿出去的演示包就成型了。剩下的都是细节，而细节可以靠检查单兜住。

第三句：演示包最危险的用法，是被当成正式版发出去。所以它必须有独立的名称、独立的版本号、明确的回收方式。这三样是保险，平时用不上，出一次事就值回全部成本。

三句合起来是一件事：演示是获客链路里唯一一次「完全由你控制节奏」的展示，而它只有一次机会。把它当成一件要准备的事，而不是一件顺手的事，结果会差很多。

十五、附：一页速查

下面这张表把全文压成八行，准备演示包的时候可以对着看。

这八行里，最容易被当成「多余」的是最后一行。但演示包的风险几乎全部发生在演示之后：它被留下、被转发、被当成正式版。演示当天出问题是丢一单，演示之后出问题是丢一批。

还有一句值得写在最前面：演示包的目标不是「展示全部功能」，是「让客户相信这件事能办成」。相信只需要三个场景、三十条数据、十分钟顺畅。剩下的功能，等签约之后有的是时间讲。

十六、三个容易走反的地方

做演示包这件事，有三处方向特别容易搞反。搞反了不报错，但效果会打折。

第一处，把「功能多」当成卖点。演示的时候一个接一个点，把二十个功能全过一遍，客户记住的往往是「挺复杂的」。人对一次展示的记忆上限大概是三件事，说二十件等于一件都没说。正确的做法是只讲三件，每件讲透。

第二处，把「真实数据」当成可信度。有人觉得用真实数据显得更真实，实际上客户看到的第一个反应往往是「这是谁家的」。可信度不来自数据的真假，来自数据的一致性：时间对得上、状态对得上、金额对得上。一份自洽的假数据，比一份残缺的真数据可信得多。

第三处，把「界面漂亮」当成准备重点。界面当然要好看，但演示现场真正决定成败的是「点下去有没有反应」。一个朴素但处处有响应的界面，胜过一个精致但点了三下才动的界面。响应速度是演示里唯一无法用话术弥补的东西。

这三处的共同点：它们都是「做加法」的诱惑。加功能、加数据、加设计，看起来是更努力，实际是让主线变模糊。演示这件事，做减法比做加法难，也更有用。

还有一个相关的判断：如果某个功能你需要在演示时解释「这个正常情况下是……」，那它就不该出现在演示里。解释一次，客户的注意力就从产品转到了你的说明上，而说明永远比产品弱。

我们内部评审演示包的时候，只问三个问题：三条主路径分别是什么？每条的点击次数是多少？断网能不能走完？三个问题答不上来，这个包就不算准备好。至于功能全不全，从来不是评审项。

这条标准看起来很低，实际执行起来会发现：很多演示包连「三条主路径是哪三条」都没想清楚。而这恰恰是最该先想清楚的事。

最后说一个很具体的细节：演示时不要一边操作一边解释操作。「我点这里啊，然后这里会出来一个……」这种话会把客户的注意力拉到你的手上，而不是屏幕上。正确的方式是先说「我要做一件事」，然后做，最后说「做完了」。三步之间留半秒空白，让人看清结果。

这半秒空白听起来是小事，但它是演示和讲解最重要的区别。讲解是在传递信息，演示是在制造一次亲眼所见。亲眼所见需要时间，而那半秒就是留给它的。

十七、演示包这件事，对产品本身也有用

做到这里，你可能会觉得演示包是一份额外的负担。但它其实会反过来推着产品变好。

第一，它逼你把主路径想清楚。能讲清楚的路径通常只有三条，而产品里可能有二十个入口。「哪三条最重要」这个问题，平时没人问，做演示包的时候必须回答。回答一次，产品经理对优先级的判断会准很多。

第二，它暴露「点下去没反应」的地方。正式用户会忍，客户不会。演示包是最严格的一次可用性测试，因为使用者是一个完全没有耐心的陌生人。

第三，它让资源层的改动被认真对待。名称、图标、启动页、首页入口，这些东西平时藏在代码深处，只有在做演示包的时候才会被集中梳理一遍。梳理完你会发现，原来换个名字要动五处。

第四，它是新人最快的上手材料。新同事拿到一个演示包，十分钟就能明白这个产品在讲什么、给谁用。比读二十页文档有用。

这四条是我们做完三批演示包之后才意识到的。最初只是为了应付一次客户拜访，后来变成了一个固定的东西：每次大版本更新，顺手更新一次演示包；每次新行业进来，加一份行业版。成本很低，因为它只动资源和配置，不动代码。

顺带说一句，这类「只动资源和配置」的改包，用安卓修改大师智改工坊来做是最省事的：名称、图标、启动页、首页入口这些改动，说清楚就行，回编和签名交给它，改完可以真机预览再确认。产品介绍页在 www.apkeditor.cn。

还有一点值得说：演示包是最早暴露「资源层耦合」的地方。如果你发现改一个名字要动五个文件、换一个图标要重新裁三套尺寸，那说明这个应用的资源管理本来就该整理了。演示包只是把这个问题提前摆到了桌面上，而不是制造了它。很多人是在做第三次演示包的时候，才下决心把命名和目录理顺的。

十八、用过的人怎么说

这一篇里的两个实例，都是我们自己维护的应用：一个门店经营管理平台，一套现场巡检端。演示包这件事的难点不在改包，在「想到要改哪几处」：数据、入口、身份，三处各自独立，漏一处就在现场露一次。文中的三处改动、七项检查和三个容易走反的地方，都是从这类现场里长出来的。

合规提醒：本文所有实例均针对自有版权或已获授权的应用，用于企业内部维护、售前演示与合法定制。演示数据请勿使用未经脱敏的真实客户信息，也不要把演示包当作正式版本分发。改包前请确认你对目标应用拥有相应权利。

演示是把产品递到别人手里的那一下。递之前擦干净、摆整齐、把不该出现的收起来，这个动作本身就是专业。

安卓修改大师智改工坊能做的，是把改包之后那一串动作一次落到位：名称、图标、启动页、首页入口一次改到位，改完可以真机预览再确认。说清楚，就够了。