企业官网建设流程全解析

Unslop 实战指南：用 pstack 的 AI 写作痕迹清洗规则写出干净的人类文本

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

在 AI 辅助开发的日常里，"一眼 AI 味"的文本几乎无处不在：PR 描述里堆着 "Additionally" 与 "delve"，回复里藏着 "I hope this helps!"，文档标题全是 "Title Case" 配冒号。pstack 插件中的 unslop 技能 就是为消灭这类痕迹而生的文本编辑规范。它给出一份带稳定编号的 AI 痕迹检测清单，要求 Agent 在扫描后重写、保留原意、匹配目标语气，并自问"这段文字为什么会让人一眼看出是 AI 生成的"。读完本文，你将掌握完整的规则目录、调用姿势，以及它在 pstack 写作流水线（poteto-mode、opening-a-pr、technical-writing）中的实际位置。

unslop 是什么：一个必须常开的文本清洗技能

pstack 是作者 poteto 在 Cursor 中日常使用的一套工程技能集，其 README 开宗明义地写了一句判断："there's a growing sense that ai writes too much slop code. i agree."（越来越多人觉得 AI 写了太多"垃圾代码"，作者认同这一点，并希望不要"像一支由二十个 slop 艺术家组成的团队那样发货"）。unslop 正是这套理念在文字层面的落点：/deslop负责清洗代码里的 slop，/unslop负责清洗文字里的 AI 痕迹。

从技能元数据看，unslop 的定位有几个关键点：

--- name: unslop description: Cut AI tells from any writing. Must always apply. disable-model-invocation: true ---

• description 里写着 "Must always apply"（必须始终应用）：它不是按需调用的工具，而是常驻的写作纪律。
• disable-model-invocation: true：模型不会靠自身猜测自动触发它，而是由调用方（其他技能或用户指令）显式带入，保证触发时机可控。

在 poteto-mode 的触发规则中有一条非常明确的绑定："Any prose surface → the unslop skill. Your reply is a prose surface."（任何文字表面都走 unslop，你的回复本身就是一块文字表面）。也就是说，在 poteto-mode 下，Agent 的每一次回复、每一段说明，都被视为需要经过 unslop 清洗的散文，写作必须"边写边净"，而不是写完再补一道清理工序，因为"drafting 之后的清理流程无法移除这些模式"。

三步工作流

unslop 的 Process（处理流程）极简，只有三步：

1. 扫描：对照规则清单（Patterns）逐一检查文本中出现的 AI 痕迹模式。
2. 重写：保留原意，匹配目标语气，把痕迹改写掉。
3. 自审：问自己"What makes this obviously AI generated?"（是什么让这段文字一眼就是 AI 生成的），把剩余的痕迹修掉。

第三步的自审是整个流程的关键：它不是语法检查，而是"换位成读者"的体验检查。这与 pstack 的 technical-writing 技能 中"一篇累工程师一眼就能读懂的文档"的总体目标一致，也和 principle-minimize-reader-load（最小化读者认知负担）遥相呼应。

规则编号为什么有缺口

规则清单的编号是1, 3, 5, 7, 8, 9 ... 33，中间缺了 2、4、6、21 等编号。这不是笔误。SKILL.md 明确说明：

Rule numbers are stable ids that other skills cite. A removed rule leaves a gap.

（规则编号是稳定 ID，其他技能会引用它们；被移除的规则会留下空缺。）也就是说，编号体系刻意保持稳定，即使某条规则被删除，编号也不回填，以免破坏其他技能对特定编号的引用。在 poteto-mode 中就存在这种跨文件引用：它直接点名"A colon as a mid-sentence connector is also out(unslop rule 14)"，把 unslop 的第 14 条规则当作共享规范来执行。这意味着当你修改 unslop 时，必须考虑所有引用方，这正是"稳定编号"设计的意义。

按类别掌握规则目录

规则按内容分为七大类：Content（内容）、Language（语言）、Style（风格）、Communication artifacts（交流产物）、Filler（填充词）、Jargon（行话）、Plain speech（平实表达）。下面逐类展开，每条规则都给出原文要义、判别要点和改写示范。

Content：内容层面的痕迹

内容类规则针对的是"看似说了什么、其实什么都没说"的写法。

规则 3：表面的 -ing 短语。如 "highlighting..."（凸显）、"ensuring..."（确保）、"reflecting..."（反映）、"showcasing..."（展示）、"fostering..."（培育）。处理方式二选一：直接删除，或者用真实来源把它落到实处。这类短语是典型的"氛围词"，删掉后句子往往原样成立，说明它本来就不承担信息。

规则 5：模糊归属。"Experts believe"（专家认为）、"Industry reports suggest"（行业报告显示）、"Some critics argue"（一些评论者主张）。要么写出具体来源，要么整体删除。一个没有名字的"专家"并不能为论点背书，只会暴露作者不想负责。

Language：语言层面的痕迹

规则 7：AI 词汇表。这是最容易被识别的清单，原文给出了明确的禁用词与替换方向：

Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant.

这些词用平实的替代即可：Additionally 可以直接去掉或换成 "Also"；crucial 换成 "important"；delve 换成 "dig into"；enhance 换成 "improve"。判断标准很简单：换成日常口语词，句子是否依然准确。在 technical-writing 里有同一条原则的强化表述："Use the short, everyday word. 'Use', not 'utilize'. 'Help', not 'facilitate'. 'Do', not 'perform'. A long word has to buy its length with precision."（长词必须用精确性来买它的长度。）而 bro 技能（把上一条消息用平实的人类语言重述）可以被视为规则 7 在对话场景的极端形态。

规则 8：花哨的"是"。"serves as"、"stands as"、"boasts"、"features" 这类词往往只是在给 "is" 或 "has" 化妆。直接说 "is" 或 "has"。

规则 9："Not just X, but Y."（不只是 X，更是 Y）。这种对比框架经常是修辞空转，直接陈述观点本身即可。

规则 10：三连（Rule of three）。强行把观点凑成三组（如 "fast, reliable, and secure"），是演讲技巧对技术文档的入侵。该几个就几个，用自然数量。

规则 11：同义词轮换（Synonym cycling）。同一段里把同一个概念换着花样说：protagonist、main character、central figure、hero 全来一遍。正确的做法是选一个词，反复用它。这一点与 technical-writing 的 Global English 层规则完全一致："Call each thing by one name, everywhere."（每样东西自始至终只用一个名字。）

规则 12：伪范围（False ranges）。"from X to Y" 中 X 和 Y 不在同一个有意义量纲上，例如 "from startups to enterprises" 看似给出范围，实则没有具体信息。直接把主题列出来。

Style：风格层面的痕迹

规则 13：破折号（Em dash）滥用。这条非常严格：完全避免 em dash（——），只使用句号或逗号；不用括号、不用 en dash、不用连字符冒充破折号。如果一个想法需要分隔，就结束句子或改用逗号。poteto-mode 把这条内化成了自己的硬性写作规则："No long-dash character anywhere."（任何地方都不出现长破折号字符），并给出了具体替换示例：文件清单写成句子（"main.jsowns persistence and the IPC handlers"），粗体小标题写成独立句子（"Verification.End to end via CDP"）。technical-writing 的 Global English 层也有同款规则："Use periods, not semicolons. Replace an em dash with a new sentence."（用句号代替分号，用新句子代替破折号。）

规则 14：冒号滥用。冒号在列举或举例之前是合法的，但不能当作句中连接符。原文给了一个典型病例：

"If you're coming from traditional automation: instead of registering event handlers, you describe conditions"

这个冒号没有贡献任何信息，纯粹是语法拐杖。改写后：

"Describing when the scheduler should fire works best as plain English."

同样意思，去掉了对比框架和冒号，让观点自己站住。poteto-mode 直接复用了这条："A colon as a mid-sentence connector is also out (unslop rule 14). A colon before a list is fine."（句中连接用的冒号禁用，列表前的冒号没问题。）

规则 15：粗体滥用。不要给每个专有名词和缩写都加粗。粗体只该标记真正需要强调的内容。

规则 16：行内标题式列表。典型 tell 是"粗体标签+冒号+复述行"的结构，例如 "Performance:Performance improved..."（标签和正文复述同一件事）。处理方式是转成散文。但原文同时给出了合法的边界：如果粗体引导语以句号结尾、命名了条目、后面紧跟真正的新信息，就不算 tell：

"Schema in TypeScript.Tables live in one file."

（"Schema in TypeScript." 作为独立句号收尾的粗体小标题，后面 "Tables live in one file." 是新信息，这是允许的。）poteto-mode 的回复规范里也沿用了这一形态："a bold section header as its own sentence"。

规则 17：标题用句首大写（sentence case），不用 Title Case。即 "How to calibrate the radar array"，而不是 "How To Calibrate The Radar Array"。technical-writing 同款："Headings carry the point, not just the topic... Sentence case."

规则 18：装饰性 emoji。从标题和列表项中移除。emoji 只在表达真实情感语境（如聊天）中才有位置，技术文档的标题和 bullet 里它是纯噪音。

规则 19：弯引号（Curly quotes）。替换为直引号（straight quotes）。弯引号往往是文字处理软件或 LLM 输出管线引入的，代码语境下还可能引发解析问题。

Communication artifacts：交流产物层面的痕迹

规则 20：聊天机器人套话。"I hope this helps!"、"Let me know if..."、"Of course!"、"Certainly!"、"Found the smoking gun!"（找到确凿证据啦！）。全部删除。这些句子不携带任何信息，纯粹是社交润滑剂的劣质仿制品。

规则 22：谄媚语气（Sycophantic tone）。"Great question! You're absolutely right!"（好问题！您完全正确！）直接回答问题，不要先给情绪反馈。这与 poteto-mode 的 "No is an acceptable answer... candor over sycophancy"（真诚优先于谄媚）一脉相承：pstack 甚至把"直说真话、拒绝加戏"写成了 Agent 的默认姿态。

Filler：填充词层面的痕迹

规则 23：填充短语。给出三组经典替换：

• "In order to" → "To"
• "Due to the fact that" → "Because"
• "It is important to note that" → 直接删掉

technical-writing 顶部也有同款："Cut every word that does no work."（删掉每个不干活的词），并给出 "It is important to note that is nothing"（它什么都不是）的判定。

规则 24：过度含糊（Excessive hedging）。"could potentially possibly be argued that it might"（可能大概也许可以说它或许）这一串叠加的模糊词，最终只该留下一个 "may"。含糊不是谨慎，是把判断责任推给读者。

规则 25：泛泛的结论。"The future looks bright."（未来一片光明。）这种句子里没有信息，正确的收尾是写出具体的计划或事实。

Jargon：行话层面的痕迹

规则 26：抽象隐喻名词。这是规则清单中最长的一条，也是 technical-writing 明确授权 unslop 独家持有的"违规词汇表"（"That skill owns the slop-pattern catalog"）。原文列出的词：

Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel.

这些词"读起来很技术，但通常有更平实的具象词"。原文给出的替换表：

• "Substrate" → "base"
• "Wedge in" → "add"
• "Vector" → "way" 或 "method"
• "Gold-plating" → "more than the job needs"
• "Ratchet" → 机制的真实名称，或 "a limit that only tightens"
• "Evacuate" → "move out"
• "Endgame" → "the last phase"

选具体的词。判据来自 technical-writing 的提法："Use the words a developer would say out loud"（用开发者会脱口而出的词），"move"、"delete"、"a budget that only decreases" 而不是 "evacuate"、"ratchet"、"endgame"。

Plain speech：平实表达层面的规则

这一节是清单的收尾，也是把前面所有规则升华成方法论的部分。

规则 27：说它做了什么，而不是它给人什么感觉。原文的三个反例都是"感觉式"描述：

• "the database stays close at hand"（数据库就在手边）
• "SQL you can read"（你能读懂的 SQL）
• "types that follow your schema"（跟随你 schema 的类型）

它们描述的是情绪而不是机制。修正版给出机制或数字：

• ".toSQL()returns the exact string sent to the database"（返回真正发给数据库的那个字符串）
• "a column rename fails the build"（改个列名构建就挂）

方法论部分给出两条硬判据：第一，问"这句话告诉读者要做什么或知道什么"，然后把它写出来；如果你无法把它重述成一条具体指令、一个事实或一个数字，就删掉它。第二（也是最狠的一条）：如果这句话原封不动出现在另一个项目的文档里也毫无违和，那它对这个项目就什么都没说，删掉它。这正是"泛泛而谈"的终极检测法。technical-writing 里有完全一致的表述："Be specific over sterile. Not 'schema changes can cause issues' but 'a column rename fails the build'."

规则 28：缩短或拆分稠密长句。如果读者必须回读才能解析一句话，就把它拆成两句或删掉从句。一句话只承载一个想法。这条与 STE 层的 "One instruction per sentence. One thought per sentence everywhere else."（每条指令一个句子，其他场合每句一个想法）以及"把超过 25 词的句子拆开"的数量化约束互为表里。

规则 29：主动语态优先。抓住 "is/are/was/were + 过去分词" 的模式，找出动作发出者：

• "queries are validated" → "the compiler validates queries"
• "the file is parsed by the loader" → "the loader parses the file"

只有动作发出者未知、或确实无关紧要时才允许被动语态。technical-writing 的 Google 风格层同款："Say who does what: 'the compiler checks', not 'is checked'."

规则 30：删副词，或换更强的动词。"runs quickly" → "is fast" 或直接写数字；"significantly improves" → 写出实测的差值（measured delta）。一个副词撑着一个弱动词，说明动词本身选错了。这条与 pstack 的 principle-prove-it-works（拿真实证据验证，而不是口头宣称）在精神上完全同构：与其说 "significantly improves"，不如给出 before → after 的数字。

规则 31：优先用平实词。经典四组：

• "utilize" → "use"
• "leverage" → "use"
• "facilitate" → "help"
• "numerous" → "many"
• "in the event that" → "if"

更花哨的同义词极少更清晰。

规则 32：矫揉造作的文风（Mannered prose）。在存在字面表达时使用隐喻或修辞：

• 格言警句（aphorisms，如 "wire it or delete it"）
• 为效果而设的修辞性碎片句
• 拟人化代码（"the plan holds it"）
• 比喻性动词（"rides along"、"stands on"）
• 陈旧的框架短语

修正示例："A dial worth turning"（值得一转的旋钮）→ "a parameter worth varying"（值得变化的参数）。说你想说的意思。规则 26 管的是隐喻名词，这条管的是隐喻句法。

规则 33：过度压缩（Over-compression）。丢掉冠词、无动词碎片、符号语言、缩写，这些都会让读者去解码而不是去阅读。原文的病例：

"Parser rejects bad date → exit 2, no write"

改为完整句子：

"The parser rejects a bad date, exits with code 2, and writes nothing."

写带冠词和动词的完整句子，把箭头和缩写拼出来。注意这条与规则 28（拆长句）并不矛盾：压缩的对面不是冗长，而是可读。technical-writing 的 Global English 层用同一立场解释了为什么小词要保留："Keep the small words that show structure... Never trade clarity for word count."（永远不要拿清晰度换字数。）

在 pstack 中如何调用 unslop

unslop 不是独立触发的 slash 命令，而是由调用方带入。常见姿势来自 05-build-and-clean 指南：

/unslop the readme changes, no emdashes

它会读取目标文本（这里是 readme 改动），应用规则清单，外加你临时追加的约束（"no emdashes"，即规则 13）。指南还说明：技能对简短指令的理解力很强，"unslop that, tighten it" 这样的口语化指令也能正确执行。你可以在指令里叠加任意额外规则，把它们当作规则 13-19 的临时补充。

与 poteto-mode 的绑定

在 poteto-mode 中，unslop 是"任何文字表面"的默认出口：回复要按它的规则写，Agent 对子代理的指令文本同样适用（"Agent-facing prose also follows the create-skill skill"），而且必须是草稿阶段就干净，因为"清理流程无法移除这些模式"。

在 PR 与提交流水线中的位置

opening-a-pr 剧本（每个其他剧本结束时都会被调用）把分工说得非常清楚：

Write every PR title, PR description, and commit body with/technical-writing, then apply/unslop.

即：先用 technical-writing 的四层标准起草，再上 unslop 做痕迹清洗。而 05-build-and-clean 指南 给出了三者分工的总纲：

/deslopcleans slop out of the code,/unslopcleans it out of prose, and/no-commentshands the comments to a reviewer who didn't write them.

（deslop 清代码里的 slop，unslop 清文字里的 AI 痕迹，no-comments 把注释交给没写过它的审查者。）三者各管一段，unslop 专管散文。

在其他技能中的传播

unslop 的引用遍布 pstack 的各个出口，凡是 Agent 要产出文字的环节几乎都有它：

• show-me-your-work（决策日志）："Plain words, concrete actions, no AI speak or abstract jargon (the unslop skill applies to log text too)." 决策日志这种看似"内部"的产物也要过一遍 unslop。
• teach（讲解）："Write every response through the unslop skill, in plain spoken English." 教学回复同样适用，且要求 "State the concrete mechanism, not a metaphor"（讲具体机制，不讲隐喻），与规则 27、32 直接对应。
• automate-me（生成你自己的 -mode 技能）：起草的技能文件要"Apply the unslop skill and create-skill's writing guidelines to every line"。
• benny 自动化包（Slack 工单修复）：PR 文案和所有 Slack 更新都要 "Run the pull request text and all Slack updates through pstack's unslop skill"；triage-issue-reports 技能 也要求在最终结论上应用 unslop。
• blast-radius（影响面评估）：分析报告要 "Write it through unslop, cite real code"。
• recall（上下文简报）：简报要过 unslop 再输出。
• technical-writing 更是把 unslop 指定为"每份经手的文档都要应用"的收尾技能："Apply the unslop skill to every doc this skill touches. That skill owns the slop-pattern catalog."

与相关技能的分工与配合

实战：一段"去 slop"的完整演练

以 technical-writing 自带的 worked example 为例（该示例本身就是 unslop 规则的集中体现）：

原文（满是 slop）：

Configuration of the proto import ratchet budget script parameters is performed via budget.json. Note that it's important to remember that running with --write, which updates the committed budget to reflect the current count, should only be done when lowering it. If exceeded, CI fails.

问题标注：

• "Configuration ... is performed via"（规则 29 被动语态 + 规则 8 花哨"是"）
• "Note that it's important to remember that"（规则 23 填充短语叠加）
• "ratchet budget"（规则 26 抽象隐喻名词）
• 一句话塞进三个从句（规则 28）

重写后：

budget.mjsreads the committed budget frombudget.jsonand counts the files that import protos. If the count exceeds the budget, CI fails. Runbudget.mjs --writeonly to lower the budget.

• "reads the committed budget"（规则 27 说机制：具体文件、具体行为）
• 三句短句各承载一个事实（规则 28、29）
• 数字和真实符号代替了抽象名词（规则 26、31）

这就是 unslop 的理想输出：具体、短句、主动语态、真实符号，每一个词都在干活。

把 unslop 用起来：最小实践清单

1. 默认开启：在 poteto-mode 下，所有回复、PR 描述、commit body 都默认走 unslop 规则，不用等用户提醒。
2. 调用姿势：/unslop <目标文本>，<额外规则>，如/unslop the readme changes, no emdashes；口语化指令同样有效。
3. 排序纪律：technical-writing 起草 → unslop 清洗 → 提交；代码走 deslop，注释走 no-comments，文字走 unslop，别混用。
4. 自审三问：哪些词属于规则 7 的禁用词汇表？每句话能否重述成一条指令、事实或数字（规则 27）？这句话换一个项目还能原样出现吗（规则 27 的终检）？
5. 扩展清单：发现新的违规模式时，technical-writing 给出了一条明确路径：把新词及其替换建议作为对 unslop 第 26 条（抽象隐喻名词）的补充提案提出，附上 diff，但不要去改 unslop 技能本身（"Don't edit that skill."）。这既维护了清单的单一权威来源，也让规则库可以持续进化，同时保持规则编号的稳定引用。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins