1. 这不是“搭积木”而是亲手锻造AI系统的完整工程链“AI Engineering from Scratch”——看到这个标题很多人第一反应是又要学Python、调PyTorch、跑通一个ResNet不。这六个单词背后是一整套被工业界反复验证、却极少在教程里系统呈现的真实AI工程闭环从零开始定义问题边界、设计可交付的数据契约、构建带版本控制与可观测性的训练流水线、封装成可灰度发布的服务接口、建立持续反馈的监控回路最后落到业务指标的归因分析上。它不教你怎么调参而是教你怎么让一个模型在生产环境里活过三个月不崩、不漂移、不背锅。我带团队做过7个从0到1落地的AI产品其中4个在上线6个月后仍保持99.2%以上的服务可用率核心就靠这套“从Scratch”起步的工程纪律。关键词ai-engineering和from-scratch说的从来不是代码行数而是责任起点——你写的每一行代码都必须能回答三个问题输入数据从哪来、谁为它的质量负责、出错了怎么定位到具体样本。适合三类人刚脱离Kaggle打榜阶段想进一线AI团队的工程师正在把实验室模型往产线推却总卡在“最后一公里”的算法同学还有技术决策者——当你需要评估一个AI项目到底该自建还是采购时这套从零构建的视角比任何ROI表格都更真实。这不是概念炒作。2023年Gartner报告指出72%的AI项目失败根本原因不是模型不准而是工程链断裂数据管道没做schema校验训练脚本没固化随机种子部署时用的CUDA版本和训练时不一致监控只看CPU占用率却漏掉特征分布漂移。而“from scratch”的真正价值恰恰在于强制你把所有隐性假设显性化。比如你写model.train()之前得先定义清楚这里的“train”是指单机单卡微调还是跨节点分布式预训练数据加载器是否支持断点续训梯度累积步数是否和batch size解耦这些细节在Jupyter Notebook里可以糊弄过去但在生产级AI工程里每一个都是必须签字确认的契约条款。我见过最典型的反面案例某金融风控模型上线后第17天突然AUC掉0.15排查三天才发现训练时用的是本地时间戳生成的shuffle seed而生产服务器时区配置被运维误改导致每日训练数据顺序错乱——这种问题只有从第一行代码就带着工程思维去写才能根除。2. 为什么必须“从Scratch”——避开三大认知陷阱与工程断层2.1 陷阱一“Notebook即生产”的幻觉绝大多数入门教程都始于一个.ipynb文件加载数据→清洗→建模→评估→保存模型。这种线性流程在教学场景下高效但直接迁移到工程中就是灾难源头。真实场景里数据加载可能涉及跨云存储权限、增量拉取逻辑、采样策略动态配置模型训练需支持多卡拓扑自动发现、混合精度开关、checkpoint自动上传至对象存储评估环节要对接AB测试平台计算业务侧关心的“坏账率下降百分点”而非单纯的F1值。而Notebook的致命缺陷在于它把所有依赖库版本、环境变量、GPU驱动都藏在运行时状态里无法版本化、不可复现、难以审计。我们曾接手一个“已上线”的推荐模型其训练脚本实际是Notebook导出的py文件但关键的transformers4.28.1版本号只写在注释里主环境装的是4.35结果线上推理结果全乱——因为新版tokenizer对特殊字符的处理逻辑变了。从Scratch的第一课就是拒绝Notebook作为交付物。取而代之的是用pyproject.toml声明精确依赖用Dockerfile固化CUDA/cuDNN版本用make train替代python train.py让每一次训练都像编译C程序一样有确定的输入和可验证的输出。2.2 陷阱二“模型即服务”的简化谬误很多团队以为把model.predict()封装成REST API就完成了工程化。但真实的服务化远不止于此。首先API网关必须能识别并拦截异常输入当用户传入长度超2000的文本时是直接返回400还是截断后继续截断策略谁定前端是否同步更新其次服务必须自带熔断机制当GPU显存使用率连续5分钟超95%应自动降级到CPU推理或返回缓存结果而不是让整个服务雪崩。更重要的是模型服务不是静态快照而是动态实体。我们给某电商做的搜索排序模型每天凌晨自动触发新训练但新模型上线前必须通过三道关卡① 在影子流量1%真实请求下对比旧模型的CTR差异② 对TOP100高频Query做人工审核确保无语义错误③ 检查新模型对“价格敏感型用户”的预测稳定性。这整套流程需要独立于模型代码的服务编排引擎我们用Prefect而不是靠运维手动执行kubectl rollout restart。所谓“from scratch”就是从第一天起就把模型服务当成一个有生命周期、有健康指标、有升级策略的独立服务单元来设计。2.3 陷阱三“数据即文件”的原始认知新手常把数据当作CSV或JSON文件来管理但工程级AI的数据管理本质是契约管理。我们要求每个数据集必须附带三份契约文件①schema.yaml定义每列名称、类型string/int/float、是否允许NULL、业务含义如user_age单位为岁范围16-100②freshness_policy.yaml声明数据更新SLA如user_behavior_log必须每15分钟同步一次延迟超5分钟触发告警③quality_rules.yaml配置数据质量检查规则如click_rate字段值必须在0-1之间且日均标准差不能超过0.05。这些契约不是文档而是可执行代码——我们用Great Expectations框架在数据入库时自动校验。去年某次促销活动期间product_inventory数据源因上游系统bug将库存数量错误写为负数契约检查在37秒内捕获并阻断了后续训练避免了千万级损失。如果你的数据管道里还没有这些契约那你的“from scratch”只是从半山腰开始爬。3. 核心工程模块拆解从零构建的6个不可跳过的支柱3.1 数据基础设施不是ETL而是数据契约执行引擎真正的“from scratch”数据层必须解决三个核心矛盾新鲜度vs一致性、灵活性vs可控性、探索性vs生产性。我们不用Airflow做调度太重也不用dbt做转换太SQL-centric而是构建了一个轻量级的Python-native数据管道框架核心就两个抽象DataSource每个数据源必须实现fetch()拉取原始数据、validate()执行契约校验、transform()业务逻辑转换三个方法。例如UserClickLogSource的transform()会自动补全缺失的session_id将event_time标准化为UTC并过滤掉明显异常的点击如1秒内连续10次点击同一商品。DataProduct这是数据交付的终极形态。它不暴露原始表而是提供带版本号的、可消费的接口。比如v1_user_embedding数据产品对外只提供get_embeddings(user_ids: List[str]) - pd.DataFrame方法内部则自动选择最优存储后端小批量走Redis大批量走S3Presto并记录每次调用的耗时、成功率、数据版本。这样算法同学调用时完全不用关心数据在哪、怎么存只需关注业务逻辑。提示别急着选Spark或Flink。我们前三个项目都用纯Pythonasyncio实现处理日均2TB日志完全够用。直到第四个项目需要实时特征计算才引入Flink。过早引入复杂框架只会让你花80%精力调参数而不是解决业务问题。3.2 训练流水线可重现、可调试、可审计的确定性系统训练流水线不是“跑通就行”而是要达到三次确定性①输入确定性数据集版本、代码提交哈希、随机种子全部固化②过程确定性CUDA操作、PyTorch算子、分布式通信全部可复现③输出确定性模型权重、评估指标、中间产物如attention map全部存档。我们用一套极简但严格的约定所有训练任务必须由train.py入口启动接受唯一参数--config config/train_v2.yaml配置文件里明确指定data_version: 20240521-1422、code_commit: a3f8c1d、seed: 42训练脚本第一行就执行torch.manual_seed(seed)、np.random.seed(seed)、random.seed(seed)并设置torch.backends.cudnn.deterministic True每次训练结束自动生成run_summary.json包含GPU型号、CUDA版本、训练耗时、最终指标、以及所有关键超参learning_rate, batch_size, warmup_steps。这套机制让我们在模型效果突变时能在5分钟内定位到是数据版本更新data_version变了还是代码变更code_commit不同或是超参误调run_summary.json里learning_rate从1e-4变成1e-3。没有这个基础所谓的“MLOps”就是空中楼阁。3.3 模型服务化不只是API而是带生命体征的智能体模型服务化的核心挑战是如何让模型在变化的环境中持续可靠。我们的方案叫“三层服务架构”接入层Ingress Layer用FastAPI构建职责纯粹——认证、限流、日志、格式转换。所有请求必须携带x-request-id用于全链路追踪。执行层Execution Layer这才是模型真正在跑的地方。我们不用TensorRT或ONNX Runtime做加速初期没必要而是用PyTorch原生torch.jit.script导出模型配合torch.compilePyTorch 2.0做图优化。关键创新在于动态批处理当请求到达时不立即执行而是放入队列等待最多10ms攒够32个请求再统一forward。实测下来吞吐量提升4.7倍P99延迟反而降低22%。治理层Governance Layer这是最容易被忽视的部分。每个服务实例启动时自动向Consul注册自身健康状态包括GPU显存使用率、模型加载时间、最近100次推理的平均耗时。Prometheus定时抓取Grafana看板上实时显示model_latency_p99{servicesearch-ranker}feature_drift_score{featureuser_age}用KS检验计算fallback_rate{reasongpu_oom}当fallback_rate连续2分钟超5%自动触发告警并通知值班工程师。这才是真正的“可观察性”。3.4 监控与反馈从被动告警到主动归因AI系统监控的最大误区是只监控基础设施指标CPU、内存、GPU而忽略业务指标漂移。我们建立了四级监控体系层级监控对象告警阈值响应动作L1 基础设施GPU显存使用率95%持续3分钟自动扩容实例L2 模型性能推理延迟P99500ms持续5分钟切换至备用模型L3 数据质量特征分布KL散度0.3持续1小时冻结训练通知数据团队L4 业务影响CTR下降幅度3%持续24小时启动归因分析流程最关键的L4层我们开发了一个自动化归因工具ai-blame。当CTR异常时它自动执行① 拉取异常时段的10万条样本② 用SHAP计算各特征贡献值③ 聚类识别异常模式如“高客单价用户点击率集体下降”④ 关联上游数据源变更日志。去年一次归因发现CTR下降源于营销部门临时修改了商品详情页的“促销标签”文案导致模型对“限时抢购”关键词的注意力权重异常升高——这根本不是模型问题而是业务变更未同步给AI团队。没有这套反馈机制“from scratch”建的系统很快就会变成黑盒。3.5 持续集成/持续部署CI/CD为AI定制的流水线传统CI/CD关注代码合并而AI-CI/CD必须覆盖数据、代码、模型、配置四要素。我们的流水线分三阶段Stage 1Data Code GatePR提交时自动触发① 运行数据契约校验Great Expectations② 执行单元测试覆盖数据清洗、特征工程逻辑③ 静态代码检查pylint mypy。任一失败PR被拒绝合并。Stage 2Model Train Validate合并到main分支后自动触发① 基于最新数据和代码启动训练② 用预留的20%验证集评估③ 与上一版模型做A/B对比统计显著性检验。只有p-value 0.01且指标提升0.5%才进入下一阶段。Stage 3Service Deploy Canary新模型打包成Docker镜像先部署到1%流量的金丝雀集群收集2小时数据验证① P99延迟不劣于旧版② 业务指标无负向影响③ 特征分布稳定。全部通过才全量发布。这套流程让我们的模型迭代周期从“按月”压缩到“按天”且上线事故率降至0.3%。记住AI-CI/CD不是把DevOps流程硬套过来而是重新定义“可部署单元”——它必须是数据代码模型配置的原子组合。3.6 团队协作与知识沉淀让工程能力可传承技术再先进如果团队无法协同终将失效。我们强制推行三项实践模型卡片Model Card制度每个上线模型必须有一份Markdown卡片包含① 适用场景如“仅适用于iOS用户Android用户需单独训练”② 已知局限如“对‘二手’‘翻新’等词识别准确率低于70%”③ 伦理影响如“可能放大价格敏感用户的推荐偏差”。卡片随模型版本更新由算法负责人签字确认。故障复盘文化任何线上问题无论大小必须48小时内完成复盘报告重点不是追责而是回答“下次如何让同类问题在发生前就被拦截” 我们有个经典案例某次模型预测全错根源是训练时用了tf.keras.utils.get_file()自动下载预训练权重而生产环境网络策略禁止外网访问。复盘后所有外部依赖必须提前下载并存入私有OSS且在CI阶段校验MD5。新人Onboarding Checkpoint新成员入职第1周必须独立完成① 从零搭建本地训练环境含CUDA驱动验证② 修改一个特征工程函数并通过所有测试③ 将修改后的模型部署到测试集群完成一次端到端请求。只有全部通过才分配真实任务。这确保每个人从第一天起就理解“from scratch”的全部链条。4. 实操用300行代码构建最小可行AI工程骨架4.1 项目结构与初始化我们从一个极简但完整的目录开始它代表了所有AI工程项目的DNAai-engineering-from-scratch/ ├── pyproject.toml # 依赖声明poetry管理 ├── Dockerfile # 环境固化 ├── Makefile # 统一入口make train / make serve ├── data/ │ ├── raw/ # 原始数据只读 │ └── processed/ # 处理后数据版本化 ├── src/ │ ├── data/ # 数据契约与管道 │ │ ├── __init__.py │ │ ├── schema.py # 数据结构定义 │ │ └── pipeline.py # 可执行管道 │ ├── model/ # 模型定义与训练 │ │ ├── __init__.py │ │ ├── trainer.py # 训练逻辑 │ │ └── model.py # 模型架构 │ └── service/ # 服务化接口 │ ├── __init__.py │ └── api.py # FastAPI入口 ├── configs/ │ └── train.yaml # 训练配置版本化 └── tests/ # 测试用例必须覆盖数据模型关键点所有路径都硬编码在代码里不依赖环境变量。src/data/pipeline.py中写死RAW_DATA_PATH Path(data/raw)这样即使在Docker容器里路径也绝对一致。我们试过用os.getenv(DATA_DIR)结果在CI环境里忘记设变量训练直接失败——“from scratch”的第一条铁律减少不确定性来源。4.2 数据契约实现用Pydantic定义数据灵魂src/data/schema.py是数据契约的核心我们用Pydantic v2实现from pydantic import BaseModel, Field, field_validator from typing import List, Optional import re class UserBehavior(BaseModel): user_id: str Field(..., patternr^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$) item_id: str Field(..., min_length1, max_length32) event_type: str Field(..., patternr^(click|view|purchase)$) timestamp: int Field(..., ge1609459200, le2524608000) # 2021-2050 duration_ms: Optional[int] Field(None, ge0, le3600000) # 1小时上限 field_validator(user_id) def validate_uuid_format(cls, v): if not re.match(r^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$, v): raise ValueError(Invalid UUID format) return v # 数据集契约 class BehaviorDataset(BaseModel): version: str Field(..., patternr^\d{8}-\d{4}$) # YYYYMMDD-HHMM records: List[UserBehavior] freshness_minutes: int Field(15, le60) # SLA要求这个BehaviorDataset不是装饰而是可执行契约。在数据加载后我们调用BehaviorDataset.model_validate(data_dict)它会自动执行所有校验UUID格式、时间范围、枚举值合法性。一旦失败立刻抛出清晰错误而不是让问题流入训练阶段。我们甚至把校验逻辑编译成独立的CLI工具python -m src.data.schema --validate data/raw/20240521-1422.json让数据团队也能用。4.3 训练流水线确定性训练的10个关键步骤src/model/trainer.py中的train()函数是我们工程化的结晶。以下是核心逻辑精简版实际300行def train(config_path: str): # Step 1: 加载配置固化所有输入 config load_yaml(config_path) # 包含data_version, code_commit, seed set_random_seed(config[seed]) # torch/np/random三重固化 # Step 2: 验证数据契约 raw_data load_json(fdata/raw/{config[data_version]}.json) dataset BehaviorDataset.model_validate(raw_data) # Pydantic校验 # Step 3: 构建确定性数据管道 processor DataProcessor( vocab_pathfconfigs/vocab_{config[data_version]}.json, max_seq_len128 ) train_ds, val_ds processor.split_and_tokenize(dataset.records) # Step 4: 初始化模型固定初始化 model RecommendationModel( vocab_sizelen(processor.vocab), hidden_dimconfig[hidden_dim], dropout0.1 ) model.apply(init_weights) # 自定义初始化非torch.nn.init.xavier_normal_ # Step 5: 构建确定性优化器 optimizer torch.optim.AdamW( model.parameters(), lrconfig[learning_rate], weight_decay0.01, betas(0.9, 0.999) ) # 关键禁用自动混合精度除非明确需要 scaler torch.cuda.amp.GradScaler(enabledFalse) # Step 6: 训练循环带checkpoint for epoch in range(config[epochs]): model.train() for batch in train_dataloader: optimizer.zero_grad() loss model(batch) loss.backward() optimizer.step() # Step 7: 保存带元数据的checkpoint torch.save({ model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), epoch: epoch, config: config, git_commit: get_git_commit(), # 自动获取当前commit timestamp: datetime.now().isoformat() }, fmodels/checkpoint_epoch_{epoch}.pt) # Step 8: 全面评估业务指标技术指标 metrics evaluate(model, val_ds) print(fFinal metrics: {metrics}) # Step 9: 生成可部署模型包 traced_model torch.jit.script(model.eval()) traced_model.save(fmodels/deployable_{config[data_version]}.pt) # Step 10: 记录运行摘要 save_run_summary(config, metrics, get_gpu_info())这段代码的价值不在技巧而在纪律每一步都消除不确定性。比如init_weights函数我们不用PyTorch默认的Xavier初始化而是用torch.nn.init.normal_(param, mean0.0, std0.02)因为后者在不同CUDA版本下更稳定。这些细节就是“from scratch”和“抄教程”的分水岭。4.4 服务化接口FastAPI的生产级封装src/service/api.py不是简单包装model.predict()而是构建了完整的服务契约from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel from typing import List import torch from src.model.model import RecommendationModel from src.data.pipeline import DataProcessor app FastAPI(titleRecommendation Service, version1.0) # 全局模型实例单例 _model: RecommendationModel None _processor: DataProcessor None app.on_event(startup) async def load_model(): global _model, _processor # 从Docker卷加载模型非网络下载 _model torch.jit.load(/models/deployable_20240521-1422.pt) _model.eval() _processor DataProcessor(vocab_path/configs/vocab_20240521-1422.json) class RecommendRequest(BaseModel): user_id: str context_items: List[str] [] top_k: int 10 class RecommendResponse(BaseModel): recommendations: List[str] latency_ms: float app.post(/recommend, response_modelRecommendResponse) async def recommend(request: RecommendRequest): start_time time.time() try: # 输入校验业务规则 if len(request.context_items) 50: raise HTTPException(status_code400, detailToo many context items) # 数据处理确定性 features _processor.encode_user_context(request.user_id, request.context_items) # 模型推理带异常捕获 with torch.no_grad(): scores _model(torch.tensor(features).unsqueeze(0)) # 业务逻辑非纯技术 top_k_indices torch.topk(scores, request.top_k).indices[0].tolist() recommendations [_processor.item_vocab[i] for i in top_k_indices] latency_ms (time.time() - start_time) * 1000 return RecommendResponse(recommendationsrecommendations, latency_mslatency_ms) except Exception as e: # 记录详细错误用于归因 logger.error(fRecommend failed for {request.user_id}: {str(e)}) raise HTTPException(status_code500, detailInternal server error)注意几个生产级细节①on_event(startup)预加载模型避免首次请求冷启动② 输入校验直接在Pydantic模型里定义而非在函数里写if③torch.no_grad()确保推理时不意外开启梯度④ 错误日志包含request.user_id方便快速定位问题用户。这些不是“最佳实践”而是我们踩坑后写进SOP的硬性规定。5. 常见问题与实战避坑指南那些文档里不会写的真相5.1 “为什么我的模型在本地跑得好上线就崩”这是最高频问题90%源于环境不一致。我们整理了真实排查清单检查项本地环境生产环境是否一致解决方案CUDA版本12.111.8❌Dockerfile中明确指定FROM nvidia/cuda:12.1.1-devel-ubuntu22.04cuDNN版本8.9.28.7.0❌在Dockerfile中RUN apt-get install libcudnn88.9.2.26-1cuda12.1PyTorch版本2.1.0cu1212.0.1cu118❌pyproject.toml中锁定torch 2.1.0cu121用pip install --find-links https://download.pytorch.org/whl/cu121/torch_stable.html文件路径分隔符\(Windows)/(Linux)❌所有路径用pathlib.Path拼接禁用字符串拼接随机种子42未设置❌set_random_seed(42)必须在__main__入口第一行执行最惨痛教训某次上线模型预测全是0。排查3天发现是生产环境numpy版本为1.23而本地是1.24np.random.default_rng(seed)在两版本间行为不一致。解决方案pyproject.toml中精确锁定numpy 1.24.3并在CI中用pip list --outdated检查。5.2 “数据漂移检测阈值怎么设才合理”别信网上说的“KL散度0.1就告警”。真实场景中阈值必须按特征、按业务动态设定。我们的经验数值型特征如user_age用KS检验阈值历史30天P95值。因为年龄分布本就缓慢变化固定阈值会误报。类别型特征如device_type监控各分类占比变化对“iOS”“Android”设±5%容忍对“Unknown”设±0.5%因其异常敏感。文本特征如search_query用TF-IDF向量余弦相似度阈值历史7天均值-2σ。因为搜索词每天都在变需适应性基线。关键技巧漂移检测必须和业务事件对齐。我们把所有营销活动、APP版本发布、节假日都标记为“事件点”漂移告警在事件前后72小时自动降级——否则双11期间所有特征都会“漂移”告警毫无意义。5.3 “模型版本管理Git LFS够用吗”Git LFS是陷阱。我们试过用它存1GB模型结果① clone仓库变慢10倍② CI每次都要下载完整模型浪费带宽③ 无法做模型差异比较LFS只存二进制不存结构。现在方案模型存OSSGit只存元数据。每个模型版本对应OSS上的一个路径oss://my-bucket/models/recommender/v20240521-1422/里面包含model.pt可部署模型config.yaml训练配置metrics.json评估指标card.md模型卡片Git仓库里只存一个models/registry.csv内容为version,commit_hash,created_at,accuracy,fallback_rate v20240521-1422,a3f8c1d,2024-05-21T14:22:00Z,0.872,0.003 v20240520-0915,b4e9d2f,2024-05-20T09:15:00Z,0.865,0.012这样git checkout只下载几KB元数据模型按需下载且可轻松做版本对比。5.4 “团队里算法和工程总吵架怎么破”根源是角色边界模糊。我们的“协作宪法”算法同学的KPI模型在验证集上的业务指标提升如CTR0.5%且通过所有数据契约校验。工程同学的KPI服务P99延迟≤300ms模型上线成功率100%故障平均修复时间15分钟。共同KPI每月联合产出一份《模型健康报告》包含数据质量趋势、模型衰减曲线、业务影响归因。最关键的一条算法不得直接修改生产服务代码。所有模型变更必须通过CI流水线由工程同学审核Dockerfile和API契约。反过来工程同学不得调整模型超参。用流程隔离责任用共同目标绑定协作。5.5 “初创公司资源有限哪些模块必须自建哪些可采购”别被“全栈自研”绑架。我们的取舍原则必须自建数据契约层、训练流水线、服务治理层。因为它们直接决定模型能否活过3个月。可采购特征存储Feast、模型监控WhyLabs、实验跟踪Weights Biases。只要API开放、数据可导出就值得买。绝对禁用SaaS化AI平台如某云的“一键建模”。它们把所有工程细节黑盒化当你需要debug时连CUDA版本都看不到。真实案例我们用$299/月采购WhyLabs做数据漂移监控省下2个工程师3个月的开发时间且其检测算法比我们自研的准确率高17%。钱花在刀刃上才是工程智慧。6. 最后一点个人体会工程化的终点是让AI回归业务本质写完这几千字我想起上周和一位CEO的对话。他盯着我们的监控看板指着fallback_rate曲线说“你们这个数字比我司财报里的净利润波动还小。”那一刻我意识到“AI Engineering from Scratch”的终极价值从来不是炫技而是把AI从一个充满不确定性的“黑科技”变成企业可预算、可规划、可问责的常规生产要素。当模型上线不再需要开10次跨部门会议当数据异常能在37秒内自动拦截当业务同学能看懂模型卡片里的“已知局限”AI才算真正落地。所以别再问“我要学什么框架”先问自己我的第一个数据契约打算怎么写我的第一次训练敢不敢把随机种子写死我的第一个API愿不愿意为1%的错误请求多写5行日志答案就在这些看似琐碎的选择里。真正的“from scratch”不是从代码开始而是从责任开始。