Claude Code 在写代码方面确实很强大。然而，在专业工作中，真正耗费时间的并不仅仅是实现本身。它还包括搜索过去的决策、整理规范、编写 SQL、审查设计、发布前检查、阅读合同和 PDF，以及为利益相关者创建报告。开发者和产品团队的工作远不止于代码。
这正是 Claude 官方插件的用武之地。
本文不会介绍 Claude Code CLI 专属市场中的开发插件。我们将探讨的是在 Claude Desktop 中，可以从“目录 -> 插件 -> Anthropic”选项卡中选择的官方 Anthropic 业务专属插件，如下图所示。具体来说，这些插件包括工程、产品管理、数据、设计、企业搜索、PDF 查看器等。
虽然这些插件主要是为 Claude Desktop 的 Chat 和 Cowork 提供的，但 Anthropic 的官方仓库表明它们也适用于 Claude Code。通过将相同的包导入 Claude Code，你可以将技能、斜杠命令和 MCP 连接器引入到你的开发工作流中。简而言之，本文的前提是“在 Claude Code 中使用 Desktop 上找到的官方插件”。
截至 2026 年 7 月 18 日，插件在付费计划中可用：Pro、Max、Team 和 Enterprise。插件捆绑了技能、连接器和子 Agent。安装的技能可以在 Web 聊天、Claude Desktop Chat 和 Cowork 中使用。但是，由于某些钩子和子 Agent 是 Cowork 专属的，因此你应该检查每个插件的“在何处运行”。
在本文中，我根据开发者、产品经理、设计师、技术负责人和独立开发者是否可以在实践中反复使用，而不是仅仅根据功能多少，选择了 10 个插件。
首先，你应该了解的安装方法
在 Claude Desktop 中，打开左侧边栏的“自定义”，进入“插件”选项卡，然后按“+”显示目录。接着，选择“Anthropic”选项卡，在目标卡片上按“+”或“安装”。安装后，你可以通过在输入字段中输入“/”或打开“+”菜单来检查添加的技能和命令。
要在 Claude Code 中使用相同的插件，请添加官方知识工作市场并单独安装它们。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-plugins
你可以将 engineering 更改为 data、design、product-management 等。安装后，当需要技能时会自动引用它们，并且可以通过命名空间调用显式命令，例如 /engineering:review 或 /data:write-query。
请注意，某些插件会启动本地 MCP 服务器或连接到外部服务，如 Google Drive、Slack、GitHub 和 Figma。由于本地 MCP 可能以与普通程序相同的权限在你的终端上运行，因此请务必检查提供者、所需的权限、连接目标以及它们是否具有写入权限。
1. 工程 | 开发团队必备基础套件
工程是重中之重。它的范围很广，涵盖了每日站会、代码审查、调试、架构决策、事件响应、部署前检查和技术文档。它作为将 Claude Code 不仅仅用作实现工具，而是作为支持整个开发过程的合作伙伴的基础。
代表性命令包括用于审查更改的 /engineering:review，用于复现/隔离/根因识别/修复的 /engineering:debug，用于以 ADR 格式组织技术决策的 /engineering:architecture，用于故障响应支持的 /engineering:incident，以及用于发布前检查遗漏的 /engineering:deploy-checklist。它不仅包含代码审查技能，还包含测试策略、技术债务、系统设计和文档等方面的知识。
它在编写代码前后的阶段特别有用。例如，在实现之前，使用 /engineering:architecture 来决定函数是同步还是使用队列；在实现之后，运行 /engineering:review；在上线之前，运行 /engineering:deploy-checklist。在故障期间，不要只是盯着日志，而是按时间顺序记录复现条件、影响范围、假设、验证结果、缓解措施和永久修复。
对于初次尝试，以下请求很容易理解：
/engineering:review
请按照正确性、安全性、性能和可维护性的顺序检查此差异。
首先列出高严重性问题，并为每个点提供理由和建议的修复。
但是，审查结果不应取代测试或 CI。工程作为结构化决策材料的插件是强大的；它不能保证构建成功、类型检查或在真实环境中的行为。当实现、测试和审查集成到一个流程中时，其最大价值才能得以实现。
2. 产品管理 | 将模糊想法转化为可执行规格
如果你突然向 Claude Code 抛出“实现这个功能”，它会生成一个看似合理的实现。然而，如果为谁解决问题、哪些不在范围内以及如何衡量成功仍然模糊不清，那么在完成后将需要进行大量返工。产品管理是一个强化这个上游流程的插件。
它包括用于编写功能规格或 PRD 的 /product-management:write-spec，用于更新路线图的 /product-management:roadmap-update，用于进度报告的 /product-management:stakeholder-update，用于总结访谈/调查的 /product-management:synthesize-research，用于竞争对手比较的 /product-management:competitive-brief，用于检查指标的 /product-management:metrics-review，以及用于深入探讨假设的 /product-management:brainstorm。常见的 PM 框架，如 RICE、MoSCoW、Jobs-to-be-Done 和机会解决方案树，也作为技能内置其中。
与 Claude Code 的协同作用在于“在同一对话中连接规格和实现”。首先，使用 /product-management:write-spec 组织问题、目标用户、验收标准、非功能性需求、成功指标和待办事项。然后，将该内容放入 Issues 中，分解为实现任务，最后使用 Engineering 进行审查。这使得代码变更的原因更容易保持一致，而不会让规格文档在其他地方积灰。
在实践中，与其一次性让它写出最终形式，不如首先指定：“询问不清楚的点，并明确指出哪些是假设。” PM 插件不仅用于润色文本，更在于暴露歧义。一个能够在实现之前揭示需要解决的问题的 PRD，比一个漂亮的 PRD 更有价值。
3. 企业搜索 | 找回散落在 Slack、邮件和文档中的过去决策
团队开发中最浪费时间的任务之一就是花时间搜索“那个决定是在哪里做出的？”当规范在 Notion 中，讨论在 Slack 中，批准在邮件中，状态在 Jira 中，最终文档在 Google Drive 中时，光是搜索就会耗尽精力。
企业搜索可以交叉搜索已连接的聊天、邮件、云存储、维基、项目管理、CRM 和工单管理，并将结果去重整合为一个答案。当你向 /enterprise-search:search 抛出一个问题时，Claude 会将问题分解为每个源的查询，并附上引用进行整合。使用 /enterprise-search:digest --daily 或 --weekly，你可以按主题总结决策、行动项和提及。
对于开发者来说，它在查找过去的 ADR、事件响应、API 变更历史、特定功能的所有者以及客户请求方面非常强大。例如，你可以问：“我们为什么决定使用外部 IdP 而不是自己构建认证？”或“这个表的所有者是谁？”或“之前对支付失败的临时修复是什么？”它对于新成员入职也很有效。
它的弱点是无法找到未连接位置的信息，并且搜索范围取决于你的访问权限。从只连接必要的来源开始，如 Slack、文档和项目管理，而不是不加区分地扩展到私人 DM 或机密文件夹。始终让它将源文档附加到答案中，并区分“未找到”和“不存在”，以确保安全使用。
4. 数据 | 从 SQL 和可视化到分析验证
数据不仅仅是一个生成 SQL 的插件。它将数据探索、质量检查、统计分析、可视化、HTML 仪表板创建和共享前验证视为一个完整的分析过程。
主要命令包括用于从问题开始进行分析的 /data:analyze，用于检查数据集形状、缺失值和异常值的 /data:explore-data，用于编写 SQL 的 /data:write-query，用于使用 Python 制作图表的 /data:create-viz，用于交互式 HTML 仪表板的 /data:build-dashboard，以及用于检查分析方法和聚合逻辑的 /data:validate。它可以通过 MCP 连接到 Snowflake、Databricks、BigQuery 等，并且可以在没有连接的情况下处理 CSV、Excel 或粘贴的结果。
在 Claude Code 中方便的是能够在分析 SQL 和产品代码之间来回切换。例如，在实现新的入职流程之前调查流失点，在发布后使用相同的定义重新计算指标，并可视化差异。在 Bug 调查中，你可以快速验证假设，例如“失败率是否仅对特定版本的用户高？”或“数据迁移后 NULL 值是否增加了？”
最有价值的命令实际上是 /data:validate。即使 AI 可以快速编写 SQL，它也容易在分母选择、重复行、时区、幸存者偏差或包含测试用户方面出错。你应该在分析后将其作为单独的步骤进行验证，指定使用的表、过滤器、时间段、指标定义和排除条件。在连接到生产数据库时，最初限制为只读权限。
5. 设计 | 连接设计审查与实现交接
设计不是一个用于生成看起来“还行”的图像的插件。它是一个用于产品设计的实用工具集，涵盖设计评审、设计系统管理、UX 文案、可访问性审计、用户研究整合和开发者交接。
/design:critique 从可用性、视觉层次、一致性和可访问性的角度进行审查，而 /design:design-system 审计组件、标记、命名和模式。/design:handoff 创建包含尺寸、状态、交互和边缘情况的实现规范，/design:ux-copy 协助为错误消息、空状态和引导流程提供微文案。/design:accessibility 和 /design:research-synthesis 也可用。
当与 Claude Code 一起使用时，最好在让 Claude Code 将 Figma 视觉效果直接转换为代码之前，先用 Design 找出规范中的漏洞。让它列出从屏幕截图中不明显的状态，例如“有悬停状态，但键盘焦点呢？”或“我们如何显示加载、空状态、权限不足或通信失败？”或“它会在长日语文本或 200% 缩放时出现问题吗？”然后，将交接内容作为实现需求传递给 Claude Code。
关于可访问性审计，虽然它可以简化从 WCAG 角度的检查，但它不能取代使用真实浏览器、屏幕阅读器、键盘操作或真实用户的验证。正确的用法是使用 Design 创建审查项目，并将其连接到浏览器测试和人工验证。
6. PDF 查看器 | 不仅仅是阅读 PDF，而是在查看时进行编辑
PDF 查看器与 Claude 自带的 PDF 摘要功能不同。它可以在交互式查看器中打开本地文件或直接 PDF 链接，以进行高亮、注释、添加印章、填写表单、放置签名图像，并保存编辑后的 PDF。
使用 /pdf-viewer:open 显示，使用 /pdf-viewer:annotate 逐页反映注释建议。/pdf-viewer:fill-form 按顺序填写输入字段，/pdf-viewer:sign 放置签名或首字母图像。它使用 @modelcontextprotocol/server-pdf 通过 npx 作为本地 MCP 服务器运行，要求 Node.js 18 或更高版本。
对于开发者来说，它可以用于审查 API 规范、需求定义、安全审计报告、供应商提案和合同。与其只是说“总结问题”，不如要求它“在需要更改的地方放置注释，并用黄色标签组织问题，用红色标签组织阻碍项”，这样它就变成了一个可以返回给对方的可交付成果。
另一方面，如果你只是想阅读内容，Claude 自带的 PDF 阅读功能更快。当你希望在视觉确认的同时进行书写，并带走最终文件时，应使用 PDF 查看器。另外，请注意 sign 放置的是视觉签名图像，而不是使用证书的加密电子签名。对于需要法律效力的合同，必须使用专用的电子签名服务。
7. 运营 | 将个人任务转化为 SOP 和 Runbook
运营看起来像是用于业务管理的，但在开发组织中也相当有用。它协助进行供应商评估、业务流程文档、变更管理、容量规划、管理层状态报告和 Runbook 创建。
/operations:vendor-review 组织成本、风险、合同和续约决策，而 /operations:process-doc 创建流程、RACI 和 SOP。/operations:change-request 创建包含影响分析、批准路径和回滚计划的变更请求，/operations:capacity-plan 分析负载和人员。/operations:runbook 将例行任务转化为可重复的文档，包括流程、检查清单、故障排除和升级点。
与 Claude Code 结合使用时，它在将发布和运营从“代码之外的记忆”中解放出来方面非常强大。例如，将数据库迁移过程总结为变更请求，创建执行前检查、监控项、中止条件、回滚 SQL、人员和联系消息。在故障发生后，使用 Engineering 创建事后分析，并使用 Operations 将其反映在 Runbook 中。
一个注意事项是，切勿将 Claude 编写的程序未经尝试就正式启用。Runbook 应在 Staging 环境中执行，由人工验证命令、权限、所需时间以及如何回滚。Operations 加快了文档创建速度，但需要演练才能将其完善为可在实际环境中运行的程序。
8. 营销 | 使用 Claude Code 运行发布后的“交付工作”
即使你构建了一个很好的功能，如果发布说明、博客、电子邮件、LP、SNS 和销售解释不到位，它也不会被使用。营销协助开发完成后发生的内容创建和活动设计。
/marketing:draft-content 创建博客、SNS、新闻通讯、LP、新闻稿和案例研究，而 /marketing:campaign-plan 创建包括目标、对象、渠道、时间表和 KPI 的计划。/marketing:brand-review 检查与品牌声音的一致性，/marketing:competitive-brief、/marketing:performance-report、/marketing:seo-audit 和 /marketing:email-sequence 也可用。预计将集成 Slack、Canva、Figma、HubSpot、Amplitude、Notion、Ahrefs、Similarweb、Klaviyo 等。
对于 Claude Code 用户来说，让它从代码差异创建推广材料的流程很方便。从仓库中读取更改的功能、目标用户、已知约束和迁移步骤，并分别创建技术发布说明、一般用户公告和销售 FAQ。由于内容的来源相同，跨渠道的解释不太可能冲突。
然而，如果在没有品牌设置的情况下使用，它往往会生成安全的、AI 风格的文字。提供禁止使用的表达、词汇表、有代表性的过往文章、如何称呼客户以及可以断言的范围，最后通过 brand-review 进行检查，可以提高其效用。对于性能报告，如果连接数据的定义模糊，它会误解结论，因此应固定 KPI 定义和比较周期。
9. 法律 | 加速合同审查，但最终判断权在人类手中
法律处理内部法律部门的合同审查、NDA 初步判定、合规性、法律简报和标准回复。特别重要的是，您可以在 legal.local.md 中设置公司的谈判策略和风险承受能力，并与之进行比较，而不是泛泛地阅读合同。
/legal:review-contract 为每个条款找到与公司剧本的差异，并组织风险和修订建议。/legal:triage-nda 执行初步分类，如 GREEN、YELLOW、RED，/legal:vendor-check 从连接目标检查现有的 NDA、MSA、DPA、截止日期和关键条件。/legal:brief 和 /legal:respond 可以创建案例摘要和起草对标准查询的回复。
在开发环境中，它可以用于 SaaS 合同、云使用条款、DPA、NDA、外包合同和安全条款的初步整理。在移交给法律部门之前，用它来提取讨论点，如数据位置、子处理者、责任限制、知识产权、终止和审计权，并创建问题列表是现实的。
但是，官方 README 也明确指出，这不构成法律建议，需要由合格的专业人士进行验证。此外，初始剧本示例基于美国法律和商业惯例，如果在日本法律或公司政策下使用，则必须重建设置。更安全的做法是将 AI 的判定限制在点提取和初步整理，而不是使其成为审批流程中的最终关卡。
10. 小企业 | 对独立开发者和小企业来说转化最大的插件
小企业是一个处理小企业整体运营的插件，而不是协助特定工作类型。它具有 15 个基本技能、15 个执行工作流和一个路由器，可以从自然语言中引导你找到合适的流程。如果你正常咨询它，例如“我担心是否能支付工资”、“销售额下降了”、“我收到了一封愤怒的客户邮件”或“我应该涨价吗？”，它旨在引导你进入必要的流程。
它包括用于检查现金流和未收发票的 /small-business:plan-payroll，用于展望 30 天的 /small-business:month-heads-up，用于进行月结的 /small-business:close-month，用于比较利润率和价格的 /small-business:price-check，用于设置销售活动的 /small-business:run-campaign，用于处理投诉的 /small-business:handle-complaint，以及用于总结每周状态的 /small-business:monday-brief。预计将集成 QuickBooks、PayPal、HubSpot、Canva、Gmail、Microsoft 365、DocuSign 等，并且设计包括对涉及金钱或客户的流程的审批检查点。
对于独立开发者和小型 SaaS 运营商来说，它减少了“除了开发之外所有事情都拖延的问题”。使用 Claude Code 构建功能，使用 Small Business 运行销售、问询、计费、推广、合同和每周复盘。对于只有所有者了解情况的企业，拥有标准工作流程的效果更大。
另一方面，鉴于连接目标众多，权限设计应谨慎。不要一次性连接会计、支付、CRM 和电子邮件，而是从一两个以读取为主的连接开始。对于退款、发送和客户数据更新，始终要求预览和审批。此外，官方声明其不提供专业的财务、税务、法律或人力资源建议，这必须作为前提。
如果按目的选择，这些组合很强大
如果你独自构建产品，Engineering、Product Management、Design、PDF Viewer 和 Small Business 的组合很容易处理。你可以决定需求、实现、检查 UI、处理外部文档，并连接业务运营。你不需要一直使用所有插件；你可以切换，例如在开发期间使用 Engineering 和 Design，在销售或运营期间使用 Small Business。
对于一个几人的开发团队，Engineering、Enterprise Search、Data、Operations 和 Legal 很强大。你可以找到过去的决策，用数据验证假设，留下变更程序，并尽早识别法律或合规点。如果你添加 Product Management，它就变成了从需求到实现、验证和内部共享的单一流程。
对于产品发布或重大版本发布，Product Management、Design、Engineering 和 Marketing 这四个插件很有效。通过让 PRD、设计规范、实现和公告依次继承相同的假设，可以减少“所构建的内容”与“所传达的内容”之间的差距。
安装官方插件的 4 个注意事项
首先，不要混淆 Desktop 版本中的安装状态与 Claude Code 的安装过程。在 Desktop 中，你从目录中添加；在 Claude Code 中，最可靠的方法是注册官方市场并安装目标插件。虽然官方仓库说相同的插件可以在 Cowork 和 Claude Code 中使用，但可用的连接器和执行环境不一定相同。
其次，不要将连接器视为“方便的搜索目标”，而是视为具有权限的外部集成。对于只读就足够的任务，不要授予写入权限，尤其要缩小会计、支付、电子邮件、合同和个人信息的范围。将仅创建结果的处理与涉及发送、更新或审批的处理分开，并对后者进行人工验证。
第三，不要一次安装太多插件。随着技能和命令的增加，选择哪个程序的判断也会增加，并且类似的功能往往会重叠。从直接解决你瓶颈的 2-3 个开始。例如，如果审查需要时间，选择 Engineering；如果规格模糊，选择 Product Management；如果有大量信息搜索，选择 Enterprise Search。
第四，将插件输出视为“可验证的草稿”而不是“成品”。检查 SQL 执行结果和定义，在浏览器中尝试设计，排练 Runbook，并让专家检查合同。即使你扩大了留给 AI 的范围，你也不能转移批准的责任。
结论：前 3 个应该是工程、产品管理和企业搜索
可以从 Claude Desktop 的 Anthropic 目录中选择的官方插件不仅仅是附加提示的集合。它们将特定工作的知识、可重复使用的程序和与外部工具的连接捆绑到一个包中，作为使 Claude 与你工作方式保持一致的一种机制。在官方仓库中也提供了将这些方法引入 Claude Code 的方法。
如果我只选择三个开始，我会推荐 Engineering、Product Management 和 Enterprise Search。使用 Engineering 来提高实现和运营的质量，使用 Product Management 来减少构建前的歧义，使用 Enterprise Search 来恢复组织过去的知识。仅凭这三个，Claude Code 就从“一个编写代码的 AI”更接近于“一个连接规格、实现、判断和共享的开发平台”。
如果你处理数据，就添加数据；如果你偏向 UI 设计，就添加设计；如果你经常交换文档，就添加 PDF 查看器；如果你是个人或小型 SaaS 业务，就添加小企业。关键不是把所有东西都放进去，而是选择一个最适合你每天浪费最多时间的流程的角色。
