菜单
Richard Powers 科技叙事张力 Skill。将普利策小说家 Richard Powers 在播客中讲到的人物洋葱、价值观冲突、事实到情感转化、语域和句法控制，迁移到泊舟的 AI/科技内容创作中。用户要求写科技人物故事、产品故事、AI 工具推文、技术科普、案例文章，或者觉得内容太干、太像参数说明、缺少冲突和生命力时，必须优先使用本 Skill。即使用户没有提到 Richard Powers，只要任务是把技术事实写得更有故事、有张力、有共鸣，也应该触发。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
为文章生成配图。分析文章结构，判断哪些位置需要什么类型的插图（infographic/flowchart/comparison/framework/timeline/scene），生成 prompt 并调用 image-gen 生成图片，最后插入文章。当用户说"配图"、"给文章加插图"、"生成文章插图"、"illustrate this article"时触发。即使用户只说"帮这篇文章配个图"也应该触发。
AI image generation with OpenAI, Google and DashScope APIs. Supports text-to-image, reference images, aspect ratios, and direct Cloudflare R2 upload. Sequential by default; parallel generation available on request. Use when user asks to generate, create, or draw images.
快速信息推文 — 用户丢过来一条推文链接、新闻、开源项目、产品动态等素材，快速消化内容，写一条信息推文，判断该引用转发还是原创发布，确认后通过 xurl 直接发送。当用户说"帮我转发这个"、"这个发一条推"、"帮我分享这个"、"这条推翻译一下发出去"、"写个推发出去"并附带了链接或素材时触发。也适用于用户贴了一段英文内容想快速中文转发的场景。
Use when fact-checking a single wiki page against its cited sources — verifies that every footnote actually supports its claim and surfaces uncited factual claims. Run after ingesting a high-stakes page or any time you want confidence in one page's accuracy.
Use when adding a new source to a wiki — a paper, article, URL, file, transcript, or any document. One ingest may touch 10-15 wiki pages.
Use when bootstrapping a new personal wiki for any knowledge domain — research, codebase documentation, reading notes, competitive analysis, or any long-term knowledge accumulation project.
| name | powers-tech-narrative |
| description | Richard Powers 科技叙事张力 Skill。将普利策小说家 Richard Powers 在播客中讲到的人物洋葱、价值观冲突、事实到情感转化、语域和句法控制，迁移到泊舟的 AI/科技内容创作中。用户要求写科技人物故事、产品故事、AI 工具推文、技术科普、案例文章，或者觉得内容太干、太像参数说明、缺少冲突和生命力时，必须优先使用本 Skill。即使用户没有提到 Richard Powers，只要任务是把技术事实写得更有故事、有张力、有共鸣，也应该触发。 |
把 Richard Powers 的写作方法，变成泊舟写 AI/科技内容时可复用的创作流程。
这个 Skill 的目标不是让科技内容变得“文学腔”，而是解决一个常见问题：事实讲清楚了，但读者没有被打动，也没有行动。
使用本 Skill 处理这些任务：
不要在这些场景使用完整流程：
这些场景只保留“主谓前置、直接说人话”的部分。
技术参数、benchmark、融资金额和架构图，只能让读者“知道”。
好内容要让读者发生一点位移：从无感到关心，从旁观到代入，从知道到想行动。
写作时先问：
不要只写表层身份。
按三层剥开人物：
例子：
真正的张力来自两个都重要、但无法同时保住的价值观。
不要写“好产品打败坏产品”。
写这种冲突：
把主体放进一个必须选择的场景。选择越痛，故事越有力量。
读者被打动，通常不是因为你多给了一个参数，而是因为他看见了一个自己能代入的人。
处理技术事实时，用这个顺序：
不要把故事当装饰。故事是让读者产生认同的主引擎。
中文里可以把 Powers 的 register 理解成“白话口语”和“正式书面语”的开关。
默认使用泊舟风格：白话、直接、技术圈朋友聊天。
低语域适合 C 端、开发者、推文：
高语域只在 B 端报告、正式方案、行业分析里少量使用：
如果高语域太多，要立刻改回白话。
句子结构会影响读者感受。
主谓前置用于震惊、判断、结果：
模型自己写完了迁移脚本。
主谓延迟用于悬念、铺垫、压力：
在连续三次回滚、凌晨两点还没人敢点发布按钮、所有人都盯着监控曲线的时候，新的自动修复系统接管了。
写推文时，少用长句。写文章段落时，可以用一两个主谓延迟句制造张力，但不要连续使用。
先列出内容必须传达的事实。
包括：
不要一开始就写漂亮句子。
如果素材里没有明确人物，创建一个典型主体。
主体可以是：
为主体写三层信息：
表层特征：
行为习惯：
核心价值观 A：
核心价值观 B：
核心价值观 A 和 B 必须存在潜在冲突。
构造一个选择场景。
如果选择 A，会失去什么：
如果选择 B，会失去什么：
最终选择：
代价：
如果代价不够具体，故事会虚。
明确读者读完以后应该发生什么变化。
从：
到：
根据平台和受众选择：
输出时先给创作骨架，再给正文。
如果用户只要成稿，可以把骨架压缩为 3-5 行。
默认使用这个格式：
## 创作骨架
主体：
核心事实：
价值观冲突：
被逼到墙角的场景：
目标情感位移：
语域和句法策略：
## 成稿
[正文]
## 自检
- 是否有具体人物或主体：
- 是否存在两个冲突价值观：
- 技术事实是否被保留：
- 是否让读者发生情感位移：
- 是否删掉了用力过猛的比喻：
如果任务是推文，成稿部分直接给 1-3 个推文版本，每个版本控制在适合 X 发布的长度。
不要这样写：
当内容太玄：
这段隐喻太飘。先写清楚真实技术机制，再保留一个最贴切的比喻。删掉不能对应事实的拟人化表达。
当内容太干：
这段只有事实，没有人。请补一个被这个技术影响的具体角色，并写出他原本的困境。
当内容太用力：
这段在炫技。删掉一半形容词和宏大词，让动作、选择和代价承担张力。
当场景不适合叙事：
关闭价值观冲突和宏大开篇。改用主谓前置短句，直接给结论、步骤和注意事项。
交付前检查：