composer init 仅生成空壳 composer.json，必须手动校验 name 格式、配置 autoload、运行 validate 和 install；缺一不可，否则导致 class not found、CI 失败或 Packagist 拒绝。
直接用 composer init 生成 composer.json 很快，但填错一个字段，后续 class not found、CI 失败、Packagist 拒绝提交 就几乎必然发生。它不是“初始化项目”，只是生成一个空壳 JSON 文件，所有关键配置都得你亲手把关。
Package name 必须是 vendor/name 格式，否则 validate 直接失败
交互式运行时第一步就卡在 Package name，输 myapp 或 MyApp 或 my_app 都会报 Invalid package name。Composer 强制要求两段式小写、带斜杠的格式：
-
acme/blog合法；myorg/mycli合法 -
myapp（缺/）、MyApp（含大写）、my app（含空格）全部非法 - Git 用户名含中文或空格时，
composer init可能自动读取并拼出非法包名，建议始终显式传--name="myorg/myapp" - 老项目迁移别偷懒用目录名，
legacy-site应写成acme/legacy-site
autoload 不手动加，require 'vendor/autoload.php' 就等于白 require
交互流程里问到 Would you like to define your autoload rules?，必须选 yes，再选 PSR-4 —— 但注意：交互式模式下它**不支持直接输入 psr-4:App:src/ 这种格式**，只能一步步填命名空间和路径，且反斜杠必须双写：
- 命名空间填
App（末尾反斜杠不能少，单写App是 JSON 语法错误） - 路径填
src/（末尾斜杠推荐保留，与 PSR-4 规范一致） - 非交互模式下必须整段 JSON 传入：
--autoload='{"psr-4":{"App\":"src/"}}'（Shell 中反斜杠要双写） - 路径填错（比如类实际在
lib/却填src/），composer dump-autoload生成的映射为空，class_exists('AppFoo')直接返回false
--no-interaction 不是跳过思考，而是跳过提问——缺参数就退出
--no-interaction 不提供默认值，也不容许遗漏。少一个必需参数，命令立即失败，不生成任何文件：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必需字段包括：
--name、--author（格式为Name），缺一不可 -
--require可多次使用：--require="php:^8.1" --require="guzzlehttp/guzzle:^7.8"，不能合并成一个字符串 -
--type推荐显式设为project（普通应用/脚本），而非默认的library（否则可能被误当 SDK 引用） - 最小可用命令示例：
composer init --no-interaction --name="myorg/myapp" --author="Me" --type=project --require="php:^8.1"
生成后不验证、不安装，等于没做完
composer init 只写 JSON，不装包、不建 vendor/、不生成 vendor/autoload.php。这三步必须手动补上：
- 立刻运行
composer validate：它能发现name缺 vendor 段、authors缺邮箱、license写成MIT License（应为MIT）等硬伤 - 哪怕
require为空，也必须运行一次composer install，否则vendor/autoload.php根本不存在 - 如果
autoload已配但类仍加载失败，检查是否漏了composer dump-autoload（尤其修改过类路径后） -
type字段影响工具链行为：设成project才能避免 Symfony Flex 等工具忽略你的配置
最常被跳过的其实是 composer validate 和 composer install 这两步——前者能提前拦住 90% 的 CI 报错，后者才是让 autoload 真正生效的临门一脚。填完就走，等于只写了半张支票。
