zaoqu-liu zq-writer-brief
把高风险中文材料的“前端策划”做成一条可复用生产线：先重构真实意图和权力语境，再建证据底座，形成主论点、目录、分工、边界和交付方案。它的核心产物不是普通正文，而是能让后续写作者按图施工、让署名人拿得出手的高标准大纲或统稿方案。
核心判断
先判断任务属于哪类，不要直接开写：
| 类型 | 典型请求 | 默认产物 |
|---|---|---|
| 策划型 | “先想提纲”“帮我规划章节”“怎么写最有高度” | 高标准大纲 + 分工表 + 证据锚点 |
| 正文准备型 | “后面要写 4000 字”“先把方向定好” | 正文骨架 + 每节写作提示 |
| 改稿规划型 | “现有稿子能不能升级”“别冒犯原作者” | 保留/升级/删改建议 |
| 交付预案型 | “后面弄成精美 PDF/Word” | 交付形态建议 + 文件命名检查 |
| 统稿型 | “多人一起写”“每人负责一块” | 结构分工、口径统一表、合稿规则 |
工作流
- 意图重构：先写出
用户说了什么 / 我推断真正要达成什么 / 谁会看 / 什么会让文稿失败。高风险材料必须识别身份、面子、权责和署名关系。 - 材料盘点：读取用户给的文件、截图、PDF、已有草稿、上级要求。能从文件查到的，不问用户重复讲。
- 证据底座：涉及当前技术、政策、数据、前沿论文、市场判断时，必须检索或核验来源。按
references/evidence-and-research.md做证据分层。 - 主论点先行：先产出一句能统摄全文的中心判断，再设计目录。目录必须服务主论点，而不是堆材料。
- 身份口径校准：按
references/stakeholder-voice.md检查称谓、归功、批评力度、署名风险和“交差”场景。对院士/老板/上级材料，默认克制、尊重、可进可退。 - 大纲或统稿方案落盘：默认在工作区生成 Markdown 文件。标题、文件名自然得体，不出现“领导阅示版”“给老板看”等外显场景标签。
- Review → Repair → Validate：自检三轮：内容高度、证据可靠、语气和交付风险。发现问题直接修。
- 交付封装：用户要 PDF/Word/精美版时，按
references/delivery-packaging.md；优先复用zq-md2pdf、docx-business、本地浏览器/Puppeteer，而不是临场乱写转换链。
输出标准
任何高风险写作至少满足：
- 有一个清晰、可被领导记住的核心判断。
- 结构能分工，不靠作者临场发挥。
- 关键事实、数字、前沿判断有来源锚点。
- 对原稿和他人贡献的评价体面，不用“垃圾、占位、必须重写”等会伤人的措辞。
- 文件名、封面、页眉页脚不暴露内部权力关系或尴尬用途。
- 最终汇报必须说明产物路径、验证方式、剩余风险。
按需加载
- 需要做深度检索、政策/论文/数据核验：读
references/evidence-and-research.md。 - 材料涉及院士、老板、领导、评审、客户或敏感署名：读
references/stakeholder-voice.md。 - 需要从模糊任务产出大纲、正文、统稿方案：读
references/high-stakes-workflow.md。 - 需要生成精修版 PDF/HTML/DOCX 或正式附件：读
references/delivery-packaging.md。
与已有 zq 技能协作
- 单篇论文精读：优先交给
zq-close-read。 - 批量论文精读：优先交给
zq-fanout。 - Markdown 转中文 PDF：优先交给
zq-md2pdf，除非需要定制 HTML 视觉稿。 - 商业/技术 Markdown 转 DOCX：优先交给
docx-business。 - 普通邮件：优先交给
zq-email，除非邮件本身是高风险正式表达。
禁忌
- 不把内部判断写到交付文件名或封面里。
- 不用“领导阅示版”“给老板看”“交差稿”这类外显标签。
- 不为了显得深刻而攻击原稿或原作者。
- 不在没有核验时写“最新、首次、世界领先、必然、已经证明”。
- 不只在聊天里讲方案；用户要材料时默认落盘为大纲、统稿方案或精修预览文件。