1. 从计算书到 DWGCodex 在 CAD 工程场景到底能做什么Codex 在 CAD 工程场景里能做什么适合谁用这是我在复现北航何静那份《Codex For CAD 工程应用评测报告》时最先想搞清楚的问题。简单说Codex 不是要替代 AutoCAD而是把「自然语言描述 → 可执行脚本 → DWG 成果」这条链路打通。它擅长的是把计算书里的土层参数、土压力系数、锚索布置这些结构化信息翻译成 AutoLISP 能跑的代码或者通过 MCP 工具链直接操作 CAD 图元。适合的人群很明确做基坑支护、结构、市政这类需要大量重复绘图的工程师以及想把「计算—画图—改图」流程封装成标准动作的技术负责人。我实测下来Codex 在 CAD 场景的落地方式主要有四条路径。第一条是直接生成 DWG 文件适合批量出图但灵活性差第二条是生成 AutoLISP 脚本这是最稳的因为脚本可读可改可版本管理第三条是通过 MCP 连接 CAD 做交互操作改图阶段特别有用第四条是封装成 Skill 做标准化流程适合团队沉淀。这四条路径不是互斥的实际项目里往往是组合使用。先说说为什么这件事值得做。传统工程里「计算—画图—改图」三个环节是割裂的计算用 Excel 或理正画图用 CAD改图靠人工对照。数据孤岛导致重复劳动一个参数变了土压力图、支护剖面、锚索布置全要手动联动。Codex 的价值在于它能把计算阶段的输出直接转成绘图指令减少中间的手工搬运。比如土层参数提取后主动土压力系数、被动土压力系数、分层土压力、水土压力、支锚轴向力这些计算Codex 可以按规范公式跑一遍还能识别参数缺失并提示补充。但要注意Codex 不是万能的。报告里也提到复杂联动修改仍有不稳定情况。我的经验是单图元修改、局部联动调整、多目标复合修改这些它能做但涉及多张图纸的强约束推理修正还是得人工兜底。所以定位要清楚它是提效工具不是全自动设计系统。这一节先建立认知Codex For CAD 的核心能力是「自然语言与计算书 → CAD 成果」的转换加上辅助改图和流程封装。接下来我会从环境准备开始把可复制的配置、AutoLISP 示例、DWG 批处理验证步骤一步步拆开让你能在本地复现整个评测流程。2. TaoToken 前置准备Codex 接入的 Base URL 与 Key 怎么配要让 Codex 在 CAD 场景跑起来前置准备分两块一是 Codex 本身的接入配置二是 CAD 侧的脚本执行环境。这里我用 TaoToken 作为模型接入层因为它同时提供 OpenAI 兼容接口和 Claude Code 的 Anthropic 兼容接口配置起来比较统一。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制保存。注意这个 Key 只在创建时显示一次丢了就得重建。拿到 Key 后Codex 的配置核心是三件套Base URL、API Key、Model ID。Base URL 填https://taotoken.net/api注意不要加 UTM 参数API 地址就是纯域名加路径。如果你用的是 Codex CLI 或者兼容 OpenAI 接口的客户端配置文件通常放在~/.codex/config.toml或者项目根目录的.codex/config.toml。我实测的配置片段如下你可以直接复制# ~/.codex/config.toml model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在环境变量里设置 Keyexport TAOTOKEN_API_KEYsk-你的Key如果你用的是 Claude Code 那套 Anthropic 兼容接口配置路径在~/.claude/settings.json片段如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key } }这里有个坑要注意Anthropic 兼容接口和 OpenAI 兼容接口的 Base URL 都是https://taotoken.net/api但路径拼接方式不同。OpenAI 兼容会自动加/v1/chat/completionsAnthropic 兼容会加/v1/messages。如果你手动拼路径很容易 404。所以建议直接用官方客户端别自己写 HTTP 请求。CAD 侧的环境准备主要是 AutoLISP 的执行环境。AutoCAD 自带 Visual LISP 编辑器命令行输入VLISP就能打开。如果你用的是中望、浩辰这些国产 CAD也基本兼容 AutoLISP但部分函数可能有差异。我测试用的是 AutoCAD 2024加载脚本的方式是APPLOAD命令选择.lsp文件即可。还有一个关键点Codex 生成的 AutoLISP 脚本编码要用 ANSI 或者 GBK不能用 UTF-8否则中文注释会乱码。这个坑我踩过脚本加载后提示「输入的列表有缺陷」排查半天才发现是编码问题。保存.lsp文件时在编辑器里选「ANSI」编码。MCP 工具链的接入稍微复杂一点。MCP 是 Model Context Protocol简单理解就是让 Codex 能调用外部工具的协议。CAD 侧的 MCP Server 需要单独部署通常是一个本地服务监听某个端口Codex 通过 MCP 配置连接过去。配置片段在~/.codex/mcp.json{ mcpServers: { cad-tools: { command: node, args: [/path/to/cad-mcp-server/index.js], env: { CAD_PORT: 3000 } } } }这套配置跑通后Codex 就能通过 MCP 调用 CAD 的绘图、修改、查询接口。但要注意MCP 直连生产库是禁止的测试环境单独跑别把生产图纸接进去。3. 可复制配置AutoLISP 脚本生成与 DWG 批处理任务配置这一节是核心操作部分。我会给出一段完整的 AutoLISP 示例代码这段代码是 Codex 根据自然语言描述生成的功能是绘制基坑支护剖面里的土压力分布图。然后我会说明 DWG 批处理任务的配置方式。先看 AutoLISP 示例。假设你给 Codex 的提示词是「生成一段 AutoLISP在当前图纸里绘制一个矩形基坑剖面宽度 20 米深度 10 米并在左侧绘制三角形土压力分布图顶点在基坑底部。」Codex 生成的代码大概长这样;; 基坑支护剖面与土压力分布图 ;; 单位米绘图比例 1:100 (defun c:DrawExcavation ( / pt1 pt2 pt3 pt4 width depth scale) (setq scale 100.0) ;; 1:100 比例 (setq width 20.0) (setq depth 10.0) ;; 绘制基坑矩形 (setq pt1 (list 0.0 0.0)) (setq pt2 (list (* width scale) 0.0)) (setq pt3 (list (* width scale) (* depth scale))) (setq pt4 (list 0.0 (* depth scale))) (command _.PLINE pt1 pt2 pt3 pt4 C) ;; 绘制土压力三角形顶点在基坑底部左侧 (setq pt1 (list 0.0 0.0)) (setq pt2 (list 0.0 (* depth scale))) (setq pt3 (list (* -5.0 scale) 0.0)) (command _.PLINE pt1 pt2 pt3 C) ;; 添加文字标注 (command _.TEXT (list 0.0 (* -2.0 scale)) (* 2.5 scale) 0 土压力分布) (princ \n基坑剖面与土压力图绘制完成。) (princ) )这段代码加载后命令行输入DrawExcavation就能执行。实测结果是矩形基坑和左侧三角形土压力图都能正确绘制文字标注位置也合理。但有个细节要注意command函数里的_.PLINE前面加了下划线这是为了兼容不同语言版本的 CAD避免命令名被本地化。接下来是 DWG 批处理任务的配置。批处理的核心思路是用脚本遍历一个目录下的所有 DWG 文件对每个文件执行相同的 AutoLISP 操作然后保存。AutoCAD 提供了SCRIPT命令来执行脚本文件脚本文件是.scr格式内容就是一系列命令行输入。一个典型的批处理脚本batch_process.scr内容如下_.OPEN $1 _.APPLOAD draw_excavation.lsp DrawExcavation _.QSAVE _.CLOSE然后写一个批处理入口用accoreconsole.exe来跑。accoreconsole是 AutoCAD 的无界面控制台适合批处理#!/bin/bash # batch_run.sh for dwg in ./input/*.dwg; do filename$(basename $dwg) accoreconsole.exe /i $dwg /s batch_process.scr /l draw_excavation.lsp echo 处理完成: $filename done这里的关键参数说明/i指定输入 DWG/s指定脚本文件/l指定要加载的 LISP 文件。实测下来这个批处理能稳定跑通但要注意accoreconsole对中文路径支持不好输入输出目录尽量用英文。如果你要用 MCP 方式做批处理配置会更灵活。MCP Server 可以暴露一个batch_process工具Codex 通过自然语言调用「把 input 目录下所有 DWG 都执行土压力图绘制」。MCP Server 侧的配置片段{ tools: [ { name: batch_process_dwg, description: 批量处理 DWG 文件执行指定 AutoLISP 脚本, parameters: { input_dir: string, script_path: string, output_dir: string } } ] }这套配置的好处是Codex 可以根据你的自然语言描述动态生成脚本内容而不是固定跑同一个.lsp。但稳定性上固定脚本更可控动态生成适合探索性任务。4. 验证请求与成功结果从 401 到 DWG 输出的完整链路配置完成后怎么验证整条链路是通的我分三步走先验证模型接口能通再验证 AutoLISP 能跑最后验证 DWG 批处理能出结果。第一步验证模型接口。用 curl 发一个最简单的请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 生成一段绘制矩形的 AutoLISP 代码}] }如果返回 200 并且 choices 里有内容说明接口通了。如果返回 401说明 Key 不对或者没带上。如果返回local proxy failed说明你的网络层有代理拦截检查环境变量里的HTTP_PROXY和HTTPS_PROXY临时 unset 掉再试。第二步验证 AutoLISP。打开 AutoCAD命令行输入APPLOAD加载draw_excavation.lsp然后输入DrawExcavation。如果命令行提示「基坑剖面与土压力图绘制完成」并且图纸上出现了矩形和三角形说明脚本没问题。如果提示「输入的列表有缺陷」大概率是编码问题把.lsp文件另存为 ANSI 编码。如果提示「no function definition」说明函数名拼错了检查defun c:后面的名字。第三步验证 DWG 批处理。准备一个input目录放两三个测试 DWG然后跑batch_run.sh。实测输出如下处理完成: test1.dwg 处理完成: test2.dwg 处理完成: test3.dwg打开处理后的 DWG应该能看到每个文件里都多了土压力分布图。如果某个文件没变化检查accoreconsole的日志通常是脚本里的路径不对或者 DWG 文件被占用。这里我整理一个验证清单你可以对照排查验证项预期结果常见失败原因模型接口返回 200 choices401 Key 错误 / local proxy failedAutoLISP 加载提示加载成功编码错误 / 函数名拼写脚本执行图纸出现图元坐标系不对 / 比例错误DWG 批处理输出目录有文件路径含中文 / 文件被占用MCP 调用工具返回结果端口不通 / Server 未启动MCP 方式的验证稍微不同。启动 MCP Server 后在 Codex 里输入「调用 cad-tools 的 batch_process_dwg处理 input 目录」。如果返回reading choices相关的错误说明 MCP Server 返回的数据格式不对检查 Server 的响应是否符合 MCP 协议。如果返回 OAuth 相关错误说明 MCP Server 配了鉴权但 Codex 没带 token检查mcp.json里的env配置。实测下来最稳的组合是AutoLISP 脚本 accoreconsole 批处理。MCP 方式灵活但调试成本高适合改图阶段做交互操作不适合大批量出图。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照这一节我把实际踩过的坑列出来每个都给出报错原文和排查路径。这些报错在 Codex 接入 CAD 场景里出现频率很高你大概率会遇到。报错一401 Unauthorized{error: {message: Invalid API key, type: invalid_request_error}}原因Key 没带、Key 错了、或者 Key 过期了。排查先echo $TAOTOKEN_API_KEY看环境变量有没有值再检查配置文件里的env_key是否和实际环境变量名一致。注意 TaoToken 的 Key 是sk-开头别把别的平台的 Key 混进来。报错二local proxy failedError: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused原因你的系统配了本地代理但代理服务没启动或者端口不对。排查env | grep -i proxy看有没有HTTP_PROXY、HTTPS_PROXY、ALL_PROXY有的话临时 unsetunset HTTP_PROXY HTTPS_PROXY ALL_PROXY然后重新跑请求。如果必须走代理确保代理服务在运行端口和配置一致。报错三reading choices 相关错误Error: failed to parse response: reading choices - not an array原因模型接口返回的 JSON 结构不对通常是 Base URL 拼错了请求打到了非预期端点。排查检查base_url是不是https://taotoken.net/api有没有多写/v1或者少写。OpenAI 兼容接口的完整路径是https://taotoken.net/api/v1/chat/completions客户端会自动拼/v1/chat/completions你只需要填到/api。报错四OAuth 相关错误Error: OAuth token exchange failed: invalid_grant原因MCP Server 配了 OAuth 鉴权但 Codex 侧的 token 没配或者过期。排查检查mcp.json里的env有没有传OAUTH_TOKEN以及 token 是否有效。如果 MCP Server 不需要鉴权把 OAuth 配置去掉改成简单的 API Key 鉴权。报错五AutoLISP 加载后无反应命令行输入函数名后没报错也没绘图。原因函数名大小写不对或者defun后面的c:前缀漏了。排查AutoLISP 函数名不区分大小写但c:前缀必须有否则只能通过(函数名)调用不能直接命令行输入。报错六DWG 批处理部分文件失败原因accoreconsole对中文路径支持差或者 DWG 文件被其他进程占用。排查输入输出目录改成纯英文关闭所有打开这些 DWG 的 CAD 窗口。这里再强调一下三件套的完整性。如果你用 CC Switch、Cline MCP 或者 Codex 的auth.json必须同时配好 Base URL、Key、Model ID。缺一个都会报错。auth.json的格式{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: gpt-4o }Model ID 要和你实际调用的模型一致别填错。TaoToken 支持的模型列表可以在 https://taotoken.net/doc 查到。6. 从单点绘图到工程智能体Codex For CAD 的落地建议跑完整个评测流程后我对 Codex For CAD 的落地有几点实际建议。这些不是理论是我在复现过程中总结出来的。第一先从 AutoLISP 脚本入手别一上来就搞 MCP。AutoLISP 的优势是可读、可改、可版本管理出问题容易定位。MCP 虽然灵活但调试链路长一个环节不通就卡住。我的做法是用 Codex 生成 AutoLISP 脚本人工审核后入库再用批处理跑。这样既享受了 AI 生成的速度又保留了人工可控性。第二计算和绘图要分开验证。报告里提到计算阶段能提取土层参数、算土压力系数、复核桩身配筋。我的建议是计算部分单独跑一遍和手算或者理正的结果对照确认无误后再进入绘图阶段。别把计算和绘图混在一起调出了问题分不清是公式错还是绘图错。第三改图阶段用 MCP出图阶段用脚本。MCP 的优势是交互式修改比如「把这个锚索往左移 2 米」「把土压力图的顶点下移 1 米」这种单图元修改 MCP 很擅长。但批量出图还是脚本稳。复杂联动修改比如「基坑深度从 10 米改成 12 米所有相关图元联动更新」MCP 目前还不稳定需要人工兜底。第四Skill 沉淀是团队提效的关键。把常用的绘图流程封装成 Skill比如「基坑支护剖面标准绘制」「土压力分布图标准绘制」团队成员直接调用不用每次重新描述。Skill 的配置可以放在项目的.codex/skills/目录下每个 Skill 一个 JSON 文件描述触发条件和执行动作。第五三维协同和主动审查是下一步方向。报告里提到从单点绘图走向协同、闭环、Skill 沉淀、三维协同及主动审查。我的理解是Codex 未来不只是执行绘图指令还能主动发现图纸问题比如「这个剖面的锚索间距不符合规范」「土压力系数和土层参数不匹配」。这需要把规范库和计算逻辑都接进去目前还在探索阶段。如果你要长期做编码和 Agent 相关的任务可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan 。如果只是验证模型能力用模型对话就行https://taotoken.net/chat 。接入文档在 https://taotoken.net/doc API Key 管理在 https://taotoken.net/api-keys 。最后说一个实用技巧Codex 生成的 AutoLISP 代码别直接用于生产图纸。先在一个空白 DWG 里跑一遍确认图元位置、比例、图层都对再放到正式项目里。我踩过的坑是Codex 生成的代码默认图层是0颜色是ByLayer直接跑会导致图纸图层混乱。建议在脚本开头加一段图层设置(command _.LAYER M 土压力图 C 1 ) (command _.LAYER M 基坑轮廓 C 3 )这样图元会自动归到对应图层后续改图也方便。整个流程跑通后你会发现 Codex For CAD 确实能把「计算—画图—改图」的重复劳动压缩不少但前提是配置要对、验证要细、人工审核不能省。
【菜鸟教程】Codex For CAD 工程应用评测报告：从 AutoLISP 到 MCP 的 DWG 自动化实践
1. 从计算书到 DWGCodex 在 CAD 工程场景到底能做什么Codex 在 CAD 工程场景里能做什么适合谁用这是我在复现北航何静那份《Codex For CAD 工程应用评测报告》时最先想搞清楚的问题。简单说Codex 不是要替代 AutoCAD而是把「自然语言描述 → 可执行脚本 → DWG 成果」这条链路打通。它擅长的是把计算书里的土层参数、土压力系数、锚索布置这些结构化信息翻译成 AutoLISP 能跑的代码或者通过 MCP 工具链直接操作 CAD 图元。适合的人群很明确做基坑支护、结构、市政这类需要大量重复绘图的工程师以及想把「计算—画图—改图」流程封装成标准动作的技术负责人。我实测下来Codex 在 CAD 场景的落地方式主要有四条路径。第一条是直接生成 DWG 文件适合批量出图但灵活性差第二条是生成 AutoLISP 脚本这是最稳的因为脚本可读可改可版本管理第三条是通过 MCP 连接 CAD 做交互操作改图阶段特别有用第四条是封装成 Skill 做标准化流程适合团队沉淀。这四条路径不是互斥的实际项目里往往是组合使用。先说说为什么这件事值得做。传统工程里「计算—画图—改图」三个环节是割裂的计算用 Excel 或理正画图用 CAD改图靠人工对照。数据孤岛导致重复劳动一个参数变了土压力图、支护剖面、锚索布置全要手动联动。Codex 的价值在于它能把计算阶段的输出直接转成绘图指令减少中间的手工搬运。比如土层参数提取后主动土压力系数、被动土压力系数、分层土压力、水土压力、支锚轴向力这些计算Codex 可以按规范公式跑一遍还能识别参数缺失并提示补充。但要注意Codex 不是万能的。报告里也提到复杂联动修改仍有不稳定情况。我的经验是单图元修改、局部联动调整、多目标复合修改这些它能做但涉及多张图纸的强约束推理修正还是得人工兜底。所以定位要清楚它是提效工具不是全自动设计系统。这一节先建立认知Codex For CAD 的核心能力是「自然语言与计算书 → CAD 成果」的转换加上辅助改图和流程封装。接下来我会从环境准备开始把可复制的配置、AutoLISP 示例、DWG 批处理验证步骤一步步拆开让你能在本地复现整个评测流程。2. TaoToken 前置准备Codex 接入的 Base URL 与 Key 怎么配要让 Codex 在 CAD 场景跑起来前置准备分两块一是 Codex 本身的接入配置二是 CAD 侧的脚本执行环境。这里我用 TaoToken 作为模型接入层因为它同时提供 OpenAI 兼容接口和 Claude Code 的 Anthropic 兼容接口配置起来比较统一。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制保存。注意这个 Key 只在创建时显示一次丢了就得重建。拿到 Key 后Codex 的配置核心是三件套Base URL、API Key、Model ID。Base URL 填https://taotoken.net/api注意不要加 UTM 参数API 地址就是纯域名加路径。如果你用的是 Codex CLI 或者兼容 OpenAI 接口的客户端配置文件通常放在~/.codex/config.toml或者项目根目录的.codex/config.toml。我实测的配置片段如下你可以直接复制# ~/.codex/config.toml model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在环境变量里设置 Keyexport TAOTOKEN_API_KEYsk-你的Key如果你用的是 Claude Code 那套 Anthropic 兼容接口配置路径在~/.claude/settings.json片段如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key } }这里有个坑要注意Anthropic 兼容接口和 OpenAI 兼容接口的 Base URL 都是https://taotoken.net/api但路径拼接方式不同。OpenAI 兼容会自动加/v1/chat/completionsAnthropic 兼容会加/v1/messages。如果你手动拼路径很容易 404。所以建议直接用官方客户端别自己写 HTTP 请求。CAD 侧的环境准备主要是 AutoLISP 的执行环境。AutoCAD 自带 Visual LISP 编辑器命令行输入VLISP就能打开。如果你用的是中望、浩辰这些国产 CAD也基本兼容 AutoLISP但部分函数可能有差异。我测试用的是 AutoCAD 2024加载脚本的方式是APPLOAD命令选择.lsp文件即可。还有一个关键点Codex 生成的 AutoLISP 脚本编码要用 ANSI 或者 GBK不能用 UTF-8否则中文注释会乱码。这个坑我踩过脚本加载后提示「输入的列表有缺陷」排查半天才发现是编码问题。保存.lsp文件时在编辑器里选「ANSI」编码。MCP 工具链的接入稍微复杂一点。MCP 是 Model Context Protocol简单理解就是让 Codex 能调用外部工具的协议。CAD 侧的 MCP Server 需要单独部署通常是一个本地服务监听某个端口Codex 通过 MCP 配置连接过去。配置片段在~/.codex/mcp.json{ mcpServers: { cad-tools: { command: node, args: [/path/to/cad-mcp-server/index.js], env: { CAD_PORT: 3000 } } } }这套配置跑通后Codex 就能通过 MCP 调用 CAD 的绘图、修改、查询接口。但要注意MCP 直连生产库是禁止的测试环境单独跑别把生产图纸接进去。3. 可复制配置AutoLISP 脚本生成与 DWG 批处理任务配置这一节是核心操作部分。我会给出一段完整的 AutoLISP 示例代码这段代码是 Codex 根据自然语言描述生成的功能是绘制基坑支护剖面里的土压力分布图。然后我会说明 DWG 批处理任务的配置方式。先看 AutoLISP 示例。假设你给 Codex 的提示词是「生成一段 AutoLISP在当前图纸里绘制一个矩形基坑剖面宽度 20 米深度 10 米并在左侧绘制三角形土压力分布图顶点在基坑底部。」Codex 生成的代码大概长这样;; 基坑支护剖面与土压力分布图 ;; 单位米绘图比例 1:100 (defun c:DrawExcavation ( / pt1 pt2 pt3 pt4 width depth scale) (setq scale 100.0) ;; 1:100 比例 (setq width 20.0) (setq depth 10.0) ;; 绘制基坑矩形 (setq pt1 (list 0.0 0.0)) (setq pt2 (list (* width scale) 0.0)) (setq pt3 (list (* width scale) (* depth scale))) (setq pt4 (list 0.0 (* depth scale))) (command _.PLINE pt1 pt2 pt3 pt4 C) ;; 绘制土压力三角形顶点在基坑底部左侧 (setq pt1 (list 0.0 0.0)) (setq pt2 (list 0.0 (* depth scale))) (setq pt3 (list (* -5.0 scale) 0.0)) (command _.PLINE pt1 pt2 pt3 C) ;; 添加文字标注 (command _.TEXT (list 0.0 (* -2.0 scale)) (* 2.5 scale) 0 土压力分布) (princ \n基坑剖面与土压力图绘制完成。) (princ) )这段代码加载后命令行输入DrawExcavation就能执行。实测结果是矩形基坑和左侧三角形土压力图都能正确绘制文字标注位置也合理。但有个细节要注意command函数里的_.PLINE前面加了下划线这是为了兼容不同语言版本的 CAD避免命令名被本地化。接下来是 DWG 批处理任务的配置。批处理的核心思路是用脚本遍历一个目录下的所有 DWG 文件对每个文件执行相同的 AutoLISP 操作然后保存。AutoCAD 提供了SCRIPT命令来执行脚本文件脚本文件是.scr格式内容就是一系列命令行输入。一个典型的批处理脚本batch_process.scr内容如下_.OPEN $1 _.APPLOAD draw_excavation.lsp DrawExcavation _.QSAVE _.CLOSE然后写一个批处理入口用accoreconsole.exe来跑。accoreconsole是 AutoCAD 的无界面控制台适合批处理#!/bin/bash # batch_run.sh for dwg in ./input/*.dwg; do filename$(basename $dwg) accoreconsole.exe /i $dwg /s batch_process.scr /l draw_excavation.lsp echo 处理完成: $filename done这里的关键参数说明/i指定输入 DWG/s指定脚本文件/l指定要加载的 LISP 文件。实测下来这个批处理能稳定跑通但要注意accoreconsole对中文路径支持不好输入输出目录尽量用英文。如果你要用 MCP 方式做批处理配置会更灵活。MCP Server 可以暴露一个batch_process工具Codex 通过自然语言调用「把 input 目录下所有 DWG 都执行土压力图绘制」。MCP Server 侧的配置片段{ tools: [ { name: batch_process_dwg, description: 批量处理 DWG 文件执行指定 AutoLISP 脚本, parameters: { input_dir: string, script_path: string, output_dir: string } } ] }这套配置的好处是Codex 可以根据你的自然语言描述动态生成脚本内容而不是固定跑同一个.lsp。但稳定性上固定脚本更可控动态生成适合探索性任务。4. 验证请求与成功结果从 401 到 DWG 输出的完整链路配置完成后怎么验证整条链路是通的我分三步走先验证模型接口能通再验证 AutoLISP 能跑最后验证 DWG 批处理能出结果。第一步验证模型接口。用 curl 发一个最简单的请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 生成一段绘制矩形的 AutoLISP 代码}] }如果返回 200 并且 choices 里有内容说明接口通了。如果返回 401说明 Key 不对或者没带上。如果返回local proxy failed说明你的网络层有代理拦截检查环境变量里的HTTP_PROXY和HTTPS_PROXY临时 unset 掉再试。第二步验证 AutoLISP。打开 AutoCAD命令行输入APPLOAD加载draw_excavation.lsp然后输入DrawExcavation。如果命令行提示「基坑剖面与土压力图绘制完成」并且图纸上出现了矩形和三角形说明脚本没问题。如果提示「输入的列表有缺陷」大概率是编码问题把.lsp文件另存为 ANSI 编码。如果提示「no function definition」说明函数名拼错了检查defun c:后面的名字。第三步验证 DWG 批处理。准备一个input目录放两三个测试 DWG然后跑batch_run.sh。实测输出如下处理完成: test1.dwg 处理完成: test2.dwg 处理完成: test3.dwg打开处理后的 DWG应该能看到每个文件里都多了土压力分布图。如果某个文件没变化检查accoreconsole的日志通常是脚本里的路径不对或者 DWG 文件被占用。这里我整理一个验证清单你可以对照排查验证项预期结果常见失败原因模型接口返回 200 choices401 Key 错误 / local proxy failedAutoLISP 加载提示加载成功编码错误 / 函数名拼写脚本执行图纸出现图元坐标系不对 / 比例错误DWG 批处理输出目录有文件路径含中文 / 文件被占用MCP 调用工具返回结果端口不通 / Server 未启动MCP 方式的验证稍微不同。启动 MCP Server 后在 Codex 里输入「调用 cad-tools 的 batch_process_dwg处理 input 目录」。如果返回reading choices相关的错误说明 MCP Server 返回的数据格式不对检查 Server 的响应是否符合 MCP 协议。如果返回 OAuth 相关错误说明 MCP Server 配了鉴权但 Codex 没带 token检查mcp.json里的env配置。实测下来最稳的组合是AutoLISP 脚本 accoreconsole 批处理。MCP 方式灵活但调试成本高适合改图阶段做交互操作不适合大批量出图。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照这一节我把实际踩过的坑列出来每个都给出报错原文和排查路径。这些报错在 Codex 接入 CAD 场景里出现频率很高你大概率会遇到。报错一401 Unauthorized{error: {message: Invalid API key, type: invalid_request_error}}原因Key 没带、Key 错了、或者 Key 过期了。排查先echo $TAOTOKEN_API_KEY看环境变量有没有值再检查配置文件里的env_key是否和实际环境变量名一致。注意 TaoToken 的 Key 是sk-开头别把别的平台的 Key 混进来。报错二local proxy failedError: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused原因你的系统配了本地代理但代理服务没启动或者端口不对。排查env | grep -i proxy看有没有HTTP_PROXY、HTTPS_PROXY、ALL_PROXY有的话临时 unsetunset HTTP_PROXY HTTPS_PROXY ALL_PROXY然后重新跑请求。如果必须走代理确保代理服务在运行端口和配置一致。报错三reading choices 相关错误Error: failed to parse response: reading choices - not an array原因模型接口返回的 JSON 结构不对通常是 Base URL 拼错了请求打到了非预期端点。排查检查base_url是不是https://taotoken.net/api有没有多写/v1或者少写。OpenAI 兼容接口的完整路径是https://taotoken.net/api/v1/chat/completions客户端会自动拼/v1/chat/completions你只需要填到/api。报错四OAuth 相关错误Error: OAuth token exchange failed: invalid_grant原因MCP Server 配了 OAuth 鉴权但 Codex 侧的 token 没配或者过期。排查检查mcp.json里的env有没有传OAUTH_TOKEN以及 token 是否有效。如果 MCP Server 不需要鉴权把 OAuth 配置去掉改成简单的 API Key 鉴权。报错五AutoLISP 加载后无反应命令行输入函数名后没报错也没绘图。原因函数名大小写不对或者defun后面的c:前缀漏了。排查AutoLISP 函数名不区分大小写但c:前缀必须有否则只能通过(函数名)调用不能直接命令行输入。报错六DWG 批处理部分文件失败原因accoreconsole对中文路径支持差或者 DWG 文件被其他进程占用。排查输入输出目录改成纯英文关闭所有打开这些 DWG 的 CAD 窗口。这里再强调一下三件套的完整性。如果你用 CC Switch、Cline MCP 或者 Codex 的auth.json必须同时配好 Base URL、Key、Model ID。缺一个都会报错。auth.json的格式{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: gpt-4o }Model ID 要和你实际调用的模型一致别填错。TaoToken 支持的模型列表可以在 https://taotoken.net/doc 查到。6. 从单点绘图到工程智能体Codex For CAD 的落地建议跑完整个评测流程后我对 Codex For CAD 的落地有几点实际建议。这些不是理论是我在复现过程中总结出来的。第一先从 AutoLISP 脚本入手别一上来就搞 MCP。AutoLISP 的优势是可读、可改、可版本管理出问题容易定位。MCP 虽然灵活但调试链路长一个环节不通就卡住。我的做法是用 Codex 生成 AutoLISP 脚本人工审核后入库再用批处理跑。这样既享受了 AI 生成的速度又保留了人工可控性。第二计算和绘图要分开验证。报告里提到计算阶段能提取土层参数、算土压力系数、复核桩身配筋。我的建议是计算部分单独跑一遍和手算或者理正的结果对照确认无误后再进入绘图阶段。别把计算和绘图混在一起调出了问题分不清是公式错还是绘图错。第三改图阶段用 MCP出图阶段用脚本。MCP 的优势是交互式修改比如「把这个锚索往左移 2 米」「把土压力图的顶点下移 1 米」这种单图元修改 MCP 很擅长。但批量出图还是脚本稳。复杂联动修改比如「基坑深度从 10 米改成 12 米所有相关图元联动更新」MCP 目前还不稳定需要人工兜底。第四Skill 沉淀是团队提效的关键。把常用的绘图流程封装成 Skill比如「基坑支护剖面标准绘制」「土压力分布图标准绘制」团队成员直接调用不用每次重新描述。Skill 的配置可以放在项目的.codex/skills/目录下每个 Skill 一个 JSON 文件描述触发条件和执行动作。第五三维协同和主动审查是下一步方向。报告里提到从单点绘图走向协同、闭环、Skill 沉淀、三维协同及主动审查。我的理解是Codex 未来不只是执行绘图指令还能主动发现图纸问题比如「这个剖面的锚索间距不符合规范」「土压力系数和土层参数不匹配」。这需要把规范库和计算逻辑都接进去目前还在探索阶段。如果你要长期做编码和 Agent 相关的任务可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan 。如果只是验证模型能力用模型对话就行https://taotoken.net/chat 。接入文档在 https://taotoken.net/doc API Key 管理在 https://taotoken.net/api-keys 。最后说一个实用技巧Codex 生成的 AutoLISP 代码别直接用于生产图纸。先在一个空白 DWG 里跑一遍确认图元位置、比例、图层都对再放到正式项目里。我踩过的坑是Codex 生成的代码默认图层是0颜色是ByLayer直接跑会导致图纸图层混乱。建议在脚本开头加一段图层设置(command _.LAYER M 土压力图 C 1 ) (command _.LAYER M 基坑轮廓 C 3 )这样图元会自动归到对应图层后续改图也方便。整个流程跑通后你会发现 Codex For CAD 确实能把「计算—画图—改图」的重复劳动压缩不少但前提是配置要对、验证要细、人工审核不能省。
