AI 开发真实产品，先审影响再改代码

AI 能把功能写出来，不代表它已经替你想清楚整个系统。作者尝试用 AI 辅助开发一个包含数据库、定时任务、API、用户账户和数千个动态页面的真实产品，得到的结论是：开发越快，越需要先理解改动范围，再验证结果。

这篇没有模型跑分，也没有效率提升百分比。它的价值是把 AI 编程从「生成代码」拉回工程现场：数据量变大怎么办，自动任务出了问题怎么查，以及每次改动该怎样收住范围。

让 AI 动手之前，先让它查清影响范围

作者发现，直接要求 AI「实现功能 X」，对独立功能往往有效。但应用规模扩大后，局部修改可能牵动其他部分，任务就不再只是把一段代码写对。

他因此调整了提问方式：先审查现有实现，解释哪些组件会受影响，然后再提出最稳妥的实现方案。

先让 AI 解释改动会影响哪里，再让它修改代码。

这一步的作用，是把隐含依赖变成可以检查的说明。开发者有机会在代码改动前发现理解偏差，也能判断方案是否超出了需求范围。

作者称，这种调整避免了不少不必要的问题。不过，原文没有给出具体案例或前后对照；关于系统哪些部分会互相影响，原文对应的列表也有缺失，不能替作者补成一套完整架构方法。

数据从 100 条变成数万条，问题才开始显形

作者强调，真实数据与简单 CRUD 教程之间有明显距离。处理 100 条记录时表现正常的系统，面对数万条记录，可能出现完全不同的性能表现。

他举出的例子很朴素：一次小查询耗时不显眼，但在导入过程中重复执行数万次，就可能成为最慢的环节之一。

这里该关注的是执行次数。审查 AI 生成的数据处理代码时，只看单次操作是否正确还不够，还要看它是否被放进循环，以及整批任务会执行多少次。

后台处理又增加了一层困难：任务自动运行，开发者未必能直接看到过程。因此，作者希望每天导入数千条记录的任务至少能回答：

• 一共处理了多少条记录。
• 创建了多少条记录。
• 跳过了多少条记录。
• 时间主要花在哪里。

这些数字构成了基础的可观测性（Observability），也就是让系统留下足够的信息，帮助人判断它做了什么、慢在哪里。作者认为，补齐基础指标和日志，有时比增加一个功能更有价值。

原文没有提供查询耗时、导入总时长或优化结果，所以这里能拿走的是排查方向，不能据此判断某种优化能提速多少。

Vibe coding 的关键，是每次改动都能验证

作者认可 Vibe coding，但他采用的流程包含明确的检查步骤：

1. 描述期望结果。
2. 让 AI 检查现有实现。
3. 要求 AI 解释风险。
4. 做一次范围可控的修改。
5. 测量修改后的变化。

这套流程把「生成成功」与「修改有效」分开了。AI 完成编辑，只能说明代码已经发生变化；结果是否符合预期，还需要后续验证。

开发速度越快，验证就越不能省。

作者也认为，持续维护一个线上应用，比尝试孤立示例更能帮助他学习。真实产品会迫使开发者面对数据规模、后台任务和工程决策，而这些问题未必会出现在教程里。

我的判断

我认同作者把审查、日志和验证放回 AI 编程流程。它们都是常规工程实践，AI 提高了代码产出速度，也让遗漏这些步骤的代价更容易累积。

但这篇属于个人经验，作者没有提供对照数据，也没有说明所用模型、工具、测试方式和具体架构。不能从中推导出某个提示词能稳定降低多少缺陷，更不能把「作者避免了不少问题」当成普遍结论。

和直接要求 AI 一次完成整个功能相比，这种流程更方便人工检查；遇到跨模块的大改动，仍然需要设计评审和相应测试。让 AI 自述风险可以辅助审查，但它可能与生成代码时共享同一个理解盲点。

能拿来做什么

• 给现有前端或 Node 项目加功能时，先要求 AI 阅读相关实现，列出受影响组件及理由，再据此确定修改范围。
• 检查 Node 数据导入任务时，重点找循环内部的重复查询，并按实际数据规模验证，别只用 100 条记录判断性能。
• 给每日自动任务补上处理数、创建数、跳过数和各阶段耗时，让异常结果有据可查。
• 把 AI 编程任务拆成可控改动，每次提前说明预期结果和验证方法，完成后检查实际变化。