ai-web-delivery-doc/AGENTS.md

本目录的 AI 讨论与文档协作规则

本文件只约束当前规划目录。它帮助不同人员、不同 AI 和新对话从文件恢复讨论，不授权开发、部署、修改现网或对外发布。当前人类指令优先；遇到新事实应回写文档，而非用旧聊天覆盖文件。

新对话必须先恢复状态

1. 阅读本文件和 README.md。
2. 阅读 08-当前讨论状态.md，定位当前阶段、主文档、最新交接、已确认基线和下一轮入口。
3. 阅读 09-协作与交接规范.md，再阅读状态文档指定的最新交接记录。
4. 阅读当前主文档的相关章节及 07-待确认问题与决策记录.md，按需要读取关联文档。首次接手阶段 4 时，至少了解 01/02/05 与 03 开头的基线，不只阅读架构候选。
5. 核对最新交接的文件清单/摘要和实际文件；检查是否存在未登记改动、冲突或比状态更晚的记录。
6. 用简短回复说明恢复出的进度、已确认前提、未决事项和本轮准备讨论的主题，再开始工作。不能声称已读取未实际读取的文件。

旧对话只作辅助上下文。当前人类补充、已确认决定及对应正文是业务依据，状态文件只是导航；日期最新或 AI 改过文件本身不等于决定已获确认。若正文/决定/状态不一致，先定位差异，保留明确无冲突的结论，修正导航；涉及互相冲突的业务决定时向当前参与人确认，不静默选一个。

讨论边界

• 中文讨论，先完成产品与领域理解，再逐步设计技术。每轮聚焦一至三个相关主题，不因一次上下文容量限制整体项目。
• 首期核心正确、其他从简。后置的试用额度细则、例外月退、克隆和复杂组织授权不得重新当作首期阻塞条件。
• 已确认、建议待评审、待补事实、后续版本分别标记；不把 AI 推荐或本次未回答的问题写成已确认。
• 产品经理负责目标、业务规则、范围和业务验收；开发/运维与产品共同评审架构和迁移。技术确认不能自行改变收费、权限或客户承诺。
• 已有决定可修订，但要记录旧决定、新事实、确认来源、影响和替代关系，保存历史。
• 文档是规划成果。除当前人类明确授权的其他工作外，只修改本目录；不碰旧资产库表、客户资源、现网命名、代码/CI、供应商账户或服务器。
• 引用现状代码只用于分析，旧约束不自动成为目标架构要求。不要把凭据、客户私有数据或真实生产密钥写入交接资料。

每轮必须落盘

1. 更新本轮主文档；同步确实受影响的正文，不为统一版本号改无关文件。
2. 在 07 追加决定/建议或更新问题状态，说明人类确认依据与被替代决定。建议不进入“已确认决定”。
3. 按模板在 handoffs 新增交接记录，记录本轮主题、变更文件、确认/未决、范围影响和下一步；历史交接不覆盖。
4. 更新 08 的当前阶段/主题、最新交接、下一步和待产品/技术确认事项；必要时更新 README 和 00。
5. 检查链接、标识冲突、旧规则残留及状态/正文一致性。对交接涉及的正文和导航文件记录 SHA-256 摘要；交接记录自身和模板不参与自身摘要。
6. 最后向参与人报告保存位置和仍未定案的事项。不能把计划设计误报成已经开发、迁移或上线。

若本轮仅解释概念，没有新结论或文件变化，不必机械制造空交接；若因上下文结束中断，保存“未完成交接”，不要伪装已完成。

可移交与并行修改

• 目录内部 Markdown 链接使用相对路径，主文档不硬编码本机根路径。命令及对话中的真实路径按所在环境要求使用。
• 将整个目录移交，保留状态、规范、决策和交接历史；不要只发当前主文档。
• 无 Git 时同一时刻由一人维护主副本，交接说明发送和返回的版本；拿回目录前保留本地旧副本，按变更清单核对，不直接覆盖未合并工作。
• 有 Git 时通过分支/提交合并，状态/决定编号冲突必须人工核对。没有授权不要创建远端仓库、推送或公开文档。
• 多人同时工作须划分文件/专题；指定汇总者更新 07/08/README。同一主文档并行修改先协调；不得恢复旧版本来抹掉其他人的改动。

详细恢复、返还和冲突规则见 09-协作与交接规范.md。