with one click
code-flow-viz
// 用于梳理和可视化代码流程,生成清晰的 ASCII 流程图、数据流图和表格分析。适用于已有代码的梳理、新功能设计的说明、以及技术文档的编写。
// 用于梳理和可视化代码流程,生成清晰的 ASCII 流程图、数据流图和表格分析。适用于已有代码的梳理、新功能设计的说明、以及技术文档的编写。
项目架构约定:通过 Root/Folder/File 三层极简元数据(_dir.md + I/O/Pos 注释) 让 AI 在任意位置自定位。 **AI 创建文件夹时自动触发**:hook 会生成 _dir.md 模板,AI 填写 Input/Output/Pos。
在编写、更新、维护 roadmap.md 的时候触发
多模型协作 — 调用 gemini-agent 和 codex-agent 辅助分析 **触发场景**(主动使用): - 深度代码分析:算法理解、性能瓶颈、架构梳理 - 大范围探索:5+ 文件、模块依赖、调用链追踪 - 复杂推理:方案评估、逻辑验证、并发安全分析 - 多视角决策:需要不同角度分析再综合判断 **不触发**: - 简单修改(1-2 文件的明确改动) - 文件查找(用 Explore 或 Glob/Grep) - 已知路径的读写操作 **核心原则**:你是决策者和执行者,外部模型是顾问。
代码风格规范 / Code style conventions。在编写、编辑、评审 Python 代码时使用。包括类型注解、Decimal 精度、Docstring、模块组织等规范。Use when writing, editing, or reviewing Python code. Enforces type hints, Decimal precision, docstrings, and module organization.
分层架构规范 / Architecture and layering rules (v0.3.1)。在设计新组件、修改导入、检查分层时使用。核心约束:cli → flows → data,core 向内不向外。Use when designing components, changing imports, or reviewing layering decisions. Enforces cli/flows/core/data separation.
命名规范 / Naming conventions。在创建类、函数、变量,或重命名、检查命名时使用。核心原则:简洁优先,上下文消歧义,类型提示已提供足够信息。Use when naming classes/functions/variables, renaming code, or reviewing names. Prioritizes brevity over self-documentation.
| name | code-flow-viz |
| description | 用于梳理和可视化代码流程,生成清晰的 ASCII 流程图、数据流图和表格分析。适用于已有代码的梳理、新功能设计的说明、以及技术文档的编写。 |
本 Skill 提供一套可复用的模板和方法,用于梳理代码流程、生成可视化文档。
核心原则:用文字和 ASCII 图表讲清楚"数据从哪来、经过哪些层、最后到哪去"。
在以下场景使用本 Skill:
适用于:梳理一个功能的多种使用场景(如手动 vs 自动、成功 vs 失败)
┌─────────────────────────────────────────────────────────────────────┐
│ 功能名称(如:限额管理全生命周期) │
└─────────────────────────────────────────────────────────────────────┘
═══════════════════════════════════════════════════════════════════════
场景 1:场景名称(如:自动查询限额状态)
═══════════════════════════════════════════════════════════════════════
用户命令
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ uv run python -m src.cli.xxx ... │
└────────────────┬────────────────────────────────────────────────┘
│
▼
┌────────────────┐
│ CLI 层 │ 调用 Flow 函数
│ _do_xxx() │ ────────────────────┐
└────────────────┘ │
▼
┌──────────────────────────┐
│ Flow 层 │
│ xxx_flow() │
└───────┬──────────────────┘
│
▼
┌─────────────────────────────┐
│ Data 层 │
│ XxxRepo / XxxClient │
└────────┬─────────────────────┘
│
▼
┌────────────────────────────┐
│ 外部系统 / 数据库 │
│ (SQLite / API / etc) │
└──────────┬─────────────────┘
│ 返回数据
▼
┌──────────────────────────────────┐
│ 数据处理(解析/转换) │
└─────────────┬────────────────────┘
│
▼
┌──────────────────────┐
│ 返回值数据类 │ ← 说明为什么保留/简化
│ (Result / Item / ...)│
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ CLI 层格式化输出 │
└──────────────────────┘
│
▼
╔══════════════════════════════════════════════════╗
║ 终端输出示例 ║
║ (用框线包围,突出最终用户看到的效果) ║
╚══════════════════════════════════════════════════╝
═══════════════════════════════════════════════════════════════════════
场景 2:另一个场景
═══════════════════════════════════════════════════════════════════════
(重复上述结构,突出差异点)
适用于:解释某个功能涉及的数据库表
CREATE TABLE table_name (
id INTEGER PRIMARY KEY AUTOINCREMENT, -- ← 说明主键作用
field1 TEXT NOT NULL, -- 说明字段含义
field2 TEXT, -- NULL 的业务含义
...
);
-- 索引(说明为什么需要这个索引)
CREATE INDEX idx_xxx ON table_name(field1, field2);
示例数据表:
| id | field1 | field2 | field3 | 说明 |
|---|---|---|---|---|
| 42 | value1 | value2 | value3 | 解释这条记录的业务含义 |
| 43 | ... | ... | ... | ... |
典型查询:
-- 场景说明:什么时候需要这样查?
SELECT * FROM table_name
WHERE condition1 = ?
AND (condition2 IS NULL OR condition2 >= ?);
适用于:快速说明函数调用关系
CLI 层 (_do_xxx)
│
└─> Flow 层 (xxx_flow)
│
├─> Data/Repo (xxx_repo.get)
│ │
│ └─> SQLite (SELECT ...)
│
└─> Data/Client (xxx_client.fetch)
│
└─> 外部 API (HTTP GET ...)
适用于:评估中间数据类是否必要
| 类名 | 字段数 | 用途 | 判定 | 理由 |
|---|---|---|---|---|
XxxResult | 6 | 多字段聚合 + CLI 展示 | ✅ 保留 | 满足"最小必要原则" |
XxxWrapper | 1 | 单字段包装 | ❌ 删除 | 过度包装,直接返回原始类型 |
XxxItem | 3 | 列表明细项 | ✅ 保留 | 有业务语义 |
对比示例:
# ❌ 过度包装
@dataclass
class XxxResult:
field: SomeType # 只有一个字段
def xxx_flow() -> XxxResult:
return XxxResult(field=value)
# ✅ 简化后
def xxx_flow() -> SomeType: # 直接返回
return value
适用于:突出业务规则和设计决策
┌─────────────────────────────────────────────────────────────┐
│ 业务关键点 │
├──────────────────────┬──────────────────────────────────────┤
│ 为什么这样设计? │ 具体决策 │
├──────────────────────┼──────────────────────────────────────┤
│ • 数据精度 │ 金额用 Decimal,2 位小数 │
│ • 幂等性 │ 按 (fund_code, date) 唯一约束 │
│ • 可追溯性 │ record_id 作为全局唯一标识 │
└──────────────────────┴──────────────────────────────────────┘
回答以下问题:
原则:
│ ▼ ┐ ┘ └ ├ ─)串联数据流┌ ┐ └ ┘ │ ─)分隔层次╔ ╗ ╚ ╝ ║ ═)突出用户可见部分← 说明)符号使用规范:
| 符号 | 用途 | 示例 |
|---|---|---|
│ ▼ | 垂直流向 | 数据从上到下 |
→ ← | 水平说明 | record_id: int ← 数据库主键 |
┌ ┐ └ ┘ | 单线框 | 包围代码块、命令 |
╔ ╗ ╚ ╝ | 双线框 | 突出终端输出、重要结果 |
═══ | 分隔线 | 分隔不同场景 |
Before vs After(重构场景):
# Before(问题版本)
...代码...
# 问题:
# - 过度包装
# - 字段冗余
# - 增加认知负担
# After(改进版本)
...代码...
# 改进:
# - 直接返回有意义类型
# - 减少中间层
# - 降低维护成本
(见上面的模板 1 示例,展开 4 个场景的完整流程)
| 函数 | 之前返回 | 现在返回 | 判定 | 原因 |
|---|---|---|---|---|
add_restriction | AddRestrictionResult(6字段) | 保留 | ✅ | CLI 需要展示所有字段 |
end_restriction | EndRestrictionResult(4字段) | bool | ❌ | 只需要成功/失败 |
check_trading_status | CheckStatusResult(2字段) | ParsedRestriction | None | ❌ | 只是简单包装 |
生成流程可视化文档时,确保包含:
❌ 纯文字描述流程
首先调用 CLI 层的 _do_xxx 函数,然后 _do_xxx 会调用 Flow 层的 xxx_flow 函数,
xxx_flow 再调用 Data 层的 xxx_repo.get 方法...
✅ 用 ASCII 图表
CLI (_do_xxx) → Flow (xxx_flow) → Data (xxx_repo.get) → SQLite
❌ 表格没有重点
| 字段 | 类型 |
|---|---|
| id | int |
| name | str |
✅ 突出业务含义
| 字段 | 类型 | 说明 | 业务约束 |
|---|---|---|---|
| id | int | 主键 | 自动生成,全局唯一 |
| name | str | 基金名称 | 非空,用于展示 |
❌ SQL 没有场景说明
SELECT * FROM table WHERE id = ?;
✅ 带业务场景
-- 场景:用户查询某条限制记录详情
SELECT * FROM fund_restrictions WHERE id = ?;
-- 场景:DCA 分析时检查某日是否被限额
SELECT * FROM fund_restrictions
WHERE fund_code = ? AND start_date <= ? AND (end_date IS NULL OR end_date >= ?);
本 Skill 的核心价值:
使用频率:每次需要解释"某个功能怎么工作"时都可以用。