外观
第一章 AI 真的改变了什么？
第一次把一段真实工作交给 AI，人往往会先被速度吸引。
设想产品经理说，后台需要一个批量导入用户的功能。你把需求、接口和几张表的说明交给 AI，没过多久，上传页面、解析逻辑、校验代码和测试草稿都出现了。过去需要更久才能看到的初版，现在很快就能运行。
这确实是变化，但它还不能算完整的交付。批量导入需求真正上线前，还有几类问题必须先说清楚。遇到重复用户，是跳过、覆盖，还是直接报错？一万条数据里有几百条失败时，是全部回滚，还是允许其余数据先成功？没有权限的人能不能使用？文件太大时，服务会不会被拖垮？用户重新提交时，会不会留下重复记录？
AI 可以很快替你列出方案，甚至直接写出初版。可是代码出现得更快，并不代表关键决定已经符合业务要求。什么算完成、哪些失败可以接受、出了问题谁来处理，仍要由后续的讨论、测试和验收来确认。
所以，观察 AI 带来什么变化时，不要只看到出现了什么工具，也不要只看代码写得多快。先观察一项工作由哪些任务组成，再看每个任务花费的时间、需要的判断，以及出错后的代价。我们需要从任务成本看 AI。
本章不回答哪些职业会消失，也不回答开发者下一步应该学习什么。先做一件更基础的事：把“AI 提高效率”拆成一项项看得见的任务变化。
功能写出来以后，事情真的结束了吗？
在过去的软件开发中，代码生产往往是成本最高的环节之一，也是价值最容易被看见的环节。开发者要熟悉语言和框架，查文档，处理数据库、网络和运行环境，再通过测试和调试把实现磨到可用。很多方案上的取舍，也是在这个过程中才逐渐想清楚的。
因此，“会写代码”很自然地成了能力的代表。一个人如果能独立做出更多功能，通常也意味着他能承担更复杂的工作。代码既是工作成果，也是别人判断进度和能力时最容易看到的证据。
AI 先改变了其中一部分成本。它可以写出常见的接口和页面，整理陌生库的用法，生成测试草稿；如果接上工具，还能读文件、运行命令，再根据报错继续修改。过去需要人连续完成的几个动作，现在有一部分可以由模型和工具共同完成。
但软件交付从来不只有这些动作。只是过去，这一点很难被看见。
我们为什么会把“写代码”和“开发软件”混在一起？
因为在很长一段时间里，两者确实挨得很近。
研发人员接到一个需求，要先理解规则，再设计方案，接着写代码、调试、测试，最后上线。代码是这些动作留下的主要痕迹。评审看代码，进度按代码估算，评估一个人的经验也常看代码。久而久之，“把功能做出来”就容易被说成“把代码写出来”。
只要写代码仍然昂贵，这种混在一起的说法就不太容易暴露问题。AI 把一部分实现成本降下来以后，原本藏在代码后面的工作才显出轮廓。澄清需求、选择方案、验证结果，这些工作以前就存在，只是没有像写代码那样显眼。
所以，AI 带来的变化，首先不是“程序员突然不需要写代码”，而是代码不再能代表全部工作。要看清变化，就得把一项工作拆开，分别看每个任务的成本、边界、需要的判断，以及结果由谁确认。
代码更便宜以后，什么会变贵？
这个问题没有标准答案。
有些项目的主要困难仍然是实现本身，比如算法复杂、性能要求高，或者运行环境很难调试。另一些项目真正麻烦的是业务规则、遗留依赖或说不清的需求。前一种项目，AI 可能只能缩短部分编码时间；后一种项目，如果规则没有弄清楚，代码生成得越快，可能只是越快走向错误方向。
这里就会出现一个常见落差。开发者看到初版很快出现，便期待整个项目也按同样比例提前完成；到了项目结束，却发现确认需求、等待环境和其他系统联调、最后验收，这些时间并没有按同样的比例缩短。
这里也不存在“AI 只负责写代码，人只负责思考”这样整齐的分工。模型已经能参与分析、规划、调试和测试，而且边界还在变化。更稳妥的做法是把问题问细一点，看看同一项工作里哪些任务变快了，哪些仍然要等人决定，哪些结果更难确认。
可以先记住一个方向：实现变便宜以后，那些需要人作决定、又不容易确认结果的环节，会在一次交付中占更大的比重。它们花的钱和时间未必增加，只是其他环节缩短后，它们更容易成为等待点。具体是哪一些环节，以及人的价值怎样随之变化，留到后面几章再展开。
不要只记住“写得更快了”
回到开头那个批量导入的需求。页面和代码出现得很快，但一次完整交付花掉的时间，从来不只是写代码的时间。动手之前，要弄清背景、查依赖、比较方案；实现之后，要确认需求、准备测试环境、和其他团队配合；出了错，还要检查、返工、恢复。真正实现的那段时间最容易被看见；其余的工作藏在它前后，估算时常常被漏掉。
AI 先降低的是“动手做”那一段的成本。初版出现得更快，查文档、写测试草稿也更快，但需求确认不会因为代码先到就自动完成，错误方向的验证和返工也不会消失。如果初版变快同时带来了更多可选方案，比较这些方案本身还会增加新的工作。
所以“这个功能快了多少”是一个容易误导的问题。更值得问的是：整条交付链上，哪一段真的变快了，哪一段还在原地？把局部提速当成全链条提速，是引入 AI 之后最常见的误判之一。
先看任务，不急着看职位
“程序员会不会被替代”很容易把讨论带到一个过大的问题上。职位只是组织里的一个名称，里面其实装着许多不同的任务，包括理解需求、设计方案、实现功能、排查故障、评审改动、沟通取舍和确认上线结果。
AI 对这些任务的作用不会完全相同。有些可以让它先做，有些适合让它加速，还有些即使有它帮忙，也必须由人严格检查。今天的分界线也不是永久的；模型能力、工具环境和出错代价变化以后，分界线还会移动。
重新看看自己的工作
挑一个最近完成的功能，或一次故障处理，从头回想整个过程：
- 过去最耗时的动作里，哪些现在可以让 AI 先做？
- 哪些时间花在等待、补充背景或做决定上，几乎没有缩短？
- 哪些结果可以马上检查，哪些要等真实用户、下游系统或运行一段时间才看得出来？如果错了，返工会落在哪个环节？
- 有没有一些想法，过去因为实现成本太高而没有尝试，现在已经值得先做一个原型？
不必马上把这些答案归纳成职业结论，先把任务的变化记下来。回看几次之后，你很可能会发现，速度提升只落在少数环节；正因为这些环节变快了，原来不显眼的工作才到了面前。
这也是本书接下来要追问的问题。当一部分任务的生产成本下降以后，完成这些任务的人，市场价值为什么没有同步上涨？