AI Agent 也能写工程计算书？用 Codex 自动生成简支梁计算文档全流程

前两天同事拿来一份简支梁的计算书需求荷载、配筋、挠度、参数表一大堆领导还要Word版。我随口说了句“让Codex干呗”同事一脸懵Codex不是写代码的吗我当场给他演示了一遍十几分钟一份带公式、带参数表、带验算过程的工程计算文档就完整生成了。他看完之后只有一个问题这玩意儿还能干这个这篇文章我就围绕这个场景展开聊聊Codex除了写代码之外怎么直接生成工程计算文档。内容包括它的工作方式、完整的实操路径、一份简支梁计算书的复盘过程以及我踩过的坑和报错排查记录。适合结构工程师、设备工程师、科研人员和所有经常跟“计算文档”打交道的人参考。不需要你懂多深的编程会装软件、会描述需求就够了。1. 先说清楚Codex 到底是个什么东西想用好一个工具先得搞清楚它的运行逻辑。很多人把Codex当成一个“加强版代码补全”这是最大的误解。它会自己读文件、执行命令、调用工具、反复试错本质上是一个能独立干活的Agent。这个底层区别决定了它能做的远不止写代码。1.1 它不是自动补全是一个能自己干活的 Agent传统AI编程助手的工作方式是你写一半它补一半本质上还是“人在回路里”。Codex不太一样你给它一个目标它会自己拆解任务先分析你现在有什么文件、缺什么依赖、用什么方案最稳妥然后动手写代码、跑命令、看报错、改代码直到把任务完成。这里面的关键是它具备“工具调用”能力。Codex可以通过CLI或桌面版调用本地的Python环境、Shell命令、文件系统甚至可以挂载自定义的MCP工具去连接更多外部服务。这就意味着它不只会“生成文本”还能“对真实世界产生作用”。你要一份工程计算文档它不只是口头上给你编一段漂亮的文字而是真的会去写一个Python脚本、用数值方法算出来、再把计算结果填进文档里。这种工作方式的工程意义是很明显的计算类文档最怕的就是“公式写得很漂亮但里面的数字是拍脑袋拍的”。Codex作为Agent能把“计算”这个动作本身纳入生成流程而不是单纯模仿文档格式。1.2 工程计算文档为什么是它的“隐藏天赋区”工程计算文档有个特点它是“结构化叙述 数值计算 规范引用”的混合体。常见的有几种结构设计计算书梁、柱、基础、钢结构的承载力验算设备选型计算书泵的扬程、管道的阻力、电机的功率工艺参数计算换热面积、反应时间、物料平衡科研数据报告试验数据回归、误差分析、模型拟合。这类文档在传统工作流里非常耗时主要不是因为计算有多难而是要把计算过程、公式、假设、引用规范、参数来源一点点写清楚格式还要统一数字还不能出错。这一步在过去只能靠人工因为没有一个工具能把“数值计算”和“文档排版”打通。Codex恰好能把这两件事一起做掉。它能用Sympy做符号推导用NumPy做数值计算再把结果组织成带LaTeX公式的Markdown文档。只要你会提需求它就能把“算”和“写”合并成一条流水线。2. 用 Codex 生成工程计算文档的完整路径在讲具体提示词之前先把整条路径捋清楚。我试过几次之后发现最顺的流程不是一上来就让Codex直接写文档而是按“环境准备 → 需求描述 → 先算后写”这三个阶段走。2.1 安装与运行环境先花 10 分钟把地基打稳先说安装。Codex目前主流的用法有两种一种是命令行CLI一种是桌面客户端。CLI安装很简单电脑上要有Node.js环境然后用npm全局安装。装完之后要确保codex命令能被找到否则后面会报一个“unable to locate the codex cli binary”的错误。这个问题我在第5部分会详细说。桌面版就是图形界面操作适合不习惯命令行的人本质还是同一个内核。运行的时候需要用到AI模型服务。Codex官方版本默认对接OpenAI的模型但它也支持通过环境变量指向任何兼容OpenAI接口协议的服务。这里我用的是兼容接口方式具体来说需要配置几个环境变量export OPENAI_API_KEY你的密钥 export OPENAI_BASE_URL你的API服务地址如果你用的是ChatGPT账号直接登录官方桌面版那模型选择会被限定在订阅档支持的范围内如果你配置了第三方兼容API服务就可以切换很多模型。这两种方式的正规官网文档里都有说明不展开。我要提醒的一点是无论用哪种接入方式都要保证网络环境能正常访问目标服务这是后面一切操作的前提。2.2 把“计算书需求”翻译成 Codex 能执行的指令很多人用Codex生成文档失败问题不在Codex在需求描述。工程计算文档涉及大量隐含信息比如“按什么规范取值”“荷载是标准值还是设计值”“挠度验算用哪个组合”“结果保留几位小数”这些你不说AI就会自己猜而它一旦猜错后续全是坑。我的经验是提示词至少包含以下要素结构对象和几何尺寸材料和荷载条件要计算哪些项目按什么顺序采用哪本规范、哪个版本输出的文档格式和章节结构是否要求同时生成计算脚本。你别怕提示词写得长Codex的上下文处理能力很强。越明确它返回的结果越接近你想要的“可直接上报”的水平。2.3 先算数、后写文档顺序不要反这是我用了很多次Codex之后最深刻的一条体会。如果一开始就让Codex“直接生成计算书”它会倾向于模仿计算书的文本格式然后给你填一些看似合理但未必经过验证的数字。正确做法是分两步第一步让它写一个计算脚本把所有的输入参数、公式、结果输出到终端或者一个JSON文件里然后你必须让它自己运行一遍看到真实输出。第二步再让它根据脚本运行的真实结果去生成文档。这样做的本质是把“计算”和“写作”解耦先保证数值的可靠性再让AI组织叙述。Codex作为Agent的好处是这两步可以在同一次对话里连续完成你不需要手动切换工具。你只需要在提示词里写清楚“先写脚本并运行再根据运行结果生成文档”它就会按这个顺序执行。3. 实操复盘简支梁计算书是怎么被 Codex 塞进 Markdown 的空谈原理没有用我拿前几天做的一个简支梁计算书作为完整例子把整个复现过程拆开给你看。涉及的结构计算本身不复杂但足够说明Codex的完整工作流。3.1 我给 Codex 的提示词我用的项目背景是这样的一根简支梁跨度6米截面尺寸250×500毫米C30混凝土HRB400钢筋永久荷载标准值20千牛每米含梁自重可变荷载标准值12千牛每米。要求出计算书包含荷载组合、内力计算、正截面承载力验算、配筋、挠度验算。我给Codex的提示词大致是这样的请帮我完成一根简支梁的设计计算并生成计算书。 工程条件 - 计算跨度 L 6000 mm - 截面尺寸 b × h 250 × 500 mm矩形截面 - 混凝土 C30fc 14.3 N/mm2 - 钢筋 HRB400fy 360 N/mm2 - 永久荷载标准值 gk 20 kN/m含自重 - 可变荷载标准值 qk 12 kN/m - 环境类别为一类保护层厚度按规范取用 要求 1. 先写一个 Python 计算脚本用 Sympy 或手写公式完成以下计算 荷载设计值按可变荷载控制的组合、支座反力、跨中弯矩设计值 正截面受弯承载力验算、所需纵向钢筋面积并给出配筋建议 跨中挠度计算按荷载标准组合并验算是否满足限值 L/250。 2. 脚本必须实际运行并把关键中间结果打印出来。 3. 运行无误后根据脚本输出生成一份 Markdown 计算书 包含工程概况、计算依据、荷载计算、内力计算、正截面承载力验算、 配筋结果、挠度验算、结论。 4. 所有公式用 LaTeX 语法参数表放在对应章节开头单位必须写清楚。 5. 计算书里出现的每个数值都必须来自脚本的实际运行结果不允许手工填写。 请一步一步来先写脚本运行确认无误后再生成文档。这里有几个细节我特意处理过我直接给了材料强度设计值避免Codex去查规范时出错我要求“先写脚本再写文档”强制它走Agent的计算流程我点出“按可变荷载控制”这是荷载组合里最容易含糊的地方。3.2 Codex 自己写的计算脚本和中间检查Codex收到提示词之后首先是思考拆解任务然后就在项目目录里创建了一个Python脚本。它自己写的脚本结构大概是这样的import math # 输入参数 L 6000.0 # mm b 250.0 # mm h 500.0 # mm fc 14.3 # N/mm2 fy 360.0 # N/mm2 gk 20.0 # kN/m qk 12.0 # kN/m # 荷载设计值由可变荷载控制 q 1.3 * gk 1.5 * qk # 支座反力 R q * L / 2000 # 除以1000得到kN再考虑单位换算 # 跨中弯矩设计值kN·m M q * L**2 / 8 / 1000 # 有效高度as 按一类环境 C30 取 40mm as_ 40.0 h0 h - as_ # 正截面承载力计算 alpha_s M * 1e6 / (1.0 * fc * b * h0**2) xi 1 - math.sqrt(1 - 2 * alpha_s) x xi * h0 As 1.0 * fc * b * x / fy # 挠度计算按荷载标准组合 qk_sum q_std gk qk E 3.0e4 # N/mm2 I b * h**3 / 12 # mm4 f 5 * q_std * L**4 / (384 * E * I) print(f设计荷载 q {q:.2f} kN/m) print(f支座反力 R {R:.2f} kN) print(f跨中弯矩 M {M:.2f} kN·m) print(fAs {As:.1f} mm2) print(f挠度 f {f:.2f} mm)它运行完之后终端输出了一串结果设计荷载44千牛每米支座反力132千牛跨中弯矩198千牛·米计算配筋面积约1415平方毫米挠度约6.9毫米。这些数值我后面都仔细验算过是正确的。这里我特别观察了一下Codex的一个好习惯它自己在注释里写了“as按一类环境C30取40mm”这是规范里的常用做法。它还会主动区分荷载设计值和标准组合挠度验算用的是标准组合32千牛每米而不是设计值44千牛每米。这个区分如果不做挠度结果会偏大很多导致误判。这一点让我比较放心。3.3 输出文档长什么样质量怎么把关脚本运行结果确认之后Codex才开始生成Markdown计算书。它的文档组织得非常清晰工程概况一根简支梁跨度6米截面尺寸、材料等级计算依据列出相应规范与条文荷载计算标准值、组合系数、设计值内力计算支座反力、剪力和跨中弯矩正截面承载力验算公式、代入数值、求出受压区高度验算是否超筋配筋结果计算需要1415平方毫米选配4根直径22的钢筋实配1520平方毫米满足要求挠度验算标准组合挠度6.9毫米限值24毫米满足结论整体安全。文档里的公式都是用LaTeX写的比如跨中弯矩公式$$M \frac{q l^2}{8} \frac{44 \times 6000^2}{8 \times 1000} 198 \, \mathrm{kN \cdot m}$$参数表用的是Markdown表格单位全部带上了。生成之后我只需要做一件事把Markdown转成Word或PDF交付给同事。整个耗时大约十五分钟其中大部分时间还是我在检查中间结果。4. 工程计算文档落地的四条关键经验演示看着顺利但实际操作中我也踩了不少坑。下面这四条经验是我反复试错之后沉淀下来的每条都是用一次次的返工换来的。4.1 设计值和标准值不能混着用这是工程计算里最基础也最容易出错的点。荷载设计值用于承载力极限状态验算荷载标准值用于正常使用极限状态验算比如挠度、裂缝。Codex如果没有被明确告知它很容易在算挠度时也顺手用设计值44千牛每米导致挠度结果虚高。我后来在提示词里会明确加一句“挠度计算必须采用荷载标准组合”并且要求它在脚本里用不同的变量名区分设计值和标准值。这样既能防止它混淆也方便我最后核查。你自己用的时候建议把这类“容易混淆的工程概念”在提示词里单独拎出来强调不要指望AI自动理解。4.2 数字一致性要靠脚本来保证所谓数字一致性就是文档里出现的每一个数值都能在计算脚本的输出里找到出处。没有脚本支撑的AI计算书本质上和“编故事”没有区别。Codex很强的一点是它能自己生成脚本并运行但你得在提示词里强制这个动作否则它会走捷径直接根据训练经验把常见数值填进去。我检查文档时有一个习惯随机抽两三个结果手动带入公式验算一遍。比如跨中弯矩198千牛·米我手动算一遍是44乘36再除以8等于198没问题。这个习惯推荐你也保留不管AI多强最终的计算书签字责任永远在工程师本人。4.3 单位和规范引用是重灾区Codex在单位换算上偶尔会翻车尤其是涉及“千牛·米”和“牛·毫米”的换算一个数量级就是10的6次方。我一般要求它“所有公式用国际单位制最终输出保持工程常用单位”并在计算脚本里显式写出换算系数。这样即使出问题也能在脚本里一眼定位。规范引用也要小心。我在3.1的例子里直接给了材料强度设计值就是为了避免Codex凭记忆去查规范导致引用过时或错误。如果项目需要它自己查规范取值一定要让它备注引用来源和版本你再去人工核对对应条文。4.4 格式流转从 Markdown 到 PDF/WordCodex默认输出Markdown但工程上交付通常要Word或PDF。我的做法是让Codex在Markdown里用标准LaTeX公式语法然后用pandoc之类的转换工具转为docx。Codex对这个流程很熟悉你甚至可以要求它直接帮你写转换命令。有一个小技巧是让Codex在Markdown开头加一个简单的YAML头部声明标题、作者、日期。这样转Word时标题样式会自动映射格式不需要手动调。这个细节对经常出正式计算书的人非常实用。5. 常见报错与排查速查表用了这么久Codex相关的报错我基本都遇到过一轮。下面这些是从我自己的实操和同行反馈里整理出来的高频问题直接对照解决。5.1 模型/账号权限类这类报错最常见的就是提示模型不支持比如在配置了某个新模型之后运行时报the gpt-5.6-sol model is not supported when using codex with a chatgpt account这个问题的本质是登录方式与模型权限不匹配。用ChatGPT账号登录时模型范围受订阅档限制如果你要使用自定义的、权限之外的模型通常需要切换为API密钥方式接入而不是用账号登录。排查顺序是先确认登录方式再确认模型名是否在当前接入渠道的允许列表里。同类问题还包括API返回的detail提示比如响应里直接给出JSON格式的错误详情说某个模型不被支持。这种情况多半是配置里模型名写错了或者接入服务不支持该模型去配置文件中改模型名即可。5.2 第三方 API 配置类如果你把Codex接到第三方兼容API服务或使用本地配置切换工具可能会遇到这样一个报错cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这个报错看起来很长核心信息其实就一句上游API要求“thinking mode”下的reasoning_content字段必须原样回传但本地转发配置没有做这一步导致上游返回400。这个问题的根源在于很多新模型开启了深度思考模式API会在响应里多返回一个reasoning_content字段。当你把这个响应作为上下文再发给API时必须把之前的reasoning_content字段一并带上否则就报错。排查和解决方向有两个一是去配置里关闭thinking模式二是升级/修改本地转发配置让它能自动回传reasoning_content字段。这类配置错误的修复重点是找到“转发层”对字段的处理策略而不是改Codex本身的设置。5.3 客户端连接与安装类还有两类报错也经常出现。一个是“codex正在重新连接”对应的错误信息可能是codex connection failed: error sending request这种情况多半是网络连接中断或者本地某个服务端口占用异常。排查思路是先确认网络能正常访问目标API服务再检查本地是否有占用了默认端口的进程必要时重启Codex客户端。另一个安装类的报错是unable to locate the codex cli binary这个问题基本出现在Windows环境下原因通常是npm全局安装目录没有加入系统PATH或者安装过程没有刷新环境变量。解决方法是找到codex命令的实际安装路径手动把路径加入PATH环境变量然后重新打开终端。如果是新版CLI有时候还需要确认Node.js的版本是否满足要求版本过旧可能导致二进制安装不完整。我把这几个高频问题整理成一个速查表方便你直接对照报错特征可能原因排查思路“model is not supported when using codex with a chatgpt account”登录方式与模型权限不匹配确认登录方式切换API密钥接入或换模型“reasoning_content must be passed back”thinking模式的字段未回传关闭thinking模式或升级转发配置“error sending request”网络连接异常检查网络连通性和本地端口占用“unable to locate the codex cli binary”安装目录未加入PATH手动添加PATH并刷新终端“the ... model is not supported”模型名配置错误检查配置中的模型名是否准确6. 最后想说的几句实在话我个人在实际项目中的体会是Codex生成工程计算文档这件事真正的价值不在于“AI会计算”而在于它把“计算工具”和“写作工具”之间那条巨大的鸿沟填上了。以前做个计算书得先在Excel或Mathcad里算出结果再手动誊到Word里中间只要誊错一位小数整份文档的公信力就没了。现在Codex直接从脚本运行结果里取数数字一致性天生就有保障我只需要做最后一道人工审核。当然边界也很明确。Codex不是注册结构工程师它不会为你的计算书负责规范版本可能记错特殊工况可能考虑不全。我的原则是它负责把80%的重复性劳动干掉我负责那20%的判断和兜底。正截面配筋算出来1415平方毫米够不够、要不要放大这些属于工程判断AI只能给参考签字还得靠自己。如果你也经常被计算书、技术报告这类文档折磨不妨试着把下一个任务交给Codex跑一遍。别一次性让它写完所有内容先让它算数再让它写文档最后你自己把关。试过一次你就知道这玩意儿是真的能顶一个人用。