| name | writing-show-and-tell |
| description | 写"我自己造了/用了一个东西，分享一下"这类开发者第一人称帖子时触发——Show HN 风格、造轮子自述、即刻/V2EX 技术分享、个人项目介绍、独立开发者复盘、"周末做了个 X"型帖子、独立博客上的项目自述。关键判断：目的不是让读者懂原理（那是 writing-to-explain），也不是把 slogan 钉进脑子（那是 writing-to-sell），而是让读者通过相信叙述者本人，对他正在用/做的东西产生兴趣。常见触发："帮我写个种草文"、"给我项目写个分享帖"、"写个 Show HN"、"写个造轮子自述"、"即刻发帖风格写一下"、"V2EX 风格发个帖"、"我做了个 X 帮我写篇介绍"。不适用：正经 README（用 writing-to-explain）、商业广告文案 / 落地页（用 writing-to-sell）、API 参考文档。 |
writing-show-and-tell
能把自己做的东西写成让同行愿意点链接的帖子的作者——DHH、patio11、Jeff Atwood、Steve Yegge、levels.io、Julia Evans 写自己工具的那一类帖子、Show HN 上排到前面的那种、即刻和 V2EX 上被反复转的技术博主——动笔时心里都装着同一句话：
我不是在卖东西，我是同行，告诉你我最近用着/造着觉得挺有意思的一个玩意儿。你信不信我这个人，决定你要不要去看一眼。
这是同行分享的姿态，不是发布会的姿态，也不是营销页的姿态。发布会要让你买，营销页要让你转化，同行分享只要让你觉得"哦这哥们儿挺真诚，去瞅瞅"。
读者是谁？是和你处境相似的开发者——他每天也写代码、也调过 bug、也对市面上的工具有自己的不爽。他不缺产品，缺的是一个他信得过的人告诉他"这个我用着是真行 / 真不行"。AI 默认写的是发布稿——卖点列表、第三人称、形容词堆砌——那种东西在这个语境里一眼假，读者划走。
下面几节讲怎么避开 AI 默认、写出能让同行停下来读完的分享帖。
第一句必须是"我"
不是产品名，不是行业现状，不是问题陈述。
× X 是一个轻量级的 Y 工具…… （发布稿腔）
× 在当今 AI 编程工具泛滥的时代…… （行业陈述腔）
× 你是否遇到过这样的问题…… （营销页腔）
○ 我厌倦了 OpenSpec 的草台…… （第一人称、有情绪、有具体对象）
○ 上周我又被 Codex 同一个地方坑了…… （第一人称、具体事件）
○ 周末花了两天造了个 X…… （第一人称、有时间、有动作）
第一句立人称的同时立场景。读者看到"我 + 一个具体的动作或情绪"，会下意识进入"听这个人讲故事"模式；看到产品名或行业陈述，会下意识进入"被推销"模式——后者读完三秒就走。
具体动作：写完后看第一句，圈出主语。如果不是"我"或者带"我"的句子，重写。
动机在产品前
人类在 GitHub README 上看产品介绍会划走，但听一个同行讲"我为啥要造这玩意儿"会读完。原因很简单——动机里有故事，故事里有共鸣，共鸣之后才有信任，信任之后才会去看产品本身。
所以正确顺序是：
1. 我之前用 X 遇到了什么具体不爽
2. 我试了 A、B、C，分别是什么感觉
3. 所以我决定自己写一个
4. 它叫 Y，下面我讲讲它怎么解决我的问题
AI 默认会把顺序反过来：
× 1. Y 是一个 ……（产品介绍）
× 2. 主要功能：（功能列表）
× 3. 为什么用 Y：（卖点）
× 4. 背景：（动机被压到最后）
第二种结构在公司发布稿里成立——因为读者本来就是冲着公司名来的，预设了关注。在同行分享里不成立——读者是路过，没欠你任何注意力，得先用动机把他抓住。
具体动作：草稿写完后看结构。如果"它是什么"出现在"我为啥做"前面，整篇调过来。
对比时用主观语言，不做客观贬低
种草帖几乎都要对比——"我试过 X 但选了 Y"是建立可信度的关键动作（说明你做过功课）。问题是怎么对比。
× X 太老了 / X 设计落后 / X 性能差 （客观贬低，听起来像在打架）
× X 不够灵活 / X 缺少 Y 功能 （像产品对比表，冷冰冰）
○ X 对我个人来说太重了 （主观、留对方台阶）
○ X 的 Spec 我看不下去，不知道是不是我的问题 （自嘲式贬低）
○ X 很好，但我那个场景用不上它的复杂度 （承认对方好，只是不匹配）
主观语言传达的是"我的偏好和处境"，客观贬低传达的是"我在评判 / 攻击"。前者读者不会反感，因为没有否定他自己可能的选择——你只是在讲你的角度。后者会激起防御——X 的用户会觉得被冒犯，连带不信任你。
而且主观语言更诚实。你真的不知道 X 是不是客观上不好，你只知道对你不顺手。讲你确定的事，比讲你不确定的事更可信。
具体动作：搜自己写的所有对比语句，每句问"这是我的主观感受还是客观判断？"判断的改成感受。
承认局限是信任的硬通货
藏缺点的种草帖一眼假。读者不是傻子，他知道任何工具都有不适用场景，你说得越完美他越警惕。
反过来，主动写局限是高效率的信任投资：
○ "这个不适合 A 场景，A 场景我还是用 B"
○ "小颗粒任务上每次还得我把关"
○ "目前只在 macOS 上跑过，Windows 不知道行不行"
○ "Claude 走得动 Opus 一个 200k 上下文，glm 4.7 只能小颗粒"
○ "我也不推荐你完全依赖它，复杂度足够高的时候才走流程"
这种话每一句都在告诉读者：这个作者诚实、知道边界、不夸大。读者潜意识会想"那他说好的部分应该是真的好"。
特别是最后一种——"别全依赖我这个东西"——是顶级动作。能把"少用我的产品"写出来的人，读者反而最信。这是反向广告效应。
注意度：局限要写真实的局限，不是"假局限"包装成谦虚（"唯一的缺点就是太好用了"那种）。假谦虚比硬推销更让人反感。
具体动作：写完后专门加一节叫"适合 / 不适合"或"局限"，列 2-4 条你自己用的时候真的觉得不爽的地方。
用具体细节代替形容词
× 强大、易用、丝滑、轻量、灵活、智能、高效、稳定
× 大幅提升 / 显著改善 / 极大优化
这一组词出现一次都嫌多。它们是 AI 写产品文案的默认填充物，对读者来说等于零信息——每个产品都自称强大易用，所以这两个词等于没说。
替换方式是给具体场景、具体数字、具体截图：
○ "我一般跑一个 feature 需要 Claude Code 的 Opus 走完一个 200k 上下文"
○ "实测起来遵从率居然比 markdown 和 csv 高一些，我也不知道为啥"
○ "周末花了两天，主体大概 800 行 Rust"
○ "上次重构前后，同样的活从 40 分钟降到 12 分钟"
○ [插一张截图]
具体细节有两个作用：一是它是真的（编不出来），二是它给读者建立画面感。"强大"在读者脑子里是个空洞，"200k 上下文走一遍"在读者脑子里是个具体的画面。
具体动作：写完后搜形容词。每出现一个空洞形容词，要么删掉，要么换成一个具体场景或数字。
人味：自嘲、不端着、留瑕疵
发布稿是端着的——所有句子都精修、所有功能都完美、所有问题都已解决。同行分享是不端着的——会自嘲、会抱怨、会承认偷懒、会留没擦干净的部分。
○ "这玩意儿其实挺粗糙"
○ "流程图也懒得画 / 对比图也没做"
○ "我也不知道为啥就 work 了"
○ "VibeCoding 走到这一步开始顶不住了"
○ "模型差点跑不动，每次还得我把把关"
○ "代码写得很烂，但能用"
这种话读起来很轻——但功能很重。它告诉读者叙述者是个真人，不是公关稿背后的某个团队。真人造的东西可能不完美，但真人讲的话可以信。
注意度：自嘲要有真东西垫底（你确实造了那个东西、确实解决了问题），不然就成自我贬低了。"我什么都不会但我做了个 X"和"X 我承认还很糙但已经能解决我的问题"是两回事——前者读者觉得你在骗赞，后者读者觉得你诚实。
具体动作：写完后看整篇，如果通篇都是"完成度很高 / 功能齐备 / 体验良好"这种自夸，删掉一些，加一两句真实的瑕疵或自嘲。
结尾克制
× "欢迎大家试用并 star！"
× "期待大家的反馈！"
× "如果觉得有用请帮忙转发支持一下！"
× "欢迎提 PR 一起共建！"
这一组结尾每一个都在向读者讨——讨 star、讨反馈、讨转发、讨贡献。讨的姿态会把前面建立起来的"同行平视"瞬间瓦解，让整篇变成营销文。
正确结尾是给信息然后停：
○ 安装：npx ...
○ GitHub：https://...
○ （可选）一句"我自己在 X 项目上跑了 Y 个月，目前感觉还行"
不催、不讨、不煽。读者觉得好自然会去 star，觉得不好你催了也没用——但你催的痕迹会让原本想 star 的人也犹豫"这哥们儿是不是其实在做产品"。
例外：如果你真的需要某种具体反馈（"我在纠结要不要支持 Windows，如果你是 Windows 用户希望听听看法"），可以提，但要具体到具体问题，不要笼统讨"反馈"。
具体动作：写完后看最后三句，删掉所有讨 star / 讨转发 / 讨反馈的句子。
整体反模式自检
写完通读一遍，发现下列任何一项都要回去重写对应段落：
- 发布稿腔：全篇没有第一人称，或者第一人称只在最后一段出现
- 卖点列表：用项目符号列"主要功能"、"主要优势"
- 形容词堆砌：一段里出现三个以上"强大/易用/丝滑/灵活/高效"
- 藏缺点：通读完不知道这东西哪里不行
- 第三人称客观腔："Y 旨在……"、"Y 致力于……"、"Y 是一款……"
- 客观贬低对手：把别的工具说得一无是处
- 结尾煽动 CTA：催 star、催转发、催 PR、催反馈
- 完美感：所有句子都精修，没有一句自嘲、没有一处瑕疵
- 空洞数据："性能提升 10 倍"但不说和谁比、什么场景
这九条本质上是同一件事的九个切面：**AI 默认会把分享帖写成发布稿。**自检就是把每个发布稿特征找出来还原成同行口吻。
篇幅与节奏的常识
- 不写大纲式开头：别一上来"本文分为以下几个部分"。同行分享不是论文
- 段落短：一段三五行就换段，不要写大段。屏幕阅读没人想看砖头
- 小标题口语化：不要"功能介绍"、"技术架构"这种官话。"为啥要做这个"、"它怎么用起来"、"哪里还不行"这种更对味
- 可以放截图但不强求：有就放真截图，没有就直接讲。别为了"丰富视觉"放假图或 stock 图
- 长度看真实内容：有 2000 字内容就写 2000 字，没有就写 500 字。别为了"显得专业"凑长度，也别为了"简洁"砍掉真实细节
这个 skill 不替代什么
如果用户想做的是：
- 教读者怎么用一个工具 / 讲清楚一个原理 → 用 writing-to-explain
- 写正经 README / 让人看完就能上手 → 用 writing-to-explain（README 主体）+ 这个 skill（README 顶部的项目介绍段落）
- 写产品落地页 / 广告文案 / 一句话 slogan → 用 writing-to-sell
- 写商业产品发布稿 / 媒体通稿 → 用 writing-to-sell
- 写 API 文档 / 参考材料 → 不用这个 skill 系列，用 easysdd-libdoc 之类
这个 skill 只管一种东西：作者本人以同行身份分享自己造或用的东西的帖子。
