## 一、我想要的东西很小，小到不好意思麻烦人

事情的起因很偶然。我帮人跑一个线上小工具，纯粹是私事——但用着用着发现它缺一块：我这边的数据改了，对方那头看不到，得手动把结果发过去。
我想要的其实就是一个按钮大小的东西：**两台手机各打开一个页面，我这头一动，那头三秒内自己更新**。类似共享记事本，但只要一个数字就够了。
这种需求说出来有点丢人：太小，写代码不值当；又太小，App Store 上的现成应用没有一个顺手的。于是我想试试，让 AI Agent 一次性把这个东西造出来，看看到底能不能落地。
结果做完了。我把它拆成六步讲讲，重点不在"AI 能写前端"，而在**一个不会动的页面，怎么变成两个真人之间流动的东西**。
![配图1_双视角@2x.png](https://developer.qcloudimg.com/http-save/yehe-12800286/9d10aaf2010250eae32ce206973b5ccd.png)
## 二、先说结论：能落地，但有三件事必须自己盯

先给结论，免得看到后面觉得绕：
1. **页面很简单，真正的工作量在"状态机"和"权限"上**。页面上那点动画，AI 十分钟能写完；难的是"谁在什么状态下能看到什么"。

1. **云端数据库必须开行级权限，否则等于裸奔**。这一步 AI 不会主动提醒你，它是安全底线。

1. **两个人各自刷新页面这种最蠢的方案，能跑但没法用**。真正的分界线是：任何一边切到后台，回来的时候状态必须自己纠正。

下面按这个顺序讲。
## 三、第一步：先把状态想清楚，再动代码

我一开始是反着来的——先让 AI 把界面画出来，效果挺好看，然后才发现数据全是假的，点哪儿都不动。
返工重来。我先在纸上把状态列了一遍：**计数是多少、气和值是多少、进行到第几轮、双方各自在线没有、消息各存了什么、看到第几条了**。列完这一眼就能看出，这六七个字段不是"一个应用的数据"，而是**一个房间的属性**。
房间这个概念是关键。两个人的所有数据都挂在同一个房间下面，房间号就是两人之间唯一的约定：
```

```**为什么不拆成两张表**？因为这七个数必须永远一致。拆开了就会出现"发送方那边显示 10 条，接收方那边显示 7 条"，而且没法在一个请求里读全。放一行里，读一次就齐了。
代价是每次改动都得整行写回去。这个规模下完全能接受，几百次以后再说。
## 四、第二步：给数据库上锁，这步不能省

云数据库默认往往是宽松的，能读能写。这个应用是"任何人拿到房间号都能读写"的设计，如果表再裸奔一次，等于**全网任何人都能列出所有房间**。
所以要显式开权限，并且开完立刻验证。SQL 不长，但关键在两条策略要都在：一条管读，一条管读写，缺一条就有一边漏：
```

```写完我没直接信。专门用一个干净的会话去查了一张**不存在的房间号**，确认返回空而不是报错，才算过。
这里有个心态上的东西值得说：**AI 会帮你写代码，但不会替你承担"漏了一步"的后果**。这类配置项的正确做法是——写完立刻拿最蠢的方式验一遍，别指望逻辑自洽。
## 五、第三步：两个人分别是谁，靠一个参数决定

两个人的页面其实是同一份文件。那"我是谁"从哪来？
我用的是链接参数 + 本地存储双保险：
```

```角色存进本地存储，之后每次操作先问一句"我是不是发起方"。这个判断决定了三件事：**谁能改计数、谁的消息写进哪个数组、谁负责写进度**。
```

```这个函数是整个应用的心脏，只有一处分支：**角色决定数据往哪走**。往后所有功能——在线状态、未读红点、提示音、画面触发——全部挂在这一个判断上。设计的时候就想清楚这一点，比事后补要省事得多。
**为什么消息要存成两个数组，而不是一个？**
因为双方写的频率和时机不同，而且**只有一方会写进度字段**。硬塞进一个数组，就得每次都判重、判权，越改越乱。分开存，渲染的时候按时间戳合一次就够了：
```
![配图2_角色切换@2x.png](https://developer.qcloudimg.com/http-save/yehe-12800286/38bd203dc4185c555f278abbe76632a7.png)
```数据存的时候分两个坑，读的时候合成一条河。这是我在整个项目里最满意的一个决定。
## 六、第四步：三秒轮询，以及三个必须手动处理的情况

实时同步我用的是最笨的办法：**每三秒拉一次全量**。不上 WebSocket，不做增量。
有人会问这不浪费吗？我算了一下：一次请求返回几百字节，一个人一天在线也就几百次，总量比一张图片还小。**对一个只有两个人的应用，这个方案的复杂度收益比是最好的。**
但轮询有三个坑，一个都不省：
**第一，要区分"是我发的"和"是对方发的"。**
刚拿到数据我并不知道是谁触发的计数变化。办法是记住本地已经渲染到第几轮了，只在**远端的轮次比我大**的时候才放画面：
```

```那行 wasFull 是我自己发到第 10 条之后补的。**只做界面触发的话，进度会差一格**，这个 bug 很难在快速操作里复现。
**第二，页面切后台要停。**
手机切走了还三秒一拉，电费和流量都白扔。更要紧的是：切后台时顺手把自己的在线状态置成 false，回到前台再置回来。这一对操作，比省下来的流量值钱多了——**对方能立刻看到你走没走**。
```

```**第三，网络请求要有超时。**
这是踩得最疼的一个。第一版没加超时，结果对方在电梯里打开页面，云端请求挂着，一直卡在"连接中"，我这边点按钮**完全没反应**，也看不到任何报错。
加超时之后，状态条分成了几段显示，每一段都写清楚卡在哪：
![配图3_状态条四态@2x.png](https://developer.qcloudimg.com/http-save/yehe-12800286/be39a0811045934254941a0c8581fcbd.png)

```**任何一步失败，都要把人卡在哪一步说出来。** 一个只会显示"连接失败"的界面，等于让人猜谜。
## 七、第五步：让它变成能"装到桌面上"的东西

做到这一步它还是个网址。手机上要每次都翻收藏夹，太蠢。
补齐三样就成了一个正经的小应用：
**清单文件**。声明名字、图标、主题色，还有竖屏锁定：
```

```**Service Worker**。缓存策略我分了三类，这是我觉得最值得抄的部分：
```

```第一行是踩出来的。**我一开始图省事没做路径判断，结果离线缓存把同步接口也缓存了**——用户看到的是几分钟前的数据，而且完全没有异常表现，以为是对方没回。这种"看起来在动但其实是旧的"的问题，比直接报错难查十倍。
**图标**。用脚本生成的小熊，比找素材快。参数调了两轮：第一版心画太大，把五官全挡住了，调小挪到胸前才顺眼。这种小事 AI 做不了十次八次都得手调，做一次记下来就行。
装完之后手机上会多一个桌面图标，点开没有地址栏，断网也能打开界面（同步功能当然还是需要联网）。
## 六、第六步：三个真实踩过的坑

前面五步是设计，这三个是纯粹被现实绊倒的，记下来省得下一个人再踩。
**坑一：一个字母，废掉半个应用。**
写完最后一段，我把事件绑定收尾。里面用了 **`** 这个简写来取元素——但整个文件里我只声明过一个 **`n**，**$** 从来没定义。
结果就是这一行直接抛错，**后面的脚本一行都不执行**。而自动连接那段逻辑正好在后面。
现象特别迷惑：按钮点下去毫无反应，状态永远停在"未连接"，控制台也只有一行红字。明明大部分代码是好的，就是全不跑。
```

```一行的事，花了我一轮排查。**教训是：任何顶层脚本只要有一行抛错，它后面所有代码都不会跑。**所以关键逻辑不要写成一个大块的顶层语句。
**坑二：第三方脚本是异步加载的。**
云服务的 SDK 从 CDN 拉。我的代码在页面底部同步执行，脚本还没到，加载函数已经调完了——后面拿到的还是空。
修法是轮询等它，不是加延时：
```

```40 次乘 150 毫秒是 6 秒，超了就明确告诉用户失败。**宁可报错，不要无限等。**
**坑三：变量还没定义就用。**
这个更隐蔽。同一个文件里，我在函数定义之前就调了一次画进度条。那一刻进度条的变量还没初始化，直接抛"访问死区变量"。
神奇的是**语法检查完全通过**，因为这在语法上是对的，只有运行到那一行才炸。
我把那次提前调用挪到了所有声明之后。这个坑记了很久——**语法检查通过不等于能跑**。
## 七、回头看，这事到底值不值

从提出需求到两台手机真机同步能跑，中间的过程大概是这些步骤：
1. 列状态和字段，别先画界面

1. 建一张表，字段能少就少

1. 上行权限策略，写完拿不存在的值验一遍

1. 角色参数 + 本地存储，锁定数据流向

1. 三秒轮询，处理切后台、超时、渲染去重

1. 补清单文件、Service Worker、图标

1. 收尾的三个坑挨个填

回头看，**AI 承担了大约七成的活**——界面、动画、样式、那些琐碎的分支，它写得又快又稳，基本不用返工。
剩下的三成才是真正决定成败的：**状态怎么定义、权限怎么开、什么算"对"。**
这三样 AI 给不了，因为它们不是代码问题，是**你对这件事到底要什么**的问题。你说不清"两个人的数据怎么算一致"，它就写不出那个判断。
所以如果也要做类似的东西，我最大的建议就一句：**先把"两个人之间什么算一致"写下来，再让 AI 动手。** 这一步花的时间，比返工省下来的多得多。


----
## 写在最后

这个小应用最后没上应用商店，也没打算赚钱，就是自己用的。但整个过程里最让我意外的不是 AI 写代码有多快，而是**它把"验证"这件事变成了可交付的东西**——它能自己造页面、能自己建表、能自己上云，但"这样到底对不对"始终得人回答。
这大概就是目前 AI 编程的真实位置：能干活，不能背锅。
如果你们也做过类似的小工具——共享计数器、双人记事、协作白板——我挺想看看你们是怎么解决"两边数据怎么算一致"的。评论区说说，我下篇挑有意思的展开写。

事情的起因很偶然。我帮人跑一个线上小工具，纯粹是私事——但用着用着发现它缺一块：我这边的数据改了，对方那头看不到，得手动把结果发过去。我想要的其实就是一个按钮大小的东西：两台手机各打开一个页面，我这头一动，那头三秒内自己更新。类似共享记事本，但只要一个数字就够了。这种需求说出来有点丢人：太小，写代码不值当；又太小，App Store 上的现成应用没有一个顺手的。于是我想试试，让 AI Agent 一次性把这个东西造出来，看看到底能不能落地。结果做完了。我把它拆成六步讲讲，重点不在"AI 能写前端"，而在一个不会动的页面，怎么变成两个真人之间流动的东西。

#WorkBuddy# 我让 AI 造了个小应用，两人手机上真能同步

一个只有两个人的小工具：我在网页上改一下，对方手机三秒内自己更新。我把这个过程完整记了一遍：怎么把状态先列清楚再动手、数据库权限怎么开才不裸奔、两个人怎么用同一个文件区分身份、三秒轮询要处理哪三种情况，以及最后收尾时踩的三个坑——一个字母废掉半个应用、CDN 脚本异步加载、变量没定义就调用。文章结论是：AI 承担了大约七成的活，剩下三成状态定义、权限边界和"什么算对"，只能人自己回答。

低代码

开发工具

后端

用AI Agent六步打造双人实时同步小工具：从状态机设计、云端行级权限上锁，到三秒轮询与切后台处理，详解数据一致性、超时与渲染去重等关键坑。AI承担七成编码，但“什么算一致”仍需人定，提供可落地的AI编程实战经验。

云数据库

代码解释

数据库

数据流

WebSocket

AI编程

2026上云采购 | AI焕新·智启新局

workbuddy-enterprise

对象存储COS新用户低至1元！


CDN免费试用


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

#WorkBuddy# 我让 AI 造了个小应用，两人手机上真能同步-腾讯云开发者社区-腾讯云

#WorkBuddy# 我让 AI 造了个小应用，两人手机上真能同步

#WorkBuddy# 我让 AI 造了个小应用，两人手机上真能同步

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐