AI 10倍速CAE二次开发2:AI时代的工作流
我在AI 10倍速CAE二次开发1:找到脆弱点,10倍速才有可能里面提到了AI时代之前限制二次开发效率的3个主要问题,这篇文章重点聊聊其中的“开发进度慢”,以及AI时代如何破局。
传统 CAE 二次开发的速度瓶颈
在AI编程能力爆发之前,我是这样做二次开发的:在日常仿真工作中,把一些重复流程收集起来。然后,看看整个过程中需要用到哪些命令。HyperMesh 有一个对二次开发非常有用的功能,它可以记录你的每一步操作,并且是用命令的形式记录的。接下来,去官方 API 文档里面查找这些命令,了解它的详细用法。最后就可以开始写代码了。
当然,这时的代码只是初版,还需要在HyperMesh中实际测试,看看能不能顺利运行,有没有bug,效果怎么样。根据这些反馈再做修改。
这里面的每个步骤都需要人亲力亲为,其中查文档和反复测试修改最耗时间,而做二次开发的人大多是兼职,时间少,这成为了开发速度的最大瓶颈。
所幸,现在这套流程中的很多步骤,都可以用AI来实现了。
AI时代的二次开发新工作流
1. 收集需求
开发要有需求,需求决定了开发速度的上限。之前我的需求来源首先是自己,其次是同事。自己有需求,可以随时记下来。但是同事向我提需求的时候,可能我人刚好不在,这事就耽搁了。
现在,我在cnb(代码托管平台,相当于国内的GitHub)上开了一个仓库,不管是我自己的,还是同事的需求,都统一记录在仓库的issue里。好处是可以线上协作。AI可以定时自动获取cnb上的需求,然后自己写代码,不需要人操作。
2. 准备工具
AI写代码也有不同的方式。最早出现、也最普及的方式是在网页端和 AI 对话,代码写在对话框里;它很难从 cnb 这类第三方平台获取需求,代码也要人复制粘贴到本地文件。
它的问题在于,网页端的AI很难从cnb这样的第三方平台上获取需求,还是需要人工把需求复制粘贴到对话框中。而且,代码要在HyperMesh中运行,还需要人复制、粘贴到本地文件。
另一种方式是桌面端。它能够获取cnb上的需求,也能直接在本地写代码,省去了很多操作。
但是,它也存在问题。毕竟它不是代码编辑器,很多细节没做到位。比如,在桌面端中打开的代码文件,往往只能 AI 改,人没法编辑。而且,一些小众语言,比如tcl,往往没有语法高亮功能,可读性差。
用代码编辑器看代码是什么效果?以我曾经最喜欢用的代码编辑器Sublime text为例,它具有语法高亮、自动检查语法和代码格式化功能。即使是代码,看上去也没有那么枯燥了。
AI可以写代码,代码编辑器方便查看、检查代码,能不能把它们的优点结合起来呢?还真可以。
我现在使用的工具链是这样的:代码编辑器 zed、编程智能体 Claude Code,以及把国产模型接入 Claude Code 的 42cc。
zed 是AI时代的代码编辑器,它简洁、优雅、还具有AI功能。比如,它内置终端,能够在终端中运行 Claude Code。Claude Code 是一个编程智能体,它负责编写代码。但是,Claude Code 的原生模型 Claude 在国内很难使用,而且价格也很贵。替代方案是用42cc把国产模型接入到 Claude Code 中。
如果你用的是 Python API,zed 内置的语法高亮、代码检查等工具可以直接用,不需要做额外设置。
如果使用 Tcl API,需要安装 Tcl 扩展。按下 Cmd+Shift+P 打开命令面板,输入 zed: extensions,回车;或者直接按 Cmd+Shift+X 打开扩展面板。在搜索框里输入 tcl,找到 TCL Language,点 Install 安装。
它的主要功能是语法高亮。除此之外,还有自动缩进、括号匹配和大纲等功能。
下图左边是在桌面端查看 Tcl 代码的效果,右边则是 zed 的效果。关键字、字符串、注释分色,结构一眼能看出层次。比读一大段黑白文字轻松得多。
3. 查找命令
前文提到 HyperMesh 可以记录你每一步操作对应的命令,这个功能对编写脚本很有帮助。而查找命令的部分,则可以交给 Claude Code 来做。
具体流程是这样的,人先在 HyperMesh 中操作一遍,把命令记录发给 Claude Code。然后,让 Claude Code 去官方 API 文档中查找这些命令,熟悉它们的语法和用法。
不用每次都联网查,可以像我一样,事先让 Claude Code 把官方 API 文档全部下载下来,甚至翻译成中文(主要是为了方便自己看),放在本地。需要用的时候,Claude Code 直接在本地查。
记得把这些步骤沉淀成 Claude Code 的一个技能,让它调用技能自动完成整个流程。
4. 编写脚本
前面都是准备工作,终于来到编写脚本这场重头戏了。这一步最大的难题是,AI在写代码时会出现幻觉。特别是 API 接口这种小众命令,训练语料少,更容易出错。比如瞎编一些不存在的命令,或者少写了几个参数。
怎么解决这个问题呢?其实我们在上一步就已经开始准备了,让 Claude Code 事先学习了官方 API 文档,知道有哪些命令,应该怎么用。
除此之外,我们还可以从高质量的二次开发脚本中,提取出常见命令及其用法,把它们作为参考资料,喂给 Claude Code,这样做能大大减小代码出错的概率。
编写脚本同样也要沉淀为技能,方便复用。
5. 测试脚本
在 HyperMesh 等CAE软件中测试脚本,成本太贵了。更好的方法是先让 AI 测试,修复大多数问题,然后才让人来测试。
开智学堂的阳志平老师提出代码的三层校验理论:规则层、判据层和实效层,最后一层最终要由人来定标,AI 不能替代。
规则层,通过测试工具、测试用例来测试。zed 也内置了 Python 测试工具;要测 tcl 脚本,得装 tclint。
tclint 有三个命令:tclint 检查代码,指出语法错误和格式问题,但不改代码。
tclfmt 用来格式化代码。在 zed 中配置好,保存文件时就会自动调用它排版。
tclsp 是给编辑器用的后台程序,把问题直接标在代码行上。Zed 现在没有扩展把它接进来,暂时用不上。
判据层,就是把判断脚本对错、好坏的依据写进技能里。让 Claude Code 检查脚本中的 API 接口是否真的来自官方文档,用法是否正确。
实效层,最终让人来测试脚本。这是最贵的,也是 AI 不能替代的。
好在现在前两层都能交给 AI,只有最后一层留给自己,检查代码的成本大大降低。用阳志平老师的话说,就是“降低确认成本”。
小结
借助 AI,二次开发从收集需求到测试修复的每一步都能交给工具链推进,人只在最后把关。Claude Code 可以从 cnb 上获取开发需求,参考命令记录文档和高质量脚本,在 Zed 中编写代码。然后自己调用 tclint 和判据来测试、修复脚本。最后,才交棒给人,由人来做最终测试。










评论0