FlashForge ← 返回主页
Implementation Plan

实施方案

从 SPEC 解析到全链路自动化，每个阶段的具体步骤、技术选型、输入输出定义。
✓
Phase 0
SPEC 文件路径整理
建立 Flash SPEC 文件归档结构，明确每个 Flash 的文档路径
已完成 ▾
完成内容
  1. 确定 SPEC 文件存储根路径
  2. 按 Flash 型号建立目录结构（Vendor → Family → Model）
  3. 整理每个 Flash 的 SPEC PDF、H 文件、demo code 路径
  4. 建立文件索引表（型号 → 路径映射）
◎
Phase 1
SPEC 解析 + RAG 知识库
PDF → 结构化文本 → 向量库 → 自然语言检索
进行中 ▾
Step 1.1 · PDF → Markdown 结构化提取
  1. 工具选型：使用 docling（IBM 开源）或 marker（surya）做 layout-aware 提取，保留表格结构和章节层级
  2. 输出格式：Markdown + YAML front matter，包含 flash_name / vendor / version / page_count
  3. 质量控制：关键参数表（Register Table, Command Set, AC Timing）需人工抽样校验
技术栈doclingmarkerPyMuPDF
输入SPEC PDF
输出结构化 Markdown 文件YAML metadata
from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("MT29F8T08.pdf")
markdown = result.document.export_to_markdown()
Step 1.2 · 文本分块（Chunking）
  1. 分块策略：按 NAND SPEC 天然结构分段 — Register Table / Command Sequence / AC Timing / Feature Description
  2. Chunk 大小：800–1200 tokens，重叠 100 tokens
  3. Metadata 标注：每个 chunk 携带 flash_name / section / page_number / register_name（便于溯源）
Step 1.3 · 向量库构建
  1. Embedding 模型：本地部署 BGE-M3（中英双语，1024 维）或 OpenAI text-embedding-3-small
  2. 向量库：FAISS IndexFlatIP（内积检索），本地持久化为 .faiss + .pkl
  3. 索引构建脚本：遍历所有 Flash 的 md 文件 → 分块 → embedding → 入库
技术栈FAISSBGE-M3sentence-transformers
输入结构化 Markdown 文件
输出FAISS 向量索引chunk metadata 文件
Step 1.4 · RAG 查询管道
  1. 框架：LlamaIndex 或 LangChain，封装 query → retrieve → rerank → answer 流水线
  2. Retrieval：FAISS 向量检索 top-10 chunks
  3. Rerank：BGE-Reranker 对候选 chunk 重排序，取 top-3
  4. Answer：LLM 合成答案，强制引用来源 section + page_number
# RAG Pipeline
chunks = faiss_index.search(embed(query), k=10)
reranked = reranker.rerank(query, chunks)[:3]
answer = llm.generate(prompt, sources=reranked) # 引用 source + page
Step 1.5 · 提问库构建
  1. 整理 50–100 个工程高频问题模板（参数查询 / 对比查询 / 操作流程）
  2. 每个问题绑定 SPEC 章节路径（用于评测 RAG 准确率）
  3. 持续从实际使用中扩充（用户提问 → 人工标注标准答案）
技术栈LlamaIndexBGE-RerankerLLM (GPT/DeepSeek)
输入自然语言问题
输出带溯源的答案来源 section + page
○
Phase 2
对比引擎 + 标准文档 + 超级搜索
Flash 参数自动对比、可溯源文档生成、JIRA/Confluence 接入
待启动 ▾
Step 2.1 · SPEC 参数结构化提取
  1. 使用 LLM structured output（JSON Schema）从 Markdown 中提取 NAND 关键参数
  2. 提取字段：flash_id, page_size, block_size, die_count, timing(tR/tPROG/tBERS), commands, features, registers
  3. 存入结构化数据（JSON 文件或 SQLite），统一 Schema 保证可比性
// Structured Output Schema (excerpt)
{
  "flash_id": "MT29F8T08",
  "page_size": 18432,
  "timing": { "tR": "58µs", "tPROG": "600µs" },
  "features": ["OTP", "Vt_Read_Retry", "Multi-Plane_Read"]
}
Step 2.2 · 自动 Diff 引擎
  1. Python 脚本加载两个 Flash 的结构化参数 JSON
  2. 递归字段级对比，输出 added / removed / modified 三个维度
  3. 代际对比：BICS8 vs BICS10，识别新特性、废弃功能、参数变化
Step 2.3 · Matrix 网页可视化
  1. Python 生成 HTML table，每个 Flash 一列，参数一行
  2. 差异单元格高亮（绿色=新增，红色=删除，黄色=变化）
  3. 部署到 nginx，团队通过内网访问
技术栈instructor / Structured OutputpandasJinja2 HTML
输入Phase 1 Markdown 文件已有 Flash 参数 JSON
输出Diff Matrix 网页结构化参数 JSON
Step 2.4 · 标准文档自动生成
  1. 定义标准文档模板：overview.md / commands.md / timing.md / registers.md / features.md
  2. LLM 从 SPEC Markdown 中提取对应内容填充模板
  3. 每个参数自动注入 ``[来源: SPEC §X.Y, p.Z]`` 标注
Step 2.5 · JIRA / Confluence MCP 接入
  1. 使用 Python MCP SDK 对接 JIRA REST API 和 Confluence API
  2. Phase 1 先做只读查询（搜索 Flash 相关 issue、开发笔记）
  3. Phase 2 开放写入（自动创建文档条目、关联 issue）
技术栈Python MCP SDKJIRA REST APIConfluence API
输入Flash 型号 / 关键词
输出关联 issue 列表历史开发笔记
○
Phase 3
代码生成
基于 SPEC + Diff + 参考代码，自动生成 Flash 支持代码 patch
待启动 ▾
Step 3.1 · Context 构建引擎
  1. 输入聚合：H 头文件（寄存器/结构体定义）+ demo code（已有 Flash 支持代码）+ Diff Matrix（Phase 2）+ 标准文档（Phase 2）
  2. Context 窗口管理：按模块（初始化 / 擦写读 / 重读 / 高级功能）分批送入 LLM
  3. Prompt 模板：每个模块独立 prompt，包含 SPEC 要点 + 参考代码 + 差异项
Step 3.2 · 分模块代码生成
  1. 初始化模块：寄存器初始值、feature flags、timing 参数
  2. 擦写读模块：command sequence、page/block 操作逻辑
  3. 重读模块：read retry 表、Vt 偏移策略
  4. 高级功能模块：OTP、multi-plane、crypto 等
Step 3.3 · Patch 生成与溯源
  1. LLM 输出 unified diff 格式 patch 文件
  2. 每个变更块强制标注 // SPEC: §4.3.1 p.47 — tR max = 58µs
  3. PR-friendly 格式，可直接 code review
技术栈LLM (DeepSeek-v4 / GPT-4o)unified diff模板引擎
输入H文件 + demo code + Diff Matrix + 标准文档
输出初始化 patch擦写读 patch重读 patch高级功能 patch
目标70% 可用率
○
Phase 4
白盒验证自动化
代码自动插桩 → CLI 执行 → 收集 log → AI 分析 → 验证报告
待启动 ▾
Step 4.1 · 代码自动插桩
  1. Python 脚本解析生成的 C 代码 → 识别函数边界和关键变量
  2. 自动注入打印宏：函数入口/出口、寄存器读写值、timing 耗时、错误路径
  3. 插桩标记（__INSTRUMENTED__）确保不污染生产代码
Step 4.2 · CLI 执行 + Log 收集
  1. 编译插桩后的代码 → 烧录到测试板
  2. expect/pexpect 通过串口/telnet 发送测试命令
  3. 收集全量串口 log，结构化存储（按模块 / 测试用例分组）
Step 4.3 · AI 分析
  1. LLM 输入：log + SPEC 预期值（从 Phase 2 标准文档提取）
  2. 逐条比对实测值 vs SPEC 预期值
  3. 输出 PASS / FAIL / WARNING + 异常定位
Step 4.4 · 报告生成
  1. 生成 Markdown 验证报告：测试用例 × 结果矩阵
  2. 覆盖率统计（按模块 / 按寄存器 / 按功能）
  3. 失败用例 SPEC 引用 + 实际值 vs 预期值对比
技术栈Python AST 插桩expect/pexpectLLM log analysis
输入Phase 3 生成的代码Phase 2 标准文档（预期值）
输出PASS/FAIL 报告覆盖率统计异常诊断
○
Phase 5
全链路打通
一键触发：拖入 SPEC → AI 自动跑完整流程 → 交付
待启动 ▾
Step 5.1 · 流水线编排
  1. Python Pipeline 脚本：串联 Phase 1 → 2 → 3 → 4
  2. 异步任务队列（Celery / RQ）：长任务（PDF 解析、向量化）后台执行
  3. 状态追踪：每个 Phase 的进度和结果可视化
Step 5.2 · Web 统一入口
  1. nginx 反向代理聚合所有工具页面（Matrix / 文档 / 验证报告）
  2. 拖拽上传 SPEC 入口（Dropzone.js） → 触发 Pipeline
  3. 结果页：代码 patch 下载 + Matrix 链接 + 文档链接 + 报告链接
Step 5.3 · 持续迭代
  1. 用户反馈闭环：每次人工 review 的修改记录回写 prompt 模板
  2. 知识库自动扩充：新 Flash 解析完成后自动入库
  3. 代码准确率持续监控：70% → 80% → 90%+
技术栈Python PipelineCelery / RQnginxDropzone.js
输入SPEC PDF + H 文件（可选）
输出统一交付页面 — 代码 + 文档 + Matrix + 报告
⚡ FlashForge
NAND Flash AI 平台 · 实施方案
← 返回主页