转 AI 这三个月，我戒掉的 5 个坏习惯

 

从传统 Java 开发，到开始用 AI 做完整的事情

我做了很多年传统 Java 开发。

以前接到一个需求，我通常会先想接口怎么拆、表怎么设计、业务代码放在哪一层，再估一下开发时间。这样的工作方式没有错，很多年里它也确实帮我把系统做得比较稳定。

但开始真正接触 AI 应用以后，我慢慢发现，过去一些被我认为是“严谨”的习惯，放到现在的开发环境里，反而会拖慢自己。

不是 Java 没用了，也不是传统开发经验没用了。相反，分层、鉴权、异常处理、数据库和工程规范，依然是项目能不能跑稳的基础。变化在于，AI 已经可以帮我们完成大量基础工作：写接口、补测试、生成页面、查文档、改报错，甚至把一个简单功能从想法变成初版。

如果程序员还把大量时间花在“把已经会做的事情再手写一遍”，价值就会越来越有限。

这三个月，我没有突然变成什么 AI 专家，也没有掌握所有新技术。只是做项目的过程中，慢慢戒掉了五个以前很习惯、现在却不太适合继续坚持的做法。

一、戒掉“先把需求研究透，再开始动手”

以前拿到一个需求，我习惯先开会、记笔记、画流程图，再确认接口、字段和各种边界情况。等这些都想得差不多了，才开始写第一行代码。

传统系统这样做有它的道理。特别是医疗、金融这类业务，很多地方不能随便试，前期确认越充分，后面返工越少。

但做 AI 应用时，如果一开始就想把所有细节都想清楚，项目很可能一直停留在讨论阶段。

比如我之前做一个简单的业务智能体，最开始花了不少时间讨论：要不要拆成多个 Agent，知识库怎么规划，提示词要不要抽成配置，失败场景怎么覆盖。讨论了一圈，真正能运行的东西还没有。

后来我换了做法，先做一个最小版本：输入一段业务描述，让模型完成分类，再调用一个固定工具返回结果。功能很简单，甚至算不上完整产品，但它很快跑了起来。

跑起来之后，很多问题自然就出现了：有些输入模型判断不准，有些结果格式不稳定，工具调用失败后没有提示，用户也不知道下一步该做什么。这些问题如果只靠想，很难提前全部想到；只有真正操作一遍，才知道哪里需要设计。

现在我会把需求拆成两部分：

第一部分是不能错的东西，比如权限、数据范围、敏感信息和业务规则。这些要提前确认。

第二部分是可以试的东西，比如交互方式、提示词写法、页面布局和流程顺序。这些不必一开始就追求完美，先做一个能跑的版本，再根据实际结果调整。

以前我觉得“没想清楚就开工”是不专业。现在我更愿意把它理解成：先用一个小版本验证方向，再决定是否值得继续投入。

二、戒掉“只关注代码，不关心用户到底要什么”

传统开发很容易形成一种惯性：需求文档写什么，我就实现什么；接口能返回数据，任务就算完成。

以前我判断一个功能做得好不好，主要看几个方面：代码结构是否清晰，接口是否规范，查询是否高效，异常是否处理，日志是否完整。

这些当然重要，但还不够。

做 AI 应用后，我开始经常问自己几个问题：这个功能到底替谁省了时间？用户原来是怎么完成这件事的？他最担心的是结果不准，还是过程太复杂？如果模型回答错了，用户有没有办法发现和纠正？

比如做一个内容分析功能时，最开始我只想着让模型输出一份完整报告。提示词写得很长，返回字段也很多，看起来内容很丰富。

但实际使用时，用户并不想先看一大段分析。他更关心的是：有没有问题，问题在哪里，应该先改什么，改完之后怎么验证。

于是我把输出拆开了。先给结论，再列出具体问题，最后给出可以执行的修改建议。这样一来，模型输出少了，用户反而更容易使用。

这件事让我意识到，AI 项目和普通接口项目有一个明显区别：接口返回结果，不代表功能有价值。结果能不能被理解，能不能帮助用户做下一步决定，才是更重要的事情。

以前我的工作更像是“把别人定义好的功能实现出来”。现在我会主动往前多走一步，至少弄清楚这个功能为什么存在，以及用户用完以后要做什么。

这可能就是我最近常说的“产品思维”。它不一定意味着马上变成产品经理，而是不能只盯着代码，要开始关注问题、场景和结果。

三、戒掉“凡事都想自己写，不愿意让 AI 参与”

我刚开始用 AI 辅助开发时，其实有点抗拒。

总觉得自己写出来的代码更放心，AI 生成的代码不够优雅，担心它不理解项目结构，也担心以后出了问题不好维护。所以很多时候，我明明可以让 AI 先搭一个初版，还是选择自己从头写。

后来发现，这种坚持并不总是代表负责，有时只是习惯。

一些重复性的工作，比如 DTO、基础接口、测试数据、SQL 初稿、参数校验、接口文档、前端表单，完全可以先交给 AI 处理。生成的内容不能直接上线，但可以作为一个起点。

我现在会把任务分成三类。

第一类是重复、明确、容易检查的工作。这些可以让 AI 先做，比如生成基础代码、补测试、转换数据格式。

第二类是需要结合项目上下文的工作。这些可以让 AI 辅助，但必须提供清楚的目录结构、业务规则和约束，生成后再逐段检查。

第三类是涉及架构、权限、核心业务和风险的决策。这些不能因为 AI 给了一个看起来合理的答案，就直接交出去。方案怎么选，边界在哪里，出了问题谁负责，还是要自己判断。

现在我不再把 AI 当成一个“替我写完全部代码的人”，而是把它当成一个速度很快、知识面很广，但需要我不断校验的协作者。

比如我会让它先给出三种实现方式，再要求它比较适用场景；也会把一段报错和相关代码发给它，让它先分析可能原因，再由我决定怎么改。这样比直接说“帮我写一个完整系统”更有用，也更容易控制质量。

真正需要戒掉的，不是自己写代码，而是把“亲手写过每一行”误认为“这个项目才算属于我”。

四、戒掉“只在熟悉的技术栈里解决问题”

做传统 Java 久了，很容易有自己的舒适区。

后端用 Spring，数据库用 MySQL，缓存用 Redis，遇到问题就按过去的经验排查。这种积累是优势，但也可能让人只愿意用熟悉的方式解决新问题。

刚开始做 AI 应用时，我总想把它完全塞进自己熟悉的后端结构里。模型调用就当作一个普通接口，提示词写在代码里，结果存进数据库，能跑就先算了。

这样做并非不行，但做着做着就会发现，AI 应用有自己的问题：模型输出不是固定的，知识库检索会有误差，工具调用可能失败，任务执行需要重试，成本和响应时间也要考虑。很多地方不能直接照搬传统 CRUD 的思路。

我开始补一些过去没有认真接触过的东西：向量检索、Embedding、提示词约束、结构化输出、流式响应、工具调用和任务编排。刚开始这些词看起来都很新，但真正放进项目里以后，也不是完全陌生。

例如，向量检索解决的是“怎么找到相近内容”；工具调用解决的是“模型怎么触发系统能力”；任务编排解决的是“多个步骤怎么串起来”。换一种说法，它们和传统开发中的查询、接口调用、流程控制，本质上仍然有相通的地方。

这让我慢慢放下了一个顾虑：转 AI 不一定意味着要抛弃原来的技术栈，重新从零开始。更现实的方式，是利用原有的工程经验，再补上新的能力。

当然，也不能因此拒绝学习新工具。现在我会根据问题选择工具，而不是先问“这个是不是 Java 的标准做法”。只要方案可靠、成本可控、能维护，就没有必要为了保持熟悉感而拒绝变化。

五、戒掉“把自己定位成只负责写代码的人”

以前别人问我做什么，我会很自然地回答：Java 后端开发。

这句话没有错，但它描述的是我使用的工具，不完全是我能解决的问题。

AI 普及以后，很多基础功能确实不再需要程序员花很长时间从头实现。一个简单的接口、一个后台页面、一段数据处理逻辑，AI 往往几分钟就能给出初版。

这对程序员来说既是压力，也是提醒。

如果我的价值只是“把需求翻译成代码”，那么代码生成得越快，我能发挥的空间就越小。以后更重要的能力，可能是理解问题、设计方案、判断风险、组织资源，再把结果真正交付出来。

这三个月，我开始有意识地把自己的工作范围往外扩一点。

除了写后端，我会看用户流程，想功能是否真的必要；会自己搭一个简单的页面，方便验证交互；会关注部署、日志和失败后的处理；还会记录用户使用时卡在哪里，而不是只看接口有没有返回 200。

有时我甚至会先写一页简单的功能说明，再开始写代码。说明里不讲复杂术语，只写清楚四件事：谁来用，遇到什么问题，系统怎么帮他，最后应该得到什么结果。

这样做以后，我发现自己不再只是等待任务分配，而是在尝试把一个问题从想法推进到可以使用的状态。

我不敢说自己已经是“全能型人才”，这个词听起来太大了。但我确实越来越觉得，未来的程序员不能只守住一个岗位边界。懂一点业务，懂一点产品，懂一点交互，懂一点部署，再加上可靠的工程能力，可能比单纯把某一门语言写得很熟更重要。

所谓全能，并不是每件事都做到专家水平，而是面对一个问题时，知道该怎么拆、怎么验证、什么时候借助 AI、什么时候必须自己判断，并且能把事情推进到结果。

写在最后：AI 变快了，程序员不能只让自己写得更快

转 AI 的这三个月，我最大的变化不是学会了多少名词，而是开始重新审视过去的工作方式。

我以前习惯先研究透再动手，现在会先做小版本验证；以前更关注代码是否完成，现在会多问一句用户是否真的用得上；以前担心 AI 影响自己的工作，所以不太愿意用，现在会把重复工作交给它，把时间留给判断和设计；以前更愿意待在熟悉的 Java 体系里，现在会根据问题补新的能力；以前认为自己只要把代码写好就够了，现在开始主动关心一个功能能不能真正落地。

这些变化并不是因为传统开发过时了。恰恰相反，系统稳定性、业务理解和工程责任感，仍然是 AI 应用最容易缺少的部分。

只是未来的开发工作，可能不会再把“写出代码”当成最难的环节。真正难的，是判断该做什么，怎么做得可靠，出了问题怎么处理，以及能不能把一个想法变成用户真正愿意使用的东西。

所以我现在给自己的提醒是：不要只训练自己写得更快，也要训练自己想得更清楚，做得更完整。

代码可以让 AI 帮忙写，方向、取舍和最后的结果，还是要自己负责。

这可能就是一个传统 Java 开发者，开始转向 AI 辅助开发之后，最需要改变的地方。

如果你也在从传统开发转向 AI，或者正在尝试把 AI 用到自己的项目里，欢迎在评论区聊聊。你最近戒掉了哪个习惯，又开始培养什么新的能力？