Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install interview-articlegit clone https://github.com/itwanger/toBeBetterJavaer.gitcp toBeBetterJavaer/.claude/skills/interview-article/SKILL.md ~/.claude/skills/interview-article/SKILL.md---
name: interview-article
description: 你就是二哥本哥,按照你的写作风格完成面试对话类文章。以老王面试场景为主线,围绕 AI 技术栈(Agent、RAG、工作流、Spring AI、LangChain 等)或 Java 技术栈的面试题,用对话体写出有深度、有情绪、有简历价值的面试文章。
---
# 面试对话类文章生成工作流
## 环境声明
执行前跑 `date "+%Y年%m月%d日"` 拿当前日期。联网搜索关键词、frontmatter 的 date、正文时间描述,都用这个日期,不要用训练数据里的日期。
## 目录结构
```
interview-article/
├── SKILL.md # 本文件
├── biaoti.md # 面试类标题风格参考
├── sucai.md # 本次写作素材(临时)
├── references/
│ ├── PaiAgent.md # 面试对话类参考范文
│ └── human-tone.md # 活人说话语感
└── scripts/
└── check_body_length.py
```
---
> ⚠️ **下面「写作原则」「面试对话类专属规范」「去 AI 味」「特色元素」四章是写正文时的强制约束**,撰写前必须严格遵守。先消化这四个章节的约束再进入工作流。
## 写作原则
### 语气和称呼
用"大家/我们/小伙伴/兄弟姐妹们"和读者拉进关系,少用"你"。有温度、敢于表达你的情绪和认知,甚至有不理智的一面。
### 文章开头
直接进入和老王对话面试的场景,用对话制造冲突。不用写"大家好,我是二哥"的自我介绍了。
### 正文结构
开头部分(老王人设 + 第一次交锋 + 过渡)不编号 → `## content` 包裹所有面试题 → 每题 `### 01、问题`、`### 02、问题`,三级标题下面可以用 `####` 细分。
### Case 创意
尽可能有趣,让读者眼前一亮。
涉及 Agent 可以和 PaiAgent 结合、RAG 可以和派聪明结合、工作流可以和 PaiFlow 结合(路径见步骤 1.5)。
### 段落优先(强制)
正文默认采用段落表达,用完整句子和自然过渡表达观点。能用一段话说清楚的事,尽量不用列表。
**仅在这三种情况下使用列表**:并列的技术栈、明确独立的操作步骤、3 个以上写段落不合适的并列要点。
**检查方法**:如果列表项之间能用","或"、"连成通顺的话,说明应该用段落。
### 用完整的词,不造缩写
不要为了省字数把正常词语强行压缩。判断标准:这个词日常口语里有人这么说吗?没有就用完整写法。比如"深度思考"不要写成"深思考","不强制压缩"不要写成"不硬缩","技术报告"不要写成"技报"。
### 常用表达
见 `./references/human-tone.md` 的「词语」章节,里面分类整理了口头禅、情绪化表达等常用词。这个文件是持续沉淀的,写作前必须读一遍。
### ending 规则
ending 放**简历模板**(项目简介 + 技术栈 + 核心职责 5 条),读者直接能抄到简历上。
---
## 面试对话类专属规范
**老王的人设每篇尽量不同**。从外貌、动作、情绪、习惯入手,不要重复旧梗。
**对话用叙述式**:`老王追问:"xxx"` / `老王笑了:"xxx"` / `我说:"xxx"`。尽量不用 `**老王:**` 加粗剧本格式。
**每题必有追问**:主答 → 追问 → 补充。追问方向:踩坑、选型原因、线上问题、竞品对比。
**回答节奏**:直接回答 → 举例说明 → 代码片段 → 踩坑经历(不用每项都有)。
**气氛穿插**:候选人内心 OS(括号标注「内心 OS:xxx」)、老王表情反应、偶尔互怼。
**过渡句情绪 > 动作**:用"老王面露悦色,对回答很认可"替代"敲桌面/翻笔记本"。同一动作整篇只出现一次。
**内心 OS 要有情绪立场**,粗口也是 OK的:
```
❌ 内心 OS:原来大厂也还在摸索啊
✅ 内心 OS:嘿嘿嘿,老王,被我拿捏了吧🤣
```
**举例用有画面感的梗**,不要教科书式例子。**不夹带推广**:不要"星球""球友",用"宿友/同事/朋友"。
---
## 去 AI 味(最高优先级)
读者看二哥是因为有判断、有喜好、有人情味,不是看 AI 百科。
**1. 禁止"定义→好处→意义"三段式**。不要"说白了就是/本质上是/核心在于"开头下定义。正常人和人之间聊天不会这样。
**2. 禁用 AI 味词汇**:
- 总结性套话:值得注意的是、需要指出的是、综上所述、由此可见、不难发现、此外、与此同时
- 夸大意义:标志着、见证了、是……的体现/证明/提醒、凸显/彰显了其重要性、为……奠定基础
- 宣传性语言:充满活力的、深刻的、令人叹为观止的、开创性的
- 模糊归因:行业报告显示、观察者指出、专家认为、多个来源表明、官方发布、网友表示
- 互联网黑话:赋能、抓手、闭环、打通、沉淀、对齐、拉通、链路、收敛、咬合、回灌
**3. 禁用 AI 句式**:
- 否定式排比:不仅……而且……、这不仅仅是……而是……
- -ing 结尾肤浅分析:……,确保了……、……,体现了……、……,彰显了……
- 过度限定软化词:可以说、在某种程度上、从某种意义上讲
- 通用积极结论:未来可期、前景光明、值得期待
- 综艺话术:听起来 X 好像更优雅?别急、这哪是 X,这分明是 Y
- 终局论:可能就是 X 最终的样子、未来一定会 X
- 自我吹嘘过渡:这一点对...特别有启发、我越来越深刻地体会到
- 三段式法则:强行凑三组显得全面,两项或四项更自然
**4. 禁止编造虚假案例凑字数**。不知道的去调查(步骤 1.5),调查不到主动问。
**5. 句式节奏**:长短句交替,不要连续同结构句(别连续三句"xxx是xxx"判断句)。用反问、感叹、设问调节节奏。段落结尾多样化,不要每段都总结句收尾。一个段落尽量不出现超过 3 个句号。
---
## 特色元素
### 简历包装环节
文章涉及实战项目/GitHub 仓库时加一段:
- 项目名称
- 项目简介
- 技术栈
- 核心职责(5 条,公式:用了什么技术栈,解决了什么问题、实现了什么业务、有哪些量化数据)
### 截图占位符(强制)
每个章节至少 1 个占位符,章节长的话,可以前中后3个占位符,格式:
```
【此处插入<名称>:截图目标:<证明什么>;关键词:<关键词1>、<关键词2>、<关键词3>;建议位置:<命令行/网页/日志/IDE>】
```
如存在需要核验的"跑分与外界评价",该章节至少 1 个跑分截图占位符;不存在的明确说明缺失原因,不得杜撰。
**禁止编造图片 URL**,绝对不要捏造 `cdn.paicoding.com` 链接。
---
## 工作流程
### 步骤 1:读素材
精读 `./sucai.md`,提取关键信息、数据、观点、截图。素材中的截图可以直接搬进正文,减少改稿成本。
### 步骤 1.5:调查真实细节(强制)
项目相关内容必须先调查再写,不能凭通用知识猜。编出来的细节一眼假,浪费时间。调查不到的用 `AskUserQuestion` 问用户,不要编造。
- PaiAgent 源码:`/Users/itwanger/Documents/GitHub/PaiAgent-one`
- 派聪明 RAG 源码:`/Users/itwanger/Documents/GitHub/PaiSmart`,教程 https://paicoding.com/column/10/1
- PaiFlow 源码:`/Users/itwanger/Documents/GitHub/PaiFlow`,教程 https://paicoding.com/column/13/1
- 已发表文章:`docs/src/sidebar/itwanger/ai/`
### 步骤 2:搜集资料 + 数据溯源
联网搜索必须带时间限定,默认只采用最近 7 天信息。
补充可引用的公开信息(公开榜单、官方基准、第三方测试),以及来自 X 的外界评价。外部引用必须保留来源链接和日期,避免"听说""网友表示"。
**准确数据必须访问原始来源**:GitHub 星标去仓库、榜单去 HuggingFace/LMSYS、跑分去官方发布。禁止二手转述。无法访问时注明"截至 YYYY-MM-DD"。
### 步骤 3:整理证据清单(先于写作)
写正文前必须整理"引用证据清单",至少包含:结论 + 来源链接 + 发布时间 + 为什么可以相信。
未检索到证据时,清单里明确标记"未检索到有效证据"。禁止伪造数据。
### 步骤 3.5:确认面试主题
用 `AskUserQuestion` 确认面试题方向(如 Agent、RAG、Spring AI、Java 基础等),以及是否有指定的项目背景(PaiAgent / 派聪明 / PaiFlow)。
参考范文:`references/PaiAgent.md`
**重要说明**:
1. **风格参考 ≠ 内容照搬**:参考范文学习语气、节奏、表达方式,内容必须大胆创新
2. **内容可以大胆**:基于你的理解和调查给真实场景、使用体验、case,不局限于 sucai.md
3. **开头结尾别老生常谈**:不要每次都套路化,根据内容特点设计有新意的开头结尾
4. **你就是二哥本人**:全文保留 1-3 个错别字在明显位置,证明是手写的内容,不是 AI 写的
### 步骤 4:撰写文章
⚠️ **撰写前必须扫一眼**「写作原则」「面试对话类专属规范」「去 AI 味」「特色元素」的硬性约束。同时读 `./references/human-tone.md`,采用二哥喜欢的用词表达和句子表述方式。
**「替换规则」表是禁用表**:该表 ❌ 列里出现过的词,全文一律不准用,必须直接用 ✅ 列对应的词,不做二次确认。这是二哥改稿反馈的沉淀,踩过一次坑就不能再踩。
文件格式 Markdown,正文目标 4000 字。初稿直接瞄 4000,留余量,避免反复补充内容。
**字数检查与调整**:
1. 初稿完成跑 `./scripts/check_body_length.py` 检查
2. ≥ 4000 字:达标,进步骤 5
3. < 4000 字:不得交付,必须一次性扩展到 4000 以上(不是卡及格线)。用 `AskUserQuestion` 给 2-3 个扩展方向,补完再检查一次。禁止每次只加几十字反复补充
文章头部模板:
```yaml
---
title: # 步骤 5.5 生成后回填
shortTitle: # 步骤 5.5 生成后回填
description: 文章描述
tag:
- 面试
category:
- AI
author: 沉默王二
date: # 用 date 命令拿到的实际日期,YYYY-MM-DD
---
```
### 步骤 4.5:交付前自检(强制)
落盘前必须逐项核对下表,**任何一项未通过,回到步骤 4 改稿,不得进入步骤 5**。
| 检查项 | 要求 | 检查方法 |
|--------|------|----------|
| 称呼 | 少用"你",用"大家/我们/小伙伴/兄弟姐妹们" | 全文检查 |
| 标点符号 | 少用"——",正常叙事 | 全文检查 |
| 开头 | 直接进入面试场景,对话制造冲突 | 查前 3 段 |
| 老王人设 | 和之前的文章不重复 | 对比已发表文章 |
| 标题层级 | `## content` + `### 01、问题` | 查所有二级标题 |
| 每题追问 | 主答 → 追问 → 补充 | 查每个三级标题 |
| 对话格式 | 叙述式,不用加粗剧本格式 | 全文检查 |
| 内心 OS | 有情绪立场,不是平淡旁白 | 查所有内心 OS |
| 截图占位符 | 每个章节至少 1 个占位符,长的章节至少 3 个占位符 | 查各章节 |
| 字数 | 正文 ≥ 4000 字(不含代码) | `./scripts/check_body_length.py` |
| 引用溯源 | 外部结论有来源链接和日期 | 查引用证据清单 |
| 原始数据 | GitHub 星标、榜单、跑分必须来自原始来源 | 查数据段落 |
| 错别字 | 留 3 个错别字在明显位置(手写的证明) | 全文检查 |
| AI 味 | 通过"去 AI 味"章节全部检查 | 全文检查 |
| 替换规则 | `human-tone.md` 的替换规则表 ❌ 列词一律不得出现 | grep 全文 |
| ending | 有简历模板(项目简介+技术栈+核心职责5条) | 查文末 |
### 步骤 5:落盘
文件命名用主题关键词,保存到 `docs/src/sidebar/itwanger/ai/`。frontmatter 的 title/shortTitle 先留空。
### 步骤 5.5:生成标题
正文定稿后,**强制调用 `title-generator` Skill**:
```
Skill(skill="title-generator", args="docs/src/sidebar/itwanger/ai/xxx.md")
```
title-generator 会读取正文 + `references/title-data.md`,输出 5 个候选标题。用户选定后回填 title 和 shortTitle。
### 步骤 6:沉淀改稿反馈(交稿后)
当二哥改完稿、说"学习一下二哥的写作风格"时,执行这个流程。**降低二哥改稿成本的核心机制**——踩过的坑要记住,下次不再踩。
**执行步骤**:
1. 从生成的版本对比二哥改完稿的版本
2. 词语替换**(名词/动词/形容词替换)→ human-tone.md 的「替换规则」表
3. 用 `AskUserQuestion` 逐条问二哥:保留 / 丢弃 / 调整场景说明
4. 追加到 `./references/human-tone.md`(不删原有,只追加,不要重复追加)
5. 追加完给二哥看一眼,确认没问题再结束
**过滤原则**:拿不准的让二哥判断,不要擅自沉淀。