登录
领导把一份材料转过来，丢下一句：“拿AI做一下就行，半天够了吧。”
十分钟后，初稿真出来了。接下来两个小时，你在核对人名、数字、口径，改掉那些看着很像、其实不对的句子。
那句“AI出初稿10分钟，人工核对修改可能要2小时”，说的就是这一刻。微博
不是手慢。GitHub 9月的数据：开发者与AI智能体提交73.8亿次代码，推送33.5亿次，流水线32.6亿次，分别是5倍、4.9倍、4倍多。写代码的门槛被踩平了，新堵点是：存得进、合得上、谁签字。36氪
GitHub在博客里写了一条原则：智能体干的活越多，代码的主人越要能审、能懂、能拍板，没审过的改动，不能进主分支。
腾讯的AI Agent开发程序员maple讲过一个更具体的版本。
以前一个中等需求，二三十次提交就差不多了。最近一个差不多的需求，提交了六百多次；测试刚跑完一轮，第二天又冒出八十多个新提交。问题不在AI偷懒，在它太勤快。微博
需求评审时，产品经理常说“这个边界情况先别管，实际碰不到”。这句话不会写进文档，却是团队的默契。AI没有，它把十几个状态、异常处理、兼容分支全展开。
代码量、测试用例、工单一起涨。测试追不上，就用AI批量生成用例；开发收到单子，再用AI批量改。
AI给AI擦屁股，人在中间已经完全跟不上了。maple把这事总结成一句话：AI编程可能缺的，不是加速，是收住的能力。
换到办公室，逻辑一样。
一位出版从业者说，AI把初稿时间从几个月甚至几年压到几个小时，但“效率红利是虚的”：编辑核查、改错、校对的隐形工作量暴涨。问题出在核对这一端。36氪
AI会建议把“一文钱”改成“一元钱”，会把跨页的词在前后两页各报一次错；表格、公式、图片与图题是否相符，它又看不出来。
AI加速的是“生成”，不是“交付”。生成之后，还有需求确认、边界裁剪、质量检查、责任签字。这些环节串在一起，前一道不快，后一道快也没用。
有人算过：资深工程师每天纯写代码约1.5小时，AI提速3倍，整体工时也只省15%。其余时间花在架构、沟通、调试和review上。阿姆达尔定律早就说过：系统提速的上限，取决于那些不能被加速的部分。微博
一位财务把银行流水和账上记录两张表交给AI，让它写脚本对账。以前几百笔逐行打勾要半天，现在几分钟跑完，只看标红没对上的几笔。做对的关键，不是模型更强，而是把话说清楚了。小红书
金额用精确小数，同天同金额的两笔别重复配，原始文件先复制再跑。输入、输出、规则，三样都定了。
同样是AI，为什么这里没变成“AI写、人类改”的循环？因为“怎样算对”在开始之前就写好了。
真正该改的，是动手前的三行字。
第一行：交付物是什么。是一页纸、一张表，还是一个能跑的脚本。
第二行：哪些不做。哪些异常不用管，哪些兼容不用做，哪些情况直接报错。
第三行：怎样算过。数字跟哪张表对，来源以谁为准，哪几个点必须人工确认。
这三行不写，AI就会按最保守、最完整的方式展开。它不是故意添乱，它只是不知道你们的“先别管”。
在代码评审里，这三行就是PR里的几个检查项：改了什么、复杂度多高、风险在哪。
还有两个动作，能立刻减少返工。
一是先跑一个小样。抽十行数据、一个章节、一个页面，确认口径对了，再批量。
二是把“停”的权力留在人手里。撤不回来的那一步——发布、付款、发给客户——必须有人点头。
一位首席架构师更极端：动手前先花20到60分钟搭骨架，定目录、关键文件、函数签名；Agent跑起来后，看不懂就扔掉重来。AI确实快。它把“做出来”的成本打下来，也把“判断能不能用”的成本推给了人。36氪
提效的账，不能只算生成的那十分钟。把验收标准前置，把返工算进去，剩下的才是真正的节省。
