AI 改变的不只是工具，还有整个开发方法

一行一行看代码的时代结束了，程序员要开始对结果负责

前言

AI 时代，程序员需要调整的可能不只是开发工具，还有我们看待代码、责任和个人价值的方式。

当然，这并不是什么行业共识，也不是一个已经被证明的标准答案。只是小编最近使用 AI 开发时，越来越明显地感受到：过去那套逐行编写、逐行阅读、逐行确认的工作方式，已经有些跟不上 AI 生成代码的速度了。

过去，小编也认为只有亲自写过、认真看过每一行代码，心里才有底。毕竟代码最后出了问题，承担责任的还是程序员。

但现在的问题是，AI 几分钟生成的代码，我们可能需要几个小时才能全部看完。它还可以继续修改、重构、补充测试，一次改动十几个文件。

如果每次都从第一行看到最后一行，AI 节省下来的开发时间，最后又全部消耗在了阅读代码上。

AI 写得越来越快，我们却审得越来越慢。

这让我开始重新思考一个问题：

当代码的生产速度已经超过人的阅读速度，程序员究竟应该对什么负责？

小编现阶段的理解是：

程序员不一定还要为每一行代码负责，但必须对最终交付的产品结果负责。

这里并不是说以后不用看代码，更不是把所有事情都丢给 AI。核心业务、资金、安全、权限、数据一致性等关键部分，依然值得认真审查。

我想讨论的是：我们是否还需要通过“看完所有代码”，证明自己已经尽到了责任？

在小编看来，AI 时代真正需要调整的是两件事：

第一是价值观。程序员的价值可能不再只是亲手写出多少代码，而是能否借助 AI 把问题解决好。

第二是方法论。我们可能需要从控制每一行代码，逐渐转向控制需求、边界、风险和最终结果。

这也是小编写下「程序员重生计划」的原因。它不是为了告诉别人应该怎样开发，而是记录自己面对 AI 时代时，对程序员价值和开发方式的一次重新思考。

一、逐行看代码，正在成为新的效率瓶颈

以前开发一个功能，代码主要由程序员自己完成。

从接口到业务逻辑，从数据库操作到异常处理，整个实现过程都发生在自己手里。我们不需要专门花时间理解代码，因为写代码的过程，本身就是理解代码的过程。

但 AI 写代码不是这样。

我们把一个需求交给 AI，它可能一次生成接口、页面、类型定义、数据库脚本和测试代码。发现问题以后，它又会同时修改多个文件。

代码不再是一行一行增加，而是一批一批出现。

这个变化带来了一个很现实的问题：

AI 五分钟写完的代码，自己可能需要两个小时才能看完。

表面上看，我们使用 AI 提高了开发效率。实际上，只是把工作从“亲自写代码”转移到了“阅读 AI 生成的代码”。

过去的效率瓶颈是写得慢。

现在的效率瓶颈，可能会慢慢变成看得慢。

小编刚开始使用 AI 开发时，也会下意识地打开每个文件，从头到尾检查一遍。改动少的时候没有问题，但随着 AI 参与程度越来越高，这种方式很快就坚持不下去了。

不是不想认真，而是人的时间和精力根本追不上代码的生成速度。

所以，小编现在更倾向于承认一个现实：

一行一行看完所有代码，这种工作方式可能已经不可持续了。

这里的重点不是“以后要不要看代码”。

代码当然还是要看。只是人的精力有限，不可能平均分配给所有代码。

核心业务值得看，关键设计值得看，资金、安全、权限和数据一致性相关的代码更应该认真看。但对于普通页面、基础类型、重复逻辑和常规接口，也许没有必要投入完全相同的审查成本。

过去，我们习惯按代码数量分配精力。

现在，或许更适合按照风险分配精力。

二、代码都看过，不代表产品没有问题

很多程序员坚持逐行看代码，是因为这样更有安全感。

这些代码我都看过，所以我心里有底。

小编以前也有这种感觉。但做过一些真实项目以后会发现，代码全部看过，并不代表最后交付的产品一定正确。

功能出现问题，原因未必是某一行代码写错了。

它可能从一开始就理解错了需求。

也可能只考虑了正常流程，没有考虑异常流程。

还可能是每个功能单独运行都没有问题，放进完整的业务链路以后却无法闭环。

举个简单的例子。

假设我们要开发一个文件上传功能。AI 生成的代码结构清楚，异常捕获也写了，我们把每一行都看了一遍。

但如果一开始没有考虑下面这些问题：

• 允许上传哪些格式；
• 文件大小如何限制；
• 重名文件如何处理；
• 上传中断以后能不能重试；
• 恶意文件如何拦截；
• 上传成功以后能否正常访问；
• 文件丢失以后能否及时发现。

那么代码即使没有明显错误，这个功能依然不能直接交付。

你看，真正决定功能是否可用的，不只是代码写得怎么样，还有需求、边界、场景和验证。

逐行阅读主要解决的是：

我是否熟悉这段代码？

而产品交付需要回答的是：

我怎么证明这个功能是正确的？

这两个问题并不是一回事。

小编现在更愿意把工程上的安全感，建立在下面这些事情上：

我知道这个功能要解决什么问题。

我知道它的边界在哪里。

我知道哪些环节最容易出错。

我知道应该通过什么方式证明它是正确的。

我也知道出现问题以后，如何发现、定位和恢复。

这些问题都能回答清楚，系统才算真正处于控制之中。

所以，在小编看来，“这些代码我都看过”可以带来控制感，但不一定能够带来真正的控制力。

三、不为每一行代码负责，不代表不负责任

“不再为每一行代码负责”这句话，听起来很容易让人误解。

好像使用 AI 以后，我们就可以不关心代码质量，也不用承担问题。

这并不是小编想表达的意思。

在我的理解里，责任并没有减少，只是需要从代码层向上移动。

以前代码主要由程序员亲手完成，我们很自然地把注意力放在实现细节上：

• 这个方法应该怎么写；
• 这个变量为什么这样命名；
• 这段逻辑还能不能继续抽象；
• 代码结构是否符合自己的习惯。

这些事情仍然有价值。

但当 AI 开始承担越来越多的实现工作以后，程序员或许需要把更多精力放到另外一些问题上：

• 需求有没有理解正确；
• 功能边界有没有定义清楚；
• 技术方案是否适合当前业务；
• 关键风险是否已经识别；
• 异常情况是否能够处理；
• 最终结果是否经过验证；
• 上线以后能否观测、定位和恢复。

说白了，代码只是产品实现过程中的一种中间产物。

用户不会因为我们看完了所有代码，就接受一个无法使用的功能。业务也不会因为代码写得漂亮，就忽略最终结果和需求不一致。

大家最后关心的，仍然是功能能不能用、问题有没有解决、系统是否稳定。

所以，小编认为程序员需要负责的，不应该只是代码有没有看完，而是最终交付的产品是否可靠。

这其实不是降低了责任，而是把责任放到了更高的位置。

四、程序员和 AI 需要重新分工

现在很多人使用 AI 开发，只是在原来的开发流程里增加了一个代码生成工具。

以前自己写代码，现在让 AI 写代码。

以前写完以后自己检查，现在 AI 写完以后还是自己逐行检查。

工具变了，但工作方式没有真正改变。

小编认为，我们可能还需要重新划分一下程序员和 AI 的责任。

AI 擅长的是快速实现。

它可以生成代码、补充测试、整理类型、修改重复逻辑，也可以根据错误信息不断调整方案。只要上下文和任务足够明确，它的执行效率通常远高于人工编码。

但有些问题，AI 很难独立决定。

例如：

这个需求究竟值不值得做？

业务真正想解决的问题是什么？

哪些情况必须支持，哪些情况可以暂时放弃？

出现异常时，业务允许失败，还是必须补偿？

当前项目能够承担多少改造成本？

什么样的结果才算真正完成？

这些问题往往没有标准答案。

AI 可以根据已有信息提供建议，但它不知道项目过去经历了什么，不知道团队当前有多少资源，也不知道业务真正能够接受什么结果。

这些取舍最终还是要由程序员完成。

所以，小编现阶段比较认可的一种分工是：

AI 负责扩大实现能力，程序员负责控制实现方向。

AI 可以生成代码，却无法替我们承担最终责任。

程序员可以不再亲手写完所有代码，但需求、边界、风险、取舍和验收，仍然需要有人真正负责。

这个人至少目前还应该是程序员。

五、开发方法要从控制代码转向控制结果

价值观发生变化以后，开发方法也需要跟着调整。

过去，我们主要通过亲手编写和阅读代码控制开发过程。

以后，我们或许需要更多地通过目标、约束和验证控制最终结果。

这套方法小编也还在实践，目前大致可以分成四步。

1. 先定义什么叫完成

以前接到需求，我们很容易直接开始想代码怎么写。

但使用 AI 开发以后，如果“什么叫完成”没有提前说清楚，AI 写得越快，返工可能也会越快。

还是以文件上传为例。

如果只告诉 AI：

帮我开发一个文件上传功能。

它确实能够很快生成一个可以运行的版本。

但这个版本和真正能够上线的功能之间，可能还隔着很多问题。

所以，小编现在会尝试先补充完成标准：

• 支持哪些文件；
• 文件大小限制是多少；
• 上传失败如何处理；
• 是否允许重复上传；
• 文件如何保存和访问；
• 最终通过什么方式验收。

这些内容不一定要写成一份很重的需求文档，但至少要让自己和 AI 知道，最后究竟要交付什么。

2. 提前明确不能突破的边界

很多业务系统真正危险的地方，往往不是功能本身，而是隐藏在功能背后的约束。

例如：

• 数据不能丢失；
• 金额不能出现精度误差；
• 关键操作必须保留记录；
• 敏感信息不能进入日志；
• 失败以后必须能够重试或补偿；
• 原有接口行为不能被意外改变。

这些内容如果不提前说明，AI 很可能按照“能够运行”的标准完成代码。

等我们最后再去检查，不仅审查成本很高，返工范围也可能已经扩大。

因此，小编现在更倾向于在生成代码之前，就把关键边界说清楚。

方向越明确，AI 的执行才越有价值。

3. 把普通实现交给 AI

目标和边界明确以后，具体实现可以尽量交给 AI。

常规接口、页面结构、类型声明、重复代码和基础测试，并不一定需要全部亲手完成。

小编以前也会对 AI 生成的代码做很多个人习惯上的调整。

变量名想换一个，方法想重新拆一下，目录结构也想按照自己的习惯再整理一遍。

后来慢慢发现，有些修改只是为了让代码“看起来更像自己写的”，并没有真正改善产品结果。

如果代码能够满足约束、通过验证，也没有引入明显的维护风险，那么很多普通实现其实没有必要反复修改。

程序员的时间有限，应该尽量留给真正需要判断的部分。

4. 用验证代替无差别阅读

不逐行阅读所有代码，不代表完全不检查。

只是检查方式可以从“全部阅读”，逐渐转向“分级验证”。

例如：

• 普通逻辑通过单元测试验证；
• 接口行为通过集成测试验证；
• 完整流程通过场景测试验证；
• 页面功能通过实际操作验证；
• 运行状态通过日志、监控和告警验证；
• 核心业务和高风险代码继续进行人工审查。

这里最关键的变化是：

不再只回答“我有没有看过”，而是开始回答“我怎么证明它是对的”。

如果一个功能无法被验证，即使所有代码都看过，小编心里依然不会真正踏实。

反过来，如果目标清楚、边界明确、关键代码经过审查、完整场景也通过了验证，那么部分普通实现没有逐行阅读，也不一定意味着开发过程已经失控。

六、从写代码的人，慢慢变成解决问题的人

过去，程序员最直接的价值，就是把需求翻译成代码。

需求交过来，我们完成设计、编码、测试和上线。谁能够写得更快、懂得更多、解决更多技术问题，谁的价值就更明显。

但当 AI 可以快速完成大量编码工作以后，单纯写代码的价值一定会受到影响。

这不是说程序员没有价值了。

只是我们的价值，可能正在重新分配。

需求判断、任务拆解、方案取舍、风险控制、结果验证，这些过去容易被编码工作掩盖的能力，会慢慢变得更加重要。

至少在小编自己的开发过程中，已经能够感受到这种变化。

以前遇到一个需求，我首先想的是：

这个功能应该怎么写？

现在我会先多想一步：

这个需求真正想解决什么问题，怎样才算已经解决？

看起来只是提问方式发生了变化，实际上关注点已经从代码转向了结果。

AI 越会写代码，程序员可能越需要跳出代码。

我们不再只是等待任务，然后把它实现出来。还需要判断问题是否成立、任务如何拆分、风险在哪里，以及最后交付的东西是否真的有用。

这并不是说写代码不重要。

而是代码正在从程序员的主要产出，慢慢变成解决问题的一种手段。

小编认为，以后衡量一个程序员的价值，可能不只是看他写了多少代码、掌握多少技术，还要看他是否能够：

• 把一个模糊的问题定义清楚；
• 把复杂任务拆成 AI 可以执行的步骤；
• 识别实现过程中真正危险的地方；
• 建立可靠的验证和反馈方式；
• 对最终交付的产品结果负责。

过去，我们通过掌握代码证明自己的价值。

以后，我们可能需要通过解决问题和交付结果证明自己的价值。

总结

以上只是小编现阶段的一些理解。

这套想法不一定适合所有团队，也不适合所有项目。对于资金、安全、基础设施和核心交易系统，人工审查依然非常重要。即使在普通项目中，我们也不能因为使用了 AI，就忽略代码质量和技术债务。

小编真正想表达的，并不是“代码不用看了”。

而是当 AI 写代码的速度已经超过人的阅读速度以后，我们可能需要重新思考：程序员究竟应该把有限的精力放在哪里？

如果仍然要求自己掌握每一行实现，人工阅读很容易成为新的效率瓶颈。

如果完全不关心代码，只看功能能不能运行，又会把开发变成一次没有边界的赌博。

两种方式都不可取。

在小编看来，比较合适的方向，是按照风险分配注意力：关键代码认真审查，普通实现交给 AI 和自动化验证，同时把更多精力放到需求、边界、风险和最终结果上。

所以，不再为每一行代码负责，并不代表放弃责任。

只是责任正在从代码实现向上移动。

对需求负责，对边界负责，对关键决策负责，对风险负责，对验证负责，最后对交付的产品结果负责。

代码可以交给 AI 生成，方案可以让 AI 辅助，测试也可以让 AI 完成一部分。

但什么问题值得解决，什么结果才算正确，哪些风险不能接受，仍然需要程序员自己判断。

过去，我们通过掌握代码获得控制感；以后，我们可能需要通过掌握目标、边界和验证建立真正的控制力。

这也是小编对「程序员重生计划」的理解。

它不是教别人如何成为新时代的程序员，而是记录小编自己如何重新认识程序员的价值，如何重新划分人与 AI 的责任，以及如何一点一点调整过去的开发方法。

一行一行看代码的时代可能正在结束。

但程序员的责任并没有结束。

它只是从代码本身，慢慢走向了最终结果。