酷家乐内部，一个本科非计算机的项目管理岗，给两个客户上线了完整的、带后端和数据库的定制应用。研发没参与，外包也没参与。一个人，用了 VS Code 加上 一个 CloudBase。
名词：本文里的「应用市场 Mini App」指酷家乐 SaaS 应用市场里的轻量 Web 应用，与微信小程序无关。下文统一用 Mini App 指代。
SaaS 行业的老问题：客户定制谁来接、怎么接
做 To B 的人，大概率都被一类需求卡过：某个具体客户，提了一个跟你主线产品差一点的需求。做不做？三条路：
- 让客户自己的 IT 做？大部分中小客户没 IT 团队。
- 让原厂研发做？研发会算账：这只服务一个客户，做进主产品对其他客户没价值，排不上版本，原厂做一次的成本也高得离谱。
- 找第三方服务商外包做？三方合作本来就不牢靠。外包接完单就走，半年后客户要改个功能，原来那家外包可能换了业务、可能已经跑路了，合作就黄了。
绕一圈，多半的结局是客户算了一下成本和不确定性，说「算了，这个功能我就不用了」，事情就停在这里。
这类需求 ROI 其实算得过来，缺的是企业内部一个合适的承接位置。执壹接的就是这一类需求。
具体一点说：酷家乐做的是云端 3D 家居设计的 SaaS，给设计师、商家、家居品牌用。商家在平台上发产品——柜体、材料、家具——客户和门店用这些产品做设计、下单。产品有生命周期，过一段时间商家会下架。但客户手上常常有老订单、老合同正在跑售后或正在谈成的单子，需要继续用某个已经下架的产品。商家希 望能「对某个特定经销商，定向开放某些已下架产品，限定一段时间，到期自动关闭」。
很典型的客户定制。过去就停在这里。
三到四天，他把这个工具做出来了
执壹做的东西在酷家乐应用市场里。商家可以创建一个开放计划，选哪些下架产品、定向给哪个经销商、设定到期时间，提交，到期系统自动处理。前端有界面，后端有接口和数据库。
整件事三到四天。
工具栈很简单：VS Code + Codex（OpenAI 的编码助手）写代码，后端全部跑在 CloudBase 上——云函数承接接口、云数据库按客户维度存配置、对象存储放文件。他基本没进过 CloudBase 的控制台。CloudBase 提供的 Skill 和 MCP 装好之后，「你直接说你的诉求就可以了」，剩下的事 AI 自己会调。
他自己的描述很朴素：
「做开发的话，我就是用的 VS Code 加 Codex。CloudBase 在我这里来看，相当于它就是一个后端服务器，我们这里的程序就是一个前端，相当于它就是一个前后端的程序。」
里面有几个判断很值得分享一下。
第一，数据模型他自己想清楚了。「哪些客户能问，我肯定要以客户维度去存储我的数据。」架构他先想清楚，云数据库的表结构、字段定义让 AI 写。代码他不写，但他懂业务该怎么落到一张表上。AI 帮他打字，他自己拍板架构。
**第二，他选择不接 CloudBase 的身份体系。**用户用这个 Mini App 的前提是已经登录酷家乐，「如果再让他登录一次就感觉比较割裂了」。所以前端复用酷家乐主站的登录态，CloudBase 只承接后端的接口、数据、存储。这是一个超出「开发」范畴的产品判断——他知道 CloudBase 该出现在哪儿、留在哪儿。
**第三，发布也走主站现有流程。**写完后把前端编译产物按酷家乐的发布流程上传，发布给指定商家或公开到应用市场。前端跑在酷家乐里，后端调用 CloudBase 的接口。对最终用户来说，他用的是酷家乐应用市场里的一个 Mini App，看不到 CloudBase 的存在。这种「隐形后端」的接法，让 CloudBase 完美嵌进酷家乐的主站体验里，体验上没有任何割裂。
还有一个项目是 PDF 上传和预览，他用了 CloudBase 的对象存储。中间碰到默认域名做 PDF 预览会出现中间提示页的小问题，他没等流程，直接让 Codex 想办法绕过去。问题解掉了，工具继续上线。
一个多月，单兵作战，两个项目都跑在客户业务里。
对一家公司的业务，到底变了什么
如果只看技术细节，这是「业务岗用 AI 写出软件」的故事。放到企业里，变化要更具体一些。
**链路短了。**过去这类需求要整理需求、外发外包、对接、验收、修改，月级周期。现在内部直接做，三四天。
**钱回到内部了。**过去定制需求要么客户自己 IT 做，要么外包做，两条路里钱都不会进酷家乐。现在内部做，「这部分钱公司也收回来了，相当于是同样的经济投入下，产出变大」。
**客户接得住、也维护得住。**过去外包是一次性的，半年后客户想加个功能往往找不回当初那个外包。现在内部接：
「以前要么客户自己有 IT，要么找外包。现在我们自己接得住——更重要的是后面持续要改的，我们也接得住。」
变化背后还有一层执壹没明说但能看出来的：承接客户定制需求的角色，过去只能是研发或外包，现在多了一个选项——业务岗。同样规模的研发资源能更专注主线产品，定制需求被这条新链路消化掉了。
如果要给这条路起个名字，叫 OPT（One Person Team） 也合适。一个人，一个 VS Code，一个 CloudBase 后端，就能稳定接住一类客户需求。不是「业务岗转岗做研发」，是「业务岗 + AI + 云后端」组合出来的新角色。
执壹 的几个做法
把过程顺下来，他总结了几条算得上方法论的东西。这一段不写得很完整，因为它本来就是一个人在边做边总结。
**先让研发做一次 POC。**在执壹之前，酷家乐研发同事先做了一轮完整验证，选型、跑通流程、把 IT 开通服务的事走通。「前面那个开通服务的时候，可能流程上会跟我们的 IT 去沟通一下，后面使用的话其实就很简单了，因为 Skill 和 MCP 已经比较全面了。」对非研发岗来说，第一公里的成本由研发同事先垫付。
**架构自己设计，代码让 AI 写。**决策留在自己手上，AI 帮忙打字。业务逻辑、数据模型、产品体验的判断都自己拍板。
**不抢主站的身份。**把 CloudBase 当成补位，让它只解决主站没覆盖的那一段：后端、接口、存储。其他都交还给酷家乐主站。
**遇到边界问题让 AI 想办法。**PDF 项目，他没去申请域名，直接让 Codex 给方案绕过去。「我不知道怎么办」和「先让 AI 试试」之间，差的是一个动作。
**允许「野路子」。**他自己说，对照研发的标准流程，「我们这边做说白了，其实也就是野路子」。业务岗不背「代码仓库、CI/CD、发版规范」那一套，能跑通就好、能解决客户问题就好。这套做法能跑下来，前提是它跟研发主流程并行，不互相干扰、不互相要求。
为什么这件事可能跟你有关
如果你是 To B 公司 的业务、产品、运营、客户成功，你大概率遇到过执壹接的那类需求。这类需求过去缺的是承接位置。现在 AI 编码工具加上一套开箱即用的后端，承接位置出现了，研发之外的人也能站上这个位置。
如果你是技术负责人或老板，这件事你看的角度更直接：研发资源是恒定的，主线产品永远做不完。过去公司收不到的定制业务收入，现在可以靠业务岗 + AI + CloudBase 接住。同样的研发规模，覆盖面变大了；同样的人员配置，组织效率上一个台阶。
如果你只是好奇 AI 编码到底能做到什么程度，执壹这件事已经超出 demo——一个非研发的人写出来，上线、跑在真实业务里、客户在用、还能持续维护。
写在最后：CloudBase 的一种企业用法
执壹这条路，是用 CloudBase 标准版自己跑出来的。工具栈是 VS Code + Codex + CloudBase 的 Skill 和 MCP。能力是 CloudBase 已经对所有用户开放的基础能力，今天就能开通、今天就能起步。没有打包方案，没有等待。
业务岗承接长尾定制、研发启动第一公里、CloudBase 做隐形后端，这条路可能不止酷家乐这一家适用。
「以前要么客户自己有 IT，要么找外包，现在我们自己接得住。」 —— 酷家乐 执壹
