手机上用Claude Code开发：iNaturalist观察记录展示工具实战

概述

Simon Willison（知名开发者、Datasette 创始人）在一次露营旅行中，完全使用手机和 Claude Code 构建了一个展示 iNaturalist 自然观察记录的 Web 工具。这个项目展示了 AI 辅助编程在移动端的实用性，也提供了一套将多个简单组件串联成完整数据管道的架构参考。

Simon Willison 是 Python Web 开发领域的资深人物，他是 Django 框架的联合创始人之一，后来创建了 Datasette——一个将 SQLite 数据库即时转化为可交互 API 和数据浏览界面的开源工具。Datasette 的设计哲学是"让数据发布变得像发布网页一样简单"，这种对轻量级数据工具的执着追求贯穿了他近年来的大量项目。他同时也是 AI 辅助编程领域最活跃的实践者和记录者之一，在个人博客上持续分享使用大语言模型进行软件开发的经验和方法论。

项目背景：为什么要在手机上写代码

Simon 在 iNaturalist 上有两个独立账户，他想把这些观察记录按时间分组展示在同一个页面上。iNaturalist 是由加州科学院和国家地理学会联合运营的全球性公民科学平台，用户可以上传自己在野外观察到的动植物照片，平台通过社区协作和 AI 图像识别帮助鉴定物种。截至目前，该平台已积累超过 2 亿条观察记录，覆盖超过 40 万个物种，是全球最大的生物多样性开放数据源之一。iNaturalist 提供了完善的 RESTful API，允许开发者按用户、地理区域、物种分类等维度查询观察数据，这也是 Simon 这个项目的数据基础。

传统做法需要坐在电脑前花几个小时编写代码，但他选择了一种更轻量的方式——在露营途中用手机和 Claude Code 完成整个开发流程。

Claude Code 是 Anthropic 推出的命令行 AI 编程工具，它直接运行在终端环境中，能够读取项目文件、理解代码上下文、执行 shell 命令并自主编写和修改代码。与传统的 IDE 插件式 AI 助手不同，Claude Code 的纯终端交互模式意味着它对图形界面没有依赖——这恰恰使得它在手机终端应用（如 Termux 或通过 SSH 连接远程开发机）中也能流畅运行。开发者只需要用自然语言描述需求，Claude Code 就能完成从创建文件、编写代码到运行测试的完整开发循环。

这个选择本身就说明了一个趋势：有了 AI 编程助手，开发者不再被绑定在配备大屏幕和键盘的工位上。

技术架构拆解：三层组件设计

第一层：Python CLI 工具做数据聚合

Simon 首先构建了一个名为 inaturalist-clumper 的 Python 命令行工具，负责获取和"聚合"观察记录。核心逻辑是将时间间隔 2 小时以内、地理距离 5 公里以内的观察记录归为一组（clump）。

这种聚合策略很实用——它本质上代表了"一次外出观察"的概念，比简单按日期分组更贴合实际使用场景。从技术角度看，这是一种时空聚合（spatiotemporal clustering）的简化实现。经典的时空聚类算法如 ST-DBSCAN 需要同时在时间维度和空间维度上定义"邻近"关系，计算复杂度较高。Simon 的方案采用了更直觉化的贪心策略：按时间排序后，逐条检查新记录与当前分组最后一条记录的时间差和地理距离，如果都在阈值内就归入同组，否则开启新组。2 小时和 5 公里这两个阈值的选择反映了一个合理的物理假设——一个人在一次户外观察活动中，通常不会间隔超过 2 小时才记录下一个物种，也不太可能在单次活动中移动超过 5 公里。这种启发式规则虽然不如正式聚类算法严谨，但对于个人数据展示场景已经足够准确。

第二层：Git Scraping 实现自动化数据管道

第二步是设置 simonw/inaturalist-clumps 仓库，利用 Simon 自己推广的"Git Scraping"模式——通过 GitHub Actions 定期运行 CLI 工具，将结果保存为 clumps.json 文件并提交到仓库。

Git Scraping 是 Simon Willison 在 2020 年提出并大力推广的一种数据采集模式。其核心思想极其简单：利用 GitHub Actions 的定时任务功能（cron 调度），定期运行一个脚本去获取某个数据源的最新状态，然后将结果作为文件提交到 Git 仓库中。由于 Git 天然记录每次提交的差异（diff），这个仓库就自动变成了一个带有完整历史版本的数据存档。与传统的爬虫 + 数据库方案相比，Git Scraping 不需要维护任何服务器或数据库实例，所有数据以纯文本文件形式存储在 GitHub 上，天然具备版本控制、协作编辑和公开访问能力。这种模式已经被广泛应用于追踪政府数据变更、监控网站价格变动、记录 API 返回结果等场景，GitHub 上有数百个基于此模式的公开仓库。

这一设计有几个精妙之处：

天然支持跨域访问：GitHub 托管的 JSON 文件自带 CORS 支持，前端可以直接 fetch。CORS（Cross-Origin Resource Sharing，跨源资源共享）是浏览器的一项安全机制，默认情况下，网页中的 JavaScript 只能请求与当前页面同源（相同协议、域名和端口）的资源。如果前端页面托管在 example.com，想要通过 fetch() 请求 api.another.com 的数据，服务器必须在响应头中包含 Access-Control-Allow-Origin 字段来明确授权。GitHub 的 Raw 文件服务（raw.githubusercontent.com）默认在响应头中设置了宽松的 CORS 策略，这意味着任何域名下的前端页面都可以直接请求 GitHub 仓库中的文件，无需搭建代理服务器来中转请求——这对于纯前端的静态应用来说是一个极大的便利。
免费定时任务：GitHub Actions 提供免费的 cron 调度能力。GitHub Actions 是 GitHub 内置的 CI/CD 和自动化平台，对于公开仓库完全免费，私有仓库每月提供 2000 分钟的免费执行时间。开发者可以在仓库的 .github/workflows/ 目录下定义 YAML 格式的工作流文件，通过 schedule 触发器设置 cron 表达式来实现定时执行。例如 cron: '0 */6 * * *' 表示每 6 小时运行一次。需要注意的是，GitHub Actions 的 cron 调度并不保证精确到秒的执行时间，在平台负载较高时可能会有数分钟到数十分钟的延迟，但对于数据采集这类对时效性要求不高的场景完全够用。
内置审计轨迹：Git 提交历史自动记录每次数据变更

对于个人项目和小型数据管道来说，Git Scraping 是一种几乎零成本的自动化方案。

第三层：AI 一键生成前端展示页面

最后一步是前端页面。Simon 向 Claude Code 提供了一个精确的 prompt，要求构建一个 HTML 应用，具体需求包括：

从 GitHub Raw URL 获取 JSON 数据
使用 iNaturalist 的 small.jpg 缩略图展示所有观察记录
采用 loading=lazy 实现图片懒加载，优化页面性能
点击缩略图时在 HTML 模态框中显示大图
同时展示物种的通用名称

其中，loading="lazy" 是 HTML 原生的图片懒加载属性，于 2019 年在 Chrome 76 中首次实现，现已获得所有主流浏览器的支持。其工作原理是：浏览器在解析页面时，不会立即加载设置了 loading="lazy" 的图片，而是等到图片即将进入视口（viewport）时才发起网络请求。对于像 Simon 这个项目这样可能包含数百张自然观察照片的页面，懒加载能够显著减少初始页面加载时间和带宽消耗——用户打开页面时只需加载屏幕可见区域的几张图片，而不是一次性下载全部图片资源。在此之前，实现类似效果需要依赖 Intersection Observer API 或第三方 JavaScript 库，而原生属性的引入让这一优化变成了一行 HTML 属性就能完成的事情。

整个前端页面通过一个 prompt 就完成了生成，没有额外的手动调整。

三个值得借鉴的设计理念

手机上的 AI 编程：开发环境去中心化

这个案例最值得关注的一点是：整个项目完全在手机上用 Claude Code 完成。AI 编程助手正在降低开发对硬件环境的要求——你在通勤路上、咖啡馆里、甚至露营地都能产出可用的软件。

这不是说手机会取代电脑成为主力开发工具，而是说对于轻量级项目和快速原型，移动端 + AI 已经是一个可行的组合。

零运维的无服务器架构

整个架构不需要任何自建服务器：

功能	承担方
数据获取和处理	GitHub Actions
数据存储	GitHub 仓库（JSON 文件）
前端托管	GitHub Pages
CDN 分发	GitHub Raw 文件服务

维护成本几乎为零，也不用担心服务器宕机或账单超支。对于个人项目来说，这种"全部托管在 GitHub 上"的架构非常省心。

值得一提的是，这种架构模式可以被视为"无服务器"（Serverless）理念的一种极端简化实现。传统的 Serverless 架构通常依赖 AWS Lambda、Cloudflare Workers 等云函数平台，仍然需要配置触发器、管理环境变量和处理冷启动等问题。而 Simon 的方案将 GitHub 平台本身当作一个完整的 Serverless 基础设施来使用：Actions 充当计算层，仓库充当存储层，Pages 充当分发层。这种方案的局限性也很明显——它只适用于数据量较小（GitHub 单文件建议不超过 100MB）、更新频率较低（Actions 的 cron 最短间隔约 5 分钟，实际执行有延迟）、且不需要用户写入操作的只读展示场景。但在这些约束条件内，它几乎是成本最低、运维负担最轻的方案。

Prompt 即技术规格说明

Simon 分享的 prompt 本身就是一份清晰的技术规格文档，包含了数据源 URL、UI 交互逻辑、性能优化策略和功能需求。这种"一个 prompt 生成一个完整功能页面"的模式，对于数据展示类的轻量级工具特别有效。

关键在于 prompt 的质量：需求越明确、边界越清晰，AI 生成的代码就越接近预期。这实际上与软件工程中"需求规格说明书"（SRS, Software Requirements Specification）的理念一脉相承——区别在于，传统的 SRS 是写给人类开发者看的，而现在的 prompt 是写给 AI 看的。优秀的 prompt 和优秀的需求文档共享相同的特质：明确的输入输出定义、具体的技术约束、清晰的交互行为描述，以及对边界情况的预判。Simon 的 prompt 之所以能一次生成可用的页面，正是因为他作为资深开发者，能够精确地将脑中的技术方案转化为结构化的自然语言描述。

总结

这个项目规模不大，但它清晰地展示了一套实用的轻量级开发方案：Git Scraping 自动化数据采集 + 静态 JSON 存储 + AI 生成前端页面。

对于有类似数据展示需求的开发者来说，这个组合值得尝试：不需要后端服务器，不需要数据库，不需要复杂的部署流程，甚至不需要一台电脑——一部手机加上 Claude Code 就够了。