一家小型团队，正在让公司里的每个人都接近“一个人就是一家公司”的状态

过去公司里很多事情因为生产工具限制被搁置

在上海，一个数十人的小型团队——美亚风鸟，正在尝试一场关于组织效率的实验。

美亚风鸟专注于企业数据查询与分析服务，业务模式类似企查查、天眼查。凭借“注册即送5年 SVIP”差异化策略，正快速积累用户、拓展市场。但对于这样一个团队来说，要在竞争激烈的企业数据赛道持续提升产品能力、服务质量和市场覆盖，仅依靠增加人力并不是最优解。

过去半年，AI 部门负责人 Andy，半年来一直在公司推动一个目标：借助 AI，让每一位员工都拥有“一个人即一家公司的产能”。

" 我们做的是 OPC，One Person Company。这个目标越来越有可能了。 Andy，上海美亚风鸟 AI 部门负责人

风鸟的业务里有很大一块是数据爬取与入库。产品经理判断"我们需要这些数据"，然后找爬虫工程师提需求，工程师排期、写爬虫、入库、上架。一个完整链路下来，从需求到能用，往往是几周。

工程师时间有限，能排上去的是产品主线需求。排不上的是那些"也想要、但没那么紧急"的长尾。HR 想做一次团建投票，过去用问卷星凑合。业务同事想看一眼竞争对手的某个公开数据，过去只能写需求等着。

" 原来产品经理他基本只能提需求，他是做不了里面细节的。

说白了，会写代码的人才能把一个想法变成一个能跑的东西。公司里其余 80% 的人，无论想法多清晰，都得排队等那 20% 的人。

Andy 推 AI Native，最早盯上的就是这件事。

风鸟 AI Native 内部协作示意

产品经理打开CodeBuddy，连上CloudBase自己跑

来看一个真实的协作流程。

过去：产品经理说"我要这个网站这些字段的数据"，爬虫工程师接需求，开发，入库，再回到产品。

现在：产品经理打开 CodeBuddy（腾讯的 AI 编码工具），连上一台 CloudBase ，直接告诉 AI："我要去这个网站爬这些数据，入库到这个地方。"AI 写代码、运行、把数据落到指定位置。产品经理全程不写一行代码。

CodeBuddy + CloudBase 协作链路

这套组合 Andy 用得最熟，他给团队推荐的标准开发链路是：

• • AI 编码工具：CodeBuddy（也支持 Codex / Claude Code，Andy 自己偏向用国产工具）
• • 配套接入方式：MCP 或 Skill，AI 编码工具通过标准协议直接调用 CloudBase 的能力
• • 承接后端 / 算力：CloudBase 提供静态托管、对象存储

CloudBase 在这套组合里干两件事。

给 AI 一个"安全的物理隔离环境"。

" 你要考虑到你用 AI 开发的时候，AI 是会有不确定性的。它很聪明很灵活，如果放在生产环境去搞，很容易就造成灾难。 让 AI 在安全的环境上做，它怎么搞都不会破坏掉成果。

把整台 CloudBase 交给 AI。AI 在里面装环境、跑命令、写代码、调试，干任何事。开发完成后，把整个环境打包成一个 docker 镜像，再迁移到生产环境（CloudBase 自己的镜像服务，或公司其他主机的容器）。

Andy 把这种用法形容成"AI 开发的隔离物理机"。它解决了 AI 编码当下最棘手的一件事：AI 的不确定性 vs 生产环境的稳定性。这是他自己摸出来的用法，没有现成的教程。

让做完的东西立刻能用起来。

最早 Andy 试 CloudBase 的第一个项目，就是把开发完的应用直接托管到静态网站托管上，给一个公网链接，公司里所有人都能访问。

" 做完直接托管到 CloudBase 上，直接通过一个公网的链接就可以访问。

开发和部署是连续的，没有"找运维同事帮忙发布"这一步。

不到一个月，团队跑出了 10 个左右的内部应用

这套组合在风鸟跑通的速度比 Andy 自己预期的快。

第一批先做的是问卷类、投票类的轻应用。HR 部门要做一次团建投票，过去用问卷星凑合，现在直接做一个属于公司自己的小网站托管出去。

接下来是数据采集类。业务同事自己跟 AI 说"去爬哪个网站的什么数据，入库到哪里"，CloudBase 上跑爬虫。

再后面是一些 POC，把 AI 写出来的 demo 直接托管到 CloudBase，给内部团队验证。

" 现在差不多有 10 个了，因为我们事情本来就多。” “因为你用 AI 开发的话其实都很快的。”

10 个应用一个月内做出来。这个数字背后，是公司里第一次有非技术岗位的同事，能够独立交付一个可访问、可用的内部应用。

更具体一些看协同链路的变化：

• • 过去：所有内部需求 → 找研发 → 排期 → 等 → 上线
• • 现在：每个人都能用 AI 编码工具 + CloudBase 自己做需求 → 自己上线

研发同事从"瓶颈位"被解放出来，去做架构、模型、AI 框架本身。长尾需求被消化掉，主线需求得到了更多研发资源。

风鸟是一家中小公司，没有大厂的 AI 中台投入，没有专门的 AI 工具部门。Andy 和几个同事，用了不到半年把这条路走通了。这件事没有现成教程，他们是在一条没人走过的路上先踩了脚印。

如果要给这种"一个人独立交付一个应用"的能力起个名字，叫 OPT（One Person Team） 也合适。一个人就是一支小队伍，AI 编码工具是键盘，CloudBase 是后端的脚手架，做出来的东西直接托管出去，团队里其他人打开链接就能用。这是过去 To B 公司里业务岗做不到的事，现在做得到。

OPT 是能力单元。再往上一层看，Andy 推的 OPC（One Person Company）其实是把公司里所有这些 OPT 串起来：每个人都能独立交付价值，公司就接近"每个员工都是一家公司"的形态。

Andy 的经验分享

Andy 推 AI Native 这半年，沉淀了几条朴素的判断。

AI Native 的关键，是非技术团队能不能用上。

我自己的架构运营能力是 OK 的。但现在走 AI Native，最重要的反而不是技术团队的人会不会，我们希望把它普及到公司所有人，特别是那些非技术的同事。

技术团队会用 AI，本来就是基础动作。让非技术同事也能用 AI 直接产出业务价值，才是真正的转折点。

CloudBase 也适合推荐给非技术岗。

" 我个人认为，CloudBase 最大的用户群体不是那些专门搞技术或者 AI 的。因为我有 N 台机器或者 N 台资源，我可能已经建立了一套惯用的资源使用方式，对我来说用什么都一样。但对很多非技术、或者他没有这么多资源的人来讲，CloudBase 也许是它一个唯一的渠道。”

技术人员有自己一套使用云资源的习惯，CloudBase 对他们是可选项。但对一个 HR、一个产品经理、一个业务同事来说，让他自己去注册腾讯云账号、搞 SSH 密钥、装环境、配防火墙，一道门槛就把他拦在外面。CloudBase 把这些事抹平到"AI 直接帮你弄好了，你拿到一个公网链接"，这才是它对一家公司最大的价值。

架构自己设计，代码让 AI 写。

" “我个人更愿意用国产的这些工具，包括 CodeBuddy 也好。我是做了一些架构设计的，模型能力差距都不大，架构设计成功，那这些工具就一定能工作得好。” “如果用 Codex 或者用 Claude，你会更多依赖于别人帮你设计好的，从长远来看是不利的。”

模型能力差距正在快速收敛，工具本身已经不是变量。变量是架构是不是你自己设计的。架构是你的，工具就是顺手的工具，无所谓是谁家的。

OPC 这件事，分两步走。

" “短期内会先把流程嵌到现有的体系里面，无法做到 100% OPC，只能覆盖一部分流程。可能几个月之后我们能做到 50% 的OPC，就不需要人管，都是 AI 在搞的程度。” “将来要做 100%，我觉得最大的点是不能用旧的框架，得要用新的框架完全做一套，然后再把旧的东西往里灌。”

第一步，把 AI 嵌入现有流程，做到 50% OPC，公司里一半的流程不再需要人手动跟进。第二步，重新设计一个为 AI 而生的新框架，把现有资源全部往新框架迁移，做到 100% OPC。

" “我们现在大概在 15%，准备做更多，未来几个月最大的点是把 OPC 的比例提高到 50% 左右。”

从 15% 到 50% 再到 100%，不是 PPT 上的数字，是 Andy 给团队排的真时间表。这是风鸟团队给自己的 AI Native 路线图。

风鸟的实践，对什么样的人有意义

如果你是公司里的业务、产品、运营、HR，你大概有过这种感觉：心里很清楚一个内部工具该长什么样，但你没办法把它做出来，研发排期永远不是你想要的速度。

如果你是技术负责人或老板，你大概算过一笔账：研发资源是公司里最贵的成本之一，把它消耗在长尾内部需求上是浪费。当公司里的非技术同事可以自己用 AI + CloudBase 把内部应用做出来，研发资源就被解放出来去做真正核心的事，产品、AI 框架、深度架构。

如果你关注 AI Native、OPC/OPT 这些话题，风鸟做的事很多中小公司现在也可以参考：OPC 也可以发生在一家中小公司组织内部。从 OPT（One Person Team）到 OPC（One Person Company），是一个从"能力单元"到"组织形态"的递进。先有每个人独立交付应用的能力（OPC），才有条件拼出公司级的 AI Native（OPT）。风鸟这半年走过的路，正好是这条递进的一个完整样本。

一家公司真正进入 AI Native，看的是有没有让公司里的每一个人都接近 OPT 与 OPC 的状态。

组织上的难，比技术上的难更值得说一下

跟 Andy 聊完，他反复回到一个点上。

技术上的事其实不复杂，半年就能跑通。难的是组织。难在愿不愿意改变同事的工作习惯，愿不愿意承担短期效率下降的代价，去换一个长期更好的形态。

" “前期肯定是慢的，后续用起来的话，可能就会创建环境也就几分钟的时间就会很快。” “推广要有时间，要逐步说服别人，改变他的工作习惯。”

愿意花一两个月去说服同事改变习惯，愿意把 AI Native 真正做成全公司的事，这是小型公司里很少见的一种推进方式。

CloudBase 在他们的故事里是隐形的角色。开发的时候它是 AI 的物理隔离机，做完的时候它是公网链接，没人用了它就被回收。它在台后，每一步都在。

写在最后：CloudBase 的一种企业用法

风鸟是 CloudBase 的企业版用户。CodeBuddy + 静态托管 + Docker 镜像迁移这套链路，是 Andy 和团队自己一边做一边总结出来的，没有教程、没有方案咨询，把 CloudBase 的标准能力按自己的需求拼了起来。

这是 CloudBase 在企业里的一种用法。今天就能起步，最小路径只需要一个 AI 编码工具账号，一个 CloudBase 环境。

🔗 现在就试 CloudBase：

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

如果你已经在实践的路上了，也欢迎向我们投稿分享！

什么是云开发 CloudBase

腾讯云 CloudBase（云开发）是腾讯云面向 AI 时代的全栈一体化后端基础设施，提供云函数、云数据库、对象存储、静态托管、AI 模型托管等核心能力，配合 CodeBuddy / Codex / Claude Code 等 AI 编码工具的 Skill 与 MCP 协议，让业务岗、产品、研发都能直接接住业务需求。