👋 Welcome to fisherdaddy’s blog!
- 精心翻译的优质博客内容
- 前沿技术分享
- 认知分享
📚 博客内容:
- 翻译: 精选国外优质博客文章,涵盖编程、人工智能、产品、运营等多个领域。
- 分享: 探索各种前沿技术,从编程语言到软件开发,从云计算到人工智能。
- 认知: 结合自身经验和思考,分享对科技、生活、学习等方面的独到见解。
👋 Welcome to fisherdaddy’s blog!
📚 博客内容:
Varick Agents CTO Eyad Khrais 吃到上一篇 Claude Code 入门文章:The complete claude code tutorial 的红利后(在 X 上大受欢迎,总阅读量接近 500 万),又迅速写了第二篇 Claude Code 进阶的文章:The claude code tutorial level 2。这篇文章的核心在于介绍 Skills(技能)、Subagents(子智能体)和 MCP connectors(MCP 连接器)这三大高级功能。 关键细节 Skills(技能):教导 Claude 特定工作流 定义与结构:Skill 是一个 Markdown 文件,包含 YAML 头信息(名称、描述)和具体的指令正文。 创建方式:在 ~/.claude/skills/ 目录下创建文件夹和 SKILL.md 文件。 工作原理:采用“渐进式披露”原则。Claude 启动时仅加载 Skill 的名称和描述(约 100 tokens),只有在判定相关时才加载完整指令。这允许用户拥有数十个技能而不占用过多上下文。 应用场景:代码审查标准、Git 提交信息规范(如 Conventional Commits)、数据库查询模式、API 文档格式等。 Subagents(子智能体):隔离上下文与任务分发 核心优势:解决上下文退化问题。主对话将复杂任务委托给子智能体,子智能体在独立的 200K 窗口中运行,仅返回摘要给主对话,从而防止主上下文被污染。 内置类型: Explore:快速、只读的代码库搜索与分析。 Plan:用于规划模式下的研究和架构决策。 General-purpose:处理需要多步操作的复杂任务。 自定义智能体:用户可在 ~/.claude/agents/ 中定义自定义智能体(如安全审查员),设定特定的系统提示词和工具权限(如只读或读写)。 通信模式:主智能体委托任务 -> 子智能体执行 -> 子智能体返回摘要。注意:子智能体不能再生成子智能体。 MCP Connectors(模型上下文协议):连接外部世界 功能:一种标准化的接口,允许 AI 模型直接调用外部工具和数据源,无需为每个工具单独集成。 操作命令:使用 claude mcp add --transport http <name> <url> 添加连接。 推荐集成: GitHub:管理代码库、PR 和 Issue。 Slack:读取频道历史和摘要。 PostgreSQL:直接查询数据库。 Linear/Jira:集成任务跟踪。 实际效果:将原本需要切换 5 个标签页(查看 Issue、设计图、Slack 讨论、写代码、更新工单)的工作流,整合为一个连续的会话。 原文:The claude code tutorial level 2 这是官方 Claude Code 教程的第二部分,我将涵盖更高级的概念,帮助你更充分地利用 Claude Code。如果你还没读过第一部分,我强烈建议你在读这篇文章之前先读一下。这篇文章直接建立在那些基础之上。...
本文整理自 Varick Agents CTO Eyad Khrais 发布的文章:The complete claude code tutorial 作者 Eyad 结合其 7 年的软件工程经验指出,使用 Claude Code 等 AI 工具时,最大的错误是直接开始输入或生成代码。成功的关键在于先进行架构规划和系统设计,通过与 AI 的深度对话确定方案,而非单向指令。 AI 模型是无状态的,输出质量完全取决于输入的质量。如果 Claude 的表现不佳,通常是因为用户的提示词(Prompt)模糊、缺乏上下文或架构指令不明确。掌握清晰的沟通技巧和约束条件是提升效率的核心。 高效使用 Claude Code 需要精细化管理上下文窗口,利用 .clauderc 文件进行项目级配置,并灵活运用 MCP 和 Hooks 等高级功能来实现自动化和系统化集成,而非仅仅将其作为一次性问答工具。 关键细节 规划模式(Plan Mode)的重要性 先思考再输入:直接生成代码往往效果不佳。建议先进入“计划模式”(按两次 Shift+Tab),花时间与 AI 讨论架构、端到端状态和调试思路。 双向对话:不应只是单向下达指令,而应与 ChatGPT 、 Gemini 或 Claude 进行深入的来回对话,共同确定系统设计方案。 核心配置文件 .clauderc 的使用技巧 作为入职文档: .clauderc 是一个 Markdown 文件, Claude 在每次会话前都会读取。它应像给“失忆后的自己”写的笔记,而非给新员工的文档。 保持精简: Claude 只能可靠地遵循约 150 到 200 条指令。文件内容应简短且与项目高度相关,避免无关信息。 解释“为什么”:告诉 Claude 指令背后的原因(例如:“使用 TypeScript 严格模式是因为我们曾遇到隐式类型导致的生产错误”),这能帮助模型做出更好的判断。 持续更新:将其视为活文档,一旦发现需要重复纠正 AI 某件事,就应立即将其加入配置文件。 上下文窗口管理的艺术 性能衰减点:模型性能在上下文使用率达到 20-40% 时就开始下降,而不是 100% 。 会话隔离:每个功能或任务应开启一个新的会话,避免上下文混杂。 外部记忆:对于复杂任务,让 Claude 将计划和进度写入外部文件,以便跨会话读取。 复制粘贴重置法(The copy-paste reset):当上下文臃肿时,复制关键信息,运行 /compact 或 /clear 清空上下文,然后只粘贴最关键的内容,以恢复模型智商。 提示词与沟通策略 具体明确:避免模糊指令(如“构建一个认证系统”),应提供具体的技术栈、存储方式和中间件要求。 设定负面约束:明确告诉 Claude 不要过度设计或添加不必要的抽象,特别是对于 Claude 4....
本文整理自 2026 年 1 月 10 日,在由清华大学基础模型北京市重点实验室、智谱 AI 发起的 AGI-Next 前沿峰会上的一场含金量极高的闭门会:唐杰/杨植麟/林俊旸/姚顺雨罕见同台,“基模四杰”开聊中国AGI。以下内容由我和 Gemini 3 Pro 共同整理完成。 由清华大学和智谱AI发起的AGI-Next前沿峰会上,当下中国大模型最核心的四股力量罕见地凑齐了:刚刚敲钟港股的智谱AI创始人唐杰、腾讯CEO办公室新任首席科学家姚顺雨(前OpenAI研究员)、拥有全球最强开源生态的阿里通义负责人林俊旸,以及刚拿了5亿美元融资的月之暗面CEO杨植麟。 如果说2025年是中国大模型靠“快节奏迭代”和“疯狂开源”在国际上博得声量的一年,那么站在2026的开端,这四位掌舵人却显得格外冷静,甚至有些“悲观”。 唐杰一上来就给全场泼了盆冷水:“别觉得差距缩小了。美国还有大量闭源模型没放出来,中美大模型的差距,说不定并没有缩小。” 在这个定调下,这场对话没有客套的商业互吹,只有关于技术路线的真实分歧和对未来的硬核预判。 一、 Chat时代结束了,下一注押在哪? 对于过去的2025年,唐杰有一个断言:DeepSeek出来之后,关于“Chat(对话)”这一范式的探索已经结束了。 智谱的一年前的预判是Chat会替代搜索,但结果是谷歌自己革了自己的命。对于大模型公司而言,继续卷对话已经没有意义。智谱把新的筹码(Bet)全部押在Coding(代码)和Reasoning(推理)上。集推理、Agentic能力于一体的GLM-4.5,就是这一策略的产物。 而作为“Scaling Law(缩放定律)”的忠实信徒,杨植麟依然坚持Scaling是重点。但他眼中的Scaling不再是单纯的一力降十会,而是要讲究**“Taste(品味)”**。 “通过架构和数据层面的改进,我们要让模型拥有不同的Taste,这样才不会千篇一律。”杨植麟认为,未来的竞争不看谁的参数更大,而看**Token Efficiency(Token效率)和Long Context(长文本)**的结合——即在长语境下,你的模型到底比别人强多少。 唐杰对此表示赞同。那种疯狂堆算力、堆RL(强化学习)就能获得巨大收益的日子已经过去了。他提出了一个新的衡量标准:Intelligence Efficiency(智能效率)。在这个新阶段,算这笔账很重要:投入多少算力,甚至能不能用更少的Scaling,换来同等的智力提升? 二、 To B 还是 To C?分化已经开始 前OpenAI研究员、现任腾讯核心科学家的姚顺雨,带来了极其敏锐的硅谷视角。他发现,大模型领域正在经历一场剧烈的分化。 “Chat”在To C端已经到了瓶颈。 姚顺雨举了个生动的例子:你今天问ChatGPT“我该吃什么”,和去年问它,体验差别并不大。因为对普通用户来说,模型的抽象代数能力变强了,你根本感知不到。C端用户需要的不是更强的模型,而是更丰富的Context(上下文)和Environment(环境)——比如模型知道今天很冷,知道你老婆想吃辣,这才能给出好建议。 但在To B端,逻辑完全相反。“智能越高,生产力越高,赚的钱越多。” 姚顺雨观察到,美国企业愿意为最强的模型付溢价。一个月200美金的最强模型,和50美金的次强模型,企业会毫不犹豫选前者。因为OpenAI 4.5可能做对9个任务,差一点的模型只能做对6个,为了这3个的差距,企业还得雇人去监控,得不偿失。 阿里通义的林俊旸则认为,这种分化是自然发生的。他提到了Anthropic(Claude的开发商),这家公司之所以成功,不是因为为了做Coding而做Coding,而是因为他们频繁和企业客户交流,发现企业的真实需求就是Coding。 “现在美国API消耗量里,Coding占了绝对主导。但在中国,Coding的Token消耗量还没那么大。”林俊旸一针见血地指出。 三、 下一个圣杯:自主学习与“主动”AI 硅谷现在最火的词是什么?姚顺雨透露,大街小巷的咖啡馆都在聊**“自主学习”**。 这并不是什么科幻概念,而是正在发生的事实。Cursor每几个小时就用最新的用户数据训练;Claude 95%的代码已经是Claude自己写的了。 “这更像是一种渐变,而不是突变。”姚顺雨认为,2026年我们最大的挑战是想象力:如果AI真的实现了自主学习,它应该长什么样?是一个自动赚钱的交易系统,还是解决了一个人类未解的科学难题? 林俊旸则更关注AI的**“主动性”**。 现在的AI无论是ChatGPT还是各种Agent,都需要人类去Prompt(提示)才能启动。未来的AI,能不能环境就是Prompt?它看到环境变化,就自己决定去做事? “但我最担心的不是AI说错话,而是它做错事。”林俊旸坦言,如果AI突然产生一个想法,觉得应该往会场扔个炸弹,这就是灾难。如何让AI既有主动性又安全,是比提升智力更难的课题。 四、 20%的胜率,与“穷人的创新” 在对话的最后,主持人李广密抛出了一个尖锐的问题:三五年后,全球最领先的AI公司是中国团队的概率有多大? 向来敢说的林俊旸给出了一个数字:20%。 “这已经非常乐观了。”他解释道,中美在算力上的差距是客观存在的,甚至可能有1-2个数量级的差异。美国的巨头可以用大量的算力去探索下一代Research,而中国的团队光是做交付,可能就占用了绝大部分算力。 但他同时也提到了一个有趣的观点:“穷则思变”。 正因为算力吃紧,中国团队必须要在算法和Infra(基础设施)的联合优化上下苦功夫。这种**“穷人的创新”**,反而可能在特定路径上跑出来。他回忆起2021年和做芯片的同事“鸡同鸭讲”的经历,大家都因为认知错位错失了机会,但现在,软硬结合的创新或许是打破僵局的关键。 姚顺雨则对中国的人才充满信心。他认为,只要一个技术路径被证明是可行的(比如预训练),中国团队能以极高的效率复现并局部优化。真正的挑战在于:我们是否有勇气去探索那些不确定性极高、没人做过的新范式? “中国对于刷榜或者数字看得太重了。”姚顺雨提到DeepSeek的一个优点,就是他们不太关注榜单,只关注什么是正确的事。 结语 这场闭门会没有给出“中国AI必胜”的廉价鸡血,却展现了一种理性的韧性。 正如学术界代表杨强教授所言,AI的发展就像人类睡觉,需要清理噪音才能第二天学得更好。而唐杰的总结则更为从容: “永远不要想着环境是最好的。我们恰恰是幸运的,经历了环境从没那么好到变好的过程。如果我们笨笨地坚持,也许走到最后的就是我们。” 2026,中国大模型正在告别盲目的“卷”,走向更务实的“深”。
本文翻译自 Anthropic 官方技术博客:Demystifying evals for AI agents。 主要观点 有效的评估(Evals)是团队自信地发布 AI Agent 的基础。与单轮对话的 LLM 不同,Agent 涉及多轮交互、工具调用和状态修改,这使得它们更难评估。缺乏评估会导致团队陷入被动的“打地鼠”模式,仅能在生产环境中发现问题。相反,建立评估体系能让问题在早期显现,量化改进效果,并促进产品与研究团队的协作。 一个完整的评估体系包括任务(Task)、评分器(Grader)、评估工具(Harness)和数据集(Suite)。针对不同类型的 Agent(如代码、对话、研究、计算机操作),需要采用不同的评估策略。评分器通常结合了基于代码的确定性检查、基于模型的灵活评分(LLM-as-judge)以及人工审核,以平衡速度、成本和准确性。 构建评估体系不需要一开始就追求完美。文章提出了一个实用的路线图:从少量的现实失败案例开始,逐步建立无歧义的任务集,设计稳健的测试环境和评分逻辑,并长期维护。重要的是要结合自动化评估、生产监控、A/B 测试和人工审查,形成一个多层次的质量保障网络(类似瑞士奶酪模型),以全面理解 Agent 的性能。 关键细节 核心定义与组件 构建 Agent 评估时涉及以下关键概念: Task (任务):具有定义输入和成功标准的单个测试用例。 Trial (尝试):对任务的一次执行,通常需要多次运行以应对非确定性。 Grader (评分器):对 Agent 表现进行打分的逻辑,可包含多个断言。 Transcript (实录):完整的交互记录,包括输出、工具调用和推理过程。 Outcome (结果):试验结束时环境的最终状态(例如数据库中是否存在预定记录)。 不同类型 Agent 的评估策略 Coding Agents:通常使用确定性评分器。例如 SWE-bench Verified 通过运行单元测试来验证代码修复是否成功。 Conversational Agents:侧重于交互质量和任务完成度。常使用 LLM 模拟用户进行多轮对话,并结合状态检查(如工单是否解决)和语气评分。 Research Agents:评估较为主观。策略包括检查内容的依据性(Groundedness)、覆盖率(Coverage)和来源质量。 Computer Use Agents:在沙盒环境中运行,通过检查截图或 DOM 状态来验证结果。例如 WebArena 和 OSWorld。 评分器类型 基于代码 (Code-based):如字符串匹配、静态分析。优点是快速、便宜、客观;缺点是缺乏灵活性。 基于模型 (Model-based):如 LLM 评分量表。优点是灵活、能捕捉细微差别;缺点是成本较高,需人工校准。 人工评分 (Human):专家审查。优点是质量金标准;缺点是昂贵且慢,通常用于校准模型评分器。 处理非确定性与指标 由于 Agent 行为在不同运行间存在差异,文章提出了两个关键指标:...
Similarweb 发布截止到 2026 年 1 月 2 日的最新 AI 应用 Web 端访问数据。注意:该 PDF 文档中提到的增长率都是“基于域名级别(domain level)的 total visits(总访问量)”,“不包含 API 使用或集成”,可以简单的理解为这是 Desktop 与 Mobile Web 两端的 web 访问量统计。 OpenAI 的至暗时刻与谷歌的翻盘 OpenAI 2025 年太惨了,被 Google 按在地上摩擦。 ChatGPT 流量也从年初的 86.7%,降低为现在的 64.5%,可以预见的是今年大概率继续被 Gemini 蚕食。 反观 Gemini 从年初的 5.7% 来到现在的 21.5% 排名第二。马斯克的 Grok 和 DeepSeek 流量相当都在 3.5 %左右,并列第三。 Anthropic 因为核心精力都在 toB 上面,toC 应用 Claude 2025 年整体流量变化不大,从年初的 1.5% 升至年底的 2%。但考虑到 Claude Code 的成功,2026 年 如果 Claude Code 和 Claude 本身集成较好的好,机会也非常大。...
2025 年 3 月 5 日,一家在武汉的创业公司蝴蝶效应发布一款 Agent 产品: Manus,该产品能够调度不同的工具解决复杂问题,其在 GAIA 等基准测试中表现出 SOTA 的性能。该产品一经发布便引发国内外的关注和讨论,火爆程度堪比 DeepSeek R1 的盛况。 2025 年 12 月 17 日,Manus 宣布年度经常性收入(ARR)已突破 1 亿美元。消耗总 token 量超过 147万亿 token,创建了超过 8000 万台虚拟计算机。 2025 年 12 月 30 日,Meta 以 20 亿美元收购 Manus 的公司蝴蝶效应。收购完成后,蝴蝶效应公司将保持独立运作,创始人肖弘出任 Meta 副总裁。 配图来自于2025 年 7 月 Manus 团队对谈 YouTube 联合创始人陈士骏。左起依次为:季逸超(Manus 联合创始人、首席科学家)、肖弘(Manus 创始人兼 CEO)、陈士骏、张涛(Manus 联合创始人,产品负责人) 本文整理自 Manus 被 Meta 收购前对外接受的最后一次专访,张小珺对谈季逸超(Peak):Manus’ Final Interview Before the Acquisition: Oh, the Surreal Odyssey of 2025。这篇访谈长达 3 小时 31 分钟,季逸超的分享畅汗淋漓,信息量超大,虽然本文能让你快速了解其中的核心输出和认知,但我还是建议大家去看原视频,开 1....
2022年 11 月 30 日 ChatGPT 横空出世已经过去 3 年了,2023 年 OpenAI 再次给世界一震撼,重磅发布了 GPT-4,而2024 年 OpenAI 仍然一枝独秀,给 AI 的发展带来了两个新的方向,一个是视频生成,一个是推理范式,前者的代表是 Sora,后者的代表是 o1。时间来到 2025 年,OpenAI 终于不再一枝独秀,迎来众多挑战者,全球 AI 可以说是呈现百花齐放的状态,有 Google 和 Anthropic 等闭源模型的兴起,有 DeepSeek、Qwen、Kimi、GLM、Minimax、Mistral 等开源模型的觉醒,当然也有 Llama 4 开源模型的落寞。 本文将按照时间顺序带你一起回顾一下 2025 年 AI 圈每一个核心大事件、技术突破及社会影响。 DeepSeek R1 火爆全球 2024 年 12 月 6日,OpenAI 重磅发布 o1 系列推理模型,把大模型的发展从仅使用系统 1 思维(快速、自动、直观、容易出错)发展到系统 2 思维(缓慢、深思熟虑、有意识、可靠)。而就在 2025 年 1 月 20 日,中国 AI 创业公司 DeepSeek(深度求索)发布了其最新一代开源模型 DeepSeek R1,该模型也是一个推理模型,在基准测试中其表现与 OpenAI 的 o1 模型相当,但价格却显著低于 o1(大概是其 1/30)。这一事件迅速在全球科技界引发了海啸般的反应,被西方媒体和战略分析师称为 AI 领域的“斯普特尼克时刻”(Sputnik Moment)。R1 不仅在性能上紧追 OpenAI 的顶尖闭源模型,更重要的是,它打破了关于大模型训练成本的固有认知。...
2025年12月15日· Martin Alderson 过去十五年,我们目睹了软件吞噬世界。整个行业被软件吞没——零售、媒体、金融——只要你说得出来的,在过去几十年里都经历了 SaaS 工具激增带来的惊人颠覆。这催生了大量 SaaS 公司——总估值达数万亿美元。 在我上一篇关于软件成本是否因 AI 编程智能体而下降 90% 的文章中,我主要关注了市场的供应端。如果这个假设成立,SaaS 工具的需求端会发生什么?我一直在思考软件工程变革带来的这些二阶和三阶效应。 “自建还是购买”(build vs buy)的权衡考量开始发生变化。软件吞噬了世界。智能体将要吞噬 SaaS。 我看到的信号 最明显的起点就是需求开始蒸发——尤其是对于“更简单”的 SaaS 工具。我相信许多软件工程师已经开始意识到这一点——很多我以前会考虑寻找免费增值或付费服务来做的事情,现在我经常可以让智能体在几分钟内完全按照我想要的方式解决。有趣的是,我甚至没有注意到这种转变。它就这样发生了。 如果我想要一个内部仪表板,我甚至不会觉得 Retool 或类似工具会让它更容易。我直接构建仪表板。如果我需要在媒体摄取过程中重新编码视频,我只需让 Claude Code 编写一个围绕 ffmpeg 的健壮封装器——而不必承担将原始文件发送到单独服务的成本(和速度损耗),也不必担心触及层级限制或试图在脑海中适应另一个 API 的心智模型。 对于不那么纯粹的软件开发任务,这一点更为明显。例如,我已经让 Gemini 3 在几分钟内生成了非常高质量的 UI/UX 原型图和线框图——不需要使用单独的服务或寻找起始模板。同样,当我想做演示文稿时,我不需要使用平台来美化幻灯片——我只需让 Claude Code 将我的 markdown 导出为设计精美的 PDF。 我开始看到的另一个可能影响更大的转变是,人们真的开始质疑大型“企业级” SaaS 公司的续约报价。虽然这还处于非常早期的阶段,但我相信这是一个非常重要的新兴行为。我现在已经看到几个例子:SaaS 供应商 X 发来了他们惯常的年度两位数百分比的涨价通知,而现在团队开始问:“我们真的需要支付这笔钱吗,还是我们可以自己构建所需的功能?”一年前,这充其量是一个很快会被否定掉的假设性问题。现在,这是一个人们正在投入真正精力去思考的现实选项。 最后,大多数 SaaS 产品包含许多客户并不需要或不使用的功能。SaaS 产品工程的许多复杂性在于管理这一点——当你只有一个客户(你的组织)时,这种复杂性一夜之间就消失了。同样,当客户就是开发者本人时,这个客户拥有路线图的完全控制权。不用再指望 SaaS 供应商将你的请求优先于其他客户。 维护方面的异议 对此的主要异议是“谁来维护这些应用程序?”。这是一个真实且正确的异议。软件有 bug 需要修复,有扩展问题需要解决,有安全漏洞需要修补,这一点没有改变。 我认为首先需要指出的是,很多 SaaS 维护得很差(根据我的经验,往往越贵质量越差)。通常,安全风险来自于需要连接和交互内部数据的外部第三方本身。如果你能将所有这些都移到现有的 VPN 或访问解决方案之后,你会突然大幅减少组织的攻击面。 最重要的是,智能体本身极大地降低了维护成本。我遇到过一些最痛苦的维护任务——从弃用的库更新到另一个支持更好的库——通过智能体变得容易多了,特别是在静态类型的编程生态系统中。此外,公司构建内部工具最大的顾虑是只有一个人了解所有内容——如果他们离开,所有的内部知识也就随之而去。智能体不会离职。而且通过一个考虑周全的 AGENTS.md 文件,它们可以向未来的任何人解释代码库。 最后,SaaS 同样伴随着维护问题。我这个月从一位朋友那里看到的一个最近的爆发点是,一家 SaaS 公司决定弃用他们现有的 API 端点并转移到另一套 API,而新 API 并没有提供所有相同的方法。由于这是一个核心系统,这是一个巨大的问题,需要大量的资源来更新、测试和推出受影响的集成。...
本文翻译自 A16z 联合创始人 Marc Andreessen 在 2011年 8 月 20 号发布的文章 Why Software Is Eating the World。 本周,惠普(我是其董事会成员)宣布正在探索剥离其陷入困境的 PC 业务,转而更大力地投资于软件领域,因其在那里看到了更好的增长潜力。与此同时,谷歌计划收购手机制造商摩托罗拉移动(Motorola Mobility)。这两项举措都震惊了科技界。但这两项举措也都符合我观察到的一个趋势,这个趋势让我对美国乃至世界经济的未来增长感到乐观,尽管最近股市动荡不安。 简而言之,软件正在吞噬世界。 在 1990 年代互联网泡沫达到顶峰十多年后,大约十几家新的互联网公司,如 Facebook 和 Twitter,正在硅谷引发争议,因为它们快速增长的私募市场估值,乃至偶尔成功的 IPO。由于 Webvan 和 Pets.com 鼎盛时期的伤痕在投资者心中记忆犹新,人们在问:“这难道不只是一个危险的新泡沫吗?” 我和其他一些人一直在提出相反的论点。(我是风险投资公司 Andreessen-Horowitz 的联合创始人兼普通合伙人,该公司投资了 Facebook、Groupon、Skype、Twitter、Zynga 和 Foursquare 等公司。我个人也是 LinkedIn 的投资者。)我们认为,许多杰出的新互联网公司正在建立真实的、高增长、高利润、高防御性的业务。 如今的股市实际上讨厌科技,这一点从各大上市科技公司创历史新低的市盈率(price/earnings ratios)就可以看出来。例如,苹果公司(Apple)的 比率约为 15.2——与整个股票市场大致相同,尽管苹果公司拥有巨大的盈利能力和主导的市场地位(苹果在过去几周按市值计算已成为美国最大的公司,超过了埃克森美孚)。而且,也许最能说明问题的是,当人们不断高喊“泡沫!”时,你就不可能真正处于泡沫之中。 但是,太多的争论仍然围绕着财务估值,而不是硅谷最优秀的新公司潜在的内在价值。我自己的理论是,我们正处于一场深刻而广泛的技术和经济变革之中,软件公司正准备接管经济的广阔领域。 越来越多的大型企业和行业正在依靠软件运行,并作为在线服务交付——从电影到农业再到国防。许多赢家是硅谷式的创业型科技公司,它们正在侵入并颠覆既有的行业结构。在未来 10 年,我预计会有更多行业被软件颠覆,而在更多情况下,进行颠覆的将是新的、世界一流的硅谷公司。 为什么现在会发生这种情况? 计算机革命已过去六十年,微处理器发明已过去四十年,现代互联网崛起也已二十年,所有通过软件改造行业所需的技术终于成熟,并且可以在全球范围内广泛交付。 现在有超过 20 亿人使用宽带互联网,而十年前,当我在我共同创立的 Netscape 公司时,这个数字也许只有 5000 万。在未来 10 年,我预计全球至少有 50 亿人拥有智能手机,让每个拥有这种手机的人都能在每天的每一刻即时访问互联网的全部功能。 在后端,软件编程工具和基于互联网的服务使在许多行业中创办新的全球性软件驱动型初创企业变得很容易——无需投资新基础设施和培训新员工。在 2000 年,当我的合伙人 Ben Horowitz 担任第一家云计算公司 Loudcloud 的 CEO 时,一个客户运行基本互联网应用的成本约为每月 150,000 美元。如今在亚马逊(Amazon)的云上运行同样的应用,每月花费约 1,500 美元。...
本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享:Don’t Build Agents, Build Skills Instead。 Anthropic 这帮工程师真的非常高产,继创造了 MCP 协议、Claude Code 编码 Agent 后,又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求,比如: MCP 协议的提出是因为解决模型与异构数据源(如本地文件、SaaS工具)连接的碎片化与标准化难题; Claude Code 创造是因为突破对话框的限制,让 AI 直接深入本地开发环境,实现从“阅读代码”到“执行构建”的自主闭环。 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块,让 Agent 拥有长期的“肌肉记忆”,避免在重复任务中反复进行低效的 Prompt 引导。 以下是本次分享的核心内容,由我和 Gemini 3 Pro 共同整理而成。 代码就是这一层通用的接口 以前我们有个误区,觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent,肯定需要完全不同的工具和脚手架,甚至得为每个用例单独造一个 Agent。 但后来我们发布了 Claude Code(我们的第一个编程 Agent),搞着搞着发现:原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景,它其实是连接数字世界的通用接口。 想象一下生成一份财务报告:模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程,其实只需要极薄的一层脚手架(Bash 和文件系统)就能搞定。 智商 300 的天才 vs....