现在的问题已经不再是「要不要用生成式 AI 工具」，而是「怎么用」才能最大限度地发挥作用。就像在互联网时代掌握数字素养至关重要一样，在 AI 时代，掌握 AI 素养已成为工程师公平使用 AI 工具的基础。
对初级软件工程师来说，直接让大语言模型（LLM）“写一段实现 X 功能的代码”是非常诱人的做法。事实上，大多数关于如何将 LLM 集成到软件工程或数据科学工作流程中的教程，也往往是从这一步开始的。
但我认为，这可能是个错误的起点。
这篇文章是我在日常软件开发工作中大量使用 LLM 后的一些观察和总结，也是在此基础上逐渐形成的使用策略。
TLDR 总结：
-
不要直接让 LLM 写代码，而是先分析并提供上下文
-
一开始就提供完整上下文，并确认模型需要什么
-
提问要深入，挑战默认假设
-
留意细节错误（比如过时的 API、混用语法）
-
要有检查点机制，避免上下文污染
-
自己理解每一行代码，保持知识对等
-
前期设计要投入足够时间
在整个过程中，有一个很重要的心态是：把模型/系统/代理当作一个有能力但还年轻的结对编程同事。同时也要意识到，LLM 本质上是一个自回归的“下一个 token 预测器”。
注：本文聚焦于「聊天式」的工作流，比如使用 Gemini、ChatGPT 或 Claude 这样的界面，由开发者直接驱动交互和上下文。相反的工作流是像 GitHub Copilot 或 Cursor 那样的自动推断上下文的方式。
1. 不要写代码——先分析！
经验告诉我，最好的结果来自于我一开始就明确要求模型不要写代码。例如我通常这样说：
我需要重构一部分代码。
请你认真思考。
在做出任何修改之前请先和我确认。
我们使用的库或 API 可能已经更改，请多加注意。
如果你需要查看某个文件来更好理解，请告诉我。
规则是：不写代码，先规划、推理、确认。
比如说，我改了 db manager 类，那测试代码也需要调整——这时 LLM 很可能会对代码结构、数据类型、函数行为等作出大量默认假设，甚至提出一些根本不必要或不合适的优化。
因此，我们要让 LLM 一开始就主动表达它的假设，然后你需要花时间去纠正它的计划、弥补它的信息盲点，而不是直接看它产出代码。
2. 提供上下文
上下文至关重要。
这就像你和同事一起拼图，如果有一些碎片藏着不给对方看，那他就根本拼不好。也像设计评审会一样，总是由高级工程师先讲一下整体结构并回答问题。
我会先问 LLM：
“你需要了解什么上下文？”
很多时候，我们人类觉得理所当然的东西，对 AI 来说可能完全不可见。比如一个组件报错，可能是因为模型根本没看到你给它处理的 JSON 数据结构，或者它不知道这个结构改过了。
例子：
你需要什么？
下面是一些文件…
我用的是 ant design 做组件、tailwindcss 做布局、lucide-react 做图标。
这些上下文的提供会极大地减少你日后用来修 bug 和纠正模型错误的时间。
3. 提很多问题、持续学习
有时候你的任务是实现一个新功能，或者是理解一个陌生的代码库。在这种情况下，你可以把代码库看成一张地图，而 AI 可以帮你探索未解锁的区域，更重要的是从中学习。
经验告诉我：
-
深挖副作用，别只看 happy path（理想路径）
-
挑战默认实现的合理性
-
让模型分析不同做法的优劣
-
提前探索可能出错的边界条件
-
问它有什么选择（比如不同算法、不同库）
要注意：LLM 往往会「趋中」，即提供平均水平的解决方案。但真正的应用很多时候是在「长尾」——需要非常具体的调整或公式。
这时候，你就要发挥「高级工程师」的直觉。如果你不提这些问题，模型默认输出的代码可能表面看没错，但实际运行或维护起来会非常痛苦。
例如：
目标是做一个可视化组件。
-
正确提问方式：
「有哪些可选方案用于可视化多行区域图？请列出优缺点。」这样你能了解不同方向，还能发现你没想到的思路。
-
错误提问方式：
「我该用 ReChart 吗？」模型极可能说 “yes”，即使 ReChart 并不是最适合的选项。因为你一旦在 prompt 中写了 “ReChart”，LLM 的输出方向就被锁死了。
记住：LLM 是自回归生成器，它的回答受到上下文提示极大影响
