AI 生成代码的速度已经超过了人阅读代码的速度。 开发者仍在用“逐行看懂全部实现”作为主要质量控制手段，结果只能让人越来越跟不上 Agent 的节奏。

痛点一：代码生成太快，没人能及时审查。

更糟的是每次启动新会话时Agent 必须重新理解项目背景、当前进度、已确认的决策还有可执行的范围。说起来，如果这些信息只保存在对话或人的记忆里模型越快，跑偏也越快。

实现 AI 原生开发的主要：上下文闭环 + 执行闭环

只有同时建立这两个闭环。才能把代码生成速度转化为生产力，而不是失控的放大器。

一、把模型当作近似无状态函数

在设计 AI 原生项目时一个关键假设是：模型不依赖上一次会话，也不依赖口头约定的上下文。 每次调用都应从当前可见材料重新理解任务。

痛点二：缺乏持久化的操作环境和长期记忆。

仓库的职责不再是单纯存放代码，而是提供 Agent 的操作环境和长期记忆。所有希望 Agent 稳定掌握的信息。都必须有明确、可读取、可追溯的载体：

• 项目概述与技术栈
• 各类文件职责说明
• 需求当前所处阶段
• 已确认的规格与契约
• 模块修改前必须读取的前置条件
• 完成后需要运行的验证步骤
• 历史决策及其失效情况
• 必须等待人工确认的动作

四类能力模型

The three pillars cannot替代：

• Rules：提供底线，防止 Agent 每次都重新摸索。
• S​kills：提供可重复的做法，提高效率。
• S​cripts/Hooks：

二、仓库要同时保存事实、过程、状态和经验

AGENTS.md 是索引，不是百科全书

Pain point 三：KPI 文档膨胀导致冷启动信息噪声。

AGENTS.md 应优先回答冷启动时最实际的问题：

• 运行环境、技术栈与开发工具概览；
• 项目地图及文件职责；其实，
• 模块修改前必读的规格与依赖；怎么说呢，
• Coding / Testing / Acceptance 命令；

A high‑frequency red‑line index,not a megabyte‑size encyclopedia.

过程文档与长期事实必须分开

• /workflow/  — 本轮需求讨论记录。
• /specs/  — 长期有效的 API、数据库及验收标准。
• /tasks/  — 从规格拆分出的当前执行单元。
• /memory/  — 跨需求仍有价值的决策与架构记录。

Pain point 四：KPI 与过期方案混杂，使 Agent 把旧方案误当现行事实。

决策记录需要废止机制

`memory/decisions.md` 可记录简单决定；关键架构选择写入 `memory/adr/`。但"新决定覆盖旧决定" 必须显式标注覆盖关系。否则仓库会出现冲突有效决策，导致冷启动随机选取。

状态应有唯一机器来源

需求讨论 → 方案选择 → 实现就绪 → 开发 → 验收 → 提交

This linear state machine is minimal example. For parallel or conditional flows,extend it into a task graph where dependencies,triggers。rollbacks and approvals are explicit relationships.

最小可用 AI 原生仓库骨架示例

my-project/
├── AGENTS.md # 项目总览 & 门禁索引
├── workflow-state.json # 当前阶段唯一机器状态源
├── workflow/ # 本轮需求 & 决策过程
├── specs/ # 长期契约 & 验收标准
├── tasks/ # 当前可执行任务
├── memory/
│ ├── decisions.md
│ └── adr/
├── rules/ # 按测试、安全等主题分片
├── .agents/
│ ├── skills/
│ ├── hooks/
│ └── mcp.json
├── frontend/
├── backend/
├── tests/ # 契约 / 集成 / E2E 验证
└── scripts/ # 状态检查 & 统一入口

Pain point 五："目录多即好" 的误区掩盖了主要需求——新会话只读仓库就能回答“现在进行到哪，为什么这么做，接下来该干什么”。目录深浅不关键，信息完整度才是关键。

三、把设计和需求做成可执行事实

A UI‑centric product should start from an **executable prototype** rar than raw code.

• HTML — 页面结构与交互关系；
• C​SS — 色彩、字号、间距规范；A I 生成代码的速度已经超过了人阅读代码的速度。

  # 痛点一：开发者仍在用“逐行看懂全部实现”来控制质量，却根本跟不上 Agent 的产出节奏。

  、当前走到哪一步、哪些决定已经确认还有可以做什么。如果这些信息只存在于对话或人的记忆里模型越快，跑偏也越快。

  说到主要思路。上下文闭环 + 执行闭环

  • 上下文闭环： 把规则、规格、状态和历史决策写进仓库，让冷启动的 Agent 能恢复工作上下文。
  • 执行闭环： 把需求做成可执行事实把功能拆成可运行的小版本，再通过真实反馈、阶段门禁和回滚机制控制风险。
  # 痛点二：缺少持久化操作环境和长期记忆，让 Agent 在每次调用时都要重新“猜”上下文。
  每次调用都假设它需要从当前可见材料重新理解任务。不过，