AI 为啥会写出 if (obj != null && obj.ifEnabled) 这样的代码
最近在使用 AI 辅助编程时，我发现一个很有意思的现象。
即使我的项目中已经大量使用了 Hutool、Guava 或公司内部工具库，AI 依然经常生成这样的代码：
csharp
if (userInfo != null && userInfo.ifEnabled) {
// 业务代码
}而不是我项目中更常见的写法：
less
if (ObjectUtil.isNotEmpty(userInfo) && userInfo.ifEnabled) {
// 业务代码
}或者：
kotlin
if (ObjectUtil.isEmpty(userInfo)) {
return;
}
if (userInfo.ifEnabled) {
// 业务代码
}按照很多开发者的理解：
AI 既然能看到我的代码，不是应该自动遵循我的编码风格吗？
事实上，并没有那么简单。
AI 为什么会这样写？
它学习的是全世界的代码
对于大模型来说：
yaml
if (obj != null)是整个互联网出现频率最高的空值判断方式之一。
无论是：
- JDK 官方代码
- Spring 源码
- 开源项目
- 教程示例
- 面试题答案
几乎都大量存在这种写法。
而：
scss
ObjectUtil.isNotEmpty(obj)则属于 Hutool 特有的风格。
即使在国内项目中很常见，但放到整个训练数据集里，占比其实非常小。
因此当 AI 不确定你的项目习惯时，它会优先生成最通用、最保险的代码。
AI 默认会减少外部依赖
对于 AI 来说：
yaml
if (obj != null)只依赖 JDK。
而：
scss
ObjectUtil.isNotEmpty(obj)意味着：
- 项目引入了 Hutool
- 版本兼容
- 工具类存在
- 导包正确
如果 AI 无法确定这些条件成立，它更倾向于生成原生代码。
因为：
原生代码永远能运行。
这是大模型的一种风险最小化策略。
AI 更偏向显式代码
从可读性的角度看：
yaml
if (userInfo != null)任何 Java 开发者都能瞬间理解。
而：
scss
ObjectUtil.isNotEmpty(userInfo)则需要知道：
- Hutool 是什么
- ObjectUtil 的实现逻辑是什么
- isNotEmpty 对对象、字符串、集合的判断规则是什么
对于 AI 来说：
显式代码的理解成本最低。
因此默认生成结果也更倾向于显式写法。
算法代码更倾向于纯净实现
还有一个容易被忽略的原因。
当你让 AI 生成：
- 排序算法
- 数据结构
- LeetCode 题解
- 工具函数
时，它几乎不会主动使用：
ObjectUtil
StrUtil
CollUtil
BeanUtil而是会写：
ini
if (arr == null || arr.length == 0)原因在于：
算法类代码通常追求：
- 独立运行
- 无第三方依赖
- 易于移植
- 易于测试
对于 AI 来说：
这是最标准、最安全的实现方式。
AI 真的会学习你的代码风格吗？
答案是：
会，但程度有限。
很多开发者误以为：
AI 看了几百个文件以后，就会完全按照项目风格编码。
实际上大多数 AI 编程工具采用的是：
diff
当前文件
+
相关文件
+
少量上下文
+
模型训练知识进行推理。
真正影响最大的往往还是：
模型训练知识因此即使项目里：
ObjectUtil
BeanUtil
CollUtil出现了上千次，
AI 依然可能写出：
yaml
if (obj != null)因为这是它最熟悉的模式。
如何让 AI 遵循你的编码规范？
很多团队开始使用 AI 编程后都会遇到这个问题。
解决方案其实不是反复修改 AI 生成的代码。
而是：
给 AI 提供稳定且明确的规约（Rule）。
例如：
markdown
# Java开发规范
1. 所有空值判断优先使用 Hutool ObjectUtil
2. 字符串判断优先使用 StrUtil
3. 集合判断优先使用 CollUtil
4. 禁止直接使用 obj != null
5. 日志统一使用 Slf4j当 AI 每次生成代码前都读取这份规则时，结果会稳定很多。
为什么顶级团队都在维护 AI 规约？
现在越来越多的团队开始维护：
原因很简单：
AI 本身是通用的。
而项目是个性化的。
规约就是连接两者的桥梁。
它相当于告诉 AI：
我们团队怎么写代码
我们团队怎么命名
我们团队怎么处理异常
我们团队怎么写注释
我们团队怎么使用框架这样 AI 才能真正成为团队成员，而不是一个只会写通用代码的助手。
GitHub 上优秀的 AI 规约仓库
随着 AI Coding 的普及，越来越多开发者开始开源自己的 Rules 和 Skills。
这些仓库本质上是他们多年经验的沉淀。
Awesome Cursor Rules
GitHub：
收录了：
- React
- Vue
- Next.js
- NestJS
- Python
- Laravel
等大量现成规则。
Awesome Claude Code
GitHub：
目前最知名的 Claude Code 资源导航。
包含：
- Skills
- Hooks
- MCP
- SubAgents
- Workflow
等内容。
Claude Code Examples
GitHub：
Anthropic 官方示例仓库。
可以学习：
- Skills 如何编写
- Commands 如何组织
- 工作流如何设计
Everything Claude Code
GitHub：
目前社区最完整的 Claude Code 配置集合之一。
包含：
- Skills
- Commands
- Hooks
- MCP
- Agents
等大量实战案例。
如何安装这些规约？
很多开发者收藏了一堆仓库后发现：
不知道怎么使用。
实际上这些内容本质上都是：
diff
Markdown
+
目录结构
+
约定俗成的位置只要放到正确目录即可。
Claude Code
项目级规则：
css
my-project/
├── CLAUDE.md
└── srcClaude 会自动读取：
objectivec
CLAUDE.md作为项目规范。
Skills：
markdown
.claude/
└── skills/
├── java-review
├── springboot
└── architecture直接将 GitHub 下载的 Skill 放进去即可。
全局 Skills：
javascript
~/.claude/skills/所有项目共享。
Cursor
推荐目录：
arduino
.cursor/
└── rules/
├── java.mdc
├── vue.mdc
├── testing.mdc直接将下载的 Rules 文件复制进去即可。
老版本：
.cursorrules依然支持。
Codex
项目根目录：
AGENTS.md例如：
css
my-project/
├── AGENTS.md
└── src用于定义：
- 编码规范
- 测试规范
- Git 提交规范
- 项目约束
从提示词工程到规约工程
2023 年大家讨论的是：
Prompt Engineering如何写提示词。
2024 年开始讨论：
Context Engineering如何提供上下文。
而今天越来越多团队讨论的是：
Rule Engineering即：
diff
项目知识
+
团队规范
+
最佳实践
+
工作流统一沉淀成 AI 可以读取的资产。
规约才是 AI 编程时代的核心资产
很多人觉得 AI 写代码越来越强。
实际上更准确地说：
AI 并没有真正理解你的项目。
它理解的不是业务，而是上下文；
不是团队文化，而是规则；
不是经验本身，而是经验的表达形式。
那些曾经存在于开发者大脑里的经验，记录在开发规范里的约定，沉淀在最佳实践里的方法论，隐藏在无数次 Code Review 和线上故障复盘中的知识，如今第一次拥有了被数字化的机会。
过去，新成员可能需要数月甚至数年的时间，才能逐渐理解这些隐性的经验。
而今天，我们可以把这些经验蒸馏成：
让 AI 直接学习和执行。
从某种意义上说：
这些文件并不是简单的配置文件。
它们是团队经验的载体，是工程文化的数字化表达。
总结
当 AI 写出：
yaml
if (obj != null && obj.ifEnabled)时，
它只是选择了自己最熟悉、最通用、风险最低的方案。
如果希望它输出：
less
if (ObjectUtil.isNotEmpty(obj) && obj.ifEnabled)甚至完全符合团队规范的代码，
那么最重要的不是换模型，而是建立属于自己的规约体系。
未来团队之间真正的竞争力，或许不再是谁拥有更强的模型，而是谁拥有更完善的知识沉淀体系。
因为模型终将趋同。
而经验，永远稀缺。
延伸阅读：优秀规约与官方参考文档
如果你准备开始构建自己的 AI 规约体系，下面这些资料值得收藏。
建议不要一次性全部阅读。
而是：
- 先建立自己的第一份规则
- 在项目中实际使用
- 遇到问题后再查阅这些资料
效果会更好。
Claude Code 官方文档
Claude Code 是目前 Rules、Skills 生态最成熟的 AI 编程工具之一。
Claude Code 官方文档
docs.anthropic.com/en/docs/cla...
推荐重点阅读：
CLAUDE.md
项目级规则文件。
用于告诉 Claude：
- 项目结构
- 编码规范
- 技术栈
- 测试要求
- 开发约束
参考：
docs.anthropic.com/en/docs/cla...
Skills
Claude Code 最强大的能力之一。
用于封装：
- 架构设计经验
- Code Review 经验
- 测试经验
- 调试经验
参考：
docs.anthropic.com/en/docs/cla...
以及：
Hooks
在 AI 执行前后自动运行脚本。
例如：
- 自动格式化代码
- 自动执行测试
- 自动提交 Git
参考：
docs.anthropic.com/en/docs/cla...
OpenAI Codex 官方文档
随着 Agent 能力增强，OpenAI 正在逐步推动：
AGENTS.md成为项目规范的重要载体。
官方文档：
platform.openai.com/docs/codex
推荐阅读：
AGENTS.md
项目级规则文件。
用于定义：
- 项目规范
- 开发约束
- 测试要求
- 架构原则
参考：
developers.openai.com/codex/guide...
Cursor 官方文档
Cursor 是目前开发者使用最广泛的 AI IDE 之一。
官方文档：
重点阅读：
Rules
了解：
- Global Rules
- Project Rules
- Auto Attached Rules
- Rule Scope
AGENTS.md
AGENTS.md 正在成为跨平台的事实标准。
官方网站：
核心目标：
一次编写
多工具复用例如：
css
AGENTS.md
├── Claude Code
├── Codex
├── Gemini CLI
├── Cursor
└── Copilot未来都可能支持。
优秀的 GitHub 规约仓库
这些仓库最大的价值不是直接复制。
而是学习：
高水平开发者是如何组织经验的。
Awesome Claude Code
目前最知名的 Claude Code 资源导航。
包含：
- Skills
- Commands
- Hooks
- MCP
- Workflow
- Agents
Anthropics Skil
Anthropic 为 Claude 实现的技能，要是用好Claude Code等 Claude 相关场景，了解并使用它是非常有必要的。是 Anthropic 官方维护的 Claude Skills 实现，包含了丰富的示例技能、开发模板和完整文档，是学习和构建 Claude 技能的最佳起点。
- 官方权威性 - Anthropic 官方维护的 Claude Skills 实现，包含 Claude 文档能力背后的源代码（DOCX、PDF、PPTX、XLSX 处理技能），提供最权威的参考实现。
- 实用性强 - 技能涵盖创意设计、技术开发到企业工作流的多样化场景，可直接在 Claude Code、Claude.ai 和 Claude API 中使用。
- 学习价值 - 提供完整的技能开发模板和最佳实践文档，包括
skill-creator元技能用于创建和优化其他技能，以及详细的 Agent Skills 规范说明。 - 技术深度 - 包含 Managed Agents、MCP 服务器构建指南、Prompt Caching 优化等高级功能，适合深入研究 Claude API 和 Agent 开发。
Everything Claude Code
社区最完整的 Claude Code 实战仓库之一。
包含：
- Skills
- MCP
- Commands
- Hooks
- Agents
非常适合学习目录组织方式。
Awesome Cursor Rules
Cursor Rules 最大收集仓库之一。
覆盖：
- React
- Vue
- Next.js
- NestJS
- Python
- Go
- AI Agent
AI Nexus
一个非常有意思的项目。
目标是：
一份规则
同步多个 AI 工具支持：
- Cursor
- Claude Code
- Codex
未来很可能会出现更多类似工具。
推荐阅读书单
如果你希望进一步理解：
- 为什么规则重要
- 为什么团队规范重要
- 为什么经验能够被蒸馏
那么下面这些经典书籍值得反复阅读。
《人月神话》（The Mythical Man-Month）
作者：Frederick P. Brooks Jr.
软件工程领域最经典著作之一。
很多团队协作问题今天依然存在。
《代码大全》（Code Complete）
作者：Steve McConnell
关于：
- 编码规范
- 可维护性
- 工程实践
最经典的参考书之一。
《软件架构师应该知道的97件事》
（97 Things Every Software Architect Should Know）
一本由众多架构师共同完成的经验合集。
非常适合理解：
经验如何被沉淀和传播。
《设计原本》
（The Design of Everyday Things）
作者：Don Norman
理解：
为什么好的规则能够降低认知成本。
这对于设计 AI Rules 同样适用。
最后的思考
过去的软件开发流程是：
经验
↓
文档
↓
新人学习
↓
团队传承而 AI 编程时代正在变成：
经验
↓
Rules / Skills / AGENTS.md
↓
AI 学习
↓
团队生产力这些经验原本存在于开发者的大脑里，记录在开发规范里，沉淀在最佳实践里，隐藏在无数次 Code Review 和线上故障复盘中。
过去，它们只能依靠人与人的传递慢慢沉淀。
而今天，我们第一次能够将这些经验提取出来，转化为 AI 可以理解和执行的规则。
从知识管理的角度看，Rules、Skills、CLAUDE.md 和 AGENTS.md 并不是简单的配置文件。
它们记录的不是参数，而是经验；约束的不是工具，而是工程实践。
它们将原本存在于开发者大脑中的隐性知识，转化成团队可以共享、可以传承、可以被 AI 执行的显性知识。
过去，经验需要通过文档、培训和 Code Review 才能完成传递。
而今天，经验第一次能够直接参与代码生成过程。
这意味着团队积累的不再只是代码本身，还有指导 AI 编写这些代码的知识体系。
因此，未来团队之间真正的竞争力，或许不只是模型能力，而是谁拥有更完善的经验沉淀体系。
因为模型终将趋同，而经验永远稀缺。