最近有几个非技术部门的同事，vibe coding 他们部门内部用的项目给到技术部部署，因为楼主兼顾运维工作，每次都被这些项目折腾得够呛。
一开始为了方便部署，叫他们让 Codex 生成 docker compose 部署的方式，发压缩包给我，部署和更新我这边直接 up 即可，更新了几次慢慢发现，更新频率高，整个项目对楼主来说就是个黑盒，每次更新都要把 AI 的部署文档给捋一遍，我得先和项目作者沟通，项目作者又要和 Codex 沟通，最后也没搞成很好的部署方式……最近被这几个项目折腾得头疼不已。
有个更新频率很高的项目，我直接创建服务器用户做限制让他用 Codex ssh 进去更新，虽然那服务器没什么东西，但这种直接给 ssh 权限的做法好像不太妥当。
大家有没有遇到过类似的情况？这种项目一般怎么搞比较好？😂
 |
nelloshaw7713Aug 10 via Android
1
直接给他们开几台机器，让他们用 AI 自己部署就好了
|
 |
horizonAug 10
2
你给配好项目模板，写好 SKILL 之类的
|
 |
3
@nelloshaw7713 开服务器又有成本了🤷♂️
|
 |
OutOfMemeryAug 10
4
开个代码仓库，代码更新后 jenkins 点一下？每次更新不只是代码更新？
|
 |
fish2050Aug 10
5
1panel 开用户让他们自己更新
|
|
6
@OutOfMemery 好像也行，相当于接入 cicd 了
|
 |
darkengineAug 10
7
你 vibe coding 一个控制面板给他们自己搞咯
|
 |
8
开一个 Docker 容器给他们当"机器"，把他们隔离起来。
|
 |
goodrybAug 10
9
CICD + K8S 可以是试试，如果不是容器，起码也得有个 Jenkins
|
 |
zoofyAug 10
10
CICD 就好了，阿里云云效、腾讯 coding 那种
|
 |
zengxsAug 10
11
k8s 直接给他们开个固定池的操作权限，让他们自己去用 codex 折腾
共享 worker 节点池，资源不够了直接扩节点，这样你最省心 |
 |
MrBearinAug 10
12
给独立的机器, 让他自己搞
|
 |
FrankAdlerAug 10 via Android
14
你定义好一套部署方式，写成 skill ，让他们喂给自己的 ai ，让他们按这个标准来，比如 docker 不就是定义 env port volume entry ，你得让他们适配你，不然就拒绝
|
 |
r6cbAug 10
15
docker compose 怎么还要管部署文档的事情？不是 cd 进文件夹一条 docker compose up -d 就完成了？黑盒有什么不好的，你调用 sdk 和 api 不也是当成黑盒用？
|
 |
dummyxAug 10
17
我们开了个新的 k8s 集群，内部有个基建平台，用户上来创建项目自动给他开 namespace/资源限制/harbor credentials 等等。用户本地安装必须的几个 skills ，skills 读用户在基建平台的 apikey 按需去请求 k8s 的 kubeconfig 和 docker bot 的凭证，然后 skill 里边规范 docker build/push ，k8s 部署和调试等等。。。
|
 |
kekxvAug 10 via iPhone
18
gitea + gitea actions
|
 |
riscvAug 10 via Android
19
让 ai 自己部署啊
|
 |
lujiaosamaAug 10
20
没有 GIT 仓库，没有 CICD? 项目可以野鸡，流程不能野鸡。
|
 |
zhengfan2016Aug 10 via Android
21
服务器搞个 vm 虚拟机，开一个虚拟的 linux 机器，让他们自己折腾，弄坏了也不影响宿主机
 |
 |
isbaseAug 10 via iPad
22
1. 玩具项目：让他们部署到自己电脑上，或者在公司内网部署一台机器，自己玩玩得了。
2. 生产项目：对稳定性等各种有要求的，最好就拒绝掉。 3. 需求持续较多的：走平台化、服务化的方向。你制定好平台和准入规则，让他们反过来适配你就好了。你只需要确保提供的平台和服务是标准化的，自身稳的就行了。 |
 |
OceanhimeAug 10
23
部署一个 Gitea 和 Portainer
每个项目开一个 git repository, 发版就让 Codex 自行 commit & push. 和 AI 说好部署环境是全自动的, 有任何步骤全部放到 docker-compose.yml 和 Dockerfile 里面. 最后 Gitea 创建一个 push webhook, 搭配上 Portainer 的自动 Git 部署, 完全可以做到发版后全自动部署, 无需人工干预. 目前我对一些 AI 的小项目是这一套流程. |
 |
SmilehAug 10
24
我差点以为是我同事 运维
|
 |
COWAug 10
25
思路错了，你应该想办法定义标准，而不是执行。先让研发把构建、测试、打包、部署的命令和你拉通对齐，产出的内容要落地到 CI/CD 平台工作流配置里，研发后面只需要上传源码 + 配置环境变量就好了，没跑通让他看日志自己查。
|
 |
ktyangAug 10
26
我都是给服务器，控制好了权限剩下的让它自己自生自灭吧，反正这种情况我都坚持谁拉的谁埋。做不到就不要让他们 vibe coding ，服务器才几个钱，瞎耽误几天功夫什么都出来了，我还不信他们能直接搞出来需要大集群才能跑的东西。
|
 |
nerevea1313Aug 10
27
你来制定标准，可以给他们基础开发套件+Skills ，这样双方都省事
|
 |
prosgtsrAug 10
28
让他们自己部署
|
 |
yjieflAug 10
29
让 ai 写个安装说明/标准/规范就好啦
|
 |
docxAug 10 via iPhone
30
搭个 dokploy 之类的 paas 面板让他们自己部署，权限管控好
|
 |
wowhAug 10
31
写一个 skill 里面介绍如何打包如何部署，比如我这边是 jenkins 打包，k8s 部署，然后让 gpt luna 执行下就行
|
 |
nicefrpAug 10
32
直接让他们的在他们的本地电脑部署，然后内网穿透，炸鸡也是炸他的自己的鸡。
|
 |
lookenghuaAug 10
33
@r6cb 端口冲突不是很正常的事情嘛,都把 3306 暴露出来
|
 |
lschoAug 10
34
存代码库自动触发流水线啊
|
 |
lveyeAug 10
35
感觉这个需求 jenkins 可以很好的满足吧，配置下 pipeline ，之后每次自己点击一下就可以部署发布了
|
 |
36
永远要拉满 sol high 提高模型能力
|
 |
37
你一开始就不该接这活。下次遇到，你第一件事就是划清界限：非技术部门员工自己开发的工具，技术部门不接纳也不承担任何责任，特别是安全方面的。
|
 |
SingeeKingAug 11 via iPhone
38
|
 |
TinkAug 11 via iPhone
39
我们是 AI 自己部署的
|
 |
40
AI 产物谁污染谁治理，谁 vibe 谁维护。
如果是内网玩具项目，开个虚拟机做好快照和权限隔离，让他们自己先在本机弄好 docker compose 再给你部署。 但要是上生产或者外部访问，那就让他们申请单开一台服务器，成本是公司的事情不是运维的事情。权限放开，让他们自己上去搞，吃过亏之后就不会来麻烦你了。 |
 |
hafuhafuAug 11
41
让他们自己申请个新的服务器自己维护项目自己全权负责，顺便把给他们服务器和核心服务器隔离了。
|
 |
ExxfireAug 11
42
他们都用 AI 做项目了，你干吗不用 AI 部署呢？
|
 |
LoNeZAug 11
43
给他们一个单独的机器... 随便玩就行了, 弄挂了自己修.
|
 |
killva4624Aug 11
44
已经是 AI 时代了，测试环境可以单独给他们一个机器或者 namespace 集群，让他们自己折腾开发。
生产环境要直接按标准产物交付，如二进制包（含执行|卸载脚本、systemd 文件），或者容器镜像。 硬气一点，你如果兼顾运维工作，要对线上环境负责，就要有这个话语权。 |
 |
47
开个 namespace 把 kubectl 的 config 给到他们，其他的让他们问 codex 就行了
|
 |
lyxxxh2Aug 11
48
买台￥ 99 服务器呗,然后创建一个 skill 。
如何在 ssh 执行服务器命令,把全部权限交给他们。 不然: 1. 我 xx 出问题了,但是看不了,你帮我看下呗。 2. 我改了代码,提交不上去 ... 有问题就找你。 |
 |
kamilicAug 11
49
纯 web 的话参考下 vercel 咯，其实到头来就是基于 k8s 那套来封装了。
|
 |
edgeedgeAug 11 via iPhone
50
推荐用我这个工具： https://swaw.com/zh/p/ssh-remote-kit-windows/
配置好免密 ssh 命令入口，开个非管理员账号给对方的 codex 去折腾，门槛算是最低了 |
 |
itbunanAug 12
51
你也用 codex 部署不就行了吗，运维也要学会使用大模型
|
1
Select Language