企业官网建设流程全解析

1. 从计算书到 DWG：Codex 在 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"

然后在环境变量里设置 Key：

export TAOTOKEN_API_KEY="sk-你的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/completions，Anthropic 兼容会加/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 文件被占用。

这里我整理一个验证清单，你可以对照排查：

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 failed

Error: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused

原因：你的系统配了本地代理，但代理服务没启动，或者端口不对。排查：env | grep -i proxy看有没有HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，有的话临时 unset：

unset 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 确实能把「计算—画图—改图」的重复劳动压缩不少，但前提是配置要对、验证要细、人工审核不能省。