OpenHarmony Napi 生成工具教程，这次让走 TaoToken 的 Codex 排掉 basic.d.ts 依赖坑

当 Napi 生成工具报出 Cannot find module ./basic我是怎么用 TaoToken 上的 Codex 把依赖坑排干净的OpenHarmony 的 Napi 框架生成工具确实省事一份ohos.napitest.d.ts、一份cfg.json、一个serviceCode目录跑一条命令就能把 NAPI 框架代码、胶水代码、GN 文件全吐出来。但真到 Windows 上执行napi_generator-win.exe的时候很多人第一脚就踩进同一个坑——终端刷出一行Cannot find module ./basic生成目录里空空如也napi_gen.log里也只有一行干巴巴的失败记录。这篇不重复讲工具怎么用而是把排查环节单独拎出来不把 TaoToken 塞进 Napi 工具本身而是让走 TaoToken 通道的 Codex 来读日志、读报错、对照.d.ts的依赖声明帮你把basic.d.ts的路径问题定位出来。你从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿到 Key配通的是 Codex 的模型通道Napi 框架代码该由napi_generator-win.exe生成还是它生成两者互不干扰。一、原问题与场景报错长什么样卡在哪一步先把现场还原清楚。Windows 下按官方说明摆好目录E:\demo\napidir /B ohos.napitest.d.ts napi_generator-win.exe generatorCode cfg.json serviceCode然后执行E:\demo\napinapi_generator-win.exe -f ohos.napitest.d.ts -o generatorCode -i false -n double -s cfg.json期望的是generatorCode目录里出现napitest.cpp、napitest.h、napitest_middle.cpp、BUILD.gn、napi_gen.log这一整套。实际得到的却是at checkGenerate [C:\snapshot\napi_generator\src\gen\cmd_gen.js(135:21)] ohos.napitest.d.ts (15,41): Cannot find module ./basic. Did you mean to set the moduleResolution option to node, or to add aliases to the paths option? fail ohos.napitest.d.ts (15,41): Cannot find module ./basic. Did you mean to set the moduleResolution option to node, or to add aliases to the paths option?这里有两个容易误判的点。第一报错文案里出现了moduleResolution、paths这些 TypeScript 编译选项看起来像是 tsconfig 配置问题于是有人跑去改tsconfig.json、加paths别名。但 Napi 生成工具并不是在跑一个完整的 tsc 工程它内部用cmd_gen.js做.d.ts解析moduleResolution那句只是解析器抛出的通用提示改 tsconfig 基本无效。第二报错位置是ohos.napitest.d.ts (15,41)也就是第 15 行第 41 列。这一行大概率是类似import basic from ./basic或import { ... } from ./basic的语句。工具在解析ohos.napitest.d.ts时顺着这条 import 去找./basic也就是同级的basic.d.ts没找到于是整个解析中断后续的框架代码生成自然全部失败。官方文档里其实埋了一句关键备注若.d.ts文件中声明了basic.d.ts文件要把basic.d.ts放在待转换.d.ts文件的同一级目录若还声明了其它.d.ts同样要放到同级目录。问题在于很多人是从 SDK 的ets\api目录里直接拷ohos.napitest.d.ts出来用的basic.d.ts没跟着拷或者拷到了别的子目录于是同级目录里就是缺文件。传统排查方式是人肉翻ohos.napitest.d.ts的 import 段、翻napi_gen.log、再猜哪个依赖没到位。文件少还好一旦.d.ts里嵌套引用了好几个依赖靠眼睛扫很容易漏。这就是本篇要引入 Codex 辅助排查的切入点把日志和报错交给模型让它按依赖链去核对路径。二、TaoToken 前置只给 Codex 提供 Key 和 Base URL先把边界说清楚避免误解。TaoToken 在这条链路里的角色非常单一它给 Codex 提供可用的 API Key 和 Base URL。它不参与 Napi 框架代码的生成不碰napi_generator-win.exe也不改你的ohos.napitest.d.ts或cfg.json。真正生成 NAPI 框架代码的仍然是那个可执行程序TaoToken 只是让 Codex 这个排查助手能跑起来。所以前置动作只有两步第一步打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建一个 API Key。这个 Key 后面要填进 Codex 的配置里。第二步记住两个地址Base URLhttps://taotoken.net/apiAPI Key你刚创建的那串值下文用YOUR_API_KEY占位如果你还没装 Codex CLI可以先装npm i -g taotoken/taotoken装完之后用一条命令把 Codex 拉起来并带上 Key 和 Base URLtaotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m MODEL_ID其中MODEL_ID填你在 TaoToken 控制台里选定的模型 ID。这条命令的作用是让 Codex 走 TaoToken 的模型通道后续你在 Codex 里贴日志、贴报错它才能正常返回分析结果。需要强调的是这一步配通的是 Codex 的模型通道跟 Napi 生成工具的运行环境没有任何耦合。你完全可以在一个终端里跑napi_generator-win.exe在另一个终端里跑 Codex两者互不影响。三、可复制配置让 Codex 能读到日志和报错配通 Key 之后接下来要做的是把证据喂给 Codex。这里的证据有两类一类是终端里的报错输出一类是napi_gen.log文件内容。先说终端报错。上面那段Cannot find module ./basic的完整输出直接复制粘贴给 Codex 就行。注意要带上ohos.napitest.d.ts (15,41)这个位置信息它是定位的关键。再说napi_gen.log。这个文件在生成成功时会出现在generatorCode目录下生成失败时也可能在工具目录或输出目录里留下记录。你可以用命令把它打出来type generatorCode\napi_gen.log或者如果日志在别的位置type napi_gen.log把日志内容一并贴给 Codex。然后是最关键的一步把ohos.napitest.d.ts的 import 段也贴进去。因为Cannot find module ./basic的根因就在这个文件的依赖声明里。你只需要贴文件开头到第一个export之前的部分重点是所有import ... from ./xxx语句。比如import basic from ./basic; import { AsyncCallback } from ./basic;把这些 import 语句连同报错一起给 Codex它就能对照出ohos.napitest.d.ts声明了对./basic的依赖而工具在解析时按同级目录去找basic.d.ts没找到所以报错。如果你想让 Codex 直接读文件而不是手动粘贴也可以在 Codex 会话里让它读取指定路径的文件内容。但要注意Codex 读的是你本地的文件它不会去改文件只做分析和建议。一个建议的提问方式是这样的我在 Windows 上用 napi_generator-win.exe 生成 NAPI 框架代码命令是napi_generator-win.exe -f ohos.napitest.d.ts -o generatorCode -i false -n double -s cfg.json。终端报错如下贴报错。ohos.napitest.d.ts的 import 段如下贴 import。napi_gen.log内容如下贴日志。请帮我定位Cannot find module ./basic的原因并给出需要检查的路径。这样问的好处是把工具、命令、报错、依赖声明、日志五要素都交代清楚了Codex 返回的定位建议会具体得多而不是泛泛地说检查依赖。四、验证请求与成功结果Codex 返回了什么怎么确认它对了配通之后怎么判断 Codex 真的在正常工作、返回的建议真的有用先看请求是否通。如果 Key 或 Base URL 填错Codex 会直接报鉴权失败或连接失败这时候回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 检查 Key 是否复制完整、Base URL 是否写成了https://taotoken.net/api注意不要多加路径。如果请求能正常返回内容说明 TaoToken 通道是通的。再看返回内容是否对路。针对上面那个提问一个有效的返回应该包含这几层信息第一层指出报错的直接原因ohos.napitest.d.ts第 15 行引用了./basic解析器在同级目录找不到basic.d.ts导致解析中断。第二层指出需要检查的路径确认basic.d.ts是否与ohos.napitest.d.ts在同一级目录。注意是同一级不是子目录也不是父目录。第三层指出连带检查项如果ohos.napitest.d.ts还引用了其它.d.ts文件这些文件同样要放到同级目录-i参数默认false当引用了非basic.d.ts的 ts 文件时才需要打开。第四层给出验证方式把basic.d.ts放到同级目录后重新执行生成命令观察generatorCode目录下是否出现napitest.cpp、napitest.h、napitest_middle.cpp、BUILD.gn、napi_gen.log等文件。如果 Codex 返回的内容覆盖了这几层说明它确实读懂了报错和依赖声明定位建议是可用的。接下来你按它的建议把basic.d.ts放到ohos.napitest.d.ts同级目录再跑一次命令E:\demo\napinapi_generator-win.exe -f ohos.napitest.d.ts -o generatorCode -i false -n double -s cfg.json这次如果generatorCode目录里出现了完整的生成文件列表就说明依赖坑排掉了。注意这一步的成功是napi_generator-win.exe的功劳Codex 只是帮你定位了问题所在它没有参与生成。五、本篇常见错排查除了 basic.d.ts 还有哪些坑Cannot find module ./basic是最典型的一个但围绕 Napi 生成工具的依赖和路径问题还有几个高频错误值得一并排查。错误一basic.d.ts 放对了但还报别的 Cannot find module。这说明ohos.napitest.d.ts里不止引用了./basic还引用了其它.d.ts。处理方式一样把报错里提到的那个模块对应的.d.ts文件放到ohos.napitest.d.ts同级目录。可以逐个报错逐个补也可以一次性把 import 段里所有./xxx对应的文件都补齐。错误二文件明明在同级目录还是报找不到。检查文件名大小写。Windows 文件系统不区分大小写但工具内部的解析逻辑可能区分。basic.d.ts和Basic.d.ts在某些解析路径下会被当成两个文件。另外检查文件扩展名是否真的是.d.ts而不是.ts或.d.ts.txt。错误三-i 参数没打开。-i参数默认false含义是待转换.d.ts文件中引用非basic.d.ts的 ts 文件时打开开关。如果你的ohos.napitest.d.ts引用了basic.d.ts之外的 ts 文件而-i还是false就可能出现解析不完整的情况。这时候把命令改成-i true再试。错误四cfg.json 路径写错导致生成中断。cfg.json里的includeName和cppName是相对路径相对于cfg.json所在目录。如果serviceCode目录位置变了这两个路径要跟着改。路径写错时报错可能不是Cannot find module而是找不到头文件或源文件。把cfg.json内容贴给 Codex让它帮你核对相对路径是否与实际目录结构一致。错误五生成成功但集成到 OpenHarmony 时报错。这通常不是依赖问题而是BUILD.gn或binding.gyp的配置与目标系统版本不匹配。官方集成说明针对的是 OpenHarmony 4.0 release其它版本可能有差异。这类问题可以把BUILD.gn内容和编译报错一起给 Codex让它对照版本差异给建议。错误六Codex 返回的建议太泛没定位到具体文件。这通常是喂给它的信息不够。检查是否贴了完整的报错行号、是否贴了ohos.napitest.d.ts的 import 段、是否贴了napi_gen.log。信息越完整定位越具体。如果只贴一句Cannot find module ./basic任何模型都只能给通用建议。六、语义一致 CTA把 Codex 通道配通排查才有着落回到本篇的主线Napi 生成工具的Cannot find module ./basic是一个依赖路径问题根因在ohos.napitest.d.ts引用了basic.d.ts但同级目录没有这个文件。排查这件事本身不复杂复杂的是当依赖链变长、报错变多时靠人眼扫容易漏。让走 TaoToken 通道的 Codex 来读日志、读报错、对照依赖声明能把定位这一步做得更稳。如果你还没配通 Codex 的 TaoToken 通道先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key然后在 Codex 里把 Base URL 填https://taotoken.net/api、Key 填刚创建的值。配通之后把终端报错、napi_gen.log、ohos.napitest.d.ts的 import 段一起贴给 Codex让它帮你核对basic.d.ts的路径。需要再强调一次TaoToken 在这里只提供 Codex 所需的 Key 和 Base URL不参与 NAPI 框架代码的生成。生成代码的仍然是napi_generator-win.exeCodex 只负责辅助排查。验证方式也很直接Codex 能正常返回依赖缺失的定位建议你按建议把basic.d.ts放到ohos.napitest.d.ts同级目录重新执行生成命令看到generatorCode目录里出现完整的框架代码文件这条链路就算跑通了。如果你在配通过程中遇到鉴权或连接问题去 API Keys 页面和接入文档里核对 Key 和 Base URL 的填写方式如果只是想先验证模型通道是否正常可以在模型对话里发一条简单请求试试如果你打算长期用 Codex 辅助 OpenHarmony 开发Coding Plan 会更适合持续性的编码和排查场景。