先说一个我最近的常态下班回家一边把排骨下锅焖上一边把手机上某个AI编程工具打开口述了一句“把上周那个工单系统的列表页加一个批量导出功能按筛选条件导出超时的标红”。等排骨翻了个面AI已经把改动代码提交到了分支测试也跑了一轮。我再打开电脑花十分钟过一遍改动点一下部署完事。这就是标题里那个状态——“边做饭边口述交付功能”听起来像段子但确实是这一两年AI编程工具进化之后一个很真实的单人工作流。我认识不少同行现在写业务代码的方式已经从“双手敲键盘”变成了“动嘴交代”而且最核心的变化不是打字变语音而是人的角色彻底后撤生成、拼接、跑测试、修编译错误这些都交给AI去做人只保留两个最要紧的环节——审查和部署。这个模式不是噱头它对个人开发者、小团队甚至大公司里做内部工具的人来说都是一条值得摸一遍的路。这篇我就把这套“口述交付”完整拆开讲清楚每一步怎么操作、审查到底审什么、部署要卡哪些点以及我在实际使用里踩过的坑。我尽量用大白话也不堆概念重点放在你能直接拿去用的东西上。1. 单兵作战式交付人的判断为什么退到审查与部署1.1 用嘴写代码本质是分工重构先说一个容易误解的地方。很多人听到“用嘴写代码”第一反应是“这人是不是偷懒”“AI能写明白吗”。其实落到工作流里这件事的本质不是谁替代谁而是把原本混在一起的任务拆成了两层。传统的手敲代码流程是这样的你先在脑子里想清楚逻辑然后一个字符一个字符地把想法变成代码接着编译、跑起来、看到报错、再回头改循环好几轮好不容易本地跑通了还要处理依赖、环境、打包最后才是部署。整个过程中真正需要“人味”的部分只占一小块也就是想清楚要什么、判断做得对不对、决定能不能上线。剩下的大量时间都花在了“把想法翻译成代码”“跟编译器较劲”“排错调参”这些执行动作上。当AI编程工具成熟到可以听懂自然语言、能自主跑代码修Bug之后执行层就被它接走了。我现在的工作流变成了这样人说清楚要做什么、边界是什么、做成什么样算成功。AI拆任务、写代码、跑测试、反复修直到通过。人审查改动是否符合意图然后执行部署。你看人的判断并没有消失只是从“过程中不断做小决定”退到了“两头做大决定”——前头定义目标后头把关上线。这个过程里人少的是重复劳动多的是需要担责的关键判断。1.2 为什么偏偏是“审查与部署”这两步有人会问既然AI连测试都能跑为什么不停在审查这一关连部署也让它做我的回答是这两个环节本质上不是一个难度的“自动化”。审查这件事AI目前还替代不了人的原因是——它不知道自己不知道什么。比如我让AI做一个导出功能它能写对语法、跑通示例数据但它不知道这个功能是给客服用的客服用的筛选条件里某些字段是不能出现内部的它也不知道用户点导出的时候期望的是后台慢慢跑而不是一直转圈。这些隐含的上下文、业务约定、人与人之间的信任关系不在代码仓库里AI看不见但人一眼就能看出不对劲。所以“审查”必须留给人。而部署这一环跟审查还不一样。部署不只是“把代码放上去”它还牵涉到环境一致性、配置管理、数据兼容、回滚方案、甚至上线后谁来背锅。这些是责任问题。我可以用AI帮我写部署脚本、生成回滚计划但最后那个“点确认”的动作一定得是人类来做。你把代码推到生产环境就是对用户、对团队、对自己承诺“这东西我确认过了”。这个承诺没法外包。所以“人的判断退到了审查与部署那一步”不是人的价值变低了而是人的精力被收拢到了最值钱的两个口子上。1.3 这套模式适合什么场景不适合什么我不建议任何人听了这个就去把所有代码都改成口述。我自己也是挑场景用的。适合的场景有几个特征一是需求边界相对清晰二是有可运行的验收标准三是出错以后代价可控。典型的就是内部管理系统、数据看板、原型Demo、标准化接口、自动化脚本、临时小工具。这些活儿过去写起来繁琐但又不得不写交给AI非常划算。不太适合的场景也有比如涉及强合规的核心交易系统里面每一步都要留痕审计口述让AI改代码这件事本身很难追溯再比如高度依赖团队内隐性知识、代码库里根本没法表达的领域逻辑AI就算生成了代码也没人能审明白它对不对还有那些你完全陌生、连需求都说不清楚的全新项目——连人都不知道目标长什么样AI更不可能凭空想出来。说白了这套模式能成立的前提是人可以把自己的需求讲清楚并且有能力判断AI产出对不对。两样缺一样就得先回头补课。2. 口述需求的艺术把脑中的模糊想法变成机器听得懂的任务2.1 描述需求必须带“验收标准”很多人第一次用口述让AI干活最容易翻车的就是只给一句话。比如你说“帮我做个登录功能”AI确实能写出来一个登录但那个登录可能是用户名密码都明文存数据库的可能是没有任何错误提示的也可能是没有找回密码入口的——你说它错了吗也没错但它离你想要的差得远。我现在的习惯是口述需求时强制自己把“验收标准”交给AI。不要只说功能和界面要把可验证的行为说出来。举个例子同样是要登录功能我会这么说做一个登录页支持用户名密码登录。要求用户名为空或密码为空时在输入框下方显示对应的红色提示文案密码错误时提示“用户名或密码不匹配”连续错5次后锁定该账号10分钟登录成功后跳转到dashboard路由。多花二十秒把条件说清楚后面AI产出的代码质量会完全不同。因为对AI来说代码生成是概率拟合它能写对多少很大程度上取决于你给它的约束有多少。我给大家一个通用公式口述需求时按这个结构来通常不会跑偏功能名称 交互入口在哪个页面、点哪里触发正常路径的行为成功时应该发生什么异常路径的行为失败时提示什么边界怎么处理性能或时间要求如果有关键约束必须说交付形式是改现有代码、新建独立模块、还是只出方案2.2 一次别塞太多需求分三轮口述还有一个我试了几次就确定的经验千万别一口气把整个系统都口述给AI。一次性说十个需求AI第一遍大概率会把某些需求弄混或者为了赶工做出一个很差的折中方案。更稳的做法是分三轮。第一轮只交代骨架“我要一个待办事项管理Demo先实现清单列表、新增、删除、标记完成四个核心动作数据存本地即可。”等AI把骨架跑起来、你能看到页面了再进行第二轮加细节“列表按创建时间倒序标记完成的项置灰并移到列表底部删除按钮要二次确认弹窗。”最后一轮才是打磨“新增时按回车可以直接提交输入框为空时回车不触发提交并且给个轻提示。”这里面的逻辑是AI写代码的上下文窗口是有限的你一次给的信息越多它对每一条的执行精度就越低。分轮次口述等于把大任务拆成几个小契约每一轮都让AI聚焦在一件事上它才能做得干净。回看开头那个“边做饭边交付”其实真正的时间花在“等AI跑”上口述本身不到一分钟。因为这个需求我只花了十秒但它是建立在我已经对那个工单系统非常了解的基础上——我知道列表页在哪个路由、筛选参数叫什么、上次谁改过什么。所以能一句话说清楚背后其实是长期积累。如果你是第一次接触一个代码库别急着口述先花时间让AI帮你梳理一遍项目结构和关键逻辑攒够“上下文储备”再开口。2.3 口述里的三个典型陷阱陷阱一用词太口语化导致歧义。我试过说“列表加载完要有东西看”AI理解成“加一个加载动画”但我要的是“加载结束后展示空状态”。后来我改成“接口无数据时要显示空状态组件并给出按钮跳转新增页”它就立刻对了。口语词是模糊的技术描述才是精确的。陷阱二隐藏假设不说。比如你说“给用户表加个状态字段”但你没说这个字段要不要索引、要不要默认值、已有数据怎么处理AI就会给你一个最朴素的实现然后你审查时才会发现历史数据的迁