meng shao

统计数据

176

文章

0

粉丝

0

获赞

1871

阅读

2周前

谷歌首席工程师：Claude Code 一个小时做了谷歌一个团队一年做出的方案！在人才密度如此高的谷歌，也开始有了这种强烈的感受：以 Claude Code 为代表的 AI Coding Agent 能力之强，已经不是简单的做「实习生」「初级工程师」的重复工作而已了，对于更复杂更底层的深入也是越来越强，不管你经验多丰富编程能力多强，它都能帮到你，前提是：开放心态、用好它。在 Jaana Dogan 分享的这里案例里，谷歌团队从去年开始尝试构建「distributed agent orchestrators」，过程中存在多种方案且团队意见不一，进展缓慢。然而，她将问题描述输入给 Claude Code，后者仅用一小时就生成了他们去年构建的内容。在分享中，不止看到了 Claude Code 的强大，也看到了软件工程/大公司的传统问题，人越多配合越多、决策越低效，效率越低。未来的趋势，一定是 1 人 + N AI，一个有架构能力、需求理解能力和审查能力的人，和 N 个 AI 配合，去掉流程、去掉决策成本，AI 极速狂奔，人定义和把关。

2周前

纳尼 🧐 号称 3-5 个工作日审核的 Wise，在超过 30 个工作日后，居然通过了我的香港账户申请？这是赶在 2025 年内清系统挤压数据吗 😂 也不重要了，这 30 个工作日内，我早就肉身去香港办好其他银行卡，Wise... 也用不上了

2周前

同感，看到 Meta 收购 Manus 的信息时，第一反应也是负面偏多，看到朋友圈、公众号和 X 刷屏的祝贺，一时间也不知道该说些什么，看完玉伯的信息，把我模糊的感觉变清晰了。我想大家祝贺的，主要还是比上市周期更短的变现，不管是创始团队，还是投资人，在财务方面都是很不错的结果。但如果我是 Manus 创始人（不要脸带入一下😂），我被 Meta 收购，从产品发展上可能高兴不起来。Meta 最近一年的 Llama 4 扑街、天价挖人、收 Scale AI 核心团队、Lecun 离职，充满了焦虑和面向资本市场的动作。 Manus 应用于 Meta 的 C 端和企业用户？说得通，但不乐观；退一步讲，即使真的应用，模型会受限吗？其他用户策略包括与 Meta 原产品的结合会影响 Manus 的发挥吗？充满问号。另一方面我也在想，只看到了 Manus 的 ARR 快速蹿升，那成本呢，特别是 LLM API 成本，想想 Cursor 的 Claude API 成本，ARR 亮眼的背后，实际利润如何，很难讲。 anyway... 我不相信 Manus 创始团队做 Manus 的初衷是短期被收购，不然他们不会做到这么好，肯定还是有长期的通用智能体愿景的。

3周前

[开源推荐] Continuous Claude: 解决 Claude Code 等 AI Coding Agent 在长会话中面临的一个痛点：上下文丢失与“遗忘”，就像是装了一个“外挂大脑”和“自动日记本”，让它即使在长时间、复杂的开发任务中，也能保持清醒，记得住之前的决定，并且能像人类工程师一样进行跨会话的工作交接。核心痛点：为什么需要它？在使用 Claude Code 等进行大型重构或复杂功能开发时，随着对话变长，Token 数量会迅速消耗。 · 原生机制：为了节省空间，Claude Code 会进行“压缩”，把之前的对话总结成摘要。 · 后果：这种压缩是有损的。经过几次压缩后，“摘要的摘要”会丢失大量细节（比如某个函数的具体参数、之前的调试结果），导致 AI 开始“胡言乱语”或重复错误。解决方案：Continuity System（连续性系统） Continuous-Claude 提出了一套类似人类工程师的工作流，用清晰的文档代替模糊的记忆。 · Ledger（账本/工作日志）： · 在当前会话中，它会实时记录“目标是什么”、“完成了什么”、“下一步做什么”。 · 当你感觉到上下文快满时，你可以直接输入 /clear 清空上下文。但不用担心，Claude Code 会自动加载这个“账本”，瞬间找回工作状态，而不是依赖那个模糊的摘要。 · Handoff（交接文档）： · 当你结束一天的工作，或者一个 Agent 完成了它的任务时，系统会生成一份详细的 markdown 交接文档。 · 下一次启动（或下一个 Agent 接手）时，直接读取这份文档。这就像早班同事给晚班同事留了一份详细的交接条，确保无缝衔接。核心架构与功能亮点这个项目不仅仅是保存文本，它设计了一套完整的 Agent 编排和工具执行逻辑： A. 技能 vs 智能体 · 技能：在当前会话中快速执行的动作。比如“写个 Commit”、“查个文档”。 · Agent：当任务太复杂（比如“设计整个后端架构”），在当前窗口做会严重消耗 Token 时，系统会新开一个干净的上下文来运行 Agent。典型流程：Plan Agent (做计划) -> Validate Agent (验证/查资料) -> Implement Agent (执行代码)。 B. MCP 代码执行 (Token 节省) 这是非常聪明的一点。通常 AI 运行工具会将工具的定义和结果塞满上下文。 · Continuous-Claude 的做法：它通过脚本在外部运行工具（如 Python 脚本），只把必要的结果返回给 AI。这极大地减少了 Token 的占用，防止上下文被工具调用的冗余信息“污染”。 C. 钩子系统 (Hooks System) 它利用 Claude Code 的生命周期钩子（Hooks）实现了自动化： · SessionStart：自动加载上次的“账本”和“交接文档”。 · PreCompact：在 Claude 试图压缩上下文之前，自动拦截并保存当前状态，防止信息丢失。 · StatusLine：在终端底部显示一个彩色的状态栏，实时告诉你 Token 用了多少，是否需要清理上下文了。实际工作流体验如果你使用了这个项目，你的开发体验会变成这样： 1. Onboarding： · 在一个新项目中输入 /onboard，Claude 会自动分析整个代码库结构、技术栈，并生成一份初始的“认知文档”。 2. 开发 (Development)： · 你说：“我要做这个功能”。 · 系统激活 TDD Workflow，强制要求先写红灯测试（Failing Test），再写实现代码（Green），最后重构。 3. 遇到困难： · 你说：“Recall what was tried”（回忆试过什么）。 · 系统会去翻阅之前的 Reasoning History（推理历史），告诉你：“我们在 Commit abc123 中试过这个方法，但失败了，原因是...”，避免重蹈覆辙。 4. 下班： · 你说：“Done for today”。 · 系统生成一份详细的 Handoff 文档，记录当前进度和未完成事项。开源地址

3周前

[重读官方文档] Agent Skills 技能系统原理与实践 Agent Skills 把领域特定知识、工作流程、最佳实践打包成可重用的“技能包”，让通用 AI Agent 转变为专精于特定任务的 Agent。不同于一次性提示，Skills 是基于文件系统的资源，按需加载，避免重复指导。 Anthropic 已将 Agent Skills 标准正式开放： Agent Skills 核心优势包括： · 将 AI Agent 专精化，适应特定领域任务 · 一次性创建，跨会话自动复用 · 支持技能组合，构建复杂工作流 · 通过“渐进披露”机制，仅加载相关内容，高效管理上下文窗口核心概念与工作原理 Agent Skills 可基于 Agent 的 VM 环境运行，利用文件系统访问、bash 命令和代码执行能力。每个 Skill 是一个目录，核心文件为 SKILL. md，包含 YAML 元数据和 markdown 指令。加载分为三个级别，实现渐进披露： · 级别1：元数据（始终加载）：YAML 中的 name 和 description，轻量预载入系统提示，帮助 Claude 判断何时触发（几乎无 token 消耗）。 · 级别2：主要指令（触发时加载）：SKILL. md 正文，提供流程指导、示例代码等（通常 <5k tokens）。 · 级别3：资源与代码（按需加载）：额外 markdown 文件、脚本、模板或参考资料。通过 bash 读取文件或执行脚本，仅输出进入上下文（无上限限制）。这种架构允许 Skill 包含大量内容（如完整 API 文档、大型示例），但只在需要时占用上下文。AI Agent 使用 bash 命令（如 cat SKILL. md 或 python script. py）访问内容，确保高效和确定性。预构建 Skills Anthropic 提供预构建 Skills，可以看这个开源项目：最佳实践 · 元数据描述：清晰描述“技能做什么” + “何时使用”（触发条件），帮助 Claude 准确匹配用户意图。 · 指令结构：在 SKILL. md 中提供清晰步骤、快速入门、示例；拆分复杂内容到子文件，避免单文件过长。 · 利用脚本：优先用可执行脚本处理确定性操作（如数据验证、文件处理），输出高效且不占上下文。 · 渐进设计：从评估 AI Agent 能力缺口开始，迭代测试；提供丰富示例，提升鲁棒性。 · 范围控制：技能专注单一领域，便于组合使用；从简单任务起步，逐步扩展。 · 测试迭代：观察 Claude 是否正确触发和使用，必要时让 Claude 自我反思改进。

3周前

ChatGPT 服务是不是挂了？

3周前

Claude Code 创建者 Boris Cherny 的职业成长和 Claude Code 背后的故事 Claude Code 诞生的故事大家应该都看过不少，这回从 Boris Cherny 的视角，看看他从 Meta 到 Anthropic 一路的成长经验和对 AI 应用开发的关键洞见。 1. 为“6个月后的模型”设计产品，而不是今天的模型在快速进步的 AI 领域，不要基于当前模型的能力来构建产品，而要提前布局为半年后更强大的模型设计功能。这样早期产品可能体验一般，但一旦新模型发布，就能实现质的飞跃，正如 Claude Code 在 Claude 4 系列发布后迅速成为核心生产力工具。 2. 挖掘“潜在需求”是产品成功的核心秘诀最成功的产品的根源在于观察用户已经在现有功能上“滥用”或迂回实现的需求，然后为其提供更顺畅的专用工具——你无法发明全新行为，但可以完美满足用户隐藏的真实意图，如 Facebook Marketplace 和 Dating 的功能起源。 3. Side Project 是工程师职业增长的最大杠杆通过主动解决自己和他人重复遇到的痛点，并将解决方案推广为公司级工具或基础设施（如开源库、内部 lint 规则、测试框架），工程师能快速积累跨团队影响力和信誉，这是职业高速成长的最有效途径。 4. 优先选择通才，主动打破专业泳道限制高影响力工程师不仅是写代码，还需具备产品感、设计能力和用户沟通能力；团队应优先招募和培养“什么都能干”的通才，大公司尤其需要打破狭窄专业分工，让工程师自由跨界才能产生最大价值。 5. 常识是最大的超级力量，尤其在大组织中在复杂的大公司环境或快速变化的技术领域中，最可靠的决策依据往往是回归基本常识——问清楚“用户真正需要什么”“这件事合不合理”，而非被历史包袱、组织惯性或流程牵着走。 Youtube 视频地址

3周前

11月看到有朋友推荐 W**e，看下来觉得挺方便，就去注册了，结果。。。说好的2-4个工作日审核，这都一个多月了。。。后来还是更稳妥路径去hk办了卡，这个 W**e 就比较鸡肋了，卸载了

3周前

2025年终于快结束了，错峰总结一下自己2025年发生了大的变化，也给2026年一些期望，不定计划了，反正也做不到 😄 2025年我有三种很不同的状态： 1-8月，在硬件公司硬扛，但有AI解忧，硬件工作中的负能量被AI补偿和治愈 8-9月，被辞退后短暂的迷茫、难得的休息 9-12月，孩子上一年级、家人身体出现问题，全部精力照顾家里即将进入2026年的当下，孩子习惯了上学的状态、家人身体终于恢复到稳定的状态，我也终于按捺不住想工作的心了，就像最近跟朋友分享的：看着AI奔涌向前，你却站在原地，这种感觉，很像被所有河水抛弃了。。。 2026年，最大的期望：家人身体健康，生活被快乐充满，嗯，只有这一点。

3周前

[开源推荐] Skills: Anthropic 官方 Agent Skills 精选资源和最佳实践库 Anthropic 官方开源的这个项目展示了从创意到企业级的完整谱系，证明 Skills 系统能处理高度专业化的重复任务。目前仓库中共包含 16 个技能，分为几大类别 🔽 1. 文档处理类（最复杂、生产级） · docx：处理 Microsoft Word 文档生成/编辑 · pdf：PDF 文件操作（如表单字段提取、图像处理） · pptx：PowerPoint 幻灯片生成/编辑 · xlsx：Excel 表格处理 · doc-coauthoring：文档协同编辑 2. 创意与设计类 · algorithmic-art：算法生成艺术 · canvas-design：画布式视觉设计（如海报、艺术品） · frontend-design：前端界面高品质设计（最近更新） · theme-factory：主题生成 · brand-guidelines：品牌指南应用 3. 开发与技术类 · webapp-testing：Web 应用自动化测试（复杂度高） · web-artifacts-builder：Web 组件构建 · mcp-builder：模块化组件构建 4. 企业与沟通类 · internal-comms：内部沟通工作流 · slack-gif-creator：Slack GIF 生成 5. 元技能 · skill-creator：帮助创建新技能的“技能生成器”，极大降低自定义门槛，是扩展性的关键体现开源地址

3周前

跟顶尖 AI 团队学「上下文工程」通过「信息提纯、状态同步、动态剪裁、性能加速」四种手段打造具备「感知、筛选、精炼与持久化」能力的 AI Agent。一、信息提纯：确保模型只接收高价值的背景信号在上下文工程中，「信噪比」决定了 Agent 的推理上限。当模型面对海量代码库或长文档时，简单的 RAG 向量匹配已经无法满足需求。 1. 语义补全 Anthropic 和 Chroma 的研究指出，传统的片段检索会导致信息孤岛。上下文工程的核心在于「预处理」，即在存储每一个信息片段时，利用模型提前为其注入全局背景。例如，在索引一段代码时，上下文工程会强制加入其所属的项目架构信息，确保检索出来的内容自带「自解释性」。 2. 动态重排序上下文工程不相信原始检索结果的排序。它强调在信息进入模型 Context 之前，必须经过一道「提纯」工序。通过轻量级模型对检索到的 Top-N 结果进行二次评估，剔除与当前指令逻辑无关的干扰项，从而防止模型在长文本中迷失。二、状态同步：将外部执行环境实时映射到模型认知一个成熟的 Agent 不应该只生活在对话框里。上下文工程的第二个核心，是将「物理环境」实时映射到模型的认知中。 1. 实时系统镜像 Cline 和 Manus 的实践表明，上下文工程需要将文件树、终端输出、甚至当前的 UI 状态实时地编织进 Context 中。这意味着 Context 不再是静态的文本，而是一个动态更新的「仪表盘」。模型执行完一步操作后，环境反馈（成功、报错或输出结果）必须第一时间、以标准化的格式追随在 Context 末端。 2. 目标回响与任务锚定在长路径任务中，模型容易产生「漂移」。优秀的上下文工程会在 Context 的关键位置（如对话末尾或系统提示词中）反复锚定当前的主线目标。这种技术被称为「目标回响」，它能确保模型在处理复杂的子任务时，始终记得最初的用户意图。三、动态剪裁：通过修剪冗余记忆来维持长效逻辑上下文空间是昂贵的，且存在「上下文腐化」现象。随着对话轮数增加，早期的无用探索信息会干扰后续决策。 1. 自动化压缩与状态蒸馏 Ampcode 和 Cline 提倡一种「熵减」策略。当上下文接近预设阈值时，系统会自动触发「蒸馏」机制：将历史的琐碎细节进行逻辑总结，仅保留关键事实和最终结论。这种方式能将原本冗长的上下文通过「滑动总结」转化为精炼的记忆点。 2. 上下文分叉与任务隔离针对复杂的问题，上下文工程会采取「分叉」策略。当主任务衍生出独立的子任务时，系统会克隆一个干净的上下文环境给子任务，只携带必要的全局变量，从而实现任务间的干扰隔离，防止不同逻辑线索在同一个 Context 窗口中相互碰撞。四、性能加速：利用缓存机制平衡响应速度与成本最后是关于执行效能。上下文工程不仅要解决「准不准」的问题，还要解决「快不快」和「贵不贵」。 1. 提示词缓存这是 Anthropic 等厂商近期推动的最核心工程化进步。在上下文工程中，大量的前置信息（如系统提示、项目基座代码、常用库文档）在不同轮次间是重复的。通过将这些「前缀内容」进行缓存，模型在处理新输入时无需重新计算重复部分的注意力权重。这不仅大幅缩短了首字生成的延迟，更直接降低了推理成本。 2. 极简线程与 KV 缓存复用 Manus 等团队强调「追加式」上下文。通过精心设计上下文的结构，使得每一轮新的交互都是在前一轮的基础上进行线性追加，而非重写。这种工程手段能最大限度地复用服务器端的 KV 缓存，让 Agent 在面对大规模代码库时，依然能保持毫秒级的响应反馈。总结：上下文工程的终极目标上下文工程的本质，是为 AI Agent 构建一套具备「感知、筛选、精炼与持久化」能力的动态内存系统。 · 提纯解决了「看什么」的问题。 · 同步解决了「看多广」的问题。 · 治理解决了「看多准」的问题。 · 效能解决了「看多快」的问题。

4周前

⚡⚡⚡ Gemini 3 Flash 发布 🚀 核心定位：速度与智能的完美平衡 Gemini 3 Flash 的核心理念是"Frontier Intelligence Built for Speed"。它并非仅仅是一个轻量级模型，而是继承了 Gemini 3 系列强大的推理能力，同时保持了极低的延迟和成本。 · 性能越级：它的表现甚至超越了上一代的顶级模型 Gemini 2.5 Pro。 · 极致效率：在处理日常任务时，平均使用的 token 数量比 Gemini 2.5 Pro 少 30%，且速度快 3 倍。 · 成本优势：价格极具竞争力（输入每百万 token $0.50，输出每百万 token $3.00），性价比极高。 📊 关键技术指标 Gemini 3 Flash 在多个权威基准测试中展现了惊人的实力： · 推理能力：在 GPQA Diamond 测试中达到 90.4%，在 MMMU Pro 中达到 81.2%，媲美甚至超越了许多更大参数的模型。 · 代码能力：在 SWE-bench Verified 中得分 78%，击败了 Gemini 2.5 系列和 Gemini 3 Pro，非常适合构建代码助手和高频交互应用。 🌍 全面开放与应用场景 Google 已将该模型全面推向各类用户： 1. 大众用户： · Gemini App：现已成为默认模型，所有用户均可免费体验。 · Google 搜索（AI Mode）：为搜索中的 AI 概览提供支持，能够快速解析复杂问题并提供实时、直观的答案。 · 多模态体验：支持实时分析视频、图像，甚至在你绘图时实时理解意图，或通过语音指令在几分钟内生成应用程序原型。 2. 开发者与企业： · 通过 Google AI Studio、Vertex AI 和新的智能体开发平台 Google Antigravity 提供服务。 · 特别适合需要低延迟、高响应速度的场景，如实时视频分析、游戏内助手、A/B 测试实验设计等。 · 已有 JetBrains、Figma 等知名公司将其用于生产环境。

1个月前

OpenAI 如何利用 Codex，仅仅 4个人、28天从零构建发布 Sora Android 版本，给咱们什么启发？核心成就与背景 · 极速开发：在短短 4 周（10.8~11.5）内，一个小型的 4 人工程团队配合 Codex 完成了从原型到全球发布的开发工作。 · 高质量交付：App 发布后即登顶 Play Store 榜首，首日生成超百万视频，且保持了 99.9% 的无崩溃率。 · 资源消耗：整个过程消耗了约 5B token。开发哲学：打破“布鲁克斯定律” “布鲁克斯定律”：向进度落后的软件项目增加人力，只会让进度更慢。OpenAI 没有通过增加人力来应对紧迫的发布时间，而是通过为每位工程师配备 Codex 来成倍提升个人产出。如何高效使用 Codex？ OpenAI 将 Codex 视为一位 “刚入职的高级工程师”，摸索出了一套高效的人机协作模式： 1. 建立上下文： · Codex 虽然精通代码，但不懂团队的架构规范和产品直觉。 · 团队通过在代码库中维护大量的 AGENT. md 文件，明确编码规范，让 Codex 能够“入乡随俗”。 2. 先规划，后编码： · 不直接丢给 Codex 任务，而是先让它阅读代码并生成一份“微型设计文档”或实施计划。 · 人类工程师审查并修正计划后，再让 Codex 执行。这避免了方向性错误，也让代码审查更轻松。 3. 跨平台开发的“翻译官”： · 利用已有的 iOS 代码库作为参照。 · Codex 擅长阅读 Swift 代码并将其逻辑“翻译”为 Android Kotlin 代码，实现了逻辑复用，被团队戏称为“未来的跨平台框架”。 4. 分布式工程管理： · 工程师同时运行多个 Codex 会话（例如一个写播放器，一个写搜索，一个写测试）。 · 工程师的角色从“独奏者”转变为“指挥家”，主要负责架构决策、Code Review 和系统集成。核心洞察与未来展望 · AI 并不减少对严谨性的要求：相反，它增加了对系统设计和架构能力的要求。AI 可以快速产出代码，但人类必须确立正确的“地基”和“结构”。 · 工作重心的转移：软件工程的重心从编写样板代码转移到了架构设计、用户体验和复杂系统权衡上。 · 新常态：这种 AI 辅助的开发循环已成为他们默认的工作方式，展示了未来软件工程的新形态。 OpenAI 原文

1个月前

⚡⚡⚡ Gemini 3.0 Flash 真的要来了

1个月前

第一次经历了需要向开户行邮件提交合同、交易内容、证明交易内容合法性，之后才能审核放款 😂 上上周做了一个面向开发者的 AI 工具调查问卷，报酬是 500 元人民币，甲方推荐用 ***oneer（避免有推广嫌疑，不提全名）手续费低周期短，如果直接转到国内银行卡周期很长手续费很高，还需要参与个税报税，听下来合理，我就选择了注册这个平台，也在平台上绑定了国内的银行卡。注册比较顺利，甲方支付也守时，一天内就在这个平台到账，然后显示正在支付到我的银行卡了，按甲方说一天内就能到账，不过我等了大概 4-5 天还是没动静。今天早上突然收到银行短信「您的涉外收入款由开户行处理，请联系开户行」。给开户行打了电话，就开始了上面那个过程。银行工作人员要求提交合作的合同、合作的交易内容、这个内容是否合法等一系列的证明，我把往来邮件、调查问卷的发放和提交记录、我提交的收款信息、收款平台上的各种记录都发了一遍。本以为就可以了，不过银行工作人员隔一会儿打来电话，款项的证明确实没问题了，不过他们对合法性认为不明确，因为涉及到搭🪜才能完成一些事情，那你是怎么完成的呢？还好我把邮件中的内容做了一遍检查，把涉及到🪜的内容做了一些调整，因为我人在深圳，所以即使每天去香港，听起来也是合理的，这才算是勉强过关，有惊无险。倒不是金额有多大，只是感觉国内银行卡能收国外款项的成功率，怎么说呢，香港的卡能早办就早办，不要抱不惜要的幻想，出了问题，吃亏的永远是咱们这些弱势的个人。

1个月前

再次分享谷歌的 AI 学习平台「Google Skills」 —— Build AI skills for tomorrow, today! Google Skills 是 Google 推出的一个整合型在线学习平台。帮助开发者、数据专家以及技术从业者“构建面向未来的技能（Build AI skills for tomorrow, today）”。不同于以往分散的学习资源，Google Skills 似乎正在成为 Google 前沿技术教育的统一入口，目前主要聚焦于 AI、Cloud 以及 DeepMind 等高精尖技术领域的知识普及与实战训练。核心内容板块 · 生成式 AI：这是当前的重中之重。涵盖了从基础概念到 Gemini 模型应用、提示词工程、以及利用 Vertex AI 构建应用的全流程。 · Google Cloud 云计算：提供基于 GCP 的架构、部署、数据分析等传统强项课程。 · 机器学习：包括 TensorFlow、图像处理、NLP 等深度技术栈。学习体系与认证机制 Google Skills 设计了阶梯式的学习路径，兼顾了从入门到专家级的不同需求： · Learning Paths：将多门课程串联，针对特定岗位或技能（如“生成式 AI 应用开发”）提供系统化指导。 · Skill Badges：侧重实战，学员需在云端实验环境中完成具体操作挑战，通过后获得徽章。 · Certifications：行业认可度极高的职业资格认证。 · Certificates：面向入门者，帮助解锁新的职业路径，无需先修条件。平台特色与优势 · 实战导向：平台不仅仅是视频教学，极度强调“动手做”。它集成了 Google Cloud 的实验环境，让学习者在真实的云控制台中练习，这对于掌握技术至关重要。 · 紧跟 Google 最新技术栈：内容更新极快，例如针对 Gemini 多模态模型、Vertex AI Studio 等最新工具的课程都能第一时间在平台上找到。 · 面向个人与团队：既服务于寻求自我提升的个人开发者，也为企业团队提供人才培养解决方案，强调通过动手实践提高员工留存率和技能水平。 Google Skills

1个月前

2026年软件工程师求职生存指南 2023年那套成为软件工程师的方法，到了2026年将不再适用。随着 AI 的普及，单纯“写代码”的能力正在贬值，市场对人才的需求发生了根本性转变。核心现状：初级岗位的消失与角色的转变 · 严峻现实：初级工程师的岗位正在大幅减少。根据预测，超过50%的开放职位将集中在高级及以上水平。 · 根本原因：AI 大幅提高了代码生成的效率。企业不再需要大量初级工程师来“写代码”，而是需要能驾驭 AI、做架构决策、并在 AI 生成代码后进行审查和修正的人。 · 角色定义：未来的工程师不再是“代码工人”，而是“AI 领航员”。你需要指导 AI 完成工作，而不是自己从零敲每一行代码。应对策略：成为“T 型人才” 为了在竞争中脱颖而出，视频提出了“T 型”发展策略： · 一横（广度）：你需要对各种技术栈有广泛的认知。了解分布式系统、前端、后端等各个模块是如何协作的。为什么重要？只有具备全局视野，你才能精准地向 AI 提问，并判断 AI 给出的方案是否合理。 · 一竖（深度）：在某一特定领域拥有无法被轻易替代的深度专业知识。三条推荐的高潜力高价值赛道路径一：AI 工程师 · 内容：不是指研发大模型本身，而是指应用层的开发。例如构建 RAG 系统、设计 Agent 工作流、优化 Prompt 等。 · 优势：目前很多公司有预算却不知道怎么落地 AI 应用，这个领域人才缺口巨大，且可以直接调用现成的 API（如OpenAI, Anthropic）进行开发，门槛相对合理。路径二：云工程 · 内容：涉及云计算基础设施的搭建与维护。 · 优势：所有的 AI 应用都需要运行在云端，对算力和稳定性的需求只增不减。这是 AI 时代的“卖铲子”生意，非常稳健。路径三：移动开发 · 内容：iOS 或 Android 应用开发。 · 优势：相比 Web 前端，移动端的开发环境更封闭、更复杂，目前 AI 自动化生成的完整度还不如 Web 端高，因此人类工程师的价值依然很难被完全替代。给求职者的具体建议 · 不要只学语法：不要再纠结于背诵编程语言的语法细节，AI 比你更擅长这个。 · 提升决策力：把重点放在“什么是一个好的架构”、“系统可能在哪里出问题”以及“如何解决复杂问题”上。 · 动手实战：不要纸上谈兵，要利用现有的 AI 工具去构建真实的项目。 Youtube 视频在这：

1个月前

X 剧场又开演了😂 一个是周六晚上 9:02, 一个是周一晚上 9:15

1个月前

最近用美团、京东、天猫这些 App，都有一种很不好的体验，平台在刻意的推直播模式，我看到一个商品想看详情时，多半进去是直播，我要退出选其他商品或在直播间点某个很小的按钮才能看到图文的详情。可我真我只是想看图文，甚至纯文字的详情，特别是参数规格这些，直播模式，一个主播在那讲，对我一点用都没有啊。。所以直播电商到底为什么成为了更主流的电商购物方式呢？直播的内容给购买者带来了什么？除了价格更低，有直播专属优惠？

1个月前

最近一个月集中看工作机会，接触了不少的猎头，可能接触过的 + 新接触的，有 10 个左右。真实的感受到了能力的参差，电话一分钟内，就会有很明显的感受，当然只是我的感受。感受好的猎头，是那种能快速简要的讲明白企业是谁，企业为什么要人，要什么样的人，也能通过明确的问答从我这里获取企业关注的信息，做有效匹配；后续跟进过程中不会打扰很多，关键节点和关键信息能同步到位，最后环节能换位思考帮你输出参考信息，并在薪资这种敏感信息中起到很好的缓冲作用。而感受不好的猎头，基本上上面所有都做不到，很典型的特点就是特别特别喜欢给你打电话，打电话还很难输出有效信息，更多的需要我自己补充提问、帮他总结、主动提供信息。感觉他打电话只是为了工作流程的正确，和后续对领导汇报时的资料完整 😂 是不是中国的猎头门槛太低了，甚至比早些年培训机构培训几个月就能上岗的程序员都低。。

1个月前

在 Anthropic Engineering 博客里学「上下文工程」上下文工程的定义不仅仅是决定“给模型看什么”，而是设计一套能够自我净化、动态加载、且具备容错能力的交互环境。传统的提示词工程是“教模型说话”，而高级的上下文工程是“给模型设计一个高效的工作空间”。在这个空间里，资料是按需取用的，工具是智能的，工作记录是自动化的。净化上下文：对抗“上下文污染” 随着任务变长，上下文窗口面临的最大敌人不是“容量不够”，而是“噪声太多”。 1. 工具定义的瘦身（Advanced Tool Use）： · 痛点：以前为了让 Agent 能干很多事，我们会把几十个工具的定义全塞进 System Prompt，导致还没开始聊天，几万 Token 就没了。 · 解法 - 工具检索 (Tool Search)：像搜索引擎一样。Agent 只需要知道“我有一个工具库”，需要时它会搜索“查天气的工具”，系统再动态把具体工具定义加载进来。（用算力换空间） 2. 中间过程的隐藏（Programmatic Tool Calling）： · 痛点：比如 Agent 要分析一个 10MB 的日志文件。如果它用传统的“读取-思考-读取”循环，所有的原始日志数据都会污染上下文，导致模型注意力分散。 · 解法 - 代码即思维：让 Agent 编写一段 Python 代码去后台跑。Agent 只看代码运行的最终结果（比如“发现 3 个错误”），而不看那 10MB 的原始数据。（用代码执行隔离噪声）稳定上下文：构建“锚点”与“接力” 在长达数小时甚至数天的任务中（Long-running Tasks），模型会“疲劳”甚至“失忆”。如何解决？ 1. 双重 Agent 架构 (The Harness)： · Initializer Agent（架构师）：任务开始时，第一个 Agent 只负责“搭架子”。它不写具体代码，而是创建一个全局规划文件（如 feature_list.json）和进度日志（progress.txt）。 · Coding Agent（搬砖工）：后续的 Agent 接手时，不需要从头读几万字的聊天记录。它只需要读“架构师”留下的那几个关键文件（锚点），就能立刻知道“我是谁，我在哪，我要干什么”。 2. 外部存储即记忆： · 不要指望模型能记住刚才改了哪个文件的第几行。 · Git 是最好的记忆体：强制 Agent 在每做完一个小任务后提交 Git Commit。这样，即使上下文重置，Agent 通过 git log 就能完美找回记忆。增强上下文：更聪明的“输入” 在输入端，我们要追求极致的“信噪比”。 1. 用例子代替说明书 (Tool Use Examples)： · 与其用大段文字解释“这个工具的参数 date 需要是 YYYY-MM-DD 格式，且不能早于今天...”，不如直接给模型展示 3 个正确的 JSON 调用示例。模型对“模仿”的悟性远高于“阅读理解”。 2. 自适应的系统提示词： · 系统提示词不应是一成不变的。它应该包含对当前“环境状态”的即时快照（比如当前工作目录在哪里、上一步测试通过了没有）。总结：上下文工程的三层结构结合 Anthropic 的全套工程实践，我们可以将上下文工程分为三个层级： 1. 基础层（静态优化）：也就是最初提到的“Goldilocks Zone”提示词、结构化 XML、清晰的工具定义。这是基本功。 2. 战术层（动态管理）：引入即时检索、工具搜索和压缩技术。让上下文像现代计算机的 RAM 一样，频繁地换入换出数据，始终保持高效率。 3. 战略层（全生命周期架构）：利用框架、Git/Files 和代码执行来隔离复杂性。让 Agent 即使经过 100 轮对话，依然能通过外部锚点保持“清醒”。

1个月前

[论文解读] DeepSeek-V3.2 技术报告：通过架构创新和高效训练策略，在推理能力和智能体表现上，追平甚至超越同期的顶尖闭源模型，同时大幅降低计算成本架构突破：DeepSeek 稀疏注意力机制 (DSA) 这是模型最核心的底层创新。传统大模型在处理长文本时，计算量会随着文本长度呈爆炸式增长，导致速度慢且成本高昂。 · 技术原理：DeepSeek 提出了一种“稀疏注意力”机制。不同于以往模型需要“全盘扫描”所有信息，DSA 能够让模型智能地识别并聚焦于关键信息片段，忽略无关的噪音。 · 实际价值：这种机制在保持模型理解能力不下降的前提下，将计算复杂度从几何级数增长降低到了线性水平。简单来说，它让模型在处理海量信息时，既快又准，且显著降低了算力门槛。训练策略：大规模强化学习与专家蒸馏为了提升模型的“智商”，特别是逻辑推理和数学解题能力，论文展示了一套全新的训练流程。 · 专家分化与融合：团队并没有直接训练一个全能模型，而是先训练了多个在特定领域（如数学、编程、逻辑推理）达到极致水平的“专家模型”。 · 知识蒸馏：随后利用这些专家模型生成的优质数据，配合大规模强化学习算法，将这些能力“传授”给 DeepSeek-V3.2 主模型。这种“集百家之长”的策略，使得通用模型也能拥有特定领域的深度推理能力。智能体能力：合成数据构建演练场针对大模型不仅要“会说话”还要“会做事”（即使用工具、操控软件）的需求，论文提出了一种创新的数据生成方法。 · 模拟演练：团队通过算法合成构建了超过 1800 种复杂的虚拟任务场景，涵盖了从简单的日程安排到复杂的代码调试。 · 强化训练：模型在这些高难度的模拟环境中反复进行“试错-反馈-优化”的训练。这极大增强了模型在现实世界中调用工具、遵循复杂指令的鲁棒性。性能表现与行业评估 · 顶尖竞赛水平：在 2025 年的国际数学奥林匹克（IMO）和国际信息学奥林匹克（IOI）中，该模型均达到了金牌水准，证明了其在硬核理科领域的深厚功底。 · 比肩闭源巨头：在多项权威基准测试中，其综合推理能力与谷歌的 Gemini-3.0-Pro 持平，并在部分复杂任务上优于 GPT-5。阅读论文原文

1个月前

一代人有一代人的英文缩写 😂 这两天看到有人把 Prompt Engineering 缩写为 PE，虽不理解但还能接受。再看到 Vibe Coding 被缩写为 VC/VB 还是感觉不能接受了，天王老子来了，VC 也是 Visual C++，VB 也是 Visual Basic，不接受反驳...

1个月前

两年前开通 X 账号，大概今年初满足了创作者收入分成的条件？记不清了，好像曝光更早满足，但认证关注者一直不够。满足条件后，一直也没有去开通认证，好像对 Stripe/Paypal 这种国外支付产品有天然的畏惧，总感觉中国的身份证是一种不可被接受的存在，另外也是觉得我的曝光和活跃度，应该也没多少钱，就搁置在那了。最近连续几次和国外团队合作，总会涉及到付款问题（这里先略去手残把 Paypal 搞封号，$200 阵亡 😂），想想还是要面对这个问题，不能总是逃避和忽略它，刚好看到有朋友推荐开通 Stripe 认证的攻略，复制下来让 Grok 给我整理了一遍操作步骤，其中几个点还挺必要的： · 用护照，不用身份证 · VPN 全局，这样才能触发 Stripe 认证 · 去香港申请银行卡，不光 Stripe，很多地方都有用 · 提供信息用英文，提供网站和其他补充信息也尽量不用国内网站和信息先尝试把这笔存款（应该是积累了一年多？）拿到，后面每个月估计会回归几十刀的状态，就当抵扣 X 订阅费了，更重要的还是把国外更常用的首付款方式跑通，避免成为合作的瓶颈，毕竟英语的瓶颈已经很难受了 😂

1个月前

[深度实战总结] 如何构建高效稳定的 AI Agent 很多 AI Agent 之所以让人觉得“笨”，不是因为模型不够聪明，而是因为它们缺乏执行力。为了解决这个问题，制定一个包含四个核心要素的“体检清单”。只要补齐这四块短板，AI Agent 的表现就会从“人工智障”进化为“得力助手”。 1. 真正“活”的记忆 (Structured Memory) 很多 Agent 只有短暂的“上下文窗口”或简单的对话摘要，这远远不够。 · 核心问题：Agent 经常重蹈覆辙，因为它不记得自己刚才试过什么、错在哪里。 · 解决方案：需要建立结构化的记忆库，明确记录四样东西： 1. 发生了什么（事实记录） 2. 做出了什么决定（决策逻辑） 3. 哪里失败了（错误日志） 4. 下次应该避免什么（避坑指南） · 效果：只有记住了“坑”在哪里，Agent 才能避免在同一个地方跌倒两次，实现自我修正。 2. 没有任何歧义的工具 (Explicit Tools) 不要指望 AI 能靠“猜”来完美使用工具。 · 核心问题：大多数开发者给出的工具定义太模糊，导致 Agent 在选择工具或处理参数时不知所措。 · 解决方案：必须像编写严谨的代码一样定义工具，明确告知 Agent： · 这个工具具体是干什么的？ · 什么情况下才该用它？ · 一个标准的输出结果长什么样？ · 效果：消除了猜测的空间，Agent 的推理逻辑就会变得非常清晰、稳定。 3. 极度具体的目标 (Specific Goals) 模糊的指令是 Agent 的噩梦。 · 核心问题：像“帮帮用户”、“回答问题”这种指令虽然听起来很友好，但对 Agent 来说毫无指导意义，会导致它在执行时漫无目的。 · 解决方案：目标必须是可执行、可衡量、流程化的。 ❌ 错误示范：“处理这个文件。” ✅ 正确示范：“提取字段 A 和 B，验证缺失值，转换为 JSON 格式，并提交数据包。” · 效果：明确的结构化目标能强制 Agent 按照既定轨道思考和行动。 4. 完备的容错机制 (Recovery Paths) 区分“业余作品”和“专业产品”的分水岭。 · 核心问题：很多 Agent 一旦某个工具调用失败，整个流程就直接崩盘。 · 解决方案：必须为 Agent 设计“B 计划”。 · 重试机制：失败了再试一次。 · 降级方案：最好的工具用不了，有没有备用的？ · 自我诊断：让 Agent 能够分析“刚才为什么错了”。 · 效果：即使局部出现故障，Agent 依然能从错误中恢复，继续完成任务，而不是直接“死机”。