3周写了个鸟叫生成器后，我发现AI写代码最大的坑不是幻觉

过去18个月，我用AI辅助写了大概4万行代码。上周那个把电线杆上的鸟变成音乐的项目，让我第一次意识到：之前的方法可能全错了。

事情是这样的。我给了Claude一张鸟群停在高压线上的照片，让它生成一段旋律——每只鸟对应一个音符，位置决定音高，间距决定节奏。听起来简单，对吧？

但第一次跑出来的结果，音符乱得像有人把钢琴推下了楼梯。

问题不在AI，在我

我复盘了一下自己的提示词历史。发现个规律：每次遇到bug，我的第一反应是"换种说法再试一次"，而不是停下来想——这东西到底该干什么？

鸟项目暴露了这个问题。我问Claude："根据鸟的位置生成旋律"，它照做了。但"旋律"是什么意思？大调？小调？允许多少度音程跳跃？鸟扎堆的时候怎么处理？

这些我没说。AI也没问。它猜了一个，我猜了另一个，两个猜测在运行时撞在一起，输出自然是一团糟。

这让我想起以前做产品经理时的一个教训。那时候我们团队花三个月做了个功能，上线后发现用户根本不用——因为需求文档里写的"快捷"，工程师理解成"步骤少"，用户想要的是"不用动脑子"。

同一个词，两套契约。代码只是最后那层包装纸。

契约导向编程是什么

我后来查到这个概念：契约导向编程（Contract-Oriented Programming，契约式编程）。不是新技术，Eiffel语言1986年就做了，但AI时代突然变得特别有用。

核心就一句话：先写契约，后写实现。

契约分三层。前置条件：调用这个函数前必须满足什么；后置条件：函数结束后保证什么；不变量：执行过程中什么不能变。

以前我觉得这是形式主义。直到AI开始帮我写代码——它生成速度太快，快到我来不及想清楚就接受了。契约成了刹车片。

鸟项目的第二次尝试，我先写了段自然语言契约：

「输入：鸟群坐标列表，每只鸟有(x,y)位置。输出：MIDI音符序列。规则：y坐标映射到音高（底部=C4，顶部=C6）；x坐标间距<50像素时，音符时值为16分音符，否则为8分；同一水平线上的鸟优先组成和弦而非旋律线。」

这段没一行代码。但给Claude之后，它生成的结构完全不同——不是猜测我想做什么，而是在契约框架内填空。

调试时间从3小时降到20分钟。

AI时代的契约长什么样

传统契约式编程用代码写断言（assertion，程序中的条件检查）。但和AI协作时，我发现自然语言契约更有效。

不是因为它更精确，恰恰相反——它故意模糊，逼双方在实现前对齐理解。

我现在的标准流程：第一步，用200字以内描述"这东西成功时看起来什么样"；第二步，列出3-5条不可妥协的约束；第三步，才让AI写代码。

约束的例子："用户上传的图片可能包含0只鸟，这时候要静默失败，不能报错"；"生成音乐时长必须在15-90秒之间，超出范围要自动缩放"。

这些看起来是产品需求，但写进契约后，AI的代码架构会自己长出来。它知道要处理边界情况，知道要加校验层，知道主流程该拆成几个函数。

有个反直觉的发现：契约越具体，AI的"创造性"反而越有用。因为它不用再猜规则，可以把算力花在规则内的优化上。

鸟项目的最终版本，Claude主动建议了一个我没想到的功能：根据鸟群的密度变化自动切换调式。稀疏时用五声音阶显得空灵，密集时用全音阶制造紧张感。

这个建议能落地，恰恰是因为音高映射规则已经被契约锁死了。它有发挥的边界。

从个人习惯到协作协议

我现在把这套方法用到了所有AI协作场景。甚至包括不写代码的时候。

比如让AI帮忙改邮件。以前的提示词："让这封邮件更专业"。现在的契约："收件人是推迟了两次会议的客户，目标是在不道歉的前提下表达我们仍重视合作；禁止用词：'理解您的忙碌'、'随时配合'；必须在第二段给出具体替代方案。"

输出质量的差距，就像开盲盒和定制西装的区别。

团队里也在推广。我们做了个简单的契约模板，放在每个Jira ticket的描述里：输入假设、成功标准、硬性约束、已知风险。开发开始前，人和AI先过一遍这个。

bug率降了多少还没统计，但一个明显变化：代码审查时关于"这到底该干什么"的争论少了80%。契约把扯皮前置到了设计阶段。

有个同事说这叫"用AI的方式管理AI"——不是给模糊指令等它猜，而是把思考过程外化成可检查的中间产物。

鸟项目最后上线时，我发了条推文。有人回复说听起来像"提示词工程的新瓶装旧酒"。

不完全错。但提示词工程关注的是怎么让AI听懂，契约导向关注的是怎么让自己先想明白。AI只是那个逼你显式化假设的外部压力。

没有它，我可能还会继续用"试试再说"的方式写下去——直到某个更贵的bug找上门。

你现在和AI协作时，是先扔需求过去，还是会先写一段契约？