这两个AI编程习惯，你中招了吗？
2025年下半年了，不知道咱们中还有没有不用AI编程工具完全靠手敲写代码的大佬，反正我自从用惯了让AI辅助编程以后已经完全不习惯靠自己手敲的方式一行行地写代码了，有的时候我甚至觉得我是辅助AI的。
今天我们聊两个用AI编程的习惯，这两个习惯据我观察每个人的命中率还是挺高的，不是A就是B，就像两个流派一样，总能把你划拉到一派里面去。
习惯一：万年一个Chat框
第一种，我管它叫“老好人”习惯。自用Cursor打开一个项目起，开一个Chat框，然后就跟AI开始聊。从需求分析到架构设计，从具体实现到Bug修复，所有的交流都在这一个框里。
比如说今天上班要写一个用户登录功能，在这一个框里跟AI聊半天，写完了，再让他写个商品列表，还是这个框。甚至改个字段名、接口返回值这种每日细碎的小任务，也在这一个Chat框里。
这个习惯的优缺点如下： 优点：
- 上下文连贯： AI对你的项目和之前的代码了如指掌，有时候你一个眼神，它就知道你要干啥。
- 省事儿： 不用频繁开新框，懒人福音。
缺点：
- 信息过载： 当项目变得复杂，Chat框里的历史记录就像一碗陈年老汤，啥都有，找个东西得翻半天。
- AI容易“跑偏”： 聊着聊着，AI可能就分不清哪个是当前任务，开始给你扯些不相干的东西。
- 复用性差： 有的时候想找某个功能当时AI给的方案，想找当时的AI对话记录？大海捞针啊兄弟。
可能你会问AI为啥聊多了就跑偏了？这是因为大模型都有一个上下文窗口，比如这个窗口中最大可容纳200个Token，一旦超过了就会忘记前面聊过的，而且还有总的上下文的长度，比如以前ChatGPT单个框里聊太久会出现的这个提示
上面说的上下文窗口200Token的长度只是个假设哦，实际比200Token要大很多倍，而且随着模型发展会越来越大。
假设你和AI的对话一旦超过了窗口能容纳的Token阈值，窗口就会往下移，AI在这个时候就会忘掉窗口之前的内容，可能你在周一告诉AI的事情，随着每天的对话，到周五AI就把你告诉它的事情给忘了。
习惯二：一事一框
另外一种使用习惯呢，大家也能猜出来，基本上就是每一个新任务，新开一个Chat框。在每个Chat框中让AI完成一个独立的功能，或者解决一个特定的问题。
优点：
- 焦点集中： 每个Chat框只关注一个任务，AI理解能力更强，给出的建议也更精准。
- 上下文清晰： 遇到问题，直接找到对应的Chat框，上下文明确，排查方便。
- 方便复盘： 以后想找某个功能的实现思路，直接翻对应的Chat框就行，简直是写代码的“日记本”。
非要说缺点嘛，如果每个稀碎的活儿都开一个Chat框好像也不太好，所以针对不能算上独立任务的小范围代码修改，我一般用Cursor里选中代码后的 Cmd + K 功能。
在就有点像跟AI的临时对话，AI完成我们要求的同时并不会把这次对话归到IDE右边的Chat框记录中去
哪种习惯更好？
其实现在AI能力每过一段时间都在增长，上面两种用AI编程的交互习惯对于现在的最新的大模型来说其实输出的结果差异不会很大，而且我们现在的开发任务需要与AI连续沟通好几天来完成的情况也很少见。
我个人觉得习惯二对于查找过往让AI实现过的功能或者设计方案来说更容易一些，毕竟现在AI越来越贵，额度经常不够用，相似度高的功能我一般都是查记录，不让AI搞第二遍白白浪费额度。
对于上面两种用AI编程的习惯你觉得哪种更好呢？评论区说说你的看法吧，也可以留言分享一些你用AI编程的小诀窍。
结尾推荐一下我的专栏课程，如果你想了解怎么用Go做好项目的开发和设计，搭建出一个实用、适合自己的Go项目的基础框架、怎么在写业务代码时做好项目的分层和解耦，给项目打基础让AI也能写出好的代码。欢迎扫下方二维码订阅专栏，
《Go项目搭建和整洁开发实战》专栏分为五大部分，重点章节如下
- 第一部分介绍让框架变得好用的诸多实战技巧，比如通过自定义日志门面让项目日志更简单易用、支持自动记录请求的追踪信息和程序位置信息、通过自定义Error在实现Go error接口的同时支持给给错误添加错误链，方便追溯错误源头。
- 第二部分：讲解项目分层架构的设计和划分业务模块的方法和标准，让你以后无论遇到什么项目都能按这套标准自己划分出模块和逻辑分层。后面几个部分均是该部分所讲内容的实践。
- 第三部分：设计实现一个套支持多平台登录，Token泄露检测、同平台多设备登录互踢功能的用户认证体系，这套用户认证体系既可以在你未来开发产品时直接应用
- 第四部分：商城app C端接口功能的实现，强化分层架构实现的讲解，这里还会讲解用责任链、策略和模版等设计模式去解决订单结算促销、支付方式支付场景等多种多样的实际问题。
- 第五部分：单元测试、项目Docker镜像、K8s部署和服务保障相关的一些基础内容和注意事项。
腾讯云开发者
