在定制开发和低代码的夹缝里，我们用五六年、几千万融资，踩出了一条别人抄不走的低成本交付路。
我们公司是一家提供软件开发服务的公司。在行业里摸爬滚打五六年，烧了几千万融资，沉淀出一套低代码 PaaS 平台（PaaS：平台即服务，为我们的项目交付提供基础技术基座）。
依托这套平台，最近一年交付了好几个项目，总结出一套低成本打法：
- 实施工程师根据需求在平台里用数据建模工具拖出基本的菜单层级和 CRUD 表单（CRUD：指数据的增、删、改、查基础操作）
- 客户在线试用，收集细化确定“真实”需求
- 实施工程师在平台里用可视化流程工具建立业务逻辑处理和表单审批步骤
- 最后剩下难搞的，比如第三方接口集成对接、低代码实现不了定制化，开发工程师才介入进来，用一种有一定学习门槛的平台专属 DSL 代码语言（DSL：领域特定语言，仅适用于我们平台的专属开发语言），补足这些缺口
为什么这套打法能降低成本？
- 低代码 PaaS 平台已经封装了大量的工程实践，实施工程师在这个基座上启动项目，就是快
- 实施工程师不是正经的开发者，不需要掌握任何编程语言，人力成本远低于专业开发工程师
- 需要专业开发工程师出手去填空和补漏的项目并不多，一个开发工程师就能兼顾四五个项目
- 开发工程师的技能集锁死在非标准平台 DSL 上，在行业市场上无竞争力，工资的议价权不高
- 实时在线让客户看到系统在迭代进化，透明度和满意度都不错
为什么这套打法是独特的，别人复制不走？
- 烧了几千万融资，构建出的这套低代码 PaaS 平台本身就是门槛
- 从各类客户需求抽象出来的通用能力，被纳入平台，再赋能给其他项目；开发和维护这套低代码 PaaS 平台，只需要薪资最高的三个高级工程师完成。最贵的高级工程师，没有锁死在无穷无尽的项目上，而是不断沉淀平台标准能力，成为客户项目的发动机
- 平台标准能力是有限的，一旦 99% 的平台能力完成，这批高薪资工程师可以去兼顾项目了，进一步节省成本
这套打法现在有什么痛点？
- 客户的奇葩需求越来越多，有超出平台能力能覆盖的趋势；
- 也就是说，项目接的越多，项目里掌握 DSL 的开发工程师会不够用。
- 成也萧何败也萧何，这种 DSL 开发工程师在行业市场上不好招聘，因为正经开发工程师因为职业发展路径规划的问题，不会优先考虑锁死技能集的专有平台开发。
- AI 的冲击带来两个问题：
- AI 会不会代替这套平台？这是老板近期集中思考和焦虑的根源，下一篇文章细说
- 客户项目里的 AI 需求越来越多，导致简单的 CRUD 表单都要对接 AI，需要专业的工程师去做集成，打破了上述低成本打法的闭环。原本仅需少量开发补缺口，现在 AI 集成需求让开发介入比例大幅提升，直接推高项目成本。