夜雨聆风AI 开始替结构工程师干活了：Codex 重构结构设计工作流
💡 从”会说话的大脑”到”能干活的双手”——AI 正在重新定义结构工程师的工作方式。
如果你对 AI 的印象还停留在”写写文案、回答问题、帮忙查规范”，那么这篇文章想讨论的是更进一步的东西：
🔹 AI 不再只是回答问题，而是开始直接参与工程工作流。
本文将从以下维度展开：
🧠 Codex 是什么 → 从对话到执行的能力跃迁 ⚙️ Agent 工作机制 → 用案例看懂”能干活”的本质 🏗️ 结构软件应用 → SAP2000 / Rhino / CAD / YJK 实战 🚀 Vibe Coding → 工程师能力重构与未来
📊 AI 在工程领域的机会缺口
两条线之间的差距，就是机会。
对结构工程师来说，AI 真正有价值的地方，不是替你解释力学概念，而是：
✅ 帮你把模型建出来 ✅ 把数据提出来 ✅ 把图画出来 ✅ 把计算书和报告整理出来
AI 的关键变化：从”知识问答工具” → “工程执行工具”
🧠 一、认识 Codex：能执行的 AI
1.1 对话模型 vs Agent：区别在哪？
提到 AI，很多人脑海里第一反应还是聊天窗口。豆包、DeepSeek、ChatGPT 这类对话模型能回答规范条文、力学概念、软件操作思路，但有一个明显边界：
❌ 它的输出被困在文本框里。
它可以告诉你”应该怎么做”，但默认情况下：
❌ 不会打开你的文件夹 ❌ 不会读取工程文件 ❌ 不会运行脚本 ❌ 不会帮你检查结果
而 Codex 这类终端原生 Agent 的意义就在于：
✅ 读取本地项目文件 ✅ 编写并运行脚本 ✅ 调用命令行工具 ✅ 自动排查报错 ✅ 修改工程数据 ✅ 验证结果是否符合要求
当 AI 能够触碰真实文件、调用真实软件、完成真实操作时，它就不再只是”问答助手”，而是一个不知疲倦的数字工程师。
1.2 两种使用方式
Codex 有 App 端（可视化工作台，适合入门）和 CLI 终端（与脚本和自动化流程结合更紧密）两种入口，功能本质一致。
⚙️ 二、Agent 的工作机制
2.1 先看一个实际案例：批量处理图纸
为了让大家直观感受 Agent 的能力，我准备了一个非常日常的案例：
📋 任务：批量修改图纸名字，并压缩打包。
这个任务看起来不复杂，但非常典型。因为它同时包含了几个工程师每天都会遇到的动作：
进入指定文件夹 批量识别 PDF 文件 删除文件名前缀 打包成 ZIP 自动检查结果 对演示视频做 4 倍速处理 再次验收输出文件
这种事情如果手动做，并不难，但非常消耗注意力。文件一多，还容易改错。而 Agent 的优势就是：你把规则讲清楚，它就可以不厌其烦地执行，并且在最后给你一个验收结果。
💡 关键启示：Agent 最先改变的，不一定是最复杂的创造性工作，而是那些重复、机械、容易出错、但又必须做对的工作。
2.2 可复用的 Skills：把经验固化下来
如果一个动作只做一次，那它只是一次自动化。如果一个动作经常重复，就应该把它固化成可复用能力。在 Codex 里，这类能力可以整理成 Skill，你可以把它理解为 AI 的”工作说明书”。
SKILL.md 通常会包含：Use When | |
Workflow | |
Defaults | |
Commands |
比如”视频 4 倍速处理”这个功能，一开始可以只是一次临时操作。但当你经常需要处理演示视频时，就可以把它封装成一个 Skill。
下次只需要说：
调用 Video Speedup Skill，帮我把这个视频 4 倍速处理。
Agent 就会自动找到对应的工作流，而不是每次都让你重新解释一遍。
这就是 Agent 和普通脚本最大的区别之一：
❌ 普通脚本只会执行固定命令 ✅ Agent 可以理解你的目标，再选择合适的工具和流程
🏗️ 三、结构设计软件应用
3.1 驱动工程软件的底层逻辑
如果把这个过程抽象成一句话，就是：
- Codex 负责理解目标、规划步骤、生成代码和检查结果
- API 接口 负责把这些指令翻译成软件能执行的动作
- 工程软件 负责真正建模、分析、出图和导出结果
目前很多主流结构软件都具备被自动化调用的能力：
🎯 Codex 可操作的软件生态全景：
其中，Dlubal、Midas 这类软件还具备网页端或网络接口能力。这意味着在合适的网络配置下，本地 Agent 不一定只能控制本机软件，也有机会控制局域网中其他电脑上的分析软件。
再往前想一步： 甚至可以通过手机语音下达指令，让 Agent 去远程驱动某台机器完成建模和计算。这不是科幻，它只是把已有的 API、网络接口和大模型 Agent 串了起来。
3.2 SAP2000 应用：从建模到后处理的全流程
3.2.1 正确性保障：PySap2000 封装库
如果说 Agent 是大脑，软件 API 是肌肉，那中间还需要一个”中枢神经系统”。
SAP2000 的 API 文档很复杂，接口数量多、参数多、调用顺序也容易出错。让 AI 直接面对完整 API 文档，并不是一个高效的做法：
❌ 容易浪费上下文窗口 ❌ 容易调用错函数 ❌ 容易把工程意图翻译成错误参数 ❌ 也不利于后续复用
所以我专门开发了 PySap2000 库。你可以把它理解为给 AI 定制的”傻瓜式遥控器”：复杂的 SAP2000 API 被封装成更清晰、更符合工程语义的函数。Agent 不需要每次都从底层 API 开始理解，只需要调用更稳定的接口。
目前 PySap2000 已经开源在 GitHub，并收获了 100+ Stars。
GitHub 地址：https://github.com/HeisenbergJY1/PySap2000
💡 关键启示：真正适合工程场景的 AI，不是让大模型硬啃所有底层细节，而是把工程师的经验封装成稳定的接口和工具。
3.2.2 案例一：钢框架自动建模
第一个演示是钢框架自动建模。你可以直接用自然语言描述结构信息，Agent 根据描述生成建模脚本，调用 SAP2000 完成建模，并在过程中不断检查是否执行成功。prompt：安装pysap2000库，然后利用这个库，连接打开的SAP2000模型，创建一个10层的钢框架结构，AI完全自己理解10层框架结构，无额外的任何约束。
这个场景的意义不只是”自动生成一个模型”，而是：
✅ 把很多原来需要人工点击、输入、检查的步骤，变成一个可以复用、可以修改、可以追踪的脚本流程。以后如果参数变化，比如跨度、层高、截面、荷载发生调整，就不需要从头点一遍界面，而是让 Agent 修改脚本并重新运行。
3.2.3 案例二：单层球面网壳建模
第二个演示是单层球面网壳建模，这里用到一个 shell_templates.py 专门描述网壳几何。关键参数主要有三个：f 控制网壳的矢高，kn 决定环向的等分数，nx 决定径向的等分数。
prompt：连接现在打开的SAP2000模型，创建一个kiewitt_shell的模型
📝 两种实现路径： 1️⃣ 会编程的人：可以直接用代码描述几何逻辑 2️⃣ 不会编程也没关系：把相关论文截图、节点布置示意图、参数说明发给 AI，让它帮你写脚本
相比传统 Grasshopper 参数化的优势：
相比传统 Grasshopper，Agent 方式不需要记忆大量电池、不用担心插件兼容性、也不存在复杂连线难以维护的问题——你直接描述工程意图，生成的脚本可以保存复用，参数变化时随时迭代。对结构工程师来说，这是一种更接近工程语言的参数化方式。
3.2.4 案例三：后处理与截面优化
建模只是第一步。结构软件真正耗时间的地方，往往还包括后处理。
典型后处理任务：
📊 提取某个节点在指定工况下的位移 📈 提取多个节点的位移包络 📋 批量整理杆件内力 🎨 绘制柱状图、折线图、包络图 🧬 调用遗传算法做截面优化 📄 把结果整理成报告或 PPT 可用的图表
这些工作本质上都非常适合 Agent。
示例指令： Agent 会去写脚本、调接口、读结果、画图，最后把图表保存下来。💡 这一类工作特别值得做成 Skill，因为它高度重复，而且验收标准通常比较明确。
3.2.5 案例四：SAP2000 AI 智能助手
除了在终端里直接操作，还可以针对 SAP2000 做一个对话式 Web 助手。
打开网页之后，你可以像聊天一样询问：
💬 当前模型有哪些基本信息？ 💬 总用钢量是多少？ 💬 某个工况下节点位移是多少？ 💬 某组构件的内力结果如何？
💡 关键判断：对话界面只是入口，背后真正有价值的是工程软件 API、数据结构和稳定工作流。
3.3 Rhino 应用：让 AI 接管重复建模劳动
Rhino 是结构工程师和空间结构设计里非常常用的软件。很多重复性建模工作如果完全靠手动操作会非常消耗时间，用 Grasshopper 虽然能参数化，但也会遇到电池组复杂、逻辑难维护、调试成本高的问题。
Agent 结合 RhinoPython，提供了另一条路线：
你用自然语言描述目标 Agent 生成 RhinoPython 脚本 Rhino 执行脚本生成模型 你根据结果继续反馈修改
你不一定要先成为熟练程序员，也不一定要搭建复杂的 Grasshopper 电池组，只需要把工程目标说清楚：
✅ 要生成什么几何 ✅ 哪些参数可调 ✅ 输出对象如何分组 ✅ 需要什么图层、颜色、命名规则 ✅ 后续是否要导入 SAP2000 或其他软件
这些信息越清楚，Agent 生成的脚本就越接近可用状态。
3.4 SpanCoreLink 插件：AI 辅助开发工程工具
在空间结构项目中，Rhino 和 SAP2000 之间互导模型是一个非常高频的需求。但 SAP2000 原生导出 DXF 的能力往往无法满足日常工程使用——对象分类不清楚、截面信息丢失、材料信息难以对应、后续整理成本很高。于是我自己规划功能，借助 AI 完成了 SpanCoreLink 插件开发。
主要功能：
开发周期：约 2 天 | 已登记软件著作权
这件事对我触动很大。以前做一个工程插件，往往意味着你要花大量时间学习插件开发框架、调试接口、处理各种边界问题。现在有了 Agent，结构工程师可以更多地把精力放在”我要解决什么工程问题”上，而不是被底层代码细节卡住。
3.5 CAD 应用：把琐碎操作交给 Agent
CAD 场景同样适合 Agent。原因很简单：CAD 里有大量重复、规则明确、但人工操作很烦的任务。AI可能不能一次性生成想要的结果，可以多轮对话进行调整Prompt： 帮我吧SAP2000的节点坐标，生成表格，写入打开的CAD，字体和表格宽度高度不匹配
典型应用场景：
📁 批量整理图层 ✏️ 批量修改文字 🔲 批量处理块参照 📏 自动标注或统计 📤 按规则导出图纸 ✅ 对图纸文件做批量检查
这些事情不一定技术含量最高，但非常消耗工程师的注意力。Agent 的价值，就是把这些”规则清楚但执行繁琐”的工作接过去，让工程师把时间留给更重要的判断。
🤖 四、结构设计智能体实践
4.1 StructureClaw：自然语言操作结构设计软件
StructureClaw 是清华大学陆新征老师课题组发起的开源项目。它的目标很直接：
让结构设计变得像和 AI 聊天一样自然。
我本人也是社区贡献者，这类项目非常需要更多结构工程师参与。 因为真正懂工程逻辑的人，最清楚哪些流程值得自动化，哪些判断必须由工程师把关。
4.2 自然语言操作 YJK
下面这个演示，是作者通过StructureClaw通过自然语言操作 YJK 的实战流程。
这类工作如果继续发展下去，结构设计软件的交互方式会发生很大变化。
过去 vs 未来：
这并不意味着工程师可以不懂结构。 恰恰相反，软件操作门槛降低之后，结构判断会变得更重要。当建模和计算都变快以后，真正拉开差距的，是：
✅ 你能不能提出正确的问题 ✅ 你能不能识别错误结果 ✅ 你能不能设计出更合理的结构体系
🚀 五、Vibe Coding 与未来
5.1 什么是 Vibe Coding？
最近几年，Vibe Coding 这个词被频繁提起。我的理解是：
Vibe Coding 最大的意义，是把工程师从代码的泥沼中解放出来，回到工程问题本身。
你需要负责的是：
📋 明确需求 🎯 定义输入输出 🔍 判断工程逻辑是否正确 ✅ 检查结果是否满足规范和经验 🔄 决定下一步如何迭代
代码没有消失，只是从工程师的第一注意力中退到了后台。
5.2 工程工具产品化
Vibe Coding 对结构工程师最直接的启发，是可以把很多日常工具产品化。
比如销轴耳板设计，过去可能是一个 Excel 表，大家在表格里改参数、查结果、截图汇报。
但现在完全可以把它做成一个网页工具：
工具一旦网页化，就会带来几个变化：
结构工程师缺的往往不是想法，而是把想法变成产品的技术门槛。Agent 正在降低这个门槛。
🎯 六、结语：结构工程师的能力正在重构
人工智能体辅助结构设计，真正改变的不是我们会不会写代码，而是我们能不能把更多精力重新放回 工程判断、设计逻辑和创造价值 本身。我认为未来可以这样分工：
交给 Agent 的事：
🔄 重复调试模型 📊 批量处理数据 📈 绘制图表 📝 整理 PPT 和超限报告 📄 处理计算书、图纸和文件 🔍 提取并比对海量有限元分析结果
交给结构工程师的事：
🏗️ 判断结构体系是否合理 ⚡ 提高结构受力效率 🎨 把节点设计得更精美、更可靠 🎯 高效解决真实工程挑战 🛡️ 把控结构安全底线 🤝 推动多专业协同
未来，结构工程师不只是会算、会画，更要会定义问题、组织流程、驾驭智能体。
AI 不会自动让一个人变成优秀工程师，但它会让真正懂工程、懂流程、懂判断的人，拥有更强的放大器。
💡 如果这篇文章对你有启发，欢迎收藏、转发给同样关注结构设计与 AI 的朋友。后续我也会继续分享 Codex、StructureClaw、SAP2000 自动化和工程工具产品化相关内容。如需要 PPT源文件，请访问 https://www.spancore.cn下载。
