一个国内头部车企 AI Coding 真实案例复盘：热情很重要，但从“本地能跑”到“大家能用”，中间隔着一整套工程化能力。

最近在一个国内头部车企内部，AI Coding 的热情非常高。

很多业务部门、职能部门、数字化团队都在尝试用 AI 写代码、做工具、搭小系统。过去需要找研发排期的事情，现在有些同事通过 AI Coding，几天就能做出一个能演示、能自用的小应用。

这当然是好事。

但最近一个真实案例，也把另一个问题暴露得非常清楚：

一个部门用 AI Coding 做了一个 BPM 类小系统，之前一直跑在本地 PC 上，部门内部自用。后来大家觉得这个系统确实有价值，希望把它部署到服务器上，让更多同事稳定使用。

一开始，很多人以为这只是一次“搬家”：

本地电脑上已经能跑了，放到服务器上，不就是换个地方启动吗？

真正开始迁移后才发现，问题一个接一个冒出来：

• 代码前后端边界不清；
• 数据库地址、配置项大量硬编码；
• SQLite 适合 Demo，但不适合多人服务端使用；
• 后端是 Node.js 技术栈，但缺少 Docker 构建经验；
• 基础镜像、依赖源、企业内网环境、构建平台架构轮番出问题；
• AI 能给建议，但很多关键判断必须人工 Review。

这次实践让我更确定一个判断：

AI Coding 降低了“写代码”的门槛，但没有降低“交付系统”的门槛。

更准确地说：

非技术人员使用 AI Coding，真正要跨越的不是代码门槛，而是工程化门槛。

这篇文章不讨论 AI Coding 的概念，也不做工具测评，只基于这个真实案例，复盘一个非技术人员做出来的小系统，从本地 Demo 走向服务器部署时，真正会遇到哪些问题。

---

一、先说结论：本地能跑，只说明 Demo 成功，不代表系统可交付

AI Coding 最容易制造一种错觉：

页面出来了，按钮能点，数据能保存，这个系统就差不多完成了。

但在软件工程里，“本地能跑”和“系统可交付”是两件完全不同的事情。

本地 Demo 关注的是：

• 页面有没有；
• 流程能不能走；
• 数据能不能保存；
• 自己电脑上能不能启动；
• 演示时有没有明显报错。

而服务器部署关注的是另一套问题：

• 配置能不能迁移；
• 数据库能不能支撑多人使用；
• 依赖能不能稳定安装；
• 镜像能不能重复构建；
• 服务器环境是否匹配；
• 日志、权限、备份、回滚有没有考虑；
• 出错后能不能定位，能不能恢复。

这次案例中，部门自用阶段没有太大问题，因为系统只需要在本地 PC 上跑起来。

但一旦要部署到服务器，让更多人使用，问题就不再是“代码能不能写出来”，而是：

这个系统能不能在一个干净、标准、可维护的环境里稳定运行？

这就是从 Demo 到交付的分水岭。

---

二、这次迁移暴露出的 6 个工程化问题

为了便于复盘，我把这次迁移中的问题归纳成 6 类。

它们不是个别项目的偶然问题，而是非技术人员使用 AI Coding 做系统时非常容易遇到的共性问题。

问题类型	Demo 阶段的表现	部署阶段的后果
架构混乱	能跑就行，前后端边界不清	迁移、排错、扩展都困难
配置硬编码	数据库地址、端口写死	换环境就报错
数据库选型偏 Demo	使用 SQLite 本地文件	多人访问、备份、权限、并发都受限
Docker 构建缺经验	AI 生成 Dockerfile	企业环境中构建失败
依赖源不可控	本地能安装	服务器或 CI/CD 下载失败
平台架构不匹配	本地机器能跑	构建平台拉不到合适镜像

这 6 个问题背后，其实指向同一个核心：

AI 可以帮你生成代码，但不会自动替你建立工程体系。

下面逐个展开。

---

三、第一个坑：代码能跑，但没有架构

这次迁移最先暴露的问题，是代码前后端边界不清，配置项散落在代码里，很多地方是“为了本地跑通”临时补出来的。

典型现象包括：

• 数据库地址直接写在代码中；
• 本地路径写死在业务逻辑里；
• 前端请求地址不可配置；
• 后端服务端口写死；
• 配置没有区分开发环境和生产环境；
• 目录结构看起来能跑，但没有清晰分层。

这类问题在 AI Coding 项目里非常常见。

原因也很简单：非技术人员通常是按照“功能点”驱动 AI 写代码。

例如：

帮我做一个审批页面。
帮我加一个登录功能。
帮我把数据保存下来。
帮我修复这个报错。
帮我再加一个流程配置。

AI 会非常努力地满足当前指令，但如果没有人持续约束整体架构，它就很容易变成“哪里缺，就往哪里补”。

短期看，效率很高。
长期看，系统会越来越难迁移、难维护、难扩展。

一个典型反例：把数据库地址写死

Demo 阶段，为了快速跑通，把数据库地址直接写在代码里，确实很省事。

但到了服务器部署阶段，这会立刻变成问题：开发环境、本地环境、测试环境、生产环境的数据库地址不一样，账号权限也不一样，不可能每换一个环境就改一次代码。

更稳妥的做法，是把这些信息抽成环境变量。

# 错误思路：不要把生产数据库地址、账号密码直接写死在代码中
# const dbUrl = "mysql://user:password@10.0.0.1:3306/bpm"

# 推荐做法：不同环境使用不同环境变量
DATABASE_URL=mysql://<user>:<password>@<db-host>:3306/<database>
APP_PORT=3000
NODE_ENV=production

代码里只读取配置，不关心具体部署在哪台机器：

const databaseUrl = process.env.DATABASE_URL;
const port = process.env.APP_PORT || 3000;

这就是从“本地能跑”走向“可迁移”的第一步。

这里有一个很重要的判断：

非技术人员可以不亲手写每一行代码，但不能完全不理解系统结构。

至少要知道：

• 什么是前端；
• 什么是后端；
• 什么是数据库；
• 什么是配置；
• 什么是环境变量；
• 什么是本地环境；
• 什么是服务器环境；
• 什么是开发环境、测试环境和生产环境。

否则，AI 生成的系统很容易成为一个“本地可用、上线脆弱”的黑盒。

---

四、第二个坑：SQLite 很适合 Demo，但不适合多数部门级系统上线

这次系统最初使用的是 SQLite。

SQLite 不是坏东西。它非常适合：

• 本地 Demo；
• 单机工具；
• 教学项目；
• 快速验证想法；
• 小型原型系统。

但如果一个 BPM 系统要部署到服务器，让部门更多人使用，就必须重新评估数据库方案。

BPM 系统通常意味着：

• 多用户登录；
• 流程数据长期保存；
• 审批记录可追溯；
• 权限和角色管理；
• 多人同时访问；
• 数据备份和恢复；
• 未来可能和其他系统集成。

这时候，继续使用 SQLite 就会有明显隐患。

所以迁移过程中，一个关键动作就是：把数据库从 SQLite 切换到 MySQL 这类更适合服务端部署的数据库。

从配置上看，好像只是改一行地址：

# Demo 阶段：SQLite 通常是一个本地文件
DATABASE_URL=file:./dev.db

# 服务端阶段：更常见的是 MySQL / PostgreSQL 这类服务型数据库
DATABASE_URL=mysql://<user>:<password>@<mysql-host>:3306/<database>

但实际工作远不止“改一行配置”。

如果项目使用 ORM，可以把 ORM 简单理解为“代码和数据库之间的翻译层”。切换数据库后，通常还要重新生成数据库客户端、执行迁移脚本、验证表结构和初始化数据。

# 示例命令，具体以项目技术栈为准
npm install
npx prisma generate
npx prisma migrate deploy

真正麻烦的是，非技术人员一旦遇到报错，很难判断问题到底在哪里：

• 是数据库没启动？
• 是数据库地址不对？
• 是账号密码错误？
• 是端口没开放？
• 是表结构没同步？
• 是 ORM 没生成？
• 还是容器网络不通？

AI 可以帮你解释报错、分析原因、给出修改建议。

但最终仍然需要人判断：

这个建议是否适合当前环境？是否符合企业部署规范？是否会带来新的风险？

这就是 AI Coding 的现实边界：

AI 可以给答案，但使用者必须具备判断答案是否靠谱的基本能力。

---

五、第三个坑：Docker 不是一句“帮我生成 Dockerfile”就结束了

为了把系统部署到服务器，后端需要构建 Docker 镜像。

对于技术人员来说，Docker 是日常工具。
但对非技术人员来说，Docker 往往是第一次真正接触“工程化部署”。

Dockerfile 可以简单理解为：

一份告诉服务器“如何打包、安装依赖、构建项目、启动服务”的说明书。

AI 可以生成 Dockerfile，也可以解释每一行的作用。

但真实构建时，问题不会因为 Dockerfile 是 AI 写的就自动消失。

脱敏后，一个 Node.js 后端项目的多阶段构建大概长这样：

# 示例：脱敏后的 Node.js 后端多阶段构建
FROM node:20-alpine AS builder

WORKDIR /app

# 先复制依赖声明，利用 Docker 缓存提升构建速度
COPY package*.json ./

# 企业环境中通常需要替换为内部 npm 源
ARG NPM_REGISTRY=https://<internal-npm-registry>/
RUN npm config set registry ${NPM_REGISTRY} \
    && npm ci

COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/node_modules ./node_modules

EXPOSE 3000
CMD ["node", "dist/main.js"]

这段代码看起来不复杂，但到了企业环境里，任何一个环节都可能失败。

这次实践中的真实过程并不是“一次生成，一次成功”，而是：

1. 先让 AI 分析项目结构；
2. 让 AI 生成初版 Dockerfile；
3. 手工调整基础镜像；
4. 根据构建日志一点点排错；
5. 调整 Node.js 版本；
6. 切换企业内部依赖源；
7. 处理特殊依赖下载问题；
8. 再构建；
9. 再失败；
10. 再定位；
11. 再修改。

这才是真实的工程现场。

很多对 AI Coding 的宣传会让人误以为：

输入需求，系统自动生成。
不会代码，也能一键上线。
人人都是程序员。

但实际更接近：

AI 可以显著加快排查速度，但不会替你承担工程复杂度。

尤其在企业环境中，部署问题往往不是代码本身的问题，而是环境、网络、依赖、权限、安全策略、基础镜像、构建工具共同作用的结果。

---

六、第四个坑：版本不是越新越好，能稳定构建才重要

在这次构建中，后端最初使用了较新的 Node.js 版本。

从直觉上看，新版本似乎更先进。
但在企业生产环境里，“新”不一定等于“稳”。

企业内部往往有自己的限制：

• 基础镜像是否已经纳入内网仓库；
• 是否经过安全扫描；
• 依赖源是否完整同步；
• 构建工具是否支持；
• 运行环境是否验证过；
• 是否有历史项目使用经验。

所以，生产环境更重视的是：稳定性、兼容性、可重复构建。

一个典型错误是盲目使用 latest：

# 不建议在生产环境中盲目使用 latest
FROM node:latest

更稳妥的方式，是固定一个经过验证的版本：

# 更稳妥：固定主版本，必要时进一步固定镜像摘要
FROM node:20-alpine

如果企业内部已经沉淀了统一基础镜像，应优先使用经过验证的内部镜像：

# 示例：脱敏后的企业内部基础镜像
FROM <internal-registry>/base/node:20-alpine

这个问题对非技术人员来说并不直观。

AI 可能会默认推荐较新的版本；文档也可能鼓励使用新版本。但企业内部环境未必支持。

所以部署阶段不要只问：

这个技术是不是最新？

而要问：

• 这个版本在我们的环境里能稳定构建吗？
• 企业内网镜像仓库里是否存在？
• 依赖源能否访问？
• CI/CD 能否跑通？
• 上线后是否容易维护？

这是从“写代码思维”进入“工程交付思维”的关键转变。

---

七、第五个坑：依赖下载失败，是企业部署中的高频难题

这次迁移过程中，另一个典型问题是依赖下载失败。

从表面看，报错可能只是：

• 某个依赖包下载失败；
• 某个校验文件不存在；
• 某个二进制文件 404；
• 某个镜像源无法访问。

但背后原因可能非常复杂：

• 公共网络不可访问；
• 企业内网源没有同步完整；
• 某些工具安装时会额外下载二进制文件；
• 不同操作系统需要不同构建产物；
• 不同 CPU 架构需要不同文件；
• 安全策略拦截外部请求；
• 本地能访问，不代表 CI/CD 构建环境能访问。

这类问题对非技术人员非常不友好，因为它不像页面问题那样直观。

页面错了，还能看到。
按钮不动，还能描述。
但依赖下载失败，通常只剩下一堆英文日志。

这时候，AI 的价值很明显。

它可以帮助：

• 翻译错误日志；
• 找出关键报错；
• 判断可能原因；
• 搜索替代配置；
• 修改 Dockerfile；
• 给出排查路径。

但要注意：有些依赖并不只走 npm registry，还会额外下载平台相关的二进制文件。这类下载链路经常被非技术人员忽略。

脱敏后，可以理解为需要为特殊依赖指定可访问的镜像源：

# 示例：为特殊依赖指定可访问的镜像源
ARG TOOL_BINARY_MIRROR=https://<internal-mirror>/<tool-binaries>
ENV TOOL_BINARY_MIRROR=${TOOL_BINARY_MIRROR}

RUN npm ci

也可以在构建命令里明确传入参数：

docker build \
  --build-arg NPM_REGISTRY=https://<internal-npm-registry>/ \
  --build-arg TOOL_BINARY_MIRROR=https://<internal-mirror>/<tool-binaries> \
  -t bpm-server:latest .

这类配置不是业务功能，但它决定系统能不能被构建出来。

所以这里有一个非常关键的实践判断：

AI 是很好的副驾驶，但不是完全自动驾驶。

它能帮你更快找到路，但你仍然要判断这条路能不能在企业环境里走通。

---

八、第六个坑：平台架构不匹配，很多非技术人员根本意识不到

这次迁移中还有一个更隐蔽的问题：基础镜像架构不匹配。

简单说，同一个镜像名，并不代表它在所有机器、所有构建平台上都能正常使用。

这里涉及几个概念：

• amd64：常见的 x86 服务器架构；
• arm64：很多新设备和部分服务器使用的架构；
• platform：构建目标平台；
• digest：镜像内容的唯一指纹，可以用来固定镜像版本。

非技术人员很容易困惑：

为什么本地能构建，服务器不能构建？
为什么 Mac 上能跑，CI 里失败？
为什么同一个镜像名，有的地方能拉，有的地方不能拉？

这往往不是“代码写错了”，而是构建平台、基础镜像、镜像仓库之间不匹配。

常见解决方式包括：

• 指定构建平台；
• 固定基础镜像版本或摘要；
• 更换支持目标架构的镜像；
• 调整企业构建工具配置；
• 使用内部已验证的基础镜像。

例如，在构建时显式指定目标平台：

# 示例：指定构建 linux/amd64 平台镜像
docker buildx build \
  --platform linux/amd64 \
  -t bpm-server:latest .

在 Dockerfile 中，也可以对基础镜像做平台约束：

# 示例：脱敏后的平台指定方式
FROM --platform=linux/amd64 node:20-alpine AS builder

如果使用企业 CI/CD 或 Kaniko 这类构建环境，还要结合企业内部镜像仓库和构建器配置一起排查。

这类问题再次说明：

AI Coding 的难点不是“生成代码”，而是让代码在真实环境里稳定运行。

---

九、非技术人员真正缺的不是写代码能力，而是工程判断力

这次实践给我的最大感受是：

非技术人员使用 AI Coding，最缺的不是写代码能力，而是工程判断力。

AI 已经显著降低了写代码门槛。很多过去只有程序员能做的事情，现在业务人员也可以通过 AI 参与。

但只要系统要给更多人使用，就绕不开工程判断。

至少包括 5 类能力。

1. 系统拆解能力

你要知道一个 Web 系统通常由哪些部分组成：

• 前端；
• 后端；
• 数据库；
• 配置；
• 文件存储；
• 权限；
• 日志；
• 部署环境；
• 网络访问；
• 第三方服务。

如果你不知道系统由什么组成，就很难判断 AI 改的是哪一层。

2. 问题定位能力

系统报错时，要能初步判断：

• 是前端问题？
• 是后端问题？
• 是数据库问题？
• 是依赖问题？
• 是镜像问题？
• 是网络问题？
• 是权限问题？
• 是配置问题？

非技术人员不需要立刻成为工程师，但至少要有“分层排查”的意识。

3. 配置管理能力

很多项目本地能跑、服务器跑不起来，本质上都是配置问题。

比如：

• 数据库地址；
• 服务端口；
• 账号密码；
• API 地址；
• 环境变量；
• 依赖源；
• 镜像源；
• 构建参数。

AI 可以帮你改配置，但你要知道哪些配置不能写死，哪些配置不能泄露，哪些配置必须根据环境变化。

4. 部署理解能力

只会本地启动，不等于会部署。

部署至少涉及：

• 服务器环境；
• 容器；
• 镜像；
• 端口；
• 网络；
• 日志；
• 启动命令；
• 数据库连接；
• 数据持久化；
• 版本回滚。

AI Coding 项目一旦进入部署阶段，就进入了真正的软件工程阶段。

5. 风险意识

非技术人员用 AI Coding 最容易忽略风险。

比如：

• 代码能跑，但安全性不足；
• 功能可用，但权限设计混乱；
• 数据能保存，但没有备份；
• 接口能访问，但没有鉴权；
• 配置能连通，但密钥写死；
• 部署成功，但没有监控；
• 系统上线，但没人知道怎么回滚。

这些问题，AI 不一定会主动提醒。

如果使用者没有风险意识，AI 生成的系统可能只是“看起来可用”。

---

十、这次案例之后，我建议所有 AI Coding 项目上线前先做这 10 项检查

如果这篇文章只能带走一个工具，我建议带走下面这份清单。

它不复杂，但非常实用。

非技术人员 AI Coding 项目上线前 10 问

1. 系统是否仍然依赖本地文件、本地路径或本地数据库？
2. 数据库是否还是 SQLite？如果是，是否真的适合多人使用？
3. 数据库地址、账号、密码是否写死在代码里？
4. 前端 API 地址、后端端口是否可以通过环境变量配置？
5. Dockerfile 是否能在一台干净机器上重新构建成功？
6. npm、pip、Prisma 等依赖源在企业网络内是否可访问？
7. 基础镜像是否来自可信仓库，是否支持目标服务器架构？
8. 系统是否有基本日志，出错后能否定位问题？
9. 数据是否有备份方案，升级失败是否能回滚？
10. 关键配置、权限、数据库、部署脚本是否经过技术人员 Review？

这 10 个问题，基本可以帮助非技术人员判断一个 AI Coding 项目是否还停留在 Demo 阶段。

如果其中有 3 个以上回答不清楚，就不建议直接给更多人使用。

---

十一、和 AI 协作时，不要只让它“改好”，要让它帮你解释和排查

非技术人员使用 AI Coding，一个常见误区是只下达结果型指令：

帮我修好。
帮我改成能部署。
帮我生成 Dockerfile。
帮我解决这个报错。

这些指令不是不能用，但风险是：你可能得到一段能运行的代码，却没有理解它为什么这样改。

更好的提问方式，是让 AI 同时输出“判断过程”。

推荐提问模板 1：让 AI 分层定位问题

请你不要直接修改代码，先帮我判断这个报错可能属于哪一层问题：
1. 前端
2. 后端
3. 数据库
4. 依赖安装
5. Docker 构建
6. 网络或权限

请按可能性排序，并说明每一种可能如何验证。

推荐提问模板 2：让 AI 检查部署风险

这个项目本地已经能运行，现在准备部署到服务器。
请你从生产部署角度检查风险，包括：
- 配置是否硬编码
- 数据库是否适合多人使用
- 是否需要环境变量
- Dockerfile 是否合理
- 依赖源是否可能失败
- 是否存在安全隐患
- 是否需要人工 Review

推荐提问模板 3：让 AI 解释 Dockerfile

请逐行解释这个 Dockerfile 的作用。
同时指出：
1. 哪些地方可能在企业内网构建失败；
2. 哪些配置应该改成环境变量；
3. 哪些地方不适合生产环境；
4. 如何验证构建产物是否正确。

这类提问的价值在于：

不是让 AI 替你做完，而是让 AI 帮你建立判断力。

这才是非技术人员使用 AI Coding 最重要的能力升级。

---

十二、关键节点必须人工 Review，尤其是在企业环境里

这次案例里，AI 确实发挥了很大作用。

它帮助我们：

• 分析已有代码结构；
• 识别硬编码问题；
• 辅助重构数据库连接；
• 生成 Dockerfile；
• 解释构建日志；
• 搜索依赖下载问题；
• 推荐替代配置；
• 提升排查效率。

但越到后面，越能看到 AI 的边界。

尤其在企业环境里，有些判断不能完全交给 AI：

• 这个内部镜像源是否合规？
• 这个基础镜像是否经过安全扫描？
• 这个数据库权限是否过大？
• 这个环境变量是否包含敏感信息？
• 这个 workaround 是否只是绕过校验？
• 这个系统是否具备上线条件？

所以，我建议非技术人员做 AI Coding 项目时，至少在这些节点引入技术 Review：

Review 节点	为什么重要
数据库设计	决定数据结构、性能和可维护性
权限设计	防止越权访问和数据泄露
登录鉴权	决定系统是否安全可控
环境变量和密钥	防止敏感信息进入代码仓库
Dockerfile	决定系统能否稳定构建和部署
依赖源和基础镜像	决定供应链安全和构建稳定性
部署脚本	决定上线过程是否可重复
数据备份	决定出问题后能否恢复
回滚方案	决定上线失败后能否止损

非技术人员可以用 AI Coding 推动创新，但不要把所有风险都交给 AI。

---

十三、AI Coding 的正确定位：不是替代技术，而是放大能力

我并不否定 AI Coding。

恰恰相反，这次案例说明，AI Coding 的价值非常大。

如果没有 AI，一个非技术部门很难这么快做出一个可用的小系统，也很难独立推进到服务器部署阶段。

AI 的价值在于：

• 让业务人员可以把想法快速变成原型；
• 让非技术人员能参与系统建设；
• 让很多过去卡在代码层面的想法有机会落地；
• 让排错、解释、重构、学习的效率显著提升。

但这不意味着 AI Coding 可以消灭软件工程。

更准确地说：

AI Coding 把“不会写代码”的问题变小了，但把“是否理解工程”的问题放大了。

以前非技术人员卡在第一步：代码写不出来。

现在 AI 帮你跨过了第一步，于是你会更快遇到第二步、第三步、第四步：

• 架构问题；
• 数据库问题；
• 部署问题；
• 依赖问题；
• 网络问题；
• 安全问题；
• 运维问题；
• 协作问题。

这不是坏事。

这说明 AI Coding 正在让更多人真正接触软件开发的全链路。

但我们也必须承认：

从“做出 Demo”到“交付系统”，中间隔着一整套工程体系。

---

十四、给正在实践 AI Coding 的非技术人员 5 条建议

如果你是非技术背景，正在尝试用 AI Coding 做应用，我建议不要一开始就追求“大而全”。

第一，先做小系统，不要一上来做复杂平台

从单点工具开始，比如：

• 表单收集；
• 数据看板；
• 审批小流程；
• 内部查询工具；
• 自动化脚本；
• 简单管理后台。

系统越小，越容易理解全链路。

第二，尽早区分 Demo 和生产系统

本地能跑，只能说明 Demo 成功。

如果要给别人使用，你还要继续考虑：

• 数据库；
• 权限；
• 部署；
• 备份；
• 日志；
• 安全；
• 异常处理；
• 性能；
• 维护。

第三，让 AI 解释代码，而不只是生成代码

不要只问“帮我改好”。

要多问：

• 这个报错是什么意思？
• 这个配置为什么要这样写？
• 还有哪些风险？
• 如果部署到服务器，需要注意什么？
• 这个方案适合生产环境吗？
• 有没有更稳妥的做法？

第四，建立自己的问题清单

每次踩坑都记录下来。

比如：

• 本地环境问题；
• 数据库迁移问题；
• Docker 构建问题；
• 依赖源问题；
• 镜像架构问题；
• 服务器端口问题；
• 环境变量问题；
• 日志排查问题。

这些记录会变成下一次项目的工程资产。

第五，关键节点一定要找技术人员 Review

AI 可以辅助，但关键节点不能完全依赖 AI。

尤其是：

• 数据库；
• 权限；
• 登录；
• 密钥；
• Dockerfile；
• 部署脚本；
• 数据备份；
• 安全策略。

非技术人员可以用 AI Coding 推动创新，但需要工程护栏。

---

十五、结语：非技术人员 AI Coding 的路很长，但值得走

这次 BPM 系统从本地 PC 迁移到服务器的实践，让我对 AI Coding 有了更现实的判断。

它不是神话，也不是玩具。

它确实能让非技术人员做出过去做不出来的东西。
它也确实会让非技术人员更快撞上真实工程的墙。

但这堵墙不是坏事。

因为真正的软件开发，本来就不只是写代码。

它包括需求理解、系统设计、数据建模、配置管理、依赖管理、构建部署、日志排查、安全控制、持续维护。

AI Coding 改变的是入口，不是终点。

对于非技术人员来说，未来最有价值的能力，可能不是亲手写出每一行代码，而是能够和 AI 一起完成这几件事：

• 把需求说清楚；
• 把系统拆明白；
• 把问题问准确；
• 把风险识别出来；
• 把 AI 的答案判断清楚；
• 把 Demo 一步步推向可交付系统。

所以，非技术人员使用 AI Coding 的路确实很遥远。

但这条路不是“从零变成程序员”的路。

更像是：

从业务使用者，走向 AI 时代的系统创造者。

AI Coding 让非技术人员第一次真正站到了软件开发的入口。

但入口不是终点。

从 Demo 到交付，隔着的不是几行代码，而是一整套工程判断力。

这也是非技术人员使用 AI Coding 最漫长、也最值得走的一段路。