开发者审阅 AI 生成的初稿并划清责任边界

我最近做项目时,经常会想一个问题:AI 编程到底应该用到什么程度?

不是“AI 会不会取代程序员”这种大问题,而是更具体一点:今天这个任务,我到底该交给 AI,还是必须自己盯住?

我现在全职做自己的产品和自媒体,也会承接一些软件定制。日常就是和 Claude、Codex、Hermes 这些 AI Agent 一起做真实项目。膳云 MakanCloud 这种餐饮 SaaS,从订货、中央厨房、配送、排班,到 POS、扫码点餐,很多模块都是我一个人借助 AI 慢慢推进出来的。

用得越多,我越觉得 AI 编程的价值不在于“神奇”,而在于把一些过去很耗时间的环节,变得可控、可迭代。

一、AI 很适合把空白页变成初稿

AI 将空白页转化为可修改和验证的初稿结构

写代码最痛苦的时刻,很多时候不是优化,而是从零开始。

一个接口怎么搭、一个配置怎么读、一个脚本怎么跑、一个测试文件怎么起头,这些事情不一定难,但很消耗启动成本。

现在我会直接让 AI 先给一版结构。它写得不一定完美,但有了第一版,我就可以开始删、改、追问、验证。

这对独立开发者特别有用。因为一个人做产品时,后端、前端、运维、文档、排查问题都要自己来。如果每个环节都从空白开始,很容易被启动成本拖住。

AI 在这里解决的问题是:让我更快进入“审稿和决策”状态,而不是卡在“怎么起步”。

二、AI 也适合做耐心活

我很常让 AI 做几类事情:

  • 解释一段隔了一阵子没看的代码
  • 梳理一个 bug 可能经过哪些调用链
  • 补充测试用例的边界场景
  • 把功能改动整理成文档或发布说明
  • 检查错误处理和配置项有没有明显遗漏

这些事情过去不是不能做,而是容易被我往后拖。因为它们需要耐心,也需要在很多文件之间来回切换。

AI 的优势就在这里:它不会嫌烦,可以反复检查,可以帮我把零散信息先摊开。

但我不会直接相信它的结论。尤其是涉及真实项目时,我会把它当成一个提醒系统,而不是裁判。

三、需求和业务判断不能外包

做膳云 MakanCloud 之后,我对这一点感受很深。

餐饮系统不是单纯“页面好看、接口能跑”就可以。真实门店里,员工在忙,网络可能不稳,打印机可能掉线,一个流程多一步都可能影响使用。

这些现场感,AI 没有。

它可以帮我写一个订单状态流转,但不能替我判断这个状态设计对不对;它可以帮我生成一个后台页面,但不能替我判断老板、店员、厨房各自真正需要看到什么;它可以帮我优化代码,但不能替我理解为什么某个功能一定要简单。

所以需求判断、流程取舍、产品优先级,我必须自己负责。

四、安全、架构和上线责任必须自己兜底

开发者亲自把关安全信息和上线前交付检查

还有一些事情,我不会放心交给 AI 自动决定。

比如生产凭证、客户数据、服务器信息,这些不能随便放进提示词里。再比如架构取舍,到底是先快速上线,还是留出扩展空间;到底哪些地方可以简单写,哪些地方必须一开始就稳一点。

这些判断背后不是代码能力,而是责任。

代码能跑,不等于可以交付。上线前的测试、构建、回滚预案、监控、错误处理,最终都要我自己确认。

AI 可以帮我提高速度,但不能替我承担后果。

我的结论

现在我更愿意这样看 AI 编程:

AI 是一个高执行力同事,不是最终负责人。

适合交给它的,是起草、整理、解释、补充、检查;必须自己把关的,是需求、架构、安全、交付责任。

这个边界清楚之后,反而更好用了。因为我不再期待它一次性给出完美答案,而是把它放进工作流里,让它帮我更快推进真实产品。

如果你也在用 AI 写代码,可以试着列一张自己的清单:哪些任务适合 AI 先做,哪些任务必须自己拍板。

我也会继续分享自己用 AI 做真实项目的过程。如果你对 AI 编程工作流、餐饮系统或软件定制感兴趣,欢迎留言聊聊。