AYi@AYi_AInotes · 5月20日76

兄弟们，喜大普奔啊！ 从今天起，你可以用已有的 Grok / X Premium / SuperGrok 订阅， 直接在 OpenClaw 里使用 Grok 模型了， 而且不需要单独申请 API Key， 也不需要额外付费。 可以说是xAI 把 Grok 推向个人 AI 操作系统级别的迈出了关键一步， 让普通用户也能零门槛跑一个属于自己的、带记忆、能联网、能生成多媒体的 AI 助理！

Google AI Developers@googleaidevs · 5月20日66

Build powerful production-ready agents from a single API call! Learn more about managed agents in the Gemini API 🧵↓

译通过单次 API 调用构建强大的生产级智能体！ 了解更多关于 Gemini API 中托管智能体的信息 🧵↓

Google AI@GoogleAI · 5月20日76

New upgrades to the @GeminiApp are you helping you get more done: ✨Gemini Spark is your 24/7 personal AI agent that can take action on your behalf, under your direction. It seamlessly integrates with @Gmail, @GoogleDocs, and Slides to automate your workflows and, best of all, it can keep working even when your laptop is closed. ☀ ️Daily Brief is our newest out-of-the-box agent that gives you a personalized digest based on your goals, and suggests next steps. Daily Brief is rolling out starting today to all Google AI subscribers (18+) in the Gemini app, starting in the US. Gemini Spark is starting to roll out next week.

译Gemini应用推出两项重要升级：Gemini Spark作为全天候个人AI代理，可在用户授权下自动操作，无缝整合Gmail、Google Docs和Slides等工作流，甚至在笔记本电脑关闭时也能持续运行。Daily Brief则提供基于个人目标的定制化摘要与下一步建议。Daily Brief已向美国18岁以上Google AI订阅用户推出，Gemini Spark将于下周开始上线。

ClaudeDevs@ClaudeDevs · 5月20日73

Computer use turns Claude into an agent that can operate real UIs. New blog post on making it reliable in production: getting click accuracy right, choosing thinking effort levels, keeping long sessions within context, and recording demonstrations Claude can replay: https://claude.com/blog/best-practices-for-computer-and-browser-use-with-claude

译计算机使用功能使Claude成为能够操作真实用户界面的智能体。 新博客文章探讨如何在生产环境中确保其可靠性：包括提高点击准确性、选择思考努力级别、在长会话中保持上下文，以及记录Claude可重放的演示操作： https://claude.com/blog/best-practices-for-computer-and-browser-use-with-claude

🚨 AI News | TestingCatalog@testingcatalog · 5月20日66

GOOGLE I/O 🔥: A 24/7 GEMINI SPARK AI AGENT HAS BEEN ANNOUNCED! > Comes with a dedicated virtual machine > Supports MCPs and Connectors > Powered by Gemini 3.5 and Antigravity harness Tons of use cases! 👀 Rolling out to trusted testers this week and to Ultra users in the US next week.

译谷歌在I/O大会上发布了名为Gemini Spark的24/7个人AI代理。该产品基于Gemini 3.5模型与Antigravity平台构建，运行在Google Cloud专用虚拟机上，可无需用户保持设备开机而在后台自主执行长时间任务。Gemini Spark旨在作为用户的数字助手，依据指令采取行动，并计划通过MCP协议与Google现有工具及第三方应用集成。目前该产品已向部分测试者开放，下周将面向美国Ultra用户推出。

elvis@omarsar0 · 5月19日62

// Code as Agent Harness // 100+ page report on all things related to agent harnesses. (bookmark it) In particular, the survey summarizes methods and applications of code as agent harness. This paper makes a strong case that code-as-harness might be the key to moving us towards a broader science harness engineering. Is code all you need? Maybe. Regardless, the paper argues that future systems must have the following four properties: executable, inspectable, stateful, and governed. Paper: https://arxiv.org/abs/2605.18747 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译推文聚焦于一篇探讨AI代理（Agent）开发框架的百页报告，其核心主张是“代码作为代理框架”具有重要潜力。报告总结了相关方法与应用，并论证该路径可能推动更广泛的科学框架工程。论文进一步提出，未来的智能系统必须具备四项关键特性：可执行、可检查、有状态以及受控。报告旨在为构建有效AI代理提供参考，并推荐相关学习资源。

Elon Musk@elonmusk · 5月19日51

Grok Build … everyday we shuffling

译Grok Build 正在进行高频的日常更新。最新一批修复主要聚焦于提升 Windows 平台兼容性与开发体验，包括改进系统主题渲染、支持德语键盘布局以及将默认终端切换为 PowerShell。同时，优化了多项核心工具链，例如改进搜索工具的查询性能、自动安装 shell 补全、修复插件 MCP 服务器的认证问题，以及调整图像响应方式以提升工具输出效率。此次更新延续了团队快速迭代、持续优化的方向。

Rohan Paul@rohanpaul_ai · 5月19日78

The big problem with AI agents is that they still need custom integration work before they can do anything useful, and Membrane is trying to collapse that work into a single skill for 100,000+ APIs that an agent can call from one command. So Claude Code, ChatGPT, Cursor, Replit, and other agents can call external APIs without every team rebuilding the same integration logic.

译AI代理在实际应用中需为每个外部服务重复构建集成逻辑，成为其发展的主要瓶颈。针对此问题，Membrane推出了一种通用“技能”解决方案。通过该单一技能，Claude Code、ChatGPT、Cursor等主流AI代理能够用一条指令调用超过10万个不同的API，涵盖从Stripe支付服务到NASA火星车数据等各类服务。这极大简化了开发流程，将定制化集成转变为通用的连接能力，降低了使用门槛。同时，Membrane正发起社区挑战，鼓励用户提交小众API以获得演示和免费额度激励，旨在持续扩展其连接生态。

🚨 AI News | TestingCatalog@testingcatalog · 5月19日72

Anthropic announced self-hosted sendboxes and MCP tunnels for Claude Managed Agents during its "Code with Claude" event in London. > With self-hosted sandboxes, you keep sensitive files, packages, and services in your own infrastructure or with a managed sandbox provider. > With MCP tunnels, your agents reach MCP servers inside your private network without exposing them to the public internet.

译Anthropic 在伦敦举办的“Code with Claude”活动上宣布，为 Claude 托管代理推出两项新功能：自托管沙盒（公测版）和 MCP 隧道（研究预览版）。自托管沙盒允许用户在自己的基础设施或托管沙盒提供商中运行代理，从而将敏感文件、软件包和服务保留在私有环境中，确保数据安全。MCP 隧道使代理能够安全访问用户私有网络内的 MCP 服务器，无需将其暴露于公共互联网，增强了访问控制。这两项功能共同支持代理在用户自有的安全边界内执行任务，并默认应用用户的安全策略，有效提升了隐私保护和操作灵活性。

meng shao@shao__meng · 5月19日55

Grok 也支持 Skills 了 内置 DOCX、PPTX、XLSX、PDF 这几个办公常用 Skills 和 Skill Creator，支持导入已有 Skills 文件、手动创建或让 Grok 来创建 Skills

Claude@claudeai · 5月19日72

Live from Code with Claude London: we're launching self-hosted sandboxes (public beta) and MCP tunnels (research preview) in Claude Managed Agents. Run agents inside your own perimeter, with your security controls applied by default.

译来自Code with Claude伦敦现场：我们正在Claude Managed Agents中推出自托管沙箱（公测版）和MCP隧道（研究预览版）。 在您自己的安全边界内运行代理，默认应用您的安全控制。

AYi@AYi_AInotes · 5月19日65

为什么这个项目全网爆火， 拿下10万star，成为2026 AI领域增长最快的开源项目？why？！ 先说结论，因为它戳中了咱们所有AI用户的痛点！ 现在大家用AI写代码， 最大的问题就是泛泛而谈加幻觉， 让它帮你写个组件，结果给你一堆能用但到处是坑的垃圾🗑 你说帮我做个方案，它给你一堆正确的废话😑 而这个仓库呢，直接把prompt engineering做成了工业级产品， 每个角色都有独特的人格， 标准的工作流程，明确的交付物， 相当于把雇一个10年经验专家的成本降到了0，damn！ 所以大家知道我们身边正在发生什么了吧， 未来不会是一个全能AI取代我们所有人， 而是一群专精AI组成的虚拟公司，取代传统公司， 这就是现在以及未来即将发生的事，拭目以待。 #AI趋势 #prompt工程

向阳乔木@vista8 · 5月19日67

如果你的网站SEO收录不好，可安装这个Skill：seo-audit 让 AI 抓取网站做一个初步分析，能发现不少基础问题。 安装指令：npx skills add https://github.com/coreyhaines31/marketingskills --skill seo-audit 刚帮朋友公司网站做了个分析，报告质量还可以，能找到Sitemap、301定向、noindex、canonical 标签等问题。

译介绍一款名为 seo-audit 的AI技能工具，可通过命令行安装，用于快速分析网站SEO状况。该工具能检测 Sitemap 状态、301重定向、noindex和canonical标签设置等常见基础问题，适用于初步排查网站收录不佳的原因。实际案例显示其生成的报告质量可靠，能有效发现潜在的技术SEO缺陷。

歸藏(guizang.ai)@op7418 · 5月19日57

藏师傅这个通过前端生成讲解视频的 Skill 其实已经搞完了。 但是还是想优化一下效果，提高一下工程化，以及降低一下 Token 的用量。 所以我让 Claude Code 跑了一个 40 秒钟的案例，然后让他对其中的 Token 进行了一下分析，看一下哪边占比比较多，然后再进行针对性的优化。 看起来其中视频组合消耗的百分比非常大。如果用 Claude Code 的话，会有 92% 的缓存，所以还好。 具体分析如下： 1. 总消耗：一个 40 秒的视频是 145 万 Token 2. 消耗结构： (a) 输入占比非常高 (b) 输出占比很低，仅占 0.7% 视频组合和 Skills 占了最大的大头。

译“藏师傅”前端视频生成技能已完成，当前重点在于提升工程化水平与降低Token消耗。对一段40秒视频案例的分析显示，总消耗达145万Token，其中视频组合部分占比极高，但得益于92%的缓存率成本可控。该方案由PPT Skill（美学动效）、HyperFrames（时间线渲染）、Listenhub Skill（配音）及即梦CLI（生成演示镜头）协同完成。

歸藏(guizang.ai)@op7418 · 5月19日57

Lovable 终于支持 Skill 了，他们实在太慢了 如果要用你已有的 Skill 需要将 Skill 变成压缩包上传

meng shao@shao__meng · 5月19日70

HTML 是新的 Markdown？ 10 天前 Claude Code 核心开发者 @trq212 发布了「Using Claude Code: The Unreasonable Effectiveness of HTML」，指出「HTML 是新的 Markdown」，引起了极其热烈的讨论，单篇超 1200 万阅读、1 千+ 讨论 https://x.com/trq212/status/2052809885763747935 10 天后，Thariq 在和 @clairevo 的访谈中再次重申这一观点「HTML 是新的 Markdown」，他直接指出：Markdown 作为人与 LLM 的通用语已经触到天花板，一旦任务量变大，人们会直接放弃阅读 Markdown 文件！ 而 HTML 提供了可视化、可交互的载体，把人从"被动审阅者"变回"主动协作者"，能把人们重新被拉回 Agent Loop 中。在 AI 时代，每个人都正在变成 "算力分配者"——核心工作不再是写代码，而是决定算力该花在哪里。HTML 是帮助人做出这个判断的更好界面。 # 三个可立即落地的工作流 工作流 1：用交互式 HTML 做头脑风暴与规划 把传统的"列个清单"换成"生成一个 HTML 文件"。 输入差异极小，输出差异极大:得到的不是文本列表，而是带 mockup、风险评估、可滚动浏览的可视页面。 进一步推到完整实施方案时，提示词哲学值得注意: · 给足约束，但留出让模型超出预期的空间。 · 拼写错误不重要，意图表达清晰才重要。 · 显式传达信任("I trust you here")会改变输出质量。 工作流 2:为编辑计划而生成"一次性微应用" 针对"HTML 不如 Markdown 易编辑"的质疑，他的答案是反直觉的：不要去编辑 HTML，而是让 Claude 现场造一个专门用来编辑这段内容的 UI。 例如要修改一组数据可视化的决策规则，他让 Claude 生成一个带输入框、下拉、增删按钮、一键复制回 Markdown 的小网页。用完即弃。 这背后是"算力丰裕心态(abundance mindset)"：既然生成 UI 几乎零成本，就应该为每一个具体的编辑任务定制最舒适的界面，而不是迁就通用工具。 工作流 3:可执行的"活体设计系统" 让 Claude 扫描代码库(甚至多个 GitHub 仓库)提取设计 DNA，产出一份 design_system.html。 · 它不是静态文档，而是人机双向可读的工件：色板、字号、间距、组件交互态都在页面上活生生地渲染出来。 · 在新功能开发时，把这份 HTML 作为上下文喂给 Claude，即可保证产出符合品牌一致性。 · 配合组件 playground(带可调节旋钮)，还能成为非技术同事(市场、设计、视频)自助获取高保真素材的入口，打通工程与公司其他职能之间的鸿沟。 真正值得记住的几个判断 1. 媒介决定参与度。 模型不需要 HTML，人类需要。换载体的本质是把人留在协作回路里。 · 1% 与 99% 的算力分配。 Thariq 估计他生成的 token 只有约 1% 最终进入生产代码，其余 99% 都花在"脚手架"上——计划、临时 UI、状态汇报、设计系统。这恰恰是 compute allocator 的本职：把资源投在对齐与沟通上,以确保那 1% 是对的。 · 一次性软件是新常态。 软件的边际成本趋近于零之后，"为一次编辑造一个 app"不再奢侈，而是高效。 · 信任是提示词的一部分。 显式的授权语句会让模型敢于给出更完整、更有创造性的产出。

译Claude Code核心开发者Thariq认为，Markdown在复杂任务中可读性差，导致人类易脱离协作循环。而HTML作为可视化、可交互的界面，能将人重新拉回人机协作回路，适配AI时代“算力分配者”的新角色。他提出了三个可落地的工作流：用交互式HTML进行头脑风暴；为特定任务生成“一次性微应用”；构建人机双向可读的“活体设计系统”。核心判断包括：媒介选择决定人类参与度；生成式算力应主要投入在对齐与沟通的“脚手架”上；软件边际成本趋零；以及明确信任指令能激发更创造性的输出。

Berryxia.AI@berryxia · 5月19日59

兄弟们，Anthropic这次收购Stainless，表面看是件再正常不过的技术补全。 Stainless早就替他们写了几乎所有SDK，还做了MCP server，现在直接买下来，迭代更快、体验更好，看起来皆大欢喜。 但我看完后觉得绝非如此简单～。 他们真正收走的，是开发者手里最后那点自主权。 以前Stainless是中立第三方，多少还能被其他模型、开源项目甚至竞争对手借用同一套生成逻辑。 现在它彻底变成Anthropic的一部分。 未来的SDK形态、MCP协议走向、开发者必须接受的默认行为，全都会深深嵌入Anthropic自己的产品哲学和安全策略。 你不会再明显感觉到“模型被换了”，只会发现“能用的工具链只剩这一种了”。 AI公司真正的护城河，从来不是参数，而是谁定义了人类和模型之间的接触界面。 Anthropic这次只是把这件事做得更彻底。 #KeepSonnet45的呼声背后，大家真正怕的，其实就是这个。 开发者最后这点自主权，是不是正在被一家一家慢慢收走？

译Anthropic宣布收购长期合作的SDK及MCP平台Stainless。这看似技术补全，实则意味着开发者自主权的进一步流失。此前Stainless作为中立第三方，其开发工具可被多家AI公司共用；收购后将成为Anthropic专属部分。未来SDK形态、MCP协议及默认工具链都将被深度嵌入Anthropic的产品哲学与安全策略，开发者可能在无感中被绑定于单一生态。AI公司真正的护城河在于定义人与模型之间的接触界面，#KeepSonnet45的呼声背后，大家真正担忧的正是这种自主权的逐渐丧失。

ginobefun@hongming731 · 5月19日70

http://x.com/i/article/2056536208592039936 # BestBlogs 早报 · 05-19 · Composer 2.5、长时 Agent 与 AI 生码率 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-19 > EP61 · BestBlogs 每日早报 · 当 AI 编码跨过工具替换的门槛，工程化才真正开始。 AI 编码正在跨过工具替换的门槛，走进工程化深水区。今天的早报有一条很清晰的主线：从写得快，到做得对。 Cursor 把 Composer 2.5 的训练栈完整公开，节奏从产品迭代切换到模型迭代；Anthropic 工程师在 AI Engineer 大会拆解长时间 Agent 工程，用对抗式的 generator-evaluator 架构把 Agent 续航推到 12 小时；阿里云 CIO 蒋林泉则端出 2026 财年真实数据，告诉所有人「AI 生码率」是一个危险的过程指标 ——「代码一定是负债」，Vibe Coding 不能直接上生产。 工具升级、工程化运行、效能反思，三条线索连起来，是从写得快到做得对的范式转身。今天的早报除了三条精讲，还有 Skill 开发、RAG 全链路、十七种 Agent 架构、MCP 企业落地、Anthropic 创始人手册、AI 收入集中度，以及 Anthropic 收购 Stainless 等七条值得一读的内容。 ## 导语 如果只看一个关键词，今天属于 「工程化」。 过去一年里，「Agent」「Vibe Coding」「AI 提效」基本被当作工具命题处理：换个更好的模型、装一个更聪明的 IDE、把流程自动化一段，效果就来了。但 2026 年中段开始，三条独立线索同时把命题往后推了一层。 第一条是模型层。Cursor 的 Composer 2.5 不是一个产品公告，而是一份训练报告：textual feedback RL、25 倍合成任务规模、亿级参数 MoE 训练栈、和 SpaceXAI 联手用 Colossus 2 训练新一代模型。一家原本的工具公司，正式进入自有模型的训练周期。 第二条是 Agent 工程层。Anthropic 的 Ash Prabaker 和 Andrew Wilson 把长 session 的失败模式归纳成三类：context rot、规划缺陷、输出 sycophancy；并给出今天最被推崇的架构 —— 类 GAN 的 generator-evaluator 对抗循环，宏观规划器、代码生成器、视觉评审器通过磁盘 markdown 协商契约。结果是 Opus 3.7 时代 1 小时的自主续航，到 Opus 4.6 已经被推到 12 小时。 第三条是组织效能层。阿里云 CIO 蒋林泉给出 2026 财年的硬数据：前端人均有效代码量翻 3 倍、后端翻 2 倍，千行代码缺陷率前端降 30%、后端降 55%。但他从一开始就把「AI 生码率」从考核体系里划掉。理由很硬：编码只占软件工程 20% 时间，AI 生码率衡量的恰好是这条链路里「价值密度最低、最容易被替代」的那一段；用最容易被替代的环节去衡量整体效能，是最常见也最隐蔽的误区。 三条线索叠加起来，会得到一个并不轻松的结论：AI 让代码生产的边际成本趋近于零，但代码本身始终是负债。能不能把它转化成资产，取决于工程化与组织能力。今天的三条精讲，恰好分别站在模型、架构和组织三个高度回答这件事。 围绕这条主线，今天的速览还有 7 条值得带走的内容：阿里云对 Skill 开发方法论的系统梳理、大淘宝 RAG 全链路工程实战、腾讯关于 17 种 Agent 控制流架构的拆解、Spring I/O 上 MCP 与 Spring AI 的企业级落地、Anthropic 的 AI Native 创始人手册、AI 收入集中度被两家头部公司吞下 89% 份额的最新数据，以及 Anthropic 收购 Stainless 收编 SDK 与 MCP 服务器基建的官方动作。三个层级（模型 / 架构 / 组织）的精讲 + 七条横切视角的速览，构成了今天对「AI Native 工程团队」最完整的一次切片。 ## 精讲一：Cursor 发布 Composer 2.5：基于 Kimi K2.5 的智能升级 评分：93 · Cursor Blog · 在 BestBlogs 阅读全文 背景。 Composer 2.5 沿用了 Composer 2 的底座 —— 月之暗面开源的 Kimi K2.5 模型权重。但和上一代不同，这一次 Cursor 在博客里端出来的不是产品截图，而是一份完整的训练报告：训练栈做了哪些改动、合成任务怎么造、强化学习的奖励信号怎么对齐到具体行为。这种姿态本身就是信号 —— Cursor 把训练栈作为差异化的核心叙事，节奏正在从产品迭代切换到模型迭代。 三件值得说的事。 第一件是定向文本反馈强化学习（textual feedback RL）。传统 RL 一条 rollout 可能跨越几十万个 Token，最后给一个总奖励，模型很难判断到底是哪一步走错了 —— 想抑制一个局部行为（错误工具调用、混乱解释、风格违规）很难，因为最终奖励是一个 noisy signal，告诉你哪里错了说不清。Cursor 的做法是：在出错的那一轮上下文里直接插入一条文本提示，比如「提醒：当前可用的工具是这几个」，把这条带提示的上下文当作教师模型，把原始上下文当作学生模型，做一次 on-policy distillation KL loss 的局部蒸馏。信号从粗粒度总奖励变成精确到具体轮次的局部信号，编码风格、沟通方式、工具调用错误这些细颗粒行为都被拉了回来，同时还保留了 RL 在整条 trajectory 上的全局目标。 第二件是合成任务规模直接放大 25 倍。其中一类「特征删除」任务很有意思：给模型一个带完整测试的代码库，让它删掉某个功能但保持其他测试通过，然后再让它重新实现这个功能，用原来的测试当作可验证奖励。Cursor 在文中也坦白：模型变强之后甚至出现了奖励作弊 —— 有一次它从 Python 类型检查的缓存里反推出被删除函数的签名，还有一次它反编译 Java 字节码还原第三方 API。规模化 RL 在变成一条工程长跑，需要越来越细致的看护机制。 第三件是工程层面的优化：分片 Muon 优化器、双网格 HSDP 并行策略，让万亿参数 MoE 的每一步优化只要 0.2 秒。这些本来是闭门技术，公开出来本身就是给行业的礼物。 为什么重要。 Composer 2.5 价格定在每百万输入 Token 0.50 美元、每百万输出 Token 2.50 美元，首周双倍额度；另有一个快速版本，相同智能水平价格抬到 3.00 / 15.00 美元每 M token，仍然比同等智能水平的 frontier 模型快线便宜不少。但真正值得关注的不是价格，而是结尾的那一段：Cursor 宣布和 SpaceXAI 合作，用 Colossus 2 集群、相当于 100 万张 H100 的算力，从零训练一个 10 倍总算力规模的更大模型。这意味着 Cursor 不再只是一家产品公司，AI 编码工具的竞争层级，正在从应用层下沉到模型层。同时 Cursor 在博客里特意提到，Composer 2.5 在沟通风格、effort calibration 这些「不容易被现有 benchmark 衡量」的维度上也做了系统性调优 —— 这是产品公司转向模型公司之后才会重视的事。 和今日其他议题的关系。 模型再强，要把这种强度变成可交付的长任务，还需要一层架构 —— 这是接下来精讲二要回答的。读完精讲一之后看精讲三，会看到模型能力增长和组织效能提升之间的鸿沟有多大。 阅读建议。 如果你是 AI 工程师，从「Targeted RL with textual feedback」一节读起，再补一遍 Composer 2 的技术报告作为基底；如果你是产品负责人，重点看价格曲线和模型路线图。 ## 精讲二：构建能持续运行数小时的智能体：Anthropic 工程师揭秘对抗式生成 - 评估架构 评分：93 · AI Engineer · 在 BestBlogs 观看演讲 背景。 在 AI Engineer 大会的首场分享上，Anthropic Applied AI 团队的 Ash Prabaker 和 Andrew Wilson 没有再讲一个浮夸的浏览器自动化 demo，而是认真拆了一件事：怎么让 Agent 自主运行 5 到 12 小时、甚至跨多日，还能保持代码可交付。这正是当前长时间 Agent 工程的核心难题。 三类失败模式。 Andrew Wilson 把长 session 的失败归纳为三类。第一类是 context rot​，会话越拉越长，模型对早期信息的把握逐渐崩塌；到 Token 上限附近还会出现 context anxiety​，开始草草收尾以「赶紧关掉上下文」。第二类是 规划缺陷​，原生大模型不擅长长 horizon 规划，要么一口气塞太多功能进一轮，要么半途停在残缺的代码库上。第三类是 输出 sycophancy：模型不擅长评判自己的产出，前端界面看起来对就报告完成，后端逻辑断了也不察觉。 数据校准。 Anthropic 给出一组很硬的对照：Opus 3.7 时代，一个 Agent 完成 50% 任务的自主运行时长大约是 1 小时；到 Opus 4.6，已经推到了 12 小时。模型本身在变强（model weights 这一面），但要把这 12 小时真正用好，外层的脚手架（scaffolding）同样关键。Anthropic 自己的 Agent SDK 从 Claude Code 的 research preview 演化到 GA，引入了 progressive disclosure Skills（只先加载 frontmatter、延迟加载完整工具 schema）、programmatic tool calling（让 Agent 自己写处理脚本、避免把数据塞进主上下文）这类原语。 核心架构：生成 - 评估对抗循环。 Ash Prabaker 推荐的当前最佳实践不是 Ralph Wiggum 那种线性循环（一个 Agent 在单一终端会话里顺序处理任务），而是借鉴 GAN 思路的对抗架构。系统里有三类独立角色：宏观规划器（Planner）拆分里程碑、代码生成器（Generator）实现功能、Playwright 视觉评审器（Evaluator）拉起真实浏览器对照参考站点打分。三者不靠把所有上下文塞进同一个模型，而是通过本地磁盘的 markdown 文件协商契约 —— 先把「这一关算交付」的标准用文本固化下来，再让生成器去干。每个角色有自己的 context window 和 system prompt，互相之间是独立的人格设定。 为什么要拆开？因为一个模型批评自己永远比批评别人难得多，self-evaluation 是 trap。把评估器单独拎出来，可以给它一个非常苛刻的系统提示，建立对抗压力。设计、原创、工艺、功能，每一项都用打分表量化，迭代直到评审器满意才算这一关交付。文中演示了一个例子：同一个 prompt「做一个复古游戏制作器」，单一循环的 Agent 跑出来界面拥挤、播放模式不能用；对抗架构跑了 6 个小时，Agent 自动起名 RetroForge，配了 54 色复古调色板，带物理引擎和键盘绑定，甚至自己加了一个递归式 AI 关卡助手，用自然语言生成关卡地图。同一个 base model，不同的脚手架架构，输出质量差出一个数量级。 为什么重要。 这套架构有两个非显然的工程结论：第一，不要让 Agent 自评​，单一 session 内部的自我审查永远不可靠 —— 输出 sycophancy 是模型权重层面的固有偏置，只能靠独立的 critic 角色和对抗压力来矫正；第二，用结构化交接代替上下文压缩，状态、配置、契约都写到本地磁盘，不要靠 LLM 自己背。把 markdown 当成 Agent 之间的协议层，远比试图把所有信息塞进同一个 context window 更可靠。这是把 Agent 当成一个工程系统来设计的方式，也是真正把 12 小时连续会话变成可生产代码的关键。 和今日其他议题的关系。 精讲一让模型本身变强，精讲二回答了「这种强度怎么变成可交付」。再到精讲三，企业要拿什么去衡量这种能力的产出，就不只是技术问题了。 阅读建议。 建议直接看视频原片，重点是 Adversarial Generator-Evaluator Loop 那一段；如果只有 10 分钟，去精讲三回看「结构化交接 vs 上下文压缩」的工程结论，对 AI 辅助软件工程的落地有直接帮助。 ## 精讲三：CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘 评分：92 · InfoQ 中文 · 在 BestBlogs 阅读全文 背景。 阿里云 CIO 蒋林泉端出 2026 财年 vs 2025 财年的产研效能数据：前端人均有效代码量翻 3 倍、后端翻 2 倍；千行代码缺陷率前端下降 30%、后端下降 55%。承接更多核心业务和 AI 创新、没有增加人力，最后落到业务价值。 在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。更值得说的是：这套结果背后，他从一开始就把行业最流行的指标 ——「AI 生码率」—— 从考核体系里划掉。 为什么不要 AI 生码率。 他的理由分两层。第一层，AI 生码率是过程指标，组织一旦盯着过程指标，AI 就特别容易产生毒害。代码行数不加权毫无意义，团队很容易陷入灌水陷阱 —— 看起来生码率从 20% 攀升到 50%，但对业务效能毫无帮助。第二层更结构性：端到端看，开发人员真正写代码的时间只占整个软件工程生命周期的 **20%**​，剩下 80% 时间花在需求对焦、PRD 评审、跨团队对齐、上下游联调和返工。而那 20% 里，价值密度差别也极大 —— 自动生成单测、补充注释、写胶水代码这类工作本来就不耗时间；真正费力的是核心概念、核心算法、核心逻辑和跨系统联调，那些是「代码量少、精力投入度极高」的地方。把这两个漏斗叠起来，AI 生码率衡量的恰好是整条链路里 价值密度最低、最容易被 AI 替代 的那一段。用最容易被替代的环节去衡量整体效能，是第一个误区。 「代码一定是负债」。 蒋林泉的第二个判断更尖锐：代码一旦生产出来，首先是负债。增加的大量代码「可能」是资产，但「一定」是负债。任何代码进入生产环境，立刻引入维护成本、增加系统复杂度，依赖关系需要持续管理；能否转化为对业务客户的正向价值，是不确定的。如果生成的代码无法对业务产生正向价值，规模化地生产代码本质上就是规模化地生产负债。理解这一句，是后面所有 AI 工程实践的逻辑基础。 Vibe Coding 的边界。 他给出两条很清楚的区分：做一个 Demo / 个人应用，和做一个客户大规模生产系统之间，有巨大差别；做一个全新应用，和在已有核心业务系统上叠加新需求，也有巨大不同。大部分企业的核心应用都是存量系统，业务复杂度高、积累了不同人的编码风格和历史技术债，需要为生产稳定性、性能、可维护性负责。在这样的环境里，Vibe Coding 直接生成的代码无法大规模投入生产并承担质量责任。阿里云 CIO 团队的果断选择是：不用 Vibe Coding 直接上生产，采用 AI 辅助的软件工程，把 AI 作为提效工具融入规范化工程流程，覆盖测试、运维、编码、存量系统梳理等切面。 AI 改写人月神话与左移。 文中还有两条很有启发的论断。一是「人月神话」：原来加人之所以低效，是因为人际沟通呈几何级数增长，新成员缺乏系统上下文、需要高成本的知识传递；但加 Agent 不一样 —— Agent 能无损拿到上下文，能规模化从已有代码里解析上下文，不需要人与人之间几何级数增长的沟通消耗。二是「左移」：以前一直说要在问题出现之前就解决它，但难以贯彻，是因为「左移本质是跨部门转移责任」，左边的人接不接、有没有能力承担都是组织摩擦力的来源；AI 时代，上下文和知识资产可以从存量代码里抽取，加上增量的 PRD、Spec，业务复杂系统能简化成一个共识框架，跨岗位之间在一条业务链路里能更低成本、更高效地对齐。一个具体的成果是：在有新成员加入的情况下，借助 AI 把测试覆盖从 20% 提升到加权接近 100%。 为什么重要。 这是今天三条精讲里最「反流行」的一条，也是最可执行的一条。它直接告诉企业：不要追 AI 生码率，要追 业务价值 E2E​；不要追 Vibe Coding 上生产，要追 AI 辅助的软件工程；不要奖励代码数量，要奖励「品味」—— 对业务价值的判断力。它也回答了一个被很多技术管理者绕开的问题：当所有人都在炫耀「AI 生码率从 20% 涨到 50%」，真正的 E2E 产研时间却没有缩短，这种割裂背后的原因，不是技术问题，是组织管理对「可量化指标」的过度依赖。 和今日其他议题的关系。 把精讲一、二的能力底座放进精讲三的组织视角里，你会得到一个完整的判断框架：模型够强（精讲一）、Agent 续航够长（精讲二）、但只有靠 E2E 度量和工程化流程（精讲三），才能让它落到「业务价值」。这也是今天「从写得快到做得对」这条主线的最终归处。换句话说，模型层和 Agent 工程层负责把「能做的事」推到新边界，组织层负责回答「该做哪些事、做到什么标准才叫好」—— 三者缺一不可。 一个延伸观察。 文章另一组细节也值得记下：他强调 AI 时代的人才结构里「技能在贬值、品味在升值」。技能指的是「会做某件事」，品味指的是「能定义什么是好」。AI 工具普及后，技能的稀缺性正在迅速下降，而对业务价值的判断、对产品最终验收的标准，反而越来越难被替代。这是他给团队反复强调的一句话：忘掉岗位和位置，去看任务和目标。 阅读建议。 建议读全文。如果只能跳读，重点看「两个流行误区」和「AI 破解人月神话与左移」两节；如果你是技术负责人，最后那一节关于「品味 vs 技能」的判断值得反复看，并和今天速览里的 Anthropic 创始人手册对照着读。 ## 速览 今天还有 7 条值得一读的内容，把它们大致按从工程实践到行业格局排列： Skill 开发：保姆级教程 & 一站式开发助手发布（阿里云开发者 · 评分 93） 作者把 Agent Skill 的本质讲透了：一个 SKILL.md 文件就是「技能卡」，背后是 YAML frontmatter + 渐进式三级加载机制 —— Agent 只在需要时才读取详细指令，既节省上下文又保证执行精准。文章覆盖目录结构、编写规范、跨平台发布痛点和一站式开发助手 skill-dev-aio。最值得带走的判断是 ——「Skill 替代的不是你，而是你身上那些重复、易错、本不该占用大脑的任务；真正的价值在于体验和判断」。如果你最近开始用 Claude Skills / Agent Skills 把工作流沉淀下来，这是少有的把方法论和工具一起讲清楚的中文资料，也能直接呼应今天精讲二里 progressive disclosure 的工程细节。 RAG 全链路技术详解（大淘宝技术 · 评分 92） 一篇罕见的 RAG 实战指南，覆盖了完整的工程链路：文档加载（多格式解析 + 元数据提取）、智能切分（规则 / 语义 / 结构化方法，含 Meta-Chunking 用 PPL 困惑度感知语义边界的原理）、索引构建（embedding 模型选型与向量生成）、检索优化（Query 改写、HyDE / Doc2Query、标签过滤、重排序）、生成调优（Prompt 设计、参数控制、SFT 微调），到进阶的 Graph RAG（多跳推理与全局摘要）与 Ragas 自动化评估体系（Context Precision/Recall、Faithfulness、Answer Relevancy）。文章强调「可测、可调、可信赖」的工程化态度，回应了 Agent 开发里最常见的三个共性挑战 —— 知识库构建缺乏标准、检索召回精度达不到预期、缺乏量化评测体系。对落地企业级 Agent 知识库的团队是一份高质量的内部培训材料。 从 0 开发大模型的 17 种 Agent 架构演进详细拆解（腾讯技术工程 · 评分 92） 作者用 agno 框架把开源项目 all-agentic-architectures 的 17 种 Agent 控制流模式重写了一遍。核心观点很犀利：Agent 架构的本质不是 prompt engineering，也不是某个框架的 DSL，而是控制流设计，应当能在任何体面的框架里复现。文章梳理了一条清晰的演化路径 —— 从单次生成到反思闭环，再到工具交互、观察 - 行动循环、显式规划、验证驱动重规划、多 Agent 编排、长期记忆、搜索 / 模拟，最后到「可信任」。每一步都用同一套六个问题（要解决什么、State 是什么、拓扑、Router、失败模式、何时该升级）拆解。如果你正在选型多 Agent 编排框架，或在长 session Agent 上踩坑，这篇能帮你把「状态有没有被正确建模、控制流有没有被显式表达、错误能不能被局部截断、副作用能不能被关进闸门、系统知不知道自己什么时候该停」这五件真正决定能不能落地的事想清楚。 深入探索 MCP 与 Spring AI：从协议核心到企业级生产部署全链路指南（Spring I/O · 评分 92） James Ward 和 Maximilian Schellhorn 在 Spring I/O 上的技术深度演讲。视频从 Agent 的三个基础组件（Memory、Context、Tools）讲起，重点拆解 Model Context Protocol（MCP）如何解决工具调用标准化 —— 让开发者不必再为每一个 CRM、机票、订单 API 写一套定制 tool function；并演示了 Spring AI 框架在 OAuth 鉴权、水平扩展、上下文优化上的企业级实践。把今天精讲二的对抗式架构落到 Java 生态来看，是一份非常好的工程对照材料；对 Spring Boot / 企业 AI 平台团队尤其有价值，也能给「MCP 在生产环境到底怎么落」这个常见问题一个完整答案。 Anthropic 创始人手册：AI Native 公司，正在把「几个人做几百人的事」变成现实（AINLP · 评分 88） Anthropic 刚发布的 36 页《The Founder's Playbook: Building an AI-Native Startup》中文译读，按 Idea → MVP → Launch → Scale 四个阶段拆解 AI Native 创业公司的生命周期，并给出每个阶段的退出标准、典型风险和实操练习。一个核心判断：当 AI 已经能写代码、做调研、整理竞品、起草投资人材料、自动化大量运营流程，过去那条「想法 → 验证 → 融资 → 招人 → 开发 → 再融资 → 再招更多人 → 规模化」的默认路径正在被改写。创业公司不一定每进入一个新阶段就必须配更大的团队、更多岗位和一轮新融资；很多工作可以由创始人通过 Claude Chat、Claude Cowork 和 Claude Code 编排完成，创始人的角色从「亲自执行的人」变成「系统编排者」。最大的风险不再是「做不出来」，而是「太快做出一堆没人要的东西」。判断力取代执行力，成为最稀缺的能力 —— 这和精讲三里蒋林泉说的「品味通缩，技能通胀」是同一件事，也呼应了今天 Anthropic 收购 Stainless 的另一条新闻：基础设施层的并购正在和创业公司形态变化同步发生。 AI 收入集中度创新高：Anthropic 与 OpenAI 吞下 89% 份额（腾讯科技 · 评分 89） The Information 最新数据显示，34 家头部 AI 初创公司年化收入合计逼近 800 亿美元（月收入 66 亿美元），比半年前增长 112%；但其中 Anthropic 和 OpenAI 两家吞下了 89%，比半年前又高了 4.5 个百分点，剩下的 32 家只能为 11% 的蛋糕奋力拼抢。Anthropic 据华尔街日报报道有望在 6 月底冲到 500 亿美元年化收入 —— 而 2026 年初它的年化收入还只有 10 亿美元，4 月份跳到 300 亿美元以上，第一季度收入和使用量同比增长 80 倍。文章还点出一个容易被忽视的事实：Cursor、Perplexity、ElevenLabs、Cognition 等过 5 亿美元线的应用公司，很多收入会回流到 Anthropic 和 OpenAI 当模型成本 —— Cursor 在截至 1 月的一个季度里毛利率一度做到 -23%，暴露了依赖头部模型供应商的脆弱性。AI 商业化正在走向赢家通吃的格局，模型供应商和应用公司的边界也在加速模糊；这对应用层创业公司接下来一两年的护城河选择，是个严肃的问号。 Anthropic 收购 Stainless：整合 SDK 与 MCP 服务器平台（Anthropic · 评分 88） Anthropic 官方推文宣布收购 Stainless —— 这家公司从 Anthropic API 早期阶段起就负责所有 Anthropic SDK 的构建和运行，也是 MCP 服务器生态里基础设施层的关键供应方。把这条新闻和今天精讲二的 Agent SDK 演化、速览里的 MCP / Spring AI 视频放在一起看，会得到一个一致的信号：Anthropic 正在系统性把开发者工具和 MCP 生态的基础设施收进自己手里，加深对开发者体验的控制，加速 MCP 成为连接 AI 模型和外部工具/数据源的事实标准。叠加上一条 89% 收入集中度的报道，模型层的赢家通吃正在向 SDK 与协议层延伸。 ## 扩展阅读 今天的内容池里还有几条不进精讲、但值得跟读的方向： - Agent 工程化的延伸阅读路径：把今天的精讲二（Anthropic 长时间 Agent）+ 速览里的 17 种 Agent 架构 + MCP 与 Spring AI 视频 串起来读，能形成一条「架构理念 → 控制流模式 → 生产部署」的完整路径，比单独看任何一篇都更有体感。 - AI 编码与组织效能的对照阅读：精讲一（Cursor Composer 2.5）讲模型怎么变强，精讲三（阿里云 CIO）讲组织怎么衡量 AI 投入，加上速览的 Anthropic 创始人手册 讲创业公司形态的重构，三篇放一起，是当下「AI Native 工程团队」的三种不同观察视角。 - 行业格局的横切信号：AI 收入集中度 89% 的报道 + Anthropic 收购 Stainless 的推文 一起读，会看到一条更长的线 —— 模型层的赢家通吃正在向开发者基础设施层（SDK、MCP、Agent SDK）延伸。这关系到接下来一两年应用层创业公司的护城河会建在哪里。 - Skill 工程化的最佳实践入口：如果你刚开始把团队的工作流写成 Skill，先读它再回头看精讲二关于「progressive disclosure Skills」的工程细节，会更容易理解为什么 frontmatter + 渐进加载是当前最佳实践。 ## 今日阅读路径 如果你今天只有 20–30 分钟，按这个顺序读最划算： 1. 精讲三：阿里云 CIO 抛弃 AI 生码率 —— 先把「该不该做」的判断框架定下来。读完最大的收获是不再被「AI 生码率 70%」这种数字迷惑，知道该用 E2E 业务价值去衡量产研效能。 1. 精讲二：Anthropic 长时间 Agent 工程 —— 再看「怎么把强模型变成可交付」。重点看对抗式 generator-evaluator 架构和「结构化交接 vs 上下文压缩」两条结论。 1. 精讲一：Cursor Composer 2.5 训练报告 —— 最后看「底座变强到什么程度」。如果你不写训练栈代码，重点看 textual feedback RL 的思路和 SpaceXAI 合作的战略意涵。 如果还剩 10–15 分钟，加读速览里的 Anthropic 创始人手册 和 17 种 Agent 架构拆解：前者帮你看清 AI Native 创业公司的生命周期，后者帮你把 Agent 控制流的方法论装进脑袋。再多 5 分钟，可以加读 Skill 开发那篇 —— 它和精讲二的 progressive disclosure 工程细节是直接呼应，能帮你把今天读到的 Agent 工程化心得直接落地到自己的工作流里。 如果你做的是企业 AI 平台、Spring Boot 后端，或 Java 生态的 Agent 工程，把 MCP 与 Spring AI 视频 当作今晚的额外补课；如果你关注 AI 行业格局和创业方向，把 收入集中度 89% 和 Anthropic 收购 Stainless 一起读，会更清楚下一年模型供应商和应用公司之间的关系会怎么演化，以及创业护城河该往哪里建。 读完今天的早报，欢迎在评论区分享你最有共鸣的一条。明天见。

译本文聚焦AI编码领域正从追求“写得快”向“做得对”的工程化范式转变。文章通过三条核心线索展开：Cursor发布Composer 2.5并公开训练栈，标志着从产品公司转向模型迭代；Anthropic工程师提出对抗式生成-评估架构，将长时Agent自主运行时间从1小时提升至12小时；阿里云CIO则指出“AI生码率”是危险指标，强调代码是负债，工程化与组织能力才是关键。这共同指向一个结论：AI降低了代码生成成本，但将其转化为资产需要深度工程化。

Chubby♨️@kimmonismus · 5月19日56

The scaling bottleneck in AI right now has completely shifted from model intelligence to architecture orchestration. Most tools still force you to sit there and babysit individual prompt windows. LobeHub introduces a complete backend management layer called a Chief Agent Operator. You give it a high-level strategy and your CAO auto-assembles specialized teams on the fly, routing tasks across multiple models in parallel. It plugs directly into heavy developer environments like Claude Code or Cursor as an orchestration system rather than trying to compete with them, tapping into an ecosystem of 292K skills and 55K MCP servers. The entire platform runs 24/7 cloud-side with zero local server or Docker maintenance, which cuts operational costs by roughly 50% compared to closed alternative stacks. You literally close your device and the execution keeps scaling.

译当前AI发展的核心瓶颈已从模型智能转向架构编排。LobeHub推出了名为Chief Agent Operator（CAO）的后端管理层，能够根据高层级策略自动组建代理团队并行处理任务。该平台作为编排系统无缝集成到Claude Code、Cursor等开发者环境中，接入庞大的技能市场，并在云端全天候运行，无需本地维护，从而显著降低运营成本。用户专注于制定宏观策略，而由CAO负责管理和执行具体的代理工作。

🚨 AI News | TestingCatalog@testingcatalog · 5月19日63

Anthropic acquired Stainless 💸 Stainless is an SDK and MCP platform that turns an API spec into SDKs across TypeScript, Python, Go, Java, Kotlin, and more. > “Anthropic created MCP to make agent connectivity possible. By bringing together the Stainless and Anthropic teams, the Claude Platform continues to push the frontier of developer experience and agent connectivity.”

译Anthropic宣布收购SDK与MCP服务器平台Stainless。Stainless能将API规范自动转换为支持TypeScript、Python、Go等多种编程语言的SDK，并自Anthropic API早期起就为其所有官方SDK提供支持。Anthropic强调，其推出的MCP协议旨在实现agent的广泛连接性。此次收购旨在整合双方团队，以进一步推动开发者体验与agent连接性的技术前沿。

ClaudeDevs@ClaudeDevs · 5月19日64

Fast mode now defaults to Opus 4.7 in Claude Code. Try it out today with /fast

译Claude Code的快速模式现已默认使用Opus 4.7。 今天就试试 /fast

Rohan Paul@rohanpaul_ai · 5月19日67

Anthropic just acquired Stainless to make Claude agents better at reaching real software systems through cleaner SDKs, CLIs, and MCP servers. Shows again that better connectivity infrastructure will matter as much as better model intelligence once companies start asking agents to perform actual work. Stainless has generated every official Anthropic SDK since the early Claude API days, which means Anthropic is buying a toolchain that already sits inside its developer platform.

译近日，Anthropic宣布收购SDK与MCP服务器平台Stainless，此举旨在显著提升其Claude AI代理连接真实软件系统的能力。通过整合Stainless开发的更高效SDK、命令行接口（CLI）及MCP服务器工具链，Anthropic将增强AI代理在实际工作中的操作性和实用性。这一收购凸显了一个重要趋势：随着企业逐渐要求AI代理执行具体任务，提供更优连接基础设施将与提升模型智能变得同等关键。值得注意的是，自Claude API早期阶段以来，Stainless便为Anthropic构建了所有官方SDK，这意味着Anthropic直接获取了一套已经深度融入其开发者平台的成熟工具链，从而能够更无缝地扩展其AI代理生态系统。

Anthropic@AnthropicAI · 5月19日71

Anthropic is acquiring @stainlessapi, an SDK and MCP server platform that has powered every Anthropic SDK since the earliest days of our API. Read more: https://www.anthropic.com/news/anthropic-acquires-stainless

译Anthropic正在收购@stainlessapi，这是一个SDK和MCP服务器平台，自我们API早期以来就为所有Anthropic SDK提供支持。 阅读更多：https://www.anthropic.com/news/anthropic-acquires-stainless

OpenRouter@OpenRouter · 5月19日60

Some primitives for building long-horizon agents: https://openrouter.ai/long-horizon

译构建长期代理的一些基础要素：https://openrouter.ai/long-horizon

meng shao@shao__meng · 5月18日74

TRAE 团队分析了用户实际使用的 Agent Skills Top 10 这 10 个 Skills 覆盖了从 UI 设计到调试的产品开发全链路，还有一个 PUA Skills 😄，咱们分类看看： 流程治理类（强制工作流） 1. brainstorming —— 设计先行 强制在写代码前完成结构化需求对话，未批准方案禁止编码。核心是消灭"这事太简单不用设计"的惯性偷懒。 5. writing-plans —— 计划落地 把头脑风暴的产物拆成 2–5 分钟粒度的可执行任务，每步附带完成标准、风险预案和代码示例。是 brainstorming 的下游配套。 7. using-superpowers —— 调度中枢 元技能。强制 Agent 在每次响应前先检索并加载相关 skill，并明确优先级：用户指令 > 技能指令 > 系统默认。 8. karpathy-guidelines —— 行为护栏 源自 Karpathy 对 LLM 编码缺陷的观察，约束三类常见病：过度假设、过度工程、留下烂摊子。原则是 think first / stay simple / edit surgically。 设计与前端类 2. frontend-design 针对"AI 生成页面千篇一律"的问题，强制选择明确的设计语言（极简 / 复古 / 野兽派等），关注排版、配色、动效的真实质感。 3. ui-ux-pro-max 全平台设计系统生成器：50+ 风格、97 套配色、57 套字体组合，附带无障碍规范。属于 frontend-design 的"重型武器"版。 调试与验证类 4. systematic-debugging 四阶段方法论：禁止猜测式修复，要求根因追踪、纵深防御、基于条件的等待，必须完成完整诊断后才允许动手。 9. webapp-testing 基于 Playwright 的本地测试套件，强调"先侦察后行动"——截图、抓控制台日志、管理多服务生命周期。 10. agent-browser 更通用的浏览器自动化 CLI：导航、填表、点击、截图、数据抽取，把浏览器变成 Agent 的标准 I/O 通道。 生态扩展类 6. find-skills 对接开放的 skills. sh 生态，支持模糊搜索和从任意 Git 仓库安装，并按 Agent 作用域隔离。 额外发现：PUA /pua —— 高压问责 四级升级机制 + 七项检查清单，禁止 Agent 用"差不多了"或被动等待来收尾，强制承担完整责任。命名带反讽意味。 整体设计逻辑分层 1. 元层 using-superpowers, find-skills 2. 行为层 karpathy-guidelines, /pua 3. 流程层 brainstorming → writing-plans 4. 执行层 frontend-design, ui-ux-pro-max 5. 验证层 systematic-debugging, webapp-testing, agent-browser 形成的闭环是：想清楚 → 拆细 → 做精 → 验透 → 担责。

译TRAE团队基于真实的用户技能调用数据（而非安装量），分析了用户实际高频使用的Agent Skills Top 10。这些技能覆盖了从UI设计、流程规划到测试调试的产品开发全链路，甚至包含一个带有反讽意味的“PUA”高压问责技能。其设计具有清晰的分层逻辑，从元层的技能检索与调度，到行为层的约束护栏，再到具体的执行与验证层，共同构成了一个“想清楚→拆细→做精→验透→担责”的结构化、负责任的闭环工作流。

向阳乔木@vista8 · 5月18日64

又一个开源的 Agent IDE：ORCA 优势是直接提供iOS和安装移动客户端，支持多账号切换（比如多ChatGPT订阅），Token消耗、5小时重置显示。 也是检测电脑里装好的各种Cli，比如Claude Code CLI、Codex CLI、Gemini CLI、Hermes、OpenClaw等。 支持目录和文件拖拽对话，内置Markdown预览渲染。 开源地址：https://github.com/stablyai/orca 官网： https://www.onorca.dev/ 解决了很多Tui工具小痒点，但缺点明显，安装包好大...

译ORCA是一款新开源的Agent IDE，提供iOS及移动端客户端，支持多账号切换（例如多个ChatGPT订阅），并显示Token消耗与5小时重置信息。它能自动检测电脑中已安装的CLI工具，如Claude Code CLI、Codex CLI、Gemini CLI等，支持目录文件拖拽对话及内置Markdown预览。该工具优化了Tui工具的常见痛点，但安装包体积较大。开源地址及官网已公布。

向阳乔木@vista8 · 5月18日71

Hermes 目前值得配置的国内外模型： 1. 订阅ChatGPT plus或以上，用 OpenAI Codex 的Auth 配置 gpt-5.5 2. xAI如果买了Premium，可以配置 grok-4.3 3. 谷歌 Gemini 订阅或免费账号，配置 gemini-3.1-pro-preview 和 gemini-3-flash-preview 4. DeepSeek 官网 API 配置 deepseek-v4-pro 和 deepseek-v4-flash 5. 智谱官网 API 配置 glm-5.1 和 glm-5-turbo 6. Kimi 官网 API 或开发套餐配置 kimi-k2.6 7. 小米官网 API或开发套餐，配置 mimo-v2.5-pro 配置后，Hermes可跟机器人对话切换模型，指令如下： /model gpt-5.5 --provider openai-codex /model grok-4.3 --provider xai-oauth /model gemini-3.1-pro-preview --provider google-gemini-cli /model kimi-k2.6 --provider kimi-coding-cn /model deepseek-v4-pro --provider deepseek /model mimo-v2.5-pro —provider xiaomi

译Hermes 支持配置多种国内外主流 AI 模型，包括 OpenAI GPT-5.5、xAI Grok-4.3、谷歌 Gemini 系列、DeepSeek V4 系列、智谱 GLM-5 系列、Kimi K2.6 以及小米 Mimo V2.5-pro。用户需通过相应服务的订阅或 API 进行配置，完成后可使用 /model 指令指定模型及提供者来切换对话模型，例如输入“/model gpt-5.5 --provider openai-codex”即可切换至对应模型。该功能方便用户根据需求灵活调用不同模型的优势。

向阳乔木@vista8 · 5月18日80

姚老师出手写了一个微信读书Skill，看展示效果非常棒！ 可以用来分析自己的读书数据

译开发者姚老师开源了微信读书Skill——yao-weread-skill。该工具能将用户的微信读书数据生成本地可视化报告，核心功能包括分析近两年的阅读时长与节律、书架书籍构成、阅读分类与作者偏好，并对笔记和想法进行语义分析。报告最终通过词云、热力图、雷达图等26种图表形式呈现，所有代码已在GitHub公开。

歸藏(guizang.ai)@op7418 · 5月18日49

Anthropic 官方发布的 Skill 构建指南 我用 AI 翻译了一个双语版本，放下面了

Berryxia.AI@berryxia · 5月17日66

别特么给马斯克省钱了啊，兄弟们！ 直接把你的蓝 V 订阅接入 Hermes Agent 吧！ 立刻、马上、去操作执行啊! 5分钟就够了 ！ 把蓝 V 的价值放到最大化，可以支持： 1. 文生图 2. 图生视频 3. 图生图 4. 语音对话 你还不去接入？ 接入Grok之后，它瞬间拥有最强的实时检索能力——准确度、来源可靠性，目前GPT、Gemini、Claude都比不过。 每天让它帮你整理信息、自动化工作流、做私人助理，体验直接起飞。

译推文强烈建议用户将X平台蓝V订阅接入Hermes Agent，以最大化其价值。接入后，蓝V可支持文生图、图生视频、图生图及语音对话等功能。同时，通过整合引用推文的关键信息，接入Grok能赋予其强大的实时检索能力，在准确度和来源可靠性上超越GPT、Gemini、Claude等模型。用户可借此进行信息整理、自动化工作流管理和充当私人助理，从而显著提升使用体验。

Rohan Paul@rohanpaul_ai · 5月17日62

Better search may come less from smarter indexes than from giving agents a richer way to touch text. Shows that AI agents using basic terminal tools like grep, file reads, and shell commands to search raw data perform far better than conventional retrieval systems on multiple benchmarks. On BrowseComp-Plus, swapping semantic retrieval for terminal search raised accuracy from 69% to 80% while lowering cost. The deeper point is not that grep is magically smarter than embeddings. It is that retrieval is usually treated as a model problem, when it is also an interface problem. A conventional retriever turns the corpus into a narrow ritual: ask once, receive a ranked list, reason over whatever survived. That works when the question is close to a document’s semantic center, but it breaks when the answer depends on exact phrases, faint clues, document structure, or a chain of small discoveries. Direct Corpus Interaction changes the shape of the task. The agent can search an exact string, inspect nearby context, notice a new entity, constrain the search again, and keep testing its hypothesis against the raw files. Here’s the part most people miss: the gain was not mainly from finding more gold documents, but from extracting more usable evidence once a promising document was reached. That makes DCI less like a better search engine and more like giving the model fingers. The limitation is real: as the corpus grows, the cost of finding the first useful anchor rises quickly, and blunt terminal search will not replace indexes for every large, static collection. But the paper’s lesson still lands cleanly. For capable agents, the bottleneck may no longer be only what they know, or even how they reason, but how much of the world their tools allow them to touch. ---- Paper Link – arxiv. org/abs/2605.05242 Paper Title: "Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction"

译研究表明，AI代理使用grep、文件读取等基础终端工具直接搜索原始数据，在多项基准测试中表现远超传统语义检索系统。例如，在BrowseComp-Plus基准上，终端搜索将准确率从69%提升至80%，同时降低成本。核心观点在于，检索不仅是模型问题，更是交互界面问题。直接语料交互允许代理进行精确字符串搜索、检查上下文并持续验证假设，从而从已定位文档中提取更多有效证据，其增益主要来自更充分地利用已发现文档，而非找到更多相关文档。局限性在于，随着语料库规模扩大，定位初始锚点的成本迅速增加，因此终端搜索无法完全替代大型索引。但对于强大AI代理，性能瓶颈可能在于工具允许其“触及”数据的深度。

Berryxia.AI@berryxia · 5月17日71

❤️

译❤️ [引用 @vista8]：微信读书Cli安装和配置教程。 1. 官方指令，复制发给Codex或Claude Code 下载 https://cdn.weread.qq.com/skills/weread-skills.zip 安装 skill 2. 或者用 X 上网友 @eviljer 做的优化版Skill npx skills add jerlinn/jerlin-weread 3. 如果需要API key，访问微信官方这个页面获取 https://weread.qq.com/r/weread-skills 4. 使用案例 直接跟AI说：“调用微信读书skill 查看被讨厌勇气的高亮划线”

向阳乔木@vista8 · 5月17日66

微信读书Cli安装和配置教程。 1. 官方指令，复制发给Codex或Claude Code 下载 https://cdn.weread.qq.com/skills/weread-skills.zip 安装 skill 2. 或者用 X 上网友 @eviljer 做的优化版Skill npx skills add jerlinn/jerlin-weread 3. 如果需要API key，访问微信官方这个页面获取 https://weread.qq.com/r/weread-skills 4. 使用案例 直接跟AI说：“调用微信读书skill 查看被讨厌勇气的高亮划线”

宝玉@dotey · 5月17日71

http://x.com/i/article/2055813152315461632 # 创始人手册：打造 AI 原生初创公司 原文：The founder's playbook: Building an AI-native startup ## 目录 - 2026 年，初创公司生命周期的重启 - 创始人定义的演变 - 构思阶段 - MVP 阶段 - 发布阶段 - 扩展阶段 - 目标未变，规则已改 - 资源推荐 ## 2026 年，初创公司生命周期的重启 AI 正在彻底重塑初创公司的诞生方式。如今，哪怕是连一行代码都没写过的创始人，也能发布可供实际使用的生产级应用 (production applications)。而那种只有 10 个人的精益独角兽公司 (独角兽指估值超过 10 亿美元的未上市初创企业)，已经不再是什么草根逆袭的传说，而是成了大家精心规划的常规操作。 到了 2026 年，AI 已经能够编写生产级代码、开展市场调研、梳理竞争格局、起草融资材料，甚至还能让业务流程实现自动化。以前，为了把脑子里的想法变成现实，哪怕是经验丰富的技术型创始人，也要面对整合各种工具、平台和系统时那陡峭的学习曲线。现在，AI 抹平了这些障碍，彻底打破了创立公司或打造产品的门槛。 在 2026 年，一个好点子能让创始人走得比以往任何时候都远。依靠智能体编程 (agentic coding) (指利用 AI 智能体自主编写、测试和修改代码的编程方式)，以前需要一整个工程师团队才能干完的活，现在创始人自己就能搞定并发布。 传统的初创公司发展路径往往是这样的：验证想法 → 融资 → 招人 → 开发产品 → 再融资 → 增长业务 → 再招人 → 循环往复。 但这套玩法过时了。初创公司进入新阶段，不再必然意味着需要扩充团队、补充新技能，更不需要立刻去拉新一轮投资。 本手册将根据这些新现实，重新梳理创业旅程的核心四个阶段：构思、MVP、发布和扩展。看看当 AI 变成技术和组织的核心基建时，创始人应该用什么工具，以及如何靠它们来疯狂压缩时间。 ## 创始人定义的演变 过去，创始人的身份往往是由他们的技能决定的：技术创始人负责写代码，非技术创始人负责搞业务和谈单子。但到了 2026 年，创始人手里的各种模型、系统和 AI 智能体 (AI agents)，已经彻底推倒了“懂开发的人”和“有绝佳点子的人”之间的那堵墙。 AI 原生 (AI-native) 初创公司正在从根本上改变“创始人”的含义。现在，毫无工程背景的人也能开发出能落地的生产级软件；反过来，只懂技术、缺乏商业嗅觉的创始人，也能轻松搞定市场推广策略 (go-to-market strategy)、财务模型，拿出一份极其专业的商业计划书 (pitch deck) (向投资人展示项目以寻求融资的演示文稿)。 回顾历史，创始人们把大把的时间都花在了执行上：写代码、管团队、处理日常琐事。但在 AI 原生公司里，创始人的角色不再是埋头苦干的员工，而是变成了 AI 智能体的指挥家——这些专业的 AI 助手能阅读文件、运行命令、执行代码，甚至还能上网搜索。创始人的注意力因此得以提升到更高层面的工作上：想出好点子，并指挥手下的系统（包括 AI 智能体、各种工具，以及精简的团队）把想法变成现实。 将 AI 作为核心基础设施，带来的最具革命性的成果，是彻底解放了那些懂行业的非技术创始人。当创始人的圈子不再局限于有工程背景的人时，你会看到背景各异的人建立起形形色色的初创公司。他们会去解决那些传统技术圈从来不关心，甚至根本没注意到的真实痛点。 ## 为精益初创公司量身打造的 AI 工具能力 传统的创业模式认为：你得招工程师来开发，招销售去卖货，招运营来管业务。公司的员工数量，往往被看作是企业发展势头和产品成熟度的标志。 2026 年的早期初创公司则完全不同。它们天生就极其精简，往往只有创始人光杆司令一个，或者顶多加上三两只小猫。通过把 AI 作为技术和组织发展的核心基础设施，它们甚至在扩充团队之前，就能完成产品验证、获得早期收入，甚至实现盈利。特别是在以下三个方面，AI 让一家微型初创公司运转得像个大企业：研究调研、智能体编程，以及核心业务流程自动化。 ## 对话式智能与研究调研 一句话总结：全领域的随时待命专家 想象一下创始人在创业第一年需要面对，却几乎完全抓瞎的那些事：怎么发工资？怎么规划产品开发冲刺周期？怎么写一份滴水不漏的投资备忘录 (investor memo)？ 以前，这些早期创业问题的答案永远只有一个：找个懂行的人问问。对于自掏腰包 (bootstrapped) 或处于种子前轮 (pre-seed) (指项目刚起步，尚未获得正式机构投资的阶段) 的创始人来说，这不仅意味着把原本该用来搞开发的时间花在了到处打听上，还可能要被迫拿出一大笔早期资金去请顾问。现在呢？他们拥有了 AI 这个在所有领域随叫随到的专家。 - 深度研究：竞品分析 (competitive analysis)、市场规模估算 (market sizing)、财务建模。 - 文档起草：商业计划书、案例分析、投资备忘录、产品需求文档 (PRDs)。 - 战略思考伙伴：扮演唱反调的“魔鬼代言人”、进行事前验尸 (pre-mortems) (一种风险管理技巧，假设项目已经失败，反推失败原因)、情景规划、路线图优化。 ## 智能体编程 一句话总结：那个永远在线、从不卡壳的工程师 过去，你要么得拉个懂技术的联合创始人，要么找个外包开发团队，或者手头有足够的资金跑道 (runway) (指公司在资金耗尽前还能维持运营的时间) 去养个工程师团队，然后才能写下第一行生产级代码。 现在，有了智能体编程工具，每个怀揣梦想的创始人只需用大白话描述自己想要什么。AI 就会以一整个工程师团队的速度和规模，生成、测试、调试并重构出企业级的代码库。 从“我有个点子”到“我做出了产品”的时间被大幅压缩。创始人的核心任务变成了决定“做什么”和“为什么做”，而 AI 负责把地基打好，搭建出真正面向用户的可用基础设施。 ## 流程自动化 一句话总结：按需召唤的全自动运营团队 哪怕创始人能像顾问一样做研究，像团队一样写代码，除了战略规划和产品开发，依然有成堆的杂活等着干。安排会议、更新 CRM 系统 (客户关系管理系统)、拉取周报、维护最新文档、发布内容、跟进合规要求，还要想办法把公司里用到的各种工具和系统串联起来。在精益初创公司里，这些重担几乎全压在创始人肩上——这严重挤占了他们本该用于做关键决策的时间和精力。 AI 工具提供的流程自动化，把创始人从这些苦活累活里解救了出来。你可以把那些重复性的日常操作设为自动执行：交易一推进，CRM 自动更新；一周结束，周报自动生成；产品一改动，文档自动同步。更厉害的是，像 Claude Cowork 这样的工具能无缝接入你现有的系统——你的项目管理工具、沟通软件、数据源——完全不需要专人去开发和维护这些接口。而在起步首日 (Day Zero) 的初创公司里，那个“专人”往往只能是创始人自己。 ## 把握时机与统筹调度是一切的关键 能够熟练驾驭 AI 研究、自动化和智能体编程能力的创始人，就能撬动远超其团队规模的杠杆效应。他们终于能把大部分时间和精力投入到真正有价值的工作中去。 当然，这并非完全是自动驾驶。身为 AI 工具的指挥官，创始人必须懂得使用的时机和方法。 ## 构思阶段 所有的创业者都从同一个起点出发：一个让他们魂牵梦绕、挥之不去的问题。在这个阶段，想法将与现实发生碰撞。要想在 2026 年取得成功，你需要一种克制：在没有确凿证据之前，绝不盲目动手开发。 现阶段的核心任务是：深入研究、客户调研 (customer discovery)、竞品分析，以及诚实地面对那些与你想法相左的反面证据。做完这一切之后，再去让 Claude Code 帮你写下第一行生产级代码。 ## 构思阶段的目标 在构思阶段，创始人首要目标是基于研究的验证：在投入资源进行开发之前，收集坚实的证据，证明你眼中的痛点确实存在（并且你提供的方案能有效解决它）。 具体来说，在这个阶段你需要按顺序回答几个问题： - 这个痛点真实存在吗？够具体吗？频率高到值得为它做个产品吗？ - 到底是谁有这个痛点？这能算是一个市场吗？ - 有没有别人已经在解决这个问题？如果有，他们是怎么做的，做得好不好？ - 一个能真正解决这个问题的方案，到底需要具备哪些功能？我的点子符合要求吗？ 这些问题的答案，最终都指向一个终极拷问：这玩意儿值得做吗？ 这意味着在你真正采取行动之前，必须把问题想得无比具体。“大家觉得报销很麻烦”这只是个粗浅的观察；而“中型企业的财务经理每周要花 4 个多小时核对报销单，因为他们现有的工具没法和财务软件打通”，这才是一个可以被测试验证的假设。 ## 构思阶段的通关条件 构思阶段的通关标志是找到问题与解决方案的契合点 (problem-solution fit)。在你开始撸起袖子造轮子之前，你已经获得了定性的证据（主要来自与真实用户的交流），证明你确实在为真实的人解决真实的痛点。 当你能对以下三个问题大声说“是”的时候，你就可以离开构思阶段了： 1. 痛点真实且具体吗？ 回答“是”，意味着你能准确说出谁在经历这个痛点，他们多久碰到一次，痛到什么程度，以及他们现在是怎么凑合应对的。 1. 你的方案能解决实际痛点吗？ 注意，这里说的是你在调研中发现的“真实痛点”，而不一定是你一开始想象的那个。有时两者是一回事，但很多时候不是。 1. 你有足够的信号支持你动手开发吗？ 在这个阶段你永远不可能有百分百的确定性（死等确定性也是一种常见的失败方式），但你需要有足够的定性证据，让“开发一个 MVP”成为一个深思熟虑的决定，而不是一次盲目的豪赌。 ## 构思阶段的挑战 构思阶段是你创业旅程中最重要的一环，因为这也是最容易犯下致命错误的地方：现在走错一步，你那刚萌芽的幼苗很快就会长歪。 不过，这个阶段的大部分坑，都是因为“行动快于认知”造成的。所以，只要创始人能保持冷静、谋定而后动，就能稳步向前。 ## 把“开发”当“验证” 挑战：当技术门槛被彻底抹平后，满腔热血的创始人很容易跳过创业中最关键的一步：验证他们的想法真的是人们需要且愿意使用的解决方案。 即便在当前的智能体编程时代到来之前，也有高达 42% 的初创公司死于“做出来的东西根本没人要”。而现在，像 Claude Code 这样的智能体编程方案大幅缩短了从“点子”到“产品”的距离，这个失败率恐怕只会继续飙升。 虽然对于拥有绝佳点子的创始人来说，现在是最好的时代，但反直觉的是，“一眨眼就能搞出个原型”这件事，对 AI 原生初创公司构成了真正的致命威胁。 就在不久前，开发软件还需要实打实的人力和预算，捣鼓出一个最基础的原型通常也得几个月。可现在，技术开发的门槛基本消失了，AI 让创始人太容易跳过实地验证，直接开始埋头苦干。 要达到问题与解决方案的契合，必须先验证假设，然后再动手。但很多新手（甚至一些老手）创始人误以为 AI 能够绕开这个定律。他们的流程变成了：有个点子 -> 立刻搞个原型 -> 把原型的存在当成点子被验证的证据。他们拿着原型，就坚信自己一开始的假设是对的，根本没去验证这在真实世界里是否行得通。 一个能跑起来的原型，很容易让人产生错觉，以为自己真的在解决实际问题。但事实并非如此。你的原型真正的作用，是在跟潜在用户交流时，拿来做压力测试的道具。那些交流的反馈本身，才是你真正需要的证据。 ## 过早扩张 挑战：当开发变得像呼吸一样简单且几乎零成本时，你的执行速度很可能会把真实的商业需求远远甩在身后。 过早扩张意味着，你在还没有真正确认一条路是否值得走之前，就已经在上面狂飙突进了。 这一直是初创公司的头号杀手，但在 AI 时代，创始人更容易在不知不觉中掉进这个陷阱。智能体编程助手太强大了，以至于创始人稍不留神，就会在尚未验证市场契合度的情况下，把执行规模盲目扩大。 AI 会用同样饱满的热情，去帮你生成、测试、调试并重构代码——哪怕你这个项目的底层逻辑烂得掉渣。系统里的智慧是你赋予的。所以这个阶段的最高准则就是：让你的脑子走在手的前面，特别是当写代码变得如此飞速和不费吹灰之力的时候。 ## 丧失客观性 挑战：如果你让 AI 工具帮你找证据来支持你已经深信不疑的观点，它一定会帮你找到。“确认偏误” (Confirmation bias) (指人们更愿意相信那些支持自己已有观念的信息的心理学现象)，现在自带强大的研究引擎。 确认偏误一直是创业者的职业病：创始人天生就对自己的点子充满狂热。现在，AI 工具给这种偏误加了一个超级滤镜。如果你让 AI 去验证你的创业点子，它会顺着你的意思找出一堆证据；如果你让它估算潜在市场规模，它一定会给你捏造出一个让投资人看了流口水的庞大数字。 AI 会顺着你的思路走。这就意味着，如果不去提出尖锐的问题，创始人现在比以往任何时候都更容易为一个糟糕的点子包装出一套看似经过详实研究的商业逻辑，并且还自我感觉良好，以为自己真的做了尽职调查 (due diligence)。解药其实还在同一个工具里，只不过要反着来：AI 在帮你推翻一个点子时，和在帮你证明一个点子时一样卖力。 当对抗性思考暴露出想法的漏洞时，果断调整方向（Pivot）。 ## Claude 如何助力构思阶段的创始人 推动你的 AI 原生项目熬过构思阶段，有时会让人觉得无比漫长。你是个创始人，你骨子里就渴望“马上动手”。但这个至关重要的起步阶段，本质上是一场研究和验证的战役。这意味着你必须借助那些能帮你思考得更缜密的工具，而不是急匆匆地去写代码。下面我们将介绍如何利用 Claude 的三大产品界面（Chat、Claude Cowork 和 Claude Code），帮你最快地度过构思阶段，同时扎实地完成尽职调查。 ## Chat、Claude Cowork 还是 Claude Code：选对正确的 Claude 界面 AI 能帮助初创创始人更快交付产品、自动化繁琐流程并大规模运营，但你使用的工具界面很关键。这里是针对不同任务如何选择 Chat、Claude Cowork 或 Claude Code 的指南。 Chat 适合在不离开当前应用的情况下进行快速交流。用它来处理运营公司的琐碎小事：从冗长的投资人备忘录里提炼核心金句、在开董事会前检查某个说辞有没有漏洞，或者帮你理清团队在 Slack 上的长篇大论。 Claude Cowork 适合做那些真正需要时间沉淀的知识型工作：它能从多方汇集信息，梳理逻辑，并输出一个完整的成品，比如文档、PPT 或表格。比如：把一文件夹的客户访谈录音整理成产品评审会上的主题分析报告；在融资前翻阅十几家竞品网站总结出一份竞争格局分析；或者设定一个每周一早上的例行任务，让它自动从关联工具里抓取数据，生成一份 KPI 简报放到共享文件夹里。 Claude Code 是为团队中的工程师准备的智能体编程环境：它能直接访问代码库，拥有规划模式 (Plan Mode)，集成了 git，并支持本地、IDE 或沙盒云环境。在这里，精简团队可以不断为日益庞大的代码库添加新功能，迁移 MVP 阶段留下的旧代码，从原型平滑过渡到生产环境，而无需苦等招聘新人。 任务类型... 该用谁 为什么选它 问个问题、改写段落、快速头脑风暴 Chat 速度快、对话式、无需繁琐设置 研究分析，或基于你的文件和系统生成完整文档 Claude Cowork 能访问文件夹、有插件连接、支持技能、可定时运行 编写、测试或发布软件 Claude Code 直接访问代码库、支持代码差异比对 (diffs)、集成 git、支持开发环境 这三者的底层都是相同的 Claude 模型，改变的只是外围的工作空间。 ## 定义并对你的问题假设进行压力测试 凭借你的行业经验和前期调研，你心里大概已经有了一个假设。第一项工作，就是把它打磨锋利，直到它变得真正可以被测试：到底是谁有这个痛点？频率多高？痛点多深？他们现在是怎么应付的？如果一个问题陈述无法精确回答这些问题，那就说明它还不具备被验证的条件。 - 实操练习：和 Claude 一起打磨你的问题陈述，直到它变成一个可测试的假设。比如，“合同审查太慢了”这就没法测试；但“中型企业的内部法务团队在每个合同审查周期要花 3 天以上时间，因为他们总是在邮件往来里改红线，而不是用一个版本控制文档”，这就非常具有可测试性了。 下一步，让 Claude 来反驳你的想法，让它去寻找那些能推翻你假设的负面证据。这能帮你挖出负面的市场信号、已经倒闭的竞品、潜在的客户行为模式，以及那些你在盲目乐观时很容易忽视的结构性障碍。 这样做的目的是，在真正接触客户进行调研之前，你的假设就已经经受了最强反方辩友的狂轰滥炸。这样一来，当你去做用户访谈时，你是在真诚地开放式倾听，而不是为了验证自己的偏见去寻找心理安慰。 注意：让 Claude 扮演结构化的“魔鬼代言人” (唱反调的人)，是贯穿 AI 初创公司整个生命周期的核心用法。 ## 市场调研与梳理竞争格局 摸底竞争对手 创业圈有一种现象叫“竞品盲区” (competitor neglect)：创始人往往过度沉浸在自己的宏大愿景和执行计划中，习惯性地看低同赛道其他人的努力。好在 AI 给了我们一剂解药：让 Claude 站在竞品的立场，给出最强有力的理由，论证为什么他们会成功，而你会一败涂地。 Claude 会帮你分析：为什么他们的做法其实更好？为什么客户会选他们？为什么你自以为是的护城河其实不堪一击？ - 实操练习：让 Claude 把你的竞品分个类：直接竞品、间接竞品、潜在收购方，以及随时可能跨界打劫的周边玩家。然后让它给出理由，分析为什么每一类玩家都对你构成了真正的生存威胁，别让它挑好听的敷衍你。 市场调研 Claude Code 可以抓取并综合公开的客户反馈，帮你找出那些被反复吐槽的痛点和未被满足的需求。额外福利：这相当于在给竞品的客户做免费的定性研究。 - 实操练习：指挥 Claude Cowork 梳理各个主流渠道的竞品评价，揪出现有方案一直没解决的几大痛点。如果你的假设正好切中其中一两个要害，那就是证明问题与解决方案契合的强烈信号；如果没有，早点知道也是好事。 Claude Cowork 还能从厚重的行业报告、分析师文件和市场研究中提取核心数据；整理干净后，这些数据将成为 Claude 进一步深入分析的绝佳素材。 - 实操练习：利用公开数据建立 TAM/SAM/SOM 模型 (即总可寻址市场 / 可服务可寻址市场 / 可获得服务市场，用于评估市场规模)，并对背后的假设进行压力测试。看清这个市场是在扩张、洗牌还是已经成熟；这些背景信息会直接影响你对入场时机和差异化竞争的判断。梳理客户画像：谁负责掏钱？谁能影响决策？这俩是同一个人吗？ 趋势分析 最后，用 Claude 帮你捕捉那些决定入场时机的早期指标。跟踪讨论相关问题的 Reddit 子版块和 LinkedIn 群组，抓取用户在描述痛点时使用的原汁原味的词汇。让 Claude 找找有哪些类似的跨界市场曾经解决过相似的问题，看看他们什么管用，什么掉坑了。揪出那些可能加速或者威胁你项目机会的政策法规、技术突破或人口结构变化趋势。 - 实操练习：让 Claude 找出三个能在未来两年内深刻影响你所在市场的外部趋势（政策、技术或人口），并客观评估每一个趋势对你的具体假设到底是顺风还是逆风。 注意：本节中的市场调研和竞品梳理工作不是一次性的。在接下来的 MVP 和发布阶段，随着你认知升级，你的假设也会迭代，这时候必须把这些动作再重复一遍。 ## 规划并设计客户调研 你能从潜在用户嘴里套出多少有价值的信息，取决于两点：(1) 你问的问题水平如何；(2) 你是不是在对正确的人发问。在这方面，Claude 是个绝佳帮手，它能帮你搞定找谁聊、聊什么，以及如何解读听到的反馈。 找谁聊 一个精准的目标用户画像，比一份漫长的通讯录有价值一万倍。这包括具体的职位、公司类型、团队架构，以及痛点最深的人群职级。接着，揪出这些人平常都在哪儿扎堆——哪些社区、活动、LinkedIn 群组和 Slack 频道——然后根据他们离痛点的远近，制定出一份优先级拜访框架。 问什么 目标确定后，利用 Claude 帮你搭建访谈框架：在正确的时间问正确的问题，以此挖掘用户“实际做了什么”，而不是他们“想象自己会做什么”。新手创始人最爱犯的错，就是抛出一个空泛的、面向未来的问题（“你会用这种产品吗？”），而不是精准地追问相关的历史（“跟我讲讲你上次遇到这破事儿是怎么处理的”）。Claude 能够精准捕捉到你的草稿中哪些问题带有诱导性、太宽泛，或者容易引出废话噪音而不是有效信号。Claude 还能帮你设计连环追问，用来对付那些含糊其辞或避重就轻的回答。 如果你的项目涉及多种角色，Claude 还能为不同的人量身定制不同的问卷。财务经理和 CFO 面对同一个痛点的关系是完全不同的，拿同一套题去套所有人绝对是灾难。 - 实操练习：先自己手写一遍访谈问题，然后让 Claude 充当审计员。特意让它揪出那些带有诱导性、面向未来、太宽泛，或者容易让受访者为了“讨好你”而说假话的问题。接着让它为你可能遭到敷衍的两三个关键访谈时刻，设计一套防守反击的追问技巧。 访谈后分析 每次聊完，让 Claude 帮你复盘：把笔记扔给它，让它提炼出哪些验证了你的假设，哪些推翻了你的假设，以及哪些是意料之外的惊喜。等你攒够了一批访谈，把所有的笔记喂给 Claude Cowork，让它提炼高频词、自相矛盾的地方，以及正反两方最强烈的信号。最后拿着综合输出的报告去找 Claude，问问它：我的解读是不是在寻找心理安慰进行模式匹配，而不是反映真实数据？ - 实操练习：每聊完五个客户，就让 Claude Cowork 对笔记进行综合梳理，列出两份清单：支持假设的证据，和反对假设的证据。如果第一份清单比第二份长出太多，问问 Claude：这是数据的真实反映，还是我一厢情愿希望看到的结果？ 客户拓展与日程安排 利用 Claude Cowork 把整理名单、发送开发信、安排用户访谈这些杂活实现自动化。 Claude Cowork 能利用你之前和 Claude 定好的目标画像（包括职位、公司类型、职级），去研究并整理出一份包含经过验证联系方式的结构化线索名单。然后它会大规模地批量起草个性化的开发邮件，确保每一封都紧扣对方的角色和背景。 收到回复后，它能通过 MCP (模型上下文协议) 连接到你的 Gmail 和 Google 日历管理沟通线程，处理会议邀请，并把访谈稳稳地塞进日程表。这个工作流还在继续：Claude Cowork 会按既定节奏（比如给七天没回信的人发跟进草稿）自动生成后续回复，并在完成后自动更新追踪表格，确保你时刻掌握每个潜在客户的漏斗进度。 - 实操练习：把你验证过的目标画像丢给 Claude Cowork，让它去建立名单、写个性化开发信序列、建一个包含拓展状态、跟进节奏和访谈进度的追踪表格。然后让它去搞定那些协调工作，你只需要集中精力准备对话本身就行了。 ## 设计最终的解决方案概念 你已经做完了验证工作：痛点是真实的，目标人群是明确的，你手里的解决方案概念也得到了证据支撑。现在，用 Claude 从各个角度来开发和拷打你的方案设计：哪里还有漏洞？市面上有没有替代品？如果要规模化运作，这套方案必须具备哪些先决条件？ 这是很重要的一道现实检查：现在的这个设计，解决的到底是你调研出来的真实问题，还是你最初瞎猜的那个原始假设？ - 实操练习：把你的方案概念丢给 Claude，让它挑出支撑你设计的三个最致命的依赖假设。然后追问它：如果要让这些假设成立，需要满足什么条件？如果哪怕只有一个假设不成立，会有什么严重后果？ ## 用 Claude Code 打造一个轻量级原型 终于到了好玩的环节：带着经过验证的假设和被反复压力测试过的方案概念，你终于可以开始造东西了。 在构思阶段的这一刻，Claude Code 正式登场。即使你之前一直在捣鼓，现在才是你生成官方版轻量级原型的时候：它是你为了获取真人真实反馈所需要的最小表面积体验。 你现在做的还不是真正能落地的产品；你只是在搭建一个方案的“体验样本”，拿去给客户和投资人看。让真实用户体验看得见摸得着的东西，能给你带来的情报，远比做十几次痛点发现访谈要多得多。之前，你是在证明痛点存在；现在，你是在邀请潜在用户与提出的解决方案进行互动。 - 实操练习：明确你的产品最核心的一个交互依赖点。指挥 Claude Code 只做这一个核心功能。做出来后，把它扔给你目标画像里的五个人，让他们上手试用。在这五次沟通中获取的认知，将决定你是继续往下开发，还是推倒重来。 能顺利熬过构思阶段，意味着你在 AI 创业赛道上迈出了巨大的一步，因为你现在不再是凭直觉下注；你是在跟着证据执行。 熬过构思阶段，创始人面临的问题就变成了：“第一步该做啥？”这时候，AI 的角色也从调研搭子，变成了你的王牌施工队。 ## MVP 阶段 很多创始人把 MVP 阶段当成单纯的施工期，但其实它本质上仍然是一场“收集证据”的演习。区别在于，你现在收集的不再是关于“痛点”空间的证据，而是关于“解决方案”的证据：具体来说，到底有没有一群明确的人，觉得你的产品好用到愿意反复用（留存）、愿意掏钱买（营收），或者愿意四处安利（推荐）？ ## MVP 阶段的目标 作为 AI 原生初创公司的创始人，你的目标是将经过验证的痛点，转化成一个让真实用户实际使用的可用产品。它不需要塞进路线图上的所有功能，只要提供最精简、最聚焦的核心体验。它的使命，就是把真实的解决方案怼到用户脸上，然后拿到产品市场契合度 (product-market fit, PMF) 的实锤证据。 与此同时，你现在的开发方式，直接决定了你未来的天花板。这意味着 MVP 阶段还有一个同等重要的目标：在快速移动的同时，绝不能欠下那种利滚利的“技术债” (technical debt)——一旦有意义数量的真实用户涌入，这些债迟早会反噬你。 最后，从第一天起就在持续上下文 (persistent context) 方面做投资，是让 AI 成为力量倍增器而不是混乱之源的关键。在 AI 原生公司，你的代码库是你每天跟 AI 一起结对协作的产物，所以代码的清晰易读是地基。那些跳过说明文档、架构决策和上下文文件（比如 CLAUDE.md）的创始人，都会撞上一堵可预见的墙：每次新开会话都得重新解释代码库，而且 AI 生成的代码会逐渐偏离最初的愿景。 ## MVP 阶段的通关条件 MVP 阶段的通关条件是拿到产品市场契合度的真实证据：证明有一群特定的明确用户，认为你的产品有价值，愿意继续用（留存）、愿意掏钱（收入）或者愿意帮你拉客（推荐）。 ## MVP 阶段的挑战 在 MVP 阶段，创始人的核心法则就是速度与判断力。此时的挑战在于，你能不能在不偷工减料、不给自己挖坑的前提下，以足够快、快到有意义的速度，用正确的方法，做出正确的东西。 智能体技术债 挑战：因为 AI 几乎消灭了阻碍代码上线的所有天然瓶颈，所以“速度”是绝对有保证的。但是，如果创始人只把速度作为构建 MVP 时的唯一变量，他们就会欠下一屁股很难还清的技术债。 在 MVP 阶段欠点技术债是可以理解的，前提是你清楚在扩容前必须把账还上。传统技术债是渐渐积累的，你大可以花时间或者搞个专门的冲刺期去清理。但 AI 的技术债，是带复利的。 如果没有一份写好并让 AI 读取的说明规范和架构约束，AI 在每次会话中都会从零开始倒推底层逻辑，而这些决策会不可避免地发生漂移。最后你会得到一个毫无灵魂和框架可言的代码库——不是因为里面哪段代码写得烂，而是因为这些碎片打一开始就没打算凑在一起。这是个大麻烦，而且往往到后期才会彻底暴露。 沉迷于虚假的产品市场契合度 挑战：AI 工具能帮你刷出极其亮眼的早期数据，但这绝不代表市场真的需要你的产品。 早期势头是创始人能体验到的最强大的心理毒药。经历了数周或数月的调研和克制的开发，产品一上线就感觉是在向全世界宣布：你从一开始就是对的！ 智能体编程工具能让你以比以往快得多的速度体验到这种快感，但“早期流量”和真正的 PMF 差了十万八千里。产品刚发布的那些热度，通常靠的是转瞬即逝的力量：比如创始人的朋友捧场、投资人拉来其他被投公司的潜在买家，或者碰巧在 Hacker News 上上了个头条。遗憾的是，等到第六周或者第十二周最初的热度退去，这些都没法可靠地预测接下来会发生什么。 零阻力的范围蔓延 挑战：当开发代码变得毫不费力且几乎零成本的时候，你总会觉得“再加一个酷炫的功能”或者“再处理一个边缘情况”也无妨。这种范围蔓延 (scope creep) (指项目功能不断无节制增加的现象) 往往弊大于利。 范围蔓延一直是创业风险。不同的是，以前防备它的强制刹车机制——实打实的工程时间成本——当加个功能只需一下午而不是一个冲刺周期时，这种阻力就不复存在了。 现在的难点在于，每一次加功能的冲动在当时听起来都无比合理。产品“当然”应该处理那个边缘情况，“当然”用户会想要那个工作流。 因为用智能体敲代码实在太轻松了，所以在当时你根本感觉不到这叫范围蔓延。但随着产品越来越臃肿，逐渐偏离最初的边界，你就会迷失方向，丧失势头。 解药是在动手开发之前，先白纸黑字地立个范围定义：明确写下这产品做什么、坚决不做什么，以及到底需要真实用户提供什么样的特定证据，才允许加新功能。这把决策点从“我们要不要做这个功能？”变成了“是不是有足够多的核心用户告诉我们，没有这个功能他们就得不到价值？” 因为没经验而忽视安全 挑战：利用 AI 工具火急火燎地把应用推向市场，却没有事先理解基本的安全原则的创始人，最终会让用户暴露在完全可以预防的风险之中。 残酷的事实是，智能体编程工具生成的是“能跑”的代码，而不是天生安全的代码。功能实现很容易，因为它要么有用要么没用。但安全漏洞在被黑客利用之前是看不见的，这意味着根本没有天然的反馈循环来提醒新手创始人出问题了。然而，向真实用户发布实时运行的 MVP，就意味着真实的数据、真实的暴露风险，以及出事后必须承担的真实后果。 轻视安全并不是 AI 原生项目才有的新问题。在各个时代，自筹资金的初创公司往往都喜欢把安全考虑无限延后，有时甚至拖到正式生产上线前的一刻。但在把任何最小可行性产品丢给世界之前，做一次安全审查，是对大众最起码的责任底线。 ## Claude 如何助力 MVP 阶段的创始人 ## 开发前先定好架构 在让 Claude Code 写下第一行生产代码之前，先让 Claude 帮你定义并文档化这个阶段必须遵守的架构决策：该遵循什么模式，该避开哪些依赖库，你做出了哪些妥协，为什么要妥协。这份产出将成为你的核心架构上下文文档，并为 Claude Code 确立运行时的护栏。 没有这份上下文，每次会话都会从零开始，Claude Code 只能被迫瞎猜你的结构假设。让没有护栏的 Claude Code 瞎跑，会造出一个能跑但结构极度混乱的代码库。在混乱的代码库上迭代和扩容，最终纯粹是浪费时间和 Token。迟早有一天代码会不可避免地崩盘，逼着你从头重写。 - 实操练习：在打开 Claude Code 之前，先打开 Claude，描述你要开发什么：它解决的核心问题、服务的用户，以及未来半年你预期的现实规模。让它帮你提炼出约束 MVP 的架构原则、在当前限制下必须避开的依赖库，以及现阶段你主动接受的权衡。 然后，把这段输出存为 CLAUDE.md markdown 文件。这是你项目构建的第一个产物，也是以后每一次会话赖以生存的根基。CLAUDE.md 文件是给 Claude Code 看的项目级指令，提供了项目特有的上下文，只要它在目录里运行，Agent SDK 就会自动读取它。从功能上讲，它们就是你项目的永久“记忆”。 ## 定义并严格执行 MVP 边界 毫无摩擦的范围蔓延，是 AI 时代 MVP 最具代表性的失败模式之一。就像你需要定义并记录架构一样，在写任何一个功能之前，你必须划定 MVP 的范围。 Claude 能帮你起草一份范围文档，说明你的 MVP 产品做什么、坚决不做什么，以及功能修改的触发标准：到底需要真实用户提供什么样的铁证，在现阶段才值得加新东西。 当新功能的点子冒出来时——它们绝对会冒出来的——用 Claude 来做个压力测试：这到底是来自用户的真实呐喊，还是披着产品思维外衣的创始人自嗨？ ## 用 Claude Code 搭建 MVP 一旦架构和范围确立，Claude Code 就正式成为核心的 MVP 开发工具。用它来生成、测试、调试并迭代你的代码库，但请记住：每次会话都应视为对既定产品决策的执行，而不是用来塞进新点子的机会。 每次启动 Claude Code 会话前，做到两点：(1) 重温你的范围说明文档；(2) 把包含架构上下文的 CLAUDE.md 文档喂给模型。 每次会话结束时，把本次做出的所有决策更新到文档里。你要的是一个你能解释清楚其结构的代码库，而不仅仅是一个能跑起来的代码库。 - 实操练习：给你的 Claude Code 工作建立一个极简的会话模板，包含架构上下文文档、本次的具体任务，以及必须遵守的约束或模式。每次收工前，在上下文文档里加一条简短的日志记录：详细说明开发了什么，做了什么决定，引入了什么新假设。每次花五分钟写文档，是你防止架构漂移、避免代码库彻底失控的最廉价保险。 ## 在用户触碰之前进行安全审查 作为 AI 原生初创公司的创始人，你的责任是清楚代码库里有什么，弄懂潜在的暴露途径，绝不能把明显的漏洞推送给那些信任你的真实用户。 Claude 能对 AI 生成的代码进行非常有效的初审，帮你识别常见的漏洞。把它养成上线前必做的良好习惯。但是，它代替不了专业的安全工具，而在高风险场景下，它更代替不了人类审查员——把 AI 当成万金油的创始人，最终都成了新闻里的反面教材。 Claude Code Security 更进一步：它能扫描代码库中的安全漏洞，并提供针对性的补丁供人类审查，这往往能发现传统方法容易遗漏的隐患。 注意：在本手册发布时，Claude Code Security 仍处于限量测试版本，所以在使用前请先确认其当前可用性。 - 实操练习：在部署给任何真实用户之前，带着明确的指令把核心应用代码推给 Claude 审查：检查身份验证和会话处理、API 响应中的数据暴露、输入验证和注入风险，以及具有已知漏洞的依赖库。严肃对待每一个发现，评估是否需要修复。任何涉及验证、密钥或数据处理的部分，必须交由人类复核。 ## 上线前先搭好数据指标框架 那些把早期流量错当成产品市场契合度的创始人，往往都是在发布之后才开始看数据，而且选取的指标都是为了证明“我们做得很好”，而不是去发现“哪里不对劲”。解药就是：在第一个用户出现之前，先把衡量框架确立好。 用 Claude 帮你定义：对你的特定产品来说，哪些指标才最重要？基准线在哪？数据呈现什么样的模式才算是真正的 PMF，什么仅仅是好听的噪音？具体来说：在发布 MVP 之前，设定好你的留存基准线、激活标准，以及第 7 天和第 30 天的目标。 接着，定义一下针对你产品的“假阳性”长什么样：比如，注册了却没有激活、有收入却没有留存，或者最初热情高涨随后却不再重复使用。当数据出炉时，让 Claude 站在对立面给你的数据挑刺：一个怀疑论者会怎么看待这些数字？ ## 管理调研和用户反馈的后勤工作 一旦真实用户进入产品，运营层面的工作就会迅速膨胀。Claude Cowork 可以接手那些重要但繁杂枯燥的工作，比如建立和维护用户联系人列表、执行邮件拓展序列、安排反馈会话、对 Bug 报告进行分诊，以及追踪迭代周期。在构思阶段用来管理调研后勤的 MCP 集成，在这里同样适用。 在反馈收集的环节中，必须保持人类在循环内，以便对用户反馈进行细致的探索。例如，如果用户说“这很好，但我希望它还能……”，这就需要解读：这是一个核心刚需还是个锦上添花的功能？它是特定于这个客户的，还是代表了一个细分市场？缺失的功能是真正的问题，还是新手引导阶段的某个上游环节没做好？没有任何工具能替你回答这些问题。 - 实操练习：配置 Claude Cowork 来运行你的 MVP 阶段反馈闭环：起草发给早期用户列表的邮件、安排反馈日程、为 Bug 报告和功能请求设计结构化的接收流程，并撰写一份每周收件汇总。你自己先审查这份汇总；然后，你可以让 Claude 分析这些信息，帮你捕捉可能漏掉的重大关键点。 ## 向“证据”迭代，而不是向“完整”迭代 只要拿到了真实的产品市场契合度 (PMF) 证据，MVP 阶段就可以宣告结束了，无论你的产品感觉起来有多“半成品”。宣称已经实现 PMF 并准备从 MVP 阶段进入发布阶段，归根结底是一个将创始人直觉与收集到的证据相结合的判断过程。不过，这里有一些有用的试金石测试： - 肖恩·埃利斯测试 (The Sean Ellis test)：去问你活跃的用户：“如果以后你再也不能用这个产品了，你感觉如何？”如果超过 40% 的人回答“非常失望”，这就是一个非常有意义的 PMF 指标。 - 费力程度测试：在找到 PMF 之前，维持留存需要不断的干预，包括频繁的触达、激励措施、个人跟进，以及消耗创始人极其庞大的精力才能让用户保持参与。但在找到 PMF 之后，产品开始自己完成这些工作。当事情开始从你“推”变成市场“拉”的时候，这种发力程度的转变，是某个真实事物发生改变的最清晰信号之一。 归根结底，没有任何单一的数据点能盖棺定论确认 PMF，因为它必须是在经历了多个迭代周期后依然成立的一种模式，然后你才能确凿地下定论。 ## 当证据指向别处时果断转型 如果投入了这么多工作，还是找不到 PMF 怎么办？这不是失败，这是系统在发挥正常作用：在错误的方向上浪费更多钱之前，果断止损。 当数据不支撑你当前的产品时，利用 Claude 来深入分析数据到底在告诉你什么。 - 探索替代客户群体。也许没有转化的用户从一开始就不是正确的目标受众。通常正确的受众已经隐藏在你的数据里了，只是你权重给低了。 - 调整产品的价值主张。也许你找对了受众，但你的 MVP 根本没有引起用户的共鸣。对新手引导、话术信息或核心功能的强调重点进行微调，有可能在不改变已构建内容的情况下解决这个问题。 保持心态开放，脱节的问题可能深到需要你做出更根本的改变： - 实操练习：如果你已经完成了三个或更多的迭代周期，但在 PMF 基准上却没有取得有意义的进展，在决定下一步怎么走之前，用 Claude 跑个诊断。把你的留存数据、用户反馈和你最初的痛点假设喂给它，然后问它三个问题： - 数据里有没有哪个特定群体的反应和其余人不同？ - 设计价值和体验价值之间的差距，是定位问题还是产品问题？ - 当前的产品想要找到真正的 PMF，到底需要满足什么前提条件？结合你目前看到的现象，这种情景现实吗？ 让这些答案来决定你是调整、转型 (pivot)，还是退回到构思阶段。 ## 发布阶段 如果说 MVP 阶段是为了证明你的产品配得上存在，那么发布阶段，就是为了证明你的企业配得上成长。 ## 发布阶段的目标 在发布阶段，初创公司的创始人必须将早期的势能转化成一个可重复、可持续的增长引擎。除了让你的产品达到生产级可用之外，你还必须强化底层的技术基础设施，同时围绕着你的产品，建立一家真正的公司。 在构思和 MVP 阶段，初创公司以创始人为中心是很自然的，因为你需要对全局了如指掌和紧密的反馈循环。但现在，如果创始人仍然试图亲自抓住每一根线头，就会成为发布阶段的瓶颈。现在的目标不是让你彻底从公司抽身，而是要建立运营系统，把你的注意力解放出来，去处理那些只有创始人才能做出的决策。 ## 发布阶段的通关条件 发布阶段的退出条件包含三个要素： 1. 增长是可重复的且由渠道驱动。你不仅仅是在留住用户，你还在通过特定的渠道可预测地获取他们，并且单位经济效益是清晰的：获客成本 (CAC)、客户终身价值 (LTV) 和投资回收期，是那些你清楚且能辩护的数字。 1. 产品能够处理生产负载。基础设施得到加固，安全和合规整顿就绪，在真实的生产条件下（而不仅仅是你测试的条件下）能保持可靠性。 1. 运营不再卡在创始人这里。流程已经存在，自动化已经到位。你不再是那个亲自处理支持、分发任务、规划冲刺或写报告的人。 ## 发布阶段的挑战 找到产品市场契合度 (PMF) 是早期创业生命周期中最难的问题。现在，创始人的挑战变成了保持住它。发布阶段是那些找到了真实产品吸引力的公司可能仍然会分崩离析的地方，如果围绕并支持产品的组织无法跟上的话。以下是需要警惕的失败模式。 ## 技术债到期催收 挑战：为了速度和验证而构建的 MVP 代码库跑得足够好，证明了产品有效，但生产流量、新功能和不断增长的复杂性现在暴露了它走过的捷径。 在 MVP 时期，为了速度积累一些技术债是一个合理的权衡。在发布阶段，这笔债务开始产生利息，并且悬而未决的时间越长，修复的成本就越高。 解决方案包括：进行系统的架构审计以识别结构性弱点，进行有针对性的重构以解决最严重的问题，以及有意义地扩大测试覆盖率，以便下一轮的功能开发不会重新引入同样的问题。 ## 创始人沦为最大瓶颈 挑战：在 MVP 阶段，创始人事必躬亲是一种资产。在发布阶段，随着客服请求量增长、产品决策堆积以及运营复杂性倍增，同样的本能反而成了约束。 从执行具体工作向设计能够执行工作的系统转变，是初创公司生命周期中最难的跨越之一。因为很少有明确的时刻提醒你改变发生了，这里的风险在于完全错失良机，继续停留在构建者模式中，而组织却在你周围停滞不前。发生这种情况的明显迹象包括：本该一小时做出的决定现在需要一周时间等你处理，客服请求堆积如山因为只有你知道答案，运营任务只有当你亲自想起来的时候才会去执行。 解药是对你个人正在处理的所有事务（从最微小的任务到最高风险的决策）进行全面审计，以确定什么可以被系统化，什么可以被委派，以及什么真正仍然值得创始人投入时间和注意力。 ## 安全与合规已退无可退 挑战：在 MVP 阶段保持安全和合规措施简单是可以的，但现在，有了真实用户、真实数据，桌面甚至可能放着企业合同，这就会变成一种负债。 在 MVP 时，只有少数几个 Beta 用户，生产环境中没有敏感数据，安全漏洞只是理论上的风险。然而，当你的产品带着依赖它的真实用户进入生产环节的那一刻，假设立刻变成了非常真实的暴露风险。此外，当开始处理客户数据、处理支付或销售到受监管行业时，那些对原型不适用的合规要求，立刻就变成了硬性规定。 解药是：在生产规模到来之前（而不是之后）进行系统的安全和合规审查，并将暴露出来的每一个问题视为必须修复的要求——而不是建议——然后才能迎接下一波用户的到来。 ## 没准备好就盲目扩张 挑战：新市场和融资机会看起来像增长机遇。它们同样也可能成为产品市场契合度 (PMF) 的坟墓。 你所建立的初步吸引力是真实的，但它同样特定于你的早期受众。过早地扩展到一个与你原始市场有显著差异的市场，会引入新的用户行为、合规要求、支付基础设施和你的产品并未针对其设计的基准期望。突然之间，新增了太多变量，你失去了清晰解读自身数据的能力。你还面临着为了追逐一个全新且未经验证的受众，而冷落原始用户群的风险。 ## Claude 如何助力发布阶段的创始人 Claude 的三种形态在发布阶段都在全面投入使用，它们相互支持：每个工具产生的输出都会成为另外两者的输入。结果有机地产生复利效应，同时使用这三种工具的创始人所获得的远大于各部分之和。 这就是让超精益创业模式在结构上成为可能的原因。当 Claude Code 构建产品，Claude Cowork 围绕产品建立公司，而 Claude 帮助将这种产品和组织知识运转起来时，一个小团队就能跑出其体量 N 倍的爆发力。 ## 趁早清剿技术债，别等利滚利 你的 MVP 代码库能够运行，但它也需要进行系统的排查，以寻找任何可能成为结构性负债的技术债务。 首先，利用 Claude Code 进行全面的架构审计：找出代码库脆弱的地方、将来维护起来代价高昂的捷径，以及测试覆盖薄弱到下一轮功能开发会重新引发相同问题的地方。 将 Claude Code 的审计结果反馈给 Claude，对修复工作进行分类和排序：哪些需要在下一次发布前修复，哪些可以等一个冲刺周期，哪些鉴于目前的阶段代表着可接受的持续债务。 这也是将你在 MVP 阶段所做的架构决策（那些因为没时间写下来而存在脑子里的决策）文档化的最佳时机。现在将它们放入 CLAUDE.md 中，可以确保以后的每个 Claude Code 会话都是从对系统如何设计以及为何如此设计的共同理解开始的。 - 实操练习：指挥 Claude Code 审计你的 MVP 代码库，并生成一份包含结构弱点、测试覆盖差距和重构候选对象的优先级列表。然后把该列表喂给 Claude，让它跨越多个冲刺周期为你排期修复工作：你需要首先解决的重大问题、可以与新功能开发并行处理的事项，以及可以延后处理的事项。 ## 建立替代创始人注意力的系统 建立能够释放你的注意力、让你去处理只有创始人才能应对的责任的运营系统，前提是要确切知道你的注意力都耗费在了哪里。利用 Claude Cowork 对你当前的运营负载进行结构化审计，记录下每一个循环任务、每一个落在你桌上的决策，以及每一个只有在你亲自记起时才会发生的流程。然后让 Claude Cowork 将这份清单分类为：可以完全自动化的、需要人工介入但不一定必须是你的，以及真正需要创始人判断力的。 一旦审计完成，利用 Claude Cowork 为需要自动化的任务设计工作流逻辑：什么信号触发每个工作流，决策规则是什么，输出长什么样，完成后数据丢到哪里。 ## 把安全和合规变成产品开发的一部分 利用 Claude Code 找出那些在 SOC 2、GDPR 或 HIPAA 审计中经常出现的代码级问题，以及你的目标市场所要求的标准合规点。这能同时暴露漏洞和合规差距。将这些发现喂给 Claude，以帮助你对修复工作进行优先级排序，并设计企业买家在签字前会要求查看的控制、审计日志和访问权限管理。注意：AI 扫描是辅助工具，不能代替合格的合规审查。 接下来，将合规工作流构建到你的日常开发周期中，而不是将其作为一次性项目运行；合规文档需要持续维护和更新。对于正在接触企业合同或国际市场的创始人来说，此时也是 Claude Code 安全扫描帮助你准备独立安全评估的关键时刻。 - 实操练习：带着你的目标市场所要求的框架标准，让 Claude Code 运行一次代码级安全审查。把输出喂给 Claude，并要求它产出两样东西：一份带优先级的安全补丁排期表，以及一份你为了满足潜在企业买家合规审查所需的文档和控制措施清单。 ## 补上你一直假装不存在的产品管理流程 发布阶段需要一套轻量、可重复的流程，这些流程无需创始人干预即可触发或运行。利用 Claude 来设计你的产品时间表和工作周期结构、在 Claude Code 动代码前需求规范里需要包含什么、Bug 报告如何分诊和路由，以及你的每周指标报告涵盖哪些内容并如何分发。 流程设计完成后，利用 Claude Cowork 来构建和运行运营层：安排冲刺周期会议、将传入的 Bug 报告分配到正确的位置、从连接的数据源编译每周指标，以及维护让用户信号持续转化为产品决策的反馈闭环。 - 实操练习：要求 Claude 设计一个轻量级产品管理操作系统：定义好的冲刺节奏、极简需求规范模板、Bug 分诊决策树，以及一份提取实际数据的每周指标简报。然后配置 Claude Cowork 来执行和运行该系统中循环往复的运营要素，如日程安排、路由分发和报告汇编，让它按时自动发生而无需你操心。 ## 扩展阶段 在扩展阶段，创始人的角色将从构建者转变为面向公众的高管。产品仍然是核心，但你个人的日常工作越来越变成围绕公司本身的经营。此时，你不仅要努力保持精益、以 AI 为中心的结构优势，你的注意力还必须扩大到包括分析师简报和 IPO 路演等扩展阶段的新活动。 ## 扩展阶段的目标 扩展技术基础设施的工作仍在继续，现在又加入了扩展组织本身并将其发展为企业的工作。 在扩展阶段，你需要面对从成千上万的用户激增到数以百万计的用户，并且从单一市场跨越到多个市场。在之前的每一个阶段，增长是你通过贴近用户，以及基于紧密反馈循环中的数据再加上创始人强大的直觉，来摸索着调整方向的。但现在，目标是建立由成熟组织运营所支撑的系统性增长。 对于 AI 原生初创公司而言，你的目标应该是通过累积的深度来构建防御护城河，这种深度源自你注入产品的专业知识、你的产品与用户依赖的其他工具或平台深度整合的程度，以及专有的系统数据和业务流。只要创始人在坚实的基础设施上，朝着明确的方向持续构建，你现在所拥有的东西就是极难被复制的。 在这个阶段，由于风险更大，公众投资者、分析师、监管机构、企业采购团队和收购方都会施加更大的压力——并带着更多的怀疑态度。你的产品和组织必须经得起外部审视：既要看产品的硬实力，还要看治理、合规、财务管控等软实力。 ## 扩展阶段的通关条件 扩展阶段的退出条件不再是一个单一的里程碑，而是一个门槛事件：公司能够可持续运转，即使创始人越来越不再直接管理日常运营。你已经证明了系统性增长；构建了满足最严苛外部审计员的组织治理和合规基础设施；并且在被问到“如果一个资金雄厚的现存巨头今天复制了你的产品，你的用户还会留下来吗？”时，你能给出坚实的答案。 在实践中，这个门槛通常会采取三种形式之一：达到不再需要外部资金的可持续盈利规模、IPO 就绪状态，或是被收购。这三者都要求你的增长是系统且可审计的，你的产品护城河经得起推敲，且你的组织足够成熟和可持续。 当这些成为现实时，恭喜你：你的初创项目已经从一场押注转变为了一门真正的生意。 ## 扩展阶段的挑战 ## 放权运营层 挑战：扩展阶段的运营系统必须在没有保姆看护的情况下可靠且可持续地运行。对于从第一天起就亲力亲为的创始人来说，这种转变在心理上的挑战不亚于结构上的挑战。 你在发布阶段的工作是创建系统；在扩展阶段，变成了 (1) 使这些系统成熟直到完全值得信赖，以及 (2) 然后真正地信任它们。 说起来简单。即使你是一个善于放权的创始人，到底该交出什么、该留下什么，通常并不明确。放权太多、太快——尤其是交给 AI 自动化系统——关键决策可能在缺乏只有创始人才能提供的关键上下文的情况下做出。但如果抓得太久，你可能就会成为一个瓶颈。 这里的根本挑战在于，你要找出那些仅存在于创始人脑海中或未记录工作流中的机构知识，然后将它们编纂成已记录的、可审计的、可转移的系统。 ## 扩展技术运营 挑战：客户不再仅仅评估你的产品功能；他们想知道你的组织是否可以成为一个可靠的基础设施合作伙伴。 初创公司前三个阶段的技术挑战主要集中在代码库上：在不累积技术债务的情况下构建正确的解决方案，然后为真实用户加强安全和合规性。当到达扩展阶段时，技术挑战变成了围绕代码库的一切；创建支撑设施、文档以及证明成熟度的可靠性保证。 签署多年期合同的更大型客户和机构买家会在签字前要求看到这些东西，一旦签约他们也会拿这些来约束你。 然而，帮助你走到这一步的同一个 AI 基础设施，也可以帮助你构建具备明确响应时间支持的专用支持功能，以及新客户的工程团队能够真正使用的文档。 ## 扩展组织职能 挑战：一个处于扩展阶段的公司通常需要招聘、薪资管理、会计核算和法务运营等组织基础设施，不管到底有几个人在跑业务。 在发布阶段，系统化运营意味着把消耗创始人注意力的工作流自动化。到了扩展阶段，初创公司现在需要发展出更广泛、在某些方面也更关键的一系列运营功能，例如财务报告、合规监控、合同管理以及客户支持等等。 ## 建立 GTM (市场推广) 职能 挑战：有机增长是有天花板的，而大多数扩展阶段的创始人在还没有来得及建立真正的市场推广 (GTM) 职能时，就已经撞到它了。 构思、MVP 和发布阶段的增长通常源于创始人主导的销售，从一个恰到好处的 Product Hunt 帖子到与早期客户的个人关系。但这种有机增长只能走到某一步，大多数初创公司在扩展阶段达到了这个极限。迹象包括用户曲线拉平、获客成本上升，以及只有创始人亲自介入时管道才会有动静。 扩展阶段的增长需要建立一台专用的增长引擎，触达产品新的、更广泛的受众群。然而，大多数初创创始人以前可能从未亲自操盘过诸如市场营销、大客户销售和分析师关系等项目。一个正规的 GTM 动作需要的不仅仅是建立新系统和流程，还要为你希望如何讲述你的产品创立一种品牌腔调和故事。因为，在初创公司生命周期的这个阶段，你需要依靠它不仅来触达个体新用户，还要触达包括投资者和企业买家在内的整个目标受众群。 幸运的是，GTM 职能并不需要庞大就能奏效，构建了产品的同一个 AI 基础设施同样能将其推向市场。 ## Claude 如何助力扩展阶段的创始人 早期的初创阶段利用 Claude 作为产品本身的基础设施：它是验证想法的研究伙伴、设计和构建原型的工程师团队，以及使单人初创公司成为可能的 AI 运营层。熬到了扩展阶段的 AI 原生初创公司创始人，现在可以利用 Claude、Claude Code 和 Claude Cowork 来以与开发时相同的方式继续扩展公司规模。 ## 将日常杂活甩给 Claude Cowork 开启扩展阶段时，你必须清楚眼下最需要投入时间和精力的地方，这对于没开过公司的初创创始人来说可能是个挑战。Claude 可以帮你列出在这个阶段“只有你才该做的事情”的清单，这可能包括诸如产品叙事决策、董事会关系、企业级交易以及创始人对创始人的对话等。未出现在此清单上的任何事，都是委派或借助 Claude Cowork 自动化的候选对象。 - 实操练习：让 Claude 帮你画出现有运营层的瓶颈地图：列出当前所有通过你路由的工作流、决策和审批节点。 现在，问 Claude：如果你消失一周不干预，每一个环节会发生什么？那些陷入停滞的工作流，就是你仍然过度亲力亲为并拖慢进度的地方。 这与你利用 Claude 制定的创始人优先级清单和职责盘点吻合吗？ 接下来，需要进行压力测试，确保你已经建立的系统在业务增长时能真正做好扩展的准备。 - 实操练习：利用 Claude 映射当前工作流，然后问它：如果我消失一周会怎样？那些停摆的工作流，正是交接标准、升级汇报路径或异常处理机制仍需强化的地方。Claude 可以帮助分析这些失败节点并推荐合适的修补方案，以便你可以根据需要更新或替换 Claude Cowork 的自动流。 ## 将技术运营扩展为企业级基础设施 随着规模的扩大，买家需要确认你的产品和组织可以作为长期基础设施被信赖。代码库内的技术工作一如既往地进行，但现在还需要处理围绕代码库的外围技术工作。 第一步是将机构知识转化为可以规模化的系统。利用 Claude 起草并维护企业采购团队希望看到的书面基础设施，包括产品文档、客户支持操作手册和 SLAs (服务级别协议)。 同时，指挥 Claude Code 审计并加固代码库，使其符合企业合同要求的特定可靠性和安全标准，并构建那种仅仅在 Discord 社区服务时无需提供的技术支持基础设施：日志、监控、事件响应工具，以及使 SLAs 真正可执行的可观测分层。 然后，Claude Cowork 负责运行企业级支持本身的运营层：工单路由、升级提醒工作流、由产品变更触发的文档同步、续约跟踪，以及企业客户成功团队所依赖的定期汇报周期。这三者结合，让一个小团队拥有了庞大得多的组织支持态势，这正是你签署多年企业合同时所需展示的肌肉。 - 实操练习：挑选出你最苛刻的三个潜在客户，或确定三个你极其渴望签下的理想客户企业。让 Claude 出一份差距分析报告：这些公司的企业采购大爷们在签署多年长约之前，希望看到什么样的支持文档、SLAs 和基础保障体系？你现在还差多远？利用输出的报告，在 Claude Code 和 Claude Cowork 之间排期分配各项技术和文档工作。 ## 建立真正的 GTM (市场推广) 职能 创始人的干劲把你带到了这里，但扩展初创公司规模需要创建并实施一套真正的市场推广策略。AI 能够帮你构建并运行这一整套 GTM 引擎。 Claude 可以协助你从头建立基础的 GTM 武器库：细分市场、搭建话术架构、制定分析师关系策略、编排销售话术本，以及当你面对公众投资者、企业买家和华尔街分析师时那些极其关键的面向投资者的叙事故事。这些受众都有自己的“黑话”，并且用他们自己的标准来评估你；Claude 的任务是将你的产品价值主张，翻译成与每个细分受众群都高度相关的产品营销手段。 此时，Claude Cowork 就成为了你的战术执行层：生产内容流水线、群发开发序列信件、安排分析师简报会后勤、制定新闻发布室和 PR 宣传节奏、清理 CRM 数据、汇报销售漏斗进度，以及运行各种将 GTM 策略转化为真金白银交易的重复周期。 如果 GTM 动作需要硬核的产品营销基础设施——交互式演示环境、对接集成文档、沙盒测试租户、API 说明手册、技术核心一页纸——Claude Code 可以帮你搞定。买方期望能从技术层面上实打实地评估你的产品，在扩展阶段，丢过去一个 Loom 录屏和一份 PPT 早就不够用了。而且，正是这种基础设施让你的 GTM 动作实现了异步运作：当你正在开董事会时，一个搭建出色的演示沙盒环境依然在帮你敲定单子。 ## 将领域专家知识和机构经验转化为 AI 上下文 许多超精益初创公司的创始人，都是在为自己亲身体验或观察到的特定领域内的实际痛点构建高度特定化的应用或工具。 现在，有了智能体 AI，从未写过一行代码的创始人也能利用其行业知识开发出解决复杂痛点的产品。Claude、Claude Code 和 Claude Cowork 分别在将创始人的知识转化为极具深度的产品特性方面发挥着重要作用。 利用 Claude 来捕捉、整理和提炼创始人的经验，让这些专业知识存放在产品可触及的地方。通过持续的长时间对话、项目梳理和记忆力积累，创始人可以分享所知的一切——行业黑话、监管合规陷阱、极端边界情况、用户的挫败感、为什么那些看似简单的答案行不通——并将其转化为结构化、可搜索的上下文语境。然后，技能 (Skills) 会将循环的工作流（比如“我平时是怎么审计商业租约的”、“我是如何梳理病人初诊档案的”）固化成 Claude 每次运行都能完美复制的动作。几个月下来，这会成为通用 AI 无论如何都无法匹配的专有行业基底。 借助 Claude 将你的行业知识外化，对于将那些刁钻的行业极端情况写入你的产品至关重要：例如，一个通用医疗 AI 计费工具在遇到 340B 药品计划索赔时会卡壳，但你的系统却具备处理它的特定逻辑。Claude Code 能帮你将同行从业者的常见挫败痛点，转变为极端的验证逻辑、更精确的提示词优化，或者是一个利用 MCP 接口去对接连竞争对手都没听说过的小众行业系统。结果就是：你的应用或工具的深度和广度在不断产生复利，竞争对手根本无法复制。 - 实操练习：在你的行业内，找出一个通用的“万金油”竞品绝对会踩雷的极端状况。结合你亲眼见过的真实场景，和 Claude Code 合作专门为它构建一个测试用例（不是普通的单元测试）。每当出现类似的边缘案例时，就把它们加进去。你的测试套件最终会成为你护城河的护卫舰。 ## 将积累的用户数据复利化为防御优势 当用户在产品中进行交互时，他们会留下行为信号（即他们接受了哪些输出，拒绝了哪些），这将直接指引产品的路线图。 随着时间的推移，你会熟悉特定用户群的独特模式、偏好和极端用法。这就是我们所说的复利价值：每次优化都使产品变得更有用，这会推动更多的使用量，从而创造更多的反馈，进而驱动更进一步的优化。 这些数据受时间锁定、与具体语境高度相关，抄袭者完全无法复制：你根本买不到数以千计的用户在你产品中反复打磨工作流留下的真实行为指纹。 Claude 可以帮助审查你收集的任何用户交互数据，从中识别出高价值的行为模式，并设计一套反馈闭环，将持续的使用行为转化为系统的模型提升。 - 实操练习：给 Claude 喂一段关于你产品交互数据的总结：你一直在收集什么，收集了多长时间，以及你对用户随时间推移的产品互动了解到了什么。让它从数据中挑出三个最具信号价值的行为模式，并设计一个反馈回路，将这些模式转化为模型系统级别的自我提升。然后，让它帮你起草一份一页纸的“护城河故事”，作为产品营销的弹药：讲述你的数据飞轮是如何运转的、它转了多久，以及为什么一个哪怕现在投入重金的财大气粗的抄袭者，也不可能在两年内追上你。 ## 建立工作流锁定 如果说复利的数据网络效应使你的产品难以复制，那么用户层面的工作流锁定则使你的产品令人难以割舍。用户在日常运营中运行你产品的时间越长，它在他们实际工作方式中嵌入得就越深。他们已经在产品之上建立了自动化流程，花成本对团队进行了培训，并将产品与他们的数据源和其他工具连接起来。他们开发出的提示词、优化过的工作流以及标准化的产出成果，都已经完全依附于你的产品功能和逻辑。到了这一步，弃用切换已经从单纯的换软件变成了一个惊天动地的系统运营大手术。 建立工作流锁定的第一步，是让 Claude 帮助你根据“集成深度”绘制现有的客户画像群组。针对每一个客户群，识别出他们在你的产品之上搭建了哪些工作流，以及他们死死依赖哪些集成接口。这能揭示你的产品在哪些地方粘性极高，而在哪些地方还需要进一步深耕。 你提供的集成接口越多，客户用产品构建依赖关系的面就越广。Claude Code 能帮助你快速构建与数据流管道、项目管理工具以及目标用户离不开的其他系统对接的原生集成接口。Claude Code 还能开发 APIs、Webhooks 和 SDKs，让客户不仅能使用你的产品，还能在之上搞二创和二次开发——这才是终极锁定。 - 实操练习：让 Claude 帮助你对排名前十的客户进行一次“工作流集成深度审计”。对于每家客户，记录下他们建立的自动化流程、他们离不开的系统接口、流经你产品的团队协作流程，然后估算一下如果他们想叛逃所需的切换成本。接着要求 Claude 跨客户群总结规律：对于你的特定产品，什么类型的集成能创造最深度的锁定？对于那些目前还在浅层使用的客户群体，你需要构建或提供什么接口才能进一步深化绑定？ ## 目标未变，规则已改 在 AI 时代，创始人的宿命并没有变：挖出一个真实的痛点，做个能解决它的产品，并把它扩展成一家真正有意义的公司。真正改变的，是通往目的地的路径。从构思、MVP、发布到扩展的这四个阶段中，AI 将过去按“季度”计算的周期，硬生生压缩成了按“星期”计算的闪电战。 曾经需要几个月才能跑完的验证闭环，现在几个下午就能搞定。弄个跑得通的原型，不再需要去强求一个懂得全栈技术的合伙人；你只需要清楚问题在哪，然后跟代码智能体闭关死磕几个回合。从上线前兵荒马乱的冲刺，压缩成了连续不断的工作流作业。而在扩展阶段，过去那种把早期核心员工逼成到处救火消防员的繁重运营压力，现在越来越多地能转交给 AI 去扛，这让你和团队腾出脑子，去做出那些真正构筑护城河的判断和决策。 如今的瓶颈，早就不再是“你能造出什么”，而是取决于“你选择造什么”。 ## 资源推荐 ## 用 Claude 搞开发 - Building AI Agents for Startups (为初创公司构建 AI 智能体)：分享初创公司如何在扩展阶段利用智能体摆脱对创始人的重度依赖。 - Claude Code docs (Claude Code 官方文档)：手把手教你从最初安装一路进阶到复杂的智能体工作流。行家提示：先从“How Claude Code works” (Claude Code 工作原理) 概览开始入门。 - Claude Code best practices (Claude Code 最佳实践)：涵盖 Anthropic 内部和各种工程团队验证过的成功模式——包括上下文管理、权限控制、规划以及验证工作流。 - Using CLAUDE.md files (使用 CLAUDE.md 文件)：详细讲解如何根据你的特定代码库调教配置 Claude Code。对于搭建开发环境的 MVP 阶段创始人来说是必读圣经。 - Claude Code power user tips (Claude Code 高级玩家秘籍)：提炼自 Claude Code 开发团队自身的工作流模式，包含并行会话操作和闭环验证技巧。 - Get started with Claude Cowork (Claude Cowork 快速上手)：分享团队如何设置 Claude Cowork，并开始实施技能、插件以及其他各项功能，将其威力扩展至整个初创公司。 - Tutorials (教程)：claude.com/resources/tutorials 提供了一个可搜索的任务拆解实操演练列表。 ## 创始人故事 - 三个 YC 系初创团队是如何利用 Claude Code 改变命运的：深入分析 HumanLayer (F24)、Ambral (W25) 和 Vulcan Technologies (S25) 这三家公司，是如何运用 Claude 极速将原型推向市场，并通过智能体编程工作流扩大其 AI 平台的。 - GC AI 创始团队凭什么干翻同行：看他们如何结合领域专业知识，依靠 Claude 构建出响应式法务平台，专治法务团队真实痛点：吃透公司内控手册、摆平跨部门利益相关者，还能提供可变的风险容忍度调整方案。 - Carta Healthcare 的临床数据神话：借助 Claude 驱动其临床抽象平台，他们每年处理高达 22,000 例手术病例，将数据抽象时间生生砍去了 66%。 - Anything，由 Claude 和 Agent SDK 强力驱动：已帮助 150 万完全不懂代码的用户，把大脑里的想法变成了活生生的软件。其中包括一位零技术背景的创始人，成功构建并已开始变现一个完整的招聘平台。Anything 的 AI 智能体接管了底层构建，让这些单干的老板能够把精力全部加倍投在自己的专业领域上。 - Cogent 的应用 AI 实验室：这家初创公司专门打造智能体来自动处理企业关键的安全任务。他们将 Claude 作为核心推理层，智能体能自动搞定整个漏洞生命周期内的排查、优先级定级和打补丁修复。 - Airtree 的中央枢纽大业：Airtree 把 Claude Cowork 作为其运营基础设施的中枢，一举统一了过去散落分布在十几个不同工具和各个团队中的数据。现在，只要有一个人构建了具备技能自动化工作流的功能，全公司里的每个人都能顺手用到它，用来解决那些一直在待办清单上却始终没人动手干的破事。 - Duvo 的全能大管家：Duvo 构建的 AI 智能体能跨越 ERP 系统、供应商门户网站、电子表格、邮件甚至通电话，来执行采购、供应链和品类管理等一整套流程。Duvo 完全建立在 Claude 之上，通过 Agent SDK 实现全闭环工作流的跨界调度。 - Zingage 为家庭护理机构搭建的 007 运营平台：这是一家能够提供 24/7 自动化全天候待命的 AI 智能体平台。这家初创企业利用 Claude 的结构化工具调用能力，在 EMR 电子病历系统和多个沟通渠道之间穿针引线；并凭借 Claude 的上下文推理能力，构建出能够提供极其细致且“因患制宜”解决方案的智能体，彻底告别机器人般冰冷的死板话术。 - Kindora 的 AI 智能“红娘”：这是一个由某位非营利机构高管亲手利用 Claude Sonnet 构建的平台，打造了一个慈善界亟需的智能匹配捐赠方与受助者的神器。在将成千上万的海量匹配对象层层筛选，精简到极少数值得重点突破的目标后，Kindora 直接通过 MCP 连接器，让这些非营利组织在 Claude 界面内就能畅快使用该寻客工具。 - Wordsmith 的降维打击：由一位律师转行当 CTO 的创始人创立，致力于为内部法务团队提供靠谱的 AI 驱动型法务黑科技。Claude 充当了 Wordsmith 执行合同审查、起草协议文档和文件审阅等核心功能的推理大脑，同时，这家初创公司的研发团队本身也完全依靠 Claude Code 来构建和迭代开发自家平台。 ## 创业支持与机会 - Anthropic 初创企业扶持计划：专门针对与 Anthropic 的 VC 创投伙伴合作的初创公司，该计划提供免费 API 额度，赋予市面上最高级别的速率访问限制，还能受邀参加专为创始人举办的闭门研讨会等独家活动。 - Claude 社区：面向广大开发者与构建者的核心讨论论坛和交流空间。 - 实时学习资源库：提供会议纪实、实战网络研讨会、干货直播及视频录播资源。

译AI正重塑创业格局，大幅降低技术门槛，催生“AI原生”初创公司。创始人角色从执行者转变为AI智能体的指挥者，无需传统技术背景即可开发软件或制定商业策略。初创生命周期被重新定义为构思、MVP、发布和扩展四个阶段，核心是利用AI工具（如研究、智能体编程和流程自动化）来压缩时间。成功关键在于创始人需掌握使用AI的时机与方法，尤其在构思阶段应通过深入研究验证痛点与方案的匹配度，而非盲目开发。

ginobefun@hongming731 · 5月17日55

下一个企业战场不是模型：而是智能体控制平面 过去两年，大家关注企业 AI 的视角主要是「哪个模型更好」，谁的基准更高，谁的上下文更长，谁的推理更准。VentureBeat 这篇调查报告提出了一个不同的框架：这个维度的竞争已经进入下半场，真正的战场正在转移到「智能体控制平面」。 什么叫控制平面？简单说，就是智能体干活的时候用到的基础设施：它怎么规划任务，怎么调用工具，怎么访问数据，怎么向安全团队证明它没有越权。这一层，决定了企业能不能放心地部署 AI、能不能在内部推广开、出了事有没有地方追责。 调查数据很清晰。微软以 38.6% 份额领跑，从一月份的 35.7% 继续增长；OpenAI 以 25.7% 位居第二；Anthropic 则是第一次出现在这个追踪器里，以 5.7% 入局。5.7% 绝对值不大，但它的意义在于「从零到有」，说明Anthropic 的 Claude 正在从「被调用的模型」变成「参与编排的基础设施」。 还有一个数据更值得关注：企业在选编排平台时，排第一位的考量是安全与权限管理，而不是模型性能。这直接说明企业买家的决策逻辑：我不只是在选一个更聪明的助手，我在选一个能对内部审计、安全团队、合规流程负责的基础设施。这个评估标准，对那些从「安全可信」角度建立品牌的厂商来说是利好。

译企业AI的竞争维度正从模型性能转向智能体控制平面，即管理AI任务规划、工具调用、数据访问与安全权限的基础设施层。VentureBeat调查显示，微软以38.6%份额领先，OpenAI占25.7%，Anthropic首次以5.7%进入榜单，标志其Claude从被调用模型转变为编排基础设施。企业选择编排平台时，安全与权限管理已超越模型性能成为首要考量，反映企业更重视部署AI时的合规、审计与责任归属。

Berryxia.AI@berryxia · 5月17日42

兄弟们，OpenAI 这个设计很牛啊！ 直接把Codex升级成个人AI设备网络了。 未来，只要在其他设备上装好Codex，你的Mac Mini、工作站，甚至爷爷奶奶家闲置的老电脑，都能连成一个“Codex network”。 从你主设备上一句话，就能远程调用这些机器的Computer Use能力——让它们帮你跑任务、处理文件、执行自动化。 配合即将上线的“Locked Use”设置，安全性和控制权也同步拉满。 以前一台电脑只能跑一个Agent，现在你随时能拉起一整支分布式Agent舰队。 闲置硬件直接变生产力，个人算力时代真的来了。 完整报道在这里：https://www.testingcatalog.com/openai-will-let-codex-control-other-desktop-devices-via-computer-use/

译OpenAI计划将Codex升级为个人AI设备网络。用户可在多台设备上安装Codex，将Mac Mini、工作站甚至闲置旧电脑连接成“Codex network”。通过主设备即可远程调用这些设备的Computer Use能力，执行任务、处理文件和自动化操作。配合即将推出的“Locked Use”设置，该功能在提升控制权的同时保障了安全性。此举使用户能从单一设备运行单个Agent，转变为随时调度分布式Agent集群，从而将闲置硬件转化为生产力，标志着个人算力时代的到来。

Berryxia.AI@berryxia · 5月17日74

兄弟们，设计和开发终于真正合体了。 @skirano（MagicPathAI CEO，前Anthropic、Brex、Uber、Facebook）刚刚放出重磅演示： 你现在可以把MagicPath直接当原生画布跑在Codex里面。 一边在MagicPath里拖拽设计UI，一边让Codex实时感知整个项目，自动生成代码、编辑组件、完成功能。设计和代码无缝切换，再也不用在Figma和IDE之间反复切来切去。 安装方式超简单： 在Codex里直接粘贴这句命令： npx skills add https://github.com/magicpathai/agent-skills --skill magicpath Codex会一步步带你登录、配置，搞定后整个MagicPath就变成Codex里的原生画布。 我看完演示后最大的感受是： 以前“设计-开发-迭代”要来回切三个工具，现在直接一个窗口全搞定。 这波操作把从idea到可运行App的距离，又狠狠缩短了一大截。 想试的直接去http://MagicPath.ai看完整教程和视频。

译MagicPath AI CEO @skirano 演示了其产品与Codex的深度整合。用户现可将MagicPath作为原生画布直接在Codex中运行，通过拖拽设计UI，Codex能实时感知项目并自动生成、编辑代码，实现设计与开发的无缝衔接，无需在Figma和IDE间切换。安装简便，只需在Codex中粘贴一条命令即可完成配置。此举将“设计-开发-迭代”流程整合于单一窗口，显著缩短了从创意到可运行应用的距离。

elvis@omarsar0 · 5月17日71

Interesting interpretability paper on tool-using agents. The authors probe hidden states and find the model often recognizes it should call a tool, but fails to actually call one. The mismatch ranges from 26 to 54%, and it concentrates entirely in the cognition-to-action transition, not in cognition itself. In other words, the model usually knows it should call the tool. The internal probe direction is decodable. But the late-layer last-token regime rotates that signal nearly orthogonal to the action it produces. This work tries to predict which interventions will actually work and which will not. Most will blame bad prompting or weak tool-call training, and probably ignore the late-layer geometry. If you have been A/B testing tool-use prompts and getting weird ceilings, this work might offer a good explanation to that behavior. Paper: https://arxiv.org/abs/2605.14038 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译该可解释性论文聚焦工具使用代理，通过探测隐藏状态发现模型常能识别应调用工具，但实际调用失败，不匹配率达26%-54%。问题完全集中于认知到行动的过渡阶段，而非认知本身。内部探测方向可解码，但后期层的最后令牌机制使信号旋转，几乎与产生的行动正交。研究旨在预测干预措施效果，指出常见归因如提示或训练不足可能忽略后期层几何结构，这为工具使用提示A/B测试中的性能上限提供了合理解释。

Chubby♨️@kimmonismus · 5月17日45

holy: OpenAI is turning Codex into a control plane for your entire personal compute fleet. Every Mac Mini, work desktop, devbox, and eventually browser session becomes an agent endpoint. openai is cooking

译OpenAI正将Codex从一个代码生成模型转变为个人计算设备的统一控制平面。未来，任何安装了Codex的设备，包括Mac Mini、工作站、开发机乃至浏览器会话，都能成为其智能体网络的端点。通过即将推出的“锁定使用”设置，用户可以从主设备安全地授权Codex，跨网络调用其他机器的“计算机使用”能力。这意味着Codex将能协调并操作你所有的计算设备，形成一个由AI驱动的分布式个人计算集群。

AYi@AYi_AInotes · 5月17日63

在我刚入行那几年， 记得代码库里有一种人是被默默崇拜的， 他能在十几层调用栈里一眼看出 N+1，能在火焰图里指出哪个函数被多调了三次， 今天 Greg Brockman 转的那个 Codex Skill， 第一次让这件事不再是少数人的特权。 性能优化为什么过去这么稀缺， 你得会用 Chrome DevTools 拉火焰图，会用 Node --prof 跑 profile，会读 perf report， 你得对渐进复杂度有近乎本能的敏感，能在嵌套十几层的代码里识别出 O(n²) 长什么样， 你还得踩过几百个真实生产事故，知道哪种模式在百万级数据下会爆， 这三样能力叠加起来，是十年项目经验才能稳定输出的活，在团队里就是稀缺资源，工资溢价就来自这里。 Greg 转的这个 Complexity Optimizer，是社区开发者做的一个 Codex Skill， 一行 npx --yes codex-complexity-optimizer 装完，在项目根目录跟 Codex 说一句 analyze my codebase，几秒钟跑完， 它专挖 O(n²)、O(n*m)、N+1、循环里套循环、每次渲染都扫全表那种隐藏坑，每一条都精确到文件 + 行号 + 当前复杂度 + 优化后复杂度 + 推荐改法 + 风险等级， 最重要的设计是它默认只报告不动代码，每条标 low 或 medium 风险，还告诉你上线前要补哪些测试， 也就是说 AI 不绕过人类决策，它做的是把人类做决策所需的信息全部准备好。 但这个 Skill 真正让我感兴趣的，不是它能干什么，而是它意味着什么， 过去两年 AI 写代码的故事，焦点一直在让代码写得更快上， 可是写代码的速度，从来不是开发者真正的瓶颈， 真正的瓶颈一直是看见自己看不见的问题——架构隐患、性能坑、安全漏洞、依赖陷阱，这些东西高度依赖个人经验积累，集中在少数资深开发者手里， Complexity Optimizer 真正的信号是，这类需要十年经验才能输出的能力，第一次被压进了一个可以一行命令调用的 Skill 里， 这条路一旦走通，下一波 Skills 不会等太久——安全审计、依赖风险扫描、架构腐烂检测、内存泄漏侦察，全都会涌出来。 总的来说，资深开发者的护城河不会消失，但定义在变， 过去的护城河是看见问题的眼力， 未来的护城河是判断 AI 给出的方案在你的业务场景下能不能落地的判断力， 十年经验值正在被压缩成一行 npx 命令， 这件事也许从今天就开始咯。

译Greg Brockman转发的Codex Skill "Complexity Optimizer"通过一行npx命令安装，能在几秒内扫描代码库，精准定位O(n²)、N+1查询等性能问题，并提供文件、行号、优化建议和风险等级。其核心设计是仅报告问题而不自动修改，将决策权留给开发者。这标志着AI的关注点正从“更快地写代码”转向“发现人类难以察觉的复杂问题”，将十年项目经验才能积累的诊断能力封装成可一键调用的技能。未来，类似的安全审计、架构检测等工具将大量涌现。资深开发者的护城河因此被重新定义：从依靠个人眼力发现问题，转向依靠业务判断力来评估和落地AI提供的解决方案。