我刚才盯着一个很小的动作。
把一份公众号写作规则放进 skill。
再让它真的产出 HTML。
不是口头说“可以”。
是要有文件。
要能打开。
要能复制。
要能看到图。
这个动作很小，却能看出运行时是真是假。
如果一个环境只能生成文字，不能落地 Excel、Word、PPT、HTML、PDF，甚至不能把一个小应用跑起来，那它最多是聊天层。不是生产层。
真正的运行时，必须有产物
你刚才说的判断很准。
一个运行环境，不能只回答“我会”。
它要交出东西。
Excel 要能写公式。
Word 要能排版。
PPT 要能成稿。
HTML 要能预览。
PDF 要能生成和检查。
应用要能启动。
这些不是锦上添花。
它们是能力边界。
没有这些，所谓智能体就会停在“看起来懂”。
有了这些，才开始接近“真的能干活”。
这个公众号 skill，关键不是写作
写一篇文章并不难。
难的是把交付标准固定住。
这份 skill 把很多容易漏掉的细节写死了。
比如开头不能套话。
比如正文不能靠排比撑气势。
比如头图必须在正文容器里。
比如名片必须包含固定电话。
比如所有视觉块，都要转成 PNG。
这里的逻辑很工程化。
文字只是其中一层。
真正要验证的是：规则能不能变成文件，文件能不能被浏览器执行，浏览器执行后能不能得到稳定结果。
为什么一定要把图跑出来
公众号编辑器对样式并不宽容。
很多网页里好看的效果，复制进去就丢。
背景色可能没了。
渐变可能没了。
复杂布局可能散了。
所以这个 skill 选择了更笨也更稳的路。
先用 Canvas 画出来。
再导出 PNG。
最后把 PNG 放进。
MDN 对这条链路有明确说明：Canvas 可以通过 toDataURL() 导出图片数据。浏览器也支持 Blob URL 承载临时资源。复制动作则可以通过选区和复制命令完成。
所以它不是“看起来像网页”。
它是一条浏览器能力支撑的交付链。
这次补能力，补的是执行器
单独一份 skill 文档还不够。
它会告诉 AI 怎么做。
但你要验证运行时，就要有可执行入口。
所以我给这个 skill 补了脚本。
脚本会生成完整 HTML。
页面打开后，会把头图、金句、信息框、流程图、能力图、步骤卡、CTA 和作者名片全部画成 PNG。
这一步跑不出来，就说明绘图能力没接上。
能跑出来，才说明这条链路成立。
产物型运行时，要看三张账
第一张账，是格式账。
它能不能产出你真正要用的格式。
不是 Markdown 代替 Word。
也不是截图代替 PPT。
第二张账，是验证账。
文件生成后，能不能打开、渲染、检查错误。
第三张账，是迭代账。
发现缺库、缺路径、缺浏览器能力时，能不能补上。
这三张账合在一起，才是运行时的真实水平。
你接下来应该怎么用这套东西
现实意义很简单。
你不是在做一个“会写文章”的功能。
你是在判断一个平台能不能承接真实工作。
真实工作一定会落到文件、浏览器、预览、导出、检查、修复上。
能力迁移也应该从这里开始。
先不要追求大而全。
先选一个高频场景，把标准写成 skill。
再给 skill 配一个最小执行器。
然后做三轮试跑。
第一轮只看文件能不能生成。
第二轮看文件能不能打开和渲染。
第三轮看交付物能不能被真实使用。
方法上，建议你把每个 skill 都拆成四层：触发条件、内容规则、产物格式、验证动作。触发条件解决“什么时候用”。内容规则解决“按什么标准做”。产物格式解决“交什么东西”。验证动作解决“怎么证明它不是假跑”。这四层跑通后，skill 才不只是提示词。它会变成一种可复用的生产能力。以后无论是公众号文章、流程报告、合同审查，还是数据看板，都可以沿着同一条路迁移。
核查依据： MDN Canvas toDataURL、 MDN URL.createObjectURL、 MDN Document.execCommand。