在开始之前
首先设置操作边界。
- 至少访问三个代表性用户或现实任务示例。
- 一个负责的构建者，能够完成完整的输入到输出路径。
- 一个七次会话实验的固定时间和支出限制。
- 非敏感测试数据和一份不可接受的故障模式书面清单。
逐步
从范围转移到一个已检查的成果。
会话1 — 选择一个用户决策
命名一个用户、一个重复任务、当前的解决方法，以及你的产品应使什么决策或行动变得更简单。写出最小的可观察成功信号，以及使这个想法不值得开发的条件。
- 检查点
- 这个问题可以通过真实例子进行测试，而不需要服务所有人。
- 工件
- 一页问题和停止规则简报
会话2 — 定义一个完整的流程
从输入到有用输出的最小路径，包括空状态、加载状态、错误状态、拒绝状态和重试状态。将必需的工作流程与可以等待的功能分开。确定需要人工审查或批准结果的位置。
- 检查点
- 第一个发布版本有一个端到端的结果，没有孤立的功能列表。
- 工件
- 流程图和接受检查表
会话3 — 准备任务包
收集代表性输入、预期输出结构、证据需求、隐私限制和失败示例。对提示、模型标识符、参数、工具和上下文文件进行版本控制，以便以后解释观察到的行为。
- 检查点
- 构建者可以区分模型故障与任务不明确或上下文缺失。
- 工件
- 版本化任务和评估包
第 4 节 — 选择满足运行需求的精简技术栈
根据流程的约束选择工具、模型访问、存储、托管和分析。优先选择可逆选择和现有基础设施。记录每个组件存在的原因、成本、接收的数据以及何时应替换。
- 检查点
- 每个组件都支持第一个流程，而不是假设的未来平台。
- 工件
- 技术栈决策记录
会话5 — 构建并验证可用路径
实施完整的流程并使用任务包进行测试。根据发布风险的比例检查内容安全、授权、数据处理、超时、模型故障、速率限制、可访问性和移动行为。
- 检查点
- 该路径对每个代表性示例都能产生有用的结果或清晰的安全失败。
- 工件
- 测试版候选和缺陷列表
会话6 — 向有限受众发布
部署一个可追溯的版本，验证公共路径，并邀请最小的有用群体。告诉用户产品能做什么、不能做什么、如何处理他们的数据，以及在哪些地方仍需要人工判断。
- 检查点
- 该发布可以被识别、监控和回滚，而无需猜测。
- 工件
- 发布记录和用户测试脚本
会话7 — 根据观察到的工作做出决定
审查已完成的任务、失败模式、放弃、支持问题、成本和定性反馈。决定是否改进流程、打包以重复使用、运行新实验或停止。保留证据和决策原因。
- 检查点
- 下一步行动遵循观察到的行为和预定义的约束，而不是发布日的热情。
- 工件
- 决策记录和下一步实验
交付成果
保持工作可重复使用和可检查。
- 问题简报和明确的停止规则
- 端到端流程和接受检查表
- 版本化任务和评估包
- 技术栈决策记录
- 已验证的发布候选版本
- 生产发布和用户测试记录
- 基于证据的下一步决策
决策边界
本教程不证明的内容。
- 七个会话限制实验；它们不保证产品与市场匹配、收入或生产级系统。
- 高影响决策需要合格的审查、更强的评估和超出此发布节奏的治理。
- 不要仅仅为了使原型看起来真实而收集个人或机密数据。
- 早期用户兴趣是方向性证据，而不是证明存在更大的市场或可重复的业务的证据。
来源台账
检查当前的主要指导。
- NIST AI 600-1：生成式AI配置文件
针对根据上下文定义范围、控制措施、所有权和评估的风险管理参考。
- Richbay：如何判断AI答案
该审查方法用于区分任务匹配度、证据、不确定性和可用性。
- Richbay：已审核输出比较
一种可重复的版本控制任务方法，捕获输出并发布有限的决策记录。