一个人用 AI 把功能做到上线：时间其实花在这 4 段

两天能交，但时间不是均匀省下来的

有人说 AI 把两周的活压成两天。我按自己加过的一个小功能对过表。两天可以交。省下的时间几乎全在「写实现」那一段。前后几段省了，就会在第二天返工。

功能是给文章加定时发布。到点从待发布变成前台可见。听起来就是一条定时任务。本站的文章已经有状态、首页显示、分类，所以它不是从零开始的新项目，是往旧逻辑里插一根针。这种活最容易被模型写「看起来完整、实际上和旧字段打架」的代码。

第一段：把现有代码讲对，大约四成时间

模型不知道状态值哪一个表示上架，也不知道定时任务该跑在 Webman 进程里，还是系统的计划任务里。这两件事猜错，后面全部作废。

这段我几乎不让它改文件。只让它读相关代码，然后用我的话复述三句：状态字段每个值是什么意思，前台列表在哪里过滤文章，定时任务打算跑在哪个进程。复述错了就纠正，直到和代码一致。

我第一次图快，跳过了复述。它把「1 是下架」理解反了，定时任务一跑，把已经公开的文章收了起来，又把草稿公开了。演示时用的是新建数据，看不出来。旧文章一跑就反了。这四成时间看着慢，它买的是不用整段推倒。

第二段：按约束生成，大约两成时间

三句复述对了之后，命令、查询和后台表单都很快。快的原因不是模型突然变强，是坑已经标出来了。很多人剪辑视频，剪的就是这一段，于是「两天做完一个产品」看起来像全程都这么快。

第三段：数据和规则得你拍板，大约三成时间

模型会给一个合理答案。合理不等于符合你的站点。我当时定死了三条，并写进注释：

• 只处理「待发布」并且发布时间已到的行。已经公开的文章，任务不许再改一遍。
• 时间按上海时区写入和比较。服务器若是 UTC，不处理时区就会提前 8 小时公开。
• 管理员取消定时，就清空发布时间。下一轮任务必须把它当成「不再发布」，不能又改回去。

这三条没有标准答案。换成另一个业务，可能正好相反。比如有的站点取消定时后仍希望保留原定时间、只是先暂停。把选择写下来，比再生成一版代码重要。模型可以列出选项，不能替你的读者承担发错文章的后果。

第四段：上线后的第一小时，大约一成时间

看日志，放一条一分钟后到点的测试文章，确认前台打得开。再点一次取消，确认它不会在下一轮复活。最后拿一篇已经公开的旧文章，确认任务没有碰它。

一个人能做完，靠的是把模型按在第二段。第一段和第三段如果也图快，两天交出去的是一个会在错误时间公开错误文章的定时器。能演示，不等于能值夜班。