[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71V7KXYFC7HFN7P4BEGRENK":3,"skill-same:01M71V7KXYFC7HFN7P4BEGRENK":59},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":58},"01M71V7KXYFC7HFN7P4BEGRENK","nomi-intake-radar",null,"每次 Nomi 会话开始自动跑用户反馈雷达——先跑 `pnpm run intake:radar` 抓 Cloudflare 上的反馈\u002F用量事件并汇总，再对汇总结果做分诊：真 bug \u002F 配置问题 \u002F 体验问题 \u002F 数据上报问题，挂私有待办，给用户今天最该看的 1-2 件事。","aqm857886159\u002FNomi","aqm857886159","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F77039254?v=4","01M71V6AZN6880Q4X2G1XANS5E","青阳","01M71V6B08RP8GMYG9QBX9QXCH",651,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fagent-skills\u002Fnomi-intake-radar\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32],"nomi intake radar","intake","radar","cloudflare","run","数据","bug","pnpm","总结","2026-11-10 13:02:02",false,"---\nname: nomi-intake-radar\ndescription: 每次 Nomi 会话开始自动跑用户反馈雷达——先跑 `pnpm run intake:radar` 抓 Cloudflare 上的反馈\u002F用量事件并汇总，再对汇总结果做分诊：真 bug \u002F 配置问题 \u002F 体验问题 \u002F 数据上报问题，挂私有待办，给用户今天最该看的 1-2 件事。\n---\n\n# Nomi 用户反馈雷达\n\n目标：把「用户点了反馈按钮 \u002F 匿名用量事件」变成「今天最该改的 1-2 件事」。抓取和算数字是脚本的活（`scripts\u002Fintake-radar.mjs` + `scripts\u002Flib\u002Fintake-radar\u002F`），**这份技能只做判断**——分诊、归因、写待办、汇报。这个分工和 `feedback-radar.mjs`（GitHub\u002FB站\u002F微信反馈）、`model-radar.ts`（供应商模型雷达）是同一条线：脚本确定性、不花额度；技能才调 LLM 判断。\n\n## 入口\n\n1. 跑 `pnpm run intake:radar`（如果本轮会话开始时的「每日雷达」步骤已经跑过，直接读它的输出，不用重跑）。\n   - 失败会红着退出，终端明说「今天没查成」——这种情况**不要**把它读成「今天没有新反馈」，如实告诉用户抓取失败以及失败原因，不要往下分诊（没有新数据可分诊）。\n2. 报告在仓库外的缓存目录：默认 `%LOCALAPPDATA%\\nomi-intake\\reports\\\u003CUTC 时间>.md`（每轮一份，同一天多跑不会互相覆盖；同名 `.json` 是给这份技能读的结构化版本），可能被 `NOMI_INTAKE_CACHE` 改过位置——脚本终端输出的最后几行会打印这一轮报告的实际路径，认那个，不要假设默认路径。\n3. 读 `.json` 报告里的 `triage.items`（**这次要分诊的就是它**：还没记进待办的全部反馈，不只是这一轮新到的）、`newFeedback`（这一轮新到的）、`delivery`（送达：直达率、重复送达）、`logTail`（反馈包带没带上日志）、`generationResults`（成功\u002F失败\u002F取消分布，**默认已排除自动化事件**，被排除的条数在 `excludedAutomated`）、`failureReasons`（失败按原因排行，原因是分类码）、`errorCodeRanking`、`spikes`（突增）、`launches`\u002F`updateActions`。这些数字都已经算好，**不要重新数一遍**，也不要在没重新验证的前提下怀疑脚本的算术。\n\n## 先判断数据可不可信，再下结论\n\n看到成功率、错误码分布、突增这类数字异常时，第一反应不是「这是个 bug」，而是「这个数字覆盖的是不是它看起来该覆盖的那个总体」。上报链路本身有缺口时，数字会系统性失真，而不是随机噪音——先查缺口，缺口没排除之前任何百分比结论都要加限定语。\n\n已知的两个缺口（2026-09-29 查实，写进这里是为了不用每次都重新排查一遍；如果之后有人把它们接上了，删掉对应这条，别留着误导）：\n\n- **`generation.completed` 目前只覆盖「画布直生成」**：唯一的上报点是 `src\u002Fworkbench\u002Fapi\u002FtaskApi.ts` 的 `runWorkbenchTaskByVendor`（渲染层，画布节点执行器 `catalogTaskActions.ts` 调它）。**「制作流程」（ProductionRun，`electron\u002FproductionRun\u002F`，多镜头批量调度）和「Agent 付费卡」触发的生成（`electron\u002FcapabilityCore\u002FmcpStdioServer.ts`、`appIntegration.ts` 调 `createProductionGenerationSubmission`）整条链路里没有任何 telemetry 调用**——不是成功事件漏报而失败事件正常报，是这两条路径的生成**完全不出现**在 `generation.completed` 里，无论成败。所以任何从这份数据算出来的生成成功率，**只代表画布直生成这一条路径**，不能说成\"Nomi 的生成成功率\"。看到这类数字要在汇报里加一句「样本只覆盖画布直生成，制作流程\u002FAgent 生成不在里面」。这本身也是要挂私有待办的一条（数据上报问题，不是产品 bug），可以引用 `electron\u002Ftelemetry\u002FtelemetryOutbox.ts` 的 `recordTelemetryEvent`——它是渲染层 IPC 和主进程都能直接调的唯一出口，ProductionRun 要补报点时不用建新链路，在它判定终态的地方直接调这个函数即可（接线本身不在这份技能的职责里，只在待办里写清楚\"接到哪\"）。\n- **独立的 Agent 轨迹上报 2026-11-13 删了**（客户端队列、接收端路由、雷达前缀一起删；从没有发布版本发过）。轨迹只作为一键反馈包里的附件到达（`projectLaneTrajectory`，用户手动提交时附最近 3 个回合的白名单投影）。报告里不再有「轨迹条数」。\n- **定位读数（报告「定位读数」一节）**：按补丁版的失败率、失败里上游 `unknown` \u002F 本机规则 `uncoded` 的占比、上次没正常结束的启动占比、主进程停顿分布。只有 2026-11-13 之后的版本带这些格；老版本事件记成 `x.y.?` 或「不带细节」。`unknown` \u002F `uncoded` 占比高 = 码还没覆盖到，分诊时记成「补码」类待办，不要去猜具体原因。\n\n对生成结果按能力\u002F版本\u002F系统\u002F日期看的时候同理：事件的 `systemProps` 只有 `appMajor.appMinor`，没有补丁号——报告里出现的\"版本\"是\"0.22\"这个粒度，不是完整版本号，不要在汇报里假装精确到补丁版本。\n\n## 归类\n\n每条新反馈归到四类之一，写进私有待办前先定这个类：\n\n1. **真 bug**——Nomi 自己的代码\u002F设计导致用户做不成事，且可复现、可定位到具体模块。\n2. **配置问题**——用户自建\u002F中转渠道、模型 id、参数等配置错误，Nomi 按预期拒绝或报错；但如果报错文案让用户摸不清\"该怎么改\"，这本身是体验问题，两类可以同时成立。\n3. **体验问题**——功能能用，但流程绕、提示不清楚、需要用户多想一步；包括\"设计出来的保护性拦截\"（比如为避免白扣费主动拒绝某个操作）用户仍然觉得困惑的情况——护栏本身没错，但用户体验到的是一次\"卡住\"，值得记。\n4. **数据上报本身有问题**——现象不是产品行为异常，是遥测\u002F反馈链路本身漏报、误报、口径不一致（比如上面两个已知缺口这一类）。\n\n一条反馈可以同时挂多个类（比如\"真 bug + 体验问题\"），不必只选一个。\n\n## 归因到底层设计问题\n\n不要满足于\"这条反馈对应哪一行代码\"。先查这个现象是不是已经被结构性归过因——读 `docs\u002Faudit\u002F2026-09-29-hot-modules-structure-review.md`（四个热模块为什么扎堆）和它引用的 #897 结构簇（两台生成发动机 \u002F 同一件事多处判断 \u002F 跨边界约定没有共用定义 \u002F 投影层自己下结论 \u002F 失败不出声）。如果一条新反馈明显是这几类的又一个实例（尤其\"画布直生成 vs ProductionRun 两台发动机\"这条线——目前看到的很多生成类反馈最终都会落在这上面），在私有待办里点出它属于哪一簇，不要当成孤立新 bug 重新归因一遍；同一层 7 天内第三份根因合同要先出结构评审（R21），挂待办时可以提前标出\"这可能是第 N 份\"，帮后面派工的人少走一遍这个判断。\n\n## 挂私有待办\n\n- 私有待办是唯一真相源，这份技能只知道它叫\"私有待办\"，不在这份公开仓库的文件里写它的具体位置——运行这份技能的会话应该已经知道去哪读写它。\n- 先搜私有待办里有没有已经登记的相关条目（按模块\u002F症状关键词搜，不是按这条反馈的编号搜——同一个底层问题可能已经被换了个说法登记过）。有就把这条反馈的编号（`NF-MMDD-NNNN`）追加挂上去当新证据，不重复开条；没有就新记一条。\n- **记完就出账**：`pnpm run intake:radar -- --triaged \u003C编号…> --todo \u003C待办号或说明>`。不出账的话这一条每次开会话都还在「待分诊」里，这是有意的：看过不算处理过，只有记进待办才算。只是噪音不用记待办的也要出账，`--todo` 写明理由（比如「测试反馈，不用记」）。升级后第一次跑时缓存里已有的反馈会全部进账，对过账之后用 `--triaged-through \u003C日期> --todo \u003C说明>` 一次出完。\n- **写进待办的只能是归纳后的问题描述**：模块、现象、影响范围、属于哪个结构簇（如果查得到）。**不许**把用户反馈的原文摘要、留言原文、或反馈自带的附件内容（比如那份很大的 `model-catalog.json` 诊断快照）整段搬进待办——那些是本机缓存里的诊断数据，不是要长期保存的产品文档。要引用就用自己的话转述\"用户反馈说 X 场景下 Y 不工作\"，不逐字复制。\n\n## 汇报给用户\n\n大白话，今天最该动的 1-2 件事，不是把整份报告念一遍。格式：\n\n- 这件事是什么（一句话，说人话不说术语）\n- 为什么值得今天动它（新出现的 \u002F 影响面大的 \u002F 突增的 \u002F 卡住付费路径的，优先级从这几条里选）\n- 建议怎么处理（继续走正常修复流程 \u002F 需要用户拍板 \u002F 只是记录观察，不用现在动）\n\n如果待分诊是 0、也没有突增，如实说\"今天没有新东西\"，不要为了有话说而重复讲已经报过的旧发现。「新增 0 条」不等于没事：待分诊不为 0 就还有反馈没人管。\n\n## 隐私\n\n原始反馈\u002F事件只留在本机缓存目录（脚本已经保证不进仓库、不进任何提交）。这份技能自己的输出——包括私有待办里新增的条目——只能是归纳后的问题描述，不贴用户反馈原文、不贴附件内容、不贴账号 id、不贴任何价格\u002F成本数字。跟\"论文雷达\"\"模型雷达\"一样，这份技能的判断额度默认已授权，不用为了跑一次分诊再单独问用户。\n","# Nomi 用户反馈雷达\n\n目标：把「用户点了反馈按钮 \u002F 匿名用量事件」变成「今天最该改的 1-2 件事」。抓取和算数字是脚本的活（`scripts\u002Fintake-radar.mjs` + `scripts\u002Flib\u002Fintake-radar\u002F`），**这份技能只做判断**——分诊、归因、写待办、汇报。这个分工和 `feedback-radar.mjs`（GitHub\u002FB站\u002F微信反馈）、`model-radar.ts`（供应商模型雷达）是同一条线：脚本确定性、不花额度；技能才调 LLM 判断。\n\n## 入口\n\n1. 跑 `pnpm run intake:radar`（如果本轮会话开始时的「每日雷达」步骤已经跑过，直接读它的输出，不用重跑）。\n   - 失败会红着退出，终端明说「今天没查成」——这种情况**不要**把它读成「今天没有新反馈」，如实告诉用户抓取失败以及失败原因，不要往下分诊（没有新数据可分诊）。\n2. 报告在仓库外的缓存目录：默认 `%LOCALAPPDATA%\\nomi-intake\\reports\\\u003CUTC 时间>.md`（每轮一份，同一天多跑不会互相覆盖；同名 `.json` 是给这份技能读的结构化版本），可能被 `NOMI_INTAKE_CACHE` 改过位置——脚本终端输出的最后几行会打印这一轮报告的实际路径，认那个，不要假设默认路径。\n3. 读 `.json` 报告里的 `triage.items`（**这次要分诊的就是它**：还没记进待办的全部反馈，不只是这一轮新到的）、`newFeedback`（这一轮新到的）、`delivery`（送达：直达率、重复送达）、`logTail`（反馈包带没带上日志）、`generationResults`（成功\u002F失败\u002F取消分布，**默认已排除自动化事件**，被排除的条数在 `excludedAutomated`）、`failureReasons`（失败按原因排行，原因是分类码）、`errorCodeRanking`、`spikes`（突增）、`launches`\u002F`updateActions`。这些数字都已经算好，**不要重新数一遍**，也不要在没重新验证的前提下怀疑脚本的算术。\n\n## 先判断数据可不可信，再下结论\n\n看到成功率、错误码分布、突增这类数字异常时，第一反应不是「这是个 bug」，而是「这个数字覆盖的是不是它看起来该覆盖的那个总体」。上报链路本身有缺口时，数字会系统性失真，而不是随机噪音——先查缺口，缺口没排除之前任何百分比结论都要加限定语。\n\n已知的两个缺口（2026-09-29 查实，写进这里是为了不用每次都重新排查一遍；如果之后有人把它们接上了，删掉对应这条，别留着误导）：\n\n- **`generation.completed` 目前只覆盖「画布直生成」**：唯一的上报点是 `src\u002Fworkbench\u002Fapi\u002FtaskApi.ts` 的 `runWorkbenchTaskByVendor`（渲染层，画布节点执行器 `catalogTaskActions.ts` 调它）。**「制作流程」（ProductionRun，`electron\u002FproductionRun\u002F`，多镜头批量调度）和「Agent 付费卡」触发的生成（`electron\u002FcapabilityCore\u002FmcpStdioServer.ts`、`appIntegration.ts` 调 `createProductionGenerationSubmission`）整条链路里没有任何 telemetry 调用**——不是成功事件漏报而失败事件正常报，是这两条路径的生成**完全不出现**在 `generation.completed` 里，无论成败。所以任何从这份数据算出来的生成成功率，**只代表画布直生成这一条路径**，不能说成\"Nomi 的生成成功率\"。看到这类数字要在汇报里加一句「样本只覆盖画布直生成，制作流程\u002FAgent 生成不在里面」。这本身也是要挂私有待办的一条（数据上报问题，不是产品 bug），可以引用 `electron\u002Ftelemetry\u002FtelemetryOutbox.ts` 的 `recordTelemetryEvent`——它是渲染层 IPC 和主进程都能直接调的唯一出口，ProductionRun 要补报点时不用建新链路，在它判定终态的地方直接调这个函数即可（接线本身不在这份技能的职责里，只在待办里写清楚\"接到哪\"）。\n- **独立的 Agent 轨迹上报 2026-11-13 删了**（客户端队列、接收端路由、雷达前缀一起删；从没有发布版本发过）。轨迹只作为一键反馈包里的附件到达（`projectLaneTrajectory`，用户手动提交时附最近 3 个回合的白名单投影）。报告里不再有「轨迹条数」。\n- **定位读数（报告「定位读数」一节）**：按补丁版的失败率、失败里上游 `unknown` \u002F 本机规则 `uncoded` 的占比、上次没正常结束的启动占比、主进程停顿分布。只有 2026-11-13 之后的版本带这些格；老版本事件记成 `x.y.?` 或「不带细节」。`unknown` \u002F `uncoded` 占比高 = 码还没覆盖到，分诊时记成「补码」类待办，不要去猜具体原因。\n\n对生成结果按能力\u002F版本\u002F系统\u002F日期看的时候同理：事件的 `systemProps` 只有 `appMajor.appMinor`，没有补丁号——报告里出现的\"版本\"是\"0.22\"这个粒度，不是完整版本号，不要在汇报里假装精确到补丁版本。\n\n## 归类\n\n每条新反馈归到四类之一，写进私有待办前先定这个类：\n\n1. **真 bug**——Nomi 自己的代码\u002F设计导致用户做不成事，且可复现、可定位到具体模块。\n2. **配置问题**——用户自建\u002F中转渠道、模型 id、参数等配置错误，Nomi 按预期拒绝或报错；但如果报错文案让用户摸不清\"该怎么改\"，这本身是体验问题，两类可以同时成立。\n3. **体验问题**——功能能用，但流程绕、提示不清楚、需要用户多想一步；包括\"设计出来的保护性拦截\"（比如为避免白扣费主动拒绝某个操作）用户仍然觉得困惑的情况——护栏本身没错，但用户体验到的是一次\"卡住\"，值得记。\n4. **数据上报本身有问题**——现象不是产品行为异常，是遥测\u002F反馈链路本身漏报、误报、口径不一致（比如上面两个已知缺口这一类）。\n\n一条反馈可以同时挂多个类（比如\"真 bug + 体验问题\"），不必只选一个。\n\n## 归因到底层设计问题\n\n不要满足于\"这条反馈对应哪一行代码\"。先查这个现象是不是已经被结构性归过因——读 `docs\u002Faudit\u002F2026-09-29-hot-modules-structure-review.md`（四个热模块为什么扎堆）和它引用的 #897 结构簇（两台生成发动机 \u002F 同一件事多处判断 \u002F 跨边界约定没有共用定义 \u002F 投影层自己下结论 \u002F 失败不出声）。如果一条新反馈明显是这几类的又一个实例（尤其\"画布直生成 vs ProductionRun 两台发动机\"这条线——目前看到的很多生成类反馈最终都会落在这上面），在私有待办里点出它属于哪一簇，不要当成孤立新 bug 重新归因一遍；同一层 7 天内第三份根因合同要先出结构评审（R21），挂待办时可以提前标出\"这可能是第 N 份\"，帮后面派工的人少走一遍这个判断。\n\n## 挂私有待办\n\n- 私有待办是唯一真相源，这份技能只知道它叫\"私有待办\"，不在这份公开仓库的文件里写它的具体位置——运行这份技能的会话应该已经知道去哪读写它。\n- 先搜私有待办里有没有已经登记的相关条目（按模块\u002F症状关键词搜，不是按这条反馈的编号搜——同一个底层问题可能已经被换了个说法登记过）。有就把这条反馈的编号（`NF-MMDD-NNNN`）追加挂上去当新证据，不重复开条；没有就新记一条。\n- **记完就出账**：`pnpm run intake:radar -- --triaged \u003C编号…> --todo \u003C待办号或说明>`。不出账的话这一条每次开会话都还在「待分诊」里，这是有意的：看过不算处理过，只有记进待办才算。只是噪音不用记待办的也要出账，`--todo` 写明理由（比如「测试反馈，不用记」）。升级后第一次跑时缓存里已有的反馈会全部进账，对过账之后用 `--triaged-through \u003C日期> --todo \u003C说明>` 一次出完。\n- **写进待办的只能是归纳后的问题描述**：模块、现象、影响范围、属于哪个结构簇（如果查得到）。**不许**把用户反馈的原文摘要、留言原文、或反馈自带的附件内容（比如那份很大的 `model-catalog.json` 诊断快照）整段搬进待办——那些是本机缓存里的诊断数据，不是要长期保存的产品文档。要引用就用自己的话转述\"用户反馈说 X 场景下 Y 不工作\"，不逐字复制。\n\n## 汇报给用户\n\n大白话，今天最该动的 1-2 件事，不是把整份报告念一遍。格式：\n\n- 这件事是什么（一句话，说人话不说术语）\n- 为什么值得今天动它（新出现的 \u002F 影响面大的 \u002F 突增的 \u002F 卡住付费路径的，优先级从这几条里选）\n- 建议怎么处理（继续走正常修复流程 \u002F 需要用户拍板 \u002F 只是记录观察，不用现在动）\n\n如果待分诊是 0、也没有突增，如实说\"今天没有新东西\"，不要为了有话说而重复讲已经报过的旧发现。「新增 0 条」不等于没事：待分诊不为 0 就还有反馈没人管。\n\n## 隐私\n\n原始反馈\u002F事件只留在本机缓存目录（脚本已经保证不进仓库、不进任何提交）。这份技能自己的输出——包括私有待办里新增的条目——只能是归纳后的问题描述，不贴用户反馈原文、不贴附件内容、不贴账号 id、不贴任何价格\u002F成本数字。跟\"论文雷达\"\"模型雷达\"一样，这份技能的判断额度默认已授权，不用为了跑一次分诊再单独问用户。\n",{"name":5,"description":7},"main","40895f94fc128549df1cdf08f70fd9029d25d983","agent-skills\u002Fnomi-intake-radar",143,"https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi","https:\u002F\u002Fnomiaqm.com","https:\u002F\u002Fgithub.com\u002Faqm857886159","2026-11-15 04:15:12",{"source":8,"skillName":5,"commands":47,"prompt":56,"zipAvailable":57},[48,51,54],{"tool":49,"command":50},"npx","npx skills add aqm857886159\u002FNomi --skill nomi-intake-radar",{"tool":52,"command":53},"bunx","bunx skills add aqm857886159\u002FNomi --skill nomi-intake-radar",{"tool":31,"command":55},"pnpm dlx skills add aqm857886159\u002FNomi --skill nomi-intake-radar","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fagent-skills\u002Fnomi-intake-radar\u002FSKILL.md",true,[],[60,92,105,116,127,137],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":65,"sourceHtmlUrl":66,"categories":67,"keywords":71,"publishedAt":33},"01M71VD47ACM64K4Y24RVQV9QC","effect-camera-13","用具体的机位与运动描述控制镜头节奏。 用户要求焦点转换时使用。","MIT","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-13\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-13\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91],"effect","effect camera 13","camera","Video","Composition","chinese","move","labels","false","image","review","text","focus","reveal","cover","library","add","png","illustration","true",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":96,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":33},"01M71VD0KJRAPYGNYNYK4WPSB9","effect-camera-12","用具体的机位与运动描述控制镜头节奏。 用户要求快动作降格时使用。","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-12\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-12\u002FSKILL.md",[99],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,101,74,75,76,77,78,102,79,80,81,82,86,87,88,89,90,91,103,104],"effect camera 12","time","task","github",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":109,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":33},"01M71VCX6WAKTNSAAZ3BBYSQ1Q","effect-camera-11","用具体的机位与运动描述控制镜头节奏。 用户要求慢动作升格时使用。","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-11\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-11\u002FSKILL.md",[112],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,114,74,75,76,77,78,79,115,80,81,82,83,86,87,88,89,90,91,103],"effect camera 11","impact",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":120,"sourceHtmlUrl":121,"categories":122,"keywords":124,"publishedAt":33},"01M71VCSATCP6GXGJK6WAKN6GS","effect-camera-10","用具体的机位与运动描述控制镜头节奏。 用户要求手持跟拍时使用。","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-10\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-10\u002FSKILL.md",[123],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,125,74,75,76,77,78,79,80,81,82,86,87,88,89,90,91,103,104,126],"effect camera 10","blob",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":131,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":33},"01M71VCNC1B3QWNWNKTEXT1WSX","effect-camera-09","用具体的机位与运动描述控制镜头节奏。 用户要求逆光剪影时使用。","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-09\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-09\u002FSKILL.md",[134],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,136,74,75,76,77,78,79,80,81,82,86,87,88,89,90,91,103,104,126],"effect camera 09",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":64,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":33},"01M71VCJ22T8994KQ3BSBG5V2B","effect-camera-08","用具体的机位与运动描述控制镜头节奏。 用户要求移轴虚化时使用。","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-08\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Faqm857886159\u002FNomi\u002Fblob\u002Fmain\u002Fskills\u002Feffect-camera-08\u002FSKILL.md",[144],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,146,74,75,76,77,78,79,80,81,82,147,86,87,88,89,90,91,103,104],"effect camera 08","tilt"]