keywords对Packagist搜索排名影响极小，真正起作用的是下载量、更新频率、依赖健康度和用户点击转化率；填错不会拉高排名，但堆砌泛词或大小写不一致会稀释相关性，拖慢精准发现速度。
keywords字段本身对Packagist搜索排名影响极小，真正起作用的是下载量、更新频率、依赖健康度和用户点击转化率。填错 keywords 不会拉高排名，但堆砌泛词或大小写不一致会稀释包的相关性，间接拖慢被精准用户发现的速度。
keywords怎么填才不算白填
Packagist 对 keywords 的匹配是精确词干匹配，不支持模糊或语义扩展。它只在用户手动输入某个关键词（比如搜 redis）时，作为辅助筛选条件之一。
- 只填 3–5 个最具体、用户真会搜的小写词，例如
["laravel", "rate-limiting", "api", "redis"]；别写["php", "tool", "package"] - 避免大小写混用：
"Redis"和"redis"被视为不同词，统一用小写 - 不要重复包名或 vendor 名——
myorg/laravel-cache里再写"laravel-cache"是冗余 -
keywords必须是字符串数组，不能是逗号分隔的字符串："keywords": ["laravel", "cache"]✅，"keywords": "laravel,cache"❌（JSON 解析失败）
description和type字段比keywords更关键
这两个字段直接影响 Packagist 页面展示、分类页可见性，甚至长尾搜索命中率。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
description要写成一句完整话，开头就嵌入 1–2 个核心关键词 + 动词短语，例如："A PSR-6 cache adapter for Redis using phpredis, built for high-concurrency CLI applications" -
type必须填准确类型："library"、"laravel-package"、"wordpress-plugin"；填错会导致包被过滤出对应分类页 - 如果
type是"composer-plugin"，但 autoload 配置错误，Packagist 会标为 “broken”，直接降权
为什么改了keywords后排名没变化
Packagist 的搜索排序不是只看 keywords，它综合了下载量、星标数、更新频率、require 版本约束合理性、以及用户点击转化率。刚提交的修改不会立刻生效。
- 确认修改已 push 到默认分支，并触发 Packagist 自动同步（检查页面右上角
Last updated时间戳是否刷新） - 等待 12–48 小时，Packagist crawler 才会重新抓取并索引
-
composer search命令查不到新关键词——它只读本地缓存，且早已废弃；必须去 packagist.org 手动搜 - 搜索时不加引号：
cache redis是“或”关系，不是短语匹配
真正能快速提升搜索位的动作
相比 keywords，这几项改动上线后 1–2 周内就能看到搜索位置浮动：
- 把
require中的 PHP 和框架版本写明确，例如"php": "^8.1"、"laravel/framework": "^10.0"；搜索结果页显示的标签全来自这里 - 确保
autoload配置正确，特别是psr-4映射路径无误；autoload 失败 = “broken” 标签 = 搜索隐藏 - 保持更新节奏：最近 release 时间越近（如
v2.3.0 (2026-03-28)），越容易进 Trending 榜 - GitHub star 数 ≥ 5k 且近 6 个月有合并 PR，比堆关键词更能建立信任权重
最容易被忽略的点是：Packagist 不会因为你写了 "keywords": ["fast", "lightweight"] 就认为你的包真的快——它只认客观信号：PHP 版本兼容性是否最新、autoload 是否 classmap-authoritative、CI 是否通过、是否有活跃 issue 交互。这些才是爬虫每天在扫的真实指标。
