write-draft-outline

# 写成草稿的文章大纲 ## 要交付什么 交付一份作者可以继续展开、合作方可以判断文章内容的大纲。用列表保留结构，每条里面直接写作者准备说的话，读起来接近文章草稿。 默认使用中文。以用户提供的原话和最新版本为依据，保留其直接、具体、略带口语的表达。用户要求简略提纲、全文或其他格式时，按当次要求调整。 ## 先确定材料和主线 - 先读用户给的笔记、现有大纲、产品资料和审核意见。有可用工具时读取指定文档；无法读取时说明缺少什么，不假装读过。 - 用户指定“最新大纲”时，以该版本为底稿；整合后续补充，避免恢复已经放弃的标题或遗漏确认过的内容。 - 区分用户的真实经历、产品资料和准备演示的操作。可以用第一人称复述用户已经交代的经历，不编造试用结果、生成质量、节省时间、价格优势或个人感受。 - 标题服从用户的最新选择。正文兑现标题承诺，例如“从读文献到组会汇报”应包含阅读方法、笔记整理和汇报制作，而不只是列功能。 - 合作方希望更贴近科研或其他领域时，围绕该领域中的任务和问题重组内容。保留用户的口吻，不机械复刻 brief 或参考文章的结构。 ## 草稿式列表怎么写 - 通常用编号列出标题、引子、主体几部分和结语；主体内部用少量无序列表，每条是一段完整、自然的话。篇幅和层级随内容决定，不固定章节数量。 - 小标题写作者或读者正在做的事，例如“读文献时，先把文章最重要的东西弄清楚”“准备组会时，做 PPT 也是重新理解文献的过程”。 - 条目直接进入正文表达：写“我一般会先让 AI 按固定框架整理一遍”，不写“分享自己的使用心得”；写清实际问题和用法，不写“自然引出产品”“展示功能优势”“回到核心价值”。 - 用因果、具体困难和个人取舍连接段落。产品能力出现时，说明它在当前任务中怎么用，以及结果如何接着用。 - 用户给出的提示词、链接和具体细节应保留在对应位置。能直接给出模板时就给出，避免只有“正文提供模板”的空承诺。 - 不默认添加“本步产出与配图”“验证环节”等统一栏位。用户要求截图计划时，再单独安排；缺少实际演示时，不把计划写成已经发生的体验。 - 引子可以从用户的真实习惯或共同困难进入，尽快落到文章要解决的事。结尾接一个读者可以试的具体任务，再放体验入口，避免重新罗列卖点。 ## 减少 AI 味 - 先修正写作视角：把给作者安排任务的句子改成作者面对读者说的话。只替换几个形容词不够。 - 保留用户自然的语气，例如“挺麻烦的”“我一般也是省着用”“对学生来说成本也太高了”。适量使用，不人为制造夸张感。 - 少用整齐的口号和抽象总结，不用“赋能”“全方位”“效率神器”“本文将深入探讨”等套话。避免每节都套“问题—操作—产出—价值”的说明书格式。 - 可以比较具体方案或解释不同模式；不要反复用“不是……而是……”制造转折，也不要通过贬低读者、工具或已有习惯来突出观点。 - 少用感叹号和泛泛夸奖。用户已经明确表达的“相见恨晚”等感受可以保留，但后文应有具体缘由。 - 写个人判断时保留边界：“我自己感觉”“有时候”“对我来说”比把经验写成普遍结论更合适。 ## 工具与科研合作文章 处理科研 AI、文献阅读和组会汇报主题时，阅读 [科研场景与写法示例](references/research-examples.md)。其中的文献模板和 PPT 学习心得是可按需采用的例子，不是所有文章的固定结构。 让产品随着任务出现。例如在理解论文时使用知识库，在拿不准创新点时对照多个模型，在整理回答时总结共识或差异，在准备汇报时组织材料、制作 PPT。只使用已确认的能力，不为覆盖功能而插入无关章节。 判断和人工处理要写进实际过程：回原文检查什么、补充什么理解、为什么调整汇报顺序。避免在每个条目末尾机械重复免责声明。 ## 修改与交付 - 用户只补充一点时，修改相应部分即可；不要顺手重写其他已经认可的内容。 - 用户要求完整版时，合并本轮及之前确认的修改，交付一份完整、连贯的当前版本，尤其检查提示词、新增能力和个人心得是否保留。 - 用户要求保存到文档时，按指定位置写入；只提供来源链接不等于要求修改来源。不要自动发送给合作方或发布。 - 输出前通读：这份大纲能否直接拿去继续写文章？是否仍有大量“介绍、展示、强调、自然引出”的任务说明？每个产品能力是否接在具体需求后面？有没有编造经历或遗漏用户最新补充？在内部修正，不附冗长自检报告。