项目执行交接

生成基于项目证据、可独立接手、可执行和可验收的交接文档。只有“生成执行交接文档”一个入口：接受新目标或已有文档，审查是交付前的必经步骤，不单设模式。

工作边界

• 默认只调查项目和编写文档，不顺带修改业务代码、安装工具、修改运行配置或操作真实业务数据。用户另有明确指令时按授权范围执行。
• 沿用项目文档布局、备份规则和现有成果；已有文档优先修订，不新增相互矛盾的事实来源。
• 交接文档应能脱离历史聊天使用。记录必要背景与已确认约束，不复制对话流水账。
• 根据任务复杂度控制篇幅。小任务简写，复杂任务再补接口、状态、恢复等细节；不强制每个项目采用相同技术方案。

生成流程

1. 调查项目基线

读取适用项目规则、已有需求/方案、工作区变更和与任务相关的源码、测试及构建入口。无需遍历无关模块。

• 核对仓库与运行环境；已有改动可能不在 HEAD 中，不能只记录提交号。
• 通过文件和关键符号定位代码，行号仅作辅助；命令来自实际依赖清单、脚本或 CI。
• 区分“已确认事实”“待验证假设”“拟新增内容”，记录必要证据及核对时间。
• 无法访问源码时说明限制，不编造文件、接口或命令。将必要调查列为任务，并指出受其阻塞的实施任务。

2. 明确目标与边界

将用户意图转成可观察的结果，明确本次范围、非目标、权限和必须保持的行为。

优先从项目证据和已有约定解决问题。只有未决问题会影响目标、关键方案、数据安全或验收时才询问用户；不因普通实现细节反复确认。非阻断假设明确标注。

3. 确定关键方案和修改职责

先确定接手者不应猜测的决策：相关接口、数据或状态变化、兼容策略、操作边界及失败行为；只为实际涉及的项目展开。

• 文件范围说明每个文件或模块需要承担的修改职责，不只列路径。
• 明确哪些是固定约束，哪些普通实现细节可由执行者判断。
• 尚未解决的关键设计先安排调查或验证任务，不包装成“直接实现”步骤。
• 涉及迁移、删除、共享数据或配置时，说明操作范围、恢复方法和验证条件；不向普通低风险修改套用无关流程。

4. 拆分任务并关联验收

使用 交接模板 生成文档，按依赖顺序组织任务。

• 每个任务解决一个明确问题，可独立审查和验证；不机械限制代码行数或文件数量。
• 为目标、任务和验收设置稳定编号，如 G-01、T01、AC-01，修订时保留原编号。
• 每项任务包含前置条件、涉及位置、具体动作、验证方法及执行记录。跨层行为需要多文件配合时，保持任务完整。
• 验证说明运行目录、必要环境、命令或人工操作及预期结果。未经执行的命令标明待执行；人工或平台验证缺少条件时说明限制。
• 全局约束、文件职责和总体验收各只写一次，任务用编号或章节引用；局部检查只补充本任务特有内容。
• 不默认委派子代理、自动提交 Git 或开展 GUI 操作；执行方式受当前授权和项目规则约束。

5. 交付前自检并修订

对生成文档完成以下检查，发现问题先修订，不把审查作为用户必须另行选择的操作：

1. 事实可靠：引用的文件、符号和命令有依据；拟新增内容与现有事实没有混淆。
2. 步骤可执行：输入、依赖和预期行为明确；没有“完善逻辑”等缺少具体结果的关键步骤。
3. 目标可验收：每个目标都有任务承接与验收依据；测试与实际风险相称，不要求无意义测试。
4. 范围一致：方案、文件范围、任务、风险与交付没有矛盾或无关扩张，重复内容已合并。

核对本地文档链接及编号。不能声称自检证明实现正确，更不能将预期结果写成已运行通过。

6. 交付接手入口

保存到用户指定位置或项目现有文档类别。没有文件写入授权时直接返回文档内容。

最终说明文档位置、适用基线、建议开始的任务及关键未决事项；简述实际完成的文档检查。交接文档包含必读资料和接手起点，执行者无需从聊天中寻找授权或设计决策。

修订与执行记录规则

• 输入已有文档时，先核对代码与执行记录，再修改受影响部分。按项目规则备份，保留仍然有效的决策和证据。
• 历史验证注明对应版本或条件；环境或代码变化后不能自动当作当前通过。
• 新任务默认“未开始”；状态使用“未开始 / 进行中 / 已实现待验证 / 验证通过 / 阻塞”。已有状态仅在证据支持时保留。
• 执行者记录真实变更、验证结果、证据位置及下一步。写完代码不等于验收通过，跳过不等于通过。
• 普通实现细节允许自主调整；若必须改变目标、接口契约、数据安全边界或扩大修改范围，记录差异并交回规划者处理。没有证据时不得弱化验收来宣布完成。
• 方案修订只说明影响理解的变更原因，不积累冗长历史，不擅自覆盖已验证成果或其他人的工作。

参考原则

以下是本工作流的参考实践，不代表任何公司的统一交接标准，也不保证不同能力模型的实现质量相同。用户只要求生成文档时，不必每次联网重查这些原则；具体 API、版本或其他不确定事实应按任务需要核实。

• GitHub Spec Kit：需求、技术计划、任务与实施相互对应。
• Google 工程实践：小而完整、便于审查的变更。
• Anthropic 长任务实践：增量推进、真实验证和可恢复上下文的进度记录。