AI 工作方法 / 2026.09.26

封面｜原创概念视觉，非产品截图

你可能也遇到过这种情况：上周刚告诉 AI，周报要先写结论、不能漏掉待确认事项；这周重新开始，又得把要求说一遍。真正让人疲惫的，往往不是打字，而是反复纠正同一种偏差。

9 月 25 日，Anthropic 发布了 Claude 插件提交门户的介绍。开发者可以提交、跟踪审核，通过后再决定发布。门户面向付费 Claude 计划的开发者。这是一项发布流程更新，不能据此理解为所有用户的任务都已自动化。[1][2]

官方文档把插件描述为承载扩展能力的包：它可以包含连接器、Skill 等组成部分，不必每种都有。Skill 用来说明工作步骤和结果标准；连接器则用于接触产品或数据。具体平台会加载哪些部分，仍需要查看对应支持范围。[3]

打个便于理解的比方：你交给同事一张做事说明，是告诉他“怎么做”；给他一个已经确认可用的工具入口，是让他“到哪里做”。这两件事可以配合，也可以只需要其中一种。这个比方用来区分职责，不是对任何插件能力的保证。

概念图解｜方法与工具按任务需要组合

对普通读者，我更建议先观察自己的工作，而不是先找一份最长的插件清单。哪些事情总要重复交代格式？哪些错误你已经纠正了很多次？哪些输出一拿到，你就知道该怎么验收？这些问题比追新名词更接近实际需要。

例如，每周把零散事项整理成下周待办。如果你每次都在强调“已经完成的别再列进去”“没有日期的不要编日期”，这些要求就值得单独写下来。它们并不高深，却决定了结果到底能不能拿来用。

相反，如果一件事只是偶尔做一次，需求也没有固定形态，先写清当前说明就可以。把不稳定的要求过早固定下来，反而可能让你花更多时间维护。这里是本文的工作建议，不是官方对省时效果的承诺。

下面以“整理每周待办”为例，给出一个可以自己尝试的草稿框架。它没有连接真实账号，也没有运行某个现成插件，因此请把它当成设计练习，而不是已经验证过的自动化案例。

先写输入：我会提供什么？可以是一份本周事项，附上已经完成的标记、明确的截止日期，以及不能改动的安排。没有提供的内容，就不要让系统自行补成事实。

再写步骤：先合并表达不同但含义相同的事项，再区分已完成和未完成，最后按我给出的优先级整理。优先级不明确的，单独列为待确认，不强行替我做决定。

接着写输出：希望得到一份能逐条核对的清单。每项包含事项、当前状态、已知时间；缺少的信息留空或标明待确认。格式不必漂亮到像报告，先保证我能看出哪里需要补充。

最后写验收：有没有漏掉明确事项？有没有把已完成的重新安排？有没有编造时间？把这些检查点写在前面，后续无论用普通对话还是寻找相应插件，都有一个共同的判断依据。

编辑示例｜输入、步骤、输出和验收；未做账号功能实测

选几份不含敏感信息的小样本：一份内容完整，一份有重复，一份缺少日期。它们不需要很复杂，只要能覆盖你最在意的情况。每跑一次，就对照刚才的验收清单，记录哪些地方仍然需要你修改。

如果结果看上去整齐，但总把未知日期补出来，问题并没有解决。你可以调整说明，再用同样的样本试一次；如果修改只是让文字更好看，却没有减少实际返工，也要承认这条流程暂时不适合自己。

建议给流程留一个小版本记录：改了什么要求，为什么改，哪份样本暴露了问题。这样你积累的是可检查的经验，下一次调整也有依据。没有自己的测试，不要把别人的演示当成自己账户一定能实现的结果。

本文未在你的 Claude 账号里安装或实测插件；不同客户端支持、账号条件、所需工具连接和具体插件说明，都可能影响结果。新门户的存在，也不能证明某个第三方插件适合你的业务，或不会产生额外费用。

我对这次更新的判断是：工作方法有了更明确的分发路径，普通人更值得练习的能力，是把自己的要求写成别人能照着做、自己能验收的步骤。插件是承载方式，方法本身才是你长期积累的东西。

今天可以先选一件最常重复的小事，写下输入、步骤、输出和验收。你最想先整理的是周报、资料汇总，还是内容提纲？