一人军队（OMA），如何玩转 Vibe Coding？

这几年，“一人公司”越来越流行，也就是 OPC（One Person Company）。

它强调的不是“公司只有一个人”，而是一种更强烈的状态：一个人，却拥有完成一整套任务的能力。 或者更大粒度的，完成整个目标交付的能力， 从产研到销售和服务。

过去想做一个稍微完整的软件产品，往往需要产品、设计、前端、后端、客户端、测试、运维等不同角色。现在，随着 Coding Agent 的能力越来越强，一个人能够覆盖的范围正在迅速扩大。

我自己已经做了不少工具软件，包括 KeeNotes、FooSnippets、FooCloud、RMBG 等，更有多款产品已经进入 Apple App Store 的发布流程。

最主要的是，Tooling 本身也是整个 KEEVOL TEC 体系的一部分：工具软件、技术教育和战略咨询，构成了一套相互支撑的事情。（我叫这个战略愿景为KEEVOL Troika）

当 KVectors 向量数据库成为个人古早手工编码时代的最后一个高质量交付的产品之后，

从 2026 年开始，我的软件开发方式发生了一个非常明显的变化，即开始了 Vibe Coding（Everything）。

很多有多年开发经验的人第一次真正面对 Vibe Coding，多少都会经历一点心理冲击，而我就经历了一个如下的过程：

我们几十年来形成的软件工程习惯和个人能力，本质上建立在一个前提之上：

代码需要人一行一行写，框架需要人学，API 要查，跨平台意味着重新学习另一套技术栈，一门新语言可能要花几个月才能熟悉。

因此，我们过去的软件工程里，有大量决策，其实是在优化“人写代码的成本”。

可是 Coding Agent 出现以后，一个极重要的变量发生了变化：

这时候，如果依然机械地沿用过去所有“为了减少写代码而产生的最佳实践”，未必还是最优解。

这也是我这一段时间 Vibe Coding 最大的体会，下面是个人Vibe Coding过程中总结的一部分个人认为的最佳实践，与大家分享。

传统团队为什么经常把项目拆成很多 Repository？

前端一个 Repo，后端一个 Repo，iOS 一个 Repo，Android 一个 Repo，基础设施可能还有一个 Repo。

这是一种很典型的组织结构映射到代码组织结构的方式。

如果一个产品本来就是一个人加若干 Agent 在维护，那么人为把它切成七八个仓库，反而会产生额外的上下文成本。（还记得微服务吗？🤪）

Web 前端、API、数据库 Schema、macOS 客户端和部署脚本。

如果它们都在一个 MonoRepo 里，Agent 可以直接看到整个系统。

数据库字段改了，它能够顺着依赖关系找到 API；API 改了，又可以继续找到客户端。

所以，对 OMA 来说，MonoRepo 不只是代码管理风格。

换句话说，过去 Repository 经常围绕“人和团队”划边界；到了 Agent Coding 时代，Repository 还要开始考虑：

有了 MonoRepo，还只是让 Agent 看得到代码。

如果这些东西只存在于你的脑子里，Agent 每一轮都得重新猜。

所以，一个适合 Agent 的代码库，不应该只有代码，还应该有一套层级化的上下文体系。

比如在最顶层描述整个项目的目标、原则和架构约束；进入具体模块以后，再补充这个模块自己的规则；再往下，还可以有更加局部的约定。

Global Context → Project Context → Module Context → Task Context

更重要的是，它开始把过去存在于程序员脑子里的隐性知识显性化。

这其实是 Agent Native Software Engineering 很重要的一步。

Vibe Coding 更像以前的 Pair Programming，只不过你的 Pair 从另一个程序员变成了 Coding Agent。

事实上，我越来越不相信所谓 “一条神 Prompt 把事情搞定”。

当然，这里的 Pair 也可以是 Agent 和 Agent 组 Pair，不一定是你和 Agent 组 Pair，甚至组合成两个甚至更多的层次，并不冲突。

能不能一套代码跑 iOS、Android、macOS、Windows？

开发两个/多个平台的版本太贵，所以最好只维护一个版本。

Multi-Platform over Cross Platform

Swift 写一套，Kotlin 写一套，Web 再写一套，维护成本太高。（甚至人你都找不到，除非你一起手就是大厂）

但当 Coding Agent 可以帮你承担大量实现工作以后，这个成本结构发生了改变。

这时候，与其为了共享代码，让所有平台迁就某一个抽象层，不如：

真正共享的，可以是产品定义、协议、数据模型、设计规则和业务逻辑描述，而不一定非得共享每一行实现代码。

Multi-Lang over Single Lang Ecosystem。

以前我们很喜欢所谓 One Language Everywhere。

但 Coding Agent 并没有这么强的“语言洁癖”或者说“语言壁垒”。

今天写 Swift，下一分钟写 Rust，再下一分钟改 TypeScript，对 Agent 来说并不像人一样需要重新学习个半年。

过去 Polyglot Programming （多语言混合编程） 最大的问题之一是认知成本。

所以未来软件系统可能反而会变得更多语言，而不是更少语言。

只不过复杂性的一部分，从“人必须熟悉所有语言”，转移成了：

一个功能完成以后，不要让对方先装环境、VPN、依赖和各种工具才能看。

但最终真正交付的时候，尤其企业内部系统或者私有化软件，完全可以进入客户自己的局域网或者内部环境。

把“验收”和“最终部署”拆开，解决的是两个不同的问题：

如果把二者强行绑定在一起，反馈周期往往会被部署复杂性拖慢。

但 Vibe Coding 以后，我们可能需要重新思考：

比如我刚刚完成一个非常好的 macOS 权限授权流程。

然后把这些东西沉淀成一份 Context、Spec、Skill 或 Pattern。

下一次，再让 Agent 根据新的项目重新生成最适合那个项目的实现。

而被提炼出来的知识，则可以继续生成许多不同的结果。

AI 让“重新生成代码”越来越便宜以后，后者的价值会越来越高。

这其实也是我现在理解 Vibe Coding 最核心的一点。

恰恰相反，它让每一次修改的成本急剧下降，因此我们终于可以：

如果以前修改一个方案需要两天，那么大家倾向于修改之前讨论半天。

当代码越来越多由 AI 生成时，并不意味着工程能力变得不重要。

AI 可以写代码，可以跑命令，可以修改 UI，可以修 Bug。

但方向、边界、取舍和最终验收，仍然在 Builder 手里。

而这，大概也是 Vibe Coding 真正有意思的地方。

它首先改变的不是编程语言，不是 IDE，也不是某一种模型。

现在，一个 OMA 也可以靠 Agent 扩大能力和个人边界。

至于如何让这种能力变得稳定，而不是变成一场随机的“AI 抽卡游戏”，我的答案依然是：

循环得足够快、足够多，反馈足够及时，结果就会越来越确定。

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。

开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。