昨天，我新建一个项目，准备用 AI 工具快速生成全栈代码。
结果刚起步就卡住了：项目需要依赖一个内部 shared/prisma/ 模块，但我没有访问权限。
申请权限要走流程，等审批可能要一天。
而讽刺的是——我用 AI 本来能在 10 分钟内写出一模一样的数据库访问层。
这件事让我意识到：在 AI 编程普及的今天，有些“封装”正在变成枷锁。
🔧 手工时代 vs AI 时代：封装的价值变了
在纯手工开发时代，封装的核心目标是：
- 少写重复代码
- 统一团队规范
- 避免低级错误
所以我们会建 shared/ 目录，把通用逻辑集中管理。
但 AI 时代，情况不同了：
- AI 不怕写重复代码，它能秒级生成标准化 CRUD。
- AI 怕黑盒：如果封装没有清晰类型或文档，AI 无法理解，只能瞎猜。
- AI 追求敏捷：项目启动越快越好，强依赖外部模块反而拖慢节奏。
🛠️ 我的建议：做“AI 友好的封装”
不是不要封装，而是要换一种方式封装。以下是我现在新项目的实践：
✅ 1. 每个项目自带 Prisma Schema
不再依赖外部 ORM 封装，直接在项目内定义 schema.prisma。
AI 能直接读取模型，生成对应 service 和 controller。
✅ 2. 共享能力用 npm 私有包或脚手架
通用工具函数（如日志、分页、校验）打包成 @company/utils，按需安装，非强制依赖。
✅ 3. 强制类型导出
任何共享模块必须导出完整的 TypeScript 类型，确保 AI 能安全调用。
✅ 4. 项目结构扁平清晰
避免多层嵌套或魔法路径。AI 更擅长处理“所见即所得”的代码结构。
💡 一个原则：让 AI 能“看懂”你的代码
AI 编程的本质，是基于上下文的模式匹配与生成。
如果你的项目充满隐式约定、动态 require、无文档的 shared 模块，AI 就会“失明”。
相反，如果你的代码：
- 目录清晰
- 类型完整
- 逻辑显式
- 无隐藏依赖
那么 AI 不仅能读懂，还能帮你扩展、重构、测试。
📌 结语
那个卡住我的 shared/prisma/，或许初衷是好的。
但在 AI 时代，“统一”不应以牺牲“敏捷”为代价。
未来的工程体系，应该让新成员（无论是人还是 AI）都能在 5 分钟内跑起一个项目——而不是卡在一个权限申请上。
你在用 AI 编程时，是否也被“封装”绊住过？
欢迎留言交流，一起打造更 AI 友好的开发环境！
