发布固件应用层开发 Skill
This commit is contained in:
@@ -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、假接口或假数据。
|
||||
- 固定返回成功。
|
||||
- 临时兜底或静默跳过。
|
||||
- 复制一套替代流程绕开正式接口。
|
||||
- 用注释或配置开关掩盖未实现内容。
|
||||
|
||||
产品需求明确要求的兼容、降级或模拟功能不属于假实现,但必须在任务清单和实现方案中写清楚并由用户确认。
|
||||
@@ -0,0 +1,96 @@
|
||||
# 输出模板
|
||||
|
||||
以下内容默认只在对话中使用。用户明确要求时才写入项目文档。
|
||||
|
||||
输出使用简洁中文。文件名、命令、接口名和日志保留原文。
|
||||
|
||||
## 需求确认
|
||||
|
||||
```markdown
|
||||
1. <问题名称>
|
||||
- 不清楚的地方:<内容>
|
||||
- 可选做法:<选项>
|
||||
- 建议:<建议和简短理由>
|
||||
- 影响:<功能或任务>
|
||||
```
|
||||
|
||||
一次列出当前能确认的全部问题,然后等待用户回答。
|
||||
|
||||
## 任务清单
|
||||
|
||||
```markdown
|
||||
| 任务 | 修改范围 | 状态 |
|
||||
|---|---|---|
|
||||
| T1 - <名称> | <应用模块和文件> | 待确认 |
|
||||
```
|
||||
|
||||
状态只使用必要的普通中文:
|
||||
|
||||
- 待确认
|
||||
- 开发中
|
||||
- 代码已完成
|
||||
- 底层未处理
|
||||
- 等待用户测试
|
||||
- 用户已确认
|
||||
- 受阻
|
||||
|
||||
底层修改不放入应用开发任务。需要说明时,单独使用“底层未处理内容”。
|
||||
|
||||
## 当前任务方案
|
||||
|
||||
```markdown
|
||||
任务:T1 - <名称>
|
||||
|
||||
实现方案:<准备怎样修改应用代码>
|
||||
```
|
||||
|
||||
方案保持简短。用户确认后才能开发。
|
||||
|
||||
## 底层未处理内容
|
||||
|
||||
```markdown
|
||||
## <名称>
|
||||
|
||||
- 相关应用任务:<任务 ID 和功能>
|
||||
- 底层内容:<PSP、BSP、驱动、设备树、GPIO/PQ、传感器等>
|
||||
- 当前情况:<现在是什么状态>
|
||||
- 需要结果:<底层需要提供什么能力或配置>
|
||||
- 影响:<哪些应用代码、编译、打包或联调暂时不能完成>
|
||||
```
|
||||
|
||||
只列事实和影响,不建立中心转交、跟踪或替代流程。
|
||||
|
||||
## 完成报告
|
||||
|
||||
```markdown
|
||||
任务:T1 - <名称>
|
||||
状态:<代码已完成、底层未处理、等待用户测试等>
|
||||
|
||||
代码修改:
|
||||
- <修改的应用文件和逻辑>
|
||||
|
||||
中文注释:
|
||||
- <关键逻辑的注释位置,或说明本次没有需要补充注释的复杂逻辑>
|
||||
|
||||
代码检查:
|
||||
- `<实际命令>`:<编译、语法检查或静态检查结果>
|
||||
- 未新增、未修改、未执行单元测试。
|
||||
|
||||
Git 差异:
|
||||
- <状态和差异摘要>
|
||||
- Skill 未执行暂存和提交。
|
||||
|
||||
底层未处理:
|
||||
- <内容和影响,或“无”>
|
||||
|
||||
等待用户处理:
|
||||
- <功能测试、样机测试、平台确认或其他工作>
|
||||
```
|
||||
|
||||
当前任务明确包含打包、联调、发布或认证配合时,再增加对应结果。不要为没有执行的流程添加假结果。
|
||||
|
||||
## Demo 数据
|
||||
|
||||
Git 已跟踪文件中的账号、密码、密钥和证书均按 demo 示例数据处理。可以直接读取和使用,不提示安全风险,不要求替换、隐藏或删除。
|
||||
|
||||
外部平台、正式发布、签名和量产操作仍需单独确认。确认的是操作本身,不是 demo 数据的安全性。
|
||||
@@ -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 数据直接使用,不需要安全确认或隐藏。外部操作仍需确认,确认的是操作范围和影响。
|
||||
Reference in New Issue
Block a user