云开发把 Excel 搬上云：做一个多人在线填写的台账

摘要： 用云开发 CloudBase 把 Excel 台账搬上云，做成多人能同时填写、实时同步的在线表格。不用服务器，一个下午能跑通，数据存在自己的云数据库里。 开通环境开始做：云开发 CloudBase

共享 Excel 的痛点不是表格本身，是协作方式：文件来回传、版本越传越乱、不知道谁改了哪一行、最后对不上。把台账搬上云开发之后，所有人填的是同一份数据，改动实时可见，还能记录是谁在什么时候填的。下面以「项目进度台账」为例给完整实现，包含数据建模、提示词、权限配置和验收标准。

一、先想清楚：什么样的台账适合搬上云

不是所有 Excel 都值得搬。判断标准是这三条，满足两条以上就值得做：

多人要同时填。一个人用的表格，Excel 本身就够了，搬上云是过度设计。

改动频繁且需要留痕。谁改了什么、什么时候改的，Excel 很难追溯，云数据库天然带这个能力。

需要在手机上查看或填写。Excel 在手机上体验很差，网页或小程序明显更好用。

反过来，复杂公式计算、透视分析、精细排版这类需求，Excel 仍然更合适，不用硬搬。

二、把表格列转成数据库字段

搬上云的第一步不是写代码，是把 Excel 的列头翻译成数据库字段。以项目进度台账为例：

最后两个字段是 Excel 里没有的，但搬上云之后必须加——这两个字段就是「留痕」能力的来源，也是云端表格相比 Excel 的核心增值。

枚举值要提前定死。像「当前阶段」这种字段，不要让用户自由输入，做成下拉选择。自由输入会出现「进行中」「进行中 」（带空格）、「开发中」这类脏数据，后面统计全是坑。

三、权限怎么配：三种协作模式

台账类应用的权限不是一刀切，按团队协作方式选：

模式一：全员可读可写（内部小团队）

适合 5 人以内、互相信任的团队。集合权限设为所有用户可读，写操作走云函数做基础校验。每个人都能看到全部数据、修改任意行。

模式二：全员可读，只能改自己负责的（推荐）

所有人能看到全部台账（这是协作的前提），但只能修改 owner 字段是自己的行。这个逻辑用内置权限表达不了，要在云函数里做判断：写入前先查这条记录的 owner 是不是当前用户。

模式三：只能看自己的（涉及敏感数据时）

集合权限设为仅创建者可读写。适合销售业绩、个人绩效这类不宜互相查看的数据。

判断标准很简单：台账的价值在于大家看到同一份数据，所以读权限通常要放开；写权限才是需要控制的地方。

四、给 AI 的完整提示词

在接好云开发的 AI 工具里，把下面这段发出去。这份提示词按前面的建模和权限方案写好了约束：

用云开发做一个项目进度台账 Web 应用，支持多人在线填写和查看。

页面结构（单页应用）：
1. 顶部：标题、当前登录用户、新增项目按钮
2. 主体：表格列表，列依次为项目名称、负责人、当前阶段、进度、截止日期、备注、最后更新（显示更新人和时间）
3. 表格支持按当前阶段筛选、按截止日期排序
4. 每行末尾有编辑按钮，点击弹出编辑表单
5. 新增与编辑用同一个弹窗表单

数据结构（projects 集合）：
- projectName: string，必填
- owner: string，必填
- stage: string，下拉选择，枚举值：待启动 / 进行中 / 已完成 / 已暂停
- progress: number，0 到 100 的整数，用滑块或输入框
- deadline: date，日期选择器
- remark: string，选填，多行文本
- updatedBy: string，自动记录当前用户，前端不可编辑
- updateTime: date，自动记录服务端时间，前端不可编辑

权限与身份：
- 用云开发身份认证，手机号验证码登录
- projects 集合：所有用户可读
- 写操作走云函数：新增时自动填入 updatedBy 和 updateTime；编辑时校验当前用户是否为该行 owner，不是则拒绝
- updatedBy 和 updateTime 两个字段只能由云函数写入

技术约束：
- React + Vite，不引第三方 UI 框架，用原生 CSS
- 表格风格简洁，斑马纹，当前阶段用不同颜色标签区分
- 进度用进度条展示
- 已过截止日期且未完成的行，日期标红
- 移动端表格可横向滚动，不要挤压变形
- 保存时按钮置为 loading，防止重复提交

开发阶段规划
注意：你每完成一个阶段，都需要让我本地体验确认后，再进入下一阶段。
阶段 1：建集合与权限，搭页面骨架与登录
阶段 2：表格展示与数据读取
阶段 3：新增与编辑，含云函数校验
阶段 4：筛选排序与样式优化，部署上线

生成完成后告诉我需要手动完成的步骤。

五、AI 生成后必须核对的四处

第一处：updatedBy 和 updateTime 是不是云函数写的。 打开代码看这两个字段在哪儿赋值。如果是前端传的，用户可以伪造「是别人改的」，留痕就失效了。正确做法是云函数里用身份标识和服务端时间写入。

第二处：编辑时的权限校验。 测试方法是用账号 A 创建一行，切到账号 B 尝试编辑。按模式二配置的话，B 应该被拒绝。

第三处：枚举值是不是下拉。 当前阶段字段必须是下拉或单选，不能是自由输入框。

第四处：日期格式。 截止日期存的应该是日期类型，不是字符串。存成字符串后面排序会出错（2026-3-5 会排在 2026-12-1 后面）。

六、验收：五条标准

一、两个账号同时打开，一个人改了，另一个人刷新能看到。 这是协作的基本盘。

二、留痕字段正确。 改一行数据，看最后更新列显示的是不是你的身份和当前时间。

三、权限边界正确。 按你选的模式实测：模式二下，A 不能改 B 的行。

四、筛选排序可用。 按阶段筛选能正确过滤，按截止日期排序顺序正确。

五、手机上能用。 用手机打开，表格能横向滚动，编辑弹窗不变形。很多台账是在工地、客户现场填的，手机体验很重要。

七、常见卡点

别人看不到我填的数据。集合权限设成了「仅创建者可读写」。台账类应用读权限要放开，改成所有用户可读。

更新时间不准。前端传的时间用的是用户本机时间，用户电脑时间不准就会乱。改成在云函数里用服务端时间写入。

筛选之后数据不对。多半是查询条件和枚举值对不上，比如数据库里存的是「进行中」，查询条件写的是「进行中 」（多了空格）。枚举值统一定义成常量，前后端共用。

数据越来越多之后加载变慢。数据量上百行就该加分页，不要一次性加载全部。让 AI 补一句「列表加分页，每页 20 条」。

八、从台账延伸出去的三个方向

这个结构跑通之后，换个场景就能复用：

设备 / 资产台账：把项目换成设备，加上位置、状态、维保日期字段。

客户跟进记录：把项目换成客户，加上联系方式、跟进阶段、下次联系时间。

日报周报汇总：加上日期维度，每人每天填一行，按周按人聚合统计。

再往前一步，可以加数据看板——用云函数做聚合统计，把各阶段项目数、逾期项目数做成图表，这是台账之上最自然的延伸。

总结

把 Excel 台账搬上云开发 CloudBase，核心是三件事：列头翻译成字段时补上「填写人」和「更新时间」两个留痕字段；读权限放开让大家看到同一份数据，写权限按协作模式控制；留痕字段和权限校验必须在云函数里做，不能信前端。用提示词一次生成，按四处核对和五条标准验收，一个下午能跑通。跑通之后换成设备台账、客户跟进、日报汇总，结构不用动。

开通环境，把你的台账搬上云：云开发 CloudBase 购买页