用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/itwanger/toBeBetterJavaer --skill ai-article命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | ai-article |
| description | AI 类文章撰写。三种风格：安装教程、产品评测、面试八股。覆盖 AI Coding 工具实测、AI 开发框架应用、大模型测评、Agent/Skills/RAG 技术讲解。 |
执行前跑 date "+%Y年%m月%d日" 拿当前日期。
读者应当感觉对面有一个具体的人。这个人知道一些事，也有不知道的地方。他愿意讲细节，敢下判断，说话自然。
“活人感”不是靠口头禅、网络梗、错别字装出来的。读者觉得对面是个真人，首先因为你手上有真东西（事实、数据、经历），其次因为你说得清楚自己为什么知道这件事，最后才是语气随不随意。
用校准句检验自己的写法：
他毕业后离开上海，去了成都。那套量化程序已经跑过一段时间，他觉得可以全职试试。收入会不会稳定，当时没人知道。
这比“他关掉一条好走的路，把命运押上赌桌”更接近目标。前一种写法告诉读者他做了什么、条件是什么、风险在哪里，后一种写法什么具体信息都没给，只是在摆造型。
## 01、标题，标题只写名称，不加冒号和后缀解释AgentBudget、McpServerManager），用通俗功能描述代替（“循环预算机制”、“MCP 管理模块”）。面试场景里面试官听到一串英文类名会懵，正文叙述中只用中文功能描述，类名只在代码块里出现论坛感不等于“老铁”“兄弟们”“谢邀”“泡杯茶慢慢说”。烟头、啤酒、冷馒头、深夜屏幕和突然响起的电话，也不能凭空替文章增加真实感。
没有来源的精确时间、神态、天气、房间摆设和对白都是假细节。假细节越具体，AI 味越重。
有用的是信息来源——作者在哪里知道的这件事，起初哪里想错了，哪条材料改变了判断，哪一块到现在仍拿不准。
除非用户明确要求清单或教程，不要先把题目命名成两个成本、三层原因、四个阶段。
新段落必须增加一件新东西——事实、动作、例子、区别、后果都算。同一观点改换说法不算推进。一个技术概念解释一遍够了，不要换三种比喻再各讲一遍。
承载技术信息的句子（机制、原理、参数、步骤、结论）用词要准确无歧义，读者看一遍就懂。技术陈述和个人判断分开写——先说事实，再给观点。每个技术断言要么有出处（源码、文档、实测），要么标注“我的推断是”。出处要写明——论文标注作者和年份，数值标注来源（源码文件、文档章节、实测条件），算法名标注在哪里用的。用户拿到稿子不应该还需要自己去核实技术细节的准确性。
不承载技术信息的句子（感受、态度、经历），用自然口语。“有一说一，不黑不吹”“太用心了兄弟”“我都想给它鞠个躬”——这些好，因为真实。自嘲、预判读者反驳、情绪直给都欢迎，但不要硬造。
一句话能说清楚的事，不要两句话绕来绕去。尤其禁止同义反复和无信息量的过渡（“说完了 A，接下来看看 B”）。
“三层原因”“五个维度”“分三步”是最典型的 AI 大纲体。真人回答问题不会先宣布“有三个要点”再一条一条展开，而是直接开始讲第一件事，讲完自然过渡到第二件事。
去掉编号之后仍然可能读着像罗列——只是换了个连接词的并列结构。好的回答有起承转合：前一个点的结论引出后一个点的问题，点和点之间有因果、递进或转折，读起来像一段连贯的叙述，不像一组各自独立的要点拼接在一起。
前言是一篇独立的短文，读者只看前言就应该觉得“这个作者有东西”。
三个要素是骨架，决定前言质量的是每个要素展开的深度。正例拆解和反面模式见 references/preface-examples.md，撰写前必读。
作者是读者的同行者。引导读者学新东西的动机是“在稳定的状态下变得更好”。
判断方法只有一个：读出来像不像人说的话，人写的词语、成语、句子。 写完每一段，默读一遍，问自己：“如果我在群里发这段文字，朋友会不会觉得是 AI 写的？”觉得别扭就改，改到自然为止。
高频 AI 味特征和禁用词替换表见 references/human-tone.md，全篇适用。
文章涉及实战项目时加一段：项目名称、项目简介、技术栈、核心职责（5 条，用了什么技术栈 + 解决了什么问题 + 量化数据，不能出现自定义类名）。
每个章节（二级、三级、四级标题各算一个章节）至少 1 个占位符，四级标题也不例外——面试类文章的 #### 往往是追问展开，信息密度高，更需要配图帮助读者理解。超过 500 字的章节安排 2 个，保证图文密度——读者看了一会没看到配图就容易走神。占位符紧贴它可视化的内容，不能只出现在章节末尾。格式：
【截图：<名称>；风格：<风格>；截图目标：<证明什么>；关键词：<关键词1>、<关键词2>、<关键词3>】
风格只选 6 种：whiteboard（架构图）、skill-card（技能卡片）、data-board（数据对比）、three-layer（层级关系）、swimlane（泳道流程）、checklist-card（注意事项）。
精读 ./sucai.md，提取关键信息、数据、观点、截图。用 IKR 三维度快速评估：
素材充分：数一数手上有多少条真实材料（用户经历、具体事实、可引用的数据、直接引用的描述、明确的判断），每 1200 字至少需要 5 条。不够就缩短篇幅，或在步骤 2 补充调研。
项目相关内容必须先调查再写，不能凭通用知识猜。
| 文章类型 | 最低调查深度 |
|---|---|
| 安装教程类 | 表层：官方博客、文档、公开榜单 |
| 产品评测类 | 中层：GitHub README、issue、PR、commit 历史 |
| 面试八股类 | 深层：读源码，找到具体实现，用代码片段证明观点 |
事实核查：调查到的材料按可信度排序——直接证据（源码、文档、实测）> 官方声明 > 第三方转述 > 自己的推断（标注“我的推断是”）> 不确定的（直接说“没查到”）。核心论点必须有前两级证据支撑。
知识库优先：调查前先检查 ./knowledge/ 目录下是否有缓存调研文件。有缓存时用 git log --since="<调研日期>" 判断变更量：无变更直接用，少量变更增量补充，大量变更或无缓存则派 Sub-agent 全量调研并写入 ./knowledge/。
源码调研用 Sub-agent：读源码、grep 关键参数这些事情，交给 Sub-agent（Explore 或 general-purpose）去做，不要在主对话里直接读源码文件。源码文件动不动就几百行，在主对话里读多个文件会把上下文窗口撑满。
源码只是参考：源码实现如果不够好（设计粗糙、缺少关键机制），答案按业界最佳实践写，按面试官期望的高标准来。大纲里标注哪些答案是基于源码的、哪些是按理想方案写的，用户后续会根据这个来迭代源码。
补充可引用的公开数据（榜单、基准测试、第三方评测）。数据必须从原始来源获取，不能二手转述。访问不到的注明“截至 YYYY-MM-DD”。
分两步，都由用户决定。
第一步：选风格。用 AskUserQuestion 让用户三选一：
references/interview-style.md）references/deep-analysis.md）第二步：选参考文章。风格确定后，列出所有可选的参考文章，推荐最合适的一篇，但由用户最终决定。可选参考文章：
references/agent-mianshi-xiaomi.md — 面试对话体，直问直答节奏，Agent工程化方向，读者高赞验证references/claude-code-grep-vs-rag.md — 深度拆解体，证据-解读交织，读者高赞验证references/deepseek-tui-review.md — 产品评测体，有观点有数据references/deepseek-v4.md — 产品评测体，实测对比references/OpenClaw-install.md — 安装教程体，手把手教学用户选定后，写之前先通读这篇参考文章，学它的判断力和节奏感，不是照搬模板。
写大纲前先想清楚这几个问题（内部思考，不输出给用户）：
想清楚后，用 AskUserQuestion 或直接输出大纲，等用户确认后才进入步骤 6 撰写。大纲必须包含：
agent-mianshi-xiaomi.md 的对话体节奏”），让用户知道写出来大概什么样用户确认大纲后再动手全文撰写，避免返工。
写之前先看一遍 references/human-tone.md，找找语感。扫一眼 inbox.md 看有没有能用的素材。
文件格式 Markdown，正文目标 4400 字（给删改留余量），最终不少于 4000 字。面试文章每道题的回答目标就一个：回答清楚，让面试官认可，不限字数。
头部模板：
---
title: # 写完后回填
shortTitle: # 写完后回填
description: # 50-120 字 SEO 描述，含 2-3 个核心关键词
keywords: # 5 个搜索关键词
tag:
- Agent # 面试对话类用：- 面试
category:
- AI
author: 沉默王二
date: # YYYY-MM-DD
---
根据第一步选定的形式：
references/interview-style.md 后再写references/deep-analysis.md 后再写。核心要点：
保存之前做一轮自检。分两级：P0 必须全部通过，P1 提升质量但不影响交付。
机械检查（跑脚本或 grep）：
./scripts/check_body_length.py 检查字数 ≥ 4000python3 ./scripts/check_prose.py <稿件路径> 检查翻案腔、破折号、冒号、连词密度、句子长短变化、名词化动词等（失败的必须修，警告的自己判断）references/human-tone.md「词语」里的禁用词推进检查（每段问一句“这段新增了什么”）：
结尾压力测试：试着删掉最后两段，文章还完整吗？如果删完反而更好，就在那里收住。最后一段如果在概括全文、或者上升到时代意义、人类命运这种高度的，拉回来，回到这篇文章讲的具体的人和具体的事。
中文韵律检查（默读一遍，感受句子的节奏）：
references/human-tone.md「翻案腔禁止」一节通读检查（假装自己是第一次看这个话题的读者）：
检查有没有在演（逐段问“这段在表演吗”）：
段落压力测试：逐段检查——删掉这一段，读者会少知道什么？如果答案是“什么都不少”或者“只是换了种说法”，合并或者删掉。
最后通读（放下规则，当读者来读一遍）：
自检完成后给用户一个简短的报告。P0 的问题当场改，P1 的问题列出来让用户决定改不改。
文件命名用主题关键词，保存到 docs/src/sidebar/itwanger/ai/。
保存后整理截图来源链接清单：
## 截图来源链接
1. 【占位符名称】→ 来源链接
2. 【占位符名称】→ 来源链接
有链接的直接给链接，需要自己操作截图的标注“需自行操作”。
直接生成 5 个候选标题，不调用 title-generator Skill。素材里有现成标题直接用。
/Users/itwanger/Documents/GitHub/ 下，文章涉及项目细节时直接读源码，不要编造：
paicoding）— 前后端分离的技术社区系统，即 paicoding.compaicli）— 对标 Claude Code 的 Java Agent 命令行工具PaiAgent-one）— LangGraph4j + Spring AI 的工作流编排平台PaiSmart）— 基于 ES 混合搜索的 RAG 知识库PaiFlow）— 可视化 AI Agent 工作流编排平台，类 Dify/Coze/n8npmhub）— 基于 SpringCloud & LLM 的智能项目管理系统