去年年初我主动揽下了在公司推广AI编程的活儿。当时所有人包括我自己都觉得，这事最大的变量是模型——选GPT还是Claude，开源还是闭源，上下文窗口够不够大，推理能力强不强。我甚至花了整整两个星期做模型选型对比，列评测集、跑生成测试、比API价格，搞得像在实验室做基准测试。一年过去，真实情况和我最初的判断几乎完全相反：在企业里推AI编程，模型强不强根本不是重点，甚至可以说，在大部分团队的日常场景里，模型之间的能力差距被一大堆更基础的问题淹没了。这篇文章我把这一年的复盘、踩坑和方法论完整写出来，给准备在企业里推AI编程，或者正在推但总觉得哪里不对劲的朋友做个参考。
1. 复盘：为了"最强模型"折腾了三个月，效率纹丝不动
1.1 当时的选型逻辑，现在看全是坑
我刚开始做推广时，第一步就是搞模型选型。当时建立了一个内部评测集，大概几十道题：生成工具函数、给遗留代码补单元测试、修复一个有明确报错的bug、跨文件重构一个模块。评测维度包括正确率、代码风格、一次通过率、耗时和成本。
评测结果有意思。在"生成一个独立的工具函数"这类简单任务上，各家模型差距很小，都能写对，主要差别在风格和命名偏好。在"给一段遗留代码补单测"这种中等任务上，模型之间的差距被提示词质量完全盖过——同一模型，换一种Prompt写法，通过率能从四成跳到七成。到了"跨文件重构"这种复杂任务，结果几乎只取决于一件事：模型能不能拿到完整且准确的上下文。拿不到，再强的模型也是瞎猜；拿到了，中等偏上的模型也能完成得像模像样。
我后来反思，选型不是没意义，但它的意义被我严重高估了。模型能力是AI编程这条链路上的最后一个环节，前面还有代码库质量、上下文组织、工具链稳定性、安全合规流程、团队使用习惯，每一环都可能成为瓶颈。当瓶颈在前面时，你换再强的模型都没用，就像通畅的下水道出口被堵住之前，换再大的水泵也只是让水管压力更大而已。
1.2 三组真实对照，模型差距被上下文淹没了
为了把这个问题讲透，我举三组实际发生过的对照实验，都是我带着两位同事一起做的，用的都是公司真实代码，不是网上的测试题。
第一组：让AI把一段老化的日期处理函数改成基于新时间库的实现。闭源旗舰模型和开源中档模型都做对了，运行结果一致，差异只体现在注释风格和边界条件的写法上。这种任务随便哪个模型都能干，不值得纠结。
第二组：让AI在订单模块里新增一个"取消订单后异步发送通知"的功能，只给需求描述，不给关联代码。结果所有模型都在编——有的用了不存在的服务类，有的把事务边界放错，有的甚至发明了一个公司里根本没有的消息队列组件。这个实验里，模型强不强完全体现不出来，因为它们的失败原因都一样：上下文里没有提供订单状态机的定义、事务管理的约定、消息组件的封装方式。
第三组：同一个任务，但我们提前做了上下文工程，把订单模块的状态机代码、事务注解约定、消息组件的封装接口全部检索出来，连同任务描述一起发给模型。结果包括开源中档模型在内的所有模型都给出了可用的实现，返工次数从三次降为零。
这三组对照直接让我明白了一个道理：在企业里，模型之间的排名远不如"你有没有把正确的上下文喂给模型"重要。很多团队连自己的代码库里有哪些模块都说不清楚，就开始纠结要不要上最强模型，这完全是次序颠倒。
1.3 什么时候模型强弱才真正拉开差距
当然，我也不能说模型强弱完全没用。这一年的观察下来，模型能力真正拉开差距的场景大概有三类：
一是全新的领域或全新的代码库，没有任何上下文可以依托，模型只能凭预训练知识硬扛，这时候更强的模型确实能给出更合理的骨架。但这类场景在成熟企业里占比很小。
二是处理极其复杂、涉及十几个文件联动的架构级修改，强模型对意图的解析和代码结构的一致性把握更好，不过它对上下文的要求也更高，你先得把这么多文件的内容正确组织出来。
三是代码审查这类"阅读理解"场景，强模型更容易发现隐蔽的业务逻辑漏洞。但这里有个前提：你得给模型一份足够清晰、足够完整的代码说明，否则它也只是在瞎猜。
换句话说，模型强弱是在单点智力题上体现出来的，而企业里的AI编程日常，更多是体力活和工程活。真正决定AI产出质量的，是你能不能把问题定义清楚、把上下文准备好、把验证闭环搭起来。后面这几件事，才是真正值得投入资源的地方。
2. 被忽略的主战场：代码库的"体质"决定了AI的上限
2.1 老单体项目的混沌依赖，AI第一步就迷路
我在复盘时发现，阻碍AI发挥的最大单一因素，不是模型，而是代码库本身的混乱程度。我们公司有一个维护了快十年的单体项目，模块之间互相引用，一个订单类不知不觉依赖了十几个DAO和Service，而且很多依赖是隐性的——你在IDE里静态追踪根本看不出来，得靠运行时才能发现。
这种代码库对AI是极不友好的。AI生成代码时，最核心的能力是"在正确的位置产生正确的修改"，但它首先得理解这个模块的依赖边界和调用约定。在混沌的代码库里，AI就像进了一个没有路标的迷宫，它只能靠猜，猜错是常态。
我记得最典型的一次，我们让AI在支付模块里加一个"风控标记"。AI生成了代码，逻辑本身没什么问题，但它引用了一个已经被废弃的配置类，导致运行时抛异常。这种错误并不高深，就是代码库里的旧债太多，AI从历史代码里学到了过时的模式。
2.2 上下文工程：把"找代码"变成AI的导航
后来我们花了大力气做上下文工程，这是这一年里投入产出比最高的一件事。所谓上下文工程，就是主动把AI生成代码需要的相关信息，从浩瀚的代码库里打捞出来，组织好喂给模型，而不是指望模型自己会"翻代码"。
具体我们做了三件事：
第一，建立代码索引。把仓库里的类、接口、核心函数、枚举定义、数据库表结构抽出来，做成结构化的索引文档。我们用向量化的方式做检索，用户问一个问题，系统先把相关文件和片段捞出来。这里我有个经验：网上有一堆embedding模型排行，但排行前几名的在我们自己的代码库上不一定排前面，一定要拿自己的仓库做召回测试，用真实的检索任务来选。
第二，在提问前强制AI先输出"参考文件清单"。我们要求AI在回答前先列出它打算参考哪些文件，人确认后再生成代码。这一步看起来多此一举，实际非常管用——它能阻止AI在错误的前提上自信地生成大段代码。如果AI列出的文件不对，让用户补充文件，而不是让AI硬写。
第三，把git历史利用起来。很多需求其实是对历史代码的修改，我们通常的做法是让用户把相关的commit贴进对话里。AI看到历史commit后，对来龙去脉的理解速度提升非常明显，比用自然语言描述需求有用得多。有一次我甚至没写需求描述，直接把一个两周前的commit标题和内容丢给AI，让它在此基础上加新功能，一次就对了。
2.3 一个真实对比：同一个功能，两次截然不同的结果
为了说明上下文工程有多重要，我分享一个对比案例。需求是"在某个老订单模块里，取消订单后异步发通知给用户，通知内容要带上取消原因"。
第一次尝试，我们用最强的商业闭源模型，只给需求描述。结果生成的三版代码都被退回了：第一版调用了一个不存在的事件监听器；第二版把取消原因字段名写错；第三版在事务提交前发了消息，会导致下游系统读到回滚数据。
第二次尝试，我们换了个开源中档模型，但提前做了上下文准备：把订单状态机定义、事务注解的团队规范、消息组件的封装接口和最近三个月相关的commit记录，全部检索出来拼进上下文。结果第一版代码就通过了评审，只改了变量命名。
这个案例我每次分享都会讲，因为它非常直观地说明了：在真实企业环境里，做好上下文工程带来的收益，远大于从"中档模型"换成"最强模型"带来的收益。模型像是一个阅读理解能力很强的实习生，你给他的资料越全，他写出来的东西就越靠谱；资料不行，换再聪明的实习生也没用。
2.4 基建的隐性贡献：CI、自动化测试和代码托管
上下文工程之外，代码库的"体质"还体现在基建上。我越来越觉得，AI编程落地程度，和团队现有的工程化水平是强相关的。
举个例子。AI生成代码后，我们怎么验证？如果CI流水线要跑四十分钟，开发者的耐心早就耗尽了，他会跳过验证直接提交，然后线上出错。我们的做法是把CI拆成两层：一层快速检查，几分钟内跑完编译、静态检查和核心单测，用来给AI生成代码做"闪电验证"；另一层全量测试，在合并前跑。有了这层快速验证，AI生成代码的迭代速度就起来了——错了立刻知道，而不是等半天后才发现。
还有一个被大多数人忽略的点：自动化测试覆盖率。AI在学习上下文时，如果仓库里本来就有大量高质量的单测，它能从中学到函数预期行为，生成的代码会规范很多。反过来，一个完全没有测试的仓库，AI生成的代码也容易"野"，因为它没有参考约束。
代码托管平台的开放性也很重要。如果你们的代码托管系统支持API调用，就可以把代码检索、上下文拼接、AI审查全部串起来，做成一条自动化链路。我们后来做了一个内部工具，开发者在IDE里选中文件，工具自动收集相关代码和文档，生成上下文摘要，再调用模型模型。整个流程走下来，人工操作量大幅减少。
3. 比模型更值钱的是沉淀下来的提示词资产
3.1 从个人小技巧到团队提示词库
推广AI编程的前三个月，团队里每个人都有自己的Prompt写法。有人喜欢把需求写成一段长描述，有人喜欢用"你是资深架构师"这种角色设定，有人根本不用Prompt，直接把代码贴给AI让它改。结果就是产出质量参差不齐，无法横向比较。
后来我牵头建立了一个团队提示词库，把高频场景的Prompt模板沉淀下来，放进了Git仓库。这个动作带来的收益，远超我们换三次模型。
为什么要这样做？因为提示词的本质是"把团队的知识和经验编码成可复用的指令"。一个刚入职的同事，不知道我们公司代码里事务边界怎么约定，但他用团队沉淀的代码审查提示词，就能让AI按公司的规范去检查代码。这是把个人经验组织资产化的过程，和当年把代码规范写进README是一个道理。
3.2 提示词模板的核心结构，拆开讲讲
很多人写Prompt就是一段话从头写到尾，效果不稳定。我们的模板统一采用了六个部分的结构：
角色设定：告诉AI它扮演什么角色。比如"你是精通Spring事务管理和数据库性能优化的资深工程师"。这个部分的作用是限定AI的出题范围，避免它泛泛而谈。
目标描述：用一两句话说清楚任务目标。目标描述必须是"可验收的"，而不是"想做的"。比如"检查订单模块的事务边界，找出可能造成数据不一致的代码"比"帮我看看这段代码有什么隐患"清晰得多。
约束条件：这是最容易被忽略的部分。必须明确告诉AI不能做什么。我们经常写"不能使用已废弃的项、不能修改公共接口签名、生成代码必须兼容Java 11"。约束条件越具体，AI输出越可控。
输入规格：告诉AI你要给它什么，以及它应该如何对待输入。比如"以下是我公司订单模块的接口定义和调用链清单，请基于这些信息作答"。这其实是在帮AI管理注意力。
输出格式：规定AI输出的形式。我们经常要求"先列出你参考的文件清单，再给出代码diff，最后给出风险说明"。格式化输出不光方便人看，也是在逼AI先思考再回答。
参考示例：给一个小的输入输出对，告诉AI"你要做到的效果大概是这样"。这一步非常有效，相当于给AI一个靶子。
这套结构看着简单，实际用起来能解决很多问题。我们内部流传一句话：Prompt写得不够清楚，通常不是因为表达能力差，而是因为需求本身没想清楚。所以，如果连Prompt都写不明白，先别怪模型，先把需求理清楚。
3.3 提示词库也会腐烂，三个月不维护就变废
提示词库建立之后，第一个坑是过了几个月发现很多模板已经不好用了。原因很现实：业务规则变了、接口变了、团队的技术栈选型变了，但提示词里的假设还没变。
举个例子，我们有一套"遗留代码解释"的提示词，原本效果很好，但后来接口文档更新了，这套提示词还在要求AI参考旧的接口文档，结果生成的解释牛头不对马嘴。后来我们加了一条强制规则：任何提示词提及"文档"时，必须附上"当前最新代码片段优先于文档"的指令，并让AI标注它的信息来源。
现在我们把提示词当成代码一样管理和维护：每次修改都走评审流程，必须有人验证新版本的输出质量，并且配套一个简单的回归用例集——挑几个有代表性的任务，每次修改提示词后跑一遍，确认没把之前的效果搞退化。
3.4 几个可以拿去直接改的模板骨架
挑几张我们团队现在还在高频使用的模板骨架，分享出来，你们可以按需改。
需求拆解提示词：适用场景是把一句模糊的产品需求变成开发任务清单。核心指令有：列出业务边界条件，标记出所有不确定项并要求需求方确认，拆解任务并标注依赖关系，给出建议的实现顺序和风险点。实际用下来，它能把"搞一个用户等级功能"这种需求，拆出十几个可执行的子任务和三个需要确认的边界条件。
代码审查提示词：适用场景是在人工评审前做一轮AI预审。我们的模板强制AI按照安全（注入、越权）、性能（N+1查询、内存占用）、可读性（命名、复杂度）、测试（缺失断言）四个维度逐项检查，并要求每个问题都给出文件行号和前置证据，不许空说"你的代码有待优化"。
单测生成提示词：适用场景是为函数或方法生成单元测试。模板里最关键的是要求AI"覆盖正常路径、空值、边界值、异常输入、并发冲突，并标出哪些用例需要Mock依赖"。如果没有这句，AI写出来的单测基本都是Happy Path，没实际意义。
迁移脚本提示词：适用场景是数据库迁移或框架升级。模板要求AI先厘清源结构和目标结构的映射关系，列出所有可能丢数据的操作，然后生成迁移脚本，最后给出一份验证步骤。这套模板在我们一次MySQL版本升级里救了命——AI提前发现了三个会丢数据的问题点。
这些模板不是魔法，核心逻辑都是把"资深工程师脑子里会想的那些问题"显式写出来，让AI替你看一遍。而这个过程本身，就是在逼迫团队把隐性的经验变成显性的文字。我发现，团队里原本最排斥写文档的同事，反而成了提示词库用得最勤的人，因为提示词写得越好，AI产出的代码质量越高，这在短期内就能看到收益。
4. 企业级推广的真正门槛：安全、权限与部署现实
4.1 代码能不能出内网，三个问题一次问清
模型能力再强，如果你的企业不允许代码出内网，一切都白搭。这是我在推广过程中遇到的最大阻力，也是很多AI编程项目死在半路的真正原因。
当时安全团队一开始的态度是"不建议任何代码出网"。这可以理解，谁也不愿意为风险背书。我的做法是主动去找安全团队，把问题拆成三个层面沟通：哪些代码允许被发送到外部模型？发送前是否需要脱敏处理？涉及支付、用户隐私的核心模块是否完全豁免？三方协商后，我们定了一条规则：普通业务代码可以走外部模型，但必须先经过一个自动化脱敏脚本，把数据库连接串、密钥环境变量、真实用户ID替换掉；密级模块和支付风控模块一律走内部部署的本地模型；所有AI生成代码在合并前必须跑静态安全扫描。
这个过程给了我一个很深的体会：安全合规不是敌人，是需求的一部分。与其抱怨阻碍，不如把安全团队变成项目的一部分，让他们参与方案设计。
4.2 私有化部署路线的现实选择：从"低显存"和"本地模型"说起
因为安全要求，我们不得不私有化部署一部分模型能力。这里就遇到了一个很现实的矛盾：我们不可能在内部机房塞一堆顶级GPU，成本扛不住；也不可能让所有核心场景都走外部模型，安全不允许。
最终方案是分层：通用辅助场景（代码解释、文档生成、变量命名建议）走本地部署的开源模型，用低显存优化方案——量化、上下文裁剪、限制最大生成长度。实际体验下来，这类任务完全够用，毕竟它们不要求模型有极强的推理能力。需要高推理能力且不涉密的任务，走经过审批的外部API；涉密任务全部禁止使用AI生成的代码，必须纯人工编写加双人评审。
这里我想多说一句关于工具链的感受。很多团队纠结"API好不好用""某个开源工具能不能配置自定义模型服务地址"，但往往忽略了：工具链的统一配置和管理，比工具本身的能力更影响推广效果。我们最初让各小组自己找工具，结果出现了五六种不同的接入方式，有人直接用网页版，有人用了命令行工具，有人自己写脚本调API，安全和体验完全不可控。后来我们把所有工具的模型地址统一收敛到内部网关，无论是外部API还是本地模型，都通过同一个网关出去。Langflow这类可视化工具，内部模型地址也是统一配置好的，才把混乱局面控制住。
4.3 "模型繁忙"才是真正的体验杀手
聊一个特别现实的问题：当你的团队到了一定规模，同时在线使用AI的人多了以后，体验会急剧下降。模型服务商返回"模型繁忙"是家常便饭，高峰期等十秒二十秒是常态。
你可能会觉得这不是什么大问题，等一等而已。但在开发者的工作流里，这个等待是致命的——他在等AI补全一个函数，等了几秒没反应，本能地切回手写模式，然后AI就再也回不到他的注意力里了。很多开发者就这样慢慢放弃使用工具，但他们嘴上不会说"因为卡顿所以不用"，只会说"觉得这个功能对我没用"。
这个现象让我明白：在企业环境里，工具链的可用性和稳定性，比模型的聪明程度更能决定工具能不能被大家持续使用。我们的解法有两手：一是把高优先级任务调度到本地模型池，宁可牺牲一点答案质量，也要保证响应速度稳定；二是错峰提醒——在高峰期提示开发者可以先把任务排队，或者转为异步生成，先把思路整理好，等结果返回再合并。
4.4 把AI生成代码纳入安全审查闭环
最后一张安全牌是审查闭环。AI生成代码有一个特点：它看起来太正常了，所以很容易被跳过审查。很多开发者在拿到AI代码时会下意识觉得"AI生成的应该没错吧"，然后直接提交。这是危险信号。
我们在流程上加了几个硬性要求：任何由AI生成的代码，在PR描述里必须标注"AI生成"标签；AI生成代码合并前必须跑一遍自动化安全扫描，且扫描工具独立，不依赖AI；涉及权限管理、认证、加密的代码，不管是不是AI生成的，都要求有至少一名资深工程师专门审查逻辑和边界场景。
刚开始大家觉得这套流程烦，但半年后，我们统计到至少有六次事故被这层审查拦住了。有个典型的例子：AI生成了一段文件上传功能，逻辑完全正常，但它把上传文件的后缀名校验写在了客户端表单层面，服务端没有二次校验，这会导致任意文件上传漏洞。人很容易漏掉这种问题，但独立扫描工具加AI预审加人工复核，把概率降到了最低。
5. 一年试出来的方法论：AI编程正确落地的四步走
5.1 选好试点项目："中等复杂度+高重复度"是最佳窗口
如果你准备在企业里推AI编程，第一步不是铺开，而是精心选试点。我强烈建议选择"中等复杂度+高重复度"的模块。
为什么？太简单的任务（比如生成一个工具函数），AI能干，但说服力不够，大家会觉得"我用不上"；太复杂的任务（比如重构支付核心），AI大概率会翻车，反而让围观者留下"AI编程不行"的第一印象。中等复杂度的任务，AI成功率明显更高，且能让人直观感受到提效。而"高重复度"意味着团队成员能自己立刻把手里的活套进去，体会到效率提升。
我们当时选的是内部管理系统的一批CRUD接口和报表查询模块。这些模块业务逻辑不复杂，但代码量不小，模板化程度高，AI生成起来很容易命中。试点期间，团队的开发速度明显变快，加上分享会里的现场演示，比任何书面规定都管用。
5.2 建立双轨评审：AI先审，人再审
AI编程推广的核心阻力，除了技术层面，还有信任层面。资深工程师往往对AI生成代码有一种本能的怀疑，认为它不可控。这种怀疑不能靠嘴说服，得靠流程证明。
我们设计了一个双轨评审机制：AI先跑一轮代码审查，把问题列出来，然后人再带着AI的清单去review。这套机制有两个好处。第一，AI审查会给出一个相对客观的基线，资深工程师可以把精力集中在"AI看不到"的抽象问题上，比如架构合理性、业务语义、长期可维护性。第二，AI审查能让新人从输出中学到"资深视角"——AI列出的问题往往和资深工程师关注的点高度重合，新人等于多了一个随时可以请教的对象。
这里我想强调，AI的代码审查不是用来替代人工的，而是用来逼着人问"为什么"的。AI告诉你某段代码有越权风险，你就得想想为什么有风险、怎么杜绝这类风险。这种"AI发现问题+人理解问题"的循环，反而是提升团队平均水平的好手段。
5.3 度量指标：别用代码行数和接受率骗自己
推广AI编程必须做度量，但度量的指标必须选对。我见过不少团队，把"AI生成的代码行数占比""AI建议接受率"当成KPI，这是我在这一年里踩过的最深的坑，比选错模型还伤。
这两个指标天然会被刷高——开发者只要让AI随便写一点代码，行数就上去了；只要把AI的输出原样合并进代码库，接受率就是100%。但这些指标严重偏离"业务提效"这个终极目标：AI可能给你生成了两千行代码，但这两千行里一半是重复的样板，另一半需要大量返工，最后你还要花三小时去改，这算提效还是添乱？
我们后来重新建立了一套更接近业务价值的指标：需求交付周期（从需求到可发布代码的平均时长）、缺陷逃逸率（合并后线上被发现的bug数量）、重构回归bug数（重构类任务上线后引发原有功能异常的次数）。这套指标不直接衡量AI本身，但AI有没有帮上忙，会间接体现在这些数字上。季度复盘的时候，我们拿这些数据给管理层看，说服力远大于一张"AI生成行数"的截图。
5.4 推广节奏：从自愿尝鲜到全组流程化的临界点
推广节奏也很关键。我把它分成三个阶段。
第一阶段是自愿尝鲜。只找团队里对AI工具感兴趣的极客，让他们在低风险任务上用AI，产出经验和分享。这个阶段不需要强推，目标是收集一手案例和踩坑清单，为后面铺路。
第二阶段是小团队压测。选两三个愿意配合的完整业务组，把AI工具纳入他们的日常开发流程，从需求拆解到代码生成再到审查全覆盖，用一到两个迭代周期跑出真实的数据对比。这个阶段会暴露大量问题——工具不稳定、提示词不好用、安全审查卡壳——这些问题必须在扩大范围前解决。
第三阶段是全组流程化。当数据验证确实有效，工具和提示词也已经迭代稳定之后，就要把AI编程写进流程，变成"不做反而麻烦"的事情。比如代码审查模板里强制要求AI预审报告；需求任务模板里附带AI拆解结果。从我观察到的现象来看，只要把AI嵌进既有的工具链里，用起来比原来顺手，大多数人不会抵触，真正抵触的是那些流程之外还要被要求额外使用AI的人。
6. 说点心里话：能用好AI编程的人，和模型关系不大
6.1 什么人上手最快，什么人最容易翻车
这一年里我观察了几十位开发者的使用习惯，发现了一个反直觉的事实：上手最快的往往不是技术最新潮的年轻同事，而是那些有五年以上业务经验的"老手"。
原因很简单。AI编程使用过程，本质是"把脑子里的方案清晰地描述出来"。老手对自己负责模块的代码了如指掌，知道哪里是雷区，哪里是扩展点，哪里可以放心让AI改。他们给AI下的指令通常是精准的："在OrderService的cancel方法里，把状态更新放在事务边界内，然后在事务提交后调用NotifyProducer推送消息，注意取消原因字段用reason。"这种话AI一听就懂，生成的代码质量自然高。
而经验不足的开发者，最大的问题是不知道自己要什么。他们让AI生成代码，AI生成了，他看着觉得好像也对，就直接提交了。等出了bug，他连AI生成的代码为什么会出bug都看不懂——因为他不了解背后的业务假设和技术约束。所以我的结论是：AI编程不会让新人秒变资深工程师，反而放大了资深工程师的杠杆，同时也放大了新人对代码的不可控感。
6.2 这一年反复踩到的高频坑，列成清单给你
最后把我这一年见过最多的坑列一份清单，每条都是真实的：
第一，无脑接受AI输出，不审。这是最常见也是后果最严重的一个坑。AI生成的代码天然有一种"正确感"，很多人都懒得细看就合入。我的经验是：任何AI生成代码，至少要回答三个问题——它的边界条件是什么？它依赖的组件/接口存在吗？它的性能在合理范围内吗？
第二，上下文塞太多。我见过有人为了追求"模型看得全"，把一个几十万行的大型代码库整个交给AI，或者在对话里硬塞十几个文件。上下文过长会让AI开始"编"，尤其是生成一些它自己都拿不准的细节时。正确做法是精准检索，只给跟当前任务强相关的代码片段，而不是越多越好。
第三，试图"一句话生成整个功能"。AI生成大型功能的最好方式是拆解成十几个小任务逐步完成，而不是期待一句话变成十个文件的完整实现。小任务意味着每个步骤的上下文都清晰，验证点都明确，出了问题也好定位。
第四，组织层面的坑：只给工具，不给时间和信任。如果你只是把AI工具发给团队，然后催大家"要多用"，但不对流程做任何调整，不给试用和犯错的空间，那团队只会偷偷用，而且用出了问题也会藏着掖着。推广AI编程，本质是在推广一种新的工作方式，需要给团队时间去适应。
第五，把AI生成代码直接焊进核心模块却不加测试。AI生成的代码如果被用在核心链路，必须有完整的测试兜底。哪怕代码看着再正常，没有测试约束，它在真实流量下翻车的概率都不低。
这一年走下来，我的核心体会是：AI编程在企业里落地，比的是谁能把工程问题、组织问题、流程问题先解决掉。模型是这个链条上最容易被讨论，也最不应该被优先讨论的环节。你需要的不是一个更聪明的模型，而是一整套能让现有模型发挥出真正工程价值的体系——清晰的代码库、可靠的上下文、稳定的工具链、规范的安全审查，还有一群愿意把需求讲清楚的人。把这些做好了，你手里的模型不管是什么级别，都能干活；做不好，换再强的模型也只会是昙花一现的兴奋。
