从零构建AI项目到求职：前亚马逊工程师的完整实战流程

想进入AI行业，几乎所有人都被建议去「做项目」。但真正的难点在于：跟着教程做（别人已经替你做好了每一个决策）和从零搭建一个真正的项目之间，存在巨大的鸿沟。

一位曾在亚马逊等公司构建生产级AI/机器学习系统的油管博主，分享了他实际使用的完整流程——从判断什么值得做，到测试、部署，再到如何利用上线后的项目撬动求职机会。这套方法论对所有想靠项目作品集进入AI领域的人都极具参考价值。

先想清楚：为什么要做这个项目

动手之前，必须明确项目到底要解决什么目标。一个项目可以做三件完全不同的事：

学习技能：比如只是想学会怎么调用视觉模型；
向雇主证明能力：这时门槛明显更高，你需要构建更健壮的系统，还要证明你在全程使用了良好的判断力，而不是让Claude「凭感觉」帮你生成代码；
积累真实经验：如果真的有人在用，它甚至能写进简历的工作经历部分，或成为可变现的产品。

博主强调，最好的作品集项目往往不是技术最炫的那个，而是你与之有个人连接的那个——因为这能让你全程保持动力，而这种热情会在面试中自然流露。他引用了自己为机器学习职业书籍采访的几乎所有招聘经理的共识：他们极其看重热情和决策能力，而这些只有在你自己提出想法时才能真正展现。

从问题出发，而非从技术出发

很多人卡在「不知道做什么」这一步，要么觉得想法太简单不够惊艳，要么太宏大无从下手。博主指出，问题根源在于大家常常从想用的技术出发——学了RAG、Agent或某个新模型，然后到处找能用它解决的问题。

正确的方向恰恰相反：从你真正理解的问题出发，再反推什么技术才合理。你自己的生活是最好的起点，因为你清楚什么让你烦恼，也知道好的解决方案长什么样。

博主的例子是他重做的应用「Shelf Scanner」：走进书店面对满架陌生书籍无从下手，于是他想要——拍一张书架照片，告诉系统自己的阅读偏好，让它推荐该买哪本。他特别提醒：不要照抄这个应用，要学的是流程框架，而不是拿走一个现成项目。

把模糊想法写成可决策的范围文档

在打开编程助手之前，博主会先把「一个能从照片推荐书的App」这样的模糊想法，转化为足够具体、可以据此做决策的问题陈述。关键是——做决策的必须是人，而不是Claude。

范围界定中的延迟与预算决策

他使用一套贯穿职业生涯打磨出来的模板，涵盖产品需求、数据、模型、评估、基础设施、安全、部署、监控等生产级AI系统会涉及的方方面面。但此刻他只填写初始范围界定部分，大部分内容刻意留空，因为还没有证据证明需要那些东西。

这里有一个被太多人忽略的关键问题：这个项目真的需要AI吗？ 如果普通软件就能同样好地解决问题，加一个语言模型只会带来额外成本、不可预测性和安全隐患。

MVP不是粗糙的完整版，而是回答最大疑问

博主对MVP（最小可行产品）有独到理解：它不是「做一个粗糙的完整App」，而是能回答你当前对项目可行性最大疑问的最小东西。

Shelf Scanner在两个问题上存在致命不确定性：

便宜的视觉模型能否从普通书架照片中准确读出书名？（书脊可能歪斜、很小、被遮挡，光线也可能很差）
价格合理的语言模型，能否结合找到的书和极少的偏好信息，给出合理推荐？

因此第一版MVP只是一个命令行脚本：给它一张照片，一个模型读书名，另一个模型结合偏好做推荐，仅此而已。

配置Supabase数据层与日志Schema

用「实验」的方式做评估

博主强调不能「凭感觉」试，而要像真正的实验一样做。他把每次模型调用的结果都记录下来——使用的模型、提示词、返回内容、成本、延迟，并在Supabase中建立日志Schema。

他把读取书架和推荐书籍两个阶段分开评估，因为擅长识别图片小字的模型未必擅长推荐书籍。他用OpenRouter通过单一接口调用多家模型，用5张书架照片做小规模对比。几个关键发现：

Claude Sonnet和Gemini Flash几乎能读出所有可辨识的书名且不产生幻觉，而更小的模型漏读多、幻觉多；
成本比预期不重要，表现好的模型都在预算内；
延迟才是问题，有些调用光读书架就要10-20秒，而整体体验目标约15秒；
在推荐环节，更便宜的GPT模型反而比贵模型更贴合他本人的选择；
还发现了一个隐私问题：源图片的元数据里带有GPS信息，这是他不想存储的。

这个MVP让他明白：这是个用现有模型、合理成本与延迟就能解决的真问题，应该分离识别与推荐阶段，还学到了提示词写法、参数设置和隐私注意事项。

OpenRouter是一个API聚合平台，允许开发者通过统一的接口调用来自OpenAI、Anthropic、Google、Meta等数十家供应商的模型，无需分别申请各家API密钥或适配不同的调用格式。对于需要横向对比多个模型性能的评估场景，这种方式可以显著降低切换成本。Supabase则是一个基于PostgreSQL的开源后端即服务平台，提供数据库、身份认证、实时订阅和存储功能，开发者可以在不自建服务器的情况下快速搭建数据层。在AI项目中用它记录模型调用日志，兼顾了结构化查询的灵活性和部署的便捷性——这正是博主选择它而非简单写本地文件的原因。

克制「堆技术」的冲动

基于MVP所学，博主回头更新范围文档，并明确哪些技术不用：

不用RAG：书本就来自当前书架，额外信息通过普通目录查询即可，没有检索问题；
不用Agent：工作流程是固定的（读架→核对→推荐），没什么可让模型决策的，加Agent只会更慢、更贵、更不可预测；
不做微调：现成模型工作得很好。

他点明了一个常见误区：为了让AI项目显得高级，很多人忍不住把学过的每种技术都塞进去，但你不会因为堆砌技术而加分。如果问题不需要，省略它们才是更好的决策。同样，登录、账户、购买链接等酷炫功能在V1阶段全部排除，保持聚焦。

RAG（检索增强生成）是一种让语言模型在生成回答前先从外部知识库检索相关内容的架构，适用于需要访问大量私有文档或实时更新信息的场景。Agent（智能代理）则是让模型自主决定调用哪些工具、以何种顺序执行多步任务的模式，适合流程本身不固定、需要动态规划的问题。微调（Fine-tuning）是用特定领域数据对预训练模型做进一步训练，以改变其输出风格或专业能力。这三项技术各有其适用的问题类型：RAG解决知识边界问题，Agent解决流程不确定性问题，微调解决风格或领域适配问题。当项目的工作流程固定、所需知识有限且通用模型表现已足够好时，引入它们只会增加系统复杂度而不带来实质收益。

分阶段构建 + 双重质量检查

博主把项目拆成多个阶段，每个阶段结束后系统仍能端到端运行，只是多了一项新功能，并设置粗略截止日期避免范围蔓延。每个改动都有spec和任务清单，每次提交关联到具体任务，便于追踪进度、回顾决策和回滚。

上线前捕获问题的质量检查环节

关于「正确性」，他区分了两种：

普通软件正确性：如剥离照片位置信息的代码，是确定性的，可以写标准单元测试；
AI行为正确性：改了提示词后视觉模型可能漏掉一半书，普通测试发现不了，这需要评估集。

他用GitHub Actions搭建CI/CD，每次推送或提PR都自动跑测试；另外单独维护AI行为评估集。为提高可靠性，他把原始照片人为做出模糊、眩光、旋转、低分辨率等更糟的版本，并加入更多书架照片，覆盖更广的使用场景。只要有改动可能影响模型，就重跑评估对比当前可信版本。

这一切的前提是提示词版本化——这是许多新手忽略的最重要环节之一。AI系统的诡异之处在于，代码完全有效，行为却可能变差，什么都不会崩溃，但结果就是更差。

CI/CD（持续集成/持续部署）是一种软件工程实践：每当代码发生变更时，自动触发一系列测试和构建流程，通过后再自动部署到生产环境。GitHub Actions是GitHub内置的自动化工具，可以在代码推送、Pull Request等事件发生时执行预设的脚本。对AI项目而言，CI/CD的重要性在于提示词和模型配置的改动往往不会让程序「报错崩溃」，却可能悄悄降低输出质量——没有自动化测试门禁，这类退化极难被及时发现。提示词版本化（将提示词像代码一样纳入版本控制，记录每次修改）与评估集搭配使用，才能形成可追溯的质量保障闭环。

上线后的监控与利用真实用户

生产环境会暴露不同的问题：有人上传奇怪照片、供应商变慢、触发限流。博主不需要企业级可观测性，只需足够的信息判断「发生了什么变化、我是否在意」。

幸运的是，早期决定保存每次模型调用的那些记录，现在正好能告诉他哪个模型处理了请求、耗时、成本、提示词版本以及是否失败。他据此做了一个简单的仪表盘。更进一步，他还能用失败案例持续改进系统，并在产品中收集简单反馈信号（如用户保存推荐或标记「不喜欢」）。

他举了个面试视角的例子：如果被问「你为什么加缓存」，他不想回答「生产应用都有缓存」，而是能指出自己观察到延迟升高、基于数据做出的优先级判断。

部署上他用Vercel，连接GitHub仓库点几下即可，之后每次改动在通过预部署检查后自动部署。

让项目真正帮你求职

当你只看应用本身时，是看不出背后所有工作的。所以博主强调呈现方式同样重要。他花时间重写了README，解释构建内容、权衡取舍，甚至加上架构图。

更关键的是获取真实用户。哪怕只有几十个人使用你的应用，都能教会你大量东西，并给你面试中可讲的好故事。而如果用户达到几百上千，这就开始接近职业经验了——博主认为，如果你构建了一个有真实用户甚至付费客户的产品，它可以写进简历的工作经历部分，而非项目部分。

这正是破解「需要经验才能获得经验」死循环的方式：打造一个真正的产品，你就能为自己创造机会。最后博主再次提醒：不要照抄Shelf Scanner，要复制的是这套流程。