2026 年了，别再把 LLM 当 "魔法答案机" 了
2026 年了，别再把 LLM 当 "魔法答案机" 了
今天想聊的不是什么新技术突破，而是一个更实在的话题：
一位高级工程师在 2026 年是怎么用 LLM 的？
这个分享来自 Sean Goedecke。
不是那种 "我用 AI 写了整个应用" 的标题党，而是一位 Staff Engineer 在日常工作中真实的使用场景、工具选择、以及方法论沉淀。
我觉得值得聊，因为它对大多数人有参考价值——你不用是 OpenAI 的研究员，不用有无限算力预算，你就是一位想把活干好的工程师，这就够了。
先搞清楚：你是在 "找答案"，还是在 "生产代码"？
Sean 分享的第一个观察很扎心：大多数人用 LLM 的方式错了。
他们把 LLM 当成了 "魔法答案机"，输入一个问题，期望得到完美的、直接能用的输出。
但实际上，对一位真正负责的工程师来说，LLM 更像是 "协作伙伴"，而不是 "答案提供者"。
Sean 把场景分成了两类：
场景 A：探索未知（Exploration）
这种场景下，你并不真的知道自己要什么。
你可能在：
- 学习一个新技术
- 调研几个方案的差异
- 理解一段复杂代码的意图
- 探索某个问题的边界
这种时候，LLM 的价值不在于 "给你答案"，而在于 "陪你思考"。
你会跟它对话：
"这个概念我理解对了吗？" "如果换个角度看呢？" "这个方案的 trade-off 是什么？"
这时候，输出质量不重要，思考过程才重要。
场景 B：生产交付（Production）
这种场景下，你要的是可交付的结果。
你可能在：
- 写一段具体的业务代码
- 实现一个已知方案的功能
- 把设计文档转成实现
- 修复一个有明确 root cause 的 bug
这时候，你需要的是精确、可验证、符合标准的输出。
Sean 的选择：两个工具，两种用法
Sean 并没有用什么神秘工具，他的选择很务实：
探索阶段：Claude + 长对话
他用 Claude 来做探索性工作。
为什么是 Claude？
Sean 的理由很实在：Claude 更能记住对话上下文。
当你在探索一个复杂主题时，你可能会有 20、30 轮对话，你不希望每次都重新解释一遍你在做什么。
他的用法是：
开一个 Claude 的长对话 session，标题就写 "2026-05-17 探索 XX 方案" 然后把整个思考过程都放进去 想到什么就问什么 它可能会说错，但没关系，重要的是这个对话帮你理清了思路
这种对话本身就是一种思考脚手架。
生产阶段：Cursor + 小范围修改
他用 Cursor 来做实际的代码生产。
为什么是 Cursor？
不是因为它是 "AI IDE"，而是因为 它很擅长做小范围精确修改。
Sean 不会让 Cursor 写整个文件，他的用法是：
选一段代码 给出精确的修改指令 然后审查它做的改动 要么接受，要么让它重来
他强调：对生产代码，你必须让修改范围最小化。
你要能清晰地解释：
- 改了哪几行
- 为什么要这样改
- 引入了什么风险
如果让 AI 重写整个文件，你就失去了这种控制力。
真正有用的不是工具，是约束
Sean 分享的最有价值部分，不是他用了什么工具，而是他给自己定了什么约束。
他的三个铁律：
约束 1：一个对话只做一件事
他不会在一个对话里既讨论架构，又调试具体代码，又写文档。
为什么？
"如果一个对话里混了太多不同类型的任务，上下文就变浑浊了。 AI 会困惑，你自己也会困惑。 你需要的是清晰、可追溯的思路，而不是一锅粥。"
所以他的做法是：
- 架构探索对话：只聊架构、方案、trade-off
- 代码实现对话：只聊具体代码、测试、边界情况
- 文档写作对话：只聊表达、结构、读者体验
每个对话干净利落，用完归档。
约束 2：AI 输出必须 "可验证"
Sean 不会相信一段他无法验证的 AI 输出。
什么叫 "可验证"？
- 能跑测试吗？
- 能和现有代码集成吗？
- 能通过你的直觉检查吗？
他的原则是：
"如果 AI 给了一段代码，我至少得能说出来： 这段代码的哪几行是对的，哪几行需要改。 如果我完全看不懂，那这段代码再高级也没用。"
约束 3：最终决策权在你，不在 AI
Sean 说，很多人搞反了。
他们让 AI 做决定，自己只负责挑错。
但实际上，正确的顺序应该是：
- 你先有一个观点（哪怕很粗糙）
- 让 AI 来挑战这个观点
- 你来决定是坚持、修改还是推翻
为什么要这样？
"如果你自己没有观点，你很容易被 AI 带着走。 它说得头头是道，但方向可能根本就不对。 你得先有自己的锚点，AI 只是用来校准这个锚点的。"
具体场景 1：学习一个新技术
Sean 学习新技术的方式很有意思，他会玩一个 "AI 访谈" 游戏。
他不会上来就读文档，而是先跟 AI 对话：
"假设你是这个技术的作者，你能给我讲讲吗？" "你当时设计的时候，最难的决定是什么？" "你犯过什么错误吗？" "你觉得这个技术最适合解决什么问题？" "如果让你给刚入门的人三个建议，你会说什么？"
然后他会再开另一个对话，扮演反面角色：
"假设你是这个技术的批评者，你会怎么喷它？" "它的边界在哪？" "什么场景下千万别用它？"
这样一来一回，他对这个技术的理解就立体了。
然后他才会去读真正的文档，这时候他知道该关注什么。
具体场景 2：写业务代码
写业务代码时，Sean 不会让 AI 写整个功能。
他的方法是分层的：
第 1 层：你写核心逻辑
你先把关键的 50 行代码写了——那些包含业务规则、核心算法、关键判断的代码。
为什么自己写？
"因为只有你真正理解业务，只有你知道这里的坑在哪。"
第 2 层：AI 写脚手架
然后让 AI 写：
- 类型定义
- 错误处理
- 参数校验
- 日志记录
- 测试框架
这些是体力活，但 AI 写得比你快，比你全。
第 3 层：AI 补测试
最后让 AI 补测试用例。
但 Sean 会给非常具体的指令：
"给这个函数写测试用例：
- 正常路径 3 个
- 边界情况 5 个
- 错误路径 3 个 不要用 mock 库，用最直接的测试方式"
然后他会逐条审查这些测试。
具体场景 3：调试一个 Bug
调试时，Sean 不会直接把代码丢给 AI 说 "帮我找 bug"。
他的做法更结构化：
步骤 1：你先形成假设
你先自己看代码，形成至少一个假设：
"我觉得问题可能在这一行，因为..." "或者是那个边界条件没处理..."
哪怕假设是错的也没关系，重要的是你有了思考的起点。
步骤 2：让 AI 挑战你的假设
把你的假设告诉 AI：
"这是我的假设：_____ 你觉得这个假设成立吗？ 如果成立，你能帮我设计一个验证方法吗？ 如果不成立，你觉得我的推理哪里有问题？"
AI 会帮你找推理漏洞。
步骤 3：用真实数据验证
最后用真实数据来验证哪个假设是对的。
这一步 AI 帮不上太多忙，但前两步已经帮你节省了大量时间。
你可能没注意到的细节：Sean 根本不用 "AI 编程" 这个词
整篇分享里，Sean 从来没说过 "用 AI 编程"。
他说的是：
- "用 AI 帮我思考"
- "用 AI 帮我写样板代码"
- "用 AI 帮我补测试"
- "用 AI 帮我理解复杂代码"
这个区别很重要。
他没有把编程这件事外包给 AI，他只是把自己的工作流优化了。
他还是那个负责任的工程师——理解需求，设计方案，写核心代码，审查最终结果。
AI 只是帮他处理了那些机械重复的部分。
为什么这种方式反而更强？
我见过很多团队的 "AI 转型" 是这样的：
- 买一堆 AI 工具
- 培训 "AI 编程技巧"
- 试图把一切都丢给 AI
但结果往往是：
- 代码质量下降
- 没人能解释清楚系统为什么是这样
- 出了问题没人负责
Sean 的方式反而更可持续，因为：
1. 你还是主人
代码的最终解释权在你，不在 AI。
你理解每一个决策，你能解释每一段代码。
2. 风险可控
AI 的输出范围是约束好的，你知道哪些是它写的，哪些是你写的。
出了问题，你知道该从哪查起。
3. 你依然在成长
你没有停止思考，你只是把机械劳动外包了。
你依然在做设计、决策、架构这些高价值工作。
总结：Sean 的 LLM 使用观
读完他的分享，我觉得最有价值的是他看待 LLM 的态度：
"LLM 不是来替代你的，是来帮你节省时间的。 节省下来的时间，你可以用来做那些真正需要人的判断、品味和经验的工作。 如果因为用了 LLM，你反而停止思考了，那就是本末倒置。"
2026 年了，我们不用再讨论 "AI 会不会替代程序员" 这种问题了。
我们应该讨论的是：
- "如何让 AI 帮我们做更多机械劳动？"
- "如何让 AI 帮我们更好地思考？"
- "如何把节省下来的时间花在真正重要的事上？"
Sean 给了一个很好的示范。
希望对你也有启发。
如果你觉得这篇内容有价值，欢迎点赞、点在看，也欢迎转发给更多朋友。
我是 AI 杨侦探，持续记录 AI、技术、产品和产业变化里那些真正值得看、值得想的事。
谢谢你读到这里，我们下次见。