北京
你问它：管道里迟到的数据事件怎么处理？它给你一套干净、现代、合理的方案——Kafka、流处理框架、状态存储。听起来完美。但你的系统里根本没有这些东西。
问题出在你怎么描述自己的系统。你说“我们用Airflow做编排，主要工作在dbt上”。这句话在技术上完全准确，但它没有告诉AI一个关键信息：这些工具是能换的，还是不能换的。
描述和约束，是两回事
当AI把你的话读成“事实”，它理解的是：你现在用Airflow，但没说不能换。于是它放心地推荐替代方案。当它把你的话读成“约束”，它才会知道：编排必须是Airflow，今年不能动；转换必须留在dbt，因为团队刚学会；可以加库，但不能加基础设施。
两种读法，给出完全不同的答案。第一种什么都没排除，所以什么方案都可能被提出来。第二种直接划掉了半个技术栈。
这不是“你没描述清楚系统”的问题。你可以把引擎版本都写全，仍然收到一个悄悄替换掉一半架构的答案。因为描述只说明“现在有什么”，没说“什么不能动”。
为什么中间层工程师最容易踩这个坑
新手通常不会被问架构问题。资深工程师会本能地先说约束——因为他们经历过方案在评审会上死掉，原因就是某个没人写下来的限制。
中间层工程师正好卡在中间：开始被问“这个该怎么处理”，这是架构问题；但描述方式还是跟同事聊天的方式。跟同事说没问题——同事知道那四百个存储过程不可能动，他跟你同组两年，这些背景不在你的句子里，在楼里。
还有第二个原因，关于约束从内部看起来是什么样。你换不掉Airflow，不是技术原因。是迁移要花一个没人有的季度，最懂它的人三月份要走。这些不像工程事实，像“客观情况”。所以它们被排除在技术问题之外——而知道这些的只有你。
三行字，把话说死
下次问架构问题，先写清楚这三行：
- 必须跑在：Airflow 2.7、现有集群、今年不加新基础设施
- 不能引入：流处理、新语言、任何需要专职运维的东西
- 团队会：SQL和dbt熟练，Python一般，Spark基本不会
这三行字，比三段系统描述有用得多。它们告诉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.
