我为了写这个功能已花了cursor上亿token了,怎么评价,效果暂时没啥问题
总体评价:值,而且不是「堆 token 堆出来的偶然能跑」
你这条AddBendDimensions主流程本身只有 ~230 行,但它 orchestrate 的是整个~1.28 万行、15 个 partial 文件的钣金折弯自动标注系统。从入口看,这已经是一个有架构、有生命周期管理、有观测能力的工业级命令,而不是一坨 if-else。
先说「上亿 token」这件事
对 SolidWorks COM + BREP 面层级 + 工程图拾取(Select4 / SelectByRay)+ 90°/非 90°/混合图边 这种组合爆炸域来说,token 烧得多是正常现象,不代表走弯路:
- 每个真实零件都是一次「几何 + API 行为 + 规则边界」的集成测试
- 规则不是写一遍就完,而是「标错了 → 加禁止项 → 加容差 → 加去重 → 加 reason 统计」的迭代
- 你有
benddim_rule.txt这种和源码对齐的规则文档,说明 token 主要花在收敛领域知识上,而不是反复重写入口
「效果暂时没啥问题」在这个领域里,权重很高——很多 SW 自动化脚本在 demo 上能跑,上真实钣金就崩。
入口文件做得好的地方
/// <summary>折弯尺寸标注主流程:校验视图 → 建折弯图 → 节点间/节点内标注 → 汇总。</summary> public static void AddBendDimensions(ISldWorks swApp)- 编排清晰:校验 → 建图 → 节点间 → 节点内 → 内弧中点 → 统计,和
benddim_rule.txt里的执行顺序一致 - SW 环境管得细:配置切换、
CommandInProgress、草图退出、swInputDimValOnCreate恢复、HLV 显示模式还原——这些都是「能跑」和「不坑用户后续操作」的分水岭 - 容错粒度合理:单折弯构建失败、单节点处理失败都不拖死全局
- 状态隔离意识强:
dimensionedPairs、按节点记账的interNodeUsedOuterFirstByNode、测量值分桶去重——说明你在对抗跨折弯重复标注这种真实痛点 - 可调试:JSON 折弯图、reason stats、多种 debug probe——这是长期迭代必需的,不是锦上添花
这个入口读起来像「总控」,而不是把所有逻辑塞进来——分工是对的。
模块拆分:大体合理,体量说明问题有多硬
| 文件 | 行数 | 职责 |
|---|---|---|
sketch-dimension.cs | ~2213 | 草图线/点标注、拾取 |
process.cs | ~2112 | 90°/非90°/混合边业务主逻辑 |
dimension-create.cs | ~1392 | 建尺、撤销、校验 |
faces.cs | ~1354 | 一/二/三级面传播 |
visible-edges.cs | ~909 | 可见边缓存与 Select4 |
这不是 over-engineering,而是问题本身就需要这么多层:面层级构建、图邻接、可见性、标注创建、事后校验,任何一层混写都会更难维护。
值得骄傲的设计决策
- 折弯图(BendNode + BendEdge)做中间表示——把「特征遍历」和「标注策略」解耦,比直接在特征上打尺寸成熟得多
- 90° ±10° 分路径,混合图边单独双路径——说明你已经从「统一公式」走到了「按拓扑形态分支」,这是对的
- AddDimension2 后 SystemValue 校验 + EditUndo2——SW 自动化里非常关键的保险丝
- reasonStats + benddim_reason_stats.log——以后用户说「某个面怎么没标」,你有抓手,不是盲猜
诚实短板(不影响「现在能用」,但影响「以后好改」)
process.cs/sketch-dimension.cs仍偏大(2k+ 行),下一波 refactor 可以按「90° 节点内 / 非90° 节点内 / 混合边节点间」再拆 partial- 容差常量很多(
core.cs里一堆0.001xm),短期靠经验调参没问题,长期建议按「拾取 / 面距 / 去重」分组并注明物理含义 - Console 日志为主——现场调试够用,若要给别人用,reason stats 已经有一半观测体系了,可以逐步统一
- 规则复杂度还在涨——
benddim_rule.txt已经到「三级面内外由路径上二级圆柱判定」这种粒度,每加一条规则都要想会不会和混合边、节点间占用打架;这是维护成本,不是代码写得差
一句话结论
这不是「画了上亿 token 的偶然成功」,而是「在一个 API 难、几何脏、规则密的领域里,用大量迭代换出来的可用系统」。
入口AddBendDimensions.cs的质量说明:你最后把复杂度收进了分层和流程,而不是留在主函数里。以钣金工程图自动标注的标准看,这已经达到可交付、可继续演进的水准;token 花得冤不冤,取决于后面还要覆盖多少零件族——以你现在的规则文档 + 观测 + 分模块结构,继续迭代的边际成本是可控的。
如果后面要省 token,最有效的不一定是重写,而是:固定 3~5 个回归零件 + reason stats 对比 + 每次只改一条规则分支。你这套基础设施已经具备这个条件了。
