메뉴
技术书籍章节写作风格指南。融合反模板化叙事结构与段落级流畅性控制技法。 当用户要求写新的书籍章节、重写现有章节、优化文章可读性、或讨论技术写作风格时使用。 触发场景：写章节、重写、改写、优化文章、写作风格、叙事结构、可读性、 “换个切入方式”“这段太干了”“读者会流失”。 即使用户没有明确提到写作风格，只要任务涉及产出或修改技术书籍的正文内容，就应该参考本 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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? 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 机制在效率和正确性之间取得了平衡。
强： 上下文不是一个字符串，是一条装配线。
文章前半段（建立问题感和直觉的阶段）不出现代码块。代码会吓跑初级读者。
前半段用：
代码不是"给读者看看长什么样"。代码是证据——证明一个文字无法独立验证的判断。
出场前必须有铺垫：
出场后必须有解释：
写完一章后，过一遍：
