软件开发过程中判断力的重要性

AI可以让一个人拥有接近团队的技术执行能力，但这并不代表，一个人就应该按照大型软件公司的方式开发和维护系统。

过去一段时间，我借助AI参与或完成了多个企业管理和行业软件项目。

随着大模型编程能力不断提高，我发现，很多复杂功能已经不再是最主要的开发障碍。

AI能够阅读源码、分析业务、编写程序、修复Bug，甚至同时调用多个智能体协作完成任务。

但在实际开发中，我反复遇到另一类问题：

AI很能干，却不一定始终朝着正确的方向干。

而真正困难的地方，有时候不是让AI完成任务，而是判断它正在做的事情，究竟是不是当前项目真正需要的。

一、AI为什么容易把小项目做成大工程？

我在使用AI开发软件时发现，它经常倾向于采用看起来更加标准、专业的工程方案。

比如涉及安全、权限、审计、数据备份或者系统稳定性时，AI可能主动建议增加新的服务、复杂的鉴权机制、独立的运行环境，甚至重新组织整个系统架构。

这些方案在大型企业的软件工程中，可能有合理的应用场景。

但问题是，大型软件公司的工程标准，并不天然适合个人独立开发者。

大型团队通常有专门的开发、测试、运维和安全人员，能够分工承担复杂系统的维护责任。

而一个独立开发者，即使借助AI完成了这些技术建设，未来仍然需要自己维护服务、数据库、配置、依赖和故障处理。

每增加一项架构复杂度，就可能增加一份长期维护成本。

这就是软件工程中的过度工程（Overengineering）。

它最隐蔽的地方在于，每一项新增设计单独看起来都很合理，但组合起来，却可能远远超出项目实际需要。

当然，简化工程不意味着放弃必要的安全要求。

权限控制、数据保护、备份恢复和相关合规要求，该满足的仍然必须满足。

真正需要判断的是：

当前项目究竟需要什么能力？有没有更加简单、可靠、符合实际规模的实现方式？

技术先进，不代表适合自己。

二、AI有时候不是解决问题，而是绕开问题

另一个让我印象深刻的现象，是AI面对程序运行故障时的处理方式。

比如，原有服务使用固定端口运行，出现进程占用、服务启动失败或者连接异常。

正常情况下，应该先确认当前进程、服务状态、端口绑定和实际错误原因。

但我遇到过的AI处理方式，有时是原来的问题还没有真正解决，就另外启动一个端口，让程序先运行起来。

从局部任务看，似乎成功了。

新的服务可以访问，接口返回正常，测试也可能通过。

但对于整个项目来说，问题反而变得复杂。

原来的服务还在吗？前端连接的是哪一个后端？两个端口对应的代码版本是否一致？数据又写入哪一个数据库？

原本只有一个运行问题，最后可能变成两个运行实例和一套难以判断的系统状态。

这类现象涉及配置漂移（Configuration Drift）和运行环境一致性问题。

我不认为AI是在有意识地偷懒。

更准确地说，它可能优先追求当前任务的可见成功，而没有充分考虑整个项目的真实运行状态和长期维护成本。

局部问题解决了，不代表系统问题真正解决了。

三、两套环境，为什么可能成为独立开发者的负担？

这也是我过去付出过实际时间成本的问题。

在传统软件工程中，开发环境、测试环境和生产环境分离，是常见做法。

这种设计本身并没有错。

但在一些AI辅助开发过程中，原本只需要修复一个问题，AI却可能不断创建新的候选环境、运行实例或者数据库。

随后出现一种很麻烦的情况：

候选环境测试通过了，正式环境却仍然存在问题。

甚至候选环境已经修复的功能，在更新正式环境以后，又因为配置、数据或版本差异出现新的故障。

我曾经经历过类似的反复折腾，也因此花费了大量时间重新确认究竟哪一套系统才是真正的运行版本。

对于一个人维护的项目，这种复杂度尤其值得警惕。

因为背后没有专门的测试团队、部署团队和运维团队，所有环境之间的差异，最终都需要自己理解、检查和处理。

AI可以很快建立第二套环境，但不会自动消除第二套环境带来的管理成本。

这并不是说独立开发者不能使用隔离测试、临时副本或回滚机制。

涉及真实生产数据、数据库迁移和高风险升级时，必要的隔离验证仍然非常重要。

我真正反对的是：没有明确必要，也没有经过人工确认，就为了绕过眼前的故障，不断增加新的运行链路。

对个人开发者来说，环境不是越多越安全，而是必须清楚每套环境为什么存在、承担什么作用，以及最终怎样得到验证。

四、AI还容易出现需求蔓延和工程跑偏

除了环境问题，我还经历过另一种情况。

原本已经冻结的业务功能，AI在继续开发时，可能因为读取了其他代码、参考了通用框架，或者认为某种设计更合理，就主动修改原有规则。

有时候，它甚至会增加没有要求的新功能。

这些变化从技术角度看，未必没有道理。

但技术上合理，不代表符合已经确认的业务需求。

在软件工程中，这属于需求蔓延（Scope Creep）和变更控制问题。

更值得警惕的是，这种偏离往往不是一次突然发生的。

它可能是今天增加一个字段，明天调整一个接口，后天又重构一部分已经稳定的功能。

每一次修改看起来都不大，最后却逐渐改变了项目原来的结构和业务边界。

如果开发者只关注AI提交的任务有没有完成，没有持续检查整体方向，就可能直到系统变得越来越复杂，才发现已经偏离原来的目标。

AI的执行效率越高，错误方向造成的返工成本也可能越大。

五、为什么我开始建立自己的AI防跑偏原则？

经历多次项目开发和复盘以后，我逐渐认识到，仅仅要求AI认真工作、不要出错，远远不够。

因为AI不只会产生事实幻觉，也可能在工程实施中出现目标错配、过度扩展和未经授权的决策。

这让我开始整理自己的《AI项目防跑偏最高原则》。

它并不是什么高深的技术框架，而是来自实际开发过程中反复遇到的问题。

核心目的只有一个：

让AI的技术执行始终受到真实业务目标、项目规模和个人维护能力的约束。

已经确认的业务规则，不允许AI凭经验擅自修改。

已经稳定运行的功能，不因为代码还能优化，就随意重构。

遇到工程问题，优先查明原因，而不是未经确认就扩大架构。

涉及重要变更，先解释影响和风险，再由人决定是否执行。

同时，我也开始更加重视实际运行结果、版本一致性、数据真实性和人工验收。

这些原则并不能彻底消除AI幻觉，也无法保证每次开发都不出错。

但它们能够帮助我在AI开始偏离目标时，更早地发现问题，避免错误不断扩大。

六、真正重要的是，你能不能看出AI正在跑偏

回头看，我认为AI软件开发中有一种能力，很容易被低估。

那就是开发者自己的判断力。

当AI建议采用一套更加复杂的架构时，你能不能判断它有没有必要？

当AI报告测试已经通过时，你能不能识别测试环境与实际运行环境的区别？

当AI主动增加功能时，你能不能发现它已经超出了原来的需求？

当一个问题反复修复都无法解决时，你能不能重新审视方法，而不是继续沿着同一条路线消耗时间？

这些事情，并不会因为大模型的编程能力变强，就自动得到解决。

相反，当AI能够快速生成越来越多的代码、配置和工程方案时，人的判断责任可能变得更加重要。

我不认为自己已经掌握了最好的软件开发方法，也不认为个人经验能够适用于所有项目。

但我逐渐形成了一个明确的认识：

一个人能够借助AI完成团队级别的部分技术工作，不代表他就应该承担团队级别的全部工程复杂度。

软件开发不是技术越多越好，也不是架构越标准越好。

真正重要的是，系统能否正确解决业务问题，能否稳定运行，出了问题能否查清楚，以及自己未来是否维护得住。

对我来说，AI时代的软件开发能力，不只是知道怎样让AI写代码。

更重要的是，能够判断哪些事情应该做、哪些不应该做，什么时候需要继续推进，什么时候应该停止并重新审视方向。

AI决定了任务可以执行得多快，而人的判断力，决定了这些任务是否值得执行，以及最终会把项目带向哪里。

真正需要警惕的，不是AI做得不够快，而是它可能非常高效地，把一个原本简单的项目做得越来越复杂。