Kimi Code 完全手册：Workbench、Hook 校验与死循环刹车

一句话：一个能用的资产工作台

agentic-workbench 是「个人上下文优先的 UI 组件资产与视觉样式探索工作台」。说人话就是：一堆散落的 UI 模板和设计素材，不该躺在 zip 里睡大觉，而是拆成能独立打开、能预览、能翻找的主题项目。

这轮 Kimi 干的，是把散装素材整理成 17 个自包含主题：

每个主题都是标准「五件套」：README + AGENTS + CLAUDE + CONTEXT + LANGUAGES，配 assets、docs、产品层。别的 Agent 进来照着 README 就能启动预览，不用再翻原始 zip。

它这轮新增的：glass-ui-assets

这次重点加的是 glass-ui-assets（玻璃拟态 UI 设计资产库）：

• 20 张组件参考图：white-light 白光玻璃 11 张 + thin-glass 超薄玻璃 9 张，覆盖导航栏、按钮、图表、模态框、命令面板全系列
• 2 份设计规范：ClauseOS 企业合规 SaaS 设计系统 v2.0 + WenXiBuddy 复刻提示词包 v1.0
• 画廊预览壳：tab + iframe 的静态画廊，20 张图三个 tab 切换，端口 8879
• SaaS 成品页：一个 35KB 的 dashboard.html，把 ClauseOS 的 Token 直接落地成可交互后台（侧边导航、模态、⌘K 命令面板都能点）

这不是「把素材堆上去」那种敷衍，是真能打开看、能翻图、能抄 Token 的完成度。

真正让我服气的三个点

1. 规则的自觉性：它主动对齐了仓库的 port-registry（端口唯一事实源）、ADR 0016 扁平主题布局、project-init 五件套骨架。不是我提醒的，是它自己查的。
2. 文档的克制：上游素材只读，不擅自改图改规范；README 里不塞绝对路径不塞私钥；macOS 的资源叉文件主动剔除。
3. 收尾的规整：461 个 commit 的仓库，这轮 commit 信息干净（feat(glass-ui-assets) / docs(workbench) / docs(commit-history) 分门别类），git log 读起来像正规开源项目。

99 元套餐，值不值

最让我意外的是：这是 99 元/月的 Kimi 套餐干出来的，不是 200 刀的 Claude 订阅，也不是开 API 按 token 烧。模型本身能不能打是一回事，它有没有把「维护一个仓库该有的姿势」内化成习惯是另一回事。这一轮它显然是会的。

当然不是无脑吹。中途它也有几次文档路径指错、计数对不齐，得我纠。但纠完它能记住，下一轮不再犯。这个「被纠正后不重复踩」的特质，比一次完美交付更难得。

收个尾

如果你也有个「素材越堆越多但没人整理」的仓库，丢给 Kimi 试试。它也许不能一次写对，但它的下限是「完整、自洽、可运行」，这个下限对整理型任务来说，恰恰是最稀缺的。

一句话：99 块的 Kimi，干出了你按模板攒一星期才能攒出来的完成度。 这轮我服。

这个 hook 在拦什么

规则本身很简单：模型对图片/视频文件调用 Read 时，hook 在工具执行前拦截，stderr 返回一句「改用 ReadMediaFile」，进程 exit 2 阻断这次调用。其它文件类型正常放行，stdin 解析失败时 fail-open 不误伤。

脚本本身没什么可说的，四十行不到。真正的坑在配置层。

配置里修掉的两个真问题

第二个坑尤其阴：配置写错了 hook 不执行，但表面上一切正常——没有报错，只是「没拦」。这也是为什么必须做下面这套验证。

三层验证法

实弹层是关键，也是最容易被跳过的一层。这次验证时翻了运行日志，里面只有启动记录，没有任何 hook 执行的痕迹——光看日志既证明不了它在工作，也证明不了它没工作。唯一的硬证据是在会话里故意犯一次规，看拦截信息是不是脚本里写的那句 stderr。

结果是拦住了，返回的就是脚本里那句提示。三层证据凑齐，这事才算闭环。

防循环其实有两道闸

hook 只是入口那道。配置里还有一层 [loop_control]：

1
[loop_control]
2
max_steps_per_turn = 300
3
max_attempts_per_step = 2

max_attempts_per_step = 2 和「同一调用失败两次就停手」的纪律是同一个思路：循环靠重试续命，把重试次数掐死，循环就起不来。一道闸拦错误的工具选择，一道闸拦无底线的重试，两层是互补的。

顺带揪出的卡片边框漂移

验证之余还排了一个博客（Astro/Firefly）的卡片边框问题，根因是典型的「两处公式漂移」：

同一个卡片，全局规则和动态页覆盖用的是两套不同的 color-mix 公式，视觉上自然不一致。最小修法二选一：直接删掉动态页那段覆盖回归全局，或者把覆盖里的公式对齐全局。改之前先在 pnpm dev 下切壁纸模式肉眼对比，再决定删还是对齐。

两个顺手的教训

剪贴板管理器的截图路径会失效。 这次两张截图里有一张路径已经不存在——剪贴板工具会清图。收到这类路径先确认文件还在，再决定用哪个工具读，能省一轮无效往返。

「故意犯错」是验证防护机制最硬的证据。 防护类配置（hook、拦截规则、权限门禁）静默时不产生任何痕迹，日志里也看不见。想知道它在不在岗，就得在安全范围内真的踩一脚红线。踩中了，才是真的。

之前还记过一次 Kimi CLI 工具调用陷进循环的事，那篇在这里，这道 hook 就是防它的入口闸。

现象：同一参数的死循环

典型触发是截图验证：

• 要读 temp\…\*.png 做视觉核对
• 临时文件生命周期、Windows 路径、权限或同步延迟 → Read 失败
• 模型收到失败后，不更新「已失败」状态，继续发完全相同的调用
• 界面连环 failed，直到人打断

同类变体还有：同一批文件反复 grep/sed；auto-compact 后「忘了」失败，又从头循环；长会话里默认循环上限太高，死循环能跑很久。

根因：模型策略 + 配置过松

怎么掐：配置优先，提示词托底

1
[loop_control]
2
max_steps_per_turn = 40          # 建议 30–60，默认 1000 太高
3
max_retries_per_step = 2         # 建议 1–2
4
max_ralph_iterations = 0         # 不需要 Ralph 就关掉

1
kimi --max-steps-per-turn 40 --max-retries-per-step 2

1
KIMI_LOOP_MAX_STEPS_PER_TURN=40
2
KIMI_LOOP_MAX_RETRIES_PER_STEP=2

防循环 checklist

边界

这不是「Kimi 和 Claude 工具不兼容」的单一锅。同一模型挂到别的宿主也会转圈，说明要模型侧继续改策略 + 用户侧主动拧上限。步数和重试压下来，再配退出指令与操作习惯，频率会明显下降。

出处与边界