“这个功能需要多久？”
过去，这是一个合理的问题。开发资源有限，写代码需要时间，排期决定了一个需求什么时候能上线。
但在 AI 大量参与开发之后，我们应该重新审视这个问题。
当一个功能可以在几个小时内完成，当过去需要几个人协作的代码，如今一个人就能生成，写代码的时间正在大幅缩短。真正需要认真考虑的，是这些代码的质量、稳定性、扩展性，以及它们带来的风险。
开发可以做得很快，但不能因此要求交付也必须同样快。验证和回归，需要留出足够的时间。
写得快，不代表做得好
代码写出来有多快，已经不足以说明一个功能完成得有多好。
一个页面能打开，一条流程能跑通，一次演示没有报错，只能证明它在某个条件下可以工作。
它是否正确处理了权限？是否会在并发请求下重复扣款？失败后能否恢复？修改一个模块会不会影响另一个模块？半年以后，业务发生变化，还能不能继续扩展？
这些问题，不会因为代码生成得更快而自动消失。
开发质量决定业务规则是否被正确实现，稳定性决定系统能否在真实环境中持续运行，扩展性决定后续变化是否需要付出高昂代价。而风险控制，决定一次错误最终会造成多大的损失。
这些才是评估一个功能是否完成时，需要认真回答的问题。
代码越来越多，人力越来越少
过去，代码增长受到人力和时间的限制。团队每天能写多少代码、上线多少功能，通常存在一个自然的上限。
现在，这个上限正在被打破。
代码可以快速增加，功能可以不断堆叠，但理解系统的人、审查代码的人、处理故障的人，并没有同步增加。有些团队甚至在提高产出的同时，进一步减少开发人力。
于是，一个值得警惕的局面出现了：
代码越来越多，人力越来越少，每个人需要承担的系统复杂度却越来越高。
写出一段代码，可能只需要几分钟。理解它与整个系统的关系，确认它没有破坏现有规则，却可能需要更深的业务知识和工程经验。
如果代码增加的速度持续超过团队理解、验证和维护系统的能力，复杂度就会不断积累，最终在某次修改或故障中集中暴露。
很多风险，在交付时看不见
不合理的模块依赖，可能在下一次需求变更时才显现；遗漏的权限校验，可能在某次越权访问时才被发现；不完整的异常处理，可能一直等到线上服务中断才成为问题。
这些代码在交付时，都可能表现得“没有问题”。
演示通常发生在预期条件下，真实业务却充满异常：请求超时、重复提交、数据缺失、服务不可用，以及多个操作同时发生。
因此，“代码写完了”之后，还必须回答：
关键行为验证了吗？异常路径检查了吗？对现有系统的影响评估了吗？出了问题能发现吗？能定位吗？能回滚吗？
如果这些问题没有答案，功能就还没有真正完成。
代码加速生产，风险检测必须同步提速
开发工程的风险检测环节，必须跟上代码生产的速度。
当 AI 可以在短时间内生成大量代码，团队的检查能力也必须随之提升。如果代码生产速度提高了十倍，而审查、测试和风险评估仍然依赖原有的人力与流程，未经充分验证的代码就会持续积累。
人力越少，越不能把风险检测完全寄托在个人的经验和责任心上。它需要进入日常开发流程，成为交付的必要条件。
基础检查、类型检查、依赖检查和关键流程测试，应该尽可能自动执行。涉及权限、资金、数据删除和核心业务状态的变更，需要更严格的影响评估与异常验证。
上线之后，还需要监控、告警和回滚机制，确保问题能够及时发现、定位和处理。发布前的检查与发布后的观察，共同构成系统的风险控制能力。
检查的深度，也应该与风险相匹配。一个文案调整与一次支付逻辑修改，需要不同的验证投入。团队应当根据影响范围和失败代价，把有限的人力集中在高风险环节。
同时，检查通过并不意味着绝对安全。工具能够发现一部分问题，业务规则是否正确、系统边界是否合理、失败后能否承受，仍然需要工程判断。
生成代码的能力决定交付速度，检测风险的能力决定团队能否承受这个速度。
省下来的开发时间，要给验证和回归留一份
开发效率提高以后，省下来的时间应该如何使用，是一个需要认真作出的选择。
过去一个功能需要三天开发，现在可能半天就能写完。但这并不意味着，它应该在半天后立即上线。新功能是否符合业务要求，要验证；原有功能有没有被影响，要回归；发现问题之后，还需要修复和再次检查。
验证关注这次新增的功能是否做对了，回归关注这次修改有没有把原来正常的功能弄坏。这两件事，都不能被“代码已经写完”代替。
自动化可以缩短检查时间，但建立测试、准备数据、判断结果和处理异常，仍然需要投入。尤其是在业务复杂、历史代码多、测试覆盖不足的系统里，这些时间更不能想当然地省掉。
如果为了赶上线而压缩验证和回归，就要接受更多问题没有被提前发现的可能性，承担更大的上线风险。
有些紧急需求确实需要尽快发布。但是否值得加速，应该结合影响范围、失败后果和恢复能力来判断。作出这个决定的人，需要知道省掉了哪些检查，还有哪些不确定性，以及出了问题如何处理。
不能只要求更早上线，却同时要求风险保持不变。
我们应该换一组问题
开发时间当然仍然影响交付，但它不应该继续占据所有讨论的中心。
对于很多常规功能，写出代码的时间已经可以大幅压缩。与此同时，验证质量、理解影响和控制风险的投入，必须得到认真对待。
以后讨论一个功能，我们更应该问：
- 它的正确性如何验证？
- 它会影响哪些现有能力，需要回归哪些流程？
- 它在异常情况下是否稳定？
- 它能否支撑后续变化？
- 它最严重的失败后果是什么？
- 出现问题后，我们能多快发现并恢复？
- 如果提前上线，还有哪些检查没有完成，需要承担多大的风险？
这些问题的答案，才决定一个功能能否放心上线，系统能否持续演进，团队能否长期承担维护责任。
我们已经有能力更快地构建系统。接下来，必须给验证留下足够的时间，让交付的系统值得信任。