xdi xdi-spec 查看计划

小电智控团队 · Embedded R&D Tooling Pilot

xdi-spec

XDI = XiaoDian Intelligence

面向多平台嵌入式研发，构建连接需求、知识、执行与验证的可追溯工程工作流。

当前在做什么 后续计划
已具备 Spec 框架

变更说明、风险点、验证要求已有基础模板。

进行中 Wise 知识库

正在整理历史 bug、项目经验和检索入口。

未开始 工程执行 / 板端采集

作为后续阶段推进，当前不承诺已完成。

xdi R&D FLOW
scan build flash verify
kb issues logs review

Current Work

当前目标：把需求变更、工程执行和验证记录串起来

先从嵌入式软件最常见的改动场景切入：需求澄清、相关历史问题检索、生成变更说明、调用项目构建/烧录脚本、记录验证结果。

workflow drafting

项目识别

整理 SDK、OS、构建系统和输出产物

xdi scan --project current
project log
board check planned
BOOT OK
screen_not_black serial_login_seen audio_1khz_detecting

Project Scope

项目范围：先打通通用 SDK 的基础工程信息

当前不追求覆盖所有芯片和全部场景，先把项目结构、构建方式、烧录方式、日志入口和历史经验整理成可复用的工程配置。

01

项目识别

整理 BSP、bootloader、kernel、RTOS、app、DTS、defconfig、产物目录等关键信息。

02

构建 / 烧录入口

统一记录 make、idf.py、west、ADB、fastboot、JLink、OpenOCD 和厂商烧录器的调用方式。

03

日志 / 配置

整理串口、logcat、dmesg、RTOS assert、Kconfig、DTS 和板级配置差异。

04

经验资料

把 Wise、Jira、飞书、坚果云、厂商文档和历史 bug 中的可复用信息整理成检索入口。

Differentiation

机会：企业内部研发流程层

全志 ThunderWorkbench 证明了“知识库 + 工具链 + 硬件管控”的方向成立。它解决的是 Tina SDK 生态内的原厂知识和执行自动化；xdi-spec 不做原厂工具平替，而是把公司内部项目经验、历史问题和多平台流程整理成可复用的研发层。

01

企业内部知识

重点接入 Wise、Jira、飞书、历史 bug、客户问题和项目 SOP，这是原厂工具天然拿不到的上下文。

02

多平台统一

面向多芯片、多 OS、多 SDK 的项目现实，沉淀统一的 Project Profile，而不是绑定单一原厂生态。

03

可追溯边界

先强调资料来源、风险标记、人工 review 和验证记录，避免一开始就承诺全自动执行。

04

工具可接入

如果项目使用全志，ThunderWorkbench 可以作为执行工具接入；xdi-spec 负责需求、知识、验证和复盘链路。

Deliverables

把一次性问答变成可复查的工程记录

每次任务尽量留下四类交付物：任务说明、参考资料、执行日志、验证记录。先做到能追溯，再逐步提高工具化程度。

需求输入
Wise / Jira
变更说明
资料来源
构建
烧录
板端检查
问题复盘

Board Verification

后续规划 / 未开始

验证方案：先设计板端信息采集方式

该模块目前作为后续规划，不表示已经落地。目标是优先把串口、ADB、截图、音频、上电日志等信息标准化采集，减少人工记录遗漏。

HDMI / USB camera

屏幕状态采集

采集屏幕画面，辅助检查黑屏、花屏、分辨率异常和关键 UI 状态。

assert:
  vision:
    - screen_not_black
    - text_contains: "Welcome"
    - no_major_artifacts

Evaluation Metrics

试点评估指标：用真实项目数据校准

0 分钟

目标：相似问题和历史资料可在分钟级找到

0%

目标：重复问题定位时间下降，先以试点数据验证

0%+

目标：常规变更都有明确验证项和结果记录

0%+

目标：重点板端现象具备截图、日志或采样证据

Roadmap

Roadmap：明确当前进度和未启动范围

当前已具备 spec 框架，Wise 知识库接入正在推进；验证、关键事实来源、构建烧录和板端采集先作为后续阶段规划。

已具备 进行中 未开始
当前重点 把 Wise / Jira 历史问题和项目经验接入任务分析
下一步 选定一类高频 bug，做出“相似问题 Top5 + 根因建议 + 验证项”的真实分析 demo
Phase 1
已具备

Spec 框架

已形成嵌入式变更说明框架，可覆盖任务背景、影响模块、风险点、约束条件和验证要求。

Phase 2
进行中

Wise 知识库接入

正在整理 Wise / Jira / 飞书 / 历史 bug 的检索入口，目标是把相似问题和项目经验带入任务分析。

Phase 3
未开始

验证项清单

后续为不同类型变更生成验证项，早期允许人工 checklist，先保证记录完整。

Phase 4
未开始

关键事实来源

后续对寄存器、时钟、pin、协议、时序常量等关键硬件信息标记资料来源。

Phase 5
未开始

构建 / 烧录 / 日志接入

后续接入项目级 build、flash、serial、ADB、日志采集脚本，形成可复用入口。

Phase 6
未开始

板端现象采集

后续评估摄像头、麦克风、采集卡和可编程电源接入，形成可回放的验证附件。