"能交给模型的都交了，最后返工比手写还多"——这句话在用过半年辅助工具的人里出现频率很高。它通常不是模型能力不够，而是交付单元的粒度错了：把整块工作整体交出去，而模型的可靠区间只覆盖其中若干环节。边界问题不是"AI 行不行"的判断题，而是"哪一段路我自己走"的切分题。切分有三个变量：任务属性、验证成本、这条边界是否已过期。
1. 返工从哪来：按环节分账
把"写一个接口"当成一个任务，账永远是糊的。拆成环节，差异立刻显现：
| 环节 | 手写投入 | 生成投入 | 验证 + 返工 | 净收益 |
|---|---|---|---|---|
| DTO、序列化骨架、Mapper XML | 中 | 低 | 低（结构可对照） | 明确为正 |
| 单测用例的参数化改写 | 中 | 低 | 中（断言是否还有意义） | 为正 |
| 解释堆栈、读日志片段 | 中 | 低 | 低（结论可当场验证） | 为正 |
| 存量模块重构方案 | 高 | 低 | 高（隐性依赖不在上下文） | 常为负 |
| 线上故障的处置决策 | 高 | 低 | 极高（不可逆） | 为负 |
右列依据不是"模型答得好不好"，而是验证这一段花多少人力。返工集中在后几行：生成很快，但验到能上线的成本超过手写。
2. 可以交出去的工作，有四项共性
| 共性 | 判据问句 | 反例 |
|---|---|---|
| 输入可验证 | 上下文是否完整到能自查？ | 只给函数名，让模型猜约定 |
| 输出可验证 | 能否被测试或对照物机械判定？ | "这个架构是否合理" |
| 错误代价低 | 错了会怎样？改回来要多久？ | 直接改生产库表结构 |
| 上下文自足 | 知识都在仓库/文档里，不靠某人脑子？ | "为什么当初这么设计" |
四项都成立，人从生产者变成验收者，净收益来自这里；只满足两项，人变成返工者，比手写更累。
3. 不该交出去的四类
| 类别 | 识别信号 | 代价形态 |
|---|---|---|
| 判据未成形 | 说不清"什么算对" | 反复改需求，生成物永远差一点 |
| 后果不可逆 | 删了、发了、转了没法回退 | 一次事故抵消一年效率 |
| 责任必须落人 | 出事要签字、对外解释 | 责任无法转移，签署人却不懂细节 |
| 依赖跨系统隐性知识 | 关键约束不在文档里 | 给了典型答案，在此环境里错 |
**判据的输出不该是"禁止"，而是"降级为草稿"。**草稿仍有价值：它把空白页变成待修改的文本，成本几乎为零。
4. 按任务拆解，不按职业拆解
"AI 适合初级、不适合架构师"这类说法几乎总是错的。同一岗位内部，环节的可交付性差异远大于岗位之间：
| 岗位 | 适合交付的环节 | 不适合的环节 |
|---|---|---|
| 后端 | 样板代码、错误码映射、SQL 改写 | 事务边界切分、幂等键选择 |
| 前端 | 组件骨架、样式调整、类型补齐 | 状态归属、首屏预算分配 |
| 数据 | 清洗脚本、口径核对、图表初稿 | 指标定义、口径争议裁决 |
| 运维 | 巡检脚本、日志聚合、配置模板 | 变更窗口决策、容量承诺 |
把这张表写成配置，团队才有共同参照物：
# ai-scope.yaml —— 白名单按环节写，不按职级写
backend:
allow:
- "生成 DTO / 序列化骨架"
- "把已有测试改写成参数化"
- "解释堆栈与日志片段"
deny:
- "决定分片键与路由规则"
- "任何直接作用在生产库的语句"
配置的价值在于可争论：不同意就改一行再评审，比在会上争"AI 行不行"高效得多。
5. 验证成本才是真门槛
生成把生产时间压到接近零之后，瓶颈整体迁移到验证侧。这是"AI 让所有人变快"叙事里最被忽略的一段：生产变便宜，检验就成了稀缺资源。
| 验证方式 | 单次成本量级 | 能覆盖的错误 |
|---|---|---|
| 编译器 / 类型检查 | 秒级，近零 | 语法、签名、空安全 |
| 单测 | 分钟级 | 逻辑分支、边界值 |
| 集成 / 契约测试 | 十分钟级 | 跨服务假设、兼容性 |
| 代码评审 | 十分钟到小时级 | 设计意图、命名、可维护性 |
| 灰度观察 | 小时到天级 | 真实流量的行为偏差 |
越往下越贵，而模型产出的错误恰好偏向下几行：它擅长写得像对的，不擅长保证在真实环境里对。判据因此可简化成一句：这次产出有没有一条便宜的验证通道。
刻意记录四段时间，账才算得清：
# 别只记"总共花了多久"，按环节记
# t_gen 生成耗时（含挑上下文、改提示）
# t_read 读懂结果的耗时（比自己写更费神）
# t_ver 验证耗时（跑测试、对照既有实现、查边界）
# t_fix 返工耗时
net = t_manual - (t_gen + t_read + t_ver + t_fix)
t_read 最易漏记：读别人写的代码比写自己的更累，往往吃掉净收益的一半。
6. 省下的时间去哪了
"效率提升 30%"在个人层面常测量不到，因为省下的时间被重新分配了：
| 时间去向 | 表现 | 是否算收益 |
|---|---|---|
| 评审与返工 | PR 变长、轮次变多 | 不算，是转移成本 |
| 上下文准备 | 写清约束、贴文件 | 部分算，可复用 |
| 等待与切换 | 生成期间刷别的事，回来要重入状态 | 不算 |
| 探索更多方案 | 多试两条路再选 | 算，收益滞后 |
| 交付更多 | 同样时间做完更多需求 | 算，需有需求池承接 |
末行是组织层面的关键：**省下的时间没有更多需求来接，就会变成空转或返工。**这解释了单人试点效果好、团队推广后度量不到——瓶颈从编码移到了需求供给与评审带宽。
7. 边界会移动，要周期性重估
去年不能交的今年可能可以；反过来也成立——工具换代时团队熟悉的失效模式会变，旧禁令可能束缚手脚，旧信任可能已经过时。按季度做一次就够：
季度重估三问（写进季会，别靠临时想起）
1. 上季度否掉的哪几类任务现在有把握了？依据是可复现的验证，不是感觉。
2. 上季度出过事故的环节，是否要从白名单移到"人必须签字"？
3. 验证手段有没有变强（覆盖、回放、灰度）？验证变强，边界就该变宽。
第三问杠杆最大：多数"AI 不可靠"的结论，实际是"我们没有便宜的验证手段"。
8. 团队三种策略与各自代价
| 策略 | 收益 | 代价 | 适用 |
|---|---|---|---|
| 全禁 | 风险最低，规则简单 | 骨干偷着用，风险不可观测 | 事故容忍度极低 |
| 全放 | 上线快，无摩擦 | 方差极大；评审被淹没；责任模糊 | 原型期、一次性项目 |
| 白名单 | 风险可分层；规则可演进 | 需维护清单；边界外要有人裁决 | 有交付压力的团队 |
白名单真正的成本不在写清单，而在裁决机制：清单外谁批、多久批、批错怎么回滚。缺了它，白名单会退化成"谁声音大谁说了算"。
9. 手感退化是隐性成本
判断力依赖手感，手感只能靠写过。长期只做验收会退化：看到生成物"像对"就放过；估时失准，因为没经历过从零到跑通；排错下降，因为不熟悉没写过的代码。
对策不是"少用"，而是保留一条必须手写的通道：核心链路首次实现、事故后修复、性能关键路径自己写，其余放开。这条规矩维持判断力下限，不是道德姿态。
10. 不可逆操作的硬规矩
| 操作 | 可以有的 AI 参与 | 不该有的形式 |
|---|---|---|
| 发布 / 回滚 | 生成清单、比对配置差异 | 由模型直接触发 |
| 删除数据 | 生成候选语句并附影响行数 | 直接执行 DELETE / DROP |
| 转账 / 计费变更 | 生成对账脚本、核对口径 | 参与金额计算并调用 |
| 对外沟通 | 起草、润色、翻译 | 未经人读就发出 |
做成硬闸门，不靠自觉：
# 不可逆动作不做"建议即执行"，一律过人工闸门
case "${ACTION}" in
deploy|rollback|delete|transfer|mail-send)
require_human_approval "${ACTION}" || exit 1 ;;
esac
闸门成本是每次几十秒确认，收益是把"模型判断失误"从事故降级为待办。
11. 可观测：三个数就够
| 指标 | 口径 | 采集点 |
|---|---|---|
| AI 参与度 | 标注 AI 参与的提交占比 | commit trailer / PR 勾选 |
| 返工率 | 同一需求的返工提交数 ÷ 总提交数 | 需求号关联 |
| 评审耗时 | ready→approve 时长中位数 | 平台事件 |
ai_share = commits_with_trailer / commits_total
rework_rate = rework_commits / commits_per_issue
review_p50 = median(approved_at - ready_at)
三个数要一起看：参与度升、返工率同步升，说明白名单太宽；参与度升、评审时长翻倍，说明验证带宽不够。单看任一个都会误判。
12. 排错
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 用了工具反而更慢 | 粒度是"整任务"而非"环节" | 按 §1 拆账，只交可验证段 |
| 轮次变多、意见重复 | PR 过大，抓不住重点 | 限制 PR 规模，先自评 |
| "看着对但跑不通" | 缺上下文，补了不存在的约定 | 先给签名、错误码、既有实现 |
| 骨干抵触、暗中使用 | 全禁 + 无裁决机制 | 改白名单，把清单外流程写清 |
| 度量无提升 | 时间被评审与等待吃掉 | 查 §6，补需求供给 |
13. 边界：这些情况本就不该套这套判据
| 场景 | 为什么不适用 | 更合适的做法 |
|---|---|---|
| 探索性草图、发散讨论 | 错误代价近零，验证可忽略 | 完全放开，多试几版 |
| 一次性工具、临时脚本 | 无维护期，坏了就扔 | 放开，不评审 |
| 纯格式转换、批量改名 | 输出可机械比对 | 放开，只抽查一小部分 |
| 团队信任度高、流程成熟 | 边际收益低于讨论成本 | 只留不可逆闸门 |
一句话收口：这套判据管的是"有交付压力、有维护期、有责任归属"的工作；不满足这三条的场合，讨论边界本身就是浪费。
14. 自测
- 你团队里哪个环节最近一次返工超过了手写成本？它缺的是四项共性里的哪一项？
- 为什么"降级为草稿"比"禁止使用"更适合作为判据的输出？
- 同一岗位内，哪些环节可交、哪些不能？你能各举两个吗？
- 生成变快之后，瓶颈为什么移到验证侧？你们最便宜的验证通道是哪一条？
- 全禁、全放、白名单三种策略，各自最大的隐性成本是什么？
- 什么样的任务，本就不该用这套判据去衡量？