1. 从零构建AI工程体系这不是写个模型脚本而是搭一条生产线“AI Engineering from Scratch”这个标题乍看像极了某门新课的宣传语但如果你真把它当成“手把手教你怎么用PyTorch跑个MNIST”那接下来的路会走得非常辛苦——因为这根本不是在教你怎么调参而是在教你如何把AI从实验室里的demo变成能进产线、扛流量、可维护、能迭代的工程产品。我带过7个AI落地项目从金融风控模型到工业视觉质检系统最深的体会是80%的失败不是模型不准而是工程链路断在了数据接入、特征更新、服务部署或监控告警任何一个环节。你用Python写出了99.2%准确率的分类器结果上线后因上游数据库字段变更导致特征缺失服务直接返回NaN你用Rust写了超快的推理引擎却卡在Kubernetes里连不上Redis配置中心你用TypeScript写了漂亮的前端可视化面板但后端API每次返回的schema都和文档对不上……这些都不是“小问题”而是AI工程化没做实的典型症状。核心关键词“ai-engineering”背后是一整套跨语言、跨团队、跨生命周期的协作范式。它不绑定Python也不排斥Rust不鼓吹“一门语言打天下”而是强调“按场景选武器”。Python负责快速验证与数据探索TypeScript守住前端交互与API契约Rust攻坚高并发低延迟推理服务Julia专攻数值密集型科学计算模块——它们不是竞争关系而是流水线上的不同工位。你不需要成为四门语言的专家但必须清楚当模型要每秒处理3000张缺陷图时Python的GIL就是瓶颈当需要在嵌入式设备上做实时姿态估计时Rust的内存安全比开发速度更重要当训练一个万亿参数的稀疏模型时Julia的多维数组原生支持和并行调度能力可能比硬啃CUDA C省下两个月工期。这不是技术炫技而是成本、稳定性、可扩展性之间的精密权衡。这篇文章不讲理论推导只讲我在真实项目里踩过的坑、验证过的路径、以及现在每天都在用的最小可行工程骨架——从环境初始化开始到CI/CD流水线收尾所有环节都附带可复制的命令、配置片段和避坑提示。2. 工程底座设计为什么必须放弃“单语言单仓库”幻想2.1 多语言协同不是炫技而是解决本质矛盾很多人看到“Python TypeScript Rust Julia”这个组合第一反应是“太重了一个小项目搞这么复杂”——这种质疑非常合理但恰恰暴露了对AI工程化本质的误判。我们来拆解三个真实场景场景A电商推荐系统的实时特征计算用户点击行为需在50ms内完成用户画像更新并触发新推荐列表生成。Python做特征工程逻辑清晰但单线程处理高并发写入时CPU飙升到95%下游服务开始超时。换成Rust实现特征聚合模块后同等负载下CPU稳定在35%延迟P99从120ms压到42ms。这里Rust不是替代Python而是补足Python在IO密集计算密集混合场景下的短板。场景B医疗影像分析平台的前端交互医生需要在浏览器里旋转、缩放、标注3D MRI体数据。Python后端提供DICOM解析和模型推理API但前端若用纯JavaScript处理GB级体数据渲染内存溢出是常态。TypeScript Three.js WebAssembly方案让GPU加速的体绘制逻辑在浏览器端高效运行同时利用TypeScript的强类型约束确保前后端API契约如{ patientId: string; sliceIndex: number; }在编译期就校验通过避免运行时因字段名拼错导致的“黑屏”。场景C量化交易策略的回测引擎策略研究员用Python写逻辑但分钟级tick数据回测耗时过长。将核心价格匹配、订单簿更新等计算密集模块用Julia重写得益于其JIT编译和多线程原生支持回测速度提升6.8倍。更关键的是Julia的distributed宏让分布式回测集群配置只需3行代码而Python生态中类似方案往往要引入Dask、Ray等额外依赖运维复杂度指数上升。提示多语言不是为了堆砌技术栈而是为每个关键路径选择“最不痛”的工具。Python胜在生态和迭代速度Rust胜在确定性性能和内存安全TypeScript胜在大型前端项目的可维护性Julia胜在科学计算领域的表达力与性能平衡。强行用Python写高并发服务或用Rust写数据分析脚本都是在制造新的技术债。2.2 项目结构分层按关注点隔离而非按语言隔离很多团队尝试多语言项目时习惯性地按语言建四个仓库my-ai-python-backend、my-ai-rust-inference、my-ai-ts-frontend、my-ai-julia-sim。这看似清晰实则埋下巨大隐患版本不一致Python服务调用的Rust API接口变了但前端没同步更新、环境割裂本地调试时Python环境用condaRust用rustupTypeScript用nvm彼此隔离导致集成测试总失败、发布混乱四个仓库各自发版线上服务实际运行的组合可能是从未在CI中验证过的“幽灵版本”。我们采用单体仓库领域分层结构根目录如下ai-engineering-from-scratch/ ├── docs/ # 架构决策记录ADR、接口契约文档 ├── infra/ # Terraform云资源定义、Docker Compose本地环境 ├── packages/ │ ├── core/ # 共享类型定义TypeScript生成的.d.ts供Python/Rust/Julia引用 │ ├──>// packages/core/src/types.ts export interface FeatureSpec { name: string; type: float | int | categorical; source: database | api | file; lastUpdated: Date; // 自动映射为Python datetime, Rust chrono::DateTime, Julia Dates.DateTime }生成的Rust代码自动带#[derive(Deserialize, Serialize)]Python代码带dataclass和pydantic.BaseModel继承Julia代码带autohash和JSON3.read支持。类型一致性不再靠人工对齐而是由代码生成强制保障。infra/统一环境基线Docker Compose定义本地全栈环境Terraform定义生产环境。所有服务镜像均基于同一基础镜像如ubuntu:22.04预装各语言必要工具链python3.11,rustc 1.75,nodejs 18,julia 1.10避免“本地能跑线上挂”的经典问题。特别注意Rust镜像大小控制使用rust:1.75-slim而非rust:1.75编译阶段用multi-stage build分离构建环境与运行环境最终镜像仅含/usr/bin/inference-service二进制文件体积从1.2GB压至28MB。scripts/解决跨语言构建痛点例如sync-version.sh脚本读取package.json中的version自动更新Cargo.toml、pyproject.toml、Project.tomlJulia中的版本字段并提交PR。再如gen-types.sh调用ts-generator生成各语言类型定义后自动运行cargo check、mypy、julia --check验证生成代码有效性。这些脚本让多语言协作从“手动对齐”变为“机器驱动”。2.3 工具链统一VS Code成为唯一IDE入口开发者不必为每种语言安装独立IDE。我们定制VS Code工作区.code-workspace集成所有语言插件与任务PythonPylance Ruff代码检查、Poetry依赖管理Rustrust-analyzer智能提示、cargo-watch热重载TypeScriptESLint Prettier、TypeScript官方插件JuliaJulia extension、Julia Formatter关键配置在.vscode/settings.json中{ files.associations: { *.ts: typescript, *.rs: rust, *.jl: julia }, rust-analyzer.cargo.loadOutDirsFromCheck: true, julia.executablePath: /opt/julia/bin/julia, python.defaultInterpreterPath: ./.venv/bin/python }更关键的是统一任务系统tasks.json定义跨语言任务。例如“全栈启动”任务{ label: dev:full-stack, type: shell, command: cd packages/data-pipeline poetry run python main.py cd ../inference cargo run cd ../web npm start, group: build, isBackground: true, problemMatcher: [] }配合live-server插件前端修改保存即刷新Rust服务用cargo-watch -x run监听源码变化自动重启Python数据管道用watchmedo auto-restart监控配置文件变更。开发者只需按CtrlShiftP→ “Tasks: Run Task” → 选择dev:full-stack整个环境一键拉起无需记忆各语言启动命令。实操心得曾有个团队坚持“每个语言用最顺手的IDE”结果Python工程师用PyCharmRust工程师用IntelliJ RustTypeScript工程师用WebStorm。结果是.gitignore规则不统一PyCharm生成.idea/WebStorm生成.webstorm/代码格式化风格冲突Rust用rustfmtTS用prettier但团队未约定换行符和空格数最致命的是调试体验割裂——当API调用链跨越Python→Rust→TS时无法在单个IDE里设置断点追踪全流程。统一VS Code后通过CodeLLDBRust、Python Debugger、Debugger for Chrome插件可在同一界面调试全栈效率提升显著。3. 核心模块实现从数据管道到推理服务的逐层落地3.1 数据管道Python主导的可靠数据流AI工程化的起点永远是数据。我们不用Airflow或Prefect这类重型调度器而是用Python标准库轻量框架构建可测试、可观察、可回滚的数据管道。核心组件># packages/data-pipeline/src/sources/base.py from abc import ABC, abstractmethod from typing import Iterator, Dict, Any class DataSource(ABC): abstractmethod def fetch_batch(self, batch_size: int) - Iterator[Dict[str, Any]]: pass abstractmethod def get_schema(self) - Dict[str, str]: pass具体实现如PostgresSource、S3ParquetSource、KafkaSource均继承此接口。关键设计所有fetch_batch方法必须支持offset和limit参数确保管道可中断续传。例如Kafka消费时记录partition和offset到SQLite本地数据库崩溃重启后从断点继续避免重复消费或丢失数据。feature-store模块不依赖外部Feature Store服务如Feast而是用SQLiteParquet构建轻量级特征存储。特征计算逻辑用DuckDB执行内存计算快SQL语法友好结果存为Parquet分区表按date2024-03-15组织同时生成SQLite元数据表记录特征版本、血缘、统计摘要如null_rate,std_dev。这样既保证查询性能DuckDB直接读Parquet又具备可观测性通过SQLite查特征健康度。># packages/data-pipeline/src/pipeline/stages/validate.py def validate_features(df: pd.DataFrame, schema: Dict[str, str]) - Tuple[pd.DataFrame, List[str]]: errors [] for col, dtype in schema.items(): if col not in df.columns: errors.append(fMissing column: {col}) elif dtype float and not np.issubdtype(df[col].dtype, np.floating): errors.append(fColumn {col} has wrong dtype: {df[col].dtype}) if errors: logger.error(fData quality errors: {errors}) # 发送告警到Slack webhook send_slack_alert(errors) return df, errors每次管道运行生成quality-report.json包含total_rows、null_counts、outlier_counts等指标上传至S3供Grafana展示。当null_rate超过阈值如5%自动暂停下游任务并通知负责人。注意Python数据管道最大的陷阱是“隐式状态”。曾有个项目用全局变量缓存数据库连接在多进程模式下导致连接泄漏。我们的解决方案是所有资源DB连接、S3客户端通过contextlib.contextmanager封装确保with块退出时自动清理管道主函数明确声明输入输出禁止修改外部状态。例如pipeline_step def enrich_user_profile(raw_data: pd.DataFrame) - pd.DataFrame: # 所有依赖如Redis client通过参数注入不从全局获取 redis_client get_redis_client() # ... 处理逻辑 return enriched_df这样每个步骤可独立单元测试且易于并行化。3.2 推理服务Rust构建的高性能、低延迟服务当模型进入生产环境Python的GIL和解释器开销成为瓶颈。我们用Rust重构推理服务核心目标单实例支撑2000 QPSP99延迟80ms内存占用512MB。技术选型理由ONNX Runtime Rust绑定不自己实现模型加载而是用onnxruntimecrate调用C ONNX Runtime。它支持CUDA、TensorRT、OpenVINO后端且Rust绑定成熟onnxruntimecrate下载量超10万/月。相比自己用ndarraytchPyTorch Rust绑定ONNX Runtime对模型格式兼容性更好运维更简单。Tokio异步运行时处理高并发HTTP请求。关键配置# Cargo.toml [dependencies] tokio { version 1.33, features [full] } hyper 1.0 onnxruntime 0.10 serde { version 1.0, features [derive] }内存池优化推理中频繁分配Tensor内存。用bumpalocrate实现arena allocator避免频繁malloc/free。例如预分配100个InputTensor对象在请求间复用// packages/inference/src/memory_pool.rs use bumpalo::Bump; thread_local! { static POOL: Bump Bump::new(); } pub fn alloc_input_tensor(shape: [i64]) - InputTensor { POOL.with(|bump| { let data bump.alloc_slice_fill_copy(0f32, (shape.iter().product::i64() * 4) as usize); InputTensor::new(data, shape.to_vec()) }) }服务结构inference/ ├── src/ │ ├── main.rs # Tokio服务入口 │ ├── model.rs # ONNX模型加载、推理执行 │ ├── api.rs # Hyper路由定义/predict, /health │ └── memory_pool.rs # 内存池实现 ├── models/ │ └── classifier.onnx # 预编译ONNX模型 └── config/ └── service.yaml # 模型路径、batch_size、device等配置关键实现细节批处理优化HTTP接口接收单条请求但内部攒批max 32条后统一推理。model.rs中pub struct InferenceEngine { session: Session, batch_queue: ArcMutexVecInputBatch, batch_size: usize, } impl InferenceEngine { pub async fn predict(self, input: Vecf32) - ResultVecf32, Error { // 将单条输入加入队列 self.batch_queue.lock().await.push(InputBatch { data: input }); // 当队列满或超时10ms触发批处理 if self.batch_queue.lock().await.len() self.batch_size { self.process_batch().await } else { tokio::time::sleep(Duration::from_millis(10)).await; self.process_batch().await } } }这样既保证低延迟单条请求最多等10ms又提升GPU利用率批量推理吞吐更高。健康检查与热重载/health端点返回{status: ok, model_version: v2.1.0, gpu_memory_used_mb: 1245}。模型更新时不重启服务而是监听models/目录变化用notifycrate检测文件修改动态卸载旧模型、加载新模型。实测热重载耗时200ms业务无感。实操心得Rust推理服务最容易被忽略的是日志与监控。很多团队只关注“模型跑通”但线上问题往往出在数据预处理。我们在api.rs中记录每条请求的原始输入、预处理后输入、模型输出、后处理结果采样1%写入ClickHouse。当发现预测准确率下降时可直接查询历史请求对比“预处理前后的图像像素分布”快速定位是上游摄像头曝光参数变更还是预处理代码bug。没有这层日志排查周期从小时级变成天级。3.3 前端交互TypeScript构建的可信可视化层AI前端不是简单展示结果而是建立人机信任。医生需要知道“这个结节标记为什么置信度只有62%”交易员需要理解“策略在2023年Q4回撤的原因是哪些因子失效”。TypeScript Three.js Vue3为此提供坚实基础。架构分层api-client基于axios封装自动生成TypeScript类型。openapi.yaml定义后端API用openapi-typescript生成src/api/generated/。例如# openapi.yaml paths: /predict: post: requestBody: content: application/json: schema: $ref: #/components/schemas/PredictionRequest responses: 200: content: application/json: schema: $ref: #/components/schemas/PredictionResponse components: schemas: PredictionRequest: type: object properties: image_base64: { type: string } PredictionResponse: type: object properties: mask_base64: { type: string } confidence: { type: number }生成的PredictionResponse类型自动用于Vue组件props校验避免运行时response.mask_base64为undefined的错误。visualization模块Three.js处理3D渲染但核心是可解释性可视化。例如医疗影像!-- src/components/VolumeRenderer.vue -- template div refcanvasRef classvolume-canvas/div !-- 叠加热力图显示模型关注区域 -- HeatmapOverlay :mask-dataprediction.mask :opacity0.6 clickshowExplainModal / /template script setup langts import { onMounted, ref } from vue import * as THREE from three import { HeatmapOverlay } from /components/HeatmapOverlay const canvasRef refHTMLDivElement() let renderer: THREE.WebGLRenderer onMounted(() { // 初始化Three.js场景 const scene new THREE.Scene() const camera new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000) renderer new THREE.WebGLRenderer({ canvas: canvasRef.value?.querySelector(canvas)! }) // 加载DICOM体数据通过WebAssembly加速解码 const volumeData await loadDicomVolume(dicomUrl) const volumeTexture new THREE.DataTexture3D(volumeData, volumeData.width, volumeData.height, volumeData.depth) scene.add(new VolumeRender(volumeTexture)) }) /script关键创新点热力图mask_base64解码为Float32Array与原始体数据对齐点击热区弹出“归因分析”模态框显示该区域对最终诊断的SHAP值贡献。这不再是“黑箱输出”而是可对话的AI协作者。state-management不用Vuex或Pinia而是用Composition API reactive管理跨组件状态。例如模型配置状态// src/stores/modelConfig.ts import { reactive } from vue export const modelConfig reactive({ modelName: resnet50-v2, threshold: 0.5, iouThreshold: 0.4, update: (config: Partialtypeof modelConfig) { Object.assign(modelConfig, config) // 触发API重新加载模型 api.reloadModel(modelConfig.modelName) } })所有组件通过import { modelConfig } from /stores/modelConfig访问响应式更新无额外依赖。注意TypeScript前端最大的风险是类型漂移。后端API字段改名如confidence_score→confidence前端类型未更新导致运行时错误。我们的解决方案是CI流水线中增加check-api-consistency步骤用openapi-diff工具比对openapi.yaml与生成的generated/类型文件差异超过阈值如新增字段3个则阻断发布。同时前端调用API时强制使用as const断言const response await api.predict(payload) as const // 如果后端返回字段与类型定义不符编译直接报错这让类型安全从“可选最佳实践”变成“强制准入门槛”。3.4 仿真引擎Julia构建的高性能数值计算模块当AI需要与物理世界深度耦合如机器人运动规划、电池寿命预测通用框架力不从心。Julia以其接近C的性能 类似Python的简洁语法 原生多线程成为理想选择。典型应用电动车电池健康度SOH预测。传统方法用LSTM拟合电压-电流-温度序列但物理机理缺失导致外推失效。我们用Julia实现电化学-热耦合模型将物理方程Butler-Volmer方程、热传导方程与数据驱动模块神经ODE融合。核心代码结构simulation/ ├── src/ │ ├── battery_model.jl # 物理模型定义 │ ├── neural_ode.jl # 神经ODE求解器 │ └── simulator.jl # 主仿真循环 ├── models/ │ └── soh_predictor.jld2 # 训练好的神经ODE权重 └── data/ └── cycle_data.jld2 # 实验室循环测试数据关键实现物理模型battery_model.jlusing DifferentialEquations, ModelingToolkit variables t V(t) I(t) T(t) Soh(t) parameters R₀ R₁ C₁ k_heat α D Differential(t) # Butler-Volmer动力学 eqs [ D(V) ~ -(1/R₀)*V - (1/R₁)*(V - I*R₁) k_heat*(T - 25), D(I) ~ α*V - β*I^2, # 简化电化学反应 D(T) ~ I^2*R₀ k_heat*(25 - T), # 焦耳热散热 D(Soh) ~ -γ*I^2*exp(-Ea/(R*T)) # Arrhenius老化模型 ] named sys ODESystem(eqs, t, [V, I, T, Soh], [R₀, R₁, C₁, k_heat, α, γ, Ea, R])神经ODE集成neural_ode.jlusing Flux, DiffEqFlux # 定义神经网络作为ODE右侧函数 nn Chain(Dense(4, 32, relu), Dense(32, 32, relu), Dense(32, 4)) prob_nn NeuralODE(nn, (0.0, 100.0), Tsit5(), saveat1.0) # 混合求解物理方程提供先验NN学习残差 function hybrid_rhs(u, p, t) phys physical_rhs(u, p_phys, t) # 物理模型计算 nn_out nn([u; t]) # 神经网络输出残差 return phys nn_out end高性能仿真simulator.jlusing Distributed, SharedArrays # 启动4个工作进程 addprocs(4) everywhere using LinearAlgebra # 并行仿真1000个电池单元 soh_results distributed (vcat) for i in 1:1000 u0 [3.7, 0.0, 25.0, 1.0] # 初始状态 p [p_phys..., p_nn...] # 参数向量 sol solve(ODEProblem(hybrid_rhs, u0, (0.0, 10000.0), p), Tsit5()) return sol.u[end][4] # 返回最终Soh end实测效果Julia单机4核仿真1000个电池单元10000秒工况耗时18.3秒同等PythonNumPy实现耗时217秒。更关键的是Julia的distributed让并行代码简洁如串行而Python的multiprocessing需手动管理进程间通信、序列化开销大。实操心得Julia新手常犯的错误是“过度向量化”。例如用broadcast操作代替循环但在内存受限场景如嵌入式设备广播会创建临时数组导致OOM。我们的经验是对小数组1000元素用广播对大数组用LoopVectorization.jl的avx宏显式向量化循环。另外Julia包管理Pkg的Project.toml必须锁定所有依赖版本否则Pkg.update()可能升级DifferentialEquations.jl到不兼容版本导致ODE求解器静默失败。我们CI中强制运行julia --project -e using Pkg; Pkg.instantiate()确保环境可重现。4. 工程化落地CI/CD、监控与持续演进4.1 统一CI/CD流水线从代码提交到生产发布的自动化闭环多语言项目最大的运维挑战是“发布一致性”。我们用GitHub Actions构建单一流水线多阶段验证一次发布的CI/CD。流水线设计原则阶段化验证每个语言模块独立测试但最终集成验证必须通过环境一致性所有阶段使用相同基础镜像ghcr.io/myorg/ai-base:2024.3预装Python 3.11、Rust 1.75、Node 18、Julia 1.10制品统一管理构建产物Python wheel、Rust binary、TS bundle、Julia package全部上传至私有Artifactory按Git Tag版本索引关键Workflow.github/workflows/ci-cd.ymlname: AI Engineering Pipeline on: push: branches: [main] tags: [v*.*.*] jobs: # 阶段1静态检查与单元测试 lint-and-test: runs-on: ubuntu-22.04 container: ghcr.io/myorg/ai-base:2024.3 steps: - uses: actions/checkoutv4 - name: Install dependencies run: | cd packages/data-pipeline poetry install cd ../inference rustup default 1.75 cargo build --release cd ../web npm ci cd ../simulation julia --project -e using Pkg; Pkg.instantiate() - name: Run Python tests run: cd packages/data-pipeline poetry run pytest tests/ --covsrc - name: Run Rust tests run: cd packages/inference cargo test --lib - name: Run TS tests run: cd packages/web npm test - name: Run Julia tests run: cd packages/simulation julia --project -e using Pkg; Pkg.test() # 阶段2集成测试全栈联调 integration-test: needs: lint-and-test runs-on: ubuntu-22.04 container: ghcr.io/myorg/ai-base:2024.3 steps: - uses: actions/checkoutv4 - name: Start services run: | cd packages/data-pipeline poetry run python -m http.server 8000 cd ../inference cargo run --release cd ../web npm start sleep 30 # 等待服务就绪 - name: Run integration tests run: pytest tests/integration/ --base-urlhttp://localhost:3000 # 阶段3构建与发布仅Tag触发 release: needs: integration-test if: startsWith(github.event.ref, refs/tags/v) runs-on: ubuntu-22.04 container: ghcr.io/myorg/ai-base:2024.3 steps: - uses: actions/checkoutv4 - name: Build Python package run: cd packages/data-pipeline poetry build - name: Build Rust binary run: cd packages/inference cargo build --release --target x86_64-unknown-linux-musl - name: Build TS bundle run: cd packages/web npm run build - name: Build Julia package run: cd packages/simulation julia --project -e using Pkg; Pkg.build() - name: Upload artifacts to Artifactory uses: jfrog/setup-jfrog-cliv2 with: version: latest user: ${{ secrets.JFROG_USER }} password: ${{ secrets.JFROG_API_KEY }} run: | jfrog rt u packages/data-pipeline/dist/*.whl ai-py/${{ github.event.tag_name }}/ jfrog rt u packages/inference/target/x86_64-unknown-linux-musl/release/inference-service ai-rust/${{ github.event.tag_name }}/ jfrog rt u packages/web/dist/** ai-web/${{ github.event.tag_name }}/ jfrog rt u packages/simulation/Project.toml ai-julia/${{ github.event.tag_name }}/关键设计点Musl目标构建Rust二进制--target x86_64-unknown-linux-musl生成静态链接二进制无需担心生产环境glibc版本兼容性直接COPY到Alpine镜像即可运行。Artifactory统一制品库所有语言产物按language/version/路径存储Kubernetes Helm Chart通过artifactory.myorg.com拉取对应版本确保“一次构建处处运行”。Tag驱动发布只有v1.2.3格式的Tag才触发发布避免main分支频繁构建污染制品库。Tag命名遵循SemVerCI自动解析MAJOR.MINOR.PATCH用于Helm Chart版本号。注意CI流水线中最容易被忽视的是测试覆盖率门禁。我们要求Python单元测试覆盖率≥85%Rustcargo test覆盖所有pub函数TypeScript用c8收集覆盖率低于70%则失败。但覆盖率不是目的关键是关键路径必须有测试。例如数据管道的validate_features函数、Rust推理服务的process_batch函数、Julia仿真器的hybrid_rhs函数这些直接影响结果正确性的函数必须有边界值测试如输入全零、输入NaN、输入超大值。我们用pytest.mark.parametrize和
