Day 65 / 共 68 天 · 阶段 12 实战求职

GitHub / 博客 / 开源:把作品"陈列"出来

昨天(Day 64)做完了三件作品集。可"能跑的代码"不等于"被看见的作品"——酒香也怕巷子深。今天教你四件"展示功夫":写一份 30 秒看懂的 README、录一段抓人的 demo、写一篇讲设计取舍的技术博客、给开源项目提第一个 PR,再把 GitHub 主页门面打理干净。明天(Day 66)把这些原料提炼进简历。

📍 你在阶段 12(实战求职 D62-68)的位置
D62 作品集①RAG D63 作品集②工具 D64 作品集③多智能体 D65 开源包装 D66 简历 D67-68 面试冲刺
💡 用一个类比兜住今天(今天全程沿用「开一家临街小店」的世界观) 把作品发上 GitHub = 开一家临街小店代码 = 你店里的好货;README = 店门口的招牌 + 橱窗(路人 30 秒决定要不要进来);demo 视频/GIF = 橱窗里循环播放的"效果演示",比一堆文字管用一百倍;技术博客 = 你贴在墙上的"匠人手记",讲你为什么这么做菜,让人信你懂行;给开源提 PR = 去别人的名店后厨帮个忙、留下你的名字,证明你能融入真实团队;GitHub 主页 = 整条街上你这家店的门面招牌。今天的功课:货是好货,还得让路人愿意进门。
L01

为什么"会展示"和"会做"一样重要

🤔 痛点很多人埋头把项目做得很扎实,GitHub 上却只有一堆源码、README 里就一句"a rag project"。招聘方/面试官平均在你的仓库上停留不到 1 分钟——看不懂、看不到效果,再好的货也直接划走。
💡 本质招聘方看你的 GitHub,和路人逛街一模一样:先看招牌决定进不进门,再看橱窗决定停多久。所以展示的第一原则是"降低理解成本"——让人 30 秒内看懂"这是啥、解决什么、效果如何、怎么跑"。会展示不是包装虚的,而是尊重看的人的时间。
📝 举个例子:同一个项目,两种命运 A 同学:README 只有标题 + 源码。招聘方点开→看不懂→划走。
B 同学:README 顶部一张 GIF 演示 + 一句话价值("给公司文档做带出处的问答,答对率 86%") + 三行启动命令。招聘方点开→10 秒看懂→顺手跑起来→加分。
货可能一样好,但 B 拿到了面试。展示,就是把你的努力翻译成别人能秒懂的语言。
👶 这算不算"包装过度"?不算。包装过度是"没有的吹成有";好的展示是"有的说清楚"。你确实做了 RAG + 评测 + 部署,只是把它讲明白、配上真实效果图和真实数字——这是本分,不是虚夸。心虚的是编数字,踏实的是把真东西讲清楚。
L02

README 黄金结构:招牌 + 橱窗

🤔 痛点README 到底写啥、按什么顺序?新手要么写成一句话,要么写成又臭又长的说明书,读者抓不住重点。
💡 本质README 有一套久经考验的"黄金结构",本质是倒金字塔:最重要的(是啥、效果)放最上面,越往下越细节。让人按需往下读,读到哪一层都有收获。照下面模板填空即可。
# 项目名:一句话说清它是什么
> 员工手册问答助手 · 给公司文档做"带出处"的问答,答对率 86%

![demo](docs/demo.gif)   <!-- ① 顶部直接放效果 GIF,胜过千言万语 -->

## 它解决什么问题        <!-- ② 痛点 + 价值,2~3 句 -->
新员工找制度要翻 20 个 PDF。本项目让他们直接提问,秒答且给出处。

## 效果                  <!-- ③ 用数字说话(评测来的!Day62) -->
- 20 道常见问题答对率 **86%**,均带出处
- 单次回答 < 3 秒

## 快速开始              <!-- ④ 三行内能跑起来,别让人猜 -->
```bash
pip install -r requirements.txt
python ingest.py          # 摄入文档
uvicorn app:app           # 启动,浏览器打开 /docs 试问
```

## 架构                  <!-- ⑤ 一张流程图 + 关键取舍,展示你懂设计 -->
文档 → 切块 → 向量库 → 检索top-k → LLM生成(带出处)
## 技术栈 / 目录说明 / License   <!-- ⑥ 细节兜底 -->
👶 README 用什么写?Markdown(回忆你写过的 .md)。GitHub 会自动把它渲染成带标题、图片、代码块的漂亮页面。# 是标题,![xx](路径) 插图,三个反引号包代码。不用学新东西,你做教程时早就在用了。记住一条:第一屏(不用滚动就能看到的部分)必须让人看懂"是啥+效果"
L03

录一段抓人的 demo:会动的橱窗

🤔 痛点文字描述"它能问答"再多,也不如让人亲眼看到"输入问题→秒出带出处的答案"。但新手要么不录,要么录一段 5 分钟啰嗦视频没人看完。
💡 本质demo 的黄金法则:短(15~40 秒)、无声也能看懂、直击核心动作。README 顶部最好放 GIF(自动循环、不用点播放,像橱窗里的循环片)。脚本就一条主线:提出一个真实问题 → 展示助手秒答 + 出处。别演环境安装,只演"最爽的那一下"。
30 秒 demo 分镜 ① 0-5s 打字输入一个 真实问题 ② 5-20s 答案流式冒出 (打字机效果) ③ 20-30s 高亮"出处" 这是可信亮点 工具:屏幕录制 → 转 GIF(如 macOS 用 Kap,或录屏后用 ffmpeg 转)
图注:只演"最爽的一下"。把最能体现价值的动作(带出处的秒答)放大给人看。
📝 举个例子:录屏转 GIF 的命令 录一段 mp4 屏幕视频后,用 ffmpeg 转成体积小的 GIF 放进 README:
ffmpeg -i demo.mp4 -vf "fps=10,scale=800:-1" docs/demo.gif
(fps=10 每秒 10 帧够顺滑又不大;scale=800 宽度压到 800 像素控制体积。) 然后 README 里 ![demo](docs/demo.gif) 就能自动播放。
L04

写一篇"设计取舍"博客:匠人手记

🤔 痛点面试官怎么判断你是"跟着教程抄"还是"真懂"?看你能不能讲清为什么这么做、当时有哪些选择、你为什么选了这个。而这些,一篇博客就能提前替你回答,还能被搜索到、被转发。
💡 本质技术博客最有价值的不是"我做了啥"(README 已经说了),而是"我做了哪些取舍、踩了什么坑"。取舍 = 你面对多个选项做了判断,这正是工程师的核心能力。一篇好博客抵得上半场面试。
📝 举个例子:一篇取舍博客的骨架 标题:《给公司文档做 RAG,我在这 3 个地方纠结了很久》
切块大小:试了 800 字答不全、200 字太碎,最后 500+50 重叠——附评测对比数字。
要不要上向量数据库:数据量小,先用内存索引够了,没上重型 DB,避免过度设计。
怎么防编造:加了"资料没有就说不知道"的纪律 + 强制出处,答对率从 68% 到 86%。
每一节结构:面临的选择 → 我的判断依据 → 结果(最好带数字)。真实、有数字、有反思,就是好博客。

👶 小白:我一个转行新人,写博客会不会被笑"太浅"?

👨‍🏫 老师:完全不会。"新手视角讲清一件事"本身就有价值——比你晚一步的人最爱看。而且写作会倒逼你真正想明白(讲不清=没懂透),这个过程受益的首先是你自己。别追求高深,追求"真实 + 讲清一个具体决策"。你做这套 68 天教程的经历,本身就是绝佳的博客素材。

L05

给开源提第一个 PR:进名店后厨帮忙

🤔 痛点只有自己的项目,证明不了"你能在别人的代码库里协作"。而给知名开源项目(如 LangChain、LlamaIndex)提过 PR,是简历上极亮的一笔——但新手总觉得"我哪有能力改大项目的代码"。
💡 本质第一个 PR根本不用改核心逻辑。从最小的贡献开始:修文档错别字、补一个缺失的示例、翻译一段 README、修一个报错信息的拼写。重点是走通协作流程(fork → 改 → 提 PR → 按维护者意见改),证明你懂 Git 协作、能沟通、守规范(呼应 Day 06 Git、Day 59 CI)。
# 提 PR 的标准流程(Day06 的 Git 技能派上用场)
# 1) 在 GitHub 网页点 "Fork",把别人的仓库复制一份到你名下
git clone https://github.com/你的名字/项目.git   # 克隆你 fork 的那份
cd 项目
git checkout -b fix-typo-in-readme               # 开一个新分支干活(别在 main 上改)
# 2) 改点小东西:比如修 README 的一个错别字 / 补个示例
git add . && git commit -m "docs: fix typo in quickstart"
git push origin fix-typo-in-readme               # 推到你 fork 的仓库
# 3) 回 GitHub 网页,点 "Compare & pull request",写清"改了啥、为什么"
# 4) 维护者可能提意见 → 按建议再改再 push → 合并!你就有第一个开源贡献了 🎉
👶 提 PR 有什么礼仪?三条:①先看 CONTRIBUTING.md(贡献指南,像进门先看店规);②一个 PR 只做一件事(改错别字就别顺手重构,否则维护者难审);③描述写清"改了什么、为什么",态度谦逊。被要求修改很正常,别玻璃心——按建议改,恰恰展示了你的协作素养。第一个 PR 哪怕只是修个标点,也是真实的开源足迹。
L06

打理 GitHub 门面:整条街的招牌

🤔 痛点招聘方点进你的 GitHub 主页,第一眼看到的是一堆 fork 来的空仓库、乱七八糟的命名、没头像没简介——像一家门口堆满杂物的店,好项目全被埋没了。
💡 本质GitHub 主页 = 你的整条街门面。花半小时打理:把三件作品置顶(pin)、写清个人简介、给仓库起清楚的名字和描述,让人一进来就看到你的"招牌菜",而不是杂物堆。
要做怎么做为什么
Pin 置顶作品主页 "Customize pins" 选中三件作品集访客第一眼就看到你的代表作
写个人简介 (Bio)"正在从 X 转型 AI Agent 开发|作品见下"一句话交代你是谁、在做什么
仓库名 + 描述名字用短横线(rag-assistant),描述一句话价值列表里就能看懂每个项目干啥
Profile README建一个与用户名同名的仓库放 README主页顶部展示,等于个人主页的橱窗
提交历史持续小步提交(绿格子)体现你在真实、持续地投入
📝 举个例子:三件作品串成一句话叙事 在 Profile README 里写:"这三个项目覆盖了 Agent 开发核心链路——RAG 知识问答(带评测)、多工具 Agent(带安全护栏)、多智能体工作流(带可观测)。"招聘方一眼就看出你的能力是成体系的,而不是零散练手。把 Day 62-64 的三件作品讲成一个"能力全景"故事,门面立刻高级。
L07

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • 为什么"会展示"和"会做"一样重要?好展示 vs 包装过度的区别?
  • README 的黄金结构(倒金字塔)是哪几层?第一屏必须放什么?
  • 一段好 demo 的三条法则?为什么 README 顶部放 GIF?
  • 技术博客最值钱的内容是什么?(设计取舍 + 踩坑,带数字)
  • 第一个开源 PR 该从什么改起?提 PR 有哪三条礼仪?

✋ 动手 10 分钟:给作品①写好第一屏 README

打开作品① RAG 助手的 README.md,只写"第一屏"(最能决定去留的部分):

# 员工手册问答助手
> 给公司文档做"带出处"的智能问答 · 20 题答对率 86% · 单次 < 3s

<!-- 先占位,demo 录好后替换成真图 -->
![demo](docs/demo.gif)

## 它解决什么问题
新员工找制度要翻一堆 PDF;本项目让他们直接提问,秒答且标注出处。

## 快速开始
```bash
pip install -r requirements.txt
python ingest.py && uvicorn app:app
```

再列一个"包装 To-Do"贴在博客草稿里(课后逐项完成):① 三件作品各写第一屏 README ② 录一段 30 秒 demo GIF ③ 写一篇设计取舍博客 ④ 给一个开源项目提一个修文档的 PR ⑤ Pin 置顶 + 写 Bio。

明日预告 · Day 66:门面打理好了,该把这些"陈列"提炼进简历了。明天讲怎么用 STAR(问题→方案→指标)把项目写成一条条有数字、有分量的经历,别再堆一串"熟悉 LangChain/RAG/向量数据库"的名词——招聘方要的是"你解决了什么、结果如何"。
← Day 64 · 作品集③ 多智能体工作流 Day 66 · 简历 & 项目包装 →