我的 AI 编程工作台：工具、模型与基础配置

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