企业官网建设流程全解析

如果你正在准备做一个微信小程序商城、餐饮外卖小程序、或者企业展示类小程序，最常听到的选型建议就是：找三家小程序制作公司做对比，谁家案例多、报价低、排期短就选谁。

这个思路放在几年前还勉强够用，放在现在很容易翻车。案例多不等于你的项目能一次过审，报价低大概率会在后期通过增项和“加急费”找补回来，而一张承诺“30天全包上线”的排期表，可能根本没有算入微信认证、支付商户号、隐私协议、审核驳回这些不可控时间。

很多团队签完合同才发现：小程序后台挂在乙方自己的主体下面，上线后代码不在自己手里，后端接口和数据库连文档都没留下，想换一家服务商就得从零再来一遍。

所以这篇评估指南不是告诉你“哪三家公司最强”，而是帮你建立一套可以复用的选型判断框架。假设你手上有三家候选公司A、B、C，你需要用同样的内容、同样的标准去验证它们，最后得出的不是“谁看起来最牛”，而是“谁的风险最低、谁更适合陪你走完未来三年的迭代”。

真正值得签的公司，不一定是案例最华丽的那个，而是能把“微信平台规则变化”当成成本、把“源码交接”写进合同、遇到问题能讲清楚机制的那一个。

1. 小程序选型评估真正要解决的问题

把名单从三家缩减到一家，表面上是比较“实力”，本质上是评估三件事：技术路线会不会锁死你、乙方对微信平台的理解是否足够深、以及交付后在代码和数据层面你能不能持续掌控。

1.1 被低估的“技术栈锁定”问题

很多非技术背景的决策者签约时只关心“能不能做出来”，不关心“用什么技术做出来”。但技术栈直接决定了：项目以后谁来维护、能不能兼容后续营销需求、换服务商时源码能否平滑迁移。

常见的四种实现路线差异很大：

如果乙方用的是封闭的 SaaS 模板平台，你购买的小程序本质上只是该平台的一个“皮肤”。今天能改的字段，明天可能受平台模板限制改不了；平台调价，你只能被动接受；将来要做深度定制，只有付费插件可以走。

1.2 微信平台规则理解能力，是真正的分水岭

从大量开发项目暴露出的问题来看，支付不到账、iOS 端虚拟支付被限制、订阅消息发送失败、隐私协议未配置导致部分 API 无法调用，这些并不是代码写不出来，而是乙方不了解微信平台的规则边界。

所以评估三家候选公司时，不能只看他们做过多少模板案例，而要看他们能不能解释：某个功能为什么在某些手机系统下不可用、为什么支付回调要验签、为什么用户要点击授权才能收到一次订阅消息。能够把“平台限制”讲清楚的团队，才具备应对规则变化的能力。

1.3 交付后的掌控权：代码、账号、数据、文档

小程序并不是一个“文件包”，而是一套完整的账号体系加前后端系统。选谁能让你以后睡得着，至少要确认这些问题的答案：

• 小程序管理员和微信支付商户号挂在哪个主体名下？
• AppSecret、API 密钥、证书文件有哪些人知道？
• 后端代码和数据库结构是否随项目交付？
• 有没有环境部署文档、接口文档和变更记录？
• 乙方是否把源代码放到了你们自己的 Git 仓库？

这些问题与写代码能力无关，却直接影响项目未来一年的维护成本。评估三家候选公司时，应该把它们放在和“报价金额”同等重要的位置。

2. 先建立技术栈判断力：你能不能让乙方“说清楚怎么做”

不知道怎么判断技术方案，就很容易被销售话术带着走。所以你要掌握的最基本一件事，是打开一个前端项目后，能分辨它到底是原生小程序还是 uni-app/Taro 工程，或者只是一个打包好的产物。

2.1 拿到源码后如何快速识别技术栈

如果乙方愿意在沟通阶段给你看一个演示项目，或者签约后交付了源码，你可以先看项目根目录结构。

原生微信小程序项目一般会有这些文件：

{ "pages": [ "pages/index/index", "pages/goods/detail" ], "window": { "navigationBarTitleText": "门店商城", "navigationBarBackgroundColor": "#ffffff" }, "sitemapLocation": "sitemap.json" }

上面是原生小程序的app.json，负责注册页面和配置窗口样式。如果项目根目录看到这个文件，大概率是微信原生小程序。

uni-app 项目则不使用app.json作为唯一页面入口，而是通过pages.json统一管理页面，并存在manifest.json配置多端信息，典型结构如下：

{ "pages": [ { "path": "pages/index/index", "style": { "navigationBarTitleText": "首页" } } ], "globalStyle": { "navigationBarTextStyle": "black", "navigationBarTitleText": "门店商城", "navigationBarBackgroundColor": "#ffffff" } }

更快的判断方式是在代码根目录执行：

# 进入小程序前端代码仓库 ls -la # 如果看到 app.json / app.js / app.wxss，通常是原生小程序 cat app.json # 如果看到 src/pages.json 和 src/manifest.json，或者根目录的 manifest.json，通常是 uni-app 工程 cat src/manifest.json 2>/dev/null || cat manifest.json # 如果有 package.json，看依赖列表里是否出现 @tarojs/taro cat package.json | grep taro

这些命令本身并不复杂，但它能帮你建立基本的工程认知。乙方技术负责人在讲方案时，你可以直接问一句：“你们的项目负责人能区分原生小程序和跨端框架的实现差异吗？”

一个靠谱的团队会说清楚为什么选择某种方案，比如：

• 因为后续要覆盖 H5 和 App，所以用 uni-app 或 Taro；
• 因为只需要做微信端，且对启动性能有要求，所以用原生；
• 因为业务太标准化，所以先用 SaaS 模板快速上线，等技术验证后再迁移定制。

如果对方回答“没关系，都能做”，还不说明实现上的差异，你就需要提高警惕。

2.2 技术栈判断为什么影响选型结论

从长期看，技术路线直接关系到你能不能低成本地去接其他服务商。

如果你公司内部已经有前端工程师，那么选择与团队技术栈一致的路由会更安全。比如团队熟悉 Vue，选 uni-app 后续可以内部维护；团队熟悉 React，选 Taro 会更友好；如果公司完全没有自研团队，那么选用比较主流的原生或 uni-app 都可行，因为市场上这些工程师的招聘供给更充裕。

反过来，如果乙方用的是自研低代码平台，前端代码高度封装，页面逻辑只能在对方后台配置，你拿到的“源码”可能只是一堆配置文件和二进制产物。这种情况下，项目看起来是“你的”，实际控制权却始终在乙方手里。

给三家打分时，建议先给“技术方案可控性”一个足够高的权重，而不是一上来就比谁家的 UI 图更惊艳。

3. 三家候选公司横向评估模型：五个维度一张表

所谓“制作实力公司”，不能只看销售怎么说。你需要把评估内容标准化，给三家候选公司用同一张表打分，否则很容易被沟通顺序和演示效果影响判断。

3.1 五个核心评估维度

建议从以下五个维度出发：

这五项的权重可以根据自身情况调整。如果公司完全没有技术团队，那么“源码可控性”和“微信规则理解”权重应该更高；如果只是想快速上线一个标准门店商城，对定制要求低，那么可以更看中交付效率与响应速度。

3.2 怎么避免“评分靠感觉”

推荐采用两轮评分法。

第一轮书面评审：把同样的问题发给三家候选人，让他们用文档回复。例如：

• 请画出你的整体架构图。
• 请列出本次项目完成后交给我们的数字资产清单。
• 请说明支付、登录、订阅消息这三大模块的实现关键点。
• 请指出你们的方案在微信审核阶段最容易卡住的是什么地方。

第二轮现场讲方案：要求不是销售或商务来讲，而是实际负责这次项目的产品经理与后端开发来讲方案。因为销售听不懂接口和验签细节，问答环节一问就露馅。

最后根据五个维度，为三家分别打分。注意，总分不是唯一决策依据，如果某一家在“交付资产可控性”上出现明显风险，即便总分靠前，也应该谨慎选择。

4. 重点验证一：微信生态接口和平台规则的理解深度

评估小程序服务商，最容易产生信息差的地方就是微信平台接口规则。一个经验不足的团队可以很快做出“看起来没问题”的页面，但在登录、支付、推送、审核合规这些环节，会频繁踩坑。

4.1 微信登录与 OpenID 体系

任何一个需要后端的小程序，基本避不开wx.login获取临时 code，再把 code 传到后端换取 openid 和 session_key。

一个合格的乙方至少要能解释清楚：为什么不能直接在客户端拿 openid 作为用户身份凭证，为什么服务端要用 code2Session 接口去换身份信息，以及登录态 token 应该如何设计过期时间。如果对方说“我们直接在前端从缓存读 openid”，这个方案从一开始就不安全。

4.2 微信支付：版本差异与回调验签

微信支付是电商、外卖、餐饮类小程序的命脉，也是最容易出现严重问题的模块。

你可以这样问候选公司：

• 现在使用的是微信支付 API v3 还是旧版 v2？
• 支付回调请求如何做签名验证？
• 证书和密钥怎么保存？
• 如果用户支付成功但回调延迟，订单状态如何保证最终一致？

如果候选团队只会“调起支付 + 回调改订单状态”，却说不出掉单处理、对账机制和证书轮换方案，说明他们对于生产环境级别的支付接入经验不足。

还需要和乙方确认：微信支付商户号是否是你们自己申请的，支付资金是否直接进入你们对公账户。正规做法是小程序主体、支付商户号主体、营业执照主体尽量保持一致，避免后续结算和税务问题。

4.3 订阅消息与推送

很多需求方会把“给用户推送通知”误以为像微信服务号模板消息那样随意。实际上，小程序里常规的做法是使用订阅消息，而且一次性订阅消息通常需要用户主动点击授权。

一个可以现场验证的代码层面提问角度是：

wx.requestSubscribeMessage({ tmplIds: ['模板消息ID'], success(res) { // 用户点击允许后，res[模板消息ID] 为 'accept' console.log('订阅结果', res); }, fail(err) { console.error('订阅失败', err); } });

你可以追问：用户在什么环节授权、授权后能发几次、如果用户拒绝能否引导重新授权、长期订阅消息是否适用于自己所在行业。回答得越具体，说明对微信平台规则越熟。

4.4 审核与虚拟支付红线

小程序审核失败是项目延期的高发原因，尤其是涉及虚拟商品或者内容付费时。iOS 端对于虚拟支付有非常严格的限制，很多小程序团队就是因为把“会员”、“充值”、“付费解锁”做成 iOS 内购不支持的形态，导致线上功能被限制。

合格服务商的做法是：在需求评审阶段就提示你哪些业务在 iOS 端可能遇到合规问题，并给出合规调整方案，而不是等上线被拒后再手忙脚乱地改架构。

隐私协议与用户隐私保护指引也值得单独确认。近几年微信平台对用户隐私保护的要求越来越高，小程序如果未配置隐私相关说明，部分能力接口可能被限制调用。一个有经验的乙方，会在开发初期就把这类合规工作纳入排期，而不是把它当成上线前的临时补丁。

5. 重点验证二：源码质量与数字资产归属

当候选团队演示完华丽后台，你要做的最重要一件事是：把注意力从演示界面切换到源码和资产清单上。评估代码质量不需要你变成技术专家，有几项基础检查足够筛掉大部分“半成品外包”。

5.1 检查敏感信息是否写死在源码里

一个常见的安全隐患是开发人员把 AppSecret、支付密钥、数据库密码直接写在前端代码或未加密的配置文件里。

拿到候选团队的项目后，可以执行一次简易搜索：

# 在源码与配置目录下搜索敏感信息 grep -rEn "(AppSecret|SecretKey|api[_-]?key|access[_-]?key|password|BEGIN RSA)" . \ --include="*.js" \ --include="*.ts" \ --include="*.json" \ --include="*.env" \ 2>/dev/null | head -50

如果结果里出现大量密钥和密码，无论前端还是后端项目，都说明工程安全意识不足。这种做法一旦上线，很容易导致支付密钥泄露、服务器被刷接口，严重时会造成资金损失和平台封禁。

5.2 检查 Git 历史与依赖规范性

你还可以要求候选公司提供一个演示仓库，或者让技术人员当面打开他们过往项目的 Git 仓库。重点看三点：

# 查看项目是否持续提交 git log --oneline -10 # 查看是否提交了不该提交的目录 git status # 查看远端仓库地址 git remote -v

健康的项目应该具备频繁的提交记录，而不是只有一个“初始化完成”的巨型提交。node_modules、.env、dist等产物目录不应被强行提交到代码仓库。依赖信息应该由package.json明确描述，其他人拉下代码后可以按文档安装依赖并运行起来。

5.3 资产归属清单

在合同阶段，要把下面这些“数字资产”逐项写进交接清单：

如果你发现候选公司坚持要把小程序后台绑在自己公司主体下，或者服务器只允许使用他们自己的账号，这个合作方案的后续风险就会很高。未来一旦双方关系出现问题，你连最基本的“换服务商”权利都没有。

6. 重点验证三：用 POC 小项目检验真实交付能力

会讲 PPT 的公司很多，真正能把代码跑起来并解决实际问题的团队却不多。在三家候选公司进入最终比较前，建议安排一个轻量 POC（Proof of Concept）环节。

6.1 POC 任务清单设计思路

POC 不需要覆盖全部业务，也不需要让乙方免费开发数周。更推荐的方式是选择业务中最核心、技术风险最高的链路，让候选团队现场演示或给出可运行 Demo。

一个商城类小程序典型的 POC 可以拆成以下任务：

POC 最核心的价值是观察乙方团队如何拆解需求、如何汇报风险、如何应对技术障碍。如果 POC 一开始就说明支付接口必须用真实商户号，这是正常的；如果所有环节都需要“改天演示”，并且没有一个可运行环境，就要小心了。

6.2 POC 验收时怎么判断代码质量

验收时不要只看“页面长得好不好看”, 还要观察实际运行和工程组织：

• 在微信开发者工具中导入项目是否能直接编译成功。
• 页面请求接口是否走 HTTPS，是否存在明文http://请求。
• 用户登录态的 token 是否安全存储。
• 异常发生时是否有统一的错误提示，而不是页面白屏。
• 项目文档是否写明本地启动步骤、环境变量配置和联调地址。

在腾讯云或服务器上部署一个小型测试环境是很好的做法。让候选团队把 POC 后端部署到你们指定的测试服务器，并给出部署日志，这样既验证了技术实力，也验证了文档和协作效率。

7. 报价单和排期表里，最容易被操作的模糊点

经过三家对比后，你手里会有三份报价单和三张排期表。此时要做的不是“挑一个心里价”, 而是把每份报价单里的模糊项一个一个挑出来。

7.1 按“功能点”报价和按“工作内容”报价完全不同

比如同样报“商城类小程序开发 3 万元”，一份合理的报价单应该体现以下内容：

• 前端页面数量与页面明细。
• 后端模块清单与接口数量。
• 是否包含管理后台。
• 是否包含支付、登录、消息推送等基础能力。
• 数据统计和运营工具是否单独收费。

如果报价单只写“小程序商城开发一套”，没有具体交付清单，后期很容易演变成“这个功能不在套餐内，需要额外加钱”。

一个比较稳妥的做法是，在正式签约前先整理一份自己的需求说明模板，包含核心功能模块和验收标准，让三家公司基于同一份需求报价。报价对比只有在同一需求基线前提下才有意义。

7.2 警惕“排期压缩到极致”的方案

常见延期点包括：微信认证、小程序审核、支付商户号审核、隐私协议配置、前后端联调、UI 走查、产品验收反馈。一个有经验的项目经理会在排期表里留出至少两周的“审核与返工缓冲期”。

如果两家公司的排期差不多，第三家却说自己能快三分之一，这时候要问清楚：是通过裁剪开发范围，还是因为模板复用度很高，或者是打算压缩联调和测试时间？如果无法给出合理解释，这种“快”很大程度上只是销售话术。

7.3 合同条款里必须写清楚的验收红线

合同比口头承诺重要得多。尤其在确认三家候选公司时，建议至少要求合同包含以下条款：

• 源代码与设计稿的知识产权归甲方所有。
• 小程序后台、支付商户号、服务器账号等由甲方掌握。
• 最终验收以需求文档中的验收标准为准。
• 上线后免费维护期从“验收通过日”开始计算，而不是从项目启动日计算。
• 乙方应提供部署文档、接口文档和管理员操作手册。
• 付款节点与实际交付物绑定，而不是按模糊的“项目进度”付款。

比较常见的付款比例是“3-4-3”或“3-5-2”，也就是签约付一部分，中期验收付一部分，最终上线验收通过后付尾款。但任何比例都没有标准答案，关键是每个付款节点都要有可验证的交付物。

8. 怎样从三家“实力接近”的候选公司里选最后一家

如果三家公司的报价、排期、案例都差不多，最终决策最忌讳的是“哪家销售更热情就选哪家”。这时候应该做一些更落地的比较。

8.1 让“实际做项目的人”出面沟通

选型进入最后一轮时，可以安排一次技术沟通会。要求每家候选人至少带三个人参加：销售或商务、产品经理、后端开发或技术负责人。

你会发现一个明显差别：

• 实力强的公司：能快速响应技术问题，能给出明确改动点和周期。
• 实力不足的公司：技术问题由销售翻译，甚至出现“这个功能很容易实现，但做的时候再说细节”的模糊表达。

这次会议不是要问倒谁，而是通过互动判断项目执行过程中沟通是否顺畅。小程序的复杂之处不在于单个页面开发，而在于边界模糊时的需求决策能力和风险响应速度。

8.2 用决策矩阵把风险摆到桌面上

在最终对比三家时，可以把每家的优劣势整理成一张决策矩阵：

从这张表可以看出，公司 C 虽然快和便宜，但如果代码控制权低、维护费按年订阅，长期成本可能并不低。公司 A 短期报价更高，却可能拥有更清晰的交付边界和可控的技术路线。

最终选择应该优先排除“不可控风险”，再在剩余选项中挑出与你们现阶段目标最匹配的一家。

9. 给准备签约的你一份可复用的行动清单

选型评估方法看起来很多，落地时可以按下面五步执行：

1. 先不聊报价，先让三家候选公司交技术方案，说明技术路线与微信平台风险点。
2. 拿到可查看的演示项目后，用 Git、源码检查命令快速确认工程质量和密钥管理情况。
3. 统一安排一次 POC 或技术沟通会，让实际做项目的人来回答支付、登录、订阅消息、审核等问题。
4. 整理三份报价单的功能模块差异，确认是否有隐藏后期收费。
5. 合同最终版本里，把源码归属、账号归属、文档交付、免费维护期和付款节点逐项写死。

即使经过这些流程，你也不能保证项目零风险。但至少可以把最容易失控的几类风险，在签约前暴露出来：代码方案不稳定、微信规则不熟悉、交付后无法维护、费用不断上涨。小程序制作公司的实力，最终不体现在 PPT 里有多少酷炫词，而体现在是否能让你在项目上线后依然睡得着觉。