75 lines
6.5 KiB
Markdown
75 lines
6.5 KiB
Markdown
# 协作与交接规范
|
||
|
||
本机制用于同一规划目录跨人员、跨电脑和跨 AI 对话接续。文件保留业务依据与修改历史，不要求共享原聊天，也不依赖某个 AI 产品的长期记忆。规范版本 0.15，2026-10-12。
|
||
|
||
## 信息分别放在哪里
|
||
|
||
| 文件 | 责任 |
|
||
| --- | --- |
|
||
| [README](README.md) | 项目入口、阅读顺序、可复制的启动提示与导航 |
|
||
| [AGENTS.md](AGENTS.md) | AI 讨论规则、范围与每轮保存要求；不保证所有工具会自动加载，需要启动提示明确要求读取 |
|
||
| [08 当前讨论状态](08-当前讨论状态.md) | 当前进度、最新交接、主文档、下一步与后置事项 |
|
||
| 01–06 | 对应领域的完整正文、候选比较与计划素材 |
|
||
| [07 决定记录](07-待确认问题与决策记录.md) | 确认依据、决定编号、建议、未决与被替代关系 |
|
||
| handoffs | 每轮追加交接，说明相对哪个版本改了什么、谁确认了什么、还有什么未完成 |
|
||
|
||
状态不能替代正文，交接不能替代决定。AI 修改文件不是确认来源，建议和已实现也不能混同。新的人类指令有优先级，但应同步保存其改变了什么。
|
||
|
||
## 产品与技术如何配合
|
||
|
||
前三阶段主要由产品经理组织，技术人员可以提前识别可行性问题。阶段 4 是架构与数据边界，阶段 5 是旧业务迁移/切换，并非开始直接编码；阶段 6 是自动交付和运行契约，阶段 7 决定实施范围与验收。
|
||
|
||
开发/运维负责说明方案、能力限制、投入和验证依据，产品负责需求边界、收费/权益、客户体验、风险接受与切换影响。技术设计若改变前三阶段约定，单列“待产品确认的业务变化”，不能直接用候选架构覆盖产品要求。产品也不必替开发决定每个库/队列/部署参数。
|
||
|
||
每轮只记录参与人实际确认的事项及其角色；没有证据的“团队通过”不成立。没有指定技术负责人时记录待明确，不能替用户授予部署或现网操作权限。
|
||
|
||
## 一轮讨论的最小闭环
|
||
|
||
1. 开始：读取 AGENTS、README、08、最新交接及本轮主文档/关联决定，核对实际改动。
|
||
2. 聚焦：说明这一轮只解决什么，不因新上下文重复确认全部前三阶段。
|
||
3. 讨论：用业务例子校验候选，记录约束和优缺点；技术事实需实际检查或可靠资料，不能用现状人工约定代替需求。
|
||
4. 保存：更新正文，07 保存已确认/建议/未决；使用 [交接模板](handoffs/_交接记录模板.md)新增 H 记录，更新 08 和必要导航。
|
||
5. 校验：链接有效、标识唯一、状态与正文对应、旧规则修正、未误把建议升级为决定；记核心文件摘要。
|
||
6. 结束：报告本轮结论、文件位置和下一轮入口。没完成就记录未完成与恢复位置，不推断阶段已结束。
|
||
|
||
目录版本用于说明本次交接包；业务基线可以仍为 0.14，单文件版本只在实际改动时更新。不是每次讨论都要重写所有文档。H 编号追加递增，文件名例如 `H0002-2026-10-13-架构模块边界.md`；模板文件不代表已有新结论。
|
||
|
||
## 交接记录的必需内容
|
||
|
||
- 基于哪个目录版本/业务基线/上一条 H 记录，本轮结果版本和日期；参与人/角色仅填已知信息。
|
||
- 本轮主题、修改文件与具体章节、已确认的决定编号和确认依据。
|
||
- 建议、待补事实、待产品确认的业务变化、未完成工作分别列出。
|
||
- 是否影响阶段/首期范围/已有决定，下一轮主文档和第一项讨论题。
|
||
- 校验结果、未登记改动、冲突处理与正文/导航文件 SHA-256。
|
||
|
||
确认依据可以是一句人类确认摘要；不要求贴整段聊天或上传私有会话。摘要只帮助检测漏传/修改，不能证明内容获确认、取代审查或抵御恶意篡改。交接文件自身与模板不参与自身摘要，避免循环依赖。
|
||
|
||
## 把目录交给同事
|
||
|
||
发送整个目录，包括规范、状态、正文、决定、handoffs。目录内部链接采用相对路径；旧源码与环境路径仅是可选参考，同事没有那些目录时明确缺失，不编造检查结果。正式分享前按实际对象检查内容，避免连同客户私有数据或密钥公开。
|
||
|
||
先约定谁持有当前主副本。简单方式是一人接手期间另一人暂停编辑同一份目录；发送与返回都带 H 记录和版本号。项目文件复制不代表已经创建远端仓库或公开发布。
|
||
|
||
## 同事修改后拿回来
|
||
|
||
1. 保留你的当前副本和同事返回副本；先不要直接覆盖本地新增工作。
|
||
2. 比较对方 H 记录中的来源版本、变更文件与实际文件；检查返回目录是否包含 07/08 与新 H 记录。
|
||
3. 如果本地从发送后没有推进，可以采用完整返回包；如果两边都改了，则按共同基线逐文件合并，不能只根据文件修改时间选择最新版。
|
||
4. 保留明确已确认的业务/技术决定。AI 草案仍作建议；来源不明、跨产品边界或冲突的变化列待确认。
|
||
5. 更新合并后的正文、07/08，并新增“接收/合并交接”。旧 H 记录不覆盖。
|
||
6. 在原聊天或新聊天让 AI 重新读取当前状态和最新交接；原聊天先前记忆只作参考。
|
||
|
||
同事如果只改了正文，尚无交接，仍可以通过实际差异恢复，但必须标记“确认依据不足/未登记改动”，补状态和交接；不要假装所有新增内容都已讨论通过。
|
||
|
||
## 并行与冲突
|
||
|
||
有 Git 时可用分支与提交合并，提高改动可追踪性；当前未建独立仓库，也不自动推送。没有 Git 时用双方副本及共同基线比较，同一文档尽量只由一人编辑。
|
||
|
||
并行须事先划分专题/文件，指定汇总者负责 07/08/README。D/H 编号只能在汇总后确定最终唯一值；撞号时保留原分支来源，分配新编号并修正文内引用，在合并交接注明映射，不能悄悄复用一个编号代表两件事。
|
||
|
||
资料不同步与实质意见冲突分别处理：前者核对/补传文件，后者明确提问。未争议部分可以继续，不要求整轮重新审批。
|
||
|
||
## 新对话能做到什么
|
||
|
||
完整文件、可靠的确认记录和及时更新状态，可以让任何能读文件的 AI 恢复有效上下文；不保证某个 AI 自动遵循规则或永不误读。因此每次启动都要求它先读取并复述进度，必要时核对变更。聊天上下文足够时也照此执行，不能因“我记得”跳过同事的新版本。
|