上个月我干了一件挺轴的事：把Claude Sonnet 4.6硬塞进自己的日常C#开发流程，整整两周。目标很明确——不是找什么银弹，就是想看看这玩意儿能不能真帮上忙。我们的代码库是个典型的"祖传项目"：.NET 6 Web API，正在往.NET 9迁，C# 10语法混着各种历史包袱。
团队之前也玩过AI工具，Copilot、GPT-4o写文档都试过。但我这次想测点更实在的：重构和调试现有代码。尤其是那些让人头疼的LINQ查询，还有Visual Studio 2026里时不时冒出来的异步死锁。说白了，我想要的是新鲜视角，不是更智能的自动补全。
说实话，我原本没抱太高期待。C# 10的语法细节，加上我们业务的特定领域知识，我以为Sonnet 4.6会栽跟头。结果它经常在上下文理解上给我惊喜。最开始我只贴小段孤立函数，效果一般。真正的转折点是我开始扔整份.cs文件进去，甚至成对的服务和接口一起喂。感觉MCP（模型上下文协议）确实帮它构建了更丰富的内部模型。
举个例子。我们有个ProductRepository.cs里的LINQ查询，性能瓶颈卡了很久。我把整份文件贴给Claude，prompt很简单：重构GetFilteredProductsAsync方法，让它更高效、更易读，多条件过滤考虑用IQueryable动态构建。它的回应不是简单的Where clause堆砌，而是真正理解了意图——建议用AsQueryable()打底，链式拼接多个Where和Select，还主动提议Include一个相关实体。这个Include从方法签名里根本看不出来，但它从文件上下文里推断出来了。
当然也不是一次到位。Select投影我调了好几轮才完全符合需求。但方向是对的，省了我大量查文档和试错的功夫。这种"理解业务上下文"的能力，比单纯语法正确重要得多。
两周下来，我的判断是：Claude Sonnet 4.6在C#代码重构上确实能干活，但有个前提——你得舍得给上下文。 isolated snippet效果平平，整文件甚至多文件投喂才能激活它的真正实力。对于正在维护大型遗留代码库的.NET团队，这算是个务实的帮手，不是替代方案，而是加速理解的杠杆。
热门跟贴