即刻App年轻人的同好社区
下载
记录一下对于 Deepseek Harness 的理解
DeepSeek Harness（DSH）：系统由哪些能力组成，允许持续变化；这次工作实际发生过什么，必须保持不变。这背后对应着两套独立运行的机制。
第一套机制：能力构成要能随时变，但变的时候不能把别的东西搞坏
模型可能换供应商，某个工具可能从本地版换成沙箱版，某个会话可能只想用两三个工具而不是全部，这是产品持续迭代必然会遇到的日常需求。
* DSH 的做法：把“谁在提供什么能力”“谁在用这个能力”“换掉一个会不会影响到不该受影响的部分”，全都当成运行时要一直维护的状态，而不是写死在代码里、改起来要挨个排查影响面。
* 带来的作用：换一个组件时，只有真正依赖它的部分会跟着重新加载，不相关的部分完全不受影响；退出时占用过的资源、注册过的监听器，能自动干净收回去，不留垃圾。
* 不这么做会出的问题：
* 改一处、炸一片，换掉一个模型供应商或工具实现，顺带影响到本不该受影响的其他部分，因为没人明确管着
“谁依赖谁”，全靠开发者自己记住并小心绕开，系统越大越容易漏。
* 资源和注册项收不干净，一个功能被关掉或替换之后，它注册过的东西、占用的连接、留下的临时状态，没有统一机制保证会被清理，时间长了系统里全是没人管的残留，排查问题越来越难，最终的归宿只会是坍塌。
* 热插拔只是这套机制带来的最容易被看到的效果，真正的工作量在于换的时候只影响该影响的部分，退出时收得干净。
第二套机制：不管能力怎么变，这次任务实际做过什么，必须有原始的记录，不能被冲掉或改写
这是完全独立的另一半，跟能不能换东西没关系，哪怕系统一次都没换过任何组件，历史记录该怎么记、能不能完整倒回去看，依然是必须单独解决的问题。
* DSH 的做法：把这部分单独拎出来，做成一份只能往后加、不能往回改的记录，用户能看到的任何东西，理论上都要能从这份记录里还原出来。
* 带来的作用：不管系统内部后续怎么调整，这份记录永远反映当时真实发生的事，用户可以拿它逐条核对，而不是只能选择相信。
* 不这么做会出的问题：让历史记录和系统当前状态混在一起记，系统内部一旦做了调整，比如换了个模型、优化了内部调度逻辑，连带着把之前的执行记录也改样了。用户想回头核对“当时到底发生了什么”时，看到的可能已经不是真实情况，而是被系统后续变化污染过的版本，这对需要建立用户信任的产品是致命的，记录如果不可靠，记不记其实没有本质区别。
这两件事是 DSH 的核心逻辑，系统的能力构成允许一直变，系统发生过什么永远不能变。前者让产品能持续替换和调整内部实现而不至于每次都伤筋动骨，不牵一发而动全身；后者让用户不管产品内部怎么调整，始终能相信自己看到的执行记录是真的、完整的。把整个系统的可观测性、可维护性拉满，可以持续运营维护的系统才是好系统。
DeepSeek Harness（DSH）：系统由哪些能力组成，允许持续变化；这次工作实际发生过什么，必须保持不变。这背后对应着两套独立运行的机制。
第一套机制：能力构成要能随时变，但变的时候不能把别的东西搞坏
模型可能换供应商，某个工具可能从本地版换成沙箱版，某个会话可能只想用两三个工具而不是全部，这是产品持续迭代必然会遇到的日常需求。
* DSH 的做法：把“谁在提供什么能力”“谁在用这个能力”“换掉一个会不会影响到不该受影响的部分”，全都当成运行时要一直维护的状态，而不是写死在代码里、改起来要挨个排查影响面。
* 带来的作用：换一个组件时，只有真正依赖它的部分会跟着重新加载，不相关的部分完全不受影响；退出时占用过的资源、注册过的监听器，能自动干净收回去，不留垃圾。
* 不这么做会出的问题：
* 改一处、炸一片，换掉一个模型供应商或工具实现，顺带影响到本不该受影响的其他部分，因为没人明确管着
“谁依赖谁”，全靠开发者自己记住并小心绕开，系统越大越容易漏。
* 资源和注册项收不干净，一个功能被关掉或替换之后，它注册过的东西、占用的连接、留下的临时状态，没有统一机制保证会被清理，时间长了系统里全是没人管的残留，排查问题越来越难，最终的归宿只会是坍塌。
* 热插拔只是这套机制带来的最容易被看到的效果，真正的工作量在于换的时候只影响该影响的部分，退出时收得干净。
第二套机制：不管能力怎么变，这次任务实际做过什么，必须有原始的记录，不能被冲掉或改写
这是完全独立的另一半，跟能不能换东西没关系，哪怕系统一次都没换过任何组件，历史记录该怎么记、能不能完整倒回去看，依然是必须单独解决的问题。
* DSH 的做法：把这部分单独拎出来，做成一份只能往后加、不能往回改的记录，用户能看到的任何东西，理论上都要能从这份记录里还原出来。
* 带来的作用：不管系统内部后续怎么调整，这份记录永远反映当时真实发生的事，用户可以拿它逐条核对，而不是只能选择相信。
* 不这么做会出的问题：让历史记录和系统当前状态混在一起记，系统内部一旦做了调整，比如换了个模型、优化了内部调度逻辑，连带着把之前的执行记录也改样了。用户想回头核对“当时到底发生了什么”时，看到的可能已经不是真实情况，而是被系统后续变化污染过的版本，这对需要建立用户信任的产品是致命的，记录如果不可靠，记不记其实没有本质区别。
这两件事是 DSH 的核心逻辑，系统的能力构成允许一直变，系统发生过什么永远不能变。前者让产品能持续替换和调整内部实现而不至于每次都伤筋动骨，不牵一发而动全身；后者让用户不管产品内部怎么调整，始终能相信自己看到的执行记录是真的、完整的。把整个系统的可观测性、可维护性拉满，可以持续运营维护的系统才是好系统。
3 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
49 1232
大多数 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
周末我把 YouMind 的公开页面、Semrush 数据，以及它增长工程负责人写的复盘文章放在一起看了一遍。这里面最值得学的点，不是它做了多少页面，也不是它押中了某个关键词，而是它把 AI 产品的 SEO 做成了一个更接近产品增长的系统。
很多人做 SEO 的第一反应是：哪个词流量大？哪个词 KD 低？我能不能写一篇 Blog？但 YouMind 这轮增长不是这个路径。它更像是先看用户现在到底想完成什么任务，比如大家在找 image prompts、nano banana pro prompts、seedance 2.0 prompt，然后快速把这些需求做成 Prompt 集合页，再用 SEO、社媒、GitHub、KOL 和产品转化把它放大。
YouMind 最近海外 SEO 增长最明显的市场是印度和美国，但这两个市场的结构不一样。印度关键词数量没有美国多，但自然流量高度集中，主要是 /prompts 和 /prompts/image 这种页面贡献的；美国关键词覆盖更广，品牌词更强，同时 Prompt 页面开始形成第二增长线。
真正起量的不是 Blog，而是 Prompt 聚合页。印度市场里 /prompts 大概有 20K 流量，/prompts/image 大概有 12.8K 流量。这点很重要，因为用户搜 image prompts 的时候，不是想看解释文章，而是想要一堆可以直接复制、马上用的 prompt。
Prompt 集合页本质上正在变成新的工具页。以前工具页是 transcript generator、image converter、pdf summarizer 这种，用户打开页面是为了完成一个动作。现在 Prompt 页面也是这样，用户打开页面是为了找到 prompt、复制 prompt、使用 prompt，最好还能直接进入产品生成。
YouMind 不是先从关键词表里硬推页面，而是先从需求里推页面，再用关键词数据验证和放大。它增长负责人复盘里提到，像 Nano Banana Pro 这种集合站，是先看到社媒上很多人在发效果图和 prompt，判断用户有需求，然后快速做集合页，再通过社媒、KOL、GitHub 去分发。
这类页面能跑出来，是因为它满足了“免费而丰富的高价值资源”这个条件。用户愿意收藏，KOL 愿意转发，工具站和 GitHub 愿意引用，搜索引擎也能理解这是一个持续更新的资源库。
YouMind 的页面结构也不是乱铺的。它有 /prompts 承接泛词，有 /prompts/image 承接类目词，有模型 Prompt 页承接热点词，再用大量详情页补内容库存和长尾。这个顺序比一上来生成几万条详情页健康很多。
所以 YouMind 这轮增长最值得学的，不是某一个关键词，而是一套顺序：先看用户需求，再做可用页面，再用社媒和 GitHub 做第一波分发，再让 SEO 放大，最后把流量接回产品
完整分析见： mp.weixin.qq.com
很多人做 SEO 的第一反应是：哪个词流量大？哪个词 KD 低？我能不能写一篇 Blog？但 YouMind 这轮增长不是这个路径。它更像是先看用户现在到底想完成什么任务，比如大家在找 image prompts、nano banana pro prompts、seedance 2.0 prompt，然后快速把这些需求做成 Prompt 集合页，再用 SEO、社媒、GitHub、KOL 和产品转化把它放大。
YouMind 最近海外 SEO 增长最明显的市场是印度和美国，但这两个市场的结构不一样。印度关键词数量没有美国多，但自然流量高度集中，主要是 /prompts 和 /prompts/image 这种页面贡献的；美国关键词覆盖更广，品牌词更强，同时 Prompt 页面开始形成第二增长线。
真正起量的不是 Blog，而是 Prompt 聚合页。印度市场里 /prompts 大概有 20K 流量，/prompts/image 大概有 12.8K 流量。这点很重要，因为用户搜 image prompts 的时候，不是想看解释文章，而是想要一堆可以直接复制、马上用的 prompt。
Prompt 集合页本质上正在变成新的工具页。以前工具页是 transcript generator、image converter、pdf summarizer 这种，用户打开页面是为了完成一个动作。现在 Prompt 页面也是这样，用户打开页面是为了找到 prompt、复制 prompt、使用 prompt，最好还能直接进入产品生成。
YouMind 不是先从关键词表里硬推页面，而是先从需求里推页面，再用关键词数据验证和放大。它增长负责人复盘里提到，像 Nano Banana Pro 这种集合站，是先看到社媒上很多人在发效果图和 prompt，判断用户有需求，然后快速做集合页，再通过社媒、KOL、GitHub 去分发。
这类页面能跑出来，是因为它满足了“免费而丰富的高价值资源”这个条件。用户愿意收藏，KOL 愿意转发，工具站和 GitHub 愿意引用，搜索引擎也能理解这是一个持续更新的资源库。
YouMind 的页面结构也不是乱铺的。它有 /prompts 承接泛词，有 /prompts/image 承接类目词，有模型 Prompt 页承接热点词，再用大量详情页补内容库存和长尾。这个顺序比一上来生成几万条详情页健康很多。
所以 YouMind 这轮增长最值得学的，不是某一个关键词，而是一套顺序：先看用户需求，再做可用页面，再用社媒和 GitHub 做第一波分发，再让 SEO 放大，最后把流量接回产品
完整分析见： mp.weixin.qq.com
4 14