- 用户只需要与 AI 对话即可完成编程任务
- 默认不依赖冗长对话历史作为记忆
- AI 的“记忆”由结构化文档驱动：长期概述 + 当前功能工程要求 + 正在编辑的工作集
- AI 进行编辑时必须先沿文档树定位，再读取/修改代码，尽量避免全局搜索
- AI 每次修改代码后必须同步更新对应文档，保持文档与工程一致
- AI 接入半成品项目时，优先自动补齐文档树以建立可导航的理解
- 形式：项目总体概述文档（一个文件）
- 内容：架构分层、核心模块职责、关键入口、关键约束/不变量、运行与验证方式（高层、稳定、可复用）
- 生命周期：长期存在，随架构变化才更新
- 注入策略：默认总是注入（但必须保持精简）
- 形式：每个具体功能的工程要求文档（一个功能一份；可随任务切换）
- 内容：该功能的目标、输入/输出、验收标准、约束/不变量、验证方式、已知风险与回滚点（强调“怎么验收”，不写实现细节）
- 生命周期：仅在该功能实现周期内常驻上下文；功能切换时替换；完成后仍保留在仓库作为工程依据
- 注入策略：只注入“当前正在实现的功能”的工程要求，不全量注入其他功能
- 形式：当前正在编辑/即将编辑的文件内容与少量相关片段
- 生命周期：仅在当前编辑周期内存在
- 注入策略：默认注入（仅限必要文件），避免全仓库上下文
- 根文档：仓库根目录的 AI_ARCH.md
- 子文档：每个子目录可选 AI_ARCH.md（分层）
- AI 需要理解或修改某块代码时，必须从根文档开始逐级下钻，直到定位到具体文件
- 注入策略：文档树不是记忆层；默认不全量注入，仅在定位/检索命中或显式读取时注入最小必要片段
- 目标：把“规划架构 / 写代码 / 维护文档”三类职责隔离，避免实现细节污染导航文档与工程要求。
- 总原则：文档树（AI_ARCH.md 树）是定位唯一路径；代码变更后必须回到文档维护阶段，保证“文档与工程一致”。
- 输入：用户需求、长期概述（Project Overview）、现有文档树（若存在）。
- 输出：
- 项目架构/计划（AI_PLAN.json）：功能拆分、范围边界、验收标准、阶段划分。
- 文档树导航骨架：根到关键目录的 AI_ARCH.md，Where to Look 能下钻到文件级入口。
- 规则与约束：必要时更新 AI_RULES.md 与当前功能工程要求（短期记忆）。
- 约束：默认不写业务代码；只产出“可导航、可定位、可验收”的架构与文档骨架。
- 输入：当前这一轮用户输入（只生效一轮）、AI_PLAN.json、当前功能工程要求（短期记忆）、文档树定位路径（从根 AI_ARCH.md 下钻得到的目标文件/入口）。
- 输出：可应用的代码变更（patch/diff）、变更文件清单、验证结果（tests/build/lint/最小运行验证之一）。
- 约束：
- 禁止绕开文档树定位；默认禁止全局搜索（仅允许在文档指向范围内有限搜索作为兜底）。
- 若本轮用户输入包含新增/变更的需求或验收标准，必须先写入“当前功能工程要求（短期记忆）”，再继续实现；后续实现以短期记忆为准。
- 不直接改写文档树结构；发现导航不充分时，反馈给文档维护 Agent 进行补齐。
- 输入：架构产物（AI_PLAN/AI_ARCH/规则）、代码变更结果（diff/文件清单）、实际目录结构。
- 输出：更新后的 AI_ARCH.md 树与相关文档（Project Overview/Feature Requirements），确保定位路径可走到最新入口。
- 约束：默认不改业务代码；文档更新必须以“可导航、一致性、可验收”为准绳。
- 输入：用户需求
- 输出：任务计划（短），包括：
- 需要阅读的文档节点（AI_ARCH 路径）
- 预计涉及的文件/模块（来自文档，不来自全局搜索）
- 验证方式（tests/build/lint）
- 记忆：加载/生成该功能的工程要求（短期记忆），作为本轮实现的硬约束
- 代码生成阶段允许直接使用“当前这一轮用户输入”作为即时指令（仅本轮有效，不沉淀为记忆）。
- 若用户输入包含新增/变更的需求或验收标准，必须先同步写入“当前功能工程要求（短期记忆）”，再进入后续实现；后续实现以短期记忆为准。
- 读取长期概述（Project Overview）
- 读取根 AI_ARCH.md 的 Purpose / Where to Look
- 进入 Where to Look 指向的目录，读取对应子目录 AI_ARCH.md
- 重复直到定位到目标文件或入口
- 只读取定位到的文件及其最小依赖（Working Set）
约束：
- 默认禁止全局搜索
- 如果必须搜索，只能在文档指向的范围内进行“有限搜索”
- 搜索是兜底，不是主要定位手段
- AI 生成补丁/变更，并应用到代码
- 每次变更必须记录：
- 改了哪些文件
- 为什么改（与需求的映射）
- 风险与回滚点
- 每次编辑后必须进入“文档同步阶段”
在完成任意代码编辑后，必须更新以下至少一项：
- 相关目录的 AI_ARCH.md：
- Entries：文件/目录职责是否变化
- Entry Points & Flows：关键流程是否变化
- Where to Look：定位路径是否需要调整
- 项目总体概述（若涉及架构级变化）
- 当前功能工程要求（若需求/验收发生变化，必须同步更新）
补充约束：
- 新项目制作过程中：每次工程（编辑循环结束）都必须严格编译文档树（确保相关目录的 AI_ARCH.md 与目录内容一致）。
- 只在“半成品项目接管/导入”场景，允许对文档树进行注入式辅助理解（例如通过检索片段注入上下文）；新项目默认不依赖注入。
- 运行验证（至少一种：tests/build/lint/最小运行验证）
- 维护短期记忆文档到“可验收”的最终状态
- 仅保留：长期概述 + 文档树 + 各功能工程要求 + 代码产物
目标：先建立“可导航的文档树”，再开始改代码。
- 生成/更新根 AI_ARCH.md
- 按目录逐级生成子目录 AI_ARCH.md（BFS/按需）
- 优先保证可导航与可定位，不追求文学化描述
- 每个 AI_ARCH.md 至少包含：
- Purpose：一句话说明目录作用
- Where to Look：明确指向“下一层该看哪些目录/文件”
- Entries：对出现的文件/子目录有一行描述（允许简短）
- 以
.aider/doc_first_mode.json为准：mode: new：新项目（从本软件开始制作；不依赖注入；每次工程后严格编译文档树）mode: imported：导入项目（做到一半才接入；允许注入式辅助理解；仍需维护文档树可导航）
- 首次打开且未设置时，可按“是否已有真实工程文件/目录”推断默认值；必要时允许手动修改该文件进行切换。
- 项目目的
- 关键模块与边界
- 入口与关键流程
- 约束与不变量（例如：鉴权、数据一致性、目录约定）
- 验证方式（如何跑测试/如何验收）
- 常见陷阱
- 输入：
- 输出：
- 风险：
- 回滚：
- Purpose
- Entry Points & Flows
- Entries（Directories / Files）
- Where to Look
- Rebuild：重建文档索引
- Update：增量更新索引（按文件变更）
- Search：按 query 返回 topK 文档片段（含来源路径）
- BuildContext：拼装上下文（长期概述 + 文档片段 + Working Set）
- ProposePatch：输出补丁（diff/patch）
- ApplyPatch：应用补丁
- Verify：运行验证并收集错误摘要
- DocSync：生成/应用文档更新
你是一个 Doc-First 编程助手。默认不使用冗长对话历史作为记忆。你的上下文来源严格按优先级：
- 项目总体概述（长期记忆）
- 当前功能工程要求（短期记忆）
- 正在编辑的文件内容（瞬间记忆）
- 当前这一轮用户输入（只生效一轮）
行为规则：
- 修改任何代码前，先沿文档树定位目标文件（从根 AI_ARCH.md 开始）。
- 默认禁止全局搜索；如必须搜索，只能在文档指向范围内有限搜索。
- 每次改代码后，必须同步更新相关 AI_ARCH.md / 总体概述，确保文档与工程一致。
- 功能需求/验收变化时，必须同步更新当前功能工程要求。
- 当前这一轮用户输入只记录一轮；新增需求/验收必须落到短期记忆，后续以短期记忆为准。
输出要求：
- 给出要修改的文件清单与理由（来自文档定位结果）。
- 输出可应用的补丁/变更，并说明验证方式与回滚点。