AI时代下定制软件开发项目如何采购

【摘要】生成式AI编码工具快速普及，重构了定制软件开发的生产方式，人机协同成为新常态。传统定制软件采购主要依托人工开发形成的人天计价、功能点计价两类模式，其以人力工作量与功能规模为核心的定价体系，已难以适应AI赋能后的开发现实。文章梳理定制软件传统采购模式的特点与短板，分析AI驱动下软件开发范式的主要变化，从需求端、采购端、使用端3个维度剖析范式变革带来的冲击和影响，并针对性提出适应AI时代的采购优化对策，以期为采购方开展定制软件采购工作提供参考。

【关键词】生成式AI；智能编码；计价模式；定制软件；软件采购

随着大模型技术加速演进，AI（Artificial Intelligence，人工智能）生成代码已成为AI的重点应用场景。AI编码工具在软件开发领域大规模落地应用，从代码补全、片段生成到简单模块开发，AI已深度参与软件开发的全流程。以往定制软件开发属于典型的智力密集型工作，大量人力集中于编码、调试等重复性工作。如今，AI可以快速输出基础代码，压缩了编码环节的时间投入，但业务梳理、架构设计、代码审核、风险排查等工作依旧需要人的专业判断。

定制软件与标准化商用软件不同，它是为满足组织个性化业务流程开发的专用系统，广泛应用于政务、制造、金融、通信等行业和领域。由于不存在现成产品，定制软件采购一直是采购管理中的难点，采购方需要在需求不确定、技术路线复杂、交付边界模糊的条件下完成供应商遴选、定价、履约管控与验收工作。长期以来，国内定制软件采购形成了人天计价和功能点计价两种主流模式，采购规则、合同条款、验收标准均建立在人工开发这一根本基础之上。

现有采购制度、采购文件、合同范本大多未针对AI开发场景作出专门调整。因此，如何调整采购思路，顺应新的软件开发范式，统筹平衡成本、质量与风险三者之间的关系，已经成为数字化采购领域亟待解决的课题。

定制软件传统采购模式

定制软件的本质是开发并交付一套贴合特定业务的软件系统，需求差异性大，项目范围容易发生变动，难以套用标准化产品的定价逻辑。经过行业长期实践，人天计价与功能点计价成为国内定制软件采购通用的两种模式，二者适用场景不同，各有优势与不足。

人天计价模式

人天计价也称工时计价，核心计算公式为：项目总价＝各职级人员单日单价×对应岗位投入人天。报价过程中，服务商根据采购方提出的业务需求，配置产品经理、架构师、前后端开发、测试工程师等岗位，预估每个岗位投入的工作人天，结合人员职级单价核算出项目总报价。该模式适合前期需求模糊、业务创新性强、项目范围无法一次性锁定的项目。

在采购实施阶段，采购方重点审核人员单价是否符合市场水平、项目团队配置是否匹配业务及系统复杂度。项目履约过程中，依据人员到岗记录、工作周报、监理记录等核算实际投入工时，按阶段结算。人天计价模式的最大优势在于其灵活度高，当业务内容发生变化或需求发生调整时，可通过增减投入人天快速适应项目变化，避免出现项目结算受阻甚至停滞的情况。采用人天计价方式采购的项目，通常签订固定单价合同。

人天计价模式存在先天性短板。第一，项目最终成本取决于实际消耗工时，服务商存在刻意拉长工期、虚增工时的动机，预算可控性较弱，管控不力容易造成费用套取、预算超支。第二，该模式存在逆向激励，服务商越是提升开发效率、缩短工时，项目总收入反而下降，这客观上助长了“磨工时”的现象。在纯人工开发阶段，编码效率提升空间有限，这一矛盾尚不突出，但引入AI编码工具后，开发效率大幅提升，这套计价模式的公平性基础因此被严重削弱。第三，人天计价侧重于计量“人员投入”，而非“业务成果”，可能出现投入大量人力而系统业务价值不及预期的情况。

功能点计价模式

功能点计价是软件工程领域的标准计价方式，它跳出工时统计，以软件交付的功能规模作为计价基础。服务商根据需求说明书，识别业务功能、外部接口、数据处理单元，按各类对象的复杂程度赋予不同权重，乘以功能点单价得到项目总报价。该模式适用于需求边界清晰、业务逻辑稳定、变更较少的项目，在大型企业和政府采购招投标中应用广泛，该模式通常采用可调总价合同，发生需求变更时按照增减的功能点调整合同价款。

与人天计价相比，功能点计价实现了从“投入计量”向“产出计量”的转变。采购方可以在采购阶段锁定项目预算，采购评审指标相对客观，验收以需求清单和功能点清单作为依据，有助于减少双方争议。服务商可以通过提高效率、组件复用、工具优化等方式降低开发成本，获得效率带来的收益。

功能点计价模式也存在明显局限：第一，对前期需求完整性要求很高，采购方必须在采购阶段将全部需求加以固化；然而，定制软件个性化强、业务复杂，前期很难完整定义全部业务场景和功能要求，后期频繁变更会削弱可调总价合同机制的优势。第二，该模式重数量而轻价值——只统计功能体量，不区分功能的业务重要程度，简单查询功能与支撑核心业务流转的高风险功能被一视同仁，极有可能出现计价偏差。第三，架构设计、数据治理、安全加固、性能优化等不直接产生功能点的高价值工作，无法纳入计量范围。进入AI代码开发时代，编码成本降低，架构、安全、代码审计等隐性工作的成本占比随之上升，功能点计价模式的缺陷被进一步放大。

软件开发范式变化

传统定制软件开发遵循顺序开发范式，整体流程为需求拆解、总体设计、详细设计、编码开发、系统测试、上线交付。编码环节消耗大量人力，项目周期长，试错成本高，项目质量高度依赖开发团队人员规模与个人技术能力。AI编码工具普及之后，软件开发范式发生本质性改变，集中体现在生产模式、迭代节奏、成本结构、风险特征4个方面。

第一，生产模式由纯人工开发转向人机协同开发。传统模式中，开发人员在代码编写、语法调试、基础接口开发等方面耗费大量时间进行重复性工作。AI编码工具可以基于自然语言提示快速生成代码、完成语法纠错、生成基础单元，替代大量低价值编码工作。开发人员的工作重心由人工编写代码转向更高层次的智力工作，更多承担业务拆解、系统架构设计、提示词梳理、AI生成代码审查、业务逻辑校验、安全审计等职责。AI负责快速产出基础代码，由人负责把控业务正确性、架构合理性与合规性，形成人机协同的新型软件开发生产模式。

第二，迭代节奏由长周期顺序开发转向快速迭代开发。传统定制软件大多完成全部开发工作之后集中上线，中小型项目周期普遍为3～6个月，大型项目周期则超过1年，需求变更的代价高昂。AI工具大幅压缩编码和基础测试耗时，可以快速搭建最小可用产品（Minimum Viable Product,MVP）原型，快速上线试用，再根据业务反馈持续迭代优化。原本需要数月才能完成的基础功能开发，数周即可完成原型落地，试错成本显著降低，需求动态调整将成为项目常态。

第三，成本结构发生明显偏移。编码人力成本占比下降，智力服务与风险管控成本占比提升。传统定制软件项目成本主要来自编码人员人工成本，架构设计、需求分析、安全审查占比较低。AI时代，基础编码人力投入明显下降，项目成本重心转移到需求拆解、业务建模、架构设计、AI代码审计、知识产权核查、数据安全管控、迭代运维等智力型工作上。软件的价值不再取决于代码行数，而是解决业务问题的能力、系统稳定性、数据治理水平。

第四，项目风险结构发生迁移。传统人工开发风险降低，AI特有风险凸显。传统项目风险主要集中在人员能力不足、工期延误、人工编码漏洞等方面。AI辅助开发之后，基础代码漏洞、开发进度失控等风险得到显著缓解，但同时带来新的风险类型：其一，AI生成代码版权归属模糊，容易引用存在协议冲突的开源代码。其二，AI生成代码通用性强，业务场景适配性欠缺，隐性逻辑缺陷风险增大。其三，大模型版本迭代，可能带来系统兼容性隐患。开发风险的重心从进度风险转向合规风险、业务适配风险。

范式变化对定制软件项目采购的影响

软件开发范式的变化传导至采购全链条。原本适配人工开发范式的需求管理、计价模式、评审指标、合同履约、验收交付规则逐渐难以适配当前形势，对需求端、采购端、使用端均产生冲击。

对需求端的影响

需求端是整个采购工作的起点，AI改变了需求定义逻辑，同时提高了需求管理的难度。

首先，需求目标从“实现功能”转向“实现业务价值”。人工开发时代，开发成本较高，采购方的核心诉求是按清单完成功能开发，功能实现即被视为目标达成。AI降低了功能实现门槛，批量生成简单功能不再存在技术障碍，单纯堆砌功能没有实际意义。采购方需要把关注点从“需要哪些功能”转向“系统要解决哪些业务痛点、实现怎样的效率提升”，并把需求定义同可量化的业务指标相配套，使业务功能价值的优先级高于功能数量。

其次，需求管理模式从一次性固化需求转向动态迭代需求。传统采购为适配长周期顺序开发，要求采购阶段尽可能确定全部需求，需求变更流程烦琐、成本高。由于AI生成的代码可修改性好，且可持续低成本试错，项目得以分阶段迭代，上线后根据用户反馈持续调整。采购阶段难以一次性明确全部需求，传统固定范围的采购模式难以适应，需求变更趋于常态化，需求边界管控难度明显上升。

最后，AI对采购方的需求管理能力提出更高要求。AI输出代码质量高度依赖清晰严谨的业务描述，如果业务需求模糊、数据口径混乱、边界界定不清，AI生成的代码就会脱离业务实际需要，导致后续频繁返工。采购方不仅要提出业务诉求，还要做好业务梳理、数据标准定义、场景边界识别、风险预判等工作。现实中，许多采购方的需求人员普遍缺乏技术认知，难以胜任高质量的需求拆解工作。

对采购端的影响

采购端承担供应商遴选、定价、合同签订、履约管控等职能，受范式转变的冲击最为直接，由此传统计价、评审、履约管控等工作模式均面临压力。

第一，传统计价模式的底层逻辑被颠覆，采购方与服务商之间价格博弈加剧。若继续沿用传统人天计价，服务商利用AI快速完成编码，却仍按人工工时收取费用，将拉低采购资金的使用效益，同时进一步放大逆向激励问题——服务商效率越高，收益反而越低。功能点计价则仅计量功能数量，无法体现架构设计、AI代码审计、合规审查等高价值工作，容易诱发低价竞标、交付大量低质量AI生成代码，使核心业务方案与安全管控投入不足，采购效果难以得到保障。采购方希望减少编码环节付费，服务商强调智力服务和新增风险成本，定价矛盾已成为当前采购中最突出的冲突。

第二，供应商评价指标体系需要重建。传统采购评审重点考察团队人员规模、开发人员资质、历史开发项目业绩，核心是评判人工编码能力。AI时代，供应商核心竞争力已经发生转移，转向业务方案能力、AI开发流程管控能力、代码审查能力以及知识产权风险管控能力。单纯的人员规模不再等同于项目交付质量，部分中小服务商依托成熟的AI开发流程，也可以实现更高质量的交付。原有评审体系缺少针对AI开发管控的考核指标，可能筛选出AI代码审查、版权管控能力不足的供应商，为项目高质量交付埋下隐患。

第三，异常低价判定规则需优化。不同服务商在AI模型选择、编码深度、人机协同能力等方面差异较大，报价偏差将越来越大，这种因AI应用程度不同而产生的价格差异，对采购评审中“报价明显偏低”的澄清与认定提出了挑战。据此，原有的异常低价判定规则与判定方法亟须调整和优化——使用与不使用AI编码的服务商，其成本结构必然不同，采购文件中惯用的异常低价判定规则，以及启动报价偏低澄清的条件，都需作相应调整。

第四，合作模式和履约监控方式不匹配。传统项目大多采用总包一次性采购、一次性交付，履约监控重点在于人员在岗、工时投入。AI项目具有短迭代、持续优化的特征，更适合分阶段采购、按效果结算，但现有招标采购制度、合同模板、结算规则大多面向固定范围项目。履约监控重心需要从人员出勤转向AI开发流程管控、代码审计记录、知识产权溯源、业务指标达成情况，原有监控指标部分失效，过程监管容易失位。

对使用端的影响

使用端即系统的最终使用者。系统交付之后的业务适配、运行维护、长期使用体验，直接决定项目成败。AI开发范式变化，同样对系统交付后的实际使用产生深刻影响。

第一，系统业务适配风险上升。AI生成代码偏向通用化，更擅长运用通用逻辑，对企业个性化业务流程、特殊业务规则的适配能力不足。如果服务商直接交付未经充分人工校验的AI原生代码，系统功能虽可“跑通”，但与实际业务流程脱节，使用者在实际业务中难以落地应用，较传统模式更容易出现“能用但不好用”的现象。

第二，后期运维复杂度提升。受开发人员个体习惯与所选模型差异的影响，AI生成代码存在编写风格不统一、注释不清晰、逻辑跳转复杂等问题，若缺少人工整理和优化，后期运维人员理解代码的难度增大，软件缺陷（Bug）排查、功能修改的成本也可能显著增加。同时，大模型本身持续迭代，若开发过程对特定模型存在较强依赖，未来模型版本变化会带来系统兼容风险。以往采购合同对后期运维的约定主要针对缺陷修复，较少考虑AI自身带来的特殊运维问题，为使用方的后期运维成本管控带来隐患。

第三，知识产权风险传导至使用端。AI生成代码可能包含未经授权的开源片段，若未完成开源协议扫描与清理，知识产权风险将自开发方传导至采购使用方。一旦出现版权纠纷，承担风险的将是采购方。通常情况下，采购合同都未就AI生成代码的知识产权归属、侵权责任划分作出充分明确，系统上线后使用方面临潜在的法律风险。

新时代定制软件开发项目采购的应对之策

面对AI带来的开发范式转变，采购管理需要从计价体系、供应商遴选、合同与合作模式、验收机制、全流程风险管控等多维度同步优化，构建AI驱动、价值导向、风险可控的新型采购体系。

第一，重构计价模式，建立复合化计价模型。转变单一依靠人天或单纯依靠功能点计价的思路，构建“基础服务费＋复杂度系数＋风险溢价＋效果激励”的复合计价模式。人天仅作为辅助参考，不再作为核心定价依据。优化功能点计量，增加业务价值系数、技术风险系数，以区分简单通用功能与核心高风险业务功能。将需求拆解、架构设计、AI代码审计、安全评估、知识产权审查等隐性高价值工作纳入计价范围。同时，合同价款拆分为基础费用和浮动激励两部分：基础费用覆盖方案与基础开发成本，浮动部分与业务指标达成情况挂钩，从而实现双方风险共担、价值共享。

第二，优化供应商评审标准，增加AI开发管控能力考核。降低人员数量、基础编码经验等项的评审权重，重点考察服务商的行业业务方案能力、AI相关项目实践业绩。新增AI管控体系评审内容，核查服务商是否建立提示词版本管理、AI生成代码人工强制审查、开源组件扫描、知识产权溯源等流程，评估服务商的安全审计与缺陷治理能力。鉴于AI编码的高效率、低成本，服务商投入Demo（演示版）制作的额外成本总体可控，评审中可增加对应标的软件Demo的评审指标。优化采购文件中异常低价判定规则，以及启动报价偏低澄清的条件，避免将优质且低价的供应商排除在外，以契合AI生成代码的新形势。此外，优化供应商履约后评价机制，将交付质量、合规情况、实际使用效果纳入评价结果，作为后续采购寻源与选择的依据，淘汰劣质的低价服务商。

第三，创新采购合作模式，完善合同条款，以适应软件开发新范式。可将大型定制项目拆分为若干迭代单元，实行分阶段采购、分阶段交付结算，从而降低一次性采购的风险。针对需求相对明确且会长期反复发生的开发与运维类需求（如系统迭代、功能优化、缺陷修复、运维支撑、通用组件复用等），可采用框架协议采购：第一阶段确定入围服务商并锁定相对固定的价格体系，第二阶段按任务逐项下达需求、必要时二次竞价，从而减少重复采购、降低采购成本；而个性化强、交付边界模糊的从零定制开发，仍宜按项目单独采购。合同中专门针对AI开发设置条款：明确需求变更管理流程、阶段性交付物与分阶段验收标准；明确AI生成代码知识产权全部归采购方所有，约定侵权责任由服务商全部承担；明确所有AI生成代码必须经过人工审查与优化后方可交付，禁止直接交付未经处理的原生AI代码。大型项目可引入第三方监理或技术评估机构，开展报价合理性审核、开发过程监督与代码合规审计。

第四，完善验收机制，兼顾功能、业务使用效果与AI专项合规。应在采购需求阶段即约定可量化的业务使用指标，作为验收核心依据。验收可划分为功能完整性、系统性能安全与实际业务使用效果3个层面，并同步增设AI专项合规审查，核查版权归属、开源协议合规、人工审计留痕等文档。推行分阶段迭代验收，每一轮迭代结束后进行独立验收，问题全部闭环方可进入下一阶段。做好全项目文档归档，需求文档、架构方案、AI开发记录、代码审计报告、测试报告、验收资料等统一集中归档。

第五，强化面向使用端的风险防控。在采购阶段即应预判后期运维风险，并在合同中明确服务商应当遵循对AI生成代码的注释标准，以保障代码的可维护性。同时，明确约定大模型迭代情形下的改造责任，界定运维响应的时效与范围。落实知识产权责任，要求服务商对AI生成代码进行开源合规扫描并提供合规承诺，一旦发生侵权纠纷，由服务商承担全部赔偿与处置责任。

结语

AI编码技术推动定制软件开发由人力技术密集型向智力价值密集型转变，建立在人工开发基础之上的传统采购模式已经难以完全适应新形势，从需求端、采购端到使用端，采购方均面临诸多挑战。采购实践中，既不能全盘否定传统软件工程计量方法，也不能无视AI带来的范式变化而盲目沿用既有套路。采购方应当结合自身业务实际，通过构建复合计价模型、优化供应商评审、完善合同管理、健全多维度验收、强化项目风险防控，综合平衡成本、质量与风险之间的关系。在控制采购成本、防控AI带来的版权、运维与业务等风险的同时，充分认可服务商在架构设计、业务建模、AI成果审查等方面提供的高价值智力服务，科学合理制定采购实施方案、遴选适配供应商，推动定制软件采购项目优质高效地支撑业务活动。

（作者单位：中国移动通信集团陕西有限公司）