AI 编码工具仍处于研发阶段

根据Stack Overflow 的 2024 年调查，76% 的开发人员正在使用或计划使用 AI 工具——它们现在只是工作的一部分。它们可以帮助完成平凡的任务，但当它们自信地产生无意义的结果时可能会令人讨厌。虽然 YouTubers 使用 ChatGPT 提示创建了“价值数十亿美元的初创公司”，并且 AI 代理每周都在接管世界，但真正的团队仍在研究如何有效地使用这些工具。今天，掌握 AI 辅助与编码或系统设计一样重要——我们需要快速适应。

问题是这些工具本质上仍处于研发阶段——它们不断变化、相互抄袭，并且因解决以前未解决的问题而受到赞扬。它们都缺乏明确的使用指南。即使是 Copilot，尽管更为成熟，也缺乏明确的教程和最佳实践。解决方案？我们将做开发人员最擅长的事情——自己组织和创建一个框架。

游戏规则改变者

...还有“量子飞跃”、“范式转变”、“代理即将到来”，等等。虽然这些工具确实改变了我们的工作流程，但变化更为实际：开发人员现在像团队领导一样工作，管理 AI 助手而不是直接编写代码。核心技能已转移到设计、规划、描述和审查。

这些工具引入的主要 UX 概念是：

1. 内联建议- 最自然的集成模式。当它们工作时，它们是无缝的 - 但当它们扰乱您的代码时，会立即影响生产力。
2. 聊天- 经典方法，LLM 通过引导提示与你的代码库进行交互
3. Composer （“ Copilot Edit ”、“ Cline act ”）——许多人觉得令人困惑的新概念。这是向自主代理的转变。Composer 可处理多个文件，并可根据错误、linting 问题等自动应用更改和迭代。
4. 代理- 预期的下一个发展阶段 - 完全自主和个性化的 AI 助手直接集成到您的 IDE 中。

熟悉“建议”并不复杂。AI 助手就是从这些建议开始的，这首先引起了我们的注意。聊天很简单：将文件插入上下文，迭代、应用并验证结果。

作曲家类型的工具在掌握方面更具挑战性，需要一定的学习曲线和一些不太明显的方法。目前， Cursor 编辑器提供了最易用的“作曲家”工具，而 Copilot 紧随其后，推出了“ Copilot Edits ”，最近推出了基于代理的工作流程。

要精通作曲家，您需要了解三个关键概念：

1. 指示
2. 规则
3. 语境

让我们逐一检查一下。

指示

作为团队负责人而不仅仅是开发人员，我们应该通过创建设计文档或清晰的产品需求文档来开始任何新项目或主要功能。这种做法可以培养强大的工程和产品思维，同时节省大量实施时间。最好的部分是这些文档可以：

1. 通过人工智能生成
2. 然后用作作曲家的指导

要创建这些文档，首先要收集人类的需求，然后参考 Chat 中的推理模型。Copilot 和 Cursor 都具有适合此任务的内置推理模型。OpenAI 的o1和o3-mini默认可用，而 Cursor 的 Chat 支持 DeepSeek-R1（尽管其 Composer 中尚未支持）——所有这些工具都是实现此目的的出色工具。

一个好的做法是将设计文档存储在存储库的顶层（我们将使用requirements文件夹），并按功能进行组织，并在根目录中放置ProjectOverview.md 。以下是 Twitter Web 应用程序需求的示例结构：

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

如果一切设置正确，添加新功能的设计文档就像写下这个提示一样简单：

将指令存储在代码库中具有明显的优势：版本控制、易于维护和标准 PR 工作流程。但是，产品负责人、经理和 UX 设计师等非技术团队成员可能需要在不使用 git 的情况下进行访问。以下是三种解决方案：

1. 将所有内容存储在 Notion 中，发布说明页面，并使用@Docs快捷方式将其作为文档注入

2. 创建一个将 Notion 页面转换为.md文件并将其存储在存储库中的管道
3. 教你的团队使用 git——对整个团队最有利的选择

一旦你的指令在编辑器中可用，就切换到编写器并开始执行。这将引导我们组织规则。

规则

目前，只有 Cursor 支持“规则”——针对特定文件/文件夹的直接执行指令。此功能可能会扩展到其他编辑器，包括 VSCode Copilot，它目前仅提供无法直接附加到代码库的“ 提示文件”。

Cursor 的规则更加全面 - 想象一下CONTRIBUTING.md与 linter 规则相结合并通过 LLM 功能增强。这些规则与产品无关、可共享，并可有效地在团队和库用户之间传递知识、最佳实践和实施细节。

规则可以通过命令面板创建，并以.mdc扩展名存储在项目的.cursor/rules文件夹中。此格式启用高级功能，例如在您的代码库中@mentioning特定文件。强烈建议将这些规则提交到您的存储库并协作改进它们。以下是使用规则的工作流程：

1. 研究特定于您的技术堆栈的游标规则，以精选列表作为参考。例如，您可以找到编写良好的 Next.js 和 React 游标规则，它们可以作为很好的模板。
2. 在开发过程中主动更新规则。当您在编写代码时注意到可以形式化为规则的模式时，请立即将其记录在规则文件中。
3. 向该领域的佼佼者学习。库创建者共享知识和增加采用的一种新方法是为 AI 助手创建专门的规则。我知道很少有公司这样做 - Convex通过为 OpenAI 和 Anthropic 模型创建规则并在其文档中分享这些规则而脱颖而出。虽然我没有使用过他们的产品，但他们专注于通过 AI 集成改善开发人员体验，这一点很有说服力。Supabase 是另一个很好的例子。

许多库都迫切需要 AI 规则。从前端开发人员的角度来看，如果TanStack Query 、 React Spring 、 Firebase等都有这些规则，我会受益匪浅。这些规则将节省大量时间，并有助于避免开发人员在学习新技术时犯的常见错误。

语境

请记住包含所有相关上下文 - 您提供的数据质量越高，获得的结果就越好。光标编辑器在这方面比 Copilot 更有优势，因为它允许多种类型的上下文：

1. 文档 - 效果非常好，只需为其提供任何文档的入口点，它就会下载、解析并保存以供将来需要
2. 网络搜索 - 不严格限于上下文，它提供对在线资源的快速访问
3. 各种开发工具 - 特定的 git 提交、lint 错误、记事本和其他工件
4. MCP服务器可以提供实时上下文。虽然设置起来有点棘手，但当您需要实时数据访问时，它们非常有用。

掌握这些工具后，下一步就是优化个人和团队绩效。但接下来的路该怎么走呢？

Cline 和 Roo-Code。控制

您总是需要在简单性和控制性、自动化解决方案和手动决策之间做出权衡。如果您愿意深入研究并且不怕处理错误、性能挑战和粗糙之处，请考虑尝试Cline （或其分支Roo-Code ，其理念略有不同）。

这两种工具都是为了尽可能地清晰地展示底层真正发生的情况：

1. 它们是开源的，无需订阅。相反，您可以使用自己的 LLM API 密钥或OpenRouter等服务，只需为您使用的内容付费。
2. Cline 清楚地展示了它的所有操作，包括它读取和修改了哪些文件。
3. Cline 提供了有关 LLM 通信、上下文窗口状态以及每次聊天会话的成本的详细见解。
4. 它具有直观的计划/行动模式——其他工具应该考虑采用的逻辑方法。

杀手级功能是 Cline 实际上可以运行和调试您的应用程序 - 它是真实的并且功能齐全，当您尝试时就会看到。

如果您对这一切感兴趣，请查看Addy Osmani 的最新文章，其中对这些编辑进行了出色的介绍。

结论

采用这些工具并非易事，不要指望“在 5 分钟内从头开始完成整个项目”。然而，这是一条明确的前进道路。

技术已经存在，但我们缺少一个强大的 AI 集成工作流程，以便围绕这些新工具组织整个团队（不仅是开发人员，而且是至关重要的管理人员和设计师）。AI 可能会让人感到害怕，分享其影响一开始可能会让人感到不舒服（例如告诉您的团队负责人，AI 通过精心配置编写了 80% 的功能）。然而，只有当这些工具成为团队工作流程不可或缺的一部分时，软件开发才会发展。最成功的转变发生在那些促进关于 AI 体验的公开讨论、协作工具探索并积极向更广泛的开发社区贡献他们学到的最佳实践的团队中。