①摘要
用 TRAE SOLO TMC 从零搭建了一套企业级飞书电子表格实时变更监控系统。支持同时监控任意多个飞书电子表格、每个飞书电子表格通知到不同的飞书群、单元格级变更检测、60秒防抖合并、应用内机器人 @所有人、Web 可视化管理页面及密码认证、systemd 服务化部署。全程 20+ 次真实迭代，从第一行代码到最终上线，没有手写一行代码。
②背景
企业团队使用飞书协作，多个业务飞书电子表格（项目进度表、需求跟踪表、资源分配表等）分散在不同知识库中。
现实场景：产品档案专员在飞书电子表格更新产品编码，并未想起通知对应产品开发专员，形成沟通遗漏，产品开发专员经验之谈，并未检查产品飞书电子表格内容最新状态，导致该产品包装印刷编码错误。形成信息不对等的错漏结果。
核心痛点：
- 表格更新后，其他人无法第一时间感知，信息严重滞后
- 每天要手动打开 5-6 个表格检查是否有更新，耗时且容易遗漏
- 不同表格需要通知到不同的项目群，没有统一方案
- 飞书官方不提供表格变更实时通知能力
一句话需求：表格一改，群里立刻知道改了什么。
③实践过程
我的策略：不追求一步到位，而是「跑通 → 测试 → 反馈 → 迭代」
整个项目经历了 20+ 次迭代。每次都是：部署到服务器 → 真实测试 → 发现问题 → SOLO → 修复 → 再测试。所有代码都是 SOLO 生成的，我只负责提需求和提报测试结果。
迭代全景（20+次）
第一阶段：从0到1，让通知跑通（迭代 1-6）
| 迭代 | 做了什么 | 结果 |
|---|---|---|
| 1-3 | 搭建基础框架，Python + lark-oapi SDK，WebSocket 长连接 | 能连接飞书服务器 |
| 4-6 | 订阅文件编辑事件，实现变更检测和卡片消息推送 |  第一次收到群通知！ |
踩坑： 一开始用 HTTP 回调模式，需要公网域名+SSL证书。SOLO 建议改用 WebSocket 长连接，本地就能跑，部署难度直接降了一个量级。
第二阶段：适配真实场景（迭代 7-12）
| 迭代 | 做了什么 | 结果 |
|---|---|---|
| 7-9 | 支持知识库表格（Wiki URL → spreadsheet_token 自动解析） | 知识库表格也能监控了 |
| 10-12 | 加入防抖机制（60秒内多次编辑合并为一次通知） | 不再频繁刷屏 |
第三阶段：从能用变成好用（迭代 13-17）
| 迭代 | 做了什么 | 结果 |
|---|---|---|
| 13-15 | 多表格多群支持，JSON 配置文件，事件路由 | 一个应用监控所有表格 |
| 16-17 | 升级为应用内机器人，支持真正的 @所有人 | 群里所有人都会收到提醒 |
第四阶段：零代码运维（迭代 18-20+）
| 迭代 | 做了什么 | 结果 |
|---|---|---|
| 18-20 | Flask Web 管理页面，增删改查、一键重启、密码认证 | 添加新表格不用碰代码 |
| 20+ | 修复各种边界问题（编码、缓存、打包覆盖等） | 生产级稳定运行 |
我是怎么跟 SOLO 协作的
整个过程我的 Prompt 都很简短，说人话就行：
「现在是我修改1下，通知一下，太快了」
→ SOLO 理解为需要防抖，实现了60秒合并通知
「我需要拓展，支持这个应用，多个飞书电子表格，不同群」
→ SOLO 重构了整个配置体系，引入 monitors.json
「那能改成应用内机器人吗？」
→ SOLO 切换到 Bot API，实现真正的 @所有人
「我希望能够生成一个页面，让我直接修改配置」
→ SOLO 用 Flask 搭了完整的 Web 管理后台
「你又忘了打包项目给我」
→ ……这个确实是我的问题 😂
SOLO 在这个项目中扮演的角色：
| 角色 | 具体表现 |
|---|---|
| 全栈开发 | Python 后端 + Flask 前端 + systemd 运维配置 |
| API 专家 | 查阅飞书官方文档，修正 API 路径和参数 |
| Debug 助手 | 20+ 次 Bug 定位和修复，分析日志精准定位问题 |
| 架构师 | 从单表格到多表格的架构演进设计 |
| 运维工程师 | 防火墙配置、服务部署、缓存管理 |
④成果展示
系统运行效果
服务部署在云服务器上，systemd 托管，7×24 小时稳定运行，断开 SSH 也不影响。
通知卡片效果
表格被编辑后，60 秒内群内自动收到通知卡片：
核心能力：
- 单元格级变更检测：精确到每个单元格的新增、修改、删除
- 变更前后对比：清晰展示「旧值 → 新值」
- 可点击表格链接：直接跳转到对应表格
- @所有人强提醒：应用内机器人，真正提醒每位群成员
- 60秒防抖：连续编辑合并为一次通知，不刷屏
Web 管理页面
访问 http://服务器IP:5000（密码保护），所有配置操作可视化：
零代码添加新表格： 点击「添加监控」→ 填写表格URL和群聊ID → 保存 → 重启服务 → 完成。
技术架构
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ 飞书表格 │────→│ 飞书服务器 │────→│ WebSocket 推送 │
│ (任意多个) │ 编辑 │ 事件检测 │ │ (长连接) │
└─────────────┘ └──────────────┘ └────────┬────────┘
│
┌──────▼──────┐
│ 监控服务 │
│ 事件路由 │
│ 防抖合并 │
│ 变更检测 │
└──────┬──────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ 项目群 A │ │ 需求群 B │ │ 运营群 C │
│ @所有人 │ │ @所有人 │ │ @所有人 │
│ 变更卡片 │ │ 变更卡片 │ │ 变更卡片 │
└─────────────┘ └─────────────┘ └─────────────┘
技术栈
| 组件 | 技术选型 | 说明 |
|---|---|---|
| 开发语言 | Python 3.12 | |
| 飞书 SDK | lark-oapi | WebSocket 长连接，无需公网IP |
| 事件订阅 | drive.file.edit_v1 | 云文档编辑实时事件 |
| 变更检测 | 自研对比引擎 | 逐单元格 diff，支持新增/修改/删除 |
| 通知方式 | Bot API | 应用内机器人，支持 @所有人 |
| Web 管理 | Flask | 可视化配置管理 |
| 进程管理 | systemd | 开机自启 + 崩溃自动重启 |
| 认证安全 | HTTP Basic Auth | Web 页面密码保护 |
⑤效果与总结
效果对比
| 维度 | 之前 | 现在 |
|---|---|---|
| 变更感知 | 每天手动打开 5-6 个表格检查 | 实时自动推送，0 感知延迟 |
| 通知方式 | 靠口头传达或手动@人 | 自动 @所有人 + 变更详情卡片 |
| 变更粒度 | 只知道「表格改了」 | 精确到每个单元格改了什么 |
| 多表格管理 | 无法同时监控 | 一个应用监控任意多个表格 |
| 添加新表格 | 需要开发+部署 | Web 页面 3 分钟搞定 |
| 服务稳定性 | 无 | systemd 托管，7×24 稳定运行 |
开发效率
| 指标 | 数据 |
|---|---|
| 总迭代次数 | 20+ 次 |
| 我写的代码行数 | 0 行 |
| 总耗时 | 约 4 小时（含测试和部署） |
| 传统开发预估 | 2-3 天（含 API 调研、开发、调试、部署） |
核心思考
-
AI 最大的价值不是「一次生成」，而是「无限迭代」：这个项目如果让 AI 一次性生成完整代码，大概率跑不起来。但通过 20+ 次「测试→反馈→修复」的循环，每次只解决一个小问题，最终打磨出了生产级系统。
-
不需要会写代码，只需要会说清楚需求：我的所有 Prompt 都是中文大白话，没有一行技术术语。SOLO 理解需求的能力远超预期。
3.想法停留在脑子
里，始终是想法，一句即使不清晰的提示词开始，MTC即可协助你一步一步逐渐完成那个想法。想法的实现，就是创造，从那句来源于实际需求的提示词而来