第 0 章｜如何使用这本书

两个人，同一本书，两种证据

设想两位学习者。

林乔在一家制造企业负责销售数字化。她获得了业务负责人的支持，可以观察真实的客户跟进流程，也能在脱敏环境里查看会议记录和 CRM 示例。只要继续取得数据、系统和试点授权，她有机会把书中的方法用在真实项目中。

陈放正在准备转向企业 AI 产品岗位。他暂时没有客户项目，也不能接触公司的真实数据，只能使用书中的高保真教学案例。他同样可以练习问题定义、流程重构、系统契约和评估设计，但不能声称自己已经推动真实用户采用，或者为企业创造了业务收益。

两个人读的是同一本书，完成的练习也可能很相似。区别不在文档是否漂亮，而在证据来自哪里、谁授权、是否影响过真实任务，以及结论能否由第三方复查。

这就是第 0 章要解决的问题：在没有教师监督的情况下，怎样把阅读变成可以检查的能力，同时不夸大自己的项目经历？

这本书要求你边读边做

AI Native Builder 处理的是现实中的建设问题。许多关键判断无法靠记住术语做出。例如，你需要分辨一线用户说的“麻烦”到底来自信息整理、审批等待、系统权限，还是管理机制；也需要判断一项工作应该使用规则、LLM 工作流、Agent，还是根本不需要 AI。

整本书围绕三个问题展开：业务中哪些问题能用、值得用 AI 解决；怎样把一次有效的 AI 输出变成稳定、可评估的效果；怎样把 AI 应用推进生产环境，让真实团队持续使用。你选择的项目和保存的证据，都应帮助自己回答这三个问题。

这些判断只有放进具体材料里才看得出高下。你需要面对一段不完整的会议记录、一条相互矛盾的政策、一项会修改系统状态的工具，以及一个并不愿意改变工作方式的用户。读懂方法只是起点，把决策过程留下来才是学习证据。

完成本书后，你应该能拿出一条连贯的项目记录：问题是怎么发现的，流程怎么还原出来，方案在哪一步缩小了范围，系统跑起来后在哪里成功、在哪里失败，评估依据什么允许或阻止试点，用户到底有没有持续用下去，最后哪些经验被其他人拿去复用了。

第一条约束：结论必须回到证据

“销售整理会议很花时间”听起来像一个合理问题，但它还不能支持项目立项。谁觉得花时间？是销售本人、经理，还是项目发起人？时间花在整理内容、查资料、等待审批，还是重复录入？高峰期和普通时期是否一样？

Builder 需要把判断拆回可检查的材料。访谈可以说明不同角色怎样理解问题，现场观察能看到实际步骤，任务样本可以暴露输入和例外，系统记录则可能提供频率、时间和状态变化。不同材料回答的问题不同，也会带来不同偏差。

因此，每条重要结论至少要标记它属于什么：

• 事实可以回到具体记录，例如一次任务的开始和结束时间；
• 判断是某个角色对事实的解释，例如经理认为延迟源自销售不重视 CRM；
• 假设尚未被验证，例如自动生成纪要可能减少延迟；
• 决定包含负责人、日期和范围，例如先做影子运行，不开放正式写入；
• 缺口说明当前缺少什么证据，以及它会影响哪个决定。

分类不是为了多做文档。它可以防止一次会议里的观点在传递几轮之后变成“公司已经确认的事实”。

第二条约束：失败也要进入作品集

许多 AI 项目展示的是一条精心挑选的正常路径：输入完整，模型回答流畅，工具调用成功，页面也没有报错。真实工作不会一直这样配合。资料会缺失，来源会冲突，权限会过期，接口会超时，模型也可能在不确定时给出过分肯定的答案。

一条失败记录至少要回答：系统当时收到了什么输入，使用了哪些上下文，做过哪些模型和工具调用，环境状态怎样变化，人是否及时发现，最后如何停止、重试、回退或转交。

保留失败的目的，是证明你理解系统的边界。一个只能展示成功截图的人，很难说明自己是否具备生产判断。一个能解释失败在哪里产生、怎样被发现，以及什么修改可以防止再次发生的人，才开始具备建设能力。

第三条约束：自学不能替代真实授权

你可以在个人电脑上模拟 CRM，可以用虚构会议记录练习抽取行动项，也可以手工扮演工具返回结果。但你不能通过“高保真模拟”获得读取客户数据、修改正式商机、向客户发信或处理敏感信息的权限。

真实项目开始前，需要确认业务负责人、数据来源、允许使用的环境、可以执行的动作和风险联系人。涉及财务、医疗、法律、安全、人事或不可逆操作时，还需要相应专业人员参与。课程作者、项目 Builder 和模型都不能代替这些审批责任。

权限暂时不足时，仍然有三种安全做法：使用完全虚构的数据；在脱敏材料上验证判断；让系统影子运行，只比较结果而不影响真实业务。边界清楚，学习就能继续；边界含糊，漂亮的演示也不应该进入真实流程。

选择你的项目路径

用真实项目并不天然学得更好。如果真实项目范围太大、负责人缺席、数据不可用，学习者很容易把时间耗在协调上。虚构案例也不天然浅薄，只要材料足够具体，仍然可以练习复杂判断。两条路径的差别主要是能证明什么。

项目条件	建议路径	可以形成的证据	不能作出的陈述
有真实负责人、流程、样本和授权	真实项目	限定范围内的发现、运行、试点与结果记录	未被证据支持的规模化价值
有真实流程，但不能影响真实状态	脱敏或影子项目	流程诊断、系统行为和高保真比较	已经改变真实业务或形成持续采用
暂无项目入口	贯穿教学案例	方法理解、模拟系统、评估和决策练习	真实客户交付、业务收益或外部认证

选择路径后不要频繁更换。项目条件发生变化时，记录变化日期。例如，前三章可能只能使用脱敏材料，第七章取得沙盒写入权限，第九章才获得有限真实试点授权。证据边界会随项目推进，但不能倒过来替过去的练习升级身份。

贯穿案例：一次会后跟进

“澄川工业”是取材于作者内部实践经验的原创复合案例。公司名称、人物、数据、系统和部分事件顺序经过合并与改写，不对应某个具体组织。

周二下午，销售顾问许岚刚结束一场客户会议。客户谈到了设备扩容、旧系统兼容和可能的交付时间，但没有形成正式承诺。许岚接下来要核对录音转写、整理纪要、识别需求与风险、更新 CRM，再给三项后续工作安排负责人。

经理希望当天看到 CRM 更新，许岚却先去准备下一场会议。晚上她重新打开记录时，已经记不清“六月前完成”究竟是客户要求，还是会议中的一种假设。她复制上一份纪要模板，补完主要字段，但遗漏了兼容性风险，也没有给行动项设置负责人。

团队最初提出的方案很直接：做一个会议纪要 Agent，自动生成摘要并写入 CRM。这个想法看起来合理，却跳过了许多问题。转写是否准确？产品资料哪个版本有效？AI 能否判断什么构成正式承诺？CRM 写入失败一半时怎么办？销售愿意审核多少内容？

书中给出的初始教学设定如下。这些数字是待验证材料，不是已经建立的基线。

项目	初始教学设定
参与角色	12 名销售、2 名销售经理
任务频率	每周约 35 次客户会议
会后整理	传闻中位数约 45 分钟，尚未完成抽样核验
常见问题	CRM 字段遗漏、行动项无负责人、产品承诺表述不一致
可用材料	脱敏会议记录、CRM 示例、经批准产品资料、销售政策
高风险动作	对外承诺价格或交付期、直接发送客户邮件、改变正式商机阶段
初始运行边界	AI 只生成结构化草稿；销售确认后才能写入仿真 CRM

第 5 章会要求你验证这些说法，而不是接受它们。后续章节还会逐步加入过期资料、来源冲突、工具失败、用户放弃和第二团队复用等问题。案例的价值不在于提供标准答案，而在于让同一个决定经受越来越真实的约束。

建立一个能追溯判断的证据目录

项目材料如果散落在聊天记录、个人文档和临时表格里，几周后很难还原一次决定为什么产生。证据目录的作用是把问题、版本和阶段决定连接起来。它不是规定你必须使用某种工具；Markdown、在线文档、项目系统或代码仓库都可以。

建议从下面的结构开始：

project/
├── 00-index.md
├── 01-discovery/       # 负责人、访谈、观察、样本、基线
├── 02-workflow/        # 现状/目标流程、责任、演示反馈
├── 03-system/          # 上下文、对象、工具、状态、运行说明
├── 04-evals/           # 数据集、评分规则、结果、轨迹、失败
├── 05-governance/      # 数据、权限、人审、停止、事件响应
├── 06-pilot/           # 试点计划、采用、指标、复盘
└── 07-assets/          # SOP、组件、版本、维护、复用记录

00-index.md 是目录，也是项目的证据地图。每个条目至少记录产物、负责人、版本、日期、来源、状态和它支持的决定。

例如，澄川案例的第一条记录可以写成：

产物	负责人	版本与日期	来源	当前状态	支持的决定
会后流程观察记录	许岚、项目 Builder	v0.1，教学第 1 周	三次模拟任务观察	待与系统记录交叉验证	是否进入问题定义

“待交叉验证”不会降低材料价值。它让下一位读者知道这条记录目前能支持什么，不能支持什么。

用能力前测决定学习投入

开始前，为八类能力做一次 0—2 分自评：0 表示从未做过，1 表示在指导下完成过，2 表示能够独立完成并出示证据。完整表格在练习册的能力前测中，可以复制到自己的项目目录。这八类对应全书主线：问题发现、工作流重构、业务约束、系统契约、评估、治理、试点采用，以及复用与诚实披露。结业时改用五维 0—4 分画像；前测只用来安排时间。

分数需要附证据。例如，“我做过用户访谈”不足以获得 2 分。更有用的记录是：你能提供访谈提纲、原始记录、相互矛盾的观点、由此修改的项目范围，以及第三方复核意见。

前测不是选拔，也不适合拿来比较学习者。它只帮助你安排时间。技术能力较强的人可能需要把更多精力放在现场观察、采用和净价值；业务经验丰富的人则可能需要补工具契约、运行轨迹和评估自动化。

每章怎样推进

每章先让你面对一个具体问题，再解释概念和机制。贯穿案例会展示一次完整判断，你随后要在自己的项目或同一案例上再做一次。练习完成后，对照示例、评价标准和常见错误，决定继续、返工、暂停或缩小范围。

学习并不是严格的直线。第 8 章出现的严重失败，可能要求你回到第 6 章重新分配人机责任；第 9 章发现用户绕开系统，也可能说明第 5 章选错了问题。返回前一章不是落后，而是项目证据改变后的正常动作。

建议每周固定留出一段时间更新证据索引。记录“为什么改”通常比保留五个无说明版本更有用。使用 AI 帮助整理材料时，也要说明它参与了哪些工作，以及哪些结论经过人工核查。

开始前的练习

现在完成四件事：选择项目路径，建立证据目录，完成能力前测，再写一份学习契约。学习契约至少说明每周投入、数据规则、禁止动作、风险联系人和退出条件。

下面是一段合格的教学案例陈述：

我将使用澄川工业案例完成八周高保真实践。人物、数据和结果均为教学设定。练习只用于证明我能使用问题发现、工作流、系统契约和评估方法，不用于声称真实企业采用或业务收益。任何涉及正式 CRM、客户数据或外部消息的动作都只在仿真环境中完成。

真实项目陈述则需要写清授权边界：

我获得销售运营负责人的流程观察许可，可以使用去标识化会议记录和 CRM 沙盒。当前没有正式 CRM 写入、客户通信和价格信息访问权限。第一阶段只验证问题与目标流程；新增权限必须由 IT 和业务负责人书面确认。

常见错误有三种。第一种只写“选择真实项目”，却不说明负责人和权限。第二种把“做出可运行原型”写成“已经产生业务价值”。第三种为了让作品集完整，删除失败、范围变化和停止决定。这些写法都会让证据看起来比实际更强。

完成后，请让一个不了解项目的人阅读你的学习契约。如果他仍然不知道哪些数据可以使用、哪些动作被禁止，以及你最终可以声称什么，说明边界还没有写清楚。

进入第一章之前

你已经为学习准备了三个基础：一条诚实的证据边界，一个可追溯的项目目录，以及一项能够随着材料变化而修改的初始任务。

下一章将从企业 AI 项目最常见的错位开始：模型已经能生成不错的内容，业务工作为什么仍然没有改变？这个问题会帮助我们理解，为什么企业需要一种新的建设角色。

继续阅读：第 1 章：为什么企业 AI 需要新的建设角色。