行业资讯
很多老板签软件合同时，看到 "免费维护一年" 就觉得省心。真上线出了事才发现，合同里这句话可能就一行字，范围、时效、责任全没写。后面每修一个问题都要重新谈价，扯皮从验收那天就开始了。 我见过不少项目，维护期内出了 bug，开发公司说这算新增需求要另收钱，老板觉得合同写了免费就该全包，两边各执一词，最后只能翻合同。可合同里偏偏没写清楚，翻也翻不出结果。今天就把售后条款拆开，看看这一年到底值不值。一、免费维护，到底免费什么 行业里默认的维护范围，一般只含 bug 修复，也就是程序报错、闪退、功能不正常这类缺陷。这类问题属于开发质量范畴，本来就应该修，写上免费只是约定个时间窗口。 新增功能、界面调整、业务流程改动，通通算需求变更，不在维护范围内，要单独报价。这一点很多老板没概念，以为 "维护" 就是提什么需求都能免费做，等报价单出来才傻眼。 还有三样东西合同里经常不写：服务器费用、域名费用、第三方接口费用。这些是外部成本，跟开发公司没关系，但很多老板以为 "维护一年" 就全包了。合同没写范围，就等于没约定，到时候解释权在对方手里。 签合同前最好把维护范围列个清单，写清楚哪些算 bug、哪些算变更、哪些要另付费。哪怕只是把范围写明白，后面都能少很多麻烦。二、三个最容易漏掉的细节第一个是响应时效。故障报修后多久有人接、多久给出修复方案、多久修完，不写清楚就是没承诺。有的公司写了 "及时响应"，实际上三天回一条消息也叫及时。第二个是修复方式。远程能修的不算完，核心系统要不要现场处理、修复前要不要备份数据、会不会影响当天业务，这些都得落到合同里。特别是政企项目，系统一停就是事故，光靠远程可扛不住。第三个是验收前后的界限。上线当天发现的问题算不算验收前问题、验收后多久内算 "维护期问题"，最容易吵。双方各执一词，最后往往看谁嗓门大。有的合同把验收和上线混在一起写，出了问题根本分不清责任段。这三条看起来都是小事，真出事都是大事。合同里写了，是约束对方；没写，就是给自己留隐患。三、需求变更为什么总能吵起来 "顺手改一下" 和 "重新开发" 是两码事，边界在哪，合同里得写明白。改个按钮颜色算小事，改个审批流程就是新需求，工作量差出好几倍。很多老板觉得 "就改个逻辑"，程序员得重新梳理上下游，一改就是一两天的活。 规范的流程是：提需求、开发公司评估工时和费用、书面确认、再
上个月有个客户问我们，政务平台马上要验收了，甲方突然甩出一句话，系统要过等保三级测评。他一脸懵，等保是啥，以前从来没听过。其实这不是个别现象。现在做政企项目，招标文件里 "满足等保 2.0 二级 / 三级要求" 几乎是标配，你心里没数，很可能就卡在验收这一步。一、等保到底是个啥？ 等保全称网络安全等级保护，是国家给信息系统定的一套安全等级制度。等保 2.0 从 2019 年正式实施，核心逻辑很简单，按系统的重要性和被破坏后的影响分成五级，级别越高，要求的安全措施越严。大多数企业系统落在二级和三级，政企项目最常见的是三级。 打个比方，这就像给系统做安全体检加定级。一级是基础防护，三级要能防住常见攻击、有日志留存、有灾备和应急预案。它不是一个证办完就完事，是真要按标准配防护措施，测评机构会一项一项查。二、什么项目绕不开等保？ 一句话，凡是跟政府、医院、学校、国企沾边的项目，基本都绕不开。政务服务平台、医院信息系统、智慧校园、国企内部管理系统，招标文件里十有八九写着 "系统需满足等保 2.0 三级要求"，有的甚至把通过测评写进付款条件。 原因也简单，甲方自己也有考核，网络安全出了事要担责，干脆把等保写进合同，让系统方来兜底。你做这类项目，等保就是投标的入场券，不是可选项。三、从定级到测评，要走几步、要多久？ 流程固定四步：定级、备案、建设整改、等级测评，后面还有监督检查。定级要先请专家评审，二级以上都要，然后到公安机关备案，一般几个工作日办完。接下来是建设整改，按测评要求补安全设备、日志和管理制度，这步最花时间，也最容易被低估。最后找有资质的测评机构做测评、出报告。 周期没有固定标准，按我们的经验，从启动到拿到测评报告，顺利也要两三个月，涉及整改多的拖上半年很正常。还有一条硬规矩：三级系统每年至少测评一次，新建的三级系统要先通过测评才能上线运行。四、一般提前做三件事第一件，预算。测评费加整改投入，不同规模差很多，项目立项时就该算进去，别等验收前才发现没这笔钱。第二件，时间。定级备案可以提前走，整改和测评留出两三个月以上，别把等保当成验收前一星期能补的作业。第三件，找对测评机构。测评机构要有公安部认可的资质，各地名单公安网能查，提前问清周期和排期，热门机构年底经常排不上队。说到底，等保不是技术部门的事，是项目能不能顺利验收、款能不能按时收的事。提前把它当回事
项目开发到收尾，老板突然被问一句：软著办了吗？ICP 备案做了没？再一问商标，连什么是 "商标类别" 都不知道。上线日期从月底推到下月中，业务等着用，证一个都没有。这 4 样东西名字像、用处完全不同，办错时间就是白等两三个月。下面逐个说清。一、软著，不是必须，但上架和维权都靠它 软著就是软件著作权登记，登记中心出个证书，证明这软件是你的。它不是法律法规强制要求的，但安卓应用商店基本都要，华为、小米、应用宝这些主流渠道上架，没软著连提审的入口都没有。苹果商店不强制要，可你要维权、防别人抄，光靠 "我先做的" 说不清楚，证书一摆就明白。 好消息是登记费早就停征了，自己办基本不花钱，普通流程 35 到 60 个工作日，急用也能走加急通道。我的建议是代码冻结、准备发布的时候就去办，别等商店审核提示缺材料才想起来。二、ICP 备案，大陆上线躲不掉 ICP 备案是网站和线上服务在中国大陆上线的前提，说的是 "这个网站是谁的、在哪放着、谁负责"。它是免费的，办的是资质不是交钱。注意两个点：第一，小程序从 2023 年 9 月起强制备案，不备案不给上架，老小程序也得补；第二，备案要留时间，平台初审一到两个工作日，省通信管理局审核一到二十个工作日，顺利一般两到三周，材料被驳回一次就再等一周。 很多项目死在 "功能全做完了才想起备案"，早点把备案材料（营业执照、负责人信息、域名）准备好，和开发并行推进，能省下大半个月。三、别把备案和经营许可证搞混 备案是门槛，说明 "你有这么个线上服务"；经营许可证是 "你要靠它收费经营" 才要办的。做普通展示型官网、内部管理系统，备案就够。一旦业务涉及收费交易、信息发布、在线教育、金融信息这类经营性服务，就要看 ICP 许可证或者 EDI 许可证，电商平台类的业务大多绕不开。 这个判断做错很麻烦。有的老板以为办了备案就能开商城收钱，平台审核时被要求补证，补证又要走几个月的流程。拿不准业务属不属于经营性，做之前就找开发方或者当地通管局的服务窗口问清楚，别等上线前才补。四、商标，越早办越好 商标管的是名字和品牌，软件叫啥、小程序叫啥、公众号叫啥，都可能被人抢注。商标是 "先申请先得"，你用了三年不等于你有权利，别人抢注成功还能反过来告你侵权。整体周期从申请到下证十到十二个月，审查不通过重新再来，又是将近一年。 所以名字一旦定了就赶紧申
上个月有个做电商的老板跟我吐槽，说公司花几万块上了一套 AI 客服，结果客户问包邮吗，机器人答非所问扯了一堆会员积分，三天不到就被下线了。AI 客服这两年特别火，几乎每家做软件的都在推。但落地效果差距很大，有的确实顶用，有的纯属添乱。这篇就把答非所问背后的 4 个原因说清楚，也讲讲怎么判断一套 AI 客服靠不靠谱。一、第一个坑，知识库就没好好整理 很多企业上 AI 客服，就是把一堆产品说明书、售后文档、常见问题 PDF 直接丢进去，然后等着它变聪明。结果机器人一问三不知，或者答得牛头不对马嘴。原因不复杂。AI 客服不是搜索引擎，它是在文档里找答案的。文档里答案藏在长段落中间，机器人就抓不准。客户问法五花八门，文档里没有现成问答对，它就只能瞎猜。 上 AI 客服之前，先花时间把问题整理成问答对。客户会怎么问，标准答案是什么，逐条列出来。知识库整理得越规整，机器人答得越准。这一步省不得，省了后面全是事。二、第二个坑，它听不懂人话 同一个意思，客户有十种问法。问怎么退，问退款流程怎么走，问买了不想要了怎么办，AI 客服要是只认死词，前面三个问题全判成不同意图，答出来就乱套。 这里面有个环节叫意图识别，就是把客户的问法归类，判断他到底想干嘛。意图没调好，机器人就只会背答案，不会看问题。判断 AI 客服听不听得懂人话，有个土办法。把你们客户真的问过的问题拿出来，挑一百条，原样丢给它，看它能答对多少。别看演示，演示永远是挑好的说。三、第三个坑，它没接上你们的业务系统 很多 AI 客服只接了一个壳，脑子里装的还是通用知识。客户问我的订单到哪了，它答不上来。问余额多少，它也答不上来。一问到具体情况，就回一句请稍后，然后没有然后。 真正好用的 AI 客服，是要查系统的。订单查订单库，库存查库存库，工单查工单库。答完还能顺手帮你把售后单开了。这一步要对接业务系统，技术上比前面两步都麻烦，但恰恰是 AI 客服值钱的地方。光会聊天不会办事的 AI 客服，跟个复读机差不多。选型的时候，先问清楚它能不能接你们的订单、库存、工单系统。四、第四个坑，没有人工兜底 AI 客服答不上来，最怕的就是死磕。客户越问越气，机器人还在那儿绕圈子，绕到最后客户直接投诉。合格的 AI 客服，要知道自己答不了。连续几次没把握，就该判断转人工。转人工还要转得快，别让客户等三分钟还没人接。 人工兜底
去年有个做贸易的客户找我，说系统做一半了，想加个审批流。开发报价多出两万，他不理解，就多一个功能，凭什么这么贵。我反问他，这个审批流要跟哪些单据走，要走几级，超时怎么办，他说没想过，领导让加就加。做软件定制这几年，因为需求变更跟客户扯皮的，比因为功能做不出来扯皮的还多。这篇不站队，就把需求变更为什么贵讲清楚，也讲讲怎么让它不那么贵。一、加一个功能，动的是一整条线 客户眼里的加功能，是界面上多一个按钮。开发眼里的加功能，是数据表要加字段，接口要加参数，列表要加一列，详情页要加一块，权限要加一条，报表要跟着调，测试要重新跑。 一个审批流，最少牵动单据、审批、审批人配置、消息通知、操作日志五六个模块。哪个环节漏了，线上就得出问题。所以开发一听加需求就报价，不是想多收钱，是这笔账他算得比你清楚。二、真正贵的不是代码，是推倒重来 需求如果还没动工，加功能只是多写一段代码，成本有限。可大部分变更都发生在开发中段，甚至快验收的时候。这时候加需求，写好的代码要改，对好的接口要调，测过的功能要重测。更麻烦的是数据，有些已经录进去了，表结构一改，数据要迁移、要清洗、要对账。代码本身不贵，贵的是前面所有工作的返工。三、这 3 类变更，最烧钱第一种，改数据结构。今天加个字段，明天改个类型，表结构一变，查询、报表、导入导出全跟着动。第二种，改业务流程。销售流程原来一审，现在要二审三审，审批节点一变，流程引擎、权限逻辑、消息通知全部要重配。第三种，加第三方对接。原本没打算接系统，做到一半要接，接口文档、联调环境、异常处理，每一项都是看不见的工时。这三种变更，报价贵不奇怪，不贵才要担心。四、怎么减少无谓的变更第一，原型先行。开发前先看原型，界面、流程、按钮全摆出来，看得见摸得着，比讲一百遍需求文档管用。第二，签字确认。原型确认后书面留档，后面要改，就有据可依，客户也更能意识到每次变更都有成本。第三，一期只做核心。别想一步到位，先把最核心的流程跑通，上线用起来再迭代。系统用得越久，需求越清楚，返工越少。五、真遇到变更，怎么办 变更躲不掉，怕的是没有流程。规范的开发公司，接到变更会先评估影响范围，给出工时和费用，让客户自己决定做不做、怎么改。影响小的，顺手就改。影响大的，拆成阶段，先做收益最高的那部分。所有变更书面记录，事后对账清清楚楚。需求变更是常态，不是事故。变更管好了，费用透明，进
去年有个做机械加工的老板，花了三十万做了一块数据大屏，挂在厂区大厅里。客户来参观，看着满墙的图表和跳动的数字，觉得这厂子很先进。但问车间主任，他说那玩意儿就是给客户看的，自己从不在上面找数据，有一次库存数据还是错的，传了三天没人发现。 这不是个例。数据大屏这几年火得不行，几乎成了企业数字化的标配，但真正用起来的没几个。这篇不讲大屏有多酷，就讲它到底值不值，什么样的钱该花，什么样的钱是打水漂。一、大屏为什么这么火 先承认，大屏确实有它的价值。老板汇报的时候，一屏数据比十页 PPT 有说服力；客户参观的时候，一块动态大屏比任何口头介绍都直观；政府项目里，可视化大屏更是标配，没有都不好意思汇报。 火的原因也很简单，它把看不见的数据变成了看得见的东西。库存多少、订单多少、设备转没转，一眼就能看到，比翻报表快得多。这种直观感，是报表系统给不了的。 但问题也出在这。很多人只看到了大屏的 "好看"，没看到它背后的 "数据"，以为屏幕一挂，数字化就成了。二、什么样的数据大屏真有用第一类是生产监控类的。车间设备的状态、温度、产量、报警，实时投到屏上，值班的人盯着就能发现问题。这类大屏是给人用的，数据准、更新快，能直接帮管理。第二类是调度指挥类的。物流车队在哪、订单走到哪一步、仓库还剩多少货，管理者靠它做判断。这类大屏连着业务系统，数据是活的，不是摆样子。第三类是汇报展示类的。展厅、会议室、客户参观区，把企业关键数据做成可视化，用于对外展示和内部汇报。这类大屏重在设计感，数据要求没那么实时，但必须准确。 判断大屏值不值，就看一条：它服务的是 "看的人" 还是 "用的人"。给人看的，便宜点就行；给用的，数据底子才是关键。三、哪些大屏纯属浪费钱第一种是数据不准的。大屏上展示的数据和实际对不上，库存显示充足，实际已经缺货，这种大屏不但没用，还会误事。数据源都没打通，屏做得再好看也是摆设。第二种是没人看的。挂在大厅里当装饰，真正管业务的人从不看它，老板一年也开不了几次。花几十万买个静态背景墙，不如把钱投到业务系统上。第三种是为了做而做的。看同行有，政府检查要有，供应商也推荐，自己都没想清楚拿来干什么，就先把钱花出去。这种大屏，做完就吃灰的概率最大。四、做之前，先想清楚这 4 件事数据从哪来？大屏不是设计出来的，是数据喂出来的。你的库存、订单、设备数据，有没有系统在管？数据源没打通
上个月有个做贸易的老板找我，说公司一个销售离职三个月了，前阵子才发现他还能登录公司的管理系统，客户名单、报价单、聊天记录全在里面，不知道私下看了多少。问他为什么不销号，他愣了一下说，压根没想过这事。这不是个例，很多公司都有同样的问题，只是没出大事，一直没人去管。 员工离职不销号，权限随便给，账号大家共用，这些事单看都是小事，凑在一起就是安全隐患。客户资料被前员工带走、财务数据被人导出、系统被人删了库，哪一件出了都是大事故。权限管理这件事，看起来是技术问题，根子上是管理问题。一、权限不是设个密码那么简单 很多公司对权限的理解，就停留在登录密码上。密码能登进去，但进去能看什么、能改什么、能删什么，完全没有区分。有的公司全部门几十号人共用一个管理账号，登录记录全混在一起，真出了事根本查不到是谁干的。 权限管理的本质是回答三个问题，谁能进系统、进去能干什么、数据能看到哪一层。这三个问题不搞清楚，账号管理就是形同虚设。公司里谁负责审核、谁只能录入、谁只看报表，每个人的权限都应该跟岗位职责对齐，而不是谁想要就给谁开。 把权限拆开来看，至少分功能权限和数据权限两层。功能权限决定能点哪些菜单、哪些按钮，数据权限决定同样的报表，你是只能看自己部门的，还是能看全公司的。两层都管住，权限才算真正落地。二、这几个权限坑，很多公司都在踩第一个坑是共用一个账号。小公司图省事，一个超级管理员账号大家轮着用，密码人人都知道，员工离职了也不改，等于给所有离开的人都留了一把钥匙。第二个坑是超管权限满天飞。为了操作方便，给好几个人都开了最高权限，导数据、删数据、改配置样样能干，风险全敞着口子，一旦有人乱来，损失根本兜不住。第三个坑是离职不销号。员工交接完，人事没通知，IT 没动作，账号就静静躺在系统里。前员工哪天想起来，登录进去照样能看数据，你连他什么时候进过系统都不知道。第四个坑是谁都能导出数据。客户名单、销售报表、财务明细，任何有账号的人都能一键导出，数据流到哪去了，完全没法追溯。这四个坑，踩中任何一个都够头疼的。三、权限到底怎么设计才合理 设计权限先分角色。老板、部门负责人、普通员工、财务、运维，各自管各自的事。角色定清楚，权限跟着角色走，而不是跟着人走，人换了，角色不变，权限体系就稳定。 权限还要分层控制。功能层管能看哪些菜单、能点哪些按钮，数据层管能看到哪一范围的数据，比如同样
上个月一个做门窗生意的老板找过来，说他花六万块买了一套 “智能客服”，装上去没两天就撤了。客户问 “你们有没有断桥铝窗户”，AI 回一句 “请问您需要什么帮助”，客户连问三次，它只会绕圈子。他问我，AI 这行是不是全靠吹。我说 AI 不是不行，是你把钱花在了用不上的地方。 企业上 AI 应用，钱最容易花错的就是三个环节：场景没选对、数据没备好、步子迈太大。下面一个一个说。一、AI 擅长的事，和你想的不一样 很多老板买 AI，是从 “别人有我也要有” 出发的，先定方案再找场景，方向从一开始就是反的。AI 真正擅长的是高频、重复、有标准答案的活儿，比如客服问答、单据录入、报表汇总、售后答疑。这类工作量大、规则清晰，AI 替人干，效率立竿见影。 反过来，让 AI 去管门店选址、判断供应商靠不靠谱，这些靠经验、没标准答案的事，AI 现阶段就是帮不上大忙。所以别问 “AI 能做什么”，先问自己：公司里哪个环节最重复、最占人力？那里才是 AI 该去的地方。二、数据不干净，AI 就是空转 AI 不是买回来就能用的，它吃的就是数据。很多企业的历史客户咨询记录还散在几个人的微信和 Excel 里，格式不统一、字段对不上，这种数据喂给 AI，它只能学出一堆错误答案。 上线 AI 之前，先把数据收拢、清洗、打上标签，至少保证有三个月以上的干净历史数据。这一步最枯燥，也最容易被老板跳过，但它恰恰是 AI 能不能用起来的命根子。数据底子没打好，后面花再多钱调模型都是白搭。三、别一上来就搞大模型 一说 AI，很多老板张口就是 “给我们部署一个大模型”。先不说私有化部署的成本，光是算力、运维、安全合规，就不是一般中小企业扛得住的。更常见的情况是：业务场景还没跑通，先把最重的架构上了，最后系统躺在那里吃灰。 稳妥的做法是从轻场景起步，先用现成的 AI 能力把一个小点做好，比如智能客服、合同初审、报表问答。跑通了、有效果了，再考虑串联流程，再谈私有化部署。顺序反了，钱就白花了。四、AI 落地，三步走稳 落地路径其实不复杂，三步。第一步，挑一个高频重复的业务环节，用现成 AI 工具做试点，周期控制在几周以内。第二步，把试点跑出来的数据和反馈收回来，看准确率，看员工愿不愿意用。第三步，效果验证过了，再把 AI 接到现有系统里，比如跟 CRM、订单系统打通，让 AI 真正参与业务流程。
前阵子一个做餐饮连锁的老板找过来，项目做了一半，和第一家开发公司闹掰了，问我能不能接着做。聊下来发现，合同里源码归属没写，数据全在对方服务器里，连数据库脚本都没交付过。他以为换家公司就行，结果接手的成本比新做一套还高，最后只能硬着头皮继续跟原公司合作。 换开发公司不是不行，但很多老板把这事想简单了。这篇把中途换公司必须想清楚的 4 件事讲透，能帮你少踩一半的坑。一、源码到底归谁，合同里写了没 先翻合同，看有没有明确写源码归你。现实是，很多项目合同就一张报价单，功能列了一堆，源码归属一个字没提。按行业惯例，没有约定的，默认归开发公司。真到交接那天，你连谈判筹码都没有，对方咬定不给，你只能干瞪眼。 就算合同写了源码归你，交付的东西也不一定全。光给一份代码远远不够，还要有数据库脚本、部署文档、接口说明、三方服务账号。缺了任何一样，新公司都接不上手。见过不少老板，源码拿到了，打开一看没有注释没有文档，等于拿了一堆天书。 所以签合同那天就要把源码归属、交付清单写清楚。别等到闹掰了才想起来补，那时候对方没有动力配合你。二、数据还在别人服务器上吗 系统跑了大半年，客户资料、订单记录、财务报表，全存在开发公司的服务器里。这些数据是你业务的核心资产，比代码还值钱。走的时候数据能不能导出来、导成什么格式、多久导一次，合同里有没有约定？ 很多老板换到一半才发现，数据根本导不出来。有的被要求加钱才给导，有的只能按对方给的格式一点点手动录，录完还怕录错。更麻烦的是，有些系统用的是第三方云数据库，数据存在哪、谁有权限，老板自己都不清楚。 正确的做法是，从第一天就约定数据归属和导出机制。每个季度让开发公司导一次全量数据备份给你，本地留一份。真到换公司那天，数据在手，心里不慌。三、第二家公司，愿意接吗 接手二手项目，是开发公司最不愿意干的活之一。没有文档、架构混乱、代码风格陌生，新团队要一行行读懂别人写的东西再改，成本比新做一个系统还高。所以很多公司要么报高价，要么直接拒单，理由都是同一个：不可控因素太多。 换之前别急着定，先找两三家开发公司聊，把现状讲清楚，让人家评估接不接得了、要多少钱、要多久。注意，口头评估和书面评估是两回事。靠谱的公司会要求你先做一次系统摸底，出一个正式的交接评估报告，写清楚哪些能复用、哪些要重写、风险在哪。 如果好几家都不愿意接，或者报价都接近重新
前阵子一个做环保检测的老板来咨询，说想上一套设备台账系统。他发来一个低代码平台的链接，对方承诺三天上线、价格不到一万，看着确实诱人。结果我们坐下来把业务一捋，发现他的检测流程要经过采样、送检、报告、复检好几道手，同一个样品在不同条件下走的流程还不一样。这种复杂度，真不是拖拽拼装能解决的。 低代码平台这两年确实火，上线快、价格低、自己人就能改，听起来样样都好。但很多老板只看到了宣传里的 "快" 和 "省"，没想过业务复杂之后怎么办。这篇文章把低代码能干什么、不能干什么讲清楚，你再决定要不要用它。一、低代码到底在解决什么问题 低代码平台的核心思路，是把常用的功能模块做成现成的积木：表单、列表、报表、审批流，拖一拖、配一配，一个系统就出来了。它最擅长的是那些流程固定、结构清晰的轻量场景，比如报修登记、库存盘点、客户回访、合同归档。这类需求用低代码搭，速度快、成本低，后期改动自己也能上手，确实比定制开发划算。 判断你的业务适不适合低代码，先看三个特征：功能是不是通用型、流程是不是固定不变、数据量是不是可控。如果三个都是，那低代码平台基本够用，没必要花大价钱定制。二、业务一复杂，低代码就露怯 很多项目一开始看起来简单，做着做着就复杂了。同一个订单，不同客户、不同地区要走的审批流程不一样；一张单据要跟财务系统、仓储系统、外部接口做数据互通。低代码平台在这种场景下就开始吃力，要么配置逻辑绕到怀疑人生，要么开放接口能力不够，要么数据量一上来页面就卡。 最怕的是系统搭到一半、数据录了一半，才发现撑不住。这时候再换系统，数据迁移、人员重新培训、业务停摆，成本比一开始就定制还高。所以复杂度越高的业务，越要把话说在前面，而不是等项目做起来才回头补课。三、比功能更要紧的，是平台和数据 很多人选低代码只盯着功能，忽略了平台本身的风险。数据存在别人的服务器上，系统跑在别人的框架里，平台一旦改版、涨价甚至停运，你的系统怎么办？尤其是医疗、金融、政企这类对数据敏感度高的行业，数据安全合规这一关就过不去，低代码平台基本一票否决。 定制开发虽然前期投入高，但源码、数据、服务器都在自己手里，后续想怎么改、怎么扩展都有主动权。签合同、有验收、找得到人，出了问题有人兜底，这是低代码平台给不了的确定性。四、到底怎么选，先问自己三个问题 拿不准的时候，先问三个问题。第一，流程是固定的还是天天在
前阵子一个做建材的老板过来问，我想做个 APP，多少钱。聊了十分钟才发现，他其实只想让客户在手机上看产品图、留个电话，一个月也用不了几次。这种需求砸钱做 APP，钱花了效果还不一定好。他真正需要的，可能只是个小程序，或者一个 H5 页面。 很多人第一反应都是做 APP，因为觉得 APP 显得正规、上档次。这个想法可以理解，但软件这东西，先选对形态比什么都重要。选错了，后面开发的每一分钱都是冤枉钱。一、先分清 APP、小程序、H5，别让名字唬住你APP 是要下载安装的，装完占手机内存，独立运行，图标长在桌面上。小程序长在微信里，扫码、搜索、从公众号点进去都能打开，用完关掉就行，不用下载。H5 说白了就是一个网页，浏览器打开就能看，一条链接随手就能转发到任何地方。 这三样没有谁绝对高级，只有合不合适。APP 听着响亮，但下载这一步就拦住了不少用户；小程序轻便，可它离不开微信这个圈子；H5 最轻，却承载不了太复杂的业务。 成本和周期也是这个顺序。APP 要同时考虑安卓和苹果两套系统，开发和维护量都最大；小程序在微信生态里，一套代码多端能用，成本周期都低一档；H5 最快最省，但能力和体验也最弱。记住这个顺序，后面看报价的时候心里就有数了。二、什么业务适合做 APP APP 适合那种用户天天要用、离不开的产品。比如企业内部的业务系统，员工每天打开好几次，数据要存在本地，还要配合扫码枪、蓝牙打印机这些硬件。这种场景小程序顶不住，H5 更不行，只能做 APP。 再比如产品需要主动给用户推送消息，像外卖、打车、健身打卡这类，APP 的通知能把用户直接拉回来。小程序也能发消息，但限制多，触达效果差一截。做 APP 还要过应用商店审核这一关，安卓和苹果规则还不一样，上线前后要准备的东西不少。加上用户得主动下载安装，每多一步，就多流失一批用户。这些隐性成本，很多人是做到一半才发现的。 如果你的业务属于低频使用，一年用不了几次，那就要慎重。低频需求做 APP，用户下载完就忘了，成本收不回来。这种情况换个轻的方案，反而更实际。三、什么业务适合做小程序 小程序适合大多数中小商家第一次触网。做点餐、做预约、做会员储值、做报名查询，这些功能都不重，用户用完就走，小程序刚刚好。开发成本比 APP 低，上线周期短，改起来也方便。 小程序还有一个优势是别人比不了的，它长在微信里。客户
前阵子一个做餐饮的老板给我们留言，说小程序花了两万多做好上线，三个月过去，线上订单一只手数得过来。他问是不是小程序这玩意不行，我说小程序本身没问题，问题是没人知道你有这个小程序。 小程序不是做好上线就完事的，它跟开实体店一个道理，店开了不挂招牌、不喊客，自然没人进来。今天把小程序没人用的原因掰开说清楚，每个问题背后都跟着解法，你看完直接照着改。第一个问题：名字起得不好，用户根本搜不到 小程序名字就是它在微信里的招牌，但很多老板把招牌起错了方向。有人图省事直接用公司全名，叫 "XX 科技有限公司" 这种，用户不会拿公司名去搜；有人用生僻的商标名，客户念都念不出来，更别说搜。微信里找小程序，绝大多数人用的是需求词，想吃饭搜 "火锅"，想找人打扫搜 "保洁"，想寄宠物搜 "宠物寄养"。你的小程序名里不带行业、不带地域、不带用户会用的词，就等于在街上开了一家没有招牌的店。 改名字有两个原则：行业词打底，地域词加分。做火锅的就叫 "成都 XX 火锅"，做家政的就叫 "XX 家政保洁"，让别人一听就知道你是干什么的、在哪干。名字确定之前，先在微信里搜一搜，看看用户搜这个词出来的是不是你，这一步成本几乎为零，却决定着小程序一半的流量入口。 还有个小细节，小程序名字不是随便改的，认证后一年能改的次数有限，所以定名字前多花两天想清楚，比上线后发现问题再改要省事得多。第二个问题：只上架不运营，页面半年不更新 很多老板把小程序当成一次性工程，验收上线就再也不管了。结果就是菜单还是开业那天的，优惠活动过期了还挂在首页，留的电话打不通，评论区里用户问的问题没人回。用户点进来看到的是一个 "没人管" 的店，第一反应就是这家店是不是不干了，自然不会再打开第二次。 小程序要有人气，本质上靠内容持续更新。菜品变了改菜单，季节到了换活动，店里忙不过来就在小程序上挂预约入口，甚至每周发一条公告，告诉用户店里最近有什么动静。不用搞得多复杂，哪怕一周动一次，用户也能感觉到这个店是活的、有人在经营。 运营这事不一定花钱，但一定要花时间。实在没人手，就把更新频率定低一点，比如一个月保证动一次，也比半年不动强。用户对你的信任，就是在这一次次更新里攒起来的。第三个问题：没有分享入口，裂变不起来 小程序最大的优势在微信里，分享方便，点一下就能发给朋友、扔进群聊。但很多小程序上线后，连个分享动作的设
在线
电话
微信
需求
TOP