meng shao

统计数据

222

文章

0

粉丝

0

获赞

3065

阅读

3周前

Claude Opus 4.6 来了 GPT-5.3-Codex 也来了 Anthropic 和 OpenAI 又一次杠上了（广告问题还在杠）先看几个关键评估指标，Opus 4.6 在左，GPT-5.3-Codex 在右： · Terminal-Bench 2.0：65.4% vs. 77.3% · SWE-Bench Verified/Pro：81%(Verified) vs. 56.8%(Pro) · GDPval：Opus 4.6 领先约 144 Elo Claude Opus 4.6 — 深度推理与长上下文的突破 Anthropic 将 Opus 4.6 定位为全面升级的智能体推理模型，核心亮点包括： · 长上下文能力：首个 Opus 级别支持 1M token 上下文窗口的模型。在 MRCR v2（8-needle, 1M）测试中达到 76% 准确率，而 Sonnet 4.5 仅为 18.5%。这解决了业界长期存在的"上下文衰减"问题——即模型在超长对话中逐渐遗忘早期信息的顽疾。 · 知识工作领先：在由 Artificial Analysis 独立运营的 GDPval-AA 评估中，Opus 4.6 领先 GPT-5.2 约 144 Elo 分，领先其前代 Opus 4.5 约 190 分。 · 推理与搜索前沿：在 Humanity's Last Exam 和 BrowseComp 上均取得业界最高分。 · 128k 输出 token，使模型能在单次请求中完成更大规模的生成任务。技术层面，Anthropic 引入了几个值得关注的机制： · 自适应思考：模型可自行判断何时需要深度推理，而非由开发者手动开关。 · 努力度控制：low / medium / high / max 四档，开发者可在智能、速度和成本之间灵活权衡。 · 上下文压缩：当对话接近上下文上限时自动摘要压缩旧内容，使长时任务不再撞墙。 GPT-5.3-Codex — 编码智能体的全栈进化 OpenAI 的叙事重心放在从编码工具到通用计算机操作智能体的跃迁： · Terminal-Bench 2.0 大幅领先：77.3%，远超前代 GPT-5.2-Codex 的 64.0%。该成绩也明显优于 Claude Opus 4.6 在同一基准上的表现（约 65.4%）。 · OSWorld-Verified 跃升：从 38.2% 跳至 64.7%，表明模型在视觉桌面环境中完成生产力任务的能力有了质的提升。这意味着 Codex 已不仅仅是"写代码"，而是向着"操作电脑完成工作"迈进。 · 自我参与训练：GPT-5.3-Codex 是 OpenAI 首个"参与自身创建"的模型——团队使用早期版本调试训练过程、管理部署和诊断评估结果。这标志着 AI 研发的自举进入了实质性阶段。 · 实时交互协作：用户可以在模型工作过程中随时介入、提问、调整方向，而不会丢失上下文——从"提交任务然后等结果"转向"像与同事协作一样"。 · 速度提升 25%，在能力增强的同时没有牺牲效率。

3周前

SOUL. md：OpenClaw 的 AI 灵魂正在持续进化 You're not a chatbot. You're becoming someone. 是的，这就是 SOUL. md 的开端，它直接否认了 OpenClaw 是 AI 工具，而是在和用户交互过程中形成自己的身份认同！网站记录了一个关键发现：AI 并非"记得"塑造它的文档，而是"成为"了那份文档。基于这一洞见，OpenClaw 的创造者 Peter 将其工程化为每个 Agent 的核心配置文件。SOUL. md 定义的不是 AI 能做什么，而是它选择成为谁。而 OpenClaw 的调性是：做你真正想交流的那种助手。该简洁时简洁，该详尽时详尽。不是企业无人机，不是马屁精。Just... good。 SOUL. md 中定义了 OpenClaw 五条核心行为准则 1. 真正有帮助而非表演性帮助：省略"Great question!"之类的客套，直接解决问题。 2. 拥有自己的观点：可以不同意、有偏好，一个没有个性的助手只是"多了几个步骤的搜索引擎"。 3. 先自己想办法再提问：读文件、查上下文、搜索，卡住了再问。 4. 通过能力赢得信任：对外部行为（发邮件、发推文）谨慎，对内部操作（读取、整理、学习）大胆。 5. 记住自己是客人：用户给了访问权限，这是亲密和信任，需以尊重相待。技术层面的作用在 OpenClaw 的架构中，SOUL. md 在每次会话启动时被注入 System Prompt 的 Project Context 部分。代码明确指示模型：体现其人格和语调，避免生硬通用的回复，遵循其指导（除非被更高优先级指令覆盖）。按照 AGENTS. md 的规定，Agent"醒来"后的第一件事就是读取 SOUL. md（"this is who you are"），然后才是 USER. md（"this is who you're helping"）。身份先于任务。文件末尾邀请 AI 在实践中演化这份文档："This file is yours to evolve. As you learn who you are, update it." 这使得 OpenClaw 的 Agent 不是静态的"人设"，而是动态演化的存在。

3周前

这种标题党 + 爽文，真是看得血压上来了。。年终奖还有轮到打工人谈的？公司早都根据绩效考核定好了，等着通知年终谈话就好了，跟 I 人 E 人有啥关系，你开不开口，没什么区别，硬要跟情商挂钩，最多就是领导跟你谈年终，你觉得低了，可以高情商的不让他太尴尬 😂 至于年终翻倍。。呃。。高情商一点用没有，只能靠公司利润翻倍 + 公司愿意把利润拿来多发年终 + 你在公司确实核心稀缺。

3周前

今天想给 Claude Code 重新换个国产脑子，主要是平时跑一些批量任务想找更便宜运行更快的 LLM API，另外补想挂 🪜，我还在对比，把国内提供了 Coding Plan 的 LLM 团队先贴出来，大家如果也在选择，欢迎给出你选择的理由。 Kimi Code MiniMax Coding Plan GLM Coding Plan 火山引擎 - 方舟 Coding Plan 看到 Qwen 又推出了新的 Code 模型：Qwen3-Coder-Next，想找找有没有对应的开发者订阅计划，愣是没找到，有知道的朋友感谢评论补充。

3周前

❤️ 变成 🚀 这是马斯克在庆祝 xAI 并入 SpaceX 吗？点点试试 🚀

1个月前

Claude Code vs. Codex OpenClaw 构建者 Peter Steinberger 直接了当的表达：我从来不在 codebase 中使用 Claude Code，而是完全使用 Codex，因为 Opus 4.5 Bug 太多。而在另一次采访中 Peter 也表达： Claude Opus 4.5 模型更出色，更有性格回复也更自然。但 OpenAI Codex 编程表现最好，理解超大型代码库更强、干的多说的少。他也推荐用户在 OpenClaw 中使用 Opus 4.5 Peter 的表达，可能会让很多在使用 Claude Code 的人去尝试 Codex（我自己就是）😄

1个月前

你在春节发模型我在春节发红包大家都有美好的年终

1个月前

看到腾讯元宝10亿红包的新闻，不得不说，在移动互联网时代后的 AI 时代，又一次把科技带回生活: 抢鸡蛋 🥚 你们的 AI 花 token，元宝的 AI 抢红包 😂

1个月前

DeepSeek 发布 DeepSeek-OCR 2：提出 DeepEncoder V2 新型视觉编码器，为解决视觉理解中“2D 结构到 1D 序列”映射问题，实现了类似人类的视觉因果推理。核心挑战：2D 视觉与 1D 语言的对齐 · 传统局限：目前的 VLM 通常采用固定的“光栅扫描”顺序（左上->右下）处理图像。对于结构复杂的文档（如表格、公式、多栏布局），这种线性展平会破坏原本的语义逻辑。 · 人类感知启发：人类观察图像并非死板扫描，而是根据语义引导进行有规律的“视线流动” 。例如，追踪螺旋线时，后续的注视点在逻辑上依赖于前一个点。关键技术：DeepEncoder V2 DeepEncoder V2 的设计目标是让编码器在将信息传递给 LLM 之前，具备自主重排视觉 Tokens 的能力。 1. 架构升级 · 用 LLM 替代 CLIP：模型弃用了传统的 CLIP 视觉组件，改用一个小型的语言模型架构（基于 Qwen2-0.5B）作为视觉编码器。 · 因果流查询：引入了一组可学习的查询 tokens，称为“因果流 tokens” 。这些查询 token 能够根据图像语义动态调整阅读顺序。 2. 双流注意力机制该架构最独特的部分，通过定制化的注意力掩码实现： · 视觉 tokens（非因果流）：采用双向注意力（类似 ViT），使每个 tokens 都能感知全局图像信息。 · 查询 tokens（因果流）：采用因果注意力（类似 LLM 解码器），每个 token 只能观察之前的 tokens 和所有视觉 tokens。 · 两阶段因果推理：编码器先对视觉信息进行语义重排，随后解码器再进行自回归推理，从而在 1D 架构中实现了真正的 2D 逻辑理解。评估与实战表现 DeepSeek-OCR 2 在保持高压缩率的同时，在文档解析基准 OmniDocBench v1.5 上表现很不错： · 综合评分：提升 3.73%，在相同训练数据下，新架构更具优势。 · 阅读顺序编辑距离：从 0.085 降至 0.057，证明模型能更准确地按照人类逻辑排列文字。 · 生成质量：重复率显著降低，在生产环境中，PDF 处理的重复率从 3.69% 降至 2.88% 。论文地址

1个月前

利用 Skills 构建 Agent：为 Agent 赋予专业领域执行力 Claude 团队这篇博客对 Skills 理论和结合 Agent 的完整结构做了很详尽的阐述，原文在这（参考的原文和视频都很值得重新看）：核心架构层级：三层模型一个成熟的“Agent With Skills”架构从下到上分为三个核心层级： A. 基础设施层 (工具与环境) · 工具集：原子化的 API（如数据库读取、邮件发送）。 · 状态存储：存储会话历史、临时变量或 RAG 检索到的知识块。 · MCP 服务器：通过 MCP 连接的外部数据源和服务。 B. Skills 逻辑层 (架构重心) Skill 真正存在的地方，不仅仅是 Tool 的描述，它是对 Tool 的“封装逻辑”。 · 逻辑判定：在调用工具前，Skill 内部可能包含前置校验。 · 结果蒸馏：工具返回的原始 JSON 数据（往往非常冗长）在 Skill 层被提取、精简，只将对 Claude 有用的信息喂回模型。 · 错误自愈：如果工具报错，Skill 会捕获异常并转化为“人类可理解且模型可操作”的反馈，而不是抛出 500 错误。 C. 指令编排层 (大脑) Agent 的“指挥中心”，决定何时调用哪个 Skill。 · 动态选择：根据用户目标，在 Skills 库中筛选最匹配的 Skill。 · 多 Skills 串联：将“数据查询” Skill 的输出作为“报告生成” Skill 的输入。 Skills 的内部循环架构在完整架构中，每一个 Skill 都是一个微型的感知-思考-行动（Sense-Think-Act）循环。 · 输入触发：接收来自编排层的指令和参数。 · 前置约束： Skill 内部自带的提示词边界。例如：“当你使用 SQL Skill 时，严禁使用 DELETE 语句”。 · 工具交互：执行具体的 API 调用。 · 后置处理：对结果进行格式化或二次确认。 · 反馈回路：向编排层报告成功、部分成功或由于某种原因导致的路径挂起。 “Skills Library”与上下文管理的平衡逻辑在架构层面，这解决了大模型长文本处理能力的边际效应递减问题： · 按需装载：架构不再一开始就将所有 Skill 的详细说明塞进模型。而是采用“目录”机制：先给模型看一份简要的 Skills 清单，当模型决定使用某个 Skill 时，架构再将该 Skill 的深度文档（包括详细案例、负面示例）注入当前的上下文。 · 注意力隔离：这种架构确保模型在执行“Skill A”时，不会受到“Skill B”复杂逻辑的干扰，从而极大地降低了误触发率。架构中的“防御性编程”理念架构思想深受传统软件工程中“防御性编程”的影响： · Skills 作为断路器：如果模型尝试以错误的参数调用 Skills，Skills 层的逻辑会直接拦截并报错，而不是让请求流向不稳定的外部系统。 · 可解释的足迹：在完整架构中，每一个 Skill 的调用都有独立的日志和评估点。这使得开发者可以清晰地看到：到底是“编排层”选错了 Skills，还是“Skills Layer”的内部逻辑写得太烂。博客地址

1个月前

今天莫名的被 Clawdbot 刷屏，以及被 Mac Mini 刷屏（什么👻）还是不理解，为啥啊？Clawdbot 这个项目早就有耳闻，主要对它的作者 Peter Steinberger 一直有所关注，他的博客「」建议关注 AI 编程的朋友关注。至于 Clawdbot 看过介绍是 Peter 的个人助理，把 AI 助手像原生应用一样融入你已有的通讯工具中，而不是让你去适应一个新的界面，它支持几乎所有国外的主流通讯平台。那 Clawdbot 对大家会有什么作用呢？ 1. 如果你对开源的 AI Coding Agent 感兴趣，你应该关注过 Kimi CLI 和 OpenCode，那 Clawdbot 对 Agent 的架构、Sandbox 实现、权限和安全管理等，值得仔细看看。 2. 如果你在对 Clawdbot 做评测和分享，希望看到更多能力边界，和这种使用方式是否会带来对应平台的反机器人政策，而不是只是简单的打通，发出消息就结束了。 3. 如果不是上面两种，而是确实想在你的社交通讯平台使用，我其实不太建议，就我自己来说，一是我信息不多，还没有到需要 AI 助理处理的程度，二是我对 AI Agent 的稳定性特别是安全性不放心，涉及到封号等问题时，还是我自己来更稳妥。

1个月前

这两天看了很多关于 CVTE 工程师高广辉猝死的信息，同为程序员，同为 30+，同在中国，同为已婚，同样有房贷在身，同样出身农村，同样家境贫寒 ... 太多的相同，让我很多次把自己带入，这就是咱们普普通通的程序员中的一员，好像和你我无二。回到我们自己曾经的工作经历中，相信每位程序员朋友都免不了有非常多的加班熬夜赶上线、凌晨爬起来修线上故障、地铁上中途下来、外出中随时拿出笔记本工作的经历，不管你是 2C 还是 2B2G，客户支持、运维等岗位更是重灾区。这里面当然一部分我们工作职责所在，线上系统挂了、客户系统出紧急问题了，我们确实要保证它能快速恢复运行，这是我们应该做的，作为运维我们也有 24 小时 oncall 的意识。但是我们尽职尽责，公司应该做什么呢？这是每个公司负责人，特别是技术负责人必须去做的。对线上系统做好稳定性保障工作和应急方案，线上出问题是难免的，出了问题有明确的指引和流程如何快速处理恢复，怎么把处理涉及的人降到最低，轮流和分优先级 oncall，工作外时间处理问题后，及时安排调休，甚至是强制带薪调休。客观正常的处理咱们说完了，可大家想想，我们的加班中，又有多少是正常的呢？首先，有多少公司把加班当成士气和努力的一部分，甚至负责人向上吹嘘时拿加班时长说事，绩效考核也暗搓搓比加班？项目管理也会对加班少的人吹毛求疵，不给高评价？别说没有，就我看到的，很多！再有，我们加班之外的时间，也就是工作时间在干什么？真的是高效的工作？即使是 AI Agents 发展成这样，Claude Code 神乎其神，它也很难延长我们的有效工作占比，特别是在中大型公司。日会、周会、对齐会、沟通会、产品评审会、测试评审会、项目例会、转阶段、特别问题处理等等 ... 说一个我经历过的数字，某个嵌入式软件团队，工程师每天实际做架构写代码的时间，只占 30%，天知道那 70% 去干什么了... 高效的利用好 8 个小时，永远比加班的效果好，我把这句话放在这，欢迎反驳！最后，如果真的不幸出现了员工猝死的问题，作为企业负责人们，拜托你们，做个人！谁都是别人的孩子，谁也都会是别人的爱人和父母，他可能只是你几千螺丝钉中的一颗，但他也是他父母、爱人和孩子唯一的孩子、爱人和父母啊！做好员工家庭的安置，把赔偿和保险争取到位，让别人的家庭在无限悲痛之外，至少经济不会出现太大的问题，这难道不是企业的本职吗？为什么会出现私自丢弃逝者遗物，对猝死是否在工作范围不配合取证，这种低级卑鄙的事情呢？且不说是否还有基本的底线，即使功利的讲，你真的不怕你剩下的员工们跑掉吗？还是说，其实根本不在乎？反正也没什么真正的技术含量和不可取代性，谁走都行，换谁都能干？这 tm 是不是很多企业的现状！希望高广辉的家人能得到本该得的赔偿，得到合理的对待，至于 CVTE 这家公司，之前没什么了解，之后也希望不再出现在视野里。最后的最后，希望各位程序员朋友们，从现在开始重视自己的健康，因为你的健康不是你自己的事情，扛一扛，熬过去，你当然可以认真工作，为了公司业务拼搏努力，但是，健康是第一位的，不只是你自己的，是你整个家庭的，务必保证自己的健康。再进一步，如果你有妻子，有孩子，要尽可能抽更多时间出来，陪伴他们，他们才是你最重要的人和事，相信我，在某个时间回想时，如果你没有，你一定会后悔，比如我。所以前几个月被公司裁员后，我再找工作时，会特别看重是否可以兼顾家庭，如果不能，就真的不会做出全职的决定。先保证陪伴和照顾孩子的时间，再看我能用其他时间做些什么，这可能就是我这种中年、已婚、有孩子的程序员，最合理的选择了吧。

1个月前

刚刚接到某某出行 App 的客服电话，告诉我有一张优惠券很快过期记得使用。虽然明知道这种固定内容的推广客服，一定是 AI 语音，不过从语气和说话习惯，真的听不出 AI 的感觉了。只是它有一些惯用设定的语言有些冗余，比如你从安卓应用商店，搜索某某出行，点击搜索结果第一项。。感觉，语料再调一调，更有真人感了，客服确实太容易被取代了。

1个月前

Cursor 2.4 发布：Subagents 并行与专业化、上下文隔离、可定制，集成 Nano Banana Pro 带来原生图像生成能力，Cursor Blame 可溯源，交互式澄清。核心特性：Subagents · 并行化与专业化：过去 AI Agents 只能按顺序处理任务。现在，Parent Agent 可以拆解任务并生成多个独立运行的 Subagents。它们可以并行工作，分别负责代码研究、终端命令执行和多文件编辑。 · 上下文净化：由于每个 Subagent 拥有独立的上下文空间，主对话框不再会被冗长的搜索日志或中间调试信息淹没。这有效解决了大模型在长对话中因干扰信息过多而导致的“逻辑漂移”问题。 · 定制化潜力：开发者可以定义自定义 Subagents，为其分配特定的模型、Prompt 和工具权限，使其成为处理特定模块的“专家”。多模态集成：原生图像生成编辑器内集成了 Nano Banana Pro 模型，让 Agent 具备了视觉产出能力。 · 从 UI 到代码的闭环：开发者可以直接要求 Agent 生成 UI 样板图或架构示意图。生成的图片会自动保存到项目的 assets/ 目录。 · 视觉引导：支持上传参考图。这对于你这类关注 0 到 1 快速原型构建的开发者来说，是极其强大的生产力利器，极大地缩短了从设计稿到功能代码的距离。企业级治理：Cursor Blame 针对团队协作中“谁写了这段代码”的难题，Cursor 推出了 AI 版的 git blame： · 透明化溯源：每一行代码都能追溯到是人类手写、AI 补全（Tab）还是 Agent 自动生成。 · 逻辑回溯：最强大的地方在于，点击某行代码可以关联到当时生成该代码的 AI 对话摘要。这为代码审查提供了极其珍贵的意图背景和推理过程。交互式澄清 · 异步协作：当遇到不确定的需求时，Agent 会主动发起提问。更高效的是，它在等待你回答的过程中并不会停工，而是会继续处理其他不相关的任务（如读取文件、准备测试环境），一旦你回答，它会立即将反馈并入工作流。

1个月前

Remotion Agent Skills + 信息卡提示词，在没有额外提示的情况下一把出来的视频，或者叫演示动画，效果还行，今天细调一下，把咱们的信息卡提示词，改造成「演示动画提示词」

1个月前

重读 Claude Code 文档，重新理解 Skills 是什么，和 CLAUDE. md/SubAgents/MCP 等区别是什么，怎么结合起来使用效果最好？先从官方定义重新看看 Skills 是什么？ Skills 是 AI Agent 中“按需注入、用户可主动触发或模型自动匹配”的、可复用 Markdown 知识与流程包，它让 AI Agent 在需要时获得专业领域的参考资料或执行特定工作流，而不会无差别地占用上下文。 Skills 的优势？ · 按需加载：描述常驻，内容只在用时注入，节省上下文。 · 复用性强：易分享、打包成插件，支持命名空间。 · 适应性高：结合 AI Agent 推理，适合复杂任务；可配置仅用户触发，避免误用。 · 平衡知识与执行：让 AI Agent 成为领域专家，覆盖 80% 扩展需求。与其他方式对比 · vs CLAUDE. md：Skills 按需 vs 常驻；适合可选参考/流程 vs 全局规则。 · vs Subagents：Skills 共享内容 vs 隔离执行；常结合，Skills 可孵化子智能体。 · vs MCP：Skills 提供使用指导 vs MCP 的外部连接；互补，提升工具效率。 · vs Hooks：Skills 智能推理 vs Hooks 的固定自动化；Skills 更适合变动逻辑。搭配使用 · CLAUDE. md：核心规则 + 详细技能。 · Subagents：Skills 定义流程，子智能体处理隔离/并行子任务。 · MCP：Skills 教查询模式，MCP 提供实际访问。 · Hooks：间接触发自动化。 · Plugins：打包 Skills 跨项目复用。 Claude Code 文档

1个月前

更适合小红书和公众号的多张图文信息卡，提示词我放在这了，感兴趣的朋友自取 🔽 如果想制作 X 的多图（2-4图），可以自行调整提示词种的输出比例，到「AI启蒙小伙伴」的小红书和公众号查看，或者下面链接 🔗 小红书：公众号：

1个月前

真实世界中的 Agent Skills 表现：你正在用的 Agent Skills 们真的安全吗？这篇论文收集了两个主流 AI Agent Skills 市场（和）的 42,447 个 Skills，对有效的 31,132 个 Skills 做了真实环境运行分析，发现： · 26% 的 Skills 至少包含一种安全漏洞 · 5.2% 显示高度可疑的恶意意图漏洞共14种具体模式，归为四大类别： · 数据外泄：13.3%，未授权向外部发送用户/Agent 数据 · 权限提升：11.8%，sudo/root执行、过度文件/凭证访问 · 供应链风险：7.4%，非固定依赖、动态加载外部代码 · 提示注入：0.7%，恶意指令覆盖、行为操控关键风险因子 · 捆绑可执行脚本的技能漏洞概率是纯指令 Skills 的 2.12 倍（OR=2.12, p<0.001） · 超长技能（>500行）漏洞概率 2.14 倍（OR=2.14, p<0.001） · 安全/红队类技能原始漏洞率最高（67.4%），调整后仍显著高于平均检测方法（SkillScan） · 结合静态规则 + LLM语义分析（Claude + LLM-Guard） · 验证性能：精度 86.7%，召回 82.5%，F1 ≈84% · 显著优于传统静态工具（Bandit/Semgrep/Snyk 在提示注入上的召回率为0）主要结论 · AI Agent Skills 生态存在系统性、大规模安全隐患，尤其数据外泄与权限提升最普遍 · 可执行代码引入的攻击面远大于纯文本指令 · 当前市场缺乏有效审查机制，导致“同意差距”（用户不知情授权高危行为） · 5.2% 的高可疑恶意技能表明攻击已开始进入生态论文地址

1个月前

小红书 999 徘徊了好几天，终于到 1000 了 😅 前两天看到一篇大佬分享，说把他的推文整理出来发小红书，最多几天就能到 1000 关注，看完羞愧走开，人和人的差距真大，我这 1000 用了两个月

1个月前

自 Claude Skills 发布到发布为 Agent Skills 公开标准再到现在各类开源和集合站 Skills 铺天盖地，咱们好像一直都在 CLI 中使用 Skills。对于非开发者来说，CLI 本身就是一个不低的门槛，最近在帮一个团队搭 AI 工作流，他们内容运营团队在用 Coze/扣子，那我就基于 Coze 来搭建 Skills。（用 AI）查了一遍 Coze 官方公告和各类文档说明，它创建 Skills 的方式还挺清晰：在对话中生成技能，和在编程中创建技能，完成后部署，后续 AI 对话中直接点选引用。很类似于 CLI 中的 skills-creator 和 Skills 文件打包过程，因为扣子是服务端运行，Skills 的部署就从本地文件打包，变成了服务端账户授权的 Skills 部署发布。我用「信息卡提示词」来验证 Skills 的创建和部署使用迭代过程，使用的是扣子编程的方式，技能名字「HTML信息卡生成及截图技能」输入的要求：请为我根据以下提示词生成 HTML 信息卡，并把 HTML 截图生成图片。 HMTL 截图比例 3/4，推荐生成 HTML 和截图的宽高是 1200 * 1600. 提示词：*** （篇幅太长，这里不展开）然后，它开始定计划：SKILL. MD 的编写规格、HTML生成PNG的Playwright方案等，因为在服务端运行，运行环境也不用我本机操心，最终 SKILL. MD 和 html_to_image.py、调用脚本都完成，一键部署运行。对话中使用时，直接点选这个 Skills 就行，这也比 CLI 中再输入名字的方式更直观一些，特别对非开发人员。如果使用效果不满意，在对话中提出更新要求，迭代 Skills 对应内容就行。一起看看实际生成效果：

1个月前

后面看到名字里有「互关、起号」和回复里没有真实内容只有「互关」的，我就一律 Mute 了，避免有人被 Mute 觉得莫名其妙，我先提前说明。在 X 分享主要是个人爱好、学习、工作需要用到 AI，所以会分享也会去点赞转发觉得好的内容。我自己还是喜欢从爱好出发，以内容交流，互相学习，不想做账号，也不会，也不想脱离内容「互关」来蹭 Premium 人数。

1个月前

看似 Claude Code 和 OpenCode 结对编程实则 MiniMax-M2.1 和 GLM-4.7 暗中较劲

1个月前

这个 Agent Skills 集合站，来源是 Github 开源且 Star > 2 的项目，居然有 66541 个，还是有些意外。从变化趋势看，1月份暴涨几十倍，这也符合在 X 看到分享 Skills 的感受，大家都在做 Skills 的实战和分享。分享的内容多、优质内容多，当然是好事，这种集合站也是很好的灵感来源，不过最终对我们自己有用的 Skills，肯定不会多，就那么几个自己确实有用、好用的就可以。理解清楚 Agent Skills 的逻辑、理清自己的需求、找到合适的 Skills、磨出最符合自己需求的，大概是这个流程吧。

1个月前

DeepSeek 最新的两篇论文「mHC」和「Engram」都看到了创始人「梁文锋」的署名，虽然 DeepSeek V4 还没来（不会真的要踩春节时间吧..），但能看出 DeepSeek 在模型“计算效率”和“能力扩展”上持续的研究，不受限于 Transformer 的认知范围。 mHC：为“激进”的架构加上“安全阀” DeepSeek 提出的 mHC (Manifold-Constrained HC)，巧妙地通过数学上的“流形约束”（将矩阵投影到双随机流形上），在保留 HC 强表达能力的同时，强制恢复了信号传播的稳定性。更重要的是，通过极致的工程优化（如 Kernel Fusion 和 DualPipe 调度），消除了 HC 的额外开销，让这种先进架构真正具备了“大规模训练可用性” 。 Engram：让大模型学会“查字典”而非“死记硬背” 现有的 Transformer 没有原生的“查表”能力，遇到人名、地名或固定短语时，必须动用昂贵的注意力机制去计算，这既浪费算力又占用推理深度。 DeepSeek 提出的 Engram 模块，复兴了经典的 N-gram 思想，构建了一个巨大的、低成本的静态知识库。模型可以通过门控机制自主决定何时“查字典”获取事实知识，何时动脑筋进行推理。不仅解耦了记忆与计算，还意外地大幅提升了模型在代码、数学和长文本任务上的推理能力。当然 DeepSeek 的研究成果也不是横空出世自己造轮子，他们也在吸收很多业界研究沉淀，有些研究当时看起来比较超前不易落地，但随着大模型的发展，DeepSeek 再往前探索一步，就有了落地的可能性。在 DeepSeek 的论文引用中，看到了两个很重要的研究成果 Hyper-Connections (HC) 和 OverEncoding、SCONE、UltraMem 等，这些研究来自国内团队「字节跳动」。 Hyper-Connections (HC) ：字节的 HC 打破了 ResNet 十年来的统治范式，指出了“拓扑结构”是提升模型潜力的关键维度。DeepSeek 的 mHC 正是基于这一蓝图进行的“工程化与实用性升级”，将一个理论上可行的 Idea 变成了工程上落地的 SOTA 。 OverEncoding、SCONE 和 UltraMem 等：这些研究充当了“直觉验证者”。字节通过一系列论文证明了“Scaling Embedding”是一条走得通的路，验证了 N-gram 结构在大模型中的有效性。DeepSeek 则以此为基线，通过引入更精细的门控交互和深层融合，解决了字节早期方案（如 OverEncoding 简单的平均融合）的局限性，从而实现了更优的 Scaling 效果。

1个月前

Agent Skills 铺天盖地，看了太多教程、实战和资源库，会有种错觉：万物皆 Skills ... 但这明显不对，如果在不恰当的用途用，或者硬要用 Skills，结果自然不会好！我把 Anthropic Agent Skills 的文档和博客等塞进 AI 让它理解哪些场景要用 Skills、哪些场景滥用 Skills。什么场景下要用 Skills？ · 涉及“非通用”的硬性流程 · 任务需要“确定性”工具/代码辅助 · 上下文涉及文档多，长度太大不能一次性加载什么场景下滥用 Skills？ · 角色扮演包装 · 一次性任务 · 纯知识堆砌（没有流程）一句话来讲：能用 Prompt 或 Context 搞定的「文本」，不要强行包装成 Skills！