在个人项目与企业代码库中使用 AI

Source: Dev.to

最初发布于 johnvw.dev

Source:

我使用 AI 的方式出现了转变

作为一名资深软件工程师，我在大型企业软件项目中大量使用 AI。尽管在这方面投入颇多，我在个人项目中却很少使用它。大约一年前，我在这些工具仍相对新颖时进行过一些尝试，但此后我的使用基本都局限于职业环境。

这种情况最近发生了变化。

我使用 GPT 5.2 完全构建了一个个人网站（也许正是你正在阅读的地方）。这次体验令人受益匪浅，凸显了在小型个人项目中使用 AI 与在大型企业系统中使用同样工具之间的一些重要差异。

以下是我从这种对比中得到的一些教训。

当 AI 几乎像魔法一样

对于我的个人项目，我创建了一个简单的静态博客。我先放了一个占位的登录页面，简要描述了我的需求，AI 生成了一个大约 90 % 符合我想法的页面。再经过几次交互后，我们就准备好了第一个可用版本。

我立刻把它上传，以免在我真正想要的功能博客还在开发时网站是空的。从头到尾，包括一些托管配置，整个过程大约用了 一个小时——远快于我的预期。

第二天，我坐下来开始构建博客本身。即使使用现代工具，我也预计要花几晚的时间。我想看看 AI 能把这个过程加速到什么程度。

结果，它真的加速了。

清晰的规范、小故事与快速进展

我先向 AI 说明了项目的情况：约束条件、配色、技术选型，以及同样重要的不想要的东西。我让它把所有内容写进仓库根目录下的 SPEC.md 文件，这样我们可以在开发过程中不断完善并随时查阅。

AI 提出了一些澄清性问题，经过几轮来回讨论后，规范达到了我满意的程度。

随后，我开启了一个新对话，和它一起把规范拆分成若干小的、可执行的故事（stories）。这些故事我们也一起细化。即使在项目演进过程中，我仍会再添加一些故事。

当故事准备就绪后，我再次开启新对话，请求 AI 实现第一个故事，并在需要时参考规范。

这时我的大脑开始“熔化”了。

企业对比

在工作中，我习惯在大型系统上使用 AI。我习惯向它提供上下文，帮助它理解需求（stories），并让它完成大部分实现工作。但我也习惯这会花费时间。等待几分钟才能得到响应并不罕见，随后还要花更多时间审查它生成的内容。

即使我把任务保持得很小，遗留系统往往也需要大量上下文才能理解看似简单的更改。

这里却不是这种情况。

在一两分钟内，AI 就完成了第一个需求——而且从我能判断的情况来看，它把所有工作都正确完成了。我让它提交并推送了更改，然后打开一个新聊天，让它实现下一个需求。

于是如此进行。

每个需求都被快速且完整地实现了。正是这时，可能性真正开始在我脑海中浮现。

为什么简单工作正在商品化

如果 AI 能这么快发展，是什么阻止人们构建任何他们想要的简单项目？在很多情况下，仅仅是他们自己的动力。这实际上 使简单工作商品化，降低了人们在没有外部帮助的情况下构建小系统的门槛。

但随后我想到了我的日常工作。

我所工作的系统规模庞大。尽管现代模型令人印象深刻，但它们不可能在上下文窗口中容纳整个系统。不过，AI 在那里无疑是有用的；只是表现方式不同。

这种对比引出了一个重要问题：我们可以从这两种环境中学到什么？

第一期课：上下文决定一切

在小型系统中，AI 可以在其上下文窗口中容纳大部分甚至全部相关代码。虽然你可能不想这么做，但关键要点是系统本身更简单，也更易于推理。

想要添加新页面吗？ 提供需求和一点上下文，你很可能在几分钟内得到一个可靠的实现。

在企业系统中，同样的更改是可能的，但前提是你必须更加慎重。你不能仅仅描述你的需求，而需要向 AI 提供它缺乏的架构上下文：

• 你使用的是哪个路由？
• 页面采用了哪些既定模式？
• 这段代码应该放在哪里？
• 是否有现有页面可供它参考？

提供这些信息会显著提升成功的概率。是的，这比个人项目要花更长时间，但如果不提供，你会陷入反复纠正误解的循环——随着上下文窗口被填满，模型性能下降。

第二课：小块是领导力技能

与上下文密切相关的是将工作拆分为小而可管理的部分的能力。对我而言，这根本上是一项 tech‑lead 技能。

技术负责人与产品经理合作，将用户需求转化为技术需求。我们将这些需求组织成小而可行的块，以便团队能够快速推进，而不会陷入困境。

同样的技能在使用 AI 时也极其宝贵。

• 工作项越小，提供完整上下文就越容易。
• 交互越顺畅，获得可测试和改进的工作软件就越快。
• 更快的反馈循环意味着你可以更早发布、更早学习、也更早调整。

这就是强化版的敏捷软件开发。

AI 放大约束

所有这些都凸显了一个更深层的问题：AI 放大约束。

最近出现了很多类似的观点，例如，“AI 并没有毁掉这家公司，它暴露了糟糕的商业模式”，或者，“AI …”

(原文在此处截断；预期的结论可能会进一步阐述 AI 如何揭示现有的流程和架构弱点。)

> “didn’t cause these layoffs, it exposed poor performance.”  
> While I don’t fully agree with those claims, I do agree with the underlying idea: as systems become more efficient, their weaknesses become more visible.

As coding gets faster, bottlenecks shift elsewhere. If implementation takes minutes, what about:

- UX research?  
- Requirements gathering?  
- Testing?  
- Deployment?  
- Maintenance?  
- Architectural shifts?

This is why small personal projects can move at breakneck speed while large enterprise systems often feel slow—even with AI moving things along. It’s rarely the tools that are the problem; more often, it’s the surrounding process. That’s not a criticism of enterprise environments—it’s a reality of scale. The more customers, products, and revenue you have, the more those supporting processes matter.

**The real question** is how we improve those areas alongside our tooling.

随着编码速度加快，瓶颈会转移到其他地方。如果实现只需要几分钟，那么以下方面怎么办：

• 用户体验研究？
• 需求收集？
• 测试？
• 部署？
• 维护？
• 架构变更？

这就是为什么小型个人项目可以以飞快的速度推进，而大型企业系统常常显得缓慢——即使有 AI 的加持。问题往往不在于工具本身，而是周围的流程。这里并不是对企业环境的批评，而是规模带来的现实。客户、产品和收入越多，这些支撑流程就越重要。

真正的问题是我们如何在改进工具的同时提升这些方面。

高级工程师的定位

我认为没有唯一的 definitive（确定）答案，但其中一部分取决于 所有权：

• 在合理范围内，尽可能拥有产品生命周期的各个环节。
• 在无法拥有的地方，发挥积极影响。

AI 并不会消除高级工程师的技能；相反，它会提升这些技能的价值。管理约束、提供上下文、拆解工作以及系统性思考的能力，在 AI 辅助的世界里变得更加重要。

这对有经验的工程师并不是威胁，而是机遇。

讨论提示

• 你在工作中是否注意到类似的模式？
• 在小型项目与大型代码库中使用 AI 有哪些差异？
• 你会向他人分享哪些经验教训？