十九世纪的远洋船厂里，有一种常见事故。

新船下水前，工匠会不断修改甲板、桅杆与船腹结构。前线木匠负责局部修补，后方绘图师负责整体设计。若某次测算中，龙骨弧度存在偏差，后续所有“局部优化”都会逐渐演化为灾难：甲板越修越歪，桅杆越来越高，最后整艘船在视觉上仍然“像船”，重心却已经偏离。

真正危险的地方，在于错误并不发生于最后一次修改。

它发生在最初那条未经复核的曲线。

最近一次 Three.js 几何生成模块的重构，让我再次意识到：当前阶段的大模型协作开发，最脆弱的位置，通常不在代码生成能力，而在“数学推演”与“工程状态”混杂后的失真链条。

尤其当几何、Shader、BufferGeometry 与极坐标推导同时存在时。

一、局部修补为何会持续失效

在这次隧道截面生成模块中，问题最初表现得并不严重。

水沟悬空。 高度异常。 旋转后法线方向错误。 GLSL 着色与 CPU 端顶点结构不一致。

表面看，都是局部 Bug。

于是开始进入典型的大模型协作循环：

  • 提交报错
  • 请求修复
  • 替换代码
  • 局部恢复
  • 出现新问题

几轮之后，代码越来越长。

问题却越来越像“结构性错位”。

后来回头看，真正的起点其实是一个几何建模决策：

厚度计算采用了整体 Scale 缩放，而非同心偏移。

这个选择在单段几何中可以成立。 进入复杂截面后，拓扑关系开始逐渐漂移。

于是后续所有 API 模式下的“精准修复”，都在错误地基上继续施工。

这也是当前很多 LLM Coding 工作流容易忽略的问题：

局部生成能力越强，越容易掩盖底层数学模型已经失效。

二、为什么 Web 长对话会逐渐“漂移”

很多人将 Web 端长会话理解为“持续记忆”。

实际更接近一个不断被重写的临时施工日志。

上下文足够长时，大模型会开始进行压缩、抽象与遗忘。某些前期定义过的几何约束，会在后续推导中逐渐降权。

问题在于：

工程系统里，有些约束无法被“语义近似”。

例如：

  • 水沟必须位于回填层内部
  • 禁止通过 Scale 实现厚度
  • CPU 与 GPU 必须共享同一基准圆心
  • 极坐标逆推必须使用固定参考半径

这些条件一旦漂移，后续代码即使语法正确，也会逐渐偏离原始拓扑。

于是会出现一种很典型的现象：

你看到生成结果越来越复杂。 却越来越不像最初定义的结构。

这像什么？

像一个长期扩建的港口。

每一批施工队都只看最近的图纸。 没人再确认最初的潮汐线。

三、数学推演必须从代码上下文中剥离

这是这次复盘后最明确的一条结论。

数学 Prompt，应当独立并行验算。

不能混在工程代码会话里。

代码生成模型在处理以下内容时，会天然发生注意力竞争：

  • 几何连续性
  • TypeScript 类型
  • Three.js API
  • GLSL 变量
  • Vue 生命周期
  • BufferAttribute 排布
  • 数学约束

一旦上下文开始拥挤，模型会优先维持“代码可运行”，随后逐渐牺牲“数学严格性”。

于是会出现一种危险局面：

程序运行正常。 结构推导已经错误。

这难道不正是很多工程事故最典型的前兆？

四、数学会话与工程会话需要“双轨制”

后来我开始调整工作流。

将数学验证与工程实现拆分。

第一轨：纯数学推演会话

只做几件事：

  • 截面连续性验证
  • 曲率变化推导
  • 偏移合法性检查
  • 极坐标逆运算验证
  • 分段函数边界验算

不允许出现：

  • Three.js
  • Shader
  • Vue
  • TypeScript

甚至不允许出现变量命名优化。

这里只有公式、边界、连续性与几何关系。

因为数学问题一旦进入工程语境，模型会倾向于“生成代码”，而不是“验证结构”。

这是能力偏置。

第二轨：工程实现会话

数学闭环确认后，再进入代码生成。

此时输入内容已经变成：

  • 确认后的公式
  • 固定接口
  • 参数定义
  • 输入输出边界
  • 不可变约束

模型的任务从“推导”，收缩为“翻译”。

风险会下降很多。

五、状态文档比长对话更重要

另一个变化，是开始外部化状态。

很多开发者仍然依赖聊天记录维持项目连续性。

这个模式在小型项目中问题不大。 进入复杂系统后，会逐渐失效。

因为对话历史并不稳定。

真正稳定的，是结构化状态。

后来我开始维护一份独立 State Document，专门记录工程技术方案与开发步骤方案：

  • 不可变几何约束
  • 禁止使用的实现方式
  • CPU/GPU 参数基准
  • 坐标系定义
  • 厚度生成规则
  • 法线方向约定

每次新开 API 会话，先注入状态文档。

这相当于：

先固定船坞坐标。 再允许工匠施工。

否则每轮会话都在重新定义世界坐标系。

六、接口快照需要人为锁死

很多跨文件错误，并非模型不会写代码。

问题出在“自由推演空间过大”。

例如：

TS 端生成：

invertCenterY = archCenterY + offset

GLSL 端却可能推导成：

radius = distance(vPos, center)

两边都合理。

组合后开始错位。

因此后来会在提交 Prompt 前，人工增加“接口快照”：

  • 当前基准点是多少
  • 哪个变量绝对不可修改
  • Shader 必须以哪个值反推
  • 哪些字段属于只读约束

本质上，是人为缩小 LLM 的解释空间。

因为当前阶段的大模型，并不真正理解“系统”。

它更像一个极强的局部生成器。

边界越清晰。 结果越稳定。

七、未来的协作重点，可能不再是“对话”

很多人仍然在比较：

  • Web 模式更强
  • API 更精准
  • 某模型代码能力更高

但真正决定协作效率的，可能已经开始转向另一件事：

谁在维护“状态”。

因为模型会遗忘。 工程不会。

长上下文可以延缓漂移。 无法消除漂移。

所以未来真正重要的能力，也许不再是持续聊天。

而是：

  • 数学验证如何独立闭环
  • 状态如何外部持久化
  • 接口如何冻结
  • 约束如何强制注入
  • 哪些推导必须人工复核

这已经接近一种新的工程分工。

人负责结构边界。 模型负责局部生成。

如果边界不存在，模型会持续“看起来正确”。

直到整个系统开始缓慢倾斜。

就像那艘不断返工的船。

每块木板都经过认真修补。 龙骨方向却早已偏离潮线。