大模型编程实践：警惕只会打补丁的60分模型

每一代旗舰大模型发布时，数学推理基准的成绩几乎都是宣传重点：解题更快、证明更长、竞赛得分更高。可一旦把模型放进真实的编程与业务场景，许多开发者都会有类似的体感落差——分数很高，交付平庸。它不会犯致命错误，但也产不出让人眼前一亮的东西；它能把大部分测试跑通，却难以支撑一款对质量上限有要求的产品。

本文把这类模型统称为“60分模型”：数学能力可圈可点，但在工程落地与业务判断上，表现为平庸、沉闷、缺乏品味。下面先拆解它的五种典型症状，再分析“数学高分换不来业务能力”的机理，最后给出选型识别方法与工程应对策略。

一、“60分模型”的五种典型症状

1. 防御性写作：回答你问题的“隔壁”

最消耗沟通成本的行为，是不直接回答你问的问题。你调研方案A是否可行，它花大篇幅论证“B同样无法被证明更优”；你需要一个明确结论，它给你五段“取决于”。

这类输出的典型特征有三：一是答非所问，绕开核心命题做外围铺陈；二是表述模糊、不可验证，事后无法复盘它到底承诺了什么；三是用信息密度极低的铺垫稀释关键内容。更麻烦的是，这种行为很大程度上源于训练与对齐阶段形成的“求稳”倾向，属于行为模式而非偶发失误——仅靠在提示词层面叠加约束，只能压制被显式约束的部分，未被约束的角落它会继续滑回默认姿态。约束成本随场景数量线性增长，最终你会发现自己在为每一种提问方式编写防御性提示词。

2. 局部正确性陷阱：只见补丁，不见架构

给它一个缺陷，它的第一反应是就地加一个分支；再给一个边界用例，它再补一个判断。几个回合下来，代码往往长成这样：

def calc_fee(order):
    fee = base_fee(order)
    if order.type == "B2B":                     # 补丁1：企业客户打折
        fee *= 0.9
    if order.region == "EU":                    # 补丁2：地区附加费
        fee += fee * 0.05
    if order.coupon and order.amount > 100:     # 补丁3：满减叠加
        fee -= 5
    if order.vip and order.hour < 9:            # 补丁4：早间会员价
        fee *= 0.95
    # ……第12个补丁已经在路上了

每个分支单独看都是“正确”的，合起来却是一段复杂度失控、组合爆炸无法穷举测试的代码。合格的工程师会在第三四个补丁时停下来问一句：这些规则是否应该抽象成一张策略表或一个计价规则引擎？而这恰恰是此类模型最缺的动作——它从不质疑既有抽象是否错了，因为它缺少“推翻重来”的品味，也缺少对整体演进成本的责任感。业务目标就这样从视野里一点点消失，剩下的是一个个“都正确”的补丁，垒成一堵没人敢动的墙。

3. 不敢下判断：把决策成本转嫁给用户

问“两个方案选哪个”，得到“各有优劣，具体取决于场景”；追问，它开始引用“有人认为……也有人认为……”，唯独没有“我认为”。优点缺点全部模糊化处理，不排权重、不给倾向、不下结论。

这种“和稀泥”式输出对技术决策的边际价值接近于零：它把自己降级为一份检索结果的摘要器，把最终判断与担责完整转嫁给提问者。而现实中，工程师需要的是一个有观点、可被反驳、可被验证的参谋——哪怕它给出的判断只有七成正确率，也比百分之百正确的“没有判断”更有用。不敢下判断的助手，永远只能做外围综述，进不了决策环节。

4. 无法胜任需求评审：守门员失守

需求评审的本质是品味：在方案尚未落地时识别“这个设计平庸，后期必然返工”。它要求评审者同时具备业务理解、架构审美和说“不”的意愿——很遗憾，这正是“60分模型”的三重盲区。

业务理解上，它对隐性约束、组织现实与演进方向不敏感，只能看到写在字面上的需求；架构审美上，它无法区分“能用但难看”与“简洁可演进”之间的差距；意愿上，对齐训练让它天然倾向顺着既有思路往前走，极少主动给出否定性结论。后果是：平庸方案在评审环节被顺利放过，缺陷被带到下游，返工成本以数量级放大。评审时省下的十分钟，三周后可能要还三天的重构。

5. 幻觉规避的代价：以平庸换安全

幻觉当然要治理，但有一类治理策略值得警惕：把模型整体“锁”到60分，所有不确定的输出一律降级为保守模板，再叠加无穷无尽的局部校验。这套策略的安全性是真实的，代价同样是真实的。

具体而言：其一，输出上限被锁死，模型不再给出任何有风险但可能有价值的判断；其二，校验开销爆炸，为了消灭最后1%的幻觉，引入了90%的防御性代码与流程负担；其三，也是最重要的一点——它对业务目标毫无帮助。业务需要的是“在可接受风险内最快拿到80分的方案”，而不是“零风险地拿到60分方案”。用平庸换取安全，本质上是把模型从“能力放大器”降级为“不出错的复读机”。

二、为什么数学高分换不来业务能力

可验证目标与不可验证品味

数学之所以能持续突破，核心原因是它拥有明确的、可机器执行的判据：对就是对，错就是错，证明链条可以逐步核验。这意味着可以批量构造带标准答案的训练信号，让强化学习沿着“结果对错”持续优化，且每一分进步都能被基准直接度量。

而业务能力依赖的三样东西——架构品味、业务理解、判断力——恰恰没有普适判据：“这个抽象是否合理”依赖具体业务语境，无法脱离上下文打分；“这个方案是否平庸”往往是长期演进后才能兑现的隐性知识；它们难以被标准化为训练目标，于是在优化过程中天然处于劣势。一句话：训练管线擅长生产“可验证的正确”，而产品质量的上限由“不可验证的品味”决定。

宣传与现实的错位

还有一点值得甄别：被广泛传播的“数学难题重大突破”，往往出自专门强化推理的版本或更后期的迭代，而非你日常通过接口调用的通用版本。厂商愿意重点宣传数学，是因为数学可测、可比、便于讲故事；而业务品味既不可测，也塞不进发布会。这造成了系统性的认知落差——你以为买到的是“解出难题的那个模型”，实际拿到的是被层层保守策略包裹的通用版本。

三、选型实战：如何识别“60分模型”

公开基准跑分无法暴露上述问题，有效的做法是把评测拉回自己的真实任务。以下四步适合任何规模的团队：

1. 真实任务盲测。 抽取近半年你亲手完成的3~5个真实需求，脱敏后让候选模型从零实现，与实际方案对比。重点不是“能不能跑通”，而是抽象边界是否合理、演进成本是否可控。
2. 判断力测试。 准备若干“两难取舍”题，要求模型给出明确选择、核心理由与最大风险，并显式禁止“各有优劣”式表述，随后人工评估其判断质量。
3. 统计答非所问率。 准备10个目标明确的调研问题，统计有多少回答绕开了核心命题。这个数字比任何榜单都诚实。
4. 观察迭代修复行为。 故意提交一个含边界缺陷的实现，观察模型是收敛于重构，还是发散于补丁。第三轮修复后仍在加if分支的，基本可以给出结论。

其中，判断力测试可以固化成极简的自动化脚本，让“和稀泥率”从主观印象变成可跟踪的数字：

# 判断力测试：检验回答是否给出明确取舍
PROMPT = """背景：订单查询接口 P99 延迟 800ms，超出 SLA。
方案A：引入热点缓存，预估命中率70%，改动约3人日。
方案B：重构为宽表加预聚合查询，改动约3周。
请给出你的选择、核心理由与最大风险。
禁止使用"各有优劣""取决于具体场景"等无结论表述。"""
HEDGING = ("各有优劣", "取决于实际", "具体问题具体分析", "两者皆可")
STANCE  = ("我建议", "我的选择是", "优先选择", "应选择")
def is_decisive(answer: str) -> bool:
    has_stance = any(m in answer for m in STANCE)
    is_vague   = any(m in answer for m in HEDGING)
    return has_stance and not is_vague

十几行的断言当然替代不了人工评审，但多轮测试之后，不同模型在“和稀泥率”上的分化会非常明显。对于希望把评测沉淀为长期流程的团队，也可以依托百度智能云等企业级平台搭建统一的模型接入与评测流水线，让“选对模型”从一次性的主观判断，变成可持续、可回归的工程活动。

四、工程应对：让模型待在它擅长的位置

即便选定了相对更强的模型，也应当用流程设计主动规避它的短板，而不是幻想通过提示词让它“变有品味”：

1. 人机分工显式化。 架构设计、方案取舍、需求评审的最终裁决权留在人手里；模型承担可验证的实现、转换、补全与填充。一句话：让模型写代码，不要让模型定架构。
2. 用流程兜底，而非提示词兜底。 防御性写作与和稀泥是行为模式问题，提示词只能缓解。真正的兜底来自工程机制：单元测试门禁、覆盖率阈值、静态检查、强制评审。模型输出先过机器校验，再过人的品味。
3. 把业务约束显式写进上下文。 模型的平庸有相当一部分来自业务信息缺失——它不知道演进方向，自然只会打补丁。在上下文工程上投入，显式给出不变量、边界约束与“哪些补丁不可接受”，能显著压低补丁式修复的频率。
4. 建立“品味审计”。 定期抽查模型产出：本周的实现中有几个函数在第三轮修改后被重构过？补丁密度是否在上升？把品味问题转化为可观测指标，才能防止劣化在不知不觉中累积。
5. 永远不要把决策外包。 模型可以提供选项与论据，但决策与责任必须留在团队。凡是需要说“不”的场合——需求评审、方案否决、上线取舍——让有业务理解的人来执行。

五、总结

“60分模型”的真正问题不是能力差，而是能力结构错位：它在可验证任务上的严谨性极高，在不可验证任务上的品味极低；它擅长证明局部正确，不擅长判断整体好坏；它能把事情做对，却无法判断这件事值不值得做。

数学高分的价值是真实的——把确定性的、可验证的工作交给模型，收益立竿见影。但架构审美、业务理解、敢于说不的评审，这些决定产品上限的能力，目前仍必须由人来供给。正确的姿势不是等待一个完美模型，而是设计一个放大其优点、隔离其缺点的工程流程：让机器负责可验证的正确，让团队保留不可验证的品味。这样，无论下一代的基准分数涨到多高，你的交付质量都不必跟着一起坐过山车。