メニュー
技术书籍章节写作风格指南。融合反模板化叙事结构与段落级流畅性控制技法。 当用户要求写新的书籍章节、重写现有章节、优化文章可读性、或讨论技术写作风格时使用。 触发场景：写章节、重写、改写、优化文章、写作风格、叙事结构、可读性、 “换个切入方式”“这段太干了”“读者会流失”。 即使用户没有明确提到写作风格，只要任务涉及产出或修改技术书籍的正文内容，就应该参考本 skill。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/luochang212/codex-notebook --skill tech-book-writingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | tech-book-writing |
| description | 技术书籍章节写作风格指南。融合反模板化叙事结构与段落级流畅性控制技法。 当用户要求写新的书籍章节、重写现有章节、优化文章可读性、或讨论技术写作风格时使用。 触发场景：写章节、重写、改写、优化文章、写作风格、叙事结构、可读性、 “换个切入方式”“这段太干了”“读者会流失”。 即使用户没有明确提到写作风格，只要任务涉及产出或修改技术书籍的正文内容，就应该参考本 skill。 |
两个核心维度：
前者解决“章与章之间不能雷同”，后者解决“段与段之间不能断裂”。
技术书最大的可读性杀手是"所有章节读起来一样"。读者在第三章就能预测第四章的结构，阅读变成了填表。
每章开写前，先问自己：这一章的内容特质是什么？什么叙事结构最适配它？
| 切入方式 | 适合内容 | 例子 |
|---|---|---|
| 悬疑/侦探 | 排查 bug、追踪数据流 | "配置没生效。你检查了三个地方都没问题。第四个地方你根本没想到。" |
| 个人发现 | 首次理解某个机制 | "我一直以为 X 是这样工作的。直到我读了源码。" |
| 问答/对话 | 概念辨析、常见误解 | "每步都全量注入不行吗？可以，但贵。" |
| 类比贯穿 | 抽象机制需要直觉 | 报纸底版与增量、餐厅菜单与厨房 |
| 张力/续写 | 上一章留下的悬念 | "上一章说了知识不是能力。那能力从哪来？" |
| 鸟瞰回顾 | 总结章、哲学章 | 每章一句话概括，然后找共同模式 |
| 痛点-解法 | 工程决策、取舍分析 | "20 条命令点 20 次确认。你受得了吗？" |
| 时间线叙事 | 生命周期、状态迁移 | "下午两点你开始重构。到四点，context window 快满了。" |
每段只承载一个念头。长度尽量控制在 3 句左右。
读者在手机上看你的文章。一个 6 句的段落在手机上是半屏的文字墙。他们会跳过。
反面：
Codex 的上下文构造采用 baseline/diff 机制。首次全量注入后，后续每步只做增量。这样做的好处是保护前缀不变，从而命中 prompt cache。cache 命中可以显著降低 token 费用。但代价是调试困难，因为你无法在一个地方看到完整的 system prompt。
正面：
第一步，系统注入所有东西。这是底版。
从第二步开始，只告诉模型"什么变了"。底版不动。
为什么？因为前缀不能变。变了就浪费钱。
段落之间的衔接不靠"接下来""此外""另外"这类结构标记词。靠的是上一段末句制造的问题/张力，被下一段首句接住。
弱转场：
……cache 就 miss。
接下来我们看看 compaction 机制。
强转场：
……cache 就 miss。
那如果对话太长了呢？128K 的窗口，40 轮对话就满了。系统必须做点什么。
用具体数字替代形容词。数字制造画面感，形容词制造模糊感。
| 弱 | 强 |
|---|---|
| 很多 token | 110K token |
| 等很久 | 90 秒超时 |
| 大幅降低 | 从 20 次审批降到 0-2 次 |
| 很快 | 200ms 初始退避，每次翻倍 |
注意：数字必须来自源码或可验证的事实。不要为了画面感编造数字。
能引用源码注释/变量名/函数名的时候，直接引用。引用比转述更可信，也更精确。
转述： 系统会在压缩后警告用户准确性可能下降。
引用： 系统发送一条 Warning："长线程和多次压缩可能降低准确性，建议开新线程。"
比喻不是装饰。好的比喻构成分析框架——读者可以用它推理后续问题。
装饰性比喻： 沙箱就像一个保护罩。（然后呢？保护什么？怎么保护？读者还是不知道。）
分析性比喻： 底版不动，增量追加。就像报纸印刷——底版校准一次很贵，所以底版不变，只换今天的新闻。（读者立刻能推理：如果底版变了会怎样？校准成本。如果增量太多会怎样？版面不够→compaction。）
适度使用"我"表达真实的困惑。这建立可信度——读者知道作者也是人，也会犯错。
说实话，第一次看到这个空文件时我觉得这是个 bug。
但不要滥用。每章最多 2-3 处。第一人称是调味料，不是主菜。
每个 section 的最后一句应该是可记忆的——一个判断、一个对比、一个反转。不是总结性陈述。
弱： 综上所述，baseline/diff 机制在效率和正确性之间取得了平衡。
强： 上下文不是一个字符串，是一条装配线。
文章前半段（建立问题感和直觉的阶段）不出现代码块。代码会吓跑初级读者。
前半段用：
代码不是"给读者看看长什么样"。代码是证据——证明一个文字无法独立验证的判断。
出场前必须有铺垫：
出场后必须有解释：
写完一章后，过一遍：
