#WorkBuddy# 从 0 到 1：用 AI 把一台办公电脑变成项目数据平台（零成本 · 零运维 · 内网可用）

一、起因：台账散在 Excel 和微信里

我在做一个感知设备安装项目，日常有几类数据要来回倒腾：

• 对外发文：文件发出去，对方签没签回、超没超期，靠打电话催；
• 现场照片：勘察照片存在各自手机和微信群里，三个月后想找某个点位的整改前后对比，找不到；
• 设备材料：设计量、到货量、安装量三套数字分在三张 Excel 里，每次对账都要人肉 VLOOKUP；
• 进度日报：每天在群里发一段文字，周末再人工汇总成周报。

试过在线表单和 SaaS，问题是：数据放在别人服务器上，项目部不同意；而且要按人数收费，一年几千块。真正想要的其实很简单：一个内网网址，电脑手机都能开，数据在自己机器上。

于是我做了个决定：拿一台正在用的办公电脑当服务器，让 AI 帮我从零写一个平台。

二、先搞清楚：办公电脑能不能当服务器？

动手前我实测了自己那台工作机，结论是完全够用，这也是本文最想破除的一个误解：

一个 Node 服务跑起来，内存占用不到 100 MB，对一台办公机毫无压力。真正需要处理的不是性能，而是三个"办公机特有"的毛病：

1. IP 会漂：走 WiFi + DHCP，重启可能换 IP。解决：进路由器做「DHCP 静态分配」，把 MAC 绑死成一个固定 IP；能插网线更好。
2. 会休眠：电源设为「从不睡眠」+ 合盖不睡眠。
3. 单点风险：硬盘挂了数据全没。解决：每日自动快照到另一块盘。

这台机器白天还是要带去工地，人一走服务就断。所以我的规划是：先用它把平台跑起来验证，后面买台几百块的小主机 7×24 开机，整个目录打包复制过去，十分钟迁完。

三、技术选型：为什么不用 Docker、不用 MySQL

我给 AI 提的约束只有一句话：我不是运维，出问题必须能自己修。于是定下三条：

• 零 Docker：Docker、PostgreSQL 出问题我排不了；Node 一个进程跑到底，看日志就能定位。
• 零依赖：只用 Node 内置模块（http / fs / path），npm install 都不需要，拷到任何一台装了 Node 的电脑就能跑。
• 数据用 JSON 文件 + 原子写：数据量在这个规模（几千条）完全够，备份就是复制文件，恢复就是替换文件，谁都会操作。

目录结构一眼能看懂：

四、关键代码（四段骨架）

1. 服务本体：零依赖 HTTP + 原子写

为什么要串行写队列：两个人同时保存，两个异步写交错就会互相覆盖。把所有写操作串成一条链，天然排掉并发。

2. 前端三模式自适应：一个页面通吃三种环境

这是我做得最值的一个设计。同一个 index.html，能在三种环境自动切换：

好处是：服务器没开时页面不会白屏报错，而是降级成本地模式继续能录数据；等服务器起来了，数据再合并回去。业务连续性不依赖运维水平。

3. 删除保护：任何删除都要口令，且先进"回收站"

真实场景里，误删一条发文记录比系统宕机更麻烦。所以：登记免密、删除要密码、删了还能找回。

4. Windows 自启脚本：中文 bat 必须存成 GBK

这是卡了我最久的一个坑。用 UTF-8 写的 bat，双击后 cmd 满屏「'X' 不是内部或外部命令」——cmd 按 GBK 逐行解析，中文全变乱码命令。chcp 65001 也救不了（逐行读取时编码切换有偏移）。

正确做法是用 Python 强制以 GBK 写出：

顺带一提，防火墙放行规则名要用纯 ASCII（如 FaWenQianShou-8080），否则 netsh 参数也会乱码。

五、五个真实踩过的坑（这段最值钱）

1. 网页上删除按钮"消失了"：表格用了 table-layout: fixed，我只给部分列设了宽度，结果唯一没设宽的列被挤成 16px，操作列 overflow: hidden 又把「删除」裁掉了。 → 铁律：fixed 布局必须每一列都给宽度，别留 auto；操作列用 position: sticky; right: 0 永远可见。
2. 前端拿不到云端 SDK：一开始在页面顶部同步快照 window.__SMART_PAGE__.database，注入时机晚一点就永远 undefined。 → 改成轮询等待（最多 5 秒），并保留本地降级模式。
3. 直接改数据文件，改动被覆盖：服务在内存里缓存了数据，我手工编辑 data.json 后一保存就被内存里的旧值覆盖。 → 要么走 API 改，要么改完重启服务。
4. 自动化测试把真实数据删了：用 jsdom 跑端到端测试时走了真实删除流程，把一条真实记录删掉了（好在从快照恢复了）。 → UI 测试一律用注入的假数据，或把删除接口 stub 掉。
5. 控制台一直刷 404 favicon：页面上加一行 <link rel="icon" href="data:,"> 即可消除，别让它淹没真正的报错。

布局问题我最后是用 puppeteer-core + 本机 Edge 无头模式，逐列量 getBoundingClientRect() 和 scrollWidth 定位的——比肉眼截图靠谱得多，哪个列被截断一量就知道。

六、现在的效果与下一步

第一批已经跑起来了：内网打开 http://10.10.17.250:8080，发文登记、附件上传（方案 PDF 直接挂）、超期未签收标红、删除要密码、删除自动备份。手机上也能开，只是表格要横滑。

第二批开始按模块扩展，每批都复用同一套骨架（权限、导出、备份全是现成的）：现场照片台账 → 设备材料清单（设计量/到货量/安装量三栏自动算差） → 施工进度日报（自动汇周报） → 设备出入库。

最关键的一条经验：先做"统一主数据 + 统一编号规则"这层地基。 单位名录、点位库、设备型号库只维护一次，五个模块全部下拉引用。不这么做，三个月后一定会出现"同一个船闸在发文里叫白石窑、在日报里叫白窑"这种对不上账的局面，然后推倒重来。

七、给同样用 AI 搭东西的人：三条省钱心得

这次全程是让 AI 写的代码，几点体会：

1. 需求一次定清再动手。返工是最贵的：需求中途变一次，代码就要重写一遍。我先把表结构和栏目定死，确认后再让 AI 一次生成完整代码。
2. 别用"截图→改→再截图"的循环。图片往返消耗大，而且慢。改成让 AI 写自测脚本（jsdom 跑前端、curl 跑接口），自己验证自己修。
3. 看一眼模型倍率再派活。同一段代码生成任务，高档位和低档位模型的消耗能差好几倍；日常小活挑低倍率档就够。注意同一任务干到一半别换模型，换一次上下文要重跑，白花一轮。

小结

搭内部系统真正的门槛从来不是技术，而是"有没有人愿意为你花两周写 CRUD"。 现在这个门槛被抹平了：硬件用现成的、软件零依赖零成本、代码让 AI 写、运维只需双击一个 bat。

如果你的团队也在用 Excel + 微信群管项目，不妨从最小的一个模块开始试——比如先把"发文签收"做成能登记、能预警、能导出的一张网页。跑通一个，后面的模块就是复制粘贴的事。

（本文是系列第一篇，第二篇会讲多模块扩展与主数据设计，欢迎关注。）