AI Coding 中，人在做什么？
当 AI 能读代码、改功能、补测试，甚至根据报错连续尝试修复时，一个问题开始变得具体：
如果代码主要由 AI 编写，开发者的工作还剩下什么？
看看一次真实的开发过程，就会发现：输入需求和生成代码之间，还有许多需要人作出判断的地方。代码生成得越快，这些判断越影响最终结果。
一、把一句需求变成一个明确的问题
"给订单加一个取消功能。"
这句话足够开启对话，却不足以直接开发。
哪些订单可以取消？支付后能不能取消？取消是否需要退款？库存什么时候释放？重复点击如何处理？调用外部系统失败后，订单应该停留在哪个状态？
AI 可以帮助列出这些问题，也可以根据已有代码推测答案。但推测需要确认，尤其是涉及业务规则和利益取舍的时候。
人在这里要做的，是找到真正需要解决的问题，并明确什么结果可以接受。
有时，讨论之后会发现，用户需要的只是"提交取消申请"，实际取消仍然需要审核。如果一开始就让 AI 实现立即取消，代码写得越完整，返工范围可能越大。
在 AI Coding 中，人的第一项工作，是让值得实现的需求变得明确。
二、给 AI 足够可信的上下文
开发者接到任务时，很少只依赖需求文字。他还会考虑：
- 项目已经有哪些实现。
- 哪些模块负责哪些业务。
- 当前接口被谁调用。
- 团队遵守什么约定。
- 哪些历史问题必须避开。
AI 同样需要这些信息。
例如，项目已经有统一的分页入口，如果没有提供这一背景，AI 可能写出另一套分页逻辑。单看代码能够运行，放进项目后却增加了维护成本。
人的工作包括找到相关信息，帮助 AI 定位可信来源，并处理资料之间的冲突。文档说一种规则，代码实现另一种规则时，需要有人确认哪一个代表当前业务。
这也会推动开发者把过去藏在脑子里的经验写下来。那些"大家都知道"的约定，只有变成可查阅、可更新的资料，才能被同事和 AI 稳定使用。
三、决定改到哪里，什么时候停
AI 往往可以继续做下去：修复一个问题之后，再整理附近代码；增加一个接口之后，再抽出一个公共组件。
这些修改可能各有理由，但每增加一处改动，也会增加理解、审查和验证的范围。
假设任务只是修复金额展示的小数位问题，AI 却顺手调整了整个金额计算工具。此时，人需要判断：这次调整是否必要？会影响哪些调用方？现有证据是否足以支持它？
划定范围是一项重要的工程工作：
这次必须解决什么，允许修改什么，哪些问题另行处理，满足什么条件就可以结束。
范围清晰，AI 的执行才容易控制，最终结果也更容易被审查。
四、在多个可行方案之间作选择
同一个功能通常存在多种实现方式。
可以直接修改现有逻辑，也可以增加一层扩展；可以同步完成，也可以异步处理；可以复用已有组件，也可以引入新的依赖。
AI 能帮助整理方案、解释差异、补充风险。人需要结合项目处境作决定。
一个设计优雅的方案，可能需要团队暂时承担不起的改造成本；一个实现直接的方案，可能更适合当前规模；一个能快速上线的方案，也可能留下必须明确记录的后续工作。
这些选择涉及时间、复杂度、稳定性和团队能力。它们通常没有脱离场景的标准答案。
人的价值体现在判断：对于这个项目、这个阶段、这次任务，哪一种方案更合适。
五、验证"完成"究竟意味着什么
AI 说"已经修复"，应当被视为一个需要检查的交付结果。
开发者需要进一步确认：
- 原来的问题是否能够复现。
- 修改后是否通过相同场景。
- 异常输入和边界条件如何处理。
- 原有行为是否受到影响。
- 测试是否真正覆盖了需求。
尤其需要注意，代码和测试可能共享同一个错误理解。
如果 AI 把"只有未支付订单可以取消"误解为"所有未完成订单都可以取消"，它也可能按照这个理解编写测试。测试全部通过，业务规则仍然是错的。
因此，验证需要回到独立的依据：验收标准、已有接口约定、明确的业务规则，以及能够观察到的运行结果。
使用另一个 AI 进行审查，可以增加检查视角；最终仍然需要核对它指出的问题和给出的依据。
六、保留对系统的理解
当代码生成越来越容易，开发者可能遇到一种新的困境：功能已经完成，自己却解释不清它为什么这样工作。
平时这似乎不影响使用，一旦出现故障，问题就会显现。数据为什么进入这个状态？失败后能否重试？哪一步可能重复执行？应该从哪里回滚？
这些问题需要对系统保持理解。
使用 AI 后，开发者可以减少逐行输入，但仍然需要掌握关键路径、数据流转、外部依赖和失败处理。对于自己无法解释的关键逻辑，应继续阅读、追问和验证。
理解并不要求记住所有细节。它要求开发者在需要时，能够找到依据，判断影响，并采取行动。
七、让一次交付成为下一次工作的基础
一项任务结束后，还会留下许多值得整理的内容：
- 这次为什么选择这个方案。
- 排查问题时，哪些证据最有用。
- 哪些业务规则曾经存在歧义。
- 哪些遗漏可以加入检查清单。
- 哪些重复步骤适合交给工具执行。
AI 可以帮助整理这些材料，人需要筛选其中真正值得保留的内容。
如果每次开发都重新解释项目、重新发现约定、重新踩同样的坑，个人执行速度再快，团队也很难持续积累效率。
把有效经验沉淀为项目说明、验收模板、检查清单或自动化工具，才能让下一次协作从更好的起点开始。
人的工作，会更集中在判断和责任上
在 AI Coding 中，人仍然会写代码，也会调试和修复问题。但工作的重心会发生变化：
| 工作环节 | 人需要抓住的事情 |
|---|---|
| 开始之前 | 明确目标、范围和验收标准 |
| 执行过程中 | 提供上下文，处理歧义，决定方案 |
| 交付之前 | 核验结果，检查影响，判断是否可以发布 |
| 交付之后 | 跟踪实际效果，处理问题，沉淀经验 |
这些工作原本就是软件开发的一部分。AI 加快了实现速度，也让它们变得更加突出。
一个模糊的目标，可以更快地变成大量代码；一个错误的假设，也可以更快地扩散到多个文件。因此，开发者需要更早发现方向问题，更清楚地表达约束，并用证据判断结果。
当 AI 完成了一次修改，人最终需要回答的是：
这是不是我们需要的结果？我依据什么相信它正确？如果出了问题，我是否知道如何处理？
能够回答这些问题，开发者就仍然掌握着这次交付。