你的AI怀疑是财富，10种利用方式

你经历过这一幕。

看着NoSQL炒作周期。记得微服务宣称要解决一切，结果却带来一堆分布式系统的新问题，没人有时间debug。看着敏捷从一个方法论变成了“每天开站会”的代名词。知道大重构在决定两年后是什么样子。

所以当团队里的初级工程师用AI生成自己都不完全懂的代码，VP问你“AI战略”什么时候落地时，你的怀疑不是无知——而是模式识别。你见过太多颠覆性技术来了又去，承诺很多，最后只在一个小角落里找到真实位置。

问题不是怀疑正不正确——它当然正确。问题是你有没有把它用出价值。

下面10个方法，帮资深工程师和工程经理用AI真正发挥自己的经验，而不是假装不懂。

1. 用你的代码审查直觉，抓住初级工程师漏掉的问题

AI生成的代码有典型的失败模式：语法正确但语义错，只走快乐路径忽略边界情况，解决的是字面问题而不是真实问题。代码看起来完工了，其实没有。

你多年读别人代码、帮别人善后的经验，让你特别适合审查AI输出。那种“看起来对但总觉得不对劲”的直觉，恰恰是这里需要的。关键是要像对待初级工程师的PR一样，系统性地把这种直觉用在AI输出上。

对AI代码，用和新员工第一个PR同样的审查纪律：不多信任，也不少信任，就是结构化怀疑。

2. 用AI生成你本来会跳过的文档初稿

文档永远是deadline的牺牲品。你知道它重要，也被无文档系统害过。但sprint结束、测试还红的时候，你还是会跳过文档直接发版本。

AI很擅长从代码生成初版文档——不完美，会遗漏“为什么”、坑点、三年前某个周四凌晨做决定的原因。但一个60%的骨架，加上你独有的制度知识，远比什么都没有强。

粘贴一个函数，让AI写出做什么、参数含义、返回值、代码里能看出来的边界情况，并标记任何看上去可能有未记录行为的地方。

AI负责表面，你负责深度。结果就是原本不会存在的文档。

3. 让AI在方案评审里扮演对抗角色

方案评审最难的，是真正的对抗性思考。每个人都不想当“拖慢进度的人”，因此真实的弱点常常混过去。

AI对结果没有社交利益。让它做专门的魔鬼代言人。

粘贴技术设计文档，让AI找出弱点：单点故障、规模假设、缺失的故障模式、安全面，以及看上去不对但没人说出来的东西。

它发现的有时明显，有时是每个人心里想说没说的话。无论如何，你在方案真正重要之前就已经对它做了压力测试。

4. 用AI压缩对不熟悉代码库的上手时间

每个资深工程师都经历过：继承一个无文档代码库，作者两年前就离职了，下周截止。传统做法——从头读到尾、grep入口点、手动追踪执行路径——有效但慢。

AI能加速这个，但有个重要前提：你不能信任它对你代码的解释，必须自己验证。用它生成关于代码做什么的假设，然后对照实际实现来验证。AI让你更快找到正确的问题，但你仍然要回答它们。

粘贴不熟悉模块的代码，让AI解释它认为这是做什么、依赖是什么、还需要调查哪些问题。

5. 用你的事故历史做出更好的事后复盘

事故复盘通常投入不足：事故结束了，压力没了，大家都累了。结果就是只描述发生了什么，没有提取能防止下一次事故的结构性教训。

AI可以帮助系统化分析——如果你给它原始材料（时间线、因素、尝试过的方法），并让它找模式而不是总结。你的工作就是验证它识别出的模式是否匹配你对系统的理解。

粘贴事故时间线和因素，让AI分析：超出直接技术原因的系统性模式、导致问题未被发现的流程缺陷、更健壮的架构能在什么阶段捕获问题。

AI的模式分析加上你的制度知识，产生比任何一方都更好的复盘。

6. 用AI写出你一直拖延的RFC初稿

你知道需要改变什么，半年了。问题是写RFC——正式论证、备选方案、权衡——需要时间和精力，总被优先级排挤。

AI能从脑暴中生成结构化的初稿。它不会得到正确技术判断，但能给你一个可以编辑的骨架，这比白纸开始的门槛低得多。

表达想改进什么，然后给AI大脑倾泻内容，让它转成RFC格式：背景和动机、方案、备选、权衡、开放问题。特别要求“不要粉饰不确定性”。

AI倾向于让事情听起来更自信。明确要求它保留你的不确定性，会得到更诚实的草稿。

7. 用AI准备你下属还没准备好面对的对话

工程经理花大量时间进行需要仔细构思的对话：传递艰难反馈、和产品争论范围、顶住来自上层的进度压力。这些对话需要准备，但大多数EM没有时间。

AI可以帮你快速对框架做压力测试——不是为了写剧本，而是为了在对方找到你论证的弱点之前，自己先找到。

描述需要和谁、关于什么话题、你的立场。让AI尽最大努力反驳你，找出最强版本的反论。

你会得到一些你已经预想到的，也可能有一些你没考虑到的。但无论如何，你进入对话时准备更充分。

8. 用AI把技术现实翻译成领导层会行动的语言

资深技术角色常有的挫败：你清楚风险，但需要批准的人不说同样的语言。“结账流里有N+1查询模式”挪不动预算。“结账流里有时炸弹，会在[具体规模]时酿成[具体故障]”能挪动预算。

AI能帮助做这种翻译：给它技术现实，让它为特定受众重新组织。

描述技术问题，让AI从商业风险、潜在客户影响、现在修和以后修的成本来重述。不要粉饰，但不要危言耸听。

目标：产生适当的紧迫感，而不制造恐慌。

9. 用你的debug本能评估AI的解释，不只是AI的代码

当AI解释bug、架构模式、库的行为时，它可能会以深层专业知识难以察觉的方式犯错。无论对错，解释听起来都很自信、很连贯。

你的debug本能——那种让你验证假设而不是接受它们的本能——正是该用的工具。把AI解释当作假设，而不是答案。让它解释推理过程。问它：如果你的解释是错的，需要什么东西成立？

针对AI之前的解释，问它：要让它错误，需要怎样？有哪些隐藏假设？

这会让AI成为思考伙伴而不是先知，是更有生产力的关系。

10. 用“给初级解释”的提示，捕捉自己的盲点

深度专业知识会造成盲点。那些你太熟悉以至于多年没审视过的东西，有时在新语境里是错的。尤其在AI改变了某些过去决定的经济性的当下。

一个有用的习惯：偶尔让AI解释你自认为完全懂得的东西，并明确要求它挑战常见假设。

解释一个你很熟悉的概念，像对多年前学过之后没再更新过知识的资深工程师。常见假设在哪些地方失效？最近三到五年发生了什么变化，可能让旧经验不那么可靠？

常常你会发现回复确认了你的知识。偶尔你会发现一个值得拉一拉的线头。

核心原则

以上每个用法都有一个共同结构：AI处理第一稿、结构分析、模式识别，你来应用只有真正交付、debug、维护过真实系统才有的判断。

这不是妥协。这是最有效的分工。AI快速产出、不知疲倦；你稀缺、昂贵、不可替代——在判断输出是否可信、完整、适合实际问题方面。

现在从AI获益最多的工程师，不是最信任AI的那些。而是那些确切知道哪里不能信任AI的那些——而这种知识来自多年经验，无法通过prompt获得。

你的怀疑就是资产。用它。

关注更多针对过来人的实用AI内容。

Ken Iidabashi 为商业专业人士和技术领导者提供实用的AI内容。