即刻App年轻人的同好社区
下载
记录一下对于 Deepseek Harness 的理解
DeepSeek Harness（DSH）：系统由哪些能力组成，允许持续变化；这次工作实际发生过什么，必须保持不变。这背后对应着两套独立运行的机制。
第一套机制：能力构成要能随时变，但变的时候不能把别的东西搞坏
模型可能换供应商，某个工具可能从本地版换成沙箱版，某个会话可能只想用两三个工具而不是全部，这是产品持续迭代必然会遇到的日常需求。
* DSH 的做法：把“谁在提供什么能力”“谁在用这个能力”“换掉一个会不会影响到不该受影响的部分”，全都当成运行时要一直维护的状态，而不是写死在代码里、改起来要挨个排查影响面。
* 带来的作用：换一个组件时，只有真正依赖它的部分会跟着重新加载，不相关的部分完全不受影响；退出时占用过的资源、注册过的监听器，能自动干净收回去，不留垃圾。
* 不这么做会出的问题：
* 改一处、炸一片，换掉一个模型供应商或工具实现，顺带影响到本不该受影响的其他部分，因为没人明确管着
“谁依赖谁”，全靠开发者自己记住并小心绕开，系统越大越容易漏。
* 资源和注册项收不干净，一个功能被关掉或替换之后，它注册过的东西、占用的连接、留下的临时状态，没有统一机制保证会被清理，时间长了系统里全是没人管的残留，排查问题越来越难，最终的归宿只会是坍塌。
* 热插拔只是这套机制带来的最容易被看到的效果，真正的工作量在于换的时候只影响该影响的部分，退出时收得干净。
第二套机制：不管能力怎么变，这次任务实际做过什么，必须有原始的记录，不能被冲掉或改写
这是完全独立的另一半，跟能不能换东西没关系，哪怕系统一次都没换过任何组件，历史记录该怎么记、能不能完整倒回去看，依然是必须单独解决的问题。
* DSH 的做法：把这部分单独拎出来，做成一份只能往后加、不能往回改的记录，用户能看到的任何东西，理论上都要能从这份记录里还原出来。
* 带来的作用：不管系统内部后续怎么调整，这份记录永远反映当时真实发生的事，用户可以拿它逐条核对，而不是只能选择相信。
* 不这么做会出的问题：让历史记录和系统当前状态混在一起记，系统内部一旦做了调整，比如换了个模型、优化了内部调度逻辑，连带着把之前的执行记录也改样了。用户想回头核对“当时到底发生了什么”时，看到的可能已经不是真实情况，而是被系统后续变化污染过的版本，这对需要建立用户信任的产品是致命的，记录如果不可靠，记不记其实没有本质区别。
这两件事是 DSH 的核心逻辑，系统的能力构成允许一直变，系统发生过什么永远不能变。前者让产品能持续替换和调整内部实现而不至于每次都伤筋动骨，不牵一发而动全身；后者让用户不管产品内部怎么调整，始终能相信自己看到的执行记录是真的、完整的。把整个系统的可观测性、可维护性拉满，可以持续运营维护的系统才是好系统。
DeepSeek Harness（DSH）：系统由哪些能力组成，允许持续变化；这次工作实际发生过什么，必须保持不变。这背后对应着两套独立运行的机制。
第一套机制：能力构成要能随时变，但变的时候不能把别的东西搞坏
模型可能换供应商，某个工具可能从本地版换成沙箱版，某个会话可能只想用两三个工具而不是全部，这是产品持续迭代必然会遇到的日常需求。
* DSH 的做法：把“谁在提供什么能力”“谁在用这个能力”“换掉一个会不会影响到不该受影响的部分”，全都当成运行时要一直维护的状态，而不是写死在代码里、改起来要挨个排查影响面。
* 带来的作用：换一个组件时，只有真正依赖它的部分会跟着重新加载，不相关的部分完全不受影响；退出时占用过的资源、注册过的监听器，能自动干净收回去，不留垃圾。
* 不这么做会出的问题：
* 改一处、炸一片，换掉一个模型供应商或工具实现，顺带影响到本不该受影响的其他部分，因为没人明确管着
“谁依赖谁”，全靠开发者自己记住并小心绕开，系统越大越容易漏。
* 资源和注册项收不干净，一个功能被关掉或替换之后，它注册过的东西、占用的连接、留下的临时状态，没有统一机制保证会被清理，时间长了系统里全是没人管的残留，排查问题越来越难，最终的归宿只会是坍塌。
* 热插拔只是这套机制带来的最容易被看到的效果，真正的工作量在于换的时候只影响该影响的部分，退出时收得干净。
第二套机制：不管能力怎么变，这次任务实际做过什么，必须有原始的记录，不能被冲掉或改写
这是完全独立的另一半，跟能不能换东西没关系，哪怕系统一次都没换过任何组件，历史记录该怎么记、能不能完整倒回去看，依然是必须单独解决的问题。
* DSH 的做法：把这部分单独拎出来，做成一份只能往后加、不能往回改的记录，用户能看到的任何东西，理论上都要能从这份记录里还原出来。
* 带来的作用：不管系统内部后续怎么调整，这份记录永远反映当时真实发生的事，用户可以拿它逐条核对，而不是只能选择相信。
* 不这么做会出的问题：让历史记录和系统当前状态混在一起记，系统内部一旦做了调整，比如换了个模型、优化了内部调度逻辑，连带着把之前的执行记录也改样了。用户想回头核对“当时到底发生了什么”时，看到的可能已经不是真实情况，而是被系统后续变化污染过的版本，这对需要建立用户信任的产品是致命的，记录如果不可靠，记不记其实没有本质区别。
这两件事是 DSH 的核心逻辑，系统的能力构成允许一直变，系统发生过什么永远不能变。前者让产品能持续替换和调整内部实现而不至于每次都伤筋动骨，不牵一发而动全身；后者让用户不管产品内部怎么调整，始终能相信自己看到的执行记录是真的、完整的。把整个系统的可观测性、可维护性拉满，可以持续运营维护的系统才是好系统。
4 00
最近做了一个复刻网站的 Skill：给一个 URL，就能 1:1 复刻整个页面，布局、排印、素材、滚动动画、交互状态全部还原。整个 skill 需要依赖于 ego lite 这个目前最好的浏览器自动化产品
repo 地址往下翻👇
首先为什么能做到 1:1？
核心是把要复刻的网页当成一个可以查询的数据源，而不是一张一张靠眼睛比对的图片。
大部分人让 AI 仿站的做法，是丢一张截图过去，让模型看图写代码。截图只有像素信息，字体、间距、动画曲线这些关键事实全靠模型猜，所以效果不稳定。
我的做法是让 agent 打开真实页面，直接从运行中的页面里提取事实：完整 DOM 结构、CSS 设计变量、字体文件、动画关键帧，甚至从编译后的 JS 里挖出界面上懒加载的配置数据。
滚动动画这种最难仿的部分，也是靠真实滚动逐帧采样逆向出来的，不是看着效果猜参数。
拿到这些事实之后，重建就有据可依了。静态站直接做 HTML 镜像，框架站逐节重建成组件。
最后一步是验收。
在原站和克隆站上跑同一套测量脚本，对比几何位置、排印、颜色、字体、动画覆盖等八个维度的数值，任何一项不达标就继续修，直到收敛。
所以，还原度不是靠模型“画得像”，而是整个流程里没有靠眼睛判断的环节：每一步的输入是测量出来的事实，产出也用测量来验证。
“像不像”这件事，从主观判断变成了一个可以收敛的数值问题。
但是要注意的是
我写这个 skill 的原因是因为我看到一个网站的滚动动画很惊艳，但是无论怎么口述，模型都无法很好地复刻出来。通过开发这个 skill 之后，模型可以直接通过 ego lite 自己去理解对应滚动动画实现的各种逻辑。
所以使用的时候也必须是用于学习，绝对不可以用于抄袭他人的作品。
目前测试成功的模型有：fable 5、opus 5、gpt 5.6-sol
repo: github.com
repo 地址往下翻👇
首先为什么能做到 1:1？
核心是把要复刻的网页当成一个可以查询的数据源，而不是一张一张靠眼睛比对的图片。
大部分人让 AI 仿站的做法，是丢一张截图过去，让模型看图写代码。截图只有像素信息，字体、间距、动画曲线这些关键事实全靠模型猜，所以效果不稳定。
我的做法是让 agent 打开真实页面，直接从运行中的页面里提取事实：完整 DOM 结构、CSS 设计变量、字体文件、动画关键帧，甚至从编译后的 JS 里挖出界面上懒加载的配置数据。
滚动动画这种最难仿的部分，也是靠真实滚动逐帧采样逆向出来的，不是看着效果猜参数。
拿到这些事实之后，重建就有据可依了。静态站直接做 HTML 镜像，框架站逐节重建成组件。
最后一步是验收。
在原站和克隆站上跑同一套测量脚本，对比几何位置、排印、颜色、字体、动画覆盖等八个维度的数值，任何一项不达标就继续修，直到收敛。
所以，还原度不是靠模型“画得像”，而是整个流程里没有靠眼睛判断的环节：每一步的输入是测量出来的事实，产出也用测量来验证。
“像不像”这件事，从主观判断变成了一个可以收敛的数值问题。
但是要注意的是
我写这个 skill 的原因是因为我看到一个网站的滚动动画很惊艳，但是无论怎么口述，模型都无法很好地复刻出来。通过开发这个 skill 之后，模型可以直接通过 ego lite 自己去理解对应滚动动画实现的各种逻辑。
所以使用的时候也必须是用于学习，绝对不可以用于抄袭他人的作品。
目前测试成功的模型有：fable 5、opus 5、gpt 5.6-sol
repo: github.com
00:57
52 1236
大多数 Windows 应用，登录状态明明保存在本地，但如果电脑开机时没联网，这些应用在尝试自动登录失败后，就会直接显示登录失败，直接进入未登录状态。此时即便网络恢复，你点击应用内的功能时，它还是会提示让你重新登录。但如果你把应用彻底关掉，在联网状态下重新打开，它就能立刻读取到登录状态直接进入。
我简单调研了一下
首先是为什么开机瞬间联网经常没就绪
这是 Windows 上一个很经典的问：开机自启动的程序(通过注册表 Run 项、启动文件夹、登录时计划任务拉起)往往比 Wi-Fi 真正建立连接更早启动。Wi-Fi 重连需要走 WPA 握手、DHCP 续租,域内机器还可能要等域控可达,这些加起来经常要几秒到几十秒。而且 Windows 有个更隐蔽的坑：网卡"已连接"(link up)和"能访问外网"(internet 可达)是两个不同的状态，很多应用检测的是前者，网卡刚连上但实际还没解析出网关、DNS 没通的时候,应用已经发起请求了，自然失败。
然后是大多数产品的设计 现状
大部分应用的登录状态设计成一个很简单的状态机：未登录 → 登录中 → 已登录，或者失败后回到未登录。开机自启动时，应用去读本地缓存的 token（存在 Windows Credential Manager、DPAPI 加密文件或本地数据库里）,然后拿这个 token 去服务器换取一次刷新验证——这一步需要联网。如果这时候网络还没就绪，这次请求会超时或直接报错，应用捕获到的是一个笼统的"请求失败"异常。没有区分"网络不通"和"token 已过期/被吊销"这两种完全不同的失败原因，于是直接把状态切到未登录。
为什么重新打开应用就能立刻登录
很简单了，因为完整重启进程会重新走一遍启动时的登录流程，就是产品想要用户走的正常逻辑。
实际上完全可以做"网络恢复后自动重试"的功能
Windows 完全有对应的能力可以支持这么做：Network List Manager 的 ConnectivityChanged 事件、WinINet 的连接状态回调、WinRT 的 NetworkInformation.NetworkStatusChanged，这些都能让应用订阅"网络真正恢复"这个信号。自动重新发起登录请求，或者至少把重试按钮绑定到同一段登录逻辑上。
希望各家加速器的PM可以看到，优化一下
我简单调研了一下
首先是为什么开机瞬间联网经常没就绪
这是 Windows 上一个很经典的问：开机自启动的程序(通过注册表 Run 项、启动文件夹、登录时计划任务拉起)往往比 Wi-Fi 真正建立连接更早启动。Wi-Fi 重连需要走 WPA 握手、DHCP 续租,域内机器还可能要等域控可达,这些加起来经常要几秒到几十秒。而且 Windows 有个更隐蔽的坑：网卡"已连接"(link up)和"能访问外网"(internet 可达)是两个不同的状态，很多应用检测的是前者，网卡刚连上但实际还没解析出网关、DNS 没通的时候,应用已经发起请求了，自然失败。
然后是大多数产品的设计 现状
大部分应用的登录状态设计成一个很简单的状态机：未登录 → 登录中 → 已登录，或者失败后回到未登录。开机自启动时，应用去读本地缓存的 token（存在 Windows Credential Manager、DPAPI 加密文件或本地数据库里）,然后拿这个 token 去服务器换取一次刷新验证——这一步需要联网。如果这时候网络还没就绪，这次请求会超时或直接报错，应用捕获到的是一个笼统的"请求失败"异常。没有区分"网络不通"和"token 已过期/被吊销"这两种完全不同的失败原因，于是直接把状态切到未登录。
为什么重新打开应用就能立刻登录
很简单了，因为完整重启进程会重新走一遍启动时的登录流程，就是产品想要用户走的正常逻辑。
实际上完全可以做"网络恢复后自动重试"的功能
Windows 完全有对应的能力可以支持这么做：Network List Manager 的 ConnectivityChanged 事件、WinINet 的连接状态回调、WinRT 的 NetworkInformation.NetworkStatusChanged，这些都能让应用订阅"网络真正恢复"这个信号。自动重新发起登录请求，或者至少把重试按钮绑定到同一段登录逻辑上。
希望各家加速器的PM可以看到，优化一下
0 00
13 410