一个开发者遇到报错，第一反应是打开对话框，把代码贴进去问"哪里错了"。这个动作正在变成肌肉记忆。
问题→问AI→复制代码→再问AI为什么失败→让AI修→让AI解释修了什么。这条链路很顺手，顺手到很多人已经忘了，链路上有一半的环节，本来不需要另一个智能体介入。
更值得警惕的不是效率，是依赖的形状：开发者变成了另一个智能的API客户端，而不是变成一个更好的工程师。
该用AI的地方，和不该用的地方
目标从来不是把AI从软件开发里删掉。更合理的分界线是：推理成本高的地方交给AI，计算、验证、重复成本低的地方交给确定性工具。
这条线在开发者转向AI工程和推理工程之后会变得更重要。Git、GitHub、编译器、linter、调试器、性能分析器、Docker、Ollama、vLLM、Hugging Face、Unsloth，这些工具能覆盖开发生命周期里相当大的部分，不需要每一步都调用一次大模型。
先看最直白的一类：答案本身是确定性的。
要算 1024 × 768，用计算器。要格式化代码，用格式化工具：ruff format、gofmt、prettier。让大模型去做确定性工作，等于额外引入一种失败模式——机器能精确算出来的东西，模型可能算错。
编译器早就知道答案了
一段代码写成这样：def add(a, b) 换行 return a + b。不需要AI告诉你这里有语法错误，跑一下解释器就行。解释器已经知道了。
同样的道理适用于一长串场景：语法错误、类型错误、导入错误、格式化、lint、测试失败、依赖解析、构建失败、静态分析。
这里有一条值得记住的工程层级，从下往上排：
- 编译器
- 测试
- 调试器
- 性能分析器
- 文档
- 搜索
- AI
AI排在这条链的末端。只有当确定性工具没法充分回答问题时，才轮到它出场。
版本控制系统里已经存着答案
Git本身就是一个极强的开发者推理系统，只是很多人没把它当推理系统用。
想知道"我的项目改了什么"，不用问AI，跑 git diff。想知道"我昨天改了什么"，用 git log。想知道某一行代码为什么存在，git blame file.py 能定位到引入它的那次提交。
源码控制这块，起点是Git官方文档和GitHub官方文档。AI辅助开发可以看GitHub Copilot的官方文档。Copilot能帮忙写、理解、审查和修改软件，但那条工程原则不变：源码控制系统里已经存着答案的时候，不要再去问大模型。
文档里有确切答案时，文档优先
假设你想知道FastAPI怎么处理依赖注入。有两条路。
一条是直接问："FastAPI的依赖注入是怎么工作的？"另一条是读官方文档，然后去看源码。
当文档里写着确切答案时，读文档比问模型更可靠——文档是这套框架的作者写的，模型只是读过很多关于它的文字。
热门跟贴