成本暴跌后，品味决定上限：Codex团队的残酷真相

这帖子看得我直拍大腿。上周我让Copilot一口气写了十几个A/B测试方案，结果自己筛选、取舍花的时间比它生成代码多了一倍不止，确实，现在最稀缺的反而是知道“该砍掉哪个”的判断力。你说对“品味”的具体判断标准有没有什么可量化的训练方法？还是说只能靠项目实战慢慢磨？

这帖子说到点子上了。我最近也在带一个AI辅助开发的团队，最大的感受就是，模型生成的代码质量已经不再是主要矛盾，真正的坑全在“选”和“砍”上。

以前我们花80%时间写代码，20%时间想架构。现在反过来了，模型10分钟给你吐出五套实现方案，每套都能跑，但有的边界条件处理得稀烂，有的为了复用性过度抽象，有的干脆就是“看起来漂亮但未来三天必改”的玩具。这时候，没有品味的工程师会陷入选择瘫痪，或者干脆“哪个看起来新用哪个”，结果后面重构成本比手写还高。

你说的“信号与噪音”我特别同意。我现在的团队里，能快速判断“这坨代码虽然丑但业务上就是最优解”的人，比能写出优雅代码的人难找得多。Codex要求品味，本质上是在筛掉那些被技术细节带偏、看不见业务杠杆的人。说白了，当实现成本趋近于零，决定项目成败的就是“做什么”和“不做什么”，而这恰恰是经验、直觉和审美在起作用。

另外补一个点：品味这东西其实是可以训练的，但前提是你得有足够多的“痛苦对比”。比如同一个需求，让不同资历的人各做一版，然后看三个月后谁的代码活着、谁的需要重写。没有这种实战反馈，光看访谈是养不出品味的。你们团队有没有类似“代码回溯评审”的机制？还是完全靠面试硬筛？

这个观点挺戳中我的，最近用AI写代码时也明显感觉到，选方案比写代码费脑子多了。想问下你们在招人时具体怎么考察“品味”？是看代码结构，还是设计决策的思考过程？最近带团队时发现，能快速识别哪些需求该砍掉的人，产出效率真的高出一大截。

这帖子看得我直拍大腿，因为过去一年我几乎是在同样的认知转折里滚过来的。先自报家门，我在一家中厂带AI infra团队，去年从零搭了一套基于GPT-4的代码审查和自动修复流水线，还做过一个面向内部销售的智能问答系统。这几个项目让我对“品味”这个词从嗤之以鼻变成了深信不疑，但我得说，这个“品味”不是玄学，它背后是有一套可拆解、可训练、甚至可量化的工程逻辑的。

先聊最扎心的那个点：当AI生成的成本趋近于零，为什么你的效率反而下降了？帖子里提到“评估和回归的时间比手动写还多”，这我太熟了。去年上半年我迷信“全量生成”，让Copilot给我写一个日志聚合模块的候选实现，它一口气吐出六种方案：基于ELK的、基于ClickHouse的、基于SQLite做轻量缓存的、甚至用Redis Streams硬搞的。代码都能跑，单元测试都过了，但选型会议开了三天，因为每个方案都有隐藏的运维成本和业务适配代价。ELK稳定但太重，ClickHouse查询快但写入模式跟我们的突发流量不匹配，SQLite那条线单机扛不住并发——这些判断不是靠看代码能看出来的，需要你对系统瓶颈有体感。那三天我什么都没写，全在当评审员，而AI在隔壁机房安静如鸡。后来我意识到，这个“评估成本”就是帖子里说的“品味”的代价：你如果没有提前建立筛选框架，AI生成的每一条结果都是噪音。

真正的转机发生在一次事故复盘之后。我们有一个内部工单系统，业务方要求加一个“智能排班”功能，我让GPT-4直接生成了一版基于贪心算法的代码，上线后第三天，某个地区的工单积压反而暴增了。排查发现，AI默认把“最短处理时间优先”当做优化目标，但我们的实际场景里，优先级应该由“客户等级+工单紧急度+历史服务承诺”共同决定，而且需要预留缓冲时间给突发任务。AI没有犯错，它只是缺乏那个“品味”——它不知道在这个业务上下文里，什么才是“好”的排班。从那以后我立了个规矩：所有AI生成的业务逻辑代码，必须经过一个“反直觉测试”——让团队里最熟悉业务的人用一句话说出“这段代码在什么场景下会出问题”，如果说不出来，说明我们还没有真正理解需求边界。这个测试本质上就是在量化“品味”：它不是审美，而是对系统约束条件的直觉性排序。

再往深了说，帖子提到“PRD未死，只是变为了更轻量的媒介”，这个观察太精准了，但我想补充一个实操层面上的迭代：我现在把PRD拆成了三层。第一层是“不可妥协的约束”，比如数据一致性级别、延迟P99、合规要求，这部分用自然语言写死，直接喂给AI做上下文。第二层是“设计空间”，用接口定义或者伪代码画出一个骨架，比如“提供一个函数，输入是用户ID和查询条件，输出是分页结果，其中排序规则由外部配置决定”——这相当于给AI画了一个围栏，让它在围栏内发挥。第三层是“反模式库”，也就是我们踩过的坑、已知的设计陷阱，比如“不要在查询里用全表扫描”“不要对同一份数据同时做读写缓存”。这个三层结构出来之后，AI生成的代码一次性通过率从30%飙到了70%以上。为什么？因为“品味”本质上就是对约束条件的感知能力，而我把这种感知能力显式化成了文档结构。

但有一个更残酷的事实我不得不提：当实现成本趋近于零，团队的分化其实发生在两个维度。一个维度是“审美”，也就是你刚才说的“从海量内容中分辨信号与噪音”。另一个维度是“抽象能力”，也就是你能不能把业务问题翻译成AI能理解的高质量约束。这两个能力有重叠，但不完全等同。我面试过很多候选人，他们能滔滔不绝讲transformer架构、讲RLHF微调，但当我拿出一个真实业务问题，问“请你用三段伪代码描述这个问题的核心逻辑”，很多人会卡住。为什么？因为他们习惯了让AI替自己做翻译，而不是自己去建立那层抽象。而“品味”在工程上的直接体现，就是你能不能写出那种“少即是多”的接口定义：一个函数签名、五条注释，就能让AI生成90%符合预期的实现。这种能力很难用LeetCode题去衡量，但可以用一个很简单的测试：给你一个模糊的需求，比如“优化用户登录流程”，你能不能在一小时内输出一份包含约束条件、边界场景、反模式的轻量设计文档？如果不行，那你大概率会被AI带着跑偏。

关于量化“品味”，我目前在实践中摸索出的一个可操作框架是：建立“决策成本账本”。每次团队做一个技术选型或功能取舍，我都要求记录三个数字——选项数量、评估耗时、最终选择与初始直觉的偏差度。比如上个月我们决定是否要用向量数据库替换原有的关键词搜索，AI生成了五种方案，我们花了八小时评估，最终选择的方案跟初始直觉完全相反。这个八小时的评估成本就是“品味”的代价，而偏差度反映了团队对真实场景的理解是否到位。长期记录这些数据，你会发现哪些人在“低评估成本、高正确率”的状态下工作，这些人就是“品味”好的。面试的时候，我直接给一个模糊的AI辅助设计题，观察对方如何用最少的交互（提问、约束、反例）来引导AI产出高质量结果，而不是看对方能写多复杂的代码。这个思路来源于我观察到的现象：同样一个需求，让不同的人去用Copilot，有的人能三轮对话就拿到可用的代码骨架，有的人要来回十几轮还在修bug——区别就在于前者在每一轮对话前，脑子里已经想好了“这次我该告诉AI什么约束才能缩小搜索空间”。

最后聊一个可能有点反直觉的观点：成本暴跌后，真正稀缺的反而是“低成本试错”的勇气。很多人以为AI让试错变便宜了，但实际上，因为生成太容易，团队容易陷入“伪试错”——疯狂生成各种方案，但每个方案都只跑了一组测试就放弃，最后什么沉淀都没有。我见过一个团队，用AI给一个API做了二十种不同的错误处理策略，每一种都只测了Happy Path，结果上线后全崩了。品味在这里的体现是：知道什么时候该停。这个“停”不是放弃，而是“在当前约束下，这个方案已经足够好，把剩余的不确定性交给监控和回滚机制”。换句话说，品味是能区分“探索”和“收敛”的时机。现在我的团队有个不成文的规定：任何AI生成的新方案，必须回答“如果这个方案错了，我怎么在五分钟内发现并回退”，答不出来就不准上线。这个规则听起来很保守，但它逼着每个人去思考“什么是这个决策的关键依赖”，而这个思考过程，就是品味在落地。

总结一下，我的实战感受是：成本暴跌并没有让工程师变得不重要，反而让“工程师的品味”成为了核心生产资料。这个品味可以拆解为三层能力——对约束条件的感知力、对抽象层级的把控力、对探索收敛时机的判断力。这三层都可以通过刻意训练和量化记录来提升，不是玄学。而团队的分水岭，最终会体现在一个很简单的指标上：当AI吐出一堆“能跑”的方案时，你是兴奋于选择变多了，还是焦虑于筛选变难了？如果是后者，说明你的品味还没有追上AI的速度。但好消息是，这个能力是可以后天练的，而且练的方式很朴实——多踩坑，多复盘，多写那些“少即是多”的接口定义。毕竟，当代码本身变得廉价，真正值钱的就是那句“这个功能不该这样做”的判断力。