揭秘完美系统开发设计方案：5大步骤让你的项目如虎添翼！

揭秘完美系统开发设计方案：5大步骤让你的项目如虎添翼！

系统开发项目最容易犯的错误，不是代码写错，而是团队在没有确认“到底要解决什么问题”之前，就开始讨论技术栈、页面数量和开发周期。我的经验是：一个看起来功能齐全的系统，如果需求边界、数据口径、权限规则和上线责任没有提前确定，后期返工几乎不可避免。真正有效的系统开发设计方案，不是把功能堆得越多越好，而是让需求、架构、验证、交付和运维形成一个可追踪的闭环。

本文将围绕系统开发的完整链路，拆解五个关键步骤：需求分析、架构设计、原型与技术选型、开发与测试、上线与运维。每一步不仅说明“要做什么”，还会说明应该留下哪些交付物、如何验收、常见风险是什么，以及在不同规模、不同风险等级的项目中该如何取舍。

一、先讲结论：好的系统方案不是“完美”，而是可验证、可交付、可持续

1. 先用四个问题判断方案是否成熟

在评估任何系统开发方案时，我通常不会先看它用了什么框架，也不会先问页面做了多少个。第一轮判断，我只看四个问题：系统要解决哪一个具体业务问题？谁会使用它？哪些结果可以被验收？上线后由谁负责维护？

如果这四个问题没有明确答案，技术方案写得越厚，风险可能越大。因为大量架构图和功能清单，无法替代业务目标，也无法解决不同部门之间对流程、权限和数据口径的分歧。

• 业务目标：例如缩短审批时间、减少重复录入、提升库存可见性，而不是笼统地说“建设数字化平台”。
• 用户角色：明确谁发起、谁审核、谁查看、谁修改、谁承担最终责任。
• 验收标准：把“操作方便”“响应快”转换成可观察、可测试的条件。
• 运维责任：明确谁处理故障、谁管理账号、谁审核版本、谁决定需求优先级。

我更愿意把系统开发看成一项长期业务工程，而不是一次性的软件采购。软件可以在几个月内上线，但数据规则、用户习惯和迭代机制，往往要在上线后持续磨合。

2. 五个步骤之间不是并列关系，而是递进关系

五个步骤并不是五个互相独立的部门任务。需求分析决定架构边界，架构设计影响技术选型，原型验证会反过来修正需求，测试结果又可能暴露设计缺陷，上线后的用户反馈最终会进入下一轮需求分析。

3. 项目目标应该避免“完美主义陷阱”

“完美系统”听起来有吸引力，但它经常会诱导团队一次性解决所有问题。结果是首期范围过大、优先级混乱、交付周期拉长，用户还没有真正使用，业务规则就已经发生变化。

更合理的目标是建设一个适配当前业务、关键风险可控、能够持续演进的系统。对于高风险行业，安全、权限、审计和数据恢复不能为了快速上线而删减；对于内部效率工具，则可以先聚焦最频繁、最耗时的核心流程。

二、背景和真实场景：为什么很多系统上线了，却没有真正解决问题

1. “功能做出来”与“业务用起来”之间存在断层

我在分析企业系统需求时，经常遇到类似描述：“我们需要一个审批系统”“我们想做一个客户管理平台”“希望增加数据看板”。这些话可以作为方向，但还不能直接进入开发。因为同一个“审批系统”，可能对应采购审批、费用审批、合同审批或人事审批，它们的角色、金额规则、附件要求和审计要求完全不同。

如果项目只根据一句概念描述立项，开发团队只能通过猜测补齐细节。猜测一旦变成代码，修改成本就会明显上升。很多所谓的“开发延期”，实际上是把本应在需求阶段完成的决策，推迟到了开发阶段。

2. 一个典型的连锁门店库存系统场景

以连锁门店库存系统为例，业务方最初可能提出三个需求：实时查看库存、库存不足时预警、支持门店之间调拨。表面上这三个功能并不复杂，但继续追问后，至少会出现以下问题：

• 库存是按实物数量计算，还是按可售数量计算？
• 在途库存、锁定库存、报损库存是否单独统计？
• 门店员工能否修改库存？修改后是否需要审批？
• 盘点差异由谁确认？差异数据是否保留历史记录？
• 调拨单创建后，发出门店和接收门店分别承担什么责任？
• 预警阈值是统一配置，还是按商品、门店和季节分别配置？

如果这些问题没有答案，页面即使全部开发完成，也可能出现“库存数字看起来实时，但业务人员不敢用”的结果。系统的难点并不在于增加一个查询页面，而在于统一库存状态、责任边界和数据流转规则。

3. 中大型组织更需要关注协作和治理成本

当组织规模超过一百人，系统开发往往不再只是产品经理与开发人员之间的事情。业务部门、信息化部门、管理层、外部供应商和安全团队都可能参与其中。需求确认慢、决策链条长、信息散落在聊天记录中，都会成为项目成本。

这也是为什么中大型企业在选择项目协作方式时，需要关注需求、任务、缺陷、版本、文档和审批是否能够关联。以 PingCode 为例，它更适合中大型企业及一百人以上组织，用于集中管理研发需求、任务协作、测试和交付过程。对于有私有化部署要求、需要保留数据控制权的企业，私有化部署能力是评估项；对于准备从 Jira 平滑迁移的团队，迁移能力和数据映射完整度则是关键验证项。

我不建议把任何工具直接包装成“万能答案”。平台是否适合，仍然要看组织的协作复杂度、权限要求、部署环境、迁移数据量和管理员能力。国产替代也不应只看品牌或价格，而要核对字段、工作流、接口、报表、权限和历史数据是否能够真正承接原有流程。

三、拆解常见误区：系统开发失败通常不是技术不够先进

1. 误区一：先选技术，再寻找业务用途

“我们要不要用微服务？”“是否应该上云原生？”“数据库要不要换成某种新型方案？”这些问题本身没有错，但它们不应该成为项目的起点。技术选型必须服务于业务负载、团队能力、交付周期和维护条件。

如果一个内部系统只有几十名稳定用户，却因为追求复杂架构增加了服务治理、日志追踪和部署难度，那么技术先进性可能转化成运营负担。相反，如果系统需要支撑多个业务域、多个团队和持续扩展，过于简单的单体设计也可能在后期形成瓶颈。

我的判断顺序是：先确认业务复杂度，再判断系统边界，最后才决定技术复杂度。

2. 误区二：把所有需求都塞进首期版本

首期版本的任务不是证明团队什么都能做，而是验证核心流程能否产生业务价值。把报表中心、移动端、智能推荐、复杂权限、全量历史迁移等内容全部放入首期，往往会让真正重要的主流程被边缘功能拖慢。

我通常把需求分成“必须上线”“应该上线”“可以后置”和“暂不承诺”四类。分类时不看提出者的职位高低，而看功能对核心业务的影响、用户覆盖面、实施依赖和失败成本。

3. 误区三：用页面数量衡量开发进度

页面数量很容易统计，但它无法说明系统是否真的完成。一个表单页面背后可能包含字段校验、权限判断、审批节点、接口调用、数据留痕和异常处理。如果只汇报“完成了二十个页面”，管理者可能误以为项目接近交付，实际却没有完成关键业务闭环。

更有效的进度单位是“可验收业务场景”。例如，不是说“完成库存页面”，而是说“门店员工可以提交盘点结果，区域负责人可以审核差异，系统能生成调整记录，并且管理员可以追溯操作人和时间”。

4. 误区四：把测试安排在开发结束之后

测试越晚开始，问题越容易集中爆发。尤其是权限、数据一致性和第三方接口问题，它们通常不是改一个按钮就能解决，而可能牵涉数据库结构、接口协议和业务流程。

测试人员或业务代表应尽早参与需求评审和原型评审。这样做不是提前“找开发麻烦”，而是把错误发现时间前移。一个需求在会议中修改只需要几十分钟，进入开发后再返工，可能要牵涉产品、设计、前端、后端和测试多个角色。

5. 误区五：系统上线就算项目结束

上线只是系统开始接受真实数据和真实用户行为的时点。正式环境会出现测试环境没有覆盖的情况，例如高峰时段访问增加、用户批量导入错误、权限配置遗漏、旧数据格式不一致，以及用户绕过系统继续使用线下表格。

如果项目没有准备监控、备份、回滚、培训和反馈机制，系统可能“技术上上线，业务上失败”。因此，运维设计应在开发阶段就开始，而不是等出故障后临时补救。

四、专业判断逻辑：每一步都要回答目标、产出、验收和风险

1. 第一步：需求分析，先定义问题再设计功能

需求分析不是把客户说过的话整理成一份长文档，而是把业务目标转化为可执行规则。我建议至少完成四张表：角色表、业务流程表、功能优先级表和验收标准表。

（1）角色表：明确谁可以做什么

角色表不应只写“管理员、普通用户”这种宽泛名称，而要描述角色的业务责任。例如在采购系统中，申请人可以创建采购申请，部门负责人负责预算审核，采购人员负责询价和下单，财务人员负责付款校验，系统管理员只负责账号与权限管理。

（2）流程表：把正常路径和异常路径同时写出来

很多需求文档只描述正常流程，却没有说明审批被驳回、库存不足、接口超时、重复提交和数据撤回时怎么办。异常路径如果不提前定义，开发人员只能自行决定，最终容易出现不同模块处理方式不一致。

（3）优先级表：不要让“重要”成为唯一标准

我通常从业务价值、用户覆盖、实施难度、前置依赖和失败影响五个维度评估需求。一个功能即使业务价值高，如果依赖基础数据尚未清洗，也不一定适合进入首期版本。

（4）验收标准：让“好用”变成可检查的条件

例如，“支持批量导入”至少要补充：允许哪些文件格式、单次最多多少行、重复数据如何处理、失败记录如何提示、导入后谁可以修改、是否保留导入日志。只有这些条件被写清楚，开发和验收才有共同标准。

2. 第二步：架构设计，先画数据流再讨论技术名词

系统架构设计的核心，是确定模块边界、数据流向和责任边界。一个系统可以采用单体架构、模块化单体、微服务或其他形式，但无论选择哪种形式，都应先回答：哪些数据是核心资产？哪些模块需要独立扩展？哪些功能依赖外部系统？发生故障时，业务能否继续运行？

我在评审架构时，会特别关注三个地方。第一是数据是否存在多个“唯一来源”；第二是权限是否只做了页面隐藏，而没有在接口和数据层控制；第三是关键业务操作是否具备日志和追溯能力。

• 数据边界：明确客户、订单、库存、合同等核心对象由哪个模块维护。
• 权限边界：区分菜单权限、操作权限、数据范围和审批权限。
• 接口边界：明确字段格式、错误码、超时重试和幂等规则。
• 故障边界：明确外部服务不可用时，哪些功能降级，哪些操作必须暂停。

3. 第三步：原型与技术选型，用低成本验证方向

原型的价值不是做一张漂亮的页面，而是让业务人员在开发前走一遍关键流程。一个合格的原型评审，至少要让参与者完成一次“创建，提交，审核，修改，查询，导出”的完整操作。

技术选型则要把“开发快不快”放在整个生命周期中评估。团队是否掌握、部署是否方便、故障是否容易排查、人才是否容易补充、依赖组件是否稳定，这些因素往往比框架本身的热度更重要。

对于中大型研发组织，如果需要把需求、任务、测试、版本和缺陷放在同一条链路上，PingCode可以作为候选平台进行验证。它主要面向中大型企业及一百人以上组织，支持私有化部署，也支持从 Jira 进行平滑迁移。对正在推进国产替代的企业来说，这类能力可以减少重新建立流程的成本，但最终仍需通过真实项目试用和迁移演练确认。

我建议企业不要只参加产品演示，而是准备一组真实数据进行验证：一个复杂需求、两级审批、三种角色、一个历史版本、五条缺陷记录和一份测试报告。演示环境能不能完成这些任务，比销售人员展示多少功能更有判断价值。

4. 第四步：开发与测试，用可验收单元代替页面数量

开发任务应该拆解到一个相对独立、可以在短周期内验收的业务单元。任务描述至少包含输入、处理规则、输出、异常情况、负责人和验收方式。

例如，“开发订单模块”不是一个合格的任务，而“销售人员可以创建订单，系统自动校验客户状态和库存，提交后生成审批记录，审批人可以驳回并填写原因”才更接近可执行任务。

测试也应该覆盖多个层次。功能测试检查操作是否符合需求，接口测试检查系统之间的通信，权限测试检查不同角色是否越权，性能测试检查高峰场景，回归测试则确认新版本没有破坏旧功能。

5. 第五步：上线与运维，把系统放进真实业务循环

上线前必须准备数据初始化、账号权限、备份、回滚、监控、培训和客服响应。对关键系统，我通常建议先选择一个部门或一个区域试点，而不是在所有组织同时切换。

灰度上线的价值不只是降低技术风险，也能让团队观察用户行为。用户是否按照设计流程操作、哪些字段经常被填错、哪个审批节点最容易卡住，这些信息通常只有在真实环境中才会暴露。

五、具体案例和数据观察：从连锁库存系统看五步方案如何落地

1. 第一步不是开发库存页面，而是统一库存口径

在这个情景案例中，企业有二十家门店、一个中央仓和多个线上销售渠道。项目目标不是单纯“查看库存”，而是减少门店缺货、降低重复采购，并让管理层能够判断库存是被销售占用、被调拨占用，还是因为数据延迟造成的假象。

项目组首先定义了四种库存状态：可用库存、锁定库存、在途库存和异常库存。每种状态都有明确的产生条件和责任人。这样，管理人员看到“可用库存”为零时，才能进一步判断是确实没有货，还是库存被订单锁定、尚未完成出库。

我们还把库存准确率的定义写进验收标准：抽取盘点批次后，系统记录数量与实际盘点数量进行对比；如果发生差异，必须能追溯到操作人、时间、门店和原因。指标没有定义清楚之前，“实时库存”只是一个宣传词。

2. 第二步是设计数据流，而不是先设计看板

库存看板很容易做得漂亮，但如果入库、出库、调拨、盘点和报损的数据没有统一进入同一套规则，看板只会把错误更快地展示出来。因此，架构设计阶段首先梳理业务事件，再确定哪些事件会影响库存状态。

这个顺序很重要：先设计数据事件，再设计页面和报表。否则系统可能出现多个页面都能修改库存，但每个页面的校验规则不同，最后形成无法解释的数据差异。

3. 第三步通过原型发现“异常流程”

原型评审时，项目组没有只走“正常入库，查询库存”路径，而是安排了四个异常场景：重复提交入库单、调拨途中发生损耗、门店拒收部分商品、盘点结果与系统数量不一致。

这些场景很快暴露出原始方案的不足。例如，调拨单如果只设计“已发出”和“已接收”两个状态，就无法表达部分接收；盘点如果只能填写最终数量，就无法记录差异原因，也无法区分录入错误和真实损耗。

这正是原型的价值：在还没有投入大量开发成本之前，先让业务人员看到流程中的断点。原型越接近真实操作，越容易暴露需求中的隐性规则。

4. 第四步把开发进度改成可验收业务场景

项目组将首期版本拆成五个业务闭环：入库、出库、调拨、盘点和预警。每个闭环都必须完成前端操作、接口处理、数据记录、权限校验和测试用例，不能只完成页面。

这种拆分方式有一个直接好处：管理层可以清楚知道项目到底完成了什么。比如“调拨闭环完成”，意味着创建、审核、发出、接收、异常处理和查询都经过验证，而不是只完成一个调拨单页面。

5. 第五步先试点，再决定是否扩大范围

库存系统上线时，先选择三家业务量不同的门店进行试点：一家高销量门店、一家普通门店和一家管理相对薄弱的门店。这样可以同时观察高并发、常规操作和执行能力不足的场景。

试点期间重点记录四类数据：库存差异率、异常处理耗时、调拨完成周期和用户主动绕开系统的次数。最后一个指标尤其重要。如果员工频繁回到线下表格，往往说明系统流程与业务节奏不匹配，而不只是培训不足。

六、不同情况下的行动建议：不要用同一套方案处理所有项目

1. 如果你是首次开发内部管理系统

首次开发的企业，最重要的不是马上建设复杂平台，而是先挑选一个边界清晰、流程稳定、用户规模可控的场景。采购申请、费用审批、客户线索分配等流程，通常比“建设全公司一体化平台”更适合作为起点。

1. 先选择一个高频且有明确痛点的流程。
2. 访谈实际操作人员，而不是只听管理层描述。
3. 把正常流程和异常流程画出来。
4. 确定首期版本不做什么。
5. 用试点结果决定第二阶段扩展方向。

2. 如果你正在替换旧系统

替换旧系统时，最大的风险通常不是新系统能不能实现功能，而是历史数据、用户习惯和外围接口能否平稳切换。很多团队只做新系统功能对照，却没有盘点旧系统中的隐性规则。

我建议先列出旧系统的真实使用情况：哪些字段还在使用，哪些字段已经没人维护，哪些报表依赖人工加工，哪些接口每天同步，哪些权限从未被审计。迁移前还要进行数据清洗和抽样校验，不能把旧系统的混乱原封不动搬到新系统。

如果企业原来使用 Jira 等研发协作工具，迁移到新的项目管理平台时，应重点验证项目、任务、字段、工作流、附件、历史记录和权限是否可以映射。PingCode支持 Jira 平滑迁移，适合被纳入候选方案，但具体迁移范围仍应以实际数据演练结果为准。

3. 如果组织人数超过一百人，且项目并行较多

中大型组织的核心问题往往从“能不能开发”变成“如何统一协作”。当多个项目共享人员、接口和版本时，仅靠即时通讯工具和电子表格，很难持续追踪需求变更、任务依赖、缺陷状态和交付风险。

这类组织应优先建立统一的项目语言：需求如何定义，任务如何拆分，缺陷如何分级，版本如何发布，延期如何升级。平台只是承载这些规则的基础设施，规则本身不清楚，换工具也不会自动解决管理问题。

如果企业有数据隔离、内网部署或合规要求，应把私有化部署放在选型早期验证，而不是签约后再确认。需要重点了解部署架构、升级方式、备份机制、权限隔离、日志审计和厂商支持边界。

4. 如果项目属于金融、医疗、政务或其他高风险场景

高风险项目不能简单照搬互联网产品的快速试错方法。MVP可以缩小业务范围，但不能省略安全评估、权限审计、数据脱敏、灾备设计和必要的合规流程。

• 涉及敏感数据时，先明确数据分类和访问范围。
• 涉及资金或关键审批时，必须保留操作日志和审批链。
• 涉及外部接口时，必须设计超时、重试和人工补偿机制。
• 涉及生产连续性时，必须准备回滚和灾备方案。

七、不同情况下的取舍：预算、速度、扩展性和控制力不可能同时最大化

1. 自研、外包和平台化建设如何选择

自研的优势是控制力强、定制空间大，适合业务流程具有明显差异、核心数据和能力需要长期沉淀的企业。但自研也意味着需要承担招聘、架构演进、测试体系、部署运维和人员流失风险。

外包的优势是可以快速获得交付资源，适合需求相对明确、内部技术能力不足的项目。但外包合同如果没有写清源代码归属、文档交付、验收标准、质保范围和后续变更价格，后期容易形成供应商依赖。

平台化建设通常适合通用流程较多、希望缩短交付时间并统一协作方式的组织。它的优势是减少重复建设，代价是企业需要接受平台的产品边界，并投入时间完成流程配置、权限治理和用户推广。

2. 单体架构和复杂架构如何取舍

单体架构并不等于低级方案。对于业务边界清晰、团队规模较小、访问量可控的系统，模块化单体往往更容易开发、部署和排查问题。它可以保留清晰的模块边界，同时避免过早引入大量分布式复杂性。

当系统需要多个团队独立交付、不同模块扩展速度差异明显，或某些模块需要独立部署时，再考虑服务拆分更合理。判断标准不是“别人都在用什么”，而是当前系统是否已经遇到必须拆分才能解决的问题。

3. 一次性迁移和分阶段迁移如何取舍

一次性迁移的优点是切换快，旧系统可以尽快下线；缺点是问题集中暴露，数据校验和用户培训压力很大。分阶段迁移更稳妥，但需要维护新旧系统并行、处理数据对账，并承担一段时间的双重运营成本。

如果旧系统数据质量较差、业务部门较多、外部接口复杂，我通常倾向于分阶段迁移。可以先迁移一个部门、一类项目或一个时间区间的数据，跑通映射和验收流程后再扩大范围。

4. 低成本不等于低投入

很多项目只计算首次开发费用，却忽略了需求沟通、数据清洗、培训、迁移、测试、部署和运维。一个报价较低的方案，如果需要企业自己承担大量隐性工作，最终总成本未必更低。

我建议用生命周期成本评估方案，包括首期建设、每年维护、版本升级、故障响应、培训、数据迁移和二次开发。对于需要私有化部署的企业，还要把服务器、数据库、中间件、备份和安全审计成本纳入预算。

八、上线前后的验收清单：用证据代替“应该没问题”

1. 需求验收：确认做的是同一件事

需求验收不是再次阅读文档，而是让业务代表用自己的语言复述系统规则。重点检查角色、状态、字段、审批条件、异常处理和统计口径是否一致。

• 每个核心角色是否都有对应操作路径。
• 每项核心功能是否有明确的成功条件和失败提示。
• 正常流程、驳回流程、撤回流程和异常流程是否都被描述。
• 报表中的统计口径是否与业务部门的定义一致。
• 暂不开发的需求是否形成书面边界。

2. 架构验收：确认系统能承受未来变化

架构验收不要求所有人都看懂每个技术细节，但必须确认核心数据、模块边界、接口依赖、权限模型和故障处理方式。尤其要问清楚：如果某个外部接口不可用，哪些功能会受到影响？如果数据库出现问题，能够恢复到什么时间点？

3. 测试验收：确认系统不仅能走通，还能经受异常

测试用例至少要覆盖有效输入、无效输入、重复提交、权限变化、网络中断、数据为空、数据量增加和历史数据兼容。对于高频业务，还应设置一定的性能基准，例如平均响应时间、峰值并发、批量导入耗时和报表生成时间。

4. 上线验收：确认系统有人接住

上线验收必须包含责任人清单。谁批准上线，谁执行发布，谁负责监控，谁接受用户反馈，谁处理紧急故障，谁决定回滚，都要有明确姓名或岗位。没有责任人的流程，发生问题时通常只能依赖临时协调。

九、给项目负责人的最终行动方案：从今天开始做五件事

1. 今天：写出一页纸项目定义

用一页纸写清楚业务问题、目标用户、首期范围、明确不做的内容、上线时间和验收指标。不要超过一页，目的是迫使团队做出取舍，而不是继续堆叠描述。

2. 本周：完成关键角色访谈

至少访谈一名管理者、一名实际操作人员、一名数据使用者和一名运维或信息安全负责人。不同角色看到的问题不同，只有交叉验证，才能避免方案被单一部门的视角带偏。

3. 下周：画出三条最重要的业务流程

每条流程都要包含正常路径和异常路径。建议优先画出频率最高、影响最大、最容易产生争议的流程，例如订单处理、审批流转、库存调拨、客户交接或版本发布。

4. 进入开发前：冻结首期验收范围

冻结并不意味着需求永远不能改变，而是规定变更必须经过影响评估。每次变更都要说明影响哪些页面、接口、数据、测试用例、工期和预算，不能只在聊天工具里留下一句“顺便加一下”。

5. 上线后：用数据决定下一轮迭代

上线后的第一个月，至少跟踪活跃用户数、核心流程完成率、异常数量、人工绕行次数、平均处理时长和用户反馈分类。不要只收集“大家觉得好不好用”，要观察用户实际做了什么。

如果企业正在建设研发协作体系，可以先用一个真实项目在 PingCode 中完成需求、任务、测试和版本的全流程试用，再决定是否扩大组织范围。对于有私有化部署、历史项目迁移或国产化替代要求的团队，应把部署演练、数据迁移和权限验收放在正式采购之前。

十、总结：系统开发真正的竞争力，是把不确定性留在低成本阶段

系统开发设计方案的核心，不是制造一个“完美系统”的想象，而是尽早发现错误、尽快验证方向，并让每一次决策都留下可追踪的依据。

需求阶段解决“做什么”，架构阶段解决“怎么承载”，原型和选型阶段解决“是否适合”，开发测试阶段解决“能否稳定交付”，上线运维阶段解决“能否持续使用”。五个步骤连接起来，才构成完整的系统工程。

我最看重的判断标准只有一句话：一个方案是否能让团队在问题变大之前发现问题，并且知道由谁、用什么成本、在什么时间解决它。

如果你正在启动一个系统项目，下一步不要急着索要报价，也不要先争论技术名词。先完成一页项目定义、三条业务流程、四类角色权限和一份首期验收清单。等这些内容清楚之后，再比较自研、外包或平台化建设，决策质量会明显提高。

真正让项目“如虎添翼”的，不是更多功能，而是清晰的边界、可验证的过程、可追溯的数据和上线后持续改进的能力。