项目制不是原罪，复杂性沉淀在哪里才是分水岭

很多老板都有过这种困惑：营收一年比一年涨，团队从几十人扩到几百人，毛利却没跟着涨，自己反而越来越累。钱赚到了，人却困在没完没了的定制项目里，出不来。

问题不在做项目。Palantir长期深入客户现场做重交付，照样被视为平台公司。差别在于，它把现场反复出现的复杂性吸收进平台，让项目现场同时成为产品进化地。多数中小软件公司正好相反，复杂性留在客户现场，留在项目代码和个别老员工脑子里。

这个差距有数字可查。用友网络2024年年报显示，整体毛利率47.54%，比2019年的65.42%下滑近18个百分点，主因是大型客户项目制交付比重大、驻场成本高。金蝶国际同一年业绩公告显示，整体毛利率65.07%，订阅软件毛利率据业务披露可达96.5%。

估值逻辑也一样。资本市场对可复用的SaaS订阅收入，通常给6到15倍ARR；对定制化服务收入，只给1倍左右，这是多家PE和VC估值研究的共识。收入规模相同的两家公司，产品化程度高的那家，估值能高出数倍。

所以真正的命题，不是要不要接项目，而是每一次现场工作，到底是在重复劳动，还是在增强平台。下面五道坎，是把交付变成资产的落地路径。

一、能力分层：通用底座与企业独有分开

第一道坎，是分清哪些能力该平台化，哪些该留给企业自己。

通用底座管共性问题：用户体系、权限模型、流程引擎、数据接入、报表中心。这些不挑客户，一次建设、长期复用。企业独有的业务规则、行业算法、特殊流程，才是差异化的来源，应当用配置和适配表达，而不是每次重写底层框架。

做不到这一点的公司，典型症状是客户越多、代码分支越多。新接一个项目，先拷贝老项目，再改三个月。边际成本降不下来，规模越大越重。

落地动作很具体：把现有项目里的公共模块抽出来，做成可配置组件；业务差异用参数、规则、插件表达，不进主干代码。

二、需求回流机制：让现场成为产品雷达

第二道坎，是建一条从项目现场到产品团队的规范通道。

现场每天都在暴露真实痛点：某个行业通用的报表、反复出现的集成需求、客户共有的审批逻辑。这些共性问题如果只解决在当前项目里，平台就永远追不上现场。必须有一条通道，把现场收集到的共性需求、通用组件提议，规范地送回产品团队，纳入版本规划。

不少公司的需求回流，靠个别牛人凭记忆口头传达，人一走经验就断。要制度化：现场提交需求模板，产品团队定期评审排序，明确哪些进下一个版本、哪些拒绝、哪些转为配置项。

这一步决定平台是在持续进化，还是原地踏步。

三、统一技术底座：禁止私自分叉

第三道坎，是搭一个真正公共的技术底座。

底座至少覆盖四件事：统一数据层、统一权限与审计、统一AI能力接入、统一部署运维。所有项目基于底座做二次适配，不许私自复制代码、另起炉灶。

很多公司号称有平台，实际是多个项目各维护一套相似代码，所谓平台只是几个公共页面的集合。真正的底座，要能承载从数据接入、业务建模、权限治理到版本发布的完整链条，让现场团队调用统一能力快速建模，而不是重复造轮子。

禁止分叉听上去很硬，却是防住版本地狱的唯一办法。否则客户越多、环境越异构，升级一次就草木皆兵。

四、交付模式转型：驻场从写代码到搭方案

第四道坎，是改变驻场团队的工作方式。

传统驻场需求来了就写代码，现场成了人力外包池。转型方向是，驻场用平台工具快速搭方案，把精力放在理解业务、建模问题和验证价值上，而不是重复编码。

这条路有案例可查。葡萄城活字格低代码平台的公开案例里，某科技企业搭供应商管理系统，传统开发要14人天、成本约3.2万元，用平台只用3小时、约0.2万元，效率提升近10倍。数商云低代码B2B系统的公开案例也显示，某机电设备企业上线后订单处理效率提升60%。

当现场人员从写代码转向用平台配置，交付速度和解耦程度会同步改善。现场不再是成本发生地，而是产品验证点。

五、闭环考核导向：不只考验收，考资产产出

第五道坎，也是最容易被忽略的一道：考核什么，组织就做什么。

只考项目验收和回款，团队自然选最快交付的方式，也就是堆人写代码。要推动平台化，得同步考核可复用资产产出：沉淀了多少组件、被多少个后续项目调用、新项目从零编码的比例降了多少。

指挥棒一变，行为就变。现场团队会主动回流共性需求，优先用平台能力而不是另写一套，因为这直接关系他们的绩效。

两个让闭环不空转的机制

五道坎之外，还有两个机制决定闭环能不能真正转起来，创始人要特别留意。

第一是资产目录与复用度量。没有量化抓手，闭环考核会空转。建议建立平台资产目录，盯几个硬指标：新项目从零编码占比、组件复用率、平均交付周期降幅。这些数字直接回答，平台到底有没有在降低边际成本。

第二是平台治理裁决。谁来定哪些需求下沉平台、哪些必须拒绝、版本节奏怎么排？需要一个平台委员会或类似PMO角色。否则销售要快、研发要稳、项目要灵活，三方拉扯之下，平台迟早被项目侵蚀。

AI可以轻量介入的几个环节

不用大张旗鼓搞AI战略，在现有闭环里嵌几点就够。

需求抽象环节，用模型对现场需求自动聚类，识别共性、推荐平台组件候选。低代码搭建环节，让业务人员用自然语言描述规则，平台生成配置和轻量应用。资产沉淀环节，用检索增强把项目复盘自动抽取成可复用资产，避免经验随人流失。测试巡检环节，用自动化回归保障多客户版本一致。

每一点都不必一步到位，先在一条业务线上跑通即可。

写在最后

平台化不是消灭定制，而是重划边界：把产生答案的工程机制不断标准化，让业务答案保持差异。

中小软件公司不必学Palantir做通用大模型，但要学它那套闭环。先选一个行业或一类客户群，把五道坎跑通一遍，让第一个项目的复杂性真正沉淀进平台，第二个项目就能走得更轻。

项目负责接触现实，平台负责沉淀规律。这个循环一旦转起来，重交付终将成为你最深的护城河。