都2026年了,你为什么依然觉得AI编程不好用?亚马逊工程师怒怼:别怪模型,是你太拉

都2026年了，你为什么依然觉得AI编程不好用？

最近听了两位大神的分享。一位叫Eyad，在亚马逊、迪士尼、Capital One干了七年软件工程师，现在是一家做企业级AI代理公司的CTO。另一位是Lee Robinson，Cursor的VP。

这两位每天都在用AI写代码，而且不是写着玩，是在生产环境里写那种不能出错的代码。

听完他们的分享，我算是明白了一件事：为什么同样的工具，有人觉得是神器，有人觉得是智障。

差距不在工具，在人。

Eyad说了一句话特别扎心："如果你用一个好模型，却总是得到糟糕的结果，那问题不在模型，问题在你。"

原话更狠，他说的是"you suck"。

是的，不是AI不行，是你不行。

那到底哪里不行呢？我总结了一下，大概有这么几个问题。

第一个问题：你从来不思考，上来就让AI写代码。

Eyad说，十次里有十次，他用Plan模式出来的东西，都比直接让AI写要好得多，而且差距非常大。

什么是Plan模式？就是先不让AI动手，而是让它出方案，你来审核，来来回回讨论，直到方案满意了，再让AI写代码。

大部分人怎么用AI呢？直接说"帮我写个xxx功能"，然后期待AI一步到位。

这就好比你去饭店，跟厨师说"给我做个好吃的"，然后厨师端上来一盘菜，你说不好吃。废话，你压根没说要吃啥，厨师怎么可能知道你想要什么？

AI也是一样的道理。你说"帮我写个用户登录系统"，这句话的信息量太少了，留给AI发挥的空间太大了。

它可能给你写一个最简单的用户名密码登录，也可能给你整一个支持OAuth、SSO、双因素认证的完整方案。它不知道你的用户模型长什么样，不知道你要把session存在哪里，不知道你的路由结构是怎样的。

你不告诉它，它就只能猜。猜对了是运气，猜错了才是常态。

Eyad举了个例子。同样是做登录系统，你可以说"帮我写个登录系统"，也可以说"用现有的User模型做邮箱密码登录，session存Redis，24小时过期，加个中间件保护/api/protected下的所有路由"。

你说哪个输出质量更高？

花5分钟想清楚要什么，能省你几小时的调试时间。

这个道理其实所有程序员都懂，需求不清晰，代码肯定写不好。但不知道为什么，到了AI这里，大家就忘了这个基本原则，总觉得AI应该有读心术。

AI没有读心术，它只能根据你的输入来推断。你的输入越具体，它的输出就越靠谱。这是铁律，没有例外。

第二个问题：你从来不"培训"你的AI。

很多人把AI当成一个现成的工具，拿来就用，用不好就骂。

但你想过没有，一个新来的员工，你也不可能期望他第一天就能干好活吧？你得告诉他公司的规矩，项目的规范，业务的逻辑，他才能慢慢上手。

AI也是一样的。

Eyad使用CLAUDE.md专门用来"培训"AI。每次AI犯错，他们就把错误记下来，告诉AI"下次别这么干"。

时间长了，这个文件就变成了一个"项目手册"，里面记录了所有AI需要知道的东西——代码规范、业务逻辑、常见坑点、工作流程。

每次启动AI，它第一件事就是读这个文件。相当于每次对话前，先给AI上一堂培训课。

Eyad说了一句话我印象很深：差的CLAUDE.md像是给新员工写的入职文档，好的CLAUDE.md像是你给明天会失忆的自己留的备忘录。

什么意思？就是别写那些废话，AI知道什么是components文件夹，你不用解释。你要告诉它的是那些"奇怪的东西"——为什么这个函数要这么写，为什么这个参数不能改，为什么这个流程跟常规不一样。

而且，不只要告诉它做什么，还要告诉它为什么。

"用TypeScript严格模式"是一个指令，"用TypeScript严格模式，因为我们之前因为implicit any踩过生产事故"是一个更好的指令。当AI知道为什么要这么做，它在遇到你没预料到的情况时，也能做出更好的判断。

你不培训AI，AI就永远是个什么都不懂的新人。你培训AI，AI就会越来越懂你。

这就是复利，前期投入一点时间，后期节省大量时间。

第三个问题：你不知道AI有"疲劳期"。

这个很多人不知道。

AI有个东西叫上下文窗口，比如Opus 4.5有20万token的上下文窗口。很多人以为，只要不超过20万token，AI就能正常工作。

错了！！！

Eyad说，AI在上下文用到20%-40%的时候，输出质量就已经开始下降了。不是到100%才崩，是到三四成就开始出问题。

为什么？因为每条消息、每个文件、每段代码、每个工具调用，都会累积在上下文里。累积得越多，AI需要"记住"的东西就越多，它的注意力就越分散。

这就像你一边开会一边回消息一边写代码，你能集中注意力吗？不能。AI也一样。

所以Eyad有几个习惯：

一是一个对话只做一件事。写登录系统就是写登录系统，别在同一个对话里又让它重构数据库。不然上下文混在一起，AI自己都搞不清楚你到底要干嘛。

二是用外部记忆。他会让AI把计划和进度写到实际的文件里，比如SCRATCHPAD.md。这样明天再来，AI可以读这个文件继续干活，而不是从零开始。

三是定期清理。当对话跑偏了，或者累积了一堆没用的上下文，直接/clear清空，从头开始。你的CLAUDE.md还在，项目规范不会丢，但那些没用的历史记录就清掉了。

他还有个骚操作，叫"复制粘贴重置法"。当上下文太臃肿的时候，先把重要的东西从终端复制出来，然后/compact压缩一下，再/clear清空，最后把重要的东西粘贴回去。相当于手动做了一次"记忆筛选"，只保留有用的，丢掉没用的。

AI是无状态的，这是很多人没意识到的关键点。每次对话，AI都是从你给它的信息开始的，它不会"记得"之前的对话。你得主动帮它管理记忆。

第四个问题：你不告诉AI"不要做什么"。

这个点很有意思。

大部分人只会告诉AI"做什么"，从来不说"不要做什么"。

但AI，尤其是Claude 4.5，有个毛病，它特别喜欢"过度工程"——你让它写个简单功能，它给你整出一堆抽象层、一堆配置项、一堆你根本用不到的灵活性。本来一个文件能搞定的事，它给你拆成十几个文件。

所以Eyad会专门告诉AI："保持简单，不要加我没要求的抽象，能一个文件就一个文件。"

你不说，AI就会按它的"本能"来。它的本能是什么？是尽可能写得"专业"、"完整"、"可扩展"。但很多时候，你不需要那么专业，你就需要一个能跑的东西。

告诉AI边界，比告诉AI目标更重要。

目标AI可以猜，边界AI猜不到。你不告诉它不能做什么，它就会做一堆你不想要的事。

第五个问题：你用错了模型。

Eyad提到一个很实用的工作流：用Opus规划，用Sonnet执行。

Sonnet更快更便宜，适合执行类任务——写样板代码、按照明确计划重构、实现已经想清楚的功能。

Opus更慢更贵，但更适合复杂推理、规划、需要深度思考权衡的任务。

所以聪明的做法是：先用Opus把架构想清楚、把方案定下来，然后切换到Sonnet去执行。

很多人的问题是，要么全程用便宜的小模型，结果反复纠错浪费更多时间；要么全程用贵的大模型，其实很多执行性任务用小模型就够了。

选对模型，比死磕一个模型重要得多。

第六个问题：Claude卡住了你只会硬刚。

有时候Claude会陷入循环——它试一个方案，失败了，再试同样的方案，又失败，来来回回。或者它自信满满地写了一堆完全错误的代码，你解释半天它还是不明白。

大部分人的本能是继续解释，加更多指令，给更多上下文。

但Eyad说，更好的做法是换个思路。

首先，清空对话。累积的上下文可能正在干扰它，/clear重新开始。

其次，简化任务。如果Claude搞不定一个复杂任务，拆成小块，一块一块搞定再组合。不过说实话，如果Claude搞不定复杂任务，很可能是你的Plan模式不够充分。

然后，用"展示"代替"告诉"。如果Claude一直理解不了你要什么，你自己写一个最小的示例给它看。"这是我想要的输出效果，照这个模式来。"Claude特别擅长理解示例，比你用语言描述强多了。

最后，换个角度。有时候你描述问题的方式，跟Claude的思维方式对不上。换个说法——"把这个实现成状态机"和"处理这些状态转换"——可能就通了。

关键技能是尽早识别你陷入了循环。如果你解释了三遍Claude还是不懂，继续解释也没用，那就得做出改变。

第七个问题：你不用工具，全靠手动。

Claude有一堆功能，很多人根本不知道。

MCP（Model Context Protocol）让Claude可以连接外部服务——Slack、GitHub、数据库、各种API。如果你发现自己总是从某个地方复制信息粘贴给Claude，大概率有个MCP能自动完成这件事。

Hooks让你在Claude修改代码前后自动运行脚本。想让Prettier在Claude每次改完代码后自动格式化？设个Hook。想让类型检查在每次编辑后自动运行？设个Hook。这能在问题刚出现时就抓住，而不是堆到最后一起爆。

自定义斜杠命令就是把你常用的提示词打包成命令。在.claude/commands文件夹里加markdown文件，就能用/commandname来调用。如果你经常做某类任务——调试、代码审查、部署——做成命令。

Eyad说了一句话：如果你付了$200一个月的Pro Max，为什么不把Claude的功能都试一遍？反正你已经付钱了。

而且，不要因为第一次试不成功就放弃。这些模型基本每周都在进步，一个月前不行的功能，现在可能行了。保持好奇心，持续实验。

第八个问题：你把AI当一次性工具，而不是系统组件。

Eyad说，真正从Claude获得最大价值的人，不是拿它做一次性任务的，而是把它当成系统的一部分。

Claude Code有个-p参数，叫headless模式。它会跑你的prompt然后输出结果，不进入交互界面。这意味着你可以把它脚本化，管道到其他工具，跟bash命令链起来，集成到自动化工作流里。

企业级用户在用这个做什么？自动PR审查、自动支持工单回复、自动日志和文档更新。全都有记录、可审计、可以根据效果持续改进。

这里有个飞轮效应：Claude犯错 → 你检查日志 → 你改进CLAUDE.md或工具配置 → Claude下次做得更好。这个循环会复利。Eyad说他用同样的模型，但经过几个月迭代，系统比刚上线时好得多。

如果你只是交互式地用Claude，你在浪费它的潜力。想想你的工作流里，哪些地方Claude可以在没人盯着的情况下跑。

第九个问题：你没搞清楚什么时候该用AI。

Cursor的VP Lee Robinson说了一句话："代码本身已经不值钱了。"

他自己都承认，Sonnet 4的编程能力可能比他还强。他做了一个Rust写的图片压缩器，编译成WebAssembly，配合前端框架跑起来——一行代码没手写，全是AI干的。

他还做了一个需要写Verilog的硬件游戏，之前完全不懂这个领域，AI帮他搞定了。

这说明什么？

说明AI最擅长的是执行，是把一个明确的需求变成代码。而人类擅长的是判断，是想清楚要做什么、做出来好不好。

所以Lee的建议是：用AI干掉所有无聊的工作。那些复制粘贴JSON、调试shell脚本、排查奇怪错误的活，全部丢给AI。你自己专注在产品设计、用户体验、商业判断上。

把自己从"写代码的人"变成"指挥AI写代码的人"。

这是一个思维模式的转变。很多人还停留在"AI是补全工具"的阶段，觉得AI应该帮他把没写完的代码补完。

但真正的用法是，你是导演，AI是演员。你不需要亲自上场演戏，你只需要告诉AI你要什么效果。

说到这里，可能有人会问：那我是不是就不用学编程了？

恰恰相反。

Eyad说了一句话："如果你从来不学这些，你就是在给自己设限，哪怕每次只学一点点也好。"

为什么？因为你不懂这些，你就不知道该怎么跟AI沟通。你不知道什么是"好的架构"，你就没法在Plan模式里给出好的方案。你不知道什么是"常见的坑"，你就没法在CLAUDE.md里写出有用的规则。

AI是放大器，不是替代品。你懂的越多，AI能帮你的就越多。你什么都不懂，AI也没法帮你从零变成一。

Lee的建议是：用AI来学习。

他有个习惯，让AI给他生成"迷你课程"，帮他快速理解一个新领域。比如他不懂Verilog，就让AI解释什么是Verilog、语法怎么工作、从硬件到代码有哪些抽象层。

以前学一个新领域，可能得看十本书。现在有AI，你可以按需学习，不懂就问，问完就干。

AI不只是干活工具，更是学习工具。

最后说几句。

很多人觉得AI不好用，本质上是因为他们还在用旧的思维方式。

他们觉得AI应该像一个"聪明的搜索引擎"，你问它一个问题，它给你一个答案。如果答案不对，那就是AI不行。

但AI不是搜索引擎，AI更像是一个"极其聪明但什么都不懂的新人"。你得培训它、引导它、给它反馈、帮它验证。你投入得越多，它回报得就越多。

Lee说的一句话我很认同：那些早点学会用AI工具的人，会比那些犹豫不决的人，获得巨大的优势。

这就像当年Excel出来的时候，有人说"这东西不好用，还不如算盘"。后来呢？

历史总是在重复。工具变了，但逻辑从来没变。

早期拥抱新工具的人吃红利，后知后觉的人被淘汰。

AI编程也是一样。它不会取代所有程序员，但它会取代那些不会用AI的程序员。

与其在那里纠结AI到底行不行，不如先用起来，边用边学。

用着用着你就会发现，原来真不是AI的问题，是你的问题。

而一旦你解决了你的问题，AI就真的成了你的超能力。

全文完，👇如果觉得有用，欢迎点赞转发关注，把最新的技术变化掰碎了讲给你听。