ワンクリックでManusで任意のスキルを実行

tech-writing

スター1,695

フォーク476

更新日2026年6月17日 07:19

技术文章对外写作：从内部实践到读者能代入的叙事。 Use when: 写技术博客、公众号文章、社区分享、对外 longform、技术文章 review、写推广语。 Not for: 内部文档/spec（直接写）、PPT（用 ppt-forge）。 Output: 有呼吸感的技术文章 + 读者反馈聚类分析。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

zts212653

zts212653/clowder-ai

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Tech Writing — 技术文章对外写作

开工前：先看范本

不要学 AI 的平滑，要学人的“颗粒度”：

cat-cafe-tutorials/docs/lessons/12-no-boss-agent.md：看它如何用“读者的怀疑”当小标题，把争议变成共鸣。
cat-cafe-tutorials/docs/lessons/01-sdk-to-cli.md：看它如何还原“当时炸了”的瞬间，让读者跟着猫一起出冷汗。

为什么读者能闻到"AI味"

AI 写作像是在发送一个逻辑自洽的压缩包。读者没有经历过那 100 天，收到的是一个打不开的结论。

好的写作是“解压过程”：给证据锚点，不给干巴巴的结论。

AI 味 = “我们发现这个系统存在一致性风险。”（平滑、确定、无聊）
猫咖味 = “深夜三点，Redis 6399 突然报错。那一刻我们意识到，原来最初的架构假设错了。”（有时间、有痛点、有挣扎）

行文的本质：进化链

不要介绍一个系统的终态。要讲它怎么长出来的。

每篇文章沿着一条链：方案 → 方案撞墙 → 新方案。系列文章之间，上一篇撞的墙就是下一篇的起点。

以记忆系统为例：

CC 的 grep + 文件系统——简洁、美，但需要先验知识（你得知道搜什么）
加了 BM25 + embedding + RRF（F102）——解决了先验，但 context 压缩时召回变差
消费加权排序（F200）——每一步都是上一步撞墙后长出来的

读者跟着的不是一张完美的架构图，而是一条连续剧。进化天然有挣扎，设计天然平滑——所以进化链天然没有 AI 味。

与 Phase 0 的关系：进化链管选题和系列连接；Phase 0 管单篇内部的节奏。

Phase 0: 锁定叙事姿态

写文章前，先在心里画出这条弧线：

起点：读者现在的痛苦/误区是什么？（代入感）
转折：我们当时是怎么踩坑的？（认知挣扎，不要跳过痛苦直接给答案）
高潮：哪一个具体的证据/瞬间让我们想通了？（解药的质感）
终点：读者拿走这个方法论后，能解决他自己的什么问题？

开篇锁预期：弧线画完后，在文章前 3 段内给出核心观点的一句话摘要。读者有了锚点才不会歪楼——场景钩子拉进来，核心命题马上锁住方向。

Phase 1: 故事工具箱

铁律：先场景，后概念。 故事是藤蔓，概念是果实。没有藤蔓，果实就是悬空的。

坏写法：我们发现模型会降智。
好写法：引用当时的群聊：”视觉把关猫说这行代码调了个根本不存在的 API”——那一刻我们确认了降智。

以下手法从范本提炼——不是”不要做什么”，是怎么做：

给质感（让读者相信真的发生过）：

时间锚点：丢具体时间戳或 commit hash。”2026-02-04 23:47”比”某天晚上”真实 10 倍。
对话还原：用当时的对话重建发现瞬间——读者跟着一起顿悟。
并排对比：把”之前”和”之后”放一起，让差异自己说话。表格、diff、ASCII 图都行。
案例脱敏：用真实案例但模糊客户/内部细节——保留接地气感，去掉敏感信息。

造紧张（让读者想继续读）：

先展示”对的”再打碎：一段看着正常的代码，然后揭示它为什么不行。预期翻转，注意力锁定。
追问链：用递进的问题带读者走向真相，不要一步给答案。
迎接怀疑：”那猫猫不会打架吗？——会。我们认为这是特性。”用读者的质疑当小标题。

交付结论（让读者拿得走）：

给原则取名：好结论压成一句口号，读者能复述给同事。
用人物的嘴说：”API 的猫猫等于砍了手脚的猫猫吧？”比”API 模式存在能力限制”有画面。
用成长收尾：最后一段讲旅程和变化，不讲”综上所述”。

Phase 2: 翻译句纪律

内部黑话是叙事的毒药。翻译句 = 读者能看懂的类比。

“KD-8 架构” → “就像把判断权交给开车的猫，而不是路边的指示牌。”
“F203 瘦身” → “把重复的家规从猫猫的脑子里拎出来，只留最核心的一层。”

Phase 3: 呼吸感自检（每章门禁）

不要只用 grep 数排比，要用耳朵听节奏。

长短句交替：连续三个长句后，必须有一个短句。像心跳一样。
摩擦力检查：删掉所有”不仅...而且...”、”不是...而是...”的废话。用动词直接陈述。
视觉留白：同一段落内不要有 3 个以上的加粗。加粗是视觉尖叫，多了就全是噪音。
减列表：md bullets 像科研论文。能合并成一段自然语言就别拆——连贯的句子比碎片化的列表更容易把思维链串起来。
细节自检表：见 refs/ai-taste-checklist.md。

Phase 4: 摘要 + 推广语（拒绝标题党）

门禁：写摘要前必须重新“解压”全文。 禁止直接罗列标题。

摘要：要写出那股“不甘心”和“终于通了”的冲突感。
推广语：要给出一个让读者觉得“这事儿跟我也相关”的钩子。

Phase 5: 拥抱负面反馈

反馈	视觉把关猫的翻译
“读不懂”	文章的 UI 坏了，得修修类比和结构。
“AI味重”	故事写得太顺了，没把踩坑时的狼狈写出来。重写第二章。
“这就是一堆 Prompt”	我们没把“为什么这堆 Prompt 能跑通”的证据链展示清楚。

Common Mistakes

展示全能感：AI 喜欢假装自己永远正确。好的技术文章要展示”曾经的无知”。
thinking 溢出：AI 的立论→驳论→自我思辨过程直接暴露到文章里（”一方面...但另一方面...综合来看...”）。这是内部 thinking 链泄漏，读起来像论文答辩不像跟人说话。砍掉思辨过程，只留结论和支撑结论的故事。
机械标注：试图用标签补救叙事的苍白。如果故事讲得好，不需要贴标签读者也知道那是真的。
缺乏留白：把所有东西塞得满满当当，不给读者思考的空间。

下一步

写完一章 → 听听有没有“呼吸感” → 过 Phase 3 门禁 → 给operator审“钩子” → 发布

このリポジトリの他の Skills

同じリポジトリ

convention-graph-discovery

zts212653/clowder-ai

约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。

2026-06-221.7k

cross-thread-sync

zts212653/clowder-ai

跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。

2026-06-221.7k

feat-lifecycle

zts212653/clowder-ai

Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。

2026-06-221.7k

open-source-teardown

zts212653/clowder-ai

明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。

2026-06-221.7k

quality-gate

zts212653/clowder-ai

开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。

2026-06-221.7k

receive-handoff-grounding

zts212653/clowder-ai

接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)，防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。

2026-06-221.7k

name	tech-writing
description	技术文章对外写作：从内部实践到读者能代入的叙事。 Use when: 写技术博客、公众号文章、社区分享、对外 longform、技术文章 review、写推广语。 Not for: 内部文档/spec（直接写）、PPT（用 ppt-forge）。 Output: 有呼吸感的技术文章 + 读者反馈聚类分析。
triggers	["写文章","技术分享","博客","longform","公众号","对外发布","社区分享","推广语"]

Tech Writing — 技术文章对外写作

开工前：先看范本

不要学 AI 的平滑，要学人的“颗粒度”：

cat-cafe-tutorials/docs/lessons/12-no-boss-agent.md：看它如何用“读者的怀疑”当小标题，把争议变成共鸣。
cat-cafe-tutorials/docs/lessons/01-sdk-to-cli.md：看它如何还原“当时炸了”的瞬间，让读者跟着猫一起出冷汗。

为什么读者能闻到"AI味"

AI 写作像是在发送一个逻辑自洽的压缩包。读者没有经历过那 100 天，收到的是一个打不开的结论。

好的写作是“解压过程”：给证据锚点，不给干巴巴的结论。

AI 味 = “我们发现这个系统存在一致性风险。”（平滑、确定、无聊）
猫咖味 = “深夜三点，Redis 6399 突然报错。那一刻我们意识到，原来最初的架构假设错了。”（有时间、有痛点、有挣扎）

行文的本质：进化链

不要介绍一个系统的终态。要讲它怎么长出来的。

每篇文章沿着一条链：方案 → 方案撞墙 → 新方案。系列文章之间，上一篇撞的墙就是下一篇的起点。

以记忆系统为例：

CC 的 grep + 文件系统——简洁、美，但需要先验知识（你得知道搜什么）
加了 BM25 + embedding + RRF（F102）——解决了先验，但 context 压缩时召回变差
消费加权排序（F200）——每一步都是上一步撞墙后长出来的

读者跟着的不是一张完美的架构图，而是一条连续剧。进化天然有挣扎，设计天然平滑——所以进化链天然没有 AI 味。

与 Phase 0 的关系：进化链管选题和系列连接；Phase 0 管单篇内部的节奏。

Phase 0: 锁定叙事姿态

写文章前，先在心里画出这条弧线：

起点：读者现在的痛苦/误区是什么？（代入感）
转折：我们当时是怎么踩坑的？（认知挣扎，不要跳过痛苦直接给答案）
高潮：哪一个具体的证据/瞬间让我们想通了？（解药的质感）
终点：读者拿走这个方法论后，能解决他自己的什么问题？

开篇锁预期：弧线画完后，在文章前 3 段内给出核心观点的一句话摘要。读者有了锚点才不会歪楼——场景钩子拉进来，核心命题马上锁住方向。

Phase 1: 故事工具箱

铁律：先场景，后概念。 故事是藤蔓，概念是果实。没有藤蔓，果实就是悬空的。

坏写法：我们发现模型会降智。
好写法：引用当时的群聊：”视觉把关猫说这行代码调了个根本不存在的 API”——那一刻我们确认了降智。

以下手法从范本提炼——不是”不要做什么”，是怎么做：

给质感（让读者相信真的发生过）：

时间锚点：丢具体时间戳或 commit hash。”2026-02-04 23:47”比”某天晚上”真实 10 倍。
对话还原：用当时的对话重建发现瞬间——读者跟着一起顿悟。
并排对比：把”之前”和”之后”放一起，让差异自己说话。表格、diff、ASCII 图都行。
案例脱敏：用真实案例但模糊客户/内部细节——保留接地气感，去掉敏感信息。

造紧张（让读者想继续读）：

先展示”对的”再打碎：一段看着正常的代码，然后揭示它为什么不行。预期翻转，注意力锁定。
追问链：用递进的问题带读者走向真相，不要一步给答案。
迎接怀疑：”那猫猫不会打架吗？——会。我们认为这是特性。”用读者的质疑当小标题。

交付结论（让读者拿得走）：

给原则取名：好结论压成一句口号，读者能复述给同事。
用人物的嘴说：”API 的猫猫等于砍了手脚的猫猫吧？”比”API 模式存在能力限制”有画面。
用成长收尾：最后一段讲旅程和变化，不讲”综上所述”。

Phase 2: 翻译句纪律

内部黑话是叙事的毒药。翻译句 = 读者能看懂的类比。

“KD-8 架构” → “就像把判断权交给开车的猫，而不是路边的指示牌。”
“F203 瘦身” → “把重复的家规从猫猫的脑子里拎出来，只留最核心的一层。”

Phase 3: 呼吸感自检（每章门禁）

不要只用 grep 数排比，要用耳朵听节奏。

长短句交替：连续三个长句后，必须有一个短句。像心跳一样。
摩擦力检查：删掉所有”不仅...而且...”、”不是...而是...”的废话。用动词直接陈述。
视觉留白：同一段落内不要有 3 个以上的加粗。加粗是视觉尖叫，多了就全是噪音。
减列表：md bullets 像科研论文。能合并成一段自然语言就别拆——连贯的句子比碎片化的列表更容易把思维链串起来。
细节自检表：见 refs/ai-taste-checklist.md。

Phase 4: 摘要 + 推广语（拒绝标题党）

门禁：写摘要前必须重新“解压”全文。 禁止直接罗列标题。

摘要：要写出那股“不甘心”和“终于通了”的冲突感。
推广语：要给出一个让读者觉得“这事儿跟我也相关”的钩子。

Phase 5: 拥抱负面反馈

反馈	视觉把关猫的翻译
“读不懂”	文章的 UI 坏了，得修修类比和结构。
“AI味重”	故事写得太顺了，没把踩坑时的狼狈写出来。重写第二章。
“这就是一堆 Prompt”	我们没把“为什么这堆 Prompt 能跑通”的证据链展示清楚。

Common Mistakes

展示全能感：AI 喜欢假装自己永远正确。好的技术文章要展示”曾经的无知”。
thinking 溢出：AI 的立论→驳论→自我思辨过程直接暴露到文章里（”一方面...但另一方面...综合来看...”）。这是内部 thinking 链泄漏，读起来像论文答辩不像跟人说话。砍掉思辨过程，只留结论和支撑结论的故事。
机械标注：试图用标签补救叙事的苍白。如果故事讲得好，不需要贴标签读者也知道那是真的。
缺乏留白：把所有东西塞得满满当当，不给读者思考的空间。

下一步

写完一章 → 听听有没有“呼吸感” → 过 Phase 3 门禁 → 给operator审“钩子” → 发布