大家好，我是 lv。
上一篇文章，我们聊了市面上不同 AI Coding 产品的分类、侧重点、优缺点以及面向的人群。
「适合很多公司和团队的 AI Coding 落地范式（一）」
接下来，我们将从上一篇提到的两种产品形态（AI Coding 平台类 & AI Coding 基建类） 来分别探讨适合很多公司和团队的 两种 AI Coding 落地范式：
-
AI Coding 平台工程化
-
AI Coding 基建工程化
不多说，开整～
针对 AI Coding 平台的落地范式
市面上的 AI Coding 平台类产品很多，如 V0、Bolt New、Lovable 等。
这种产品面向的人群大部分都是非程序员，如产品经理、设计师、运营等。
在一个公司和团队内部，我发现大家使用这种产品的主要方式有三种
AI Coding 平台使用现状分析
第一种方式: 产品经理基于 Figma Make 或者 V0 出产品可交互性的原型，主要用来进行需求评审、设计评审、开发评审等，下游还是设计师参考原型进行设计稿的产出。
这种使用方式其实本质上是产品经理自身能力的补充或者说针对产品经理本职工作的提效，当然这种 AI Coding 平台产出的 可交互式原型 相比较于传统的产品原型，可以传递给团队的信息量也会更丰富。
这种方式，在任何公司和团队内部都可以进行尝试，因为它并没有改变原有的工作流程，只是针对产品经理的工作流进行了一定程度的优化。
第二种方式: 需求方（产品、设计师、运营人员）基于 Figma Make 或者 V0 出产品可交互性的原型，满足需求就直接发给开发人员，开发人员基于原型再转成成符合公司规范（技术栈、代码规范等）的代码。
这种使用方式有点意思了，从 AI Coding 平台生成可交互原型 -> 程序员基于原型进行代码的开发。
相当于把常规的：产品 -> 设计师 -> 程序员 的岗位职责进行了一定程度的合并。
产品和设计师合并在了一起，我就暂且叫做 Product Designer，简称 PD。
第三种方式: 需求方（不特指产品经理，可能也是设计师、运营，甚至技术人员等）使用 V0 快速生成一个产品的 MVP，也可以迅速通过 Vercel 平台进行上线。
这种方式对于跟时间赛跑，需要快速验证需求、获得市场反馈的场景来说，倒是挺合适的，当然也仅限于 MVP 验证阶段，对于需要进行长期迭代的项目来说，这种方案可能就不太合适了。
这里的需求方，可以叫做：Product Design Engineer，简称 PDE，Design 和 Engineer 的能力其实是 AI Coding 平台赋予的。
好，先踩一脚，我们来总结一下这三种 AI Coding 平台的使用方式：
第一种，相当于是针对产品经理本身能力的补充，相当于是针对现有产品研发流程中单个角色的提效，但并没有改变原有的产品研发流程。
第二种是需求方使用 AI Coding 平台完完成可交互原型的输出，这个可交互的原型可以直接交付给程序员，相当于把 Product 和 Designer 的岗位合并在了一起，叫做 Product Designer，简称 PD。
第三种是需求方直接使用 AI Coding 平台完成了产品研发的全流程，相当于把 Product、Designer、Engineer 的岗位合并在了一起，叫做 Product Design Engineer，简称 PDE，这是对整体产品研发流程的重塑，但是注意，这种场景仅限于 MVP 验证阶段。
从第一种 -> 第二种 -> 第三种，其实对应了从单个角色的提效 -> 部分研发流程的合并 -> 整体产品研发流程的重塑。
这三种使用方式，大家可以根据自己公司或团队的实际情况，进行选择。
我们回到看似最牛逼的第三种使用方式，我们再思考一下：
第三种使用方式尽管是对整体产品研发流程的重塑，但也仅适用于 MVP 验证阶段，能否在长期迭代的项目中使用呢？
有些场景能，我们接着往下聊。
AI Coding 平台工程化
作为长期迭代的项目来说，势必需要人工的参与，其实最核心的点是：如何保证人工介入的场景下，代码的可维护性，包括：
-
契合团队项目技术栈，比如说 nextjs、react、vue、antd、shadcn、tailwindcss、私有组件库等，大家都能看懂，并且能够快速上手。
-
代码结构规范，比如说组件的文件结构、代码风格等，按照大家日常的开发习惯来。
-
...
那我们的重点，其实就是能够基于 AI Coding 平台，生成符合团队项目技术栈、代码结构规范的代码，从而能够保证代码的可维护性。
我把这个工作叫做 AI Coding 平台工程化。
市面上的 AI Coding 平台，受限于定制化能力（定制符合团队项目技术栈、代码结构规范的代码生成器），私有化能力（在公司内部私有化部署）等。
因此，新轮子来了：Compoder，它代表的就是 AI Coding 平台工程化的产物。
Compoder 是一个 AI 驱动的组件代码生成引擎，可以基于它定制基于特定技术栈（React、Vue、开源组件库、私有组件库）、特定业务场景（landing page 等）的组件代码生成器。
先上案例：Lading Page Codegen（Code Generator）
这个 Code Generator 能够针对用户的需求使用 Nextjs、PageUI（一个构建 LandingPage 的组件库，github.com/danmindru/p... 来生成对应的 Landing Page 代码。
我们使用 Compoder，可以定制这个 Lading Page Codegen 的代码生成规则，从而能够保证代码的可维护性。
- 技术栈定制，如私有组件库定制（pageui 不是很出名，llm 不包含其知识，相当于是 私有组件库 场景）
- 代码规范定制，如组件的文件结构、代码风格等
最终效果，我们从用户的使用视角来看：
- 进入刚刚定制好的 Landing Page Codegen，输入需求，选择合适的模型。
需求是把 Compoder 的 Readme 给了过去（github.com/IamLiuLv/co... 生成 Compoder 本身的 Landing Page 代码。
- 等待代码生成完成，在线查看效果。
从用户的使用角度来看，本身不需要关心代码的生成原理，只需要关心效果是否满意即可，其他的代码生成细节，都交给了 Compoder（AI Coding 平台工程化的产物） 内部来实现。
至于 Compoder 内部实现原理，涉及到很多前端 + AI 相关的知识点，比如 Prompt 设计、Workflow 设计、RAG 理念，怎么基于私有组件生成代码等，怎么实现代码渲染器等等。
本篇就不展开讲了，想深入学习的同学可以看：Compoder 项目介绍
言归正传。
至此，AI Coding 平台化工程搞定，作为需求方（产品、设计师、运营、技术人员）来说，可以基于 Compoder 的 Codegen 快速生成符合团队项目技术栈、代码结构规范的代码，同时还能够保证代码的可维护性。
本着一篇文章把一件事聊透的原则，本篇就先聚焦在 AI Coding 平台化工程这块。
下一篇，我们接着聊 AI Coding 基建工程化。
读后思考：
-
AI Coding 平台化工程的缺点？
-
技术人员自己出了一个产品把自己给干掉了？