企业做软件定制开发，到底应该先做需求还是先找软件公司？
![]()
西安摩高互动![]()
2026-08-28![]()
58
2026-08-28
58# 企业做软件定制开发，到底应该先做需求还是先找软件公司？
很多企业第一次准备开发软件时，都会遇到一个看起来很简单、实际上很容易走弯路的问题：
**到底应该先把需求全部整理清楚，再找软件开发公司？还是先找一家软件公司，让他们帮助梳理需求？**
这件事情没有绝对的答案。
但从多年软件项目开发的实际经验来看，如果企业要求业务人员在没有专业产品人员参与的情况下，把一套复杂系统的所有需求提前整理完整，往往并不现实。
更合理的方式是：
**企业先明确业务目标和核心问题，再让软件开发公司参与需求梳理，双方共同把业务想法逐步转化成可以开发、可以验收的软件需求。**
这两者看起来只差了一步，实际上会直接影响后面的项目周期、开发成本和最终效果。
---
## 一、企业真正需要准备的，不是一份完整需求文档
很多老板在找软件开发公司之前，会要求公司内部先写一份详细需求文档。
这件事情本身没有错。
问题在于，很多企业并不知道一份真正可以用于软件开发的需求文档应该包含什么。
例如，一家企业准备开发一个项目管理系统。
老板可能会提出：
* 要有项目管理；
* 要有人员管理；
* 要有合同管理；
* 要有进度管理；
* 要有数据统计；
* 要有审批流程；
* 最好能够手机上使用。
这些内容可以说明企业“想做什么”，但还不能直接进入开发阶段。
因为软件真正需要解决的是另外一层问题：
项目怎么创建？
谁可以创建？
一个项目有哪些状态？
项目负责人可以修改什么？
不同角色看到的数据是否一样？
合同和项目之间是什么关系？
审批通过以后，哪些数据发生变化？
项目延期以后，系统怎么处理？
统计数据按照什么口径计算？
这些问题如果没有明确，开发人员就只能根据自己的理解去实现。
**所以，企业前期真正需要准备的，并不是一份看起来非常完整的功能清单，而是把自己的业务目标、现有流程、使用人员和核心痛点讲清楚。**
剩下的很多工作，本来就应该由专业的软件产品人员参与完成。
---
## 二、为什么企业自己写需求，反而容易把项目做复杂？
这是很多企业在软件项目中非常容易出现的情况。
因为企业内部人员最熟悉自己的业务，所以很容易把现有工作方式一项一项搬进软件。
比如原来一个业务流程需要经过五个人签字。
做系统的时候，企业可能会直接提出：
“系统也按照五级审批来做。”
但真正分析之后可能发现，其中两个审批环节只是过去因为纸质文件流转不方便而产生的，现在使用系统以后完全可以取消。
如果只是按照企业提交的功能清单开发，软件公司可能会把这五级审批完整做出来。
系统是做出来了。
但是企业的问题并没有真正解决。
这就是一个很典型的现象：
**把线下流程搬进软件，不等于完成了数字化。**
软件开发真正有价值的地方，不只是把按钮、表单、审批流程做出来，而是把企业的业务规则转化成一套更加清晰、高效、可执行的数字化流程。
---
## 三、但是，这并不意味着企业什么都不用准备
另外一个极端也不可取。
有些企业会认为：
“我不懂软件，需求你们自己想办法。”
这同样容易造成问题。
软件公司再专业，也不可能完全代替企业理解业务。
尤其是一些行业性比较强的系统，里面可能存在大量只有企业内部人员才知道的业务规则。
例如：
* 哪些数据属于核心经营数据；
* 哪些岗位拥有特殊权限；
* 哪些业务情况属于例外；
* 哪些审批环节必须保留；
* 不同部门之间如何协作；
* 现有系统有哪些历史数据；
* 哪些业务规则不能改变。
这些内容，软件公司无法凭空判断。
因此，一个好的软件项目从一开始就应该形成这样的关系：
**企业负责讲清楚业务，软件公司负责把业务转化成产品和技术方案。**
而不是企业负责“设计软件”，软件公司只负责“写代码”。
---
## 四、企业在找软件公司之前，最好先回答五个问题
如果企业目前还没有整理需求，其实不用急着制作几十页甚至上百页的需求文档。
先把下面五个问题想清楚，往往更加有价值。
### 1. 为什么要开发这个系统？
不要只回答“因为公司需要数字化”。
应该具体到业务问题。
例如：
“现在项目资料分散在Excel、微信群和纸质文件里，项目负责人无法实时掌握整体进度。”
这就是一个比较明确的问题。
---
### 2. 谁是系统的主要使用者？
至少需要明确核心角色。
例如：
* 管理层；
* 部门负责人；
* 普通员工；
* 财务人员；
* 项目负责人；
* 外部合作人员。
不同角色对应的功能和权限可能完全不同。
---
### 3. 现在这项业务是怎么做的？
这一点非常重要。
很多企业直接告诉软件公司：
“我要一个项目管理系统。”
但如果能够把现在的工作方式展示出来，比如：
“项目从立项开始，由A部门发起，B部门审核，C部门执行，财务在某个节点参与，最后由D部门归档。”
软件公司对需求的理解会准确很多。
**一套真实的业务流程，往往比几十条功能描述更有价值。**
---
### 4. 哪些问题是最需要解决的？
软件项目一定存在优先级。
不可能第一阶段把所有想法全部实现。
企业最好提前区分：
**必须解决的问题、希望解决的问题、以后可以解决的问题。**
这样才能判断第一期到底应该做多大。
---
### 5. 未来有没有扩展计划？
比如现在只需要一个内部管理系统，但未来可能连接：
* ERP；
* OA；
* 财务系统；
* 微信；
* 企业微信；
* 物联网设备；
* 数据平台；
* AI知识库。
这些信息不一定意味着第一期就全部开发，但会影响前期的技术架构设计。
---
## 五、真正专业的软件公司，应该在需求阶段做什么？
企业找软件开发公司，并不是把一份需求清单发过去，然后等待报价。
比较合理的合作过程应该是一个逐渐明确的过程。
通常可以分成几个阶段。
### 第一阶段：了解业务
先了解企业的行业背景、组织结构、业务流程以及当前存在的问题。
这一阶段不应该急着讨论技术。
因为如果业务都没有理解清楚，直接讨论使用什么框架、什么数据库，其实意义并不大。
---
### 第二阶段：梳理业务流程
把企业原来的口头描述、Excel、纸质流程、聊天记录等信息，逐步整理成清晰的业务流程。
例如：
**业务发起 → 信息录入 → 部门审核 → 业务处理 → 结果确认 → 数据归档 → 统计分析**
到了这个阶段，很多原本模糊的问题就会暴露出来。
---
### 第三阶段：形成产品结构
在业务流程明确之后，再进一步拆分系统模块。
例如：
**用户与权限 → 项目管理 → 合同管理 → 流程审批 → 数据管理 → 消息通知 → 数据统计**
这时候讨论功能，才开始变得有意义。
---
### 第四阶段：确定哪些功能真正需要开发
这是非常重要的一步。
因为需求梳理并不是“越详细越好”。
真正好的需求分析，应该帮助企业判断：
**什么应该做，什么可以不做，什么应该第一期做，什么应该放到第二期。**
如果一个软件项目一开始就把所有想法全部装进去，项目很容易失去边界。
---
### 第五阶段：再讨论技术方案和开发成本
到了这一步，软件公司才真正有条件评估：
* 开发工作量；
* 技术实现方式；
* 开发周期；
* 人员配置；
* 第三方服务；
* 数据迁移；
* 系统部署；
* 后期维护。
因此，**软件报价最好建立在相对明确的业务和功能边界之上，而不是建立在一句“我要做一个XX系统”之上。**
---
## 六、为什么同一个项目，不同软件公司的报价可能差很多？
很多企业会遇到一个现象：
同样一个项目，A公司报价20万，B公司报价35万，C公司报价甚至50万。
这时候很多人的第一反应是：
“是不是有人在乱报价？”
不一定。
因为如果大家理解的“项目”根本不是同一个东西，报价自然没有可比性。
例如：
一家软件公司只按照基础功能报价。
另一家公司把：
* 产品原型；
* UI设计；
* 权限体系；
* 操作日志；
* 数据统计；
* 消息通知；
* 数据迁移；
* 测试；
* 部署；
* 上线支持
全部纳入项目范围。
表面上看都是“开发一个管理系统”，实际交付内容可能完全不同。
所以企业在比较软件开发报价时，真正应该比较的是：
**功能范围、交付标准、技术方案和服务内容，而不仅仅是报价单最后那个数字。**
---
## 七、需求也不是一次性确定的
这是定制软件开发中非常正常的一件事情。
企业第一次做系统时，很多需求只有真正看到产品原型以后，才会发现原来的想法需要调整。
例如：
原来认为一个页面就可以解决的问题，真正设计之后发现需要拆成两个页面。
原来认为所有人员都可以使用同一个操作流程，实际使用后发现管理人员和普通员工的权限完全不同。
这些变化并不一定说明前期需求分析失败。
因为软件本身就是一个把抽象业务逐渐具体化的过程。
比较合理的方式不是要求企业在项目开始之前把所有细节一次性想完，而是通过：
**业务梳理 → 产品原型 → 需求确认 → UI设计 → 开发 → 测试 → 上线**
不断降低不确定性。
---
## 八、企业第一次做软件，最应该避免的是什么？
我们更建议企业避免一种情况：
**还没有把业务想清楚，就急着让软件公司开始写代码。**
因为代码一旦开始开发，后面每一次业务调整都会产生实际成本。
如果问题发生在需求阶段，修改一张流程图可能只需要几个小时。
如果发生在UI设计阶段，可能需要重新设计页面。
如果已经进入开发阶段，就可能涉及数据库、接口、前后端代码以及测试。
如果已经上线，再修改就可能影响真实业务数据。
所以软件项目有一个非常朴素的规律：
**越早发现问题，修改成本越低。**
这也是为什么成熟的软件开发流程中，会把大量工作放在需求分析和产品设计阶段。
---
## 九、那么企业到底应该先做需求，还是先找软件公司？
回到文章开头的问题。
我们的答案是：
**如果企业内部已经有专业产品经理，可以先完成较完整的需求分析，再寻找开发团队。**
但如果企业没有专业产品团队，那么没有必要等到“所有需求都整理好了”再找软件公司。
更推荐的方式是：
**企业先明确业务目标和核心需求 → 找专业软件公司进行需求梳理 → 形成业务流程和产品方案 → 明确功能范围 → 再进行报价和开发。**
这样做的好处是，企业不需要强迫自己成为“软件产品经理”，软件公司也不会在不了解业务的情况下直接开始开发。
双方各自负责自己擅长的事情。
---
## 十、软件开发真正的第一步，不是写代码
很多企业把“软件开发”理解成程序员写代码。
但一个真正的软件项目，在代码出现之前，其实已经做了大量工作。
从一个老板提出：
“我想做一个系统。”
到最终上线，中间还需要经历很多次转换：
**企业想法 → 业务问题 → 业务流程 → 产品功能 → 页面原型 → 技术方案 → 软件系统**
每一步都是一次“翻译”。
其中任何一步理解错误，最终的软件都有可能偏离企业真正需要的东西。
所以，对于准备做定制软件的企业来说，真正重要的第一步并不是寻找一个“写代码最快”的团队。
而是找到能够：
**听懂业务、梳理业务、理解业务，并最终把业务落地成软件的人。**
---
## 写在最后
做软件定制开发，最理想的状态从来不是企业把所有事情都想好了，再把一份需求交给软件公司。
也不是企业什么都不想，只告诉软件公司一句“帮我做一个系统”。
真正高效的合作方式，是双方从项目一开始就共同参与。
企业最了解自己的业务和经营目标；
软件公司最了解如何把这些业务目标转化为产品、流程和技术实现。
**企业负责告诉软件公司“为什么做、解决什么问题”；软件公司负责帮助企业明确“怎么做、做到什么程度”。**
当这两个部分真正结合起来，软件开发才不是简单的功能堆砌，而是在帮助企业把原本依赖人的经验、流程和规则，逐步沉淀成一套可以持续运行的数字化工具。
对于企业来说，这往往才是定制软件真正的意义。
---
### 关于摩高互动
摩高互动长期专注于企业定制软件开发，为企业提供小程序、APP、管理系统、数据可视化平台以及AI相关应用的产品设计与技术开发服务。
在实际项目中，我们通常不会拿到一份功能清单就直接进入开发，而是会先从企业实际业务出发，对业务流程、用户角色、功能边界和系统目标进行梳理，再形成相应的产品和技术方案。
**因为我们认为，软件开发的起点应该是业务问题，而不是代码。**
很多企业第一次准备开发软件时，都会遇到一个看起来很简单、实际上很容易走弯路的问题：
**到底应该先把需求全部整理清楚，再找软件开发公司？还是先找一家软件公司，让他们帮助梳理需求？**
这件事情没有绝对的答案。
但从多年软件项目开发的实际经验来看，如果企业要求业务人员在没有专业产品人员参与的情况下，把一套复杂系统的所有需求提前整理完整，往往并不现实。
更合理的方式是：
**企业先明确业务目标和核心问题，再让软件开发公司参与需求梳理，双方共同把业务想法逐步转化成可以开发、可以验收的软件需求。**
这两者看起来只差了一步，实际上会直接影响后面的项目周期、开发成本和最终效果。
---
## 一、企业真正需要准备的，不是一份完整需求文档
很多老板在找软件开发公司之前，会要求公司内部先写一份详细需求文档。
这件事情本身没有错。
问题在于，很多企业并不知道一份真正可以用于软件开发的需求文档应该包含什么。
例如，一家企业准备开发一个项目管理系统。
老板可能会提出：
* 要有项目管理；
* 要有人员管理；
* 要有合同管理；
* 要有进度管理；
* 要有数据统计；
* 要有审批流程；
* 最好能够手机上使用。
这些内容可以说明企业“想做什么”，但还不能直接进入开发阶段。
因为软件真正需要解决的是另外一层问题：
项目怎么创建？
谁可以创建？
一个项目有哪些状态？
项目负责人可以修改什么？
不同角色看到的数据是否一样？
合同和项目之间是什么关系？
审批通过以后，哪些数据发生变化？
项目延期以后，系统怎么处理？
统计数据按照什么口径计算？
这些问题如果没有明确，开发人员就只能根据自己的理解去实现。
**所以，企业前期真正需要准备的，并不是一份看起来非常完整的功能清单，而是把自己的业务目标、现有流程、使用人员和核心痛点讲清楚。**
剩下的很多工作，本来就应该由专业的软件产品人员参与完成。
---
## 二、为什么企业自己写需求，反而容易把项目做复杂？
这是很多企业在软件项目中非常容易出现的情况。
因为企业内部人员最熟悉自己的业务，所以很容易把现有工作方式一项一项搬进软件。
比如原来一个业务流程需要经过五个人签字。
做系统的时候，企业可能会直接提出：
“系统也按照五级审批来做。”
但真正分析之后可能发现，其中两个审批环节只是过去因为纸质文件流转不方便而产生的，现在使用系统以后完全可以取消。
如果只是按照企业提交的功能清单开发，软件公司可能会把这五级审批完整做出来。
系统是做出来了。
但是企业的问题并没有真正解决。
这就是一个很典型的现象：
**把线下流程搬进软件，不等于完成了数字化。**
软件开发真正有价值的地方，不只是把按钮、表单、审批流程做出来，而是把企业的业务规则转化成一套更加清晰、高效、可执行的数字化流程。
---
## 三、但是，这并不意味着企业什么都不用准备
另外一个极端也不可取。
有些企业会认为：
“我不懂软件，需求你们自己想办法。”
这同样容易造成问题。
软件公司再专业，也不可能完全代替企业理解业务。
尤其是一些行业性比较强的系统，里面可能存在大量只有企业内部人员才知道的业务规则。
例如：
* 哪些数据属于核心经营数据；
* 哪些岗位拥有特殊权限；
* 哪些业务情况属于例外；
* 哪些审批环节必须保留；
* 不同部门之间如何协作；
* 现有系统有哪些历史数据；
* 哪些业务规则不能改变。
这些内容，软件公司无法凭空判断。
因此，一个好的软件项目从一开始就应该形成这样的关系：
**企业负责讲清楚业务，软件公司负责把业务转化成产品和技术方案。**
而不是企业负责“设计软件”，软件公司只负责“写代码”。
---
## 四、企业在找软件公司之前，最好先回答五个问题
如果企业目前还没有整理需求，其实不用急着制作几十页甚至上百页的需求文档。
先把下面五个问题想清楚，往往更加有价值。
### 1. 为什么要开发这个系统？
不要只回答“因为公司需要数字化”。
应该具体到业务问题。
例如：
“现在项目资料分散在Excel、微信群和纸质文件里，项目负责人无法实时掌握整体进度。”
这就是一个比较明确的问题。
---
### 2. 谁是系统的主要使用者？
至少需要明确核心角色。
例如：
* 管理层；
* 部门负责人；
* 普通员工；
* 财务人员；
* 项目负责人；
* 外部合作人员。
不同角色对应的功能和权限可能完全不同。
---
### 3. 现在这项业务是怎么做的？
这一点非常重要。
很多企业直接告诉软件公司：
“我要一个项目管理系统。”
但如果能够把现在的工作方式展示出来，比如：
“项目从立项开始，由A部门发起，B部门审核，C部门执行，财务在某个节点参与，最后由D部门归档。”
软件公司对需求的理解会准确很多。
**一套真实的业务流程，往往比几十条功能描述更有价值。**
---
### 4. 哪些问题是最需要解决的？
软件项目一定存在优先级。
不可能第一阶段把所有想法全部实现。
企业最好提前区分：
**必须解决的问题、希望解决的问题、以后可以解决的问题。**
这样才能判断第一期到底应该做多大。
---
### 5. 未来有没有扩展计划？
比如现在只需要一个内部管理系统，但未来可能连接：
* ERP；
* OA；
* 财务系统；
* 微信；
* 企业微信；
* 物联网设备；
* 数据平台；
* AI知识库。
这些信息不一定意味着第一期就全部开发，但会影响前期的技术架构设计。
---
## 五、真正专业的软件公司，应该在需求阶段做什么？
企业找软件开发公司，并不是把一份需求清单发过去，然后等待报价。
比较合理的合作过程应该是一个逐渐明确的过程。
通常可以分成几个阶段。
### 第一阶段：了解业务
先了解企业的行业背景、组织结构、业务流程以及当前存在的问题。
这一阶段不应该急着讨论技术。
因为如果业务都没有理解清楚，直接讨论使用什么框架、什么数据库，其实意义并不大。
---
### 第二阶段：梳理业务流程
把企业原来的口头描述、Excel、纸质流程、聊天记录等信息，逐步整理成清晰的业务流程。
例如：
**业务发起 → 信息录入 → 部门审核 → 业务处理 → 结果确认 → 数据归档 → 统计分析**
到了这个阶段，很多原本模糊的问题就会暴露出来。
---
### 第三阶段：形成产品结构
在业务流程明确之后，再进一步拆分系统模块。
例如：
**用户与权限 → 项目管理 → 合同管理 → 流程审批 → 数据管理 → 消息通知 → 数据统计**
这时候讨论功能，才开始变得有意义。
---
### 第四阶段：确定哪些功能真正需要开发
这是非常重要的一步。
因为需求梳理并不是“越详细越好”。
真正好的需求分析，应该帮助企业判断：
**什么应该做，什么可以不做，什么应该第一期做，什么应该放到第二期。**
如果一个软件项目一开始就把所有想法全部装进去，项目很容易失去边界。
---
### 第五阶段：再讨论技术方案和开发成本
到了这一步，软件公司才真正有条件评估：
* 开发工作量；
* 技术实现方式；
* 开发周期；
* 人员配置；
* 第三方服务；
* 数据迁移；
* 系统部署；
* 后期维护。
因此，**软件报价最好建立在相对明确的业务和功能边界之上，而不是建立在一句“我要做一个XX系统”之上。**
---
## 六、为什么同一个项目，不同软件公司的报价可能差很多？
很多企业会遇到一个现象：
同样一个项目，A公司报价20万，B公司报价35万，C公司报价甚至50万。
这时候很多人的第一反应是：
“是不是有人在乱报价？”
不一定。
因为如果大家理解的“项目”根本不是同一个东西，报价自然没有可比性。
例如：
一家软件公司只按照基础功能报价。
另一家公司把：
* 产品原型；
* UI设计；
* 权限体系；
* 操作日志；
* 数据统计；
* 消息通知；
* 数据迁移；
* 测试；
* 部署；
* 上线支持
全部纳入项目范围。
表面上看都是“开发一个管理系统”，实际交付内容可能完全不同。
所以企业在比较软件开发报价时，真正应该比较的是：
**功能范围、交付标准、技术方案和服务内容，而不仅仅是报价单最后那个数字。**
---
## 七、需求也不是一次性确定的
这是定制软件开发中非常正常的一件事情。
企业第一次做系统时，很多需求只有真正看到产品原型以后，才会发现原来的想法需要调整。
例如：
原来认为一个页面就可以解决的问题，真正设计之后发现需要拆成两个页面。
原来认为所有人员都可以使用同一个操作流程，实际使用后发现管理人员和普通员工的权限完全不同。
这些变化并不一定说明前期需求分析失败。
因为软件本身就是一个把抽象业务逐渐具体化的过程。
比较合理的方式不是要求企业在项目开始之前把所有细节一次性想完，而是通过：
**业务梳理 → 产品原型 → 需求确认 → UI设计 → 开发 → 测试 → 上线**
不断降低不确定性。
---
## 八、企业第一次做软件，最应该避免的是什么？
我们更建议企业避免一种情况：
**还没有把业务想清楚，就急着让软件公司开始写代码。**
因为代码一旦开始开发，后面每一次业务调整都会产生实际成本。
如果问题发生在需求阶段，修改一张流程图可能只需要几个小时。
如果发生在UI设计阶段，可能需要重新设计页面。
如果已经进入开发阶段，就可能涉及数据库、接口、前后端代码以及测试。
如果已经上线，再修改就可能影响真实业务数据。
所以软件项目有一个非常朴素的规律：
**越早发现问题，修改成本越低。**
这也是为什么成熟的软件开发流程中，会把大量工作放在需求分析和产品设计阶段。
---
## 九、那么企业到底应该先做需求，还是先找软件公司？
回到文章开头的问题。
我们的答案是：
**如果企业内部已经有专业产品经理，可以先完成较完整的需求分析，再寻找开发团队。**
但如果企业没有专业产品团队，那么没有必要等到“所有需求都整理好了”再找软件公司。
更推荐的方式是：
**企业先明确业务目标和核心需求 → 找专业软件公司进行需求梳理 → 形成业务流程和产品方案 → 明确功能范围 → 再进行报价和开发。**
这样做的好处是，企业不需要强迫自己成为“软件产品经理”，软件公司也不会在不了解业务的情况下直接开始开发。
双方各自负责自己擅长的事情。
---
## 十、软件开发真正的第一步，不是写代码
很多企业把“软件开发”理解成程序员写代码。
但一个真正的软件项目，在代码出现之前，其实已经做了大量工作。
从一个老板提出：
“我想做一个系统。”
到最终上线，中间还需要经历很多次转换：
**企业想法 → 业务问题 → 业务流程 → 产品功能 → 页面原型 → 技术方案 → 软件系统**
每一步都是一次“翻译”。
其中任何一步理解错误，最终的软件都有可能偏离企业真正需要的东西。
所以，对于准备做定制软件的企业来说，真正重要的第一步并不是寻找一个“写代码最快”的团队。
而是找到能够：
**听懂业务、梳理业务、理解业务，并最终把业务落地成软件的人。**
---
## 写在最后
做软件定制开发，最理想的状态从来不是企业把所有事情都想好了，再把一份需求交给软件公司。
也不是企业什么都不想，只告诉软件公司一句“帮我做一个系统”。
真正高效的合作方式，是双方从项目一开始就共同参与。
企业最了解自己的业务和经营目标；
软件公司最了解如何把这些业务目标转化为产品、流程和技术实现。
**企业负责告诉软件公司“为什么做、解决什么问题”；软件公司负责帮助企业明确“怎么做、做到什么程度”。**
当这两个部分真正结合起来，软件开发才不是简单的功能堆砌，而是在帮助企业把原本依赖人的经验、流程和规则，逐步沉淀成一套可以持续运行的数字化工具。
对于企业来说，这往往才是定制软件真正的意义。
---
### 关于摩高互动
摩高互动长期专注于企业定制软件开发，为企业提供小程序、APP、管理系统、数据可视化平台以及AI相关应用的产品设计与技术开发服务。
在实际项目中，我们通常不会拿到一份功能清单就直接进入开发，而是会先从企业实际业务出发，对业务流程、用户角色、功能边界和系统目标进行梳理，再形成相应的产品和技术方案。
**因为我们认为，软件开发的起点应该是业务问题，而不是代码。**
陕公网安备61019002001856号