2023年夏天，我让ChatGPT帮我写了一段MicroPython代码。它运行在一块ESP32上，每隔几分钟读取家里的温度、湿度和空气质量，并把数据送进树莓派。
三年后，这套看起来很朴素的设备还在工作，数据库里已经积累了27万多条记录。
与此同时，我使用AI的方式已经完全变了。现在，我会在上班路上拿出手机，把需求交给Codex。它读取代码、修改文件、发起Pull Request，再由GitHub自动部署。很多时候，我到公司之前，一个新功能已经上线。
从网页聊天到Copilot，再到可以独立执行任务的AI Agent，我经历了三种完全不同的协作方式。回头整理才发现，最初的一段脚本，已经慢慢长成了传感器、小程序、照片直播、播客、婚礼网站、AI视频和3D模型。
这篇文章想把它们完整记录下来。
AI编程的三个阶段
ChatGPT在2022年11月30日公开发布。那时最常见的入口是网页聊天框：输入一个问题，等待一段回答，再把结果复制到其他工具中。
Copilot形态出现得更早。GitHub Copilot在2021年开放技术预览，但真正让我感受到AI进入开发环境，是我在2025年4月开始使用Cursor之后。AI能够看到更多项目文件，也能连续修改互相调用的脚本。
2025年，编程Agent密集出现：Claude Code在2月开放研究预览，Codex CLI在4月推出，Codex云端Agent在5月发布。AI开始读取整个仓库、运行命令和测试，并直接参与GitHub工作流。
这三个阶段一直互相重叠。下面的划分依据，是当时我主要怎样使用AI：
网页聊天阶段： 我描述问题，AI生成脚本，我复制、运行和排错。
Copilot阶段： AI进入编辑器，理解项目上下文，协助修改多个文件。
Agent阶段： 我提出目标，AI调用工具、执行任务、提交代码，并把结果交给我检查。
有趣的是，每一个阶段停留的时间都比上一个更短，能完成的项目却越来越长。
第一阶段：聊天框里写出的程序，真的运行了三年
刚开始使用ChatGPT时，我很快发现它很擅长写脚本。当时的模型很难掌控大型软件工程，对于MicroPython这类结构清晰、规模有限的程序，已经能提供很大帮助。我正在玩ESP32，于是让ChatGPT协助开发了一套家庭环境监测系统。
第一套长期运行的AI项目
项目从2023年6月开始运行。
ESP32连接BME280和SGP30传感器，采集温度、湿度、气压、TVOC和eCO₂等指标。数据写入SQLite数据库，再通过树莓派上的Superset进行可视化。ChatGPT还帮助我梳理架构、绘制示意图和编写技术文档。
截至2026年4月，数据库已经积累271,142条传感器记录。
这些数据记录了一个北京家庭内部的季节变化：夏天湿度升高，冬天供暖后空气明显变干，夜间通风减少时读数上升。SGP30给出的CO₂数据属于算法估算值，容易受到TVOC影响，因此更适合观察趋势。这个局限也让我逐渐认识到，AI可以快速生成分析，但传感器原理和数据边界仍需要人来判断。
三年持续运行的价值，远远超过最初那几段代码。它留下了一份真实、连续、属于自己生活的数据，也改变了我对个人项目的看法：只要程序真的进入生活，一个很小的想法也可能积累出意料之外的结果。
沿着这个思路，我开始把ChatGPT接到更多日常工具中。
一个不用Hook的微信机器人
当时我觉得，大语言模型聊天比传统的规则机器人有趣得多，于是尝试把它接进微信。
常见方案需要通过底层Hook读取微信消息，我担心账号安全，便选了一条更保守的路线：程序模拟鼠标点击，通过OCR识别屏幕上的聊天内容，再调用模型生成回复。
它只能处理一对一聊天，速度也谈不上快，却完成了从“屏幕上看到消息”到“自动给出回答”的闭环。这是我第一次把大语言模型接入日常通信工具。
一个运行在Lambda上的短链接平台
我还借助ChatGPT搭建了自己的短链接服务。输入一个很短的路径，便能跳转到经常使用的网站。
服务部署在AWS Lambda上，体量很小，维护成本也很低。它没有宏大的产品规划，只解决了我每天都会遇到的小麻烦。后来我越来越喜欢这类项目：先满足自己的需要，再看它能走多远。
第二阶段：AI进入编辑器，脚本开始连接成系统
在网页聊天阶段，代码通常以片段的形式出现。我需要反复复制、粘贴，把不同脚本连接起来。AI进入编辑器后，它可以查看项目结构，理解文件之间的调用关系，也能围绕同一个目标连续修改。项目的规模随之扩大。
辅助延时摄影的小程序
“延时摄影计算器”在2024年6月上线。
它帮助摄影爱好者根据拍摄间隔、素材数量和目标视频时长完成计算。进入Cursor阶段后，我继续用AI维护和迭代它。到2026年7月，小程序已有约1700名用户。
这个数字放在互联网产品中很小，对个人项目却很有意义。一个从个人需求出发的工具，在上线两年后依然有人使用，也依然值得继续维护。
一套成本很低的照片直播平台
当我开始使用Cursor，想做的事情很快从一个界面扩展到一整条链路。照片直播在会议、比赛和大型活动中已经很常见，商业方案往往需要按场次付费或购买年度服务，我便用Cursor做了一套自己的实现。
相机拍摄照片后，通过局域网实时传输到FTP服务器。服务端发现新照片后，自动上传至阿里云OSS，同时生成照片索引文件。前端只需要一份静态HTML，读取索引后便能持续展示最新照片。
分享链接还设有有效期，到期后可以自动下线。整个系统主要依赖OSS、静态页面和少量自动化脚本，利用云平台提供的免费存储与流量额度，实际成本几乎可以忽略。
过去，这种跨设备、跨服务的程序需要投入不少时间处理细节。Cursor让我可以先描述完整流程，再逐步检查每个环节。
用14000张照片观察小区早高峰
同一时期，我也越来越愿意把程序接到现实世界。2025年春天，我做过一次由好奇心驱动的小型研究。
有一天早上，我发现小区主路上的行人似乎很少，于是想知道：居民通常几点出门？工作日和周末有什么差别？大家什么时候遛狗？
我把树莓派、HQ Camera和25毫米镜头架在窗台，每隔10秒拍摄一张覆盖小区主路的照片。树莓派负责采集，图片通过局域网传到Mac mini；Mac裁剪画面后，使用YOLOv12x识别人、狗和自行车，再把时间与数量写入SQLite，最后导入Superset分析。
系统累计处理了约14,000张图片。初步结果显示，工作日8点至9点、17点至19点是行人高峰；周末分布更均匀；工作日遛狗集中在8点前后，周末则散布在全天。
实验也留下不少问题：夜间画面太暗，同一个人可能被多帧重复统计，远距离目标缺少足够特征。人工抽样显示，统计结果大约是真实数量的两倍。
这些缺陷没有让实验失去价值。它让我看到，一套由树莓派、本地模型和数据库组成的小系统，已经可以把生活中的一个疑问变成可分析的数据。回头看，第二阶段最重要的变化正发生在这里：AI开始陪我跨过文件、设备和云服务之间的缝隙，一个人的小项目也有了完整产品的形状。
第三阶段：从辅助写代码，到接手一整条工作流
2025年之后，我开始频繁使用AI Agent。这一阶段最明显的变化，是任务长度。过去我让AI写一个函数，后来让它完成一个页面，现在会把“做一套能运行、能发布、能长期维护的系统”直接交给它。
在手机上完成的婚礼网站
这种变化在我备婚时变得格外清晰。2025年12月之后，我用Codex制作了完整的婚礼网站，婚礼现场的抢答、抽奖等互动小游戏，也由AI Agent完成。
婚礼结束后，网站继续演变成家庭网站，用来记录纪念日、生活经历和宠物。
整个项目由Codex开发，通过GitHub CI/CD构建，自动发布到阿里云OSS和CDN。我没有手动敲代码，很多开发工作发生在上下班路上：拿出手机描述需求，Codex修改代码并发起Pull Request，我检查结果后合并，网站随即完成部署。
手机在这里已经变成了项目指挥台。写代码所需的连续时间被大幅压缩，零散的通勤时间也能推动项目前进。
每个工作日早上7点自动更新的播客
其实更早在2025年6月，Agent已经开始接手那些需要每天准时运转的事情。我上线了全自动网络安全播客《安全新鲜事》。系统每天从网络安全媒体的RSS中抓取新闻，写入SQLite数据库，再由阿里云百炼平台上的多个智能体分工完成新闻提炼、撰稿、内容审核、读音修正、节目标题和Show Notes。
读音处理是很具体的一步。例如，系统会把“Pwn2Own”转换成“Pwn To Own”，把“SQLI”转换成“SQL注入”，把“ATT&CK”改写成适合TTS朗读的“attack”。处理完成后，阿里云TTS生成音频，程序拼接片头片尾，再把文件和Podcast Feed上传到OSS，通过CDN发布到Apple Podcasts和小宇宙。
所有流程由调度器自动执行，异常会推送到我的iPhone。节目从上线至今一直更新，每个工作日早上7点准时发布。于是，我在上班的地铁上，可以听到一档当天早上刚刚自动制作完成的安全资讯节目。
自动查询天气，再把穿衣建议发到微信
同样在2025年6月，我还用阿里云百炼搭建了天气提醒助手。它每天查询天气和预警信息，根据温度、降水和风力生成穿衣建议，再把结果发送到微信。播客和天气提醒让我第一次拥有了两套会自己醒来、完成工作并主动找到我的系统。
做完这些长期运行的项目，我又把Agent带进了内容创作。
把当天的日记改写成2065年的故事
我用Codex搭建过一套文章生成与发布系统。
每天，我只需要写下简单的生活记录。Agent按照预设的Markdown结构提取内容，把现实中的一天映射到2065年，改写成带有未来科技背景的短篇日记。
例如，现实中的自动驾驶变成了“私人智能仓”，普通剧场变成使用低密度光场布景的艺术中心，生活细节仍然来自当天真正发生的事情。
这个栏目只连载了三天。原因也很直接：没有什么流量，于是我停更了。
AI让内容生产变得很快，读者是否愿意看依然由选题、表达和传播决定。一次没有流量的实验，同样会留下有用的结论。
把AI视频的前期工作交给Agent
单次生成AI视频并不困难，真正耗时的是前期准备：扩展脚本、拆分镜头、制作参考图、设计首尾帧，再为图片、视频和音乐分别编写提示词。
我的做法是只提供创意和简要脚本，再让Codex完成详细分镜，并通过LibTV相关Skill组织后续生成流程：为每个片段准备参考图、首尾图、图片提示词和视频提示词，再调用生成工具制作视频片段。
最终剪辑仍由我使用传统方式完成。镜头节奏、情绪控制和素材取舍需要大量个人判断，AI则承担了重复而繁琐的前期工作。配乐提示词也交给AI生成，最终成片的效果比我最初预想得更完整。
从一段描述到可以打印的3D模型
视频之后，我又把这条路延伸到3D设计。其中一个项目是拍立得方形相纸收纳盒：GPT-5.1生成OpenSCAD代码，再转换成可以3D打印的模型；盒盖文字可以通过参数修改，最终版本能够收纳约50张Instax Square相纸。
代码、模型和实体物品在这里连接到了一起。AI输出的内容离开屏幕，变成了真正可以拿在手里的东西。到了这个阶段，我已经很难用“写代码”概括自己在做什么，更像是在调动代码、模型和各种工具，把一个想法一路推到可使用、可收听、可观看甚至可触摸的结果。
三个阶段，改变的是我与软件之间的距离
回看这些项目，三个阶段各有一种典型动作。
网页聊天阶段，我不断复制代码、运行代码，再把报错贴回聊天框。
Copilot阶段，我和AI共同面对一个项目。它理解上下文，我决定结构和方向。
Agent阶段，我开始描述目标、约束和验收标准，让AI完成中间的大量操作。
AI当然没有让所有项目都成功。小区人流实验存在重复统计，SGP30无法提供准确的CO₂浓度，“未来日记”没有流量，AI视频仍然需要人工精细剪辑。真实项目总会带着限制运行。
但它确实缩短了想法与成品之间的距离。
三年前，我因为一段MicroPython脚本感到惊喜。今天，我已经习惯在手机上管理会自己读取代码、运行工具和提交PR的Agent。下一步也许是更复杂的3D设计、更长的视频生产流程，或者一批同时工作的Agent。
我还不知道会做出什么。
好在现在，一个想法出现之后，已经可以立刻动手了。