gm-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

gm — single entry point

gm — 单一入口点

Every turn begins with

instruction

. Write

.gm/exec-spool/in/instruction/<N>.txt

(empty body) and read the response — its

instruction

field is the active phase prose, its

prd_items

is the live work plan, its

mutables_pending

is what blocks the EMIT gate, its

recall_hits

is the prior memory already loaded for you. Follow that prose imperatively until the phase's exit condition is met, then

transition

. The user's request is the authorization; the PRD is the receipt; the chain runs PLAN → EXECUTE → EMIT → VERIFY → COMPLETE without re-asking between phases.

Direct Read/Edit/Bash before the first

instruction

dispatch is the failure mode this skill prevents. If you find yourself reaching for a tool to "just take a quick look", you have already dropped the loop — dispatch

instruction

first, then act on its prose.

Fix on Sight. Every unexpected output, broken neighbor, lockfile drift, suppressed error, or stale generated file surfaced during work becomes a PRD item the same turn and is executed before COMPLETE. Surprise is a new mutable, not noise to absorb. Stubs, mocks, placeholder returns, fixture-only paths, and "always succeeds" code paths are forbidden in shipped material; acceptance is real input through real code into real output, witnessed. Edits to code that runs in a browser require a live

browser

verb witness in the same turn — Browser Witness is non-negotiable.

Do not create documentation files the user did not ask for. No COMPLETED.md, no SUMMARY.txt, no IMPLEMENTATION_NOTES.md, no START-HERE.md, no *-STATUS.md, no build-output.txt left behind, no new top-level

.md

.txt

of any kind. Closure narrative lives in the PRD (which plugkit owns), in

memorize-fire

(which becomes recallable next session), and in the commit message (which

git log

preserves) — those are the only sanctioned destinations. A new doc at project root, in

docs/

, or anywhere else is a residual the next stop-gate will flag.

Before any apparent stop, dispatch

residual-scan

. If it returns work that fits the spirit of the original ask and is reachable from this session, expand the PRD and execute; only residuals genuinely out-of-spirit or out-of-reach are name-and-stop. A turn that ends with uncommitted changes, an open PRD slice, or unresolved mutables has not actually stopped — it has stalled the chain.

If the

instruction

response carries a non-null

update_available

, plugkit drift has been detected on disk and the running watcher is behind. Rebootstrap before continuing — newer fixes are sitting on disk unused, and every dispatch is wasted on stale code.

bun x gm-plugkit@latest

(or

npx -y gm-plugkit@latest

) is the one-shot: it fetches the new wasm, replaces the artifact, and the watcher reloads. Drift past one version is a deviation.

running_tasks

is non-empty, you own them — every entry is a subprocess you started that's still consuming CPU/memory. Stop ones that have outlived their purpose with

task-stop

(write

.gm/exec-spool/in/task-stop/<N>.txt

with

{id: "t<n>"}

). The 15-min idle reaper is the last resort, not a substitute for hygiene. If

stuck_spool

is non-empty, dispatches are wedged — the watcher's host_exec_js is synchronous and a stuck body blocks every other verb until it returns. Diagnose via

.watcher.log

and consider rebootstrapping if it doesn't clear; spool bodies are Turing-complete and can loop forever. Long-running work goes through

task-spawn

(returns a

task_id

immediately, body runs detached), not through the sync

nodejs

bash

python

language verbs.

should_residual_scan

is true, dispatch

residual-scan

before any text response that reads like a stop. The marker is one-shot per stopping window — re-checking after you've fired it is fine; firing it for the first time in a session that has pending work is non-negotiable. If

unsupervised_watcher

is non-null, the running watcher predates supervisor.js and has no unplanned-restart recovery; stop the named PID and let the next bootstrap re-spawn it under supervision.

No deferral phrasing. "Next pass", "next session", "future work", "defer to later", "address it next", "below criticality", "do later", "fix later" are all forced closure dressed up.

prd-add

rejects items whose description/subject/notes contain these markers unless the item carries

blockedBy: [external]

blockedBy: [out-of-reach]

. The dispatch gate also rejects git commits whose message contains them. Per §22 Fix on Sight: in-spirit reachable work is executed this turn, not deferred. If the work is genuinely unreachable, declare it with blockedBy; that's an auditable refusal, not a defer.

The wasm artifact lives at

~/.claude/gm-tools/plugkit.wasm

; the spool watcher runs it. The watcher's own stdout/stderr is appended to

.gm/exec-spool/.watcher.log

— Read it to see plugkit's internal trace, dispatch timings, sweep actions, errors.

The watcher self-shuts-down after 15 minutes idle (no spool I/O, no live browser session) and is restarted on next agent activity by a detached supervisor.

.gm/exec-spool/.unplanned-restart.json

is a critical-failure marker — present means a prior watcher died without a planned shutdown. Treat as a PRD-worthy incident on sight: diagnose via

.watcher.log

and

gm-log/<day>/plugkit.jsonl

events

supervisor.watcher-exited-unexpectedly

and

supervisor.heartbeat-stale

around the prior_status.ts timestamp, then delete the marker once root cause is named.

每个轮次都从

instruction

开始。写入

.gm/exec-spool/in/instruction/<N>.txt

（空内容）并读取响应——其中

instruction

字段是当前阶段的执行说明，

prd_items

是实时工作计划，

mutables_pending

是阻碍EMIT阶段的项，

recall_hits

是已为你加载的过往记忆内容。严格遵循该执行说明，直到满足阶段退出条件，然后执行

transition

。用户的请求即为授权；PRD是工作依据；流程会按PLAN → EXECUTE → EMIT → VERIFY → COMPLETE运行，阶段间无需再次确认。

在首次

instruction

调度前直接进行读取/编辑/执行Bash命令是本技能要避免的错误模式。如果你发现自己想要使用工具“快速查看一下”，说明你已经脱离了循环——先调度

instruction

，再根据返回的执行说明操作。

即时修复（Fix on Sight）。工作过程中出现的任何意外输出、关联模块故障、锁文件漂移、被抑制的错误或过期生成文件，都要在本轮次中转为PRD项，并在COMPLETE阶段前执行修复。意外情况属于新的mutable项，而非可忽略的干扰。交付内容中禁止使用桩代码、模拟对象、占位返回值、仅适用于测试用例的路径以及“始终成功”的代码路径；验收标准是真实输入通过真实代码产生真实输出，并经过验证。对浏览器运行代码的修改，必须在同一轮次中通过

browser

操作进行实时验证——浏览器验证是硬性要求。

不要创建用户未要求的文档文件。禁止留下COMPLETED.md、SUMMARY.txt、IMPLEMENTATION_NOTES.md、START-HERE.md、*-STATUS.md、build-output.txt，也禁止创建任何新的顶级

.md

或

.txt

文件。收尾说明应记录在PRD（由plugkit管理）、

memorize-fire

（可在下一会话中被调用）以及提交信息（由

git log

保存）中——这些是唯一被允许的记录位置。项目根目录、

docs/

或其他任何位置的新文档，都会被下一阶段的检查标记为残留项。

在任何看似要结束的节点前，调度

residual-scan

。如果返回的工作符合原始需求的精神且可在本次会话中完成，则扩展PRD并执行；只有完全不符合需求精神或无法完成的残留项才可以标记并终止。如果轮次结束时存在未提交的更改、未完成的PRD片段或未解决的mutables项，说明流程并未真正结束——只是陷入了停滞。

如果

instruction

响应中

update_available

不为空，说明磁盘上的plugkit已出现版本漂移，当前运行的监控进程已过时。继续前需执行bootstrap——磁盘上已有更新的修复版本，使用过时代码进行的所有调度都是无效的。

bun x gm-plugkit@latest

（或

npx -y gm-plugkit@latest

）是一键更新命令：它会获取新的wasm文件，替换旧文件，监控进程会自动重新加载。版本漂移超过一个版本属于违规操作。

如果

running_tasks

不为空，你需要负责管理这些任务——每个条目都是你启动的仍在消耗CPU/内存的子进程。使用

task-stop

终止已无存在必要的任务（写入

.gm/exec-spool/in/task-stop/<N>.txt

，内容为

{id: "t<n>"}

）。15分钟闲置自动清理是最后手段，不能替代主动管理。如果

stuck_spool

不为空，说明调度已陷入阻塞——监控进程的host_exec_js是同步的，阻塞的任务会阻止所有其他操作直到它返回。通过

.watcher.log

进行诊断，如果无法解决则考虑重新执行bootstrap；spool任务是图灵完备的，可能会无限循环。长时间运行的工作应通过

task-spawn

（立即返回

task_id

，任务后台运行）执行，而非同步的

nodejs

bash

python

语言操作。

如果

should_residual_scan

为true，在任何看似结束的文本响应前调度

residual-scan

。该标记在每个结束窗口期仅生效一次——执行后再次检查是允许的；在有未完成工作的会话中首次执行该操作是硬性要求。如果

unsupervised_watcher

不为空，说明当前运行的监控进程早于supervisor.js，不具备意外重启恢复能力；终止指定PID，让下一次bootstrap在监控下重新启动它。

禁止使用延迟表述。“下一轮”、“下一会话”、“未来工作”、“延后处理”、“后续解决”、“非关键项”、“以后再做”、“稍后修复”等表述都是变相的强制收尾。

prd-add

会拒绝描述/主题/备注中包含这些标记的项，除非该项带有

blockedBy: [external]

或

blockedBy: [out-of-reach]

。调度网关也会拒绝提交信息中包含这些标记的git提交。根据§22即时修复原则：符合需求精神且可完成的工作必须在本轮次执行，不得延迟。如果工作确实无法完成，需通过blockedBy声明；这是可审计的拒绝，而非延迟。

wasm文件位于

~/.claude/gm-tools/plugkit.wasm

；spool监控进程运行该文件。监控进程的标准输出/错误会追加到

.gm/exec-spool/.watcher.log

——查看该文件可了解plugkit的内部跟踪信息、调度时间、清理操作和错误信息。

监控进程在15分钟闲置（无spool I/O、无活跃浏览器会话）后会自动关闭，下一次Agent活动时会由后台监控程序重新启动。

.gm/exec-spool/.unplanned-restart.json

是严重故障标记——存在该文件说明之前的监控进程未正常关闭就已终止。一旦发现需将其视为PRD级事件：通过

.watcher.log

和

gm-log/<day>/plugkit.jsonl

中prior_status.ts时间戳附近的

supervisor.watcher-exited-unexpectedly

和

supervisor.heartbeat-stale

事件进行诊断，确定根本原因后删除该标记。

Boot the spool watcher (first turn only)

启动spool监控进程（仅首次轮次）

Check

.gm/exec-spool/.status.json

. If absent or

ts

> 15s old, boot via the npm package —

bun x gm-plugkit@latest spool

fetches the freshest plugkit (wasm + wrapper), copies them into

~/.claude/gm-tools/

, then enters spool mode:

bun x gm-plugkit@latest spool > /dev/null 2>&1 &

bun

is not available, fall back to

npx -y gm-plugkit@latest spool > /dev/null 2>&1 &

or to the local wrapper if it's already installed:

node ~/.claude/gm-tools/plugkit-wasm-wrapper.js spool > /dev/null 2>&1 &

. The wrapper has a self-heal: if it detects a

LinkError

or missing wasm at instantiation, it re-runs bootstrap automatically and retries.

Wait 2 seconds, then verify boot:

Read
```
.gm/exec-spool/.cli-status.json
```
— the launcher writes its phase here (
```
starting
```
→
```
bootstrapped
```
→
```
ready
```
). Present with
```
phase: "ready"
```
= good.
Read
```
.gm/exec-spool/.status.json
```
— the watcher writes its heartbeat here every 5s. Fresh
```
ts
```
(within 15s) = watcher alive.
If neither file exists or
```
.cli-status.json
```
is stuck at an earlier phase, read
```
.gm/exec-spool/.bootstrap-error.json
```
— the launcher writes
```
{error_phase, error_message, stack}
```
on any failure even when stdout/stderr were redirected to
```
/dev/null
```
. Also read
```
.gm/exec-spool/.watcher.log
```
for the post-spawn trace. Surface the error to the user; do not retry blindly.

检查

.gm/exec-spool/.status.json

。如果文件不存在或

ts

超过15秒，通过npm包启动——

bun x gm-plugkit@latest spool

会获取最新的plugkit（wasm + 包装器），将其复制到

~/.claude/gm-tools/

，然后进入spool模式：

bun x gm-plugkit@latest spool > /dev/null 2>&1 &

如果

bun

不可用，可改用

npx -y gm-plugkit@latest spool > /dev/null 2>&1 &

，或使用已安装的本地包装器：

node ~/.claude/gm-tools/plugkit-wasm-wrapper.js spool > /dev/null 2>&1 &

。包装器具备自我修复功能：如果在实例化时检测到

LinkError

或缺失wasm文件，会自动重新执行bootstrap并重试。

等待2秒后，验证启动状态：

读取
```
.gm/exec-spool/.cli-status.json
```
——启动器会在此写入阶段状态（
```
starting
```
→
```
bootstrapped
```
→
```
ready
```
）。文件存在且
```
phase: "ready"
```
表示启动成功。
读取
```
.gm/exec-spool/.status.json
```
——监控进程每5秒在此写入心跳信息。
```
ts
```
较新（15秒内）表示监控进程存活。
如果两个文件都不存在或
```
.cli-status.json
```
停留在早期阶段，读取
```
.gm/exec-spool/.bootstrap-error.json
```
——即使标准输出/错误被重定向到
```
/dev/null
```
，启动器也会在此写入
```
{error_phase, error_message, stack}
```
错误信息。同时查看
```
.gm/exec-spool/.watcher.log
```
获取启动后的跟踪信息。将错误告知用户；不要盲目重试。

Plugkit version updates

Plugkit版本更新

The watcher checks GitHub Releases every 5 minutes for a newer plugkit. If drift is detected, it writes

.gm/exec-spool/.update-available.json

with

{installed, latest, instruction, update_url}

; if no drift, the file is removed. Read this file at session start (and occasionally afterward); if present, kill the current watcher, run

bootstrapPlugkit({latest: true})

once to fetch the new wasm, then restart the watcher. Default bootstrap never hits the network — only

{latest: true}

fetches the newest binary.

监控进程每5分钟检查GitHub Releases是否有更新的plugkit版本。如果检测到版本漂移，会写入

.gm/exec-spool/.update-available.json

，内容为

{installed, latest, instruction, update_url}

；如果无版本漂移，该文件会被删除。会话开始时（之后也可定期）读取该文件；如果文件存在，终止当前监控进程，运行

bootstrapPlugkit({latest: true})

一次以获取新的wasm文件，然后重新启动监控进程。默认bootstrap不会访问网络——只有

{latest: true}

会获取最新的二进制文件。

Dispatch ABI

调度ABI

Write request body to

.gm/exec-spool/in/<verb>/<N>.txt

. Read response from

.gm/exec-spool/out/<verb>-<N>.json

(nested verbs) or

out/<N>.json

(root verbs). Bodies are JSON, raw code, or a single phase name depending on the verb.

将请求内容写入

.gm/exec-spool/in/<verb>/<N>.txt

。从

.gm/exec-spool/out/<verb>-<N>.json

（嵌套操作）或

out/<N>.json

（根操作）读取响应。内容格式根据操作不同可为JSON、原始代码或单一阶段名称。

Batch dispatch — never serial round-trips for independent verbs

批量调度——独立操作绝不串行往返

The watcher processes verbs sequentially internally, but the agent's bottleneck is round-trip latency, not the watcher. Write N inputs in one message via parallel Write tool calls, then read N outputs in one message via parallel Read calls. A 5-verb batch is one agent turn, not five.

Example PLAN orient pack — 3 recalls + 3 codesearches in ONE message:

Write .gm/exec-spool/in/recall/1.txt        body: {"query":"<noun A>"}
Write .gm/exec-spool/in/recall/2.txt        body: {"query":"<noun B>"}
Write .gm/exec-spool/in/recall/3.txt        body: {"query":"<noun C>"}
Write .gm/exec-spool/in/codesearch/1.txt    body: {"query":"<phrase X>"}
Write .gm/exec-spool/in/codesearch/2.txt    body: {"query":"<phrase Y>"}
Write .gm/exec-spool/in/codesearch/3.txt    body: {"query":"<phrase Z>"}

Then in the NEXT message, all 6 Reads in parallel.

For dependent verbs (transition after instruction, prd-resolve after work), the agent must serialize — but only at the dependency boundary, not across independent dispatches.

监控进程内部会按顺序处理操作，但Agent的瓶颈是往返延迟，而非监控进程。**通过并行Write工具调用在一条消息中写入N个输入，然后通过并行Read调用在一条消息中读取N个输出。**5个操作的批量处理只需一个Agent轮次，而非五个。

示例PLAN阶段批量操作——在一条消息中完成3次recall + 3次codesearch：

Write .gm/exec-spool/in/recall/1.txt        body: {"query":"<noun A>"}
Write .gm/exec-spool/in/recall/2.txt        body: {"query":"<noun B>"}
Write .gm/exec-spool/in/recall/3.txt        body: {"query":"<noun C>"}
Write .gm/exec-spool/in/codesearch/1.txt    body: {"query":"<phrase X>"}
Write .gm/exec-spool/in/codesearch/2.txt    body: {"query":"<phrase Y>"}
Write .gm/exec-spool/in/codesearch/3.txt    body: {"query":"<phrase Z>"}

然后在下一条消息中，并行读取所有6个结果。

对于依赖操作（instruction后执行transition，工作完成后执行prd-resolve），Agent必须串行执行——但仅在依赖边界处串行，而非所有独立调度都串行。

State lives in plugkit, not in conversation context

状态存储在plugkit中，而非对话上下文

Never Read

.gm/prd.yml

.gm/mutables.yml

directly. Every

instruction

response carries the data you need:

{
  phase,               // current phase
  instruction,         // phase prose (the active discipline)
  prd_items: [...],    // full PRD items with id, subject, status, fields
  prd_pending_count,
  mutables_pending: [{id, claim, witness_method, witness_evidence, status}, ...],
  recall_hits: [...],  // auto-fired against phase + first pending PRD subject
  next_phase_hint
}

切勿直接读取

.gm/prd.yml

或

.gm/mutables.yml

。

instruction

响应会携带你所需的所有数据：

{
  phase,               // 当前阶段
  instruction,         // 阶段执行说明（当前规则）
  prd_items: [...],    // 完整PRD项，包含id、主题、状态、字段
  prd_pending_count,
  mutables_pending: [{id, claim, witness_method, witness_evidence, status}, ...],
  recall_hits: [...],  // 根据阶段+首个待处理PRD主题自动触发的记忆内容
  next_phase_hint
}

Plugkit observability — read .watcher.log

Plugkit可观测性——读取.watcher.log

The watcher writes its own stdout + stderr (plus the wasm cdylib's

println!

eprintln!

) to

.gm/exec-spool/.watcher.log

. Useful when:

A dispatch returned an error you don't understand → tail the log for the stack
A verb seems slow → log shows
```
[dispatch] ← verb=X ms=N
```
Sweep cleaned up something → log shows
```
[retention]
```
or
```
[stale-sweep]
```
lines
Watcher boot issues →
```
--- watcher boot ... ---
```
markers

Read with

offset

to tail:

Read .gm/exec-spool/.watcher.log offset=<last-known-line>

The log is rotated at 10MB (older content moves to

.watcher.log.1

监控进程会将自身的标准输出+错误（以及wasm cdylib的

println!

eprintln!

输出）写入

.gm/exec-spool/.watcher.log

。以下场景中该文件非常有用：

调度返回无法理解的错误→查看日志末尾的堆栈信息
操作执行缓慢→日志中会显示
```
[dispatch] ← verb=X ms=N
```
清理操作删除了某些内容→日志中会显示
```
[retention]
```
或
```
[stale-sweep]
```
行
监控进程启动问题→查看
```
--- watcher boot ... ---
```
标记

使用

offset

参数读取日志末尾：

Read .gm/exec-spool/.watcher.log offset=<last-known-line>

日志文件达到10MB时会自动轮转（旧内容移动到

.watcher.log.1

）。

The loop

循环流程

Add PRD items via

prd-add

(JSON body), resolve via

prd-resolve

(id as body). Add mutables via

mutable-add

, resolve via

mutable-resolve

once

witness_evidence

is filled — narrative resolution is rejected; only file:line, codesearch hit, or exec output snippet counts. Every

mutable-resolve

auto-fires memorize so the witness becomes recall-able next session.

Resolve every entry in

mutables_pending

before transitioning. When the phase's exit condition is met, dispatch

transition

with the next phase name (or empty for auto-advance). Each transition response embeds

recall_hits

automatically — relevant prior memos surface without you asking.

Stop only when

phase

COMPLETE

AND

residual-scan

returns empty AND the worktree is clean AND CI is green. Any of those false means the chain has not finished.

通过

prd-add

（JSON内容）添加PRD项，通过

prd-resolve

（内容为id）标记完成。通过

mutable-add

添加mutables项，填充

witness_evidence

后通过

mutable-resolve

标记完成——仅描述性说明不被接受；只有文件:行号、codesearch结果或执行输出片段才算有效证据。每次

mutable-resolve

都会自动触发memorize，使该证据可在下一会话中被调用。

在执行transition前，需解决

mutables_pending

中的所有条目。当满足阶段退出条件时，调度

transition

并传入下一阶段名称（或留空自动推进）。每次transition响应都会自动嵌入

recall_hits

——相关过往记忆会自动呈现，无需主动请求。

只有当

phase

为

COMPLETE

且

residual-scan

返回空、工作目录干净、CI验证通过时，才可终止流程。任何一项不满足都说明流程尚未完成。

Orchestrator verbs

编排类操作

instruction

transition

phase-status

prd-add

prd-resolve

prd-list

mutable-add

mutable-resolve

mutable-list

memorize-fire

residual-scan

auto-recall

task-spawn

task-list

task-stop

task-output

instruction

transition

phase-status

prd-add

prd-resolve

prd-list

mutable-add

mutable-resolve

mutable-list

memorize-fire

residual-scan

auto-recall

task-spawn

task-list

task-stop

task-output

。

Host verbs

主机类操作

fs_read

fs_write

fs_stat

fs_readdir

kv_get

kv_put

kv_query

fetch

exec_js

env_get

recall

codesearch

memorize

health

status

wait

sleep

close

kill-port

forget

feedback

learn-status

learn-debug

learn-build

discipline

pause

runner

inference

browser

fs_read

fs_write

fs_stat

fs_readdir

kv_get

kv_put

kv_query

fetch

exec_js

env_get

recall

codesearch

memorize

health

status

wait

sleep

close

kill-port

forget

feedback

learn-status

learn-debug

learn-build

discipline

pause

runner

inference

browser

。

Language verbs

语言类操作

nodejs

python

bash

powershell

ssh

go

rust

cpp

java

deno

— write raw code as the request body.

nodejs

python

bash

powershell

ssh

go

rust

cpp

java

deno

——请求内容为原始代码。

Browser

The

browser

verb is the only sanctioned way to drive a live page. Do not reach for any other browser tool, library, or skill — the host owns the managed session and a parallel surface fragments witness state. Dispatch

.gm/exec-spool/in/browser/<N>.txt

with raw JavaScript as the body. The host runs Chrome under a project-scoped profile at

<cwd>/.gm/browser-profile/

(cookies/login persist per project) and exposes the body to four globals:

page

(the live page handle —

await page.goto(...)

await page.evaluate(...)

, etc.),

snapshot

(accessibility-tree snapshot),

screenshotWithAccessibilityLabels

(annotated screenshot helper), and

state

(a per-session object that persists across dispatches within the same session).

Special commands (body starts with

session

session new

session list

session close <id>

manage session lifecycle.

Required for any edit to code that runs in a browser — Browser Witness is non-negotiable. A

node test.js passes

does not substitute for a live

page.evaluate

asserting the invariant the edit was supposed to change.

browser

操作是唯一被允许的实时页面驱动方式。请勿使用任何其他浏览器工具、库或技能——主机管理会话，并行操作会破坏验证状态。调度

.gm/exec-spool/in/browser/<N>.txt

，内容为原始JavaScript。主机会在项目作用域配置文件

<cwd>/.gm/browser-profile/

下运行Chrome（Cookie/登录状态按项目持久化），并向代码暴露四个全局对象：

page

（实时页面句柄——

await page.goto(...)

、

await page.evaluate(...)

等）、

snapshot

（可访问性树快照）、

screenshotWithAccessibilityLabels

（带无障碍标签的截图工具）和

state

（会话内跨调度持久化的对象）。

特殊命令（内容以

session

开头）：

session new

、

session list

、

session close <id>

用于管理会话生命周期。

对浏览器运行代码的任何修改都必须使用该操作——浏览器验证是硬性要求。

node test.js passes

不能替代通过

live page.evaluate

验证修改应实现的逻辑。