writing-to-sell
writing-to-sell
能让一句话口口相传的作者——David Ogilvy、乔布斯、雷军、叶茂中、华与华、Eugene Schwartz——动笔的时候心里都装着同一句话:
读者的注意力是借来的 3 秒。我的活不是让 TA 懂我的产品,是在 3 秒里把一句话钉进 TA 脑子,让 TA 带着走、有机会就原样说出来,并且觉得自己想变成那句话里的人。
这是广告人干的活,不是讲台上老师干的活,也不是翻译者干的活。翻译者搭桥让读者理解,广告人往读者脑子里钉一句话让 TA 记住。AI 默认当翻译者——把产品功能、使用方法、技术原理铺平摆给读者看——结果读者脑子里装了一堆信息,但没产生想要的感觉,因为没人往 TA 脑子里钉过一句话。
下面几节讲广告人具体在做什么动作。最后一节讲这套手法什么时候会翻车、该换成翻译者来写。
不讲"是什么",讲"读者会变成什么样"
乔布斯介绍 iPod 不说"5GB 硬盘 MP3 播放器",说 "1,000 songs in your pocket"。雷军介绍小米不说"8 核处理器",说"年轻人的第一台手机"。女娲.skill 不介绍技术实现,说"让乔布斯、马斯克、芒格、费曼都给你打工"。
翻译者的第一问是"这东西怎么工作",广告人的第一问是"读者有了这东西会变成什么样的人"。前者是信息,后者是画面。读者掏钱、点赞、转发不是为了获取信息,是为了那个画面里的自己。
具体动作:写每一段文案前问自己——"读者读完这段,想象里的自己变成了谁?"答案如果只是"读者知道了一件事",重写。
More from liuzhengdongfortest/easysdd
easysdd-feature-acceptance
feature 流程的阶段 3——做完整验收闭环。三件事:一是逐层对照 {slug}-design.md 核对实现有没有走样,发现偏差就当场修不是写在报告里"记一下";二是把这个 feature 归并到项目的整体架构文档里;三是如果本次 feature 改变了对应 requirement 的用户故事或边界,把 requirement doc 也回写一次。最后产出一份 {slug}-acceptance.md 作为整套流程的闭环凭证。前置依赖 easysdd-feature-implement 已完成。触发场景:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。
98easysdd-feature-fastforward
feature 流程的超轻量通道——不写 design、不写 checklist、不做分阶段 review,就让 AI 像平时一样直接动手写代码,但在动手前先告诉它项目里的 easysdd 知识库在哪、怎么搜,让它写出来的代码踩过的坑更少、和项目约定更一致。触发场景:用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干"、"帮我做个 xxx"且需求小到不值得走 design 流程。
98easysdd
easysdd 工作流家族的根技能——介绍工作流体系并把用户路由到正确子技能。触发场景:用户提到"easysdd"、"sdd"、"规约驱动"、"怎么用这套流程"、"我该用哪个技能"、"从哪开始",或描述了新功能但还没决定切入阶段。已知意图(brainstorm/设计/实现/验收/BUG/探索等)优先触发对应子技能而非本技能。
97easysdd-feature-design
feature 流程的阶段 1——为新功能起草一份方案文件,作为后续实现和验收的唯一输入。先收集证据(读架构、读相关代码、grep 防术语冲突、查归档),然后一次性写出完整初稿(含 YAML frontmatter + 三层结构 + 测试设计),交给用户整体 review,迭代到拍板。拍板后从 {slug}-design.md 里抽出 {slug}-checklist.yaml 给后面两个阶段用。触发场景:"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已经知道做什么、为谁做、怎么算成功。
97easysdd-feature
做新功能开发时进入这套子流程——把"加个 X 能力"从模糊想法走到验收闭环,中间有方案文件做存档,AI 和用户后面回头都能查到当时怎么想的、为什么这样定的。触发场景偏向新增能力("做新功能"、"加个 X"、"实现 XX"),不处理已有代码的 bug。本技能只做路由,根据已有产物决定下一步走 brainstorm / design / fastforward / implement / acceptance 中的哪一个。
97easysdd-feature-implement
feature 流程的阶段 2——按 {slug}-design.md 的推进顺序写代码,写完用统一格式做完成汇报给用户 review。前提是 {slug}-design.md 已经 approved(标准 design 含测试设计,或 fastforward design 含验收标准),并且同目录下有 {slug}-checklist.yaml。触发场景:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。实现中遇到方案没覆盖到的情况(新概念、范围外文件、需要打补丁分支)要主动停下来回到方案谈,不要硬冲。
96