你问AI如何处理管道中迟到的数据事件。它给出的答案干净、现代、合理——涉及Kafka、流处理框架和状态存储。但你的团队用的是Airflow批处理，四百个存储过程没人敢碰，上季度刚学会dbt。

答案没错，只是用不上。

打开网易新闻 查看精彩图片

问题不在AI，在你提问的方式

大多数人是这样描述现状的：“我们用Airflow做编排，主要在dbt里工作。”这句话作为事实陈述，只是背景信息——描述了你在哪，没说你要被困在这。

但AI读到的是一份“可替换清单”。你说用了Airflow，它默认你可以换掉Airflow。你没说“不能换”，它就当“可以换”。

同样的信息，换一种读法就完全不同：

  • 编排必须用Airflow，今年不能变
  • 转换逻辑必须留在dbt，因为团队刚熟练
  • 可以加库，但不能加基础设施

这才是约束。第一种说法什么都没排除，所以AI什么都不会排除。

为什么资深工程师从不犯这个错

新手通常不会被问架构问题。资深工程师会本能地先说约束——因为他们经历过方案在评审会上被毙掉，原因就是某个没人写进文档的限制。

中间层最尴尬：开始被问“这个该怎么处理”这种架构问题，却还像跟同事聊天一样描述现状。跟同事说没问题——同事知道那四百个存储过程动不了，你们在同一栋楼里待了两年。上下文不在你的句子里，在楼里。

还有第二个原因，关于约束的“体感”。你换不掉Airflow，不是技术原因——是迁移要花一个没人有的季度，最懂它的人三月要离职。这些不像工程事实，像“客观情况”。于是它们被排除在技术问题之外，而被排除的恰恰是唯一知道答案的人。

三行字，把约束说清楚

下次问AI架构问题，先写这三行：

  • 必须跑在：Airflow 2.7，现有集群，今年不添新基础设施
  • 不能引入：流处理、新语言、任何需要专职运维的东西
  • 团队会：SQL和dbt熟练，Python一般，Spark几乎不会

三行字，每个都有用。AI给的答案会立刻从“理想架构”变成“能落地的方案”。

描述现状是告诉AI“我在哪”，声明约束是告诉AI“我能去哪”。后者才是它真正需要的信息。