行业资讯
上个月有个客户来找我，说店里那套用了八年的进销存系统，"一天都忍不了了"。打开一看，界面是十几年前的风格，报个价要跳四个页面，库存数据偶尔还对不上。老板情绪很激动，张口就是要重做。我劝住了他。不是这套系统不该动，而是 "重做" 这两个字，大多数人没想清楚它到底意味着什么。先分清三个词，别把代价算错改造、重构、迁移，是三件完全不同的事，花的是三种完全不同的钱。改造，是小修小补。某个模块不好用，改掉；某个流程卡顿，捋顺。风险小，周期短，改动范围锁死在局部。迁移，是换底座。系统照用，业务逻辑不动，把背后的技术框架、服务器、数据库换一遍。好比给老房子重新走水电，房子还是那个房子。重构，才是推倒重来。代码重写、数据库重建、页面重做，相当于把房子拆了盖新的。很多客户说 "我要重构"，心里想的其实是 "这系统太难用了，你们帮我改改"。真按重构报价，报价单能把他吓一跳。所以第一件事，是先把话说准，你到底要的是哪一种。什么情况真的该动老系统不是都得动。我判断一个系统该不该动，就看四条。跑不动了。 并发一上来就卡，报表要算半小时，业务高峰期系统直接罢工。这是性能撑不住了，属于硬伤。改不动了。 想加一个功能，开发说 "这个改动会牵连十来个地方"，改一个点要测半个月。系统的结构已经锁死了它的扩展空间。没人会了。 系统是用十几年前的技术写的，当年写它的程序员都转行或退休了，现在全公司没人敢碰，出了事只能干瞪眼。撑不住了。 安全漏洞没人补、数据没有备份、合规要求过不去，风险已经大到不敢让它继续跑。占一条，值得认真考虑动它。一条都不占，那你其实没有重构的理由。什么情况别急着动反过来，我也拦过不少想重构的客户。系统能用、每天稳定跑着、业务都靠它撑着，这种时候最忌讳大动干戈。重构最大的风险从来不是技术，是业务断档。新系统还没跑顺，老系统已经停掉，库存乱了、订单漏了、客户电话打进来没人答得上来，这个损失比系统难用大得多。我见过一个项目，重构做了一半，钱花了，人累了，业务方每天在群里催，最后老系统继续跑着，新系统烂尾在服务器里。根子不是技术不行，是启动之前没人想清楚 "这三个月业务怎么办"。系统只要还在好好干活，就不存在 "必须立刻重做" 的紧迫性。它可以等，等你准备充分。动之前，先盘点三件事决定要动，别急着找开发公司报价。先花半天，把这三件事写在纸上。它到底在撑什么。 这套系统连着哪些业务，断了会死哪
"我不懂技术，怎么跟你们提需求啊？"这句话，做开发的人几乎每周都会听到。说这话的客户，一半是真的谦虚，一半是怕说外行话被忽悠。先说结论：提需求这件事，考验的是你对自己的生意熟不熟，跟懂不懂技术没有关系。你不需要会说代码，需要的是把你每天怎么做事、怎么挣钱、哪里最烦，讲给别人听。这篇不讲大道理，直接给方法。提需求最常见的三个坑先看看需求为什么总说不清，大多逃不开这三个。只报功能名。 "我要一个会员系统"" 我要一个进销存 ""我要一个商城"。功能名听着专业，其实信息量接近零。会员怎么分级、积分怎么算、进销存管到哪个环节、商城谁上架谁发货，全都没说。开发公司听完，只能按自己的理解猜。只说结果，不说过程。 "我要能查库存。" 这句话没错，但库存是怎么来的？是每次进货手动录，还是和供应商系统自动同步？盘点怎么盘？报损怎么处理？过程不说清，做出来的查库存，大概率不是你想要的查库存。需求全在脑子里。 客户心里其实有一套完整的想法，但没写下来，也没讲全。讲到一半觉得 "这个不用说了吧"，结果开发公司真的不知道。需求没有落到纸面上，就等于没需求。这三个坑的共同点，是把 "需求" 当成了 "名词"，而不是 "过程"。讲人话的三件套：讲场景、讲流程、给例子别急着背功能清单，试着用三种方式说需求。讲场景。 不说 "我要会员系统"，说 "我的店长每天下班前，要把当天的充值、消费、退款统计出来，发到工作群里"。场景一说，开发公司立刻知道要做什么、给谁用、什么时间用。讲流程。 不说 "我要一个下单功能"，说 "客户现在是这样下单的：打电话给我，我在本子上记，月底手工对账。我想让客户自己在手机上选、自己付款，账自动对"。流程一说，改造的目标就清楚了。给例子。 你手上如果有现在用的纸质单据、Excel 表格、对账单，直接拍照片发给开发公司。一张真实的单子，顶一百句描述。开发公司照着单子做，跑偏的概率小得多。这三件套有一个共同点：都在说 "你现在的样子"。现在的样子说清楚了，要改成什么样，自然就出来了。分清 "必须有" 和 "可以没有"提需求时，人很容易把什么都当重点。预算有限、工期有限，需求也得排队。把需求分成两堆：一堆是 "没有它，生意没法做"，一堆是 "有了更好，没有也能先跑"。前者先进开发，后者往后排。这招还有一个好处：开发公司拿到需求清单，知道什么是底线、什么是弹性，报价和排期都会实在很多
系统做完，验收当天，客户打开一看："这跟我想要的完全不一样。"开发这边也委屈："当初需求就是按这个做的，怎么现在全不对了。"这个场面，在软件行业太常见了。两边都觉得自己有理，最后闹到互相扯皮、拖尾款、甚至打官司。说句实话，验收当天才发现问题，责任多半不在验收本身，在开发前就埋下了。这篇把验收这件事从头捋一遍：为什么总扯皮、怎么分阶段验收、验收清单该列什么、不合格怎么办。验收扯皮，根子在哪大多数验收纠纷，逃不开三个原因。需求没写清。 合同里写着 "做一个会员管理系统"，但会员等级怎么分、积分怎么算、手机端要不要、报表长什么样，全都没写。没有依据的验收，最后只能凭感觉，凭感觉就有得吵。标准不可量化。 "界面要美观"" 操作要流畅 ""功能要完善"，这些词在验收时一点用都没有。什么叫美观，什么叫流畅，甲方乙方各有一套标准。写进合同的验收项，必须能回答 "达到什么程度算合格"。心态错位。 甲方把验收当成 "找茬大会"，乙方把验收当成 "走个过场"。一个使劲挑毛病，一个使劲糊弄，最后验收变成了拉锯战。这三个问题，都不是验收当天能解决的，都得往前挪。聪明做法，是分阶段验收别把宝押在 "最后那一次" 上。项目周期里设几个验收节点，每个节点确认一次，问题早暴露、早修正，成本最低。需求确认阶段。 需求文档和原型图出来后，先验收一次。确认功能清单、页面结构、业务流程，这一关过了，后面开发才有据可依。开发中演示。 开发到一半，约一次演示。看看界面方向对不对、流程顺不顺，这时候改，改的是局部；等到全部做完再改，改的是全局。上线试运行。 系统部署上线后，不要急着终验，留出试运行期。真实业务跑几周，数据对不对、有没有报错、业务人员用不用得惯，这些问题只有真实使用才会暴露。终验。 试运行没问题，再走正式验收流程，签署验收确认。分阶段验收还有一个作用，它逼着双方每过一关都把问题摊开说，而不是攒到最后一刻爆发。验收清单，该列这些项不管项目大小，验收清单至少覆盖这几个方面。功能：逐条对照需求，每个功能点实际点一遍，而不是听对方说 "都做了"。数据：测试数据跑几轮，看数据是否正确、统计是否准确、导入导出有没有丢。性能：正常业务量下，页面响应、操作流畅度、并发承受能力。性能指标应该在需求阶段就定下数字，比如 "查询响应 3 秒内"。兼容与适配：不同浏览器、不同手机型号、不同系统版本都要过一遍，业务越依赖线
选软件开发公司时，不少企业会纠结一个问题：本地公司，还是外地公司？一线城市的团队规模和技术储备看起来更有吸引力，本地公司的沟通和响应又让人更踏实。两边都有道理，但多数企业在对比时，比错了重点。下面我们直接把两类选择的差别、适用场景和签约前要确认的事项讲清楚。 软件外包的坑，大多出在沟通环节做过软件采购的人应该都有体会：项目延期、返工、验收扯皮，真正的原因往往不是技术能力，而是需求没对齐。需求不明确，是大多数项目的起点。企业方知道自己要"一个管理系统"，但管什么、怎么管、哪些流程要覆盖，通常要到开发过程中才逐渐清晰。这个过程中，需求确认的效率决定了整个项目的节奏。当面沟通的优势在这里体现得很直接。白板画图、现场比划、边说边改，一次需求访谈可以明确七成细节。远程沟通则要依赖文档往返，一份需求文档改七八个版本，是远程项目里常见的现象。软件项目的工期，很大一部分消耗在需求确认上。沟通距离每增加一档，这段工期就相应拉长。 本地公司的价值，体现在响应和介入深度本地公司的优势，通常不体现在报价单上，而体现在几个关键节点。需求阶段，可以高频安排面对面访谈，原型确认、页面评审都能随叫随到，减少理解偏差。上线阶段，系统出现问题可以当天响应，严重时直接到场处理，不必排队等工单。迭代阶段，长期的小改动、流程调整，一次面谈就能定清楚，不需要来回两轮邮件。这些看起来是"便利"，实质是对项目风险的控制手段。对依赖系统运行的业务来说，响应速度不是加分项，是刚需。外地公司的风险，主要在交付链条一线城市公司聚集了大量工程师，技术底子通常不错，这一点不否认。但需要留意一个事实：签约的公司和执行团队，可能是两拨人。外包行业转包现象普遍，销售端承诺方案，执行端拆分到下层团队，验收时对接人可能已换过一轮。这种结构下，质量控制和责任追溯的成本会明显上升。远程沟通的隐性成本同样存在。需求文档往返、验收时的理解偏差、响应时间的延迟，在项目周期里都会被放大。软件项目一半的问题出在沟通上，距离会加剧这个问题。远程外包能胜任的场景需要说明，远程外包有它适用的场景，并非所有项目都必须本地化。需求已经明确。功能清单、页面结构、业务流程、验收标准都白纸黑字定好，远程执行和本地执行的差异不大。标准化程度高的产品，如电商模板、企业官网、管理后台，远程团队往往因为交付经验多，效率和性价比更高。企业方有熟悉技术的人员参与管理，能把远程
"我想做个 APP。"来咨询的人，一大半开口都是这句。你再问他：这个 APP 打算解决什么问题？用户什么时候会用？很多人答不上来，说 "就是觉得现在做生意，应该有一个"。这话没毛病，但方向容易跑偏。你需要的可能根本不是 APP，是个小程序，甚至公众号就够。这三样不是越高级越好，是越合适越好。为什么人人都想做 APP？说到底是被带着走的：看同行做了、听人说了 "APP 才显得正规"、或者就是直觉觉得 "手机上的东西都叫 APP"。这些理由都成立，但都跟 "你的生意需不需要" 没关系。先把 "别人有什么" 放下，想想 "你的用户要什么"。这三样，到底是干嘛的公众号，是给别人看的。发文章、发通知、放个菜单，用户在微信里关注你，你发的东西他能刷到。它的本事是 "触达"：隔三差五能跟你说上话，新品、活动、行业动态，都能送到人眼前。但它不适合 "办事"。让用户在公众号里下单、约课、查余额，流程绕、体验一般，用户操作两步就想退出去。公众号的价值是 "把话说出去"，不是 "把事办完"。小程序，是给别人用的，但用完就走。扫码进来自助点单、约时间、查余额、领券，办完事关掉，不用下载。它的本事是 "方便"：没有安装门槛，路边的海报、桌角的二维码，扫一下就能用，用完也不用想着删。小程序的短板是 "存在感低"：用户办完事就忘，很难主动想起你。指望它做品牌沉淀、做深度互动，不太现实。它是 "办事的窗口"，不是 "留人的家"。APP，是让人装到手机里、天天打开用的。能做推送、能用摄像头定位这些手机能力，用户粘性最强，天天见。它适合真正的高频场景：打卡、记账、刷内容、下单，一天不开就难受。代价也最大：要下载、要过两个应用商店的审核、开发和维护都最贵。最怕的是做成一个 "装了没人用" 的 APP—— 用户下载那一刻的热情，撑不过三天。所以别问 "哪个高级"，问 "你的用户是来看、来用、还是来常驻"。做哪种生意，上哪种车开店的—— 餐饮、美容、健身、教培这些，用户到店要办的事就那几样：点单、约课、办卡、查余额。拿餐饮举例：扫码点单、会员储值、优惠券，这些事用户打开就办、办完就走，小程序正合适，还便宜、上线快。你不需要他天天打开你的店，他要吃的时候能找到你就够了。这类生意做 APP 的很少，做了也多半是浪费：用户不会为了吃顿饭专门下载一个 APP。做平台、商城、高频工具的—— 用户天天用、要推送、要提醒
谈项目的时候，最常听到的对话是："这个系统多久能做出来？" "正常的话，两个月。" "能再快点吗？"两个月后，需求还没聊完的大有人在。不是谁在骗你，是 "开发" 这两个字，在大家脑子里理解的不一样。你以为是 "写代码" 要两个月，实际上写代码只是中间一段。这篇文章把一套软件的真实时间构成拆开给你看，看完你就知道：周期长在哪、哪些能压、签约前怎么把工期谈实。一个项目的时间，其实花在五个环节以一套常规的定制管理系统为例，周期大概是这样的：需求梳理：1-2 周。把你要做的事一条条聊清楚、写成文档。这步最容易被跳过，也是后面返工的根源。界面设计：1-2 周。出原型、出视觉稿，你看着像 "还没开始写代码"，其实这步决定后面改多少。开发：4-8 周。这才是大家以为的 "做软件"，前端、后端、数据库一起上。测试：1-2 周。自己测、给你测、发现问题修掉。上线部署：3-7 天。装服务器、配域名、导数据、试运行。加起来，一套常规定制系统 2-4 个月，是正常区间。说 "一个月上线" 的，要么是模板套壳，要么后面必有加急费。（以上是常规项目参考，具体周期以实际评估为准。）为什么实际总比报价时说的长？报价时给你的周期，是按 "理想状态" 算的：需求一次聊清、决策人当场拍板、你随时在线、开发不出意外。实际不是这样，时间基本丢在这四个地方：沟通往返。 一个需求点要确认三遍：先微信问，再开会定，会后又变。每次往返看着不起眼，攒起来就是一两周。改动返工。 做完的功能要改：字段加一个、流程换一下、样式调一版。改一次看着快，但牵一发动全身，测过的还要重测。联调对接。 系统要对接支付、短信、硬件、别的系统，对方配合慢，你就只能等。验收扯皮。 "这个和我要的不一样"—— 哪里不一样，说不出来，又得来回对。哪些项目真的能快？不是所有项目都要两三个月，看你在哪一档：快（2-4 周）：展示型页面、营销小程序、模板改改就能用的系统。需求基本固定，没什么定制逻辑。常规（2-4 个月）：带业务流程的管理系统、小程序 / APP 的第一版。上一条说的五个环节都跑一遍。慢（4 个月以上）：对接硬件、对接老系统、多端同步、复杂权限、高并发，或者需求还在变。判断标准一句话：要跟别人系统打交道越多、流程越绕，越快不了。想压缩工期，真正有用的几个办法想快点上线，砍的不是开发，是这些：需求写细再开工。 把你要做的每件事列出来，哪
前两天一个做传统生意的老板来聊系统，其他问题都还好，问到数据，他明显犹豫了一下："数据是不是都存在你们那边？"我知道他真正想问的不是技术，是：这些家底交出去，还安全吗？这个问题没有标准答案，但确实有一套问法。别急着让人报价，先把下面几句聊完。先反问自己一句：数据泄了，怕不怕？聊数据安全，第一件事不是问技术，是问自己：这套系统的数据，丢一份或者漏出去，你会不会睡不着？客户名单、报价体系、进货渠道、财务账 —— 这些数据一旦出事，轻则丢生意，重则伤根基。越靠这几样，越不能随便交出去。反过来，如果系统里存的都是能重新补的记录，丢了也就丢了，那就不用纠结，怎么省心怎么来。有的行业，规定已经替你选了做政务、金融、医疗这些，不用你自己纠结。等保、数据不出境、行业监管、甲方合同里写着 "必须部署在指定环境"—— 规定已经把答案写好了，就是私有化部署。这种情况别讨论性价比，合规是底线，先照着要求办。钱的事，按三年算很多人一听私有化就摆手："太贵了。"其实得看怎么算。云端按月按年付，第一年看着便宜，用三年五年加起来不是小数目，人一多还按人头加钱。私有化前期要买服务器、买授权，看着吓人，但后面主要是运维费，用久了反而摊薄，而且系统是自己的资产，不是租的。一句话：别比第一年，比三年。最难的不是装，是养这一条能劝退一半想私有化的人。系统装完不是结束。服务器要打补丁、要备份、半夜可能要处理告警，这些都得有人管。公司里没个懂技术的人，要么花钱外包，要么硬扛。硬扛的常见结局是：备份没做过、补丁没打过，出事那天才发现系统早就在裸奔。所以先回答：这套系统，以后谁维护？给自己留条退路最后想一个长远的问题：三年后要是换系统，这堆数据搬不搬得走？云端的系统，数据能不能导出、导出什么格式、迁移麻不麻烦，全看服务商。有的系统看着好用，数据却锁死在里头，想走都走不了。私有化的数据在自己手里，想对接、想换，主动权在你。如果拿不准，就选一条折中路：先用云端跑，签约时白纸黑字写清楚 "数据随时可完整导出、格式开放"。最后，签约时记得问这一句说了这么多，其实就一句话：数据是你公司的资产，不是系统的赠品。不管最后选云端还是私有化，签约前都把这句话问清楚 ——"我们的数据存在哪？以后能不能完整导出来？"对方答得含糊，直接换下一家。
到底软件开发该不该找人做，还是买个现成的就行。这个问题问得最多的是两类人：一类觉得定制贵，想省事买现成的；一类买完现成的发现不好用，又回头想定制。两边都花了冤枉钱。其实这不是技术问题，是算账问题。下面 4 个问题过一遍，答案基本就出来了。先说清楚两种选择是什么买现成的（SaaS 或成品软件），意思是你的业务去适配软件的流程。它怎么设计，你就怎么用。好处是便宜、上线快，坏处是它不会为你一个人改。定制开发，意思是软件来适配你的业务。你要什么流程就做什么流程。好处是贴合、想改就改，坏处是贵、周期长。没有哪个绝对好。关键在于你的情况更靠哪边。问题一：你的业务流程是通用的，还是独有的？做进销存、客户管理、报销审批这些，全行业都差不多，现成系统完全够用，没必要花定制的钱。但你要是做的是冷门行业，比如特殊品类的生产管理、带行业规矩的审批流、要和自家设备对接的流程，现成系统大概率没有，或者有但不好用。这种情况，定制才是正解。判断标准：你描述业务流程的时候，如果对方软件销售一听就懂、直接给你演示功能，说明你的业务够通用；如果你讲了半天对方还在问 "这个场景我没见过"，那基本得定制。问题二：你愿不愿意改自己的流程去适应软件？这是最容易被忽略的一问。很多人买现成系统之前信心满满，买回来发现：得按软件的逻辑重新捋流程，员工要学新操作，以前的干法全得变。如果你愿意改，而且改了不伤业务，那现成系统很划算。如果你死活改不动 —— 比如行业规矩就是那样，客户就认那套流程 —— 那就别硬买，硬买的结果是系统买回来吃灰。问题三：这个系统以后会大改吗？业务几年内很稳定，流程十年不变，买现成的没问题，反正也不用改。但你要是正处在扩张期，或者业务模式年年变，现成系统的短板就出来了：想加个功能，要么做不了，要么得加钱等排期，要么整个方案换掉。这种时候定制 + 一个好架构，比买现成划算，因为架构是为你以后的变化留的口子。问题四：数据在谁手里？这条最容易被普通老板忽略。买现成系统，数据存在服务商的服务器上；哪天你不续费、或者服务商调整业务，数据取不取得出、取出来能不能用，都是问题。如果你的数据敏感，比如客户名单、报价体系、生产配方，或者公司有硬性要求必须数据自己掌握，那至少要考虑私有化部署或者定制开发。数据握在自己手里，晚上睡得着。顺便算一笔账：现成系统的隐形费用很多人觉得现成系统便宜，其实算总账不一定：按年
很多客户选公司只看两样：报价低不低、案例多不多。这两样都不太靠得住。报价低可能是没算清楚，案例多可能是包装出来的。判断一家公司靠不靠谱，其实用不着多高深。签约前把下面 8 个问题问一遍，回答的质量基本能说明问题。1. 你们怎么了解我的需求？上来就报价格、催你签约的，先放一边。靠谱的公司会先问清楚：你要解决什么问题、现在是怎么干的、系统给谁用。他问得越细，后面返工越少。判断标准很简单：聊需求的时间比报价格的时间长，基本靠谱。2. 这个项目谁来负责？问清楚：项目经理是谁、开发几个人、有没有专职测试。一人包干不是不行，但你要知道风险 —— 这个人一离职，项目可能就停了。还有一句值得问："这个项目是你们自己人做吗？" 有的公司接单后转包给别的团队，这一问能筛掉一批皮包公司。3. 报价单里包含什么？让公司把报价拆开：需求、设计、开发、测试、上线各占多少，包含几次修改、多久维护。不给明细、只说 "全包" 的，后面大概率加钱。顺带问一句：超出需求范围的新功能怎么算钱？这是扯皮高发区，最好提前说清楚。4. 你们用什么技术做？不用懂技术，但要看对方能不能把技术讲明白。问 "系统用什么架构、数据怎么存、以后业务量大了撑不撑得住"。支支吾吾答不上来的，技术团队可能很弱。再问一句系统用什么语言开发。以后你们自己维护或者换人维护，用的技术越主流越省事。5. 合同里怎么写？重点看四条：付款节点：别一次性付清，按里程碑付，做完一步付一步。验收标准：什么算做完，白纸黑字写清楚。源码归属：验收付款后归客户，必须写进合同。保密条款：你的业务数据不能外泄，违约怎么赔。这四条缺一条，合同就先别签。6. 上线之后谁管？问清楚：交付后有没有免费维护期、多久、超出怎么收费、平时有问题响应多快。系统不是做完就完，业务一变就要改。售后跟不上的公司，报价再便宜也别选。7. 有没有同类案例？要案例别只看效果图，问三个问题：这个项目做给谁的、什么时候上线的、现在还在用吗。还在稳定运行的老案例，比一堆漂亮截图有用得多。8. 能不能先小范围试一下？第一次合作，可以从一个小功能或者一个模块开始。做得好，再放心把大项目交出去。愿意让你先试的公司，通常对自己的水平有底。总结 8个问题问完，公司靠不靠谱，心里基本有数了。问的过程也是互相摸底 —— 正经公司不怕你问，反而会觉得你是个懂行的客户。要是对方答得含糊、催你赶紧签约、又
做软件这一行，被问得最多的一句话是：做一套软件要多少钱？问的人从做餐饮的到搞机械加工的都有，上来第一句基本一样。说实话，这个问题没法直接答。就像问装修一套房子多少钱，得先知道多大面积、什么档次、装到什么程度。但钱花在哪、为什么有的报 3 万有的报 30 万，这个能讲清楚。下面拆开说。一套软件的钱，主要花在四个地方需求梳理（约占 5%-10%）。把你想做的事，翻译成系统能做的事。这块最容易被跳过，跳过的后果是后面不停返工 —— 改一处动全身，钱就是这么多出来的。设计（约占 10%-15%）。界面设计是一部分，更重要的是数据库结构设计。地基打歪了，后面跑得再顺也是危房。开发（约占 50%-60%）。这是大头，按人天算。一个工程师干一天是一个价，一个团队干一个月是另一个价。测试和上线（约占 10%-20%）。功能测试、性能测试、部署、试运行。有些低价报价单里没有这块，系统上线一堆问题，客户自己当测试员。比例是行业大致水平，不同项目会浮动，但大方向没错。2026 年市场行情，大致是这样的以下按成都本地市场估，不同城市、不同公司有差异，具体以实际评估为准：简单系统（内部工具、简单后台管理）：3 万 - 8 万常规业务系统（进销存、客户管理、审批流）：8 万 - 20 万行业定制系统（复杂流程、对接硬件或第三方系统）：20 万 - 50 万大型平台（多端、高并发、复杂业务）：50 万起步，上不封顶注意，这不是报价单，是区间参考。而且不是功能越多越贵 —— 有些看着功能多的系统反而便宜，因为都是成熟模块拼的。同样说 "做个管理系统"，为什么报价差十倍差别不在嘴上说的功能，在这几件事：真定制还是套模板。拿现成模板改改 logo 和字段，3 万能做；从需求开始一步步做，20 万起步。一个叫套模板，一个才叫定制开发。团队结构。一个全栈工程师包干，和一个前后端加测试加项目经理的团队，报价当然不一样。人少不一定差，但人少意味着很多环节没人盯。报价里包了什么。有的报价只含上线，后面改需求、修 bug 另算；有的含一年免费维护。问价时一定问清楚：这个价格里面，到底包含什么。烂尾风险。这个不在报价单上，但比报价重要。低价接了单，做到一半发现亏钱，项目停在那儿，最后吃亏的是客户。客户最容易踩的三个坑比价只比总价，不比交付内容。A 公司报 10 万含一年维护，B 公司报 6 万不含维护，算总账
做小程序这几年，被问得最多的一个问题：为什么我的小程序这么卡。卡的原因翻来覆去就那几个 —— 包体超了、setData 用猛了、接口串着调、启动链路太长。单拎出来都不难，难的是不知道先弄哪个，改了一通发现白屏还在。我们按实际踩坑的顺序来：先砍包体，再弄首屏，接着处理数据更新，最后补监控。这个顺序别乱，乱了容易白忙。一、先把包体砍下来 微信小程序主包和单个分包上限 2M，整个小程序 20M。这条硬限制卡死过不少项目。我们接过一个，主包超了传不上去，一查，问题全在主包：页面不分包全塞进去、图片没走 CDN 本地打包、组件库全量引入其实就用了一两个组件。 分包不是可选项，是必做的。tabBar 页面留主包，其他页面按业务拆。新手容易栽的一个细节：分包之间公共代码要抽到主包，不然每个分包都打包一份公共库，总包越拆越大。{"pages": ["pages/index/index", "pages/mine/mine"],"subPackages": [{ "root": "pages/order", "pages": ["order/list", "order/detail"] },{ "root": "pages/mall", "pages": ["mall/home", "mall/goods"] }],"preloadRule": {"pages/index/index": {"network": "all","pages": ["pages/order/order-list"]}}}preloadRule 记得配。用户点进 tab 的时候，该去的分包已经悄悄拉下来了，体感就是秒开。network 别只设 wifi，用户流量没那么金贵，体验要紧。包体瘦下来，启动也跟着快。小程序冷启动的 JS 代码注入是按代码量算时间的，代码少了，注入就快。光这一项，能顶掉一半的启动优化。二、首屏白屏，一半是自找的 排查下来，首屏白屏的根因基本三种：onLaunch 或 onLoad 里干了重活、首屏接口串行调用、页面引了大图或 base64 图。前两种最常见。 接口能并行就并行。有个首页，三个接口本来串着调，最后一个要等快一秒，页面就干等。改成 Promise.all 之后，首屏明显快了一大截。这个改动成本最低、收益最直接，建议先做。 骨架屏该上上，但别指望它解决慢的问题。它
客户来问 AI 客服，我一般会先问一个问题：你说的 AI 客服，是让它答你产品的常见问题，还是想让它像销售一样跟客户聊？ 十次里有七次，对方会愣一下，说 "这个我们还没想过"。 这个回答我太熟了。找我们做 AI 功能的客户，开口都是 "我们要做个 AI 客服"，问下去，有人想给售后减负，有人想把销售话术统一，还有人纯粹是看同行上线了 AI，自己不能没有。需求完全不一样，方案、预算、工期，差得不是一点半点。 这篇不打算讲概念，概念网上到处都是。我写点实在的：接大模型 API 这事，钱花在哪、坑在哪、哪些事别一开始就想岔了。先泼一盆冷水：别急着训模型 先说结论，可能有点得罪人：绝大多数企业做 AI 功能，不需要训练模型，连微调都未必用得上。 现在通用大模型 API 开箱就能干的活不少，答客服、写文案、做资料问答、抽结构化信息，都行。真到需要自己动模型的程度，基本绕不开三件事：数据出不了内网、响应要极低延迟、业务知识非常垂直而且 API 怎么调都不准。 举政企项目说，数据不出域是硬要求，那就只能私有化部署。这跟买 API key 完全是两个量级：GPU、运维、模型版本管理全得自己扛，成本至少翻几倍。反过来，只是给内部员工做个知识库问答，数据不敏感，直接调 API 就是最划算的。 所以我们谈需求，顺序是反的：先问数据能不能出去、业务允不允许用公有云，再谈选哪个模型。这两个问题没有答案，后面聊的全是白聊。接 API 最容易翻车的地方 模型选型其实最省事，各家接口基本都兼容 OpenAI 那套格式，换模型就是改个参数。真正耗时间的是工程。下面四个坑，是我们被坑得比较多的。 超时和重试，代码必须写对。大模型生成是流式的，慢的时候几十秒都正常，网络层默认超时根本不够用；反过来完全不设超时，服务一挂，请求全堆在那儿，把别的接口也拖死。我们最早就是吃了这个亏，才沉淀出下面这个模板：import timeimport requestsdef call_llm(prompt, model="qwen-plus", max_retries=3): url = "//api.example.com/v1/chat/completions" payload = { "model": model, "messages": [
在线
电话
微信
需求
TOP