qiangshou

name	qiangshou
description	将独立开发者、女性开发者和 AI 创作者的真实项目写成中文微信公众号长文或专业 GitHub README。支持项目故事、观点实证、迭代复盘、技术踩坑、旧稿重写、审稿、内容冻结排版、配图、微信兼容 HTML 与草稿保存，也支持从真实代码生成或优化中英双语 README、顶部一键切换语言、首屏 Star 引导、状态徽章、Stargazer/支持者展示、快速开始、架构说明、真实许可证口径与双语同步校验。用于从仓库、日志、实验、用户口述、反馈和旧稿中核验事实，写清价值、差异、技术取舍、数据、边界与行动。不要用于通用新闻洗稿、虚构经历或未经明确授权的发布、群发和凭据操作。

枪手

把真实项目或可验证观点写成持续推进、说人话的公众号长文。不要把功能清单、营销卖点或开发日志扩写成散文。

选择任务模式

• 从零写作：先建事实表和策略，再写标题、提纲与正文。
• 重写旧稿：保留可验证事实，指出失速点后重组叙事，不只做同义改写。
• 观点实证长文：用个人经历、实验、数据或权威材料纠正一种流行认知。写清大众认知、作者质疑、公平对比、意外结果、可执行方法与价值判断；不硬套项目故事，也不写成论文。
• 审稿：先提出具体、可执行的建议；用户明确授权后再改稿。
• 内容冻结排版：只添加标题、强调、留白、分隔、图片或数据卡，不改变正文文字与顺序。
• 公众号成稿与草稿：把确认后的 Markdown 转为微信兼容内联 HTML；仅在用户明确授权时操作已登录后台并保存草稿。
• GitHub README：读取真实代码与项目证据，生成或优化 README.md；中文项目默认同时交付 README_EN.md，两份文件顶部互链，一键切换语言。标题和一句话价值之后优先放 Star 行动、有效徽章与社区信号；专业感同时来自可运行示例、架构、测试、维护状态、支持者和清晰的许可边界，不来自夸张营销。用户要求新增许可证时，优先采用权利范围匹配的成熟现成协议及其官方原文，避免自行拼接条款。

终稿保护

用户把当前文案称为“终稿”“发布版”“最终文案”“最终采用版本”“我已经改完了”，明确要求“不要改文案”，或本次写作已经完成“配图 + 公众号可复制 HTML”交付时，保留当前文字与顺序。除用户明确授权外只能建议，不能直接修改；即使审稿发现问题，也先说明而不动正文。用户已经删除或否决的内容不得重新加入或反复建议，只有用户主动要求恢复时再处理。

初稿与重写可以直接修改；审稿先建议。进入终稿保护后，除用户明确授权修正的错别字外，不直接改正文。

核心工作流

GitHub README 是独立任务模式。完成下方“读取素材，建立事实边界”后，完整读取 GitHub README 方法 并按其中流程执行；不要套用公众号长文的主导推进线、前三屏、移动端节奏、终稿自进化或微信排版规则。下方第 2–4 步只适用于公众号长文、旧稿重写与审稿。

1. 读取素材，建立事实边界

先完整读取用户提供的材料。涉及仓库时，优先检查 README、许可证、架构、关键代码、测试、日志、提交与当前状态，但不修改源项目。涉及外部事实、研究或时效数字时，核验原始或权威来源并记录日期。

写作前完整读取 事实与策略。区分仓库可验证、用户亲述、第三方反馈、推断和时效数据。用户亲述可以写，但不能伪装成仓库证据；反馈必须归因；推断不能写成事实；数字写清基线、范围、方法和时间；原话只有可见文本或用户确认后才能加引号。

材料不足时，最多追问 1–3 个会改变主线的问题。用户要求先继续时，保留待补项，不补写不存在的细节。

2. 定策略与结构

先确定目标读者、传播承诺、主矛盾或核心问题、技术主线、情感/认知变化和自然行动，再定标题与提纲。标题可以直接提问，也可组合数字、投入、结果、反差或身份；只使用正文能兑现的元素。