honey-for-devs

一、场景切入

你的团队用 AI 编码 Agent 干了三个月，月底一看账单——Token 消耗是预期的好几倍。开发同事说「模型就这么贵」，但真实原因往往是另一回事：Agent 输出了大量它自己都说「其实可以不写」的代码，附上一大段解释为什么这么写，然后把这堆东西原封不动塞进下一个 Agent 的上下文里。上下文每轮膨胀，输入 Token 成本呈指数上升。

Green-PT/honey-for-devs 要做的事就一句话：让 AI 少写字，而且不损失质量。

二、背景科普

该项目由 GreenPT 组织于 2026 年 6 月发布，采用 MIT 许可，341 星、22 fork。定位是「跨工具编码 Skill」——同一套规则同时适配 Claude（claude.ai 与 API）、Claude Code、Cursor、GitHub Copilot、Codex、Gemini CLI、Windsurf、Cline、OpenClaw、oh-my-pi、Kiro、Kilo Code、Hermes Agent、Kimi Code、Devin CLI、Grok Build、Qoder、Antigravity、CodeBuddy 等几乎所有主流编码 Agent。

它的直接灵感来自两个已有项目：Ponytail（最小化代码）和 Caveman（简洁措辞）。Honey 的做法是把两者合并并再往前走一步——不只压代码，也压散文，还专门优化「Agent 对 Agent」之间的交接格式。

三、类比解释

如果 Agent 写作风格是一场会议，通用 Agent 是那种「把所有想到的都倒出来」的同事——先复述一遍需求，再讲三种备选方案，再解释原理，最后才给结论。Honey 是那个「先给结论，细节我问你再补」的同事。区别不在能力，在表达密度。

四、核心功能

• 三个压缩杠杆，反射式触发：一是少写代码——走 YAGNI 阶梯（这东西需要存在吗 → 标准库 → 语言原生 → 现有依赖 → 一行 → 最小块），在第一个能用的层级就停；二是少写废话——砍掉铺垫、模糊限定词和对自明代码的解说，先给答案；三是更高密度的 Agent 间交接——当读者是另一个 Agent 而非人类时，用最省 Token 且可无损解析的格式（紧凑/列式 JSON，或自研的 ESON 格式）传递，这种优化只在交接场景触发，绝不用作面向用户的答案
• Auto-intensity 三档：lite / full / ultra 由请求本身反射式选择，且不消耗推理 Token 来决定「如何合规」——在推理模型上这本身就是反目标
• 安全豁免清单：输入校验、错误处理、认证、密钥、数据库迁移、删除操作，以及用户明确要求的内容，一律不压缩。Lazy ≠ broken，这是它最重要的设计约束
• 技能家族而非单个提示词：包含常驻核心技能 + 按需卫星技能（review、eco、gain、compress），以及一群只读子 Agent（hive）返回压缩后的交接结果
• 多宿主适配目录：仓库内含 .claude-plugin、.cursor、.codex-plugin、.devin-plugin、.grok-plugin、.kilo、.kimi-plugin、.kiro、.openclaw、.qoder-plugin、.qoder、.windsurf、.hermes、.clinerules、.agents 等十余种宿主的适配配置

五、上手门槛

极低，属于「放进目录就能用」的类型：

git clone https://github.com/Green-PT/honey-for-devs.git

然后按目标宿主把对应配置目录拷到项目或用户级配置路径。仓库提供 INSTALL.md 与各宿主的安装说明。JavaScript 为主要语言（JavaScript/TypeScript），无运行时依赖。

六、争议与局限

• 基准是作者自写的：README 里的关键数字来自 23 个任务 × 3 次运行，而这些任务「均由作者编写」。作者同时是 benchmark 的设计者，这是一个难以回避的效度问题。README 自己也承认「两个任务，所以没有 p 值」
• 评测结果本身显示质量不是提升而是持平：对照 Caveman 和 Ponytail，Honey 的优势主要体现在输出 Token、代码行数与成本，盲评质量判定为「平局」（5/12/4）。它的价值是省钱，不是变聪明
• 压缩有天然边界：项目自己列出豁免清单，安全相关的代码不会被压缩，这意味着在安全敏感场景下收益会显著缩水
• 「少写散文」有副作用：对需要详尽解释的场景（如教学、文档撰写、面向新人的代码讲解），这套规则会显得冷淡甚至答非所问
• ESON 格式的生态封闭性：自研交接格式只有本项目内部理解，跨工具时并未形成标准，实际上仍是私有约定
• 对比数据的绝对值可疑：README 提到 Claude Opus 5.5 等模型，其基准分数与方法未提供完整可复现细节

七、行业意义

这个项目折射出一个正在成为共识的行业转向：从「追求模型能力上限」转向「追求单位任务成本」。当 AI 编码 Agent 深度进入日常开发，Token 成本从「实验费用」变成了「工程成本项」，能压 40% 输出 Token、52% 代码行数、31% 成本的方案，无论质量持平与否都有明确的经济价值。

更值得注意的是它对「Agent 之间的交接」这个方向的关注。随着多 Agent 协作成为主流实践，Agent 与 Agent 之间那段冗长的上下文传递其实是成本黑洞，专门优化这一层的工具目前还很少。

它同时也是多宿主适配策略的一个样本：一个 Skill 想覆盖 17+ 个工具，唯一可行的路径是提供足够薄、足够标准的适配层，而不是每家写一套规则。

MIT 许可、341 星、明确的 benchmark 数据表和诚实的「质量是持平不是更好」表述，让这个项目在 Skill 生态里属于文档质量较高的一类。