上周有人把一句需求直接贴给编程助手：给订单列表加一个导出按钮。两分钟后回来两百行代码，样式、事件、请求都齐了。粘进项目，页面能打开，点下去报错，接口路径用的是这个仓库三年前就废弃的那一版。这件事把问题问清楚了：AI 编程的难点不在会不会写，在写到哪一层该停手。下面按任务粒度拆开，说清哪类活能直接用、哪类必须自己过一遍、哪类现在不该交出去。
能用不能用，取决于它拿得到多少上下文
模型看到的只有你贴进去的那部分。入参、返回值、命名习惯、错误处理方式，它都能从片段里推；数据库字段叫什么、这个模块被谁调用、历史上为什么这么写，它推不出来。同一句需求，扔给一个空对话和一个带着十个相关文件的对话，产出质量差得远。
让它写一个快排永远成功，让它在这个项目里加一个筛选却经常失败——差别就在这里。前者是封闭问题，答案只由需求决定；后者是开放问题，答案由需求和环境共同决定。一次能塞进多少代码，直接决定了它能处理多大的问题，上下文窗口塞满之后模型会怎样里有更细的拆解。
按任务粒度分四档
| 任务粒度 | 能做到什么 | 要人改什么 |
|---|---|---|
| 单文件里的样板片段：读文件、发请求、格式转换、正则、SQL | 一次成型，语法和常见写法基本没错，改个名字就能跑 | 换成项目里的路径、字段名、错误处理；正则要拿真实样本跑一遍，边界条件常漏 |
| 单测初稿、注释、接口文档 | 能按函数签名补出用例，边界值常比你想得全 | 断言里的期望值要自己核；文档要对着实现看，它会把没做的部分也写上 |
| 业务逻辑与页面交互 | 结构对、命名像样，流程能跑通主路径 | 数据结构、历史包袱、上下游约定要自己补；修改量和手写差不多 |
| 跨模块重构、性能调优、线上排障 | 能给方向、能列可能原因，能写排查脚本 | 定位基本靠自己；它看不到调用链，也拿不到火焰图和线上日志 |
四档的分界线不在代码长短，在错了以后多久能发现。第一档错了，编译器或一条测试当场报出来；第四档错了，可能上线三天才有人投诉。发现成本越高，交出去的尺度就该收得越紧。
为什么业务代码总是语法对、业务错
公开代码里样板多，业务规则少。它见过一万种分页写法，没见过你们这条规矩：退款单必须关联原订单，金额不得超过原单。缺了这一条，它写出的判断逻辑读起来合理，跑起来是错的。
更隐蔽的是它会把缺失的部分补圆。字段名对不上，它顺手造一个看起来像的；接口没返回那个值，它默认有。这类补全在阅读时几乎看不出来，跑起来才炸，和模型为什么会一本正经地编是同一个机制：它的目标是让文本连贯，不是让事实正确。
交出去的边界，按错了谁承担来划
跨模块重构接不住。改一个函数签名牵连多少调用点，要靠全局检索和类型检查，它只看得见你贴的那几个文件。性能调优也接不住，没有火焰图、没有慢查询日志，它给的优化建议多半是加索引、少循环这类通用条目，对不对得试了才知道。线上排障同理，缺运行时状态，它容易给出一条自洽但错误的因果链。
还有一类它不会主动说：它不知道你的构建流程、灰度策略和回滚方式。让它改依赖版本、改数据库迁移脚本、改网关配置，风险比改业务代码高一个量级，因为出错范围不在一个页面里，回滚也未必干净。
放在打字员的位置，收益才是正的
划算的分工很清楚：你说清要什么、判断对不对，它负责敲。写样板、写正则、写测试初稿、逐行解释一段没看懂的旧代码，这四件事省下的时间是实打实的，因为验证成本低，错了当场能发现。业务逻辑也能让它写，但要预留和手写差不多的修改时间，别按它写完就完事来排期。
给需求的写法直接影响返工率。说清文件路径、相关函数、不许动的部分，比一句帮我优化一下有用得多，提示词里该交代哪几件事讲的是同一套拆法。改完跑测试，重点看它有没有顺手改到别的地方，这是最常见的隐性损伤。
三个问题，判断这次能不能交
一，这段代码错了，多久能发现？编译期、测试期，还是上线后。二，验证它对不对，需不需要外部数据？真实流量、profiling、线上日志，需要的话它给不出可靠结论。三，影响范围在一个文件内，还是跨了模块？跨了就别整段交出去。
三个问题里有两个答不上来，就当它只能出草稿，别按成品排期。
速查：一次改动该交到哪一档
- 样板片段、正则、SQL：直接用，改成项目里的路径和字段名，正则拿真实样本跑一遍
- 单测、注释、接口文档：用初稿，断言里的期望值自己核
- 业务逻辑：能写，预留同等修改时间，逐条对业务规则
- 跨模块重构、性能调优、线上排障：只要方向，不要结论
