AI时代下，历史项目如何共享上下文？

背景

AI工具繁多，历史项目存在业务多、维护人多。业务背景、接口、页面入口和已知问题不能只留在聊天记录里。得产出一套规范流程，让AI的上下文在不同的人和模型直接丝滑切换而不产生幻觉。

目录结构

text 复制代码

根目录
├── AGENTS.md
└── .ai/
    ├── project-rules.md
    ├── project-summary.md
    ├── context-template.md
    └── business-index.md

业务目录
└── src/views/某个业务/
    ├── context.md
    ├── spec.md
    └── requirements/

名称	用途
`AGENTS.md`	唯一的 AI 规则入口。Codex 会自动读取。
`.ai/project-rules.md`	项目代码规范和技术约束。
`.ai/project-summary.md`	公共组件、公共方法、构建、分包和全局基础能力摘要。
`.ai/business-index.md`	业务根目录、入口和业务文档路径。
`.ai/context-template.md`	新建业务 `context.md` 的固定格式。
`context.md`	一个业务的长期共享上下文。
`spec.md`	当前进行中任务的目标、范围和状态。
`requirements/`	该业务的需求文档、图片、UI 稿等资料。

怎么做？

AI 处理业务前，按顺序读：

AGENTS.md
.ai/project-rules.md
.ai/project-summary.md
.ai/business-index.md
当前业务的 context.md 和 spec.md

业务目录没有 context.md 时，先按 .ai/context-template.md 创建 UTF-8 Markdown 格式的 context.md。模板中的所有一级章节必须保留；已知信息先写入，未确认信息标记为"待定位"，完成必要代码阅读后再补齐。开始新任务时更新 spec.md；任务完成后将稳定结论写入 context.md。

每次涉及业务的对话结束前，更新两处：

当前业务的业务文档。
如果本次涉及项目级架构变化，再更新 .ai/project-summary.md。

业务新增、入口变化或业务文档路径变化时，再更新 .ai/business-index.md。

同一业务再次维护时，直接合并到已有维护记录，保留最新结论、影响文件和验证结果，不重复新增相同业务条目。完整改动历史由 Git 保存。

收到需求或 UI 文件时

在业务根目录创建 requirements/。文件可访问且同事确认后，再复制进去；不要擅自移动或删除原文件。

业务文档中记录资料名称、来源、用途和路径。资料暂时没有时，放一个 requirements/README.md，保证目录能被 Git 跟踪。

业务完成并验证后，AI 要问：

是否把本次需求、图片、UI 稿等资料归档到 requirements/，并将代码、业务文档、.ai/project-summary.md、.ai/business-index.md 和资料一起提交 Git？

未确认时，不自动提交。

提示词建议

text 复制代码

请先按 AGENTS.md 阅读项目规则、.ai/project-summary.md、.ai/business-index.md 和当前业务文档，再处理需求。
开始任务时更新 spec.md；完成后合并更新 context.md。涉及公共能力时更新 project-summary.md；有需求或 UI 文件时，问我是否归档到 requirements 并提交 Git。