更佳阅读效果，请移步关注我的公众号
业务需求是近实时了解新能源车在不同城市和区县的市场变化。但现有历史数据虽然粒度较细，更新周期却较长；公开互联网数据更新更快，却大多只有全国或部分城市维度，无法直接满足需求。
本次实践使用 WorkBuddy v5.2.3 + DeepSeek-V4-Pro。我向 WorkBuddy 提供了业务目标、数据现状和结果要求。它在调研公开数据源后判断，单靠网页采集无法直接获得全国区县级高频数据，因此提出将公开高频数据与历史区域数据结合，基于历史区域权重进行推算的方案。
经过多轮校验与交互修订，最终完成了数据采集、处理、校验和入库，并将整套流程封装为可复用的 Skill。
一、理解需求，识别关键风险
我没有让 WorkBuddy 直接开始执行，而是先要求它复述需求并说明思考过程。
页面较长仅截取了需求理解部分
从结果看，WorkBuddy 不仅明确了数据粒度、更新频率、输出形式和入库要求，还识别出一个关键风险：互联网公开数据几乎不存在覆盖全国区县级的周度新能源车销量数据。
基于这一判断，它给出了两种方案：一是将公开高频数据与已有历史区域数据结合，通过权重推算补齐区县粒度；二是继续尝试直接采集，若无法获得目标数据，再输出数据缺口和替代方案。最后由我在交互中选择是否按推荐方案推进。
这一步的价值，不只是完成需求确认，更在于 WorkBuddy 主动识别了关键问题，给出可选方案，并把最终路径交由人来确认。
二、先验证数据源，再确定技术路线
在我选择推荐方案 A 后，WorkBuddy 没有立即进入脚本开发，而是先对多个公开数据源进行搜索、访问和可用性验证。
公开数据源调研与验证结果
数据源调研结果表明，多数候选站点存在需要登录、数据收费、缺少城市维度或无法稳定提取等问题。本轮调研最终筛选出一个当前可稳定访问、具备持续采集条件的高频数据源，并据此确定后续路线：以公开高频数据作为总量基准，再结合历史区域分布推算到城市和区县层级。
这一轮先验证了数据源是否真实可用，也避免后续方案建立在“看起来有数据、实际无法采集”的假设上。
三、把技术路线拆成可执行任务链
数据源和推算思路确认后，WorkBuddy 进一步将方案拆解为一条完整的数据处理链路，覆盖数据采集、历史数据清洗、区域权重计算、销量推算、结果校验、测试入库和 Skill 封装。
流程设计落地步骤
这次拆解并不是简单罗列步骤，而是进一步明确了每个环节的处理方式和预期产出：数据从哪里获取、历史数据如何清洗、区域权重如何生成、推算结果如何校验，以及最终如何写入测试库并沉淀为可复用流程。
这一步把前面的技术判断转化为可以逐步执行、逐步验收的任务链。后续无论是数据源异常、清洗规则偏差，还是入库失败，都可以快速定位到具体环节，并通过多轮交互继续修正。
四、清洗历史数据，形成区域计算基础
公开数据解决了“全国周总量是多少”，接下来还需要借助已有历史数据，判断这些销量应如何分布到城市和区县。
WorkBuddy 使用 Python 和 openpyxl 对历史数据进行清洗与权重计算。过程中先后发现了校验条件过严、原始数据被误覆盖、规则边界不合理，以及临时结果与权重文件混放等问题，并通过多轮交互逐项修正。
历史数据清洗
最终，清洗规则、区域映射和有效历史数据集被分别固化，并保留中间结果用于复核，为下一步权重模型设计提供可靠输入。
这一轮也说明，真实的数据任务不能只看最终结果。规则是否合理、异常是否被误判、中间文件是否可追溯，都会直接影响后续推算的可信度。
五、修正权重模型，完成城市与区县推算
历史数据清洗完成后，WorkBuddy 开始设计区域权重模型。真正需要解决的，不是简单地用总量乘以权重，而是权重基于什么数据、采用哪个时间口径，以及不同维度如何独立归一化。
经过多轮交互修订，WorkBuddy 最终确定以有效历史保有量作为区域分布依据，并分别计算城市和区县权重，形成“全国到城市、城市到区县”的两阶段推算逻辑。
权重计算模型设计与校验
模型确定后，公开高频总量被逐层分摊到城市和区县，并通过汇总回归验证推算结果是否能够回到原始总量。
需要说明的是，这些结果属于基于公开总量和历史空间分布形成的估算数据，适合用于趋势分析和内部判断，不等同于真实上牌或成交统计。
六、完成测试入库，验证整条链路
推算结果通过校验后，WorkBuddy 将城市和区县结果写入 SQL Server 本地测试库，并通过查询结果复核记录数量、区域覆盖和汇总数据是否一致。
SQL Server 测试入库与结果核验
这一环节不仅验证了字段映射和批量写入，也通过查询复核确认数据库记录与前一步输出一致。至此，数据采集、清洗、推算、校验和测试入库形成了完整闭环。
环境说明： 文中 SQL Server 仅用于本地测试库或沙箱环境验证。正式接入生产环境时，应做好权限控制与数据隔离。
七、把一次性流程封装为可复用 Skill
测试入库完成后，整条流程虽然已经跑通，但还没有真正沉淀为可复用能力。若下次仍需重新说明数据源、清洗规则、权重逻辑和入库步骤，这套流程就仍然依赖人工重复交代。
因此，WorkBuddy 将本次任务中的配置、脚本、校验规则和数据源说明进一步整理，并封装为可复用的 Skill。
自动化流程封装为 Skill
从目录结构可以看出，这个 Skill 不只是保存一段提示词，而是将数据连接配置、运行参数、清洗逻辑、权重计算、周度推算、校验规则和数据源说明分别组织到不同文件中。
这一步让任务从“一次性跑通”，转变为后续可以按统一规则重复执行、检查和维护的流程。真正被沉淀下来的，不只是代码，还有数据口径、校验方法和执行边界。
八、真正决定结果的，是校验与边界
回看整个过程，方案并不是一次成型。数据源、清洗规则、权重模型和推算结果，都在多轮校验与交互修订中逐步收敛。
其中有三点最值得复盘。
第一，数据源判断比写代码更重要。 如果一开始默认公开渠道存在全国区县级周度销量，后续开发很可能建立在错误前提上。
第二，自动化必须有明确的验收标准。 采集是否成功，不能只看页面能否打开；推算是否正确，也不能只看是否生成结果，还要检查来源、口径、汇总偏差和异常记录。
第三，Agent 可以主动推进，但关键判断仍需由人确认。 WorkBuddy 能够调研数据源、提出方案并执行任务，但数据口径、推算逻辑和结果用途，仍应由人最终负责。
这次实践真正体现的，不是 AI Agent 替代了多少人工操作，而是它能否在清晰目标、规则边界和验收标准下，把模糊需求推进为可执行、可验证、可复用的流程。
任务做完只是结果，经过校验的方法能够持续复用，才是 Agent 工程化更有价值的地方。
浙公网安备 33010602011771号