场景：从「试试看」到「离不开」
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（顺篇提到的工具）的下载
GitCode（国内源）：AtomGit - 全球开发者的开源社区,开源代码托管平台
仅在你确实装了 2 个以上 AI 编程 CLI、且频繁在它们之间切换时再考虑。 它不做对话，只做发现——这个克制，是它最大的优点。
