AI IDE

IDE介绍

IDE（Integrated Development Environment）为“一体化的软件开发工作空间”，包含编辑器、编译器、调试器等核心组件。大多数开发工作都在 IDE 中完成，因此它是 AI 增强功能的自然载体，在 IDE 的演进过程中，功能整合与开发者定制化之间始终存在一种平衡。

AI IDE的发展历程：

• 1983 年：Turbo Pascal 发布，被标注为“第一个真正的 IDE”，集编辑器、编译器、链接器于一体，专为 Pascal 语言设计。
• 1997 年：Microsoft Visual Studio 发布，为 C++/Visual Basic 提供高级调试功能，标志着 IDE 向多语言、多功能平台演进。
• 2001 年：IntelliJ IDEA 发布，引入上下文感知的代码导航、重构与自动补全，极大提升了 Java 开发效率。
• 2015 年：Microsoft VSCode 发布，以轻量级、高度可扩展的编辑器形态出现，迅速成为开发者主流工具。
• 2023 年：Cursor 发布，被描述为“首批广泛使用的 AI 原生 IDE 之一”，标志着 AI 技术深度融入开发环境。

现代AI编程助手

基础模式

现代AI编程助手的能力主要分为两种：基础核心模式 和 真正的AI原生模式。

基础模式代表了当前 AI 编程的“基本功”，主要解决的是局部、即时、确定性的问题。

比如行内补全，函数生成，对单文件进行操作，多文件修改等，前三者大多都是基于使用者惯性或者对单个文件的简单分析。直到多文件才是过往IDE和未来IDE之间的临界点，多文件修改和理解会逼迫AI去检索项目中的其它文件，对整体进行改动。

代码补全只会截取光标附近的小窗口代码，代码片段发送到云端的大模型，然后回流到编辑器。其中为了保障速度，一般采用专门针对代码优化的模型。

AI原生模式

真正的AI原生模式代表了范式转移。在这里，AI 不再仅仅是被动等待指令的补全工具，而是变成了能够自主思考、规划和执行的智能体。

它一定会涉及到全项目的上下文理解。IDE会将整个项目代码切分成小块（chunks），然后用embedding模型把代码转换成向量存储在向量数据库中，之后当用户进行提问时，IDE会根据用户的提问在数据库中找到最相似的代码作为上下文。当然代码在更新时，IDE也会定期更新向量数据库的索引，通过 Merkle 树计算块差异以进行高效更新。所以说AI IDE记住整个项目并不是靠模型，而是外挂了一个高效的向量数据库。

常见的代表有：

• Background agents（后台代理）：让AI在后台异步完成一些任务。
• Model Context Protocol（MCP，模型上下文协议）：它允许 AI 模型安全地连接到外部数据源和工具。在编程语境下，AI 不仅能读代码，还能连接数据库查看表结构、读取本地文件系统、甚至调用编译器 API它允许 AI 模型安全地连接到外部数据源和工具。
• Learn memories（学习记忆）：长期记忆和短期记忆，上下文等。
• Bugbot (PR review)（缺陷机器人/代码审查）：语法检查（Lint），而是逻辑审查。指出代码潜在的空指针异常、安全漏洞或设计模式的不当使用。

AI工具的演进路径

1. 从“辅助”到“代理”：工具的角色正在从“辅助开发者写代码”（左上象限）向“独立完成任务”（右下象限）转变。
2. 从“本地”到“云端”：随着任务复杂度的增加，对算力和数据的需求也增加，工具正越来越多地依赖云端资源。
3. 从“同步”到“异步”：未来的高效开发者将更多地采用“异步”模式，将复杂任务委派给AI代理，自己则专注于更高层次的设计和决策。

与AI的协作实践

Plan

你给 AI 的指令质量，应该取决于任务的复杂程度。它其实是在暗示开发者，随着任务难度的提升，你的角色也需要发生转变。

当完成简单变更时，比如修改函数命名，添加注释，实现简单小功能。在这种场景下，你的直觉就是最好的提示词。你不需要写文档，不需要画流程图，甚至不需要完整的句子。因为上下文就在那里，AI 能够轻易捕捉到你的意图。过度设计提示词反而是一种时间浪费。

面对复杂任务，你必须强迫自己转变身份，成为一个“产品经理”。你要对任务有一个清晰的认知和描述，描述过程存在几个核心要素：

• 目的：明确变更目的，让AI做出更符合业务逻辑的技术决策。
• 定义：补充必要的背景知识，专业术语解释等
• 计划：高层次的实现分解任务，给出大致的技术路线图。
• 被更改的源文件：明确指出代码库中哪些部分是相关的，以及为什么。这能帮助 AI 聚焦上下文，避免它去分析无关的代码，从而提高效率和准确性。
• 范围外：明确指出什么不应该被更改。这是一个非常关键的约束条件。
• 测试用例，边缘情况
• 扩展性：说明未来哪些变更会相关，以便 LLM 能够设计出具有前瞻性的架构。

Code

AI 的困惑往往源于“混乱的代码库”。为了让 AI（以及人类）能更好地理解项目，我们需要提供最优的上下文。我们的核心在于增加代码库的可读性和消除上下文的歧义。

比如在让 AI 工作前，应确保以下信息清晰且文档化：

• 仓库导航与结构： 文件目录树、核心文件位置。

• 环境设置： 如何安装依赖、如何启动开发环境。

• 规范与风格： 代码风格（缩进、命名）、最佳实践。

• 技术细节： 数据访问模式、API 接口定义与契约。

• 文档化： 上述所有内容都必须有详尽的文档。

• 单体仓库设计： 强烈推荐将相关项目、库、服务放在一个仓库中，便于 AI 统一理解上下文。

• 避免“混乱”： 杜绝多种访问模式混用、变量命名不一致、重复代码（多个函数做同一件事）。

除了优化代码本身，我们还可以通过特定的配置文件，主动向 LLM “投喂”规则和指令，引导其正确导航和操作代码库。

Agents.md推荐内容清单：

• 项目概览： 让 AI 知道自己在做什么。
• 构建和测试命令： 让 AI 知道如何验证自己的工作。
• 代码风格指南： 让 AI 知道怎么写才合规。
• 测试指令： 确保质量。
• 安全考量： 避免 AI 写出有漏洞的代码。

AI编程的常见顺序：

1. 用 DeepWiki 读懂代码库。DeepWiki可以自动生成整个仓库的文档、架构图和依赖关系图。
2. 用 Devin 设计架构方案。Devin拥有强大的推理能力。在这个阶段，你把它当作一个资深架构师来咨询，进行可行性验证和头脑风暴。
3. 用 Codemaps 确认具体细节。Codemaps能让你以图形化或结构化的方式快速浏览代码结构，找到具体的函数定义和调用链。
4. 最后在 Windsurf 中结合所有信息，开始真正的规划落地。将DeepWiki生成的文档或Devin的建议，直接引入到你正在使用的本地IDE（Windsurf）中。

当前的工作流大致分为两部分

step1. 异步委派。程序员将任务发给AI写代码。

step2. 同步测试和微调。当前AI生成代码不够完善，或者任务项目等逻辑太复杂，AI无法完全搞定，因此人类需要重新介入，实时验收和修改。

AI编程的未来发展

Why

前面讲到AI编程关键的一点在于同步到异步工作流的转换，当然它不止于表面的技术，更是在强调人的思维模式转变。

异步代理是一项困难但可以学习的技能，但现实中大多数人仍然停留在使用同步代理的阶段。传统开发中，资深程序员习惯于“自己动手，丰衣足食”，因为自己写代码往往比教别人（或教AI）写更快、更可控。当你不擅长或者需要花时间朝着陌生领域学会如何“正确的管理”AI时，会存在一种焦虑的心理状态。而且异步和同步的思维方式本质是不同的，同步模式是线性的、单线程的，大脑只需要处理当前的一个上下文，很符合直觉；异步模式要求开发者具备多线程处理能力。要求开发者能在极短时间内完成不同任务的上下文切换。

注意其中要忌讳的是一个半异步的尴尬的中间地带。如果你是在同步写代码，AI思考的时间过长容易打断心流，但如果你是异步写代码，AI思考的时间太短让你无法切换到另一个任务，夹在其中的效率是最低的。所以当你发现自己在等一个“不长不短”的任务时，要么优化指令让它变快（回归同步），要么给它派一个更大的任务让它跑得久一点（进入异步），从而让你自己解放出来。

How

当前理想的AI增强型软件开发工作流为：

在规划（Planning）和测试（Testing）这两个需要高度智慧和判断力的环节，人类保持同步介入，确保方向正确和质量达标。在最耗时、最机械的编码（Coding）环节，AI异步执行，释放人类的时间。

1

planning sync --- coding async --- testing sync

对于未来的期望应该是

• 人类工程师作为代理管理者

  利用同步工具解决最困难的问题，利用异步工具实现10倍杠杆效应

• 未来需要的宝贵技能

  委派与多线程处理能力；代码阅读能力；规划、范围界定、架构设计

上下文工程

失控的上下文

一般来说，较长的上下文可以让模型对我们的需求了解更多，模型效果会更好。但实际上，当上下文过于超出时，会导致智能体和应用程序出现意想不到的故障。上下文可能会变得混乱、分散注意力、令人困惑或相互冲突。这对依赖上下文来收集信息、综合分析结果和协调行动的智能体来说尤其成问题。常见的失控方式有以下几种：

语境中毒

幻觉或其他错误进入语境，并在语境中被反复提及。

情境的许多部分（目标、总结）都被关于博弈状态的错误信息“污染”了，而这种污染往往需要很长时间才能消除。结果，模型可能会执着于实现不可能或无关的目标。

情景干扰

上下文发展到一定程度，导致模型过度关注上下文，而忽略了训练期间学到的内容。

随着模型收集更多信息并建立历史记录——这些累积的上下文可能会变得分散注意力而非有所帮助。当上下文数量显著超过 10 万个词元时，智能体倾向于重复其庞大历史记录中已有的操作，而不是生成新的方案。

语境混淆

模型使用上下文中的冗余内容来生成低质量的响应。

如果你把某些信息放入上下文中，模型就必须关注它。这些信息可能无关紧要，也可能是不必要的工具定义，但模型都会将其考虑在内。大型模型，尤其是推理模型，在忽略或舍弃冗余上下文方面做得越来越好，但我们仍然不断看到无用信息让智能体犯错。

语境冲突

你在你的环境中积累了新的信息和工具，而这些信息和工具与环境中的其他信息相冲突。

模型在掌握所有信息之前尝试回答问题的早期结果。这些错误答案会保留在上下文中，并在模型生成最终答案时对其产生影响。LLM（逻辑推理能力强的人）在对话初期常常做出假设，并过早地试图得出最终解决方案，而他们又过度依赖这些解决方案。简而言之，我们发现，当LLM在对话中走错方向时，他们就会迷失方向，并且无法挽回。

面向编码代理的高级上下文工程

在实际生产中，代码库通常是非常巨大的，此时AI工具的使用甚至会降低生产效率，但更好的上下文工程可以尝试解决这个问题。

上下文窗口是控制 AI 输出质量的唯一杠杆。盲目对话会让搜索日志、代码片段等杂讯迅速填满窗口，导致模型迷失；解决方案是频繁有意压缩（Frequent Intentional Compaction）——通过"研究→规划→实现"的分段工作流，将中间产物蒸馏为结构化文档，主动将上下文利用率维持在 40-60%，确保每次交互都输入高信噪比的信息。

围绕上下文窗口的工程实践，本质是把人类审查的杠杆点前移：与其在实现阶段逐行审查代码，不如在研究与规划阶段确保上下文输入的准确性与完整性。因为一行错误的研究结论可能衍生千行错误代码，而精准的上下文管理能让今天的模型在复杂代码库中同样产出高质量、可维护的代码。

Anthropic工具设计原则

1.构建精心设计的工具。一些工具仅仅封装了现有的软件功能或API接口——无论这些工具是否适合智能体。以通讯录为例，您可以选择实现一个search_contacts或多个message_contact工具，而不是一个单一的list_contacts工具。确保你开发的每个工具都有清晰明确的用途。工具应该使智能体能够像人类一样，在拥有相同底层资源的情况下，细分并解决任务，同时减少中间输出所消耗的上下文信息。

2.为工具进行合适的命名。MCP 客户端有时默认启用此功能。例如，按服务（例如，Service、asana_search``Resource jira_search）和按资源（例如，Resource、asana_projects_search``Service asana_users_search）对工具进行命名空间划分，可以帮助客服人员在合适的时间选择合适的工具。

3.工具中返回有意义的上下文。工具实现应注意仅向智能体返回高信号信息。它们应优先考虑上下文相关性而非灵活性，并避免使用底层技术标识符（例如：uuid、、）。智能体处理自然语言名称、术语或标识符的效果往往要好得多。

4.优化工具的响应。优化上下文质量固然重要，但优化工具响应中返回给智能体的上下文数量也同样重要，过于长的响应会导致占用过多的上下文。

5.仔细编写工具描述和规范，方便在导入上下文之后被智能体所理解。

Assignment

cs146s/week3·基于高德地图天气 API 的 MCP (Model Context Protocol) 服务器，支持 STDIO 和 HTTP 两种运行模式。