AI Coding 搞了快一年，我们开始让业务同学自己做系统了

前段时间，我们一个设计同学突然找到我，说他做了一套系统，想让我帮忙部署一下。

我当时真的有点震惊。

一个做运营素材的设计同学，居然已经能自己做出一套系统了？

我先没有答应部署，而是让他把系统从头到尾讲了一遍。听完以后，我发现它并不是随便拼出来的 Demo，里面已经有了不少完整的业务思考。

这个系统，做得还挺好

这个同学属于 UI 设计组，平时主要负责运营素材设计。他做这套系统，也是从自己每天面对的问题出发的，系统主要包含3部分内容吧。

第一部分是需求管理。

业务提出的设计需求，可以统一进入系统，在里面流转和处理。需求完成以后，对应的素材也会被汇总起来，所以它同时还有一个素材中心的功能，方便后续检索和复用。

第二部分是素材模板。

运营经常会提一些重复性的设计需求。比如固定样式的图标、大促氛围图等，基本上都是整体版式不变，只需要替换标题、字体或者少量内容。以前每次都要重新做，现在可以把这些固定样式沉淀成模板，只要输入变化的文案或占位图就可以直接下载。

有的模板是用代码、文字和 CSS 或 Canvas 实现的绘图，也有的模板会调用 AIGC 的生图工具。

第三部分是工具箱。

里面放了一些设计和运营日常会用到的图片、视频处理工具，比如图片压缩、图片抠图、图片裁剪、视频压缩等。

从解决问题的角度看，这套东西挺实用。它不是为了炫技，而是真的可以减少大量重复工作。

但再往下看，问题也很明显。

系统没有接公司的账号体系，图片上传后保存在本地，AI 设计的技术选项和架构和我们研发体系差异也很大。它还调用了很多本地脚本和工具，其中也有不少能力仍停留在 Demo 阶段。

所以他问我怎么部署时，我一下子不知道该怎么回答。

如果只是看功能，我觉得应该支持他。但如果把它当成正式系统直接放到线上，账号、权限、文件、数据、备份、日志和运行稳定性，几乎每一项都需要重新处理。

AI 编程已经不只是研发的事了

产研团队 AI Coding 已经将近一年的时间了，到现在为止，99% 的代码都已经是 AI 生成的了。所以我们必须承认，代码本身越来越不值钱了。

以前大家觉得写代码是一道很高的门槛。现在这道门槛确实变低了。

产品、设计、运营，甚至完全没有技术背景的同学，都开始尝试用 AI 做一些日常工具、工作流和自动化程序。再往前走一步，他们自然会想到：既然工具能做，那业务系统是不是也能做？

所以今天想聊的，其实不是“业务同学能不能写代码”。这件事已经发生了，也拦不住。

更现实的问题是，在 AI Coding 越来越普遍以后，业务同学参与到什么程度，哪些东西可以自己做，哪些东西要进入正式的工程体系。我们把业务同学参与到 Coding 的方式，大致分成了以下三类。

第一类：个人脚本和离线工具

最简单的一类，是处理本地数据的脚本、工作流和小工具。

它可能读取现有业务系统导出的数据，做一次批处理；也可能做一个 Web 页面，把本地文件整理后可视化；还可能通过浏览器操作现有页面，自动完成一些重复工作。

这类工具主要服务个人或小范围团队，不承担企业级系统的职责。只要不绕过权限、不接触不该接触的数据，也不影响线上系统，我们原则上是允许的。

第二类：业务先把想法做成 Demo

业务同学也可以参与到前置技术调研和需求验证环节了。

比如我们之前做 AI 商品图时，业务同学先用 AI 做了一套能力，把商品图里的模特替换成真人。他们验证了效果，也把核心逻辑跑通，然后把 Demo 交给产研同学，由产研完成最后的工程化改造，并接入现有业务系统。

过去业务提需求，往往只能用文字描述自己想要什么。现在他们不但能提需求，还可以先验证需求有没有价值、技术路线能不能跑通。

这对产研来说其实是好事。大家面对的不再是一份只能靠想象理解的需求，而是一个已经能看到效果的原型。

Demo 可以由业务快速试错，但正式集成仍然由产研负责。

第三类：在现有系统外面做扩展

还有一类，是在正式业务系统之外做外挂能力。

其中比较轻的一种，和业务系统几乎没有数据交换。

比如我们在商品编辑环节，业务希望增加一些强提示和规则校验。我就建议他们做浏览器插件：识别商详页或编辑页已经展示的信息，再给出强提醒或弱提醒。

插件可以和页面发生交互，但不直接读取数据库，也不绕过正式接口修改核心数据。这类扩展对原系统侵入比较小，风险相对可控。

再往前一步，就是业务同学开发一个独立系统。它有自己的页面、流程和数据，也会通过研发提供的接口，与线上业务系统发生真正的数据交互。

这已经是一套正式业务系统了，也是最难划边界的一类。

允许业务自研，不等于做完就能上线

对于业务自研系统这个事，我们大的原则一直是“允许做，技术控制好风险，业务也要自己担责”。

业务同学最懂自己每天在做什么，也最清楚哪些重复工作最浪费时间。现在 AI 把实现门槛降下来，如果还是规定所有想法只能排队等研发，反而是在浪费这种变化带来的机会。

但允许自研，不代表一套功能能跑的代码就可以直接上线。

一个线上系统要长期稳定运行，需要处理的远不只是页面和功能。账号是不是真的可信，用户有没有权限操作这条数据，文件会不会被越权访问，数据库坏了怎么恢复，接口流量突然放大会不会拖垮上游，依赖接口变化以后谁来发现，日志里会不会留下敏感信息，这些都属于工程问题。

AI 的编码能力很强，但它不会自动替一个团队承担这些责任。

所以我们先给业务自研系统划了一个独立的网络环境。在这里不能随意访问线上服务，只能通过统一网关调用部分注册了的业务接口。

哪些接口可以开放，由研发控制；并发、鉴权、数据范围和安全限制，也统一放在网关处理。这样业务系统能够使用线上能力，但不会因为写错一段代码，就直接把风险传到核心系统。

只有网关，还不够

统一网关解决的，只是业务系统能不能访问线上接口。但一个系统从“在自己电脑上能跑”，到真正部署上线，中间还有很长一段路。

技术栈怎么选，项目目录怎么组织，账号和文件怎么接，数据库放在哪里，出了问题怎么看日志，版本怎么发布和回滚，这些问题不会因为有了网关就自动解决。

于是我们在 Zeus、Zeus Studio 和 Zeus Talos 之外，又做了一套专门面向业务自研系统的工作流，叫 Zeus Forge。

它不要求业务同学安装整套 Zeus，也不是再建设一个大平台。它是一个可以全局安装的 Agent 插件，里面包含一组 Forge Skill，以及项目生成、检查和部署工具。

Forge 把工程化拆成几步：设计阶段先用 design 梳理边界，启动时用 create 生成统一技术栈（Go+React）的脚手架，接入时用 connect 绑定账号和文件能力，上线前用 check 做强制检查，最后通过 deploy 锁定版本完成部署。出问题后，diagnose 会结合日志和配置统一排查。

Forge 要补上的，其实就是一个系统从“能跑”到“能上线、能维护”之间的距离。

回到最开始那个设计系统，如果按以前的方式处理，研发可能要先帮他改账号，再改文件存储，再补日志、数据库和部署脚本，最后还要告诉他以后出了问题找谁。做完一遍以后，下一个业务同学再做一套系统，我们还得重新来一遍。

Forge 想解决的，就是别让这些工程问题每次都靠某个研发同学临时帮忙补。

最后

代码变得越来越容易生成，参与编码的人也一定会越来越多。设计、产品、运营不再只是需求的提出者，他们会直接参与验证，甚至做出可以使用的系统。

我觉得我们应该用更开放的心态接受这件事，而不是先想着怎么拦住。

但代码容易生成，不代表线上系统也变得容易了。稳定性、数据安全、权限、备份、接口治理和持续维护，这些不会因为用了最先进的 AI 就自动消失。

所以我们既要让更多人能够写，也要给他们一条安全进入线上系统的通道。

业务负责把真正的问题找出来，把想法快速做出来；平台提供边界、接口和工程规范；核心系统仍然走完整的产研流程。

最后，祝好。