企业官网建设流程全解析

AI Coding 辅助下的 L2 前视感知原型开发，这个话题最近在自动驾驶团队的讨论里越来越热。不少工程师都想知道，用大模型写代码能不能缩短感知原型的实现周期，以及 AI 生成的代码到底能在自动驾驶这种安全敏感场景里推到什么边界。我自己的答案是：周期可以从 8-12 周压到 4-6 周，但工程边界不是由 AI Coding 决定的，而是由功能安全意识和自动化测试体系决定的。这篇记录就六块内容：需求拆解、工具选型、周期拆解、核心实现、工程边界、问题排查，都是我这次做 L2 前视感知原型的真实经历。适合正在做或准备做自动驾驶感知原型的技术团队参考，也适合对 AI Coding 交付质量抱有好奇的工程师围观。

1. L2 前视感知原型：先拆需求，再谈周期

1.1 L2 和 L2+ 的感知边界在哪里

先明确一个事：我们说的 L2，从 SAE 分级来看，驾驶员仍是最终责任主体，系统只提供纵横向辅助。所以 L2 前视感知原型的核心功能其实不多——前向碰撞预警（FCW）、自动紧急制动（AEB）、自适应巡航（ACC）、车道偏离预警（LDW）、车道保持辅助（LKA）。这些功能对应的感知目标也相对收敛：车辆、行人、骑行者、车道线，有时带一个可行驶区域。

为什么我不建议一上来就做 L2+ 的 BEV 感知？因为 L2+ 的感知系统要解决遮挡、跨传感器联合标定、时序融合等一堆问题，一个月根本推不动。L2 的好处是单目前视即可覆盖大部分工况，毫米波雷达可以作为冗余，但原型期甚至可以先不接雷达。把边界定义在“白天到黄昏、高速和城市快速路、无大雾大雨”这个 ODD 内，原型的可完成度会大幅提升。

这里还有一个常被忽视的点：L2 感知原型不是要做出一个“可量产”的感知系统，而是要证明技术链路是通的。因此传感器布局不需要多复杂，一台带前视摄像头的采集车，一块中等算力的边缘盒子，一套数据回放工具，基本就够了。对比 L2+ 要堆多路摄像头、激光雷达，这个起步成本要低一个数量级，非常适合团队在项目初期验证算法方向。

1.2 原型验收标准先定死，后面所有决定都容易

开发原型最怕目标漂移。开始前就应该把“跑通”具体化。我一般会压四个指标，逐个说清楚。

第一个是检测 mAP。用自己标注的 500-1000 张测试集做静态评估，目标 mAP 不低于 0.85。注意这个数字是相对你自己的数据集，不是 COCO 上的绝对值，目的是把回归测试的基准固定下来。第二个是端到端延迟。从摄像头采到一帧图像开始，到感知模块输出完整的目标列表和车道线方程，延迟控制在 100 ms 以内，实测跑 80 ms 左右比较舒服。第三个是车道线拟合误差。在真实测试道路的直线段和弯道段各取 50 个点，横向误差一般控制在 20 cm 内。第四个是稳定性。连续跑 1 小时不出崩溃、内存不持续上涨、日志无异常堆积。

验收标准看起来是纸面工作，但越早定死，后面被 AI 生成代码带偏的概率越低。举个实际例子，如果验收指标里没有定延迟，AI 给你写一个 Python 版的 NMS 解码，跑起来确实能用，但到了实车一测只有 5 FPS，你就得从后处理整个重来。相反，验收标准先把 100 ms 钉死，写代码的时候就会主动考虑向量化、C++、TensorRT 这些手段。原型阶段最怕的不是代码写得慢，是做完才发现测错了东西。

2. AI Coding 工具选型与工作流

2.1 工具选型：Cursor、Copilot、Aider 怎么选

AI Coding 工具已经不是“一个自动补全”那么简单了。现在主流的有三类：编辑器内联补全、IDE agent、CLI 工具。我这次没有只锁定一个工具，而是按场景混着用。

实际项目里我的组合是 Cursor + Copilot，Copilot 负责写单函数，Cursor 负责改整个工程骨架，比如一次性生成目录结构、CMakeLists、数据加载类。Aider 则在远程服务器上用，训练脚本迭代特别快，改完直接提交 git。选型的原则是：能用内联补全的不要开整个仓库索引，减少 AI 无谓的全局改动，也减少 review 的负担。

还有一点心得：远程训练机上没有图形界面，Aider 这种 CLI 工具反而比 IDE 更方便。多模型支持是加分项，但实际用下来模型差异没有那么大，关键是上下文管理好。如果你是单人开发，建议直接 Cursor 一把梭；如果是一个团队协作，尽量统一工具链和代码规范，否则后面合入时风格分裂的代码会让你很难受。

2.2 代码生成规范示例：让 AI 输出可靠代码的第一道闸

热词里有一个“AI Coding 代码生成规范示例”，这一点我特别有体会。没有规范约束时，AI 生成的代码看起来都能跑，但往往风格极度混乱：有的函数 200 行，有的变量干脆用data、res。我让 AI 生成代码前，会先给它一套约束。

• 先写清楚函数签名、输入输出类型和边界条件，再写实现。
• 函数长度不超过 60 行，超过就拆函数。
• 所有外部 API 调用必须注明来源，不能凭空造。
• 必须处理空输入、异常输入，不能裸用数组下标。
• 注释写“为什么”，不写“是什么”。

把这段规范直接贴进 Cursor 的规则文件（比如.cursorrules），后面生成的代码质量会有质的提升。有一次我让 AI 生成一个画框函数，没加规范时它自己编了个cv2.paint_text_with_alpha的不存在方法，加上规范后它老老实实写了个两层循环。这个例子足够说明规范的价值。

代码生成规范不是限制 AI，而是帮助 AI 对齐真实工程的约束。传统开发里没人会在每个 prompt 里写这些，但 AI Coding 时代这非常重要。我的习惯是先把规范文件写好，然后再开始对话生成代码。这样每一轮生成都自带约束，而不是等代码出来以后再人工修正，效率差距非常大。

3. 实现周期拆解：关键路径和真实时间分配

3.1 总体时间线：AI Coding 把周期压缩到哪里

前面说要 4-6 周，这个数字不是拍脑袋。下面这张表，左边是传统手写代码，右边是这次用 AI Coding 的真实结果。

整体算下来，原计划 9 周的项目，压缩到 5 周左右。但注意，省下的时间几乎全部集中在“写代码”这件事上，而数据采集、标注、实车验证这些物理流程基本没有变化。这也解释了为什么不要指望 AI Coding 能替代测试工程，它只能让你把有限的时间花在真正难的地方。

一个容易忽略的现实是：AI Coding 加速之后，瓶颈反而转移了。你可能一周就把模型训练脚本、数据管线、后处理代码全写完了，但第二个礼拜全耗在等待标注、修数据质量、标定摄像头内参上。如果团队没有提前并行安排这些数据侧工作，AI Coding 带来的周期压缩会被数据等待吃掉一大半。

3.2 数据准备阶段：物理流程决定周期的下限

这个阶段最大的坑，是以为 AI Coding 能自动处理数据。它确实可以生成标注格式转换、图像质量筛查这样的脚本，但采集车不能因为 AI 而自动开上路。我这次的数据准备分成四步：采集、筛选、标注、增强。

采集用的是前视摄像头+GNSS 记录，跑了几条固定路线上，覆盖高速、城市快速路、隧道和傍晚时段。筛查环节让 AI 生成脚本自动筛掉过曝、模糊、静止帧，这一步大概省了一天。标注采用 CVAT 加半自动标注，先跑一个预训练模型打预标签，人工修正，效率确实比纯手工高一倍。增强写了一个数据增强 pipeline，包括亮度扰动、空间变换、天气模拟。

AI Coding 在这里的加速点在于数据统计和预标签脚本，不在数据本身。如果目标是把周期压到一个月以内，数据环节一定要提前并行启动，不要在算法代码完成之后再拍采集排期。我现在每个新项目第一周就把采集车排出去，边写代码边采数据，等代码能跑了，数据也标注得差不多了。

3.3 模型训练与迭代：AI 生成训练脚本，但超参需要理解

模型层面我选的是 YOLOv8 做目标检测，UFLD（Ultra Fast Lane Detection）做车道线，这两个都是开源基础模型，拿来在自有数据上微调最快。AI Coding 确实能直接生成 dataloader、训练循环、混合精度、EMA 更新，但我强烈不建议拿到代码就直接跑，你得知道自己在做什么。

# 用 AI 生成的简化训练循环片段 for epoch in range(epochs): for batch in dataloader: img, targets = batch loss = criterion(model(img), targets) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

这段代码本身没毛病，但它没有包含任何数据校验、loss 异常抛出、梯度裁剪，一旦训练中途挂了，你只能看黑乎乎的日志猜原因。实操中我会让 AI 再补一个“训练状态检查脚本”，实时把 loss、学习率、显存占用画出来，这样曲线一旦发散能立刻发现。

训练阶段的几个小技巧：先用 1000 张子集验证流程，不要全量；用混合精度减少显存；学习率直接抄官方，再根据 loss 曲线调整，一般 1e-3 起步，到后期降到 1e-4。保存模型时记录class_map和输入尺寸，避免部署时错位。训练阶段我只让 AI 做三种事情：生成脚本、做 loss 可视化、检查崩溃源头。实际调参还是自己来，毕竟一辆车 30 km/h 时检测框慢 50 ms 的后果，AI 没有感觉。

4. 实操过程与核心环节实现

4.1 YOLO 输出解码与 NMS：AI 生成的典型代码长这样

前视感知里，模型输出解码是 AI Coding 最好发力又最容易翻车的地方。下面这段代码基本是 AI 一次性写出来的，我们加上了一堆边界处理后再用。decode_boxes接受模型输出的四维张量，返回目标列表。

import numpy as np def decode_boxes(pred, conf_thres=0.25, iou_thres=0.45): """YOLO 输出解码 + NMS。 pred 形状为 (B, C, N)，B=1，C=84（80类别+4坐标）。 返回 [{"class_id": int, "score": float, "box": [x1, y1, x2, y2]}]。 """ pred = pred[0].transpose(1, 0).astype(np.float32) boxes = [] for row in pred: scores = row[4:] class_id = int(scores.argmax()) score = float(scores[class_id]) if score < conf_thres: continue cx, cy, w, h = row[:4] boxes.append([class_id, score, cx - w / 2, cy - h / 2, cx + w / 2, cy + h / 2]) if not boxes: return [] boxes = np.array(boxes) pick = [] candidates = list((-boxes[:, 1]).argsort()) # score 降序 while candidates: best = candidates[0] pick.append(best) best_box = boxes[best][2:] rest = candidates[1:] ious = compute_iou(best_box, boxes[rest][:, 2:]) candidates = [r for r, iou in zip(rest, ious) if iou < iou_thres] return [{"class_id": int(boxes[i, 0]), "score": float(boxes[i, 1]), "box": boxes[i, 2:6].tolist()} for i in pick]

注意，AI 第一次生成时compute_iou并没有定义，这就是需要人工 review 的地方。具体实现很简单，两个框的交并比计算，网上到处都是，这里不占篇幅。我想强调的是，AI 能快速给出主体结构，但“缺函数”“漏 import”“注释和实现不一致”是高频问题，所以必须编译/运行验证。

这段解码代码质量其实还可以，边界分支处理得也不错。但有个隐蔽问题：当候选框超过 20000 个时，Python 循环会把 FPS 拉低。这里就是工程边界：AI 给的“能跑”和量产的“能实时”之间，差了向量化或 C++ 实现。我们在原型阶段先用 numpy，后期一定要在 TensorRT 导出的后处理里用 C++ 重写。

4.2 把 AI 生成代码收进工程骨架：目录、接口、配置

AI Coding 很容易丢一个文件就跑，所以工程上要守住接口。我的做法是：让 AI 直接基于一个 contract 文件生成代码，比如只输出满足pipeline/output.h声明的实现。

// pipeline/output.h struct BBox { int class_id; float score; float x1, y1, x2, y2; }; std::vector<BBox> DecodeBBoxes(const float* pred, int num_preds, float conf_thres, float iou_thres);

给 AI 的 prompt 也很简单：“实现 DecodeBBoxes，输入 float 数组 pred，布局方式和 YOLOv8 输出一致。要求实现放在 decode.cpp，不得修改 output.h。完成之后写一个单元测试 decode_test.cpp。”这样做的原因很简单：把 A/B 边界看好，AI 生成的代码再乱也不会跑出缓冲区。

工程里还有一个容易被忽视的点是配置文件。AI 生成的代码经常把阈值、模型路径、图像尺寸写死在代码里，一旦换一台车就得改代码重编。我习惯让 AI 读一个 YAML 配置，所有能调的参数都放进去，包括置信度阈值、NMS 阈值、模型输入尺寸、相机内参文件路径。这样后面调参只需要改配置，不用动代码，也能避免 AI 改代码时不小心把参数弄坏。

重要：AI 生成代码必须经过编译和单测合入，不要直接部署到车上。哪怕只是一个小小的decode函数，一旦上了实车，出问题的成本就不是分钟级的了。

5. 工程边界：AI Coding 改变速度，不改变规则

5.1 AI 生成代码的三种失效模式

先说幻觉 API。AI 会编造不存在的接口，比如cv2.fit_lane、std::fast_clamp。如何识别？打开编译器/解释器报错再问 AI 修正，而不是直接相信它。我遇到过 AI 一本正经地给了个torchvision.ops.nms的用法，参数完全正确，但输入类型不对，结果一跑就崩。

第二种是局部正确、全局错误。单函数能过单测，但它的输入输出约定跟主程序里其它模块不一致。比如生成一个CameraFrame结构体，字段名是img_bgr，但 C++ 侧是image，联调时浪费一整天。这类问题靠单测无法发现，只有真正走到模块接口的集成测试才能暴露。

第三种是边界条件缺失。AI 对空数组、NaN、相机断流这类情况经常不管，自动驾驶里这些都是家常便饭。所以我坚持让 AI 生成代码时带上异常处理，明显不合法输入要有日志输出。如果 AI 生成的函数在输入为空时直接索引越界，再好的算法也没法用。

5.2 L2 感知对代码质量的底线：确定性、可追溯、可测试

感知代码出厂不是写完就验收。对我的团队来说，哪怕只是一个原型，三条底线也不会让 AI 来碰。

确定性：相同输入必须相同输出。让 AI 生成代码时要留意随机初始化、动态阈值等写法，这些在测试阶段会非常烦人。可追溯：每个算法模块对应需求编号，AI 生成的代码要能落到需求条目上，比如SYS_REQ_02，不能只保留一行行碎片逻辑。可测试：不要让 AI 生成只有内部 IO 而无法注入的代码，否则 CI 跑不下去，边界也无法收敛。

从热词里来看，大家很关心“AI Coding 的到来会不会让代码质量下降”。我的观点是：代码质量下降不是因为 AI 生成了坏代码，而是因为流程里没有加约束。如果团队本来就缺少 review、单测和回归机制，那即使手写代码质量也大概率不行；反过来，有规范约束后，AI Coding 会成为一个 quality amplifier——好的约束放大质量，差的约束放大混乱。

5.3 AI Coding 工程师是不是人工智能工程师

热词里还有一个很有意思的讨论：“AI Coding 工程师属人工智能工程师吗”。做感知原型这段时间，我的感受是：AI Coding 是一个技能，不是一种职业。最后交付 L2 前视感知原型的人，仍然需要理解模型评估、数据分布、后处理逻辑、安全降级和集成测试，这些东西 prompt 再顺也给不出来。你可以把 AI Coding 当成手速极快的实习生，但技术负责人永远要自己当。

如果你正以“AI Coding 工程师”的身份进入自动驾驶团队，建议尽快补齐传感器标定、数据闭环、功能安全方法论，不然很容易陷入只会改 prompt 不会 debug 模型的尴尬。原型阶段可以靠 AI 快速堆代码，但到真车上出了问题，能定位问题的人，永远需要懂系统的人。

6. 常见问题与排查技巧实录

6.1 晚上误检率莫名上升，怎么定位

这个问题是数据分布问题而非代码问题。我现在的排查顺序：先从数据统计入手，看看模型在低亮度样本上的 AP；再看预处理是不是有 bug，比如图像压缩参数在低亮度下丢失严重；最后再看模型的置信度阈值是否固定。某次傍晚拿 200 张黄昏图测试，发现 AEB 的误检率比白天高 5 倍。找数据后发现训练集里亮度低于 60 的样本只有 12%，AI 没什么好办法，只能增加数据增强和收集更多弱光样本，另外把 NMS 阈值调高 0.05，误检明显回落。

6.2 车道线在弯道拟合错乱

原因大概率来自拟合范围或曲线模型。弯道中车道线在图像里的曲率变化快，一条二次多项式可能不够。我的做法是前段和后段分别拟合，并在接缝处做加权平滑。AI Coding 可以直接生成一个分段拟合函数，但加权系数要在实车上调，这部分算法经验无法用统计代替。提示词可以这样写：“写一个分段二次多项式拟合函数：输入是车道线的起点、终点和样本点，输出是两条曲线的系数，并在连接点处平滑过渡。”

6.3 AI 改了一个函数，导致另一个模块回归

这是最常见的工程事故。解决方式是把 AI 的修改局限到指定文件，并在生成后立即跑全量单测。用 git 做隔离：单独一个分支，CI 过了再合入。不要用“重新生成全部”当常规操作，成本很高。我现在通常给 AI 的指令里都会加一句“只修改 xxx 文件，不要动其他文件”，配合 git diff 审阅，基本能避免大范围误改。

6.4 帧率不达标

8 FPS 上不到 25 FPS 时，先 profiler 看瓶颈。有时候耗时不长，而是 decode 的 Python 循环，或者图像预处理被重复执行了两次。用 AI Coding 生成一份 profiling 脚本，得到各阶段耗时，然后用 TensorRT 加 int8 量化，或把 decode 移到 GPU/后处理专用线程。模型输入分辨率我一般用 640 x 640，这是一个速度与精度相对平衡的点。

6.5 遇到 AI 生成代码版本混乱

用 AI Coding 切忌每轮 prompt 都大改。提交信息最好让它明确：“只更新 decode.cpp，不碰 CMakeLists 和 config”。并且每次生成后至少有 5 分钟的 self-review 再 commit。AI 会把旧的实现全部替换掉，特别容易把之前辛苦调好的参数一并冲掉。所以配置文件必须独立于代码，AI 能改代码但别让它直接改已经标定好的内参和阈值。

最后说一点个人体会。我把这次项目里 AI 生成的代码和手写的代码放到一起看，真正让我省时间的不是那些花哨的算法，而是把数据脚本、读取样本、画框 debug、写测试样例这些“体力活”全部自动化了。L2 前视感知原型的实现周期确实被 AI Coding 大幅压缩，但工程边界依然要靠人来守护——尤其是确定性验证、安全降级和实车测试。如果你接下来也要做类似的感知原型，建议先定好 ODD 和验收指标，再让 AI Coding 帮你跑得快一点。