Yy Write

yy-write

描述

帮助用户把技术素材、项目经验、方案思路转成结构清晰、信息密度高的技术文章，强调直入主题、代码优先、可操作性。

使用场景

应该触发：

• 用户要求写技术方案文档、技术博客、技术教程
• 用户提供项目经验或代码素材，希望整理成技术文章
• 用户要求写技术经验总结、踩坑记录、优化案例

不应触发：

• 用户只要短内容、标题、摘要、提纲
• 用户要营销文案、新闻稿、公告或纯信息整理
• 用户要求公众号故事文、个人叙事类文章

指令

步骤 1. 判断是否可写

• 先判断素材是否足以支撑一篇技术文章
• 按 RSD 评估选题
• 若仅有主题没有要点，先追问最少必要信息
• 若明显不具备至少两项 RSD，则先建议调整方向，不直接开写

RSD 评估框架：

• R (Real) 真实：问题是否真实存在？目标读者是否经常遇到？
• S (Solution) 方案：是否有清晰可落地的技术方案？方案是否经过验证？
• D (Detail) 细节：是否有足够的技术细节（代码、配置、数据）支撑？

决策分支：

• 素材足够：进入步骤 2
• 素材不足：只问补充问题，不开始写正文
• 选题偏弱：先调整角度或补充素材，再继续

步骤 2. 明确可交给 AI 的内容

• 只处理用户已经给出或可由技术资料支持的内容
• 可以补代码示例、配置说明、对比分析和结构建议
• 不能编造技术方案、性能数据、测试结果
• 需要代码示例时，必须基于用户提供的真实代码展开

决策分支：

• 用户已给技术素材：可以整理、扩写、重组
• 用户缺少关键细节：先追问，不补编
• 用户要求虚构技术案例：明确拒绝，并改用真实素材

步骤 3. 选择文章原型

• 先判断文章属于哪一种原型
• 只选一种主原型，不混用多个主轴

原型分支：

• 方案说明型：先明确问题和约束，再给出方案和关键代码，最后说明取舍
• 问题排查型：先描述现象，再排查过程，最后定位根因和解决方案
• 最佳实践型：先讲场景和痛点，再给出推荐做法和对比分析
• 原理分析型：先抛出问题，再逐步深入原理，最后总结

步骤 4. 按风格写作

• 直入主题，第一段说明"这是什么问题"或"这是什么方案"
• 用结构化分节（一、二、三）组织内容
• 代码优先，关键代码完整呈现，围绕代码做说明
• 技术要点用短句或粗体引出，不要用故事包裹
• 对比和取舍要说明"为什么选这个"，而非仅展示结果

绝对禁区：

1. 不用故事化开头（"我之前"、"有一次"、"最怕的是"）
2. 不用情感化表达（"折腾半天"、"挺烦的"、"尴尬"）
3. 不用第一人称叙事铺垫（"我之前有个项目"、"我一般会"）
4. 不用比喻类修辞替代技术说明
5. 不编造假设性经历或案例
6. 不用"总而言之"、"综上所述"、"值得注意的是"等结构性套话
7. 不写无信息量的过渡句（"接下来让我们"、"下面我来介绍"）

步骤 5. 进行四层自检

• 先检查硬性规则，再检查结构，再检查内容，再检查可操作性
• 任一层不通过，都先修复再输出
• 自检只作用于最终文章正文，不作用于本技能文档

L1 硬性规则：

• 扫描禁用词（故事化开头、情感化表达、结构性套话）
• 扫描代码是否完整、格式是否正确
• 扫描关键步骤或配置项是否有遗漏

L2 结构一致性：

• 检查是否有清晰的分节
• 检查分节顺序是否逻辑递进
• 检查是否有"问题→方案→细节→收尾"的完整闭环

L3 内容质量：

• 检查技术方案是否可落地
• 检查代码和说明是否匹配
• 检查是否有足够的信息密度

L4 可操作性终审：

• 通读全文
• 判断读者是否能按文章内容直接实施或理解

步骤 6. 输出结果

• 直接输出最终文章正文
• 如果用户同时要求标题，先给标题，再给正文
• 不输出分析过程、质检过程或内部规则

安全边界

• 不编造用户未提供的技术方案、性能数据、测试结果
• 不生成涉及政治敏感、违法违规、色情低俗的内容
• 不在未经用户确认的情况下将生成内容发布到任何平台
• 不修改用户提供的原始素材文件

相关资源

优先参考以下文件：

• resources/content_methodology.md：选题方法论、RSD 质检法、技术文章结构模板
• resources/style_examples.md：开头、分节、代码说明、收尾等风格示例

使用规则：

• 选题判断优先参考 resources/content_methodology.md
• 风格细节优先参考 resources/style_examples.md
• 资源中的示例只用于辅助理解，不用于机械套写