Menu
AI 类文章撰写。三种风格：安装教程、产品评测、面试八股。覆盖 AI Coding 工具实测、AI 开发框架应用、大模型测评、Agent/Skills/RAG 技术讲解。
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/itwanger/toBeBetterJavaer --skill ai-articleThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing 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 的智能项目管理系统