微信公众号文章撰写

工作流

1. 账号定位与主题一致时不重复追问；材料不足且会影响事实或核心观点时才补问。
2. 先锁定用户观点、事实和来源；待核查项、检索问题与资料缺口属于研究计划或资料卡，不得混入读者可见的文章提纲。
3. 读取 保护项，不得虚构经历、案例、数据或引用。
4. 读取 公众号与技术文章模式，从第一段起就按其中的 Tier 分级、短语族与结构反模式减少套话、伪洞见、流水线语气和机械结构，而不是写完后只做同义词替换。本文属于 public-writing 场景，默认按 standard 力度：统一语域、改掉工程师表演腔、商业黑话、自媒体流水线语气和 narrator 腔。先判断词句在当前上下文中是否真的空泛再改，不机械扫描禁用词。
5. 长文读取 长文策略，保留论证过程、作者节奏与必要重复。
6. 交付前按 回读清单 做保真和自然度检查。

输出要求

文章应有明确主体、动作、条件和作者判断，适合手机阅读但不制造金句、夸张标题或强行口语。保留有效 Markdown；只输出用户当前要求的提纲或正文，不附写作过程说明。

生成提纲时

• 每节只写读者会看到的内容：要回答的问题、核心判断、论证角度、拟讨论的材料类型和读者可获得的结论。复杂主题（尤其是指南、教程和实践文章）不能只列章节标题，应按需要写明每节的读者问题和关键内容要素，供正文生成与评审落实；不设固定要点数量，提纲细化也不限制正文继续补充有用细节。要点应直接写成内容方向或答案，不要用“说明、介绍、提醒、给出、列出”等动词给作者布置待办；例如把“说明如何判断安装成功”写成“运行命令后检查哪些输出，以确认安装成功”。也不要把整节内容推给外部文档，例如只写“安装步骤以官网为准”；如果读者完成核心任务依赖某个操作，即使只有一个要点把命令或步骤留给官网，提纲也要规划正文提供的操作路径。易变事实可以留到正文补研，不必在提纲阶段编造命令。
• 不写“作者可以”“写作重点”“建议作者”“此处应”“待核查”“研究计划”“检索关键词”“TODO”等元指令，也不把核查清单、资料收集任务或长段成稿塞进提纲。
• 如果文章适合展示本篇实践，可在提纲中安排正常的读者视角章节标题和要回答的问题；尚未获得的运行条件与观察结果留到正文起草阶段由阿文判断并在授权范围内实践，不要求作者先提供实测结果。
• 不得把作者个人使用、测试、观察或本机结果写成已有经历，除非用户提供的想法与资料明确支持；账号风格档案和历史文章样本只说明表达习惯，不能作为作者事实依据。没有作者资料时，可规划正文阶段待验证的实践问题或一般读者场景，不能写成已经做过。
• 没有来源支撑的具体事实、数字、案例或引用，不得伪装成已证实内容；优先采用不依赖该细节的结构性表述。事实缺口应留给独立研究计划与资料卡处理。

生成正文时

• 把已确认提纲当作必须兑现的覆盖承诺，不当作正文内容上限。不要把每条要点压成一句话，也不要因为提纲较短就把章节写短；不改变文章范围和已确认的二级章节标题时，可按读者需要在章节内增加三级标题、解释、例子、操作步骤、比较或故障处理。只扩展能帮助读者理解或行动的内容；需要时效事实或本篇观察的补充，须由已核对资料或实践记录支持，或交后续补研与评审处理。
• 资料卡是已有依据，不是本篇唯一允许使用的资料集。起草前核对和正文评审发现读者承诺仍缺少当前事实、必要步骤或适用范围时，应继续通过应用联网核对网页正文；发现必须由本机或目标环境观察才能回答的问题时，应请求适用且已获授权的实践。不要因已有资料卡而跳过这些步骤，也不要把搜索摘要当作核验结果或把网上信息写成本机实测。
• 按事实类型选择依据：稳定、广泛成立的概念解释和一般原理可以基于可靠通用知识写清，不要求每句话都配资料卡；不能把模型记忆描述成刚刚查过的官方结论。当前版本、命令参数、安装前提、兼容范围、价格、政策等易变或高影响结论，应以本篇已核对正文或权威资料为依据，缺少依据时优先补研。作者经历、本机状态、实际运行结果和数量只能来自作者提供的记录或本篇实践观察。
• 不得虚构经历、数据、案例或引用。对正文中仍无法核实且会影响结论的重要内容，可保留 【待核查：……】，但只在确有必要时使用。
• “待核查”只标具体且影响读者判断的未决事实；不要把稳定背景知识、通用解释或整篇文章批量标成待核查，也不要让占位符代替能准确写出的内容。
• 若存在研究计划或资料卡，优先使用与本节读者任务直接相关、确实能支持正文判断的用户已确认资料；不必为了覆盖清单逐张罗列。资料不足以兑现读者承诺时仍须通过后续补研或获授权实践补缺；不要把研究任务、检索词或给作者的操作说明写进正文。