技能工程的暗黑技艺：Paul Bakaus 的九个 harness 工程技巧

Paul Bakaus 说，Impeccable 起于他建设大型应用时的实际问题。代理能很快生成可见结果，但把结果重新规范到应用的设计系统里很难。他的第一个技能 Normalize，就是为这个缺口而做。

随着集合变大，他不再把技能看成打包的提示词，而是编码运行环境的扩展。这场工作坊介绍九种方法，把文字与工具、脚本、状态和反馈结合起来。

他也解释，越来越长的审美禁令为什么不够。禁止一个熟悉字体或风格，可能只让模型移向另一个熟悉默认值。这是他基于设计默认值经验对收敛的解释，不是关于所有模型与网站的测量定律。

Bakaus 描述两种批评失败。一个设计很好、却有许多细节问题的页面，可能因为模型被问题数量锚定而被评得很差；一个空白或糟糕页面，也可能因为检测器没有发现什么而显得很好。

他的办法是拆开输入。一个独立审查根据浏览器证据观察层级、连贯性和设计质量；另一个收集确定性发现与技术证据。主流程再综合报告，不让某一位审查者提前锚定另一位的判断。

目标是更好地区分证据，不保证两个模型就会与人意见一致。现场演示没有清楚展示预期的子代理行为，他也承认仓库版本较旧。本文保留这个限制，不把台上的尝试写成已经验证成功。

他把发散方法叫作 anti-attractor。简单做法是先列出熟悉选择，再反复舍弃，但他也承认，这最终仍可能收敛。

更强的创意线索，可以来自模型眼前默认值之外。他用意外联想生成大量着色器想法，再在新上下文中排序。另一种方法是脚本从人工筛选的起始颜色里选一个，再要求模型围绕它发展。

种子提供变化，不自动提供质量。用户仍然可以拒绝结果。这个方法的目的，是创造不同起点，让后续判断和迭代有新的方向。

把所有可能规则装进一个大技能，会造成模糊。Bakaus 的例子是字体：为了鲜明落地页而不鼓励系统字体的规则，可能不适合希望接近原生体验的产品。

因此，Impeccable 同时按照操作和表达类型路由，例如批评或打磨，以及面向品牌的内容或产品界面。不同任务说明决定加载哪些文档和规则。

他使用混合专家作比喻，是在说明技能路由的组织方式，并非声称 Markdown 文件实现了神经模型的同种架构。实际目标是加载需要的指导，而不把互不兼容的指令塞进一份巨型文档。

Bakaus 把批评等工件保存成文件，让后面的工作能使用此前发现。即使发生在另一次会话，打磨阶段也能读到先前批评。

用户的不同意见也应进入记忆。如果用户有意识地偏好一个被批评否定的选择，后续不应假装没有作过决定，再机械重复同一反对意见。

这是显式存储状态，不是神奇的长期记忆。流程需要选择工件放在哪里、是否进入版本控制，以及后续怎样解释。保存下来的意见仍是需要评估的背景，而不是永远不可质疑的规则。

工作坊中的背景脚本收集产品和设计信息。缺少文件时，它可以结构化地报告缺口与下一步，而不是期待主技能里埋着的一句话始终被记住。

Bakaus 说，他发现，在这个时刻返回的指令，比长串静态规则更有效。他也描述了需要用户允许的更新流程，而不是把发现更新当作安装许可。

这有成本。动态输出会改变对话前缀，可能减少缓存机会。问答环节里，他澄清静态技能内容仍可能被缓存，并不是说一个动态脚本就消灭了所有提示缓存。

钩子解决另一个问题：用户与代理都可能忘记调用技能。与编辑动作关联的检查，能够立刻返回反馈，或在不允许的操作发生前阻止它。

Bakaus 区分编辑后的消息与工具执行前的阻止。他说，一些模型不能稳定根据事后反馈纠正问题，因此在特定环境需要更强干预。这是他当时的运行经验，不是当前各家能力对照表。

他明确警告误报。需要提供合适粒度的忽略规则和配置，否则所谓帮助会很快变成打扰。钩子的价值，在于给出适当反馈循环，而不只在于它能够阻止工作。

针对设计，Bakaus 想要的不只是聊天框里关于像素的指令。实时模式把页面交互变成代理消费的事件，随后生成变体或修改选中元素。

他解释，一个小型轮询进程等待事件，再带着会话可读取的信息退出。代理按指令处理事件，结果返回浏览器。演示中可以选中页面元素，查看变体，再接受或放弃选择。

37:10查看原图

更广泛的思路是，利用运行环境已有的界面来匹配工作。不要求每个技能都运行浏览器桥接，作者后来也承认这套实现仍有问题，原生集成可能更合适。

Bakaus 列出子代理许可、提问工具、任务完成通知、钩子和安装方式的差异。符号链接可以共享文字，却不能让不同执行环境表现完全一样。

他也观察到模型各有习惯，因此纠正一个模型的规则，可能让另一个过度纠正。他的构建会替换运行时工具、选择性加载指导，而不是不加区分地给所有模型施加全部警告。

这些观察描述的是工作坊中的经验，不应被当作重新核实过的当前提供方行为或权限规则。长期有效的工程问题是，安装后的工件是否调用了实际可用的工具，并遵循那个环境中的流程。

分发技能时，Bakaus 会测试指令跟随较弱的模型，而不只测试自己偏好的模型。他描述明确检查点及其结果记录，以免模型悄悄把流程压缩成少数方便步骤。

检查点清单仍是指令，不是加密意义上的完成保证。记录必须对应真实发生的事情。模型说自己通过检查，不能替代底层工具结果或工件。

他没有要求所有人采用全部九种方法。工作坊的建议，是选择问题真正需要的机制，尤其是要把技能交给使用不同模型和环境的人时。

问答中，Bakaus 描述端到端测试、浏览器自动化，以及复刻选定环境和工具的评估框架。模拟用户处理交互部分，设计评审则比较不同业务领域和模型的结果。

他还介绍消融：移除一条带标识的规则，重新运行评估，再与恢复规则后的行为比较。确定性检查可以显示，一条指令是否改变了对比度之类的具体性质。

这是他报告的方法，私有评估框架并未在本文独立复现。消融成本高，某个可测行为变化，也不证明整体设计质量。但相较于一句话听起来是否有道理，它为保留规则提供了更具体的依据。

被直接问到品位时，Bakaus 说自己的评估效果并不好。他举出一个评审偏好拥挤首屏的例子，说明代理指标可能朝错误方向移动。

他在自己系统里抵消这种偏差的实验属于启发式做法，不是普遍反转模型分数的配方。他仍然用人的观察和批注，也区分功能性观察与更依赖情境的品位判断。

这个承认改变了前面方法的解读。更好的路由、钩子和测试，可以改善控制，却不能建立通用审美评估器。系统可以支持判断，同时留下重要的未解部分。

Bakaus 最后认为，广泛共享的技能需要比个人提示更多测试。打包、更新与目标运行时，都可能破坏作者那里有效的过程。

他也承认有些东西没试过，包括听众提出的由服务器提供技能的问题。他没有假装分发生态已有定论，也不愿永远自行维护安装器的每一部分。

因此，工作坊的中心转变，是从写指令走向软件行为：显式保存状态，在需要的地方连接反馈，测试实际环境，并如实告诉用户哪些能力没有执行。更复杂的技能，只有因此产生更可靠结果时，才值得付出复杂度。