这套提示词的核心目的，是把一次性的 agent 编程过程，逐步沉淀成一种近似 harness 编程的项目协作方式。
需要这么做的根本原因是：大模型本身是无状态的。Codex 在一个上下文窗口里可以理解项目、推理链路、排查问题、形成判断；但这个上下文一结束，很多理解就会消失。换一个线程、换一个 agent，甚至隔一段时间重新进入同一个项目，如果没有外部化的项目上下文，就必须重新扫描、重新猜测、重新踩坑。
但它也有明显局限：这还不是完整的自动化 harness。它解决得比较好的是工作环境和上下文持久化，但反馈回路仍然依赖大模型本身执行：输入如何拆解、检查是否充分、问题是否问得对、验证结果如何解释，仍然需要模型消耗推理和上下文成本来完成。也就是说，它把“记忆”和“项目地图”从模型里搬到了仓库里，但还没有完全把判断、测试和反馈自动化。 因此，这套提示词更准确地说，是从 agent 编程走向 harness 编程的中间形态：先让项目具备可被 agent 反复读取、修正和增强的上下文骨架，再逐步把其中稳定的检查、验证和部署步骤自动化。
请为当前项目建立一套面向 Codex / LLM 的项目上下文 Wiki，目标是让新的 agent 在不依赖历史聊天记录的情况下，能够快速理解项目结构、运行方式、关键约束、跨模块关系、常见故障、验证方法，以及当前仍然缺失或需要澄清的信息。
请先读取当前仓库文件结构，再按下面格式创建或更新 Markdown 文档。不要编造未知事实；不确定的信息写成“待确认”，并说明需要用什么命令、文件、人员或外部系统确认。
推荐文件结构：
- README.md
作为项目上下文入口，说明：
- 项目是什么
- 项目为什么存在
- 当前目标
- 成功标准
- 失败标准
- 主要服务对象或使用者
- 文档目录说明
- 推荐阅读顺序
- AGENTS.md
作为 Codex 的持久入口说明，保持简短，说明：
- 先读哪些上下文文件
- 修改代码或配置前必须确认哪些约束
- 如何验证工作完成
- 哪些内容不能写入文档，例如密钥、token、密码、私有凭证
- modules/overview.md
列出系统模块索引。每个模块只描述“自己是什么、负责什么、在哪里运行、如何检查、如何重启、有哪些注意点”。
- modules/<module-name>.md
每个文件描述一个模块，建议包含：
- 职责
- 部署位置
- 关键路径
- 配置文件
- 启停命令
- 检查命令
- 日志位置
- 已知问题
- 不属于本模块负责的事情
- relationships/overview.md 或 relationships/access-flow.md
描述跨模块数据流、请求链路、调用关系、依赖关系。重点写清：
- 用户请求如何进入系统
- 数据如何流转
- 哪些模块影响哪些能力
- 如何判断问题发生在哪一层
- relationships/service-registry.md
作为权威清单，只维护当前真实状态，不写长篇事故过程。建议用表格记录：
- 服务名
- 对外入口
- 内部地址
- 运行位置
- 配置文件
- 启停/检查命令
- 日志位置
- 最近验证时间
- 当前认证或安全状态
- constraints/environment.md
记录稳定环境事实和假设，例如：
- 操作系统
- 运行环境
- 网络条件
- 目录约定
- 权限限制
- 不能改变的外部依赖
- 待确认事项
- constraints/operations-runbook.md
写可执行运维手册，包含：
- 新增一个服务或模块的步骤
- 修改配置后的最小验证
- 常用构建、测试、部署、回滚命令
- 分层排查流程
- 安全检查项
- issues/issues.md
作为历史问题索引。这里只放问题列表、状态、影响和结论。
- issues/<issue-name>-YYYY-MM-DD.md
每个历史问题单独成文，建议包含：
- 现象
- 背景
- 当时的错误假设或误解
- 诊断证据
- 处理过程
- 最终结论
- 当前替代方案
- 对现在的影响
- 后续如何避免
- questions.md
记录 Codex / LLM 在理解项目时发现的缺口、矛盾和待澄清问题。
这是持续迭代项目上下文的入口，不是失败产物。
写作规则：
1. 当前真实状态优先于历史记录。
2. 权威表优先于分散模块说明。
3. issue 只记录历史问题，不维护当前端口、当前服务状态或权威配置。
4. 模块文档只解释模块自身，跨模块链路放到 relationships/。
5. 运维命令必须可复制执行；如果命令依赖环境，写明运行位置。
6. 所有验证都要写“预期结果”，不要只写命令。
7. 不要把密码、API key、token、私钥、cookie、UUID、生产凭证写入 Wiki。
8. 不确定内容标记为“待确认”，不要用猜测填充。
9. 如果发现历史 issue 暴露出稳定规则，把规则同步到 modules/、relationships/ 或 constraints/，不要只留在 issue 里。
10. 文档目标是让新的 Codex agent 能根据文档完成修改、运行检查、定位故障并解释判断依据。
理解与疑问处理规则：
1. 默认项目上下文一定存在缺口。不要为了让文档看起来完整而补全未知事实。
2. 发现以下情况时，必须记录为问题：
- 文件存在但用途不明确
- 配置项存在但不知道谁读取
- 服务、脚本、端口、目录、环境变量没有来源说明
- 文档之间存在冲突
- 代码行为和现有文档不一致
- 缺少验证命令
- 缺少运行位置
- 缺少负责人、调用方或依赖方
- 历史问题有结论但没有证据
- 当前状态无法从仓库内确认
3. 问题不要散落在对话里，必须汇总到文档中。
4. 新建或维护 `questions.md`，作为“待澄清问题清单”。
5. 每个问题应包含：
- 问题描述
- 相关文件或模块
- 为什么这个问题重要
- 当前已知线索
- 建议确认方式
- 优先级：High / Medium / Low
- 状态：Open / Answered / Obsolete
6. 如果某个问题被确认，应把结论同步回对应的 `modules/`、`relationships/`、`constraints/` 或 `issues/` 文档，并把 `questions.md` 中的问题状态改为 `Answered`。
7. 如果问题已经不再 relevant，标记为 `Obsolete`，不要直接删除。
请完成以下任务：
1. 扫描当前项目结构。
2. 判断项目中的主要模块、跨模块关系、环境约束、历史问题和待澄清问题。
3. 创建上述目录和 Markdown 文件。
4. 如果已有类似文档，按这个结构重组，保留有效事实。
5. 不要为了完整性编造内容；缺失、冲突、无法确认的信息统一进入 `questions.md`。
6. 最后输出：
- 创建或更新了哪些文件
- 当前已经确认的项目理解
- 当前仍待确认的信息
- 已汇总到 `questions.md` 的问题数量和最高优先级问题
- 建议下一次优先补充的上下文配套的agent.md
# Codex 项目上下文规则
开始处理本项目任务前，优先阅读：
1. `README.md`
2. `modules/overview.md`
3. `relationships/service-registry.md` 或 `relationships/overview.md`
4. `constraints/environment.md`
5. `constraints/operations-runbook.md`
6. `questions.md`
7. 需要排查历史问题时再读 `issues/issues.md`
维护规则：
- 当前真实状态写入 `relationships/service-registry.md`。
- 单个模块说明写入 `modules/`。
- 跨模块链路写入 `relationships/`。
- 环境事实和可执行运维命令写入 `constraints/`。
- 历史故障、误解修正和处理过程写入 `issues/`。
- 理解缺口、文档矛盾、无法确认的信息写入 `questions.md`。
- 不写入密码、token、私钥、cookie、生产密钥或其他敏感凭证。
- 不确定的信息标记为“待确认”，并写明确认方式。
- 当 `questions.md` 中的问题被确认后，必须把结论同步回对应上下文文档。