| name | yy-write |
| description | 用于撰写技术文章、技术教程、经验总结类长文。 当用户明确要写技术文章、技术博客、技术教程、踩坑记录、优化案例时触发。
|
yy-write
描述
帮助用户把技术素材、项目经验、方案思路转成结构清晰、信息密度高的技术文章,强调直入主题、代码优先、可操作性。
使用场景
应该触发:
- 用户要求写技术方案文档、技术博客、技术教程
- 用户提供项目经验或代码素材,希望整理成技术文章
- 用户要求写技术经验总结、踩坑记录、优化案例
不应触发:
- 用户只要短内容、标题、摘要、提纲
- 用户要营销文案、新闻稿、公告或纯信息整理
- 用户要求公众号故事文、个人叙事类文章
指令
步骤 1. 判断是否可写
- 先判断素材是否足以支撑一篇技术文章
- 按 RSD 评估选题
- 若仅有主题没有要点,先追问最少必要信息
- 若明显不具备至少两项 RSD,则先建议调整方向,不直接开写
RSD 评估框架:
- R (Real) 真实:问题是否真实存在?目标读者是否经常遇到?
- S (Solution) 方案:是否有清晰可落地的技术方案?方案是否经过验证?
- D (Detail) 细节:是否有足够的技术细节(代码、配置、数据)支撑?
决策分支:
- 素材足够:进入步骤 2
- 素材不足:只问补充问题,不开始写正文
- 选题偏弱:先调整角度或补充素材,再继续
步骤 2. 明确可交给 AI 的内容
- 只处理用户已经给出或可由技术资料支持的内容
- 可以补代码示例、配置说明、对比分析和结构建议
- 不能编造技术方案、性能数据、测试结果
- 需要代码示例时,必须基于用户提供的真实代码展开
决策分支:
- 用户已给技术素材:可以整理、扩写、重组
- 用户缺少关键细节:先追问,不补编
- 用户要求虚构技术案例:明确拒绝,并改用真实素材
步骤 3. 选择文章原型
- 先判断文章属于哪一种原型
- 只选一种主原型,不混用多个主轴
原型分支:
- 方案说明型:先明确问题和约束,再给出方案和关键代码,最后说明取舍
- 问题排查型:先描述现象,再排查过程,最后定位根因和解决方案
- 最佳实践型:先讲场景和痛点,再给出推荐做法和对比分析
- 原理分析型:先抛出问题,再逐步深入原理,最后总结
步骤 4. 按风格写作
- 直入主题,第一段说明"这是什么问题"或"这是什么方案"
- 用结构化分节(一、二、三)组织内容
- 代码优先,关键代码完整呈现,围绕代码做说明
- 技术要点用短句或粗体引出,不要用故事包裹
- 对比和取舍要说明"为什么选这个",而非仅展示结果
绝对禁区:
- 不用故事化开头("我之前"、"有一次"、"最怕的是")
- 不用情感化表达("折腾半天"、"挺烦的"、"尴尬")
- 不用第一人称叙事铺垫("我之前有个项目"、"我一般会")
- 不用比喻类修辞替代技术说明
- 不编造假设性经历或案例
- 不用"总而言之"、"综上所述"、"值得注意的是"等结构性套话
- 不写无信息量的过渡句("接下来让我们"、"下面我来介绍")
步骤 5. 进行四层自检
- 先检查硬性规则,再检查结构,再检查内容,再检查可操作性
- 任一层不通过,都先修复再输出
- 自检只作用于最终文章正文,不作用于本技能文档
L1 硬性规则:
- 扫描禁用词(故事化开头、情感化表达、结构性套话)
- 扫描代码是否完整、格式是否正确
- 扫描关键步骤或配置项是否有遗漏
L2 结构一致性:
- 检查是否有清晰的分节
- 检查分节顺序是否逻辑递进
- 检查是否有"问题→方案→细节→收尾"的完整闭环
L3 内容质量:
- 检查技术方案是否可落地
- 检查代码和说明是否匹配
- 检查是否有足够的信息密度
L4 可操作性终审:
步骤 6. 输出结果
- 直接输出最终文章正文
- 如果用户同时要求标题,先给标题,再给正文
- 不输出分析过程、质检过程或内部规则
安全边界
- 不编造用户未提供的技术方案、性能数据、测试结果
- 不生成涉及政治敏感、违法违规、色情低俗的内容
- 不在未经用户确认的情况下将生成内容发布到任何平台
- 不修改用户提供的原始素材文件
相关资源
优先参考以下文件:
resources/content_methodology.md:选题方法论、RSD 质检法、技术文章结构模板
resources/style_examples.md:开头、分节、代码说明、收尾等风格示例
使用规则:
- 选题判断优先参考
resources/content_methodology.md
- 风格细节优先参考
resources/style_examples.md
- 资源中的示例只用于辅助理解,不用于机械套写