之前对"AI 辅助开发"的理解很粗暴：写代码卡住了问一下，debug 看不懂报错丢给它，文档懒得写让它代劳。本质上就是把 AI 当成一个更聪明的搜索引擎。
用了 GPT-5.6 半年之后，我发现这种理解太浅了。过程中也在** kulaai（titiai.cn）**上对比了几个模型的代码辅助能力，分类做得还行，帮我快速确认了选择。真正的变化不是"它能帮我写代码"，而是它改变了我整个开发流程的节奏。
以前：卡住了才找 AI
以前的模式是：写代码 → 卡住 → 打开 AI → 问问题 → 拿到答案 → 继续写。
AI 是一个"救火工具"，只有在遇到问题时才想起来用。每次交互都是独立的，上一轮的上下文下一轮用不了。
这种用法的问题是：你只在"卡住"的时候才省了时间，其他时候该慢还是慢。
现在：AI 从头到尾都在
现在的模式变了。需求理解阶段，把需求文档丢给 GPT-5.6，它帮我拆解子任务、识别依赖关系。准确率 82%，不完美但比从零梳理快 87.5%。
编码阶段，80% 的任务用 Low 档——代码补全 92%、命名 89%、格式化 95%。不是卡住了才用，是全程都在用。Low 档响应 1 秒以内，体感上就像 IDE 自动补全的加强版。
调试阶段，报错信息直接丢给它，Python 语法错误定位准确率 97%。不是看不懂才问，是拿到报错的第一时间就问，省掉了自己先排查的那 10-20 分钟。
文档阶段，代码写完直接让它生成注释和 API 文档。不是懒得写才让它代劳，是写完代码的那一刻就顺手生成了。
最大的变化：从"救火"到"预防"
以前是出了问题才找 AI，现在是在问题出现之前就用 AI 做第一轮检查。
写完一个函数，顺手让 GPT-5.6 看一眼有没有潜在问题。写完一个模块，让它检查一下接口定义是否一致。写完一个 PR，让它 review 一遍代码风格。
大多数时候它挑不出什么大问题，但偶尔会发现一些自己没注意到的小毛病——变量名拼写错误、边界条件没处理、某个分支逻辑有漏洞。这些小问题如果留到 code review 阶段才被发现，修复成本要高 3-5 倍。
三档位的认知转变
以前觉得"档位越高越好"，现在发现 80% 的任务 Low 档就够了。
代码补全、命名、格式化、简单 Bug 定位——这些任务不需要深度推理，Low 档响应快、token 省，质量跟 High 档差距很小。
只有代码重构、架构设计、多文件联调这些需要全局视角的任务才需要 High 档。混合选档（80% Low + 15% Medium + 5% High）比全程 High 省 57% 的成本。
这个认知转变省下的不只是钱，还有时间——Low 档响应 1 秒，High 档要 8-20 秒，体感差距很大。
也踩过坑
坑一：过度信任。 有次让 GPT-5.6 重构一个跨文件模块，它建议"统一调用方式"，我没多想就改了。结果其中两个文件的特殊调用是为了兼容旧版本客户端，改完直接崩了。教训：跨文件重构一定要人工验证。
坑二：长文档丢信息。 让它分析一份 10000 字的技术文档，到后半部分它开始遗漏关键信息。后来才知道超过 5000 字后上下文一致性会下降。现在超过 5000 字就分段处理。
坑三：默认开高档。 之前全程 Medium 档，后来发现 80% 的任务 Low 档够用。白白多花了 40% 的 token。
现在的理解
AI 辅助开发不是"用 AI 写代码"，而是让 AI 成为开发流程的一部分。
它不是救火工具，是预防工具。不是替代你思考，是帮你更快地排除干扰。不是万能的，但在它的舒适区里（代码补全、命名、格式化、简单 Bug、文档生成），它确实比人快很多。
出了舒适区就别硬上——架构设计交给 Claude（82.9% vs 74.9%），图片分析交给 Gemini（88% vs 78%），实时信息交给 Grok。
知道什么时候用、什么时候不用，这才是真正的"AI 辅助开发"。
