269 lines
15 KiB
Markdown
269 lines
15 KiB
Markdown
---
|
||
title: "Vibe-coding工具栈的别样用途"
|
||
date: 2026-06-17T22:00:00+08:00
|
||
draft: false
|
||
description: "分享两个日常使用的 AI 辅助办公场景：如何让 AI 帮助梳理待办事项，以及如何利用 AI 进行数据模型分析。"
|
||
poet: |
|
||
工欲善其事，
|
||
必先利其器。
|
||
——《论语》
|
||
tags:
|
||
- AI
|
||
- 效率
|
||
- 教程
|
||
---
|
||
|
||
给部门同事做了一次内部分享，讲了两个我在日常办公中高频使用 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 提取所有含注释字段的表，归纳出清晰的业务分类：
|
||
|
||
| 实体类型 | 代表表 | 职责说明 |
|
||
|----------|--------|----------|
|
||
| 用户身份 | u_user, u_user_encrypt, u_user_his | 账号全生命周期管理，含加密存储和历史追溯 |
|
||
| IT 资源 | u_resource, u_res_account, u_entry_resource | 被管 IT 资源及账号-资源映射 |
|
||
| 权限控制 | u_role, u_menu, u_role_menu_rel | RBAC 角色权限模型，菜单功能点定义 |
|
||
| 密码策略 | u_pwd_policy, u_history_pwd | 密码复杂度策略与历史密码管理 |
|
||
| 审计日志 | u_portal_log, u_oper_log | 用户操作审计追踪，满足合规要求 |
|
||
| 机构人员 | u_organization, u_user_group | 组织架构与用户组管理 |
|
||
| 定时调度 | 调度框架相关表 | 定时任务配置与管理 |
|
||
|
||
不需要看一行代码，仅通过表结构和注释就能理解模块管理了七类业务实体，每类的职责边界清晰。这对于接手维护一个新模块、或者给新同事做技术交接，价值巨大。
|
||
|
||
同样的方法可以应用到其他模块。比如资源管理模块，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% |
|
||
| 关联映射表 | _rel 等关系表 | ~6% |
|
||
| 历史/日志表 | _his/_log/_record 结尾 | ~12% |
|
||
| 运维辅助表 | 调度/监控/临时/通知类 | ~9% |
|
||
| 其他业务表 | 非以上规则 | ~68% |
|
||
|
||
真正需要重点关注的业务核心表占比不到 5%。接近 70% 的表属于"其他业务表"——它们是日常业务运行的表，虽然不是实体核心但承载了大量业务逻辑。12% 是历史日志表，说明系统重视审计追溯。
|
||
|
||
这个分类的最大价值在于：接手一个新模块时，不用从海量表中找重点。先把那 5% 的核心实体表搞懂，再根据业务需求逐步深入。
|
||
|
||
### 这个分析流程的可复用性
|
||
|
||
以上七步不是一次性分析。它是一个**可重复的模板**。
|
||
|
||
当你接手一个新系统、或者现有的系统做了大版本升级后，把数据模型文件重新喂给 AI，跑一遍这七步，就能快速建立对系统数据架构的全局认知。过去需要两三天人工梳理的事情，现在几十分钟就能完成。
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
两个场景的底层逻辑一致：**将结构化数据提供给 AI → AI 完成聚合、比对、关联分析 → 人工判断决策。** AI 负责"算"，人负责"懂"。
|
||
|
||
### 工具与门槛
|
||
|
||
不需要昂贵的企业级产品。日常使用的工具组合：
|
||
|
||
- **[Zed](https://zed.dev)** — 高性能代码编辑器，内置 AI 面板，支持与多种大模型直接对话
|
||
- **[DeepSeek V4](https://chat.deepseek.com)** — 大语言模型，理解力强，支持超长上下文
|
||
- **[Reasonix](https://reasonix.ai)** — AI 编码助手，提供文件读写、目录浏览、内容搜索、Shell 执行等工具能力
|
||
|
||
三者配合：Zed 作为交互界面，DeepSeek 作为推理引擎，Reasonix 作为执行层（操作文件、跑脚本、搜目录）。全部基于现有工具，零额外采购成本。
|
||
|
||
关键在于思维转换：不把 AI 仅仅当作问答工具，而是作为能帮助翻阅材料、统计数据、整理提纲的工作助手。只需要明确"让它做什么"，具体的执行过程由它自行完成。
|