即刻App年轻人的同好社区
下载
26 10
上周 ChatGPT Health 的功能向美国用户推出了，我试了一下，这东西非常顶啊！
即使你没有美国其他的健康应用，只是有 Apple Watch 的一些健康数据，它也能分析出非常多的信息。
比如说我长期的那个“有氧适能”低问题。我一直以为是自己身体有什么问题，导致长期运动以后依然无法提升。
但是 GPT 就分析出来了（尤其是配合 ChatGPT Pro 使用，效果更顶）：
它分析出这是因为 Apple Watch 的有氧适能测试只针对徒步和跑步，而我这两个运动进行得比较少，所以它就没有机会进行测试。
还有就是它对你身体的运动量、睡眠，以及其他一些因素对健康的影响，分析得都非常准确。
其实我们在 Apple Watch 中的很多数据平时都被浪费了，如果拉长时间维度来看，这些数据非常有用。
现在 ChatGPT 可以对这些数据进行非常准确和清晰的分析，它还会去检索各种权威的健康信息网站。
如果你经常使用 Apple Watch 的话，建议你开启这个功能试试。目前该功能只针对美国市场开启。
甚至可以设置一个定时任务，让它每周针对你这周的这个 Apple Watch 数据，给你一份健康报告
即使你没有美国其他的健康应用，只是有 Apple Watch 的一些健康数据，它也能分析出非常多的信息。
比如说我长期的那个“有氧适能”低问题。我一直以为是自己身体有什么问题，导致长期运动以后依然无法提升。
但是 GPT 就分析出来了（尤其是配合 ChatGPT Pro 使用，效果更顶）：
它分析出这是因为 Apple Watch 的有氧适能测试只针对徒步和跑步，而我这两个运动进行得比较少，所以它就没有机会进行测试。
还有就是它对你身体的运动量、睡眠，以及其他一些因素对健康的影响，分析得都非常准确。
其实我们在 Apple Watch 中的很多数据平时都被浪费了，如果拉长时间维度来看，这些数据非常有用。
现在 ChatGPT 可以对这些数据进行非常准确和清晰的分析，它还会去检索各种权威的健康信息网站。
如果你经常使用 Apple Watch 的话，建议你开启这个功能试试。目前该功能只针对美国市场开启。
甚至可以设置一个定时任务，让它每周针对你这周的这个 Apple Watch 数据，给你一份健康报告
25 610
Anthropic 讲解了随着模型的提升，应该如何更新自己的上下文规则，推荐看看。
随着 Fable 5 和 Opus 5 的发布，他们精简了 80% 的系统提示词，但在编程测评上没有任何损失。
其核心问题在于，Claude 的提示词只是它获取上下文的一小部分，更多的上下文来自于系统提示词、Skills、claude.md 以及 Memory。
这里的难点在于：上下文是跨多个请求通用的，不能像单个提示词那么具体。
他们之前对 Claude Code 的约束过度了，而且经常存在互相矛盾的指令（约束越多，冲突的概率就越大）。
像 Fable 5、GPT 5.6 这种新模型，完全能够靠上下文和自己的判断力处理很多事情，因此没必要过度约束。
他们总结了过去到现在关于上下文转变几条趋势：
1. 从“给规则”到“让 Claude 运用判断力”：比如旧版会写“默认不写注释”，新版可以改成“写出与周围代码一致的代码”，这样它自己就会去匹配周围代码的注释密度、命名和习惯。
2. 从“给具体示例”到“设计接口”：给具体示例容易让模型变得死板。现在可以给一些设计接口（比如脚本文件的设计），让参数更具表达力，以此来引导它，而不是塞给它具体的示例。
3. 从“全部前置的上下文”到“渐进式披露”：把代码审查、验证等相互独立的信息放在不同的 Skills 里面，按需调用。模型可以通过文件搜索去查找，而不需要一次性塞入。
4. 不在系统提示词和工具描述里重复提示：直接把用法写进工具描述里，不再到系统提示词里去强调。
5. 从“手动记录”到“自动记忆”：以前是在 claude.md里存记忆，现在直接由模型自动记忆，不再依赖手写输入。
6. 从“简单规则”到“丰富的引用”：以前规则非常单一，现在可以把图片、HTML 文件、测试文件、测试代码、函数甚至是评分标准，都作为模型的上下文塞进去。
---
关于如何将这些原则运用到你自己的上下文管理中，有以下几点建议：
系统提示词定位：在系统提示词里明确告诉 Claude 在什么产品里做什么。如果你在构建 Agent，需要投入精力重新编写系统提示词。
保持 [claude.md]或 [agent.md]的轻量：把仓库用途和说明性内容花在最核心的地方（比如已知的坑或缺陷上）。避免把 Claude 一看代码就能懂的事情非要写进 [claude.md]里。
多用 Skills 进行模块化：把需要按需查找的信息打包成 Skills。如果 Skills 过长，需要采用渐进式披露的方式拆分成多个文件。
优先引用代码形式：在使用 @ 引用文件时，优先引用代码。比如引用 HTML 模板的效果，通常比只给设计描述或截图效果更好。
使用自动化工具：他们还提到了 `claude doctor` 这个命令，可以自动帮你精简 Skills 和 [claude.md]文件。
详情：claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
随着 Fable 5 和 Opus 5 的发布，他们精简了 80% 的系统提示词，但在编程测评上没有任何损失。
其核心问题在于，Claude 的提示词只是它获取上下文的一小部分，更多的上下文来自于系统提示词、Skills、claude.md 以及 Memory。
这里的难点在于：上下文是跨多个请求通用的，不能像单个提示词那么具体。
他们之前对 Claude Code 的约束过度了，而且经常存在互相矛盾的指令（约束越多，冲突的概率就越大）。
像 Fable 5、GPT 5.6 这种新模型，完全能够靠上下文和自己的判断力处理很多事情，因此没必要过度约束。
他们总结了过去到现在关于上下文转变几条趋势：
1. 从“给规则”到“让 Claude 运用判断力”：比如旧版会写“默认不写注释”，新版可以改成“写出与周围代码一致的代码”，这样它自己就会去匹配周围代码的注释密度、命名和习惯。
2. 从“给具体示例”到“设计接口”：给具体示例容易让模型变得死板。现在可以给一些设计接口（比如脚本文件的设计），让参数更具表达力，以此来引导它，而不是塞给它具体的示例。
3. 从“全部前置的上下文”到“渐进式披露”：把代码审查、验证等相互独立的信息放在不同的 Skills 里面，按需调用。模型可以通过文件搜索去查找，而不需要一次性塞入。
4. 不在系统提示词和工具描述里重复提示：直接把用法写进工具描述里，不再到系统提示词里去强调。
5. 从“手动记录”到“自动记忆”：以前是在 claude.md里存记忆，现在直接由模型自动记忆，不再依赖手写输入。
6. 从“简单规则”到“丰富的引用”：以前规则非常单一，现在可以把图片、HTML 文件、测试文件、测试代码、函数甚至是评分标准，都作为模型的上下文塞进去。
---
关于如何将这些原则运用到你自己的上下文管理中，有以下几点建议：
系统提示词定位：在系统提示词里明确告诉 Claude 在什么产品里做什么。如果你在构建 Agent，需要投入精力重新编写系统提示词。
保持 [claude.md]或 [agent.md]的轻量：把仓库用途和说明性内容花在最核心的地方（比如已知的坑或缺陷上）。避免把 Claude 一看代码就能懂的事情非要写进 [claude.md]里。
多用 Skills 进行模块化：把需要按需查找的信息打包成 Skills。如果 Skills 过长，需要采用渐进式披露的方式拆分成多个文件。
优先引用代码形式：在使用 @ 引用文件时，优先引用代码。比如引用 HTML 模板的效果，通常比只给设计描述或截图效果更好。
使用自动化工具：他们还提到了 `claude doctor` 这个命令，可以自动帮你精简 Skills 和 [claude.md]文件。
详情：claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
29 27
笑死 Anthropic 这么草台？
这 Opus 5 的测试成绩分数标红不太对吧
53.4 大于 53.5？
这 Opus 5 的测试成绩分数标红不太对吧
53.4 大于 53.5？
歸藏: 来了！Opus 5 模型发布，价格跟 Opus 4.8 相同 在测评成绩上大幅优于 Opus 4.8，同时相当多的测评成绩都高于 Fable 5。 终于有个能用的模型了！ 要再不出，我感觉 Claude Max 都没必要续订了，性价比过低，4.8 跟屎一样
14 21
来了！Opus 5 模型发布，价格跟 Opus 4.8 相同
在测评成绩上大幅优于 Opus 4.8，同时相当多的测评成绩都高于 Fable 5。
终于有个能用的模型了！
要再不出，我感觉 Claude Max 都没必要续订了，性价比过低，4.8 跟屎一样
在测评成绩上大幅优于 Opus 4.8，同时相当多的测评成绩都高于 Fable 5。
终于有个能用的模型了！
要再不出，我感觉 Claude Max 都没必要续订了，性价比过低，4.8 跟屎一样
23 66
牛逼！黄仁勋开了自己的 Twitter 账号
并且发表了第一篇帖子，力挺开源模型和开源生态！
这是最近美国政府和企业领域关于是否要封禁中国的顶尖开源模型，在持续了好几天的讨论中，应该是第一个明确站队的行业头部 CEO。
主要观点是，美国不应该把 AI 领导力理解成保护几家头部巨头公司的领先地位，否则有可能输掉整个 AI 战争。真正的优势应该来自于开放的模型、算力基础设施、生态应用和广泛的落地。
主要的诉求包括：
1. 为初创公司和研究机构提供更多算力
2. 建设共享数据集、工具和评估体系
3. 不要因为潜在风险而过早地限制开源模型
对于英伟达来说，这种开源模型的存在肯定是对它有好处和有帮助的。他把角度找得很好，即：美国究竟是需要整个美国 AI 生态的繁荣，还是仅仅为了保护某几个公司的利益？
我翻译了一下他的公开信的内容
并且发表了第一篇帖子，力挺开源模型和开源生态！
这是最近美国政府和企业领域关于是否要封禁中国的顶尖开源模型，在持续了好几天的讨论中，应该是第一个明确站队的行业头部 CEO。
主要观点是，美国不应该把 AI 领导力理解成保护几家头部巨头公司的领先地位，否则有可能输掉整个 AI 战争。真正的优势应该来自于开放的模型、算力基础设施、生态应用和广泛的落地。
主要的诉求包括：
1. 为初创公司和研究机构提供更多算力
2. 建设共享数据集、工具和评估体系
3. 不要因为潜在风险而过早地限制开源模型
对于英伟达来说，这种开源模型的存在肯定是对它有好处和有帮助的。他把角度找得很好，即：美国究竟是需要整个美国 AI 生态的繁荣，还是仅仅为了保护某几个公司的利益？
我翻译了一下他的公开信的内容
27 109