企业官网建设流程全解析

1. 项目概述：当测试驱动遇上智能体生成

最近在AI工程化领域，一个名为TAG的轻量级框架开始引起不少开发者的讨论。它的全称是“Test-Driven Agentic Artifact Generation”，直译过来就是“测试驱动的智能体工件生成框架”。这名字听起来有点拗口，但拆解一下核心概念就清晰了：它试图用写测试用例的方式，来驱动和约束AI智能体（Agent）去生成我们想要的“工件”（Artifact）。这里的“工件”可以是一段代码、一份文档、一个配置脚本，甚至是更复杂的业务流程设计图。

我最初接触这个想法，是因为在团队内部尝试用大语言模型（LLM）生成代码时遇到的老大难问题：生成结果的不确定性。你让模型写一个函数，它可能这次写得完美，下次就漏了异常处理，或者用了过时的API。传统的提示工程（Prompt Engineering）像是在“祈祷”，调整措辞、增加示例，希望模型能“理解”你的意图。而TAG框架引入的“测试驱动”思维，则是一种更工程化的“契约”思维：我先定义好这个工件必须通过哪些测试（即满足什么标准），然后让智能体去尝试生成，直到产出的结果能通过所有测试为止。这就像你先写好单元测试，再让一个不知疲倦的、知识渊博的“实习生”（智能体）去反复尝试实现功能，直到测试全部变绿。

这个框架的目标用户很明确：任何需要频繁、可靠地由AI生成结构化产出的开发者、测试工程师或技术写作者。比如，你需要批量生成符合公司规范的API客户端代码，或者为一系列数据模型自动生成数据库迁移脚本和对应的CRUD接口。TAG不是要替代你的创造性工作，而是要把那些重复、模板化但又容易出错的生成任务，变得可预测、可验证。

2. 核心理念与架构设计拆解

2.1 为什么是“测试驱动”？

测试驱动开发（TDD）的理念是“红-绿-重构”：先写一个失败的测试，再写最少代码使其通过，最后优化代码结构。TAG框架巧妙地将这一理念移植到了AI生成领域。其背后的逻辑是，对于AI生成的内容，我们往往难以用精确的指令描述所有细节要求，但我们可以相对容易地定义出一组“验收标准”。这些标准以自动化测试的形式存在，成为了衡量生成物质量的客观标尺。

传统的AI生成流程是线性的：输入提示（Prompt） -> 模型生成 -> 人工审查。审查环节耗时费力，且依赖人的主观判断。TAG框架将其改造成了一个循环反馈系统：定义测试 -> 生成候选 -> 执行测试 -> 评估结果 -> （如失败）基于反馈调整或重新生成。这个循环的核心价值在于将模糊的质量要求，转化为了可自动执行的、二元的通过/失败判断。智能体不再是被动地执行一次提示，而是成为了一个在测试约束空间内主动寻找可行解的“问题解决者”。

2.2 “轻量级”体现在何处？

市面上已经有一些复杂的AI应用编排框架（如LangChain、LlamaIndex），它们功能强大，但学习曲线陡峭，有时显得“重”。TAG框架的“轻量级”设计哲学体现在几个方面：

1. 职责单一：它不试图成为一个全功能的AI应用开发平台，而是聚焦于“测试驱动生成”这一个核心工作流。它不内置向量数据库、不管理复杂的记忆流，它的核心就是一个“生成-测试”循环引擎。
2. 依赖最小化：框架本身对特定的大模型供应商、测试框架保持中立。它定义了一套清晰的接口，你可以接入OpenAI的GPT、Anthropic的Claude，或是本地的开源模型；同样，测试部分可以用pytest、unittest，甚至是自定义的简单Python函数。这种设计让集成到现有项目变得非常容易。
3. 配置即代码：整个生成任务（称为一个“TAG任务”）可以通过一个结构化的配置文件（如YAML或JSON）来定义。这个文件描述了目标工件是什么、使用什么模型、有哪些测试用例、失败后如何调整策略等。这种声明式的配置方式，使得生成流程可版本化、可重复执行。

2.3 核心组件交互逻辑

一个典型的TAG框架内部，可以抽象出四个核心组件，它们协同工作，构成了完整的生成流水线。

1. Artifact Spec（工件规格）：这是生成任务的蓝图。它不仅仅是一个简单的提示词，而是一个结构化的描述，可能包括：

   • 目标描述：用自然语言说明要生成什么（例如：“生成一个FastAPI的GET端点，用于根据ID查询用户信息”）。
   • 上下文信息：提供必要的背景，如相关的数据结构（User模型的Pydantic定义）、项目依赖等。
   • 约束条件：非功能要求，如“代码必须兼容Python 3.8+”、“不能使用已弃用的库”。

2. Test Suite（测试套件）：这是质量守门员。一套与工件规格绑定的、可自动执行的测试集合。测试可以是：

   • 单元测试：针对生成代码的函数级测试。
   • 集成测试：检查生成代码是否能与现有代码库正确编译或交互。
   • 静态分析：用linter（如flake8, pylint）检查代码风格和潜在错误。
   • 自定义验证器：一个简单的Python函数，检查生成文档是否包含特定章节，或配置文件的格式是否正确。

3. Agentic Generator（智能体生成器）：这是执行引擎。它接收工件规格和（可选的）历史反馈，调用底层的大语言模型来生成候选工件。它的“智能体”特性体现在，当测试失败时，它并非简单地重试，而是能够接收测试失败的错误信息或输出，将其作为新一轮生成的“反馈”融入提示中，引导模型进行针对性修正。这模拟了一个开发者根据测试错误调试代码的过程。

4. Orchestrator（编排器）：这是大脑。它控制整个“生成-测试”循环的流程：

   • 初始化任务，加载规格和测试。
   • 调用生成器产生第一个候选版本。
   • 在隔离环境（如临时目录、沙箱）中执行测试套件。
   • 分析测试结果。如果全部通过，则返回成功的工件；如果失败，则提取失败信息，决定下一步策略（例如：直接让生成器基于错误反馈重试、调整生成参数、或者触发更复杂的修复逻辑）。
   • 管理重试次数和超时，防止无限循环。

这个架构的美妙之处在于它的清晰和可扩展性。每个组件都有明确的接口，你可以替换其中的任何部分。例如，你可以为生成器接入一个更强大的模型，或者为测试套件增加更严格的安全扫描。

3. 实战演练：从零构建一个TAG任务

纸上谈兵终觉浅，我们通过一个具体的例子，来看看如何用TAG框架解决一个实际问题。假设我们经常需要为不同的数据模型（如Product,Order）生成对应的RESTful API服务层代码。手动编写虽然不难，但重复且容易在命名规范、错误处理上不一致。我们的目标是：输入一个Pydantic模型定义，自动生成包含CRUD端点、符合项目规范的FastAPI路由器代码。

3.1 环境准备与框架安装

首先，由于TAG是一个相对新颖的概念，你可能需要从开源仓库克隆或通过包管理器安装其实现。这里我们假设有一个名为tag-framework的Python包。

# 假设通过pip安装 pip install tag-framework # 或者从源码安装 git clone <TAG项目仓库地址> cd tag-framework pip install -e .

接下来，创建一个新的项目目录，结构如下：

my_tag_project/ ├── config/ # 存放TAG任务配置文件 ├── artifacts/ # 成功生成的工件会存放 here ├── tests/ # 存放针对生成工件的测试用例 └── run_task.py # 主运行脚本

3.2 定义工件规格（Artifact Spec）

我们在config/product_api.yaml中定义第一个生成任务。

# config/product_api.yaml artifact_spec: name: "product_fastapi_router" description: "为Product模型生成一个完整的FastAPI路由器文件，包含增删改查端点。" context: # 提供模型定义，这是生成代码的关键上下文 model_definition: | from pydantic import BaseModel from typing import Optional from datetime import datetime class Product(BaseModel): id: Optional[int] = None name: str description: Optional[str] = None price: float stock: int created_at: Optional[datetime] = None # 提供项目规范示例 coding_standard: "使用snake_case命名变量和函数。使用类型注解。异常处理使用HTTPException。依赖注入使用Depends。" constraints: - "必须使用FastAPI和Pydantic。" - "代码必须通过mypy静态类型检查（忽略缺失的导入）。" - "需要包含以下端点：GET /products, GET /products/{id}, POST /products, PUT /products/{id}, DELETE /products/{id}。" - "POST和PUT端点必须验证输入数据。" - "使用异步SQLAlchemy（假设）进行数据库操作，但生成时用伪代码注释代替具体连接逻辑。"

这个规格文件清晰地描述了“我们要什么”，并且提供了生成所需的全部背景知识。

3.3 构建测试套件（Test Suite）

测试是TAG的灵魂。我们为这个生成任务编写一个测试文件tests/test_product_router.py。注意，这些测试是在生成之后，用于验证生成的代码是否合格。

# tests/test_product_router.py import sys import os import tempfile import subprocess from pathlib import Path # 这是一个自定义验证器，将被TAG框架调用 def validate_generated_router(router_code: str, spec: dict) -> dict: """ 验证生成的router代码。 返回一个结果字典，例如：{'passed': False, 'message': '错误信息'} 或 {'passed': True} """ results = {'all_passed': True, 'details': []} # 测试1：语法检查 with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f: f.write(router_code) temp_file = f.name try: # 使用python -m py_compile进行语法检查 result = subprocess.run([sys.executable, '-m', 'py_compile', temp_file], capture_output=True, text=True) if result.returncode != 0: results['all_passed'] = False results['details'].append({'test': 'syntax', 'passed': False, 'error': result.stderr}) else: results['details'].append({'test': 'syntax', 'passed': True}) finally: os.unlink(temp_file) # 测试2：关键端点名称检查（简单示例） required_endpoints = ['/products', '/products/{id}'] for endpoint in required_endpoints: if f'@router.get("{endpoint}")' not in router_code and f'@router.post("{endpoint}")' not in router_code: # 简化检查，实际应更严谨 results['all_passed'] = False results['details'].append({'test': f'endpoint_{endpoint}', 'passed': False, 'error': f'Missing endpoint: {endpoint}'}) else: results['details'].append({'test': f'endpoint_{endpoint}', 'passed': True}) # 测试3：是否包含必要的导入（FastAPI, APIRouter, HTTPException等） required_imports = ['FastAPI', 'APIRouter', 'HTTPException', 'Depends'] for imp in required_imports: if imp in router_code: results['details'].append({'test': f'import_{imp}', 'passed': True}) else: # 对于Depends，可能以`from fastapi import Depends`形式存在，这里做简单检查 if 'Depends' not in router_code: results['all_passed'] = False results['details'].append({'test': f'import_{imp}', 'passed': False, 'error': f'Missing import related to: {imp}'}) return results

这个测试套件包含了语法检查、功能点验证和基础规范检查。在实际项目中，你可能会集成更强大的工具，比如用ast模块进行抽象语法树分析，或者用pytest直接导入生成的模块进行更真实的单元测试。

3.4 配置与运行生成任务

现在，我们需要一个主脚本来粘合一切。创建run_task.py。

# run_task.py import yaml import asyncio from tag_framework import Orchestrator, OpenAIGenerator, LocalTestExecutor # 假设框架提供了这些类 async def main(): # 1. 加载工件规格 with open('config/product_api.yaml', 'r') as f: config = yaml.safe_load(f) artifact_spec = config['artifact_spec'] # 2. 初始化生成器（这里以OpenAI为例） # 你需要设置你的OPENAI_API_KEY环境变量 generator = OpenAIGenerator( model="gpt-4", system_prompt="你是一个资深的Python后端开发者，擅长编写高质量、符合规范的FastAPI代码。请根据用户提供的规格和上下文生成代码。" ) # 3. 初始化测试执行器 # 这里使用我们自定义的验证函数，框架应能调用它 test_executor = LocalTestExecutor( validation_function="tests.test_product_router.validate_generated_router" ) # 4. 创建编排器 orchestrator = Orchestrator( generator=generator, test_executor=test_executor, max_retries=3, # 最大重试次数 retry_delay=1.0 # 重试间隔（秒） ) # 5. 运行任务 print("开始执行TAG任务...") result = await orchestrator.run(artifact_spec) # 6. 处理结果 if result.success: print("✅ 生成成功！") print(f"生成内容预览：\n{result.artifact[:500]}...") # 打印前500字符 # 保存生成的工件 with open('artifacts/product_router.py', 'w') as f: f.write(result.artifact) print("工件已保存至 artifacts/product_router.py") print(f"总共尝试了 {result.attempts} 次。") else: print("❌ 生成失败。") print(f"最后一次错误：{result.last_error}") print(f"测试失败详情：{result.test_failures}") if __name__ == "__main__": asyncio.run(main())

运行这个脚本，TAG框架就会开始工作。它会先让GPT-4根据我们的规格生成第一版代码，然后调用我们的测试函数进行验证。如果测试失败（比如漏了某个端点），编排器会把错误信息反馈给生成器，生成器会调整提示（例如：“上一版代码缺少对/products/{id}端点的实现，请修正。”），然后产生第二版代码。如此循环，直到通过所有测试或达到最大重试次数。

3.5 一次可能的生成结果

经过一轮或几轮迭代后，我们可能在artifacts/product_router.py中得到如下代码：

from fastapi import APIRouter, Depends, HTTPException, status from pydantic import BaseModel from typing import List, Optional from datetime import datetime # 假设的数据库依赖层，实际项目中需要具体实现 from .database import get_db, AsyncSession from . import models # 假设Product SQLAlchemy模型已定义 router = APIRouter(prefix="/products", tags=["products"]) # 使用Pydantic模型定义请求/响应体 class ProductCreate(BaseModel): name: str description: Optional[str] = None price: float stock: int class ProductResponse(ProductCreate): id: int created_at: datetime class Config: from_attributes = True @router.get("/", response_model=List[ProductResponse]) async def list_products( skip: int = 0, limit: int = 100, db: AsyncSession = Depends(get_db) ): """ 获取产品列表。 """ # 伪代码：实际应从数据库查询 # products = await db.execute(select(models.Product).offset(skip).limit(limit)) # return products.scalars().all() return [] # 占位符 @router.get("/{product_id}", response_model=ProductResponse) async def get_product( product_id: int, db: AsyncSession = Depends(get_db) ): """ 根据ID获取单个产品。 """ # 伪代码 # product = await db.get(models.Product, product_id) # if product is None: # raise HTTPException(status_code=404, detail="Product not found") # return product raise HTTPException(status_code=404, detail="Product not found") # 占位符 @router.post("/", response_model=ProductResponse, status_code=status.HTTP_201_CREATED) async def create_product( product_in: ProductCreate, db: AsyncSession = Depends(get_db) ): """ 创建新产品。 """ # 伪代码：数据验证和保存 # db_product = models.Product(**product_in.dict()) # db.add(db_product) # await db.commit() # await db.refresh(db_product) # return db_product return ProductResponse(id=1, created_at=datetime.now(), **product_in.dict()) # 占位符 # ... 省略PUT和DELETE端点实现

可以看到，生成的代码结构清晰，包含了所有要求的端点，使用了正确的FastAPI装饰器和依赖注入，并且按照我们的约束使用了伪代码注释来替代具体的数据库操作。它通过了我们之前定义的语法检查、端点检查和导入检查。

4. 深入核心：智能体如何与测试反馈协同工作

TAG框架最精妙的部分在于“智能体”（Agentic）与“测试驱动”（Test-Driven）的闭环。这不仅仅是“生成-检查-再生成”的简单循环，而是一个有学习能力的反馈系统。

4.1 反馈信息的结构化

当测试失败时，框架不能仅仅告诉模型“失败了”。它需要提供结构化、可操作的反馈。在我们的例子中，自定义验证器返回的results['details']列表就是结构化的反馈。编排器会将这些信息提炼成给生成器的提示。例如：

初始提示：“请根据提供的Product模型定义，生成FastAPI路由器代码...”第一次生成后测试失败：测试endpoint_/products/{id}未通过。第二次生成提示：“请根据提供的Product模型定义，生成FastAPI路由器代码。注意，上一轮生成的代码缺少对GET /products/{product_id}端点的实现。请确保包含该端点。”

更高级的框架实现可能会解析单元测试的堆栈跟踪（Traceback），提取出具体的错误行号和错误信息（如AttributeError: 'NoneType' object has no attribute 'name'），并将这些精准的信息反馈给模型，引导其进行针对性修复。

4.2 生成策略与重试机制

编排器需要智能地管理重试过程。简单的“失败就重试”可能导致无限循环或陷入局部最优。TAG框架可能包含以下策略：

• 增量修正：在后续提示中，不仅包含原始规格和最新错误，还附加上一轮生成的代码，让模型在原有基础上修改。这通常比每次都从头生成更有效。
• 提示升温：如果连续失败，可以逐步增加提示的“温度”（Temperature）参数，让模型产生更多样化的输出，以跳出当前的错误模式。
• 规格分解：对于复杂的生成任务，如果整体失败，编排器可以尝试将任务分解成多个子任务（如先生成模型，再生成CRUD端点），逐个击破。
• 备用模型回退：如果主模型（如GPT-4）多次失败，可以切换到备用模型（如Claude或本地模型）尝试不同的生成风格。

4.3 测试的层次与成本

在TAG流程中，测试的执行是有成本的（时间、API调用次数）。因此，设计一个分层测试策略至关重要：

1. 快速静态检查（低成本）：最先执行，如语法检查、导入检查、关键词匹配。这些测试能快速过滤掉明显不合格的生成物。
2. 功能逻辑测试（中成本）：随后执行，如运行单元测试、检查生成的函数是否被正确定义。这可能需要在一个轻量级的隔离环境中执行代码。
3. 集成与运行测试（高成本）：最后执行，如将生成的模块导入真实项目环境、运行端到端测试。这类测试成本高，通常只在快速检查通过后，用于最终验证。

一个好的TAG任务配置，会按照这个顺序组织测试套件，以最小的成本尽快淘汰不良候选，将宝贵的重试机会留给最有希望的生成结果。

5. 高级应用场景与模式扩展

理解了基础原理后，TAG框架的潜力远不止生成API代码。它的范式可以应用到任何需要高质量、结构化输出的AI生成任务中。

5.1 场景一：自动化文档生成

问题：为代码库生成或更新API文档（如OpenAPI Spec），但手动维护容易过时。TAG解决方案：

• 工件规格：目标是根据当前代码的AST（抽象语法树）和已有的部分文档，生成完整的openapi.yaml文件。
• 测试套件：
  • 验证生成的YAML语法正确。
  • 使用prance或openapi-spec-validator库验证是否符合OpenAPI 3.0规范。
  • 确保文档中提到的每个API路径都在实际代码中存在（反向检查）。
  • 检查必填字段（如info.title,info.version）是否齐全。
• 智能体：模型需要理解代码结构和OpenAPI规范的复杂关系。反馈循环可以纠正诸如数据类型映射错误、缺少参数描述等问题。

5.2 场景二：配置代码与基础设施即代码（IaC）生成

问题：为不同的微服务生成Kubernetes部署配置（Deployment, Service, Ingress），要求符合公司的安全策略和资源规范。TAG解决方案：

• 工件规格：输入服务名称、镜像地址、端口、资源需求（CPU/内存），生成一套K8s YAML文件。
• 测试套件：
  • 使用kubeval或kubeconform验证YAML语法和K8s模式合规性。
  • 自定义检查：确保没有使用latest标签、必须设置资源限制（limits/requests）、必须包含探针（liveness/readiness）配置等。
  • 可以运行kubectl apply --dry-run=client进行预演验证。
• 智能体：模型需要掌握K8s配置的最佳实践。测试反馈可以确保生成的配置不仅是语法正确，更是生产就绪的。

5.3 场景三：测试用例本身生成

问题：为已有的复杂业务函数编写全面的单元测试用例费时费力。TAG解决方案：

• 工件规格：输入函数的源代码及其签名，生成对应的pytest单元测试文件。
• 测试套件：
  • 生成的测试文件本身必须语法正确。
  • 运行生成的测试，它们必须能够成功导入被测函数。
  • 生成的测试用例执行时，其断言（assert）必须全部通过。（这里形成了一个有趣的“自举”：用测试来验证生成的测试是否有效）。
  • 可以计算测试覆盖率（如使用coverage.py），要求生成的测试达到一定的行覆盖率或分支覆盖率阈值。
• 智能体：模型需要理解代码逻辑并推断出各种边界条件。反馈循环可以补充遗漏的测试用例或修正错误的断言。

5.4 模式扩展：多智能体协作

对于极其复杂的工件，可以引入多智能体协作模式。例如，生成一个完整的微服务代码库：

1. 架构师智能体：根据需求生成一个高层次的设计文档（工件1）。
2. API智能体：基于设计文档，生成OpenAPI规范（工件2）。测试套件验证其与设计文档的一致性。
3. 后端智能体：基于OpenAPI规范，生成FastAPI服务器代码（工件3）。测试套件验证其符合OpenAPI规范。
4. 前端智能体：基于同一个OpenAPI规范，生成React/Vue客户端代码（工件4）。

每个阶段都是一个独立的TAG任务，上游任务的输出成为下游任务的输入和上下文。整个流程可以串联或并联执行，形成一个强大的AI辅助开发流水线。

6. 避坑指南与最佳实践

在实际使用TAG模式或类似框架时，我踩过不少坑，也总结出一些让流程更顺畅的经验。

6.1 测试设计是成败关键

最大的误区：认为测试只是最后的把关者。在TAG中，测试是引导生成方向的导航仪。

• 测试要原子化、快速：一个测试最好只验证一件事。避免编写冗长、缓慢的集成测试作为第一道关卡，这会严重拖慢迭代速度。优先使用静态分析、模式匹配等轻量级检查。
• 提供清晰的失败信息：测试失败时输出的错误信息，要尽可能清晰、具体，能被模型理解。避免AssertionError: False is not True这种信息，而是"生成的函数缺少对输入参数age的类型注解"。
• 从简到繁，分层验证：如前所述，建立测试金字塔。先过语法关，再过功能关，最后过集成关。

6.2 提示工程与规格编写

• 上下文不是越多越好：给模型的上下文（如artifact_spec.context）要精准相关。无关的代码或文档会成为噪声，干扰模型判断。只提供生成当前工件所必需的信息。
• 将约束明确写入规格：不要指望模型能猜出你的潜规则。像“代码必须用Black格式化”、“所有字符串必须使用双引号”这类风格要求，应明确写在constraints里。更好的做法是，让一个格式化测试（如调用black --check）来强制执行。
• 使用系统提示（System Prompt）塑造角色：在初始化生成器时，一个强大的系统提示能极大提升输出质量。例如：“你是一个严谨的、注重细节的软件架构师，擅长编写可维护、符合最佳实践的代码。你会严格遵循用户给出的所有约束。”

6.3 成本与性能优化

• 设置合理的重试上限和超时：对于简单任务，max_retries=3可能足够；对于复杂任务，可能需要5-8次。同时设置总超时，防止任务卡死。
• 缓存测试结果：如果测试执行成本高（如启动一个数据库），可以考虑缓存成功通过的生成物及其哈希值。当遇到相同或相似的规格时，可以直接返回缓存结果，节省资源和时间。
• 考虑使用更便宜的模型进行初筛：可以用GPT-3.5-turbo进行前几轮快速生成和简单测试，只有通过初筛的候选，才用更强大（也更贵）的GPT-4进行精修和复杂测试。

6.4 集成到CI/CD流水线

TAG框架的产出是代码或配置，自然应该纳入版本控制和CI/CD流程。

1. 生成即代码：将成功的工件保存到代码仓库中，和手写代码一样进行代码审查（Code Review）。AI生成不是免检金牌，人工审核对于关键业务逻辑仍然必要。
2. TAG任务本身也是代码：你的工件规格文件（YAML）和测试套件（Python）应该被版本化管理。它们的演变历史就是你对AI生成质量要求不断提高的历史。
3. 在CI中运行TAG验证：可以在拉取请求（PR）中设置一个CI任务，当相关模型或规格发生变化时，自动触发TAG任务重新生成工件，并运行测试。确保生成结果始终符合最新标准。

7. 常见问题与故障排查

在实际操作中，你可能会遇到以下典型问题：

TAG框架所代表的“测试驱动智能体生成”范式，本质上是在用软件工程中最经典、最可靠的方法论——测试，来驯服大语言模型生成的不确定性。它不是一个全自动的魔法盒，而是一个强大的人机协同工具。开发者负责定义精确的规格和测试（即“什么是对的”），智能体负责在巨大的可能性空间中探索和实现（即“怎么做”）。这种分工将人的抽象思维、质量要求和AI的执行力、知识广度结合起来，为自动化生成高质量、可信任的软件工件开辟了一条切实可行的道路。从我自己的使用体验来看，最大的转变在于思维模式：从“我该如何提示AI才能让它做对”，变成了“我该如何定义测试，才能判断AI做对了”。后者是一个更可控、更可重复、也更符合工程师直觉的过程。