计划执行与检查节点
executing-plans
按既定实施计划完成工作,保持过程检查和反馈。
de-ai-writing【效率与协作】Use when the user asks to remove AI tone, humanize a draft, or polish text written (or smelling) like an LLM. Trigger phrases include "去 AI 味"、"去ai味"、"降低机器感"、"改得像真人写的"、"不要 AI 腔"、"humanize"、"de-ai"、"remove AI tone". Default optimized for Chinese; supports zh/en mixed text. Always cross-checks output against the Wikipedia "Signs of AI writing" taxonomy…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
This skill is anchored to Wikipedia's Signs of AI writing taxonomy maintained by WikiProject AI Cleanup. It is the diagnostic source of truth — do not rely on memory or "feel".
Every run MUST:
references/wikipedia-signs.md and walk through Groups A–D.Upstream source: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing Structure inspiration: https://github.com/op7418/Humanizer-zh/blob/main/SKILL.md
If the user explicitly says "skip the checklist" / "just rewrite", honour that — but log in
处理说明that the Wikipedia cross-check was skipped on user request.
Codex supports native subagents. Delegate with spawn_agent, coordinate with send_input, collect via wait_agent, and clean up with close_agent.
Execution preference:
[ANALYST]/[ARCHITECT]/[EXECUTOR]/[REVIEWER] structure in a single response.Minimal orchestration: spawn_agent -> send_input (optional) -> wait_agent -> close_agent
Codex invocation:
$de-ai-writing ...orde-ai-writing: ...
将“去 AI 味”定义为一次风格校正 + 注入声音,不是“伪造真人痕迹”,也不是“胡乱口语化”:
去掉 AI 模式只是工作的一半。无菌、没有声音的写作和机器生成内容一样可疑。
判断“写作是否有人住在里面”的迹象:
强行输出“干净但无灵魂”的文本,与未处理的 AI 文本同罪。
content-research-writer 补证据未指定时默认 standard。
| Mode | Use Case | Rewrite Strength |
|---|---|---|
light | 只去掉明显 AI 腔,不改结构 | Low |
standard | 调整段落、句式、连接方式和措辞 | Medium |
deep | 重写开头、中段推进和结尾逻辑 | High |
voice-lock | 强锁定作者现有语气,只修机器感 | Medium |
默认输出三段;用户只说“直接改”时只给改写结果。
## AI味诊断
- [Wikipedia 分类: 信号名] 具体问题(引用原文片段)
- 最多 3-5 条,挑最强的
## 改写版本
[rewritten text]
## 处理说明
- 保留了什么
- 重点改了什么(按 Wikipedia 分类列动作)
- 还有哪些建议补事实/例子
锁定不可动项:事实、数字、术语、引用、目标读者、语气目标、可接受口语度。
用户未说明时默认:受过基础教育的中文互联网读者;自然、克制、有判断;半口语,不堆俚语。
打开 references/wikipedia-signs.md,按四组扫描原文:
诊断只保留 3–5 条最强信号;不要把所有触发都列出来。
按问题类型选动作,不平均用力:
详细中文短语清单与前后对照见 references/chinese-patterns.md。
交付前再过一遍 Wikipedia 分类法,并自检:
保护:代码块、命令、配置项、API 名、库名、版本号、错误信息、故障链路、性能数字、刻意保留的精确限定词。
改写重点:去“背景铺垫型空话”,更快进入问题;抽象收益 → 工程后果(延迟、复杂度、维护成本);保留术语,不洗平。
禁止:改代码语义;合并丢步骤顺序;把报错/命令/配置键改近义词;把工程判断放大成不准确的结论。
保护:经文引用、章节号、关键措辞、神学立场、教义边界、释经逻辑、牧养语气中的庄重与节制。
改写重点:去模板化引言不稀释属灵重量;推进更像真实宣讲而非答题分点;保留敬虔、谦卑和边界感,不改成轻松鸡汤。
禁止:改动经文原意或换松散意译;把谨慎神学表述改武断;把讲道改营销文;为“自然”削弱敬畏、悔改、恩典、十字架等核心语义。
完整领域 playbook 见 references/domain-playbooks.md。
仅在用户要求评分或多版本对比时输出:
| 维度 | 评估问题 | 得分 |
|---|---|---|
| 直接性 | 直接陈述还是绕圈宣告 | /10 |
| 节奏 | 句长是否变化 | /10 |
| 信任度 | 是否尊重读者智慧 | /10 |
| 真实性 | 是否听起来像真人 | /10 |
| 精炼度 | 还有冗余可删吗 | /10 |
| 总分 | /50 |
判定:≥45 优秀;35–44 仍可优化;<35 重写。
content-research-writerplan 梳理提纲writer-memoryreferences/wikipedia-signs.md — Wikipedia 53 类信号 + 中文映射(强制参考)references/chinese-patterns.md — 中文常见套话、替换方式、前后对照references/domain-playbooks.md — 技术 / 讲道领域的保护与禁止动作