我用 AI 做了个网球场提醒，再也不用每小时刷一次小程序
一位 B 端产品经理为了少刷几十次小程序，用 AI 给自己做了一个网球场空场提醒：从「定时打开小程序看页面」的第一版，一路被真实使用逼着改到「绕过小程序直连只读查询接口 + 云端定时 + 本机静默兜底 + 飞书通知」。真正值得留下的不是这个工具，而是它演示的那条路径——AI 让「只服务自己的小需求」第一次变得值得动手，而产品经理的创造力往往就藏在一句「这也太麻烦了」里。
基本信息
- 来源类型：文章（网页文章 / 人人都是产品经理）
- 原文位置：raw/articles/2026-09-24-112136-tg-b46552.md
- 原文 URL：https://www.woshipm.com/pd/6468790.html
- 原作者：简谙（微信公众号：简谙；深耕 B 端产品领域）
- 发布日期：2026-09-23
- 消化日期：2026-09-24
- 篇幅：约 2800 字（全文处理）
核心观点
-
需求的起点是一句生活化的话，不是一份需求文档。作者平时打网球，家附近球场 19:00–21:00 黄金时段被商家自己的教练课优先占用，对外开放的场地很少；但商家会临时放场、也会有人退订，捡漏概率其实不低。问题在于空场「什么时候放出来完全不确定，可能只存在十几分钟」，真要捡漏就得隔一会儿打开一次微信、进小程序、切换今天和明天、横向查看十几片场地。于是最初的需求只有一句：「有场子的时候，提醒我。」——没有需求文档，没有流程图，没有宏大的产品设想。
-
第一版能跑，但离「能用」还差得很远——因为用户在过程中定义的规则远比一句话多。AI 最初的方案是「定时打开小程序 → 查看预约页面 → 发现空场就通知」，听起来已经解决了问题，真正做起来细节立刻冒出来：
- 什么叫「有场子」：小程序按半小时切分时段，而场馆要求至少 1 小时起订，孤立空出半小时毫无意义。所以不能「看到一个白色格子就提醒」，必须判断同一片场地是否有连续两个可预约时段。
- 到底查哪些时间：只关心当天和第二天，且只看 19:00–21:00，白天的场地再多也没有价值。
- 提醒发到哪里：在 AI 工具里提醒没法一直盯着，后来选了飞书，因为工作日基本在线、手机也能及时收到。
到这一步第一版才勉强跑通：每半小时看一次小程序，发现当天或次日晚间有连续一小时的空场，就发飞书。
-
第一版的根本缺陷是「依赖用户自己的电脑和一直开着的微信小程序」。电脑休眠、关机，或者小程序被顺手关掉，监控就失效。作者的原话是：它不是一个真正的提醒工具，而「更像是找了个人坐在我的电脑前，定时替我看一眼」。
-
真正让方案翻身的不是加功能，而是找到结构化的数据入口。作者问 AI「能不能让电脑关机之后也继续监控」，随后尝试寻找小程序背后的场地查询方式：装了网络调试工具、开了临时抓包，发现微信小程序并不走普通的系统代理，绕了一圈才找到它查询场地时使用的、无需登录的只读查询接口——该接口只返回场地和时段状态，不涉及占位、下单和支付。找到它之后方案性质变了：以前是让 AI 像人一样盯着页面看，现在是直接读取结构化场地数据，判断每片场地哪些时间可订，再把符合条件的结果发出去；不再依赖微信，也不需要小程序一直开着。随后 AI 把这套监控放到云端，每半小时自动执行一次，飞书密钥单独加密保存、不写进程序，每次只做查询、不代替下单、更不碰支付。
-
「完成」之后，真实世界会继续补课——异常链路往往比主链路更长。跑了一段时间后陆续出现的修改与故障：
- 1 号中心场价格太贵，本人不会订 → 从监控范围里排除；
- 提醒频率：最初为避免骚扰要求「每天只提醒一次」，后来发现第一次没来得及订、后面再出现空场仍应继续提醒，于是改成每次轮巡发现空场都通知；
- 消息静默丢失：明明下午放出过几次场地却一条消息都没收到。排查后确认不是场地判断错了、也不是飞书发送失败，而是云端定时任务出现了延迟和漏跑 → 调整云端执行时间，避开容易拥堵的整点和半点，同时增加本机兜底任务：先检查云端最近有没有正常运行，只有云端失效时才补查，避免两边重复发送；
- 兜底任务抢焦点：每次本机兜底运行 PowerShell 窗口都会闪一下、抢走正在工作的焦点 → 最终改成完全静默的后台运行。作者原话：「这个工具确实开始提醒我了，也确实开始打扰我了。」
-
最终形态（可直接对照复用的需求规格）：每半小时查询当天和第二天的场地；只看 19:00–21:00；跳过价格太高的 1 号中心场；只认连续一小时以上的可预约时段；每次轮巡只要符合条件就发飞书；云端异常时由本机静默兜底；不打开微信，不自动下单，也不碰支付。作者感叹：最初那句「有场子的时候提醒我」，和最后真正能用的东西之间，隔着一长串当时根本没想到的问题。
-
AI 更适合被当成持续协作的搭档，而不是「一次性交作业」的工具。作者并没有一开始就想清楚所有需求——他只知道「自己不想反复刷小程序」；至于孤立的半小时时段算不算、电脑休眠怎么办、提醒发到哪里、一天提醒几次、某片场地要不要排除、云端调度失败怎么处理，都是在实际使用中一点点暴露出来的。这与做产品同构：用户最初说出来的通常只是一个目标，不是一份完整方案。如果 AI 只是严格执行第一句话，最后拿到的「大概率只是一个可以演示的东西」。真正让它变得可用的，是后续不断观察、反馈和修正——这一步能不能跑、那一步会不会漏、异常发生时怎么办、它解决问题的同时有没有制造新的问题。AI 可以写程序、查问题、配置通知、在某条路走不通时换一种办法，但**「现在这样到底好不好用」仍然需要人自己判断**。
-
产品经理的创造力，常常藏在一句「这也太麻烦了」里。我们一说创新就想到全新商业模式、改变行业的产品、没人做过的技术；但 PM 日常能接触到的创新往往没有这么宏大——它可能藏在一句「每次都要这样操作，也太麻烦了」里，藏在一个大家已经习惯却始终不太合理的流程里，藏在那些反复消耗时间、但因为问题太小一直没人专门解决的地方。文中列举的四个「小问题」（为订一小时球场每天开几十次小程序；半小时空场虽可订但无实际意义；电脑休眠后监控失效、云端任务偶尔漏跑、后台窗口抢焦点）恰恰都是产品经理本来就在做的事情：不断发现这些不顺手、不合理、不够好的地方，然后想办法让它往前走一步。创造力不一定表现为凭空想出一个惊天动地的点子，更多时候是你愿不愿意多问一句：这件事一定只能这样吗？有没有可能换一种方式？
-
AI 真正的意义是把「试」的门槛降下来，让想法离验证更近。过去很多想法会停在「不顺手」这一步：不是没有价值，而是实现成本太高——为了一个只服务自己的小需求专门找开发不现实，自己从头学技术又很可能还没学会就先放弃。AI 不会自动替我们发现生活中的问题，但当我们发现问题之后，它可以陪着我们把一个模糊的念头，慢慢试成一个能运行的东西。因此 AI 对 PM 的意义不只是写 PRD 更快、画原型更快，而是让想法离验证更近：以前提出想法要考虑有没有研发资源、能不能排进版本、值不值得投入；现在有些小想法可以先自己做一个最小尝试，跑起来再看有没有价值。哪怕最后只解决了自己的一个小麻烦，这个过程也完整地经历了发现问题、明确需求、设计方案、验证结果和持续迭代——本身就是一次很具体的产品实践。面对 AI 浪潮，更现实的选择是「先看懂它能做什么，再想清楚自己能借它做什么」，不必一开始就做完整的产品，先从身边一个真实的小问题开始，借它一点力，往前走一小步。
实操内容保留
原文是一篇叙事型复盘，没有给出完整代码、Prompt 模板或配置片段。以下保留作者明确描述的方案结构、关键约束与迭代判定规则——它们可直接迁移为同类「网页/小程序捡漏监控」的需求规格。
方案结构（最终形态）
| 环节 | 做法 | 关键约束 |
|---|---|---|
| 数据获取 | 找到目标小程序无需登录的只读查询接口（只返回场地/时段状态） | 不涉及占位、下单、支付；小程序不走普通系统代理，需抓包定位 |
| 触发频率 | 每半小时轮巡一次 | 云端执行时间避开拥堵的整点和半点 |
| 时间范围 | 当天 + 第二天，仅 19:00–21:00 | 白天场地再多也无价值 |
| 有效空场判定 | 同一片场地连续两个半小时时段（≥1 小时可订） | 场馆要求 1 小时起订，孤立半小时无意义 |
| 场地排除 | 排除价格过高的 1 号中心场 | 用价格做黑白名单而非全量监控 |
| 通知渠道 | 飞书机器人 | 工作日在线、手机及时可达 |
| 通知策略 | 每次轮巡只要符合条件就发（不再「每天只提醒一次」） | 漏订后仍会出现新空场，需持续提醒 |
| 可靠性 | 云端定时 + 本机兜底：先检查云端近期是否正常运行，只在云端失效时补查 | 避免云端漏跑导致静默丢失，同时避免两边重复发送 |
| 静默性 | 本机兜底任务改为完全静默的后台运行 | 避免 PowerShell 窗口闪动抢走工作焦点 |
| 安全边界 | 飞书密钥单独加密保存，不写进程序；只查询、不下单、不碰支付 | 只读接口 + 凭证隔离 |
迭代中暴露的问题清单（可作为同类方案的检查项）
- 「空」的判定口径：单格可订 ≠ 用户可用（需按最小起订时长合并判断）。
- 范围口径：默认全量监控会在无价值时段上浪费通知配额，应按用户真实关注窗口收窄。
- 通知渠道：不能用「需要人盯着看」的渠道（AI 工具内提醒），要选常驻可达渠道（企业 IM）。
- 运行载体：依赖本机进程 + 必须常开的小程序，等于方案随电脑休眠一起失效 → 迁到云端。
- 数据入口层级的跃迁：从「模拟人看页面」升级为「直连结构化只读接口」，是方案能否长期稳定的分水岭。
- 调度可靠性：云端定时任务会延迟与漏跑 → 错峰执行 + 本机兜底 + 去重。
- 打扰成本：兜底任务的副作用（窗口抢焦点）会让工具「开始打扰我」→ 静默化。
（原文无完整代码/配置文件；上表与清单为对原文所述方案的忠实结构化保留。）
关键概念
- 个人生活自动化：本素材是一次典型样本——需求方、使用方、唯一受益方都是作者自己；需求起点是一句生活化的抱怨而非需求文档；最终产物是一个只服务自己的只读监控。
- 场景架构：本素材的完整需求描述（什么时间、哪片场地、连续一小时、价格上限、通知渠道）几乎全部来自「打网球 + 订场」这一具体生活场景，而非抽象需求。它是「场景是需求被激发的原因」的一次自证。
- 飞书机器人：本方案选定并实配的通知渠道——创建机器人、配置发消息权限、找到用户 ID、发测试消息验证整条链路。
- AI Agent 智能体：本次 AI 承担的角色是「可长期协作的执行者」——写程序、抓包定位接口、配置通知、迁云端、排障、改兜底策略。
- MVP：第一版「每半小时看一次小程序」正是最小可跑版本；它的价值不是交付，而是把「什么叫有场子」「查哪些时间」这些问题逼出来。
- 产品思维：把「发现生活中的小别扭 → 定义需求 → 设计 → 验证 → 迭代」这套 PM 流程用在自己的小需求上，构成一次完整的产品实践。
与其他素材的关联
- 与 2026-08-08-agent-sport-checkin-data-governance 同属「用 Agent 处理个人生活琐事」的实战：那篇的抓手是「图片多、规则明确、又要留痕」的数据治理（人定规则、Agent 执行、异常标待核查），本篇的抓手是「数据源不公开、要自己找到只读接口」的监控自动化。两者共同说明：这类工具真正难的不是让 AI 写代码，而是把「什么算有效」的规则说清楚。
- 与 2026-06-10-用-codex-skills-红狐数据-api-搭一个-ai-热点雷达 的架构同构：都是「找到结构化数据源 → 定时拉取 → 按规则筛选 → 推送通知」，区别只是热点雷达用公开 API，本素材是一次非公开接口的逆向发现。
- 与 2026-08-11-woshipm-lingjichu-kao-AI-gao-dajihua / AI 协作模式 呼应：本篇的主张「AI 是持续协作的搭档，不是一次性交作业的工具」，正是 AI 协作模式在个人小需求上的最小规模体现——人只给目标（「有场子的时候提醒我」），执行层全交给 AI，人只负责判断「现在这样到底好不好用」。
- 与 2026-05-13-ai-agent-productivity-20x 的「跨 SaaS Agent 编排 + 定时调度」方向一致，但把尺度从「工作流提效」拉到了「个人生活捡漏」：定时任务 + IM 通知 + 兜底容错是同一套工程骨架。
原文精彩摘录
「如果真想捡漏，就得隔一会儿打开一次微信，再进入小程序，切换今天和明天，横向查看十几片场地。说实话，为了打一小时球，一天盯几十次小程序，实在有点折磨。……没有需求文档，没有流程图，也没有什么宏大的产品设想。就是一句非常生活化的话：有场子的时候，提醒我。」
「装了网络调试工具，开启了临时抓包，结果发现微信小程序并不走普通的系统代理；又尝试了其他办法，绕了一圈，最后才找到它查询场地时使用的、无需登录的只读查询接口。这个接口只返回场地和时段状态，不需要登录，也不涉及占位、下单和支付。……以前是让 AI 像人一样盯着页面看。现在则是直接读取结构化的场地数据，判断每片场地哪些时间可订，再把符合条件的结果发给我。」
「它不是一个真正的提醒工具，更像是找了个人坐在我的电脑前，定时替我看一眼。」
「结果每次本机兜底运行，PowerShell 窗口都会闪一下，抢走正在工作的焦点。这个工具确实开始提醒我了，也确实开始打扰我了。」
「我并没有一开始就把所有需求想清楚。事实上，我只知道自己不想反复刷小程序。至于孤立的半小时时段算不算、电脑休眠怎么办、提醒发到哪里、一天提醒几次、某片场地要不要排除、云端调度失败怎么处理，这些都是在实际使用中一点点暴露出来的。……如果 AI 只是严格执行第一句话，我们最后得到的大概率只是一个『可以演示』的东西。」
「它不会自动替我们发现生活中的问题，但当我们发现问题之后，它可以陪着我们把一个模糊的念头，慢慢试成一个能运行的东西。……产品经理的创新力和创造力，很多时候就潜藏在那些不起眼的小事里。以前我们看见了，也只能先放在那里；现在，我们终于多了一种把它做出来的可能。」