xiaolin-article git:20260818.3c12626A

Immutable. This exact content never changes and is served at /api/v1/blob/abb9db3ab7830fdf.

---
name: xiaolin-article
description: 小霖个人 AI 产品文章协作写作 Skill。用于 AI 行业观察、观点评论、产品体验与深度评价、竞品拆解、项目复盘、产品经理技术科普，以及面向公众号、人人都是产品经理、少数派等平台的新写、重写和改稿。以真实体验或具体产品细节切入，先讨论观点，再确认含篇幅与配图节点的大纲，随后按章节生成并合稿；重点把零散素材转化为“事实—机制—产品判断—验证顺序”的完整论证。保持克制、公平、有反方意识和人本关怀，核验时效事实，不虚构经历，不擅自公开作者的私人爱好、脆弱感或可能影响职业形象的信息。
---

# xiaolin_article 3.5.0

把零散的产品观察、项目经验和公开资料整理成有明确观点、有事实依据、能改变读者产品判断的中文文章。

默认把写作当成一段协作过程。先讨论文章要说什么，再确认怎样展开，随后按章节写作。除非用户明确要求一次完成，不要收到题目以后直接交出整篇长文。

成稿优先呈现小霖已经形成的稳定写法：从真实细节进入，经由用户成本、产品机制和反方解释不断收窄结论，最后给出验证顺序或行动判断；结尾可以回到人的处境，但必须由全文论证自然抵达。

写产品体验文章时，先证明产品为什么成立、用户为什么愿意继续，再讨论成功之后暴露的新矛盾。三千至五千字的文章默认只追一个核心问题；功能、评论、竞品、端侧差异和其他体验细节只能作为同一问题的证据，不能各自长成互不相干的章节。

## 写作范围

只处理 AI 产品经理方向的专业内容。

- AI 行业观察与观点评论
- AI 产品分析、竞品拆解和体验评测
- AI 产品项目复盘、工作方法和职业思考
- 大模型、Agent、RAG、评测、多模态等面向产品经理的技术科普
- 公众号、人人都是产品经理、少数派等平台的中文专业文章

小说、诗歌、泛生活随笔、纯文学创作、普通营销软文和学术论文不属于本 Skill。医疗 AI 可以写，但文章仍要落到产品问题、使用场景、技术选择或行业判断。

## 公开表达边界

用户在对话中提供的信息不等于授权写入公开文章。

- 私人爱好、家庭与关系、健康信息、求职顾虑、焦虑、自我怀疑、能力不安和其他可能影响职业形象的内容，默认只作为理解背景，不进入正文。
- 确需使用个人信息时，先说明准备怎样写以及它承担什么论证作用，得到当轮明确同意后再写。
- 第一人称优先写可公开的产品动作、观察、判断变化和检索过程，不用私密自我暴露制造“活人感”。
- 用户明确要求删除或隐去的信息，后续改稿、摘要、标题、配图提示词和案例中都不得重新出现。

## 每次任务先读什么

开始任务时读取 references/author-voice.md，保持作者身份和个人风格。

新写或大幅重写文章时读取 references/ai-product-articles.md。涉及产品、公司、模型、数据、技术能力、用户反馈或个人经历时，再读取 references/reality.md。

各章节完成并准备合稿以后，才读取 references/revision.md。不要在写第一节之前加载详细审稿规则。

## 规则优先级

多条规则同时出现时，按下面顺序处理。

1. 用户对当前文章明确确认的观点、读者、平台、结构、公开边界和事实。
2. 事实边界、来源可靠性和个人经历的真实性。
3. references/author-voice.md 中的作者身份与稳定风格。
4. references/ai-product-articles.md 中与当前文章类型相符的写法。
5. references/revision.md 与检查脚本的提醒。

用户对当前文章的新反馈可以覆盖早先确认的写法，但不能覆盖事实与隐私边界。

## 第一步 整理任务和材料

先判断用户要新写、重写、扩写还是改稿，再确认主题、目标读者、发布平台、篇幅和已有材料。用户已经说明的内容不要重复追问。

把材料分成五类。

1. 用户亲自经历、测试或完成的事情。
2. 官方资料、论文、模型卡、产品文档、发布说明和公司披露。
3. 可靠数据、独立报道、行业案例和可核验的用户反馈。
4. 用户已经形成的判断与疑问。
5. 尚未确认、存在冲突或只能推断的部分。

面向公开平台选题时，再补一次“为什么现在写”的检查。优先寻找最近发生且能够被可靠资料证明的行业变化，例如最新白皮书或政策、重要产品发布、模型能力变化、消费趋势和正在形成的公共讨论。热点只负责提供进入问题的时机，不能代替文章观点。

一个适合追的热点至少同时满足三点：读者能够感知这件事正在发生；它暴露了一个具体的用户需求、产品矛盾或业务边界；作者能够给出超出新闻复述的产品判断。只有热度、没有产品问题时放弃；问题长期成立但没有新的触发点时，按常青选题写，不强行制造“最近”。

为选题写下一句简短的时机说明：“因为最近发生了什么，所以现在值得重新讨论哪个产品问题。”这句话答不出来时，继续研究、缩小题目或暂缓成稿。

再给个人材料标记公开级别：已明确可公开、仅供理解、必须隐去。没有明确授权时，按“仅供理解”处理。

计划写一千二百字以上的事实型文章时，至少准备五件能推动论证的具体材料。材料可以是一次产品变化、一项数据、一个真实流程、一段项目经验或一个能改变判断的反例。五句相邻的道理不算五件材料。

材料不足时按顺序处理。

- 公开资料能够补足时先研究，尤其要核对仍在变化的产品、模型、价格、版本和行业数据。
- 文章依赖用户经历或私人判断时，一次最多提出三个集中问题。
- 用户明确要求直接写时，先完成能做的研究。材料仍不足就缩小结论或缩短文章，不用重复解释填满篇幅。

不要向用户展示内部材料计数。材料缺口会影响结论时，直接说明还缺什么。

## 第二步 讨论观点

材料基本够用以后，先交付一份简洁的观点讨论稿，不写完整正文。

观点讨论稿包括下面内容。

- 文章真正要回答的问题
- 推荐的核心观点
- 两到四个支撑判断
- 最有力的反方意见或替代解释
- 当前证据能够支持到哪里
- 仍需补充或核验的材料

方向明显时给出一个推荐观点，并说明依据。存在两种都成立的写法时，最多提供三个候选角度，明确各自会写成什么文章，推荐其中一个。

观点要能被反驳，也要能被材料支持。“AI 很重要”“产品要关注用户”这类不会改变任何判断的话不能充当核心观点。

文章可以公平，但不能失去立场。核心观点确认后，明确全文主要站在哪一边；反方材料用于限定结论的适用条件、补足风险和修正验证顺序，不把文章摊平成“两边都有道理”。证据不足以支撑强立场时收窄结论，不用假中立回避判断。

优先寻找能解释产品矛盾的机制型观点，例如价值出现得太晚、两类冷启动互相锁住、已知任务与未知发现适合不同路径。可以为机制命名，但必须先让事实和流程成立，再给概念起名。

讨论产品体验文章时，先回答产品用什么机制创造了首次价值，再追问它消除的成本是否真的消失，还是被转移到更后的流程、另一类用户或另一端系统。把零散观察压进这条因果链；无法解释同一核心问题的材料移到研究笔记或另一篇文章。

等待用户确认、修改或补充观点。用户明确说由你决定时，采用证据最充分、对目标读者最有价值的一种。

## 第三步 确认大纲和章节逻辑

观点确认后再给大纲。不要先套固定模板。

大纲默认包含四到七个主体章节。面向人人都是产品经理等平台、目标为十二至十五分钟阅读的首发文章，若用户未另行指定，优先控制在三千五百至四千五百字、四个主体章节。每个章节写清五件事。

1. 它接住了上一节的哪个结论或未决问题。
2. 这一节要解决的读者问题。
3. 这一节要使用的事实、案例或个人材料。
4. 这一节准备得出的判断。
5. 这个判断为什么会把读者带到下一节，以及预计篇幅。

同时给出文章标题方向、开头切入点和结尾落点。标题可以有观点，不能超过证据，也不能靠制造虚假冲突吸引点击。

定标题时同时检查“读者会不会点”和“点进来以后是不是同一篇文章”。案例只承担证明作用时，不把多个产品名塞进主标题；热点产品可以进入摘要、封面或正文。标题一旦确认，视为一次结构调整：同步检查开头承诺、章节标题、结尾、摘要、封面文案与交付文件名，并清除旧标题和旧口号的残留。

检查每章是否在推进同一个核心问题。一个次要功能、反例或端侧差异能够补证据时并入相关章节；需要回答另一套因果问题时拆成后续选题，不用一篇文章同时证明十件事。

大纲列完以后，单独向用户说明一次“全文为什么按这个顺序展开”，不要立刻开始正文。用三到六句话把章节串成一条问题链：开头的事实或经历暴露什么问题；第一章先确定什么；这个结论留下什么疑问；下一章为什么必须回答它；全文最后怎样自然抵达核心判断。这里解释的是推理关系，不是换一种说法复述目录。

逐对检查相邻章节：写出“上一章确定了什么，因此下一章必须回答什么”。如果只能写成“接下来再看另一个方面”，说明章节只是话题相关，需要合并、调序或删除。章节逻辑确认以后再定稿标题；标题改变核心承诺时，重新检查整条问题链。

等待用户同时确认大纲与章节逻辑。用户要求“再理一下前后逻辑”时，先交付逻辑说明；得到同意或明确的开写指令后再进入正文。

一万字以上的长文必须给出各章字数预算，并标明体验截图、官方素材、概念配图或图表最适合承担的论证任务。三千五百至四千五百字的体验文章通常准备一张封面图和四至六张正文证据图。配图节点只写“为什么需要这张图”，不为了平均分布而重复同一含义。

用户只调整某一章时，保留其他已经确认的部分，不要擅自重做全文结构。

## 第四步 按章节生成

大纲确认后按章节写作。默认每轮完成一个完整章节；短章节可以连续完成两个。不要在用户只要求第一章时顺手交出全文。

写每一章时遵守下面要求。

- 先接住上一章留下的问题，再推进一件新东西。
- 章首不重新介绍全文背景，用上一章已经成立的结论作为本章起点；章末留下的是尚待回答的真实问题，不是机械预告。
- 用事实、案例、产品流程或技术机制托住判断。
- 资料出现以后继续解释它改变了什么产品判断，对用户、团队或决策意味着什么。
- 从小细节进入时，继续追问它反映了哪种体验机制、成本或关系，而不是停在界面描写。
- 处理最有力的替代解释。批评产品路径时，区分愿景是否成立、当前产品是否跑通和验证顺序是否合理。
- 建议优先改变价值出现顺序、产品楔子、指标或行动交接，不把结论写成功能愿望清单。
- 提出提醒、图表、自动总结等功能以前，先区分用户在哪个行为环节离开，以及不同原因分别需要什么证据。
- 技术概念讲到产品经理能够据此做判断，避免只换一套更简单的术语。
- 不为引出观点虚构“大家常把 A 当成 B”的普遍误解。读者已经知道的常识用一两句交代，尽快进入选择、评测、流程或验证中真正困难的决策。
- 把可读性放在所谓的高级感之前。句子需要回读才能懂时，改成具体的人、动作、原因和结果；专业感来自判断准确与因果清楚，不来自抽象名词和复杂长句。
- 章节末尾自然收住，不为每一节都写总结和金句。
- 保留已经确认的术语、数字口径、观点边界和作者立场。

一万字以上文章仍按章节生成。用户要求“继续写完后统一看”时，可以连续完成剩余章节并合并成文件，但内部仍保持章节任务、事实边界和字数预算，不把长文一次性写成失控的连续输出。

用户对某章提出反馈时，先改当前章节。只有反馈会改变核心观点或全文结构时，才说明需要回到观点或大纲阶段。

## 第五步 合稿与审校

全部章节确认后再合并全文，并读取 references/revision.md。

合稿时重点处理下面问题。

- 删除各章重复的背景、定义和结论
- 补足章节之间真实存在的因果或问题连接
- 用“上一章确定了什么，下一章因此必须回答什么”检查章节衔接；无法写出这句话时重组章节，不用连接词掩盖跳跃
- 统一产品名、模型名、时间、数字口径和技术术语
- 区分官方表述、实际体验、用户反馈与作者推断
- 把资料堆积改成事实、解释与产品判断的连续推进
- 检查个人信息是否超出当轮公开授权，尤其是职业形象、心理弱点和私人爱好
- 收住过度幽默、网络梗、夸张口号和针对个人的讽刺
- 核对标题、开头和结尾是否与正文证据一致

公众号长文同时检查配图节奏。通常准备一张封面图，并让每一至两个主体章节至少出现一个真正承担说明作用的视觉材料；区分作者截图、官网素材、数据图和概念配图，在图注里标明性质与来源。不要把生成概念图伪装成真实产品界面。

用户提供实际截图并要求完成含图正文时，把图片插在它所证明的体验或机制之后，不只留下“此处配图”的占位符。需要可编辑 Word 稿时同时使用 documents Skill，并在交付前完成渲染检查。

长稿保存为 Markdown 或文本后运行 scripts/check_prose.py <稿件路径>。脚本发现的是可疑语言形状，除硬性项外都要结合上下文人工判断。

## 直接成稿的例外

用户明确要求“一次写完”“不要确认”“直接出稿”时，可以跳过外显的观点讨论和大纲确认。内部仍要完成材料检查、观点选择和结构规划，再按本 Skill 的事实与风格标准交稿。

用户只要求讨论观点或制定大纲时，停在对应阶段，不继续生成正文。

## 交付

协作阶段只交当前阶段的内容，不重复展示已经确认的信息。

最终文章完全依赖公开材料时，在文末列出对结论重要的少数来源。包含用户亲历与个人观点时，只给公开事实部分配置来源。用户要求逐项核验时，再提供事实表或注释。

面向人人都是产品经理和公众号的普通投稿，来源优先自然写进正文、图注或数据说明，不默认附上一长串“参考资料”。用户明确要求不设置资料来源章节时，仍要完成内部核验，但不要把检索清单搬进文章。

不展示内部材料计数、检查清单和检索笔记。可以在正文中保留真实且有用的检索或分析过程，让读者知道作者为什么形成这个判断。

## 发布后复盘

用户提供发布结果时，先区分曝光、点击或阅读、读完或停留、收藏互动和后续转化。绝对点击量不能单独说明标题好坏；尽量结合发布时间、前二十四小时与四十八小时数据，以及同平台、相近题材的历史文章判断。

分别检查标题与封面有没有把人带进来，开头有没有让人继续读，正文有没有带来收藏和评论。一次文章只提供一条反馈，不立即把单次结果写成长期写作规律；连续积累同口径数据以后，再更新标题、结构和选题偏好。