北京
你问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“我能去哪”。后者才是它真正需要的信息。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
