从“会聊天的 AI”到“理解你代码的 AI”很多程序员第一次使用 AI 编程工具时会有一种错觉AI 这么聪明只要告诉它需求它应该能直接帮我完成开发。于是输入“帮我开发一个用户管理模块。”几秒钟后AI 输出ControllerServiceMapper数据库表前端页面。代码看起来非常完整。但是复制到真实项目后很快发现问题为什么生成的代码和现有架构不一致为什么 AI 又创建了一套用户体系为什么用了项目不存在的技术为什么业务逻辑和实际流程不一样为什么修改一个地方影响了一堆功能很多人开始怀疑AI 编程是不是没有想象中那么好用其实问题不在 AI。而在于你没有让 AI 真正理解你的项目。一、AI 为什么“不懂”你的项目1. AI 看到的是代码不是系统很多开发者认为我把代码给 AI它就能理解项目。实际上并不是。一个企业项目包含的信息远远超过代码。例如一个医院系统。代码里面可能只有SampleService.java SampleController.java SampleMapper.java但是隐藏的业务规则标本必须签到 ↓ 生成条码 ↓ 采集确认 ↓ 传输LIS ↓ 结果回传这些流程可能存在于产品文档会议记录老员工经验历史需求数据库设计。代码只是结果。不是全部知识。2. AI 不知道你的“为什么”软件项目里面最重要的问题不是“怎么写代码”。而是“为什么这么设计。”例如数据库有一个字段sample_stateAI看到0 1 2 3它不知道为什么不能0 → 3因为真实业务必须经过未采集 ↓ 已采集 ↓ 已送检 ↓ 已接收这种规则不写在代码里的时候AI无法知道。二、什么是上下文工程很多人关注Prompt Engineering提示词工程。例如优化你的提问方式。但是在复杂项目中Prompt 只是很小的一部分。真正重要的是Context Engineering上下文工程简单理解给 AI 提供完成任务所需要的全部背景信息。包括项目架构技术规范数据模型业务规则历史决策当前代码。普通 AI 使用需求 ↓ AI ↓ 代码上下文工程项目知识 代码 规范 业务规则 需求 ↓ AI ↓ 符合项目要求的代码三、如何给 AI 构建项目上下文一个成熟项目可以建立专门目录.ai/ ├── project-context.md ├── architecture.md ├── coding-rule.md ├── database-rule.md ├── business-rule.md └── api-standard.md这些文件就是AI 的项目知识库。四、architecture.md告诉 AI 系统怎么设计例如# 系统架构 技术栈 Spring Boot 3 MyBatis Plus MySQL 8 Redis 项目结构 Controller ↓ Service ↓ Mapper 架构规则 1. Controller禁止处理业务逻辑 2. Service负责业务编排 3. 数据访问必须经过Mapper 4. 公共代码统一放common模块这样 AI 在生成代码时不会随意创建结构。五、coding-rule.md告诉 AI 如何写代码很多项目最大的问题不是功能错误。而是代码风格混乱。例如团队要求接口统一返回ResultT异常BusinessException日志Slf4j那么告诉 AI编码规范 1. 所有接口返回ResultT 2. 禁止直接抛RuntimeException 3. 禁止System.out.println 4. Service方法必须考虑事务AI生成代码质量会明显提升。六、database-rule.md让 AI 理解数据库设计数据库是 AI 最容易犯错的地方。例如AI喜欢select * from user但是企业项目可能要求禁止select *大表必须分页查询必须走索引。可以定义数据库规范 1. 禁止select * 2. 新增字段必须兼容历史数据 3. 超过百万数据表必须考虑索引 4. SQL必须说明索引设计原因七、business-rule.md最容易被忽略的部分技术人员容易关注代码。但是 AI 最缺的是业务。例如订单系统订单规则 订单状态 CREATE PAYED SHIPPED FINISHED CANCEL 规则 支付完成后不能直接取消。 必须经过退款流程。否则 AI 很可能生成order.setStatus(CANCEL);但是实际业务这是错误操作。八、上下文工程的核心不要一次喂全部代码很多人还有一个误区把整个项目压缩上传给 AI。这也不是最佳方案。原因项目太大。信息噪声太多。更好的方式分层提供上下文。第一层项目级上下文告诉 AI整个系统是什么。例如技术栈架构业务范围。第二层模块级上下文例如订单模块提供表结构接口服务关系。第三层任务级上下文例如当前需求增加订单取消功能。只提供相关代码。这种方式类似新人入职。不是第一天给他整个公司的所有资料。而是先了解公司再了解部门最后处理任务。九、如何让 AI 参与真实开发推荐流程第一步让 AI 阅读不要修改。提示分析当前模块。 说明 1. 模块职责 2. 类之间关系 3. 数据流转 4. 业务规则 不要生成代码。第二步让 AI 设计根据当前项目。 设计实现方案。 不要编码。第三步人工确认检查是否符合架构是否影响旧功能是否存在风险。第四步让 AI 实现限制只修改order模块。 禁止新增框架。 禁止修改公共代码。 遵循项目规范。十、上下文工程带来的变化过去程序员问 AI帮我写代码。现在高级开发者我建立项目知识体系让 AI 按照我的工程规则开发。普通使用AI 只是聊天工具工程化使用AI 是项目成员十一、未来开发竞争力在哪里未来程序员之间的差距不会只是谁写代码快。而是谁能让 AI 更好理解自己的系统。核心能力1. 架构能力知道系统应该怎么设计。2. 业务抽象能力知道业务规则如何表达。3. 上下文管理能力知道什么信息应该提供给 AI。总结AI 写不好代码很多时候不是 AI 能力不足。而是我们没有告诉它这个项目是什么它为什么这样设计哪些事情不能做。真正高效的 AI 开发方式不是提高 Prompt 技巧让 AI 多写代码。而是建立上下文工程让 AI 在你的项目规则内工作。最懂如何让 AI 理解项目、遵守规则、稳定交付的人。