前言：为什么要有这个？
前段时间买了一台miniled显示器，hdr能上到1400nit亮度非常爽，但miniled上使用hdr获得最好的体验必须在osd菜单中 开启分区背光（分区调光）选项，就导致我想看个电影或者玩支持hdr游戏结果必须在设置中打开hdr选项或者按win+alt+b，然后伸手去摸显示器背后那个反人类的摇杆/按钮，在一层层OSD菜单里翻找。看完电影想回桌面办公，又得把这些亮瞎眼的设置关掉，再按一遍……
太蠢了。 都2026年了（bushi），为什么不能在桌面上点一下鼠标或者按快捷键就搞定？
其实显示器一直支持软件控制，这就是 DDC/CI (Display Data Channel / Command Interface) 协议。
然后我就在想我为什么不能写一个python脚本来实现 “一键双开”：同时激活 Windows 系统的 HDR + 显示器内部的高级功能（如分区调光）呢？
经过和gemini小姐的一番沟通下，也是把脚本给写出来了

1. 什么是 DDC/CI？
简单来说，就是通过你的视频线（HDMI 或 DP），让电脑直接给显示器发号施令。
通常我们用它调亮度（VCP Code 0x10），但既然它是“Command Interface”，它能做的远不止这些。每个厂商（LG, Dell, HKC, 泰坦军团等）都在里面藏了一些“私有代码”，用来控制特殊功能。
我们要做的就是：抓包找到这个代码 → 编写脚本控制它 → 联动 Windows HDR。

2. 准备工作
环境需求

Windows 10/11
Python 3.x
一个支持 DDC/CI 的显示器（99%都支持，记得在OSD菜单里开启“DDC/CI”选项）

安装依赖库
在 CMD / PowerShell 中运行：
pip install monitorcontrol


3. 实操步骤
第一步：开启“嗅探模式”，找到你的神秘代码
不是所有功能都有国际标准代码。亮度的代码通常是 0x10，但“分区调光”、“HDR模拟”、“游戏模式”等通常是厂商私有的。
我们需要用一个脚本来“找不同”：

运行下方的嗅探脚本。
脚本会暂停，此时手动在显示器上关闭该功能，按回车。
脚本再次暂停，手动开启该功能，按回车。
脚本会对比并告诉你哪个代码变了。

(压缩包内 Sniffer 脚本代码)
假设你抓到了代码是 0xF4（通常是一个十六进制数），关闭是 0，开启是 3。
第二步：部署“完全体”联动脚本
这是经过多次迭代、防崩溃、防锁死的最终版脚本。
它的逻辑非常暴力且稳健：

精准查询：调用外部工具 HdrSwitcher 确认 Windows 当前 HDR 状态。
状态纠错：如果 Windows 开了但显示器没开，它只修正显示器，不执行切换。
防锁死机制：很多显示器在 HDR 开启时会锁死 DDC 通道，导致脚本报错。本脚本采用了“先切 Windows 回 SDR 解锁，再关显示器”的特殊顺序。

你需要下载一个辅助工具：
去 Github 下载 Vaiz/HdrSwitcher，把 HdrSwitcher.exe 放在脚本同级目录。（压缩包内已有）
脚本代码示例 (monitor_sync.py)：
import sys
import time
import subprocess
import os
from monitorcontrol import get_monitors

# ====== 配置你的显示器参数 ======
TARGET_VCP_CODE = 0xF4   # 第一步抓到的代码填这里
VALUE_MONITOR_ON = 3     # "开"对应的数值
VALUE_MONITOR_OFF = 0    # "关"对应的数值
# =============================

HDR_TOOL = "HdrSwitcher.exe"

def main():
    # ......
    pass

if __name__ == "__main__":
    main()

第三步：一键执行

把脚本和 exe 放在一起。
新建一个 .bat 文件：@echo off
python monitor_sync.py


以后只要双击这个 bat，或者用 Stream Deck 绑定它，就能实现：

咔哒一下：Windows HDR 开启 + 显示器分区调光开启。
再咔哒一下：Windows HDR 关闭 + 显示器分区调光关闭。




4. 原理与避坑细节 (Technical Deep Dive)
为什么不用 Windows 自带的 API？
Windows 的 HDR 切换没有公开且好用的 API（ChangeDisplaySettingsEx 很难搞定 Advanced Color）。使用 SendInput 模拟 Win+Alt+B 在玩游戏或全屏时极其不稳定。所以利用 HdrSwitcher 这种直接操作私有 API 的工具是最稳的。
这里的“防锁死 (Anti-Lock)”逻辑是什么？
在测试中发现，当部分国产显示器（具体型号不点名）处于 HDR 模式时，如果你试图通过 DDC/CI 读取或写入数据，它的 MCU 会拒绝响应（Invalid Command）。
解决方案：

开启时：先开 Windows HDR → 等待握手(黑屏) → 再发 DDC 指令开分区调光。
关闭时：反过来！先关 Windows HDR (强制让显示器退回 SDR 模式，解放 MCU) → 再发 DDC 指令关分区调光。
这个顺序至关重要，否则脚本大概率报错。

适用性
理论上支持所有支持 DDC/CI 的显示器。我目前在自己的设备上实现了分区调光和SRGB模式的自动切换，体验极为舒适。
文件下载：
显示器控制.zip (133.1 KB)

最后：
如果大家抓到了自己显示器特殊功能的 VCP Code，欢迎在评论区分享型号和代码，方便后来人！
格式参考：
显示器型号：LG 27GP950
功能：分区调光
VCP Code: 0x??
值：开=1, 关=0

之前发起了关于AI代码工具的调查问卷（第二次），共有5个问题：

[!info] 5 个问题

Q1 用过哪些 AI 编程工具？（多选）：用于统计各工具用过率
Q2 现在的主力 AI 编程工具是？（单选）：用于统计各工具主力率
Q3 认为目前最好的 AI 编程工具是？（单选）：用于统计各工具最佳率
Q4 手码的代码占比是多少？（单选）：用于观察AI 参与度的分布
Q5 对 AI 编程工具未来预期是？（单选）：用于观察整体预期的分布


第二次调查问卷已收集到较多样本。本文基于第二次调查问卷进行结果分析，并与第一次问卷结果分析进行对比。

[!success] 数据来源：第二次调查问卷

Q1 用过：512 人（多选，合计 2135 票，平均每人选 4.17 项）
Q2 主力：429 人（单选）
Q3 最佳：381 人（单选）
Q4 手码占比：358 人（单选）
Q5 未来预期：350 人（单选）



1. AI代码工具使用情况

[!warning] 方法论

用过率：在 Q1“用过哪些工具”中选择过该工具的比例
主力率：在 Q2“主力工具”中选择该工具的比例
最佳率：在 Q3“最好工具”中选择该工具的比例
忠诚度 = 主力率 / 用过率
好感度 = 最佳率 / 用过率
口碑差= 最佳率 - 主力率


1.1 第二次问卷核心工具表




工具
用过率
主力率
最佳率
主力/用过（忠诚度）
最佳/用过（好感度）
口碑差




Claude Code
56%
32%
48%
0.57
0.86
+16


Cursor
61%
19%
16%
0.31
0.26
-3


Augment
36%
14%
20%
0.39
0.56
+6


GitHub Copilot
34%
4%
1%
0.12
0.03
-3


Roo Code
29%
4%
2%
0.14
0.07
-2


Gemini CLI
28%
1%
1%
0.04
0.04
0


Trae
30%
2%
0%
0.07
0.00
-2


Codex
23%
5%
3%
0.22
0.13
-2


通义灵码
22%
1%
0%
0.05
0.00
-1


Kilo Code
20%
4%
1%
0.20
0.05
-3


Cline
19%
1%
1%
0.05
0.05
0


Windsurf
18%
1%
0%
0.06
0.00
-1


Warp
8%
1%
0%
0.13
0.00
-1


Gemini Code Assist
7%
0%
0%
0.00
0.00
0


Continue
5%
0%
0%
0.00
0.00
0



1.2 与第一次问卷对比




工具
用过率（第1→第2）
主力率（第1→第2）
最佳率（第1→第2）
忠诚度（第1→第2）
好感度（第1→第2）




Cursor
74% → 61%（-13）
33% → 19%（-14）
26% → 16%（-10）
0.45 → 0.31（-0.14）
0.35 → 0.26（-0.09）


Augment
49% → 36%（-13）
18% → 14%（-4）
25% → 20%（-5）
0.37 → 0.39（+0.02）
0.51 → 0.56（+0.05）


Claude Code
30% → 56%（+26）
10% → 32%（+22）
20% → 48%（+28）
0.33 → 0.57（+0.24）
0.67 → 0.86（+0.19）


GitHub Copilot
48% → 34%（-14）
12% → 4%（-8）
5% → 1%（-4）
0.25 → 0.12（-0.13）
0.10 → 0.03（-0.07）


Roo Code
29% → 29%（0）
6% → 4%（-2）
5% → 2%（-3）
0.21 → 0.14（-0.07）
0.17 → 0.07（-0.10）


Gemini CLI
25% → 28%（+3）
2% → 1%（-1）
2% → 1%（-1）
0.08 → 0.04（-0.04）
0.08 → 0.04（-0.04）


Cline
21% → 19%（-2）
1% → 1%（0）
1% → 1%（0）
0.05 → 0.05（0）
0.05 → 0.05（0）


Gemini Code Assist
11% → 7%（-4）
1% → 0%（-1）
0% → 0%（0）
0.09 → 0.00（-0.09）
0.00 → 0.00（0）


Kilo Code
9% → 20%（+11）
1% → 4%（+3）
1% → 1%（0）
0.11 → 0.20（+0.09）
0.11 → 0.05（-0.06）



楼主评价：

Claude Code 全面崛起：用过率/主力率/最佳率三项都显著提升，且口碑差进一步拉大，认可度 + 依赖度双上升。
Cursor 主力率与最佳率回落：依然很多人用过，但主力率与最佳率下降，感觉跟最近白嫖难度增加相关。
Augment 口碑依旧强：最佳率略高于主力率，好感度在头部工具里依然靠前。推测是因为现在白嫖难度极大。
Copilot 继续走弱：用过不低，但主力率与最佳率继续下降，且好感度进一步走低。据说微软都准备放弃Copilot了。
Kilo Code 用过率提升明显：用过率与主力率都增加，但最佳率没有增长，推测只是被很多人拿来当备胎。


2. 手码的代码占比
2.1 第二次问卷分布




手码占比
佬友占比




0%
25%


5%
19%


20%
17%


50%
18%


80%
11%


95%
5%


100%
5%



2.2 与第一次对比




手码占比
第一次
第二次
变化




0%
19%
25%
+6


5%
18%
19%
+1


20%
15%
17%
+2


50%
23%
18%
-5


80%
13%
11%
-2


95%
5%
5%
0


100%
7%
5%
-2



楼主评价：


平均手码≈32%（相比第一次的≈38%下降）。


如果剔除“0%（不写代码）”，只看仍在写代码的人，平均手码≈43%（第一次≈46%）。



3. 对AI代码工具的未来展望
3.1 第二次问卷分布




预期等级
佬友占比




极高
46%


高
43%


中
11%


低
0%


极低
0%



3.2 与第一次对比




预期等级
第一次
第二次
变化




极高
44%
46%
+2


高
40%
43%
+3


中
13%
11%
-2


低
2%
0%
-2


极低
1%
0%
-1



楼主评价：

正面期望（极高+高）从 84% 上升到 89%，更乐观了。

4. 结论


工具格局：Claude Code 目前遥遥领先；Cursor 和 Augment 等其它工具略有回落。


未来预期：平均手码从 38 %降到 32 %，对AI的正面期望从 84% 升至 89%，程序员的可替代性继续增加。



觉得有价值可以投喂LDC哦：1 LDC丨10 LDC丨50 LDC丨100 LDC

https://wcdk.224442.xyz/
怎么关闭了
我的钱啊，还没提呢

想做一个中转站，咨询一下佬友们现在比较稳/活得比较久点的2api有哪些。

项目白皮书：Web3影视共享社区 - [项目名称待定]
日期：2025年4月1日
版本：1.0

1. 项目愿景
1.1 背景
在Web 2.0时代，影视内容的创作、分发和消费高度依赖中心化平台（如YouTube、Netflix）。这些平台掌控用户数据、内容分发和收益分配，导致创作者收益受限，用户缺乏自主权。传统P2P分享（如BitTorrent）虽实现了去中心化分发，但缺乏可持续的激励机制和优质用户体验。
Web 3.0的兴起为重塑影视生态提供了契机。通过区块链、IPFS和去中心化技术，我们可以构建一个用户驱动的影视共享社区，让创作者和消费者共同掌控内容与价值。
1.2 使命
[项目名称]致力于打造一个去中心化的影视共享生态系统，用户既是内容的创造者和分享者，也是存储和分发的贡献者。通过分布式技术与代币激励，我们赋予用户数据主权、内容所有权和收益权利，重新定义影视行业的价值分配。
1.3 目标

提供高效、持久的去中心化影视存储与分发平台。
激励用户分享优质内容并贡献网络资源。
为独立创作者提供直接面向观众的渠道，绕过传统中介。


2. 项目概述
2.1 核心概念
[项目名称]是一个基于IPFS和区块链的Web3影视共享社区。用户通过独立运行的微端服务成为网络节点，上传、存储和分发影视资源。社区结合中心化的元数据管理、推荐系统和搜索功能，形成混合式架构，兼顾效率与去中心化。
2.2 功能亮点

去中心化存储：利用IPFS技术，影视资源分布在用户节点，降低中心化依赖。
独立微端服务：微端作为一个独立程序运行，用户可在一台或多台设备上部署多个实例，贡献存储和带宽。
多节点支持：单个用户可运营多个节点服务器，根据贡献度获得更高奖励。
代币激励：用户分享内容或提供节点服务可获得[代币名称]奖励，观看内容需支付代币。
内容推荐：智能算法基于用户行为推荐优质资源。
跨平台支持：提供桌面、移动端（iOS、安卓）和TV端（Android TV、Apple TV）客户端，优化多场景体验。
合法生态：聚焦独立创作者和公共领域内容，确保版权合规。


3. 技术架构
3.1 系统组件


微端服务（独立节点）

基于js-ipfs或go-ipfs开发的轻量级独立程序，通过API与主应用通信。
功能：上传影视资源、缓存热门内容、提供P2P分发。
多节点支持：用户可在一台或多台设备上运行多个微端实例，每个实例独立注册为IPFS节点。
动态调整：根据设备性能分配存储和带宽贡献，主应用提供统一管理界面。



IPFS网络

分布式存储协议，内容通过Content ID寻址。
支持HLS流式传输，实现边下边播，目标延迟<5秒。



区块链层

选用低成本公链（如Polygon或Solana），运行智能合约。
功能：记录交易、分配奖励、管理代币经济。



中心化服务

元数据刮削：从公开数据库提取影视信息（如标题、海报）。
推荐引擎：基于AI分析用户偏好。
搜索索引：提供快速资源检索。



主应用（跨平台客户端）

桌面端：支持Windows、macOS、Linux。
移动端：iOS和安卓原生应用，支持离线缓存。
TV端：适配Android TV和Apple TV，优化大屏播放。



3.2 工作流程

用户在一台或多台设备上启动多个微端实例，上传影视资源至IPFS，生成唯一Content ID。
元数据（标题、简介等）提交至中心化服务，社区审核后上链记录。
其他用户通过主应用搜索或推荐找到资源，支付[代币名称]从IPFS下载并观看。
分享者和节点贡献者（包括同一用户的多个微端）根据智能合约自动获得奖励。

3.3 技术优势

持久性：多节点缓存确保内容长期可用，平均缓存时间目标>30天。
效率：P2P分发分担带宽压力，支持大规模用户。
安全性：内容加密传输，保护用户隐私。
灵活性：独立微端支持多实例运行，适应不同用户需求。


4. 代币经济模型
4.1 代币概览

名称：[代币名称待定]
符号：[符号待定，例如FILM]
总量：1亿枚（可调整）
用途：支付观看费用、奖励分享与节点贡献。

4.2 代币分配

40%：社区奖励（分享者、节点运营者）
20%：团队开发与运营
20%：生态基金（营销、合作伙伴）
15%：早期用户与投资者
5%：预留

4.3 激励机制

分享奖励：每部资源被观看1次，分享者获得0.01代币（示例值）。
节点奖励：每贡献1GB存储或1Mbps带宽，获得0.005代币；同一用户多节点奖励按实例累计，高性能节点可获加成（如1.5倍）。
观看费用：观看1小时内容支付0.02代币（动态定价）。

4.4 经济循环

平台抽取5%-10%交易手续费，用于开发与生态维护。
设置代币销毁机制（如超额手续费销毁），控制通胀。


5. 法律与合规
5.1 版权策略

仅支持原创内容、公共领域作品或获得授权的影视资源。
实施社区审核与举报机制，移除侵权内容。

5.2 代币合规

将[代币名称]定位为“社区积分”，避免证券化风险。
根据运营地区咨询法律专家，确保符合当地监管要求。


6. 实施路线图
6.1 第一阶段

开发独立微端服务原型，支持单设备多实例运行。
搭建区块链奖励系统，测试多节点代币机制。
开发移动端（iOS、安卓）主应用原型。
招募早期用户，聚焦独立创作者。

6.2 第二阶段

优化视频流传输，集成HLS协议。
推出TV端（Android TV、Apple TV）客户端Beta版。
发布推荐引擎与搜索功能。
启动代币公开发行（若适用）。

6.3 第三阶段

扩展全球节点网络，引入超级节点。
与独立影视社区合作，扩大内容库。
实现生态自循环，减少外部补贴。


7. 团队与社区
7.1 核心团队

[待填：技术负责人、市场负责人等]
团队具备区块链、IPFS和影视行业经验。

7.2 社区参与

通过X、Discord等平台与用户互动。
鼓励开发者贡献代码，开放微端模块为开源。


8. 风险与挑战
8.1 技术风险

节点分布不均可能影响分发效率。
应对：初期部署种子节点，优化P2P算法，鼓励多节点运行。

8.2 法律风险

版权争议可能导致平台受限。
应对：严格内容审核，聚焦合法资源。

8.3 市场风险

用户接受度低可能影响生态启动。
应对：简化微端安装与主应用体验，提供早期奖励。


9. 结语
[项目名称]通过Web 3.0技术重塑影视分享生态，赋予用户前所未有的自主权与收益机会。独立微端和多节点支持的设计不仅提升了系统的灵活性，也为创作者和消费者提供了更公平的舞台。我们相信，这一去中心化社区将为独立影视行业带来革新，为用户带来全新的互动体验。加入我们，共同构建未来的数字内容世界！

后续步骤

命名：确定项目名称和代币符号，增强品牌识别度（建议：FilmWeb3、CineDAO、FILM）。
细节补充：填充团队信息、技术参数（如节点加成公式）。
反馈：请告诉我你对这份更新版白皮书的看法，或需要进一步调整的方向。

有一个需求绕不开。导致必须要使用 Google Drive 的容量存储和分享一些内容。然后免费账户的15G 实在是太少了。对这个产品不是很了解，所以想问一下有没有低成本可以长期稳定获得一个固定的容量的，比如说2t, 1t