开篇
开始使用 AI 编程后，很多人的桌面会迅速变成这样：
- 浏览器里开着多个 AI 对话窗口。
- 编辑器里装了好几个代码助手。
- 终端里偶尔运行一个自动化 Agent。
- 收藏夹里保存了很多模型、插件和 Prompt。
工具越来越多，真正的问题却没有减少：
- 写需求时，不知道该打开哪个工具。
- 让 AI 改代码时，担心它不了解项目上下文。
- 遇到复杂问题时，不知道该优先使用快速模型还是深度推理模型。
- 配置换了一次又一次，最终还是回到临时复制、临时提问。
- 密钥、日志和代码片段散落在不同地方，既不高效也不安全。
我后来意识到，AI 编程最重要的不是"拥有多少工具"，而是建立一个稳定的工作台。
这里的工作台不是某一个软件，而是一套能够重复使用的配置：
text
任务入口
↓
项目上下文
↓
模型分工
↓
代码执行与验证
↓
知识沉淀本文分享的是一套面向中级开发者的最小 AI 编程工作台。
它不依赖某个具体品牌，也不要求一次配置很多工具。你可以用现有工具替换其中的任意一层。
本文不会讨论什么
为了避免把"工作台"写成一份工具广告，先说明本文不会讨论的内容：
- 不做工具或模型的能力排名。
- 不要求同时安装多个编辑器插件。
- 不把 Agent 自动改代码当作默认工作方式。
- 不把生产环境密钥、用户隐私数据或未脱敏日志发给 AI。
- 不认为更贵、更慢的模型一定适合所有任务。
这篇文章的目标是：
用最少的层次，搭一套能够持续使用、容易验证、方便迁移的 AI 编程工作台。
一、为什么需要"工作台"，而不只是一个 AI 工具
单个 AI 工具通常只能解决一个局部问题。
例如：
- 对话窗口适合讨论需求、方案和报错。
- IDE 助手适合阅读当前文件、修改小范围代码。
- 终端型 Agent 适合执行多文件修改、运行命令和生成脚手架。
- 文档库适合保存项目背景、规范和可复用 Prompt。
如果这些工具之间没有明确分工，就很容易出现两种情况：
text
情况一：所有问题都丢进对话窗口
↓
上下文越来越长
↓
答案越来越泛
↓
最终仍然要自己重新整理
text
情况二：所有改动都交给 IDE 或 Agent
↓
修改范围越来越大
↓
项目规则没有说清
↓
测试和审查压力反而增加稳定的工作台应该让不同工具各自做擅长的事：
| 工作层 | 主要职责 | 适合的任务 |
|---|---|---|
| 对话层 | 思考、澄清、比较方案 | 需求拆解、技术方案、排障假设 |
| IDE 层 | 阅读、局部编辑、即时反馈 | 当前模块理解、小范围修改、代码解释 |
| 终端层 | 执行、批处理、验证 | 运行测试、生成文件、跨文件修改 |
| 模型层 | 按任务复杂度分工 | 快速问答、代码阅读、深度设计 |
| 项目上下文层 | 提供规则和可复用信息 | 架构、规范、接口、测试与安全边界 |
工作台的价值，不是让 AI 自动完成一切。
而是让每一次协作都有明确入口、足够上下文和验证出口。
二、我的工作台遵循的 4 个原则
1. 一个任务，只保留一个主要入口
一个任务开始时，先决定它最适合从哪里进入：
- 需求不清晰，先进入对话层。
- 需要理解当前模块，先进入 IDE 层。
- 需要多文件执行和测试，先进入终端层。
- 需要整理规范或复盘，先进入文档层。
不要在多个工具中同时开始同一个任务。
否则很容易产生多个版本的结论、代码和待办事项。
2. 默认使用最小权限和最小上下文
AI 不需要知道整个项目，才能帮助你解决一个函数级问题。
提供上下文时，建议从小到大逐步增加：
text
任务描述
↓
相关文件和类型定义
↓
已有规则与测试
↓
必要的调用链和日志这样既能减少无关信息干扰，也能降低敏感信息泄露的风险。
3. 模型按任务分工，不按"谁最强"分工
可以把模型简单分成三类用途：
| 模型类型 | 更适合的任务 | 使用重点 |
|---|---|---|
| 快速模型 | 代码解释、摘要、简单脚本、格式整理 | 追求反馈速度 |
| 主力模型 | 模块实现、测试设计、常规排障 | 追求稳定和性价比 |
| 深度推理模型 | 架构比较、复杂 Bug、跨模块设计 | 追求思考质量和风险分析 |
不需要为每一类任务准备多个模型。
先明确一个默认模型，再为复杂设计或高风险排障保留一个深度模型，通常就足够了。
4. 所有 AI 输出都要回到代码和测试中验证
无论输出来自对话窗口、IDE 还是终端 Agent，都不要把它当作最终交付。
你的工作台必须保留这条闭环：
text
AI 提供建议或代码草稿
↓
开发者审查改动范围
↓
运行格式化、静态检查和测试
↓
查看差异并确认业务逻辑
↓
提交或继续迭代没有验证出口的工作台，只是一个更快的内容生成器。
三、搭建工作台时，先配置这 5 个核心组件
1. 任务对话区：用于澄清，而不是长期存放所有信息
对话区适合处理还没有进入代码编辑阶段的问题，例如：
- 把模糊需求整理成待确认问题。
- 比较两个技术方案的利弊。
- 根据日志整理排障假设。
- 为一次代码修改设计测试矩阵。
每次开启对话，建议先给出固定的任务卡：
text
任务目标：
[要实现、排查或重构什么]
当前阶段：
[需求澄清 / 代码阅读 / 方案设计 / 实现 / 测试 / 排障]
已知事实：
[已经确认的业务规则、错误现象、相关模块]
待确认问题：
[目前还不清楚的地方]
本轮希望得到的结果：
[问题清单 / 方案对比 / 测试矩阵 / 代码草稿]这比直接问"怎么做"更容易得到可审查的结果。
2. IDE 协作区：用于理解当前上下文和完成小范围修改
IDE 是代码修改的主阵地。
在这里使用 AI 时，建议遵守两个边界：
- 先阅读相关文件，再请求修改。
- 优先让 AI 处理小范围、可验证的改动。
例如，与其说：
text
帮我重构整个订单模块。不如说：
text
请只审查当前 Service 中的 cancelOrder 方法。
要求：
1. 不修改其他文件。
2. 列出输入校验、状态流转和异常处理问题。
3. 区分必须修改和建议优化。
4. 给出最小修改方案。范围越清楚，审查和回滚就越容易。
3. 终端执行区：用于把建议变成可验证结果
终端型工具最适合执行固定、重复、可检查的动作：
- 创建规范的文件和目录。
- 运行测试、静态检查和格式化。
- 搜索调用链和配置项。
- 批量修改明确模式的文本。
- 输出改动摘要和待验证项。
但终端自动化不应该跳过测试。
建议把常用验证命令整理为项目脚本，并要求 AI 在执行后报告：
text
1. 修改了哪些文件。
2. 每处修改的目的。
3. 执行了哪些检查。
4. 哪些检查通过，哪些没有执行。
5. 还需要人工确认什么。只要保留这份报告，即使工具自动化程度提高，开发者也不会失去对改动的掌控。
4. 模型分工区：为速度、成本和复杂度留出选择
"所有任务都使用同一个模型"并非一定错误，但容易造成两种浪费：
- 简单工作使用了过度复杂的推理，等待时间太长。
- 高风险问题使用了过快的回答，遗漏关键约束。
可以用一个简单策略管理模型：
text
简单、重复、结果容易检查
→ 使用快速模型
常规开发、测试设计、代码审查
→ 使用主力模型
跨模块设计、复杂排障、重要技术决策
→ 使用深度推理模型，并要求列出假设和风险模型不是越多越好。
关键是每次使用前，知道自己需要的是"更快得到草稿"，还是"更仔细地分析问题"。
5. 项目上下文区：让 AI 每次都能拿到正确的规则
这是最容易被忽略、但最值得优先配置的一层。
建议在项目里维护一份 AI 也容易阅读的上下文目录：
text
docs/
ai/
project-overview.md
architecture.md
coding-conventions.md
testing-guide.md
security-boundaries.md
task-template.md这些文件不需要写得很长。
最重要的是回答常见问题：
| 文件 | 至少应包含什么 |
|---|---|
| project-overview.md | 项目目标、技术栈、启动方式、目录说明 |
| architecture.md | 模块职责、分层边界、核心调用链 |
| coding-conventions.md | 命名、异常、日志、依赖和提交规范 |
| testing-guide.md | 测试命令、测试类型、关键覆盖要求 |
| security-boundaries.md | 脱敏规则、权限边界、禁止暴露的信息 |
| task-template.md | 任务背景、规则、验收和输出要求模板 |
例如，project-overview.md 可以从最小版本开始：
md
# 项目概览
## 技术栈
- 后端：Java + Spring Boot
- 数据库：MySQL
- 测试：JUnit
## 目录职责
- controller：HTTP 请求和参数校验
- service：业务编排
- repository：数据访问
## 本地验证
- 运行单测：[填写命令]
- 运行静态检查：[填写命令]
## 注意事项
- 金额统一以分存储
- 业务错误统一使用领域异常
- 不要在日志中打印用户隐私字段这类上下文文件既服务于 AI，也服务于新同事和未来的自己。
四、基础配置中最容易忽略的安全边界
AI 编程工作台必须从一开始就把安全边界配置进去。
以下信息默认不应直接发送到外部模型或第三方工具：
- 生产环境密钥、Token、Cookie 和私钥。
- 用户手机号、身份证、地址等隐私数据。
- 未脱敏的线上日志和数据库导出。
- 客户合同、内部财务信息和未公开业务策略。
- 包含敏感地址、账号和权限信息的配置文件。
建议保留以下习惯：
text
提交代码前
→ 检查 .env、密钥和本地配置是否被忽略
发送日志前
→ 删除用户标识、Token、完整请求体和内部地址
提供代码前
→ 只提供与问题相关的最小片段
使用自动化工具前
→ 确认它能访问哪些目录、能执行哪些命令安全不是在出现问题后再补的功能。
它应该是工作台的默认配置。
五、30 分钟搭建你的最小 AI 编程工作台
不需要等到换电脑或新项目。
你可以用半小时完成下面这套最小配置：
- 确定一个主入口。 选择你最常用的对话工具或 IDE 助手，不同时维护多个主要入口。
- 准备两个模型档位。 一个用于日常快速协作，一个用于复杂设计和排障。
- 写一份项目概览。 先完成
project-overview.md，把技术栈、目录和验证方式写清楚。 - 保存一个任务模板。 每次提问前写清任务目标、上下文、规则和验收标准。
- 固定验证动作。 找出项目中的测试、静态检查和格式化命令。
- 建立复盘位置。 每周记录一次有效 Prompt、失败案例和可复用清单。
可以用这份清单检查自己的工作台是否已经可用：
text
[ ] 我知道每类任务应该从对话、IDE 还是终端进入。
[ ] 我有一个默认模型和一个处理复杂任务的模型。
[ ] 我能向 AI 提供项目概览、规范和测试方式。
[ ] 我不会在对话中暴露密钥、隐私数据和未脱敏日志。
[ ] 我会检查 AI 修改的文件和差异。
[ ] 我有固定的测试、静态检查或格式化验证命令。
[ ] 我会保存有效的 Prompt、检查清单和复盘记录。这套配置的目标不是追求"全自动"。
而是让你在每一次真实任务中，都能更快进入状态、更少重复解释项目背景，并更容易验证 AI 的输出。
六、总结
我的 AI 编程工作台，不是一张工具清单，而是一套五层结构：
- 用对话层澄清问题和比较方案。
- 用 IDE 层理解当前代码并完成小范围修改。
- 用终端层执行可验证的自动化动作。
- 用模型分工匹配任务复杂度。
- 用项目上下文层提供规则、规范和安全边界。
当这五层逐渐稳定后，即使你更换工具或模型，核心工作方式也不会被打乱。
真正可持续的 AI 编程效率，来自清晰的任务入口、干净的项目上下文、可靠的验证闭环和不断积累的工程资产。
下一篇文章，我们来解决一个更具体的问题：
如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
也欢迎在评论区留言：你的 AI 编程工作台里，最常用的是对话、IDE 还是终端？
✍坚持原创，求关注，点赞，收藏