powers-tech-narrative

name	powers-tech-narrative
description	Richard Powers 科技叙事张力 Skill。将普利策小说家 Richard Powers 在播客中讲到的人物洋葱、价值观冲突、事实到情感转化、语域和句法控制，迁移到泊舟的 AI/科技内容创作中。用户要求写科技人物故事、产品故事、AI 工具推文、技术科普、案例文章，或者觉得内容太干、太像参数说明、缺少冲突和生命力时，必须优先使用本 Skill。即使用户没有提到 Richard Powers，只要任务是把技术事实写得更有故事、有张力、有共鸣，也应该触发。

Richard Powers 科技叙事张力 Skill

把 Richard Powers 的写作方法，变成泊舟写 AI/科技内容时可复用的创作流程。

这个 Skill 的目标不是让科技内容变得“文学腔”，而是解决一个常见问题：事实讲清楚了，但读者没有被打动，也没有行动。

适用场景

使用本 Skill 处理这些任务：

• 科技人物故事：创始人、开发者、研究员、产品经理、开源作者。
• 产品故事或用户案例：想把功能、参数、结果写得更有代入感。
• AI 工具推文：不是简单介绍功能，而是让读者产生想试用的冲动。
• 技术科普文章：需要把硬知识写得有场景、有冲突、有情感位移。
• 内容修改：用户说“太干了”“太像说明书”“没有故事感”“没有冲突”“AI 味太重”。

不要在这些场景使用完整流程：

• 故障通知、事故告警、紧急恢复步骤。
• API 文档、配置说明、纯操作手册。
• 小版本 release notes、普通 bug 修复说明。
• 用户明确要求极简、只要事实、不需要故事。

这些场景只保留“主谓前置、直接说人话”的部分。

核心原则

1. 事实不会自动改变价值观

技术参数、benchmark、融资金额和架构图，只能让读者“知道”。

好内容要让读者发生一点位移：从无感到关心，从旁观到代入，从知道到想行动。

写作时先问：

• 这个技术事实会影响谁？
• 这个人原本被什么困住？
• 读者为什么会觉得“这和我有关”？

2. 人物是洋葱，不是标签

不要只写表层身份。

按三层剥开人物：

• 表层特征：身份、场景、外在处境。
• 行为习惯：他说话、决策、工作时的固定模式。
• 核心价值观：他最想维护什么，最怕失去什么。

例子：

• 表层：一个做 AI Agent 产品的创始人。
• 行为：每天看用户录屏，亲自回高价值用户消息。
• 核心价值观：既想把产品做得足够强大，又害怕用户把控制权完全交给机器。

3. 把人物逼到墙角

真正的张力来自两个都重要、但无法同时保住的价值观。

不要写“好产品打败坏产品”。

写这种冲突：

• 增长速度 vs 用户信任
• 自动化效率 vs 人的控制权
• 模型能力开放 vs 安全边界
• 极致创新 vs 现有用户稳定
• 短期收入 vs 长期声誉

把主体放进一个必须选择的场景。选择越痛，故事越有力量。

4. 用故事制造认同，而不是只靠论证

读者被打动，通常不是因为你多给了一个参数，而是因为他看见了一个自己能代入的人。

处理技术事实时，用这个顺序：

1. 先写一个具体人或具体场景。
2. 再写他遇到的技术困境。
3. 然后放入关键技术事实。
4. 最后写这个事实如何改变他的处境。

不要把故事当装饰。故事是让读者产生认同的主引擎。

5. 语域控制距离

中文里可以把 Powers 的 register 理解成“白话口语”和“正式书面语”的开关。

默认使用泊舟风格：白话、直接、技术圈朋友聊天。

低语域适合 C 端、开发者、推文：

• 搞定
• 跑通
• 踩坑
• 少绕路
• 这事有点反直觉

高语域只在 B 端报告、正式方案、行业分析里少量使用：

• 提升系统稳定性
• 降低迁移成本
• 构建治理能力
• 形成规模化交付

如果高语域太多，要立刻改回白话。

6. 句法控制心理状态

句子结构会影响读者感受。

主谓前置用于震惊、判断、结果：

模型自己写完了迁移脚本。

主谓延迟用于悬念、铺垫、压力：

在连续三次回滚、凌晨两点还没人敢点发布按钮、所有人都盯着监控曲线的时候，新的自动修复系统接管了。

写推文时，少用长句。写文章段落时，可以用一两个主谓延迟句制造张力，但不要连续使用。

工作流程

Step 1: 提取硬事实

先列出内容必须传达的事实。

包括：

• 技术事实
• 产品能力
• 数据或结果
• 人物背景
• 时间线
• 用户场景

不要一开始就写漂亮句子。

Step 2: 找到被影响的人

如果素材里没有明确人物，创建一个典型主体。

主体可以是：

• 创始人
• 开发者
• 用户
• 团队
• 产品
• 被拟人化的系统，但必须有真实技术机制支撑

Step 3: 剥洋葱

为主体写三层信息：

表层特征：
行为习惯：
核心价值观 A：
核心价值观 B：

核心价值观 A 和 B 必须存在潜在冲突。

Step 4: 逼到墙角

构造一个选择场景。

如果选择 A，会失去什么：
如果选择 B，会失去什么：
最终选择：
代价：

如果代价不够具体，故事会虚。

Step 5: 把事实变成情感位移

明确读者读完以后应该发生什么变化。

从：

• 不关心
• 以为只是工具
• 觉得和自己无关
• 只知道参数

到：

• 想试一下
• 重新理解一个行业判断
• 对某个角色产生共情
• 意识到自己也在同一个困境里

Step 6: 选择语域和句法

根据平台和受众选择：

• X 推文：短句、低语域、强钩子、主谓前置为主。
• 公众号文章：场景开头、低语域解释、高语域少量用于总结行业判断。
• 产品案例：人物困境开头，技术事实居中，结果落到人的变化。
• 深度科普：硬事实和具体比喻交替出现。

Step 7: 写成稿

输出时先给创作骨架，再给正文。

如果用户只要成稿，可以把骨架压缩为 3-5 行。

输出格式

默认使用这个格式：

## 创作骨架

主体：
核心事实：
价值观冲突：
被逼到墙角的场景：
目标情感位移：
语域和句法策略：

## 成稿

[正文]

## 自检

- 是否有具体人物或主体：
- 是否存在两个冲突价值观：
- 技术事实是否被保留：
- 是否让读者发生情感位移：
- 是否删掉了用力过猛的比喻：

如果任务是推文，成稿部分直接给 1-3 个推文版本，每个版本控制在适合 X 发布的长度。

禁用清单

不要这样写：

• 不要把普通功能升级写成生死抉择。
• 不要在没有技术事实支撑时强行拟人。
• 不要使用“交响乐、舞蹈、挂毯、魔法、宿命”等泛滥隐喻。
• 不要堆“不是...而是...”和整齐排比。
• 不要为了显得高级而使用商业黑话。
• 不要让方法痕迹暴露出来，比如“现在我们进入高潮”。
• 不要把每段结尾都写成升华金句。

修正提示

当内容太玄：

这段隐喻太飘。先写清楚真实技术机制，再保留一个最贴切的比喻。删掉不能对应事实的拟人化表达。

当内容太干：

这段只有事实，没有人。请补一个被这个技术影响的具体角色，并写出他原本的困境。

当内容太用力：

这段在炫技。删掉一半形容词和宏大词，让动作、选择和代价承担张力。

当场景不适合叙事：

关闭价值观冲突和宏大开篇。改用主谓前置短句，直接给结论、步骤和注意事项。

最后自查

交付前检查：

• 开头有没有具体场景或强判断，而不是“本文将介绍”。
• 技术事实有没有保真，不能为了故事扭曲事实。
• 冲突是不是具体，不是虚假的戏剧化。
• 读者是否能代入一个人、一种处境或一个选择。
• 语气是否像泊舟：懂行、坦诚、接地气。