用 WorkBuddy 从零构建交通专业工具 ——《车道宽度规范速查与计算工具》v1.0 → v5.0 全过程复盘与方法指引

用 WorkBuddy 从零构建交通专业工具

——《车道宽度规范速查与计算工具》v1.0 → v5.0 全过程复盘与方法指引

摘要 本文复盘一个真实案例：一位交通管理领域的产品经理，如何用 AI 助手 WorkBuddy，在约 80 分钟内、经过 5 个版本迭代，把分散在 9 本规范中的车道宽度条文，变成一个 54.8 KB 的单文件 HTML 工具。 文章的重点不是这个工具本身，而是一套可复用的方法：如何提需求、如何投喂专业素材、如何增量迭代、如何要求 AI 自检、以及如何做领域把关。 读者看完应当能够照着做出自己的专业小工具。

0. 一句话结论

你提供领域知识，AI 提供工程实现。 整个过程中，人负责的是「规范条文、数据归属、逻辑纠错」，AI 负责的是「结构化、写代码、做校验」。这个分工跑通了，一个专业工具的产出成本可以从"几天"压到"一小时"。

1. 需求起点：一个真实的工程痛点

1.1 痛点是什么

交通工程师在做道路与交叉口设计、方案审查时，需要频繁查阅车道宽度要求。这些要求散落在多本规范里：

而且这些规定不是平面的一张表，而是多维交叉的：

• 城市道路 vs 公路 → 两套数值体系
• 路段 vs 交叉口 vs 弯道 → 三种场景
• 进口道 vs 出口道 → 两种部位
• 新建 vs 改建 → 两套松紧尺度
• 机动车道 vs 非机动车道 → 两种车道类别
• 部分场景还要计算（转弯车道、曲线加宽）

靠人脑记忆 + 翻规范，效率低且易出错。

1.2 需求的原始表达

需求方（本文作者）的第一句话是这样的：

"我想做一个小工具，独立静态网页方式使用。用途是给交通工程师使用，用于道路车道宽度的标准规范要求查询或者计算……还有一些更复杂的情况，是需要进行计算的。"

这句话里包含了三个关键信息，后面被证明都至关重要：

1. "独立静态网页" —— 技术形态约束（决定了零依赖、单文件）
2. "查询或者计算" —— 功能分类（后面演化为"速查 Tab"与"计算器 Tab"）
3. "更复杂的情况需要计算" —— 预留了扩展空间（后来催生了弯道加宽计算器）

1.3 为什么"独立静态网页"这个约束很重要

这个约束直接决定了技术选型。对比几种方案：

对于"给同事用的专业小工具"，单文件 HTML 是最优解。这也让 AI 可以一次性生成完整产物，无需多文件工程。

2. 全过程复盘：五个版本的演进

2.0 总览

总计约 80 分钟。 其中 AI 的实际工作量（写作 + 校验）远大于此，但对使用者而言，等待与沟通成本就是这 80 分钟。

2.1 v1.0：从一张截图起步

输入：一张规范摘录的截图（含路段车道宽度表、交叉口车道宽度表、转弯专用车道表），配一句需求描述。

第1次提问时附带的截图

第1次提问的需求表述

AI 做了什么：

1. 读取截图，识别并结构化其中的表格数据
2. 判断功能应拆为"查询类"与"计算类"
3. 生成单文件 HTML

产出：4 个 Tab

值得注意的设计决策：AI 在处理"转弯专用车道"时，发现规范表格只覆盖了 R≥25m 的情形，于是主动补了一个 R<25m 的几何验算模式（宽度 = 车宽 + 内侧偏移 + 外侧富余），并标注需结合仿真复核。

这是 AI 的加分项：它不只是机械地搬表格，而是发现了规范的覆盖缺口并给出兜底方案。当然，这个兜底方案是否合规，仍需要领域专家判断。

2.2 v2.0：公路体系并入

输入：一段较长的文字资料，说明公路与城市道路的差异：

"关于公路交叉口上车道宽度的要求……现行标准规范中公路与城市道路的规定有所不同，且进口道（车辆驶入）与出口道（车辆驶出）的要求也存在差异。"

资料中明确了公路侧的规则，包括一条此前未覆盖的：

"当设计速度大于或等于 40km/h 时，展宽渠化的转弯车道宽度宜采用 3.5 米，同样不宜小于 3.25 米，且不应小于 3 米。"

以及一条重要信息：

"交通运输部已发布新的《公路平面交叉设计规范》(JTG/T 3322—2026)，将于 2026 年 10 月 1 日起施行。"

第2次需求的表述--要求增加公路交叉口的车道宽度要求规范

AI 做了什么：

1. 在顶部与速查表中补充 JTG B01 / JTG D20 / JTG/T 3322—2026 引用
2. 交叉口模块重构为多维组合：道路类型 → 部位 → 建设条件 → 设计速度 → 是否通行公交及大型车
3. 把公路特有的"展宽渠化转弯车道"做成独立分支

经验：这一轮的关键在于，用户提供的资料自带了维度信息（公路/城市道路、进口/出口、新建/改建），AI 得以直接把它映射为界面上的选项组。资料的结构化程度，直接决定了产出的结构化程度。

2.3 v3.0：非机动车道（一次"翻车"）

输入：非机动车道的详细条文，明确区分城市道路与公路两套体系：

城市道路（CJJ 37）：单条基本宽、合并设置 ≥2.5m、专用道单向 3.5/双向 4.5m、有效通行单向 1.5/双向 3.0m、交叉口进口道 2.5m 与内部通行空间 3.0m。

公路（JTG B01 / JTG 2112）：单条自行车 1.0m、三轮 2.0m、四级公路混行 4.0/5.0m、城镇化合并 2.0/3.0m。

第3次需求的表述--要求增加非机动车道宽度的要求

AI 做了什么：新增非机动车道模块，支持道路类型切换 + 场景切换。

出问题的地方：AI 把这个模块整体塞进了 ② 交叉口车道综合查询 这个 Tab 里。

这是一个典型的"就近归类"错误：因为当时正在改交叉口模块，AI 就把新数据挂到了最近的那个模块上，而没有判断数据本身的适用场景。

过程中还发生了两个技术小事故（AI 自行发现并修复）：

1. 写文件时漏掉了 .html 后缀 → 重命名修正
2. JS 对象字面量中把 alert:'...' 误写成 alert='...'（赋值语句）→ 语法错误，修正后通过校验

2.4 v4.0：一次关键的逻辑纠错

用户输入（原文）：

"非机动车道的宽度，你全放在了【交叉口车道综合查询】这个tab里，这是存在逻辑错误的。路段上也会有非机动���道的，这部分你没考虑"

第4次需求的表述--指出当前设计中没有将路段上的非机动车的场景考虑进去，要求修改

这是一次高质量的领域纠错。 用户没有说"改一下位置"这种模糊指令，而是直接指出错误本质：非机动车道不止存在于交叉口，路段上同样有。

AI 的修正：把非机动车道按部位拆分——

同时做了视觉区分：Tab1 切到非机动车道时，结果卡片整体转为粉色主题，避免与机动车道结果混淆。

数据结构也相应改为二维组织：

这一轮的教训最重要，见第 4.5 节。

2.5 v5.0：弯道加宽计算器 + 交互顺序优化

输入：曲线加宽的完整规则，包括两条公式和两张查表：

以及加宽缓和段的要求：

"如果道路本身设有缓和曲线或超高缓和段，加宽缓和段长度通常与之相同。如果都没有，加宽缓和段长度需按渐变率（如 1:15）计算，且不得小于 10 米。"

第5次需求的表述--要求增加存在弯度的车道宽度的计算器功能

AI 的判断：这是"曲线加宽"，与直线车道宽度是两套逻辑，必须独立成 Tab，不能并入任何既有模块。（吸取了 v4.0 的教训）

产出的 Tab ⑤ 弯道加宽计算器：

• 输入：道路类型、圆曲线半径 R、设计速度 V、计算方式（查表法 / 公式法）、设计车型、a_gc、基础车道宽、车道数、缓和段设置
• 输出：单车道加宽值、总加宽值、加宽后车道宽、加宽缓和段长度、逐步展开的计算过程、自动高亮的加宽值表

几个关键处理：

• R > 250m → 提示无需加宽
• 公式法同时显示规范表典型值，供互为校核
• 公路表中"该车型无对应加宽值"的档位（如第 3 类铰接列车在 R≤50m）→ 明确警示"该设计车辆不宜采用如此小的半径"，而非静默返回空值
• 缓和段长度强制 ≥ 10m

接着是一轮交互反馈：

"它熟悉'计算器'，它的tab的顺序应该放在第4位，你现在是放在最后，这个不太顺畅，请修改。"

顺序调整为：① 路段查询 ② 交叉口查询 ③ 转弯车道计算器 ④ 弯道加宽计算器 ⑤ 完整规范速查表。两个计算器相邻，速查表收尾。

第6次需求表述--弯道加宽计算器在界面的TAB位置不对，需要修改

3. 最终成果

4. 方法指引：如何用 WorkBuddy 高效生成专业工具

这一节是本文的核心。以下五条方法，全部来自本次实战，可直接复用。

4.1 提需求：描述"业务结果"，而非"技术方案"

不要这样写：

"帮我用 Vue + Tailwind 写一个响应式页面，用 flex 布局，数据用 JSON 组织……"

应该这样写：

"我想做一个小工具，独立静态网页方式使用。用途是给交通工程师使用，用于道路车道宽度的标准规范要求查询或者计算。"

原因：你可能并不清楚该用什么技术栈，而 AI 清楚。约束你真正关心的东西（运行方式、使用者、用途），把技术决策交给 AI。

如果需要特定技术约束，单独点明即可，例如：

• "独立静态网页" → 决定了单文件、零依赖
• "要能在内网发给同事" → 排除了需要 CDN 的方案
• "要能打印" → 影响排版设计

4.2 投喂素材：截图 + 条文 + 规范编号，三位一体

本案例中，素材经历了三种形式，效果都很好：

强烈建议带上规范编号（如 CJJ 37、JTG D20）。好处：

1. AI 能据此判断数据的适用范围
2. 工具中可以直接标注引用来源，方便使用者溯源
3. 便于后续按规范更新

一个实用技巧：如果资料很长，可以在开头加一句定位，例如：

"以下是我查到的关于非机动车道宽度的要求，也请你补充到这个工具里面"

这句"定位语"能让 AI 立刻把新素材与既有结构对齐。

4.3 增量迭代：用"补充这个"代替"重做一个"

本案例 5 个版本，没有一次是"推倒重来"。每轮用户的表述都是增量的：

• v2.0："关于公路交叉口上车道宽度的要求，我补充这个……"
• v3.0："以下是我查到的关于非机动车道宽度的要求，也请你补充到这个工具里面"
• v5.0："对于存在弯度的车道……可以单独设置一个tab给它"

为什么增量迭代更有效：

1. 保留已验证的部分，降低出错概率
2. AI 能理解上下文，知道往哪里加
3. 每轮产出都能立刻验证

但要注意：增量迭代的前提是上一轮的结构是对的。如果发现结构性问题（如 v4.0 的场景），就要果断要求重构，而不是继续往上加。

4.4 主动要求自检：让 AI 校验数据与代码

这是本案例中最容易被忽视、但价值极高的一环。

AI 在本次开发中自发做了三轮校验：

① JS 语法校验（每次改完都做）

→ 捕获了 alert= 笔误这类会导致整个脚本失效的错误。

② 数据录入校验（v5.0） 把 HTML 中的加宽表格数据提取出来，用 45 条断言逐格比对：

→ 确保手写表格时没有输错数字、区间判定（左开右闭）正确。

③ Tab 映射校验（调序后）

你可以直接要求 AI 做这些校验，见第 5 节的模板。

4.5 领域把关：你是终审，AI 是初稿

v4.0 暴露的问题值得单独讨论。

AI 为什么会犯错？ 因为它在处理"非机动车道"这批新数据时，把它挂到了当时正在编辑的模块（交叉口）上。这是"就近归类"的惯性，而非对业务的理解。

这类错误的特征：功能能跑、数据没错、但归类错了。代码层面完全看不出问题，只有领域专家能发现。

如何防范？ 在补充数据时，主动说明适用范围。对比一下：

结论：AI 生成的是高质量初稿，但结构性的判断必须由你来把关。当 AI 新增了一个模块时，花 30 秒问自己一句："这个东西只存在于这个场景吗？"

5. 可复用的 Prompt 模板库

以下模板均来自本实战，可直接复制改编。

模板 1：首次提需求

模板 2：增量补充数据

模板 3：要求新增独立模块

模板 4：要求做数据与代码校验

模板 5：指出逻辑错误（要求重构而非打补丁）

模板 6：交互顺序调整

6. 工具的技术实现要点

给想自己维护或二次开发的人。

6.1 文件结构

单个 HTML 文件，三段式：

无外部依赖，无 CDN 引用，离线可用。

6.2 数据驱动设计

所有规范数值都抽成数据对象，与渲染逻辑分离：

好处：修改规范数值不需要碰任何渲染代码。新规施行时，只改数据即可。

6.3 条件显示模式

每个复杂模块配一个 sync 函数，控制哪些输入项可见：

好处：界面随选择动态精简，工程师不会被无关选项干扰。

6.4 缺失值的显式处理

规范表格中的"—"（不适用）不能简单存 0 或空：

三种"非正常"状态在界面上给出不同的警示文案，而不是静默返回空值。这是专业工具与玩具的区别。

7. 踩过的坑与避坑清单

8. 后续可扩展方向

本工具目前的边界与扩展可能：

待确认的数据（已在工具中标注为参考值）：

1. CJJ 37 中"单条自行车道基本宽度"的精确值（当前按 1.5m 参考值处理）
2. 公路交叉口的非机动车道数值（当前沿用城市道路值，标注需以 JTG/T 3322—2026 复核）

9. 结语

回顾这 80 分钟，真正耗费人的不是"写代码"，而是三件事：

1. 把规范条文整理清楚 —— 这只有领域专家能做
2. 判断数据该归到哪里 —— 这需要业务理解
3. 在 AI 犯错时指出错在哪里 —— 这需要专业判断

而那些真正耗时的苦活——结构化、写交互、调样式、做校验、反复修改——全部交给了 AI。

这就是这类协作的价值所在：它不替代你的专业知识，而是把你的专业知识放大成可交付的产品。

如果你手头也有一堆"散落在规范里、每次都要翻"的知识，不妨试试用同样的方法，把它变成一个工具。