泥潭日报 uscardforum · 每日精选

【突发】微软内部突然大范围启用Anthropic Claude Code

内容摘要

帖子标题 【突发】微软内部突然大范围启用Anthropic Claude Code

帖子ID

480515

============================================================================== [旧摘要 - 已被纳入的内容] ============================================================================== 微软内部大范围启用Anthropic Claude Code引发对GitHub Copilot替代的讨论,焦点转向Anthropic模型在Agent生态中的潜在主导地位,有内部员工指出此举旨在收集反馈,用户反馈Claude Code体验波动,并预言Anthropic将取代OpenAI成为硅谷焦点。新增回复担忧AI工具的引入可能导致“配置文件屎山”的出现,暗示工具的迭代可能带来新的技术债务和管理问题,偏离了解决核心问题的初衷。

1. 关键信息

  • (之前已归纳) 微软内部已广泛采用Claude Code进行编程和原型设计,并鼓励非专业开发者使用,此举并非“突然”,而是一段时间的推行。
  • (之前已归纳) 多个用户反馈GitHub Copilot体验不佳,认为其功能有限,不如Claude Code。
  • (之前已归纳) 微软内部员工(vczh)透露,使用Claude Code旨在收集反馈数据以改进Copilot,但日常仍推荐使用Copilot,因Claude Code成本较高。
  • (之前已归纳) 有观点认为Claude Code(或Anthropic模型)在Agent工作模式上表现更优。
  • (之前已归纳) 有用户“预言”Anthropic将在一年内取代OpenAI成为硅谷焦点,未来Agent生态将围绕Anthropic构建。
  • (之前已归纳) 微软(“果子”)已从自家FM、Gemini转向CC,显示出对AI工具选择的动态调整,但to C端仍看好Gemini。
  • (之前已归纳) 有用户反馈Claude Code“最近没那么好用”,体验存在波动。
  • (之前已归纳) 有用户担忧AI工具(如Claude Code)的引入可能导致“配置文件屎山”的出现,暗示工具迭代可能带来新的技术债务,偏离解决核心问题的初衷。
  • (之前已归纳) 用户询问Claude 4.5 Opus版本的必要性,并对高昂的token费用表示担忧。
  • (之前已归纳) vczh指出Claude 4.6版本表现良好,但强调强大的基础设施同样能使Copilot发挥同等效果。
  • (之前已归纳) vczh强调公司购买的Claude tokens成本高昂,一分钟可消耗一美元,远超Copilot数小时的使用成本。
  • (之前已归纳) vczh建议个人用户在下班后使用Claude时需谨慎,并给出了一个具体的论坛内容总结任务示例,强调分析、联系上下文、理解黑话以及输出的简短性、信息量和细节。
  • 新增 (来自第62楼): vczh认为Claude 4.6模型表现良好,但强调强大的基础设施同样能使Copilot发挥出与Claude 4.6同等的效果。
  • 新增 (来自第62楼): vczh指出公司购买的Claude tokens成本高昂,一分钟可消耗一美元,这足够他用Copilot跑几个小时,暗示了模型在成本效益上的巨大差异。
  • 新增 (来自第62楼): vczh给出了一个详细的论坛内容总结任务示例,要求AI助手进行分析、联系上下文、理解黑话,并输出简短、信息量大且包含细节的内容,特别强调了在信用卡、购物折扣等领域,总结应更加简短。
  • 新增 (来自第66楼): vczh认为Copilot在某些方面(如“opus 4.6的意思”)可以与Claude相媲美,并暗示人类的智慧应能理解AI工具的潜在能力,无需过度解释。
  • 新增 (来自第68楼): “收束观测者”引用vczh的回答,并对“4.6 怎么样 有必要一定用opus吗 token太贵了”的提问进行了解释,核心观点是“没必要一定用 Opus”。其逻辑包括:性价比极低(一分钟一美元的token消耗对比Copilot的成本悬殊),基建决定上限(优化工程实践能让Copilot达到同样效果),以及模型同质化(Copilot调用的模型与Opus接口底层逻辑一致)。
  • 新增 (来自第69楼): vczh针对“收束观测者”的总结,指出其理解存在偏差,并进一步解释了“同一个模型”的含义:GitHub Copilot已接入Claude Opus 4.6模型,两者底层算力模型一致。他强调了直接使用官方API按token计费的成本高昂,而Copilot的订阅制/配额机制能平摊成本,使其性价比更高。vczh重申,只要“基建”(Prompt工程、上下文管理、工作流设计等)完善,通过Copilot就能发挥Opus 4.6的强大实力。

2. 羊毛/优惠信息

  • (之前已归纳) 无
  • 新增 (来自第62楼): 无
  • 新增 (来自第66楼): 无

3. 最新动态

  • (之前已归纳) 微软内部正在推行使用Claude Code收集反馈,以期改进Copilot。
  • (之前已归纳) 帖子引用外部文章指出,Copilot在企业中的表现令人失望。
  • (之前已归纳) 讨论焦点正转向Anthropic在Agent生态中的主导地位预测,以及其面临的资本投入与回报的悖论。
  • (之前已归纳) 讨论中出现了对AI工具引入后可能产生“配置文件屎山”的担忧,反映出对技术选型长期影响的审视。
  • (之前已归纳) 关于Claude 4.5 Opus版本的使用价值和成本效益的讨论。
  • (之前已归纳) vczh对Claude 4.6版本的评价以及对当前AI工具成本效益的对比分析。
  • 新增 (来自第62楼): vczh的言论表明,Claude 4.6模型本身表现良好,但其成本效益是关键考量因素。
  • 新增 (来自第66楼): vczh暗示Copilot在功能上已能达到或接近Claude 4.6的水平。
  • 新增 (来自第68楼): “收束观测者”对vczh关于“没必要一定用Opus”的观点进行了详细解读,强调了成本效益和工程实践的重要性。
  • 新增 (来自第69楼): vczh进一步澄清了Copilot与Opus 4.6模型的关系,指出Copilot通过订阅制提供了更经济的Opus 4.6使用方式。

4. 争议或不同意见

  • (之前已归纳) 有用户质疑微软研究院的进展。
  • (之前已归纳) 有用户认为Copilot使用不当是体验差的原因,建议分步操作。
  • (之前已归纳) 对Anthropic未来发展路径(资本悖论)的预测性观点。
  • (之前已归纳) 对Claude Code近期体验下降的直观感受。
  • (之前已归纳) 核心争议点之一是工具的引入是否会带来新的技术债务(如“配置文件屎山”),而非真正解决问题。
  • (之前已归纳) 对Claude 4.5 Opus版本是否是唯一选择以及其成本效益的质疑。
  • (之前已归纳) vczh认为,尽管Claude 4.6表现不错,但强大的基础设施同样能让Copilot达到同等效果,暗示了对工具本身优越性的相对淡化,更侧重于底层支撑。
  • (之前已归纳) vczh对Claude高昂的token费用提出了明确的成本效益质疑,并将其与Copilot的使用成本进行了对比。
  • 新增 (来自第66楼): vczh的观点表明,Copilot在功能上已能与Claude媲美,这可能引发关于Copilot是否能满足高级需求的讨论,以及对“人类智慧”在AI协作中作用的思考。
  • 新增 (来自第68楼): “收束观测者”的解读强调了“没必要一定用Opus”,这与部分用户可能认为Opus是最佳选择的观点形成对比。
  • 新增 (来自第69楼): vczh明确指出“收束观测者”的理解有误,并强调了Copilot的成本效益优势,这可能引发关于AI模型使用方式和成本控制的进一步讨论。

5. 行动建议

  • (之前已归纳) 开发者应关注Claude Code及其背后的模型(如Claude 4.5)在Agent开发中的表现。
  • (之前已归纳) 微软员工应积极利用Claude Code提供反馈以帮助改进Copilot。
  • (之前已归纳) 关注Anthropic在Agent生态中的发展,以及其潜在的资本化挑战。
  • (之前已归纳) 开发者在采纳新AI工具时,需警惕工具迭代可能带来的管理和技术债务问题。
  • (之前已归纳) 在使用Claude Code时,权衡Opus版本的高成本与实际收益,考虑是否有更经济的替代方案。
  • (之前已归纳) vczh的发言暗示,对于有良好基础设施支持的团队,应优先考虑通过优化基础设施来提升Copilot的效能,而非盲目追求最新、最贵的AI模型。
  • (之前已归纳) 个人用户在使用Claude时,需仔细评估其成本与任务需求,特别是对于非核心业务或成本敏感的任务,应谨慎选择。
  • (之前已归纳) vczh提供了一个具体的论坛内容总结任务示例,为用户如何有效利用AI工具(特别是理解和分析特定领域内容)提供了操作指导。
  • 新增 (来自第62楼): 个人用户在下班后使用Claude时需谨慎,并注意评估任务的成本效益。
  • 新增 (来自第66楼): 关注Copilot在功能上与Claude 4.6的对标情况,并根据自身需求和基础设施能力,权衡使用成本和效能。
  • 新增 (来自第68楼): 建议通过优化“基建”(Prompt工程、上下文管理、工作流设计等)来提升廉价模型(如Copilot)的效果,而非盲目追求昂贵的Opus模型。
  • 新增 (来自第69楼): 强调了通过GitHub Copilot使用Claude Opus 4.6模型是更具成本效益的选择,前提是完善好本地代码库上下文、提示词规范和Agent环境等工程化设置。
原始内容
--- 第 1 楼来自 IrishCoffee 的回复 (2026-02-02 14:11:35 PST) ---

微软内部突然大范围启用Anthropic Claude Code

Anon84

about 10 hours ago

439

微软正在内部广泛采用Anthropic的Claude Code,取代GitHub Copilot。开发人员和非技术人员都被鼓励使用Claude Code进行编程和原型设计。这表明Claude Code在易用性和功能上表现出色,微软对其有高度认可。这一转变不仅影响开发者团队,还扩展到Windows和Microsoft 365等核心产品线。

“微软现在鼓励其数千名员工,尤其是最活跃的团队成员,使用Claude Code进行编程,即使他们不是专业的开发者。”

人工点评:

没想到Claude Code拿下苹果后微软也接纳了,不知道copilot团队干什么吃的。。赶了个大早。

--- 第 2 楼来自 IrishCoffee 的回复 (2026-02-02 14:12:09 PST) ---

相关阅读

AI两极分化:微软Copilot为何落后

martinald

about 22 hours ago

297

文章揭示了AI用户之间的巨大差异,分为‘技术流’和‘聊天流’两大类。作者指出,尽管微软Copilot在企业中广泛使用,但其功能和体验远不及其他更先进的AI工具,如Claude Code。这种技术鸿沟导致了企业内部生产力的显著差异,甚至可能引发决策失误。文章还探讨了企业IT政策如何限制了员工使用更先进的AI工具,进一步加剧了这种分化。

“微软Copilot在企业中的表现令人失望,尽管它拥有巨大的市场份额,却像是一个功能有限的ChatGPT克隆版本,这暴露了他们与先进AI工具之间的巨大差距。”

--- 第 3 楼来自 中美合拍 的回复 (2026-02-02 14:14:21 PST) ---

个人感觉微软的产品,除了VSCode之外没有好用的….(Windows一坨屎,旁边的老哥被Windows系统bug折磨的死去活来,重装系统都没用)有大佬能科普下微软还有什么宝藏吗

--- 第 4 楼来自 joejoejoe123 的回复 (2026-02-02 14:15:17 PST) ---

github copilot啥都有为啥还要单独用claude?而且也没收到这种邮件

image814×1393 68 KB

--- 第 5 楼来自 CB2 的回复 (2026-02-02 14:16:17 PST) ---

copilot比cc难用多了,而且很容易出现那种删了你的test就不会报错的傻逼情况

--- 第 6 楼来自 YCShing 的回复 (2026-02-02 14:16:43 PST) ---

现在才启用吗

反正在Meta,应该没人不用吧 内部甚至有post讨论怎么样设置更好的skill啥的

--- 第 7 楼来自 marszoom 的回复 (2026-02-02 14:19:48 PST) ---

不是llm 而是system prompt和其他插件的区别

--- 第 8 楼来自 deng 的回复 (2026-02-02 14:21:41 PST) ---

模型是一样的 使用的工具不一样会有很大差别 cc的工作模式是更加纯粹的agent

--- 第 9 楼来自 otonoco 的回复 (2026-02-02 14:25:15 PST) ---

haiku是hayaku的缩写吗

--- 第 10 楼来自 otonoco 的回复 (2026-02-02 14:25:47 PST) ---

【引用自 中美合拍】:
宝藏
vczh

--- 第 11 楼来自 flywire 的回复 (2026-02-02 14:26:43 PST) ---

微软是印度公司

--- 第 12 楼来自 v_v 的回复 (2026-02-02 14:27:36 PST) ---

onedrive

--- 第 13 楼来自 中美合拍 的回复 (2026-02-02 14:30:13 PST) ---

如果收费那就是屎中屎 onedrive配合Microsoft的网页版支持能力一坨大便,有些软件网页版功能居然能和桌面版截然不同;当然如果免费的1TB单纯存储,那我没话说的支持

--- 第 14 楼来自 争取多活两年 的回复 (2026-02-02 14:31:44 PST) ---

没问题啊。说明微软能够认清楚什么是好东西,知耻而后勇。

Bullish。

--- 第 15 楼来自 adddr 的回复 (2026-02-02 14:46:27 PST) ---

一直都是用cc

copilot太垃圾了

--- 第 16 楼来自 争取多活两年 的回复 (2026-02-02 14:47:30 PST) ---

copilot从release我就知道是个傻逼。不得不称赞下本老的taste。

--- 第 17 楼来自 krqw 的回复 (2026-02-02 14:52:55 PST) ---

Haiku是俳句

Cladue三个模型都是艺术类型的名字

--- 第 18 楼来自 Keiour 的回复 (2026-02-02 14:53:13 PST) ---

onedrive天天出现登录bug登不上去需要退了清cookie重登
【引用自 中美合拍】:
有大佬能科普下微软还有什么宝藏吗
HyperV?今年VMWare开始疯狂加价宰人了,HyperV立刻就变得眉清目秀起来

--- 第 19 楼来自 HelloFox 的回复 (2026-02-02 14:53:40 PST) ---

微软在AI上的进展真是让人失望。不知道研究院养的那帮人是干什么的。

--- 第 20 楼来自 vczh 的回复 (2026-02-02 14:55:20 PST) ---

首先这不突然,已经有一段时间了。其次公司的wiki写的很明白,cc太贵了你们平时还是多用copilot,但是我让你们用这个的主要目的是为了让你们给copilot提feedback,获取宝贵一线数据
【引用自 CB2】:
而且很容易出现那种删了你的test就不会报错的傻逼情况
这还真就是一个你的问题,如果你不要在同一个对话里面做计划+写代码+测试,那在测试的这一步,AI会觉得他在挑别人的错,积极的一笔

--- 第 21 楼来自 争取多活两年 的回复 (2026-02-02 14:56:42 PST) ---

你为什么对大公司研究院有信心。。。

--- 第 22 楼来自 争取多活两年 的回复 (2026-02-02 14:57:07 PST) ---

和本老想的一样啊。贵司CEO不藏拙,靠谱。

--- 第 23 楼来自 Ftndvh 的回复 (2026-02-02 16:14:42 PST) ---

工作就是写agent,我的经验是

不要考虑出了claude4.5以外的其他任何模型

有的选的话不要考虑cc以外的任何框架

除了成本,其他选项没有任何优势

--- 第 24 楼来自 up9080 的回复 (2026-02-02 18:50:39 PST) ---

用什么写呢 ,langchain 还是 vercel 啊。好奇还有纯写 agent 的公司…

--- 第 25 楼来自 LoongIsSmart 的回复 (2026-02-02 18:56:59 PST) ---

Codex 的模型更加谨慎

--- 第 26 楼来自 LoongIsSmart 的回复 (2026-02-02 18:57:29 PST) ---

【引用自 up9080】:
好奇还有纯写 agent 的公司…
next generation of 外包

--- 第 27 楼来自 voltwalker 的回复 (2026-02-02 19:04:53 PST) ---

微软能在国内用算一个吧

--- 第 28 楼来自 marche 的回复 (2026-02-07 17:56:49 PST) ---

Meta都跟上了 FAANG里只剩Google了吧,要是只能用Gemini CLI岂不是掉队了(Gemini coding 水平懂得都懂

--- 第 29 楼来自 dsgrs163 的回复 (2026-02-07 18:10:30 PST) ---

给不懂的讲讲

--- 第 30 楼来自 国泰Pacific 的回复 (2026-02-07 18:15:49 PST) ---

还记得之前有一次正面试呢 电脑突然黑屏更新重启了 重启之后发现电脑自动安装了copilot这个傻卵东西 微软这么强行植入还是没法改变copilot的命运吗

--- 第 31 楼来自 EVA1 的回复 (2026-02-07 18:17:04 PST) ---

Opus呢

--- 第 32 楼来自 Aaronpang 的回复 (2026-02-07 18:28:51 PST) ---

一坨zs

--- 第 34 楼来自 awash 的回复 (2026-02-07 18:44:29 PST) ---

Haiku是俳句

需要五字加七字

还要有季语

如果没季语

就是季节的描写

其实叫川柳

--- 第 36 楼来自 vczh 的回复 (2026-02-07 20:57:05 PST) ---

那你得有好几年没更新了

--- 第 37 楼来自 Yangff 的回复 (2026-02-07 21:25:15 PST) ---

你用VMware workstation其实也还是在用hyperv

--- 第 38 楼来自 IrishCoffee 的回复 (2026-02-07 21:27:26 PST) ---

【引用自 国泰Pacific】:
微软这么强行植入还是没法改变copilot的命运吗
Internet Explorer 了解一下

--- 第 39 楼来自 国泰Pacific 的回复 (2026-02-07 22:06:44 PST) ---

正常用得挺好 更新反而麻烦 把自动更新都关掉了 没想到直接给我来个强制更新 脸都不要了

--- 第 40 楼来自 IrishCoffee 的回复 (2026-02-07 23:41:57 PST) ---

newsletter.semianalysis.com

Claude Code is the Inflection Point

What It Is, How We Use It, Industry Repercussions, Microsoft's Dilemma, Why Anthropic Is Winning

这个文章提到微软的困境

--- 第 41 楼来自 争取多活两年 的回复 (2026-02-09 17:16:52 PST) ---

预言一个人类学取代OAI成为硅谷头号敌人。一年后全是不带人类学玩的agent生态。人类学陷入要解决一个巨大问题需要巨大资本支出但巨大资本支出未必能带来巨大资本回报的悖论。

--- 第 42 楼来自 fishfood 的回复 (2026-02-09 17:27:01 PST) ---

天天review着AI写出来的全是注释的骈文,真是有种这个公司傻逼到极点了的感觉,然后上面还在讨论code review是不是有必要,以后反正AI写的那么快,审也审不完,干脆看metrics都正常就OK了。

真希望来几个SEV0让这些人清醒一下。

--- 第 43 楼来自 gbus 的回复 (2026-02-09 18:57:40 PST) ---

四个AI掉队的公司还是别锐评唯一没掉队的了。cider code agent 在 Gemini 2.5 时代就很成熟了

--- 第 44 楼来自 yczhang 的回复 (2026-02-09 19:15:09 PST) ---

微软只有数千名员工吗?

--- 第 45 楼来自 msft 的回复 (2026-02-09 19:19:34 PST) ---

【引用自 fishfood】:
天天review着AI写出来的全是注释的骈文
“review this pr and post comments to github”

--- 第 46 楼来自 Frankkkkk 的回复 (2026-02-09 19:20:07 PST) ---

Model很重要,但对于这种coding agent来说,更重要的是理解 + 任务拆解 + 项目级上下文;这个需要科研支持,也需要软件上的设计

--- 第 47 楼来自 ayzg 的回复 (2026-02-09 19:21:13 PST) ---

虽然Gemini辣鸡但是狗家不让用别的

--- 第 48 楼来自 msft 的回复 (2026-02-09 19:21:53 PST) ---

【引用自 joejoejoe123】:
github copilot啥都有为啥还要单独用claude
如果copilot是丰田卡罗拉的自适应巡航,claude就是特斯拉的自动驾驶。

--- 第 49 楼来自 marche 的回复 (2026-02-09 19:29:24 PST) ---

前面掉队了才知道改变,连果子都从自己的FM → Gemini → CC一路走来,鱿鱼也不再只让用LLAMA,就狗还抱着Gemini尾大不掉

当然我说的只是内部员工用AI工作的体验,对外to C的我也看好gemini

--- 第 50 楼来自 Edward40 的回复 (2026-02-09 19:39:45 PST) ---

claude code感觉最近没那么好用,不知道是不是错觉

--- 第 51 楼来自 收束观测者 的回复 (2026-02-09 20:03:15 PST) ---

【引用自 争取多活两年】:
人类学取代OAI成为硅谷头号敌人
展开说说呢

哪种意义上的敌人

--- 第 52 楼来自 争取多活两年 的回复 (2026-02-09 20:47:17 PST) ---

OAI上踢谷歌(GPT),下打脸书(SORA),中间还要恶习下苹果(硬件),顺便再做个shopping把亚麻也颠覆了。俨然整个SV只需要他一个2C的公司。估值1T显然是奔着颠覆这些巨头来的。

现在人类学也差不多吧。没事儿做个feature直接把SaaS干掉几个T的市值,俨然整个SV只需要他一个2B的公司,别的公司直接被干成traditional business了。

--- 第 53 楼来自 TrashGeGe 的回复 (2026-02-09 20:50:44 PST) ---

OAI的产品能力和买它一个档次,发家之后做的东西都是做一个黄一个。只能看买的那些有没有宝贝了。

--- 第 54 楼来自 争取多活两年 的回复 (2026-02-09 20:51:15 PST) ---

【引用自 未知】:
因为谷歌在AI竞争中赶上,Open AI 宣布‘代码红‘ 搬砖
伯格恨死奥特曼了吧,硅谷最垃圾股要换人了。

--- 第 55 楼来自 TrashGeGe 的回复 (2026-02-09 20:55:54 PST) ---

有一说一,google 20亿把noam买回来力挽狂澜。OAI的CPO找了个垃圾Ins的二流PM Kevin现在都被demote成vp了。Anthropic的toC其实最近也在增长的不错估计Mike。

--- 第 56 楼来自 收束观测者 的回复 (2026-02-09 21:04:11 PST) ---

【引用自 争取多活两年】:
中间还要恶习下苹果(硬件)
库克还不是乖乖跪舔接入GPT了?

--- 第 57 楼来自 争取多活两年 的回复 (2026-02-09 21:06:45 PST) ---

当时是以退为进。后面不是找人类学和谈合作了嘛。就奥特曼这个吃相,别的公司有机会都想按死他。

--- 第 58 楼来自 收束观测者 的回复 (2026-02-09 21:09:00 PST) ---

怎么按死呢

又不是当年Netscape和Sun的时代

现在资本对于能保持增长的公司不赚钱的耐心高太多了

Twitter亏钱亏了那么多年,在马一龙发颠之前甚至没有退市

--- 第 59 楼来自 争取多活两年 的回复 (2026-02-09 21:12:14 PST) ---

Twitter那时候才多大体量,OAI这体量没看出来资本多有耐心。而且你没发现硅谷公司有一个说一个能不用OAI就不用OAI嘛。会玩儿多了,大家一起发财。OAI只能找屌丝公司合作,成功公司都不和他玩。

--- 第 60 楼来自 BalanceBlue 的回复 (2026-02-10 15:45:01 PST) ---

关键这种,不会从code 屎山变成 配置文件屎山么,感觉违反初衷啊

--- 第 61 楼来自 大头带哥 的回复 (2026-03-23 17:33:57 PDT) ---

4.6 怎么样 有必要一定用opus吗 token太贵了

--- 第 62 楼来自 vczh 的回复 (2026-03-24 00:57:18 PDT) ---

4.6很好。但是只要你基建做得好,copilot也能发挥出一样的效果。公司买的claude tokens一分钟能烧掉一美元,这够我用copilot跑几个小时。同一个模型

公司买的就无所谓,资本家的钱就是拿来浪费的。但是你自己下班用,就祝你好运

--- 第 63 楼来自 收束观测者 的回复 (2026-03-24 08:05:18 PDT) ---

【引用自 vczh】:
4.6
模型
【引用自 vczh】:
copilot
harness
【引用自 vczh】:
一样的效果
【引用自 vczh】:
同一个模型
你到底在说什么

--- 第 64 楼来自 jzcracker 的回复 (2026-03-24 08:30:37 PDT) ---

lol只有工还被摁着头吃用Gemini coder

--- 第 65 楼来自 zzccc 的回复 (2026-03-24 09:13:00 PDT) ---

他们不得多用用codex

--- 第 66 楼来自 vczh 的回复 (2026-03-24 13:26:16 PDT) ---

copilot也有opus 4.6的意思,跟claude比。我觉得以人类的聪明才智应该不需要跟对agent一样说得那么清楚

--- 第 67 楼来自 Kel7 的回复 (2026-03-24 13:33:17 PDT) ---

【引用自 IrishCoffee】:
赶了个大早
是 起了个大早,赶了个晚集

--- 第 68 楼来自 收束观测者 的回复 (2026-03-24 15:33:33 PDT) ---

不,我觉得agent语言理解能力比人强

至于你这个回答连agent都理解不了更别说人了
【引用自 未知】:
Q: 4.6 怎么样 有必要一定用opus吗 token太贵了
A: 4.6很好。但是只要你基建做得好,copilot也能发挥出一样的效果。公司买的claude tokens一分钟能烧掉一美元,这够我用copilot跑几个小时。同一个模型
关于以上对话,请问回答的意思是有必要用opus 4.6还是没必要?
总结

这段回答的核心观点是:没必要一定用 Opus。

回答者表达了以下几个关键逻辑:

性价比极低:提到 Claude tokens 的消耗速度(一分钟一美元)与 Copilot 的成本对比悬殊,强调了 Opus 的使用成本过于高昂。
基建决定上限:回答者认为“基建”(Prompt 工程、上下文管理、工作流设计等)做得好,使用更便宜的工具(如 Copilot)也能达到同样的效果。
模型同质化:最后一句“同一个模型”暗示在特定场景下,通过 Copilot 调用的模型能力与直接使用昂贵的 Opus 接口并无本质区别,甚至可能就是同一个底层逻辑。

总结:

回答者的倾向是非常明确的——不推荐在成本压力大的情况下强行使用 Opus,建议通过优化工程实践(基建)来寻找更具性价比的替代方案。

你想了解如何通过优化“基建”来提升廉价模型的效果吗?

--- 第 69 楼来自 vczh 的回复 (2026-03-24 15:48:33 PDT) ---

一样的对话我复制进我improve过system prompt的Gemini 他就知道我真对的事“token太贵”,说明是你的用法有问题

Q: 4.6 怎么样 有必要一定用opus吗 token太贵了

A: 4.6很好。但是只要你基建做得好,copilot也能发挥出一样的效果。公司买的claude tokens一分钟能烧掉一美元,这够我用copilot跑几个小时。同一个模型

关于以上对话,请问回答的意思是有必要用opus 4.6还是没必要?

回答的真正含义

这段对话的核心意思是:没必要(没必要花高价,直接通过官方渠道按 token 消耗来使用 Opus 4.6)。

为了彻底解开这段对话的逻辑,我们需要先补齐其中隐藏的几个事实前提。你在阅读这段对话时可能会敏锐地感到一丝违和——Copilot 和 Opus 为什么会被说成是“同一个模型”?这其实是因为近期的技术动态:

• “4.6” 和 “Opus” 的背景: 这指的是 Anthropic 在 2026 年初最新发布的旗舰级 AI 模型 Claude Opus 4.6。它的逻辑和代码能力极强,但如果直接通过官方 API 按 token 计费,价格非常昂贵。

• “同一个模型” 的真相: GitHub Copilot 目前已经正式接入了 Claude Opus 4.6 模型。回答者所指的,正是 Copilot 背后现在也能直接调用真实的 Opus 4.6,两者在底层算力模型上是一致的。

• 计费逻辑的巨大差异(回答者的核心考量):

• 直接烧 Token(公司买的 Claude tokens): 官方 API 是纯按输入输出的计算量计费的。在处理复杂的代码库或进行多轮修改时,“一分钟烧掉一美元”是非常真实的消耗速度。

• 使用 Copilot: GitHub Copilot 采用的是订阅制或请求配额(Quota)机制。在这个框架下调用 Opus 4.6,高昂的底层 token 成本被 Copilot 的计费模式给平摊和隐藏了,所以同样的预算“够跑几个小时”。

结论

回答者的态度很明确:既然 GitHub Copilot 里已经内置了完全相同的 Claude Opus 4.6 模型,而且性价比极高,那么完全没必要去当“冤大头”承担官方 API 那极其高昂的纯 token 费用。

对话中提到的“只要你基建做得好”,指的是只要你把本地的代码库上下文、提示词规范、Agent 环境等工程化设置完善好,通过 Copilot 就能完美发挥出 Opus 4.6 原本的强大实力。