第 14 章　做一个能证明能力的作品集

14.1 作品集不是截图集合

漂亮界面、流畅对话和架构图都能吸引注意，却无法单独证明 FDE 能力。面试官或客户真正想知道的是：你怎样发现问题，为什么选择这个方案，系统如何面对真实数据和失败，最后产生了什么变化。

因此，作品集应是一条从问题到结果的证据链，而不是产品功能展览。

作品首先要交代用户和现状。谁在什么流程中遇到问题，现有办法有什么代价，哪些内容已经由观察或数据确认。

随后说明范围与取舍：为什么选择这一个节点，哪些能力明确不做，最大风险是什么。架构部分重点解释模型、检索、工作流、工具与人工怎样配合，而不是罗列技术名称。

数据部分说明来源、质量、权限和版本。评测部分展示样本类型、指标和主要失败模式。安全部分说明身份、最小权限、人工确认和降级方法。

最后呈现试用和结果：谁使用了多久，技术表现怎样，用户行为有什么变化，业务指标是否改善，以及哪些结论仍然不确定。

转型者往往暂时接触不到企业客户，可以使用公开数据、模拟业务资料或自己构造的小型流程。关键是诚实标注哪些是真实观察，哪些是模拟假设。

模拟项目可以证明工程、评测和安全意识，却不能声称带来了真实收入或效率提升。可以报告系统在测试集上的表现，也可以邀请少量目标用户体验，但不能把朋友的一句好评包装成企业验证。

如果能找到真实使用者，即使只有三五个人持续使用两周，也比虚构大型客户故事更可信。

一个清晰的仓库通常包括 README、可运行代码、示例配置、架构说明、评测方法、测试数据说明和项目复盘。

README 应先讲问题和结果，再讲安装方法。读者不运行代码，也能在几分钟内理解项目价值、主要取舍和限制。

敏感配置通过环境变量处理，示例数据与真实数据分离。仓库应说明模型和依赖版本，并提供最短运行路径。复杂项目可以附简短演示，但视频不能替代文档和代码。

一个容易运行、边界诚实的小项目，比无法复现的庞大仓库更能证明专业性。

真实客户项目不能因为适合作品集就默认公开。客户名称、业务数据、代码、架构、合同和项目指标都可能属于保密范围。

公开前应获得明确授权。没有授权时，可以彻底匿名化，只描述通用问题、个人职责和方法；仍可能识别客户的信息应删除。不能为了证明能力而上传脱敏不彻底的数据或内部文档。

如果核心内容无法公开，可以单独做一个结构相似的演示项目，并清楚说明它与真实项目不是同一个系统。

知识密集流程适合产品、开发和行业人员，例如在带版本与权限的资料中检索，并生成带来源的工作建议。重点是知识治理和评测，而不是聊天界面。

工单协同适合开发、测试、运维和实施人员，例如对工单分类、补全信息、推荐处理步骤，并在人确认后写回。重点是系统集成、失败处理和流程闭环。

运营分析适合数据、BI 和产品人员，例如把多来源数据整理为异常解释与行动建议。重点是指标口径、证据来源和建议是否进入后续动作。

选题时优先使用自己的行业知识。理解一个普通业务问题，通常比复制一个热门 Demo 更有区分度。

三分钟版本只讲用户、问题、关键方案、结果和一个重要取舍。它用于让对方迅速判断是否值得继续了解。

十五分钟版本加入流程、架构、评测、安全和失败复盘。它适合面试陈述或客户初次交流。

四十五分钟版本可以演示代码、数据流、评测集、运行日志和方案演进。它应允许对方追问，而不是背诵固定演讲。

无论多长，都不要从使用了多少框架开始。FDE 作品首先证明的是判断与闭环，技术服务于这条主线。

好的作品集让人看见一条完整证据链：真实或诚实标注的场景、清楚的范围、可解释的技术选择、系统化评测、安全边界、使用结果和失败复盘。

作品集证明你能做什么，求职过程还要证明你为什么适合某家公司。下一章将进入岗位选择、简历和面试。