软件开发手记

周末看着清零的Codex周额度恢复了，还给了次重置，又能嗨起来了。

想着之前用钢构CAD挺好的，现在AI都那么高级了，是不是也能自己写一个类似的软件。说干就干。和ChatGPT 还有Gemini讨论了下，确实可行。于是直接把钢构cad软件包丢给Codex，说明我想要做一个常用管件的展开插件，然后让他给我一个方案和框架。然后就是卡卡一顿消耗，很快就整出来了V0.1.0，然后，然后，然后就是各种奇怪图形输出，真的要经历99八十一难，终于，终于，在用量耗尽前，完成了v0.2.17版本，不是软件完成了，而只是弯头能生成三视图和展开图了。

两天开发的真实终点：不是“软件完成”，而是 0.2.17 的“弯头 OK”。

周末快结束时，我终于说出一句：“这个版本弯头没问题了。”

周末快结束时，我在浩辰 CAD 里重新加载 0.2.17，输入 BMZH，打开“任意弯头”，填参数、选插入点，看着三视图和整体展开图终于落在图面上。

我给出的确认只有一句：“这个版本弯头没问题了。”

这句话听起来不热烈，却是两天里最踏实的时刻。它并不代表软件完成了，只代表弯头这一项终于跨过“能画”到“能用”的门槛。插件里的三通、变径、方转圆、斜插管已经有基础输出，但还没有经过同样强度的实机确认，还有各种各样的问题。我不敢把一个阶段性基线写成“软件开发完成”。

两天里，最容易产生的错觉

打开 Codex 时，我也期待过一种很顺的过程：把功能、界面和输出要求讲清楚，AI 很快写出 AutoLISP 和 DCL，文件齐全，加载之后就能直接使用。

第一版确实来得很快。主菜单、参数窗口、弯头、三通、斜插管、变径、方转圆，都能迅速搭出骨架。AI 写代码的速度足够让人兴奋，也很容易让人误判：既然功能已经“出现”，是不是离完成只剩一点收尾？

真正耗时间的，是第一版之后。

从插件骨架到“弯头 OK”，中间不是一次生成，而是一连串可验证的小步。

版本号一路走到 0.2.17。开发速度变快了，但“写出第一版—实机试用—识别偏差—继续修改”的循环没有消失。Codex 缩短的是每次改代码的时间，并没有替我省掉判断、沟通和验收。

报错只是最直白的失败

最早拦在面前的，并不是高深的几何算法，而是一个又一个很具体的运行问题：DCL 文件提示 near char(0XA)，语法解析报 cannot match any predicted input；LSP 与 DCL 版本不匹配；菜单出现 stringp T 或 nil；参数框能弹出，点击之后却闪退；插入点或对象结构稍有异常，又冒出 numberp:nil。

加载、版本、对话框——在真正画图之前，插件先要学会稳定地打开。

这些错误并不“高级”，却足以让整个插件停在入口。浩辰 CAD 对 DCL 编码、GBK/CRLF、系统变量、COM 接口、字体和命令状态都有自己的脾气。源码看起来正确，也不等于目标 CAD 会照着预期运行。

Codex 可以很快读错误、改代码、补静态检查，但前提是我必须在真实环境里加载、点击、截图，再把现象反馈回去。没有这一步，AI 看到的是源码；我面对的却是一个打不开、会闪退的程序。

更难的是：图出来了，却不能用

报错反而容易判断：它明确告诉你哪里失败。更消耗时间的，是图形已经生成，看上去也像那么回事，实际却不满足加工和出图要求。

三通输入 D=800，图里却没有正确表达 800 的主管；中文说明变成问号，标注文字太小；方转圆画出一堆交叉三角线，却不是可以下料的展开图；弯头两端方向不对，侧视和俯视轮廓缺失，内部线、中心线和可见线也混在一起。

早期图形“已经像软件输出”，但距离加工表达仍有明显差距。

最关键的一次纠偏，是明确虾米腰弯头每一节本质上仍是一段直圆管的斜截。圆柱面上的纵向母线在三维空间里必须是直线，不能为了“像弯头”就用弧线代替。最终的方案 D 还要求整体下料，并把纵向焊缝放在弯头两侧，而不是背部或内侧。

这些都不是语法问题。代码可以运行，图也可以很漂亮，但懂加工的人一眼就能看出：这个结果不能直接拿去用。似是而非，比报错更危险。

Codex 的强，体现在它能陪你反复重来

写得快。

从纯 AutoLISP + DCL 的插件骨架，到中文界面、原生 DIMENSION 标注、板厚和中性层参数、三视图与展开图，Codex 可以迅速把需求落成可执行代码。

改得快。

每一次截图反馈，都能很快转成下一轮修改：修 DCL 生命周期、恢复 FILEDIA/CMDDIA、统一字体和标注、重做母线求交、补齐可见轮廓、调整展开布局。很多过去需要查半天资料、手工试很多次的修改，现在可以在更短的循环里完成。

还能把沟通问题变成工具。

当弯头三视图的可见线、侧视和俯视表达反复说不清时，我们没有继续堆文字，而是做了一个 HTML 评审页，把候选方案、视图关系和可见线放在同一个浏览器画布里。

文字沟通卡住后，HTML 评审页把“各自理解”变成“共同看见”。

这一步很重要。我们不再争论一句话到底是什么意思，而是看着同一个图确认：哪条线应该出现，哪一半椭圆可见，哪种视图关系才对。AI 的价值不只在写最终代码，也在快速制造这种中间工具。

真正不能外包给 AI 的，是“什么叫对”

Codex 能根据说明生成一套看起来合理的几何，也能根据报错修掉语法。但“合理”不等于“符合现场”。弯头端口为什么要一水平一垂直，母线为什么必须是直线，焊缝为什么要放在两侧，尺寸为什么必须是 CAD 原生标注——这些验收口径来自设备、图纸和加工经验。

很多人把提示词理解成一句更长、更细的需求。真正有效的提示，往往不是多几个形容词，而是能给出可判断的边界：输入什么参数，应该出现什么实体；哪条线可见，哪条线隐藏；结果能不能下料；测试通过以后，还要由谁在什么环境里确认。

AI 可以把反馈执行得很快，但方向、取舍和最后的签字仍然要有人承担。它更像一个写代码很快、愿意不厌其烦重来的工程搭档；如果没有明确的验收口径，它也会非常高效地把错误继续做下去。

为什么两天后，我只敢说“勉强能用”

两天后的真实状态

0.2.17 已经不是一个只能演示的空壳。它可以通过 APPLOAD 加载，输入 BMZH 打开菜单，用参数框输入直径、角度、中心线半径和节数，再在图面指定插入点；弯头三视图、红色中心线、原生尺寸和方案 D 整体展开能够实际生成。隐藏回归测试也给出了 All sheet-metal geometry tests passed，实际试用确认“这个版本弯头没问题了”。

但我仍然只敢说“勉强能用”。因为可用性是逐项建立的：弯头过线，不代表三通、变径、方转圆和斜插管已经达到同样程度；测试脚本通过，也不代表每一种参数组合都能放心交给现场。

“勉强能用”不是贬低成果，是给软件划清边界：哪里已经验证，哪里仍然欠账。

两天真正完成的，不是一套成熟软件，而是一条被证明能走通的开发路径：先把目标表达画清楚，再落到 LSP 函数；先做静态和隐藏回归，再回到浩辰 CAD 实机；最后由使用者根据图纸和加工逻辑确认。这个基线不耀眼，却能让后续迭代不再从猜测开始。

如果你也在用 AI 做软件

先定义验收动作，不只描述功能

“做一个展开插件”太宽。更有效的说法是：输入哪些参数，点击哪个命令，图面必须生成哪些视图和尺寸，哪一种结果才算可下料。验收动作越具体，AI 的速度越能变成有效进度。

尽早进入真实环境

不要等代码“看起来完整”才加载。DCL 编码、字体、系统变量、COM 接口和命令状态，都只有在目标 CAD 里才会暴露。越晚实机，返工越大。

截图和对比图，常常比长篇解释更有效

把错误位置圈出来，把参考图和当前输出放在一起，把候选方案放进同一个评审页。可共同观察的对象，可以显著减少“我以为你说的是……”这类反复。

把“测试通过”和“现场可用”分开

回归测试能保证代码没有把已知逻辑弄坏，使用者确认才能判断结果是否符合现场。两者都要有，但不能互相代替。

开发没有变容易，只是试错成本下降了

这次周末开发让我对 AI 编程少了一点想象，多了一点信任。

少掉的想象是：写一句需求，软件就会自己完成。需求里没有说出的规则、目标软件的特殊行为、图纸里的行业习惯、使用者真正介意的细节，不会因为模型会写代码就自动消失。

增加的信任是：只要愿意把问题拆开、把反馈说清、把结果放进真实环境验证，Codex 能把很多过去迈不过去的技术门槛压低。它让我可以在一个周末里，从想法走到一个能够继续迭代的 0.2.17。

Codex 很厉害。没有它，对我而言，两天内走到这个节点很难。但它不是完成按钮。它能写代码、改代码、补测试，也能搭评审工具；真正决定软件能不能交到现场的，仍是对需求的理解、对图纸的判断、一次次重载验证，以及愿意把“差不多”继续改下去的耐心。

下一次再听到“用 AI 一天做一个软件”，我更想问一句：能让使用者放心？

好了，这段心路历程就给大家分享到这里，插件，还要等有时间继续折腾。有了AI，以前一直想做的很多事情都能搞起来，比如网站现在能用了，小程序也在备案中。其他的一些想法也都在构思和讨论明确。如果有喜欢折腾的朋友，欢迎加好友，一起沟通，分享各自踩过的坑。

关注与资料交流公众号：环保除尘知识｜微信号：hbcc_6_6_6｜邮箱：hbcc666@vip.qq.com｜QQ群：537578245。群内有部分规范文件、设计手册、图册、图纸和方案资料可供交流学习。