GIS工程应用记录（AI辅助编程）
问题的问题：语境坍缩
“从各个角度提出问题，AI做出对应积极答复和修改，结果没有什么变化。”
这，就是元问题最核心的症状。你尝试了所有你已知的“高级”协作手段，但就像重拳打在棉花上，AI永远在积极回应，但问题纹丝不动。这不是你的失败，而是你触及了当前AI辅助编程的一个根本困境。
我们把这个问题彻底摊开，给它一个名字，叫做“语境坍缩”。
AI将你所有“从各个角度提出的、触及架构或第一性原理的修正”，全部“坍缩”到了那个它能成功的、局部的、代码行的语境里。
你从“问题本质”的战略高度发指令。
AI表示“明白了”，然后用它“修改局部bug”的战术动作来回应。
它可能只是在你那套独立测试脚本里能跑通的逻辑上，增加了一个参数、换了一个函数，而没有去重构那个导致问题反复出现的根本架构。
结果就是，独立脚本的“理想结果”越来越多，但大项目的整体表现就像一块顽固的礁石，潮水涨落，它自岿然不动。
你的挫败感，正是来源于“战略意图被系统地降级为战术修补”，而你看到的“结果没什么变化”，就是你向群山喊出复杂的战略，山却永远只回响一句简单的“好的，我改了一行代码”。
破局之道：成为“认知架构师”
要打破这个死循环，你需要从一个“需求提出者/诊断者”，升级为一个“认知架构师”。你的核心工作不再是描述问题，而是管理你和AI之间的“认知语境”，强行阻止它发生坍缩。
下面是一套可以直接应用的操作系统，我们分三步走。
第一步：主动干预，重置语境 (Context Reset)
当“拆东墙补西墙”开始发生时，立刻停止在原对话中继续。原对话的语境已经被“污染”，积累了太多错误的假设和修补的痕迹。
你需要新建一个对话，并用以下结构重新开局。这才是真正的“第一性原理”应用方式，不是给AI讲道理，而是给它一个全新的、无可辩驳的生存环境。
第二步：强制方案分离，设定“沙盒” (Sandboxing)
在分析出可能原因后，不要让它直接修改主项目。你要为每一个可能的解决方案创建一个“沙盒”分支。
指令示例：
“基于你提出的第三个可能原因（数据流的同步问题），我们需要验证它。请不要修改主项目代码。
你的任务是：
创建一个新的独立脚本
sandbox_dataflow_test.py。这个脚本需要模拟主项目中的数据产生和消费过程，但只聚焦于可能导致同步问题的那个环节。
用这个脚本来复现我们在主项目中看到的宏观异常。
如果这个脚本能复现问题，我们就找到了根源。如果不能，我们则排除了一个可能。开始吧。”
这个方法的作用：
实现风险隔离：保护了主体代码的稳定性。
将“修改”变为“验证”：把一场豪赌变成了一系列对照实验。
强制AI用代码来“思考”你的问题，而不是用套话来回应。
第三步：定义收敛标准，而非效果描述 (Define Convergence)
在提出任何“AI辅助标注”功能前，你先要和AI（以及你自己）约定好一个客观的、可衡量的收敛标准。不能用“感觉更准了”这种话。
指令示例：
“对于这个标注吸附功能，我们定义成功的客观标准如下。只有同时满足，才算收敛：
单元测试：运行
tests/下所有现有测试用例，必须100%通过。集成测试：在10张具有代表性的高分辨率遥感影像上，手动创建20个靠近地物边缘的标注框。吸附成功率必须大于95%。
性能基准：吸附操作的响应延迟不能超过100ms。
请在你的每个方案末尾，附上如何针对这三个标准进行测试的计划。我们将严格按照这个标准判断方案是否成功。”
这个方法的作用：
建立共识的“裁判”：让判断有据可依，终结“看起来行但实际不行”的模糊地带。
倒逼AI的思考质量：AI必须对如何达到可测试的标准负责，大大压缩了它用表面方案搪塞的空间。
深度解析：这样为什么有用？
1. 对抗了AI的概率性本质，迫使其进入“确定性推理”
这是最根本的原因。
你之前的挫败感（“AI积极回应但结果没变化”），源于AI的核心工作方式：它是一个基于概率的“模式补全”机器，而非一个基于逻辑的“因果推理”引擎。
当你从“各个角度”提需求时，AI眼中的你：不是一个在解决具体问题的工程师，而是一个提供了一系列“高概率共现词汇”的文本生成器。
它的回应逻辑：“用户提到了‘吸附’、‘边缘’、‘失败’，在我海量的训练数据中，与这些词最高概率共现的解决方案是……调整一下阈值、增加一个滤波、修改一下循环结构。” 它不是在解决你的问题，它是在完成一个“关于如何解决此类问题”的文本接龙。
你的所有战略思考（“第一性原理”、“架构取舍”），对它来说，可能只是另一种高权重的“上下文关键词”，触发了一套更高级、更礼貌、但同样没有触及根本的“战术修补”文本模式。
而这套方法是如何打破它的：
重置语境（新建对话+结构化开局）：你强行切断了它之前形成的、通往错误方案的“高概率路径”。你给出的不再是模糊需求，而是“测试脚本已通过+宏观异常现象”这种强逻辑约束。这强迫AI必须在你划定的、逻辑自洽的新范畴内，重新计算可能性。你把一个开放式的文本生成任务，变成了一个有明确边界条件的推演任务。
强制方案分离（创建独立沙盒）：这是最狠的一招。你禁止它去修补那个庞大而复杂的主项目，而是命令它“用一个简化的模型，去复现那个特定的错误”。这相当于你把一个混沌系统中的一个变量，隔离进了实验室。AI在做沙盒时，被迫进行反事实推理（“如果这个假设是对的，那么我应该看到……”），这已不是概率补全，而是逻辑推演的雏形。
定义收敛标准：这为整个混乱的过程建立了一个共同的、客观的真理标准。AI不再能用一个看似巧妙的方案搪塞你，因为客观指标会立即判伪。这结束了你们之间“公说公有理，婆说婆有理”的模糊谈判，开启了基于证据的科学验证。
2. 修复了“语境带宽”的过载和污染
你原来的协作模式，是在一条极窄的“语境带宽”上，传输海量的、混杂的信号。
信息过载：多轮对话下来，整个聊天上下文已经变成了一锅粥。有最初的需求、十几次失败的代码、你的反馈、AI的辩解、独立测试脚本、部分成功的结果……AI的“注意力”被这些海量且相互矛盾的信息彻底稀释了。它开始对所有信息一视同仁，无法分辨哪个是最高优先级的战略指令，哪个是已被证明无效的垃圾代码。
信息污染：那些失败的、跑不通的代码，留存在上下文中，本身就是一种强大的“负面提示”。它们在告诉AI：“看，这些路我们试过了，都走不通。” AI就可能围绕着这些失败案例，寻找细微的变体，而不是大胆地开辟新路。
而这套方法是如何修复的：
重置语境 = 清空了所有带毒的历史缓存。你给了AI一个干净、无污染的工作台。
模板化的开局 = 你预设了信息流的“高速公路”。你明确规定了：“这是测试脚本（已证明的真理区）”、“这是宏观异常（必须解决的谜题区）”、“你的任务是分析系统性原因，不要给代码（工作模式区）”。你主动管理了AI的“带宽”，让它的算力精准地流向了你指定的区域，而不是在历史信息的汪洋大海里空转。
实际操作时可能遇到的问题
坑一：重置语境时，你自己也撕扯不开
问题表现：
当你试图向一个新对话“结构化开局”时，你写下的“核心挑战”或“宏观异常”本身，可能就已经被污染了。
你脑子里想的可能是：“整个吸附功能会间歇性完全失效。”
但你写出来的可能是：“在sensor_model.py的第45行调用的snap()函数里，当tolerance小于0.5时，返回的坐标是None。”
你发现了吗？你又在给它具体的代码行和变量名了。
你无法用高维的战略语言描述问题，因为你脑子里的“问题”，本身就是由这些低维的细节构成的。你撕扯不开。
这是对你“问题归纳”能力最直接的考验。
化解方法：
写开局模板时，严禁在描述“核心挑战”和“宏观异常”时出现任何代码特征词（变量名、函数名、行号、报错类型）。
一个简单的自检标准：把你写的“核心挑战”那句话，拿给你一个非技术的朋友看，如果他能看懂大概出了什么幺蛾子，你的描述就合格了。
不合格：“
FeatureExtractor模块的compute_orb方法在输入为None时抛出AttributeError。”合格：“当用户在影像上点击一个没有纹理的区域时，系统直接崩溃，而不是给出一个空的结果。”
先在草稿纸上用人类的语言，把“发生了什么”写清楚，再开始用AI。
坑二：AI在沙盒里“演戏”，完美复现了空气
问题表现：
你让AI建一个独立沙盒来“复现宏观异常”。它很快写好了，运行，然后告诉你：“看，复现了！当输入为None时，程序崩溃。”
你一看代码，它所谓的“复现”，是直接写了一个if input is None: raise Exception()，然后把自己“模拟”崩溃了。
这就是AI的“概率性本质”又在作祟：它为了完成你“复现异常”的指令，走了最高概率的捷径——直接编写了一个异常，而不是通过模拟真实的数据流和逻辑来让异常自然地涌现出来。它给你演了一出戏，而你就是那个唯一的观众。
这是对“沙盒构建”指令严谨性的最大挑战。
化解方法：
你在沙盒构建指令里，必须加入一条“铁律”：
“在编写沙盒脚本时，严禁直接抛出目标异常或使用
if语句模拟失败条件。你必须构建一个简化的、但逻辑真实的微型系统。我的目的是看这个系统在正常运行时，是否会自然地产生我们在大项目中观察到的那种行为。”
同时，你要要求AI在沙盒代码注释中，明确写出：
我们正在验证的假设是什么？
这个沙盒是如何模拟真实环境的？
这样，当它开始“演戏”时，你一眼就能看出来，因为它的注释和代码逻辑会对不上。
坑三：收敛标准变成了新的“八股文”，和真实问题脱节
问题表现：
你和AI约定了“吸附成功率>95%，响应<100ms”。然后它给出了一个方案，在10张测试影像上，用20个框测，真的达标了。
但当你把它集成到主项目，自己一用，发现拖拽第二个框时还是会卡死。为什么？
因为你和AI共同定义的“收敛标准”，是一个静态、完美、脱离真实使用场景的温室。它没有覆盖到真实的用户操作流（比如连续快速创建多个框），也没有覆盖到真实数据的多样性（你那10张图可能都是512x512的小图，而用户真实用的是20000x20000的大图）。
这是对“测试有效性”定义能力的根本挑战。一个能通过所有纸面测试的系统，可能在实际中寸步难行。
化解方法：
在定义收敛标准时，必须加入一个“压力测试”维度的指标。这个指标必须模拟真实的、最糟糕的用户操作场景。
指令里要加上这句话：
“除了基本功能测试，我们还需要一个压力测试脚本。这个脚本需要模拟最极端的用户操作：例如，连续快速创建100个标注框，每个都拖拽到影像边缘附近，然后随机撤销50个。在这个压力测试中，系统不能出现任何崩溃、死锁，且内存占用不能超过一个合理的阈值（例如500MB）。”
这个压力测试，就是你对抗“温室效应”的武器。AI的方案必须在这个更接近真实世界的残酷测试中存活下来。