企业官网建设流程全解析

有人问我：一个人，用 AI Coding，最快多久能搭出一个 L2 前视感知原型？我的答案是三到四周。这个数字不是拍脑袋，是我最近刚完成一轮实测得出的结论。我把一个原本预计要两个半月的感知原型项目压缩到三周，中间大量使用了 AI Coding 工具，也结结实实踩了不少 AI 生成代码埋下的坑。这篇内容不打算吹 AI Coding 万能，也不打算唱衰它，而是把账算清楚：哪些事情它真的把时间从周砍到了天，哪些事情它完全帮不上忙，以及"三到四周"这个结论到底建立在什么假设之上。

如果你正打算用 AI Coding 辅助做自动驾驶感知类项目，或者正在评估这类项目的周期，这篇可以当一份经验参考；如果你已经摸过 AI Coding 但觉得"用了反而更慢"，后面对工程边界的分析或许能帮你找到原因。

1. 先对齐概念：L2 前视感知"原型"到底要求做到什么

1.1 从前置摄像头到 ACC/AEB，中间缺什么

先说清楚 L2 前视感知的原型到底是个什么东西。L2 级组合驾驶辅助，常见功能包括自适应巡航（ACC）、车道保持辅助（LKA）、自动紧急制动（AEB）、车道偏离预警（LDW）、前向碰撞预警（FCW）。这些功能有一个共同的输入源——一颗前视摄像头。它通常装在后视镜支架附近，任务是每秒跑十几到几十帧，从图像里检出"路在哪里"和"障碍物在哪儿"。

具体拆开，感知模块至少要输出三样东西：目标检测结果（车辆、行人、骑行者，以及它们的像素框和距离）、车道线结构（左右车道线的位置、曲率、自车偏离量）、可行驶区域或道路边界。ACC 需要知道"本车道最近的前车是哪辆、离我多远"，LKA 需要知道"车道中心线在哪、我偏了多少"，AEB 需要估算"按当前相对速度，会不会撞上"。

这就是为什么我强调"原型不是写一个 YOLO 脚本就完事"。你可以花一下午用现成模型跑出一堆框，但框和"能用来做 ACC/LKA 决策"之间隔着标定、测距、时序追踪、评估指标这一整条链。

1.2 我定义的原型验收标准

为了避免"原型"两个字被聊成玄学，先亮出我当时定的验收标准，后面所有周期讨论都围绕这条清单：

传统方式做齐这套东西，我身边团队的普遍周期是两个半月到三个月。这次我给自己限了三周，并且没有减少任何验收项。依赖的东西只有一个：AI Coding 工具链。

2. 三周对两个半月：哪些环节真的被 AI Coding 提速了

2.1 提速最猛的三类工作：工程脚手架、工具脚本、可视化

先说结论：AI Coding 对感知原型项目的加速不平均，主要体现在三类"代码量大、逻辑相对独立、上下文强相关"的工作上。

第一是工程脚手架。ROS2 工作空间、CMakeLists、Python 包结构、GStreamer 取流、依赖安装脚本，这些东西一两天生成完，零错误，基本不用改。第二是工具脚本。把 ROS2 bag 抽帧转数据集、标注格式互相转换、按时间段切分数据、生成视频回放，这类脚本我用 AI 写，迭代三五次就收敛，省掉的都是以前手写踩坑的时间。第三是可视化。把检测框、车道线、BEV 俯视图叠到视频上，传统做法是调 OpenCV 绘图参数调半天，现在把坐标变换和颜色方案说清楚，一次生成基本能看。

举一个具体的例子：某天我需要把一段 ROS2 bag 抽成 KITTI 风格的训练目录，同时输出一段带 GT 叠加的可视化视频。以前这个需求从写脚本到跑通，最少大半天。这次我给 AI 描述清楚 bag 的时间戳格式、相机的 topic 名、KITTI 目录结构，二十多分钟拿到了第一版可运行脚本。这类工作在项目里占了大量时间，AI Coding 的收益是实打实的。

2.2 提速有限的环节：模型选型、部署接口、精度调优

但另一类工作 AI 的贡献就小得多。模型选型这件事，AI 只能给你几份"看起来都挺合理"的榜单和候选，真正决定选 YOLOv8s 还是 RT-DETR 的，是你的算力预算、量化友好度、在自采数据上的泛化表现。模型部署到 TensorRT/OpenVINO/地平面推理框架，AI 能生成接口代码，但一旦算子不支持、精度掉点、engine 序列化失败，AI 只能原地打转，因为它没有编译器和推理引擎的内部上下文。

精度调优更不用指望 AI。同样一组超参数，在 A 场景上涨点、在 B 场景下跌点，AI 给不出可解释的经验判断。这一块我三周里有将近四成时间耗在里面，AI 只帮我写了调参脚本和可视化对比工具，真正的调优判断全得人来。

2.3 很多人用 AI Coding 反而更慢，原因在这

这轮做下来我最大的感触是：AI Coding 能加速"从问题到代码"的转换，但它不会自动完成"从代码到正确行为"的验证。感知领域最典型的情况是——AI 生成的代码能编译、能跑单帧、输出结构也像模像样，但一放到连续帧上就出问题。

我踩过一个具体的坑：让 AI 生成一段基于卡尔曼滤波的目标追踪器，它给我返回了一个标准实现，状态向量是 [x, y, w, h, vx, vy]，逻辑没有任何问题。但在实车上跑，目标变道时追踪器把框带偏出去两三个车身长度。原因不是卡尔曼写错了，而是状态向量的运动模型假设和本车相对运动不匹配。AI 的代码没错，错的是问题建模。这类排查返工，往往比手动写代码还耗时。所以"用了 AI 更慢"的人，多数是卡在了"拿到代码但不知道验证什么"这个环节。

3. 工程边界之一："代码正确"不等于"行为可靠"

3.1 相机标定：AI 生成的代码跑通了，但测距整体偏移

单目测距的基本逻辑是用像素坐标、相机内参外参、地面平面假设，把目标底边投影到地面上反推距离。听起来简单，但这一条链路里每一步的微小误差都会被放大。

AI 能给你生成一整套张正友标定代码，棋盘格检测、角点优化、内参外参输出、反投影误差展示。问题是它生成代码时并不知道你用的是普通针孔镜头还是广角/鱼眼镜头，畸变模型选错一个，标定结果在画面中心看起来没问题，边缘区域像素误差直接超像素。更麻烦的是外参——相机装车后的俯仰角、偏航角，哪怕只是半度偏差，30 米外的目标测距就会差出好几米。

我在这个环节的经验是：AI 生成的标定代码可以作为工具，但标定结果每步都要有独立的验证闭环。内参拿标定板多次重投影看误差，外参拿实际的地面网格线对照，特别是测距结果必须拿真值对一组点验证。想让 AI 帮你"自动标得准"，目前没有捷径。

3.2 帧间稳定性：检测准不等于不抖

感知原型在数据回放里最容易暴露的问题是抖动。目标检测器本身是单帧独立推理的，同样的车连续几帧里框的位置可能跳来跳去，车道线也会因为阴影、树枝轻微抖动。决策模块拿到这种抖动信号，ACC 会忽加速忽刹车，LKA 会画龙。所以追踪和平滑不是"锦上添花"，是必选项。

AI 能写卡尔曼滤波和匈牙利匹配的框架，但状态噪声怎么设、观测噪声怎么定、目标出现和消失的时序怎么管理，这些是调参经验，AI 只能给初始值。我做了一个测试：同一段路采结果，用 AI 给的默认参数跑，ID 切换率是每千帧 40 多次；手动调完协方差和门控阈值后，降到每千帧 5 次以内。这个差距赛道上是能明显感知到的。

3.3 数据与长尾：感知的瓶颈在数据标注和场景覆盖

感知模型的性能上限由数据决定，这一点 AI Coding 改变不了。你在三周内可以高效生成代码，但视野里的卡车、行人、骑行者、锥桶，以及逆光、夜晚、雨天这些场景，不会因为代码写得快而自动覆盖。

我这次在数据上花的时间远超预期。路采只用了两天，但清洗、去重、截取有效片段、按光照和场景分类，再加上手工标注难例，前后占了接近一周。AI 能写自动标注脚本、切图工具、质量统计报表，但它不能代替人去判断"这个被遮挡的行人到底要不要标成难例""这个反光区域算不算车道线干扰"。结论是：AI Coding 把代码时间压下去了，但数据准备和标注仍然吃掉了原型周期的三分之一。

4. 工程边界之二：AI 不知道你的硬件、SDK 和交付标准

4.1 域控平台：x86 上跑得顺畅，板子上直接崩溃

L2 原型最终要跑在特定域控或工控机上，NVIDIA Orin、地平线征程、黑芝麻、TI TDA4 这些平台的差异，AI Coding 的通用代码生成很难覆盖。AI 生成的 CMake 工程在 Ubuntu x86 上没问题，切到目标平台的交叉编译链后，sysroot 路径、依赖库版本、链接顺序都会成为问题。我在板子上排查过几次符号找不到的链接错误，AI 提供了各种猜测，但最后还是靠比对 SDK 自带的示例工程才定位到问题。

另一个硬边界是算子支持。x86 上能跑的 ONNX 模型，量化到板端 int8 时，部分算子的精度会掉得很厉害，甚至直接不被支持。AI 帮你生成 TensorRT 封装的代码很容易，但针对某个特定模型做层级对齐、选对精度策略，只能靠人工对照 profiling 工具的输出反复试。

4.2 实时性预算：能跑起来，不代表跑得进预算

"代码能跑"和"代码在预算内跑完"是两回事。L2 前视感知通常要求端到端 50ms 以内的帧预算，这还不算后处理里的追踪和逻辑判定。AI 生成推理代码时不会主动帮你做图像 resize 的 SIMD 优化、CPU-GPU 拷贝的通信优化、多路 stream 并发，这些靠人工 profiling 定位热点后逐个优化。

我实测过在 Orin 上以 fp16 跑 YOLOv8s，单帧推理大约 18ms，加上前处理、后处理、追踪、绘制，整链超了 40ms，凑合可以跑；换成 int8 后推理到 10ms 以下，但检测小目标掉点明显。这种"精度换速度"的权衡，AI 无法替你做决定，因为它不知道你的功能安全需求和目标检出距离要求。

4.3 原型和量产之间的沟壑：代码量只是其中一环

为什么我强调"三周原型"不等于"三周量产"？因为原型的软指标和量产完全不是一套。原型可以没有诊断链路、不做降级策略、不管生命周期管理和信息安全，还可以容忍偶发帧率抖动。量产要接故障管理、目标级联失效保护、标定参数在线监控、实车法规场景验证，这些工作里代码只是一小部分，大量时间在验证、评审、证据链和跨团队对齐上。

AI Coding 把"写代码"这个环节压缩以后，项目周期的瓶颈从"代码编写"转移到了"验证和数据"。这意味着，如果你只盯着代码，用量产项目的代码工时去评估 AI Coding 的价值，会严重低估它；但如果你因为 AI 写代码快了，就承诺更激进的质量目标，也会被验证环节狠狠教训。

5. 一份可以复用的三到四周排期表

5.1 第 1 周：环境、采集、标定和基线模型

前半周搭环境：ROS2 工作空间、相机驱动取流、Python/C++ 混合工程，这些用 AI Coding 两三天内完成。后半周做两件不能省的事：采集数据和相机标定。至少采够白天、黄昏、地下车库三种光照条件的数据，标定板多次拍，跑完内参外参后必须做测距验证——找几个真实目标量一下距离。最后选一个基线检测模型和车道线模型，在自采数据上先离线跑一遍确认基本效果。

这里有个容易被 AI 带偏的地方：不要让它"端到端"给你生成一个集成大项目，分模块生成反而好控制。环境这块 AI 生成的依赖安装脚本，建议先逐条过一遍再执行，至少我遇到过一次 AI 生成的安装脚本把系统 OpenCV 给升级了，导致旧代码编译失败。

5.2 第 2 周：感知 pipeline 与后端封装

这一周把检测、车道线、分割串成统一的感知输出结构。先说清接口，再让 AI 按接口写模块。比如检测输出结构体必须包含类别、置信度、带畸变校正的像素框、底盘坐标系下的 x/y 距离，车道线输出必须包含左右线多项式系数、有效标志、曲率和横向偏移。

前后端之间的数据结构统一太重要了。我三周里至少有两次因为数据定义不一致，AI 生成的追踪模块和可视化模块互相不理解对方的结构，最后人工对齐浪费了整整一天。

周末前做一次离线评估：用录好的数据回放，检查 mAP、车道线准确率、单帧耗时的基线值。被抖动的目标框和跳变的 ID 放到下周再说，但如果离线精度就不过关，后面的逻辑闭环没有做的意义。

5.3 第 3 周：测距、追踪与 ACC/LKA 逻辑

这一周是传统方案里最容易被低估的环节。先做单目测距的修正和验证：选几段直道，把检测框底边、地面假设、外参三者组合出的距离和实际对比，写个自动统计脚本输出误差分布。然后做追踪和平滑，核心目标是降低 ID 切换率、压制框抖动。

再往后是 ACC/LKA 的简化决策逻辑，我用一个状态机实现：目标选择（本车道最近前车）、期望距离策略、横向偏离修正量。这些逻辑 AI 可以生成框架，但参数一定要人工设定，不建议直接采纳 AI 的初始值。例如目标选择的无效目标过滤阈值、前车切入切出的平滑过渡时间，这些拍脑袋给参数据实车测试一定会露馅。

5.4 第 4 周：真车路测、问题清单与缓冲时间

最后一周至少安排两轮实车路测。第一轮白天城区环线，重点看 AEB 误报率、车道线丢失率、目标 ID 是否稳定；第二轮专门挑黄昏和隧道口，看逆光和大光比条件下漏检情况。每轮路测后把问题按严重程度列成清单，影响安全的下车修，影响体验的排期修，不影响功能的先记录。

强烈建议在排期里至少留出两到三天的缓冲。AI Coding 能压缩代码时间，但路测和回归验证的时间没法压缩。我三周里最像"天塌了"的一次，是路测时发现 AEB 功能在某个特定逆光角度下持续漏检，最后定位到是预览相机自动曝光参数导致的高光区域检测退化。这种问题只有真车能暴露出来，AI 生成多少代码都替代不了。

6. 给同行和管理者的几点实际建议

6.1 AI Coding 工程师的核心竞争力不再是写代码，而是定义问题

我越来越认同一个说法：AI Coding 不会让好的工程师失业，但会让"只会照抄代码"的工程师更尴尬。这轮原型项目里，AI Coding 承担了将近七成的代码产出，但项目最后能按期做完，靠的是我每两小时做一次"它在干什么、它是否有意误解"的审查。

给 AI 提需求是一门手艺。不要直接说"帮我写一个目标检测"，而是给它完整上下文：输入图像是 1920x1080 BGR 的 cv::Mat，输出结构体包含类别、像素坐标框、归一化置信度、底盘坐标系下的距离，坐标系原点在后轴中心，单位为米，检测结果需要经过畸变校正和地面平面投影。上下文越精确，AI 生成结果的可用性越高。反过来，模糊的需求只会换来大量需要返工的漂亮代码。

6.2 代码合并前必须做三查：数值单位、坐标系、时间戳

这是我这次实操后总结的最重要经验。AI 生成代码在感知项目里最容易翻车的三个地方，第一是单位，模型输出可能是像素、可能是归一化、可能是米，混用后测距直接乱套；第二是坐标系，相机坐标系、车身坐标系、图像坐标系差一个旋转，整个 BEV 显示都会错位；第三是时间戳，数据回放和真机联调的时间戳对齐问题会让人怀疑人生。

每次让 AI 生成感知相关代码，合并之前我只干三件事：查常量定义有没有魔法数字、查坐标变换有没有写注释和单位、查时间戳字段是否统一到同一时基。三查之后再跑最小用例，而不是直接拿整段代码上真机测试。这样做之后，AI 生成的代码返工率显著下降。

6.3 关于"AI Coding 会不会让代码质量下降"的回应

最近聊"AI Coding 到来会不会让代码质量下降"的人很多。我的观察是：AI Coding 对于有明确工程判断力的人，是质量的放大镜——同样的代码审查标准，AI 产出可以更快、更规范；对于判断力还在建立中的人，敏感不当的话，AI 会批量产出"看起来对、跑起来坏"的代码，质量反而肉眼可见地变差。所以问题不在工具，在于你有没有一套验证它产出质量的流程。

如果你也在做类似的前视感知原型项目，我最后的建议是：大胆用 AI Coding 处理脚手架、工具链、可视化这些体力活，但对标定、测距、追踪逻辑、数据闭环和真机验证这些环节，该花的时间一分都不要省。原型周期的数字可以是三周，但三周的前提是工程师的工程判断力始终在线。