我如何使用 AI 编码助手（以及你如何更好地使用它们）
Source: Dev.to
AI 助手与“空盒子”共事
AI 模型并不是会自动理解你项目的魔法编码员。它们只知道你告诉它们的内容。把每个模型想象成一个 空盒子（它的上下文窗口）。如果你不把 正确且相关 的信息填进这个盒子，助手就会猜测——而且通常会猜错。
在让 AI 助手执行任务之前，它需要了解：
- 你的框架和编码规范
- 项目结构
- 功能的目的
- 任何有用的包或工具
- 代码的当前状态
像 Cursor 这样的高级编辑器可以帮助完成这一步。它们注入高质量的系统提示并索引整个项目，使 Cursor 能在需要时自动拉取相关文件。你的本地或基础 AI 工具可能做不到，因为它们从未收到系统提示或索引上下文。
即使使用了高级工具，你仍然需要给出具体指令。
“修复 X 功能” 不是一个提示
开发者常犯的最大错误之一是给出模糊的指令。
错误示例：
Improve the UserController.这太宽泛了。助手不知道 “改进” 是什么意思。相反，你应该明确问题和期望的解决方案：
正确示例：
UserController.php is too large and difficult to maintain. Please refactor it into smaller classes and services based on SOLID principles. Move business logic into services or repositories and keep the controller clean.为什么这样有效
- 你定义了问题
- 你描述了期望的方向
- 你限定了范围
给助手的清晰度应当和你对新同事的说明一样。
只提供任务所需的上下文
更多的上下文并不总是更好。如果代理正在处理 支付模块，你不需要把整个报表模块、通知模块或无关的控制器也一起放进去。上下文过多会导致：
- 输出混乱
- 更高的 token 成本
- 响应变慢
保持上下文 聚焦。只有在信息真正相关时才让助手 “搭桥”。
好的提示应当详细且透明
如果你已经知道错误是什么，或者为什么会出问题，直接告诉助手。提供：
- 问题描述
- 错误信息
- 日志输出或堆栈跟踪
- 你期望的响应
- 任何约束或规则
这样做并不会失去控制，反而会得到更好的结果。不要对已经掌握的信息保密。
为任务选择合适的模型
你不会请物理学家去修理水管。模型选择的道理也是一样。
在以下情况下使用小模型：
- 任务规模小
- 上下文需求少
- 需要快速且低成本的响应
在以下情况下使用大模型：
- 任务复杂
- 需要更大的上下文窗口
- 需要深度推理
你并不总是需要最大的或最聪明的模型，而是需要最合适的模型。
创建可复用的上下文文件
为了提升工作流，创建一个类似 .ai-context/ 的文件夹，并添加小而有组织的 Markdown 文件：
- 项目结构
- 开发规则
- 包及其使用方式
- 环境差异
- 模块说明
- 高层架构
- 系统流程图
- 示例用法
保持文件 小、聚焦且不重复。必要时在文件之间建立链接，方便助手导航。
示例工作流
- 如果使用了某个库或包，创建一个简短的
.md文件，解释该库并提供简单示例。 - 将其放入
.ai-context/packages/。 - 在主架构文件中，只需引用它。
这样就形成了一个 AI 可依赖的知识库，类似于新开发者的入职文档。
用 AI 改进你的提示
如果你对英文（B2 以下）没有信心，可以让另一个 AI 模型帮你改写提示：
“Please improve this prompt for coding agents.”
这个小技巧可以显著提升代码质量。
结论
AI 编码助手是强大的工具，但前提是我们正确使用它们。它们不是读心术，也无法在没有正确上下文、结构和指引的情况下魔法般地理解整个项目。当你提供聚焦的信息、明确的问题以及精心准备的提示时，它们就会成为真正的伙伴，帮助你加速工作、减轻思维负担。
关键要点
- 具体化
- 保持组织化
- 只提供重要上下文
- 为任务挑选合适的模型
把 AI 当作需要指引的新同事，而不是什么都懂的机器。如果你为任务的交付建立了良好的系统，就能获得可靠、一致且高质量的结果。
AI 不会取代开发者，但懂得如何与 AI 合作的开发者肯定会拥有优势。