以为快 24%，结果慢了 19%
一次关于生成与交付的自述。
我先给大家看一组数字。
十六位资深开发者，熟悉自己参与的开源仓库，两百四十六个真实任务，随机决定哪些允许用 AI。
周六我在一场面向开发者的活动上做分享，最先把这组数字投到了屏幕上。投完没有急着解释，先让大家看了一会儿。
我当时说，这个结果不能拿来证明今天用 AI 都会更慢。样本是十六个人，工具是 2025 年初的版本，任务限定在那几个仓库里。它能说明的事情只有一件，快速出现的第一版会带来很扎实的进展感，而整个任务有没有变快，得另外算。
先分清出现和完成
先说口径。
一个任务的时间要算四段，生成、核对、返工、接回原来的流程。只算第一段，AI 确实快得离谱。四段一起算，账经常会变。
这个拆分是我自己判断用的。研究里多出来的时间花在哪，作者没给答案，我也不替他们补。
::: key 两个词，得分开 输出出现了。
目标任务完成了。
演示的时候看见东西跑起来，大家默认后面那件事也成了。等到要交付，才发现跑起来的那个东西和要做的那件事，中间还隔着一截。 :::
人的位置换了三次
人的位置换了三次，我分三段说。
补全的时候，AI 帮你打字，结构在你手上。对话的时候，它给你函数和文件，你负责挑、拼、改。到 Agent，它能读文件、跑命令、看报错自己继续改，你能委托出去的步骤越来越多。
于是有人开玩笑说，写代码的人从作者变成了甲方。
这只是个比喻。工程能力还在，而且更吃功夫，要判断它理解了什么、漏了什么、改动有没有碰到原有的约束。我看模型输出时的体会是，形式越完整，越要提前说清楚什么算对。
委托之前有四件事要说，目标、约束、验证方式、停止条件。说清楚了，你检查的是任务有没有达成。
三层变化
变化落在三个地方。
先是需求。过去开发成本高，很多岗位的小工具根本进不了排期。现在可以先做一版，让真正要用的人来验证值不值得。需求这一端的试错成本降下来了。
再是能力。第一版的门槛降了，把它接进业务、处理异常、写测试、长期维护，这些还是工程活。生成容易了，工程问题一个没少。
麻烦的是责任。交接之后才发现两边理解的口径不一样，返工的代价很高。所以产品那边要更早给出业务依据和优先级，开发那边要更早提出依赖、约束和验证条件。
这一层最容易被跳过。前两层都有看得见的东西，责任这一层只能靠说。
那三个百分比得拆开看
我还引了另一份调研。
DORA 2025 年访问了接近五千名技术从业者。官方信息图里三个数，百分之九十表示自己在工作中使用 AI，超过八成认为 AI 提升了自己的生产力，百分之五十九认为代码质量因此改善。
这三个数都是受访者自己报的，量的是一份感受。实测的提效比例另有一套算法。
同一份报告也观察到交付吞吐在改善，所以拿它去证明组织上了 AI 却没提效，站不住。它真正的结论是另外一句话，AI 会放大一个组织本来就有的优势和问题。
基础能力好的团队，差距会被拉得更开。流程本来就乱的团队呢，乱得也更快。
采用度和人的感受要看，任务耗时、交付表现、稳定性也要看。这几类指标混在一起谈，永远说不清该换工具还是该补流程。
一条工作流里的具体缝
我看过一条公开的工作流，问题最后出在代码里。
那条工作流是这样的，输入一个关键词，脚本去检索真实的投诉和讨论，模型提炼痛点，再生成用户故事、MVP 功能和开发任务。
设计上做了一件对的事，每个痛点保留用户原话和链接，痛点、故事、功能、任务之间用 ID 互相关联。还规定了一件事，搜索没有结果时就返回空，不要编一段投诉出来顶上。
但读到配套工具的转换代码时，缝出现了。
设计上
痛点保留用户原话和链接; 痛点、故事、功能、任务用 ID 串起来; 搜不到就返回空，不硬凑
源码里
编号、标题、严重度都过去了; 原话和链接没跟着走; 痛点对哪个功能仍是「待映射」
这是静态读代码看到的一处缺口，算不上一场事故，也谈不上整个套件都缺这个能力。它说明这条交接路径上有一个洞还没补。
上一个步骤的输出结构看着很完整，下一个步骤照样能漏掉关键字段。任务文件生成出来了，任务和业务依据之间还差着一截。
我给的办法很土，投入开发之前抽一条回查。从一个任务追到功能，追到用户故事，追到痛点，最后打开原文。先看关联全不全，再看原话撑不撑得住这个痛点。
关联齐了只是第一层。语义对不对得上，机器判断不了。
一段没做成的经历
还有一段是我自己的。
AI 把东西做出来了，初看是对的。让真人沿着业务流程走一遍，幻觉反复出现，和真实业务的衔接也很别扭。
这段我没打算写成复盘。能说的就是这些，一个原型和 demo，看着正确，真人验证时反复出问题。中间的具体任务、错误样例、修复和上线结果，我一个都没补。
它改变的是我的做法，对 AI 的看法倒没怎么变。能更早拿到实物，围着它讨论，原先没说清的规则也提前暴露了。我把验证缩成两个问题，输出有没有依据，用户能不能完成真实任务。
前者核对关键结论和规则出处，后者沿着业务路径走一遍，把接不上的地方写成验收样例。
四类任务，四种查法
用起来的边界，我按任务类型列了四条。
一次性的任务，先算完整耗时。生成加核对加返工，超过自己动手的成本就换回手动。为了用而用的那部分，最后都在还债。
要长期维护的，第一版能跑只是入场券。得说清楚谁维护，哪些样例以后必须一直通过。
内部上下文多的，把权限、历史口径、规则出处跟着任务一起交出去。指望模型猜中公司的历史约定，这笔账从来算不过来。
自己判断不了对错的，先缩到能验的范围，找到能判断的人，把通过条件谈好再继续。
四类任务有个共同点，每一类都要留下具体的检查物或交接物。验收包含真实路径、失败条件和后续责任。
谁来完成交付
回到标题那个问题。
我的建议是把责任落到具体产物上。落到岗位上，人一调岗责任就跟着走了。
这四件事可以一个人做，小团队往往就是一个人。即便是单人项目，也值得依次问一遍，值不值得做、怎样实现、用户能不能完成、现在能不能交。
最后一问最常被跳过。AI 已经把东西生成出来了，很容易让人觉得交付的决定也一起做完了。
如果只记一句
最后我说，如果今天只带走一句话，那就是这句。
把一个模糊念头，逼成一句可验收的话。
AI 加速的是生成。交付需要明确负责人，业务依据、工程验证和真实任务，都要有人接住。
