Claude Blog 采集 (2026-05-30)¶

共采集 10 篇文章

📋 文章索引¶

Optimize code performance quickly - Oct 06, 2025 (评分: 9.5)
Preparing your security program for AI-accelerated offense - Apr 10, 2026 (评分: 9.5)
Multi-agent coordination patterns: Five approaches and when to use them - Apr 10, 2026 (评分: 9.0)
Deploying agentic AI across the enterprise with Claude Cowork - Apr 29, 2026 (评分: 9.0)
Onboarding Claude Code like a new developer: Lessons from 17 years of development - Apr 28, 2026 (评分: 9.0)
Skills for organizations, partners, the ecosystem - Dec 18, 2025 (评分: 9.0)
Bringing automated preview, review, and merge to Claude Code on desktop - Feb 20, 2026 (评分: 9.0)
Product development in the agentic era - Apr 29, 2026 (评分: 9.0)
Product management on the AI exponential - Mar 19, 2026 (评分: 9.0)
Prompt caching with Claude - Aug 14, 2025 (评分: 9.0)

Optimize code performance quickly¶

来源: Claude Blog 发布日期: Oct 06, 2025 采集时间: 2026-05-30 价值评分: 9.5/10 正文字数: ~7265 字符

摘要¶

Go from reactive profiling to proactive optimization. Find and fix bottlenecks in your codebase before they slow down production. Performance bottlenecks sneak up on you. Your API was fast last week, but now it's timing out. User dashboards that load instantly are suddenly crawling.

正文内容¶

Go from reactive profiling to proactive optimization. Find and fix bottlenecks in your codebase before they slow down production.

Performance bottlenecks sneak up on you. Your API was fast last week, but now it's timing out. User dashboards that load instantly are suddenly crawling. The payment flow that worked fine in testing chokes under real traffic. Traditional code optimization requires deep expertise: understanding profiler output, analyzing algorithmic complexity, correlating performance metrics with business logic. Each optimization cycle means profiling, analyzing, implementing, testing—stretching performance improvements across multiple sprints. Here's how to turn reactive performance fixes into proactive optimization that prevents bottlenecks before they impact users. How most performance optimization happens Profile and analyze bottlenecks Performance optimization typically starts when users complain or monitoring alerts fire. Developers reach for profiling tools like Chrome DevTools, New Relic, or Datadog to identify where applications spend time. You examine flame graphs, identify CPU hotspots, and correlate slow functions with business logic. Profiling reveals where time gets spent but not why specific code paths are inefficient. Production profiling requires careful sampling to avoid impacting performance further, leaving you with data pointing to slow functions without clear optimization paths. Review algorithms manually Next comes systematically reviewing code for nested loops, inefficient data structures, and redundant operations. This means calculating time complexity and replacing brute-force solutions with optimized implementations. The challenge is that this requires deeper codebase knowledge, and modern codebases can contain upwards of hundreds of thousands of lines. Critical bottlenecks hide in unexpected places that escape initial review. Load testing and benchmarking To better stress-test applications, developers create traffic simulations to establish performance baselines, implement improvements, then measure throughput and latency changes under simulated production load. Accurate load testing needs sophisticated environment setup and realistic data generation. The cycle of implementing changes, deploying to test environments, and collecting metrics extends optimization projects across multiple sprint cycles. Refactor code incrementally Incremental refactoring replaces inefficient code with proven alternatives by optimizing database queries, implementing caching, and refactoring algorithms. This approach minimizes deployment risk but requires coordination across multiple engineers and extensive testing. Large-scale optimizations span repositories and demand understanding complex interactions between system components. Systematic optimization with Claude Many development teams are moving beyond reactive profiling tools toward proactive performance engineering with AI coding assistants like Claude. These tools analyze functions instantly, identify algorithmic bottlenecks, and provide ways to improve your code. You can work with Claude in two ways: Claude.ai : Free web interface. Paste slow functions, get complexity analysis and optimization recommendations. Any browser, no setup required. Claude Code : Agentic terminal coding tool that integrates with your development environment. Analyzes project-wide performance patterns, directly implements optimizations across multiple files. Install with npm. Start with Claude.ai Before setting up complex profiling environments or writing benchmark suites, paste short code snippets in Claude.ai to quickly determine whether a performance issue is algorithmic, structural, or configuration-related. Unlike traditional profilers that only show where time is spent, Claude explains why code is slow and how to fix it. This initial analysis helps you decide between a quick code change or a comprehensive architectural review. Get quick optimization ideas The most straightforward approach with Claude.ai is copying a problematic function and asking for help. Developers typically paste anywhere from a few lines to entire functions that are causing bottlenecks in their applications. Claude analyzes the code structure, identifies inefficient patterns like nested loops or redundant operations, and suggests specific optimizations. User: "This function is slowing down our user dashboard. How can I make it faster?" [pastes 20-line function with nested loops] Claude: "I see two main bottlenecks here: 1. The nested loop creates O(n²) complexity 2. You're making a database call inside the inner loop Here's an optimized version using a single query and hash map lookup..." Typical questions that work well: "Why are my code functions slow with large datasets?" "Can you rewrite my code to be more efficient?" "What's wrong with this algorithm performance-wise?" Understand why your code is slow Sometimes you need to understand the root cause before jumping into optimization. Claude.ai excels at breaking down performance issues in accessible language, explaining exactly why certain code patterns become bottlenecks as your application scales. You can paste code that's consuming excessive memory, causing API timeouts, or degrading under load, then ask Claude to explain what's happening.

Common causes include algorithmic bottlenecks like O(n²) complexity from nested loops, N+1 database query problems where you make database calls inside loops, inefficient database queries that don't use indexes properly, lack of caching for repeated operations, and redundant data processing.

You can identify bottlenecks by pasting suspicious functions into Claude.ai for immediate analysis, or use Claude Code to scan your entire codebase for performance issues. Traditional approaches involve profiling tools like Chrome DevTools, New Relic, or Datadog to examine flame graphs and CPU hotspots, but these show where time is spent without explaining why code is inefficient.

Use both approaches together for best results. Traditional profiling tools like Chrome DevTools or Datadog show where your application spends time and help identify hot spots in production environments. AI tools like Claude explain why specific code is slow and suggest concrete optimizations. Start with Claude.ai to quickly determine whether a performance issue is algorithmic, structural, or configuration-related before setting up complex profiling environments.

It depends on your starting point. Eliminating N+1 queries can reduce response times from seconds to milliseconds—often 10-100x improvements. Replacing O(n²) algorithms with O(n) implementations shows dramatic gains with large datasets but minimal difference with small ones. Tools like Claude Code can generate benchmark tests to measure improvements objectively, helping you validate whether optimizations actually deliver the expected gains.

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Preparing your security program for AI-accelerated offense¶

来源: Claude Blog 发布日期: Apr 10, 2026 采集时间: 2026-05-30 价值评分: 9.5/10 正文字数: ~24571 字符

摘要¶

We share our initial set of recommendations to shore up your defenses based on our own findings and security practices.

正文内容¶

AI is changing the speed at which vulnerabilities are found and exploited. We're publishing an initial set of recommendations to shore up your defenses based on our own findings and security practices.

Earlier this week, we announced Project Glasswing—our urgent attempt to put the strong cybersecurity capabilities of our newest frontier model, Claude Mythos Preview, to use for defensive purposes. In the announcement —and the accompanying technical blog post —we described how AI models are rapidly reducing the required resources, time, and skill required to find and exploit vulnerabilities in software. With an eye on the lightning-fast progress of AI, we also noted that it will not be long before models of similar capability levels are widely available. Within the next 24 months, vast numbers of bugs that sat unnoticed in code, possibly for years, will be found by AI models and chained into working exploits. Indeed, it is already the case that publicly available, sub-Mythos-level models can find serious vulnerabilities that traditional reviews have missed for long periods of time. Thankfully, this works both ways: although attackers can use AI to move faster, so can defenders who adopt AI tools to secure themselves. In this post, we offer security recommendations and practical tips based on what our security teams and researchers have observed and learned from using frontier AI models to secure real codebases and systems. We hope security teams and others will find this advice useful as we enter the age of AI-driven cybersecurity. Many of the pieces of advice below are already part of the existing security consensus; we have prioritized them according to which controls we have seen hold and which we have seen degrade. If your organization reports against SOC 2 and ISO 27001, these will map directly onto controls you are already tracking. We’ll update this guidance as we and our Project Glasswing partners continue our cybersecurity work. What to do now 1. Close your patch gap AI models are very effective at recognizing the signatures of known, already-patched vulnerabilities in unpatched systems. Reversing a patch into a working exploit is exactly the kind of mechanical analysis at which these models excel. This means that the window between a patch being published and an exploit becoming available is shrinking. Patch everything on the CISA Known Exploited Vulnerabilities (KEV) catalog immediately. This catalog contains vulnerabilities that are confirmed to be under active exploitation. Anything on this list which is reachable from a network should be treated as an emergency. Use EPSS to prioritize the rest. Exploit Prediction Scoring System (EPSS) provides a daily-updated probability that a given Common Vulnerability and Exposure (CVE) will be exploited in the next 30 days. Patching the KEV list first and then everything above a chosen EPSS threshold will help you turn thousands of open CVEs into a manageable queue. Reduce time-to-patch on internet-exposed systems. We recommend patching internet-facing applications within 24 hours of an exploit becoming available, and within days for other vulnerabilities. Automate patch deployment and reboots where the risk of an automated update causing an outage is acceptable. Manual approval steps add delay, and delay is now the primary risk. Practical tip: Most cloud and OS vendors already ship patch automation; enabling it is often a simple configuration change. For container images and dependency manifests, several open-source scanners run as a single continuous integration step and annotate CVEs with data from the KEV catalogue and EPSS, so prioritization is built in. 2. Prepare to handle a much higher volume of vulnerability reports Over approximately the next two years, the processes you use to receive, prioritize, and fix vulnerabilities (both in your own code and in the software you buy from vendors) will be under far more pressure than they are today. Your Vulnerability Management process should plan for many more patches, from vendors and upstream. Plan for an order-of-magnitude increase in finding volume. Aspects like intake, triage, and remediation tracking need to keep pace with the increasing numbers of vulnerabilities being exposed. If your security meetings are still built around a spreadsheet and a weekly meeting, it’s unlikely that you’ll keep up. It’s worth considering some amount of automation—with, of course, humans in the loop, to assist with the sheer volume here. Check the security of your open-source dependencies. Most software supply chains are mostly open source. Most open-source projects have no service-level agreement or commitment to maintain a high level of security. OpenSSF Scorecard automatically scores every dependency on signals like branch protection, fuzzing coverage, signed releases, and maintainer activity. It runs in CI and helps to identify unmaintained packages. Apply the same expectations to your vendors. Your third-party risk management process should ask suppliers how they are themselves preparing for accelerated exploit timelines and whether they are scanning their own code. ‍ Practical tip: Look into open source software and third-party services that evaluate the reachability of vulnerable code. Build automated processes that continuously deliver new software updates to your IT and production infrastructure, by doing regression testing on updates to gain confidence that you can deploy them quickly. Above we mentioned automation of these processes. There are a number of important ways that AI can assist: Speeding up triage. Triage is a bottleneck, because it requires expert review and classification. A frontier model can deduplicate findings against an existing backlog, use its knowledge of your assets to estimate exposure, and draft remediation tickets where the affected code paths are pre-identified. Check your dependencies for redundancy. Most large codebases accumulate multiple libraries doing the same job (several HTTP clients; several JSON parsers). This gives attackers more opportunity, all for no functional gain on your part. Pointing an LLM at a lockfile and asking which dependencies overlap (and what migration and consolidation would look like) is a one-hour exercise that often pays off. AI upgrade automation. Frontier models are increasingly capable of generating patches to include alongside vulnerability reports. When the report is clear and thorough, maybe even with a proof-of-concept, the model can directly test the patch to confirm that the exploit path is closed. It can also directly automate the process of accepting the upstream patch, validating that the upgrade doesn’t break tests or internal systems. AI vendoring . Some small dependencies will score poorly on the OpenSSF Scorecard—perhaps because they’re not actively maintained. You shouldn’t continue to rely on these; instead, you should consider having an LLM write its own code to reimplement the functionality you actually use. 3. Find bugs before you ship them Prevention is always better than cure. You should assume that bugs that reach production will eventually be found, so your security testing needs to happen well before. Add static analysis and AI-assisted code review to your continuous integration pipeline, and block merges on high-confidence findings. If false positives make this impractical, you should keep the check, but address the tooling. The OWASP Application Security Verification Standard defines what “passing” a test looks like at three different levels of rigor. Add automated penetration testing to your continuous delivery pipeline. You can run the same scanning for staging that attackers will run against your production systems. Secure the build pipeline. An attacker who can inject code between commit and deployment does not need to find a vulnerability. The SLSA security framework provides a graded path: lower levels establish which commit produced which artifact, and higher levels make the build itself verifiable. Adopt Secure by Design practices. CISA’s pledge commitments (multi-factor authentication by default; no default passwords; transparent vulnerability reporting) are a reasonable minimum bar. Prefer memory-safe languages for new code. A large share of severe vulnerabilities are memory-safety bugs that do not occur in Rust, Go, or managed runtimes. CISA, the NSA, and the NCSC have published useful roadmaps . Existing C/C++ code does not need to be rewritten, but new C/C++ code should require a justification. AI assisted rewrites are increasingly viable, as well. Practical tip: Static application security testing (SAST) tooling that runs as a CI action with OWASP Top 10 and language-specific rule sets is widely available, both open-source and built into code hosting platforms (CodeQL on GitHub being the most common starting point). To assess build provenance, OpenSSF publishes a reusable workflow that produces SLSA Level 3 attestations from GitHub Actions; adopting it is significantly less work than the SLSA spec suggests. As before, there are some clear opportunities for accelerating this work with AI: AI vulnerability scanning. The logic here is straightforward: you should scan your own code and systems with the same kind of model an attacker would use, before they do. This approach just requires an isolated agent, a verification step to filter noise, and a path into your existing triage process. You can do this with an LLM today. If you implement one thing from this section, implement this. Patch generation. When SAST or a scanner produces a finding, a frontier model can usually propose a patch for it. This does not remove the need for review, but it changes the developer’s job from “understand the bug and write a fix” to “verify a proposed fix is correct.” The latter is faster. The same approach applies to memory-safe migration: LLMs can port a self-contained C module to Rust with tests; a reviewer can validate the equivalence rather than writing the whole thing from scratch. 4. Find the vulnerabilities already in your code Patching addresses known vulnerabilities in software you depend on. But your own codebase contains unknown ones. Most long-running production code has been reviewed by humans many times, but has never been examined by a frontier model, and that kind of analysis tends to surface new, previously-overlooked issues . Proactively scanning can identify vulnerabilities that are within the reach of modern LLMs before attackers discover them themselves. Prioritize by exposure. Start with code that parses untrusted input, enforces an authentication or authorization decision, or is reachable from the internet. These are the paths where a finding is most likely to matter. Include legacy code. Code that predates current review practices, or whose original authors have moved on, often has the least recent scrutiny. That’s where you have the most to gain from a fresh pass. Budget for remediation. A well-structured model scan of older code typically produces fewer findings than a SAST rollout, but a higher share of them are real. Plan engineering time to fix the bugs. Practical tip: Pick one internet-facing service with few current owners and scan its input handling and auth logic. Run the agent in isolation and add a verification step so you’re acting on confirmed findings. One service done properly is a reasonable basis for estimating what a broader program will cost. 5. Design for breach Attackers will try to get a foothold somewhere. You need to limit what they can reach from there. Mitigations whose value comes from friction—making an attack tedious —rather than a hard barrier (extra pivot hops, rate limits, non-standard ports, SMS-based MFA) are much less effective against an adversary that can grind through those tedious steps. Our recommendations below favor controls that hold even when the attacker has unlimited patience: hardware-bound credentials, expiring tokens, and network paths that do not exist rather than paths that are merely inconvenient. Adopt zero trust architecture. Authenticate and authorize every request between services as if it came from the internet. CISA's Zero Trust Maturity Model and the NCSC's zero trust principles both provide staged adoption paths. Tie access to verified hardware rather than credentials. Production systems and sensitive internal tools should only be reachable from managed employee devices with attested hardware identity, paired with phishing-resistant 2FA (FIDO2 or passkeys). Stolen credentials alone should never be sufficient to gain access. Even calls between production services should be rooted in hardware identity. Isolate services by identity. A compromised build server should not be able to query production databases. A compromised laptop should not be able to reach build infrastructure. Enforce this at the receiving end: every workload should carry its own cryptographic identity, and each service should accept connections only from the specific callers of its policy names. Network segmentation can still reduce blast radius and noise, but it is a backstop. Replace long-lived secrets with short-lived tokens. Static API keys, embedded credentials, and shared service-account passwords are among the first things an attacker with model-assisted code analysis will find. Use short-lived, narrowly-scoped tokens issued by an identity provider. Practical tip: Full zero-trust is a multi-year program, but an identity-aware access proxy puts device-verified, MFA-gated access in front of internal services without having to fundamentally change their architecture. Each major cloud provider offers a native option, and several open-source and commercial alternatives exist for on-premises or multi-cloud environments. For secrets, every major cloud has a managed secrets store; moving the single most widely-shared credential into one and rotating it is a useful forcing function for the rest. 6. Reduce and inventory what you expose This section is based on two important principles. First, you cannot defend systems you don’t know about. Second, the smaller the exposed surface, the less there is to attack. Maintain a current inventory of every internet-facing host, service, and API endpoint in your systems. Attackers can run automated reconnaissance; your inventory should be at least as accurate. Include these systems in your pentests and red-teaming. Decommission unused systems. Legacy services with no clear owner are typically also unpatched. Minimize what each service exposes. Default-deny network ingress and limit API surface area to what is actually required. Practical tip: Internet-wide scan indexes are publicly searchable; querying one for your own IP ranges and domains shows you what an attacker’s reconnaissance sees. For cloud assets, native inventory tools (AWS Config, Azure Resource Graph, GCP Asset Inventory) already exist; the work is in querying them. AI can help directly here,

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Multi-agent coordination patterns: Five approaches and when to use them¶

来源: Claude Blog 发布日期: Apr 10, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~1651 字符

摘要¶

Five multi-agent coordination patterns, their trade-offs, and when to evolve from one to another.

正文内容¶

Five multi-agent coordination patterns, their trade-offs, and when to evolve from one to another.

In an earlier post, we explored when multi-agent systems provide value and when a single agent is the better choice. This post is for teams that have made that call and now need to decide which coordination pattern fits their problem. We've seen teams choose patterns based on what sounds sophisticated rather than what fits the problem at hand. We recommend starting with the simplest pattern that could work, watching where it struggles, and evolving from there. This post examines the mechanics and limitations of five patterns: Generator-verifier , for quality-critical output with explicit evaluation criteria Orchestrator-subagent , for clear task decomposition with bounded subtasks Agent teams , for parallel, independent, long-running subtasks Message bus , for event-driven pipelines with a growing agent ecosystem Shared-state , for collaborative work where agents build on each other's findings Pattern 1: Generator-verifier This is the simplest multi-agent pattern and among the most deployed. We introduced it as the verification subagent pattern in our previous post, and here we use the broader generator-verifier framing because the generator need not be an orchestrator. How it works

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Deploying agentic AI across the enterprise with Claude Cowork¶

来源: Claude Blog 发布日期: Apr 29, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~2418 字符

摘要¶

Learn how organizations use Claude Cowork to transform their day-to-day work, including use cases and best practices from Anthropic’s own teams.

正文内容¶

Learn how organizations are using Claude Cowork to transform their day-to-day work, including use cases and best practices from Anthropic’s own teams.

Just a few years ago, using AI at work meant interfacing with a chat window: ask a question, get an answer. In 2025, Claude Code put an agent in the command line and developers started delegating some of their most tedious and time-intensive workflows, from parsing through data and modernizing legacy systems to shipping features across multi-service codebases, all while connected to their most critical business systems. Now, Claude Cowork brings that same capability to the desktop for everyone else at your company: analysts, lawyers, account executives, marketers, and more. Claude Cowork meets work where it already lives: local files and folders, connected apps like Slack and Google Drive, and the browser. Paired with Claude for Excel and Claude for PowerPoint, it can also carry context across spreadsheets and slide decks in a single workflow. And with plugins, skills, and commands, Claude becomes even more capable and customizable to your work environment. To help teams get the most out of Claude Cowork, we put together a guide that walks through how to deploy it across a business function, including where to start, how to structure your pilot, common use cases, and best practices for driving adoption at scale. While many of these examples come from Anthropic's own teams and customers, including Thomson Reuters, Zapier, and Jamf, the patterns and lessons learned are broadly applicable across industries and companies. Inside the guide, we share: A five-level maturity model for Claude Cowork adoption, from chat Q&A to department-wide plugins How to choose your first use case and structure a pilot evaluation A six-month roadmap for moving from champion teams to organization-wide deployment How Anthropic's finance, legal, sales, and product teams use Cowork in production Customer stories from Thomson Reuters, Zapier, and Jamf Check it out, here . ‍ Get started with Claude Cowork today.

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Onboarding Claude Code like a new developer: Lessons from 17 years of development¶

来源: Claude Blog 发布日期: Apr 28, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~1090 字符

摘要¶

The methodology that onboards new developers to MacCoss Lab's 700,000-line codebase works on Claude Code, too. Here's how Brendan MacLean, a Claude Developer Ambassador whose lab is part of our Claude for Open Source program, did it.

正文内容¶

The methodology that onboards new developers to MacCoss Lab's 700,000-line codebase works on Claude Code, too. Here's how Brendan MacLean, a Claude Developer Ambassador whose lab is part of our Claude for Open Source program, did it.

Skyline , the open source protein analysis software maintained by principal developer Brendan MacLean at the University of Washington's MacCoss Lab, has been in active development since 2008. Skyline helps researchers detect and quantify proteins in things like blood plasma and tissue, which is vital for biomarker discovery, disease research, and drug development. The MacCoss Lab codebase contains 700,000+ lines of C#, maintained for 17 years by a small team running 200,000+ automated nightly tests.

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Skills for organizations, partners, the ecosystem¶

来源: Claude Blog 发布日期: Dec 18, 2025 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~1834 字符

摘要¶

In October, we introduced skills—a way to teach Claude repeatable workflows tailored to how you work. Today we're making skills easier to deploy, discover, and build: organization-wide management for admins; a directory of partner-built skills from Notion, Canva, Figma, Atlassian, and others; and an open standard so skills work across AI platforms.

正文内容¶

In October, we introduced skills —a way to teach Claude repeatable workflows tailored to how you work. Today we're making skills easier to deploy, discover, and build: organization-wide management for admins; a directory of partner-built skills from Notion, Canva, Figma, Atlassian, and others; and an open standard so skills work across AI platforms. Manage skills across your organization Claude Team and Enterprise plan admins can now provision skills centrally from admin settings. Admin-provisioned skills are enabled by default for all users. Users can still toggle individual skills off if they choose. This gives organizations consistent, approved workflows across teams while letting individual users customize their experience.

An open standard We're also publishing Agent Skills as an open standard. Like MCP, we believe skills should be portable across tools and platforms—the same skill should work whether you're using Claude or other AI platforms. We've been collaborating with members of the ecosystem, and we're excited to see early adoption of the standard. Getting started Claude Apps: Browse the skills directory and enable in Settings > Capabilities > Skills. Claude Code: Install from the plugin directory or check skills into your repository. Claude Developer Platform (API): Use skills via the /v1/skills endpoint. See documentation . Admins can provision skills org-wide through Admin Settings. Skills require Code Execution and File Creation to be enabled.

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Bringing automated preview, review, and merge to Claude Code on desktop¶

来源: Claude Blog 发布日期: Feb 20, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~1190 字符

摘要¶

Preview running apps, auto-review diffs, and monitor PRs — all from Claude Code on desktop. Go from writing code to merging in one place.

正文内容¶

Updates to Claude Code on desktop help you close the development loop, so you can go from writing code to merging PRs in one place.

Today, we're shipping Claude Code improvements that let you preview running apps, auto-review code, auto-fix and merge PRs, and seamlessly switch between desktop, mobile, and CLI. Together these updates help you spend less time on the toil around code and more time on the parts you enjoy. Write code and see it run Claude Code on desktop can now start dev servers and preview your running app directly in the desktop interface. Claude views the webapp UI, reads console logs, catches errors, and keeps iterating, so you don’t have to switch to a browser and manually describe what you’re seeing to Claude. You can also select visual elements in the preview and pass feedback directly to Claude to iterate.

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Product development in the agentic era¶

来源: Claude Blog 发布日期: Apr 29, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~3461 字符

摘要¶

Jess Yan, Claude Managed Agents product manager, shares how she uses the product to unblock herself and free up time to hone her craft.

正文内容¶

Jess Yan, Claude Managed Agents product manager, shares how she uses the product to unblock herself and free up time to hone her craft.

One of the ironies of being a product manager in the age of AI is that my work feels more human than ever. The job of product management has always been a mix of craft and alignment. For most of my career, my week was occupied by the latter: meetings with cross-functional stakeholders and teammates, status reports, and ticket backlogs with my engineering team. I got used to making instinctive, quick decisions followed by uphill battles advocating, convincing, and resourcing; shipping impactful products often felt more transactional than generative. With Claude, I can pressure test ideas, automate workflows, and get unstuck. I'm finally spending real time with our users and my team on the part of the job that always mattered most: the craft. While these new workflows changed my day-to-day, the most meaningful shifts happened when we started developing Claude Managed Agents (currently in beta), a suite of composable APIs for building and deploying cloud-hosted agents at scale. In this post, I'll share how Managed Agents has changed the way I work as a product manager, and a few patterns you can borrow for your own workflows. Product development, then and now API design used to live in documents and comment threads; on the AI exponential , we build with what we ship. A spec that reads elegantly in a doc can fall apart the first time you try to build against it. With Claude Code, I can sketch out an agent against pre-production versions of our API specs, and within an afternoon be running a real prototype end-to-end. We reshaped API abstractions and Claude Console UX several times based on what we learned building with our own primitives–changes that even a multi-week doc review would never have surfaced, and otherwise would've come up too late via user feedback. We still litigate shapes and run raw curl requests to make sure we're happy with the bare-metal experience, but Claude Code gets me from the basic "hello world" test to a functional agent in the same sitting. As I build these agents, I'm able to more concretely anticipate ways our harness and API can flex for the next wave of model and task evolution. Initially, these prototypes were just for shaping the product, but they now are evolving my day-to-day work as well. My workflow as a PM now splits cleanly across our products. I use Claude and Claude Cowork for open-ended research and discovery–the murky, early-stage exploration where I want an ongoing conversation. Once I have greater clarity on the job to be done, I use Claude Code to write and ship a custom agent for it, built atop of Managed Agents . The two-pronged payoff has been the biggest unlock. On one side, being able to build against my own product easily raises the ceiling on what I can imagine shipping next. On the other, once the product is live, the same development muscle lets me automate the long tail of operational work that used to stall in my backlog. Managed Agents use cases for product managers

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Product management on the AI exponential¶

来源: Claude Blog 发布日期: Mar 19, 2026 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~3136 字符

摘要¶

Claude Code’s Head of Product Cat Wu shares how teams should rethink their workflows and roadmaps in the face of rapidly evolving model intelligence.

正文内容¶

Claude Code’s Head of Product Cat Wu shares how product management teams are adapting their workflows and roadmaps in the face of rapidly evolving model intelligence.

Since Claude Sonnet 3.5 (new) in October 2024, I made a habit of testing every new model by asking Claude Code (an internal tool at the time) to add a table tool to Excalidraw. With each new model, Claude got a little further but still failed. Then, with the release of Opus 4 in June 2025, Claude started occasionally succeeding, enough that we turned the exercise into a pre-recorded demo for the Claude 4 model launch to show what had become possible with our latest model. Less than a year later, Opus 4.6 can one-shot Excalidraw feature requests reliably enough that we feel comfortable doing it live, in front of thousands of professional developers. The speed of model progress keeps expanding what's possible. The traditional product management playbook is built on the assumption that what's technologically possible at the start of a project is roughly what's possible at the end. PMs would gather enough information upfront to make confident bets about the future, then execute against a plan over the course of months. Exponentially improving models break that assumption. The constraints you designed around might disappear mid-project. You're building on ground that's rising underneath you, and teams need to reorganize around that reality. The new product management rhythm is rapid experimentation, consistent shipping, and doubling down on what works. Not surprisingly, one of the most common questions I get as a product manager at Anthropic is how our role is changing. Here's what I've learned. My journey to product management with Claude Code I started my career as a product engineer at startups like Scale AI and Dagster, and then became a venture capitalist, a role in which I still wrote code to automate the tedious parts of my job, like scanning X for the announcement of new companies or detecting when open source projects were gaining momentum. I joined Anthropic in August 2024 as a product manager on the Research PM team, which bridges our research team and real-world customers to deliver better models. When Claude Code became available internally that fall, I used it to accelerate the more manual parts of my job, including building Streamlit apps to analyze large-scale user feedback and running evals to help the company find new benchmarks to trust. The low barrier to building also meant I could explore well beyond my usual role, like creating RL environments to better understand training. These projects took hundreds of hours of prompting Claude Code powered by Sonnet 3.5 (new), but not a single line of code written by hand. Designing a new product management workflow

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集

Prompt caching with Claude¶

来源: Claude Blog 发布日期: Aug 14, 2025 采集时间: 2026-05-30 价值评分: 9.0/10 正文字数: ~2929 字符

摘要¶

Claude caches frequently used context between API calls, reducing costs and latency for long prompts. Update : Prompt caching is Generally Available on the Anthropic API. Prompt caching is also available in preview in Amazon Bedrock and on Google Cloud’s Vertex AI.

正文内容¶

Claude caches frequently used context between API calls, reducing costs and latency for long prompts.

Update : Prompt caching is Generally Available on the Anthropic API. Prompt caching is also available in preview in Amazon Bedrock and on Google Cloud’s Vertex AI. (December 17, 2024) Prompt caching, which enables developers to cache frequently used context between API calls, is now available on the Anthropic API. With prompt caching, customers can provide Claude with more background knowledge and example outputs—all while reducing costs by up to 90% and latency by up to 85% for long prompts. Prompt caching is available today in public beta for Claude 3.5 Sonnet, Claude 3 Opus, and Claude 3 Haiku. When to use prompt caching Prompt caching can be effective in situations where you want to send a large amount of prompt context once and then refer to that information repeatedly in subsequent requests, including: Conversational agents: Reduce cost and latency for extended conversations, especially those with long instructions or uploaded documents. Coding assistants: Improve autocomplete and codebase Q&A by keeping a summarized version of the codebase in the prompt. Large document processing: Incorporate complete long-form material including images in your prompt without increasing response latency. Detailed instruction sets: Share extensive lists of instructions, procedures, and examples to fine-tune Claude's responses. Developers often include a few examples in their prompt, but with prompt caching you can get even better performance by including dozens of diverse examples of high quality outputs. Agentic search and tool use: Enhance performance for scenarios involving multiple rounds of tool calls and iterative changes, where each step typically requires a new API call. Talk to books, papers, documentation, podcast transcripts, and other long-form content: Bring any knowledge base alive by embedding the entire document(s) into the prompt, and letting users ask it questions. Early customers have seen substantial speed and cost improvements with prompt caching for a variety of use cases—from including a full knowledge base to 100-shot examples to including each turn of a conversation in their prompt. Use case Latency w/o caching (time to first token) Latency w/ caching (time to first token) Cost reduction Chat with a book (100,000 token cached prompt) [1] 11.5s 2.4s (-79%) -90% Many-shot prompting (10,000 token prompt) [1] 1.6s 1.1s (-31%) -86% Multi-turn conversation (10-turn convo with a long system prompt) [2] ~10s ~2.5s (-75%) -53%

Explore more product news and best practices for teams building with Claude.

Transform how your organization operates with Claude

Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.

Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.

采集自 Claude Blog，由 collect_claude_blog.py 自动采集