require-dev 工具本地运行需通过 vendor/bin/ 调用或 composer scripts 统一入口，而非全局命令；CI 需确保 --no-dev 未启用且缓存正确，scripts 中定义如 "test": "phpunit" 可跨平台一致执行。
require-dev 装的工具，为什么本地跑不起来？
因为 require-dev 只控制依赖安装范围，不自动把二进制文件加进 $PATH。你装了 phpunit/phpunit 或 friendsofphp/php-cs-fixer，但直接敲 phpunit 报 “command not found”，不是装错了，是没走对调用路径。
- Composer 默认把 dev 工具的可执行文件放在
vendor/bin/下，不是全局命令 - 必须用
vendor/bin/phpunit这种相对路径调用，或把vendor/bin加进 shell 的$PATH（不推荐在团队中强制） - 更稳妥的做法：统一通过
composer exec或scripts调用 —— 这样不依赖环境配置，新人拉代码就能跑
怎么用 scripts 统一定义团队开发命令？
把工具调用逻辑收口到 composer.json 的 scripts 字段里，既屏蔽路径差异，又明确意图。比如所有成员都用 composer test 跑测试，而不是各自记 vendor/bin/phpunit 或 ./vendor/bin/phpunit。
-
scripts中的命令默认在项目根目录执行，vendor/bin/下的工具可直接引用（Composer 会自动识别） - 避免写绝对路径或假设
./vendor/bin存在；优先用phpunit而不是vendor/bin/phpunit - 示例片段：
"scripts": {
"test": "phpunit --colors=always",
"cs-fix": "php-cs-fixer fix --dry-run --diff",
"cs-check": "php-cs-fixer fix --dry-run --diff"
}
这样 composer test 在 Windows/macOS/Linux 上行为一致，且不污染全局环境。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
require-dev 里该放哪些包？判断标准是什么？
只放「仅在开发、测试、CI 环境需要，运行时完全不需要」的工具。不是“有用就加”，否则会拖慢生产部署、增大镜像体积、引入非预期兼容问题。
- ✅ 推荐：静态分析（
phpstan/phpstan）、格式化（friendsofphp/php-cs-fixer）、测试（phpunit/phpunit）、构建（humbug/phar-updater） - ❌ 避免：带运行时依赖的库（如
symfony/var-dumper在开发中常用，但它会被代码直接 require，应进require）、CLI 工具但实际被应用代码调用的（如aws/aws-sdk-php的 CLI 封装） - 注意：有些包同时提供库和 CLI，比如
laravel/pint—— 它的 CLI 功能纯属开发辅助，放require-dev没问题；但如果项目代码里use Laravel\Pint\...，就得进require
CI 环境下 require-dev 安装失败或行为异常？
常见于 CI 使用了 --no-dev 或缓存策略不当。团队本地能跑，CI 却提示 Command "test" is not defined，大概率是 composer install 没装 dev 包，或者缓存复用了不含 vendor/bin 的旧层。
- 确保 CI 脚本显式执行
composer install --no-interaction（默认含 dev），而非--no-dev - Docker 构建时，如果分层缓存
vendor/，要确认composer.json和composer.lock变更后重新生成 vendor，否则vendor/bin可能缺失新工具 - CI 中慎用
composer global require—— 它绕过项目级require-dev，导致本地和 CI 行为割裂
dev 工具链的真正难点不在安装，而在让所有人——包括刚 checkout 项目的实习生——输入同一行命令，得到同一套反馈。路径、权限、缓存、CI 配置，任何一环松动，都会让“统一”变成一句空话。
