企业官网建设流程全解析

干机械这行十几年，天天跟SolidWorks、AutoCAD、各种ERP、PDM系统纠缠，我最清楚那种感觉：画图本身不难，难的是那些绕不开的杂活——做个BOM、批量改图号、整理外购件清单、把客户发来的乱七八糟表格洗成标准格式。整个人像被困在重复劳动里，想写个小脚本又没时间系统学编程。第一次看到Codex出现在终端里，说实话我没当回事，直到我试着让它处理一个几百行的物料表，它自己读文件、写脚本、跑命令，最后把干净结果摆在面前的时候，我才意识到这东西对机械工程师的意义可能被严重低估了。

这篇文章不聊什么高深理论，就从一个机械工程师的实际视角，讲清楚Codex该怎么装、怎么配、怎么真正用来干日常活，以及我踩过的一堆坑。重点会落在安装登录、接入DeepSeek这类兼容服务、三个可以直接抄的提效案例，报错速查这几块。如果你也是被表格和改名单折磨的传统工程师，这篇文章应该能帮你少走不少弯路。

1. 先搞清楚：Codex对机械工程师意味着什么

1.1 它不是聊天机器人，是能动手干活的智能体

很多人把Codex理解成又一个聊天窗口，这个误解特别要命。ChatGPT这类工具是“给你建议，你自己干”，而Codex是“接了任务，自己去干”：它在终端里能看到你的文件目录，能执行Shell命令，能调用文件编辑器，能改代码、跑代码、看运行结果，然后根据反馈继续迭代。

我习惯这么类比：普通AI是坐在旁边讲流程的老师，Codex则像实验室助理。你跟助理说“把这批样品的测试数据整理成报告”，他会自己翻数据、做表格、写说明，做完了拿给你看，你觉得哪里不对，他马上改。机械工程师不缺老师，缺的是能直接交活的人，Codex干的就是这个定位。

用命令行启动Codex，或者在VS Code里安装插件后，你会发现它的工作方式非常接近“带了个实习生在旁边”：你跟它说“处理当前目录下的CSV”，它不会只给一段代码让你自己跑，而是会实际写脚本、执行、报错后自己看原因再修，最后告诉你结果。这种“任务闭环”能力，才是提效的真正来源。

1.2 机械工程师的典型痛点，正好踩在Codex的主场上

如果你的日常工作主要是建模、出图、校核，Codex不会替你画图，也不会替你拍板选材料。但机械工程师的大半时间根本不在建模上，反而耗在这些事上：

• BOM和物料数据整理：从PDM或ERP导出的Excel、CSV，字段乱、单位混、空值多，清洗过程极其枯燥。
• 批量文件操作：几百个DWG、DXF、STEP文件，按规则批量重命名、归入对应项目文件夹，手工操作能点到手抽筋。
• 技术文档的初稿准备：写外购件清单、设计变更说明、设备操作流程，结构化的内容很多人不会写，每次都要憋半天。
• CAD脚本和宏：让SolidWorks批量导出工程图、遍历装配体生成零件清单、批量设置自定义属性，这些VBA/Python脚本每次都要临时找人写。

Codex恰恰擅长把“一次性小脚本”当场写出来并跑通。它不用你懂编程语法，你只要把工程需求描述清楚，剩下的交给它。很多机械工程师一听“编程”就头疼，但让Codex生成脚本和让你自己从零学编程完全是两码事。你要做的是会描述需求、会看结果，而不是背API。

当然，我还是要泼一盆冷水：有限元分析结论、关键承载部件的手工计算、需要签字负责的设计输出，这些不要直接“甩”给Codex。它可以帮你生成计算脚本、整理输入数据，但最后的技术判断必须由你来做。工具是放大你的能力，不是替代你的责任。

2. 装环境、登录、配模型：从0到能用要几步

2.1 安装前先检查这三样，不然会走弯路

Codex的安装方式有命令行工具、Windows桌面版、VS Code插件三条路。我不建议一上来就折腾插件，先把命令行跑通，后面在编辑器里自然就顺了。

装CLI之前，打开终端（Windows上就是PowerShell或Windows Terminal）确认两件事：

node -v npm -v

如果输出v18或更高的版本号，说明Node环境没问题。如果提示找不到命令，就去Node官网下载LTS版本装一遍，装完重开终端再验证。Codex命令行基于Node.js，这一步跳不过去。如果你完全不想碰Node，也可以直接跳过CLI，用官方桌面版安装包，图形界面点一点也能启动，但很多进阶配置还是得编辑配置文件，所以我个人推荐CLI加桌面版都装。

2.2 安装顺序和第一条命令

我用得最顺的顺序是：先装CLI，再装桌面版，最后装VS Code插件。CLI装好后，命令行里执行：

npm install -g @openai/codex codex --version

能看到版本号，CLI就装好了。然后登录：

codex login

命令会弹出一个浏览器页面，你在官方页面完成账号安全验证后，终端里会显示登录成功。整个过程一两分钟。需要注意，账号验证按官方要求完成即可，邮箱、手机号这些步骤别嫌麻烦，填完后长期有效。

登录之后第一次验证，我不建议直接去处理正式文件，先跑一条无害命令试试水：

codex "列出当前目录下的文件，并告诉我每个文件大概是什么用途"

这时候你能看到Codex的真实工作过程：它先执行ls或dir看目录，再逐行读文件开头，最后给你总结，并且每一步动作都在终端里明确显示。看到这个过程，你就知道它跟聊天窗有什么本质区别了。

2.3 VS Code插件和桌面版其实是一套配置

VS Code插件适合画图和看图纸间隙顺手用。在扩展市场搜“OpenAI Codex”，安装后用同一个账号登录，你可以在编辑器右侧打开对话面板，选中一段文字或点选一个文件，直接让Codex帮你解释、修改、生成。桌面版则像一个独立的图形界面壳，适合不想盯着命令行的人。

这三个入口共享的是同一套配置和会话历史，不会各管各。唯一要留神的是，不同入口默认选的模型可能不完全一样，后面配置了自定义模型时，一定要所有入口都检查一遍。

2.4 登录和API Key怎么取舍

个人用，codex login浏览器授权最省事，登录态保持好基本不用重复操作。但如果是公司团队用，我更推荐走API Key方式：把OPENAI_API_KEY设成环境变量，哪个会话用的哪个Key，后台看得清清楚楚，权限回收也方便。

Windows PowerShell里设置环境变量：

$env:OPENAI_API_KEY="你的key"

macOS或Linux终端里：

export OPENAI_API_KEY="你的key"

设置后重开终端、重新登录一次。如果碰到“auth token is unavailable”之类提示，九成是登录态没建立或环境变量没读到，按这个顺序重来一遍就好。

3. 进阶配置：把Codex接到DeepSeek等兼容后端

3.1 为什么有人要给Codex换个后端

Codex默认走OpenAI官方服务，账号类型合适、网络环境正常的话，开箱即用。但很多团队有额外需求：公司已经采购了某个模型服务商的API额度，或者要求所有工程数据统一走内部模型网关，又或者单纯是想用DeepSeek这类更经济的模型跑日常杂活。Codex CLI支持通过配置文件自定义模型提供商，只要对方接口兼容OpenAI格式就行。

我特别想强调一个前提：接哪个后端，一定是你有对应API Key、并且服务能力真实可用的前提下。这跟用哪个邮箱是一个道理，账号得是你自己的，权限才是你的。

3.2 配置文件到底怎么写才不出错

Codex的全局配置文件通常在用户主目录下的.codex/config.toml里。你可以在终端里用codex命令查看配置目录，也可以自己在用户目录下创建.codex文件夹。以接入DeepSeek为例，我常用的配置模板是这样的：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"

这里几个字段的逻辑很简单：

• model：你实际要用的模型名，DeepSeek平台文档里叫deepseek-chat，具体以你拿到的模型名称为准。
• model_provider：对应下面定义的[model_providers.deepseek]这一段，相当于给这个服务起了个名字。
• base_url：接口地址，很多第三方服务要以/v1结尾，写错了就会报“地址不存在”或“请求路径错误”。
• env_key：告诉Codex，去读哪个环境变量获取密钥。不要把Key直接写在配置文件里，不然文件一分享就泄密。

配好后设置环境变量：

export DEEPSEEK_API_KEY="sk-你的key"

然后重新打开终端，跑一条简单任务验证。如果Codex开始正常读文件、执行命令，说明后端已经切换成功。这里有个容易忽略的点：改了配置后一定要重启终端会话，旧会话里环境变量和配置不会自动刷新。

3.3 用内部网关统一管理时，最常见的坑就那几个

有些团队会用ccswitch这类本地网关工具来统一管理多个模型服务的入口，把不同服务的接口收敛到本地一个端口。好处是团队里每个人不用各自记五花八门的地址和Key，统一走一套接入规范。但网关类的玩法也是最容易出现连接问题的，我见过无数人卡在这里。

最典型的错误是Endpoint转发失败，Codex执行任务时会提示类似“网关端点转发失败”的信息。排查顺序我建议固定成一条线：

我个人的经验是：如果是自己电脑上跑网关调试，遇到转发失败，百分之六十是端口写错，百分之二十是网关根本没启动，剩下才是配置格式和密钥问题。先把这两点排掉，再去看日志，不要上来就怀疑配置模板有问题。

3.4 自定义模型后，要习惯看“执行日志”

配了第三方后端后，Codex界面上的行为和官方后端略有差别，有些请求状态要在网关或API服务商后台才看得清楚。我建议跑任务时开一个终端窗口专门看日志，另一边正常使用Codex。一旦报错，日志里每一行都是线索，能直接告诉你请求到了哪一步、在哪个环节断的，比盲猜快太多。

4. 三个能直接抄的机械工程提效案例

4.1 用Python清洗PDM导出的物料清单

PDM导出的CSV永远不是给人直接看的：字段错位、单位混用、空列一堆、材料名称有“\t”和空格。按我以前的脾气，这种活纯靠Excel手动拖，一遍遍筛选替换，没半小时下不来。

我给Codex的提示词是这么写的：

当前目录有一个bom_raw.csv，是PDM导出的物料清单。 字段包含：物料编码、名称、材料、单重(kg)、单重(g)、备注、备注重复列。 写一个Python脚本： 1. 读入CSV，删除全空列和完全重复的备注列； 2. 把单重(kg)和单重(g)统一换算成kg，保留两位小数； 3. 材料列去除首尾空格和制表符，统一为大写； 4. 输出bom_clean.xlsx，保留标题行。 先给我看清洗后的前10行，再输出完整文件。

Codex自己在终端里写了脚本、装了pandas和openpyxl依赖、跑了中间结果，最后给了一张干净表格。整个过程它都清楚标注了每一步在干什么。我只需要在最后确认输出文件里的物料数量跟原表一致，就完成了。

这里必须夸一下它的容错能力：CSV出现编码乱码、列名跟预期不一样时，Codex会自己读文件、发现问题、调整脚本，而不是抛个异常就停在那。这一点是真的省心。

4.2 批量重命名DWG图纸，先出计划再动手

机械团队里的图纸命名往往经历过好几代标准：ABC-123-FLANGE-V2.dwg、xxx_法兰盘_final.dwg、Draft3.dwg混在一起。手动改名不光慢，还容易点错。

我给Codex的要求是：

当前目录有几百个dwg文件，命名很乱。 按规则重命名： 格式：项目号-图号-名称小写下划线.dwg 如果图号在原名里能找到，就保留；找不到就跳过。 先输出一份改名计划列表，格式为“原名 -> 新名”， 等我说确认后再执行。

这个提示词的核心不是改名，而是“先出计划再执行”。Codex会先把扫描和重命名规则整理成一张表，你仔细核查一遍，再让它动手。我见过太多人让AI直接执行批量操作，结果规则理解偏差，几百个文件名全反了。机械行业的文件归档比代码文件更敏感，宁可慢一步，不要错一次。加了“跳过无法识别”这个兜底，也防止了它把不知道哪来的文件硬塞进新格式。

4.3 让SolidWorks宏帮你遍历装配体输出材料清单

SolidWorks的API宏对机械工程师来说是最实用的脚本场景之一。以前每次需要统计装配体里所有零件的材质、重量和数量，我都得手动展开FeatureManager树，一个个看。这个过程不但慢，还经常漏掉隐藏的子装配体。

我让Codex生成一个VBA宏，提示词直接描述需求：

用VBA写一个SolidWorks宏： 1. 读取当前打开的装配体； 2. 遍历所有零部件，包括子装配体里的零件； 3. 统计每个零件出现次数、材质、单重、总重； 4. 输出到txt文件和Excel； 5. 单位为kg，数量按顶层装配体实际使用次数计算。

Codex生成的宏主干长这样：

Dim swApp As Object Dim swModel As SldWorks.ModelDoc2 Dim swAsm As SldWorks.AssemblyDoc Dim swComp As SldWorks.Component2 Dim swCustPrp As SldWorks.CustomPropertyManager Set swApp = Application.SldWorks Set swModel = swApp.ActiveDoc Set swAsm = swModel Dim i As Long Dim totalCount As Long For i = 0 To swAsm.GetComponentCount() - 1 Set swComp = swAsm.GetComponent(i) ' 读取名称、材质、质量等自定义属性 ' 统计数量时注意区分顶层装配体和子装配体 Next i

这段不是全部代码，但足够说明思路。Codex会把完整宏写出来，连注释都一起生成。我拿到后在SolidWorks的VBA编辑器里粘进去运行就行。必须提醒的是：先在只有一个零件的装配体或小型装配体上试跑，确认输出格式没问题，再拿到大型装配体上跑。SolidWorks的遍历API在大型装配体上可能会比较慢，中途卡住要先排查是不是有虚拟零部件或者轻化状态引起的。

4.4 所有自动化任务，我都强制加一道审批关

这三个案例有一个共同点：我都要求Codex在执行前先解释计划，再由我确认。命令行工具默认在执行敏感操作前会有确认提示，但如果你为了省事在一个指令里带上了“直接执行”之类的字样，或是在某些模式下放开了自动审批，风险就上来了。机械行业最怕的就是批量操作不可逆：改名、移动文件、覆盖Excel，一旦执行错，找回的成本可能比手工干还高。

我现在的习惯是：所有涉及文件系统写入、重命名、删除的操作，提示词里固定加上“先输出计划，等我确认后再执行”。多花十几秒，能避免一次灾难。

5. 踩坑实录：这些报错我都替你试过了

5.1 “auth token is unavailable”到底卡在哪

这个报错我遇到过好几次。第一次是因为登录后直接开了一个新的终端窗口，但环境变量是在旧窗口里设的，新窗口根本没继承。第二次是打开了Codex桌面版但还没重新登录，桌面版和CLI的会话状态不同步。解决办法很简单：先codex login重新授权，然后确保环境变量在当前终端里真的存在，最后看Codex和你所用网关的版本是否一致。总之不要只盯着报错本身，先确认“登录态”和“环境变量”这两件事。

5.2 Chatgpt账号登录时提示模型不支持

这个报错原文有点长，大意是：使用ChatGPT账号登录Codex时，当前配置的模型不支持。很多人的第一反应是去改模型名，但改了半天还是错。实际上核心问题是账号类型与模型权限不匹配，你登录的账号在当前条件下没有这个模型的使用资格，或者Codex版本默认指向了一个新模型，而账号类型还没被分配该模型的访问权。

处理方式按优先级排：

• 检查Codex当前版本，新版官方模型支持情况变化很快，旧版本经常会报这些莫名其妙的模型不支持。
• 看配置里model字段是不是写了一个特别新的模型名，换成账号实际可用的模型。
• 团队场景直接改用API Key方式，或者用第3节的方法接自己的模型服务。

我之前折腾了一下午，最后发现是版本太旧加上账号类型限制，升级后就好了。

5.3 “ignoring 1 unrecognized configuration setting”

这个报错出现过两次，一次是我把env_key拼成了env_keyy，另一次是复制了网上老版本配置里的一个已经废弃的字段。Codex遇到不认识的配置项不会让程序崩溃，只会默默忽略，但忽略项可能正好是你需要的功能，结果就是配置没生效，行为跟预期不一样。

解决办法是打开config.toml，对照Codex当前版本文档逐行检查。我自己最常用的一招是：报错之后把配置文件里所有字段名复制出来，去官方文档页面对照一遍，不眼熟的一律注释掉。别偷懒，配置文件这东西，多一个错字都后果难料。

5.4 桌面版打不开、界面空白、登录转圈

这类问题基本围绕两个原因：本地缓存损坏，以及旧版本残留配置与新版本冲突。处理顺序我固定成这套：先彻底退出桌面版，清理应用缓存和用户目录下的.codex临时文件夹，再重新安装最新版。如果还不行，就卸载后手动删掉整个配置目录重来，登录后重新设置。这里提醒一句：动手删配置目录前，先把config.toml备份出来，不然自定义模型配置全要重写。

5.5 那些“伪问题”：汉化、离线包、验证

网上很多人在问汉化、离线安装包、手机号验证的事情。我的看法是：Codex的配置文件和输出内容用中文本身没问题，但你设置的键名、模型名、API地址必须保持英文原样，所以汉化界面意义不大。离线安装包确实存在，适合内网环境，但从官方渠道获取最稳妥。账号验证按官方流程走一遍就完事，没有什么特殊捷径，也不应该去追求什么特殊捷径。工具是用来干活的，把登录这关老老实实过了，后面才能顺畅。

6. 机械团队落地Codex的几条经验

6.1 先拿“只读+统计”任务练手

一个新工具进团队，最怕一步到位。我建议先用不涉及改动的只读任务让大家熟悉：让Codex统计目录里的图纸数量、汇总某类文件大小、解析标准件清单。这类任务不会改坏任何东西，即使Codex理解偏了，损失也只是重跑一次。等大家习惯了它的交互方式，再逐步上批量操作和宏生成。

6.2 把常用需求沉淀成提示词模板

同一个BOM清洗需求，第一次写提示词用了五分钟，第二次还要重来就太亏了。我让团队把反复使用的提示词统一放到一个共享的Markdown文件里，按场景分类：BOM清洗、图纸改名、SolidWorks宏生成、文档初稿、数据校验。用时直接复制，改个文件路径就行。这个模板库积累起来以后，新员工上手速度会快非常多，因为他不用摸索怎么跟Codex描述需求，直接套模板就完事。

6.3 权限控制和审计是底线

不要让Codex随便以管理员权限跑，也不要一上来就给它PDM、ERP核心数据库的写权限。我的推荐做法是：Codex负责生成脚本和输出文件，涉及生产的操作由人审定后手工执行。需要改动数据库或系统配置时，让Codex生成SQL或命令，你检查后再执行。审计日志也要开着，很多Codex入口本身会记录操作历史，团队落地时应该要求成员保留关键任务的执行日志，出了故障能追溯。

6.4 工程数据的安全边界比效率更重要

这是我最想强调的部分。很多机械图纸和材料参数是公司的核心资产，不要为了省事直接把专利图纸里的敏感信息整段发给任何外部模型服务。处理敏感数据时，先做脱敏：把型号、材料、特殊参数替换成代号，让Codex处理“结构”而不是处理“内容”。更稳妥的方案是把模型服务部署在内部网关后面，统一收敛访问日志。效率是目的，但数据安全是不可倒退的底线。这个顺序如果搞反了，后面所有省下的时间都会以另一种方式还回去。

我自己现在的工作节奏是：SolidWorks里画图时开着VS Code插件，遇到表格和文件操作就切到终端跟Codex对话。它帮我处理了曾经的“鸡肋时间”，那些以前嫌麻烦不想碰的批量整理，现在都成了几轮对话就能解决的事。最值钱的不是它写了多好的代码，而是它让我能把精力放回真正的设计判断上。机械工程师想要的不是什么魔法，就是一个能接活、能改错、能交付结果的下手，Codex在某些场景下确实做到了。