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. 用故事制造认同，而不是只靠论证
读者被打动，通常不是因为你多给了一个参数，而是因为他看见了一个自己能代入的人。
处理技术事实时，用这个顺序：
- 先写一个具体人或具体场景。
- 再写他遇到的技术困境。
- 然后放入关键技术事实。
- 最后写这个事实如何改变他的处境。
不要把故事当装饰。故事是让读者产生认同的主引擎。
5. 语域控制距离
中文里可以把 Powers 的 register 理解成“白话口语”和“正式书面语”的开关。
默认使用泊舟风格：白话、直接、技术圈朋友聊天。
低语域适合 C 端、开发者、推文：
- 搞定
- 跑通
- 踩坑
- 少绕路
- 这事有点反直觉
高语域只在 B 端报告、正式方案、行业分析里少量使用：
- 提升系统稳定性
- 降低迁移成本
- 构建治理能力
- 形成规模化交付
如果高语域太多，要立刻改回白话。
6. 句法控制心理状态
句子结构会影响读者感受。
主谓前置用于震惊、判断、结果：
text模型自己写完了迁移脚本。
主谓延迟用于悬念、铺垫、压力：
text在连续三次回滚、凌晨两点还没人敢点发布按钮、所有人都盯着监控曲线的时候，新的自动修复系统接管了。
写推文时，少用长句。写文章段落时，可以用一两个主谓延迟句制造张力，但不要连续使用。
工作流程
Step 1: 提取硬事实
先列出内容必须传达的事实。
包括：
- 技术事实
- 产品能力
- 数据或结果
- 人物背景
- 时间线
- 用户场景
不要一开始就写漂亮句子。
Step 2: 找到被影响的人
如果素材里没有明确人物，创建一个典型主体。
主体可以是：
- 创始人
- 开发者
- 用户
- 团队
- 产品
- 被拟人化的系统，但必须有真实技术机制支撑
Step 3: 剥洋葱
为主体写三层信息：
markdown表层特征： 行为习惯： 核心价值观 A： 核心价值观 B：
核心价值观 A 和 B 必须存在潜在冲突。
Step 4: 逼到墙角
构造一个选择场景。
markdown如果选择 A，会失去什么： 如果选择 B，会失去什么： 最终选择： 代价：
如果代价不够具体，故事会虚。
Step 5: 把事实变成情感位移
明确读者读完以后应该发生什么变化。
从：
- 不关心
- 以为只是工具
- 觉得和自己无关
- 只知道参数
到：
- 想试一下
- 重新理解一个行业判断
- 对某个角色产生共情
- 意识到自己也在同一个困境里
Step 6: 选择语域和句法
根据平台和受众选择：
- X 推文：短句、低语域、强钩子、主谓前置为主。
- 公众号文章：场景开头、低语域解释、高语域少量用于总结行业判断。
- 产品案例：人物困境开头，技术事实居中，结果落到人的变化。
- 深度科普：硬事实和具体比喻交替出现。
Step 7: 写成稿
输出时先给创作骨架，再给正文。
如果用户只要成稿，可以把骨架压缩为 3-5 行。
输出格式
默认使用这个格式：
markdown## 创作骨架 主体： 核心事实： 价值观冲突： 被逼到墙角的场景： 目标情感位移： 语域和句法策略： ## 成稿 [正文] ## 自检 - 是否有具体人物或主体： - 是否存在两个冲突价值观： - 技术事实是否被保留： - 是否让读者发生情感位移： - 是否删掉了用力过猛的比喻：
如果任务是推文，成稿部分直接给 1-3 个推文版本，每个版本控制在适合 X 发布的长度。
禁用清单
不要这样写：
- 不要把普通功能升级写成生死抉择。
- 不要在没有技术事实支撑时强行拟人。
- 不要使用“交响乐、舞蹈、挂毯、魔法、宿命”等泛滥隐喻。
- 不要堆“不是...而是...”和整齐排比。
- 不要为了显得高级而使用商业黑话。
- 不要让方法痕迹暴露出来，比如“现在我们进入高潮”。
- 不要把每段结尾都写成升华金句。
修正提示
当内容太玄：
text这段隐喻太飘。先写清楚真实技术机制，再保留一个最贴切的比喻。删掉不能对应事实的拟人化表达。
当内容太干：
text这段只有事实，没有人。请补一个被这个技术影响的具体角色，并写出他原本的困境。
当内容太用力：
text这段在炫技。删掉一半形容词和宏大词，让动作、选择和代价承担张力。
当场景不适合叙事：
text关闭价值观冲突和宏大开篇。改用主谓前置短句，直接给结论、步骤和注意事项。
最后自查
交付前检查：
- 开头有没有具体场景或强判断，而不是“本文将介绍”。
- 技术事实有没有保真，不能为了故事扭曲事实。
- 冲突是不是具体，不是虚假的戏剧化。
- 读者是否能代入一个人、一种处境或一个选择。
- 语气是否像泊舟：懂行、坦诚、接地气。
