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. 定策略与结构

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

写作前完整读取 写作方法、作者文风记忆和视觉审美记忆，以用户最新明确选择为准。即使本次不配图，也读取视觉记忆，避免后续排版与封面建议偏离。

“项目故事”和“观点实证”只是高层写作意图，不是固定章节模板。每篇现场识别一条主导推进线：事件变化、认知变化、决策变化、实验变化或人物关系变化；其他变化可以辅助，但不能争夺主线。结构必须从本篇事实、冲突、证据、选择与后果中生成，不按预设幕数、章节表或上篇结构套写。版本更新／迭代决策复盘只是一种可选变体，不能扩展成新的固定引擎。

每一章都要让主导推进线发生变化。相邻两节只能用“然后”或“此外”连接时，重建因果。

3. 写正文

第一句话让事情或问题发生，三句内出现真实冲突、反差、数字或明确疑问；尽快说明项目/议题和读者为何值得继续。不要从时代背景、行业趋势或“本文将介绍”开始。

重要技术段落尽量覆盖：

问题 → 为什么难 → 尝试或取舍 → 具体实现 → 可量化结果 → 适用边界

术语首次出现时用一句人话解释，再回到文件、日志、实验或决策。不能把局部指标外推为整体效果；无法量化时如实写可观察结果。

保持作者聪明、坦率、有判断也允许修正的声音。保留自然口语、自嘲和真实情绪，不自动添加性别刻板话术，不为“高级感”统一润色。短段落为主，长短句交替；表格只用于明显更清楚的比较、映射或时间线。

学习参考文章时只提取结构规律，不复制独特句子、标题、口头禅、私人经历或品牌设计。配图只承担证据、解释或转折；素材不足时少图，不用装饰图冒充事实。

4. 审稿与收束

需要审稿与交付时，完整读取 审稿与交付。先看开场、主线、局面变化和人物/认知推进，再查事实归因、技术边界、数字日期、引语、许可证、重复和移动端可读性。所有长文在交付前执行轻量的“终稿去 AI 味检查”：先删不增加事实、因果、判断或人物变化的句子，再做必要的局部改写；不得机械删字、禁用句式、改变本篇结构或重写成更标准的公关稿。

初稿和重写任务中，发现问题后可以直接修改；审稿时先给建议。进入终稿保护后，除用户明确授权的错别字外，不直接改正文。

生成终稿、配图或公众号 HTML 前，用两套记忆各自自检一次：文案检查句长、口语、删减、列表与 AI 味；视觉检查图片类型、裁剪、拼图、封面构图与排版。没有已晋升偏好时不自行补造。

结尾回扣开场与作者动机，交代当前能力或结论、适用与不适用范围、尚未验证项，以及自然行动。CTA 像邀请，不硬喊点赞、关注或转发。

轻量自进化

出现以下任一条件时，把当前版本视为终稿并在本次任务结束前执行轻量自进化，不等待用户再次确认：

• 用户明确称其为“终稿”“发布版”“最终文案”“最终采用版本”或“我已经改完了”；
• 一个写作任务已经同时完成配图交付和公众号可复制 HTML 交付。

完整读取 自进化规则 后执行。只从模型前稿与用户手改终稿的真实差异学习；依次区分删除、改写、新增、原样保留，原样保留固定视为助手文字且不得成为用户偏好证据。用脚本生成稳定匿名终稿 ID，并通过持久化信号台账更新记忆；文字规则只进入 作者文风记忆，视觉规则只进入 视觉审美记忆。每次最多新增或修正 2 条抽象规则；用户说“这次不要学习”时跳过。

条件工作流

• 用户要求终稿或“不改内容”排版时，完整读取 内容冻结排版。只在用户明确要求“内容完全不变并验证”时运行 scripts/verify_content_preservation.py；不要把校验变成每次交付的默认步骤。
• 用户需要公众号可复制排版、预览或后台草稿时，完整读取 公众号内联排版与草稿。保持现有渲染、校验和后台流程；保存草稿后停止，发布、群发、审核或定时发送需要另行明确授权。
• 用户需要生成、重写、审查或双语化 GitHub README 时，完整读取 GitHub README 方法。中文为仓库主语言时默认使用 README.md + README_EN.md；两份文件顶部提供相对链接切换，英文按英语开发者习惯重写，不逐句机翻。生成文件后运行 scripts/validate_readme_pair.py；只审稿且未修改文件时不运行。

交付原则

用户要什么就交付什么。事实表、策略卡、叙事推进表和配图蓝图可在内部生成以保证质量，但不默认全部展示；只交付用户请求的正文、标题、摘要、HTML、配图或其他成品，以及会影响发布安全的必要说明。正文不混入审稿备注、事实标签、待补提示和配图说明；需要标注稿时另做副本。第三方反馈在正文中自然归因。

不编造事实、数据、评论、经历、效果或引语；不把医疗、法律、心理和关系建议写成保证；许可证以仓库实际文件为准。不得生成、索取、读取或保存公众号凭据，也不得把“保存草稿”扩大为发布。

修改本 Skill 时，完整读取 测试场景，按改动范围做轻量测试；不默认运行公众号、Word、图片或后台交付测试。