## 场景：从「试试看」到「离不开」

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、再聊，最终找到一个优雅的解法。 然后你切换项目、第二天回来——

> 「上次那个解法是什么来着？哪次会话来着？」

工具本身不帮你解决这个问题。多数工具的会话记录存在本机的某个目录里， 文件名是哈希或者时间戳，没有任何业务含义。

**建议的做法：**

1.  **每个项目一个目录**（你可能已经在这么做了）

1.  **每周花 10 分钟"整理"**：把有价值的会话复制到一个 `notes/ai-sessions/` 目录里，文件名改成业务含义（比如 `2026-10-07-fix-session-leak.md`）

1.  **重要的会话留个 commit message 提示**，比如：
    

这样即使工具本身的会话格式改了，你也能通过 git 反查回去。

> **小提示**：如果你确实装了好几个 AI 编程 CLI、又在多个项目间切换， 找会话的频率会显著上升。一些聚合型工具能扫本机所有 agent 工具的会话目录， 把它们列在同一个界面里，比如 [kshell](https://github.com/kaiys202212/kshell "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](https://github.com/kaiys202212/kshell "kshell")， MIT 协议、Go 写的），它做的事情就是扫一遍你电脑上装了哪些 agent CLI， 把工作区、会话、终端收进一个列表——你自己挑、自己点开。

> 但记住：**它替你做的越少，你越自由**。 凡是试图接管你对话过程的"统一 AI 客户端"，都要警惕——它要么偷偷替换你的工具， 要么把上下文全锁死在它自己手里。这种工具离得越远越好。

---

## 一句话总结

> **AI 编程的下半场，比的不是"谁用得多"，是"谁能把它用得克制"。**

把 6 条心法浓缩成 3 句：

1.  **上下文 > 工具**：花 30 分钟写一份好的 `CLAUDE.md`，比换 3 个工具都值。

1.  **分阶段 > 一把梭**：探索、设计、实现、验证，每个阶段用最合适的形态。

1.  **克制 > 焦虑**：主力 1 个 + 备用 1 个；其他只在真的解决具体问题时才升上来。

最后送你一个具体可执行的起点：

> **这周选 1 个你最常用的项目，给它写一份 10 行的 `CLAUDE.md`， 列出 3 个"不要做"和 3 个"必须做"。用 2 周，看看你和 AI 的协作有没有变化。**

如果变了，那 6 条心法对你有用； 如果没变，那说明你的工作流本身已经够清晰，工具不是瓶颈。

---

## 附：kshell（顺篇提到的工具）的下载

-   GitHub：[Releases · kaiys202212/kshell · GitHub](https://github.com/kaiys202212/kshell/releases "Releases · kaiys202212/kshell · GitHub")

-   GitCode（国内源）：[AtomGit - 全球开发者的开源社区,开源代码托管平台](https://gitcode.com/abraveheart2023/kshell/releases "AtomGit - 全球开发者的开源社区,开源代码托管平台")

仅在你确实装了 2 个以上 AI 编程 CLI、且频繁在它们之间切换时再考虑。 **它不做对话，只做发现**——这个克制，是它最大的优点。

2025 年年初我把 Claude Code 装上的时候，纯粹是出于好奇； 到年底，电脑里同时有 Claude Code、Codex、Gemini CLI、OpenCode、Aider、Cursor。 我盯着 dock 上那排图标，第一次认真地想一个问题：

AI 编程工具用了一年，我把「怎么用好它们」总结成 6 条心法

编程语言

人工智能

开发工具

2025年AI编程实战心得：从工具选择到工作流优化的6条核心心法。聚焦上下文管理、工具选型、会话资产沉淀、分阶段工作流、边界感把控及工具克制使用，提供CLAUDE.md配置等具体可执行方案，助力开发者提升AI协作效率。

AI编程

GitHub

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI 编程工具用了一年，我把「怎么用好它们」总结成 6 条心法-腾讯云开发者社区-腾讯云

AI 编程工具用了一年，我把「怎么用好它们」总结成 6 条心法

AI 编程工具用了一年，我把「怎么用好它们」总结成 6 条心法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐