这篇不写具体产品排行榜——各家迭代太快，名字半年一换。只记录几条稳定的协作原则，适用于带大模型能力的编辑器、终端助手或聊天窗口。
1. 给它「仓库级」上下文
单贴一个报错栈往往不够。尽量说明：语言与框架版本、相关文件路径、你尝试过的两步。
在支持 @ 文件 / 符号 的环境里，主动把定义处、调用处一并圈进来，比空泛问「为什么错了」省一半时间。
2. 先让它解释，再让它改
对不熟悉的模块，我会先问「这段代码在做什么、有哪些边界条件」，确认理解一致后，再下「请按某某约束重构」。
直接「帮我重写」容易得到看似干净、实则删掉关键分支的补丁。
3. 把「可运行」当作验收标准
生成脚本或配置后，本地跑一遍再提交。AI 很擅长写出「语法正确但环境不对」的东西——这和人类同事一样，需要 CI 与人工扫一眼。
4. 文档与注释：它写初稿，你定事实
API 说明、README 步骤、Release Note，让模型根据代码与 diff 起草很省时间；但对外承诺、安全相关、版本号必须人眼过。
5. 知道何时关掉它
做架构权衡、定需求优先级、或处理人际与伦理问题时，模型可以给参考，但决策权在人。工具越顺手，越要有意识地保留「不依赖模型的思考时间」。
如果你也在用静态站点（例如本博客用的 Hugo）、文档站或笔记仓库，可以把「内容仓库 + 简单检索」当作练手 RAG 的第一步——比追逐新模型版本更能沉淀成自己的东西。