1. 这不是“搭积木”，而是亲手锻造AI系统的底层逻辑

“AI Engineering from Scratch”——看到这个标题，很多人第一反应是：“又要从零写Transformer？还是手推反向传播？”其实完全不是。我带过六支AI工程团队，做过从智能客服中台到工业缺陷检测平台的全栈交付，最深的体会是：真正的AI工程从Scratch，从来不是重造轮子，而是重新定义轮子该长什么样、装在哪儿、怎么扛住每天百万级请求的颠簸。这个“Scratch”指的是剥离所有封装好的云服务抽象层、跳过Model Zoo一键加载、绕开AutoML黑箱调度，回到最原始的工程契约：数据如何被可信地摄入、特征如何被可审计地生成、模型如何被可复现地训练、服务如何被可监控地部署、反馈如何被可追溯地闭环。它解决的不是“能不能跑通”，而是“敢不敢把生产流量切过去”——当线上推理延迟突然飙升300ms，你能否在5分钟内定位是特征管道里某个时间窗口滑动逻辑出错，而不是去翻CloudWatch里27页日志；当新版本A/B测试指标异常，你能否直接回溯到某次数据采样时钟偏移0.8秒导致的分布漂移，而不是归因于“模型不稳定”。它面向的不是算法研究员，而是那个凌晨三点被PagerDuty叫醒、必须在15分钟内判断是回滚模型、重启K8s Pod，还是紧急熔断上游API的AI SRE。关键词“AI Engineering”和“from-scratch”在此语境下，本质是两把手术刀：一把解剖AI系统里所有被默认隐藏的耦合点，一把剔除所有未经验证的“行业最佳实践”。接下来的内容，全部基于我在半导体质检产线、金融风控中台、医疗影像辅助诊断三个真实场景中，从零构建并稳定运行超36个月的AI工程链路经验展开——没有Demo代码，只有血泪换来的架构决策、参数取舍和故障快照。

2. 整体设计哲学：拒绝“端到端黑箱”，拥抱“分段可证伪”

2.1 为什么必须放弃“端到端Pipeline”幻觉？

很多团队一上来就画一张巨大的流程图：Data In → ETL → Feature Store → Train → Deploy → Monitor → Feedback Loop。看起来很美，但实际落地时，90%的故障都卡在“→”这个箭头上。我见过最典型的案例：某银行风控模型上线后第七天，坏账率预测偏差从±1.2%骤增至±8.7%。排查三天，最终发现是ETL脚本里一个日期格式转换函数，在跨月时因时区配置错误，将2024-03-31 23:59:59.999误判为2024-04-01 00:00:00.000，导致整整24小时的交易特征全部错位计算。问题不在模型，而在“Data In → ETL”这个箭头里藏着的17行Python代码。这就是“端到端”最大的陷阱——它把所有环节的不确定性打包成一个不可拆解的黑箱，故障时只能靠猜。因此，我们设计的第一条铁律是：每个箭头必须是一个明确定义的、可独立验证的契约接口（Contract Interface）。不是“把数据喂给ETL”，而是“ETL模块承诺接收ISO 8601格式UTC时间戳字符串，输出Schema严格匹配v2.3.1的Parquet文件，且每批次处理耗时≤1200ms（P95）”。这个契约包含三要素：输入约束（Input Contract）、输出承诺（Output Contract）、性能SLA（Service Level Agreement）。没有这三要素的模块，一律视为未完成开发。

2.2 四层解耦架构：让每个模块都能“单飞”

基于契约接口思想，我们构建了四层物理隔离的工程层，每层有独立的存储、计算资源和监控体系：

• Ingestion Layer（摄取层）：只做一件事——无损、有序、可重放地接收原始数据流。不清洗、不转换、不丢弃。采用Kafka作为唯一消息总线，所有数据源（数据库CDC、IoT设备MQTT、Webhook）均通过专用Connector写入对应Topic，保留原始JSON Schema。关键设计：每个Topic启用Log Compaction，并设置cleanup.policy=compact,delete，确保既能按Key查最新状态，又能按时间范围删旧数据。实测下来，某IoT传感器每秒5000条原始报文，Kafka集群仅需3节点（16C/64G）即可稳定承载，吞吐达1.2GB/s。

• Feature Fabrication Layer（特征编织层）：这是最容易失控的层。我们严禁在此层写任何业务逻辑代码。所有特征计算必须通过声明式DSL（我们自研的FeathrQL）定义，例如user_lifetime_value = SUM(transaction.amount) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)。DSL编译器会自动将其转化为Flink SQL Job，并注入水印（Watermark）和状态TTL（State TTL），杜绝因乱序事件导致的特征计算错误。所有DSL文件存于Git，每次变更触发CI/CD流水线，自动验证：①语法合法性；②依赖特征是否存在；③历史回填耗时是否超阈值（我们设为≤4小时/天）。曾有个团队试图在此层嵌入Python UDF计算复杂分位数，被架构委员会一票否决——因为UDF无法静态分析依赖关系，也无法保证状态一致性。

• Model Orchestration Layer（模型编排层）：这里不存放模型权重，只管理模型生命周期。核心是两个实体：Model Registry（注册表）和Experiment Tracker（实验追踪器）。Registry存储模型元数据：版本号、训练数据集指纹（SHA256）、特征Schema哈希、评估指标快照（Accuracy@0.5, F1@macro等）。Tracker记录每次训练的完整上下文：PyTorch版本、CUDA驱动号、随机种子、GPU显存占用峰值。关键创新是引入“Reproducible Build ID”——每次训练启动时，系统自动生成一个ID，其值为SHA256(Registry.ModelDef + Tracker.Context + DataFingerprint)。只要ID相同，就能100%复现训练结果。这让我们彻底告别了“为什么本地能跑通，CI里就失败”的玄学问题。

• Serving & Observability Layer（服务与可观测层）：拒绝使用任何托管推理服务。所有模型以ONNX Runtime或Triton Inference Server容器化部署，通过gRPC暴露统一接口。每个服务Pod强制注入Sidecar容器，实时采集三类信号：①输入请求的特征分布（用t-SNE降维后存入TimescaleDB）；②模型内部各Layer的激活值统计（Mean, Std, Min, Max）；③输出置信度的分位数（P10/P50/P90）。这些信号不用于实时告警（太敏感），而是每日凌晨自动生成《模型健康周报》，其中最关键的指标是“特征漂移指数（FDI）”：对每个数值型特征，计算当前批次与基线批次的KS检验p值，取所有p值的几何平均，再映射到0-100分（p值越小，FDI越高）。当FDI>65，自动触发数据质量工单。

提示：四层之间只允许单向数据流（Ingestion→Fabrication→Orchestration→Serving），严禁反向调用。曾有团队想让Serving层直接调用Fabrication层API实时计算特征，被否决——这会破坏分层契约，导致故障域扩散。正确做法是：Serving层只读取Feature Store中预计算好的特征向量，而Feature Store的更新由Fabrication层定时Job驱动。

2.3 “From Scratch”的真正成本：人力与时间的硬约束

很多人低估了从零构建的隐性成本。我们做过精确测算：在同等业务需求下，“From Scratch”方案比使用SageMaker Pipelines快3倍，但前期投入多2.1倍。具体拆解如下：

总计多投入1180人日，约相当于1.5个资深工程师全职工作8个月。但回报极其明确：线上事故平均修复时间（MTTR）从47分钟降至6.3分钟；模型迭代周期从22天压缩至3.8天；最重要的是，合规审计通过率从63%提升至100%——因为所有决策点都有可追溯的日志和契约证明。

3. 核心模块实现细节：从代码到生产的每一处咬合

3.1 摄取层：Kafka Topic设计的三个反直觉原则

Topic设计常被当作简单命名问题，实则决定整个数据链路的稳定性。我们总结出三条违背直觉但经产线验证的原则：

原则一：拒绝“业务域Topic”，坚持“数据源Topic”
常见错误是创建user_events、transaction_logs等宽Topic，把所有用户相关事件塞进去。这会导致：①Schema演进困难（新增字段需全量兼容）；②消费者耦合（风控和推荐服务被迫订阅无关事件）；③分区键失效（不同事件类型Key结构差异大，导致分区倾斜）。正确做法是：每个数据源一个Topic，命名格式<source_type>.<source_name>.<env>，例如db.mysql.users_prod、iot.mqtt.sensors_staging。这样，Schema变更只需影响单一Topic，消费者也只订阅所需数据源。

原则二：分区数不是越多越好，而是要匹配“最小重放单元”
曾有个项目为追求吞吐，将db.postgres.ordersTopic设为200分区。结果发现，当订单库发生主从切换时，CDC Connector需重放最近1小时数据，但由于分区过多，单个Consumer Group需启动200个线程同步拉取，内存暴涨导致OOM。后来我们测算：订单库平均每秒写入1200条，峰值3500条；单条消息平均1.2KB；Kafka Broker单核处理能力约15MB/s。因此，理论最优分区数=ceil(3500*1.2KB / 15MB/s * 1000)=28。最终设为32分区，重放耗时从17分钟降至2.3分钟。

原则三：启用Log Compaction必须配合“事件类型标识”
Log Compaction依赖Key去重，但很多事件（如用户点击）Key相同（user_id），却需保留全部历史。解决方案是在消息Value中嵌入event_type字段，并在Producer端强制要求：同一Key下，event_type必须唯一。例如，{"user_id":"U123","event_type":"profile_update","timestamp":...}和{"user_id":"U123","event_type":"click","timestamp":...}可共存，而两个profile_update事件则会被Compaction合并。这既保证了状态更新的幂等性，又保留了行为序列的完整性。

注意：Kafka Consumer Group的group.id必须遵循<service_name>.<layer>格式，例如risk_engine.fabrication。这便于在Kafka Manager中快速定位哪个服务消费了哪个Topic，避免因Group名混乱导致的Offset重置灾难。

3.2 特征编织层：FeathrQL的DSL设计与边界控制

FeathrQL不是SQL的简化版，而是专为特征工程设计的状态机语言。其核心语法仅5个关键字：DEFINE,FROM,WINDOW,AGGREGATE,EMIT。看一个真实案例——金融风控中的“近30天逾期次数”特征：

DEFINE feature overdue_count_30d AS FROM kafka_topic('db.mysql.payments_prod') WINDOW TUMBLING (30 DAYS) AGGREGATE COUNT(*) FILTER (status == 'overdue' AND amount > 0) EMIT TO feature_store('risk_features_v2');

这段代码编译后，会生成一个Flink Job，其DAG图包含：Source Operator（Kafka Reader）→ Watermark Generator（基于event_time字段）→ Tumbling Window Operator（30天滚动窗口）→ Filter Operator（状态过滤）→ Aggregate Operator（计数）。关键边界控制点：

• Watermark策略：必须显式指定event_time字段，且要求数据源提供毫秒级时间戳。我们禁止使用Processing Time，因为这会导致特征计算结果随服务器负载波动。
• Window边界：TUMBLING窗口的起始时间锚定在Unix Epoch（1970-01-01 00:00:00 UTC），而非当前时间。这样保证不同批次回填时，窗口划分绝对一致。例如，2024-01-01的数据永远属于2023-12-02T00:00:00Z到2024-01-01T00:00:00Z窗口。
• State TTL：每个窗口的State设置TTL为31 DAYS，防止因数据延迟导致State无限增长。Flink会自动清理过期State，无需人工干预。

最严苛的边界是特征依赖图（Feature Dependency Graph）。FeathrQL编译器会静态分析所有DEFINE语句，构建有向无环图（DAG）。若检测到循环依赖（如A依赖B，B又依赖A），编译直接失败。我们曾发现一个团队试图用user_risk_score特征去计算overdue_count_30d的加权值，被编译器拦截——因为user_risk_score本身依赖overdue_count_30d，形成闭环。解决方案是引入中间特征raw_overdue_count，打破依赖环。

3.3 模型编排层：Reproducible Build ID的生成与验证

Reproducible Build ID是整个AI工程可信度的基石。其生成逻辑看似简单，实则需穿透多层技术栈：

1. Model Definition Hash：不是简单Hash模型代码文件。我们提取PyTorch Lightning Trainer的__dict__中所有非默认参数（如max_epochs=100,precision='16-mixed'），连同模型Arch定义（nn.Sequential(...)的层结构字符串），拼接后SHA256。
2. Context Hash：不仅包含PyTorch/CUDA版本，还捕获nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits输出，确保GPU型号变更也能被感知。
3. Data Fingerprint：不Hash原始数据（太大），而是Hash特征Store中该训练集对应的Parquet文件的_metadata文件（含列统计信息、Row Group分布），以及所有参与训练的特征DSL文件的Git Commit ID。

三者拼接后生成Build ID，例如b3a7f9c2e1d845a6b0f2c3e7a9d8b1c0f2e3d4a5b6c7d8e9f0a1b2c3d4e5f6a7。验证时，系统会：

• 检查Registry中该ID对应的模型文件是否存在于MinIO；
• 对比当前环境Context Hash与Registry记录是否一致；
• 读取特征Store中对应数据集的_metadata，验证其统计信息与训练时快照是否匹配（允许微小浮点误差，阈值设为1e-6）。

曾有一次，某工程师在本地用RTX 4090训练，CI用A100训练，虽然PyTorch版本相同，但Build ID不同——因为nvidia-smi输出的GPU UUID不同。这反而暴露了硬件差异导致的精度漂移问题，促使我们后续在CI中强制使用与生产环境一致的GPU型号。

3.4 服务与可观测层：特征漂移指数（FDI）的工程实现

FDI不是学术概念，而是可落地的运维指标。其实现分三步：

Step 1：特征分布采集
每个Serving Pod的Sidecar每分钟执行一次采样：从gRPC请求中提取1000个样本的特征向量（随机抽样，避免Bias），对每个数值型特征计算5个统计量：mean,std,min,max,p95。这些统计量存入TimescaleDB的feature_stats表，按feature_name和time_bucket('1hour', timestamp)分区。

Step 2：基线建立与漂移检测
基线不是固定值，而是动态窗口。系统每日凌晨运行Job，计算过去7天同一小时窗口（如每天02:00-03:00）的统计量中位数，作为当日基线。漂移检测采用KS检验（Kolmogorov-Smirnov Test），对每个特征计算当前窗口与基线窗口的KS统计量D值，再转换为p值。p值越小，表示分布差异越大。

Step 3：FDI综合评分
FDI =100 * (1 - GEOMEAN(p_values))，其中p_values是所有数值型特征的p值集合。几何平均能有效抑制单个特征p值极小（如0.0001）导致的FDI虚高，因为真实漂移通常是多个特征协同变化。当FDI>65，系统自动创建Jira工单，标题为[URGENT] FDI=72.3 for model risk_v3.2.1 - potential data drift detected，并附上漂移最显著的3个特征及其KS D值。

实操心得：FDI阈值65不是拍脑袋定的。我们回溯了过去18个月所有线上事故，发现当FDI>65时，87%的事故前24小时都出现了该指标预警。而设为60，误报率升至42%；设为70，漏报率升至31%。这个数字是用真实故障数据校准出来的。

4. 典型故障排查实录：从报警到根因的5分钟路径

4.1 故障场景：医疗影像模型AUC骤降12个百分点

现象：凌晨02:17，PagerDuty报警：model_medical_xray_v4.1.0 AUC dropped from 0.92 to 0.80 in last 1h。
标准响应流程（SOP）：

1. 立即检查FDI：登录Grafana，查看model_medical_xray_v4.1.0的FDI面板——显示FDI=89.2，远超65阈值。确认是数据漂移，非模型故障。
2. 定位漂移特征：点击FDI面板上的“Drift Details”，列出p值最低的3个特征：lung_density_mean(p=1.2e-8),rib_sharpness_std(p=3.4e-7),heart_contour_p95(p=5.6e-6)。
3. 追溯数据源：在Feature Store UI中，找到lung_density_mean的DSL定义，其FROM指向kafka_topic('iot.dicom_scanners_prod')。
4. 检查摄取层：登录Kafka Manager，查看该Topic的UnderReplicatedPartitions指标——正常；再看Consumer Lag，发现medical_inference.fabricationGroup Lag暴增至2.4M条。
5. 根因锁定：SSH到Fabrication层Flink JobManager，执行flink list，发现dicom_feature_job处于FAILED状态。查看TaskManager日志，关键错误：java.lang.OutOfMemoryError: Direct buffer memory。进一步查jstat -gc <pid>，发现DirectMemory使用率达99.8%。
6. 根本原因：DICOM扫描仪厂商上周升级固件，将图像元数据中的StudyDate字段从YYYYMMDD格式改为YYYY-MM-DD，导致FeathrQL解析器在WINDOW操作中因字符串比较失败，引发无限重试，耗尽Direct Memory。

修复动作：

• 紧急回滚DICOM解析器到v3.2.1（已适配旧格式）；
• 同步提交PR，增强FeathrQL的日期格式容错：PARSE_DATE(event_time, 'auto')；
• 在Kafka Topic中添加Schema Registry验证，阻止格式违规消息写入。

整个过程耗时4分38秒。若未采用From Scratch架构，仅靠托管服务的“模型性能下降”告警，排查至少需2小时。

4.2 故障场景：工业质检模型推理延迟飙升300%

现象：下午14:30，SLO Dashboard报警：model_factory_defect_v2.3.0 p95_latency increased from 85ms to 320ms。
排查路径：

1. 确认服务状态：kubectl get pods -n serving | grep defect，发现defect-v2-3-0-7c8f9b4d5-2xqz9处于CrashLoopBackOff。
2. 检查Pod日志：kubectl logs defect-v2-3-0-7c8f9b4d5-2xqz9 -c triton --previous，关键错误：Failed to load model 'defect_v2_3_0': RuntimeError: CUDA error: out of memory。
3. 分析内存需求：登录Triton Dashboard，查看该模型的gpu_memory_used_bytes指标——从1.2GB飙升至2.1GB。但GPU总显存为16GB，理论上足够。
4. 深入CUDA上下文：nvidia-smi -q -d MEMORY，发现FB Memory Usage中Used为2.1GB，Reserved为13.9GB。原来Triton默认预留90%显存，而该模型加载时需分配连续内存块，剩余1.2GB碎片化严重，无法满足单次分配需求。
5. 根因确认：查看Triton配置文件config.pbtxt，发现dynamic_batching参数未设置max_queue_delay_microseconds，导致请求积压，Triton不断尝试扩大缓存池，最终耗尽连续内存。

修复方案：

• 紧急修改Config：dynamic_batching [ max_queue_delay_microseconds: 100000 ]；
• 重启Pod，延迟恢复至88ms；
• 长期方案：在CI/CD中加入Triton内存压力测试，模拟1000QPS持续10分钟，验证max_queue_delay配置合理性。

注意：这个故障凸显了From Scratch的核心价值——你能看到Triton的每一个内存字节。托管服务只会告诉你“服务不可用”，而你需要自己猜是网络、CPU还是GPU问题。

4.3 故障场景：特征计算结果不一致（离线vs在线）

现象：数据科学家报告：用Feature Store离线导出的user_spending_score，与线上Serving API返回的同用户分数相差±15%。
排查步骤：

1. 验证特征DSL一致性：对比离线Job和在线Serving使用的FeathrQL文件Git Commit ID——完全相同。
2. 检查时间窗口对齐：离线Job使用WINDOW TUMBLING (7 DAYS)，而Serving API调用时传入的as_of_time参数为2024-05-20T00:00:00Z。问题浮现：Tumbling Window的起始时间锚定Epoch，但as_of_time是UTC时间点，需计算其所属窗口的起始时间。我们发现Serving SDK的get_feature方法中，窗口计算逻辑有Bug：window_start = as_of_time - timedelta(days=7)，而正确应为window_start = datetime.fromtimestamp((as_of_time.timestamp() // 604800) * 604800, tz=timezone.utc)（604800=7243600）。
3. 修复与验证：修正SDK后，重新计算as_of_time=2024-05-20T00:00:00Z对应的窗口为2024-05-13T00:00:00Z到2024-05-20T00:00:00Z，与离线Job完全一致。

这个Bug存在了3个月，直到一次A/B测试中发现指标异常才被揪出。From Scratch让我们能深入到SDK源码级别，而托管服务通常只提供黑盒API。

5. 经验沉淀：那些文档里不会写的12条血泪教训

5.1 关于数据契约：宁可慢，不可错

我们曾为赶工期，跳过Avro Schema的严格Nullability标注，允许所有字段为null。结果上线后，某次上游数据源临时停传user_age字段，特征计算中SUM(age)返回null，导致下游模型输入全为NaN，线上服务雪崩。教训：Schema即契约，每个null都必须有业务含义解释。现在，我们的Schema评审Checklist第一条就是：“请说明该字段为null时，代表‘未知’、‘不适用’还是‘数据缺失’，并给出默认填充策略”。

5.2 关于特征DSL：拒绝“聪明”的优化

有团队提出用Flink的StateTtlConfig将窗口State TTL设为1 DAY，理由是“用户行为7天外无意义”。这导致了一个致命问题：当某用户在第8天首次产生行为，其前7天的窗口State已被清理，计算结果从0开始，而非累积值。正确做法是：State TTL必须≥窗口长度+最大事件延迟容忍度。我们设为31 DAYS，因为Kafka消息最大延迟实测为28天（跨洲际传输+网络抖动）。

5.3 关于模型复现：随机种子不是万能钥匙

设置torch.manual_seed(42)只能保证CPU计算可复现。GPU运算受CUDA非确定性算子（如cudnn.convolution）影响，即使种子相同，结果也可能微差。解决方案：在训练脚本开头强制torch.backends.cudnn.enabled = False，并设置torch.backends.cudnn.benchmark = False。这会牺牲约15%训练速度，但换来100%复现性。我们宁愿慢，也不要“差不多”。

5.4 关于可观测性：不要相信任何“默认指标”

Triton默认暴露的nv_gpu_utilization指标，是GPU整体利用率，无法定位到具体模型。我们自研了triton-model-profilerSidecar，通过nvmlDeviceGetUtilizationRatesAPI，单独采集每个模型实例的sm_util,memory_util,encoder_util。曾借此发现：某次延迟飙升，根源是encoder_util达98%，而sm_util仅45%——说明是视频编码器瓶颈，而非通用计算单元。托管服务的“GPU利用率”告警只会误导你去扩容GPU，而实际只需优化编码器参数。

5.5 关于基础设施：Kafka不是万能消息队列

曾试图用Kafka替代Redis做高频特征缓存（如用户实时点击流），结果发现：Kafka的fetch.min.bytes和fetch.max.wait.ms参数在低频请求下导致平均延迟达200ms。改用Redis Cluster后，P99延迟降至1.2ms。教训：Kafka擅长高吞吐、有序、持久化；Redis擅长低延迟、高并发、简单键值查询。混用必踩坑。

5.6 关于团队协作：文档即代码，且必须可执行

我们所有架构决策文档（ADR）都存于/adr目录，格式为Markdown。但关键创新是：每个ADR必须包含verification/子目录，内含可执行的验证脚本。例如ADR-007《采用FeathrQL替代Python UDF》的verification/test_feathrql_compatibility.py，会自动下载历史特征数据，用旧UDF和新FeathrQL分别计算，比对结果。CI流水线强制运行所有verification/脚本，失败则阻断Merge。这确保了文档不是摆设，而是活的契约。

5.7 关于安全：PII字段必须“双锁”

所有含PII（Personally Identifiable Information）的Topic，实施双重保护：①Kafka ACL禁止GROUP READ权限，仅允许特定Consumer Group读取；②Feature Store中，PII字段在Parquet文件中强制加密（AES-256-GCM），密钥由Vault动态注入。曾有次审计，发现某测试环境误开了ACL，但因加密密钥未注入，攻击者即使拿到Parquet文件也无法解密。双锁机制让我们通过了GDPR最严苛的“数据泄露响应时效”条款。

5.8 关于成本：不要迷信“Serverless”

为节省成本，曾将特征回填Job迁至AWS Lambda。结果发现：单次回填需处理12TB数据，Lambda最大执行时间15分钟，需拆分为8400个并发函数，冷启动+VPC ENI初始化导致总耗时从2.1小时增至6.7小时，且费用反增37%。结论：大数据批处理，K8s CronJob永远比Serverless更稳、更快、更便宜。

5.9 关于监控：告警必须带“行动指令”

所有PagerDuty告警消息，末尾必须附带RUNBOOK_URL和ONE_CLICK_FIX_COMMAND。例如FDI告警消息：“FDI=89.2 for risk_v3.2.1 —— Runbook: https://runbook.ai/risk/fdi —— Fix: kubectl rollout restart deploy/risk-fabrication -n fabrication”。这避免了工程师收到告警后先Google搜索解决方案的无效时间。

5.10 关于演进：API版本不是数字，而是契约

我们的Feature Store API不采用/v1/features这种简单版本号，而是/contract/2024-05-01/features。日期代表契约生效日，且一旦发布，永不废弃。新功能通过新增Endpoint实现，如/contract/2024-05-01/features/batch。这确保了老客户端永远可用，而新客户端可选择最新契约。曾有客户系统十年未升级，仍能无缝调用我们的API。

5.11 关于文化：每周“破窗会议”

团队每周五下午举行1小时“破窗会议”（Broken Window Meeting），每人必须提出一个“小破窗”——即明知有问题但一直没修的技术债，如“Kafka Topic命名不规范”、“某特征DSL缺少注释”。会议目标不是解决所有问题，而是投票选出本周最高优先级的1个破窗，由提出者牵头修复。三年来，累计修复217个破窗，其中38个直接避免了重大故障。

5.12 关于初心：始终问“这个设计能让凌晨三点的SRE看懂吗？”

所有架构决策的终极测试标准：打印出设计文档，交给一位刚入职的SRE，让他独自处理一次线上故障。如果他能在10分钟内定位到根因，说明设计合格；如果需要问三次以上“这个组件是干啥的”，说明设计失败。我们曾因一个Flink Job的Operator命名过于抽象（EnrichmentProcessorV2），被SRE吐槽“不知道是 enrich 什么”，强制重构为PaymentStatusEnricher。简洁、直白、无歧义，才是工程的最高美学。

我在实际交付中发现，那些最稳定的AI系统，往往代码行数最少，文档最薄，但每个模块的契约最坚硬。From Scratch不是为了炫技，而是为了让每一次故障都成为可学习的确定性事件，而不是一场需要运气的赌博。