AI 写代码这件事，现在已经不新鲜了。真正让我持续关注的，也早就不是“AI 能不能写代码”，而是另一个更实际的问题：它写出来的东西，能不能真正进入真实项目。
这两个问题表面上接近，实际上差别很大。
因为“能写”更多是模型能力问题，而“能进项目”是工程协作问题。真实项目里，代码不是只要看起来对就可以，它还要符合现有技术栈、目录结构、团队习惯、交付规范、项目边界，甚至还要符合一些没有被明确写出来但实际存在的上下文约束。
这也是为什么我越来越在意：怎么让 AI 真正服务于真实项目开发。
AI 最大的问题，不是不会写，而是不知道项目现在是什么样
很多时候，AI 生成的代码本身不算差。问题出在它默认站在一个“通用项目”的视角回答，而不是站在“这个具体项目”的视角回答。
比如：
- 当前项目明明是 Vue2，它却给了 Vue3 写法
- 当前项目已经有统一请求封装，它却直接另起一套
- 当前项目目录结构很明确，它却把代码放到完全不合适的位置
- 当前业务流程已经有边界，它却按通用思路重构了一遍
这些问题不是能力不够，而是上下文没有被正确识别。
所以我后面越来越明确一个判断：让 AI 服务真实项目，第一步不是继续追求更长输出，而是先让它知道当前项目到底是什么。
真实项目需要的，不是“万能回答”，而是“受约束的正确回答”
我现在越来越不喜欢那种看起来很全、很能说、但落不到项目里的 AI 输出。
真实开发里，真正有价值的输出通常有几个特征：
- 贴着当前项目已有写法
- 遵守现有目录和模块边界
- 不随意升级框架或替换方案
- 能区分“必须改”和“最好别动”
- 在不确定时明确说明假设，而不是直接乱补
也就是说，真实项目不需要一个“无限发挥”的 AI，而更需要一个“知道边界在哪”的 AI。
这件事和很多人直觉不一样。大家会觉得 AI 越自由越强，但工程里自由过度往往意味着不稳定。项目真正需要的是可协作、可接入、可维护，而不是每次都给出一份看起来很厉害但接不上当前工程的回答。
为什么规则约束很重要
我后来会花很多时间去整理规则，不是因为我喜欢写规则本身，而是因为规则能把很多原本模糊的工程语境变得可传递。
比如我会比较在意这些规则：
- 优先基于现有技术栈输出，不擅自升级
- 优先参考当前项目已有目录和模块结构
- 不混用不同项目栈的写法
- 输出尽量可直接落地，而不是停留在概念解释
- 遇到不确定栈时先识别上下文，再输出方案
- 有 plan 文档时，完成任务后同步更新状态和时间
- 输出时补充测试或验收思路，而不是只给代码
这些规则看起来不炫，但它们能明显提高 AI 输出的可用性。因为 AI 开始不只是“生成内容”，而是在“遵守工程协作方式”。
我越来越在意“上下文识别”这件事
我觉得 AI 参与真实项目，核心竞争力不只是生成能力，而是上下文识别能力。
一个真正有用的 AI，不是见到需求就立刻输出，而是能先判断：
- 当前项目是什么技术栈
- 当前模块有没有既有实现
- 现有目录怎么组织
- 当前问题属于修复、扩展还是重构
- 用户是要方案、代码、排查还是文档
- 哪些信息已知，哪些信息只能做假设
如果这层识别做不好，后面的输出越多，偏差可能越大。
真实项目里的 AI，更像协作者，而不是展示工具
我对 AI 的期待，也慢慢从“帮我更快生成”变成了“帮我更稳协作”。
它可以帮忙拆需求、补结构、出方案、整理规则、生成代码、补测试点、写文档，但前提是它要进入一个明确的协作框架里。否则它更像一个随机灵感工具，而不是工程角色。
这也是我为什么越来越重视提示词模板、开发规则文档、项目总结、固定输出结构。因为这些东西本质上都在做一件事：把 AI 从一个泛化问答对象，慢慢拉进一个具体项目的工作环境。
结语
让 AI 真正服务于真实项目开发，对我来说，关键不在于它能写多少，而在于它能不能在正确的边界里写出真正可接入、可维护、可交付的内容。
模型能力当然重要，但在真实工程里，更重要的往往是规则、上下文、边界和协作方式。只有当这些东西被讲清楚之后，AI 才不只是一个“会生成代码的工具”，而更像一个真正能参与项目的协作对象。