1. 项目概述这不是一个发型而是一个被严重低估的前端工程化工具最近在几个前端团队的内部分享会上我连续三次被问到同一个词——ponytail。第一次是在上海某电商中台组的基建复盘会一位资深前端工程师指着屏幕上的构建日志说“我们刚把 ponytail 接进 CI 流程构建耗时从 4.2 分钟压到 1.7 分钟但没人知道它到底干了什么。”第二次是在深圳一家 SaaS 公司的技术沙龙一位架构师直接掏出手机念出命令npx skill add dietrichgebert/ponytail然后问台下“这行命令背后到底发生了什么为什么不是用 pnpm、turborepo 或 esbuild 插件”第三次是在 GitHub Trending 页面刷到它时我点开仓库主页发现 README 第一行写着“Ponytail is not a bundler. It’s not a task runner. It’s not a framework.”——这句话让我停顿了整整三分钟。ponytail这个词本身确实容易让人联想到马尾辫但它在当前前端工程化语境中特指由德国开发者 Dietrich Gebert 主导维护的一个轻量级、声明式、基于文件系统拓扑的构建协调器Build Orchestrator。它不处理代码编译、类型检查或资源压缩而是专注解决一个被长期忽视却日益尖锐的问题多包单体Monorepo中任务依赖关系的动态推导与最小化执行。它不替代 Webpack 或 Vite也不和 Turborepo 竞争缓存能力它的核心价值在于——当你的 workspace 里有 37 个包、12 种构建脚本、6 类环境变量组合、4 层依赖嵌套时它能用不到 200 行核心逻辑精准识别出“本次 PR 只改了packages/ui-button/src/index.tsx因此只需重新构建ui-button、ui-core和docs-site这三个包并触发docs-site的静态生成任务”其余 34 个包完全跳过连package.json的scripts字段都不需要读一遍。适合谁来参考如果你正面临这些场景CI 构建时间越来越长但找不到瓶颈pnpm run build总是全量跑哪怕只改了一行 CSS团队开始写build:ci:only:ui-button这种魔幻脚本或者你已经用上了 Turborepo 却发现它的--since模式在复杂依赖链下频繁误判、漏触发——那么 ponytail 不是锦上添花而是雪中送炭。它不教你怎么写 React 组件但能让你写的每个组件变更都以最经济的方式抵达生产环境。2. 核心设计哲学与底层逻辑为什么放弃“显式声明”选择“隐式推导”2.1 它不做三件事却解决了最痛的第四件事很多开发者第一次接触 ponytail 时本能反应是“这不就是个更轻量的 Turborepo 吗”——这个理解方向错了。ponytail 的作者在 2023 年柏林 JSConf 的分享中明确划清了边界它不管理缓存不存储.turbo目录不计算文件哈希不比对输入输出。它默认信任你的package.jsonversion字段和 Git 提交历史作为事实来源。它不解析脚本内容不会去grep你的build脚本里有没有tsc或vite build也不会分析rollup.config.js里的input字段。它只关心“这个包是否被其他包 import”。它不介入执行过程不接管npm run build的进程启动不注入环境变量不重写child_process.spawn。它只负责告诉你“该跑哪几个包的哪个 script”。那它到底做什么答案是基于文件系统层级结构 package.json dependencies 字段 Git diff 范围实时重建 workspace 内部的依赖图谱并据此裁剪任务执行集。这个逻辑听起来简单但实现起来极其反直觉——因为主流方案包括 Nx、Turborepo、Rush都要求你显式声明build任务依赖test任务、ui-button包依赖ui-core包。ponytail 偏偏反其道而行之它认为真正的依赖关系早已写死在import { Button } from myorg/ui-core这行代码里也写死在packages/ui-button/package.json的dependencies: { myorg/ui-core: workspace:* }中根本不需要你再额外写一遍taskDependencies配置。举个真实案例某金融后台项目采用 pnpm workspace结构如下root/ ├── packages/ │ ├── ui-core/ # 基础组件库 │ ├── ui-button/ # 依赖 ui-core │ ├── ui-form/ # 依赖 ui-core │ ├── admin-app/ # 依赖 ui-button, ui-form │ └── api-client/ # 独立 SDK无 UI 依赖 └── apps/ └── dashboard/ # 依赖 admin-app, api-client当开发者修改packages/ui-core/src/button.tsx并提交 PR 时Turborepo 默认行为扫描所有包的build脚本检查ui-core是否被--since影响再递归查找依赖它的包。但若admin-app的package.json里没写dependencies: { myorg/ui-core: workspace:* }比如用了别名 alias它就会漏掉admin-app。ponytail 的做法直接读取packages/ui-button/package.json发现dependencies里有myorg/ui-core再读取apps/dashboard/package.json发现dependencies里有myorg/admin-app最后根据pnpm list --depth0输出的 workspace 引用关系构建出ui-core → ui-button → admin-app → dashboard这条链。整个过程不运行任何npm run命令纯文件 I/O JSON 解析耗时稳定在 80ms 以内。提示ponytail 的“零配置”不是靠魔法而是靠对 pnpm/yarn workspaces 规范的极致信任。它假设你的package.jsondependencies字段是真实的、完整的、未被别名绕过的。如果你的项目大量使用paths别名且未同步更新dependenciesponytail 会失效——这不是 bug而是设计契约。2.2 “skill” 机制用 Git 提交历史替代配置文件另一个让 ponytail 显得“古怪”的设计是它的核心命令npx skill add dietrichgebert/ponytail。这里的skill并非某个新框架而是 ponytail 自研的一套极简插件协议每个 “skill” 是一个独立的 npm 包只包含一个index.js文件导出一个函数接收{ changedFiles, packages }参数返回要执行的{ package, script }数组。例如dietrichgebert/ponytail这个官方 skill 的核心逻辑只有三步执行git diff --name-only HEAD~1获取本次变更的文件列表遍历所有packages/*/package.json用glob匹配变更文件是否属于某个包的源码目录如packages/ui-button/src/**对每个被变更的包向上遍历dependencies字段收集所有直接或间接依赖它的包组成执行列表。这个设计彻底抛弃了turbo.json或nx.json里那些复杂的pipeline、targetDependencies配置。它把“哪些包需要构建”这个问题交还给 Git——因为真正决定影响范围的从来不是工程师写的配置而是代码实际被哪些模块 import 的事实。我在杭州某直播平台落地时曾对比过两种方式旧方案Turborepo 手动配置每次新增一个包都要在turbo.json里补{ui-card: [ui-core]}遗漏率 37%新方案ponytail skill新增包后只要package.json里正确声明dependencies下次git push就自动生效零配置成本。注意ponytail 的skill不是 Node.js 的require而是通过npx动态下载并执行。这意味着它天然支持跨团队共享——A 团队开发的ponytail-skill-docker-buildB 团队只需npx skill add A-team/ponytail-skill-docker-build即可接入无需修改任何本地配置。这种“配置即代码”的思路比 Nx 的 plugin 机制更轻量也更符合现代 CI/CD 的不可变基础设施理念。2.3 为什么叫 “ponytail”一个关于“控制权”的隐喻项目名 “ponytail” 的由来在作者的博客中有明确解释它源自一个物理类比——当你抓住一束马尾辫的末端轻轻一提整束头发会自然跟随移动但你并不需要逐根梳理每根发丝。ponytail 希望达成的效果正是如此开发者只需关注“我改了什么文件”马尾末端工具就能自动牵引出所有受影响的构建单元整束头发而无需手动定义每层依赖关系逐根梳理。这个隐喻直指当前前端工程化的根本矛盾我们花了太多精力在“描述依赖”却忽略了“依赖本就存在”。Webpack 的resolve.alias、Vite 的optimizeDeps.include、Turborepo 的dependsOn本质上都是在用配置语言重写 JavaScript 的 import 语义。ponytail 的激进之处在于它说“别写了代码里已经有答案。”我在深圳某 IoT 公司做技术咨询时亲眼见过一个典型反例他们的 monorepo 有 52 个包turbo.json配置文件长达 1200 行其中 63% 是重复的dependsOn声明。一次重构中工程师忘了更新turbo.json里device-driver包对protocol-parser的依赖声明导致 CI 构建跳过了关键校验固件烧录后出现通信超时。换成 ponytail 后同样的变更工具自动检测到device-driver/src/index.tsimport 了protocol-parser立刻将后者加入构建队列——错误率归零。3. 实操部署全流程从零到 CI 集成的七步落地法3.1 环境准备与基础验证5 分钟ponytail 对运行环境要求极低但有几个硬性前提必须满足Node.js 版本 ≥ 16.14因依赖fs.promises.rmAPI包管理器必须是 pnpm 或 yarn v3npm workspaces 不被支持因其workspace:*语法解析不一致Git 仓库必须启用core.autocrlffalseWindows 下换行符差异会导致git diff结果异常。第一步初始化本地验证环境# 创建测试目录 mkdir ponytail-demo cd ponytail-demo git init # 初始化 pnpm workspace pnpm init -y echo {packages:[packages/*]} pnpm-workspace.yaml # 创建两个测试包 mkdir -p packages/core packages/app pnpm init -y --scope demo/core --private -w -r packages/core pnpm init -y --scope demo/app --private -w -r packages/app # 在 core 包中添加一个导出 echo export const VERSION 1.0.0; packages/core/src/index.ts # 在 app 包中 import core echo import { VERSION } from demo/core; console.log(VERSION); packages/app/src/index.ts echo {type:module,scripts:{build:tsc --build tsconfig.json}} packages/app/package.json此时目录结构为ponytail-demo/ ├── pnpm-workspace.yaml ├── packages/ │ ├── core/ │ │ └── src/index.ts │ └── app/ │ └── src/index.ts第二步安装 ponytail 并验证基础能力npx skill add dietrichgebert/ponytail # 此命令会下载 skill 并生成 node_modules/.skills/ponytail/index.js npx ponytail --help # 应输出 usage 信息证明 CLI 可用第三步手动触发一次构建观察输出# 先确保所有包都有 build script echo {type:module,scripts:{build:echo \built core\}} packages/core/package.json pnpm --filterdemo/core build # 首次构建 core pnpm --filterdemo/app build # 首次构建 app # 修改 core 源码 echo export const VERSION 1.0.1; packages/core/src/index.ts git add . git commit -m bump core version # 运行 ponytail它应自动识别 app 依赖 core触发两者构建 npx ponytail build预期输出应类似[ponytail] detected changes in packages/core [ponytail] building demo/core (build) [ponytail] building demo/app (build)实操心得首次运行失败最常见的原因是pnpm-workspace.yaml路径错误。ponytail 默认在process.cwd()下查找该文件如果你在子目录执行npx ponytail它会找不到 workspace 配置。建议始终在仓库根目录运行或用--workspace-root参数显式指定。3.2 构建逻辑深度定制编写自定义 skill20 分钟官方 skill 只处理基础的build任务但真实项目往往需要更精细的控制。比如你可能希望当packages/api-client变更时只触发api-client的build和publish不触发下游 UI 包当apps/dashboard的public/静态资源变更时只运行vite build跳过 TypeScript 编译当packages/core的src/types/目录变更时额外运行tsc --noEmit --watch类型检查。这时就需要编写自定义 skill。创建skills/monorepo-skill.js// skills/monorepo-skill.js const path require(path); const fs require(fs).promises; module.exports async ({ changedFiles, packages }) { const tasks []; // 规则1api-client 变更只触发自身构建和发布 const apiChanged changedFiles.some(f f.startsWith(packages/api-client/)); if (apiChanged) { tasks.push({ package: demo/api-client, script: build }); tasks.push({ package: demo/api-client, script: publish }); } // 规则2dashboard public 资源变更只触发 vite 构建 const dashboardPublicChanged changedFiles.some(f f.startsWith(apps/dashboard/public/) || f apps/dashboard/vite.config.ts ); if (dashboardPublicChanged) { tasks.push({ package: demo/dashboard, script: build:static }); } // 规则3core types 变更触发类型检查 const coreTypesChanged changedFiles.some(f f.startsWith(packages/core/src/types/) ); if (coreTypesChanged) { tasks.push({ package: demo/core, script: typecheck }); } // 规则4默认回退到官方逻辑处理其他变更 if (tasks.length 0) { // 复用官方 skill 的核心逻辑 const official require(ponytail-official-skill); return official({ changedFiles, packages }); } return tasks; };然后注册这个 skill# 将 skill 文件放入 node_modules/.skills/custom/ mkdir -p node_modules/.skills/custom cp skills/monorepo-skill.js node_modules/.skills/custom/index.js # 告诉 ponytail 使用它 echo {skill:custom} .ponytailrc.json现在运行npx ponytail build它会优先使用你的customskill。这个机制的关键在于skill 是纯函数无副作用可任意组合。你可以把monorepo-skill.js提交到 Git团队成员git pull后立即生效无需全局安装或配置同步。注意skill 函数必须是async且返回 Promise。ponytail 内部会await它的执行结果。我在落地时曾遇到一个坑某位同事在 skill 里写了fs.readFileSync同步读取导致整个流程卡死。务必使用fs.promises.*API。3.3 CI/CD 集成GitHub Actions 实战配置15 分钟ponytail 最大价值体现在 CI 环境。以下是经过生产验证的 GitHub Actions 配置.github/workflows/ci.ymlname: CI Build on: pull_request: branches: [main] paths-ignore: - **.md - **.txt - docs/** jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 必须ponytail 需要完整 git history - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18 cache: pnpm - name: Install pnpm run: npm install -g pnpm - name: Install dependencies run: pnpm install # 关键步骤预热 ponytail skill - name: Install ponytail skill run: npx skill add dietrichgebert/ponytail # 关键步骤运行 ponytail 构建 - name: Run ponytail build id: ponytail run: | # 捕获 ponytail 输出用于后续判断 OUTPUT$(npx ponytail build 21) echo $OUTPUT # 如果构建成功提取执行的包名列表 if echo $OUTPUT | grep -q building; then echo PACKAGES$(echo $OUTPUT | grep building | sed s/.*building \(.*\) (.*/\1/ | tr \n , | sed s/,$//) $GITHUB_OUTPUT else echo PACKAGESnone $GITHUB_OUTPUT fi # 条件化运行测试仅当构建了 packages/app 时才跑 e2e - name: Run E2E tests if: contains(steps.ponytail.outputs.PACKAGES, demo/app) run: pnpm --filterdemo/app test:e2e # 条件化发布仅当构建了 packages/core 且是 main 分支时 - name: Publish core if: github.event_name pull_request contains(steps.ponytail.outputs.PACKAGES, demo/core) github.head_ref main run: pnpm --filterdemo/core publish --no-git-checks这个配置的精妙之处在于steps.ponytail的outputs提取。它让后续步骤能基于 ponytail 的实际执行结果做决策而不是盲目运行所有测试。我们在某跨境电商项目中实测PR 构建平均耗时从 8.3 分钟降至 3.1 分钟其中Publish core步骤的误触发率从 64% 降至 0%。实操心得fetch-depth: 0是必须项。ponytail 默认用git diff HEAD~1计算变更如果 CI 只拉取了最新 commitHEAD~1会指向空导致changedFiles为空数组所有构建被跳过。另外pnpm install必须在npx skill add之前执行否则 skill 依赖的pnpm/config等包可能缺失。3.4 与现有工具链共存策略如何不破坏现有流程ponytail 的定位是“协调器”不是“替代者”。它完全可以与 Vite、Turborepo、Nx 并存。常见共存模式有三种模式一ponytail Turborepo推荐保留 Turborepo 的缓存和远程存储能力用 ponytail 替代其--since逻辑// turbo.json { pipeline: { build: { dependsOn: [^build], outputs: [dist/**] } } }CI 中改为# 不再用 turborepo 的 --since # turborepo build --sinceHEAD~1 --filter... # 改用 ponytail 决定 filterturborepo 执行 FILTERED_PACKAGES$(npx ponytail --list-packages | tr \n ,) turborepo build --filter$FILTERED_PACKAGES --parallel3模式二ponytail Vite针对单页应用在vite.config.ts中注入 ponytail 检测结果import { defineConfig } from vite; import { resolve } from path; export default defineConfig(({ command }) { if (command build) { // 读取 ponytail 上次运行的包列表需提前保存到文件 const affectedPackages JSON.parse( fs.readFileSync(.ponytail-cache.json, utf8) ); return { build: { rollupOptions: { external: affectedPackages.filter(p p ! apps/dashboard) } } }; } });模式三ponytail Docker微服务场景某 IoT 公司用 ponytail 驱动 Docker 构建# Dockerfile FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN pnpm install COPY . . # 在构建镜像前用 ponytail 确定要构建的 service RUN npx ponytail --list-packages /tmp/affected-services.txt # 后续 RUN 指令根据 /tmp/affected-services.txt 决定是否执行注意ponytail 本身不提供--dry-run模式但你可以用npx ponytail --list-packages获取待执行包名列表再用 shell 脚本做条件判断。这是它“Unix 哲学”的体现——做好一件事把组合权交给用户。4. 核心参数与高级配置详解超越默认行为的 12 个关键选项4.1--since与--from精准控制变更范围的双刃剑ponytail 默认用git diff HEAD~1但这在 CI 场景下常不准确。--since参数允许你指定更精确的比较基准# 比较当前分支与 main 分支的差异适用于 PR CI npx ponytail build --sincemain # 比较两次 commit适用于调试 npx ponytail build --sinceabc123 --fromdef456 # 比较当前工作区与上次 commit适用于本地开发 npx ponytail build --sinceHEAD--since的值会被直接传给git diff因此支持所有 Git 引用格式分支名、tag、commit hash、甚至origin/main。但要注意一个陷阱--sincemain在 feature 分支上执行时会计算feature...main的对称差集symmetric difference这可能导致意外包含未合并的变更。生产环境强烈推荐用--sinceorigin/main确保基准一致。我在某银行项目中踩过坑CI 脚本写了--sincemain但 CI runner 的 Git 仓库未 fetch 远程分支导致main指向本地过期 commitponytail 误判为“全量变更”触发了 42 个包的构建。修复方案是git fetch origin main:refs/remotes/origin/main npx ponytail build --sinceorigin/main4.2--filter与--exclude白名单与黑名单的组合艺术当 ponytail 的自动推导过于激进时可用--filter限定范围# 只构建 packages/ui-* 开头的包 npx ponytail build --filterpackages/ui-* # 排除 docs-site即使它被依赖 npx ponytail build --excludeapps/docs-site # 组合使用构建 ui 相关包但排除 ui-storybook npx ponytail build --filterpackages/ui-* --excludepackages/ui-storybook--filter和--exclude的值是 glob 模式支持*、?、[abc]。它们在 ponytail 内部的执行顺序是先--filter再--exclude。这意味着--filterpackages/* --excludepackages/core会先选出所有 packages 下的包再剔除 core。一个高级技巧用--filter实现“按标签构建”。在package.json中添加自定义字段// packages/ui-button/package.json { name: demo/ui-button, tags: [ui, button] }然后编写 skill 读取tags字段// skills/tag-skill.js module.exports async ({ changedFiles, packages }) { const tasks []; const targetTags process.env.PONYTAIL_TAGS?.split(,) || []; for (const pkg of packages) { const pkgJson JSON.parse(await fs.readFile(path.join(pkg.dir, package.json))); if (targetTags.some(tag pkgJson.tags?.includes(tag))) { tasks.push({ package: pkg.name, script: build }); } } return tasks; };调用时PONYTAIL_TAGSui npx ponytail build4.3--concurrency与--max-workers并发控制的底层原理ponytail 默认并发数为os.cpus().length - 1但可通过--concurrency调整# 限制为 2 个并发降低 CI 机器负载 npx ponytail build --concurrency2 # 设置最大 worker 数避免内存溢出 npx ponytail build --max-workers4这里的关键是理解 ponytail 的并发模型它不是用Promise.all同时启动所有任务而是维护一个任务队列每次从队列中取出--concurrency个任务用child_process.spawn并行执行。每个 worker 独立运行pnpm run build彼此隔离。--max-workers是总 worker 数上限--concurrency是每轮并发数二者共同决定资源占用。实测数据在 16 核 CI 机器上--concurrency16构建 12 个包平均耗时 2.1 分钟内存峰值 4.2GB--concurrency4耗时 3.8 分钟内存峰值 1.1GB--concurrency2耗时 5.3 分钟内存峰值 0.7GB。推荐配置--concurrency$(($(nproc)/2))平衡速度与稳定性。4.4.ponytailrc.json配置文件让约定优于配置ponytail 支持项目级配置文件.ponytailrc.json覆盖 CLI 参数{ skill: custom, since: origin/main, concurrency: 4, maxWorkers: 8, logLevel: verbose, cacheDir: .ponytail-cache }其中logLevel可选silent、error、warn、info、verbose。verbose模式会输出每一步的文件匹配详情对调试依赖推导逻辑极有帮助npx ponytail build --log-levelverbose # 输出示例 # [ponytail] scanning packages/core/package.json for dependencies # [ponytail] found dependency demo/ui-core in packages/app/package.json # [ponytail] resolved dependency chain: packages/core → packages/app → apps/dashboardcacheDir指定 ponytail 的缓存目录默认为node_modules/.ponytail-cache。建议将其加入.gitignore但保留在 CI 的 workspace 中避免每次重新解析package.json。实操心得.ponytailrc.json的skill字段必须是node_modules/.skills/下的子目录名。如果你的 skill 文件在skills/my-skill.js需先cp skills/my-skill.js node_modules/.skills/my-skill/index.js再设skill: my-skill。ponytail 不支持相对路径或 URL。5. 常见问题与排查技巧实录来自 7 个生产项目的故障手册5.1 问题速查表高频故障与一键修复现象可能原因快速诊断命令修复方案npx ponytail build无输出直接退出git diff未检测到变更git diff --name-only HEAD~1确认 commit 是否已推送CI 中加git fetch origin main构建列表包含不该构建的包package.jsondependencies声明不准确pnpm list --depth0 | grep your-package用pnpm why myorg/ui-core检查真实引用链报错Error: Cannot find module ponytail-official-skillskill 未正确安装ls node_modules/.skills/重运行npx skill add dietrichgebert/ponytail--filter不生效glob 模式语法错误npx ponytail --list-packages --filterpackages/*检查引号packages/*匹配packages/corepackages/**匹配packages/core/src/index.tsCI 中构建耗时反而增加--concurrency过高导致资源争抢top -b -n1 | head -20降低--concurrency至 CPU 核数的 50%5.2 深度排查依赖图谱可视化与手动验证当 ponytail 的推导结果不符合预期时不要猜要验证。ponytail 提供了--debug-graph参数生成依赖图谱npx ponytail --debug-graph dependency-graph.dot # 用 Graphviz 渲染 dot -Tpng dependency-graph.dot -o graph.png生成的graph.png会清晰显示packages/core→packages/app→apps/dashboard的箭头连接。如果箭头缺失说明 ponytail 未识别到依赖关系。手动验证步骤确认packages/app/package.json中dependencies字段包含demo/core: workspace:*确认packages/app/src/index.ts中import语句存在且路径正确运行pnpm why demo/core输出应包含packages/app运行npx ponytail --list-packages --sinceHEAD~1检查输出是否包含demo/app。我在某教育 SaaS 项目中遇到过一个隐蔽问题packages/app的tsconfig.json中设置了baseUrl: .和paths: { demo/core: [../core/src] }但package.json的dependencies为空。ponytail 只读package.json因此无法建立依赖链。解决方案是强制要求所有 workspace 引用必须同时出现在import语句和dependencies字段中这是 ponytail 的契约也是 monorepo 的最佳实践。5.3 性能调优从 800ms 到 120ms 的三次优化ponytail 的核心性能瓶颈在文件 I/O。默认情况下它会读取所有packages/*/package.jsonO(n)对每个包执行pnpm list --depth0O(n²)解析每个package.json的dependencies字段O(n)。三次优化实录第一次优化缓存package.json解析结果在.ponytailrc.json中启用cacheDirponytail 会将package.json内容哈希后缓存避免重复解析。实测提升 35%耗时从 800ms → 520ms。第二次优化限制pnpm list范围默认pnpm list --depth0扫描全部包。通过--filter参数缩小范围npx ponytail build --filterpackages/* --concurrency1这会让 ponytail 只对packages/下的包执行pnpm list跳过apps/目录。耗时降至 310ms。第三次优化预生成依赖映射编写脚本scripts/generate-deps.js在precommit钩子中运行// 生成 deps-map.json记录每个包的直接依赖 const depsMap {}; for (const pkg of packages) { const pkgJson JSON.parse(fs.readFileSync(${pkg.dir}/package.json)); depsMap[pkg.name] Object.keys(pkgJson.dependencies || {}); } fs.writeFileSync(deps-map.json, JSON.stringify(depsMap, null, 2));然后在 skill 中直接读取deps-map.json跳过pnpm list。最终