当内部工具团队需要将 AI 运行调查与人工处理结论关联起来时，可以使用本清单。架构与取舍见从 AI 运行日志到内部评审应用。
这是基于已文档化能力提出的原型方案，不是现成模板，也不代表完整应用已经通过运行实测。
前置条件与版本边界
- 按网关评估清单完成一次合成请求并找到对应日志
- 记录安装版本与实际支持的接口
- 使用合成数据，以及有权访问测试应用的账号
- 明确完成标准：评审者能检查运行、保存关联结论，并重新读到该记录
v0.4.1 README记录了 Data Models、CRUD API、工作流 API、React/TSX blocks 和 MCP。较新的日志结构说明是开发环境结构快照，并非稳定 API 契约，尤其不能假定其中的任务级分组已经存在于 v0.4.1。
1. 确定受支持的读取路径
- 根据合成提示标记和时间找到运行
- 检查可取得的模型、工具和最终输出证据
- 确定能提供所需引用及字段的授权 API 或内置页面
- 记录缺失字段与版本差异
v0.4.1 控制台日志处理代码使用控制台授权。用于模型请求的应用密钥，不等于读取管理日志的权限。
不要直接写入内部日志表，也不要根据表名猜测 API 地址。如果安装版本没有需要的受支持读取接口，先使用人工检查，并明确记录集成缺口。
2. 定义自己的业务记录
为评审流程创建一个小型 Data Model，建议字段如下：
| 字段 | 用途 |
|---|---|
| 应用引用 | 标识所属应用 |
| 运行引用 | 关联原始执行证据 |
| 评审状态 | 待处理、调查中、已解决 |
| 问题分类 | 使用团队自己的调查分类 |
| 评审备注 | 保存人工结论 |
| 时间字段 | 记录创建和最后修改时间 |
这些是建议的业务字段，不是内置日志列。优先保存引用，不要复制整段对话。定义必填值、谁能修改，以及原始运行被保留策略清理后如何处理引用。
3. 构建并验证人工流程
- 生成的 CRUD 操作可以创建并读取评审记录
- React/TSX 列表和详情页显示正确记录
- 修改状态后，重新读取仍能取得保存结果
- 只有有权限的评审者能查看原始证据
- 缺少权限的第二个用户不能取得其他应用的证据
- 对不可用或仍在处理的证据如实标记
把人工评审状态、执行状态和回答质量分开。成功执行的请求仍可能产生差的回答；评审已解决也不会改变原始运行结果。
4. 单独评估 MCP 访问
如果需要 Agent 协助，从文档中的 mcp_list、mcp_get、mcp_call 渐进发现方式开始，核对安装版本实际暴露的能力、认证身份和权限。
- 只暴露 Agent 需要的能力
- 从只读检查开始
- 单独审查写操作，再决定是否启用
- 复杂应用开发时提供项目上下文
MCP 工具和现成应用模板仍在完善，不能把这份清单当作无需代码、无需上下文的应用生成器。
5. 检查数据生命周期与故障边界
为原始证据和评审记录分别确定保留、备份及访问策略。不要在公开 issue 中提交私密提示、凭据和完整日志；仅通过项目 issue提供脱敏复现信息。
持久化运行记录有助于检查，但本身不能证明持久执行、崩溃自动恢复、安全重试或外部副作用恰好执行一次。此类要求必须按安装版本另外验证。
深入人工排查可参考 Token BOM。扩大应用前，保留一份包含通过、失败和未测试项目的简短原型记录。