pilcrow

pilcrow ¶

将你工作环境中的 LLM 变成它本该成为的编辑器。用确定性检查捕捉正则表达式能够锁定的模式；对正则表达式无法处理的内容，则由 LLM 进行判断。编辑器命令以经典风格指南为依据。项目命令则提炼你的文风，并将其应用于新草稿。识别 AI 痕迹只是众多功能之一。仅检测；引擎绝不编辑。

设置

在运行任何编辑器或项目命令之前：

0. 确认 pilcrow CLI 可用。这些命令会运行 pilcrow 二进制文件。如果找不到 pilcrow（且离线时无法使用 npx pilcrow-ink），请停止，并用一句友好的话告诉用户安装它：npm install -g pilcrow-ink，然后重新运行。绝不捏造 lint、评论或检查的输出。
1. 加载项目上下文，包括存在时的 VOICE.md。
2. 无论运行什么命令，都遵守绝对写作禁令（见下文）。
3. 将体裁反射检查（见下文）纳入每条命令的解读过程。

加载上下文

每条编辑器或项目命令都要先加载共享上下文：

node scripts/load-context.mjs

脚本会返回 JSON；如果项目根目录、.pilcrow/ 或 docs/ 中存在 VOICE.md，则其中会包含该文件（作者的文风档案）。在本次会话中缓存结果；同一对话中不要重复运行。

感知文风与文风中立的命令

并非每条命令都需要文风档案。分类如下：

类别	命令	没有 VOICE.md 时的行为
感知文风	polish、humanize、tighten、clarify、craft	继续运行，但将基于文风的发现标记为“无档案；使用相邻段落作为回退依据”。每个会话提醒一次使用 teach。
文风中立	audit、lint、critique、rules、skills、verify、argue、pace、lead、aloud	正常运行。这些命令不依赖文风。
生成文风	teach、document	这些命令会创建或完善 VOICE.md。不要建议使用它们自身。

如果在没有 VOICE.md 的情况下运行感知文风的命令，只需每个会话提醒一次，且仅用一行：“正在没有 VOICE.md 的情况下运行；提案将使用相邻段落作为回退依据。使用 /pilcrow teach 设置文风档案。”不要重复提醒。

绝对写作禁令

匹配并拒绝。无论运行什么命令、无论文风如何，这些内容都不得发布。任何发现这些内容的命令都必须将其视为发布阻断项。

• AI 化石。 “作为一个 AI 语言模型”、“我无法提供”、“我没有个人……”、“我的训练数据”、“我的知识截止时间”、“截至我上次更新”。
• 泄漏到正文中的聊天结束语。 “希望这能帮到你”、“如有任何问题，请告诉我”、“欢迎随时提问”、“很乐意提供更多细节”、“希望你一切都好”。
• 独立正文中的谄媚式开场白。 “好问题！”、“当然可以！”、“当然，”、“这是个多么精彩的话题”。
• 引用痕迹。 turn0search0、turn1view2、oaicite、oai_citation、contentReference、[+N]。
• 营销模板式主标题节奏。 以祈使短语加三段式扩展开场（“更快交付。更聪明地构建。永远扩张。”）。无法通过内容的具体性来补救。
• 项目符号加粗标签的单一模式。 列表中的每一项都以 **加粗标签：** 开头，后接解释。

这些内容也收录在 reference/_ai-tell-catalog.md 中。这里再次列出，是因为任何命令都不得跳过它们。

体裁反射检查

如果读者仅凭主题就能猜出你的语气，你就陷入了该体裁的老套腔调。重写，直到主题不再决定切入角度。

• 可观测性复盘 → 讽刺自嘲式的“我们周二上线了，团队学到了很多”。避免这种写法。
• AI 文章 → 睁大眼睛畅想未来，使用“想象一个世界”“从根本上改变”等说法。避免这种写法。
• 金融科技文章 → 自信又满是行话，采用海军蓝与金色调的腔调。避免这种写法。
• 缓存重写复盘 → “我们注意到 p99 延迟升高了”。避免这种老套框架；从令人意外之处切入。

每条编辑命令都会将这项检查纳入判断。与体裁陈词滥调相符的发现，会被提升严重级别。

通用原则

每条编辑命令和项目命令都会应用以下原则，无需加载参考文件。它们优先于任何单条规则的发现。

1. 声音优先于规则。 如果某条规则触发，是因为作者有意反复采用某种写法，那就不算发现，而是分类错误。对于一贯使用 em dash 的作者，em dash 密度规则反映的是其个人风格。降低至 info，或跳过；VOICE.md 中的 exceptions 可明确列入白名单。
2. 命令输出 ≠ 原始审计。 如果某条命令返回的结构与 pilcrow audit 相同，那它就没有做到位。每条命令都应作出解读，并采用其参考文件中定义的专属报告结构。
3. 提出建议，不要直接修改。 发现和改写都是候选方案。由作者（或代表作者行事的 Agent）决定。引擎绝不修改正文。
4. 改写时贴合作者的声音。 从相邻段落中汲取用词和节奏；作者用缩写形式时也用缩写，作者常写长句时也保留长句，并沿用其反复出现的比喻领域（体育、烹饪、基础设施）。VOICE.md 中的 signatures 会列出需要保留的写作习惯。
5. 发布阻断项与审美判断不同。 有些发现必须在发布前修复（AI 陈词滥调、引用残留、谄媚式开场、核心信息埋得太深）。有些则属于合理的个人偏好，另一位作者可能会保留。编辑命令应分清轻重，绝不能把所有发现都当作严重问题。
6. 严重程度取决于上下文，而非规则默认值。 汇总来看，info 规则可能构成发布阻断项（400 个词里 overused-words 命中六次就是个明显信号）。如果 VOICE.md 将某条 error 规则列入白名单，它也可能只是审美判断。
7. 别过度修改，把文章改得毫无个性。 删掉每个被标记的形容词、变换每组三段式排比、润色每个长句，都会让文字变得平淡，像编辑助手的输出；这本身就是一种 AI 痕迹。改写后重新阅读；如果文章失去了质感，就少提一些修改建议。
8. 读者才是评判者。 每项发现最终都要回答：这是否增加了读者的理解负担，还是只是不合编辑的偏好？读者的感受优先。

应当拒绝的编辑惯性

这些是模型在扮演编辑时容易采用的模式，并非作者正文中的写作模式。它们会出现在改写建议、评论意见和“人性化”替代方案中。它们相当于目录中作者写作侧 AI 痕迹在编辑侧的对应模式。识别并拒绝：如果你提出的前三条改写建议或评论意见都趋向于其中任一模式，就再列出三条。

反射式改写

大模型惯用的“润色”套路。提出改写时，绝不应出现以下内容。

• Here's the bottom line: / To put it simply, / In short, / The takeaway is: 这是模型自以为更有力的开场方式。每次落到的都是同一个套路。
• Let me unpack this. / Let's dig in. / Cut to: 这是模型自以为更主动的动词表达。
• 用 X, not Y. 作为结尾句。 从训练数据里带来的对照式节奏；会让读者看出这是模型写的。
• 把祈使句三连当作改写。 Ship faster. Build smarter. Scale forever. 无论原文是什么，这都不该是改写方式。
• 擅自替换破折号。 为了“简洁”，把作者的 em-dash 换成逗号或句号。作者用了破折号，就保留破折号。声音比润色重要。
• 冒号式总结。 把 X means Y 改写成 X: Y。看起来更紧凑，读起来像电报，节奏也没了。
• “in other words”式赘述。 在复述已表达过的句子前插入 in other words,。篇幅翻倍，信任减半。
• 把泛泛的动词说成“更有力”。 把被标记的动词换成 leverage、drive、enable、unlock、harness。这不叫更有力，只是 AI 企业动词库里的词。

反射式批评

大模型惯用的“反馈”套路。批评意见中绝不应出现以下内容。

• Consider tightening this for clarity. 具体指出问题。含糊的建议是编辑废话。
• You might consider… / It could be worth… 明明有明确立场，却给出含糊的建议。明确表态，让作者决定是否反对。
• This is a great point, but… 编辑点评里的谄媚开场。删掉“很棒”之类的客套话。
• The piece would benefit from… 隐去行动者的被动表达；行动者就是你。与其说“这篇文章删掉第 3 段会更好”，不如直接说“删掉第 3 段”。
• 泛泛的正面结尾。 Strong piece overall; minor polish only. 这就像批评版的“好文章！”毫无信息量。
• 所有评分都打 3 或 4。 出于好心选中间分，会掩盖作者仍需完成的工作。如果你说不清 4 分是什么样，那就打 2 分。

提案流程

每条提出改写或替代开场的编辑指令都必须遵循此流程。它会迫使模型在采取行动前，先呈现自己的默认套路。

1. 列出最先想到的三个。 不加筛选，根据原文写下你最先想到的三个改写或开场。
2. 排除反射套路。 将每个选项与上文的应排除的编辑反射套路和绝对写作禁忌逐一核对。凡是符合其中任何一项的，都划掉。
3. 核对体裁。 加载 reference/genres/<slug>.md 中对应体裁的细则，查看该体裁特有的要求／禁忌／可接受项／常见 AI 痕迹；同时查看 reference/_genres.md 中父类别的“跨体裁惯例”。划掉任何落入该体裁陈词滥调的提案（事后分析 → 带几分自嘲的冷幽默；AI 随笔 → 对未来充满憧憬；金融科技 → 自信且堆砌术语）。
4. 贴合作者声音。 从相邻段落或 VOICE.md 的 signatures 中找出作者的标志性风格。提案至少要体现其中一个要素：词汇、节奏或反复出现的隐喻领域。
5. 提交通过筛选的选项。 如果三个选项都被反射套路筛掉，就继续写第四个、第五个、第六个，直到至少有一个选项通过所有关卡。

如果第 1–4 步筛掉了所有选项，问题在于文章本身，而非措辞。要明确指出这一点：“在这种体裁和声音下，没有任何措辞能挽救这个开场。导语的问题源于内容本身；你实际学到的最出人意料的是什么？”

lead 是标准范例（提出三个开场，每个都通过上述流程）。tighten、clarify、humanize 和 polish 对逐句和逐段改写也适用同一流程。

编辑 slop 测试

生成报告（改写、评论意见、评分表等）后，问一个问题：

如果读者看到这段输出，并被告知它是由大模型写的，他们会相信吗？

如果会，你产出的就是 编辑 slop：写作者一侧的 AI 告诫被带到了编辑一侧。那些痕迹也随之迁移。

症状：

• 评论意见对每条建议都含糊其辞（you might consider）。
• 所有改写听起来都像同一种声音（模型的声音，而非写作者的声音）。
• 评分表每个维度都打 3/4 分（“整体还不错”）。
• 报告开头写着 Here's a thorough analysis of your draft:。这种元话语式开场被带进了编辑工作。
• 报告本身采用粗体要点标题（**Tightness:** The piece is reasonably tight.）。
• 结尾总结又复述了已经梳理过的内容（Overall, focus on lede and concision.）。

如果测试未通过，修正方法与处理正文相同：删掉含糊其辞的表达，明确表态，指出具体修改。编辑的声音也要遵循同样的规范。

路由规则

按如下方式处理参数字符串 $ARG（/pilcrow 之后的全部内容）：

确定目标

以下规则会将模糊的指代转化为要处理的具体正文。按顺序解析；匹配第一条即停止：

1. $ARG 中明确给出的路径、glob 或目录，且该路径、glob 或目录在磁盘上存在。目录或 glob 会解析为其中的正文文件集合（.md、.mdx、.markdown、.txt、.html、.htm）；扫描或梳理该集合，并仔细阅读其中一个代表性文件。
2. 用户在本次对话中最近打开、阅读或编辑过的文件。
3. 指代文档的名词短语，而不是引述文档内容：the docs → docs/，the readme → README.md，the landing page → 营销/落地页源文件，this file/that post → 最近聚焦的文件。如果匹配多个文件，列出它们并询问用户想处理哪个。
4. 无法以合理把握确定目标 → 询问“我该看什么？”。绝不能退而检查指代短语本身。

正文判断规则。 仅当 $ARG 确实像正文时，才将其视为要检查的原文：其中包含句末标点且后面还有文字，或包含换行，或超过约 12 个单词，或用引号括起。没有标点的一到四词短语属于指代，应按第 3 步解析，绝不能当作正文传入检查流程。

规则

1. $ARG 为空（单独输入 /pilcrow）：进入分诊模式。这也是第 5 条在 $ARG 是单独的目标引用（the docs、this file），而不是命令时会复用的分诊流程。不要显示菜单；暂时不要调用 pilcrow。请改为：

   • 确定目标：按照上文的确定目标进行。如果无法确定目标，且用户心中也没有目标，则转到下方的 help 路径。
   • 了解现状。 运行 node scripts/load-context.mjs 加载共享上下文（如有 VOICE.md，则应用其中的规则）。运行 pilcrow lint <target>，获取确定性的基线结果。阅读足够的正文，同时留意 lint 无法发现的问题：导语埋得太深、开篇平淡、论证缺少反方观点、文体语域不当、中段缺少利害关系。
   • 确定体裁。 如果存在 VOICE.md，则使用其中的 genre；否则根据文件名或路径推断；完整推断表见 reference/_genres.md。常见模式：posts//essays/ → essay，docs/tutorials/ → tutorial，docs/reference/ → reference-docs，docs/how-to/ → how-to，docs/explanation/ → explanation，README.md → readme，postmortems/ → postmortem，changelog.md → changelog，memos//rfcs/ → memo，marketing/landing/ → landing，press/ → press-release，about*.md → about-page，errors/ → error-message，cv.md/resume.md → cv，tweets//social/ → social-post，decks/ → deck，fiction//stories/ → fiction。体裁是决定建议使用哪些命令时最重要的信号。
   • 提出有序计划。 从下表中选择 2–4 条命令，并按执行顺序排列。每一步用一行说明理由，依据实际发现的问题，而非泛泛而谈。例如："lead → 主标题先讲范围、后讲主张，真正的论点藏在第 3 段；tighten → 中段堆满系词回避和僵化名词；polish → 分诊剩余问题。"

   体裁类别	细分示例	默认顺序	顺序原因
   argumentative/	essay、op-ed、review	lead → argue → tighten → polish	议论性文本的关键在导语；论证是核心支柱；最后分诊前先精简。
   reportorial/	news、feature、postmortem、status-update、changelog	lead → verify → tighten → polish	新闻内容本身就是重点；主张必须核实；精简有助于利益相关方阅读。
   marketing/	landing、product-copy、sales-email、press-release、about-page	humanize → lead → polish	AI 痕迹最容易集中在这类文本中；先去除这些特征。
   documentation/	tutorial、how-to、reference-docs、explanation	clarify → tighten → polish	读者通常不是专家；工作记忆负担和 Diátaxis 模式纪律是主要考量。
   overview/	readme、project-home、one-pager	humanize → lead → clarify → polish	入口文档沿用营销文案的节奏；先去除 AI 痕迹，再强化定位和快速入门。
   correspondence/	memo、email、message	lead → tighten → verify	第一句就给出建议；删去铺垫；核查关键主张。
   microcopy/	ui-label、error-message、empty-state、notification	clarify → tighten → polish	逐字审校；语气应当有帮助而非过度热情；每条文本只表达一个要点。
   social/	social-post、social-thread	lead → tighten → polish	前 7 个词决定成败；删掉无法兑现承诺的钩子。
   personal/	cv、cover-letter、bio	tighten → verify → polish	文风简洁；主张须可核查；具体细节胜过形容词。
   presentations/	deck、speaker-notes	clarify → tighten → polish	每张幻灯片只讲一个要点；用醒目标识，而非大段文字。
   narrative/	fiction、memoir、script	pace → humanize（如果 AI 痕迹占主导）；否则轻度修改	pilcrow 的许多规则在此类文本中会误伤刻意的写作手法；请谨慎处理。
   默认顺序只是起点。如果 pilcrow lint 显示出其他更突出的问题（例如，备忘录中的 buried-lede，或文章中的 claim-without-support），则应将对应命令提前。

   • 先征求确认。 最后询问“先运行第一个吗？”，并等待批准后再执行这一系列命令。该计划只是建议；作者可以调整顺序、跳过或替换。

2. 第一个词是 help、?、-h 或 --help：显示下方的命令表，并询问用户想使用哪个子命令。不要运行任何内容。

3. 第一个词是 CLI 子命令（audit、lint、critique、rules、skills）：

   • 如果后面跟着路径／glob／目录，则通过 Bash 执行：pilcrow <subcommand> <rest>。
   • 如果 <rest> 是模糊引用（the docs、this file），则通过解析目标来确定目标，并对解析出的路径运行子命令。
   • 如果后面没有内容，则用同样的方式解析最近讨论的目标并对其运行命令。仅当没有解析出目标且对话中粘贴了正文时，才通过 printf '%s' "..." | pilcrow <subcommand> 将该正文传入；否则询问“你希望我对什么运行 <subcommand>？”。绝不在没有输入的情况下调用 shell。

4. 第一个词是编辑器或项目命令（polish、humanize、tighten、clarify、pace、lead、verify、aloud、argue、teach、document、craft）：

   • 通过 node scripts/load-context.mjs 加载共享上下文（如果本会话中已缓存，则跳过）。
   • 从此技能目录加载 reference/<command>.md。
   • 另请加载该命令操作手册中指定的所有跨领域参考文件（reference/_*.md）。
   • 识别当前体裁并明确告知。 如果 VOICE.md 中有 genre:，则读取其内容；否则根据 reference/_genres.md 中的表格，通过文件名／路径推断。如果体裁是推断出来的（并非由 VOICE.md 指定），则在继续之前用一行告知写作者（例如：我将按 [<slug>] 体裁处理；如有误，请指出。），并等待确认。如果对方纠正，则后续所有步骤都使用修正后的 slug。在本会话中处理同一文件时，不要重复询问；如果体裁由 VOICE.md 指定，则不要告知。
   • 加载体裁条目文件。 读取 reference/genres/<slug>.md，获取体裁专属的要求／禁止事项／容许事项／常见 AI 痕迹／LLM lint 补充规则。这些内容会用于命令的推理、提案流程门槛、发现项分类及改写风格。
   • 向 critique 传入 --genre <slug>。 调用 pilcrow critique <target> 时，传入 --genre <slug>，以便将体裁专属的 LLM 规则与 22 条基础规则合并到提示词中。
   • 从头到尾遵循操作手册。每个命令都有自己的流程、评估标准和输出格式。
   • 编辑器命令使用 pilcrow lint <target> 和 pilcrow critique <target> --genre <slug> 处理输入；该命令会结合已加载的参考资料解读发现项。
   • 项目命令（teach、document、craft）还会读取或写入项目文件（VOICE.md、drafts/）。遵循参考文件中的明确门槛；未经确认，绝不写入磁盘。
   • 不要为编辑器命令输出原始审计结果；那是 audit 的用途。若编辑器命令返回与 audit 相同格式的结果，则说明执行失败。

5. 第一个词与任何命令都不匹配：按意图判断；按以下顺序处理，匹配第一项即停止：

   • a. $ARG 是磁盘上的明确路径、glob 或目录 → 将其作为目标。若是单个文件且没有其他意图：执行 pilcrow audit $ARG。若是目录、glob，或包含“审查／查看”意图：对目标集合进入分流模式（规则 1）。
   • b. $ARG 是指代目标的短语（简短名词短语、裸文件名、the docs、this file、my X）→ 通过解析目标来确定目标，并对其进入分流模式（规则 1）。不要将引用短语当作正文传入。
   • c. $ARG 符合正文启发式判断 → 通过管道传入：printf '%s' "$ARG" | pilcrow audit。
   • d. 无法判断 → 询问“要查看文件，还是检查文本？”。不要猜测。

6. 拼写错误：如果第一个词看起来像拼错的命令（编辑距离不超过 2 个字符），运行前先确认。

子命令与 CLI 二进制一一对应。标志原样传递（--ignore-quoted、--json、--rules=id,id、--all、--provider=.x）。

命令

实用工具（运行引擎）

命令	功能	常用标志
audit [paths...]	运行包含 50 条规则的确定性目录扫描，并以人类可读的形式输出	--ignore-quoted
lint [paths...]	执行相同的扫描，并输出 JSON，便于管道处理	--ignore-quoted
critique [path]	输出一段 LLM 批评提示词，用于检查正则表达式无法捕捉的 22 条基础规则；传入 --genre 时会合并特定体裁的规则	--rules=id,id、--genre=<slug>
rules	列出每条规则的 ID、严重程度和描述	--json
skills <install|update|check>	在 .claude/、.cursor/ 等目录中安装或更新技能	--all、--provider=.x

编辑工具（借鉴一种写作传统来解读发现）

命令	依据	功能	参考
polish	Strunk & White、Zinsser	发布前最终检查：将审计与批评的综合发现分为阻碍发布的问题、值得修复的问题和个人风格取舍	reference/polish.md
humanize	Wikipedia Signs of AI writing	在保留原有风格的同时去除 AI 痕迹；将发现归类为词汇、节奏、模板和陈词滥调	reference/humanize.md
tighten	Williams Style	删除僵化名词和无力动词；逐句改写，凸显被掩盖的动作	reference/tighten.md
clarify	Pinker Sense of Style、Orwell	减轻读者的工作记忆负担；逐段改写，并附上思维模型说明	reference/clarify.md
pace	King On Writing、Strunk	恢复节奏；提供节奏直方图、朗读诊断以及拆分／合并建议	reference/pace.md
lead	Zinsser 关于开篇的论述	打磨开篇；找出埋藏的导语，并提出三个备选首句	reference/lead.md
verify	论断审查传统	找出关键论断；将每项分类为缺乏依据／含糊／有所保留／未经核查	reference/verify.md
aloud	朗读传统	在交互会话中通过 OpenAI TTS 播放文本；等待作者回应后再继续	reference/aloud.md
argue	Toulmin / IBIS / Argdown	梳理论证结构；选出最有力的反方观点，并检查文章是否回应了它	reference/argue.md

项目工具（读写项目文件）

命令	功能	参考
teach	通过访谈作者来创建或完善 VOICE.md。在 document 之后使用，以敲定未解决的问题；也可单独使用，适用于没有现有语料的情况	reference/teach.md
document	扫描现有文本。计算文体特征，找出反复出现的写作手法，并起草 VOICE.md，其中包含引用和待由 teach 解决的未决问题	reference/document.md
craft	采用因方法而异的端到端写作流程（大纲／探索／迭代／模型起草）；构思 → 起草 → 批评 → 润色	reference/craft.md

固定 / 取消固定

将 /pilcrow polish 转为 /polish（反之亦然）。适用于作者每篇作品都会重复使用的命令。

node scripts/pin.mjs pin polish
node scripts/pin.mjs unpin polish

脚本会在安装了 pilcrow 的每个 harness 目录中写入一个重定向技能。运行 unpin 即可移除。固定的技能带有标记注释，因此 unpin 只会删除它创建的快捷方式，不会删除同名的用户自有技能。

跨领域参考资料

这些共享文件位于 reference/ 中，文件名以下划线开头。它们不是命令；而是由多个编辑命令加载的内容。

文件	内容	加载方
reference/_ai-tell-catalog.md	按类别整理的详尽 AI 痕迹目录	humanize、polish
reference/_readers.md	读者画像	clarify、lead、polish
reference/_cadence-theory.md	King + Strunk 关于节奏的论述	pace、polish
reference/_genres.md	文体惯例	clarify、lead、document、craft；以及路由规则 1（裸分诊）

通用写作法则以及编辑本能 / 提案流程 / 糟粕测试已内联在本文件上文中；它们适用于每条命令，无需显式加载。需要跨领域文件的命令会在各自的参考资料中明确说明；不要默认加载所有共享文件。

外部技能依赖

aloud 依赖 OpenAI speech skill（Apache 2.0）进行 TTS。辅助脚本会为你解析该技能：

node scripts/resolve-speech.mjs

它会检查 .claude/skills/speech/、.cursor/skills/speech/ 等位置是否有已安装的副本；如果没有，就会将固定 SHA 版本的技能获取到 /tmp/pilcrow/skills/speech/。无论哪种方式，都会返回 scripts/text_to_speech.py 所在的目录。

aloud 要求在环境中设置 OPENAI_API_KEY。命令会在会话开始时检查该变量；如果缺失，则会指引你查看 speech skill 的说明。

输出格式（用于管道传输）

pilcrow lint 返回如下 JSON：

{
  "files": [
    {
      "file": "drafts/post.md",
      "findings": [
        {
          "ruleId": "ai-tell-phrasebank",
          "ruleName": "AI-tell phrasebank",
          "severity": "error",
          "message": "AI phrasebank match: \"delve into\". Rewrite with concrete specifics.",
          "line": 12,
          "column": 8,
          "range": { "start": 234, "end": 244 },
          "excerpt": "…me delve into the rich tapestry…",
          "suggestion": "(optional replacement text)"
        }
      ]
    }
  ]
}

pilcrow critique 会输出一条提示词，由模型进行评估；模型会以相同的 Finding 格式返回发现结果。

不要自动应用建议

引擎绝不会修改正文。当命令提出改写建议时，应先将建议展示给用户，并等待确认后再编辑文件；声音和意图优先于规则。