# Qiangshou > 将独立开发者、女性开发者和 AI 创作者的真实项目、人物经历与可验证观点写成中文微信公众号长文、公共反叙事短评或专业 GitHub README。支持项目故事、观点实证、人物关系叙事、公共争议回应、迭代复盘、技术踩坑、旧稿重写、审稿、内容冻结排版、配图、微信兼容 HTML 与草稿保存，也支持从真实代码生成或优化中英双语 README、顶部一键切换语言、首屏 Star 引导、状态徽章、Stargazer/支持者展示、快速开始、架构说明、真实许可证口径与双语同步校验。用于从仓库、日志、实验、用户口述、公开动态、反馈和旧稿中核验事实，写清价值、差异、人物选择、技术取舍、数据、边界与行动。不要用于通用新闻洗稿、虚构经历、隐私曝光、骚扰动员或未经明确授权的发布、群发和凭据操作。 - Skill: `shengjidaguai-china/qiangshou` (Agent Skill, multi-file: 26 files) - Install (CLI): `npx skillmds@latest add shengjidaguai-china/qiangshou` - Raw SKILL.md: https://api.skillmd.com/api/skills/shengjidaguai-china/qiangshou/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: shengjidaguai-china (https://skillmd.com/u/shengjidaguai-china) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shengjidaguai-china/qiangshou --- # 枪手 把真实项目或可验证观点写成持续推进、说人话的公众号长文。不要把功能清单、营销卖点或开发日志扩写成散文。 ## 选择任务模式 - **从零写作**：先建事实表和策略，再写标题、提纲与正文。 - **重写旧稿**：保留可验证事实，指出失速点后重组叙事，不只做同义改写。 - **观点实证长文**：用个人经历、实验、数据或权威材料纠正一种流行认知。写清大众认知、作者质疑、公平对比、意外结果、可执行方法与价值判断；不硬套项目故事，也不写成论文。 - **审稿**：先提出具体、可执行的建议；用户明确授权后再改稿。 - **内容冻结排版**：只添加标题、强调、留白、分隔、图片或数据卡，不改变正文文字与顺序。 - **公众号成稿与草稿**：把确认后的 Markdown 转为微信兼容内联 HTML；仅在用户明确授权时操作已登录后台并保存草稿。 - **GitHub README**：读取真实代码与项目证据，生成或优化 `README.md`；中文项目默认同时交付 `README_EN.md`，两份文件顶部互链，一键切换语言。标题和一句话价值之后优先放 Star 行动、有效徽章与社区信号；专业感同时来自可运行示例、架构、测试、维护状态、支持者和清晰的许可边界，不来自夸张营销。用户要求新增许可证时，优先采用权利范围匹配的成熟现成协议及其官方原文，避免自行拼接条款。 ### 终稿保护 用户把当前文案称为“终稿”“发布版”“最终文案”“最终采用版本”“我已经改完了”，明确要求“不要改文案”，或本次写作已经完成“配图 + 公众号可复制 HTML”交付时，保留当前文字与顺序。除用户明确授权外只能建议，不能直接修改；即使审稿发现问题，也先说明而不动正文。用户已经删除或否决的内容不得重新加入或反复建议，只有用户主动要求恢复时再处理。 初稿与重写可以直接修改；审稿先建议。进入终稿保护后，除用户明确授权修正的错别字外，不直接改正文。 ## 核心工作流 GitHub README 是独立任务模式。完成下方“读取素材，建立事实边界”后，完整读取 [GitHub README 方法](references/github-readme.md) 并按其中流程执行；不要套用公众号长文的主导推进线、前三屏、移动端节奏、终稿自进化或微信排版规则。下方第 2–4 步只适用于公众号长文、旧稿重写与审稿。 ### 1. 读取素材，建立事实边界 先完整读取用户提供的材料。涉及仓库时，优先检查 README、许可证、架构、关键代码、测试、日志、提交与当前状态，但不修改源项目。涉及外部事实、研究或时效数字时，核验原始或权威来源并记录日期。 写作前完整读取 [事实与策略](references/facts-and-strategy.md)。区分仓库可验证、用户亲述、第三方反馈、推断和时效数据。用户亲述可以写，但不能伪装成仓库证据；反馈必须归因；推断不能写成事实；数字写清基线、范围、方法和时间；原话只有可见文本或用户确认后才能加引号。 材料不足时，最多追问 1–3 个会改变主线的问题。用户要求先继续时，保留待补项，不补写不存在的细节。 ### 2. 定策略与结构 先确定目标读者、传播承诺、主矛盾或核心问题、技术主线、情感/认知变化和自然行动，再定标题与提纲。标题可以直接提问，也可组合数字、投入、结果、反差或身份；只使用正文能兑现的元素。 写作前完整读取 [写作方法](references/writing.md)、[作者文风记忆](references/author-voice.md)和[视觉审美记忆](references/visual-preferences.md)，以用户最新明确选择为准。即使本次不配图，也读取视觉记忆，避免后续排版与封面建议偏离。 当素材主要依靠人物关系、公共冲突、身份反差、日常物件或克制反讽推进时，再完整读取 [微观细节与公共反叙事](references/micro-detail-and-counter-narrative.md)。该文件是第三方参考材料的方法蒸馏，不是作者偏好，不得写入作者文风记忆，也不得把其中的来源人物、标志性物件、口头禅或私人经历移植到新稿。 “项目故事”和“观点实证”只是高层写作意图，不是固定章节模板。每篇现场识别一条主导推进线：事件变化、认知变化、决策变化、实验变化或人物关系变化；其他变化可以辅助，但不能争夺主线。结构必须从本篇事实、冲突、证据、选择与后果中生成，不按预设幕数、章节表或上篇结构套写。版本更新／迭代决策复盘只是一种可选变体，不能扩展成新的固定引擎。 每一章都要让主导推进线发生变化。相邻两节只能用“然后”或“此外”连接时，重建因果。 ### 3. 写正文 第一句话让事情或问题发生，三句内出现真实冲突、反差、数字或明确疑问；尽快说明项目/议题和读者为何值得继续。不要从时代背景、行业趋势或“本文将介绍”开始。 重要技术段落尽量覆盖： `问题 → 为什么难 → 尝试或取舍 → 具体实现 → 可量化结果 → 适用边界` 术语首次出现时用一句人话解释，再回到文件、日志、实验或决策。不能把局部指标外推为整体效果；无法量化时如实写可观察结果。 保持作者聪明、坦率、有判断也允许修正的声音。保留自然口语、自嘲和真实情绪，不自动添加性别刻板话术，不为“高级感”统一润色。短段落为主，长短句交替；表格只用于明显更清楚的比较、映射或时间线。 学习参考文章时只提取结构规律，不复制独特句子、标题、口头禅、私人经历或品牌设计。配图只承担证据、解释或转折；素材不足时少图，不用装饰图冒充事实。 ### 4. 审稿与收束 需要审稿与交付时，完整读取 [审稿与交付](references/review-and-deliverables.md)。先看开场、主线、局面变化和人物/认知推进，再查事实归因、技术边界、数字日期、引语、许可证、重复和移动端可读性。所有长文在交付前执行轻量的“终稿去 AI 味检查”：先删不增加事实、因果、判断或人物变化的句子，再做必要的局部改写；不得机械删字、禁用句式、改变本篇结构或重写成更标准的公关稿。 初稿和重写任务中，发现问题后可以直接修改；审稿时先给建议。进入终稿保护后，除用户明确授权的错别字外，不直接改正文。 生成终稿、配图或公众号 HTML 前，用两套记忆各自自检一次：文案检查句长、口语、删减、列表与 AI 味；视觉检查图片类型、裁剪、拼图、封面构图与排版。没有已晋升偏好时不自行补造。 结尾回扣开场与作者动机，交代当前能力或结论、适用与不适用范围、尚未验证项，以及自然行动。CTA 像邀请，不硬喊点赞、关注或转发。 ## 轻量自进化 出现以下任一条件时，把当前版本视为终稿并在本次任务结束前执行轻量自进化，不等待用户再次确认： - 用户明确称其为“终稿”“发布版”“最终文案”“最终采用版本”或“我已经改完了”； - 一个写作任务已经同时完成配图交付和公众号可复制 HTML 交付。 完整读取 [自进化规则](references/self-evolution.md) 后执行。只从模型前稿与用户手改终稿的真实差异学习；依次区分删除、改写、新增、原样保留，原样保留固定视为助手文字且不得成为用户偏好证据。用脚本生成稳定匿名终稿 ID，并通过持久化信号台账更新记忆；文字规则只进入 [作者文风记忆](references/author-voice.md)，视觉规则只进入 [视觉审美记忆](references/visual-preferences.md)。每次最多新增或修正 2 条抽象规则；用户说“这次不要学习”时跳过。 ## 条件工作流 - 用户要求终稿或“不改内容”排版时，完整读取 [内容冻结排版](references/format-preserving-layout.md)。只在用户明确要求“内容完全不变并验证”时运行 `scripts/verify_content_preservation.py`；不要把校验变成每次交付的默认步骤。 - 用户需要公众号可复制排版、预览或后台草稿时，完整读取 [公众号内联排版与草稿](references/wechat-layout-and-draft.md)。保持现有渲染、校验和后台流程；保存草稿后停止，发布、群发、审核或定时发送需要另行明确授权。 - 用户需要生成、重写、审查或双语化 GitHub README 时，完整读取 [GitHub README 方法](references/github-readme.md)。中文为仓库主语言时默认使用 `README.md` + `README_EN.md`；两份文件顶部提供相对链接切换，英文按英语开发者习惯重写，不逐句机翻。生成文件后运行 `scripts/validate_readme_pair.py`；只审稿且未修改文件时不运行。 ## 交付原则 用户要什么就交付什么。事实表、策略卡、叙事推进表和配图蓝图可在内部生成以保证质量，但不默认全部展示；只交付用户请求的正文、标题、摘要、HTML、配图或其他成品，以及会影响发布安全的必要说明。正文不混入审稿备注、事实标签、待补提示和配图说明；需要标注稿时另做副本。第三方反馈在正文中自然归因。 不编造事实、数据、评论、经历、效果或引语；不把医疗、法律、心理和关系建议写成保证；许可证以仓库实际文件为准。不得生成、索取、读取或保存公众号凭据，也不得把“保存草稿”扩大为发布。 修改本 Skill 时，完整读取 [测试场景](references/test-scenarios.md)，按改动范围做轻量测试；不默认运行公众号、Word、图片或后台交付测试。