★ FEATURED ARTICLE 打开聊天窗口敲一句“给我写一个用户登录模块”然后复制粘贴、跑通、截图这件事我现在十分钟就能教会一个初中生。但有一个东西我教不会当AI自信满满地给出两套方案你凭什么选A不选B当它交出一段看起来非常通顺的代码你在哪一行会突然停下来说“不对这里有问题”。这个“停下来的能力”就是标题里说的判断。AI 编程这两年最热闹的讨论都在工具侧谁家的补全更聪明谁家的上下文窗口更大谁家的提示词模板更好用。但我在实际项目里观察到的规律是最终拉开产出质量差距的从来不是工具熟练度而是使用者的判断力。工具是流水的兵判断是铁打的营盘这句话放在AI编程里尤其成立。把“会用AI编程”理解成“会用某个AI编程工具”是我见过最普遍的认知偏差。这篇文章想把这层窗户纸捅破聊清楚判断力到底在判什么、为什么稀缺、怎么练以及练成之后它怎么反过来帮你省钱省事。1. 工具在天上飞判断在地上走先承认一个事实AI编程工具这几年迭代速度快得离谱今天觉得惊艳的功能半年后可能就被新版模型或者新交互方式取代。如果核心竞争力建立在“会用某个工具”上那意味着每隔几个月你的技能就要贬值一次。我在团队里带过好几个新人最典型的一种学习路径是这样的先刷一遍工具的功能导览收藏几十条别人写好的提示词模板再把快捷键背熟最后就觉得自己“会AI编程”了。等到真正上手写代码问题很快暴露出来——AI生成的东西他能看懂但看不懂的地方到底是AI写错了还是自己理解错了他分不清。而分不清本质上就是没有判断力的表现。反过来看那些产出质量很稳定的开发者他们对工具的熟悉程度往往只是中上水平但有一个共同习惯AI的输出他们从来不当“答案”看而是当“候选方案”看。既然是候选就要过审。判断力是一种底盘能力它不像工具一样需要频繁跟随版本升级。哪怕明天出现一个全新的AI编程助手功能完全不一样界面完全不同只要判断力还在你上手新工具的成本最多也就是两三天但一个只会点按钮、却不知道点完之后怎么验证的人给他再好的工具也只会更快地生产错误代码。我用一个比喻来收束这层意思工具是赛车判断力是路线感。车可以越换越好但如果你脑子里没有地图车越好跑错方向的速度越快。AI编程时代最诡异的地方在于AI把“写代码”这件事变成了一脚油门的事于是方向感变得前所未有的重要——而方向感不是从任何一个工具的文档里能读出来的。判断力的本质是对“AI输出是否值得信任”的持续校准。这个校准机制依赖你的领域知识、工程经验和对需求的严格理解它比任何工具都更难被替代也更值得花时间练。2. 判断到底在判什么——四个维度的拆解“判断力”这个词太抽象了不拆开就没法练。我在日常工作中把AI编程里的判断分成四个维度每一个都对应着具体的失误模式。2.1 真伪判断它给你的是不是“正确答案”第一个维度最基础也最容易被新手忽略AI输出的代码在逻辑上到底对不对。AI生成代码有一个很迷惑人的特点它极其擅长在格式上做到无可挑剔——缩进规范、命名清楚、注释完整就像一份排版精美的保险条款。但排版的精美和内容的正确是两回事。我见过一个最典型的例子AI生成了一段处理时间字符串的代码逻辑在整点时刻之前都没问题唯独在跨小时边界时把23:59这种时间切成两半导致数据丢失。那段代码表面上看没有任何毛病甚至变量名都起得很有语义但边界条件就是错的。判断“真伪”的关键动作是主动设计反例。不要只验证“正常输入能不能跑通”而是要追问空值呢超长输入呢并发重复调用呢时区切换呢你把这些问题抛给AI生成的代码它的逻辑是否依然成立。这个动作不需要花很多时间但它需要的是一种条件反射——看到一段代码自动开始构造“让它出错”的场景。2.2 取舍判断两个方案之间哪个更适合你的场景第二个维度是方案层面的取舍。同样一个功能AI往往能给出多种实现路径甚至它会主动对你说“方案A性能好方案B代码更简洁”。这时候看起来很民主但实际上压力全在你这边——你必须拍板。举个真实的场景让AI帮你实现一个“关键词高亮”功能。方案A是在前端用正则匹配替换文本实现简单、响应快方案B是后端分词后返回高亮区间前端按区间渲染。两种方案对单个条目来说都够用但面对长篇内容、大量渲染、XSS 安全边界时取舍完全不同。没有经验的人大概率会让AI两个方案各写一遍然后比谁的代码好看有判断力的人会先问自己几个前置问题这个项目内容是谁在编辑编辑的内容能不能包含HTML未来要不要支持批量导入取舍判断的本质是把需求翻译成约束条件再用约束条件去过滤方案。AI能帮你生成方案但它不知道你的老板真正在意的是下个月能按时上线还是三年后维护成本更低——这两个问题导向的方案选择可能是相反的。而“知道自己在用什么标准做取舍”这就是判断。2.3 边界判断它不知道你的上下文所以你才是安全的最后防线第三个维度是最常出事的地方边界判断。AI没有经历你的业务背景它对你的代码库、数据流、部署环境、团队规范一无所知。你让它“优化这个接口”它只会从通用角度优化加缓存、加异步、改并发——这些优化在抽象层面都对放到你的具体上下文里可能是场灾难。我遇到过AI给我的接口加了一层本地缓存直接在内存里存了用户列表测试环境只有三个人用所以完美通过上线后第一次热点访问就内存报警。有些人把这种事故归咎于“AI不行”我认为这仍然是判断力问题。AI不知道这个接口的调用频次、不知道进程部署了几个副本、不知道用户列表更新频率——但你知道。你有责任在让AI动手之前把这类约束信息显式地给它并在它输出之后再基于自己对上下文的掌握做一次“场外审查”。边界判断大概是四者里最核心的因为它完全建立在你对项目的真实理解上这是任何通用模型都无法替代的部分。2.4 价值判断这件事到底值不值得用AI做最后一个维度很多人压根没想过这个功能/这次重构真的应该让AI来做吗或者更直白地说花这么多时间去调教AI值吗有些任务对AI来说是顺手拈来比如把一段ES5代码改写成ES6或者给一个函数补注释——这种工作让AI做是效率翻倍。但另一些任务比如排查一个只在生产环境偶现的诡异故障它需要你不断地重现场景、观察变量、结合日志做推理这种工作AI给不了实质帮助你把它喂给AI只会得到一堆似是而非的“可能性清单”反而干扰排查节奏。价值判断的核心问题是“什么不该让AI做”。AI编程的效率红利只有在正确划定边界时才存在——你越清楚哪些环节是AI的用武之地哪些环节AI只是花架子你的整体效率才越接近最优解。否则就会出现一种很尴尬的情况你明明在用一个强大的AI助手产出的速度却比纯手写还慢因为你把80%的时间花在了“让AI理解一个它永远理解不透的需求”上。这四个维度不是独立的真伪判断和取舍判断更像是在代码内部工作边界判断和价值判断则属于系统级思考。练到后面你会发现它们都在一个问题上收束你能不能给AI的输出建立一套可信度评估体系。3. 为什么独立判断这么稀缺恰恰因为它和AI的“人设”相反想练判断力得先想明白另一件事为什么大多数人天然不具备这个能力这里有一个很要命的错位。判断力的前提是“在没有外部结论给你时你能自己得出一个可信度评估”而AI这家公司——我用“公司”打比方——它的产品逻辑恰恰相反。语言模型的核心训练目标之一是生成“看起来合理的文本”。这意味着它在与你对话时倾向于给出完整、连贯、自信的回答而不是像人类专家那样频繁地说“我不确定”“这个方案可能有问题”。这不是某个具体产品的缺点而是这一类技术内在的倾向。于是协作中出现了认知错位一个倾向于表现确定性的系统遇上一个没有建立验证习惯的人类二者一拍即合形成一道正反馈——AI越自信人越放松警惕人越放松警惕AI生成代码里的错误越晚被发现。等到错误浮出水面往往已经是在生产环境里。更要命的是传统的编程教育无论学校还是公司教的大多是“怎么实现”给你一个需求教你怎么拆解、怎么编码、怎么调用API。但很少系统性地教“怎么验证”“怎么质疑”“怎么对一段已经写好的代码做同行评审”。你可以问任何一个写代码超过五年的人他工作中大量时间其实是在读别人的代码、评审别人的代码、给别人的代码做测试——但在“学习编程”的阶段这些能力几乎没被当作核心来培养。所以当AI把“写”这个环节的体力活替代掉之后整个行业对“审”的需求一下子暴露了。以前“审”是锦上添花的工程素养现在它成了使用AI的前提条件。判断力所以稀缺不是因为它有多高级而是因为我们在过去几十年的编程教育里普遍默认阅读理解能力会跟着编码能力一起长起来——实际上它不会落下了就是落下了。我另外一个观察是独立判断和“问AI”之间还存在一种微妙竞争关系。当你习惯于“遇到问题先问AI然后直接采纳”你的批判性思维肌肉会慢慢萎缩。不是说每件事都必须先自己想清楚再去问AI而是你需要分清什么是“知识性查询”——可以直接获取答案什么是“工程性决策”——答案没有标准解必须由你自己对目标、约束、代价的权衡来决定。把后者全部外包给AI等于把判断力外包出去长期看会形成一种依赖这种依赖比工具过时更可怕。所以我说判断力稀缺的第二个原因是反直觉的AI太好用好用到了会系统性地“喂养”人的懒惰而判断力是唯一能抵抗这种喂养的免疫力。它不能从AI那里获得因为AI给你的恰恰只是“看起来专业”的结论本身而不是你评估那个结论的过程经历。4. 一套可以照做的判断训练法不依赖任何具体工具前面说到判断力稀缺接下来聊怎么练。好消息是判断力不需要等机会降临日常用AI写代码的过程本身就是最好的训练场。我分享一套自己一直在用的方法全流程不依赖任何特定工具迁移到任何AI编程类产品上都成立。4.1 画基线让AI动手前先自己写验收标准绝大多数人打开AI对话框是这么开始的“帮我写一个xxx。”完了。需求模糊输出就模糊判断也就无从谈起。我自己的习惯是先不打开AI拿两分钟用最简单的语言写下验收标准。标准不是“功能描述”而是具体的边界和条件。比如“点击提交按钮后表单内容被发送到后端失败时保留已填内容成功时跳转到列表页并显示提示”——这条标准里已经包含了成功路径、失败路径、交互状态三个可验证点。写完这个我再让AI动手之后只要拿AI的输出逐条对照验收标准判断就不再是靠感觉而是靠核对。这个动作的深层逻辑是你必须有“基线”才能做出“偏差”判断。AI的输出是一个偏差量基线是你对需求的独立认知。心里没有基线你看AI的输出只会觉得“都对”因为你对“对”没有自己的定义。4.2 控制变量同一个问题逼AI用三种不同方式解判断力不是天生的它来自大量对比。所以我会刻意做一种练习在非紧急需求上同一个任务让AI用三种不同的实现思路来做。比如让AI写一个限流器方案A用滑动窗口计数方案B用令牌桶方案C直接用现成中间件。然后把三份代码放在一起拿4.1写好的验收标准逐一过筛哪份更贴合场景哪份更容易测试哪份的依赖更轻哪份在峰值流量下的行为更能预测这个过程的价值不在于选出一个最好的而在于训练“面对多个看似合理答案时你用什么维度去区分”。AI模型的训练也类似它会聚合很多种可能的写法所以它天然能给出同题异构。你只要把这个特性转化为对比训练判断力就能在一次次的取舍中越来越敏锐。4.3 逆向审查故意给它一个有坑的提示看完它是否踩中前面说的都是正向训练还有一个偏进攻型的训练方法逆向审查。操作方式很简单故意给AI设定一个容易出错的场景让它写然后用两分钟挑刺。比如你随口让它“读一个文件并按行处理”但故意不指定文件可能不存在、可能超大、可能编码不一致。看AI是不是自动化处理了这些异常还是想当然地认为文件一定存在、一定以UTF-8编码。对每一行输出问一次“如果这是同事提交的PR我会不会打回去”你会立刻发现AI代码中那些“看起来没问题但经不起问”的地方。逆向审查还有一层好处它训练你的“怀疑直觉”。长期做以后你会形成一种近乎本能的微反应读到某一行代码心里会咯噔一下——“这个函数的返回值没有校验吧”“这里怎么直接用了eval”。这种反应没法被AI替代因为在协作中永远需要一个人扮演“挑刺的评审”而AI给自己做评审时天然会偏向自己。4.4 维护判断日志错误不可怕可怕的是忘记我在手机里维护着一个文档专门记录我自己在AI协作中判断失误的例子。不是记录AI的错误——AI配合出错太常见了——而是记录在这段协作里我自己哪个环节没做到导致失误产生。比如有一次AI生成了一段批量发邮件的脚本我用测试邮箱试了完全正常但因为忘了在判断里加入“收件人数量是否有上限”这一条真实场景第一批就触发频控。后来我把“外部服务限制是否加入判断”写进了日志。再遇到AI生成的调用外部API的代码我会习惯性地比对外部服务的官方限流文档。这个日志看起来原始但它最大的意义是建立一个个人checklist。判断力不是一次性的顿悟它是无数次小修正叠加出来的。你把修正后的规则记下来才能在下次用到时一瞬间想起。否则同样的坑踩三次就谈不上判断力训练。4.5 用“判官视角”读陌生代码而不是“从头读代码”最后一个训练方式可能反常识读AI代码时别从头到尾逐行读改成“判官视角”。判官断案不会从案卷第一页读起而是先看结论摘要、再看关键证据、最后才看细节。翻译到代码审查上就是先看函数签名和返回值类型再看错误处理分支有没有然后看依赖导入和外部调用最后抽取几个关键逻辑节点仔细验证。这种跳跃式的读法效率远高于逐行通读原因在于AI生成的代码通常是站得住的你要找的是它“站不住的点”从薄弱处入手最快。我自己做了个小实验同样的AI生成代码逐行通读需要十几分钟还得注意力高度集中判官视角读法往往两三分钟就能判断出这段代码可不可信如果不可信具体哪一块不可信也基本锁定。判断力训练到后面不是让你越来越累反而是一种降本增效。这套训练方法大概持续一个月就会产生幻觉般的效果——我说的幻觉是好的那种你会开始“看到”普通代码里的风险味道。这时再回头看那些只学工具快捷键的人你会清楚地感觉到你们之间隔的不是知识量而是面对同一段输出时的默认态度。5. 当判断力变成肌肉记忆AI编程才真正开始省钱省事判断力的回报不是抽象的“能力提升”而是非常具体的现实利益。我把见过最多的收益归纳成三点少返工、少下线、少花冤枉钱。少返工是最直接的。一段代码因为边界问题被业务测试打回返工成本包括沟通、定位、重写、再测试这一套流程少说半天没了。但如果你有判断力在AI输出时扫一眼就能预判“这段代码到八月八号日期格式会炸”顺手就修了。AI编程的效率红利本质上就是判断正确率提升后的复利每次判断堵住一个坑就省下一天。这个账算不过来的人只会一直陷在“AI写得快但改得更慢”的死循环里。少下线是关于生产环境的。真实项目里我最怕的不是AI写不出代码而是它写得过于自信然后被直接部署。生产事故的代价尤其在高并发系统里不是写点补丁能弥补的一次五分钟的故障可能就耗尽了一个季度积累的信任。判断力在这里扮演的角色不是“AI看得更多”而是“人知道什么时候该踩刹车”。没有这个刹车的团队AI带来的提速越快撞墙的动能越大。我和团队合作的某模拟项目X曾经定了一条规矩凡是AI生成的涉及支付、权限、数据删除的代码必须由人对边界条件做逐项确认不许直接合并。执行这条规矩之后涉及AI代码的生产问题减少了八成左右。这并非AI变好了只是判断介入变多了。少花冤枉钱说的是工具投入和AI接口调用成本。很多团队看到新工具就采购看到新模型就接入但真正决定投入产出比的是你有没有判断“这套工具适不适合当前团队的使用水平”。一个团队如果连基本判断训练都没做过买再贵的编程AI工具也只是得到一个更会掩饰错误的助手。反过来判断力强的团队用一个免费模型也能围着边界条件写出可靠的代码把省下来的预算投到更重要的事上。肌肉记忆形成之后最明显的变化是我对待AI的态度从一个“搜索引擎式的高地位助手”降维成了一个“话痨但经常偏题的新人”。我不再觉得它的输出需要供奉起来反而像对待实习生交上来的代码一样该问就问、该测就测、该打回就打回。这个心态转变非常重要——你会真正享受AI的速度同时不再被AI的错误刺伤。它是工具你好用就拿它用它不是判官判官的位置从来没有让出去过。6. 最后一层判断力让你在AI浪潮里有选择权工具是容易替换的。今天你在用的AI编程助手明天可能因为更好的模型而退出舞台今天你辛苦背下的提示词模板下个版本可能就不再适用。但判断力恰好相反它建立在你的领域知识、工程经验和思考习惯之上不随任何工具的兴衰而起伏。这也意味着判断力给你的是选择权。当一款新工具发布时你不需要盲目追新而是可以迅速评估它的能力边界画出它适合解决的题目再决定要不要用、用在哪一层当主流叙事说“AI已经可以取代初级程序员”时你能更清醒地看到AI替代的是“把想法变成代码”的体力部分而不替代“这个想法到底靠不靠谱应该怎么落地”的脑力部分。后者恰恰是判断力管辖的领域。这几年的一个风向是越来越多人开始把“会不会用AI”当成新的技术分水岭。但我认为这个分水岭站错了位置。真正的分水岭从来不在于工具用得多熟练而在于使用者在多大程度上保有了自己独立判断的意志和能力。AI可以替代大量写代码的手动工作却替代不了你对正确性的把关、对方案的权衡、对系统边界的理解。这几样东西过去是程序员的职业核心现在仍然是而且因为AI的出现变得更加值钱——因为它们恰恰是AI唯一没法学走的那个部分。我现在的习惯是让AI写的每一段代码都先问自己一句如果这是别人给我提交的Pull Request我会不会想都不想就合掉这个问题的答案已经成了我衡量自己判断力的及格线。每次问完我都会发现值得双击“批准”的输出远比想象中少而发现问题的速度也比想象中快。这就是判断力训练出来之后的状态它不让你更轻松只是让AI每一次偷懒和犯错的成本都无处遁形。
阅读完成 · 觉得有帮助？
