Developer Experience | The .NET Blog

在 Visual Studio 里面审查 pull request，正是我喜欢的那种减少摩擦

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

浏览器在 code review 工作流中占用了太多太久的比重。

所以我非常高兴看到 Visual Studio 继续向 在 IDE 内端到端审查 pull request 迈进。

这类功能也许不会制造巨大头条，但它确实能改善日常开发体验。

主要价值很简单：更少的 context switching

当你的 review loop 一部分在 IDE 里，一部分在浏览器里时，摩擦就会累积：

在别处打开 PR
用一个工具检查变更
回到 solution 深入调查
再切一次去评论或批准

这不算灾难，只是效率不高。

如果 Visual Studio 能让你在同一个工作环境里打开、检查、评论、批准并 merge，这就是真正的生产力提升。

“不 checkout 就 review” 这个选项尤其好

我特别喜欢的一点，是可以在不 checkout PR 分支的情况下进行 review。

这听起来很小，但它特别适合：

快速 review pass
被打断时收到的反馈请求
保持当前分支和本地状态不变

这正是优秀 code review 工具需要的灵活性。

我的看法

这不是一个革命性的功能。

它更好：它很实用。

对于大部分时间都待在 Visual Studio 里的团队来说，更紧密的 PR review 支持意味着更少的 workflow 中断，以及从检查到行动更顺畅的路径。

在我看来，这样的改进很值得。

原文：无需离开 Visual Studio 即可审查 pull request

智能体框架之所以重要，是因为提示词本身还不够

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

智能体开发中最容易犯的错误之一，就是以为提示词就是产品本身。

其实不是。

新的 agent harness 和 claw 实践教程来自 Microsoft Agent Framework 团队，它的价值在于将焦点保持在真正决定智能体是否好用的部分上：模型的运行时外壳。

这包括：

工具
规划
会话状态
记忆
执行模式
可用的控制台或迭代交互界面

正是这些让智能体从巧妙的演示变成真正的软件。

Harness 模式是一种实用的模式

我欣赏的是这个想法多么平易近人。

从一个聊天客户端开始。

然后将其包裹到带有指令和工具的 harness 中。

然后通过支持规划、待办事项、会话和流式交互的 shell 来运行它。

这是一个健康的模式，因为它清晰地区分了关注点：

模型负责推理
harness 负责运行时行为
应用决定哪些工具和体验是重要的

这非常契合 .NET 开发者的构建方式

Harness 的概念也与 .NET 的思维方式完美匹配。

当运行时行为是显式的且可组合时，我们通常能做得更好。中间件、管道、选项、提供者和适配器在这个世界中都感觉很自然。

这就是为什么我认为 Agent Framework 有很大机会在 .NET 开发者中落地。它没有强迫每个人都进入一个神奇的抽象层，而是提供了你可以组合在一起的结构化运行时组件。

我的看法

这篇文章最有用的部分在于提醒我们，智能体需要的不仅仅是好的模型和巧妙的指令字符串。

它们需要一个提供结构、记忆、工具访问、规划以及可工作的开发者循环的运行时外壳。

这就是 harness 给你的。

老实说，这就是为什么这个模式值得关注。

原文：Meet your agent harness and claw

VS Code 中的 Aspire 13.4 以恰到好处的方式收紧了开发者循环

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

最好的工具更新是那些用了几天后就能感受到的，而不是那些只在发布说明中看起来不错的。

这就是我对 VS Code 中的 Aspire 13.4 的感受。

这次更新全部关于收紧内循环：更快地创建项目、更自然地调试混合语言资源、直接在编辑器中显示健康状态和命令、保持仪表盘触手可及但又不让它成为唯一的工作空间。

这是一个非常好的方向。

最大的胜利是减少上下文切换

如果你认真使用 Aspire，你通常需要在多个界面之间切换：

AppHost 代码
终端
仪表盘
日志
调试会话
服务端点

13.4 做得好的地方在于减少了这些界面之间的摩擦。

新的 VS Code 体验让你在你已经在工作的地方就能看到更多的应用状态：

编辑器中的资源健康状态
资源声明旁边的命令
更便捷的仪表盘访问
从 AppHost 上下文中访问日志
即使在完整调试开始之前也有用的面板

这听起来很小，直到你每天都要用到它。

混合栈调试比人们想象的更重要

这次更新中最强大的部分之一，是在一个 Aspire 驱动的流程中更自然地调试 C#、TypeScript、Python、Go、浏览器应用和 Azure Functions。

这反映了现代应用的真实形态，远好于假装所有东西都运行在同一个运行时中。

对 .NET 开发者来说尤其有价值，因为我们中的许多人现在正在构建混合 API 项目、前端、工作进程和不同语言的 AI 相关服务的系统。

Aspire 在 VS Code 内部让这一切感觉更统一，是一个非常实际的改进。

TypeScript AppHost 支持达到 GA 也很有意义

我不会忽视该版本中的 TypeScript AppHost 方面。

Aspire 对 C# 和 TypeScript 都变得更加自然，扩大了可以在同一系统模型中工作的人员范围，而无需奇怪的一等公民处理方式。这对于平台代码、前端代码和服务编排紧密共存的团队来说很重要。

我的看法

VS Code 中的 Aspire 13.4 不是关于一个杀手级功能。它关于打磨日常开发循环中的粗糙边缘：

更快地启动
在你写代码的地方看到更多状态
更自然地调试
只在需要时才跳转到日志和仪表盘

这正是好的工具应有的演进方式。

如果你已经在使用 Aspire，这次更新值得安装。如果你还在犹豫 VS Code 是否是 Aspire 开发的可靠环境，答案正变得越来越明显。

原文：Aspire in VS Code: the 13.4 developer loop

Visual Studio 中的新 Plan agent 解决了一个非常真实的 AI 工作流问题

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

最让人沮丧的 AI 编码工作流之一，就是实现开始得太快。

代码从技术上说甚至可能没错，但它解决的是你脑海里那个问题的错误版本。

你想要的是 refactor，它却开始 rewrite。你想要的是一个范围明确的改进，它却碰到了项目的一半。你想讨论选项，它却直接跳到了文件修改。

这就是为什么 Visual Studio 中这个新的 Plan agent 如此有用。

这解决的是一个真实的工作流问题，而不只是表面问题

原文描述了一个非常熟悉的场景："代码并不错……只是它不是你想要的。"

这句话非常准确。

因为很多 AI-assisted development 的薄弱点，不在于模型能不能生成代码，而在于工作流是否在实现开始之前，为就工作的预期形态达成一致提供了足够空间。

这对以下情况尤其重要：

大型功能
不熟悉的 codebase
非平凡的 refactor
对架构敏感的变更
在开始编辑之前需要团队 review 的工作

在这些场景里，直接跳到实现通常是错误的做法。

当任务是真实需求时，planning 不是 overhead

我觉得团队有时会低估，过早开始实现会浪费多少时间。

如果 agent：

触碰了错误的 file
选择了错误的方法
漏掉了关键约束
忽略了必要的 edge case

那么所谓“快速”的开始，最终会变成一个更慢的整体 workflow。

这就是我喜欢这个功能的原因。

它为以下内容留出了空间：

澄清问题
起草计划
直接编辑计划
在代码更改开始前分享计划

这不是 bureaucracy。很多时候它只是好的 engineering。

markdown plan file 是一个聪明的选择

我特别喜欢的一点是，每个 plan 都会保存到 .copilot/plans/plan-{title}.md。

这让 planning 步骤变得可触摸。

也就是说，plan 不会被困在 chat transcript 里。它会变成你可以：

review
edit
mentally version 管理
与队友讨论
更有意识地交给 implementation

这让这个功能感觉比“生成代码前的一段临时前言”要严肃得多。

这就是 AI workflow 开始尊重团队流程的地方

我认为这也是这些工具正在成熟的一个强烈信号。

最好的 AI developer workflow 不是把所有中间步骤都去掉，而是改进正确的中间步骤。

而 planning 就是其中之一。

如果 plan 足够强，implementation 就更容易。如果 plan 很弱，implementation 就会变得嘈杂。

这个功能直接承认了这一点。

我的看法

这不只是一个 AI nicety。

这是 workflow 改进。

对于真实的功能和真实的 refactor 来说，这正是那种可以节省大量不必要 churn、review noise，以及“这不是我想表达的意思”式 rework 的改进。

我认为，越来越多的 agent experience 最终都会需要类似的东西。

Visual Studio 更早地做到这一点，而且方式很实用。

原文：在构建前先规划：介绍 Visual Studio 中的 Plan agent

你的 dev loop 里充满了隐性知识，而 Aspire 给出了正确的回应

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

这可能是理解 Aspire 为什么 重要的最关键文章之一。

不是因为它宣布了什么惊人的新功能。

而是因为它点出了一个几乎每个工程团队都感受到、但并非每个团队都能很好表达的问题：

dev loop 里充满了隐性知识。

这句话之所以有分量，是因为它是真的。

问题不是缺工具

原文的核心论点非常好：团队通常并不缺基础设施、脚本、仪表板或命令。

他们缺的是一个连贯的模型，能把围绕应用的隐藏运维知识变成可见且可重复的东西。

很多应用的真实架构存在于：

shell history
分散的脚本
README 片段
Slack threads
那位唯一知道操作顺序的资深工程师

这对人类来说不是可持续的 dev loop。

对 agent 来说更不是。

我认为能概括整篇文章的引用

原文里有一句话，我觉得非常准确地抓住了整篇文章的主旨：

“应用本来就以系统的形式存在。Aspire 让这些系统显性化，因为显性系统比隐性知识更容易扩展。”

这一句话就是全部论点。

说实话，这是我目前见过最强的 Aspire 一句话解释之一。

为什么这比一年前更重要

我认为这篇文章在当前时点特别贴切，因为 AI-assisted development 改变了歧义的成本。

人类可以非常好地弥补不完整的系统。

我们会记住：

先运行哪个 script
哪个 environment variable 是偷偷需要的
哪个 terminal 通常会显示有用的 logs
因为没人写文档，所以哪个 service 需要重启两次

agent 在这种隐藏的运维 folklore 上要差得多。

所以，如果我们希望 agent 真正在真实 repository 里变得有用，就必须让系统更显性，而不是更隐晦。

这就是为什么我觉得 Aspire 的这种 framing 很重要。

Aspire 的真正价值不只是 orchestration

理解 Aspire 时一个常见错误，是把它只看成分布式应用启动器或本地 orchestration helper。

这个视角太小了。

更强的 value proposition 是，Aspire 给应用提供：

一个 model
一个 shape
命名的 resources
显式 dependencies
health 和 operations surface
人和 automation 都能理解的 commands

这比很多人意识到的更能改变 dev loop。

因为一旦 app 不再是一堆隐性的 conventions，而变成一个拥有真实 model 的 system，很多事情会同时变简单：

onboarding
debugging
可重复的 setup
CI 一致性
AI-assisted workflows

这是一项设计决策带来的巨大杠杆。

我特别喜欢 “commands 作为一等操作” 这个角度

原文中另一个我认为应该得到更多关注的点，是从 README instructions 转向与资源绑定的 commands。

这是一个看起来不大、其实很大的变化。

与其说：

先运行这个 script，再运行那个，如果前一个失败了也许还要运行另一个

不如直接在 app context 里建模 operations。

这意味着人类更容易发现它们。

也意味着 agent 不必从 prose 里猜 intent。

这正是把一个应用从“如果你已经知道它就能操作”变成“按设计就能操作”的那种东西。

如果我是 team lead，我会从中得到什么

如果我用这个视角看自己团队的 dev loop，我会问几个直接的问题：

我们有多少 setup 依赖记忆？
有多少关键 dev actions 只存在于 docs 或 chat threads 中？
新 contributor 因为看不见的 system behavior 被卡住的频率有多高？
automation tool 或 coding agent 能不能只凭 repo 理解我们的 app topology？

如果最后一个问题的答案是“完全不行”，那这篇文章就会准确地碰到一个有用的痛点。

我的看法

这是对 Aspire 真实价值的一个非常强的 framing。

它不只是 orchestration。

它是在把 application model 做得足够显性，从而让系统更容易运维、理解和自动化。

这对人很重要。对团队很重要。而且随着现代开发越来越转向 agent-assisted workflows，它变得更加重要。

这正是那种能帮助解释为什么 Aspire 会越来越像一个超越 .NET marketing label 的相关技术的文章。

原文：你的 dev loop 里充满了隐性知识

Aspire 的 hermetic 端到端测试是更多团队应该采用的模式

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

脆弱的端到端测试代价很高，而且这种代价并不总能在仪表板上直接看出来。

它们不只是失败那么简单。它们会慢慢训练团队不再信任反馈循环。

这就是为什么这篇关于 Azure Chaos Studio + Aspire 的文章一开始就吸引了我。它不是那种光鲜的产品公告，而是一则非常扎实的工程故事，讲的是如何让端到端测试不再像是在和运气讨价还价。

说实话，我认为更多团队都应该采用这个模式。

核心思路很简单，但收益非常大

关键做法是给每个测试分配自己的 hermetic、临时环境，包含真实服务、真实依赖，以及基于健康状态的明确启动。

一句话读起来很自然，但在真实系统里要做到这一点难得多，尤其当云依赖、共享环境和分布式服务都参与进来时。

原文把问题说得非常清楚：共享测试环境会带来 “cross-talk、flaky behavior，以及 ‘谁把 staging 搞坏了？’ 之类的群聊消息"，而这就是它的运营成本。

这句话之所以好笑，是因为它太真实了。

太多团队把这种交换当成了正常情况。我不认为他们应该这样。

为什么这个模式不只是影响测试

我最喜欢这篇文章的一点是，它并不只是说：“我们让测试更可靠了”。

它实际上在说更大的事情：

如果你的分布式系统难以复现、难以隔离、也难以验证，那么整个工程循环都会变慢。

这影响的不只是 CI。

它还会影响：

开发者做 refactor 时有多自信
regression 被诊断得有多快
更大的架构变更能否安全尝试
团队对自动化验证的信任程度

而在 2026 年，这也会影响 AI 辅助开发能变得多有用。

文章里最重要的一句话

文中有一句我觉得值得反复引用：

“Agent 不需要完美。它们需要可验证。”

这个 framing 很棒。

人们花很多时间讨论 AI coding agent 是否足够可靠，能否帮上非平凡的工作。我认为更好的问题是：我们的系统是否足够可测试，能够正确评估这项工作。

如果一个 agent 提出了有意义的 refactor，而你唯一的安全信号只是一堆脆弱、半随机、在共享环境里运行的端到端检查，那么问题不只在 agent 身上。

问题在于你的验证模型。

这个 Aspire 模式会大幅改善这一点。

这个实现为什么特别好

原文中的几个部分让它远不只是一个“我们改进了测试”的泛泛帖子。

1. 真实的服务图，而不是假的 mock 戏剧

这些测试不是建立在一堆互不相干的 mock 上，假装它们是端到端验证。

它们运行 真实二进制，在可能的地方连接 emulator，并使用和本地开发相同的 application model。

这很重要。

因为一旦端到端测试变成 mock 对 mock 的戏剧，它们就不再能告诉你有关真实组合的可靠信息了。

2. 基于健康状态的启动，而不是魔法式 sleep

这一点比看起来更重要。

文章明确指出，测试会用 WaitForResourceHealthyAsync 等待真实 health，而不是依赖任意的时间猜测。

差别非常大。

一个说“睡 30 秒然后祈祷最好”的测试 suite，本质上是在记录不确定性。而等待真实 readiness 的 suite，则是在记录系统意图。

3. 同一个 model 同时驱动本地开发和测试

这一点我很喜欢，因为它和 Aspire 最强的那些故事非常契合。

同一个 application model 驱动：

本地开发
服务 wiring
模拟的依赖
health checks
hermetic 测试编排

这会减少 drift，而 drift 是最安静的信任杀手之一。

这种 devex 投入常常被低估

我想让这篇文章比一条快速反应更长，原因之一就是我觉得这种工程改进经常被低估。

它们不炫目。

它们不像新 AI 功能那样适合演示。

也不一定会产出一张能让高层兴奋的幻灯片。

但随着时间推移，它们会创造出更有价值的东西：一个能够更快行动、却不会对质量自欺欺人的团队。

这很重要。

文章说他们现在运行大约 90 个 hermetic 测试，其中包括 zone outage、DNS failure 和 geo-replication failure 之类的场景。这不只是更好的 test hygiene，而是分布式平台更强的信任模型。

如果我在运营一个分布式 .NET 系统，我会从这里带走什么

如果你今天在处理分布式服务、Aspire 和 CI/CD pipeline，我会立刻带走这些：

不要再把共享环境里的 flaky behavior 当成正常现象
尽可能转向 health-based startup gate
把 AppHost 当成真正的 production-grade orchestration code
构建能够验证服务组合、而不只是单个服务正确性的 end-to-end check
如果你正在采用 AI 辅助开发，先投资于 checkability，再去追求更广泛的自动化

最后这一点，我认为更多团队需要听到。

我的看法

这是这一批里最强的 Aspire 文章之一，因为它解决的是一个非常实际的问题。

它不是想用抽象概念来打动你，而是展示如何让 end-to-end 测试在真实分布式系统里变得更确定、更有用、也更值得信赖。

一旦你看到它和 agent 辅助开发之间的联系，这个模式就更有说服力了。

如果你的 end-to-end 测试故事仍然依赖共享环境、隐藏的 setup 知识和一点祈祷，那么这篇文章真的很值得研究。

原文：How Azure Chaos Studio ships with hermetic Aspire end-to-end tests