methodology-writer

# Methodology Writer 将用户的思维框架、实践经验或核心洞察，转化为结构严谨、证据充分、可传播的方法论文档。 ## 与其他 Skill 的关系 - **strategic-insight-longform**：分析现象/趋势 → 产出洞察报告。Methodology Writer 产出的是**可操作的思维框架**，不是分析报告 - **obsidian-md-ac**：格式美化。Methodology Writer 在 Phase 3 产出 Obsidian 格式版本时调用 - **humanizer-zh**：去 AI 味。可在最终产出后选择性调用 ## 执行流程 ### Phase 0: 需求澄清 通过 `clarify` 确认以下信息（缺失的必须主动询问）： 1. **方法论的核心是什么？**（一句话概括，如"约束提升产出质量"） 2. **来源素材**：用户是否有现成的笔记、草稿、对话记录、演讲稿？如有，先阅读全部素材 3. **目标受众**：给谁看？（如：AI 用户、产品经理、创业者、团队管理者） 4. **发布渠道**：哪些平台？（如：Obsidian 知识库、微信公众号、知乎、社区论坛） 5. **深度模式**： - **完整版**（默认）：完整章节 + 证据矩阵 + 附录 - **精简版**：核心章节精简合并 - **社区分享版**：单篇可读完的精华版 ### Phase 1: 方法论内核提取 从用户提供的素材中提取： 1. **核心公式/原理**：方法论用一句话怎么说？（如：`想清楚 + 定标准 + 改到位 = 高质量输出`） 2. **关键概念清单**：方法论包含哪几个独立概念？每个概念的定义、日常类比、与其他概念的关系 3. **概念间的逻辑关系**：是并列的？递进的？互补的？确保每个核心概念获得**同等权重**的独立阐述 4. **适用边界**：方法论适用于什么场景？不适用于什么场景？ 5. **与现有方法论的关系**：和已有框架（如 GTD、PDCA、OKR）有何异同？ **关键原则**：如果方法论包含多个核心维度（如 S 和 TDD），每个维度必须有独立章节进行深入阐述，不能合并讲解。合并会导致某个维度被弱化。 ### Phase 2: 证据矩阵构建 为核心论点构建跨领域证据支撑。使用 `web_search` 和 `mcp_exa_web_search_exa` 工具搜索以下维度的证据： **六维证据框架**（按需选择 3-6 个维度）： | 维度 | 搜索方向 | 示例 | |------|----------|------| | 学术层 | 期刊论文、实验数据 | PNAS, Nature, HBR 研究 | | 技术层 | 工程实践、开源项目 | OpenAI 文档、GitHub 项目 | | 艺术层 | 文化/艺术中的类比 | 莎士比亚格律、巴赫赋格 | | 商业层 | 企业案例、市场数据 | 行业报告、公司实践 | | 认知层 | 认知科学、心理学 | Kahneman、认知负荷理论 | | 历史层 | 历史案例、演化趋势 | 技术演进、方法论发展史 | **证据质量标准**： - 每个核心论点至少 3 个独立来源交叉验证 - 优先使用可验证来源（论文 DOI、官方文档 URL、开源项目链接） - 区分：共识（多源一致）、争议（来源不一致）、推测（单一来源或推理） - 所有推测性内容必须标注 `[待验证]` - 记录每条证据的完整引用信息（作者、年份、标题、来源） ### Phase 3: 结构化写作 参考 `references/document-structure.md` 中的文档结构指南，根据素材内容选择最自然的组织方式。 **结构设计原则**： 文档结构不套模板，从素材内容中自然生长。根据方法论特点选择组织模式： - **递进式**（问题驱动）：每章回答一个问题，下一章回答上一章留下的新问题 - **分层式**（架构驱动）：理念层 → 模型层 → 架构层 → 执行层 → 工具层 - **功能模块式**：按独立功能模块组织，每个模块自成一体 - **叙事式**：以个人经历/案例为主线，穿插方法论提炼 可混合使用。唯一硬性要求：**思维链**（全文逻辑链）和**参考引用**（来源索引）必须保留。 **写作规则**： - 参考 `references/writing-principles.md` 中的写作原则 - 每章开头一句话点明核心论点 - 证据紧随论点，不堆砌 - 保持概念间的独立性和平衡性 - 对于涉及人与 AI 协作的方法论，每个核心章节必须明确人和 AI 各自角色及边界 **文档元素**（按格式需求选用）： | 元素 | Obsidian 版 | 标准 Markdown 版 | |------|-------------|------------------| | 速览 | `> [!abstract]` callout | 加粗段落 | | 思维链 | `> [!info]` callout | 引用块 | | 高亮 | `==文字==` | `**文字**` | | 图表 | Mermaid 代码块 | 文字描述替代 | | 公式 | `$$LaTeX$$` | 纯文字公式 | | 表格 | Markdown 表格 | 列表替代（如目标平台不支持） | | 脚注 | `[^1]` 语法 | `[1]` 行内标注 | | 引用关系 | `[[wikilink]]` | 无（去掉） | ### Phase 4: 多平台适配 根据用户指定的发布渠道，从完整版派生适配版本。 **适配规则参考** `references/platform-rules.md`。 通用适配流程： 1. 确认目标平台的 Markdown 支持范围 2. 转换不兼容语法（callout → 引用、高亮 → 加粗、mermaid → 文字等） 3. 调整引用系统（脚注 → 行内标注） 4. 保留完整的参考来源索引（附录） 5. 添加平台适配的 YAML frontmatter（如需要） ### Phase 5: 质量验证 产出前逐项检查： **内容质量**： - [ ] 核心论点有 3+ 独立来源交叉验证 - [ ] 多个核心概念各有独立章节，篇幅均衡（最长不超最短 2 倍） - [ ] 场景应用覆盖 3+ 场景，每个场景体现所有核心维度 - [ ] 渐进采纳路径从"最小行动"开始 - [ ] 反模式/避坑指南至少 2 条 - [ ] 所有推测标注来源或标记 `[待验证]` **写作质量**： - [ ] 无 AI 味词汇（赋能、抓手、值得注意的是、总而言之） - [ ] 无工具特定名词（除非方法论本身是关于某工具的） - [ ] 每章可独立成立 - [ ] 全文有明确的逻辑递进（不是并列堆砌） **格式质量**： - [ ] 目标平台语法兼容 - [ ] 引用系统完整（正文标注 ↔ 附录来源一一对应） - [ ] YAML frontmatter 符合目标系统规范 ## 输出文件 ### 命名规范 - 完整版：`{主题关键词}_完整方法论.md` - 社区版：`{主题关键词}_方法论（社区分享版）.md` - 如用户指定文件名或路径，使用用户指定的 ### YAML frontmatter ```yaml --- title: "文档标题" subtitle: "副标题——点明核心框架" author: "作者名 × AI" date: YYYY-MM-DD version: "1.0" status: 种子 type: 方法论 tags: [核心标签1, 核心标签2, 结构化思维] --- ``` ## Agent 协作模式 对于完整版方法论，推荐使用 `delegate_task` 并行执行： | Agent | 职责 | |-------|------| | evidence-researcher | 搜索跨领域证据，构建证据矩阵 | | scenario-writer | 撰写场景应用相关章节 | | structure-writer | 撰写核心框架章节（核心概念阐述部分） | | system-writer | 撰写深层模型+采纳扩散+结语+附录 | 主 Agent 负责：需求澄清、任务分配、内容整合、质量验证、平台适配。 精简版和社区版可由主 Agent 单独完成，无需并行。