我往一个 4187 Star 的开源技能里注入了五处缺陷。三处被测试拦下，两处畅通无阻地通过了全部 1317 条测试。
有意思的是被拦下的和被放行的分别是什么。这个技能叫 answer-me-with-html，干的事很朴素：让 AI 别再甩一大段文字，而是交给你一页能点开看懂的网页。它的安全边界守得极严——内容安全策略（也就是浏览器端「只许加载白名单里的东西」那份禁令）、把网页里混进来的脚本当文本显示、本地服务只认本机域名，这三处我逐个改坏，测试立刻亮红灯。
但它的卖点没人守。我把它的写作文风检查里「英文句子最多 25 个词」改成 250 个词，重新打包，24 条相关测试全部通过；我用一篇 100 个词的长句去喂它，它回一句「0 条警告」。我又把 README 里那个「省 8 倍词元」的基准数字改成 10 倍，全量测试照样不动。
这篇要说的就是这条分界线在哪，以及它意味着什么。
它到底是什么
一句话：模型只写一段简短的 Markdown 草稿，剩下的排版、配色、深色模式、示意图坐标，全由随技能打包的一个命令行程序生成。
数字先摆出来，我逐个核过：
| 项目 | 数值 | 我核对的方式 |
|---|---|---|
| Star / Fork | 4187 / 280 | GitHub 接口，评测当天 |
| 建仓时间 | 2026 年 10 月 2 日 | 距今 19 天 |
| 许可证 | MIT | 仓库根目录 |
| 合并请求 | 210 条 | 搜索接口 |
| 发版 | 17 个，最新 0.5.7 | 发布列表 |
| 未关闭问题 | 3 个 | 接口 |
| 安装体积 | 7.2 MB，其中打包好的可执行脚本 944 KB | 磁盘实测 |
| 运行时要求 | Node.js 20 以上，不需要装任何依赖 | 只拷一个目录就能跑 |
十九天冲到四千多星，节奏很猛。但真正值得说的不是星数，是它对自己设的规矩——这一点决定了后面所有结论。
它有一整套写作纪律，取自航空维修手册那一类的受控英语标准，核心是：一句话说一件事、不写废话开头、不用「进行优化」这类空词、步骤句不超过 20 个词。出稿时程序会逐句扫，超了就报警告。
还有 95% 的测试覆盖率、432 种组合的渲染快照比对、一个「打包文件必须是最新的」的持续集成检查。这套工程习惯在个人项目里相当罕见。
实测：它守住了什么
我在一台单核、2 GB 内存的隔离沙箱里跑完整套流程，命令和结果都留在下面，方便你复现。
| 我跑的东西 | 结果 |
|---|---|
| 全量测试 | 1317 条，1235 通过，1 失败，1 取消，80 跳过 |
| 覆盖率 | 行 95.2%、函数 95.0%、分支 95.4% |
| 432 种组合的渲染比对 | 0 处差异 |
| 渲染一页示例（含两个示意图） | 0.5 到 1.2 秒，纯生成函数中位 76 毫秒 |
| 成品页面体积 | 130 KB，压缩后 36 KB |
| 页面里的外部请求 | 0 个（只有一个指向 GitHub 的文字链接） |
| 官方基准语料复算 | 手写网页 4893 词元，草稿 612 词元，比值 8.0 倍 |
那个唯一的失败是它自己的测试超时：有一组测试要串行启动几百个进程、跑约六分钟，而文件级时限设的是两分钟。我在两台机器上各复现了一次，都是卡在 120 秒被掐掉。这不是功能坏了，是测试预算没跟上自己的规模。
再看安全。我挑了三个最关键的边界逐个改坏：
| 我改坏的地方 | 测试的反应 |
|---|---|
| 内容安全策略：把「默认全禁」改成「默认全放行」 | 8 条过、1 条挂，拦住 |
| 网页正文里的原生标签过滤：放行脚本标签 | 24 条过、4 条挂，拦住 |
| 本地预览服务：不再校验请求域名（防域名重绑定攻击） | 0 条过、1 条挂，拦住 |
再补两句实测细节，说明它不是纸面安全。
往草稿里塞进带事件处理器的图片、内联框架、外发表单，四类危险写法都原样进了页面。但每一类都被那份内容安全策略在浏览器端掐死：策略只认逐条哈希过的自有脚本，而事件处理器需要「允许内联脚本」才能跑，它没开这个口子。
另外，它拒绝引用密钥文件，拒绝读取工作目录之外的路径，也拒绝符号链接逃逸。三种我都试过，全部按预期拒绝，并给出可操作的提示。
这是真功夫。安全这件事，它没有偷懒。
没守住的两处
现在说没被拦住的部分。
第一处：文风检查的阈值。
源代码里那行限制写得很清楚：中文描述句 45 个字、步骤句 35 个字；英文描述句 25 个词、步骤句 20 个词。我把英文描述句那项 25 改成 250，然后重新打包、重新跑测试：
# pass 24
# fail 024 条测试全绿。再拿一篇 100 个词的长句去喂命令行，它答：「STE ✓ 0 warnings」。
原因不难理解，但值得说清楚：那 24 条测试验的是「规则引擎能不能识别长句」——它们自己造一句刚好超限的长句，断言「报警了」。至于阈值具体是 25 还是 250，没有一条测试锁住。换句话说，测试守的是「报警器会响」，不守「报警线画在哪」。
第二处：README 上的基准数字。
仓库宣称「同样的问题，模型写草稿只用手写网页的八分之一词元」。这个数字来自九对手稿的语料统计，存在一个基准文件里。我把 README 上的 4893 改成 48093，全库搜索，没有任何测试文件引用过这个数字。测试不会失败。
诚实地说，语料统计本来就不适合进单元测试——它依赖一份不进版本库的外部语料包。但结果是：读者最容易被说服的那个数字，恰好是自动化完全不保护的那个数字。
我顺手还发现三处小裂缝，都属于「文档和实现各走各的」：
- 对比文档写「12 个组件」，组件注册表里实际是 11 个，第 12 项是「原生网页/矢量图」这个逃生口，不算独立组件；
- 主题列表在终端里排版错位，长名字会把版本号挤得贴上去，
anthropic-clay0.1.10中间没有空隙；
- 只有标题、没有任何面板的空草稿，程序照样写出一个零面板的页面并返回成功。
还有一处小落差：README 写「大约 50 毫秒后你就有一页」。我实测纯生成函数中位 76 毫秒，算上进程启动整体 0.5 到 1.2 秒。50 毫秒是生成函数的最好成绩，不是用户感受到的那个数字。这是宣传口径的常见偏差，不影响使用，但和上面那条合起来看，指向同一个习惯。
同类里的位置
这个赛道上，最需要对比的是 Archify。
| answer-me-with-html | Archify | |
|---|---|---|
| Star | 4187 | 87118 |
| 建仓 | 2026 年 10 月 | 2026 年 4 月 |
| 起点 | 一页 HTML 答案 | 一张可交互的架构图 |
| 现在做的 | 一页 HTML 答案 | 一张图 + 「解释页」模式：结论先行、一题一屏、表格图表代码 |
| 交互 | 页面上的批注与决策汇总成一条回复 | 路由追踪、分享卡、导出图片与视频 |
| 离线 | 单文件、零外链 | 单文件 |
关键在第四行。Archify 已经把自己的能力从「一张图」扩到「一页解释」，那正是这个新项目的全部地盘。而它的对比文档里，关于竞品的那句话还写着「Archify 从一份 JSON 规格生成一张可交互图」，备注是 10 月 7 日核对的——距今半个月，竞品已经变了。
所以它真正的差异化不在「一页网页」，而在剩下三点：一，任何能跑 shell 命令的编码助手都能用，不绑特定宿主；二，产物完全离线，可以当附件发给别人；三，安全模型比同类更硬。
适合谁：想让 AI 把复杂解释画成页面、又不想装一堆东西的人。它的生成速度快、体积小、离线可用，装上就有产出。
不适合谁：想要交互式图表探索的人（那是 Archify 的地盘）；以及指望它的写作检查当质量门的人——那道门的阈值可以随便改，改了没人发现。
我的判断
值得装，但要按「内容工具」理解它，而不是「质量守门人」。
它最值钱的地方是那套工程纪律：95% 的覆盖率、432 种组合的逐字节比对、打包文件必须最新的持续集成检查。这三样东西在两周做出来的项目里几乎见不到，说明作者清楚什么会悄悄坏掉。我注入的安全缺陷三处全被拦住，这正是纪律的成果。
但纪律画出的边界很清晰：安全在自动化里，卖点在自动化外。 这不是疏忽，是个合理的工程取舍——文风阈值和语料统计确实难测。问题在于文档没有把这条边界写出来，读者看到的「13 道检查」和「8 倍省词元」并排站着，会以为它们受同等保护。
真要用来干活，三条建议：
一，别信默认阈值。想让它真的管住文风，把检查模式改成严格模式，否则只是建议。
二，它生成的页面可以放心发给别人——外部请求为零，脚本逐条哈希锁定，这是实测结论。
三，如果你在意「省了多少钱」这笔账，自己拿你常问的三个问题重算一遍，别直接引用 README 的数字。
一句话收尾：一个把安全做扎实、把卖点写漂亮，却没在两者之间画等号的项目。装着用没问题，只是别把宣传单当质保单。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：