最近我把日常收短信这件事折腾成了一套自动化流程手机收到的验证码、快递通知、 APP 提醒会按规则自动变成滴答清单里的待办任务。整个过程我几乎没有手写几行代码全靠用大白话指挥 Gemini 3.0 去理解和实现接口对接。如果你也在玩 AI 编程或者正打算用 AI 省掉“从零抄代码”的时间这篇实录应该能给你一点可复用的参考。先说清楚这套东西到底解决了什么问题。随手记待办这个习惯我坚持了很多年但短信不一样它来得随机、又是强通知经常是“看到短信——切到清单——新建任务”这个动作被手上正在做的事情打断等忙完短信又被新通知淹没了。于是我就想能不能让 Gemini 3.0 帮我写一个中间服务让短信自己变成清单任务答案是可以而且用“说人话”的方式从需求拆解到接口调通比想象中顺利。这篇文章适合两类人一类是想用 AI 编程提高效率但还没找到合适姿势的开发者另一类是对“短信、滴答清单、接口”这几个词都有点概念、但不知道从哪下手去拼装这个流程的人。我会把具体的对话思路、接口定义、代码骨架、以及我踩过的坑都写出来。1. 接到需求后先别急着写代码想清楚“人”怎么“说话”1.1 这条短信和清单到底在“连”什么很多人拿到“用 AI 写代码”的需求第一反应是把需求一口气丢给模型比如“帮我写一个程序把短信转成滴答清单”然后等着输出一坨几百行的代码。这样不是不行但大概率会卡在接口文档和异常处理上。我这次的做法是先画链路和人说话一样把流程说清楚。短信到滴答清单核心就三步手机收到短信把短信内容推送出去一个自定义服务接收短信并做处理处理完毕后调用滴答清单的开放接口创建任务。最难的不是最后一步的“调用”而是中间那截“接收和处理”。接收方式有很多比如自己做个安卓应用监听通知、用运营商邮箱转发、或者用现成的短信转发工具把新短信 HTTP POST 到指定地址。我选的是最通用的方案手机端短信转发器 一个自建 Webhook 服务。自己造轮子之前先想清楚数据格式。短信转发器推送过来的数据一般包含发件人号码、短信内容、接收时间、短信唯一 ID 这些字段。而滴答清单创建任务只需要一个标题其他都是可选项。所以中间服务要做的事就是拿到短信字段把短信内容清洗成合适的标题再封装成滴答清单 API 要求的结构发出去。这个“翻译”过程恰恰是让 Gemini 3.0 写代码时最能体现“说人话”价值的地方。1.2 为什么是 Gemini 3.0 而不是传统方式传统方式下我要自己翻滴答清单 API 文档、验证 OAuth2.0 流程、处理回调地址、写 token 刷新逻辑再搭一个 Webhook 服务。光是看完文档、把认证流程跑通就够吃半天的。AI 编程的价值不是“不写代码”而是把“查文档、套模板、拼接口”这部分最机械的工作压缩掉。Gemini 3.0 对自然语言的理解比我预期更顺。它能把“短信来了就建任务”这种模糊描述转成具体的函数逻辑还能在我追问时主动补出鉴权、去重、日志这些工程细节。注意我不是说它一次就能写对而是说它的“初稿质量”足够高我只需要在它生成的代码上做少量修正。这个体验和用搜索引擎查 Stack Overflow 完全不同搜索引擎给你的是别人的完整答案你还要自己适配而 Gemini 给的是“听懂了你的话之后”的定制代码虽然偶尔有错但修正成本低很多。当然我也得泼一盆冷水。AI 编程再强也要求你本身对“接口大概长什么样”有基本概念。你要是完全不懂 HTTP、JSON、token那 AI 生成的代码一旦报错你连往哪个方向排查都不知道。建议把它当成“一个特别聪明但偶尔走神的实习生”而不是“全知全能的老程序员”。1.3 AI 编程适合什么场景不适合什么场景适合的场景个人自动化小工具、原型验证、内部系统脚本、数据清洗、接口粘合层。这些项目规模小、边界清楚、即使写错也不会有严重后果。不适合的场景涉及支付、账号体系、高并发交易、医疗数据等地方AI 生成的代码必须经过严格人工审查不能直接信任。我的原则是AI 写的代码每一段我都要能看懂它在干什么尤其是涉及 token 和用户数据的部分。这次短信对接滴答清单属于非常典型的“个人工具型”AI 编程场景单用户、低频调用、逻辑简单、接口公开。所以我可以放心让 Gemini 3.0 发挥把更多精力花在需求描述和边界条件上。2. 核心难点拆解接口、幂等和鉴权一个都不能少2.1 滴答清单开放接口的“最小可用集”滴答清单的开放接口重点是认证和创建任务这两个环节。认证用的是 OAuth2.0 授权码模式先在开发者后台创建应用拿到 client_id 和 client_secret然后引导用户访问授权页同意后回调地址会带上一个授权码再用授权码去换访问 token。整个过程听起来绕但 Gemini 其实很熟这套流程只要你把回调地址写清楚它生成的代码基本能直接跑通。最小可用集其实就三个请求第一个是访问授权页第二个是拿授权码换 token第三个是带 token 调创建任务的接口。创建任务的核心接口是 POST /api/v2/task请求头带上 Authorization: Bearer 你的访问令牌请求体传 JSON其中有 title 是必填项content、priority、tags、dueDate 这些是选填项。这里有个容易忽略的点滴答清单接口的创建任务默认返回 200 不代表一定创建成功你要看返回体里的 id 字段有 id 才算真正建了任务。Gemini 生成的代码里如果只是打印状态码就可能出现“看似成功实则没建”的情况需要人工补上这个判断。2.2 短信入口怎么选转发器 Webhook 是通用解我不建议从零写一个安卓短信监听应用维护成本实在太高。通用做法是借助手机上的短信转发工具这类工具能监控新短信并以 POST 请求方式转发到你配置的 URL。你的 URL 就是一个 Webhook 接收端这也是整个流程里短信进入系统的大门。选择短信转发器的时候要注意三点第一它能否自定义 POST 的 JSON 字段名这决定了你让 Gemini 写解析代码时的字段映射第二它是否支持自定义请求头这对接下来的鉴权很重要第三它能不能带短信的唯一标识这个标识是做幂等去重的关键。我使用的方案里自动带上发送号码和短信时间戳已经足够用来生成唯一指纹。有一点需要特别小心很多短信转发工具为了保证送达会开启失败重试。也就是说同一条短信向你服务端 POST 了两次甚至三次是很常见的事。如果你不做去重用户就会收到两条一模一样的滴答清单任务。这不是 AI 的问题是你在向 Gemini 描述需求时必须主动提出来的“重复推送”场景。2.3 幂等和鉴权AI 代码最容易被坑的地方让 Gemini 写第一版代码它通常会生成一个“接收短信直接创建任务”的朴素版本。这个版本在演示时没问题一旦放到真实环境很快就暴露两个问题。第一个是重复推送导致的重复任务第二个是任何人只要知道你的 Webhook 地址就能往你滴答清单里塞垃圾任务。幂等处理说白了就是给每一条短信算一个唯一指纹。指纹可以用“发件人号码 短信内容 接收时间”拼起来做 MD5每次接收短信时先查这个指纹有没有处理过处理过就直接返回“重复”,不再触发创建任务。这里要注意指纹集合必须持久化不能只存在内存里否则服务一重启就丢失记忆照样会重复创建。我让 Gemini 把已处理指纹存到了一个轻量 SQLite 表里重启之后也能继续去重。鉴权处理就是让 Webhook 只认你的转发器。最简单的办法是约定一个自定义请求头比如 X-Forward-Token转发器请求时必须带上这个值服务端校验不对就直接返回 403。因为转发器支持自定义请求头所以这个方案实现起来非常容易Gemini 生成的 FastAPI 代码里顺手就写进去了。千万别把这个值放在 URL 里日志一打印就泄露了。3. “说人话”的实战我这样指挥 Gemini 3.0 一步步搞定3.1 第一轮对话把整个流程描述成一张“需求清单”和 Gemini 对话最忌讳的是只给一句抽象的需求。我的习惯是先把需求拆成清单式描述再附上关键字段例子。第一轮对话我大概是这么说的“我要实现一个个人自动化服务。手机上的短信转发器会把新短信 POST 到一个 Webhook 地址请求体是 JSON里面包含 sender、content、time 三个字段。我需要你用 Python FastAPI 写一个服务接收这个请求后调用滴答清单的开放接口创建任务任务标题就是短信内容的前 30 个字优先级设为中。另外 Webhook 要加一个自定义请求头校验只有带正确 token 的请求才处理。先给我完整的代码骨架和依赖清单。”注意这句话里的几个关键信息输入格式JSON 字段名、目标接口滴答清单、业务规则标题取前 30 个字、优先级中等、安全要求请求头校验。Gemini 拿到这些信息就不会再去猜你要干什么生成的代码直接贴合你的字段结构。我第一次输出时Gemini 给的代码骨架已经包含了 FastAPI 应用、POST /sms 路由、token 校验逻辑和调用滴答清单的函数。虽然接口地址写成了占位符但整体结构没毛病。我不急着一次性让它写完认证流程而是先把骨架跑通再说这样后续迭代更稳。from fastapi import FastAPI, Header, HTTPException import hashlib import os import httpx app FastAPI() PROCESSED_DB processed.db app.post(/sms) async def receive_sms( payload: dict, x_forward_token: str Header(default), ): if x_forward_token ! os.getenv(WEBHOOK_TOKEN): raise HTTPException(status_code403, detailinvalid token) # 生成唯一指纹做幂等 raw f{payload.get(sender)}|{payload.get(content)}|{payload.get(time)} fingerprint hashlib.md5(raw.encode()).hexdigest() if is_processed(fingerprint): return {status: duplicated, fingerprint: fingerprint} title (payload.get(content) or )[:30] await create_task( titletitle, senderpayload.get(sender, ), timepayload.get(time, ), ) mark_processed(fingerprint) return {status: ok, title: title}这里的 is_processed 和 mark_processed 函数Gemini 会自动帮我补出来通常是用 sqlite3 连接本地库。我只需要检查一遍表结构和字段类型再跑一下冒烟测试就行。第一轮对话到这里我已经有一个能接收短信并检查 token 的服务雏形了。3.2 第二轮对话补上滴答清单的授权与令牌刷新第一轮生成的 create_task 函数大概率是假的里面 token 往往是硬编码的占位符。所以第二轮我会继续提需求让 Gemini 把完整的 OAuth2.0 授权流程补上。我当时的大致描述是“滴答清单的接口需要 OAuth2.0 认证。请你再帮我生成两个部分一是 /authorize 和 /callback 两个路由authorize 用来拼接授权页地址callback 用来接收授权码并换取访问令牌二是把换取到的访问令牌和 refresh_token 保存到本地create_task 函数要从保存的令牌里读取并且当接口返回 401 时自动用 refresh_token 刷新令牌后重试一次。”这个描述里面我主动指定了“回调路由”“刷新令牌”“401 自动重试”这几个关键细节等于把工程里最容易出问题的部分提前标了出来。Gemini 生成的代码会用到 requests 或 httpx 去请求滴答清单的 token 接口保存令牌的方式也可以选 JSON 文件或 SQLite。我最终选了 SQLite因为和幂等指纹放在同一个数据库文件里备份非常省事。这里有一个很多人都容易踩的坑回调地址必须和你在滴答清单开发者后台填写的 redirect_uri 完全一致不能差一个斜杠也不能用 localhost 和 127.0.0.1 混着填。我一开始让 Gemini 帮忙拼授权地址它在回调地址里加了路径 /callback但后台填的是 /cb结果授权页直接提示 redirect_uri 不匹配。改成一致之后授权流程立刻通了。这个教训说明不管 AI 多聪明你都得把接口注册信息准备好AI 不会替你去控制台点按钮。3.3 第三轮对话让代码跑起来并优化日志与异常骨架有了、认证通了接下来就是让它在真实场景里稳定跑住。第三轮对话我主要关注三类问题日志、异常、可观测性。对 Gemini 的描述是“请给整个服务加上日志收到短信时打印 sender 和时间创建任务成功时打印滴答清单返回的 task id创建失败时打印异常堆栈。另外如果滴答清单返回 429 限流要等 1 秒后重试一次不要无限重试。”这轮对话的价值在于Gemini 3.0 能自动把 try-except、logger.info、重试逻辑都补进去。你只要在测试过程中发现“下次要能看到更详细的错误信息”就直接用大白话描述现象让它改代码。这种“需求描述 自动修改”的循环一次可能只要几分钟比过去自己写日志再 debug 快多了。重试这里要提一个原则不要无限重试。Gemini 默认可能生成一个 while True 的重试循环一旦接口持续报错服务就会一直阻塞在那里。我明确加了“最多重试一次”这样即便滴答清单临时不可用请求也会快速失败并把异常写进日志至少不会把整个服务拖死。4. 上线后躲不开的坑常见问题与排查实录4.1 短信重复推送导致重复任务我上线后第一条任务就出现了重复手机收到验证码滴答清单里却冒出了两条任务。原因我前面说过短信转发器有失败重试机制第一次请求返回超时它自动重发了同一份数据。我的幂等逻辑虽然在但第一次请求因为网络闪断没有正常返回转发器就重试此时服务端其实已经处理完了只是响应没送达而已。这种情况下单纯靠内存集合去重已经不够稳妥所以我让 Gemini 把幂等指纹写入 SQLite并且处理完指纹之后才返回成功。同时我在 POST 接口里把“已处理”状态返回固定为 200而不是 500避免转发器误以为失败继续重试。改完后再测试重试机制来了也能稳稳定住不会出现重复任务。这里给你一个速查判断标准如果出现“同一条短信收到两次”先看转发日志里有没有重试记录再看服务端日志里收到的请求时间是否接近最后看幂等判断是放在“创建任务之前”还是“创建任务之后”。放在创建之前即使创建失败也可能被误判为已处理需要你根据实际需求权衡。4.2 授权过期、时区错乱、编码乱码授权过期是第二个高频问题。滴答清单的访问令牌有时效超过有效期调用接口会返回 401。如果你一开始写死了 token过期后所有任务创建都会失败。这时日志里会频繁出现 401 Unauthorized。解决方法是让代码在收到 401 时自动使用 refresh_token 换新令牌新令牌写回数据库。Gemini 可以帮你把这个逻辑写得非常完整但你要提醒它“刷新令牌如果也失败了要打印明确错误不要静默吞掉”。时区错乱主要出现在创建带 dueDate 的任务时。滴答清单接口对日期时间格式有严格要求通常是 ISO 8601 格式并且带时区偏移。如果短信接收时间直接取的是手机本地时间那么跨时区场景下任务时间就会对不上。我的建议是服务端统一用 UTC 存储时间和滴答清单交互时就传 UTC 的 ISO 格式避免你人在东八区、服务却跑在西五区的诡异问题。编码乱码的经验也要记一笔。第一次跑通时滴答清单任务标题里的中文没问题但短信内容里的部分特殊字符比如单引号、emoji到了标题里会显示成问号或者直接截断。排查下来问题出在 JSON 序列化时 ensure_ascii 设置不对以及数据库表用的字符集不是 UTF-8。Gemini 生成的代码里请求体默认 json.dumps 是 ensure_asciiTrue改成 False 之后中文显示就正常了。4.3 排查三板斧日志、接口文档、最小复现如果你跑通了这套流程但某个环节还是有问题我建议你用三板斧排查而不是盲目让 AI 改代码。第一板斧是日志。必须保证每次请求都有迹可循包括收件人、内容摘要、创建任务返回体或报错内容。日志里没有“某条短信到底处理到哪一步”的信息AI 再强也是瞎猜。第二板斧是接口文档。调用滴答清单接口报 422 时多半是请求体字段名写错了比如 title 写成了 name。这时候与其让 Gemini 改代码不如直接对照官方接口文档检查字段。你可以把文档关键段落发给 Gemini让它根据文档修正代码效果远好于让它凭空想象。第三板斧是最小复现。遇到“某条短信创建失败其他短信成功”的情况把这条短信的原始 JSON 存成一个文件单独构造一个请求去调服务看能否稳定复现。能稳定复现就说明是业务逻辑的边界问题不能稳定复现就要怀疑转发器的推送时机或网络问题。这套排查流程和传统开发没有本质区别AI 只是帮你把代码写快了并没有帮你绕过工程问题。异常现象常见原因排查方向403 ForbiddenWebhook 请求头 token 不匹配检查转发器自定义请求头是否与 WEBHOOK_TOKEN 一致401 Unauthorized滴答清单令牌过期或失效检查刷新令牌逻辑是否自动换新422 Unprocessable Entity请求体字段名或类型错误对照官方文档检查 title、priority 等字段redirect_uri 不匹配回调地址与后台注册不一致保证授权页拼接的 redirect_uri 与后台完全一致重复任务幂等指纹未持久化或处理顺序错误将指纹保存到数据库并在创建任务前判断中文乱码JSON 编码或数据库字符集问题设置 ensure_asciiFalse库表使用 UTF-8服务重启后失效使用了内存集合存状态迁移到 SQLite 或文件存储转发器超时重试首次处理时间过长或返回 5xx缩短处理流程返回 200 表示已接收已处理5. 最后再分享一个小经验持续跑了两周之后这套“短信转任务”的自动化已经成为我每天离不开的后台工具。手机一收到验证码滴答清单里几乎同步就出现一条带“短信”标签的任务密码管理、快递取件、账号通知全都有据可查。如果你也想复刻这套思路我建议从最小版本起步先用钉钉或微信机器人作为发送端把“发送消息—接收—创建任务”链路跑通再替换成短信转发器。这样你能先验证 AI 生成的代码是否有基本可用性再逐步引入短信这个外部依赖。等链路稳定了你再去让 Gemini 增加幂等、鉴权、日志一步一步往工程化靠拢。如果把这段时间和以前纯手写代码的做法对比最大的变化是我花在“描述需求”和“评审代码”上的时间变多了花在“翻文档”和“查语法”上的时间大幅下降。但这并不意味着 AI 编程能取代你思考它更像是给你配了一个可以随叫随到的结对编程伙伴前提是你得能清清楚楚地说出自己想要什么。
