跳到主要内容

Prompt 不是重点，团队代码规范才是

· 阅读需 4 分钟

AI 学的是项目不是提示词。如果代码库风格混乱，AI 会随机学习并混用。提出让代码库更 AI 友好的 4 条建议。

团队上了 Cursor、Copilot 之后，普遍会遇到一个现象：

同样的需求，有的团队 AI 生成出来基本能用，有的生成出来改的时间比自己写还长。

大部分人第一反应是去调 Prompt，但问题通常不在 Prompt。

AI 学的是项目，不是提示词​

现在的 AI 编码工具会大量参考当前代码库。它关注的是项目里沉淀下来的模式：

  • 命名习惯
  • API 调用方式
  • 异常处理风格
  • 同一类需求通常怎么实现

如果同一个问题在仓库里有五种写法，AI 不会替你选一个最好的。它会随机学一套，然后混着用。

很多团队觉得 AI 时灵时不灵，不是模型抽风，是上下文本身就在摇摆。

一个典型场景​

Java 项目里 JSON 处理最常见。

同一个仓库里，Jackson、FastJSON、Gson 各来几处，再包几层工具类。AI 补全的时候就陷入了"选择困难"——这段用 JSONObject，那段用 JsonNode，生成出来的代码能跑，但风格割裂。

维护的人得反复切换思维模型，比全用一种写法累得多。

如果团队只保留一种处理方式，不管用哪个库，关键是统一，AI 很快就会沿着固定轨迹生成。因为它看到的统计规律足够明确。

说白了：AI 在拟合代码分布。代码库越一致，生成越稳定。

为什么规范统一后体验会提升​

降低选择成本。 一个需求有四种历史实现，AI 每次都要猜。统一后它基本不用猜。

提高模式密度。 AI 对高频模式敏感。当大量代码都在重复同一个写法，它会快速建立关联——"这个项目里某某就该这么写"。这比 Prompt 里反复强调有效得多。

减少修正时间。 生成 30 秒，改 20 分钟，提效就是空话。结果贴近团队风格，后处理成本自然小。

Prompt 有用，但不是银弹​

现在有些文章把 Prompt 吹得太玄了。

好像写一句"请按照最佳实践生成高质量代码"，AI 就能顿悟。

没这回事。

Prompt 是即时指令，能影响本次生成的方向——偏性能还是偏可读性，要不要补测试。但它很难长期压过代码库里的既有模式。

项目里到处都是风格混乱、命名随意、异常各写各的，再精致的 Prompt 也救不了。

Prompt 决定这一轮怎么写，代码规范决定 AI 能写到什么水平。

怎么让代码库更"AI 友好"​

和传统工程治理差不多，只是收益被 AI 放大了。

  • 统一工具链。 同一类问题只留一种解法。别让仓库变成技术博物馆。
  • 固化常见模式。 参数校验、异常处理、DTO 转换、日志记录，这些高频场景最好有标准模板，让 AI 一眼能学会。
  • 命名别放飞。 下划线、驼峰、大写开头混在一起，对人都不友好，何况模型。
  • Review 关注一致性。 AI 时代要多看一条：这段代码是否强化了项目的一致模式？你今天 merge 的代码，就是明天 AI 学习的样本。

一个判断标准​

如果你把项目交给 AI，生成结果总让你皱眉：

先别怪模型。先看看仓库里是不是已经埋了很多历史债。

AI 只是把团队长期积累的问题放大并显性化了。它像一面镜子——代码库越整洁，照出来越顺眼；越混乱，它精准复刻这种混乱。

AI 编码真正改变的，不是写代码这件事。它放大了团队工程规范的价值。

以前代码写乱一点，影响可能是半年后某个人维护困难。现在写乱了，AI 会立刻学会，批量复制。

所以与其天天研究 Prompt 技巧，不如把项目整理成一个让 AI 容易学习的代码库。

Prompt 是方向盘。代码规范才是底盘。

底盘不稳，方向盘打得再漂亮，也容易开沟里去。

下一篇，我们将通过实验对比 4 种 JSON 处理方式，量化它们在 AI 编码场景下的差异。