独立全栈交付 · 2026 再次重构验证
产品判断
目标客户——保险、车队监管、政府部门——不缺数据，缺的是把视频变成「可解释评分」的中间层。这个产品的判断不是去判「这个人今天有没有违规」，而是持续观察驾驶习惯，形成长期风险画像。
为什么是「上传视频」这个形态，而不是行车记录仪实时流或 OBD 硬件？因为第一阶段客户的真实工作流是事后审阅——出险了、季度复盘了，才把视频调出来看。实时流要解决设备接入、带宽、隐私合规，那是后面阶段的事；OBD 硬件完全出了软件公司的能力圈。上传式 MVP 是四个月内唯一能跑通、又直接对准客户既有工作流的形态。
产品闭环 · 六步
视频上传
上传一段 MP4，后台以异步任务跑检测，前端每 2 秒轮询一次 status 取进度——上传不阻塞。
视角选择
上传时声明视角（车内 / 前向 / 路边）。这是整个产品的技术枢纽——不同视角能看到的行为完全不同，让用户声明视角，等于让用户帮我做了「路由到哪条检测管线」的决策。
驾驶者筛选
目标客户管的是「一批司机」而不是「一个司机」。数据模型从第一天就是 users→drivers→videos 三层，「按司机出报告」是系统的原生能力，不是事后拼凑。
AI 检测评分
YOLOv8 真跑、导出带检测框视频；规则层判定违规——手机在手、双手离开方向盘、红绿灯 HSV + 光流、跟车 bbox 面积比——落成 100 分制评分。
历史对比
按时间范围（3 个月 / 6 个月 / 1 年）过滤，看某司机的行为频次和评分怎么变——单次检测只是功能，趋势才是洞察。
个性化建议
按每个视角最高扣分项生成针对性改善建议，并给出「避免它大约能提多少分」——建议是前端真算的，不是文案模板。
「一个人 + AI coding，把产品判断一路做成能运行的全栈。」四个月的实现方式
AI coding 工作流
我先把客户动作画成一条最短链路：上传视频、声明视角、绑定司机、等待检测、查看结果、回看趋势。然后把它切成可独立验证的竖切片，每一片先定输入、输出、数据状态和失败路径，再让 AI coding 加速实现。
每轮都必须产出一段能点、能跑、能回归的链路：前端状态要能追到接口响应，接口要能追到数据库记录，检测结果要能回到司机和历史报告。AI 帮我加速写代码，我负责拆问题、定接口、看 Diff、跑通真实路径，再决定下一轮做什么。
AI 负责加速实现，我负责把问题切对、接口定清、结果跑通。
这套节奏最终长成 10 个前端页面、11 个接口和约 580 行检测管线，并把产品、前端、后端、模型与数据层连成同一条可运行路径。
行为能力取舍
行为清单不是越长越好。我用两个问题筛选：这个视角能否稳定观测？结果能否转成司机或车队可以采取的动作？留下的是画面里有足够证据的行为，砍掉的是必须靠猜或依赖额外硬件的行为。
车内视角能同时看到人、手腕、手机和方向盘。用目标检测与关键点距离组合判断，证据直接，结果也能落到明确的驾驶建议。
前向视角用颜色区域与光流判断红灯下车辆是否继续移动；路边视角用车辆框面积变化近似跟车距离。两种能力都围绕镜头真正看得到的信号设计。
安全带容易和衣服纹理、阴影、斜挎包混淆；真实车速又缺少 GPS、IMU 或车速接口。一个证据不稳定，一个物理信息缺失，所以没有硬塞进第一期。
2026 重构
第一次交付时，演示数据库和建表代码发生了结构漂移：旧数据还在时一切正常，一旦换到新机器从空库启动，分析结果就无处可写。
2026 年重构时，我合并三份历史副本、修正 schema 与启动逻辑、更新依赖，并把空库启动 → 上传视频 → 完成检测 → 写入结果 → 页面读取作为完整回归路径重新跑通。
最终交付
四个月里，我独立完成产品设计、前端、后端、AI 检测、数据层、端到端集成、打包与演示交付；2026 年又完成工程去重、结构修复和全链路复测。
这段经历最有价值的不是掌握某个框架，而是形成了一套稳定的 AI coding 节奏：先把问题切成可验证的链路，再让 AI 加速实现；每一轮都回到真实输入、真实状态和真实结果。