一个开发者遇到报错，第一反应不是看终端，而是打开对话框。问题抛给AI，代码贴进去，等一段解释回来，再照着改。改完还是报错，于是把新的报错再贴回去。

这个循环看起来很高效。但它有一个副作用：开发者慢慢变成了另一个智能的API客户端，而不是一个把工程能力练得更扎实的人。

打开网易新闻 查看精彩图片

问题不在于要不要用AI。真正值得问的是：哪些环节该交给AI，哪些环节交给确定性工具更划算。

确定性的事，机器比模型更可靠

如果只是算一个乘法，用计算器就够了。如果只是格式化代码，用格式化工具就够了——ruff format、gofmt、prettier，这些工具的输出是确定的，不会今天一个样明天一个样。

把确定性的工作交给大模型，等于主动引入一种新的失败模式：模型可能在一件机器能精确计算的事情上出错。这种错误本来完全可以避免。

同样的道理适用于代码里的语法问题。一段函数定义漏了冒号，不需要模型来告诉你哪里错了，跑一遍解释器，它自己就会说。

解释器已经知道答案的事，不必再问一遍。

一条被忽略的工具链顺序

语法错误、类型错误、导入错误、格式化、静态检查、测试失败、依赖解析、构建失败、静态分析——这些都属于确定性工具的主场。

可以把它想成一条从下往上的链条：编译器在最前面，然后是测试、调试器、性能分析工具、文档、搜索，AI排在最后。

顺序本身就是一种判断标准。当确定性工具无法充分回答问题时，才轮到AI出场。反过来，一上来就找AI，等于跳过了前面所有更便宜、更准确的环节。

版本控制里已经写着答案

Git本身就是一个很强的推理系统，只是很多人忘了用它。

想知道项目改了什么，跑 git diff，不用问。想知道昨天自己改了什么，看 git log，不用问。想知道某一行代码为什么存在，git blame 能直接指出引入它的那次提交。

这些命令给出的答案来自真实的提交记录，不是模型的推测。

源码管理的问题，先查Git官方文档和GitHub官方文档。AI辅助开发可以参考GitHub Copilot的官方文档，Copilot能帮忙写、理解、审查和修改软件，但那条工程原则不变：源码管理系统里已经存着答案的时候，不必再调用大模型。

文档里有确切答案时，文档优先

假设你想知道FastAPI怎么处理依赖注入。有两条路：一条是直接问AI它是怎么工作的，另一条是去读官方文档，自己看实现。

当文档里就写着确切答案时，读文档往往更快，也更不容易被带偏。

这不是要否定AI。推理成本高的地方，AI的价值最大；而计算、验证、重复这些成本更低的环节，交给确定性工具更合适。开发者越往AI工程和推理工程走，这条分界线越重要。

Git、GitHub、编译器、linter、调试器、性能分析工具、Docker、Ollama、vLLM、Hugging Face、Unsloth，这些工具能覆盖开发生命周期里相当大的一部分，不需要每一步都请一个大模型来参与。

把AI放在链条的末端，不是削弱它，而是让它出现在真正需要它的地方。