企业官网建设流程全解析

做外包的和找外包做开发的，聊起同一件事经常像两个世界的人。我两边都待过：早年给别人的项目写过微信小游戏模块，后来自己项目忙不过来，也把整条研发线交给过外面的团队。几年下来最大的感受是，微信小游戏外包这件事，真正决定项目成败的往往不是那行代码写得怎么样，而是流程有没有走对。

见过太多甲方拿着一句“我想做个合成类小游戏”就来谈合作，开口就是多少钱、多久上线。合同签了、预付款打了，才发现玩法数值、美术规格、关卡配置这些最基本的东西全都没定，最后做出来的东西和自己脑补的版本差了十万八千里。这不怪外包团队，也不怪甲方难伺候，而是流程从第一步就走歪了。

今天这篇，我打算把整套微信小游戏外包开发的流程拆开来聊透：需求梳理、团队筛选、合同排期、过程管理、测试验收，再到上线后的维护迭代。适合准备把游戏交出去做的创业者、产品经理和独立开发者，只要你想把外包这件事做得可控、不翻车，这些经验能帮你少走不少弯路。

1. 需求梳理：别让“我想做个游戏”变成外包扯皮的源头

1.1 外包团队只按文档做，不按你的脑补做

先记住一句话：外包团队拿到手的不是你的想法，也不是你口头描述的那三句话，而是需求文档。文档里写了什么，他们才能做什么；文档里没写的，做出来效果不对，责任基本在需求方。这不算推卸责任，而是行业里默认的规则。

我自己见过一个很典型的案例。某团队的产品经理想做一个合成类游戏，来找外包谈时，需求描述就只有那一句。问细节，说不急，先报个价。外包团队按市场上常见的合成玩法做了个通用版本，结果版本交付后产品经理直接傻眼——合成公式不对、经济数值节奏不对、卡关点设计不合口味。双方来回扯了两个月，最后只能加钱改，两边都憋着一肚子火。

所以，需求梳理这个阶段再怎么强调都不为过。它是整个外包流程的地基，地基歪了，后面所有楼层都会跟着歪。很多甲方在签合同前最关心价格和工期，恰恰漏掉了最不该省的那一步：把需求从模糊的想法变成能落地的文字和图表。

1.2 一份合格的需求文档至少包含这些模块

按我这些年发包和接包的经验，一份能让外包团队顺利动工的需求文档，至少要覆盖七个模块：

• 玩法概述与核心循环。你的游戏核心玩法是什么，玩家每天进来干什么，玩五分钟和玩一小时分别是什么体验。
• 功能清单。所有玩法模块、系统模块，按优先级排好，哪些第一版必须有，哪些可以放到后续版本。
• 页面结构与主流程。从启动页到主界面到每个子页面，页面之间怎么跳转，关键交互怎么走。
• 美术风格参考。哪怕是几张竞品截图、一段风格描述的文字，都远比“我只要好看”这五个字强。
• 数值体系设计说明。经济数值、关卡难度曲线、养成节奏，不用精确到小数点，但大方向必须定下来。
• 商业化设计。广告位怎么放、内购点怎么设、激励视频在什么场景出现、奖励怎么配置。
• 目标用户与平台限制。微信小游戏特有的包体限制、首屏加载速度要求、低端机型兼容范围。

这里我要专门提醒一下微信小游戏的平台特性。很多人把微信小游戏外包等同于普通手游外包，这是个误区。微信小游戏对包体大小有硬性限制，首屏加载时间直接决定用户留存，还要遵守平台自身的审核规则和运营规范。这些约束条件在需求阶段如果不考虑进去，开发到一半再回头调整，成本和工期都是成倍往上翻。

提示：如果你自己不会写需求文档，最省事的办法是让外包团队在报价前先给你出一版“需求确认稿”，你只负责逐条确认。好的团队会帮你补全需求盲区，差的团队只会把文档里没写清楚的地方当成后续增收的空间。所以哪怕文档是别人代写的，你也一定要逐字过一遍。

1.3 MVP思维：第一版别贪大，砍掉边缘玩法

新手发包最容易犯的错，就是“第一版就想把所有功能做齐”。排行榜要有、好友对战要有、每日任务要有、装扮系统也要有。全塞进去的结果就是工期失控、预算超支、上线日期一拖再拖。

我给的建议一直没变过：第一次外包，只做MVP，也就是最小可行版本。核心玩法、两三个关键系统、最简单的商业化验证，先把游戏跑起来上线，用真实用户数据验证玩法能不能立住，再谈后续迭代加功能。

我自己发包时吃过这种亏。某次做休闲小游戏，第一版塞了五个系统进去，开发到第三个月时发现核心玩法本身的留存数据根本不行，之前做的四个系统全成了白工。当时如果上一个MVP版本，两周就能验证玩法是否成立，根本不用多花那笔冤枉钱。做游戏和做用户调研一个道理，先拿最小成本去验证最关键的那个假设，别让外围功能稀释掉你的时间和注意力。

2. 团队筛选和报价拆解：低价合同背后全是隐藏成本

2.1 找团队的渠道很多，靠谱的不多

微信小游戏的外包团队，找起来渠道其实不少：熟人介绍、外包平台发需求、游戏开发者社区蹲人、朋友圈吼一嗓子都能涌来好几个推荐。但渠道多不代表好选。

我这些年筛选下来，感觉靠谱程度从高到低排序是：熟人成功案例引荐、行业社区里持续输出内容的个人或小团队、外包平台海选。前两种有信任背书或长期公开记录可查，最后一种的筛选成本极高，报价从低到高能差出十倍，而且鱼龙混杂。

怎么筛？第一步先看往期案例。注意不是只看截图和录屏，而是问一句“能不能现场试玩”。能现拿真机演示、讲清楚技术架构和美术管线、聊得透关键决策的团队，和只会丢给你一段介绍视频的团队，可信度完全是两个等级。

第二步看团队构成。做微信小游戏，比较理想的配置是策划、程序、美术各有专人，外包项目还应该有个明确的项目经理或对接人。市面上不少自称团队的，其实是一个人全包。运气好，这个人什么都能搞定；运气不好，任何一环出问题，整个项目就停摆。单干型的团队不是绝不能选，但风险你自己心里要有数。

2.2 报价单拆开看，钱到底花在哪

我见过很多甲方拿到报价单后一头雾水，只看总数，完全不知道钱都花在哪些项目上。这里把微信小游戏外包报价的主要构成拆开讲一下：

报价单最需要问清楚的就三件事：包含什么、不包含什么、变更怎么算。外包项目的大部分纠纷，其实都出在“包含什么”这四个字写得不够细。

2.3 低价团队的逻辑：便宜有便宜的道理

说句不好听的，微信小游戏外包市场里，低价本身就是最大的风险信号。有人想不通：同样一个玩法，A团队报十万，B团队报三万，为什么不选便宜的？我告诉你B团队的真实操作路径：套个开源模板改一改、美术用网上扒来的免费素材、不做真机适配、不写文档、测试全靠开发者工具模拟器跑一遍。交付之后，你发现游戏在部分机型上打不开、低端安卓机进游戏卡成幻灯片、美术素材被原作者投诉侵权，这时候再回去找B团队，人家可能已经不接你电话了。

这不是说报价高的就一定好，而是报价低到不合常理时，你损失的往往不只是那笔开发费，还有几个月的时间和上线窗口期。选外包团队的真本事不是“选个便宜的”，而是“选个性价比合理的”，在行业平均报价区间里多比服务和案例，别只盯着最低价砍。

一个粗略的参考线：包含完整核心玩法、二十到三十个关卡、基础美术规格的休闲微信小游戏，开发周期两到四个月，报价通常在几万到二十几万的区间，具体取决于美术规格和玩法复杂度。低于这个区间太离谱的，基本可以直接排除。

3. 合同和里程碑排期：把口头承诺变成可执行节点

3.1 计费模式怎么选不容易扯皮

微信小游戏外包最常见的计费模式有三种：固定总价、按里程碑付款、按人天计费。不少甲方一上来就选固定总价，觉得省心，但固定总价模式下外包团队最怕需求变更，所以他们会把合同边界写得特别细，范围之外的任何改动都会报出一个不小的价格。这个模式的真正风险在于验收标准难提前界定，只要合同里没写清“验收以需求文档为准”，到了收尾阶段，双方对“到底做完没有”可以吵到天荒地老。

按里程碑付款是我个人最推荐的方式。把开发过程切成几个阶段，每个阶段完成并验收通过后，再支付对应比例的款项。这样甲方不用一次性押上全部预算，乙方也不会累死累活做到一半还收不到钱。双方的利益绑在同一个节点上，沟通起来也会正常很多。

按人天计费更适合需求不明确、试验性质比较强的项目。但微信小游戏开发通常需求相对清晰，玩法、美术、平台都有了明确方向，用这种模式反而容易让成本失去控制。

3.2 里程碑怎么切：建议拆成五个阶段

以我经手过的项目为例，一个典型的外包微信小游戏，我会建议把进度切成五个里程碑，每一段都有明确的交付物和验收标准：

• 里程碑一：立项与原型阶段。乙方出低保真原型图或可玩的核心玩法Demo，重点验证玩法手感和可行性，这个节点通常支付总额的20%到30%作为启动款。
• 里程碑二：Alpha版本。核心功能全部开发完成，美术资源可以先放临时占位图，宗旨是把玩法逻辑完整跑通，此时支付30%左右。
• 里程碑三：Beta版本。正式美术资源全部替换到位，功能打磨基本完成，进入内部体验和玩法调优阶段，此时再支付20%。
• 里程碑四：提审准备阶段。真机适配、性能优化、平台审核素材整理、提审问题修复，产出可提交审核的完整包，支付20%。
• 里程碑五：验收与上线。对照需求文档逐项验收，bug修复清零，源码和文档完整移交，支付尾款。

每个里程碑都要写清“交付什么、验收标准是什么、付款比例是多少”。验收标准不能写“满意为止”这种模糊表述，要写“以需求文档功能清单为准，可复现操作完成且无致命性问题”。这一条看着简单，但能把后面百分之八十的验收扯皮直接堵死。

提示：合同里一定要区分“bug修复”和“需求变更”。程序错误、闪退、关卡无法通关属于bug，乙方应免费修到正常；把“Boss太简单加三倍血量”、从合成玩法改成放置玩法属于需求变更，要按变更机制走评估和报价流程。建议提前约定一张“变更单”，任何需求变化都落到书面，口头讨论一概不算。

3.3 知识产权和源码归属，不写进合同就是别人的

这一条特别容易被忽略。很多甲方签外包合同，注意力全放在价格和工期上，对知识产权条款一带而过。等到两年后想给游戏加个新功能，原团队报了个远超市场价的价格，你才发现合同里根本没写源码归你。

微信小游戏外包合同里，知识产权相关的内容至少要有四段：第一，游戏源码、美术资源、策划文档的版权归属，默认应全部归甲方所有；第二，乙方是否可以在自己的案例展示里用这个项目的截图和演示，给授权可以，但期限、范围要写明；第三，源码是否一次性完整交付，客户端、管理后台、工具脚本一个都不能少；第四，二次开发和后续维护的权利，上线后甲方找其他开发者改代码，乙方不能拿版权卡脖子。

这些条款不写清，项目做完之后的所有主动权都在对方手里。我朋友的公司就遇到过这种事，外包结束两年后要上线一个新玩法，原团队开口就是一笔更高的授权费，理由是“当初合同里没写过源码归属”。这种哑巴亏，一次就够受的了。

4. 开发过程的管理：程序员怕的不是甲方催，而是甲方消失

4.1 外包不是付钱等结果，过程管理要跟上

很多甲方对“外包”的理解就是一手交钱、一手交货。但实际上，外包项目最后烂尾或者交付跑偏，相当大一部分不是因为乙方技术不行，而是甲方在开发过程中处于失联状态。需求没人及时确认、进度没人跟踪、决策没人拍板，开发团队只能按自己理解往下做，最后交付的东西跟预期对不上是迟早的事。

微信小游戏一个开发周期两到四个月，不算长，但也绝对不短。这期间，需求理解偏差、技术方案调整、美术风格走偏，任何一个环节出了状况都是越到后期越难修。甲方至少要保证三件事：每周固定一次进度会，看Demo、确认本周产出、解决卡点问题；每两周要一次能试玩的中间版本，别只看周报文字；项目里要有一个能拍板的人，所有日常决策别层层上报，等不起。

我自己发包的习惯是周五下午固定拉会，周末把最新版Demo完整玩几遍，周一给出修改意见。这个习惯听着简单，但真能省掉后面大量的返工时间，也能让乙方始终感觉到你在这个项目里，而不是“钱给了人跑了”。

4.2 需求变更管不住，预算就是无底洞

行业里有句话叫“需求不变更是侥幸，变更是常态”。微信小游戏这种偏体验类的项目尤其明显。开发过程中，甲方看到Demo后自然会产生新想法：“这里加个转场动画会不会更顺”“这个按钮放左边好像更顺手”。这些都很正常，关键是别让变更变成消耗预算的无底洞。

我的做法是，项目启动时就约定变更机制：小改动，不影响排期和预算的，直接改，攒到一定数量后打包算一个小的任务包；大改动，触及核心逻辑或排期的，走“变更单”流程，先评估改动范围和费用，甲方签字确认后再排期执行。

同时要严格区分bug和变更。提审时发现某个机型打不开游戏，这是bug，乙方必须免费处理；甲方看完竞品后决定把合成公式全部推翻重做，这是需求变更，该报价报价。这个边界不提前定好，十有八九会在开发途中大吵一架。

4.3 美术风格走偏，是外包项目最常见的隐形坑

比需求变更更让甲方头疼的，是美术风格走偏。文字描述风格和实际能落地的美术效果之间，隔着一条巨大的鸿沟。甲方心里想的是“清新可爱的Q版风格”，乙方交出来一个廉价感很重的版本，这种落差基本没法用沟通弥补。

应对办法其实很朴素：别用文字定美术风格，用参考图。项目启动前，至少给乙方提供五到十张风格参考图，越好越具体越好。然后要求乙方在正式美术量产之前，先产出两到三张三选一的“风格试探稿”，方向确定之后再批量铺开。

这个步骤看起来多花了两三天工期，但能避免整个美术资源完成后被全盘推翻的灾难。外包项目里美术返工的成本，往往能占到项目总成本的大头，这笔账算下来，风格试探那点前期投入简直太值了。

5. 测试与验收：上线前最容易翻车的环节

5.1 微信小游戏特有测试项，一个都不能省

微信小游戏和普通手游的测试项有很大重叠，但有几类特有项目格外容易翻车，我建议直接写进测试清单里：

• 包体大小与首屏加载速度。微信小游戏对包体有限制，首屏加载时长直接决定用户打开后是留下还是关掉，弱网环境下尤其要在真实设备上测。
• 低端安卓机适配。系统版本、屏幕分辨率、内存大小都会影响运行表现，至少要覆盖几台入门级、中端和旗舰安卓机各一台。
• 微信版本兼容。旧版本微信和最新版微信对小游戏的支持存在差异，正式提审前要在多个微信版本上实测一遍。
• 支付与广告SDK链路。虚拟支付、激励视频播放、广告回调，任何一个环节出问题，损失的直接就是真金白银。

不少外包项目在验收阶段吵得不可开交，根源在于测试范围和标准没有提前约定。建议在合同阶段就把“测试清单”作为附件写进去，明确测哪些机型、哪些微信版本、哪些网络环境，测完达到什么标准算通过。标准越具体，后面就越没有扯皮空间。

5.2 验收三步走：逐项打勾、列bug清单、复测确认

验收阶段最忌讳的做法，是甲方一句“你先交来，有问题后面再说”。这种话一旦说出口，后面所有问题都会变成“说不清是谁的责任”。我建议验收严格按三步走：

第一步，对照需求文档里的功能清单，逐项试玩、逐项打勾。每个功能都实际跑一遍，核对是否达到验收标准，别只看演示，自己上手玩才算数。第二步，把测试中发现的问题整理成一份带优先级的bug清单，按致命、严重、一般、轻微四档分类，要求乙方按优先级逐项修复。第三步，乙方修完后做复测确认，全部通过再付尾款。

验收通过的标准可以写俗一点，比如“致命和严重bug全部清零，一般bug残留不超过该类总量的10%，轻微bug不影响核心流程和体验”。这一条写进合同，双方心里都踏实很多，比“甲方满意”这种主观表述好执行得多。

还要单独说一句，验收阶段的bug修复周期也要约定，不能无限拖。行业里常见的做法是：致命和严重bug在48小时内响应并开始修，一周内处理完毕；一般和轻微bug在约定时间内修复。具体周期可以谈，但必须有期限。

5.3 提审被拒怎么办，责任划分要提前写进合同

微信小游戏正式上线前，还得过平台审核这一关。被拒的原因五花八门，资质材料的问题、素材和信息填写的问题、内容不符合平台规则的问题、技术性能不达标的问题，都可能让提审包被退回。被拒本身不致命，致命的是合同里没写清楚谁负责处理被拒问题、修改要不要另收费、改一次要多久。

建议在合同里提前约定：提审被拒后，如果是乙方开发实现或配置导致的问题，比如技术规范不达标、某些平台接口配置错误、兼容性不过关，乙方免费负责改到能通过；如果是甲方提供的内容或素材导致的问题，比如甲方指定的某种玩法触碰了平台限制、美术音乐素材存在版权风险，费用和方案由双方协商。别小看这个划分，真到提审阶段，一次修改可能就卡掉一周时间，不提前说清楚，双方都会很难受。

6. 上线后的维护与迭代：外包交付不等于项目结束

6.1 免费维护期内，甲方该盯哪些事

正式上线后，大多数外包团队都会提供一段免费维护期，常见的是三到六个月，也有只给一个月的，具体看合同怎么谈。维护期内通常包含bug修复、平台规则变动导致的适配调整、必要的服务器技术咨询等内容。

这个阶段甲方要做的不是把游戏丢在那里不管，而是盯好四件事：线上数据的异常，比如崩溃率、加载失败率、支付失败率有没有突然飙升；用户反馈里的bug和体验问题，有没有集中到某个功能上的抱怨；微信版本更新后会不会出现不兼容的情况；再把问题清单定期同步给乙方，别攒到维护期结束才提。

我见过太多项目，上线后甲方从此音讯全无，半年后突然发现新版本微信下游戏打不开了，才想起找原团队。这时候免费维护期早过了，对方报个高价，你也没有太多还价空间。上线后第一个月至少主动和乙方碰两次面，把潜在的雷点提前排掉。

6.2 迭代需求别拍脑袋，先看数据再动手

外包项目上线后，绝大多数甲方都会做迭代。这时候最容易犯的错，是“拍脑袋改游戏”：今天朋友说某个按钮不好看就改一下，明天看到竞品多了个功能就也要加，最后改了一堆东西，核心数据一点没涨，反而把原本稳定的版本改出问题。

微信小游戏迭代的正确姿势是先看数据再说话。把核心指标拆出来：次日留存、人均时长、关卡通过率、广告点击率、付费转化率。找到数据的薄弱环节，再有针对性地去提需求。比如次日留存低，优先优化新手引导和前几关体验；关卡通过率卡在某一关，优先调那关的难度和反馈；付费转化上不去，侧重商业化点位和定价策略的改动。

迭代需求同样要走文档流程，哪怕是一个小版本，也要把改动点、改动目的、预期效果写清楚。我见过太多迭代项目，甲方给外包团队甩一句“优化一下商业化”，结果做出来的东西和甲方想的方向完全对不上。迭代再小，流程不能省，这是外包合作里最便宜的省钱方式。

6.3 源码在手，二次开发才有底气

最后提醒一句：外包合同里争取到的源码所有权，真正的价值不是让你把项目存档锁进柜子，而是给了你后续说得上话的底气。

拿到源码之后，就算你暂时不打算换开发团队，也建议找个技术人员把关键部分审一遍，确认文档和源码能对得上、目录结构清楚、关键逻辑有注释、第三方SDK的接入配置不依赖原团队的环境。这样以后想让别的团队接手，或者和原团队继续谈合作，你都不会完全被动。

我碰到过这种情况：外包项目做完上线后，原团队转身接了新项目，腾不出人手做迭代。我拿着源码找新合作方评估，对方看完反馈说“这代码风格和文档质量，接手得加钱”。最后还是多花钱才让人接手。源码交付的完整度，决定了这个项目后续还有多少扩展空间，这件事越早想清楚越好。

这些年外包做过、被外包过，微信小游戏这碗水有多深，我自己心里有数。要说一句总结的话，那就是：整个外包流程里最贵的成本，通常不是开发费本身，而是需求没想清楚就开工、验收没标准就付尾款、出了问题才发现合同里什么都没写。需求文档多花一周，后面往往能省下一个月；合同条款逐字多看两遍，后面可能省下真金白银。准备把微信小游戏交出去做的朋友，我真心建议把这套流程走扎实了，再做决定。项目名义上是外包的，但最终成色如何，始终是你自己那个环节决定的。