第 13 章　90 天转型路线

13.1 九十天能改变什么

九十天不足以把一个完全没有技术经验的人变成资深 FDE，也不足以掌握所有行业和模型。但它足以完成一次关键变化：从“正在学习 AI”，走到“有证据证明自己完成过一个小型闭环”。

转型最容易陷入无限准备。今天学习提示词，明天更换开发框架，后天又追逐新模型。知识不断增加，却始终没有真实用户、运行数据和项目结果。

九十天路线的重点不是课程数量，而是围绕一个窄场景，依次完成问题定义、原型、评测、试用、部署和复盘。

前十五天首先盘点自己的起点。程序员可能缺业务发现，产品经理可能缺工程实现，测试人员可能缺端到端构建，售前和实施人员可能缺少独立编码能力。

不要平均补齐所有短板。先确定自己的主能力，再找出最可能切断交付闭环的一项缺口。

这一阶段还要选择熟悉的业务场景。场景最好来自自己工作过的行业或流程，例如工单处理、销售跟进、文档审核、知识检索或数据分析。熟悉业务能减少凭空假设，也更容易找到愿意提供反馈的人。

AI 基础学习应服务于这个场景。理解模型、RAG、工作流、工具调用和评测即可，不必先掌握所有底层原理。

第二阶段要把问题收缩为一个完整但很小的闭环。明确谁使用、输入是什么、系统产生什么结果、由谁确认，以及怎样判断有用。

原型优先验证最大风险。如果最不确定的是检索效果，就先处理真实文档；如果是数据接入，就先打通一个只读接口；如果是用户是否需要，可以先用人工模拟结果。

界面够用即可。一个能够处理十几条真实样本、暴露失败并留下记录的简单原型，比功能丰富却只能演示的产品更有价值。

同时建立首版评测集。它不必很大，但要包含常见、边界、拒答和高风险情况。

这一阶段决定作品是课堂项目还是 FDE 项目。找到少量真实用户，让他们在一段时间内持续使用，而不是只看一次演示。

试用会暴露原型中看不到的问题：输入不完整、文档过期、权限不清、入口麻烦、回答太长，或者用户根本不愿改变习惯。

根据失败记录逐步补齐权限、日志、异常处理、评测回归和基本部署。每增加一个能力，都要能解释它解决了哪种真实失败。

不要把用户提出的所有建议都做完。保持场景边界，优先修复影响核心结果和安全的问题。

系统运行后，要把变化与原来的基线比较。技术表现、用户采用和业务结果应分别描述，不能用几句好评代替数据。

同时复盘关键取舍：为什么选择这个场景，哪些假设被推翻，为什么采用当前架构，系统会在哪些情况失败，下一步怎样改善。

把重复出现的部分整理为可复用资产，例如提示模板、连接器、评测结构、部署说明或业务访谈方法。作品的价值不仅是“做成了”，还在于说明下一次怎样做得更快。

最后十五天，把项目整理为公开作品集和职业叙事。简历不只写“熟悉大模型”，而要写清为谁解决什么问题、承担哪些责任、做出什么取舍、结果如何。

求职者可以定向寻找目标函数接近 FDE 的岗位；计划接副业的人，可以把项目提炼成范围清晰的小型服务；希望内部转岗的人，则可以用项目向业务与管理者证明新工作方式。

市场反馈也是转型的一部分。如果多次面试都暴露同一短板，或者客户始终不愿为某项服务付费，就要调整定位，而不是继续堆叠技术名词。

在职转型者最稀缺的是连续时间，适合用工作日完成短学习与记录，周末集中开发和复盘。选题应尽量贴近已有行业经验，减少重新理解业务的成本。

全职学习或暂时失业的人拥有更多时间，却更容易陷入长期闭门开发。应更早接触用户，把求职、交流和试用安排进每周节奏。

准备内部转型的人，可以从低风险、部门内可验证的流程切入，利用自己对组织和系统的理解建立优势。

无论哪种情况，都应设置止损点：数据长期拿不到、真实用户不参与、核心假设不成立时，及时缩小范围或换题。

九十天转型的目标不是学完 FDE，而是完成第一次可信闭环。先选择与旧经验相连的场景，再做窄原型、进入真实使用、形成证据，最后把结果带向求职、转岗或市场。

这些经历需要被清楚地展示。下一章将讨论，一个真正能证明 FDE 能力的作品集应该是什么样子。