正文
从去年开始用AI编程工具，到现在快一年了。踩过不少坑，也积累了一些心得。之前在本地记了些笔记，现在整理出来，分享给有需要的同学。
内容会比较杂，是我这一年的实操记录，不成体系，但都是真实经验。废话不多说，直接上干货。
一、AI编程工具：我用了一圈下来，结论是这样的
主流工具我用过的有：
- Cursor（主力工具，用了大半年）
- GitHub Copilot（用了小半年）
- JetBrains AI Assistant（偶尔用）
- Trae（最近在试）
用下来的感受：
Cursor对我来说是效率提升最明显的。它的Composer功能太强了，新项目直接用它生成基础代码，我再在上面改，比自己从空文件写快多了。尤其是写CRUD代码，Cursor生成得又快又规范，省去很多重复劳动。
Copilot的强项是代码补全。它对Python、JavaScript的支持非常成熟，补全准确率高，适合边写边用。但让它帮我理解陌生代码或者重构，就没Cursor好使了。
JetBrains家的AI Assistant我主要在PyCharm里用。对Java项目支持更好，Python方面稍弱。如果你主要写Java/Kotlin，可以考虑。
Trae是字节出的，优点是对中文支持好，而且完全免费。最近在用它处理一些国内项目，配合Cursor用挺顺手。
我的建议： 如果只能选一个，选Cursor。它功能最全面，Composer和Chat配合使用，基本能覆盖大部分开发场景。
二、RAG项目开发：这几个坑踩得我印象深刻
今年做了一个企业知识库问答系统，用的是RAG架构。开发过程中踩了几个坑，记录一下。
坑一：文档切分策略直接影响检索质量
一开始我用的固定长度切分，每块512字符。结果发现，切到一半的技术文档，检索出来的内容经常是断的，用户体验很差。
后来改成按语义切分，用langchain的RecursiveCharacterTextSplitter，同时把chunk_overlap调大到50左右。这样相邻块有重叠，检索出来的内容上下文更完整。
python
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=300, # 之前用512，改小了
chunk_overlap=50, # 加了重叠，保证上下文连贯
length_function=len,
separators=["\n\n", "\n", "。", "！", "？", ""] # 按语义断句
)
坑二：向量检索和关键词检索要混合使用
单纯用向量检索，有个问题：用户问”密码忘了”，检索到的可能是”忘记密码”，这没问题。但用户问”pwd reset”，向量检索可能匹配不到中文”重置密码”的内容。
后来加了BM25关键词检索，两种检索结果按权重合并。向量检索负责语义理解，关键词检索负责精确匹配，互相补充。
python
from langchain_community.retrievers import EnsembleRetriever
# 混合检索，权重可调
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.3, 0.7] # 关键词30%，向量70%
)
坑三：生产环境别用Chroma
本地开发用Chroma很方便，零配置就能跑。但上线后发现两个问题：
- 内存占用高，几万条数据就卡
- 不支持分布式，多实例部署会数据不一致
后来换了Milvus，用Docker部署，稳定多了。数据量大的话，建议直接上Milvus或者Pinecone。
三、大模型API调用：这些细节不注意，分分钟超预算
调用大模型API是按token计费的，以下是我踩过的预算坑。
教训一：prompt要精简，能不说的废话就不说
我最早写prompt特别啰嗦，喜欢加很多背景描述。输出质量确实好了，但token消耗也上去了。一算账单，发现60%的token都浪费在那些”尊敬的AI助手”之类的客套话上了。
后来学乖了，prompt能简则简，只保留核心信息。输出质量没降多少，token消耗降了40%。
python
# 优化前（浪费token）
"""
请你作为一个专业的Python后端开发工程师，
帮我审查以下代码。
这段代码是一个用户认证模块，
主要功能是验证用户登录信息...
"""
# 优化后（精简版）
"""
审查以下Python代码，找出潜在问题：
[代码内容]
"""
# 注意，我只说"找出潜在问题"，没说什么类型的。
# 模型会自动识别常见问题类型，反而更准。
教训二：temperature不是越高越好
temperature控制输出的随机性。很多人以为temperature=0.8输出更有创意，其实不是。
我的经验：
- 问答题、代码审查等需要准确答案的：temperature=0.1~0.3
- 头脑风暴、创意文案：temperature=0.5~0.7
- 精确匹配（比如JSON输出）：temperature=0
教训三：结果缓存要善用
如果你的业务里，有大量重复或相似的query（比如FAQ），一定要加缓存。
我的做法：
python
from functools import lru_cache
@lru_cache(maxsize=1000)
def get_cached_response(question: str, user_id: str = None):
"""带缓存的问答函数"""
# 先查缓存
cache_key = f"{user_id}:{question}"
# 命中缓存直接返回
if cache := redis.get(cache_key):
return json.loads(cache)
# 没命中，调API
response = call_llm_api(question)
# 写入缓存，过期时间1小时
redis.setex(cache_key, 3600, json.dumps(response))
return response
实测加缓存后，API调用量降了70%，一个月省了大几百块的API费用。
四、提示词工程：我总结了三个万能模板
提示词写得好不好，直接决定AI输出质量。我总结了三个常用模板，基本能覆盖日常开发场景。
模板一：代码审查模板
plaintext
角色：你是一个资深后端开发工程师，擅长代码审查
任务：审查以下{语言}代码
要求：
1. 找出安全漏洞
2. 指出性能问题
3. 评估代码可维护性
4. 提出改进建议
代码：
{代码内容}
输出格式：
## 安全问题
{列出发现的问题及修复建议}
## 性能问题
{列出发现的问题及修复建议}
## 可维护性
{评估结果}
## 综合评分
{1-10分}
模板二：代码生成模板
plaintext
角色：{语言}后端开发专家
任务：编写{功能描述}
技术栈：{技术栈版本}
要求：
1. 符合PEP8/{语言}代码规范
2. 添加中文注释
3. 处理异常情况
4. 返回完整可运行的代码
功能需求：{具体需求描述}
额外约束：{如果有特殊要求，如性能要求、安全要求等}
模板三：问题排查模板
plaintext
现象：{描述遇到的问题}
环境：
- 系统：{操作系统}
- {语言}版本：{版本号}
- 依赖库：{主要依赖版本}
相关代码：
{粘贴关键代码片段}
已尝试的解决方法：
{列出你试过的方法及结果}
请分析可能的原因，并给出解决步骤。
这三个模板我用了大半年，AI输出质量稳定，比每次都临时组织语言效果好很多。
五、AI编程的正确姿势：不是替代，是协作
很多人担心AI会取代程序员。我觉得这个担心有点早。
AI确实能写代码，但它不懂业务。你告诉它”实现一个订单模块”，它能写出CRUD代码，但它不知道怎么设计订单状态机、怎么处理分布式事务、要不要考虑幂等性。这些业务逻辑和架构设计，必须人来定。
我用AI编程的思路是：AI负责执行，人负责决策。
具体来说：
- 需求分析、架构设计：人来
- 简单代码、补全、格式化：AI来
- 代码审查：AI初筛，人工复核
- bug定位：AI分析，人确认
- 性能优化：人分析热点，AI生成优化代码
这样分工下来，效率确实高了不少。以前一天写200行代码，现在能写500行，而且bug率还低了。
六、实用工具清单：我的开发环境配置
最后分享下我现在的开发环境：
编辑器：
- Cursor（主力）+ VS Code（备选）
- 插件：Prettier、ESLint、GitLens、Error Lens
AI工具：
- Cursor Composer：多文件编辑
- Cursor Chat：代码问答
- Notion AI：文档处理
API调用：
- OpenAI API（主力）：gpt-3.5-turbo-1106，性价比最高
- Claude API（备选）：代码和长文本处理更强
- 智谱GLM（国内项目）：中文场景表现好
调试工具：
- Postman：API测试
- Redis：缓存和向量存储
- LangSmith：LLM应用调试（贵，但好用）
写在最后
AI编程还在快速发展，每个月都有新工具冒出来。我的策略是保持关注，但不追新。稳定好用的工具先研究透，等新工具经过市场验证了再考虑切换。
以上就是我这一年AI编程的实战笔记，比较碎，但都是真金白银踩出来的坑。如果对你有帮助，欢迎收藏。
有问题欢迎评论区交流，一起进步。
相关推荐：
发表回复