人机收口
人机收口是一次 AI Coding 任务结束时的交付说明。它不是客套话，而是让维护者能判断“这次改动能不能合并、能不能发布、还有什么风险”的最小证据。
Seed 建议每次任务都用中文优先说明，先给人能决策的信息，再给技术细节。
收口应该回答什么
| 问题 | 说明 |
|---|---|
| 改了什么 | 关键文件、功能、文档或配置变化。 |
| 怎么验证 | 运行了哪些命令，结果是什么。 |
| 有没有风险 | 未覆盖场景、失败命令、人工确认点。 |
| 是否影响发布 | 是否需要构建、部署、打包、公开发布或脱敏。 |
| 是否更新项目事实 | 模块档案、项目记忆、技术地图、待办或项目信号是否变化。 |
推荐格式
text
已完成：
- 增加文章搜索输入和过滤逻辑。
- 更新博客模块档案，补充搜索入口说明。
验证：
- npm run test:run 通过。
- git diff --check 通过。
风险：
- 目前只覆盖标题和摘要，不覆盖正文全文搜索。
发布影响：
- 命中 client，需要重新构建前端。什么时候需要展开
日常小改动可以简洁收口。以下场景需要更完整：
- 检查失败或有 warning。
- 涉及发布、数据库、权限、配置、密钥或公开仓库。
- 涉及跨模块改动。
- 涉及 Task Pack、审计、交接或外部协作者。
- 用户明确要求完整命令、日志摘要或验收证据。
Verification Pack 的关系
收口是一次任务的简短结果。Verification Pack 是可复用、可存档的证据包。
当任务较大时，可以把收口里的验证摘要进一步整理到：
docs/acceptance/docs/delivery/- 任务包的
SESSION_STATE.md - 公开案例的 Verification Pack
常见错误
| 错误 | 修正方式 |
|---|---|
| 只说“已完成” | 必须说明改了什么和怎么验证。 |
| 把失败检查省略 | 失败也要记录，并说明是否阻断。 |
| 不说发布影响 | 命中代码组件时要说明是否需要构建或发布。 |
| 把内部路径写入公开收口 | 公开内容只用仓库相对路径。 |
下一步
阅读 检查与发布 gate，把收口里的验证结果和提交前检查对应起来。