Vibe-coding工具栈的别样用途

给部门同事做了一次内部分享，讲了两个我在日常办公中高频使用 AI 的场景。两个场景：一是用 AI 管理工作任务，二是用 AI 分析数据模型。都是真实工作场景。

场景一：培养一个越来越熟悉你工作的助手

不只是记待办

一开始我只用它记录待办事项，后来发现它的作用远不止于此——它逐渐变成了一个熟悉我工作的助手。

怎么做到的？不是靠"训练"，是靠积累。我的工作任务目录里逐步沉淀了几十个任务文件夹，每个里面都有 AI 协助整理的 README，记录了任务背景、执行思路和产出物的位置。当接到临时取数需求时，它知道参考历史口径。当上级布置多项并行工作时，它能协助理清各条线的推进重点。

它不需要反复解释业务术语和项目背景——因为此前的任务记录中都有上下文。每次新任务启动，它会先在存档中检索相关材料，提示"这个和之前的某次任务有关联，可以借鉴当时的处理方式"。

换句话说，它不是每次从零开始。它是带着你的工作积累在辅助你。

具体操作方法

第一步：建立目录结构。 规则很简单，每个任务一个文件夹，命名格式为 日期@任务主题：

Todo/
├── @持续关注/                 ← 持续跟进的事项，不归档
├── 20260616@某业务创新方案/     ← 每个任务独立文件夹
├── 20260616@某系统升级改造/
└── 20260617@某数据治理专项/

为什么要这样做？几个好处：

• 状态一目了然：看目录名就知道有哪些活跃任务，不需要打开任何文件
• 上下文自包含：每个任务的所有内容（需求背景、沟通记录、产出文档）都在同一个文件夹里，不会散落在微信、邮件、本地文件各处
• 历史可追溯：三个月前处理过的任务，文件夹还在，README 还在，随时可以回顾当时的思路

第二步：将新任务交给它。 拿到一个新任务时，不需要自己先想一遍再告诉它。直接交给它即可。例如——

“年底前请协助排查全年重点工作，逐项对照当前进展，梳理出存在延误风险的事项”

它会自动完成以下步骤：

1. 定位信息源：先找到重点工作清单（可能是快捷方式指向的 Excel 表格，也可能在某个 Project 目录下）
2. 逐项比对：读取清单中的每个事项，再逐一检查各任务文件夹中的 README 状态和已有产出物
3. 输出风险清单：自动生成一份延误风险报告，按优先级列出——哪些尚未启动、哪些推进受阻、哪些已完成但缺少收尾文档

整个过程只需要在看结果时复核确认，不必亲自去翻阅几十个文件夹。

第三步：日常运转。 每次接到新任务，操作流程如下：

1. 把任务信息告知 AI（可以口述、粘贴聊天记录、或直接给一个快捷方式）
2. AI 自动创建 日期@主题 格式的文件夹，写一份 README 把任务背景、关键信息、初步思路固化下来
3. 看一遍 README，确认理解无误，补充或修正
4. AI 开始执行，过程中产出的分析、方案、报告都放在这个文件夹里
5. 任务完成后，AI 提醒：“这份产出应归档至 Project 目录，那份应归入 Archive 存档，临时文件可删除”

持续使用一段时间后，能发现一个明显的变化：它越来越不需要做背景解释。因为它已阅读过所有的 README、了解项目结构、知道此前同类任务的处理方式。用得越多，它对工作理解越深。

就像一位经验丰富的助手——不需要每次都从头交代。

为什么比传统方式好

传统工作方式的问题不在于"记不住"，而在于信息的碎片化：微信聊两句、邮件发一份、会议上提一嘴、桌面还扔个快捷方式。出一个任务，信息散落在四五个地方，过两周谁都拼不回来。

这个方案的核心就是强制归集——所有信息收拢到一个文件夹里，由 AI 协助整理成结构化的 README。从此任何任务只需要看这一个文件，就知道全貌。

三个核心原则

1. 一事一夹：每个任务一个独立文件夹，不混放
2. 文档驱动：AI 协助整理思路并记录，人确认后执行
3. 自动关联：由 AI 检索历史相关材料，避免重复劳动

前后对比

之前：多渠道接收 → 人脑跟进 → 可能遗漏 → 被动应对 → 临时赶工
现在：任何来源 → 告知 AI → 自动建档+记录 → 状态可追溯 → 闭环归档

场景二：让 AI 分析数据模型

背景

工作中需要维护一套数据模型文件（.ndm2 格式），共十多个模型，近两千张表。跨模型关联关系复杂，过去需要逐个打开模型文件，查看表结构，手动记录关联关系，一个模块就需要小半天。

.ndm2 文件本质上是 JSON 格式，每个文件内部完整记录了该模型的所有表定义、字段结构、视图定义、注释信息。AI 可以直接读取其完整结构——不需要做任何格式转换。下面按照实际分析流程展开。

分析前的准备

第一步不是让 AI 分析，而是让它了解你有哪些素材。把数据模型目录的路径告诉它，它会先列一遍目录，确认有几个文件、每个文件多大，做到心中有数。

然后才是分析。

第一步：快速摸底——谁大谁小

对 AI 说：

“分析数据模型目录下所有 .ndm2 文件，汇总每个模型包含的表数量和视图数量，按表数降序排列”

AI 编写脚本遍历所有 JSON 文件，提取关键统计指标，几秒输出结果。一眼就能看出：

• 核心模块：表数最多、视图数也最多的那个，通常是整个系统的数据中枢
• 中量模块：表数在 100-300 之间，各有独立业务领域
• 轻量模块：表数只在两位数甚至个位数，通常是配置管理、服务注册等辅助模块
• 特殊模块：某个模块的视图数特别少（甚至为零），说明它可能是纯数据存储层，业务逻辑在其他地方

有了这个总览，就知道分析的重心该放在哪些模块上。

第二步：画架构拓扑图——谁和谁有关

对 AI 说：

“对比所有 .ndm2 文件，找出同名表在多个模型中同时出现的情况。按共享表的数量从高到低排列，列出每对模型之间共享的表名和数量”

AI 逐个比对，输出一张关联关系矩阵。实际案例中会发现几种典型模式：

模式一：主数据源 + 下游副本。 比如模块 A 和模块 B 共享了二十多张表（用户主表、资源映射表、角色表、菜单表、密码策略表……）。一看就知道模块 A 是主数据源，模块 B 是其数据副本，用于运营分析或对外接口。

模式二：基础版 + 多租户版。 发现模块 C 和模块 D 共享了六十多张表——资产、部署主机、用户、权限、标签……且字段数几乎一致。这说明模块 D 就是模块 C 的多租户部署版本，两者维护同一套核心表结构。

模式三：基础设施跨模块复用。 定时调度框架的表在所有模块中完全一致（表名、字段数都相同）。这说明了系统的技术选型，也为后续运维评估提供了信息——比如调度框架升级时要同时关注六个模块。

有了这张拓扑图，以后做数据变更时，事先就能知道改一张表会波及哪些模块。

第三步：定位核心表——按字段数排名

对 AI 说：

“找出所有表中字段数量最多的前 20 张表，列出表名、所属模块、字段数和业务注释”

AI 输出结果后，能看到清晰的层级：

xxx_performance_data     模块X    298 字段  ← 性能指标宽表，数据分析类
u_user                   模块A    140 字段  ← 用户主表，系统最核心实体
u_user_encrypt           模块A    134 字段  ← 加密用户信息（与主表同构）
u_user_his               模块A    134 字段  ← 用户变更历史
u_resource               模块A    127 字段  ← IT 资源主表
u_entry_resource         模块A    118 字段  ← 入口资源
u_res_account            模块A     95 字段  ← 资源-账号映射
u_res_account            模块B     90 字段  ← 同上的运营副本
...

从这个排名里能获得很多信息：

• 用户主表 140 字段：这是整个系统的核心实体，任何对它的变更影响面最大，需要最严格的评审
• 性能宽表 298 字段：虽然字段最多，但属于数据分析类，业务变更影响相对小，更重要的是关注其查询性能
• 资源-账号映射表在两个模块中出现：印证了上一步的架构结论——模块 B 是模块 A 的下游副本
• 加密/历史表与主表字段数接近：说明数据安全策略完善，账号数据有加密存储和历史追溯

第四步：按业务语义理解模块职责

对 AI 说：

“分析某核心模块中所有有注释的表，按业务语义分组归纳该模块管理了哪些类型的实体。列出每个实体类型的代表表名和职责说明”

AI 提取所有含注释字段的表，归纳出清晰的业务分类：

不需要看一行代码，仅通过表结构和注释就能理解模块管理了七类业务实体，每类的职责边界清晰。这对于接手维护一个新模块、或者给新同事做技术交接，价值巨大。

同样的方法可以应用到其他模块。比如资源管理模块，AI 会归纳出"资产管理、部署管理、权限管理、监控管理"四类实体，告诉你这个模块管的是 IT 基础设施而非用户身份。

第五步：逐模块深度拆解

到了这一步，已经知道谁大谁小、谁和谁有关、核心表是哪些。接下来让 AI 逐个模块出详细报告：

对 AI 说：

“针对每个模块，分别列出：1) 其核心业务表（非日志/历史/运维类）的清单及字段数；2) 其关系映射表的数量和主要关联实体；3) 其历史/日志表的数量和审计覆盖范围；4) 对照全局统计，分析该模块在整体架构中的角色”

AI 逐个模块生成分析报告。以实际中最复杂的模块为例：

• 核心业务表 25 张，涵盖用户、资源、权限、密码、审计五条业务线
• 关系映射表 62 张，远超其他模块——因为 RABC 权限模型需要大量的多对多关联（用户↔角色↔菜单、资源↔账号↔权限、组织↔用户……）
• 历史/日志表 128 张，占比最高——系统重度依赖审计追踪
• 运维辅助表 19 张，主要是调度任务

而对比资源管理模块：

• 核心业务表 22 张，聚焦资产管理和部署管理
• 关系映射表仅 14 张，且都是 2-5 字段的轻量关联——说明其数据模型更扁平，权限控制由账号管理模块统一负责
• 运维辅助表 56 张，远超业务表——因为这个模块负责日常运维监控

两个模块一对比，各自的定位就非常清楚了：一个管"人"（身份与权限），一个管"物"（资产与设备）。

第六步：变更影响分析

对 AI 说：

“如果需要对某张核心表增加一个字段，列出所有受影响的模块、各自的引用方式（主表/副本/轻量引用）、以及对应的字段数”

AI 交叉检索后，能给出精确的影响范围：

• 模块 A（主表）：140 字段 —— 变更在此执行
• 模块 B（副本）：87 字段 —— 持有用户信息运营副本，需同步变更
• 模块 C（轻量引用）：2 字段 —— 仅存储用户标识，不需要同步

有了这份评估，变更方案一目了然：先改主表，再同步副本，轻量引用模块无需操作。

第七步：全局分类统计

对 AI 说：

“按表的命名规则将所有表分类，统计每个模块中各类表的数量和占比”

AI 的分类统计结果告诉我们一个关键事实：

真正需要重点关注的业务核心表占比不到 5%。接近 70% 的表属于"其他业务表"——它们是日常业务运行的表，虽然不是实体核心但承载了大量业务逻辑。12% 是历史日志表，说明系统重视审计追溯。

这个分类的最大价值在于：接手一个新模块时，不用从海量表中找重点。先把那 5% 的核心实体表搞懂，再根据业务需求逐步深入。

这个分析流程的可复用性

以上七步不是一次性分析。它是一个可重复的模板。

当你接手一个新系统、或者现有的系统做了大版本升级后，把数据模型文件重新喂给 AI，跑一遍这七步，就能快速建立对系统数据架构的全局认知。过去需要两三天人工梳理的事情，现在几十分钟就能完成。

总结

两个场景的底层逻辑一致：将结构化数据提供给 AI → AI 完成聚合、比对、关联分析 → 人工判断决策。 AI 负责"算"，人负责"懂"。

工具与门槛

不需要昂贵的企业级产品。日常使用的工具组合：

• Zed — 高性能代码编辑器，内置 AI 面板，支持与多种大模型直接对话
• DeepSeek V4 — 大语言模型，理解力强，支持超长上下文
• Reasonix — AI 编码助手，提供文件读写、目录浏览、内容搜索、Shell 执行等工具能力

三者配合：Zed 作为交互界面，DeepSeek 作为推理引擎，Reasonix 作为执行层（操作文件、跑脚本、搜目录）。全部基于现有工具，零额外采购成本。

关键在于思维转换：不把 AI 仅仅当作问答工具，而是作为能帮助翻阅材料、统计数据、整理提纲的工作助手。只需要明确"让它做什么"，具体的执行过程由它自行完成。