酷家乐一个不写代码的项目经理，1个月给客户定制上线了两个应用

酷家乐内部，一个本科非计算机的项目管理岗，给两个客户上线了完整的、带后端和数据库的定制应用。研发没参与，外包也没参与。一个人，用了 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，要么找外包，现在我们自己接得住。" ——酷家乐 执壹

关于腾讯云CloudBase

腾讯云CloudBase 是AI-Native的全栈应用开发平台，面向企业和开发者提供云函数、云数据库（NoSQL/MySQL/PGSQL）、对象存储、静态托管等一站式后端能力。开箱即用，免运维，让业务岗、产品、研发都能直接接住业务需求。

🔗 现在就试 CloudBase：

https://tcb.cloud.tencent.com/