AI 项目作品集怎么规划？用一主一辅证明完整交付与工程深度
AI 求职作品集不需要堆很多相似 Demo。更有效的组合是：用一个主项目证明你能完成需求、架构、评估和上线闭环，再用一个辅助项目补足主项目没有覆盖的能力；每个结论都应能回到代码、测试、日志、评估记录或设计文档。
先说结论
“一主一辅”不是固定数量要求，而是一种控制范围的方法：
- 主项目回答“你能否把一个 AI 需求完整交付”；
- 辅助项目回答“你是否理解另一类关键机制或工程边界”；
- 证据包回答“这些工作是否由你实际完成、能否被追问”。
如果时间有限，宁可把一个项目做深并补齐证据，也不要同时维护多个只有聊天界面、模型调用和框架名的同质项目。
适合谁，不适合谁
本文适合已有开发经验、目标是 AI 应用开发、RAG、Agent 或 AI 平台相关岗位，并准备整理 Git 仓库、项目说明和面试材料的程序员。
它不适合以模型训练、论文复现或底层推理优化为主要目标的岗位；这些方向需要不同的项目证据。作品集也不能替代真实工作经历，个人练习、课程项目和生产项目必须如实标注。
主项目与辅助项目分别证明什么
| 组成 | 核心任务 | 建议覆盖 | 不必强求 |
|---|---|---|---|
| 主项目 | 证明端到端交付 | 需求边界、数据流、核心链路、评估、观测、故障处理 | 同时覆盖所有 AI 技术 |
| 辅助项目 | 补一个明确能力缺口 | 工具权限、结构化输出、模型路由、成本或回归中的一项 | 再做一套缩小版主项目 |
| 证据包 | 支撑简历与追问 | README、架构图、测试、评估记录、日志样例、取舍说明 | 包装成无法核验的结果故事 |
一个可选组合是：主项目做带引用和权限过滤的知识库，辅助项目做有限工具集的 Agent；也可以反过来。选择取决于目标 JD 和你已有的工程背景，不是项目名称越热门越好。
第一步：从目标岗位反推能力矩阵
先收集若干与你背景匹配的真实 JD，只提取重复出现的职责，不复制任职要求中的所有名词。把要求归入四类：
- AI 机制：模型调用、RAG、工具调用、结构化输出或评估；
- 后端工程：接口、数据、异步任务、鉴权、缓存和并发；
- 生产治理：观测、成本、安全、灰度、降级和回滚；
- 协作表达：需求拆解、方案取舍、文档和跨角色沟通。
再为每项标记“主项目证明、辅助项目证明、已有经历证明或暂不覆盖”。没有任何证据承载的高频能力，才是辅助项目应补的位置。
第二步：把主项目收敛为可验收问题
主项目应先写一页项目 Brief：
- 用户与问题：谁在什么流程中遇到什么困难；
- 非目标：本期明确不解决什么；
- 输入与输出：系统接收什么，成功、失败如何返回；
- 关键风险：质量、权限、延迟、成本或数据更新中最重要的两项；
- 验收证据：用哪些固定样例、测试和运行记录判断完成。
例如，不能只写“做企业级 RAG”。更可验收的描述是“对一组经过授权的文档提供带引用回答；没有可靠证据时返回未知；不同用户只能检索其有权访问的内容”。这仍是需求示例，不是对任何现有项目效果的声明。
第三步：让辅助项目只补一个缺口
辅助项目应比主项目小，并有不同的技术问题：
- 主项目已经覆盖 RAG，就用辅助项目证明工具调用的 allowlist、参数校验、超时和人工确认；
- 主项目已经覆盖 Agent，就用辅助项目证明模型适配层、结构化输出回归或 Token 预算；
- 主项目偏后端链路，就用辅助项目补离线评估与故障演练，而不是再换一个框架重写。
辅助项目的完成标准是“能讲清一个机制并提供证据”，不是功能数量。
第四步：为每个项目准备证据包
建议仓库至少包含：
README：问题、边界、启动方式、架构与已知限制
/docs：关键决策、接口或数据流说明
/tests 或 evals：可重复运行的测试与评估样例
examples：脱敏输入、输出、错误与降级样例
CHANGELOG 或提交历史：能解释迭代过程涉及指标时，保留评估集范围、运行条件、基线、统计口径和原始结果。若只在本地样例上测试，就写“本地评估集结果”，不要外推为生产效果、用户成功率或业务收益。
用五分钟检查项目是否互补
分别用一句话回答：
- 主项目解决什么问题，最难的工程决策是什么？
- 辅助项目补了主项目哪项缺口？
- 两个项目的失败路径有什么不同？
- 哪些内容是自己实现，哪些依赖框架或外部服务？
- 面试官可以从哪里核验你的判断？
如果两个项目的答案只是框架名不同，组合仍然重复；如果主项目无法解释验收和失败边界，则还没有达到作品集状态。
常见误区与失败边界
- 按技术名词凑项目：RAG、Agent、MCP 各做一个页面，不等于形成能力闭环。
- 功能很多但没有验收：无法判断系统在哪些条件下有效。
- 只展示正常路径：没有无答案、超时、越权和依赖失败的处理证据。
- 把课程代码写成独立成果：应说明参考来源、自己修改的部分和可核验差异。
- 使用无法解释的指标：没有基线、数据集和口径的百分比不应写进作品集。
- 把个人 Demo 描述成生产系统：部署过不等于承载过真实业务流量。
作品集只能证明已展示的能力。没有做过的上线、规模和协作经历，应直接说明边界，并讨论如果进入生产会如何验证。
可执行检查清单
- [ ] 已从目标 JD 提取能力矩阵，而不是追逐全部热门名词
- [ ] 主项目有用户问题、非目标、验收标准和失败边界
- [ ] 辅助项目只补一个明确缺口，与主项目不重复
- [ ] 每个技术主张都能指向代码、测试、评估或设计记录
- [ ] 指标注明样例范围、基线、条件和统计口径
- [ ] 课程、个人练习与真实工作经历已如实区分
- [ ] README 能让他人复现核心链路或理解无法公开的边界
- [ ] 已准备正常、边界和故障样例
- [ ] 能在五分钟内讲清两个项目为什么这样组合
下一步
先回到 AI 求职与面试 Hub 确认作品集在完整转型路径中的位置。项目组合确定后，下一步阅读 RAG 与 Agent 项目怎么写进简历，把主项目整理成“问题—动作—指标—证据”的可核验表达。