Files

T

tupingr 3d43cd87d5 feat: 项目架构重构 - hwd32h757芯片成片测试及SDK开发

- 从errlens模板(3角色)重构为1人+Arch AI+Worker AI(2角色)
- 去掉review仓库/QA AI/Dev AI分离，Worker AI统一负责开发+测试
- 新增33个功能单元目录(Test/cases/)，按P0-P6七阶段bring-up
- 新增SDK驱动层骨架(Drivers/CMSIS/HAL_Driver/BSP)
- Arch AI/Worker AI角色不绑定特定AI平台，任何AI可随时接手
- 5个ADR：测试驱动SDK演进、HAL/LL双层、分阶段bring-up、单仓库、角色可替换
- 参考errlens的分层信息架构：dashboard→card→task，token预算控制

2026-05-27 16:37:52 +08:00

3.8 KiB

Raw Blame History

信息架构设计原则

为什么这样设计

AI 的上下文窗口有限。每个读入上下文的字都是成本。这套分层架构的核心思想：每个角色只加载必要信息，按需展开细节。

Token 预算

层级	预算	内容	加载时机
入口（dashboard/card）	< 2K	身份+全貌+任务	每次会话必读
Task 文件	< 1K	单任务全部信息	Worker 开工时
知识沉淀 (knowledge)	< 3K	决策/模式/教训	按需加载
阶段上下文 (phase)	< 5K	目标+范围+架构	按需加载

信息分层

指挥层: dashboard.md → 人类 + Arch AI 唯一入口
决策层: DECISIONS.md → 待人类决策事项
执行层: .ai/tasks/active/ → Worker 各自 task 文件

维护规则

不超预算：每个文件严格遵守 token 预算，超了就拆分
不重复状态：状态只在一处记录（dashboard.md），其他地方引用
Git 管历史：文档只描述"现在是什么"，历史由 Git 负责
一文一答：每个文件独立回答一个问题，不需要串联阅读
角色无关设计：任何 AI 模型都能通过读 card.md 快速接管角色

AI 上下文资源管理（硬约束，适用于所有 AI 角色）

问题：每个 AI 每次会话有上下文窗口限制。如果盲目冲刺大任务，到一半触发自动压缩，前面的讨论、决策细节、已排除的选项全部丢失——代价不是「重来」，是「用不完整的记忆做决策」。

通用规则（所有角色遵守）

任务前评估：开始一个复杂任务前，先判断能否在自己的有效上下文内完成。不能 → 拆分到多个独立会话
做完一件再开始下一件：不积累未完成的工作。阶段收尾了（commit + push），再启动下一个
决策即记录：每个重要判断产生后，立即写入对应文件，不要留在对话里。对话是易失的，文件是持久的
接近窗口上限时主动收尾：感觉上下文开始吃力时，主动 checkpoint——已完成写入文件、commit、告知人类当前进展和下一步。宁可多开一个会话，不要带着残缺记忆继续
拆分到可提交粒度：大任务拆成独立子任务。每个子任务结束后 git commit，确保即使后续会话压缩，已完成的部分不会丢失

嵌入式项目特有约束

角色	主要风险	应对策略
Arch AI	架构讨论容易收不住，寄存器细节容易混淆	每个 ADR 产出后立即写入 decisions.md；寄存器定义以 SVD 为准，不靠记忆
Worker AI	单个外设测试代码可能涉及大量寄存器位域	每个 session 只做 1 个 task；测试代码按功能单元独立，不跨单元引用

信号识别（何时应立即执行规则 4）

需要反复回看前面的讨论才能做判断
开始忘记用户几分钟前说过的话
回复质量出现可感知的下降
同一个问题被重复提出
需要同时修改 3 个以上文件才能完成 task

反模式

「一口气做完再 commit」——做一半触发压缩，前面做的全丢
「这个 task 简单，我顺便把下一个也做了」——超边界 = 超上下文
「先放着，等会儿一起处理」——对话不等人，放着 = 丢了
「凭记忆写寄存器地址」——嵌入式寄存器地址必须从 SVD/头文件获取，不能靠回忆

阶段切换检查清单

切换阶段时 Arch AI 必须：

更新所有角色的 card.md（当前阶段字段）
更新 dashboard.md（进度条 + task 状态面板 + 最近事件）
更新 phases/INDEX.md
产出上一阶段的 completion.md
审计 token 预算

3.8 KiB Raw Blame History Unescape Escape