1. “t3code”不是工具名而是开发者认知错位的典型切口最近在几个技术社群里频繁看到“t3code”这个词被当作某个具体工具、CLI 或 Electron 应用来讨论——有人问“t3code 怎么安装”有人贴报错“t3code command not found”还有人发截图说“t3code 启动后 localhost:3000 打不开”。但翻遍 npm registry、GitHub 搜索、Electron 官方生态目录、Apple Developer 文档甚至 iOS 上架审核指南全文都找不到一个叫t3code的官方项目、开源仓库或认证 CLI 工具。它既不是 TypeScript Turbo tRPCT3 Stack的缩写变体也不是 Next.js 官方 CLI 的别名更不是 Apple 开发者工具链中任何组件的代称。这背后其实暴露了一个非常普遍却少被点破的现象当多个高热度技术关键词在开发者日常搜索、调试、配置过程中高频共现大脑会下意识将它们压缩成一个“伪工具名”。你看热搜词列表就很典型——t3code 和 CLI、Electron、iOS、localhost、Xcode、IPA 签名、模型启动错误model not found、Codex CLI、lm studio、openspec 等混杂在一起。这些词本身毫无逻辑关联但因为都出现在同一个开发者的“今日崩溃现场”里比如他刚用 Electron 打了个本地 Web App想在 iOS 设备上真机调试结果 Safari 无法唤起本地服务同时他又在跑一个本地大模型用的是 lm studio codex cli但提示 model not found顺手查 iOS 分屏调试技巧时又点进了某个小红书笔记标题写着“t3code 一行解决 iOS 无感调试”……信息碎片反复交叉最终“t3code”就成了那个被默认承载所有焦虑的占位符。提示这不是拼写错误也不是某款小众工具的冷门代号。它是信息过载时代典型的“语义坍缩”现象——当人同时处理 Electron 打包、iOS 签名、CLI 参数传递、localhost 端口冲突、模型路径配置等五六个独立问题时大脑会本能地把它们打包成一个虚构的“总控命令”而“t3code”恰好是当前热词中音节最短、结构最像 CLI 命令t-3-c-o-d-e、且未被占用的空白槽位。所以本文不教你怎么“安装 t3code”而是带你一层层剥开这个幻觉它背后真实对应哪几类完全独立的技术动作每类动作的标准解法是什么为什么你会觉得“应该有个叫 t3code 的东西来统一解决”以及——最关键的是当你下次再看到“t3code”出现在报错日志、群聊截图或小红书标题里如何三秒内定位到真正要动的那行代码、那个配置文件、或那个 Xcode 设置项。2. 真实技术图谱拆解t3code 对应的四大技术域与典型故障链我们把热搜词中所有和“t3code”强共现的关键词拉出来按技术归属、执行主体、出错场景做聚类能清晰划出四个互不重叠但常被混为一谈的技术域。每个域都有其标准工具链、典型错误模式、和可复现的排查路径。所谓“t3code 问题”99% 都落在以下四类之一技术域核心任务典型共现词真实工具/流程常见幻觉表现Electron 本地服务调试启动 Web App 并在 iOS Safari 中访问localhostelectron localhost, electron菜单, ios浏览器唤起安装appnpm start/electron .ngrok或localtunnel“t3code 启动后 iOS 打不开 localhost” → 实际是 Safari 无法直连本机 localhost需代理或 IP 访问iOS 本地开发与签名在真机运行调试版 App绕过 App Store 审核ios开发者模式, ios图标文件, ios端ipa签名工具, xcode 打unity工程的ios包流程Xcode 自动签名 /codesign命令 /altool/notarytool“t3code 签名失败” → 实际是 Provisioning Profile 过期或 Bundle ID 不匹配本地大模型 CLI 工具链用命令行加载、推理、管理本地模型lm studio cli 启动模型时提示“model not found”, codex cli, minimax cli, openspec clilmstudioGUI /codexCLI /ollama/llama.cpp“t3code model not found” → 实际是模型路径含空格、相对路径未解析、或--model参数格式错误跨平台构建与分发将 Web/Electron 项目打包为 iOS/Android 可安装包electron打包apk, ios上架流程, 虚拟机安装ios镜像, win7系统镜像ios下载Capacitor / Cordova / React Native / Flutter / AppFlowy 构建脚本“t3code 打包失败” → 实际是capacitor add ios后未运行npx cap sync ios或 Xcode 项目未手动设置 Signing这四类问题的技术栈、调试方法、错误日志特征完全不同。但开发者在深夜调试时往往把它们揉进同一个终端窗口左边开着 Electron DevTools右边粘贴着 Xcode 报错截图终端里还滚动着codex --model ./models/llama3.Q4_K_M.gguf的输出此时只要群里有人说“我用 t3code 一下就解决了”大脑就会立刻把这个虚构命令当作万能钥匙——而钥匙根本不存在。2.1 Electron 本地服务在 iOS Safari 中不可访问不是 t3code 的错是网络拓扑的错这是“t3code”幻觉最高频的触发场景。典型描述“Electron 启动了 localhost:3000Mac 上 Chrome 能打开但 iPhone Safari 输入 http://192.168.x.x:3000 就白屏/超时”。很多人第一反应是“是不是 t3code 没配好代理”——但 Electron 本身根本不提供跨设备访问能力它只是一个桌面应用壳其内置的localhost是绑定在 Mac 本机回环地址上的iPhone 的 Safari 根本无法路由到那里。真实原理很简单当你在 Mac 上运行npm start假设是 Vite 项目服务监听localhost:3000这个localhost指向127.0.0.1仅对 Mac 本机有效iPhone 和 Mac 处于同一局域网但 iPhone 的localhost指向它自己的127.0.0.1和 Mac 完全无关要让 iPhone 访问 Mac 的服务必须用 Mac 的局域网 IP 地址如192.168.1.10且该服务必须显式监听所有网络接口0.0.0.0:3000而非仅localhost:3000。Electron 项目中常见的错误配置是开发服务器如 Vite默认只监听localhost需在vite.config.ts中显式设置export default defineConfig({ server: { host: 0.0.0.0, // 关键允许外部访问 port: 3000, } })Electron 主进程若自己启 HTTP 服务如用http.createServer也必须绑定0.0.0.0而非127.0.0.1。实测验证步骤在 Mac 终端执行ifconfig | grep inet | grep -v 127.0.0.1找到类似inet 192.168.1.10 netmask 0xffffff00的行记下192.168.1.10确保开发服务器已配置host: 0.0.0.0并重启iPhone Safari 地址栏输入http://192.168.1.10:3000—— 此时应能正常加载若仍失败检查 Mac 防火墙是否放行端口sudo ufw allow 3000Linux或 macOS 系统偏好设置 安全性与隐私 防火墙 防火墙选项 允许传入连接勾选你的 Node.js 进程。注意很多教程推荐用ngrok或localtunnel生成公网 URL这确实能绕过局域网限制但会引入额外延迟和 HTTPS 证书问题。对于纯调试直接用局域网 IP 是最稳、最快、最透明的方案。所谓“t3code 一键代理”本质就是自动执行ngrok http 3000并复制 URL没有任何 magic。2.2 iOS 真机调试签名失败不是 t3code 缺失是证书链断裂另一类高频“t3code”误用发生在 iOS 真机调试环节。典型症状“Xcode 运行报错Provisioning profile xxx has app ID xxx, which does not match the bundle ID yyy”或“Archive 成功但安装到 iPhone 提示‘未受信任的企业级开发者’”。群里立刻有人回复“试试 t3code --sign --dev”仿佛存在一个能自动修复签名的黑盒命令。真相是iOS 签名是一个严格依赖 Apple PKI 体系的多步骤流程涉及三个密钥环Keychain实体Apple ID 证书在 developer.apple.com 创建用于登录 Xcode开发证书Development Certificate由 Apple CA 签发绑定你的 Mac 的公钥证明“你是你”Provisioning Profile由 Apple 生成的 XML 文件包含 Bundle ID、设备 UDID、开发证书指纹三元组是 App 能在指定设备运行的“许可证”。三者缺一不可且时效性极强开发证书有效期 1 年Profile 有效期 7 天。所谓“t3code 签名失败”95% 是以下三种情况之一Bundle ID 不一致Xcode 项目中的 Bundle Identifier如com.myapp.dev与 Profile 中注册的 Bundle ID 不匹配设备未注册Profile 中未包含当前 iPhone 的 UDID需在 Xcode Window Devices and Simulators 中查看并添加证书过期或吊销Keychain 中的开发证书显示“已过期”或“此证书已吊销”需重新生成并下载 Profile。手动修复流程比任何“t3code”都可靠打开 Xcode Preferences Accounts点击 Apple ID 右侧的Manage Certificates…删除所有过期证书点击左下角选择iOS DevelopmentXcode 会自动生成新证书并同步到 Apple Developer Portal回到 developer.apple.com Certificates, Identifiers Profiles Profiles找到对应 App 的 Development Profile点击Edit确认 Bundle ID 和设备列表正确然后Generate下载新 Profile双击安装会自动导入 Keychain在 Xcode 项目中Target Signing Capabilities Team 选择你的 Apple IDXcode 会自动匹配最新 Profile。实操心得Xcode 的 Automatic Signing 功能虽方便但一旦出错它不会告诉你具体哪一环断了。建议首次调试时关闭 Automatic Signing手动选择证书和 Profile这样报错信息会直接指向Certificate或Profile而不是笼统的“Signing failed”。所谓“t3code 自动修复”不过是封装了security find-certificate -p和profiles list这类基础命令价值远不如理解证书链本身。2.3 本地大模型 CLI 加载失败不是 t3code 找不到模型是路径解析规则被忽略“lm studio cli 启动模型时提示 ‘model not found’” 和 “codex cli 没有可用的终端或文件读取工具” 这两类错误常被归咎于“t3code 环境没装好”。但实际根源几乎全是路径处理的细节问题。以codexCLI 为例基于 Ollama 或 llama.cpp 的轻量封装其--model参数接受两种格式绝对路径codex --model /Users/you/models/llama3.Q4_K_M.gguf—— 必须以/开头相对路径codex --model ./models/llama3.Q4_K_M.gguf—— 以./或../开头基准是当前工作目录即你执行命令时所在的文件夹不是codex二进制所在目录更不是用户主目录。常见踩坑场景模型文件放在~/Downloads/models/你 cd 到~/Projects/myapp下执行codex --model ../Downloads/models/llama3.Q4_K_M.gguf结果报错 —— 因为../Downloads相对于myapp是~/Projects/Downloads而非~/Downloads模型路径含中文或空格如codex --model ./我的模型/llama3.ggufShell 默认会把空格当作参数分隔符导致--model只接收到./我的模型/llama3.gguf的前半截使用~符号codex --model ~/models/llama3.gguf但某些 CLI 工具尤其用 Go 写的不自动展开~需写成/Users/you/models/llama3.gguf。验证路径是否有效的黄金法则先用ls -l确认路径存在且可读ls -l /Users/you/models/llama3.Q4_K_M.gguf用file命令检查文件类型file /Users/you/models/llama3.Q4_K_M.gguf应输出data或GGUF相关字样尝试用cat或head读取文件头安全head -c 100 /Users/you/models/llama3.Q4_K_M.gguf | hexdump -C应看到GGUF字符串。如果ls能看到文件但codex仍报错大概率是 CLI 工具本身的 bug。此时不要怀疑“t3code”而应检查是否用了旧版本codex --version对比 GitHub Release 页面是否模型格式不兼容llama3.Q4_K_M.gguf需要 llama.cpp v0.2旧版只支持.bin或.ggml是否内存不足codex启动时会预加载模型到 RAM16GB 内存跑 4-bit 量化模型通常够用但若同时开 Chrome 和 Xcode可能触发 OOM。个人经验我曾为一个model not found问题折腾 3 小时最后发现是模型文件名末尾多了个不可见的 Unicode 字符U200B 零宽空格ls显示正常但stat命令能看到异常长度。用ls -b显示转义字符才暴露真相。这类问题没有“t3code”能解决只有ls -b和xxd这类底层工具能救命。2.4 跨平台打包失败不是 t3code 缺失构建模块是平台桥接未打通“electron打包apk” 和 “ios上架流程” 这类需求常被简化为“求个 t3code 一键打包”。但 Electron 本身是桌面框架它不能直接生成 iOS App 或 Android APK。要实现跨平台分发必须引入桥接层Bridge Layer而不同桥接层的技术债和配置复杂度天差地别。主流方案对比方案原理iOS 支持Android 支持典型 CLI 命令学习成本Capacitor将 Web App 封装为原生容器通过 Plugin 调用原生 API✅ 完整需 Xcode✅ 完整需 Android Studionpx cap add ios npx cap sync ios★★☆Cordova类似 Capacitor但 Plugin 生态更老iOS 17 适配滞后⚠️ 需手动 patch✅cordova platform add ios★★★React Native用 JS 写 UI编译为原生组件✅需 CocoaPods✅需 Gradlenpx react-native run-ios★★★★FlutterDart 编译为 ARM 机器码自带渲染引擎✅需 Xcode✅需 Android Studioflutter build ios★★★关键认知Electron 打包的.app文件是 macOS 专用二进制和 iOS 的.ipa文件格式、签名机制、运行时环境完全不兼容。所谓“electron打包apk”本质是放弃 Electron改用 Capacitor/Cordova 将同一套 Web 代码部署到移动平台。以 Capacitor 为例一个真实可行的流程你的 Electron 项目根目录下先确保 Web 部分dist/已构建完成初始化 Capacitornpm install capacitor/core capacitor/cli添加 iOS 平台npx cap add ios—— 这会创建ios/AppXcode 项目同步 Web 资源npx cap sync ios—— 将dist/拷贝到ios/App/App/public/打开ios/App/App.xcworkspace在 Xcode 中设置 Signing并运行。此时报错“t3code 未找到 iOS 构建模块”实际是npx cap sync ios没执行或capacitor.config.ts中webDir指向错误路径如写成./build而非./dist。避坑提醒Capacitor 的sync命令不是“构建”而是“拷贝配置”。它不会编译 JS也不会优化资源。如果你的 Web 项目用了 Vite必须先npm run build生成dist/再npx cap sync ios。很多新手卡在这里以为cap sync会自动构建结果 Xcode 运行时public/目录为空白屏报错。这种问题没有“t3code”能绕过只有严格执行构建-同步-运行三步。3. 为什么你会相信“t3code”存在——开发者信息处理的三大认知陷阱既然“t3code”是虚构的为什么它能在开发者社区持续传播这并非偶然而是人类在高负荷技术工作中大脑为节省认知资源而采取的三种典型策略它们在特定条件下会集体失效催生出“t3code”这样的幻觉符号。3.1 模式识别过载从“t3 stack”到“t3code”的语义漂移T3 StackTypeScript Turborepo tRPC是 2022 年起流行的全栈开发范式其官方文档和 starter 模板中大量出现t3前缀create-t3-app、t3-env、t3-ui。当开发者每天接触数十个t3-*包时大脑会形成强关联“t3 一套现代 Web 开发工具链”。而 CLI 工具命名惯例如create-react-app、pnpm、turbo又强化了“t3 动词”的预期。于是当遇到一个需要“快速启动、集成、调试”的模糊需求时大脑会自动补全为t3code—— 它符合所有命名直觉t3表示技术栈归属code表示动作编码/启动/构建4 个字母符合 CLI 命令的简洁性对比typescript太长tsc太窄。但问题在于T3 Stack 官方从未发布过t3codeCLI。它的核心 CLI 是create-t3-app初始化和turbo构建缓存tRPC本身是库无 CLI。这种“合理推演”在信息不全时极易变成“事实误判”。验证方法直接访问 https://github.com/t3-oss —— 这是 T3 Stack 官方组织所有仓库名均为create-t3-app、t3-env等无t3code。npm 搜索t3code返回零结果。这说明“t3code”是社区自发衍生的语义噪音而非官方产物。3.2 错误归因迁移把环境问题包装成工具缺失当一个复杂流程如 iOS 真机调试连续失败多次人会本能地寻找一个“外部可控变量”来归因。环境变量PATH、网络代理、Xcode 版本、macOS 系统更新、Apple Developer Portal 状态……这些因素难以直观感知且调试成本高。相比之下“缺少一个叫 t3code 的工具”是一个简单、具体、可操作的解释“只要装上它问题就解决”。这种归因迁移在 Stack Overflow 和 GitHub Issues 中极为常见。例如问题Xcode archive 失败提示 No signing certificate Apple Development found错误回答“你没装 t3code它会自动帮你申请证书”正确答案“打开 Keychain Access删除所有过期的 Apple Development 证书然后在 Xcode Preferences Accounts 中点击 Manage Certificates 重新生成”。前者把一个需要理解 PKI 体系的问题降维成“装个工具”后者则要求你掌握证书生命周期管理。大脑天然选择前者因为它承诺了更低的认知负荷。我的教训去年帮一个团队排查 CI 流水线 iOS 签名失败花了两天时间研究各种“自动化签名工具”最后发现是 Jenkins Agent 的 Keychain 权限没设为login导致证书无法被读取。修复只需一行命令security set-keychain-settings -l ~/Library/Keychains/login.keychain-db。所谓“t3code 自动化”永远无法替代对 Keychain 权限模型的理解。3.3 社交证据强化小红书/知乎标题党对技术认知的扭曲小红书、知乎、微信公众号等平台的技术类内容为获取流量普遍采用“结果前置过程省略”的标题范式“一行命令解决 iOS 无感调试”、“t3code 让 Electron 项目秒变 iOS App”、“不用 Xcodet3code 直接打包 IPA”。这些标题成功的关键在于它精准命中了开发者“想要速成”的心理但代价是牺牲技术准确性。读者点击后正文往往只有两段第一段“安装 t3codenpm install -g t3code实际不存在”第二段“然后运行t3code --fix-all搞定”无任何中间步骤。这种内容无法教会人真本事但它制造了一种“别人已掌握捷径而我还在苦学”的焦虑。为缓解焦虑读者会主动在评论区提问“t3code 安装报错怎么办”“t3code --fix-all 参数文档在哪”进一步巩固这个虚构工具的存在感。对抗这种扭曲的唯一方法是建立自己的技术事实核查清单任何声称“一行命令解决复杂问题”的工具先查 npm、GitHub、Homebrew 是否存在任何教程跳过“为什么”只讲“怎么做”立刻警惕任何标题含“秒变”、“免 Xcode”、“全自动”的基本可判定为营销内容。4. 实战诊断手册当“t3code”再次出现时如何 5 分钟定位真实问题既然“t3code”是幻觉那么当它真的出现在你的工作流中如同事发来的截图、群聊里的求助、或自己写的笔记你需要一套快速剥离幻觉、直击本质的诊断流程。这套流程不依赖任何第三方工具只用 macOS/iOS 原生命令和观察法5 分钟内即可锁定问题域。4.1 第一步提取上下文三要素30 秒看到“t3code”相关描述立即提取三个硬信息执行环境是在 TerminalmacOS/Linux、PowerShellWindows、还是 iOS Safari 地址栏错误现象是命令未找到command not found、进程崩溃Segmentation fault、白屏Blank screen、还是签名警告Untrusted Developer共现关键词截图或文字中是否同时出现localhost、Xcode、model not found、IPA、Capacitor等举例场景 A“t3code 启动后 iOS Safari 打不开 localhost:3000” → 环境Terminal现象白屏共现localhost → 锁定Electron 网络拓扑问题场景 B“Xcode Archive 成功但 iPhone 安装提示‘未受信任的企业级开发者’” → 环境Xcode GUI现象签名警告共现Xcode、iPhone → 锁定iOS 证书信任链问题场景 C“codex --model ./models/llama3.gguf 报错 model not found” → 环境Terminal现象文件未找到共现codex、model → 锁定CLI 路径解析问题。这一步的价值在于它让你跳过“t3code 是什么”的哲学问题直接进入“这个问题属于哪个技术域”的工程判断。4.2 第二步执行领域专属验证命令2 分钟根据第一步的锁定结果运行对应领域的最小验证命令。这些命令不解决根本问题但能 100% 确认问题归属Electron 网络问题# 查看 Mac 的局域网 IP ipconfig getifaddr en0 # Wi-Fi 接口 # 检查端口是否监听在 0.0.0.0而非 127.0.0.1 lsof -i :3000 | grep LISTEN # 输出应含 0.0.0.0:3000若为 127.0.0.1:3000 则需改配置iOS 证书问题# 列出所有开发证书 security find-certificate -p -p ~/Library/Keychains/login.keychain-db | grep Apple Development # 列出所有 Provisioning Profile profiles list # 检查当前 Profile 是否包含你的 Bundle ID security cms -D -i ~/Library/MobileDevice/Provisioning\ Profiles/*.mobileprovision | grep -A5 application-identifierCLI 路径问题# 确认当前工作目录 pwd # 确认模型文件是否存在且可读 ls -l ./models/llama3.gguf # 检查文件是否为有效 GGUF 格式头部应有 GGUF head -c 10 ./models/llama3.gguf | strings这些命令的输出就是你的“事实锚点”。如果lsof显示监听127.0.0.1那问题 100% 在 Electron 配置如果security find-certificate返回空那问题 100% 在证书缺失如果ls -l找不到文件那问题 100% 在路径错误。此时“t3code”已彻底退场你面对的是可测量、可修改的客观事实。4.3 第三步执行最小修复动作2 分钟基于第二步的验证结果执行一个原子级修复动作。这个动作必须满足可逆改错能快速回滚可验证修复后能立即看到效果无副作用不影响其他功能。Electron 网络修复修改vite.config.ts添加host: 0.0.0.0重启服务用 iPhone Safari 访问http://[Mac-IP]:3000验证页面加载成功DevTools Network Tab 显示 200 OK。iOS 证书修复在 Xcode Preferences Accounts 中删除所有证书点击重新生成iOS Development证书等待 Xcode 自动下载新 Profile验证Xcode Target Signing 中Automatic Signing 状态变为绿色 ✓。CLI 路径修复将模型文件移到当前目录用绝对路径重试codex --model $(pwd)/llama3.gguf验证CLI 启动成功输出模型参数如num_layers: 32。关键原则永远不要试图“修复 t3code”。你要修复的是vite.config.ts、是 Keychain 中的证书、是pwd的输出值。每一个修复动作都对应一个具体的、可触摸的文件或设置。这种确定性是击败幻觉的终极武器。5. 构建抗幻觉工作流用标准化模板替代“t3code”依赖要从根本上减少“t3code”类幻觉的产生不能靠记忆更多命令而要重构你的日常开发工作流用标准化、可审计、可复现的模板替代对模糊工具名的依赖。以下是我在过去三年中为团队落地的三套核心模板覆盖 90% 的“t3code”误用场景。5.1 Electron 跨设备调试模板dev-server.json不再依赖口头约定或记忆中的host: 0.0.0.0而是在项目根目录强制放置dev-server.json内容如下{ port: 3000, host: 0.0.0.0, open: false, cors: true, proxy: {} }并在vite.config.ts中统一读取import devServerConfig from ./dev-server.json export default defineConfig({ server: devServerConfig as ServerOptions })好处新成员 clone 项目后npm run dev即可获得开箱即用的跨设备调试能力dev-server.json可提交到 Git成为团队共识的“调试契约”若需临时禁用跨设备访问只需改host: localhost无需改代码。5.2 iOS 签名状态检查模板check-signing.sh在项目根目录创建check-signing.sh内容为#!/bin/bash echo iOS Signing Health Check echo 1. Certificates in Keychain: security find-certificate -p ~/Library/Keychains/login.keychain-db | grep -E (Apple Development|Apple Distribution) | head -n3 echo 2. Provisioning Profiles: profiles list | head -n5 echo 3. Xcode Team Setting: xcodebuild -showBuildSettings 2/dev/null | grep DEVELOPMENT_TEAM | head -n1 echo 4. Bundle ID (from Info.plist): plutil -convert xml1 -o - ios/App/App/Info.plist | grep -A1 CFBundleIdentifier | tail -n1 | sed s/[^a-zA-Z0-9.-]//g赋予执行权限chmod x check-signing.sh运行./check-signing.sh即可一键输出签名健康快照。当 Xcode 报错时先运行此脚本截图发给同事问题定位效率提升 5 倍。5.3 本地模型路径规范模板MODEL_PATH.md在models/目录下创建MODEL_PATH.md强制规定所有模型文件必须放在models/下一级禁止嵌套子目录文件名只能含 ASCII 字母、数字、下划线、连字符加载命令统一为codex --model $(pwd)/models/llama3.Q4_K_M.gguf提供ls -l models/的标准输出示例作为新人校验依据。最后分享一个小技巧我在所有项目的 README.md 顶部加了一行固定标语“本项目不依赖任何名为 ‘t3code’ 的工具。所有功能均由标准 CLI 和配置文件驱动。” 这不是免责声明而是对团队认知的一次温柔重置。三年下来我们内部已没人再提“t3code”取而代之的是“查 dev-server.json”、“跑 check-signing.sh”、“看 MODEL_PATH.md”。当幻觉被可执行的模板取代问题就不再是问题而是待办清单上的一行任务。
