场景从「试试看」到「离不开」2025 年年初我把 Claude Code 装上的时候纯粹是出于好奇 到年底电脑里同时有 Claude Code、Codex、Gemini CLI、OpenCode、Aider、Cursor。 我盯着 dock 上那排图标第一次认真地想一个问题「我用 AI 编程了吗还是我在被 AI 编程折腾」这一年里我换过几次主力工具、做过几次工作流重构、踩过几次同样的坑。 最后沉淀下来的不是「哪个工具最强」而是 6 条反复验证过的心法。希望对正在用或准备用 AI 编程的你有一点点用。心法一你的核心矛盾不是AI 不够聪明是上下文不够清楚很多人卡在 AI 编程第一步是因为期待太高——以为把一段需求甩过去 AI 就能产出可用的代码。事实是AI 编程的效果几乎完全取决于你给了它多少正确的上下文。正确的上下文不是越多越好而是越贴当前任务越好。 我把它分成三类类型含义典型来源项目上下文项目结构、约定、依赖、构建命令CLAUDE.md/AGENTS.md/.cursorrules任务上下文当前要做什么、为什么要做、约束是什么你在 prompt 里写的话历史上下文这个文件之前怎么改的、上次为什么这么写git log、会话历史实战里最容易忽略的是项目上下文。很多人会让 AI 直接看整个仓库——但工具读文件是有成本和上限的 而且工具不知道你心里的约定。一个简单做法在项目根放一份CLAUDE.md或AGENTS.md视工具而定 用10–30 行写下项目类型前后端库CLI核心命令怎么 build、怎么 test、怎么 lint明确不做的事不要把测试加进 README、不要主动改 lockfile 等命名 / 目录约定这一份文档能让 AI 的第一轮输出从「能跑」变成「能合进 main」。心法二选工具看三个维度而不是听说很强工具间的能力差异没有宣传的那么大。 真正影响你日常体验的是这三个维度1. 能力边界每个工具都有擅长区和弱区任务类型通常更擅长的工具形态大型重构跨多个文件IDE 集成类Cursor 类从零探索理解陌生代码库长上下文 工具调用类Claude Code 类机械性补全写样板代码、写测试IDE 内联补全 短上下文类对话式调试为什么这个 bug 反复出现终端会话类、能跑命令的2. 上下文机制工具怎么记住上下文这决定了它能不能跨会话延续思路每次新开会话最干净适合一次性的任务带历史回放能接续但贵token / 时间自动索引整个项目最快但成本最高且容易跑偏。没有最优只有适合你的工作节奏的。3. 工作流契合度这个被严重低估。一个工具再好如果和你日常的工作流断档比如要切窗口、要复制粘贴、要重启 daemon 你最终会放弃它。判断方法很简单装上它用真实项目跑一周别看 demo。心法三会话是有价值的资产别让它随风而散这是大多数人会忽略的一点也是我今年踩最大的坑。一次成功的 AI 编程对话往往是这样 你花了 20 分钟和它聊、debug、改 prompt、再聊最终找到一个优雅的解法。 然后你切换项目、第二天回来——「上次那个解法是什么来着哪次会话来着」工具本身不帮你解决这个问题。多数工具的会话记录存在本机的某个目录里 文件名是哈希或者时间戳没有任何业务含义。建议的做法每个项目一个目录你可能已经在这么做了每周花 10 分钟整理把有价值的会话复制到一个notes/ai-sessions/目录里文件名改成业务含义比如2026-10-07-fix-session-leak.md重要的会话留个 commit message 提示比如这样即使工具本身的会话格式改了你也能通过 git 反查回去。小提示如果你确实装了好几个 AI 编程 CLI、又在多个项目间切换 找会话的频率会显著上升。一些聚合型工具能扫本机所有 agent 工具的会话目录 把它们列在同一个界面里比如 kshell 做的就是这件事——它不替你写代码但能让你少记几个目录路径。 这类工具的克制不做对话只做发现反而是优点 因为它永远不会和你的主力工具抢话语权。心法四把工作流切成阶段每个阶段用最合适的形态一个完整的开发任务其实包含多个阶段不同阶段对工具的要求是不同的我的实际切法阶段工具偏好原因探索读陌生代码、问这是干什么的长上下文、能读全文的不需要写只读多设计这个功能怎么实现聊天 多轮IDE 不重要重点是讨论不是产出实现动手写代码IDE 内联补全 短 prompt反应快、可控、不会跑偏验证跑测试、修 bug终端会话能跑命令需要 shell提交commit message、PR 描述短上下文文案任务快速出活我没有用同一个工具走完这五个阶段——太奢侈也太低效。关键的纪律是不要工具焦虑。 工具换来换去本身是低价值活动。每两周一次够了多花在理解工具特性上。心法五工具的边界感决定你能走多远我见过两类极端用户A 类让 AI 决定一切。从架构到命名到 commit message全交给 AI。 结果代码看着不错但自己讲不出为什么这么写。B 类完全不信任 AI每个字符都要逐行 review。 结果累死自己AI 编程反而成了负担。健康的位置在中间——让 AI 做它擅长的让你做你擅长的。适合让 AI 做的机械性补全boilerplate、测试用例、CRUD模式化重构重命名、提取函数、补 type annotation把自然语言需求翻译成具体代码写第一版然后你 review适合你做的业务决策要不要做、为什么这么做、优先级命名 / 接口设计品味和长期可读性跨模块的归纳这个项目和那个项目的关系出错时的根因判断AI 经常抓到症状抓不到根因一个简单的判断标准如果你能清楚描述该怎么做就交给 AI如果你自己都不确定该怎么做先自己想清楚再问 AI。心法六少即是多——挑 2–3 个深度用比装 10 个有用这条最反直觉也是我最想说的。工具圈有个怪现象每个月都有人整理「2026 年必备的 10 个 AI 编程工具」。 这类文章我几乎每年都看每年都发现装完、用一周、卸掉 8 个。真正有用的组合往往很小。我自己现在的配置角色工具占比主力一个终端 IDE 内联补全70%备用一个长上下文的会话工具探索 / 重构用25%实验偶尔试试新出的每周不超过 1 小时5%主力 备用就够覆盖 95% 的场景。 实验性工具只在「我真的有具体需求」时才升到主力。而且当你真的需要 3 个以上工具时切换成本会快速累积—— 不是因为工具本身是因为「记忆切换」这个项目上次用的是哪个上次聊到第几轮了这个工具的快捷键是什么如果你的痛点是装了 3 个以上工具、记不清哪个项目用哪个 最划算的解决方法是把找会话和开工具这两件事合并到同一个入口。 一些轻量的桌面工具能做到这点同样是上面的 kshell MIT 协议、Go 写的它做的事情就是扫一遍你电脑上装了哪些 agent CLI 把工作区、会话、终端收进一个列表——你自己挑、自己点开。但记住它替你做的越少你越自由。 凡是试图接管你对话过程的统一 AI 客户端都要警惕——它要么偷偷替换你的工具 要么把上下文全锁死在它自己手里。这种工具离得越远越好。一句话总结AI 编程的下半场比的不是谁用得多是谁能把它用得克制。把 6 条心法浓缩成 3 句上下文 工具花 30 分钟写一份好的CLAUDE.md比换 3 个工具都值。分阶段 一把梭探索、设计、实现、验证每个阶段用最合适的形态。克制 焦虑主力 1 个 备用 1 个其他只在真的解决具体问题时才升上来。最后送你一个具体可执行的起点这周选 1 个你最常用的项目给它写一份 10 行的CLAUDE.md 列出 3 个不要做和 3 个必须做。用 2 周看看你和 AI 的协作有没有变化。如果变了那 6 条心法对你有用 如果没变那说明你的工作流本身已经够清晰工具不是瓶颈。附kshell顺篇提到的工具的下载GitHubReleases · kaiys202212/kshell · GitHubGitCode国内源AtomGit - 全球开发者的开源社区,开源代码托管平台仅在你确实装了 2 个以上 AI 编程 CLI、且频繁在它们之间切换时再考虑。它不做对话只做发现——这个克制是它最大的优点。