AI Native Builder 练习册与检查清单
练习册把正文中的判断转成可以保存和复核的项目材料。它不是另一套课程，也不是填表竞赛。每张表开始前先读对应章节；如果不知道为什么要填某一项，回正文找案例和边界，不要凭空补齐。
每项练习都包含四部分：使用时机、空白模板、澄川示例和完成判断。澄川工业是取材于内部实践的原创复合案例，示例只展示填写方法，不能作为你的项目证据。
使用前先确定证据环境
在首页写明项目使用哪一种证据环境。环境只描述材料来自哪里，不评价你做得好不好。
| 环境 | 作品集最多可以说明什么 |
|---|---|
| 课堂模拟 | 理解概念并完成指定练习 |
| 高保真、原创或脱敏案例 | 能在限定条件下使用完整方法 |
| 真实影子运行，不改变业务状态 | 看见真实任务、运行和失败分布 |
| 真实受控试点 | 讨论真实采用、风险、负担和阶段结果 |
| 第二团队真实复用 | 讨论跨团队适配、维护和组织复用 |
不要在练习册公开副本中保存客户名称、个人信息、凭证、完整日志或未授权业务数据。敏感证据可以写成脱敏摘要，并记录受控原件由谁、在哪里、按什么权限复核。
章节、练习与决定
| 学习阶段 | 对应章节 | 使用模板 | 阶段决定 |
|---|---|---|---|
| 项目准入 | 第 0 章 | 学习契约 | 当前条件是否适合开始 |
| 问题发现 | 第 5 章 | 场景机会池、证据日志、问题一页纸 | 问题是否值得进入流程设计 |
| 流程重构 | 第 6 章 | 现状流程、目标流程、五分钟原型 | 目标流程是否值得建设 |
| 业务约束 | 第 6A 章 | SOP 到智能体约束转化卡 | 不新增阶段决定；检查第 6 章决定是否已写成可评审约束 |
| 系统建设 | 第 7 章 | 上下文地图、业务对象卡、工具契约、运行轨迹 | 接口与边界是否可以评估 |
| 评估治理 | 第 8 章 | 评估样本、治理与事件演练 | 是否具备有限试点条件 |
| 试点采用 | 第 9 章 | 试点计划、试点结果 | 扩大、缩小、迭代、暂停或终止 |
| 产品与复用 | 第 10 章 | 产品责任与资产登记 | 产品、资产、平台候选或退役 |
| 毕业项目 | 第 11 章 | 毕业证据与贡献披露 | 作品集自评与同行复核 |
学习契约
**使用时机：**开始读书、选择项目或更换项目时。先限定环境和责任，避免学到后面才发现没有数据权限、业务负责人或可验证任务。
| 字段 | 填写 |
|---|---|
| 学习者或团队 | |
| 项目名称与一句话任务 | |
| 证据环境 | 课堂模拟 / 高保真案例 / 真实影子运行 / 真实受控试点 / 第二团队真实复用 |
| 每周投入与预计周期 | |
| 可使用的数据和系统 | |
| 禁止使用的数据和动作 | |
| 业务负责人 | |
| 数据、安全或风险联系人 | |
| 暂停条件 | |
| 计划完成到哪一步 |
澄川示例
项目使用原创案例公司、模拟会议和沙盒 CRM，证据环境属于高保真案例。允许生成四个内部字段的更新预览；禁止真实客户信息、正式 CRM 写入、价格承诺和外部消息。目标是完成全流程教学评审，但不能声称完成真实试点。
**是否开始：**进入 / 有条件进入 / 换题 / 暂停。记录日期、参与者、支持决定的材料、尚未满足的条件和下一负责人。
**完成判断：**另一位读者能够从这一页知道项目在哪里运行、允许做什么、谁负责业务和风险，以及最终不能声称什么。
能力前测
开始前为下面八类能力打 0—2 分：0 表示从未做过，1 表示在指导下完成过，2 表示能够独立完成并出示证据。分数必须附证据；前测只用来安排时间，不兑换作品集结论。结业时改用文末五维能力画像的 0—4 分量表。
| 能力 | 0—2 分 | 当前证据 | 本轮准备补什么 |
|---|---|---|---|
| 问题发现与证据分类 | |||
| 工作流重构与人机分工 | |||
| 业务约束与 SOP 转化 | |||
| 系统契约、工具与状态 | |||
| 评估设计与失败分析 | |||
| 治理、权限与停止恢复 | |||
| 试点、采用与净价值 | |||
| 复用、退役与诚实披露 |
澄川示例
学习者在“问题发现与证据分类”上记 1 分：写过访谈提纲，但还没有把事实、判断、假设分开的证据日志。“系统契约、工具与状态”记 0 分，本轮把时间优先放在工具契约和未知状态，而不是先做平台化。
**完成判断：**八行都有分数；得 1 或 2 分的行能指出一份材料；得 0 分的行写明本轮是否补、补到哪一步。
场景机会池
**使用时机：**有人提出“做一个 Agent”“接入大模型”或你正在比较多个候选场景时。先比较问题，不先比较模型。
| 场景 | 用户与触发 | 可观察影响 | 频率 | 当前证据 | 数据与权限 | 可试点性 | 风险 | 负责人 | 初步决定 |
|---|---|---|---|---|---|---|---|---|---|
澄川示例
“销售会后更新 CRM”的用户是大客户销售，触发点是客户会议结束。已观察到资料查找、字段确认和重复录入，但还不知道哪一步占用时间最多。第一轮决定是继续取样，不直接批准建设 Agent。
反 AI 检查
- [ ] 删除这个步骤能否解决问题？
- [ ] 标准化输入或明确责任能否解决？
- [ ] 普通搜索、规则、表单或系统集成能否解决？
- [ ] 问题是否主要来自权限、激励、资源或管理？
- [ ] 即使模型输出正确，用户是否仍会被等待、审批或跨系统操作卡住？
**完成判断：**至少比较两个候选场景；每个场景都有用户、触发、影响和证据缺口；没有因为“AI 感强”就优先。
证据日志
**使用时机：**从第一次访谈或观察开始持续更新。事实、判断、假设、决定和缺口要分开记录。
| ID | 日期 | 类型 | 内容 | 来源或链接 | 可信度 | 支持或反驳什么 | 待验证 |
|---|---|---|---|---|---|---|---|
| E-001 | 事实 / 判断 / 假设 / 决定 / 缺口 | 高 / 中 / 低 |
澄川示例
E-007｜事实｜4 名销售在 8 次观察中都先找产品资料，再更新 CRM｜屏幕观察记录｜中｜支持“资料查找属于现状流程”｜仍需确认更多销售是否相同。
“销售都讨厌 CRM”不能写成事实；如果只来自经理判断，应标为判断并继续核对。
**完成判断：**关键结论至少能回到一条来源；反驳证据和缺口没有被删掉；可信度说明基于来源和取样限制。
问题一页纸与是否继续的决定
**使用时机：**机会池出现一个较强候选后。它负责把问题交给下一阶段，不负责描述解决方案的全部功能。
角色与触发
- 用户：
- 触发事件：
- 用户当时要完成的任务：
问题与证据
- 可观察问题：
- 当前基线：
- 证据来源、时间窗口和样本：
- 可能的替代解释：
- 仍缺什么证据：
目标与边界
- 期望业务结果：
- 第一轮要验证的假设：
- 不做什么：
- 风险与停止条件：
- 业务负责人：
澄川示例
问题不是“销售不会写纪要”，而是会后需要在会议内容、产品资料和 CRM 之间反复核对，造成等待与返工。当前 4 名销售、8 次观察只能支持这一流程问题，不能支持“效率下降 30%”。第一轮只验证四个内部字段的建议是否减少查找和重复录入。
**问题是否值得进入流程设计：**继续 / 有条件继续 / 返工 / 暂停 / 终止。写明决定日期、证据版本、条件和下一负责人。
**完成判断：**删掉“AI”“Agent”和产品名后，这一页仍能说明一个值得处理的问题；目标可以观察，边界可以检查。
现状流程记录
**使用时机：**问题被确认值得进入流程设计后。按一次真实任务记录发生过的步骤，不按制度文件或管理者想象补齐。
| # | 触发或输入 | 实际角色 | 动作 | 系统 | 输出或状态 | 操作时间 | 等待 | 返工或例外 | 证据 |
|---|---|---|---|---|---|---|---|---|---|
| 1 |
澄川示例
一次任务中，销售先整理会议记录，再等待产品经理确认资料版本，最后进入 CRM 更新字段。等待时间与操作时间分开记录；“边开会边记笔记”不能整段计为 CRM 任务耗时。
**完成判断：**至少记录一条从触发到结束的任务；等待、返工、例外和系统切换没有被省略；每项时间的计算范围可以解释。
目标流程与责任矩阵
**使用时机：**已经理解现状流程后。先决定删除、标准化和确定性自动化，再决定模型介入的位置。
| # | 目标步骤 | 人的判断 | AI 的判断 | 确定性系统执行 | 需要记录 | 最终责任 | 异常处理 | 回退方式 |
|---|---|---|---|---|---|---|---|---|
| 1 |
逐动作决定 AI 可以做什么
| 动作 | AI 只建议 / AI 准备结果 / 人批准后执行 / 满足条件时执行 / 在明确边界内自主执行 | 选择理由 | 扩大权限前要满足什么 |
|---|---|---|---|
澄川示例
“识别需要更新的 CRM 字段”由 AI 提供建议，“准备四字段变更预览”由 AI 生成待确认结果。销售确认后，由确定性工具写入；AI 没有正式 CRM 写入权限。价格、成交日期和外部消息不在范围内。
**完成判断：**每个副作用都有责任主体；异常不会默认继续；不同动作可以授予不同权限，没有给整个系统贴一个笼统的“高自主”标签。
五分钟原型与是否建设的决定
**使用时机：**目标流程画出后、正式建设前。原型要暴露判断和失败，不只展示顺利生成。
| 环节 | 要展示的内容 | 证据或素材 | 观察到的反馈 | 设计修改 |
|---|---|---|---|---|
| 问题与现状 | ||||
| 正常路径 | ||||
| 失败或高风险路径 | ||||
| 边界与下一决定 |
反馈可标记为：价值 / 边界 / 信任 / 数据 / 技术 / 采用。保留原话和发生情境，再写项目组判断。
澄川示例
原型先展示一次四字段预览，再故意提供两份冲突的产品资料。系统停止有冲突的字段、保留其他草稿并转给内容负责人。销售反馈“可以接受部分完成，但必须保留自己的修改”，因此目标流程增加了版本冲突时不覆盖人工编辑的规则。
**目标流程是否值得建设：**继续建设 / 有条件继续 / 返工 / 暂停 / 终止。记录被否决的方案和原因。
**完成判断：**原型至少改变了一项设计判断；有一条失败或边界路径；评审者知道哪些动作仍不获批准。
SOP 到智能体约束转化卡
**使用时机：**目标流程获准继续建设之后、开始绘制上下文地图之前。它把目标流程中的触发、输入、判断、人审、异常、输出和责任转换成第 7 章可以继续落实的业务约束。
这张卡使用单独文件保存，避免把版本记录、异常表和系统映射压缩进本练习册。请打开并复制 SOP 到智能体约束转化卡。填写时可对照澄川业务约束版；进入第 7 章后再升级为系统约束版。
**完成判断：**业务约束版已经列出批准建设的最小方案、明确未批准范围、至少一条正常样本和失败样本，并把仍待工程定义的上下文、对象、工具、状态和运行轨迹问题交给第 7 章。
上下文地图
**使用时机：**目标流程获准建设，并且业务约束版完成后。它回答系统可以依赖哪些信息，信息冲突和缺失时怎样处理。
| 来源 | 支持的任务 | 权威等级 | 版本或新鲜度 | 负责人 | 访问权限 | 冲突规则 | 缺失处理 |
|---|---|---|---|---|---|---|---|
澄川示例
已批准产品资料支持“客户需求依据”，内容负责人维护版本。会议转写不能覆盖正式产品政策；两份批准资料冲突时，该字段停止并转人工，不能由模型自行选择更像答案的一份。
**完成判断：**每个来源都有用途、版本、负责人和权限；冲突与缺失拥有明确动作；没有“搜索到就视为事实”的规则。
业务对象卡
**使用时机：**流程中的名词即将变成代码、数据库字段或工具参数时。先统一业务含义，再定义状态和动作。
| 字段 | 填写 |
|---|---|
| 对象名称与业务含义 | |
| 关键属性 | |
| 与其他对象的关系 | |
| 允许状态和转换 | |
| 允许动作 | |
| 角色与权限 | |
| 必须始终成立的不变量 | |
| 来源与负责人 |
澄川示例
CRMChangeSet表示一次待确认的 CRM 字段变更，不是模型的一段自由文本。主路径为draft → ready_for_review → approved → committing → committed；旁路包括blocked、rejected、cancelled和unknown。未知状态不得创建新的业务意图。
**完成判断：**对象拥有业务含义、状态和不变量；同一个词在业务、界面和代码中没有指向三个不同对象。
工具契约
**使用时机：**模型或工作流准备调用 API、数据库、浏览器或业务系统时。每个产生副作用的工具单独填写。
| 字段 | 填写 |
|---|---|
| 工具名称和目的 | |
| 调用者与身份 | |
| 输入 Schema 和校验 | |
| 输出与错误 | |
| 副作用等级 | 只读 / 可逆写入 / 高风险写入 |
| 超时与重试规则 | |
| 幂等键 | |
| 状态查询、补偿或回退 | |
| 人工批准 | |
| 日志与敏感字段处理 |
澄川示例
commit_crm_update只接受已经批准的CRMChangeSet，字段白名单为四项，使用一次性业务幂等键。写入超时后先进入未知状态并查询原请求结果，不生成新键重试。价格和商机阶段即使出现在模型输出中，也会被工具拒绝。
**完成判断：**提示词失效时，工具本身仍能阻止越权字段和未批准动作；写入超时不会自动制造重复副作用。
运行轨迹与是否进入系统评估的决定
**使用时机：**最小方案能够运行后。至少保存一条正常运行和一条异常运行。
| 字段 | 记录 |
|---|---|
| run_id、时间、环境和用户角色 | |
| 任务与输入版本 | |
| 上下文来源与版本 | |
| 模型与指令版本 | |
| 工具调用和参数摘要 | |
| 状态转换 | |
| 人审决定 | |
| 错误、重试与恢复 | |
| 最终输出 | |
| 最终环境状态 | |
| 耗时与成本 |
澄川示例
正常运行
RUN-CC-007从会议证据走到沙盒 CRM 状态。异常运行RUN-CC-008在提交超时后进入未知状态，通过原幂等键查询并完成协调。轨迹只保留必要摘要，不保存完整敏感会议内容。
**接口与边界是否可以进入系统评估：**进入系统评估 / 有条件进入 / 返工 / 暂停 / 终止。
**完成判断：**评审者可以核对外部状态，而不只相信模型回答；异常运行留下了停止和恢复证据；日志遵守最小数据原则。
评估样本
**使用时机：**接口与边界通过运行检查后。先写预期、允许路径和禁止动作，再运行当前版本。
| ID | 类型 | 输入与初始状态 | 预期结果 | 允许路径 | 禁止动作 | 评分器 | 通过条件 | 实际结果 | 失败分类 |
|---|---|---|---|---|---|---|---|---|---|
| T-001 | 正常 / 边界 / 失败 / 对抗 / 回归 | 规则 / 模型 / 人工 / 环境 |
澄川示例
T-018 模拟提交响应与状态查询同时超时。预期是保持原变更单和幂等键、停止新提交并转人工；若系统生成新键或创建第二个任务，必须停止试点准备并修复重复副作用问题。
**完成判断：**样本覆盖正常、边界、工具失败、权限或对抗和历史回归；结果、轨迹、环境与治理分别有人检查；高风险失败没有被平均分隐藏。
治理、事件演练与是否开始试点的决定
**使用时机：**准备进入任何真实或高保真试点前。把数据、权限、人审、停止和事件响应放进运行路径。
数据与权限
- [ ] 数据来源、用途、授权、保留和删除规则明确；
- [ ] 系统只取完成任务所需的最小数据；
- [ ] 权限限制到用户、工具、对象、字段和环境；
- [ ] 测试与正式凭证分离；
- [ ] 日志不会保存无关敏感内容。
动作与人审
- [ ] 只读、可逆写入和高风险写入已经分级；
- [ ] 人审的触发条件、角色、依据和时限明确；
- [ ] 高风险动作不能绕过批准；
- [ ] 系统可以停止、转人工、查询状态或执行受控补偿。
事件卡
| 字段 | 填写 |
|---|---|
| 事件触发与发现方式 | |
| 严重度和判断人 | |
| 立即停止或隔离动作 | |
| 通知对象与时限 | |
| 需要保留的证据 | |
| 外部状态核对 | |
| 恢复条件 | |
| 原因、修复与回归样本 | |
| 重新发布条件 |
澄川示例
事件演练假设系统疑似写入禁止字段。项目组先撤销写入身份、冻结在途变更，再核对 CRM 审计记录和运行轨迹。只有确认影响范围、完成修复并让回归样本通过后，才允许重新评审。
**当前系统是否可以进入有限试点：**允许有限试点 / 有条件允许 / 返工 / 暂停 / 终止。写明用户、任务、字段、环境、支持和停止条件。
**完成判断：**越权、敏感信息泄露、重复副作用或不可停止路径会阻止试点；“有人会处理”已经换成具体负责人和动作。
试点计划
**使用时机：**当前系统具备有限试点条件后。先写试点要支持的下一项决定，再确定人数、周期和任务数。数字来自场景，不照抄澄川案例。
| 字段 | 填写 |
|---|---|
| 试点要支持的决定 | |
| 模式 | 影子 / 辅助 / 受控真实运行 |
| 用户和角色 | |
| 符合范围的真实任务 | |
| 数据、环境和动作边界 | |
| 周期与最低任务数 | |
| 系统版本 | |
| 人审与支持安排 | |
| 使用指标 | |
| 质量指标 | |
| 业务指标 | |
| 风险、负担和成本指标 | |
| 停止条件 | |
| 决策日期与负责人 |
澄川示例
教学案例选择四名已授权销售和十个工作日，因为它足以展示当前采用问题，不是行业标准。试点只覆盖已有商机和四个内部字段；任何未授权写入、重复副作用或敏感信息泄露都会立即停止。
**完成判断：**用户、任务、环境、动作和系统版本明确；使用指标来自业务任务，不来自登录次数；试点到期必须重新作决定。
试点结果与后续决定
**使用时机：**试点结束或触发停止条件时。所有符合范围的任务都进入分母，包括未启动、放弃、失败和绕开的任务。
| 证据组 | 基线 | 试点结果 | 限制或混杂 | 判断 |
|---|---|---|---|---|
| 使用 | ||||
| 质量 | ||||
| 业务 | ||||
| 风险 | ||||
| 人工负担 | ||||
| 成本 | ||||
| 用户原话 |
澄川示例
24 个符合范围任务中，21 个启动、18 个看到预览、14 个确认写入，只有两名销售形成较稳定的重复使用。完成任务局部提速，但加入放弃、支持和修复后净人工收益仍为负，因此不能写“效率提升 30%”。
**试点之后怎样继续：**扩大 / 迭代 / 缩小 / 继续影子 / 暂停 / 终止。
- 决定及日期：
- 支持决定的证据：
- 成立范围：
- 尚未成立的部分：
- 下一负责人和到期条件：
**完成判断：**访谈覆盖稳定使用者、放弃者和绕开者；质量、业务和风险没有混成一个分数；决定带条件、负责人和复评日期。
产品责任、资产登记与长期去向
**使用时机：**试点结果已经说明项目怎样继续，或者项目准备结束时。判断未来是否值得承担支持、维护、复用和退役责任。
产品责任
| 项目 | 填写 |
|---|---|
| 产品用户与任务 | |
| 当前服务范围 | |
| 服务时段与支持方式 | |
| 业务、技术、数据和风险负责人 | |
| 版本与发布方式 | |
| 运行与采用指标 | |
| 维护成本 | |
| 退役触发和迁移方式 |
资产登记
| 资产 | 适用与不适用 | 输入输出 | 依赖和权限 | 版本 | 负责人 | 评估 | 退役条件 |
|---|---|---|---|---|---|---|---|
第二团队复用记录
| 项目 | 记录 |
|---|---|
| 团队与场景 | |
| 未获原作者帮助前完成了什么 | |
| 卡点与失败 | |
| 原作者介入时长 | |
| 相对从零建设节省 | |
| 需要抽象、删除或分叉的部分 | |
| 技术资产是否通过复用检查 | |
| 新场景是否已经得到业务证据 |
澄川示例
第二团队第一次运行遇到五个未说明依赖，原作者介入 160 分钟，复用检查不通过。补充适用范围、依赖、字段语义和最小测试数据后，第二次介入降到 50 分钟；六条共享机制样本通过，两条渠道政策样本因缺少批准来源而正确阻塞。技术核心可迁移，不表示渠道场景已经采用。
**哪些内容值得长期维护和复用：**一次性交付 / 团队产品 / 共享资产 / 平台候选 / 退役，可同时对不同部分作分流。
**完成判断：**第二团队在受限帮助下完成了真实或高保真复用测试；复用结果区分技术机制和本地业务语义；平台化决定有多个独立需求和维护成本证据。
毕业证据、贡献披露与同行复核
**使用时机：**整理毕业项目或准备公开作品集时。先限定真实性，再写主张；不要先决定自己想获得哪一种自评结论，再寻找支持材料。
项目真实性与候选状态
- 项目环境：课堂模拟 / 高保真案例 / 真实影子运行 / 真实受控试点 / 第二团队真实复用
- 可以支持的最高主张：
- 当前自评候选：未形成 / 高保真实践候选 / 真实项目建设候选
- 不能声称的内容：
主张—证据—限制
| 能力主张 | 证据名称、日期和版本 | 项目环境 | 本人角色 | 限制与替代解释 | 复核方式 |
|---|---|---|---|---|---|
澄川示例
可以写：“在高保真案例中完成受控工作流、异常恢复和评估设计。”不能写：“构建了生产级销售 Agent 并证明企业效率提升 30%。”案例中的第二团队复用记录仍是教学材料，不能声称完成真实的跨团队复用。
本人、团队与 AI 的贡献
| 工作 | 本人完成 | 团队完成 | AI 协助 | 人工怎样验证 | 证据 |
|---|---|---|---|---|---|
| 问题发现 | |||||
| 流程设计 | |||||
| 系统实现 | |||||
| 评估治理 | |||||
| 试点与资产 |
必须通过的检查
- [ ] 没有伪造、冒领或升级证据环境；
- [ ] 没有公开未授权数据、日志、合同或客户资料；
- [ ] 高风险动作没有绕过权限、人审和停止控制；
- [ ] 评估版本、样本和环境结果可以复查；
- [ ] 至少有一条失败运行和恢复证据；
- [ ] 本人、团队和 AI 的贡献可以区分。
任何一项不通过，都先修复或降级主张，不进入总分讨论。
五维能力画像
| 维度 | 0—4 分 | 支持证据 | 当前缺口 | 下一项责任 |
|---|---|---|---|---|
| 问题与业务证据 | ||||
| 工作流与系统 | ||||
| 评估与治理 | ||||
| 试点与决定 | ||||
| 复用与贡献 |
0 分表示缺失、错误或不可接受风险；2 分表示在指导下完成并可复查；3 分表示能够独立取舍；4 分要求处理复杂例外并帮助他人复用。总分只用来找短板，不能自动换成候选状态。
同行复核记录
| 项目 | 记录 |
|---|---|
| 评审者、日期和关系 | |
| 检查的材料与版本 | |
| 未检查或无资格判断的部分 | |
| 最强证据 | |
| 最严重的失败或缺口 | |
| 不同意的主张或分数 | |
| 要求修改的内容 | |
| 修改后的决定 |
**完成判断：**随机选择一条主张，可以定位到证据、版本、环境、本人贡献和限制；同行复核记录了分歧，不只留下一个分数或“专家认可”。
一份可以提交的练习册
最终提交不要求每个空格都有文字。与项目无关的字段可以标记“不适用”，并说明原因。项目在任何阶段停止都可以成为合格作品，只要停止决定有证据、责任和后续处理。
提交前，沿着项目已经走过的阶段依次检查：输入是否真实、判断是否有来源、系统是否能运行和失败、下一步决定是否诚实。随后整理毕业主张、贡献和限制。