发布固件应用层开发 Skill

This commit is contained in:
2026-09-03 14:56:38 +08:00
commit 30565e222a
5 changed files with 343 additions and 0 deletions
+61
View File
@@ -0,0 +1,61 @@
# 应用层与底层边界
文件、字段或脚本可能影响硬件和底层固件时,按本说明判断。
## 应用组负责
- 用户态应用、服务进程和业务模块。
- 直播、事件、存储、网络、云服务、告警、设备管理等应用功能。
- 明确由应用管理的功能开关、产品能力和应用参数。
- 应用日志、诊断、校验脚本和说明文档。
- 应用构建、打包、样机联调、平台联调、发布、认证配合及量产应用功能。
- Bug 修复和回归处理。
应用组负责上述工作,但只执行当前需求明确要求的内容。外部操作必须先单独确认。
## 应用组不得修改
- `psp/` 目录、`psp.json` 及其他 PSP 配置。
- BSP、Bootloader、内核、内核模块和驱动。
- 设备树、板级配置、引脚复用、寄存器、时钟和电源控制。
- Flash 分区、启动槽、内存布局和底层镜像格式。
- GPIO/PQ、传感器初始化、ISP、底层媒体实现和硬件编解码。
- 电机电气控制、Wi-Fi 驱动选择和其他硬件初始化。
可以读取和使用已有底层文件或产物,但不能修改它们。复制、链接、打包已有底层产物,也不代表可以编辑它们。
## 混合配置
PSP 文件整份都不属于应用组修改范围,即使其中某个字段看起来与应用有关,也不能直接修改。
其他产品清单、镜像清单、传感器配置、GPIO/PQ 参数和驱动映射也可能同时包含应用和底层内容。只有项目资料明确说明由应用组维护时,才能修改其中的应用字段。
无法确认归属时:
1. 先按底层内容处理。
2. 保持文件不变。
3. 列出需要底层处理的内容及其影响。
## 底层未处理内容
发现需要底层修改时,只输出必要信息:
- 相关应用任务。
- 需要处理的底层文件、模块或能力。
- 当前情况。
- 需要达到的结果。
- 对应用代码、编译或联调的影响。
不建立中心转交或跟踪流程。能独立完成的应用代码继续完成;依赖底层的部分标记为“底层未处理”。
## 禁止假实现
底层能力缺失时,不得使用以下方式冒充完成:
- Mock、Stub、假接口或假数据。
- 固定返回成功。
- 临时兜底或静默跳过。
- 复制一套替代流程绕开正式接口。
- 用注释或配置开关掩盖未实现内容。
产品需求明确要求的兼容、降级或模拟功能不属于假实现,但必须在任务清单和实现方案中写清楚并由用户确认。
+96
View File
@@ -0,0 +1,96 @@
# 输出模板
以下内容默认只在对话中使用。用户明确要求时才写入项目文档。
输出使用简洁中文。文件名、命令、接口名和日志保留原文。
## 需求确认
```markdown
1. <问题名称>
- 不清楚的地方:<内容>
- 可选做法:<选项>
- 建议:<建议和简短理由>
- 影响:<功能或任务>
```
一次列出当前能确认的全部问题,然后等待用户回答。
## 任务清单
```markdown
| 任务 | 修改范围 | 状态 |
|---|---|---|
| T1 - <名称> | <应用模块和文件> | 待确认 |
```
状态只使用必要的普通中文:
- 待确认
- 开发中
- 代码已完成
- 底层未处理
- 等待用户测试
- 用户已确认
- 受阻
底层修改不放入应用开发任务。需要说明时,单独使用“底层未处理内容”。
## 当前任务方案
```markdown
任务:T1 - <名称>
实现方案:<准备怎样修改应用代码>
```
方案保持简短。用户确认后才能开发。
## 底层未处理内容
```markdown
## <名称>
- 相关应用任务:<任务 ID 和功能>
- 底层内容:<PSP、BSP、驱动、设备树、GPIO/PQ、传感器等>
- 当前情况:<现在是什么状态>
- 需要结果:<底层需要提供什么能力或配置>
- 影响:<哪些应用代码、编译、打包或联调暂时不能完成>
```
只列事实和影响,不建立中心转交、跟踪或替代流程。
## 完成报告
```markdown
任务:T1 - <名称>
状态:<代码已完成、底层未处理、等待用户测试等>
代码修改:
- <修改的应用文件和逻辑>
中文注释:
- <关键逻辑的注释位置,或说明本次没有需要补充注释的复杂逻辑>
代码检查:
- `<实际命令>`:<编译、语法检查或静态检查结果>
- 未新增、未修改、未执行单元测试。
Git 差异:
- <状态和差异摘要>
- Skill 未执行暂存和提交。
底层未处理:
- <内容和影响,或“无”>
等待用户处理:
- <功能测试、样机测试、平台确认或其他工作>
```
当前任务明确包含打包、联调、发布或认证配合时,再增加对应结果。不要为没有执行的流程添加假结果。
## Demo 数据
Git 已跟踪文件中的账号、密码、密钥和证书均按 demo 示例数据处理。可以直接读取和使用,不提示安全风险,不要求替换、隐藏或删除。
外部平台、正式发布、签名和量产操作仍需单独确认。确认的是操作本身,不是 demo 数据的安全性。
+106
View File
@@ -0,0 +1,106 @@
# 开发流程
修改文件、生成产物或执行命令前,按下面顺序处理。
```text
只读检查需求和工程
→ 检查 Git 和 .gitignore
→ 确认不清楚的需求
→ 确认完整任务清单
→ 确认当前任务的实现方案
→ 开发当前任务
→ 编译或静态检查
→ 汇报代码和差异
→ 等待用户确认和测试
→ 处理下一个任务
```
## 1. 只读检查
- 阅读当前需求、规格说明、功能清单、工程说明、构建脚本和相关代码。
- 参考工程只用于了解做法,不能直接代替目标工程的要求。
- 找出本次需要修改的应用模块,以及可能依赖的底层内容。
- 查看 Git 状态,不修改任何文件。
需求冲突时,默认顺序是:
1. 用户当前明确要求。
2. 已确认的产品需求或规格。
3. 当前工程现有约定。
4. 参考工程做法。
5. 推测。
高优先级要求覆盖其他来源时,要简洁说明差异,不能悄悄改掉。
## 2. 检查 Git 和 `.gitignore`
正式任务清单生成前:
1. 确认当前目录属于用户已创建的 Git 仓库。
2. 如果不是 Git 仓库,停止修改,请用户先准备仓库。不得执行 `git init`
3. 查看 `git status``.gitignore` 和项目已有的输出目录说明。
4. 请用户确认现有忽略规则,或确认建议新增的规则。
5. 忽略规则未确认前,不运行会生成相关中间文件的命令。
工作区不要求完全干净。记录已有修改并避开它们。当前任务必须修改同一文件且无法安全区分时,暂停并询问用户。
## 3. 确认需求
只询问需要用户决定的问题。一次列出当前能确认的全部问题,每项包括:
- 不清楚或冲突的地方。
- 可选做法。
- 建议做法和简短理由。
- 受影响的功能或任务。
等待用户回答后再生成正式任务清单。
## 4. 确认任务清单
- 任务清单只列任务名称、修改范围和状态。
- 只包含当前需求明确分配给应用组的工作。
- 底层内容不作为应用开发任务,只在“底层未处理内容”中说明。
- 在对话中展示完整清单并等待用户确认。
- 默认不创建流程文档。用户明确要求时才写入项目。
## 5. 逐项开发
每次只处理一个已确认任务:
1. 给出简短实现方案并等待用户确认。
2. 再次检查 Git 状态和应用层边界。
3. 只修改已确认范围内的应用代码或应用配置。
4. 关键逻辑添加必要的中文注释。
5. 不新增、不修改、不执行单元测试。
6. 不使用 Mock、Stub、假数据、假成功、临时兜底或绕行流程补齐缺失功能。
7. 可以执行编译、语法检查和项目已有的静态检查。确认退出结果和实际输出,不能只看“成功”字样。
8. 当前任务明确要求打包或产物检查时,可以执行对应命令。
9. 再次检查 Git 状态和差异,确认中间文件已被忽略。不得暂存或提交。
10. 用简洁中文汇报结果,等待用户确认和测试。
用户测试通过后,把任务状态改为“用户已确认”。用户发现问题后,在当前任务范围内修正;需求或范围发生变化时,重新确认受影响的任务和方案。
## 6. 底层内容
发现 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器底层配置、底层媒体或硬件初始化需要修改时:
1. 不修改、不重新生成,也不做试验性改动。
2. 列出需要底层处理的内容、原因和对应用代码的影响。
3. 能独立完成的应用代码继续完成。
4. 依赖底层的部分标记为“底层未处理”。
5. 不写假接口、替代逻辑或临时流程。
6. 不建立中心转交或跟踪步骤。
底层内容以后准备好时,应用组负责按当前需求完成应用侧接入、编译、打包、联调和后续工作,但仍不修改底层文件。
## 7. 外部操作
以下工作属于应用组职责,但必须在实际执行前单独确认:
- 烧录或控制样机。
- 操作外部平台、实验室或流水线。
- 正式发布、签名或上传。
- 使用证书执行发布操作。
- 认证和量产操作。
Git 已跟踪的账号、密码、密钥和证书按 demo 数据直接使用,不需要安全确认或隐藏。外部操作仍需确认,确认的是操作范围和影响。