AI 到底能不能写产品软件?我用 AI 搓了一个小程序,你们看看怎么样

这句话不是喊口号，是我做完下面这个小程序之后，最真实的一点体会。

一、两个身份，一个痛点

先交代一下背景，否则后面的话你不一定信。

我是一名非典型程序员：写过不少代码，但主业不是写小程序代码，是写嵌入式代码的。日常和 Xilinx Zynq、FPGA 原型验证平台、嵌入式工具链打交道——写驱动、写工具、和硬件寄存器较劲。说得直白一点：我懂软件，但不懂小程序；更不懂互联网那一套前端 + 后端。

我也是一名非严肃跑者：跑马拉松，也跑越野，成绩平平，重在参与。不是那种周周拉练、月月参赛的严肃跑者，但一年到头也会报好几场比赛。

于是就有了一个很典型的痛点：

想报一场比赛，得先关注一堆赛事公众号，等着它们推文。

在朋友圈或跑群里刷到一篇规程，点进去读完，然后拿备忘录记下报名时间和开赛时间——到了报名那天，要么忘了，要么找不到那篇推文了。

这类 App 其实早就有，但大多太重了：要注册、要登录、要绑手机号，一打开先弹一堆弹窗，想找一场比赛得先学会整套操作。我想要的只是一个"看看最近有什么比赛"的工具，不是另一个需要我花时间伺候的 App。

至于跑完的比赛，更没有地方沉淀。你跑过哪些城市、拿过哪些成绩、哪年是 PB，全靠记忆。

这恰好是我要的东西：需求真实存在，但规模小到大厂看不上——正好拿来做一个 AI 实验。

先说明白：它首先是一次试验，但它也确实是个能用的产品。这两件事不冲突。

我不是要创业，也没打算靠它赚钱。我只是想知道：在 AI 的帮助下，"有想法但不会做"这件事，到底还算不算一个障碍？需求是真需求（我自己就在用），所以它做出来就是能用的东西；但做它的动机，一半是解决自己的痛点，一半是纯粹好奇。

需求明确、规模不大、我有全部领域知识、我不需要它赚钱。—— 这正是检验"AI 到底能不能写软件"的最好靶子。

二、先看一眼它长什么样

小程序叫「跑马助理」，定位一句话：

面向国内马拉松 / 越野 / 铁人三项跑者的赛事助手。

打开就是四个页面：

「赛事」是主视图，一屏就是一张张赛事卡片：赛事名、状态胶囊（报名中 / 报名未开始 / 筹备中 / 报名截止 / 比赛中 / 已结束）、日期、城市、项目组别。

想筛什么，拉一下筛选抽屉：赛事状态 / 地区 / 时间三个维度，地区覆盖全国 34 个省级行政区。

这里有个细节值得说一下。时间档位不是我想当然写的，是迭代了几轮才定下来的。最早有一档叫「本周末」，用了几次发现完全不好用——周六早上打开，本周末的比赛已经开跑了；周日晚上打开，「本周末」指的是下个周末。最后一刀砍掉，改成了「一周内」（今天起 7 天），语义终于清晰。

这种"用起来别扭"，是我自己作为用户才会最先发现的。专业开发团队做需求评审时，大概率会通过「本周末」这个设定；只有真的每周都拿它找比赛的人，才知道它别扭在哪。

三、功能清单：不为炫技，只为解决问题

下面这张表是我按「解决什么问题」整理的，不是功能罗列。

1. 赛事三视图：列表 / 日历 / 地图

同一个赛事库，三种看法：

日历那个「双维度」是我坚持加的：你真正做报名决策时，看的是报名时间；安排行程时，看的才是比赛时间。这两个时间点往往差好几个月，只有一个维度是不够用的。

地图页这里也有个迭代痕迹：一开始筛选器是照搬列表页的胶囊样式，结果地图顶栏浮在浅色底图上，白字胶囊整条看不见。改成了白底深字 + 选中深绿反白。这不是设计规范问题，是"跑到真机上才看得见"的问题。

2. 赛事详情 + 同天赛事 / 附近赛事

点进一场比赛，除了基本信息，页面底部还有三个可以左右切换的栏目：

「附近赛事」是我个人最喜欢的一个。你去外地跑马，落地了才发现「原来同周末隔壁城市也有一场」，这种感觉挺好的。

3. 完赛记录 + 证书 + 一键出图

这是整个小程序里我自己用得最多的部分。

跑完一场比赛，记录一下：项目、成绩、名次，再把完赛证书拍张照传上去（纯图片保存，不识别、不上传解析，单张小于 2MB，每人每年上限 12 张）。

所有记录汇成一条垂直时间轴，一年一年往下排。想要分享，点一下「生成时间轴图片」：

一张竖版海报，含比赛卡片、证书缩略图、统计数字（跑过的马 / 跑过的城）、地图点位、页脚一句随机寄语、底部小程序码。生成完走微信原生图片预览，长按可以保存 / 转发 / 收藏。

这份"跑者档案"是我做这个项目最原始的动力。比赛年年跑，但除了相册里的奖牌照片，什么都没留下来。

顺便交代一个取舍：证书我一开始是想做成"自动识别"的（拍照就能读出成绩、名次，自动关联到赛事）。后来砍掉了，改成纯图片保存 + 手动关联。原因不是技术做不到，而是机器识别完，用户还是要核对、要确认、要修正——识别错一个成绩，比让他自己填十秒钟更让人恼火。这个功能留着以后再说，但当前版本不值得。

4. 报名提醒 + 站内信

赛事状态有变化（开放报名 / 报名截止 / 改期 / 取消 / 开赛）时，通知你一声。

这里我把两个概念拆得很清楚，因为混在一起就是坑：

为什么要拆？因为「收藏」是低频的随手动作，「提醒」是需要授权的正式承诺。以前把两者焊在一颗按钮上，结果是——大部分人收藏了，但从来没授权过推送，于是永远收不到任何消息，还以为是 bug。

5. 赛事线索：用户提交，我来收录

这个功能解决的是"信息源头"问题。

比赛信息最权威的来源就是组委会公众号发的竞赛规程。所以「提交赛事」入口只接受微信公众号文章链接，你在公众号文章页点右上角「···」→ 复制链接，粘进来就行。

后端会去读这篇推文，自动把关键信息一条条摘出来：报名时间、比赛项目、报名费、发枪时间、赛事等级、参赛规模、路线、是否抽签……然后进我的后台待收录列表，我核对一眼确认上架。

同一篇文章，从不同入口分享出来，链接尾巴上会带一串不一样的小字符。所以入库前会先把这串尾巴去掉，同一篇推文只会产生一条线索，不会重复。

四、AI 到底帮我做了什么？（干货部分）

好了，前面都是产品介绍。如果你是从业者，你关心的是这一段。

先给一个诚实的定位：

AI 真正强的三件事

① 把"想法"翻译成"能跑的代码"，中间不需要我打字。

我的工作方式是：我描述行为，它写实现。

举两个真实例子。

一个是我要给小程序加「附近赛事」，按距离由近到远排。我提的需求是：

列出距当前赛事 200 公里内的赛事，直线距离、由近到远、只列未来的。当前赛事没有位置信息就不显示这一栏。

它给出的实现里用到了云数据库的地理查询。跑起来报了一条错：

Class constructor Point cannot be invoked without 'new'

翻译成人话：位置信息这类特殊数据，系统只接受一种固定的写法，它一开始写错了。这类坑在文档里不显眼，得翻半天才找得到。它是自己定位到根因的，一次改好。

这个错误的定位速度，比我翻文档快。

第二个例子更典型。小程序里有个页面，昵称输入框空着的时候，点它没有光标、也不弹微信昵称建议。我第一反应是能点到的地方太小了，让它把点击区域撑大点。它照做了，结果——

文字整个消失了。

它给出的解释让我印象很深。这个项目全局定了一条规矩：盒子先定尺寸，往里塞内容——就像先做好一个固定大小的相框，再把照片塞进去。在这个规矩下，把"点击区域"撑大，挤的是里面的文字，而不是外面的框。一个原本高 48 的输入框，被硬塞了 36 的点击区之后，留给文字的空间算出来是负数，直接被压成 0——文字连同提示语，一点显示的地方都没有了。

正确解法是：把框本身加高来获得点击区域，再让文字在这一行里垂直居中，而不是靠加点击区去挤。

说句实话：这个道理我自己是懂的。但我大概率会先试两轮、跑起来肉眼看、再回头反思。它一次就把因果链说清楚了，而且主动把"为什么上一轮的改法是错的"一并写进注释。

② 把"重复劳动"吞掉。

这个项目一共 23 个页面、18 个后端服务、14 张数据表。如果全靠自己手写，光是页面骨架、服务样板、格式化和检查逻辑，就够我写两个月。

现在这些是它的活。我只需要决定"这一页要有什么、这个字段该叫什么"。

换句话说：它替我省下的不是打字的时间，是"跨过陌生领域"的时间。我不需要先去学一遍小程序怎么做、再学一遍后端怎么写，才能动手。它把学习成本也一并吞掉了。

③ 当我的"第二双眼睛"。

它有个我很依赖的习惯：改完主动回读、主动找自相矛盾的地方。

有个例子：我做「同天赛事」这一栏的时候，它给三个栏目各自起了名字来记状态。结果发现——如果页码、到底加载完没有，这些信息三个栏目共用一份，就会串台（切到「同天赛事」，显示的却是「赛事资讯」的页码）。它自己把三个栏目彻底分开，各管各的。

这种"改 A 的时候顺手想一下 B 会不会受影响"，是资深工程师的直觉。它现在有。

AI 真正弱的三件事

① 它不知道"用起来别扭"。

前面说的「本周末」档位，就是它不会主动砍的。因为从逻辑上挑不出错：本周末就是本周六到本周日，没毛病。

问题在于——周六早上用一次你就知道有多蠢了。这需要"我是这个产品的用户"。

② 它不知道"业务上该不该这么做"。

证书要不要自动识别成绩，是纯粹的产品判断，AI 给不了。它能告诉你"识别准确率大概 95%"，但判断不了"剩下那 5% 要用户自己核对的麻烦，比让他手填还大"。

③ 关键的"最后一公里"，还得人来验收。

AI 写的代码会有静默错误——不报错、不崩溃，但行为是错的。

这个项目里有好几个典型：

这些错误的共同点是：所有测试都能通过，只有真实用户能撞见。

所以我给自己的规矩是：AI 写代码，我验证行为。每个功能我都真机跑一遍，用我自己跑马的经验去撞它。

一个更重要的发现

用了这么久，我最大的体会不是"AI 能替代程序员"，而是——

AI 把"实现"的成本压到接近零，"判断"的成本反而被放大了。

因为实现变便宜了，你会做出更多东西，也就需要做更多判断：

这些判断，AI 会给你答案，但不会替你负责。

我现在的做法是：让它先把方案和理由讲清楚，我确认方向；确认完，它一次做到底。方向对了，实现交给它；方向错了，写得再快也是白搭。

五、结论

回到标题的问题。

AI 到底能不能写软件？

我的答案是：能写出"能跑的软件"，但写不出"值得用的产品"。

这两者的差距，就是人的价值所在。

如果要用一句话总结这次试验的体会：

AI 让"不会写代码的人"能做出软件，让"会写代码的人"能做出更多软件。但它替代不了"知道该做什么"的那个人。

那个人，得是你。

六、最后，请你们看看怎么样

说回这个项目。

「跑马助理」现在已经上线了，功能也齐了：赛事三视图、详情页、同天 / 附近赛事、完赛记录时间轴、证书管理、一键出图、报名提醒、赛事线索提交。

跑马助理

我一个人，加上一个 AI，就这么把一个想法做了出来。

说实话，我自己是有点意外的。不是因为功能有多复杂，而是因为——按以前的方式，这件事我根本不会开始。不是不想做，是"要学的东西太多、要写的东西太多"，光想想就劝退了。

如果你也有一个搁置很久的小想法，一直卡在"我不会做"，我建议你也试一次。反正只是做个试验，试试又不亏。

我知道它不是完美的。所以标题里那句"你们看看怎么样"，是真心问的，不是客套。

如果你也是跑者，或者你只是对"AI 写软件"这件事好奇，都欢迎告诉我：

评论区或者后台留言都能收到。