用 AI 协作做交通信号时段划分：从 DeepSeek 雏形到 WorkBuddy 落地

本文是一份内部操作指引性质的复盘，不是算法论文。它以"路口多时段识别划分算法"这个真实需求为例，完整记录我们如何跨模型协作把它做出来：算法雏形在 DeepSeek（DS）中与 DS 讨论得到，再把核心 Python 文件带到 WorkBuddy 做算法调优与应用侧落地（前端、分享、调试）。希望给同样想用 AI 提效、但不知道"怎么把活真的干完"的同事一个可参照的范本。

零、先说结论：AI 不是给思路，是陪你把活干完

很多同事对"用 AI 写代码"的印象还停留在"它给段伪代码、我自己接着调"。但这次实践体验完全不同：算法雏形、调优、前端、调试、交付，分别由不同模型在不同阶段接力完成，每一棒都产出了可运行的东西，我几乎没有离开对话框手写核心代码。

整个项目（一个交通信号控制时段划分应用）从雏形到最终可分享的网页，全部产出来自连续对话，过程中我只在发现怪结果时截图反馈、让 AI 就地修复。本文把这条"雏形 → 调优 → 前端 → 调试 → 交付"的链路拆开讲，方便你照着抄作业。

一、协作链路全景：DS 出雏形，WorkBuddy 做调优与落地

这次最值得先讲清的，是多模型接力的真实路径，而非"某个模型包办一切"：

1. DeepSeek（DS）——算法雏形阶段：最开始的核心时段划分算法 Python 文件，是我在 DeepSeek 中与 DS 讨论、由 DS 输出得到的（初版是 K-means 思路，文件名 analyzer_v2.py）。
2. WorkBuddy——调优与应用侧阶段：我把 DS 输出的核心 Python 文件带进来，主要让 WorkBuddy 做两件事：
   • 算法调优：把不稳定的 K-means 改成"递归有序聚类"，并叠加交通业务约束（高峰优先锁定、最小段长、同型合并）；
   • 应用侧落地：把算法移植成浏览器端 JS、生成可交互前端页面、做单文件分享版、修复真实数据上暴露的各类 BUG。

这种"DS 负责想法孵化、WorkBuddy 负责工程化与迭代提速"的分工，比单一模型死磕某一环更高效。后面每个阶段都对应这条链路。

经验提示 1：别迷信"一个模型干到底"。让擅长推理/讨论的模型出雏形，让擅长工程落地与多轮调试的模型做实现，往往比强求一个模型同时擅长两者更快。

二、我们要解决什么业务问题

城市路口信号控制需要根据全天流量把 24 小时切成若干个"时段"，每个时段套一套固定配时方案。传统做法靠工程师凭经验划，三个痛点：

1. 不连续、不可复现：不同人、不同天划出来的段不一样，方案难沉淀。
2. K-means 直接聚类会"碎"：最早用 K-means 对流量序列聚类，结果不保证时间顺序连续，且一份数据被切成 17 个碎片时段，完全不可用。
3. 业务约束难表达：高峰时段业务上通常约 2 小时、时段不能太短（默认 ≥60 分钟）、相邻时段类型不能乱标（不能出现连续两个"高峰"）。这些是领域规则，通用聚类满足不了。

目标：做一个本地可用的小工具，导入路口流量 CSV，自动输出"连续、段数合理、带高峰/次高峰/平峰/低峰类型标签"的时段划分，最好能可视化、能直接发给同事用。

三、整体协作模式：把强关联工作放在一个对话里

和 WorkBuddy 先定下的工作方式：

• 算法、前端、调试强关联，必须放在同一对话保持全局上下文，不要为"省积分"拆成互不相干的多个对话。拆分只适用于主题已切换、彼此无关的场景。
• 强关联合并做，模块间才能对齐；后续换对话靠"项目资产库"（沉淀的架构/接口/数据字典）复用。

本项目最终落地的文件结构（本地磁盘）：

经验提示 2：一开始就告诉 AI"强关联任务合并在同一对话"，能省掉后期大量"它忘了前面约定"的返工。这是用 AI 做稍复杂项目最值得先定下的规矩。

四、阶段一：算法调优——K-means 到递归有序聚类

起点：DS 给的 analyzer_v2.py 是 K-means 思路，跑真实数据会碎成 17 段且不连续。

我的需求（口语化）：把 K-means 改成"递归有序聚类"，生成新文件。

WorkBuddy 产出 analyzer_v3.py，核心是递归有序聚类（最优分割树 / Fisher 动态规划）：序列本身有序，只把连续区间当候选切分点；用前缀和 O(1) 算区间方差增益，自上而下二分直到增益不足或达到最大段数；保证时间连续、段数可控。关键片段：

与此同时，WorkBuddy 还顺手解释了工程问题：多个 py 文件都含同名 TrafficFlowAnalyzer 类时靠 import 来源路径区分、包 __init__.py 的初始化时机等——后续维护都用得上。

验证：用中山路口真实 CSV 跑通，段数从 17 降到合理范围、时间连续。这一步建立"算法 + 数据"闭环，后面所有调试都基于它。

经验提示 3：别只让 AI "讲算法"，让它直接产出可运行文件并用真实数据验证。第一版就跑通，比反复讨论思路省十倍时间。

五、阶段二：把算法做成"看得见"的前端页面

需求：测试算法不方便，帮我设计前端，本地选 CSV 导入、计算、页面显示。

WorkBuddy 做了两件事：

1. 忠实移植算法到 JS（algorithm.js），挂成 window.SegmentAnalyzer 的 UMD 模块，浏览器直接调用，和 Python 版逻辑一一对应。
2. 生成 segment_analyzer.html：左侧参数面板，中间 CSV 拖拽/选择导入，右侧图表按"高峰红 / 次高峰橙 / 平峰绿 / 低峰蓝"着色，下方给出时段摘要表。页面骨架片段：

设计决策：算法内核独立 algorithm.js，页面 <script src> 引用。改算法不用动 UI；但也埋下缓存坑（见第七节）。

经验提示 4：让 AI 把算法和界面分离（内核独立模块 + 页面引用），后续改算法逻辑不用动 UI，维护成本低。

六、阶段三：业务约束的逐轮迭代（核心干货）

最能体现"AI 陪你调试"的阶段。每次拿真实数据跑出怪结果，截图发给 WorkBuddy，它定位根因、改代码、再验证。四个坑按时间顺序记录。

坑 1：K-means 碎成 17 段

• 现象：中山数据被切成 17 个碎片。
• 根因：K-means 无最小段长约束，对噪声极敏感。
• 修复：加"最小时段长度"约束（默认 30→后提到 60 分钟），换算成样本数参与切分预算：最小时段样本数 = max(最小样本, ceil(时长/间隔) + 1)。注意 +1——时长换算成样本数是"间隔数"，真正段长要加一个间隔才够。

坑 2：连续多个"高峰"很怪

• 现象：高流平台被切成好几段，相邻都标"高峰"。
• 根因：纯靠流量阈值分档，长高平台上每段都过线。
• 修复：分类阶段做上下文感知修正——仅极值段标"高峰"，其余降级"次高峰"；对"低峰"同理。分类不只看本段均值，还看相邻段关系。

坑 3：11:30 处无意义割裂

• 现象：10:30–14:10 高流平台内部在 11:30 被切一刀，切开两段均值都落"次高峰"。
• 根因：peak-first 把非高峰块交递归有序聚类后，平台内小幅下跌被当有效切分点。
• 修复：后处理合并相邻同型非高峰段；锁定高峰段不参与合并。最终 10:30–14:10 合并为一段次高峰。

坑 4：09:15 / 21:45 不合理切割（最隐蔽）

• 现象：路口 09:15 出现"高峰→次高峰"边界、21:45 把次高峰切断。
• 根因：peak-first 锁定早高峰 07:15–09:15，但递归细分其余区间又把 09:20–11:20 高均值子段判成"高峰"；两"高峰"仅隔 5 分钟，后处理却因"其中一段是锁定高峰"跳过合并。21:45 同理。
• 修复：后处理加硬规则——相邻且都标"高峰"的段，无条件合并为一个高峰，保留锁定标志。片段：

关键决策：高峰优先锁定（peak-first）

贯穿修复的核心设计：先锁定全天流量最大的 ≤2h 窗口为高峰，再对其余区间有序细分；细分用"全局段数预算"防过碎。让"高峰约 2 小时"这个业务习惯被直接编码进算法，而非事后凑。片段：

经验提示 5：调试 BUG 时，给 AI 真实数据 + 截图 + 具体时间点，比泛泛说"结果不对"效率高得多。它能在对话里直接跑脚本复现—定位—修复—验证，全程不离开对话框。 经验提示 6：算法类需求，JS 和 Python 双版交叉校验防回归。本次每次改完都让 WorkBuddy 在两份数据上各跑一遍，确保两端一致。

七、阶段四：可分享与易用性

单文件分享版

segment_analyzer.html 依赖外部 algorithm.js，发给同事可能丢文件。WorkBuddy 生成 segment_analyzer_standalone.html——把 algorithm.js 内联进 HTML，一个文件就能跑，双击即用，无需服务器、无需装环境。每次改完算法都重新生成内联版，保证分享出去的永远是最新版。

常驻文件名横幅

导入 CSV 后，页面顶部加醒目横幅：显示当前文件名（路口名+日期都在文件名里）和记录数。文件名通常就是"XX路口YYYYMMDD-已处理"，一眼确认在测哪个路口、哪天数据，避免测试搞混。

一个坑：浏览器缓存

本地打开 segment_analyzer.html 若仍显示旧结果，大概率是浏览器缓存了旧 algorithm.js。解决：Ctrl/Cmd + Shift + R 硬刷新。分享给他人不受影响——他们拿到的是已内联算法的 standalone 单文件。

经验提示 7：前端依赖外部 JS 时，务必提醒"硬刷新清缓存"；或干脆用单文件版分享，从根上规避。

八、数据预处理：从原始 Excel 到标准 CSV（真实指令复盘）

时段划分的输入是一份标准 CSV。这部分最初是另一轮对话里完成的——我给了一份原始 Excel（路口各车道的机动车流量记录），并下达了如下 5 条明确指令，AI 据此产出清洗脚本：

要求 1：转换为两列 [time]、[flow]。time 从 00:05 至 24:00、每 5 分钟一行，全天正常 288 条记录。 要求 2：原始表格时间从 00:03 开始，需全部后移 2 分钟（00:03→00:05，23:58→24:00）。 要求 3：flow 是路口在该 time 时间点前 5 分钟内的总体流量；原始记录是各车道统计流量，需汇总计算。 要求 4：原始时间有缺失，目标表必须补全——输出一定是 288 条；缺失点流量用前后有记录点的插值补全。 要求 5：处理后在原位置输出新 CSV，命名为 【中山较场西路口】路口流量数据20260624-已处理.csv。

关键处理脚本思路（pandas）：

标准 CSV 格式约定（本项目实测可用）：

• 列：time（如 2026-06-17 00:00:00 或 00:05）、flow（数值）。算法主要消费这两列。
• 粒度：5 分钟一个点，全天 288 行，时间升序、不缺段。

经验提示 8：数据预处理别手工做。把原始样本 + "我要的格式"贴给 AI，让它写清洗脚本批量处理——可复现、可重跑。上述 5 条指令就是一份可直接复用的"数据整理需求模板"。

九、协作方法论总结

把实践抽象成可复用方法：

1. 多模型分工：DS 类模型出算法雏形/做推理讨论，WorkBuddy 类智能体做工程化调优、前端落地、多轮调试提速。
2. 先定协作边界：强关联任务合并在同一对话，保持全局上下文；只在主题切换时才开新对话。
3. 要可运行产物，不要思路：每次让它直接产出文件并用真实数据验证闭环。
4. 用真实数据 + 截图驱动调试：发现怪结果，数据文件 + 截图 + 具体时间点一起给，让它在对话里复现—定位—修复—验证一条龙。
5. 算法双端镜像 + 交叉校验：JS（前端）和 Python（分析）逻辑对齐，改动两端同改同测，防回归。
6. 关注交付与易用性：单文件分享版、文件名横幅、缓存提示——"最后一公里"决定同事愿不愿意真的用。
7. 脏活交给 AI：数据清洗、格式转换、批量处理，写脚本比手工可靠。

十、给同行的操作指引 Checklist

想照着做类似的"数据 → 算法 → 网页"小工具，按顺序走：

• 用一句话写清业务目标与约束（连续？最短段长？特殊时段规则？）
• （可选）先在擅长推理的模型里孵化算法雏形，导出核心 Python
• 在同一个对话里，让 WorkBuddy 调优算法（替代不稳定方法）+ 用真实数据验证
• 让 AI 把算法移植成浏览器端 JS 内核（独立模块）
• 生成前端页面：本地选文件 → 计算 → 可视化 + 摘要
• 拿 2–3 份真实数据跑，截图反馈每个怪结果，让 AI 逐个修
• 加"单文件分享版"和"文件名横幅"等易用性
• 提醒缓存坑，或直接发单文件版
• 数据预处理也用 AI 写脚本完成（参考本文第八节 5 条指令模板），沉淀为标准格式

十一、小结与展望

这个交通信号控制时段划分应用，从"K-means 碎成 17 段"到"连续、段数合理、带四类标签、可本地可视化、可单文件分享"，是 DeepSeek 出雏形 + WorkBuddy 调优落地 接力完成的。它证明：对于中小型"数据 + 算法 + 轻量前端"需求，多模型协作已经能从需求一路干到可交付，而不只是给参考。

后续方向：把"≤2h、四类阈值、最小段长"等参数做成按路口类型自适应的配置；把算法内核抽成可独立调用的服务；或接入更多数据源做批量路口划分。