我如何使用 AI 编码助手（以及你如何更好地使用它们）
Source: Dev.to
请提供您想要翻译的具体文本内容（除代码块和 URL 之外），我会按照要求将其翻译成简体中文并保留原始的格式和 markdown 语法。谢谢！
介绍
AI 编码助手已经成为热门话题。一些开发者说它们很糟糕，让他们的工作变慢，而另一些人则说 AI 帮助他们更快工作，减轻了心理负担。那么为什么体验差异如此大？有哪些人做错了，而有哪些人做对了？
本文解释了 AI 编码助手的实际工作原理，如何为它们提供正确的上下文，以及通过改进提示和工作流程，如何获得更好的结果。
1. AI 助手与“空盒子”一起工作
AI 模型并不是能够自动理解你项目的神奇编码员。它们只能知道你告诉它们的内容。把每个模型想象成一个空盒子（它的上下文窗口）。如果你不向该盒子填入正确且相关的信息，助手就会进行猜测——而且通常会猜错。
在让 AI 助手执行任务之前，它需要了解：
- 你的框架和编码规范
- 你的项目结构
- 功能的目的
- 任何有用的包或工具
- 代码的当前状态
像 Cursor 这样的高级编辑器在这里提供帮助。它们注入高质量的系统提示并索引你的整个项目，使得 Cursor 能在需要时自动提取相关文件。你的本地或基础 AI 工具可能做不到，因为它们从未收到该系统提示或索引的上下文。
即使使用了高级工具，你仍然必须提供具体的指示。
2. “Fix X Feature” 不是提示
开发者常犯的最大错误之一是给出含糊的指示。
错误示例：
“Improve the UserController.”
这太宽泛了。助手不知道“改进”指的是什么。相反，请具体说明问题和期望的解决方案：
正确示例：
“UserController.php 太大且难以维护。请根据 SOLID 原则将其重构为更小的类和服务。将业务逻辑移至服务或仓库中，保持控制器简洁。”
为什么这样有效
- 你定义了问题
- 你描述了期望的方向
- 你限定了范围
给助手提供与你对新同事的要求同等的清晰度。
3. 只提供任务所需的上下文
更多的上下文并不总是更好。如果代理正在处理 payment module，则不需要包括整个 report module、notification module，或不相关的控制器。上下文过多会导致：
- 输出混乱
- 更高的 token 成本
- 响应变慢
保持上下文 聚焦。只有在信息真正相关时，才让助手“搭建桥梁”。
4. 好的提示应详尽且透明
如果你已经知道错误是什么，或者为什么某些东西会出错，请直接告诉助手。提供：
- 问题
- 错误信息
- 日志输出或堆栈跟踪
- 你期望的响应
- 任何约束或规则
这样做不会让你失去控制，反而会获得更好的结果。不要对你已经知道的信息保密。
5. 为工作选择合适的模型
你不会雇佣物理学家来修理你的管道。模型选择也是同样的道理。
在以下情况下使用小模型：
- 任务规模小
- 上下文需求最小
- 需要快速且低成本的响应
在以下情况下使用大模型：
- 任务复杂
- 需要更大的上下文窗口
- 需要深度推理
你并不总是需要最大或最聪明的模型，而是需要合适的模型。
6. 创建可复用的上下文文件
为了提升工作流，创建一个类似 .ai-context/ 的文件夹，并添加小型、结构化的 Markdown 文件：
- 项目结构
- 开发规则
- 包及其使用方式
- 环境差异
- 模块说明
- 高层架构
- 系统流程图
- 示例用法
保持文件小巧、专注且不重复。需要时在文件之间建立链接，以便助手能够导航它们。
示例工作流
- 如果使用某个库或包，创建一个小的
.md文件，简要说明该库并提供简单示例。 - 将其放入
.ai-context/packages/。 - 在主架构文件中，只需引用它。
这会创建一个 AI 可以依赖的知识库，就像为新开发者准备的入职文档一样。
7. 使用 AI 改进你的提示
如果你的英语水平不自信（B2 或以下），可以让另一个 AI 模型改写你的提示：
“请改进此用于编码代理的提示。”
这个简单的技巧可以显著提升代码质量。
结论
AI 编码助手是强大的工具，但前提是我们正确使用它们。它们不是读心术，也无法在没有正确上下文、结构和指导的情况下神奇地理解你的整个项目。当你向它们提供聚焦的信息、明确的问题和精心准备的提示时，它们就会成为真正的合作伙伴，能够加快你的工作进度并减轻你的心理负担。
记住：要具体、保持组织性，只提供重要的上下文，并为任务选择合适的模型。把 AI 当作需要指示的新队友，而不是全知全能的机器。如果你围绕任务分配建立一个良好的系统，你将获得可靠、一致且高质量的结果。
AI 不会取代开发者，但懂得如何与 AI 合作的开发者肯定会拥有优势。