关键不是装没装上，而是命令路径、规则指定和退出码这三处没设对；必须用./vendor/bin/phpcs --standard=PSR12 --error-severity=1确保CI严格校验并中断失败。
直接装、直接跑、CI 不过线——关键不是装没装上，而是命令路径、规则指定和退出码这三处没设对。
vendor/bin/phpcs 才是项目内唯一靠谱的调用方式
全局安装 composer global require squizlabs/php_codesniffer 看似省事，但实际会埋下版本冲突、配置错位、CI 失效三重隐患。项目级安装才是可复现、可协作、可 CI 的基础。
- 必须用
composer require --dev squizlabs/php_codesniffer（加--dev） - 执行检查时别敲
phpcs，要敲./vendor/bin/phpcs（开头加./避免某些 shell 解析失败） - Windows 用户若在 composer script 里用
%*传参，Linux/macOS 下得换$@；更稳的做法是统一用@php vendor/bin/phpcs显式调用解释器 - CI 脚本里绝对不要依赖全局
phpcs命令——它可能根本不在 PATH 里，或版本不对
不写 --standard=PSR12 就等于没启动规则
phpcs 默认不加载任何标准，phpcs -i 能看到 PSR12 列出来，不代表它自动生效。不显式指定，就走空规则集，结果就是“检查了，但什么也没报”。
- PSR-12 从 PHPCS v3.5.0+ 原生支持，但低于该版本会报
ERROR: the coding standard "PSR12" is not installed，必须升级：composer update squizlabs/php_codesniffer --with-dependencies -
--standard=psr12大小写敏感，写成小写直接失败 - 想微调规则（比如放宽行宽），别堆命令行参数，建
phpcs.xml：
<?xml version="1.0"?>
<ruleset name="MyProject">
<rule ref="PSR12"/>
<rule ref="Generic.Files.LineLength">
<properties>
<property name="lineLimit" value="120"/>
</properties>
</rule>
<file>src/</file>
<file>tests/</file>
</ruleset>
之后直接 ./vendor/bin/phpcs 就会自动读这个文件。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
CI 里 phpcs 过了但其实有 Error？退出码没控制
默认情况下，phpcs 即使扫出 100 个 ERROR，也返回 0（成功），GitHub Actions 或 GitLab CI 就认为“检查通过”，后续流程照常走——这是最隐蔽的失效点。
- 必须加
--error-severity=1：只要出现任意 ERROR，就返回非 0 码，让 CI 中断 - 慎用
--warning-severity=0：把所有 WARNING 当 ERROR，容易因无关提示（比如 TODO 注释）导致构建失败 - 推荐组合：
--error-severity=1 --warning-severity=8，只对严重 Warning（等级 ≥8）触发失败 - 脚本里别漏掉
--extensions=php，否则默认只扫.inc文件，.php全被跳过
phpcbf 自动修复不能代替人工 review
phpcbf 确实能修缩进、空格、花括号位置等机械问题，但它对语义类规范无能为力。
- 它不会帮你拆分过长函数、补全类型声明、重命名模糊变量
- 强行跑
phpcbf后再提交，可能掩盖真实设计缺陷 - 建议仅用于 pre-commit 阶段做轻量格式修正，核心逻辑审查仍需人工 + PR 检查
- CI 中不建议自动运行
phpcbf并 commit 回去——那会让 diff 失控，历史难以追溯
真正卡住项目的从来不是“会不会装”，而是 ./vendor/bin/phpcs --standard=PSR12 --error-severity=1 这一行命令有没有写全、有没有放进 CI 步骤、有没有被 git hooks 实际触发。少一个参数，就等于没开开关。
