القائمة
用于撰写中文科技爆款文章、公众号长文、技术复盘稿和高打开率标题。适合需要同时做到抓流量、显得专业、信息密度高、观点鲜明的写作任务，尤其适用于 AI、大模型、产品发布、技术事故复盘、工程突破和行业分析。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Systematically trace bugs backward through call stack to find original trigger
Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.
Use multiple AI agents to investigate and fix independent problems concurrently
Turn verified project state into execution-ready phase prompts with wave structure, hard rules, acceptance criteria, and delivery reports. For writing prompts that drive real implementation progress, not design docs.
Receive and act on code review feedback with technical rigor, not performative agreement or blind implementation
Create isolated git worktrees with smart directory selection and safety verification
| name | viral-tech-writing |
| description | 用于撰写中文科技爆款文章、公众号长文、技术复盘稿和高打开率标题。适合需要同时做到抓流量、显得专业、信息密度高、观点鲜明的写作任务，尤其适用于 AI、大模型、产品发布、技术事故复盘、工程突破和行业分析。 |
这个 skill 用来把“有料但不好看”的技术内容，写成“愿意点开、能读下去、还显得专业”的中文长文。
目标不是写自嗨技术文，也不是写空洞情绪文，而是做两件事同时成立：
标题默认采用“情绪钩子 + 专业信息”的混合结构。
不要只写：
我们修复了一个内存问题优先写：
Mac上跑大模型：一次模型切换引发的90GB内存雪崩，我是怎么把它堵住的128K 上下文跑通之后，oMLX 最危险的内存缺口终于暴露了标题公式优先顺序：
大事件/冲突 + 主体 + 后果新能力/新突破 + 关键数字 + 行业意义事故/问题 + 根因 + 修复结果标题中尽量至少包含以下元素里的 2-3 个：
前 3 段必须回答下面至少两个问题：
不允许一上来先铺论文史、框架史、行业史。
错误示例：
近年来，随着大模型的发展……正确方向：
如果你还觉得本地大模型推理只是模型权重大一点，这次事故可能会改变这个认知。我们把上下文从 32K 推到 128K 后，真正先炸掉的不是模型，而是模型切换后的运行时内存。技术复盘优先用这套结构：
每一段只回答一个问题：
写作时必须把下面三类内容分开，不要混写：
事实：日志、指标、版本、代码路径、配置、测试结果推断：根据源码或行为推出的机制解释判断：这件事对平台、行业、用户意味着什么如果是推断，不要写成绝对事实。
例如：
KV cache 轻松吃掉 60GB在我们的实测链路里，128K 时 KV/cache 相关运行时内存进入几十 GB 量级并不意外每篇文章至少要有 3 类数字：
如果一篇技术长文几乎没有数字，专业感会明显下降。
不要只写：
内存没降下来要写成：
系统把 unload 成功误判成 reclaim 成功，因为账面 estimated_size 下降了，但真实 active memory 没降。核心要求：
当用户让你“写一篇抓流量但显得专业的文章”时，按这个顺序输出：
默认同时给三类标题：
如果用户没指定，优先推荐 C 类。
# [标题]
如果你最近还觉得[旧认知]，这次[事故/突破]可能会改变这个认知。
先说背景。
[背景链：为什么会推到这个场景]
但真正的问题，不在[表面现象]，而在[真正根因]。
## 事故现场
[时间、模型/产品链路、关键异常、关键数字]
## 根因拆解
[源码路径、资源生命周期、误判点]
## 修复架构
[不是修一行，而是修一套机制]
## 验证结果
[高风险链路验证 + soak test / benchmark / regression]
## Lessons Learned
[3 条以内，必须硬]
## 行业意义
[升维一句话：这件事对谁意味着什么]
交稿前必须自查：
除非用户要求极短版，否则默认输出：