先承认：模型真的很强

我是 yusanwen，一名深度使用 AI 的工程师。我承认大模型是真的强，强到逻辑推演接近无敌：让它在代码里找边界情况、做多步推理，它做得比大多数同事都快。这篇文章不是唱衰模型，恰恰相反：正因为承认它强，有个问题才值得写下来。

一个"当下完全正确"的 demo

前几天我用目前能调到的最强档 Codex 模型（5.6 sol）做一个内部小 demo。需求很小：描述几个实体、说清楚它们之间的关系，让它建一套带接口的最小系统。我没有给表结构、没有给任何存储选型约束，想看看它"自己会怎么设计"。

它交出来的东西非常干净：每个实体一张表，自增主键，实体之间全部用主键 id 互相外键关联。代码规整，测试全绿，接口能跑。一切看起来完美。

但我盯着那张 ER 图，后背有点发凉。

单看当下，主键关联没有任何问题。问题藏在一个没说出口的假设里：这套关联成立的前提，是"永远只有这一张主键表、永远只有一套存储、永远不迁移"。

只要未来有一天换库类型（比如从单库换成分库/异构存储，或者业务合并、要和另一套系统的数据对上），以主键 id 为语义的关联就全线失效：两边都有 id=1，却不是同一个东西。那时怎么办？洗数据：把几十万行关联按业务规则重映射。能做，但那是用未来的一场大手术，偿还现在省下的十分钟。

说"后背发凉"，不是这套设计错了，主键外键在大多数单库场景就是对的。凉的是：这个"对当下完全正确、对未来埋雷"的决策，全程没有任何人做过。模型默默地替你选了，而你默认了。

为什么最强的模型，选了最"平均"的方案

第一反应当然是怪模型：不是号称最强吗，连外键策略都选不好？想了两分钟，我收回这句话。

因为大模型本质上是概率模型。它产出的不是"最优解"，而是训练数据分布里的最可能解：在它见过的几千万张表里，“自增主键 + id 外键"是最常见的写法，没有之一。我描述实体和关系时没给任何反向约束，它按概率落点，自然落在最常见、最不需要解释的答案上。

它优化的是"这段设计看起来像什么”，不是"这段设计未来扛不扛得住"。更要命的是，它没有 skin in the game：换库的迁移成本是几个月后的我的，不是现在的它的。一个不用承担后果的决策者，天然倾向于选择让自己"看起来最正常"的选项，哪怕那个选项把风险往后推。

所以，凡是你没说出口的约束，概率模型都会替你平均掉。

为什么这套设计能一路绿灯

因为链条上每个环节都在奖励"快"。demo 要得急，模型写得快，自测全绿，人扫一眼觉得"挺规范的"。管理层的关注点不在主键策略上，利益也不在那里：那里要的是交付速度、团队吞吐、demo 赶紧变成能演示的东西。没有人有动力为一个"当下完全正确"的设计踩刹车。

于是模型参与越深、任务越重，这种"概率平局"的设计被无审查放行的比例就越高。不是哪个人不负责，是速度把"想清楚"这个环节压缩没了，而模型用一个看似专业的默认值，恰好补上了这个真空。它越强，输出越像资深工程师的手笔，就越没人质疑。我在这个 demo 里看到的最危险的东西，不是主键，是流畅的平庸。

解法：把约束说出口，而不是靠模型自觉

结论不是"关键设计别让模型碰"，那是因噎废食。要做的，是把被速度压缩掉的环节，重新变成显式的东西。

解法一：关系是业务语义，先写出来，再让模型建表。

“订单属于用户"是业务，“订单表加一列 user_id 外键"是实现。只给模型后者，它就会顺着 id 一路关联下去；给它前者，它才可能停下来想"该用哪个键表达这个关系”。所以我现在的做法是，做这类 demo 前先花十分钟写一段领域骨架：每个实体的业务唯一键是什么、实体之间靠什么语义关联（单号？编码？还是本就同库同生命周期？）。这段骨架不属于任何技术选型，换什么存储都成立。写清楚之后模型再怎么实现都安全，因为最危险的那个决策，已经被写下来的业务做完了。

解法二：把"换库演练"写进验收条件。

给模型的验收清单里加一条：回答"如果存储换成另一种形态，这套关联要改多少、怎么改”。它答不上来，说明关联设计偷懒了。这一步几乎零成本，却把"未来的成本"拉进了当前这一回合：模型不能只优化当下，因为验收里写了未来。有意思的是，概率模型其实答得上来这种问题，只要你问。

解法三：踩过的坑沉淀成约束，注入而不是叮嘱。

主键关联这种事，踩一次就够。但"记住"不该靠人脑，该靠系统：把反模式写进团队的编码规范，再通过 AGENTS.md / Skill / 提示词模板注入每个后续任务，比如"跨实体关联必须引用业务唯一键，或用一句话说明为什么不能"。AI 时代，编码经验的载体正在从"老员工脑子里"变成"可注入的约束文件里"。谁的约束写得全，谁的模型输出就靠谱。说白了，就是把概率模型的落点，用显式经验强行掰回来。

解法四：架构决策不外包，但让模型自证最坏情况。

实现可以外包，设计决策留一道复核：交付前让模型自己列"这个设计在哪些条件下会失效"。它列得出来，列不出来才是问题。这一条的本质是把隐性决策变成显性决策：主键外键可以选，但必须是"讨论过、知道代价"之后的选，而不是概率的默认值。

结尾：两种能力

回到开头。我承认大模型很强，逻辑能力甚至接近无敌。但这次 demo 让我更确定另一句话：

大模型的强，是"把说出口的经验变成执行"的强；而"把没说出口的经验变成决策"，暂时还得靠人。

未来能编好程序的人，一定是两种能力的组合：深谙业务，知道哪些关联是语义、哪些只是巧合；善用模型，能把业务约束、验收标准、历史教训，全部显式地喂给它。会写代码正在贬值，“能把业务说清楚"正在升值。模型写出的每一行都在替你打工，但往 prompt 里放什么约束，决定了它是替你赚钱，还是替你埋雷。编码的姿势，暂时还是值钱的。

封面图：Ivan Radic / Flickr · CC BY 2.0