Composer项目中真有中文元数据的仅有三处：私有镜像或Satis服务中自定义的extra字段（如"chinese_name"）、Git仓库README.md开头几行、composer.json的comments（需手动预处理），其余标准字段如name、description、keywords均强制英文且不支持中文。
Composer 中文元数据本身不被官方支持，直接基于它构建技术债评估模型会失败——因为 composer.json 的 name、description、keywords 等字段在 Packagist 生态中强制要求英文，中文内容通常只存在于注释或私有仓库的非标准字段里。
Composer 项目里哪部分真有中文元数据？
实际能拿到的中文信息非常有限，常见来源只有三处：
- 私有 Packagist 镜像或内部 Satis 服务中自定义的
extra字段（如"extra": {"chinese_name": "用户中心SDK"}） - Git 仓库的
README.md文件开头几行（需额外爬取并做 NLP 提取） -
composer.json的comments（PHP 原生不解析，需用json_decode(file_get_contents(), true, 512, JSON_INVALID_UTF8_IGNORE)手动预处理）
别指望 composer show --all 或 composer info 返回中文字段——它们只读取标准 schema，跳过所有非规范键。
用什么方式提取和结构化这些中文信息？
必须绕过 Composer 自身解析逻辑，改用底层文件读取 + 正则/NLP 工具链：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 对每个依赖，先用
composer show <vendor/name> --no-ansi获取安装路径，再读取对应composer.json文件 - 用
preg_match('/"chinese_name"\s*:\s*"([^"]+)"/u', $content, $m)提取extra中的中文字段（注意/u修饰符） - 对
README.md，用mb_substr($readme, 0, 2048)截断后丢给轻量级中文分词器（如jieba-php），提取高频业务词（“订单”“支付”“风控”）作为领域标签
别用 json_decode() 直接解析带中文注释的 composer.json——PHP 7.4+ 会因 BOM 或非法 Unicode 报 JSON_ERROR_UTF8，必须先 mb_convert_encoding($raw, 'UTF-8', 'auto')。
技术债指标怎么关联中文语义？
中文文本不能直接喂给传统技术债模型，得映射到可量化维度：
- “维护成本高”类描述 → 统计
extra.chinese_description中出现“临时”“兼容”“补丁”等词频，每出现一次加 0.3 分 - “文档缺失”类信号 → 若
README.md中中文段落少于 3 行，且无 “接口说明”“参数列表” 等关键词，扣 1.5 分 - “架构腐化”暗示 → 当
keywords含英文但extra.chinese_tag出现“单体”“耦合”“硬编码”，触发规则引擎标记为高风险模块
所有规则必须可配置、可关闭——因为中文表达歧义大，“重构”可能是褒义也可能是讽刺，靠词频硬匹配容易误报。
真正难的不是解析中文，而是让机器理解中文技术表述背后的上下文意图；一个写成“历史原因暂不修改”的注释，其技术债权重可能远超十个没文档的包——这点目前没有任何自动化模型能可靠捕捉。
