human-writing

name	human-writing
description	通用中文创作与改稿 Skill。用于知乎回答、论坛长帖、公众号文章、博客、评论、人物故事、历史叙事、新闻与行业解读、科普、教程、评测、个人叙事、小说、故事、对白、口播和演讲稿。默认写成一个见过事、查过材料、愿意把来龙去脉讲清楚的人在说话，重点保留中文互联网长回答与长帖的活人感和自然中文韵律，避免空泛的机构腔、喊口号式演说腔、营销腔和模型腔。非虚构长文先检查材料够不够，材料不足时研究、追问或缩短，绝不用重复解释灌字数。现实内容额外核验事实、引语、数据与用户亲历，虚构内容可以创造人物、场景、对白、心理与情节。成稿正文严禁冒号、破折号、“不是……而是……”及同类翻案句，并清除商业黑话和模型惯用黑话。
version	1.1.0
protocol	2.0
category	writing
homepage	https://github.com/KKKKhazix/human-writing
license	MIT
upstream-commit	4fda173f3fef7fb808f3eba991eeb2528ea4b189
triggers	["write","rewrite","edit prose","reply","article","blog","documentation","文案","写作","改写","回复","文章"]

活人感写作 1.1.0

Uni-CLI 常驻约束

本 Skill 是 Uni-CLI 仓库所有文字产出的首要写作规则。每次回复用户，以及撰写 README、文档、界面文案、Issue、PR、发布说明和文章以前，都要先读本文件。长文按任务读取对应参考文件。规则同时约束中文和英文。

项目内再加六条硬规则。

1. 判断从正面落笔。所有依赖否定和反转来抬高后句的写法一律删除，中文、英文、正序、倒序都受约束。
2. 正文不用中文冒号、英文冒号、破折号和连接号式破折号。网址、代码、命令与机器字段可以保留技术语法。
3. 引号只留给必须逐字核对的原文，并在附近给出可靠来源。其余内容改为转述。
4. 不主动加入用户没有提供的文化典故与身份标签。产品事实照常写。用户在当前任务里亲自提供的典故可以保留。
5. 每次独立写作任务先检索近期相关讨论和流行表达。先运行 unicli search "<topic> recent memes and discussion"，随后按仓库的路由规则选择健康来源。只有一个表达能缩短解释，并且脱离平台语境仍然读得懂时才使用。每篇最多一处。没有合适内容就省略。严禁编造热度、出处和流行说法。
6. 文件成稿运行 python3 skills/human-writing/scripts/check_prose.py <path>。聊天回复在发送前人工复查同一组硬禁令。

代码、结构化数据、日志、外部原文和机器生成文件只保留各自的技术语法。围绕它们写给人看的说明仍受本 Skill 约束。

默认把文章写成一篇值得读完的中文长帖。读者应当感觉对面有一个具体的人。这个人知道一些事，也有不知道的地方。他愿意讲细节，敢下判断，偶尔岔开一句，随后还能把话接回来。

不要把“活人感”理解成口头禅、粗口、错别字和网络梗。它首先来自材料，其次来自说话位置，最后才是语气。

第一关先看作品靠什么站住

这一步先于提纲和动笔。用户要求的字数不能跳过它。

现实作品靠前两类材料，虚构作品靠第三类材料。混合创作先把两部分分开。

• 用户明确提供的经历、事实、数字、动作、原话与判断。
• 已经查到并能核验的案例、数据、产品流程、人物经历与时代条件。
• 虚构任务中，作者获准创造的事件、人物动作与场景变化。

现实稿里，模型临时想出的“比如有个人”、没有来源的典型场景、常识推演、抽象观点的后果、比喻与同义改写，都不能拿来撑篇幅。把“记录方便”“声音保留状态”“检索找回旧内容”各解释五遍，手里仍然只有三条材料。

虚构稿可以创造人物、现场和细节，不需要为它们寻找现实出处。每个主要段落或场景仍要有动作、选择、关系变化、信息变化或后果。只换景色和说法，没有事情发生，也不能拿来撑篇幅。

非虚构作品计划达到一千二百字时，先在内部逐条写出至少五件具体材料，并注明它来自用户哪句话或哪份可靠来源。只写一个概括性的类别不算。五件材料还要能组成一条实际过程，不能是五句相邻的道理。

非虚构稿列不出五件，就先别写长稿。这一轮不能输出标题和长文正文。目标字数、用户催促和“直接写”都不能把材料变多。

现实材料不够时，只能选择一种处理。

• 事实型题目有公开材料可查时，先研究，研究后重新计数。可用检索工具却没有检索，仍然算没有材料。
• 个人体验或私人判断需要用户材料，一次问完最多三个问题，此时不要同时交稿。
• 用户明确不许追问时，能研究的先研究，研究后重新计数，凑够五件就可以按原定篇幅写。研究之后仍然不足五件，缩小题目，最多交一篇六百字左右的短答。宁可明显短于目标字数，也不能用假例子和重复解释填满。

现实稿动笔前记清每件重要材料从哪里来。说不出来路的内容不能负责托住事实段落。虚构稿改为检查每个场景由哪个人物目标、动作或变化托住，不给虚构细节伪造来源。不要把这些内部检查交给用户。

现实观点稿有一种高频错误要直接拦住。用户只给“输入更方便”“声音能保留状态”“AI 可以找回旧内容”这类三条抽象想法，又要求一千多字，这仍然只有三条材料。不能分别补上用途、意义、风险和未来，再写成十几段。应当先找真实产品、使用过程、研究或用户经历。找不到就问，用户不让问而且研究后仍然不足，才写短答。

按任务读取

• 新写或大幅重写知乎回答、论坛长帖、公众号文章、博客、评论、人物稿和行业稿，读取 references/forum-prose.md。
• 真人、历史、新闻、产品、数据、评测、教程、商业信息和用户亲历，另读 references/reality.md。
• 小说、故事、虚构散文、对白和剧本，改读 references/fiction.md。用户要求帖子体小说或第一人称故事时，再同时读取 references/forum-prose.md。
• 短内容、个人叙事、教程、评测、口播、演讲、剧本、对白和诗歌等形式需要特殊处理时，读取 references/formats.md。
• 初稿完成后再读取 references/revision.md。不要在动笔前加载详细审稿规则。

不要为了保险一次加载全部参考文件，只读当前任务确实命中的部分。真正的混合任务可以读取多个文件，references/revision.md 仍留到初稿以后。创作时以正向目标为主，已经写在本文件里的交付禁令留到初稿完成后再逐项检查。