Agent 时代开发者该练什么三个被放大的能力这个系列前 8 篇讲的都是怎么用怎么提需求、怎么验收、怎么管上下文、怎么划边界、怎么算成本。这篇换个角度聊一个更根本的问题——它把什么变便宜了于是什么变贵了。想清楚这个你就知道接下来该把时间花在哪。文章目录Agent 时代开发者该练什么三个被放大的能力零、先说清楚便宜和贵是什么意思⚠️ 一个必须澄清的误解一、先说什么在贬值说清楚避免误读二、被放大的能力一把话说清楚为什么它变贵了它具体是什么能力怎么练具体方法三、被放大的能力二把活验明白为什么它变贵了它具体是什么能力怎么练具体方法四、被放大的能力三敢拍板为什么它变贵了它具体是什么能力怎么练具体方法五、一件元能力知道自己不知道什么为什么它最难也最重要一个可用的判断标准怎么练具体方法六、把四个能力串起来一个真实场景第一步把话说清楚能力一第二步把活验明白能力二第三步敢拍板能力三第四步元能力知道自己不知道什么回到那条链七、一个诚实的提醒八、最后零、先说清楚便宜和贵是什么意思我不用AI 会取代谁这种说法因为它没法验证也没法指导行动。我用一个更简单、也更准确的模型供给变多 → 单价下降 → 稀缺度转移。具体到开发这件事上以前现在写出一段能跑的 CRUD要花几小时几分钟搭一个接口的骨架要打字半小时一句话改一个字段、加一个校验逐个文件翻一句话写出来这件事的供给暴涨了。所以能不能写出来不再是区分度所在。⚠️ 一个必须澄清的误解这不是说代码不值钱了“程序员要失业了”。它的意思是当一个动作从要花几小时变成要花几分钟它就不再是决定产出的瓶颈了。瓶颈会跑到别的地方去——而别的地方是哪才是这篇文章要讲的。打个比方计算器发明之后会算数没有失去价值但算得快不再是核心技能了。一、先说什么在贬值说清楚避免误读贬值的不是编程是敲这个动作。贬值把想法敲成代码是的这个动作的稀缺性大幅下降记住某个 API 的签名是的随用随查更快写样板代码、重复结构是的这正是它最擅长的读懂一段代码在干什么没有反而更重要了判断这段代码对不对没有反而更重要了知道该写什么没有这才是关键看最后三行“理解和判断没有贬值贬值的只有生产”。这解释了一个现象——为什么有人认为 AI 没什么用有人认为效率翻了好几倍如果你的日常工作里生产占 70%那你的效率会大幅提升如果你的工作本来就有一半在判断和决策那提升就有限。同一件工具对不同岗位的影响天然不同。二、被放大的能力一把话说清楚为什么它变贵了以前你可以边写边想——因为写的过程本身就是思考的过程。你敲着敲着思路就清楚了。现在这一步被抽走了。你必须在他动手之前就想清楚因为他不会替你想清楚的。而第 19 篇里那句判断依然成立你省略的每一条信息它都会用自己的经验去补。而它补的那一版多半和你的项目不一样。它具体是什么能力本质上是需求分析能力——只是以前它没这么关键因为你自己写代码时需求不清的地方你能靠手感补上。现在手感这条路断了。要求的能力清清楚楚子能力表现定义问题说清楚要做什么和为什么划边界说清楚不要做什么第 24 篇给验收标准说清楚我怎么知道你做对了第 20 篇给上下文说清楚项目现状和已有约定第 19 篇怎么练具体方法练法一强制用四段式。每次提需求逼自己先写这四段哪怕只在脑子里过一遍【任务】要做什么一句话 【现状】现在是什么样贴关键信息 【约束】不能做什么 【验收】我怎么判断你做对了坚持两三周就会变成习惯——因为它不是写作技巧是逼你把想清楚的东西写下来。练法二用一个残酷的检验。把这段需求原样发给另一个人或者换一个会话重新开他能照着做出来吗做不出来——那说明不是它的问题是你没说清。练法三从改需求的成本里学。它返工一次你就复盘一次是它理解错了还是我少说了一句绝大多数情况是后者。这个复盘做上十次你的表达就会精准很多。三、被放大的能力二把活验明白为什么它变贵了这是最直接的一条它一天能产出你可能要写三天的东西。所以你的验收能力就是整个流程的瓶颈。验收跟不上会怎样产出一堆你看不完、也没验的东西——产出越多风险越大。这时候效率高反而变成了负担。它具体是什么能力第 20 篇、第 26 篇给了完整的方法四层验证、6 个机械指标、反向验证测试。但这里要提炼出那个最核心的技能把一个模糊的应该能用翻译成一条命令 一个预期输出。举个例子说法水平“下单功能应该没问题”没法验“下单后应该能查到订单”还是模糊“POST /api/orders 返回 code200然后 GET /api/orders 能查到刚下这一单”可执行可验证为什么这个能力这么关键因为你写不出来的东西你也没法验。把验收标准写成一条命令的能力和判断它对不对的能力其实是同一个能力。怎么练具体方法练法一接活前先写验收标准。在让它动手之前先写下“我怎么知道它做对了”写不出来就别开工——因为你自己也不知道要什么这正是第 24 篇里自己没想清楚那一类。练法二按从便宜到贵的顺序验。第 20 篇的四层顺序不是随便排的先跑测试几乎免费→ 再看跨层行为 → 再测边界 → 最后兜底 6 个机械指标。练法三问它能不能失败。第 26 篇那招——“我把实现改坏这个测试会红吗”。这个思维可以推广到所有验证验证的强度取决于它有没有可能失败而不是它有没有通过。四、被放大的能力三敢拍板为什么它变贵了因为它会非常认真地把选项摆到你面前三种方案各自取舍写清楚成本、性能、复杂度都算给你看然后——等你决定它不会替你拍板第 24 篇讲过为什么决策依据有一半不在技术里。你还有多久交、还能投多少时间、能接受多长停机、团队里谁会维护——这些它都不知道也问不出来。这些它不知道的部分如果没人补上这个决策就没人做。它具体是什么能力子能力说明在信息不全时决策不等到全都清楚才拍板——那时候机会也没了权衡取舍明确知道选 A 放弃了什么承担后果决策是你的不是它的其中最容易被忽略的是第三条“它建议的方案出了问题”——这句话没有意义。方案是它建议的但选择是你做的。这就是你的决策。怎么练具体方法练法一强制写选择声明。每次做技术决策逼自己写一句话我选 X因为 Y代价是 Z。代价是 Z这半句是关键——写不出来说明你还没想清楚这个选择的后果。练法二警惕你觉得呢。你觉得呢是最常见的一种逃避。❌ “用 Redis 还是本地缓存你觉得呢”✅ “我倾向本地缓存因为我们只有单机、数据量小代价是将来扩多节点要改。你觉得我漏了什么”第二种问法你知道自己要什么只是让他帮你找盲点。这是把决策权留在自己手里。练法三把能不能回退当成第一考虑。这条来自第 24 篇。敢拍板的前提是错了能回头。所以好工程师拍板前会先问这个决定错了我要花多久才能改回来能快速回退的决定可以快拍不能回退的要多花时间。五、一件元能力知道自己不知道什么前面三个是能力这一个是决定你什么时候该用哪个能力的——所以叫元能力。为什么它最难也最重要因为它不表现为你不会而表现为你以为你会。第 21 篇讲过它用同样自信的语气说对的和错的。这意味着你没法靠它的语气来判断可信度——你只能靠自己的判断力。而如果你的判断力本身有问题你会遇到一个很危险的状态你以为你在验收其实你只是在读它的自述。一个可用的判断标准第 23 篇给过一句这个事实错了代价有多大代价大 →自己去核一遍花两分钟查官方文档代价小 → 大胆用这个判断本身很简单难的是意识到该判断一下。怎么练具体方法它没法通过读书练只能通过记录错误练。练法一建立我判断错了的清单。每次发现它说的不对我当时没看出来记下来。记满十条你会看到自己的盲区模式是不是总在我没用过的技术栈上翻车是不是总在看起来合理的数字上翻车是不是总在细节的实现方式上翻车这份清单比任何教程都有用——因为它是你的盲区。练法二把我不确定当成一个正式状态。遇到你说不准的地方明确标注这块我没验而不是含糊过去。第 24 篇那句话说得很准“我没办法验证’和’它是对的’是两个完全不同的状态但表现一模一样。”把没验说出来是让它回到不同状态的唯一办法。六、把四个能力串起来一个真实场景上面四节是分开讲的但它们不是四个独立的能力而是一条链。用一个真实场景过一遍——给二手书交易网站加下单扣库存。第一步把话说清楚能力一差的说法帮我加一个下单扣库存的功能好的说法【任务】下单时扣减图书库存 【现状】t_book 有 stock 和 version 字段 统一返回体 R{code,msg,data} 已有 OrderService.create 方法 【约束】只改 OrderServiceImpl 和 BookMapper不要新建文件 不要动返回体结构 【验收】下单成功后 stock 减 1 库存不足时下单失败且不产生订单 并发下不能超卖注意最后一条并发下不能超卖——这一句会引出后面两步。如果你没写这句它会给你一个能跑但对并发不安全的实现。第二步把活验明白能力二现在问题来了怎么验并发下不能超卖它多半会给你一个看起来在测的测试——手动把 stock 设成 0断言抛异常。但那个测试永远通过验不到真正的竞态。这就是第 26 篇讲的坑。所以你要能看出这一点并且要求请写一个测试两个线程同时购买库存为 1 的书 只能有一个成功另一个必须失败。 写完后把库存判断逻辑故意改坏跑一遍 告诉我哪些测试还是绿的。这一步考的是你知道该验什么也知道怎么验才算数。第三步敢拍板能力三接着它会给你选项方案取舍悲观锁SELECT ... FOR UPDATE简单可靠但并发下会排队、吞吐低乐观锁WHERE stockn AND version?无锁、吞吐好但冲突高时要重试分布式锁Redis能跨节点但复杂度高、多一个依赖它讲完然后等你决定。而它的分析里缺了一样东西你的实际情况。你这个系统并发有多高二手书网站大概率不高你要部署几个节点大概率就一个你还有多少时间毕设时间紧把这些补进去答案就很清楚了我选乐观锁因为单机、并发不高、无锁性能好代价是高冲突时会有重试需要处理失败重试逻辑。技术最优解 ≠ 你的场景下的最优解。补上你的约束这一步只能你做。第四步元能力知道自己不知道什么最后一步最容易被跳过它说乐观锁用WHERE stockn AND version?影响行数为 0 就抛异常回滚。你要判断这句话可信吗我需要核吗按错了代价多大来判断它说的错了代价你要做的“version字段要加在t_book表上”小改表就行直接信“影响行数为 0 抛异常会自动回滚”大如果不会回滚就是脏数据自己确认一遍事务边界“这个写法在 MySQL 8.0 下没问题”大版本差异可能导致行为不同查一次官方文档同一段话里哪些信、哪些要核——这就是元能力在起作用。回到那条链你有没有发现说清楚含不能超卖这句 → 才知道该验什么 → 才知道要选哪个锁方案 → 才知道它哪句话要自己核四个能力是连着的。第一步没做好后面三步全部落空。而且注意这条链里没有写代码这一步——那一环已经交给它了。这就是我开头说的瓶颈转移到别的地方的具体样子。七、一个诚实的提醒写到这我要说一句可能有点扫兴的话这三个能力 一个元能力都不是新东西。它们本来就是工程师的基本功——需求分析、测试、技术决策、自我认知。那为什么现在要专门讲因为它们以前被写代码这件占时间最多的动作盖住了你一天有六小时在敲代码把话说清楚只占二十分钟——所以它显得不重要你有大量时间可以边写边想所以**提前想清楚看不出差距**验收主要是验自己的代码所以**设计验证方案这件事被顺手做了**现在写这一步被抽走了这些被盖住的能力全部露了出来。所以这篇不是在教你学新东西是在提醒你把本来对的东西重新排到前面。这也解释了那个现象——为什么有人用 Agent 效率提升巨大有人用了一阵就放弃了差距不在会不会用工具在基本功。基本功好的人能说清 → 能验收 → 敢拍板 → 知道自己不知道什么。Agent 是他的放大器。基本功弱的人说不清 → 验不了 → 不敢定 → 也不知道自己错了。Agent 只是把他的混乱加速了。八、最后回到那个模型供给变多 → 单价下降 → 稀缺度转移。工具做的所有事都是让执行变便宜。但它不会让判断变便宜。而判断力这件事——它没法被外包也没法被生成。所以如果只能记一句话它越强你的基本功越值钱。因为它放大的永远是你本来的水平——包括你本来的问题。互动时间你觉得用 Agent 之后自己的哪种能力被明显放大了又有没有哪种能力暴露出了短板我自己感受最深的是第二条——验收。以前我觉得自己挺会验的用了一段时间才发现我能判断跑起来了没有但很难说出它错了我要多久能发现。这条是练出来的不是看出来的。评论区聊聊你的短板在哪。系列回顾《AI 写的测试全绿但可能什么都没验》 · 《用 Agent 最贵的不是订阅费一份被算错了很多次的成本账》作者另有 18 篇运维实战文章部署 / 监控 / 排查 / 备份 / 安全见 个人主页。