亚马逊工程师:AI帮不上忙时,如何诚实记录并找到出路

亚马逊工程领导层指出,工作未从AI工具获益是发现而非失败,能解释AI边界正是工程师判断力的体现。
文章围绕亚马逊工程领导层更新中Terk Terkowitz的一段表态展开:如果工作没有从当前AI工具中获益,那是一个发现而非失败,应当记录原因、分享给同行、反馈给经理并共同寻找解决方案。作者认为,这一表态消解了工程师“不用AI就是落后”的隐性压力,把“AI无效”从尴尬重新定义为有价值的工程结论。文章进一步指出,这条行动路径将个人观察转化为组织可积累的AI适用边界知识,并通过社区分享放大单点经验。最终落脚于AI时代工程师角色的再定位:工程师不仅是工具使用者,更是能对工具做出准确判断的人,而“说清楚AI为何不适用”本身就是工程师该做的事。
亚马逊工程领导层近期就AI时代开发者的角色发布了一份更新,其中Terk Terkowitz的一段话在技术社区引发关注。这段话的核心并不复杂:如果你的工作没有从当前的AI工具中获益,那是一个发现,而不是失败。

一个被忽视的工程判断力
Terk Terkowitz的原话是这样的:
If your work does not benefit from current AI tooling, that is a finding, not a failing. Document why, share it with your community of peers, bring it to your manager, and work to find solutions. An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for.
翻译过来就是:如果你的工作没有从当前的AI工具中受益,那是一个发现,而不是失败。记录下原因,与同行社区分享,带给你的经理,并努力寻找解决方案。一个能解释清楚AI在哪些地方还帮不上自己工作的工程师,恰恰展现了我们所要求的判断力。
这句话的价值在于,它把“AI无效”从一种需要遮掩的尴尬,重新定义为一种值得记录和分享的工程结论。
为什么“记录无效”比“强行使用”更难
在AI工具被广泛推广的当下,工程师面临一种隐性压力:似乎不用AI就是落后,说AI没用就是在抗拒变化。Terkowitz的表态直接消解了这种压力。他指出,判断AI在何处不适用,本身就是一种专业能力——它要求工程师真正理解自己的工作流程、理解AI工具的能力边界,并且有勇气给出诚实的结论。
这种判断力并不比“熟练使用AI”低级。相反,它更难,因为它需要对抗从众心理,还需要用可验证的方式把结论表达出来。
从个人观察到组织知识
Terkowitz给出的行动路径很具体:记录下来,分享给同行,带给经理,一起找解决方案。这条路径把个人的“AI不适用”观察,转化为组织可以积累的知识。
文档化是一种负责任的做法
仅仅说“AI对我没用”没有太大意义,但如果说清楚“在哪个环节、因为什么原因、尝试了什么方法、结果如何”,这就成了一份有价值的工程记录。这类记录积累起来,能帮助团队识别AI工具真正的适用边界,也能为工具改进提供方向。
对于管理者而言,收到这样的反馈同样有价值。它比“大家都在用”更接近真实情况,也比“用不起来”更有建设性。
社区分享放大单点经验
把结论分享给同行社区,是这条路径中容易被忽略的一环。单个工程师的观察可能是特例,但当多个团队、多个领域的工程师都记录下类似的“AI不适用”场景时,这些分散的发现就能拼出一张更完整的边界地图。
这也是开源社区和工程博客长期在做的事:把个体经验变成公共知识。Terkowitz把这种做法明确写进了对工程师的期待里。
组织知识管理(Organizational Knowledge Management)指将个体成员的经验、洞察与判断系统性地捕获、结构化并在组织内流转的实践。在工程组织中,这类知识常以设计文档、复盘记录(postmortem)、内部技术博客等形式沉淀。其核心挑战在于隐性知识(tacit knowledge)的显性化——工程师对“何时不该用某工具”的直觉,若不落地为文字,就难以被他人复用。Terkowitz提出的“文档化—分享—反馈—求解”路径,本质上是一条轻量级的组织知识管理链路:它把一次性的个人观察转化为可检索、可讨论、可迭代的组织资产,避免同类试错在团队间重复发生。
AI时代的工程师角色:使用者还是判断者
这段话来自亚马逊工程领导层关于“AI时代开发者角色”的更新,其背后的立场值得注意:工程师的价值不只在于是不是会用AI工具,更在于能不能对工具做出准确判断。
工具素养的另一面
当前关于AI编程工具的讨论,大多集中在效率提升、代码生成质量、工作流集成等方面。Terkowitz提供了一个互补的视角:工具素养不仅包括“怎么用好”,也包括“什么时候不该用”以及“为什么用不好”。
能把后者说清楚的人,往往对系统有更深的理解,也更容易在工具快速迭代时做出正确选择。
工具素养(tool literacy)在软件工程语境中,通常指对工具能力、局限与适用场景的系统性理解,而非仅停留在操作层面。与“会用”相比,它更强调对工具内部机制的认知——例如AI代码生成工具在训练数据覆盖充分的通用任务上表现良好,但在领域特定逻辑、遗留系统耦合或强合规约束的场景中可能引入隐蔽错误。具备工具素养的工程师能预估工具的失败模式,在选型与评审时做出更稳健的取舍。这也是为什么“解释AI为何不适用”被视为一种高级能力:它要求对自身工作流与工具边界同时具备清晰认知。
给团队的实操建议
如果要把这段话落到团队实践中,可以从几个小动作开始:在技术文档中留出“AI适用性说明”的位置;在复盘会上专门讨论AI工具在哪些环节失效;把“解释AI为何不适用”视为正向贡献而非抱怨。这些做法成本不高,但能让诚实的判断在团队里获得空间。
Terkowitz的这段话之所以被广泛引用,正是因为它替很多工程师说出了那句不太好开口的话:AI很好,但它不是万能的,而指出这一点,本身就是在做工程师该做的事。
相关推荐

Last Week Tonight深扒:政客与白人至上主义的危险纽带
Last Week Tonight调查佐治亚州参议员候选人Mike Collins与佛罗里达州候选人Marshall Rawson,揭露他们与白人至上主义者的多重关联,以及共和党内的沉默反应。

AI圈爆料周:GPT-6.5泄露、Claude新模型与MiniMax性价比
本周AI圈爆料汇总:GPT-6.5疑似泄露、微软配置现GPT-6.1 Tera、Anthropic新模型能识别整类Bug、Gemini 4 Carbon早期表现失望,以及MiniMax M3.1 Flash以极低成本在基准测试中超越Claude Opus 5和GPT-5.6 Sol。

AI快讯:Gemini 4 Carbon发布,蚂蚁开源Ling-3.1
AI快讯:Google发布Gemini 4 Carbon量子位模型,宣称超越Opus 5.5且首发Token半价;蚂蚁百灵开源Ling-3.1-1019推动Personal Agent真实任务;国产AI制药19个项目18个成功,6个GPCR靶点全命中;零营收公司估值200亿美元再融10亿美元;四川便利店机器人售货失败。