Vibe Coding 让很多人第一次感到：写代码这件事，真的变了。

但我这一个多月最大的感受不是“一个人可以替代一个团队”，而是：如果把过去的产品、架构、开发、DBA、管理经验沉淀成 Skill，AI Coding 才会从“帮我写代码”变成“帮我组织交付”。

进入 2026 年后，OPC 和 Vibe Coding 都热了起来。

OPC，通常指 One Person Company，一个人公司。Vibe Coding 则更像一种新的开发方式：你用自然语言描述意图，AI 帮你理解、拆解、写代码、改代码、跑测试，人在旁边不断校正方向。

我并没有想把自己包装成 OPC。

原因也简单：真实的软件交付，从来不只是写代码。一个需求从一句话变成可用系统，中间至少要经过产品判断、边界确认、方案取舍、架构拆分、数据设计、测试验证、发布回滚。这些东西过去分散在不同角色身上：产品经理、开发经理、架构师、DBA、测试、研发团队。

但过去一个多月的 AI Coding 让我意识到另一件事：

如果一个人曾经在这些角色里轮过岗，他不一定要变成“一人公司”，但可以把这些角色的经验固化成一条 AI 可执行的工作流。

这条工作流，我把它拆成了三大 Skill。

先回答一个问题：OPC 会不会只是短期热点？

我觉得 OPC 会继续热一段时间，但它不一定会以今天这种说法一直热下去。

每一轮技术浪潮里，都会先出现一个很有冲击力的词。它负责把大家的注意力拉过来，让人意识到：原来组织方式、生产方式、个人能力边界都可能重新分配。OPC 就是这样的词。

但热词会变，底层能力不会轻易消失。

真正值得关注的，不是每个人都要不要成为 OPC，而是越来越多复杂工作，会不会被拆成更小的闭环，被一个人用 AI、工具、流程和外部协作先跑起来。也就是说，OPC 也许是阶段性的标签，但“一个人调动一套虚拟协作系统”的能力，大概率会留下来。

所以这篇文章不想预测 OPC 会不会成为主流。

我更想讲一个更具体的变化：当 Vibe Coding 遇到 Skill，一个有跨角色经验的人，怎样把过去靠团队经验完成的产品研发链路，先结构化地跑起来。

一、Vibe Coding 真正放大的，不是手速，而是判断链

很多人第一次体验 AI Coding，会先被代码速度震住。

以前一个接口要写半小时，现在几分钟就有了。以前一个页面要查组件、调样式、补校验，现在一句话能生成大半。于是大家很自然地把它理解成“效率提升”。

这当然没错，但只说了一半。

代码写得快，不等于产品做得快。因为真实工作里，慢的往往不是敲代码，而是这些问题：

• 需求到底是不是需求，还是某个人脑子里的解决方案？
• 这个版本最小闭环是什么，哪些东西应该先不做？
• 业务规则、权限、异常、数据口径有没有说清楚？
• 开发知道按钮怎么点、字段怎么变、失败怎么处理吗？
• 测试知道哪些路径必须测，哪些边界最容易出事吗？
• 上线前有没有回滚方案，数据库变更谁来审核？

这些问题不解决，AI 写得越快，返工也可能越快。

所以我后来不再把 AI Coding 看成“代码加速器”。我更愿意把它看成一个放大器：它会放大你的表达，也会放大你的含糊；会放大你的经验，也会放大你的遗漏。

Vibe Coding 的上限，不只取决于模型会不会写代码，还取决于你能不能把判断过程交给它复用。

Skill 的价值就在这里。

二、我把过去的轮岗经验，拆成了三个虚拟角色

我的职业经历比较杂。

做过开发工程师，知道代码落地时最怕什么；做过开发经理，知道任务拆分和多人协作哪里容易断；做过 DBA，知道数据变更不能靠勇气；做过架构师，知道一个方案不只要能跑，还要能维护；做过产品经理，知道需求如果没想清楚，后面所有人都会替它还债。

这些经历以前是“人的经验”。问题是，人的经验很难稳定复制。

你今天状态好，能把需求问得很细；明天赶时间，可能就漏了异常边界。你做过一次漂亮的技术拆解，但下一次换个场景，仍然要从头组织。你知道上线前该检查哪些东西，但忙起来还是可能只凭记忆。

于是我把它们拆成三类 Skill：

这三个 Skill 串起来，就不再是“让 AI 写一个功能”。

它更像是搭了一个微型产品研发团队：

原始想法 -> 需求分析 + PRD -> 开发说明 + 测试用例 + 开发任务确认单 -> 分工计划 + todolist + 工程交付检查清单 -> 编码、验证、发布准备

图里最重要的不是箭头数量，而是边界：每一步都在回答一个不同的问题。

产品阶段问的是：我们到底要解决什么，先做什么，不做什么。

开发说明阶段问的是：这件事要怎么拆成模块、页面、按钮、接口、数据、异常和测试。

工程交付阶段问的是：谁负责什么，做到什么程度才算完成，上线前凭什么说可以发。

一句话概括：

我不是让 AI 直接从想法跳到代码，而是在想法和代码之间补上了一条可复用的交付链。

三、第一个 Skill：先把“想做什么”变成“为什么做、做哪一版”

requirements-to-prd对应的是产品经理。

它的任务不是把用户原话美化成 PRD，而是先拆开看：

• 哪些是事实？
• 哪些是推断？
• 哪些只是用户提出的方案？
• 真正的问题是什么？
• 最小闭环的 MVP 是什么？
• 哪些能力适合传统系统，哪些适合 AI 增强，哪些才是 AI 核心？

这一点很关键。

很多需求一开始长这样：

“我要做一个 AI 智能排程系统。”

如果直接进入开发，很快就会变成模型选型、页面设计、接口开发。但真正要问的可能是：

• 当前排程痛点是订单冲突、设备瓶颈，还是人工调整太慢？
• 业务是要“自动生成最终计划”，还是先要“辅助发现冲突”？
• 哪些规则是硬约束，哪些只是经验偏好？
• 如果 AI 给出建议，谁有权确认？
• 第一版是否只需要覆盖一个车间、一类订单、一个调整场景？

这些问题问清楚，PRD 才不是一堆功能愿望，而是一个有边界的产品承诺。

所以这个 Skill 默认输出两份文档：需求分析文档和 PRD。

需求分析文档负责解释“为什么”：背景、用户、场景、根因、候选方案、风险、MVP。

PRD 负责定义“做什么”：功能需求、业务规则、权限、数据、异常、非功能需求、验收标准。

它还会强调一件事：AI 是一种方案模式，不是默认答案。

这句话我很喜欢。因为现在很多项目一上来就想“加 AI”，但更应该先判断：这个问题是传统流程就能解决，还是需要 AI 增强，还是没有 AI 就不成立。

读完这一阶段，最重要的收获不是“有了一份 PRD”，而是团队终于能回答：

这一版到底解决哪个问题，凭什么说做完了。

四、第二个 Skill：不要把 PRD 直接扔给程序员

prd-to-dev-spec对应的是开发经理和架构师。

很多团队的问题不是没有 PRD，而是 PRD 和开发之间还隔着一层厚厚的空气。

PRD 说：“支持订单合并规则配置。”

开发要知道的是：

• 菜单入口在哪里？
• 谁能新增、编辑、删除、启停？
• 表单有哪些字段，哪些必填，哪些有默认值？
• 保存时要校验什么？
• 冲突规则如何提示？
• 规则启停是否影响历史订单？
• API 怎么设计？
• 数据表怎么存？
• 哪些异常要回滚？
• 测试用例怎么覆盖？

这些如果靠开发自己猜，就会出现两个结果：要么开发不断追问产品，要么开发按自己的理解先做，最后评审时再返工。

所以第二个 Skill 做的是“翻译”。

它把 PRD 翻译成开发说明文档、测试用例和开发任务确认单。这里的翻译不是把中文改成技术词，而是把产品承诺拆成可以执行的工程对象：

• 模块
• 菜单
• 页面
• 按钮
• 业务逻辑
• 数据逻辑
• API
• 权限
• 异常
• 测试用例
• 追溯关系

它要求保留一条链路：

功能原子 -> 功能需求 -> 验收标准 -> 模块/接口/数据/测试/任务

这条链路看起来有点“重”，但它的价值非常现实。

当开发做到一半发现疑问时，不是凭感觉争论，而是能回到 PRD 和验收标准。测试发现一个边界问题，也能知道它对应哪个功能需求。后续要改范围，也能看清影响了哪些模块和用例。

对我来说，这一步把 AI Coding 从“生成代码片段”拉回了工程现场。

程序员真正需要的不是一份漂亮 PRD，而是一份能减少猜测的开发说明。

五、第三个 Skill：代码写完，不等于工程交付完成

engineering-delivery对应的是研发团队。

如果前两个 Skill 解决的是“想清楚”和“拆清楚”，第三个 Skill 解决的是“交付稳不稳”。

它会把已经确认的 PRD、开发说明、测试用例和任务确认单，继续转成：

• 开发分工计划
• RACI 责任矩阵
• todolist.md
• Definition of Done
• 质量门禁
• ADR 建议
• 代码评审清单
• 发布与回滚清单
• 数据库变更、回滚、校验脚本草案

这里有一个边界很重要：涉及数据库变更时，它只生成脚本草案，不直接操作目标数据库。脚本需要 DBA 或数据工程师人工审核和执行。

这不是保守，是工程常识。

AI 很适合帮你把迁移脚本、回滚脚本、校验 SQL 先整理出来，但生产数据的风险不能交给一句“执行吧”。权限越高、影响越大，越需要人工确认。

第三个 Skill 还会把任务拆到可执行层级：负责人、依赖、优先级、关联验收标准、完成标准。也就是说，它不是只给一句“完成开发”，而是逼着任务进入可检查状态。

以前一个项目做到后期，常见对话是：

“你这个做完了吗？”

“差不多了。”

“测了吗？”

“简单测了。”

“能发吗？”

“应该可以。”

这几个词都很危险：差不多、简单、应该。

工程交付需要把它们换成证据：

• 哪些测试跑过？
• 哪些截图或日志能证明？
• 哪些代码经过评审？
• 哪些配置已经确认？
• 回滚方案在哪里？
• 数据库脚本谁审核？
• 未决问题有没有负责人？

交付不是把代码写完，而是把风险关进清单里。

六、为什么它能带来远不止十倍的效率感

我不太愿意把“十倍效率”写成一个可复制承诺。

因为每个人的项目复杂度、历史包袱、技术栈、业务理解都不一样。对一个从零写的小工具，十倍可能不夸张；对一个复杂企业系统，提升可能更多体现在减少返工、减少沟通、减少遗漏，而不是单纯代码速度。

但我确实感到：这套方式带来的效率提升，远远不止“写代码快了十倍”这么简单。

原因有三个。

第一，很多重复判断被固化了。

过去每次做需求，都要重新提醒自己：要问场景、问目标、问边界、问验收、问风险。现在这些问题进入 Skill，AI 会稳定地替你发起检查。

第二，文档之间开始自动接力。

需求分析不是写完就扔，PRD 会继承它；开发说明不是另起炉灶，而是追溯 PRD；测试用例不是凭经验乱列，而是从验收标准和业务逻辑派生；工程任务不是拍脑袋分，而是绑定模块、用例和完成标准。

第三，AI 的执行力被放进了流程里。

单独让 AI 写代码，它可能很快，也可能跑偏。让 AI 按 Skill 工作，它每一步都有输入、输出、边界和自检项。你不是在和一个“聪明但容易发散的助手”聊天，而是在驱动一套可复用的工作程序。

这就是我这段时间最大的体会：

AI Coding 的效率，不来自模型替你想完所有事，而来自你把自己的经验变成了模型可以反复执行的结构。

七、这不是 OPC 神话，而是经验产品化

我没有想成为 OPC。

或者更准确地说，我不想把这件事讲成“一个人取代一整家公司”的故事。

软件交付里仍然需要真实用户、业务评审、技术判断、测试验证、安全边界、上线责任。AI 可以帮你做很多事，但它不应该替你承担所有责任。

我更愿意把这套三大 Skill 看成“经验产品化”。

以前经验存在脑子里：

“这个需求要先问清楚。”

“这个功能要补异常。”

“这个数据变更要有回滚。”

“这个任务要有完成标准。”

现在经验变成了可调用的 Skill：

• 产品经理 Skill 负责把想法变成清晰需求。
• 开发经理和架构师 Skill 负责把需求变成开发说明。
• 研发团队 Skill 负责把开发说明变成可交付计划。

这背后真正改变的不是人数，而是组织方式。

过去，一个小项目想要完整走过产品、架构、开发、测试、发布这些环节，需要很多角色协同。现在，一个有经验的人可以先用 Skill 把这条链路跑起来，再把需要人判断的地方交回给真实团队确认。

这不是取消团队，而是让团队更早看到完整结构。

八、给想尝试的人：先别急着写代码

如果你也想尝试类似的方式，我建议不要从“写一个万能 Coding Skill”开始。

先从三个问题开始：

1. 你过去反复踩过哪些坑？
2. 哪些判断你每次都要重复做？
3. 哪些输出物一旦标准化，就能减少后续返工？

然后再把这些经验拆成 Skill。

一个好的 Skill，不是把提示词写得很长，而是把角色边界、输入输出、工作流程、自检标准写清楚。

比如：

• 产品类 Skill，要知道什么时候先分析，什么时候写 PRD，什么时候标注待确认。
• 技术类 Skill，要知道不能超出 PRD 范围，必须保留需求追溯，必须写异常和测试。
• 交付类 Skill，要知道任务要有负责人、依赖、完成标准，数据库脚本不能直接执行生产环境。

这些东西看起来不酷，但很值钱。

因为真正让 AI 可靠的，往往不是一句神奇提示词，而是一组不允许它乱来的边界。

结尾：把经验交给 AI 之前，先把经验讲清楚

过去一个多月，我对 AI Coding 的理解变了。

一开始，我也会兴奋于“它写得真快”。后来我发现，快只是表层。

更深一层的问题是：你能不能把过去多年积累的判断、流程、边界、检查项，整理成 AI 能执行、你能审核、团队能接住的 Skill。

如果能，AI Coding 就不只是一个代码助手。

它会变成一个工作流放大器。

你不一定要成为 OPC，也不一定要相信一个人能覆盖所有角色。但你可以把自己经历过的角色，沉淀成一套可复用的虚拟协作机制。

这可能才是 Vibe Coding 真正有意思的地方：

不是一个人变成一家公司，而是一个人的经验，第一次可以被结构化地放大。