企业官网建设流程全解析

从十年前铆足劲做一款 App，到后来想在 App 里加个字段都要等排期，这中间的落差只有经历过的人最清楚。很多非技术出身的人以为“改 App”只是把文案改一改，实际上一次小的界面调整背后是原型图变更、前端样式调整、接口联调、发版审核一整套流程。正因为如此，绝大多数定制类 App 做完第一版之后，基本就冻结迭代了。

今天这篇博客想讨论一个更本质的变化：AI 加入之后，“定制开发”的成本模型已经被重新改写。十年前那种“每接一单，都要把开发流程完整重来一遍”的模式，正在被“描述需求 + 生成代码 + 人工验收”的新模式替代。你能看懂代码与否仍然重要，但它从“必须掌握的入场券”变成了“验证 AI 产物的验收能力”。

这个判断如果成立，那么对独立开发者、小团队，甚至产品经理来说，都意味着一个可操作的机会：你完全可以基于一套模板，用 AI 快速改造成属于自己的、可运行的 App。这篇文章不会停留在概念层面，我会用一个订单管理 App 的完整案例，带你把“硬编码页面改成接口驱动页面”的全过程跑通，并给出常见问题与工程建议。

1. 这篇文章真正要解决的问题

先说结论：AI 在 App 开发里最有价值的应用场景，不是“从零生成一个全新 App”，而是“在一套可运行的基础上，让需求修改的成本趋近于零”。

很多读者可能已经见过类似演示：输入一句话，AI 生成一个可以运行的网页。这类演示看多了，很容易产生一个错觉——AI 已经能替代程序员了。但如果真到生产环境，就会发现 AI 生成的代码往往需要二次修改、需要接真实接口、需要适配业务权限，这些工作才是大头。

这篇文章要解决的是三个实际问题：

• 为什么过去定制一个 App 或改一个 App 的功能那么贵、那么慢？
• AI 究竟在哪些环节真正降低了成本，哪些环节仍然需要人来做决策？
• 对于一个非核心开发者，怎么用现有的 AI 工具链，把一套模板改造成自己业务里能用的 App？

第三个问题会落到实操。我会选择 React Native（Expo）技术栈作为示例载体，因为它跨平台、开发者基数大、AI 生成代码的命中率也比较高。但技术栈不是重点，重点是“需求描述、代码承接、接口接通、结果验证”这条完整闭环。

2. 10年前App创业卡在哪：定制成本居高不下

2010 年前后，移动互联网创业进入爆发期，大量垂直领域的 App 定制需求被创造出来。当时的市场结构是这样的：行业客户想要一个属于自己业务的 App，市场上的供给方则是做外包的技术团队。

这个模式本身没有问题，问题出在“每一单都是全新项目”。无论客户是做餐饮、做培训还是做批发，底层的登录、列表、表单、权限管理、消息推送几乎都一样，但每一家公司都要求自己的页面风格、字段结构、业务流程。结果就是：同一个团队接了十个客户，就要维护十套几乎完全不同的代码库。

那时候的核心成本有三块：

• 需求翻译成本：客户用业务语言描述需求，开发人员要把它翻译成原型图、数据库表、接口定义。
• UI 与业务接入成本：每个页面的样式需要反复调整，每个字段的校验逻辑需要单独编写。
• 维护与修改成本：客户提一个修改需求，改动代码、回归测试、重新发版，每一步都消耗人力。

这三个成本合在一起，导致垂直 App 外包成了典型的“规模不经济”生意。单子越多，团队越累，利润反而越薄。

后来这个市场被两类产品挤压：一类是标准化 SaaS，它砍掉了定制化，用通用功能满足大部分需求；另一类是小程序生态，它让极轻量的业务可以在微信里直接跑起来，不再需要独立 App 的开发、审核、分发成本。

但注意，这两类方案都是“用牺牲个性化换成本”。如果你的业务确实需要特殊的字段结构、特殊的审批流、特殊的界面表达，SaaS 和小程序反而会成为瓶颈。这个“中间地带”，恰好是 AI 现在有机会重新激活的市场。

3. AI如何重建App开发的成本模型

要理解 AI 对 App 开发的影响，不能只看“它能自动写代码”这一个表象。我们需要拆开两层来看：表达层和逻辑层。

表达层解决的是“需求长什么样”。在过去，客户不能在开发初期直观看到最终界面，必须等原型图、设计稿、甚至第一版可运行 Demo。AI 不一样，当你输入一段需求描述，它能立刻返回一段可渲染的页面代码，或者生成一张接近成品的界面图。需求翻译成本被压缩到了一个对话周期内。

逻辑层解决的是“数据和规则从哪来”。AI 生成的首版页面往往是硬编码的，这是它的弱点，也是它的切入点。真正有用的 AI 辅助开发流程，不是让 AI 一次性交出完整系统，而是让它完成两件小事：把页面骨架生成出来，然后在你提示“接上接口”时，把数据获取逻辑替换进去。

这里给出一个成本对比表：

这张表的关键洞察是：AI 没有消灭人工，但它把“按人天计的开发成本”变成了“按提示词次数计的修改成本”。边际成本大幅下降，意味着过去不值得做的个性化需求，现在开始变得值得做。

4. 当前主流技术路径怎么选

如果你想从今天开始实践“用 AI 改自己的 App”，第一步是选对工具链。当前主流路径可以分成四类。

第一类：AI 编程助手，代表是 GitHub Copilot、Cursor、Trae、通义灵码等。它们嵌在 IDE 里，能补全代码、解释代码、支持对话式修改。适合已经有项目基础、需要持续迭代的开发者。它解决的不是“从零开始”，而是“在上下文里快速修改”。

第二类：AI 生成式原型工具，代表是 v0.dev、Bolt.new 这类。输入需求直接生成前端页面或全栈原型。它的问题是生成的代码不一定能直接进入你的工程目录，更多用于验证想法、生成初始版本。

第三类：低代码平台结合 AI，代表是各种低代码平台的 AI 生成能力。平台自带数据库表、表单、权限、审批流，AI 负责把业务描述转换成平台配置。适合不上复杂逻辑、希望 UI 也由平台托管的小团队。

第四类：自建 Agent 工作流，用 LangChain 或开源 Agent 框架定义角色、拆分任务，把需求文本自动转成代码合入仓库。这条路定制化程度最高，但也要求你有工程化能力，不适合刚入门。

从大多数人的实际情况看，我建议的顺序是：原型工具快速出稿，AI 编程助手接管真实项目代码，低代码平台作为备选。如果你已经有一个模板工程，直接进入第二类 + 第一类的组合：让 AI 理解你当前的代码结构，再按业务需求修改它。

5. 最小可改造App落地流程

为了不空谈，这里用一个非常常见的业务场景做例子：门店订单管理 App。你有一批门店，每个门店有订单数据。现在要做的事是，把一个硬编码了订单列表的 React Native 页面，改造成从接口读取数据的页面。

整套流程分成五步：

1. 环境准备：安装 Node.js LTS，准备一个可用的代码编辑器，推荐 VS Code 并安装 AI 插件。
2. 创建骨架项目：用 Expo 创建 React Native 项目，先保证它能在模拟器或真机上跑起来。
3. 生成首版页面：把需求描述发给 AI，让它生成一个静态订单列表页。
4. 提出改造需求：把“改成接口驱动”的需求继续发给 AI，让它补上请求逻辑。
5. 联调验证：启动本地 Mock 服务，让前端请求真实接口，观察列表渲染结果。

为什么是 React Native 而不是 Flutter？没有绝对原因。AI 在 JavaScript/TypeScript 生态上的训练数据更多，生成代码的命中率相对更高。另外 Expo 脚手架让“跑起来”这件事变得非常简单，对一个想快速验证思路的团队来说，启动成本低很多。

需要说明的是，这里使用的版本不需要写死，因为 Expo 和 React Native 的迭代很快。核心思想是：先让项目可运行，再让 AI 参与修改。版本只是承载思想的工具。

6. 完整示例代码与改造过程

6.1 创建项目骨架

打开终端，执行以下命令初始化一个 Expo 项目：

# 创建 Expo 项目，这里以 ts 模板为例 npx create-expo-app OrderManagerApp --template cd OrderManagerApp # 启动开发服务 npx expo start

启动成功后，用 Expo Go 扫码或启动模拟器，能看到初始页面。这一步的作用是确认工具链可用，避免后续改动堆在无法运行的项目上。

6.2 初始版：AI 生成的硬编码订单列表

新建文件src/screens/OrderListScreen.tsx，把下面的代码放进去。这是一个典型的 AI 生成风格页面：

// src/screens/OrderListScreen.tsx import React from 'react'; import { StyleSheet, Text, View } from 'react-native'; const orders = [ { id: 'A001', store: '城南店', amount: 120.5, status: '已完成' }, { id: 'A002', store: '城北店', amount: 89.0, status: '处理中' }, { id: 'A003', store: '城东店', amount: 245.0, status: '待付款' }, ]; export default function OrderListScreen() { return ( <View style={styles.container}> {orders.map((item) => ( <View key={item.id} style={styles.card}> <Text style={styles.store}>{item.store}</Text> <Text style={styles.amount}>¥{item.amount.toFixed(2)}</Text> <Text style={styles.status}>{item.status}</Text> </View> ))} </View> ); } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#F6F7FB', padding: 16, }, card: { backgroundColor: '#FFFFFF', borderRadius: 8, padding: 12, marginBottom: 8, }, store: { fontSize: 16, fontWeight: '600', }, amount: { fontSize: 14, color: '#1677FF', marginTop: 4, }, status: { fontSize: 12, color: '#888', marginTop: 4, }, });

这个页面的问题很明显：数据是写死的。在实际业务里，门店和订单都在后端数据库里。接下来要做的是把它改成接口驱动。

6.3 给 AI 的修改 Prompt

把 AI 当成一个不熟悉项目上下文的新同事，你需要在 prompt 里说清楚三件事：当前文件有哪些代码、你要改成什么效果、有哪些约束条件。下面是一个可以复用的 prompt 模板：

这是一个 React Native(TypeScript) 页面，当前使用硬编码的 orders 数组渲染订单卡片。 请把订单数据源改为从接口读取： 1. 使用 useEffect 在页面加载时请求 GET /orders?shopId=SH001 2. 保持现有卡片样式与字段展示不变 3. 增加 loading 状态，数据未返回时显示“加载中...” 4. 定义 Order 类型，包含 id、store、amount、status 四个字段 5. 增加请求失败状态，显示“加载失败，请重试”，并提供重试按钮 6. 使用 FlatList 代替 map，注意避免渲染性能问题

为什么要把约束写这么细？因为 AI 默认会自由发挥，你可能得到它自己的风格偏好。约束越具体，改造后的代码越接近预期。

6.4 改造版：接口驱动代码

把改造后的代码替换到OrderListScreen.tsx：

// src/screens/OrderListScreen.tsx import React, { useCallback, useEffect, useState } from 'react'; import { ActivityIndicator, FlatList, StyleSheet, Text, TouchableOpacity, View, } from 'react-native'; type Order = { id: string; store: string; amount: number; status: string; }; type FetchState = 'loading' | 'success' | 'error'; export default function OrderListScreen() { const [orders, setOrders] = useState<Order[]>([]); const [fetchState, setFetchState] = useState<FetchState>('loading'); const loadOrders = useCallback(async () => { setFetchState('loading'); try { const res = await fetch('http://localhost:3000/orders?shopId=SH001'); const data = (await res.json()) as Order[]; setOrders(data); setFetchState('success'); } catch (error) { setFetchState('error'); } }, []); useEffect(() => { loadOrders(); }, [loadOrders]); if (fetchState === 'loading') { return ( <View style={styles.centered}> <ActivityIndicator size="large" color="#1677FF" /> <Text style={styles.tip}>加载中...</Text> </View> ); } if (fetchState === 'error') { return ( <View style={styles.centered}> <Text style={styles.tip}>加载失败，请重试</Text> <TouchableOpacity style={styles.retryButton} onPress={loadOrders}> <Text style={styles.retryText}>重试</Text> </TouchableOpacity> </View> ); } return ( <FlatList style={styles.container} data={orders} keyExtractor={(item) => item.id} renderItem={({ item }) => ( <View style={styles.card}> <Text style={styles.store}>{item.store}</Text> <Text style={styles.amount}>¥{item.amount.toFixed(2)}</Text> <Text style={styles.status}>{item.status}</Text> </View> )} /> ); } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#F6F7FB', padding: 16, }, centered: { flex: 1, alignItems: 'center', justifyContent: 'center', backgroundColor: '#F6F7FB', }, card: { backgroundColor: '#FFFFFF', borderRadius: 8, padding: 12, marginBottom: 8, }, store: { fontSize: 16, fontWeight: '600', }, amount: { fontSize: 14, color: '#1677FF', marginTop: 4, }, status: { fontSize: 12, color: '#888', marginTop: 4, }, tip: { marginTop: 12, fontSize: 14, color: '#666', }, retryButton: { marginTop: 16, paddingHorizontal: 24, paddingVertical: 10, backgroundColor: '#1677FF', borderRadius: 6, }, retryText: { color: '#FFFFFF', fontSize: 14, }, });

这段代码的关键点是加载状态与失败处理。真实项目里，网络请求失败太常见了，如果 AI 生成的代码没有错误兜底，生产环境基本不可用。这也是为什么“让 AI 改代码可以，但必须有人做验收”。

6.5 本地 Mock 接口

前端页面已经请求http://localhost:3000/orders，现在需要给它一个可用接口。在项目根目录新建server/index.js：

// server/index.js const express = require('express'); const cors = require('cors'); const app = express(); app.use(cors()); const orders = [ { id: 'A001', store: '城南店', amount: 120.5, status: '已完成' }, { id: 'A002', store: '城北店', amount: 89.0, status: '处理中' }, { id: 'A003', store: '城东店', amount: 245.0, status: '待付款' }, ]; app.get('/orders', (req, res) => { const shopId = req.query.shopId; // 如果需要在本地模拟不同门店数据，可以按 shopId 进行过滤 res.json(orders); }); app.listen(3000, () => { console.log('mock server running at http://localhost:3000'); });

在server目录下执行：

mkdir server cd server npm init -y npm install express cors node index.js

看到控制台输出mock server running at http://localhost:3000就说明接口已经就绪。

6.6 配置分离

在实际项目里，直接把接口地址写死在代码中并不推荐。更稳妥的方式是把模块配置抽出来，统一管理。下面是一份order-module.json：

{ "module": "order-list", "title": "门店订单", "primaryColor": "#1677FF", "api": { "url": "/orders", "method": "GET", "params": { "shopId": "SH001" } }, "fields": [ { "key": "store", "label": "门店", "type": "text" }, { "key": "amount", "label": "金额", "type": "money" }, { "key": "status", "label": "状态", "type": "enum", "values": ["已完成", "处理中", "待付款"] } ] }

这个配置文件的思路是：页面结构、接口字段、展示顺序用 JSON 描述，代码只负责解释这份配置。以后业务方想改字段名称、调整字段顺序、新增一个展示字段，不需要改 React 代码，只要改配置即可。这也是“人人都能改自己 App”在工程上的落地方式之一。

7. 运行结果与验证方法

完成上面的代码调整之后，分两个终端运行：

# 终端一：启动 Mock 后端 cd server node index.js # 终端二：启动 Expo 开发服务 cd OrderManagerApp npx expo start

在模拟器或真机上打开 App，预期效果是：

• 进入订单列表页时看到“加载中”提示；
• 接口返回数据后，列表渲染出三家门店的订单卡片；
• 下拉列表能看到卡片样式与硬编码版本保持一致；
• 如果关掉后端服务再刷新 App，会看到“加载失败，请重试”和重试按钮。

这套验证流程的重点不只是“功能跑通”，而是确认三个点：接口连接正常、状态切换正常、渲染结果正确。任何一个环节失败，我们都能明确知道问题出在哪一层。

如果页面一直停留在“加载中”或请求失败，优先检查三处：

1. 看终端里 Mock 服务有没有收到请求，如果没收到，说明前端请求的地址或端口不对；
2. 看浏览器里直接访问http://localhost:3000/orders?shopId=SH001能否返回 JSON，如果不能，说明后端问题；
3. 看 App 里是否有跨域或网络权限限制，真机调试时localhost指向手机自身，需要用电脑的局域网 IP 代替。

第三步是新手最常见的坑。在开发环境中，从 Android 模拟器访问宿主机需要使用10.0.2.2，从 iOS 模拟器或 Expo Go 访问开发机则需要使用局域网 IP。你需要把OrderListScreen.tsx里的请求地址改成实际可访问的地址。

8. 常见问题与排查思路

这类错误有一个共同点：AI 无法看到你运行环境里的全部信息。它帮你生成的代码是“基于通用场景的合理推断”，而你的网络、端口、字段名、依赖版本都是本地特有信息。所以排查的核心不是责怪 AI，而是建立一条自己的“运行观测链路”：能看到接口返回、能看到错误堆栈、能看到日志输出。这条链路通了，AI 生成的代码才变得可控。

9. 安全边界与工程最佳实践

AI 降低了编码门槛，也带来新的风险。首当其冲的是敏感信息泄露。开发时很容易顺手把后端地址、API Key、甚至数据库连接信息写进前端代码，这在快速原型阶段问题不大，一旦发布就是事故。最佳实践是：让前端的密钥和密钥永不存在。

更完整的安全边界包括以下几条：

• 前端只保存公开信息，用户身份用登录态和 Token 管理，不要在前端代码里硬编码管理员账号。
• 接口请求必须经过服务端校验，不能因为前端隐藏了某个按钮，就认为后端不需要权限判断。
• AI 生成的代码同样要遵守最小权限原则，所有数据接口按需返回字段，避免一次性返回整个表的数据。
• 部署前检查代码仓库的提交历史，防止密钥被误提交后残留。
• 生产环境变更前要先在测试环境验证，数据库操作要先备份，发布要能回滚。

对工程团队来说，我看到的最佳实践是“AI 生成 + 工程师验收 + 自动化测试兜底”。AI 负责把重复劳动做完，工程师负责审核心业务逻辑，自动化测试负责防止回归。三者缺一不可。很多团队失败的原因不是 AI 不够强，而是把 AI 输出当成最终成品，省掉了验收环节。

另外，项目里一定要补一份 README 和项目结构说明。AI 修改代码时需要它来理解项目，新成员接手时也需要。别让 README 成为形式上存在、内容上过期的文件，它现在就是 AI 协作时的“项目上下文”。

10. 总结：AI改变了什么，没有改变什么

回到最初的标题。那个“10年前赌输的创业”，本质上是赌输了“定制化 App 开发成本可以被规模化摊薄”这件事。当年的技术条件下，每一单都是边际成本递增的，赌输了很正常。今天 AI 把需求到代码的翻译成本压得很低，定制化开发重新变成一门可行的小生意，这个判断是可以成立的。

AI 改变的是成本结构。它让“改一个按钮、加一个字段、调整一段业务流”不必再惊动整个研发流程。对个人开发者来说，这意味着你可以用一个模板加上一段业务描述，交付属于自己的 App；对团队来说，这意味着可以把重复性需求丢给 AI，把精力放在数据安全、核心业务和用户体验上。

AI 没有改变的是“验收责任”。无论代码是 AI 写的还是人写的，发布到生产环境前都需要做安全审查、功能验证、回滚预案。越是容易生成代码的时代，越需要有人对“什么代码值得上线”负责。

如果你想实践今天的内容，下一步建议很简单：找一个小工具类需求，准备一批模拟数据，用 AI 生成一个列表页，再加一个 Mock 接口把它跑通。这个最小闭环完成后，你会发现“人人能改 App”不再是一个口号，而是一套你自己已经走过的工程流程。