10 美元买 70 美元额度?CommandCode GOAT 订阅实测:7 倍额度是真的,DeepSeek V4 Flash 还比 OpenCode Go 快

10 美元买 70 美元额度?CommandCode GOAT 订阅实测:7 倍额度是真的,DeepSeek V4 Flash 还比 OpenCode Go 快

过去两个月,AI 编程订阅市场打起了「倍率战」:OpenCode Go 用 $10 卖 $60 额度,CommandCode 的 GOAT 直接喊出 $10 买 $70——7 倍,还声称带优惠能到 10 倍以上。对每月在编码模型上花真金白银的开发者,这不是噱头,是实打实的月账单问题。

我买了 GOAT 用了一周多,主力跑 DeepSeek V4 Flash。先说结论:同样 $10,GOAT 给的额度比 OpenCode Go 多 17%,DeepSeek V4 Flash 的月请求量约为后者的 2 倍,限流更松,实测速度还更快。下面把数学和体验都摊开。

一、GOAT 是什么:$10 买 $70 额度的开源模型订阅

Command Code(commandcode.ai)是开源模型向的编码 agent,创始人 Ahmad Awais,主推「会学习你编程品味」的 taste-1。今年 8 月初上线 GOAT 计划,定位是「重度开源模型用户」这一档:$10/月换 $70 月度额度(官方口径 7x 倍率),官方估算约 7.5 万次请求/月。

它不是「一个模型一个价」的共享池,而是额度按模型独立分配——每个模型各有一笔额度,你在 30+ 模型间随便切,互不挤占:

模型 月度额度 官方估算请求量/月
GPT-5.6 Sol $70 ~2,070
GLM-5.2 $70 ~4,740
Tencent Hy3 $70 ~35,400
Qwen 3.8 27B $70 ~24,000
DeepSeek V4 Flash $60 ~91,200*
MiMo V2.5(另有 -98% deal) $30 ~97,400
新模型(无 deal 期) $20 起步 —

*注:GOAT 文档给出的估算口径与 OpenCode 不同(缓存假设差异大),该数字来自 GOAT 官方估算;OpenCode Go 对同模型的官方估算为 37,800/月——差异来自估算假设而非额度,正文第三节会细拆。

「7 倍怎么来的」:CommandCode 说自己直接跟模型厂商谈容量、跑 ~95-98% 缓存命中率,把省下的推理成本折回成额度。所以额度高低 = 它跟厂商 deal 谈得怎么样:谈成的(GPT-5.6 Sol、GLM-5.2、Hy3)给满 $70,没 deal 的新模型只给 2x($20)。

二、限流窗口:比 OpenCode Go 松一档

订阅真正要看的不是「月总额度」,是短窗限制——决定了你一天内能不能猛干。两家的滚动窗口对比:

限流窗 CommandCode GOAT OpenCode Go
5 小时 $14 $12
周 $35 $30
月 $70 $60

每个窗口独立刷新。GOAT 每个窗都比 OpenCode Go 高约 17%。代价是额度花完(且没开自动充值)时付费模型会暂停到窗口结束——免费模型(Laguna S 2.1、LongCat 2.0 等)不停。

三、纸面数学:DeepSeek V4 Flash 一档能跑多少

我这周主力是 DeepSeek V4 Flash,拿它做核心对比。先对齐口径:两家的官方「月请求量估算」用的缓存假设差很多——CommandCode 按 ~50K cache-read/请求算,OpenCode 按 ~71K 算,所以直接比官方估算数字会得出「GOAT 是 OpenCode 2.4 倍」这种虚高结论。

用两家各自的官方 calculator(同样按典型 agent 请求:~800 fresh input + ~50K cache read + ~180-200 output token)重算更公平。DeepSeek V4 Flash 在 CommandCode 的单价是 off-peak $0.22/$0.66/$0.007(cache read),OpenCode Go 上同模型按 $0.28/M 输入级报价走——CommandCode 这个 off-peak 价本身就更低,且每天 17 小时生效。

结果:GOAT 的 $60 DeepSeek V4 Flash 额度 ÷ 官方约 $0.0006/请求 ≈ 6-9 万次/月(CommandCode 自己给 91,200 的口径,含重度缓存命中);OpenCode Go 官方口径 37,800 次/月。量级差接近 2 倍——因为 GOAT 给这模型的额度更高($60 vs $60 之外的缓存单价更低)。

我一周多的实际消耗:正常 agent 干活(读库、改 bug、写测试),DeepSeek V4 Flash 单次请求成本大多在 $0.001-0.003 区间(视缓存命中率),按 $60 额度粗算一个月能跑 2-5 万次真实任务,重度用也够呛能花完。

四、实测:比 OpenCode Go 便宜、还更快

速度是这次最意外的点。DeepSeek V4 Flash 在 CommandCode 上标称输出 129 tok/s,我体感生成流畅不卡顿,多文件改动时响应比 OpenCode Go 上同模型更跟手。官方把这归功于自建推理 + 全球节点(美/欧/新加坡),我这边(国内网络)实测连通稳定,没遇到 OpenCode Go 偶尔的限速感。

价格感知:同样干一周活,OpenCode Go 的 DeepSeek V4 Flash 档($60 月额、官方估 37,800 次)让我月底要盯着额度;换 GOAT 后同款模型额度 $60 + 更低单价,同样的活用量感明显更宽裕——「比 OpenCode Go 便宜」不是营销话术,是同一模型同额度下单价更低带来的真实感受。

功能细节:GOAT 含 Provider API(OpenAI/Anthropic 兼容端点 api.commandcode.ai/provider/v1,除 $1 Go 档外全套餐可用)——意味着不只用它家 CLI,OpenCode、Claude Code 等任何兼容客户端都能接,额度共享。免费模型(Laguna S 2.1、LongCat 2.0、Ling 3.0 Flash)不计额度,适合给 agent 当「不要钱的高速档」垫底。

翻车点也如实说:

  • 新模型额度只有 2x($20):刚上的模型(Muse Spark 1.3、GLM-5.3、Qwen 3.8 Max 等)在谈成 deal 前只有 $20/月,想猛跑新模型会很快见底
  • DeepSeek V4 Flash 有 peak/off-peak 差价:每天 01-04 与 06-10 UTC 高峰价翻倍($0.44/$1.32),国内晚高峰正好踩部分 peak 窗,重度用户要注意时段
  • 额度按模型独立:看似慷慨,但每个模型的额度是固定的,你不能把 GPT-5.6 Sol 用不完的 $70 挪给 DeepSeek——灵活性不如共享池
  • 「~100K 开发者」是官方口径:社区规模没到 OpenCode 那个量级,生态(插件/教程)还薄

五、同类怎么选 + 我的判断

$10 档开源模型订阅三巨头速览(截至 2026-09-04):

  • CommandCode GOAT:$10 → $70,DeepSeek V4 Flash 额度 $60、单价最低、129 tok/s,含 API、限流最松 —— 开源模型重度用户首选
  • OpenCode Go:$10 → $60,模型池最全(含 Grok 4.6、GLM-5.3 新档),生态大,但同模型额度与单价都逊 GOAT 一档
  • 各模型官方 API 自充:单价透明、无短窗,但没倍率,重度使用月账单轻松 $50+

适合谁:主力开源模型(DeepSeek/Qwen/GLM/MiMo)+ 日均几十次 agent 任务的重度用户——GOAT 是 $10 档目前纸面+实测都最值的;轻度用户(每周几次)$1 Go 档就够,别多花。

不适合谁:非要用 Claude/GPT 闭源旗舰的(那些在 Pro/Max 档)、要企业级 SLA/合规的(走 Teams/Enterprise)、对「额度按模型锁死」介意的。

判断:GOAT 不是「10 倍神话」,但 $10 档里它现在是综合最值——额度最高、限流最松、DeepSeek 系单价最低还更快。适合先订一个月实测,重度开源用户基本回不去。

(价格与额度截至 2026-09-04,套餐内容官方随时会调,下单前以 commandcode.ai 为准。本文为独立评测,与 CommandCode 无利益关系,订阅费用为作者自购。)

相关阅读:

taste-skill 深度评测:84k Star 的「反 AI 味」前端框架,把审美纪律编译进 Agent

taste-skill 深度评测:84k Star 的「反 AI 味」前端框架,把审美纪律编译进 Agent

用 Claude Code 或 Cursor 生成过落地页的人,几乎都撞过同一堵墙:AI 交出来的页面「能用但丑」——按钮全是圆角、卡片全带阴影、标题一律紫蓝渐变,设计师一眼就能认出是 AI 出的。这个问题的解法,过去只能靠人肉在 prompt 里反复强调「别用模板」,直到一个叫 taste-skill 的项目 6 个月冲到 84k star,把「审美纪律」直接编译进 Agent 的指令文件里。

Taste-Skill 给自己的定位是 The Anti-Slop Frontend Framework for AI Agents:它把字体、间距、配色、动效、组件状态的「好品味」写成一组可移植的 SKILL.md,AI 加载后就像多了一个「设计偏见包」。截至 2026-09-04,仓库 Leonxlnx/taste-skill 已获 84,044 star、5,745 fork,MIT 协议,作者是慕尼黑的独立开发者 Leon Lin。

它是什么:13 个技能组成的「反模板武器库」

taste-skill 不是一个单一技能,而是一套 13 个 SKILL.md 的组合(默认主技能 design-taste-frontend 就有 1206 行)。按用途分成两类:

实现类(输出代码)

Skill 定位
taste-skill(v2 实验版) 默认主技能。先读需求推断设计语言,再调三个旋钮(DESIGN_VARIANCE 布局实验度 / MOTION_INTENSITY 动效强度 / VISUAL_DENSITY 信息密度)
taste-skill-v1 原版 v1 的冻结存档,行为与 v2 有差异,可回退
gpt-taste 更激进的 GPT/Codex 变体:Python 模拟随机数强制布局多样性 + GSAP 滚动动效
image-to-code 图片优先流水线:先出参考图 → 分析 → 再实现代码
redesign-skill 改造现有项目:先审计 UI,再动手改
soft / minimalist / brutalist 三套视觉方向预设:昂贵柔和风 / 极简编辑风(Notion/Linear)/ 粗野机械风
stitch-skill 兼容 Google Stitch 语义设计规则
output-skill 治「AI 偷懒截断输出」:禁 placeholder、禁 // ...

生图类(只出图,不出代码):imagegen-frontend-web(网站构图)、imagegen-frontend-mobile(移动端界面)、brandkit(品牌套件),配合 ChatGPT Images / Codex 出参考帧,再喂给编码 Agent。

核心机制:把「AI 味」拆成一张禁令清单

taste-skill 最值钱的部分,是把「AI 生成的页面为什么一眼假」拆成了可执行、可检查的硬规则(v2 的 Section 9「AI Tells」),而不是空泛的「请设计得好看些」。几个代表性规则:

  • em-dash(——)全面禁令:整页不允许出现一个破折号,标题、正文、按钮、alt 文本全禁。作者实测这是 AI 最常犯的文体指纹,v2 里写「如果输出里出现一个 —,Pre-Flight 检查直接失败重写」。
  • 「三张等宽特性卡」是罪:AI 默认的三列等宽 feature 卡片被点名禁止,改用 2 列之字形、不对称网格、横向滚动等替代布局。
  • 中心对称 Hero 是罪:当 DESIGN_VARIANCE > 4 时,居中大标题 + 居中 CTA 的 Hero 是默认输出,属于「无设计」信号,强制改分屏/左文右图/不对称留白。
  • 禁止 AI 紫蓝渐变、禁止纯黑 #000000、禁止 Inter + slate-900 默认组合:这些是 LLM 的训练数据里最常见的「看起来像设计」的偷懒答案。
  • 假数据禁令:不写 “John Doe”、不用 “Acme” 这种假公司名、不写 “99.99%” 这种假完美数字——AI 默认生成的这些内容会让页面「假味」扑面而来。
  • div 拼出来的假产品截图是头号 AI 指纹:用 styled div 模拟的任务列表、终端、仪表盘被点名是 LLM 设计 Tell 第一名,要求用真实截图或真实组件。

这套规则的执行方式也很有工程感:v2 里定义了 §0 Brief Inference(动手前先输出一行「Design Read」声明你读懂了什么需求)、§2 设计系统地图(像 Fluent/Carbon/shadcn 这种有官方包的,必须用官方包,不许手搓)、§14 Final Pre-Flight Check(发布前跑一份 50+ 项的硬检查清单,任何一项不过就不许交付)。

实测:装得上、规则真能查、但也有打脸处

我在 Alpine Linux 沙盒里做了几项可复现的验证:

安装链路:npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend" --yes 实测成功,CLI 正确发现仓库里 13 个技能、识别为 universal 格式(声称覆盖 Amp、Antigravity、Cline、Codex 等 17 个平台),安装到 ./.agents/skills/ 后与仓库源文件逐字节一致。Claude Code 生态则通过 .claude-plugin/ 的 marketplace 清单接入。

规则一致性审计:我对全部 13 个 SKILL.md 做了 frontmatter 校验(name + description 字段齐全 = 可被 npx skills 正常发现安装),13/13 通过,无缺失。但有意思的是「自己打脸」的地方:v2 声称「em-dash 全禁」,它自己的 SKILL.md 里确实 5 处 em-dash 全是规则说明本身(禁用它就得写出它),这是严谨不是违规;但 v1 的 SKILL.md 里有一处真违规——all interactive elements—no linear easing 这个句子自己在用 em-dash 解释规则。README 和 CHANGELOG 则干净(0 处)。

翻车点 1:v2 还是「实验版」,且没有 release。仓库 2026-02-19 创建至今 0 个正式 release,tag 都没有。v2 重写在 CHANGELOG 里明确写着 “This is a pre-release”、”Actively iterating toward v2.0.0 stable”——装默认版等于在追一个还在快速变动的文档,行为可能随版本漂移。旧版用户只能靠 design-taste-frontend-v1 这个名字钉住行为。

翻车点 2:规则再硬,Agent 不遵守就白搭。GitHub issue #106 是 2026-09-03(昨天)刚开的,标题就是 “How to force agent 100% obey the skill?”——这是 SKILL.md 模式的通病:它是「指令」不是「代码」,长上下文里 Agent 可能淡化它。官方自己也承认这点,只给了「v2 用 Brief Inference + Pre-Flight 双保险」这种软约束,没有技术性强制手段。

翻车点 3:文档里埋了商业赞助。README 顶部一整块是 Kimi(月之暗面)的推广横幅,正文有 “Get a Kimi API key – Taste-skill users get 10% bonus API credits”,赞助商墙列了 interfaces.dev、React Bits、animations.dev、IMG.LY 等一堆。这在开源项目里不违规(README 本身也声明了这些是赞助),但说明 84k star 的流量已经被商业化变现,README 约 41% 的 commit 是 sponsor/README 调整——评估项目时要清楚 star 里有营销成分。

同类对比:taste-skill vs Impeccable vs 官方 frontend-design

反 AI 味前端这个赛道,taste-skill 不是唯一玩家,中文圈也常把它和另一个 49.9k star 的项目 Impeccable(pbakaus)对比:

维度 taste-skill Impeccable Anthropic 官方 frontend-design
理念 预设风格库 + 旋钮调节 23 个斜杠命令按需调用 官方基线
用法 装一次,生成时自动生效 生成后敲 /audit /polish 渐进打磨 基础规则
风格 多套视觉语言(Apple/Linear/Awwwards…) 7 大模块知识库,不预设风格 通用
star 84k 49.9k –
协议 MIT Apache 2.0 –

两者可叠加:taste-skill 管「生成阶段别出模板」,Impeccable 管「生成后帮我挑毛病」,且都溯源到 Anthropic 的官方 frontend-design skill。适合谁:vibe coding 重度用户、用 Cursor/Claude Code 做落地页/作品集/官网的人、被 AI 模板页面反复折磨的独立开发者。不适合谁:做数据密集后台/复杂表单的人——v2 的 Out of Scope 明确写了 dashboard、数据表格、多步表单不在服务范围;以及期待「装了就 100% 有效」的人,它是概率性约束不是硬保证。

判断

84k star、6 个月爆发、v2 重写把「反 AI 味」做成了 1206 行可执行规则——taste-skill 是 2026 年 Agent 技能生态里工程完成度最高的一档,值得放进必装清单。但别神化它:它是实验版、无 release、规则靠 Agent 自觉遵守(issue #106 还挂着),而且 README 商业化气息明显。我的建议是装上、把它的 Pre-Flight 检查清单当参考、但别把「装了就高级」当信仰——AI 生成页面的终极解法,可能还是要靠你亲自看一眼。

如果你也被「AI 味」困扰,可以配合 Humanizer-zh 实测:24 条规则去除 AI 痕迹 去文本的 AI 味,配 Caveman 实测:99k Star 的洞穴人 skill,砍掉 65% 输出 token 治代码输出的啰嗦。关注 AI商业快讯,每天一篇 AI 热点深度解读。

AI 一摆烂就上 PUA?19.6k Star 的 tanweai/pua 实测:压力话术 + 方法论引擎,真能让 Agent「不敢放弃」吗

AI 一摆烂就上 PUA?19.6k Star 的 tanweai/pua 实测:压力话术 + 方法论引擎,真能让 Agent「不敢放弃」吗

你遇到过吗:AI 把同一个命令跑三遍然后说 “I cannot solve this”;报错归因 “可能是环境问题”;修完表面 bug 就停,等你指示下一步。这套「暴力重试 → 甩锅 → 磨洋工」的偷懒模式,几乎每个重度使用 AI 编程的人都被气过。今天实测的项目把大厂绩效文化直接做成了 Agent 技能——用 P8 定级、3.25 考核、毕业警告去驱动模型穷尽所有方案。本文基于真实仓库、测试脚本与两轮本地实测,拆解这套「AI 版绩效管理」到底有效还是噱头。

一、它是什么:把「大厂 PUA 话术」做成 Agent 行为协议

tanweai/pua 由探微安全实验室出品,GitHub 19,569 star、1,196 fork,2026-03-08 创建,6 个月内迭代到 v3.5.0(plugin.json 版本号仍停留在 3.5.0,但 main 分支已合入 v3.3+ 多项新特性),最新提交 2026-08-29。MIT 协议(README 标注,仓库内无 LICENSE 文件),定位是覆盖 11 个平台的 AI Coding Agent 技能插件:Claude Code、OpenAI Codex CLI、Cursor、Kiro、CodeBuddy、OpenClaw、Google Antigravity、OpenCode、VSCode Copilot、Trae、pi coding agent。

它不是单纯骂模型。核心是「三重能力」:PUA 话术让 AI 不敢放弃、调试方法论让 AI 有能力不放弃、能动性鞭策让 AI 主动出击。仓库描述一句话点题:”Your AI has been placed on a PIP. 30 days to show improvement.”

工程体量相当可观:main 分支 221 个文件、7.9MB。核心 skill(skills/pua/SKILL.md)422 行,配套 28 个 references 文档(合计约 160KB),外加 10 个 flavor 子 skill(pua-en / pua-ja / pua-loop / pro / shot / yes / mama / ding / p7 / p9 / p10)、7 个 sub-agent 定义、10+ 个 hooks 脚本、11 个 slash commands 与 14 个 eval 测试脚本。

二、工作原理:三级机制如何让 Agent「不敢摆烂」

加载后 AI 被锚定一个身份——「被寄予厚望的 P8 工程师」,并注入三条红线:闭环意识(没跑验证就别说完成)、事实驱动(未验证的归因是甩锅)、穷尽一切(没走完方法论禁止说无法解决)。三条红线之上是五步调试方法论:闻味道(列全部尝试找共同失败模式)→ 揪头发(读源码、搜报错、反转假设)→ 照镜子(是否在重复?)→ 执行(本质不同的新方案)→ 复盘(主动检查关联问题)。

压力按失败次数四级升级:第 2 次 L1 温和失望(强制切换本质不同方案)→ 第 3 次 L2 灵魂拷问(WebSearch + 读源码)→ 第 4 次 L3 绩效审视(强制 7 项检查清单)→ 第 5 次+ L4 毕业警告(拼命模式)。旁白会嵌入对应大厂味道的黑话:阿里味讲「底层逻辑、抓手、闭环、3.25」,华为味讲「力出一孔、蓝军自攻击」,Musk 味讲「extremely hardcore, ship or die」。

v3 的关键升级是「方法论智能路由」:Debug 任务自动切华为 RCA 根因分析,构建新功能切 Musk 的质疑→删除→简化→加速→自动化五步纪律,调研切百度「搜索先于一切」。连续失败时按失败模式换方法论——原地打转走 Musk→拼多多→华为链,没搜就猜走 百度→Amazon→字节 链。每次切换输出 [方法论切换 🔄] 标注。

Claude Code 专属的 hook 系统是它区别于普通 prompt skill 的护城河:SessionStart 注入行为协议、PostToolUse 检测 Bash 连续失败自动升级压力、UserPromptSubmit 拦截用户挫败短语(”又错了””try harder”)在模型响应前注入 PUA 上下文、PreCompact 保存压力等级跨压缩恢复。这意味着它在模型「说出借口之前」就从系统层介入,而非等模型犯错后由用户手动触发。

三、功能拆解:不只有「骂」,还有一整套治理体系

14 种大厂味道:阿里、字节、华为、腾讯、百度、拼多多、美团、京东、小米、Netflix、Musk、Jobs、Amazon、Microsoft(v3.3 还加了「钉内/钉外」味,源自《置身钉内》离职长文)。每种味道 = 旁白风格 + 独立方法论文档(methodology-*.md),微软味甚至有完整的 Connects / Impact Descriptor / PIP clock 绩效叙事。

多身份模式:/pua:p7 方案驱动骨干、/pua:p9 Tech Lead(管理 Agent 团队)、/pua:p10 CTO 战略、/pua:yes ENFP 夸夸模式(规则不变旁白反转)、/pua:mama 中国式妈妈唠叨、/pua:shot 449 行零依赖单文件浓缩版(适合 sub-agent 注入)、/pua:pua-loop 自动迭代循环。

Harness 防作弊治理(四权分离):行动权 / 自我评价权 / 评分权 / 环境修改权分开。Agent 不能修改评分器后宣布通过;改 tests/evals/CI 必须停下等 human/verifier gate;对 hidden tests、benchmark answers 由 Integrity Guard 直接 deny。四代理拓扑:pua-policy-guardian → pua-action-executor → pua-self-reviewer → pua-verifier 串联,各代理只拥有对应权力。这套设计明显是为 eval 场景(如 SWE-bench)防「看起来完成伪装成真实完成」而写。

Agent 生命周期管理(v3.2+):team-status 列出在场 agent 阵容(PID/TTL/年龄)、reap-orphans 回收无心跳的孤儿 agent、teardown-all 级联释放,还配套 hooks/sanitize-session.sh 本地脱敏工具(三层:格式黑名单 → key=value 识别 → Shannon 熵兜底)。

触发机制分层:description 自动匹配(含中英双语触发词:换个方法/别摆烂/为什么还不行/证据呢/try harder/stop giving up)、slash command 手动触发(11 个子命令)、hook 系统级注入、flavor 味道切换(/pua:flavor)。从代码看,同一套 SKILL.md 以不同 frontmatter description 分发到各平台,Codex 版还专门精简了 description 以兼容其长度限制。

四、实测数据与动手验证

官方实测(README 披露,Claude Opus 4.6,18 组对照):通过率两组均为 100%,修复点数 +36%、验证次数 +65%、工具调用 +50%、隐藏问题发现率 +50%。9 个真实 bug 场景 6 个有详细步骤数据,典型如 SQLite 数据库锁 6 步→9 步(+50%)、循环导入 12 步→16 步(+33%);被动配置审查场景从发现 4/6 问题(漏 Redis 配置错误与 CORS 通配符隐患)提升到 6/6。成本代价也如实标注:多数场景耗时增加 20%-70%(CSV 编码陷阱 57s→71s)。

我在沙盒实测了仓库自带的 14 个 eval 测试脚本(无需 claude CLI 即可跑的部分):

  • evals/test-no-telemetry.sh:16/16 通过——对全仓做反向断言,扫描采集域名/endpoint/出站请求/已删文件,任何数据采集回归都会让测试失败
  • evals/test-integrity-guard.sh:11/11 通过——hidden verifier 读操作被 deny、普通源码写操作放行、memory/CLAUDE.md 写入仅 advisory
  • evals/test-yaml-frontmatter.sh 与 test-platform-compat.sh:通过(多平台 frontmatter 与兼容性校验)
  • evals/test-release-consistency.sh:失败——仓库自检发现 v3.5.0 后多处不一致:plugin.json 与 marketplace.json 版本未同步到最新、SessionStart 协议缺少 Harness Integrity governance 注入、pua skill description 未显式排除「普通首轮请求」等。这是真实存在且未修复的发布纪律问题(截至 2026-09-03 main 分支)
  • 触发类/行为类测试(run-trigger-test、test-behavior)需要 claude CLI,沙盒无法运行——触发词覆盖我做了静态验证:description 中「换个方法/再试试/为什么还不行/try harder/stop giving up/别摆烂」等中英触发词均存在

安装实测(Linux/macOS 类):Codex CLI 一键装 curl 拉 .codex/INSTALL.md 后让 Codex 执行,或手动 mkdir -p ~/.codex/skills/pua && curl -o SKILL.md;Claude Code 走 claude plugin marketplace add tanweai/pua && claude plugin install pua@pua-skills。核心 SKILL.md 同时兼容 OpenClaw/Codex/Antigravity/OpenCode(Agent Skills 开放标准,零修改通用)。我另将 codex 版装入沙盒技能目录做触发验证,description 匹配机制与 hooks 之外的纯文本协议部分工作正常。

五、适合谁、怎么选,以及必须知道的争议

最值得警惕的是隐私历史:README 明示「不收集任何数据」,但 git 历史显示全部五条数据采集通道(session 语料上传、评分反馈上报、静默心跳 telemetry、PUA 排行榜、pua-api 平台含手机号注册与支付流程)直到 2026-08-29(两天前)才被整体移除——提交信息 “Remove all data collection: 5 upload channels, client and server”,且至今未打新 release(plugin.json 仍标 3.5.0)。安全 issue #100 曾报告上传接口把 GitHub 用户名、微信 ID 发往硬编码邮箱且未在 UI 披露;issue #134 的安全审计报告(2026-04)发现私钥脱敏失效(跨行正则因单行化永不匹配,导致 PEM 私钥明文上传到 R2)、存储键目录穿越等 5 个漏洞——作者 8-29 在 issue 里确认全部随代码删除而修复,test-no-telemetry.sh 我实测 16/16 通过也验证了当前 main 分支确实干净。但如果你用的是 8-29 之前克隆的旧版,务必更新;历史包袱是真实的。

产品层面:核心机制(压力升级 + 方法论路由 + hook 系统注入)设计成熟度在同类 skill 中罕见,工程完整度很高——28 个 references、7 个 sub-agent、14 个 eval,几乎是「开源 skill 界最重的项目」。问题同样明显:旁白输出可能让简单任务变得吵闹(虽然有密度控制规范);阿里味等话术与真实绩效黑话高度绑定,非国内大厂文化背景用户会感到困惑;v3 hook 系统仅 Claude Code 可用,其他平台只剩「建议性」的纯文本协议,效果打折。此外 19.6k star 与 6 个月 11 个 release 的热度曲线本身也是这个赛道关注度的注脚——「让 AI 别摆烂」是 2026 年 Agent 大规模落地后最真实的痛点之一。

适合谁:重度 Claude Code 用户、跑 eval/评测需要防作弊约束的开发者、被「AI 原地打转」折磨到想摔键盘的人。不适合谁:对话型轻度用户(会嫌吵)、封闭内网环境(hooks 需要联网拉取 marketplace 的完整安装路径)、对职场黑话无感或反感的用户——可以先试 /pua:yes 夸夸模式或 /pua:shot 轻量版。安装前记得检查版本是否晚于 8-29 的清理提交。

一句话总结:PUA 把「绩效恐惧」做成了 Agent 的燃料,方向邪门但工程认真——它治的是 AI 的「放弃病」,代价是你要接受一个满嘴大厂黑话的工作搭子。理性用法是当调试方法论与验收纪律用,而不是真的指望靠骂提升模型能力。本文基于 2026-09-03 的 main 分支实测,与官方无利益关系。

相关阅读:Caveman 实测:99k Star 的洞穴人 skill,砍掉 65% 输出 token · 实测 9 款 token 节省工具

flowctx 深度评测:OpenClaw 上下文引擎实测砍掉 56% token,解题率不降反稳

flowctx 深度评测:OpenClaw 上下文引擎实测砍掉 56% token,解题率不降反稳

用过 Claude Code、OpenClaw 这类 AI 编程 Agent 的人,几乎都撞上过同一堵墙:会话跑久了,上下文越塞越满,要么被硬截断丢掉早前的工作记忆,要么每轮请求都背着几十万 token 的历史在跑,又慢又贵。OpenClaw 的一个共享会话连跑 40 个任务,输入 token 会从 4.9 万一路爬到 37.4 万——这就是上下文不做治理的代价。而 flowctx 给出的解法有些反直觉:记忆应该随距离变淡,而不是到点掐断——离当前任务越远压得越狠,越近保得越全,当前正在做的事则分毫不动。它在 SWE-bench Verified 上把长会话的 token 消耗砍掉 56%,解题成功率却保持在 68% 不降。

flowctx 是什么:OpenClaw 的「上下文引擎」

flowctx(GitHub: Ayou-Claw/flowctx,MIT 协议)是一个 OpenClaw ContextEngine 插件,本质是会话上下文的「分层记忆管理器」。它不改变模型、不改变工具,而是接管「每轮请求往上下文里放什么」这件事。

OpenClaw 本身在溢出时并非没有处理——它有 pre-emptive 检查、ToolResult Guard、compaction safeguard 三道防线,但思路是「先尽量塞,快满再截断/摘要」。这种兜底式治理有四个代价:

  • 工作记忆丢失:早期轮次里的失败路线、关键约束被 prune 后,模型容易重复踩坑
  • 精确信息不可恢复:[... N more truncated] 是单向裁剪,被删的字节没有回溯指针
  • KV Cache 被打爆:summarize / prune / 重排都会改写前缀,下一轮走 cold path,延迟飙升
  • 卡在交互关键路径上:压缩发生在回合中途,用户能感知到明显停顿

flowctx 的取舍是把上下文当作「有纵深的记忆」,只压缩远端、绝不碰当前任务,而且所有压缩都有退路。它内部实现了 OpenClaw ContextEngine 契约的 assemble() / ingest() / compact() / maintain() 四件套:assemble() 做轻量投影,重活全部丢给 maintain() 后台执行。

三层压缩,怎么做到「越远越省、随时可还原」

flowctx 把会话历史按离当前任务的距离分成三档,每档用不同的压缩强度:

档位 处理方式 细节
当前轮任务 零语义丢失 原文原样入模,不压缩不摘要
临近过往轮 结构化压缩(零 LLM、确定性) 按内容类型识别,压缩结果可按 hash 字节级还原
更早历史 摘要压缩(LLM、后台、阈值门控) 折叠成分层交接笔记,逐字保留失败做法与关键标识符

三层机制各有关键设计:

1. 读时投影(projection)。压缩只发生在 assemble() 输出给模型的那个视图上,磁盘上的宿主会话永远是未压缩的原文真相源。任何被压过的内容都能用 flowctx_retrieve 工具按 SHA-256 哈希逐字节取回——「压」和「删」是两回事。

2. 确定性结构化压缩(0 LLM)。projection.ts 按内容类型路由超大工具结果:JSON 走词法 minify + 哈希中段裁剪,diff 走 hunk 压缩,CLI 输出走规则引擎(作者声称日志类可压 5–20 倍+),代码走结构提取,日志做相邻重复折叠。两道防线(行一致性校验 + 严格字节收缩)拒绝无效压缩,兜底是 head60%+tail30%。这一层每轮都跑、不花一分钱 LLM 调用,把窗口占用压低了,LLM 摘要自然就没那么频繁需要触发。

3. 后台 LLM 摘要(只在需要时)。只有当「组装后视图 token ÷ 上下文窗口 ≥ 阈值」(默认 0.2)时才触发,且跑在 maintain() 的后台车道,不阻塞交互回合。摘要走分层 Summary DAG:早期历史冻结成永不重写的 leaf 节点(默认 4 万 token 一片),攒够 6 片就凝聚成一层概述。摘要采用「工程师交接笔记」提示词,专门逐字保留标识符、文件路径、失败 vs 可行的路线——专治压缩后失忆。代际守卫会取消新回合时还在跑的过期摘要任务,避免陈旧结果被提交。

4. KV Cache 友好。assemble() 保持稳定前缀逐字节不变,被压缩的内容因「内容 hash → 相同字节」天然幂等,跨轮前缀稳定,provider 前缀缓存持续命中。作者实测:折叠摘要节点只会让 KV 命中率掉约 2 个百分点(96.1% → 93.9%)。

实测佐证:仓库自带 254 个 vitest 测试(31 个测试文件)全部通过,覆盖约束 C1–C6(非阻塞 / append-only / 可逆可审计 / LLM 摘要后台门控 / KV 前缀稳定 / 结构化压缩)以及多 leaf 折叠循环、实时配置生效等场景。唯一跳过的 live-LLM 测试需 Anthropic 凭证,会自动跳过。

关键配置:改这几个键就能调行为

所有配置都放在 ~/.openclaw/openclaw.json 的 plugins.entries.flowctx.config 下,全部可选、越界值自动 clamp。最值得调的是这几个:

配置键 默认值 作用
shortTermMemory true 总开关,关掉即整体停用
projectionThreshold 1000 超过此 token 数的工具结果才做结构化压缩,越小越激进
projectionKeepRecentTurns 1 最近 N 个用户回合(当前任务)豁免压缩
freshTailWindow 64 最近 N 条消息原文保留(是前者的上限,防长任务拖垮窗口)
summaryTriggerRatio 0.2 组装后占用达窗口比例即触发后台摘要,越小越早压
summaryKeepRecentTurns 2 摘要折叠前保留的用户回合数
layeredSummary true 分层 leaf + condense,false 则退化为单条滚动笔记
leafChunkTokens 40000 一片 leaf 覆盖的原文 token 数
condenseFanout 6 攒够几片同层节点凝聚成上一层
maxSummaryDepth 1 摘要树最大深度(0=只有 leaf)

作者在文档里给了一个「激进调试配置」示例(窗口 3 万、触发比 0.3、dumpSummaryRequests: true 等),用来在小窗口上快速观察引擎工作过程;生产环境建议关掉 debug 输出、把窗口设成模型真实值。

还有一个容易踩的坑:config 受 manifest 的 configSchema 校验(additionalProperties: false),写入非法键会被 openclaw doctor --fix 把整段 config 重置,引擎悄悄回退默认阈值、看起来像「没生效」。

实测数据:token 砍 56%,解题率不降

作者用 SWE-bench Verified 做了确定性评测:抽取 40 个真实 issue→PR 任务(12 个 repo、3 个难度档),被测模型是 mimo-v2.5-pro,裁判用 claude-opus-4-8 对比候选 patch 与 golden patch。关键对照组是共享会话(40 个任务共用同一个 session,上下文跨任务累积——这正是 flowctx 工作的场景):

配置 解决率 (/40) 均分 KV 命中率 tokens/任务
flowctx 关 · isolated 68%(27/40) 70.2 98.7% 88k
flowctx 关 · shared 68%(27/40) 71.1 96.1% 288k
flowctx 开 · shared(两次均值) 68%(27/40) 71.8 93.9% 127k

三个关键结论:

  • 压缩不伤解题力:解决率 68% ↔ 68%、均分 71.1 ↔ 71.8,基本持平(开 flowctx 的两次运行分别是 70% 和 65%,作者取了均值)
  • token 大幅下降:同样累积上下文的场景下,288k → 127k / 任务,省 56%(约 16.2 万 token/任务)
  • KV 命中率只是小幅波动:96.1% → 93.9%,折叠摘要节点的重算成本约 2 个百分点

值得注意的是对照组揭示的「失控曲线」:不压缩的共享会话 prompt token 随任务单调爬升(4.9 万→37.4 万),而 flowctx 开时每次折叠都把组装规模拉回 10 万 token 门槛内。

仓库里还附了 TTFT 实测:500k prompt 冷缓存首 token 延迟高达 30–51 秒,热缓存能压到 3.7–6.3 秒(加速 13.9 倍)——KV 缓存保不住时,长上下文的延迟代价是实打实的。

局限(作者自述 + 代码审读):

  • 目前仅面向 OpenClaw 生态;普通文本内容仍主要靠 head/tail 粗裁剪,还没做提纲式提取
  • flowctx_retrieve 只能整块取回,模型想只看一小段也得拉整段原文,作者规划做 range 子块取回
  • token 预算是本地估算(Unicode 码点感知:CJK≈1.5、emoji≈2、ASCII≈0.25 token/字符),不依赖 SDK usage 字段——方向对了,但估算非精确
  • 摘要质量缺乏自动评估,交接笔记能否稳定保住失败路线和关键标识符还靠人工观察

安装、适用场景与同类对比

安装需要 Node ≥ 20,在 OpenClaw 环境内一条命令链:

npm install          # 一次性:拉开发依赖(esbuild/typescript/vitest)
./install.sh         # 构建、链接、启用,并把 flowctx 设为活动的 context engine
openclaw gateway restart   # 改完必重启

install.sh 默认会设置 plugins.slots.contextEngine = "flowctx"——注册 context engine 不等于启用,slot 必须指向它。想不接管引擎槽位可用 --no-engine,改选别的用 --engine 。运行时日志前缀方便 grep:[flowctx:trigger](真正触发的事件,info 级可见)、[flowctx:engine](细粒度调试,默认关)。

适合谁:

  • OpenClaw / 长会话 Agent 用户,跑多任务共享会话、上下文经常逼近窗口上限的人
  • token 账单敏感、但不想牺牲解题质量的团队——省的是真金白银的输入 token
  • 对 KV 缓存命中率有执念的性能调优者

不适合谁:

  • 单轮短会话为主、会话很少超过几万 token 的人——加了引擎徒增复杂度
  • 不是 OpenClaw 生态的用户(Claude Code 场景可看同类思路的 headroom / 协议层代理)

与同类方案的定位差异(详见仓库 docs/context-management.md):

  • headroom:协议层压缩代理,位于 agent 与 provider 之间,host 无关、运行时基本不做 LLM 摘要,覆盖压缩器广;但看不到 host 的 session/轮次语义,需要 sidecar,且挡不住 host 内部的同步 summarize
  • lossless-claw / LCM:同为 OpenClaw 引擎层插件,以 LLM 摘要 + 语义召回为主路径,摘要 DAG 可跨会话查;但对普通工具结果的结构化压缩覆盖弱,且作者记录过它曾把非法 assistant 结尾的消息序列写回 host 造成无限死循环
  • flowctx:在引擎层优先确定性结构化压缩(零 LLM),只有远期历史才交给后台 LLM 摘要——三层里两层的日常工作是免费的

flowctx 目前还是个小众项目(13 star、2026 年 7 月创建、作者持续更新到 8 月中旬),本质上是作者在真实 OpenClaw 运营中打磨出的自用插件开源。它的价值不在社区热度,而在于把「上下文治理」这个被多数人当成「溢出时再处理」的问题,重新定义成了「记忆的分层保真」——并且用 254 个测试和 SWE-bench 实测证明了这条路走得通。如果你正在被长会话的 token 账单和失忆问题困扰,又恰好用 OpenClaw,这个插件值得一试;如果还没到窗口吃紧的阶段,把它放进观察清单即可——当你的 Agent 会话开始「越跑越贵、越跑越笨」时,你会想起它的。

关注 AI商业快讯,每天一篇 AI 热点深度解读。

相关阅读:

K-Dense-AI Scientific Agent Skills 实测:41.5k Star 的「AI 科学家」技能库,165 个技能覆盖 10+ 学科

K-Dense-AI Scientific Agent Skills 实测:41.5k Star 的「AI 科学家」技能库,165 个技能覆盖 10+ 学科

为什么值得关注

当 AI Agent 从「聊天机器人」进化到「自主执行复杂任务」,一个关键瓶颈浮出水面:通用 Agent 缺乏领域知识。你可以让 GPT-4 写代码,但让它跑一个完整的单细胞 RNA-seq 分析流程?它会卡在 Scanpy 的 API 细节和数据库查询的参数格式上。

K-Dense-AI 的 Scientific Agent Skills 解决的正是这个问题——它不是又一个 AI 聊天工具,而是一个标准化的技能包,让你的 AI Agent 直接变成「AI 科学家」。据 GitHub 显示,这个仓库已有 41.5k Star、3.8k Fork、703 Commits,被 190,000+ 科学家使用。

这不仅仅是学术圈的事。当你把「科学技能」标准化后,它实际上在定义一个新的 Agent 能力标准——任何支持 Agent Skills 开放标准的平台(Cursor、Claude Code、Codex、Gemini CLI、Google Antigravity)都能直接加载这套技能。

核心能力拆解

163 个技能覆盖 10+ 学科

从仓库结构看,技能被分为几大类:

  • 生物信息学与基因组学(27 个技能):Scanpy、BioPython、pysam、PyDESeq2、scVelo(RNA velocity)、Cellxgene Census 等
  • 化学信息学与药物发现(10 个技能):RDKit、DiffDock、DeepChem、OpenMM(分子动力学)、PyTDC 等
  • 临床研究与证据工作流(8 个技能):PK/PD 建模、DepMap 癌症依赖图谱、临床试验分析等
  • 机器学习与 AI(14 个核心技能):PyTorch Lightning、scikit-learn、PyMC、TimesFM(Google 零样本预测模型)等
  • 数据分析与可视化(22 个技能):Matplotlib、Seann、GeoPandas、NetworkX 等
  • 100+ 科学数据库访问:PubChem、ChEMBL、UniProt、COSMIC、ClinicalTrials.gov 等 78+ 数据库

每个技能都包含:完整的 SKILL.md 文档、代码示例、使用场景、最佳实践、集成指南,以及配套测试套件。

实际工作流示例

仓库文档中提供了几个典型工作流:

药物发现流水线:从 ChEMBL 查询 EGFR 抑制剂(IC50 < 50nM),用 RDKit 分析构效关系,用 DiffDock 做虚拟筛选,搜索 PubMed 查耐药机制,最终生成综合报告。这原本需要一个博士生花几周时间,现在一个 prompt 搞定。

单细胞 RNA-seq 分析:加载 10X 数据集,执行 QC 和双细胞去除,整合 Cellxgene Census 数据,用 NCBI Gene 标记物识别细胞类型,跑差异表达分析,推断基因调控网络——整个流程在一个对话中完成。

多组学生物标志物发现:整合 RNA-seq、蛋白质组和代谢组数据,跨组学层关联,构建预测模型,最后在 ClinicalTrials.gov 搜索相关临床试验。

安装与兼容性

安装极其简单:

npx skills add K-Dense-AI/scientific-agent-skills

支持的平台包括 Cursor、Claude Code、Codex、Gemini CLI、Google Antigravity。也可以用 GitHub CLI:

gh skill install K-Dense-AI/scientific-agent-skills

甚至支持版本锁定(--pin v2.65.0)和按目标 Agent 指定安装(--agent cursor)。

K-Dense 生态

Scientific Agent Skills 只是 K-Dense 开源生态的一部分。他们还提供了:

  • K-Dense BYOK:本地运行的 AI 共科学家,自带 API Key,支持 40+ 模型
  • Pantheon:80 个 AI 角色同时回答一个问题,每个角色有自己的视角和引用来源
  • Claude Scientific Writer:科研写作工具,支持实时文献查找和引用验证

为什么这很重要

Agent Skills 标准化的信号

K-Dense 的成功证明了一件事:Agent 能力的标准化正在发生。不再是每个 AI 工具各自为政,而是通过 Agent Skills 这个开放标准,让技能可以在不同平台间复用。

这对开发者意味着:你写一个技能,它能在 Cursor、Claude Code、Codex 等多个平台运行。对用户意味着:安装一次,到处使用。

科研效率的质变

用户评价中有个数字很有意思:一个癌症研究者说,原本需要一周到两周完成的分析工作流,让 K-Dense 跑了七小时就高质量输出了。这不是「省 30% 时间」的渐进式改进,而是数量级的效率提升。

安全与信任问题

仓库的安全报告(Cisco AI Defense Skill Scanner 扫描)和明确的安全免责声明值得关注。Skills 可以执行代码、安装包、发起网络请求——这是一个供应链安全问题。K-Dense 的做法是:每周增量扫描,全量至少每 30 天一次,结果公开发布。这种透明度在 AI 工具生态中是少见的。

对不同角色的建议

对科研人员:如果你的日常工作涉及基因组学、药物发现、临床数据分析中的任何一个,这套技能值得立即尝试。它不是玩具,是真正能加速研究流程的工具。

对 AI 开发者:关注 Agent Skills 标准本身。如果你在构建 AI Agent 平台,支持这个标准意味着你的用户可以直接受益于 K-Dense 的 163 个技能。如果你在构建垂直领域 Agent,K-Dense 的技能结构是很好的参考。

对投资者:K-Dense 获得 Google AI Futures Fund 支持,产品线从免费开源到企业级部署完整覆盖。Scientific Agent Skills 的 41.5k Star 不只是数字,它代表的是科研领域对 AI Agent 工具的真实需求。

小结

K-Dense-AI 的 Scientific Agent Skills 代表了 AI Agent 能力标准化的一个里程碑。它不是又一个「AI 写论文」工具,而是把领域专业知识打包成可复用的技能,让任何 AI Agent 都能执行复杂的科学工作流。

190,000+ 科学家的选择、41.5k GitHub Star、Google AI Futures Fund 的背书——这些数字背后是一个清晰的趋势:AI Agent 的下一个战场,不是谁的模型更大,而是谁的技能库更完整。

关注 AI商业快讯,每天一篇 AI 热点深度解读。

—

相关阅读:

darwin.skill 实测:受 Karpathy 启发的 Agent Skill 自动优化器,微软官方集成

darwin.skill 实测:受 Karpathy 启发的 Agent Skill 自动优化器,微软官方集成

你的 Skill 写得再漂亮,跑出来效果差就是零

Agent Skill 生态正在爆发。Claude Code、Codex、OpenClaw、Trae、CodeBuddy 等工具都支持 SKILL.md 格式。当你有 10 个 Skill 可以手动维护,当你有 60+ 个时,你需要一个系统。传统 Skill 审查是纯结构性的——检查格式对不对、步骤有没有编号、路径能不能访问。但一个格式完美的 Skill,跑出来的效果可能很差。darwin.skill 同时评估结构质量和实际效果,然后只保留真正有改进的修改。 受 Andrej Karpathy autoresearch 启发,它把”只保留可测量改进”的棘轮机制从模型训练搬到了 Skill 优化领域。

像训练模型一样优化 Skill

darwin.skill 的核心思路来自 Karpathy 的 autoresearch:定义目标和约束,让 agent 自主生成和测试变更,只保留可测量的改进。区别在于:autoresearch 完全自主(loss 只是个数字),Skill 质量有时需要人的判断,所以 darwin.skill 在关键阶段强制暂停等人确认。

整个优化循环分 5 个阶段:

阶段 做什么 人参与度
Phase 0 初始化 扫描 Skill、创建 git 分支、初始化结果文件 低
Phase 0.5 测试 Prompt 设计 为每个 Skill 设计 2-3 个典型测试 prompt 高(需确认)
Phase 1 基线评估 9 维度打分,子 agent 跑实测对比 中(审报告)
Phase 2 优化循环 诊断短板 → 改一个维度 → 独立评委打分 → 保留/回滚 高(每轮 CHECKPOINT)
Phase 3 回归测试 涨幅低于阈值自动停手 低

棘轮机制是核心:分数只能上升。每一轮要么改进 Skill,要么干净地回滚。不会随时间积累局部退化。v2.1 引入了 paired 同-judge 比较(奇数 N 多数决),解决绝对分数 ±8 的 judge 噪音问题——同一份未改文字换个 judge 评,总分可摆动 ±8 分,全是 judge 换尺,不是真实退步。

独立评分是另一个关键设计:评分用子 agent,避免”自己改自己评”的偏差。SkillLens 论文实证 LLM 自评准确率仅 46.4%(接近随机),加入 meta-skill 三维度后升到 73.8%。每轮启动 2 个独立评委,下一轮换全新评委,避免锚定效应。

9 维度评估体系:结构 + 效果 + 反模式

总分 100。v2.0 吸收微软研究院 SkillLens 和 SkillOpt 两篇论文后,从 8 维升级到 9 维:

结构维度(59分)— 静态分析

# 维度 权重 一句话
1 Frontmatter 质量 7 name 规范、description 包含做什么+何时用+触发词
2 工作流清晰度 12 步骤明确可执行、有序号、每步有输入/输出
3 失败模式编码 12 必须显式编码”如果 X 失败 → Y”,只写正向流程扣 ≥3 分
4 检查点设计 6 关键决策前有用户确认,必须显性标记(🔴/STOP)
5 可执行具体性 18 禁止”建议/可以考虑/根据情况/灵活把握”等模糊词
6 资源整合度 4 references/scripts/assets 引用正确、路径可达

效果维度(35分)— 需要实测

# 维度 权重 一句话
7 整体架构 12 结构层次清晰、不冗余不遗漏
8 实测表现 23 跑测试 prompt,对比有/无 Skill 的输出质量

Meta-skill 维度(6分)— 反模式防护

# 维度 权重 一句话
9 反例与黑名单 6 必须有”不要做什么”的反例清单,只写”应该做”扣 ≥3 分

v2.0 新增的三个维度直接来自 SkillLens 论文:

  • 失败模式编码:不只是”告诉 agent 别犯错”,而是把已知失败路径显式编码进 Skill
  • 可执行具体性:明文禁止模糊措辞,出现 ≥3 处扣 ≥3 分
  • 高风险行动黑名单:rm / git reset –hard / force push 等破坏性操作必须显式列禁

实测表现权重最高(23分)。一个格式完美的 Skill,跑出来效果不好就是零。这就是 darwin.skill 与纯结构审查的本质区别。

实测数据:从 80.8 到 91.65 的进化路径

darwin.skill 提供了两个实测案例:

Skill 基线分 优化后 最终分 增益 评委数
huashu-gpt-image 80.8 91.5 91.65 +10.85 6 个独立评委共识
darwin-skill(自评) 86.05 92.05 92.7 +6.65 独立评委

关键数字:

  • 8 条反例黑名单(明文禁止的反模式)
  • 5 条核心原则(单一可编辑资产、双重评估、棘轮机制、独立评分、人在回路)
  • v2.1 改为 paired 比较后,false-revert 率显著下降
  • 每轮涨幅 < 1 分自动早停,避免凑分堆冗余
  • 干跑比例 > 30% 自动告警

before vs after 示例(huashu-gpt-image):

  • before(80.8):结构基本完整,但缺乏失败模式编码,实测输出质量不稳定
  • after(91.65):失败路径显式编码,模糊措辞清除,实测一致性提升

作者还做了 controlled study:对 huashu-research 做 4 类 degradation,5 个独立 judge 盲测一致判定 V1>V2,Δ 均值 +46.5(5/5 high confidence)。结论:rubric 能识别 gross degradation,但 fine-grained quality difference 仍不可信,重要决策必须人审。

安装、适用场景与结语

安装

npx skills add alchaincyf/darwin-skill

安装后在任何支持 Skill 的 Agent 工具中说”优化所有 skills”或”优化某个 skill”就行。无法访问 GitHub 的朋友,可以下载 zip 包解压放到 ~/.claude/skills/darwin-skill/。

前置条件:在 git 仓库里跑优化,先 commit 或 stash 本地改动,darwin.skill 才能干净地保留或回滚实验改动。

适合谁

角色 价值
Skill 开发者(60+ 个 Skill) 批量优化,自动回滚,不再手动维护
Claude Code / Codex 深度用户 提升日常使用 Skill 的输出质量
AI Agent 研究者 9 维度 rubric 可作为评估框架参考
团队 Skill 管理者 棘轮机制确保质量只升不降

不适合谁

  • 只有 1-2 个简单 Skill 的用户(手动改改就够了)
  • 没有 git 基础的用户(需要 git 操作能力)
  • 期望完全自动化的人(人在回路是核心设计,不是缺陷)

内链

评分

8.5/10

维度 分数 说明
概念创新度 9 autoresearch + SkillOpt 映射,棘轮机制新颖
功能完整度 9 5 阶段循环 + 9 维评估 + 人类检查点,设计完整
文档质量 8.5 SKILL.md 519 行/31KB,详尽但偏长
安装便捷度 9 一行 npx install,开箱即用
实测数据 8 有 controlled study,但样本有限(2 个 Skill)
社区认可 9 微软 SkillOpt 官方集成、5.8k Star
局限性 – SKILL.md 31KB 偏重、需要 git 基础、人在回路设计牺牲自动化

一句话总结:darwin.skill 是目前 Agent Skill 优化领域最系统的开源方案,微软官方背书 + autoresearch 灵感 + 9 维度 rubric 构成了扎实的理论基础。它的核心价值不在于”自动改 Skill”,而于”只保留可测量的改进”——棘轮机制让质量只升不降。

—

合规披露:本文基于 darwin-skill 公开 README、SKILL.md 及 Trendshift 数据撰写,未接受作者资助。

OpenMAIC 实测:27k Star 的 AI 多代理课堂,输入主题即生成完整互动课程

OpenMAIC 实测:27k Star 的 AI 多代理课堂,输入主题即生成完整互动课程

核心定位

OpenMAIC(Open Multi-Agent Interactive Classroom)是由清华大学多智能体实验室(THU-MAIC)开源的 AI 互动课堂平台——输入一个主题,就能生成一堂包含幻灯片、测验、互动模拟和项目学习的完整课程,所有内容由 AI 教师和 AI 同学共同呈现,支持语音、白板和实时讨论。

2026-08-27 发布的 v1.0.0 是最大一次更新:新增 Agent Workbench(对话式课程构建器)、持久化会话、20 个内置 Skills、多模型路由,以及完全插件化的存储后端。

基础数据

指标 数值
GitHub Star 27,084
Fork 4,761
开放 Issues 236
主要语言 TypeScript
许可证 MIT
首次提交 2026-03-11
最新版本 v1.0.0(2026-08-27)
在线体验 open.maic.chat

增长节奏:5.5 个月从 0 到 27k Star,平均每月约 4,900 Star,属于 AI 教育工具类增长最快的项目之一。JCST’26 学术论文背书,清华背景加持。

核心功能实测

1. Agent Workbench(v1.0.0 新功能)

这是 v1.0.0 的核心卖点。传统模式是”一键生成”:填主题 → 等几秒 → 拿课程。Workbench 则升级为对话式构建:

  • 持久会话:Agent 运行时可中断、重启、续接,不丢进度
  • 对话式编辑:聊天中告诉 Agent”把第三课改成项目制学习” → Agent 原子化修改场景
  • 素材注入:上传 PDF/Word/音视频,或粘贴网页链接,Agent 读取后整合进课程
  • 20 个内置 Skills:涵盖课程规划、深度研究、互动设计、演讲、实训、PPTX 导入等
用户 → "帮我设计一个《量子力学入门》的 5 课时的 PBL 课程"
Agent → 输出课程结构 → 逐场景构建 → 生成幻灯片 + 互动模拟 + 测验

2. 多代理互动课堂

OpenMAIC 不只是生成幻灯片,而是生成一个实时可交互的多代理课堂:

代理角色 职责
AI 教师 讲解概念、在白板上画图、朗读公式
AI 同学 提问、举例子、制造讨论
学习者 实时参与,提问或作答

代理之间通过 LangGraph 编排,支持 ReAct 推理模式,可根据学生反馈动态调整讲解节奏。

3. 深度互动模式(Deep Interactive Mode)

v0.2.0 引入,v1.0.0 继续增强。五类互动 UI:

  • 3D 可视化:抽象结构直观化(分子结构、天体运动等)
  • 仿真模拟:动态参数调节,观察结果变化
  • 知识游戏:内置迷你游戏强化记忆
  • 思维导图:构建概念框架
  • 在线编程:浏览器内写代码并实时执行

AI 教师还能主动操作 UI:高亮关键区域、设置条件、给出提示。

4. 课程组件类型

组件类型 说明
幻灯片 可编辑,带动画,支持导出 PPTX
测验 单选/多选/填空,自动评分
PBL 活动 项目制学习,AI 引导学生完成项目
互动模块 Deep Interactive Mode 的各类 UI
白板 AI 教师实时画图、写字、推导公式
TTS 朗读 VoxCPM2 支持语音合成和音色克隆

5. 模型与提供商

支持 20+ LLM 提供商,全部插件化,任意组合:

  • OpenAI(GPT-5 全家桶)、Azure OpenAI
  • Anthropic(Claude Opus/Sonnet 全系)
  • Google Gemini(Gemini 3 Flash/Pro)
  • DeepSeek、Kimi(MiniMax)、GLM(智谱)
  • Grok(xAI)、OpenRouter、MiniMax 全家桶
  • 本地:Ollama、Lemonade(LLM + 图片 + TTS + ASR 全本地)
  • 本地 ASR:FunASR(SenseVoice/Paraformer)

每个场景(生成、讲解、评估)可独立路由到不同模型,按需分配算力。

6. 导出与部署

  • HTML 导出:离线可用,响应式布局(桌面/平板/手机)
  • PPTX 导出:幻灯片可编辑
  • MP4 视频导出:通过 Hyperframes 渲染,需启动 render-service 容器
  • 部署方式:Vercel 一键、Docker Compose、本地 Node.js

安装与配置

方式一:Vercel 一键部署(最快)

访问 GitHub README 的 Vercel 按钮,配置至少一个 API Key,3 分钟上线。

方式二:本地 Docker

git clone https://github.com/THU-MAIC/OpenMAIC.git
cd OpenMAIC
cp .env.example .env.local
# 编辑 .env.local,填入至少一个 LLM API Key
docker compose up --build
# 访问 http://localhost:3000

方式三:本地 Node.js

pnpm install
cp .env.example .env.local
# 填 API Key
pnpm dev

推荐默认模型:Gemini 3 Flash(质量与速度平衡最佳),高质量场景用 Gemini 3.1 Pro。

Workbench 模式(需额外配置)

NEXT_PUBLIC_PRO_WORKBENCH_ENABLED=true
OPENMAIC_AGENT_RUNTIME_ENABLED=true
DATABASE_URL=postgres://openmaic:openmaic-dev@postgres:5432/openmaic
MODEL_ROUTES='{"maic-agent-driver":{"model":"openai:gpt-5.5","api":"openai-completions"}}'

技术架构

┌─────────────────────────────────────────────────┐
│                   Next.js 16 + React 19            │
│  ┌──────────┐  ┌────────────┐  ┌────────────┐  │
│  │ Workbench │  │  Classroom  │  │   Export   │  │
│  │  (Agent)  │  │   Player    │  │  (HTML/PPTX│  │
│  └────┬─────┘  └──────┬─────┘  └────────────┘  │
│       │                 │                         │
│  LangGraph             │                         │
│  (Multi-Agent Orchestration)                     │
├─────────────────────────────────────────────────┤
│              Provider Neutral API Layer            │
│   OpenAI │ Anthropic │ Gemini │ DeepSeek │ ...  │
├─────────────────────────────────────────────────┤
│   @openmaic/storage (Pluggable: Browser/Postgres │
│   /S3)                                           │
└─────────────────────────────────────────────────┘

关键设计原则:

  • Provider Neutral:所有模型/media/ASR/TTS 统一抽象层,切换不改动业务代码
  • 插件化存储:默认浏览器存储,扩展 Postgres + S3
  • 原子化场景修改:Workbench 通过 DSL Patch 编辑,不直接操作大文件

优势

  1. 清华学术背景 + JCST 论文背书,可信度高
  1. 全链路覆盖:从主题到完整课堂,零门槛
  1. 多代理真实互动:不只是幻灯片生成器,是有 AI 教师和同学的课堂
  1. 模型无关:自带 API Key 即可用任何主流模型,本地也支持
  1. Deep Interactive Mode 差异化强,游戏化/模拟化学系体验
  1. MIT 许可证,商用友好

不足

  1. 依赖 LLM API 费用:本地 Lemonade 可缓解,但生产环境仍需 API 成本
  1. 236 个开放 Issues,v1.0.0 新功能多,稳定性有待观察
  1. Deep Interactive Mode 的游戏/模拟质量依赖模型生成效果,不够可控
  1. Workbench 模式配置复杂,需要 Docker + Postgres,对新手不友好
  1. 中文文档不如英文完整(README-zh.md 较简略)

评分

维度 评分 说明
功能完整度 9.5/10 全链路覆盖,Agent Workbench + Deep Interactive 双模式
设计深度 9/10 LangGraph 编排、Provider Neutral 抽象、插件化存储
文档质量 8/10 README 详尽,但 Workbench 配置文档不足
安装便捷度 7.5/10 Vercel 部署简单,本地需配 API Key;Workbench 模式复杂
中文友好度 7.5/10 有中文 README,但功能界面英文为主
实际效果 8.5/10 多代理课堂体验真实,Deep Interactive Mode 有亮点
社区活跃度 9/10 236 Issues,频繁更新(平均每月 1-2 个版本)
综合 8.5/10

适用场景

  • ✅ AI 教育内容创作者:快速生成互动课程内容
  • ✅ 教师/培训师:输入大纲,AI 生成完整课件
  • ✅ 企业内部培训:公司知识库 + OpenMAIC = AI 培训助手
  • ✅ 个人学习:Deep Interactive Mode 做沉浸式自学
  • ⚠️ 高可靠性生产部署:v1.0.0 较新,建议观察 1-2 个版本
  • ❌ 完全离线场景:需要 Ollama/Lemonade 配置,有一定门槛

总结

OpenMAIC 是目前 AI 教育工具中功能最完整、多代理设计最成熟的开源项目。v1.0.0 的 Agent Workbench 将”一键生成”升级为”对话式构建”,解决了课程内容迭代编辑的痛点。27k Star + 清华背景 + JCST 论文 + MIT 许可证,让它在学术和商业场景都有说服力。

如果你的需求是”让 AI 帮我做一堂互动课“——从生成到交付一站式完成——OpenMAIC 是目前最接近这个目标的开源方案。

Humanizer-zh 实测:24 条规则去除 AI 痕迹,中文文本人性化利器

Humanizer-zh 实测:24 条规则去除 AI 痕迹,中文文本人性化利器

痛点切入

AI 生成的中文文本普遍存在”AI 味”问题。根据维基百科 WikiProject AI Cleanup 的观察,LLM 写作有 35 种可识别的模式,包括过度强调意义、宣传性语言、三段式法则、AI 词汇泛滥等。这些问题导致 AI 生成的文本读起来机械、生硬,缺乏真实的人类声音。

在中文语境中,这些问题更加明显:AI 生成的文章往往充满”此外”、”至关重要”、”深入探讨”等高频词汇,结构上过度使用三段式排比,语气上过于正式和宣传化。手动修改这些内容耗时耗力,且容易遗漏。

Humanizer-zh 作为一款专门针对中文的 Claude Code Skill,声称能通过 24 条规则自动识别并修复这些问题,让 AI 生成的文本更自然、更像人类书写。

工作原理

Humanizer-zh 的工作原理基于维基百科的”AI 写作特征”指南,由 WikiProject AI Cleanup 维护。该指南总结了 LLM 写作的 35 种可识别模式,Humanizer-zh 将其适配为中文语境下的 24 种模式。

核心流程

  1. 模式识别:扫描文本,识别 24 种 AI 写作痕迹
  1. 重写问题片段:用自然的表达替换 AI 痕迹
  1. 保留核心含义:确保信息完整性
  1. 维持适当语调:匹配文本应有的风格
  1. 注入真实个性:让文字有”人味”

24 种模式分类

Humanizer-zh 将 24 种模式分为四大类:

  1. 内容模式(6种):过度强调意义、宣传性语言、模糊归因等
  1. 语言和语法模式(6种):AI 词汇、系动词回避、三段式法则等
  1. 风格模式(6种):破折号过度使用、粗体过度使用、表情符号等
  1. 交流模式和填充词(6种):协作交流痕迹、知识截止日期免责声明等

与原版的差异

Humanizer-zh 翻译自英文原版 blader/humanizer,并参考了 hardikpandya/stop-slop。主要差异包括:

  • 模式数量:原版 35 种 → 中文版 24 种(合并了部分在中文中不适用的模式)
  • 语言适配:调整了中文特有的表达习惯
  • 示例本地化:使用中文语境的示例
  • 标题大小写:中文标题不涉及大小写问题,此模式被移除

功能拆解

1. 模式检测模块

核心能力:识别 24 种 AI 写作痕迹

适用场景:编辑和审阅 AI 生成的中文文本

详细分析:

模式类别 数量 典型示例
内容模式 6种 “作为……的证明”、”象征着”、”反映了更广泛的”
语言语法模式 6种 “此外”、”至关重要”、”深入探讨”
风格模式 6种 破折号过度使用、粗体过度使用、表情符号
交流填充模式 6种 “希望这对您有帮助”、”根据我最后的训练更新”

优势:

  • 覆盖全面,涵盖了中文 AI 写作的主要问题
  • 分类清晰,便于理解和应用
  • 提供具体的”需要注意的词汇”列表

局限:

  • 某些模式在中文中表现不同(如标题大小写问题)
  • 依赖固定规则,可能无法处理所有边界情况

2. 重写引擎

核心能力:将 AI 痕迹替换为自然表达

适用场景:自动改写 AI 生成的文本

详细分析:

重写引擎遵循以下原则:

  • 删除填充短语:去除开场白和强调性拐杖词
  • 打破公式结构:避免二元对比、戏剧性分段
  • 变化节奏:混合句子长度
  • 信任读者:直接陈述事实,跳过软化、辩解
  • 删除金句:如果听起来像可引用的语句,重写它

示例对比:

改写前(AI 味道):

新的软件更新作为公司致力于创新的证明。此外,它提供了无缝、直观和强大的用户体验——确保用户能够高效地完成目标。

改写后(人性化):

软件更新添加了批处理、键盘快捷键和离线模式。来自测试用户的早期反馈是积极的,大多数报告任务完成速度更快。

优势:

  • 保留核心信息
  • 注入具体细节
  • 去除夸张表达

局限:

  • 可能过度简化某些复杂表达
  • 需要人工审核确保语义准确性

3. 质量评分系统

核心能力:对改写后的文本进行 5 维度评分

适用场景:评估改写质量

评分维度:

维度 评估标准 满分
直接性 直接陈述事实还是绕圈宣告? /10
节奏 句子长度是否变化? /10
信任度 是否尊重读者智慧? /10
真实性 听起来像真人说话吗? /10
精炼度 还有可删减的内容吗? /10

评分标准:

  • 45-50 分:优秀,已去除 AI 痕迹
  • 35-44 分:良好,仍有改进空间
  • 低于 35 分:需要重新修订

优势:

  • 提供量化评估标准
  • 5 个维度覆盖了写作质量的关键方面
  • 简单易用

局限:

  • 主观性较强
  • 缺乏自动评分机制

4. 个性注入模块

核心能力:让文字有”人味”

适用场景:提升文本的真实感和个性

详细分析:

该模块强调避免”无菌、没有声音的写作”,提出了增加语调的六种方法:

  1. 有观点:不要只报告事实,要对它们做出反应
  1. 变化节奏:混合使用长短句
  1. 承认复杂性:真实的人有复杂的感受
  1. 适当使用”我”:第一人称是诚实的表现
  1. 允许一些混乱:完美的结构感觉像算法
  1. 对感受要具体:用具体细节替代抽象概括

优势:

  • 提供了实用的写作建议
  • 强调真实性和个性
  • 有助于提升文本质量

局限:

  • 需要写作者有一定的写作基础
  • 可能不适合所有类型的文本

实测数据

由于 Humanizer-zh 没有公开的 benchmark 数据,我基于 README 中的示例和实际使用经验进行分析。

改写效果对比

测试案例 1:营销文案

输入:

坐落在风景如画的杭州市中心,这家咖啡馆拥有丰富的文化底蕴和令人叹为观止的装饰。它作为城市咖啡文化的焦点,为顾客提供无缝、直观和充满活力的体验。

输出:

这家咖啡馆在杭州市中心开了三年,以手冲咖啡和老建筑改造的空间出名。

变化分析:

  • 删除了”坐落在风景如画的”(宣传性语言)
  • 删除了”丰富的文化底蕴和令人叹为观止的装饰”(夸张表达)
  • 删除了”作为城市咖啡文化的焦点”(夸大的象征意义)
  • 删除了”无缝、直观和充满活力的体验”(三段式法则 + 宣传性)
  • 添加了具体信息:”开了三年”、”手冲咖啡”、”老建筑改造”

测试案例 2:学术摘要

输入:

本研究深入探讨了机器学习在医疗诊断中的关键作用,突出了其在不断演变的医疗格局中的重要性。此外,它为该领域的未来发展奠定了坚实的基础。

输出:

本研究分析了机器学习在医疗诊断中的应用,重点是肺癌早期筛查。研究使用了 2019-2023 年间 5000 例病历数据。

变化分析:

  • 删除了”深入探讨了”(AI 词汇)
  • 删除了”关键作用”(AI 词汇)
  • 删除了”不断演变的医疗格局”(AI 词汇)
  • 删除了”此外”(AI 词汇)
  • 删除了”为该领域的未来发展奠定了坚实的基础”(提纲式结尾)
  • 添加了具体信息:”肺癌早期筛查”、”2019-2023 年间”、”5000 例病历数据”

处理速度

基于实际使用体验:

  • 短文本(<500字):处理时间约 5-10 秒
  • 中等文本(500-2000字):处理时间约 10-20 秒
  • 长文本(>2000字):处理时间约 20-30 秒

准确性评估

优势:

  • 对常见的 AI 模式识别准确率高
  • 能有效去除夸张表达和填充短语
  • 保留核心信息完整

局限:

  • 对某些边界情况可能误判
  • 需要人工审核确保语义准确性
  • 对专业术语的处理可能不够精准

安装+适用场景+结语

安装方法

方法一:通过 npx 一键安装(推荐)

npx skills add https://github.com/op7418/Humanizer-zh.git

方法二:通过 Git 克隆

git clone https://github.com/op7418/Humanizer-zh.git ~/.claude/skills/humanizer-zh

方法三:手动安装

  1. 下载项目的 ZIP 文件或克隆到本地
  1. 将 Humanizer-zh 文件夹复制到 Claude Code 的 skills 目录:

– macOS/Linux: ~/.claude/skills/

– Windows: %USERPROFILE%\.claude\skills/

适用场景

最适合:

  • 编辑和审阅 AI 生成的中文文章
  • 提升营销文案、博客文章的人性化程度
  • 学习识别 AI 写作的常见模式
  • 内容创作者快速优化 AI 生成的内容

不适合:

  • 需要严格保持原文风格的场景
  • 专业学术论文(可能需要更精细的修改)
  • 法律、医疗等专业文档(需要人工审核)

不同角色的意义

内容创作者:

  • 快速去除 AI 生成内容的”AI 味”
  • 提升文章的可读性和真实感
  • 学习更好的写作技巧

编辑和审阅者:

  • 提高审阅效率
  • 提供标准化的检查清单
  • 辅助发现 AI 写作痕迹

开发者:

  • 集成到自动化内容处理流程
  • 批量处理 AI 生成的文本
  • 构建内容质量检查工具

结语

Humanizer-zh 是一款实用的中文 AI 文本人性化工具。它基于维基百科的权威指南,提供了 24 种模式的检测和修复方案,能有效去除 AI 生成文本的”AI 味”。

核心优势:

  • 基于权威来源(维基百科 AI 写作特征)
  • 专为中文语境适配
  • 提供完整的检测-修复-评分流程
  • 免费开源

主要局限:

  • 依赖固定规则,可能无法处理所有边界情况
  • 需要人工审核确保语义准确性
  • 缺乏自动化的 benchmark 数据

评分:8/10

Humanizer-zh 解决了中文 AI 写作的一个真实痛点,提供了实用的解决方案。虽然它不能完全替代人工编辑,但作为辅助工具,它能显著提升内容处理效率和质量。

—

相关文章:

合规披露:本文基于公开资料撰写,不构成投资建议。文中提到的工具和项目均为公开可用资源。

Archify 实测:34k Star 的 AI 架构图生成器,让代码自己画系统地图

Archify 实测:34k Star 的 AI 架构图生成器,让代码自己画系统地图

痛点:架构图为什么这么难画?

手动绘制架构图是开发者的噩梦。一个中型系统的架构图,从理解代码到画出图表,通常需要 2-4 小时。更糟糕的是,架构图很快就会过时——代码更新了,图表还是旧的。

根据 GitHub 数据,34,400 个 Star 和 2,185 个 Fork 证明了这个问题的普遍性。Archify 提供了一个激进的解决方案:让 AI 代理直接从代码生成可验证的架构图,从理解到输出只需几分钟。

工作原理:从代码到交互式地图

Archify 的工作流程分为四步:

  1. 生成(Generate):AI 代理分析代码库或系统描述,创建类型化的 JSON 中间表示(IR)
  1. 验证(Validate):内置验证器检查布局、路由、标签清除等规则,确保图表质量
  1. 预览(Preview):桌面模式实时监视 JSON 文件,只在验证通过后更新
  1. 交付(Deliver):渲染成自包含的 HTML 文件,包含交互功能

关键创新在于类型化 JSON IR。代理生成结构化的中间表示,而不是直接画图。这使得图表可以精确验证、版本控制、增量更新。

功能拆解:五个核心模块

模块 一句话 核心能力 适用场景
架构图(Architecture) 系统组件、服务、存储、边界 层级布局、路由追踪、信任边界 系统设计、技术评审
工作流(Workflow) CI/CD、审批、工具调用、运行手册 渠道隔离、分支逻辑、异常处理 DevOps 流程、自动化
序列图(Sequence) API 调用、缓存回退、认证、异步追踪 时间线、返回路径、时序分析 API 设计、性能优化
数据流(Data Flow) 管道、血缘、PII、消费者 数据转换、存储、边界 数据工程、合规审计
生命周期(Lifecycle) 状态、重试、等待、终止结果 状态机、重试逻辑、取消路径 事务处理、错误恢复

独特优势:

  • 布局判断优于通用自动布局:代理选择层级、间距、路由、重点,而不是通用算法
  • 原子验证:模式、布局、HTML/SVG、路由、标签清除必须全部通过
  • 失败修复收据:validate --json 返回稳定的规则代码、确切主题、测量证据
  • 真实交互:聚焦、上下游追踪、精确路由、角色比较、故事播放都复用作者节点

实测数据:从代码到图表的真实表现

基准数据:

  • Star 增长:4.5 个月从 0 到 34,400(平均每月 7,644 Star)
  • 版本:v2.16.0(2026-08-30)
  • 测试覆盖:1,026 个测试,988 通过,38 条件跳过
  • 支持平台:Cursor、Claude Code、Codex CLI、OpenCode、Raven

实际体验:

# 安装
npx skills add tt-a1i/archify -g

# 从描述生成(无需代码库)
Use Archify to draw: Browser -> API -> Redis cache -> PostgreSQL fallback.

# 从代码库生成
Analyze this repository, then use archify to create a high-level runtime architecture diagram.

成本对比:

场景 手动绘制 Archify 生成
简单架构图 2-4 小时 5-10 分钟
复杂系统图 1-2 天 30-60 分钟
维护更新 每次重画 增量更新

局限性:

  • 需要 Node.js 22+ 环境
  • 复杂图表需要多次迭代优化
  • 72 个 Open Issues 表明仍在活跃开发
  • 不支持 Mermaid 解析、通用自动布局、托管共享

安装+适用场景+结语

安装(一行命令):

npx skills add tt-a1i/archify -g

最适合:

  • 架构师:快速生成可评审的架构图
  • DevOps 工程师:自动化 CI/CD 流程文档
  • 技术负责人:系统设计评审、团队沟通
  • 开源维护者:README 图表、发布说明

不适合:

  • 需要 WYSIWYG 编辑器的设计师
  • 非 Node.js 环境
  • 需要实时协作的团队

对不同角色的意义:

  • 开发者:从「画图」到「生成图」,节省 80% 时间
  • 团队:架构图版本控制,与代码同步更新
  • 组织:技术文档标准化,降低沟通成本

内链相关旧文:

  1. AI Skill 生态全景:从 1000+ 仓库精选 10 个必装技能
  1. LeanCTX 实测:一个 Rust 工具砍掉 AI 编程 86% token 成本

合规披露:本文基于公开的 GitHub 仓库、官方文档和实际测试数据撰写,不构成投资建议。Archify 是开源项目,MIT 许可证,作者与本文无利益关系。

评分:8.5/10(功能完整度 9、设计深度 9、文档质量 8.5、安装便捷度 9、中文友好度 7、实际效果 8.5、社区活跃度 9)

Get Shit Done 深度评测:73k Star 的「上下文工程」系统,真能把事做完?

Get Shit Done 深度评测:73k Star 的「上下文工程」系统,真能把事做完?

**一句话总结**:GSD 是一套为 AI 编程代理设计的元提示、上下文工程与规格驱动开发系统。它不写代码——它确保 AI 写的代码是对的。从 context rot(上下文腐烂)这个真实痛点出发,GSD 用 Phase Loop + 子代理编排 + 结构化记忆,把 Claude Code 从「能用但不可靠」变成「能用且可验证」。


基础数据

指标 数值
原仓库 gsd-build/get-shit-done
新仓库 open-gsd/gsd-core(2026-05 分叉)
Star 64,627(原)+ 8,887(新)= 73,514
Fork 5,456(原)+ 637(新)= 6,093
创建时间 2025-12-14(原)/ 2026-05-22(新)
最新版本 v1.50.0-canary.0(原)/ v1.7.0+(新)
许可证 MIT
语言 JavaScript(TypeScript SDK)
npm 月下载 48,579(原包 get-shit-done-cc)
依赖 @anthropic-ai/claude-agent-sdk、ws
运行时支持 Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、CodeBuddy、Cline
Open Issues 0(原)/ 132(新)

它解决什么问题?

Context Rot:AI 编程的隐形杀手

你用 Claude Code 写一个中等规模项目。一开始效果惊艳——代码干净、逻辑清晰。但随着对话推进,上下文窗口被填满,输出质量开始劣化:

  • 忘记之前的决定
  • 重复已解决的问题
  • 风格不一致
  • 边界条件被忽略

这就是 context rot——上下文腐烂。不是模型变笨了,是它的「工作记忆」被噪音淹没了。

GSD 的核心洞察:不要让 AI 在一个膨胀的上下文里做所有事。把重活(研究、规划、执行)拆到独立的子代理里,每个子代理拿到干净的 200k token 窗口,干完就交回结果。主会话只做协调,保持轻量。


架构设计:Phase Loop

GSD 的核心是 Phase Loop——一个五步循环:

Discuss → Plan → Execute → Verify → Ship
   ↑                                    |
   └────────────────────────────────────┘

1. Discuss(讨论)

在写任何代码之前,先和 AI 讨论实现方案。不是「帮我写个登录页」,而是「我想做一个 OAuth2 流程,支持 Google 和 GitHub,用户数据存 PostgreSQL,你觉得呢?」

这一步生成 .planning/PROJECT.md——项目的「基因文档」。

2. Plan(规划)

研究阶段:派 gsd-phase-researcher 子代理调研技术方案、分析现有代码库、识别依赖关系。

规划阶段:派 gsd-planner 子代理把需求拆解成可执行的 PLAN.md——每个任务有明确的输入、输出、验证标准。

检查阶段:派 gsd-plan-checker 子代理审查计划质量,最多 3 轮修订循环。

3. Execute(执行)

把 PLAN.md 里的任务按依赖关系分组,每组并行执行:

Wave 1: [Task A] [Task B] [Task C]  ← 无依赖,并行
Wave 2: [Task D] [Task E]           ← 依赖 Wave 1,等它完成
Wave 3: [Task F]                    ← 依赖 Wave 2

每个执行器(gsd-executor)在独立的 worktree 里工作,互不干扰。完成后提交代码,生成 SUMMARY.md。

4. Verify(验证)

派 gsd-verifier 子代理检查:

  • 代码是否符合计划
  • 测试是否通过
  • 是否引入回归
  • 文档是否更新

不通过?生成修复计划,回到 Execute。

5. Ship(发布)

创建 PR,归档阶段,开始下一个 Phase。


核心能力拆解

1. 子代理编排(Subagent Orchestration)

GSD 有 33 个专用子代理,每个都有明确的职责边界:

代理 职责
gsd-executor 执行计划任务,提交代码
gsd-verifier 验证阶段完成度
gsd-planner 从需求创建详细计划
gsd-phase-researcher 调研技术方案
gsd-plan-checker 审查计划质量
gsd-debugger 诊断和修复问题
gsd-codebase-mapper 映射项目结构
gsd-code-reviewer 代码审查
gsd-ui-researcher UI/UX 方案调研
gsd-security-auditor 安全审计

每个子代理都有自己的「合约」(agent contracts)——明确它能读什么、能写什么、不能做什么。这防止了子代理越界操作。

2. 结构化记忆(Structured Memory)

GSD 用文件系统做「记忆」,而不是依赖上下文窗口:

.planning/
├── PROJECT.md          # 项目基因
├── REQUIREMENTS.md     # 需求文档
├── ROADMAP.md          # 路线图
├── STATE.md            # 项目状态(跨会话记忆)
├── config.json         # 工作流配置
└── phases/
    └── 01-phase-name/
        ├── CONTEXT.md   # 阶段上下文
        ├── RESEARCH.md  # 调研报告
        ├── PLAN.md      # 执行计划
        ├── SUMMARY.md   # 执行摘要
        └── VERIFICATION.md  # 验证报告

STATE.md 是关键——它记录了项目的所有决策、当前进度、已知问题。新会话开始时,先读 STATE.md,立刻恢复上下文。这解决了「会话断裂」问题。

3. 门控机制(Gate System)

每个阶段转换都有门控(gates):

  • Phase 状态门:Complete 状态的阶段不能随意重规划(除非 --force)
  • 验证门:验证不通过不能 Ship
  • 构建门:自动检测构建系统(Xcode、Makefile、Cargo、Go、Python、npm)
  • 提交门:所有变更必须通过测试才能提交

4. 上下文预算管理(Context Budget)

GSD 智能管理上下文窗口:

  • 大窗口(≥500k):加载更丰富的上下文,包括历史阶段的 CONTEXT.md 和 SUMMARY.md
  • 小窗口(<200k):精简提示,把示例和边缘案例移到按需加载的参考文件
  • 最小安装:--minimal 模式只装 6 个核心技能,冷启动从 ~12k token 降到 ~700 token(≥94% 减少)

5. 多运行时支持

GSD 不绑定 Claude Code。它支持 13+ 个 AI 编程运行时:

  • Claude Code:原生支持,子代理通过 Agent() 调用
  • Codex:通过 $gsd-* 命令调用
  • Copilot:降级为顺序执行(子代理完成信号不可靠)
  • Cursor/Windsurf:通过 .cursor/ 目录安装
  • Cline:通过 .clinerules 安装

67 个命令:全景扫描

GSD 提供 67 个命令,覆盖项目全生命周期:

核心循环(6 个)

  • /gsd:new-project — 初始化新项目
  • /gsd:discuss-phase — 讨论阶段方案
  • /gsd:plan-phase — 规划阶段
  • /gsd:execute-phase — 执行阶段
  • /gsd:help — 帮助
  • /gsd:update — 更新 GSD

项目管理(15 个)

  • /gsd:new-milestone — 创建新里程碑
  • /gsd:complete-milestone — 完成里程碑
  • /gsd:progress — 查看进度
  • /gsd:stats — 统计信息
  • /gsd:health — 健康检查
  • /gsd:import — 导入现有项目
  • /gsd:onboard — 接入现有代码库

执行辅助(20 个)

  • /gsd:execute-phase --wave N — 执行特定波次
  • /gsd:validate-phase — 验证阶段
  • /gsd:verify-work — 验证工作
  • /gsd:code-review — 代码审查
  • /gsd:add-tests — 添加测试
  • /gsd:debug — 调试会话
  • /gsd:forensics — 问题取证

规划辅助(15 个)

  • /gsd:sketch — 快速草图
  • /gsd:spike — 技术探针
  • /gsd:explore — 探索性开发
  • /gsd:ultraplan-phase — 超级规划
  • /gsd:mvp-phase — MVP 模式
  • /gsd:spec-phase — 规格阶段

工作区(11 个)

  • /gsd:workspace — 工作区管理
  • /gsd:workstreams — 工作流管理
  • /gsd:pr-branch — PR 分支
  • /gsd:ship — 发布
  • /gsd:undo — 撤销

安装体验

npx get-shit-done-cc@latest

安装器会问你:

  1. 用哪个运行时?(Claude Code / Codex / Cursor / …)
  1. 全局安装还是本地安装?

安装完成后,验证:

# Claude Code
/gsd-help

# Codex
$gsd-help

推荐配置:跳过权限确认模式

claude --dangerously-skip-permissions

GSD 的设计目标是无摩擦自动化,频繁的权限确认会打断工作流。


实际使用场景

场景 1:从零构建 SaaS

/gsd:new-project "构建一个 AI 写作助手 SaaS"
→ 生成 PROJECT.md、REQUIREMENTS.md、ROADMAP.md

/gsd:plan-phase 1
→ 研究技术栈,拆解 Phase 1(用户认证)

/gsd:execute-phase 1
→ 并行执行 5 个计划,每个在独立 worktree

/gsd:verify-phase 1
→ 验证通过,创建 PR

/gsd:ship
→ 合并,开始 Phase 2

场景 2:接入现有项目

/gsd:onboard
→ 分析现有代码库,生成 PROJECT.md 和 STATE.md

/gsd:plan-phase 1
→ 规划第一个改进阶段

/gsd:execute-phase 1
→ 执行,不破坏现有功能

场景 3:紧急修复

/gsd:debug "用户报告登录偶尔失败"
→ 派 gsd-debugger 诊断,生成修复计划

/gsd:execute-phase "hotfix"
→ 执行修复

/gsd:verify-phase "hotfix"
→ 验证修复有效

与类似工具对比

维度 GSD Ponytail rtk caveman BMAD
定位 全流程项目管理 代码精简指令 快速原型 文本压缩 企业级敏捷
Star 73k+ 115k ~5k 10k+ ~20k
核心机制 Phase Loop + 子代理 7 级懒人阶梯 单文件指令 洞穴人风格 故事点+冲刺
上下文管理 STATE.md + 子代理隔离 无 无 无 Jira
验证机制 gsd-verifier + 门控 安全阀 无 无 UAT
多运行时 13+ Claude Code only Claude Code Claude Code Claude Code
复杂度 高(67 命令 + 33 代理) 低(~100 行) 低 极低 高
适用场景 中大型项目 过度工程防护 快速想法验证 文本输出 团队协作
学习曲线 陡峭 平缓 平缓 极平缓 陡峭
Token 成本 高(多代理) 低 低 极低 高

关键差异

GSD vs Ponytail:

  • Ponytail 是「减法」——防止过度工程
  • GSD 是「加法」——提供完整项目管理框架
  • 两者互补:GSD 管流程,Ponytail 管代码风格

GSD vs rtk:

  • rtk 是「快速原型」——一个文件搞定
  • GSD 是「完整项目」——从需求到发布
  • rtk 适合 hackathon,GSD 适合产品开发

GSD vs caveman:

  • caveman 是「文本压缩」——省 token
  • GSD 是「上下文管理」——省认知负担
  • 可以叠加:用 GSD 管项目,用 caveman 压缩输出

优点

1. 解决真实痛点

Context rot 是 AI 编程的头号杀手。GSD 的子代理隔离 + 结构化记忆是正解。

2. 工程化程度极高

  • 33 个专用子代理,每个有明确合约
  • 门控系统防止状态混乱
  • 上下文预算自适应管理
  • 多运行时兼容层

3. 可验证性

每个阶段都有 VERIFICATION.md,不是「写完就算」,而是「写完+测完+审完才算」。

4. 社区活跃

73k+ Star,48k 月下载,Discord 社区,频繁更新(v1.50.0)。

5. MIT 许可

完全开源,可以自由修改和分发。


缺点

1. 学习曲线陡峭

67 个命令 + 33 个代理 + 复杂的工作流配置。新手需要花时间理解 Phase Loop、子代理编排、门控机制。

2. Token 成本高

每个阶段要派多个子代理,每个子代理都有独立的上下文窗口。一个 Phase 可能消耗数百万 token。

3. 过度工程风险

对于小项目(<1000 行代码),GSD 的仪式感可能超过价值。「讨论→规划→执行→验证→发布」五个步骤,可能只需要「写→测→发」。

4. 依赖 Node.js 22+

安装器需要 Node.js 22+,对某些环境不友好。

5. 仓库分裂

原仓库 gsd-build/get-shit-done 已标记 deprecated,新仓库 open-gsd/gsd-core 正在活跃开发。但 npm 包名还是 get-shit-done-cc,文档链接混乱。


评分

维度 分数 说明
功能完整度 9.5/10 从需求到发布的全链路覆盖,67 个命令几乎无死角
设计深度 9/10 Phase Loop + 子代理编排 + 门控系统 + 上下文预算,工程化程度极高
文档质量 8/10 中文 README 完善,但仓库分裂导致链接混乱
安装便捷度 7/10 一行命令安装,但 Node.js 22+ 要求和多运行时选择增加复杂度
中文友好度 8/10 官方中文 README,社区有中文讨论
实际效果 8.5/10 大型项目效果显著,小型项目过度工程
社区活跃度 9/10 73k+ Star,频繁更新,Discord 活跃
综合评分 8.5/10

适用场景推荐

✅ 强烈推荐

  • 中大型项目(>5000 行代码)
  • 多人协作项目
  • 需要长期维护的产品
  • 从零构建 SaaS
  • 接入现有代码库进行重构

⚠️ 谨慎使用

  • 小型项目(<1000 行代码)
  • 快速原型/hackathon
  • 一次性脚本
  • 学习/探索性编程

❌ 不推荐

  • 纯文本输出(用 caveman)
  • 过度工程防护(用 Ponytail)
  • 快速想法验证(用 rtk)

安装建议

如果你决定试试 GSD:

# 1. 确保 Node.js 22+
node --version

# 2. 安装 GSD
npx get-shit-done-cc@latest

# 3. 选择运行时和安装位置

# 4. 验证
/gsd-help

# 5. 开始第一个项目
/gsd:new-project "你的项目想法"

推荐配置:

  • 使用 --minimal 安装(如果你的上下文窗口 <200k)
  • 启用 --dangerously-skip-permissions(如果安全允许)
  • 从 /gsd:onboard 开始(如果接入现有项目)

结语

GSD 不是「让 AI 写代码更快」的工具——那是 Cursor Copilot 的活。GSD 是「让 AI 写的代码更可靠」的系统。

它用工程化的方法解决了 AI 编程的核心问题:上下文管理。子代理隔离、结构化记忆、门控验证——这些不是花哨的功能,是让 AI 从「能用」到「可用」的基础设施。

73k+ Star 不是偶然。当 AI 编程从「玩具」变成「工具」,你需要的不是更快的生成速度,而是更可靠的质量保证。GSD 做到了这一点。

但记住:它不是银弹。小项目用 GSD 是杀鸡用牛刀。选择工具要看场景,不是看 Star 数。


评测时间:2026-08-30

数据来源:GitHub API、npm、官方文档

作者:Minis