标题: 想了想，还是把智谱的退款了
作者: #骑狗上学
板块: #搞七捻三
编号: 1689564
帖子: https://linux.do/t/topic/1689564
时间: 2026-03-04 19:50:24
摘要:

能全额退。还不错。 说实话的确是鸡肋。 Codex 又便宜又量大（当然基本白嫖），如果真的是需要Opus，中转站买吧。 国产的这一波，Minimax可能可以因为快且量大，虽然很蠢，但是有时候可能也能特殊地方有用。GLM的确是不行。 Kimi没用过，算了。。。。

标题: Chrome浏览器浏览ScienceDirect等网页时严重卡顿的解决笔记
作者: #hello
板块: #开发调优
编号: 1689565
帖子: https://linux.do/t/topic/1689565
时间: 2026-03-04 19:50:39
摘要:

Chrome浏览器浏览sciencedirect等网页时严重卡顿的解决笔记
(26.3.4)
笔者在使用Chrome浏览器浏览包括sciencedirect等学术网页时有时候会打开浏览器自带的翻译功能进行页面翻译，有时会导致非常严重的页面卡顿，表现为鼠标光标无法拖动，使用触控板返回桌面失效（延迟极高）等，影响工作节奏。
（关于使用DeepL等翻译插件是否卡顿，因使用较少，暂时没有印象）
近日再次遭遇这种情况后上网检索解决方案，发现有知乎网友提供了一种思路
(99+ 封私信 / 80 条消息) 浏览器全文翻译卡顿解决方法 - 知乎
遂前往该回答提及的GitHub项目的issues中查看
[Bug]: 浏览长网页并翻译，在请求译文时整个电脑变得很卡，鼠标都变卡了 打开控制台显示大量warning · Issue #1746 · immersive-translate/immersive-translate
这个解决方法是仅针对Chrome禁用微软的MPO服务

微软的 MPO（多平面叠加） 是一项 Windows 底层图形硬件加速技术，它允许显卡在输出画面信号的最后一刻，直接将网页、视频和系统 UI 等不同窗口像“透明薄膜”一样在物理层面上叠放合并，从而绕过原本极其消耗系统资源的软件合成步骤（DWM）。虽然这项技术的初衷是为了大幅降低硬件功耗、减少输入延迟并支持多窗口独立色彩输出，但由于它对显卡驱动的兼容性要求极高，近年来频繁出现图层调度错误，进而引发浏览器花屏、屏幕瞬间黑屏或网页彻底卡死冻结等严重 Bug.

将知乎中提到的方法喂给AI ，其提供的具体操作方法为，右键快捷方式，选择“属性”，在属性的目标选项的后面添加一个空格，然后输入--disable-direct-composition，点击确定。
经笔者测试，进行这样的操作后进入需要页面翻译的网页似乎确实不再卡顿，后续将在使用中跟踪观测。
本文还参考了：
解决Win11 24H2下网页卡屏\卡顿\显示残留的问题 | Bug侠
(99+ 封私信 / 80 条消息) Edge浏览器加载大页面卡顿解决办法 - 知乎

标题: 找L站邀请码的时候，有小某书用户让我直接进群，还能审核小作文
作者: #guxinlengyue
板块: #搞七捻三
编号: 1689578
帖子: https://linux.do/t/topic/1689578
时间: 2026-03-04 19:55:03
摘要:

民间自发审核组织？

标题: 图灵完备这个游戏大家都玩过吗
作者: #Steve Jobs
板块: #搞七捻三
编号: 1689582
帖子: https://linux.do/t/topic/1689582
时间: 2026-03-04 19:56:06
摘要:

听说还是不错的，适合新人入门汇编

标题: openclaw屎山代码发力！
作者: #翎
板块: #搞七捻三
编号: 1689587
帖子: https://linux.do/t/topic/1689587
时间: 2026-03-04 19:57:06
摘要:

Error: systemctl is-enabled unavailable: Command failed: systemctl --user is-enabled openclaw-gateway.service
鏖战三个小时未能安装成功
gpt、grok、gemini都搜不出个所以然，手动google直接检索到有用的Github issue

  

      github.com/openclaw/openclaw
  

  
    
  
   
  

  
    
      openclaw gateway status fails on EC2/headless servers due to missing user-level systemd
    

    
      
        已打开 10:33AM - 08 Feb 26 UTC
      


      
        
          
          niceysam
        
      
    

    
        
          bug
        
    
  


  
    # Issue: `openclaw gateway status` fails on EC2/headless servers due to missing …user-level systemd

## Summary
On headless EC2 instances (and similar server environments), `openclaw gateway status` and `openclaw gateway install` fail with "Failed to connect to bus: No medium found" because user-level systemd (`systemctl --user`) is unavailable by default.

##

标题: 想学AI不知道从哪学还来的及吗
作者: #Tangpi
板块: #搞七捻三
编号: 1689591
帖子: https://linux.do/t/topic/1689591
时间: 2026-03-04 19:58:17
摘要:

最近刷L站全是Ai相关的，不怕各位大佬笑话，真的是啥也看不懂，想看懂也是干着急，想学网上的教程也是眼花缭乱的不知道从哪学起，最近刷L站全是Ai相关的，不怕各位大佬笑话，真的是啥也看不懂，想看懂也是干着急，想学网上的教程也是眼花缭乱的不知道从哪学起。
本来以为就是点几下的事，结果一搜全是专业词，什么模型、插件、提示词、部署、云端本地，越看越懵。我就是个纯小白，电脑基础一般，也没什么编程底子，就想从最最基础的开始学，能慢慢跟上大家的节奏就行。
真心求问论坛里的大佬们：像我这种纯小白，第一步到底该干嘛？
有没有那种从零开始、一步一步教、不用折腾太复杂的入门路线？
先学什么、用什么软件、看哪些教程不容易踩坑？
不想一上来就劝退，真心想学，麻烦大佬们给指条明路，感激不尽！

标题: 实验跑着跑着就断了，好烦啊
作者: #csj
板块: #搞七捻三
编号: 1689611
帖子: https://linux.do/t/topic/1689611
时间: 2026-03-04 19:59:49
摘要:

人在旁边的时候一直跑，人一走就停止了，好邪乎啊，好烦啊

标题: 风萧萧机场无法连接
作者: #xxwa
板块: #开发调优
编号: 1689623
帖子: https://linux.do/t/topic/1689623
时间: 2026-03-04 20:02:52
摘要:

更新订阅突然报错成这样了，用的Flclash，有佬友知道是怎么回事吗？

标题: 【方案】解决Antigravity连接远程服务器无法AI对话（无sudo权限）
作者: #jasonli
板块: #开发调优
编号: 1689627
帖子: https://linux.do/t/topic/1689627
时间: 2026-03-04 20:03:29
摘要:

解决 Antigravity 连接远程服务器 AI 聊天连接失败：graftcp + mihomo 方案（无sudo权限也可）
背景与问题描述
最近，我用 Antigravity 自带的ssh连远程 Linux 服务器开发，代码能跑，但 AI 对话死活连不上。更麻烦的是：我在服务器上没有 sudo 权限。最后我用“用户态代理 + graftcp 劫持 + wrapper 替换”的组合拳把它修好了。主要有以下三个问题：

AI 聊天无法连接：提示 Cloud Code request timeout 或 Tools: Offline。
代理无效：即使服务器设置了 HTTP_PROXY，Antigravity 的核心进程（Go 编写）依然直连网络导致超时。
权限受限：在没有 sudo 权限的实验室或学校服务器上，无法安装系统级代理工具。

本教程通过 mihomo (Clash Meta) 建立底层代理，配合 graftcp 进行系统调用级劫持，彻底打通 Antigravity 的联网链路。

准备工作：在用户目录下安装核心组件
由于没有 sudo 权限，我们将所有工具安装在 ~/（Home 目录）下。
1. 部署 mihomo (Clash Meta) 内核
mihomo 负责维护与订阅节点的连接。

下载与解压：从 Mihomo Releases 下载 mihomo-linux-amd64-compatible-v1.19.17。
创建目录结构：

mkdir -p ~/mihomo/data/proxy_providers
cd ~/mihomo
chmod +x mihomo-linux-amd64-compatible



**编写 config.yaml**：
关键点：proxy-providers 的 path 必须位于 -d 指定的目录内。

port: 7890
socks-port: 7891
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

proxy-providers:
  subscription:
    type: http
    url: "你的订阅链接"
    interval: 3600
    path: ./subscription.yaml  # 必须在 data 目录下
proxy-groups:
  - name: PROXY
    type: select
    use: [subscription]
rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY



后台启动：

nohup ./mihomo-linux-amd64-compatible -d ./data -f ./config.yaml > proxy.log 2>&1 &


2. 编译安装 graftcp
graftcp 能劫持 Go 程序的 TCP 连接，强制其走 SOCKS5 代理。

安装 Go 环境（若服务器没有新版 Go）：

wget https://go.dev/dl/go1.24.7.linux-amd64.tar.gz
tar -xzf go1.24.7.linux-amd64.tar.gz -C ~
echo 'export PATH=$HOME/go/bin:$PATH' >> ~/.bashrc
source ~/.bashrc



设置 Go 国内镜像并编译：

export GOPROXY=https://goproxy.cn,direct
wget https://github.com/hmgle/graftcp/archive/refs/tags/v0.7.1.tar.gz
tar -xzf v0.7.1.tar.gz && cd graftcp-0.7.1
make



核心步骤：劫持 Antigravity 核心进程
Antigravity 启动时会拉起 language_server_linux_x64。我们需要用一个脚本“包装”它。
1. 寻找当前运行的二进制路径
Antigravity 经常更新，会产生多个版本目录。通过进程命令确认当前路径：
ps -ef | grep language_server_linux_x64


假设路径为：~/.antigravity-server/bin/1.19.5-xxxx/extensions/antigravity/bin/
2. 替换为 Wrapper 脚本

备份原程序：

mv language_server_linux_x64 language_server_linux_x64.bak



创建劫持脚本：
创建新文件 language_server_linux_x64，内容如下：

#!/usr/bin/env bash
GRAFTCP_DIR="$HOME/graftcp-0.7.1"
PROXY_SOCKS="127.0.0.1:7891"

# 自动启动 graftcp-local 监听器
if ! pgrep -f "graftcp-local" > /dev/null; then
  nohup "$GRAFTCP_DIR/local/graftcp-local" -socks5 "$PROXY_SOCKS" -listen 127.0.0.1:2233 -select_proxy_mode only_socks5 > /dev/null 2>&1 &
  sleep 0.5
fi

# 强制 Go 优化环境
export GODEBUG=netdns=cgo,http2client=0

# 执行原始程序
exec "$GRAFTCP_DIR/graftcp" -a 127.0.0.1 -p 2233 "$0.bak" "$@"



赋予权限：

chmod +x language_server_linux_x64



排查与验证

检查监听端口：
确保 7891 (mihomo) 和 2233 (graftcp-local) 都在 LISTEN 状态。

ss -lntp | grep -E '7891|2233'



强制重启服务：
修改完脚本后，必须杀掉旧进程，让 Antigravity 重新拉起：

pkill -f language_server_linux_x64



连接测试：
在服务器上测试 Cloud Code 接口连通性：

curl -I --socks5-hostname 127.0.0.1:7891 https://daily-cloudcode-pa.googleapis.com


只要返回 HTTP 状态码（如 404 或 200），而非 Timeout，说明代理链路已通。

踩坑总结与 Tips

SSH 断连问题：开启本地 TUN 模式可能导致 SSH 路由冲突，触发 Software caused connection abort。建议在 SSH 客户端开启 ServerAliveInterval 30 或在代理软件中排除 SSH 端口。
版本更新：Antigravity 更新后会生成新的版本文件夹，导致原有的 Wrapper 失效。此时需要将脚本重新应用到新文件夹下的二进制文件。
Ptrace 权限：若报错无法劫持，请检查 /proc/sys/kernel/yama/ptrace_scope。若为 1，确保 Wrapper 是通过父进程拉起的；若为 2/3 且无 sudo 权限，此方案可能失效。


刚看到一个老哥在问 正好前两天也遇到了，就总结一下发出来吧，
== 但是现在有个问题，不连续对话后过一会再聊天还是不行，需要重启应用或者重连，排查了很久也没排查出来 ==
—【求助】代理环境下 Google Code Assist OAuth 认证失败 + Antigravity remote-ssh 配置

标题: 【求助】Win 下文件的默认应用
作者: #xiaokcoding
板块: #开发调优
编号: 1689628
帖子: https://linux.do/t/topic/1689628
时间: 2026-03-04 20:03:31
摘要:

如图，经常这样，在设置中设置完之后，过一段时间自己就没了，昨天py的掉了，前几天是js…

标题: 关于AI的系统化开发流程个人感悟。
作者: #野原广志
板块: #开发调优
编号: 1689631
帖子: https://linux.do/t/topic/1689631
时间: 2026-03-04 20:04:12
摘要:

从「拆 + 并行」到「写 + 质量」：我在 AI 时代的系统化开发流程个人感悟
AI 把“写代码”这件事的边际成本打到了极低。你可以在一个下午里让 agent 产出成百上千行“看起来很像那么回事”的改动——但真正决定项目成败的，反而变成了另一件事：

你是否有一套稳定的流程，让 AI 的产能变成可控的工程增量，而不是随机游走的“vibe output”。

我踩过最典型的坑是：越写越快、越写越乱；上下文越来越长，模型开始“跑偏”，最后把自己也绕进去了。GSD 把这种现象直接点名为 context rot（上下文腐烂）：会话越长、上下文越拥挤，质量越容易下降。(GitHub)
这和很多人的经验一致：AI coding 不是魔法按钮，它更像“很强的初级工程师”，需要你给它结构、边界、验收标准。(addyosmani.com)
我后来逐步稳定下来的一套实践，可以概括成你说的那句话：

GSD 管“怎么拆 + 怎么并行”（宏观推进：规划、分期、任务波次、上下文刷新）
Superpowers 管“怎么写 + 怎么保证质量”（微观工程：TDD、审查、worktree、验证与收尾）

两者不是替代关系，而是互补：用 GSD 做整体规划，在关键任务里调用 Superpowers 的 TDD 技能，是我目前最满意、也最不容易翻车的组合。

1）先把问题讲清楚：AI 开发的“生产力悖论”
AI 让“产出”变得极其便宜，但也让两件事更难了：

一致性更难：一次性生成太多，很容易出现“像 10 个开发没沟通就开工”的碎片化结果。(addyosmani.com)
可信度更难：AI 会非常自信地写错，且不会主动告诉你它错了——所以你必须把“验证”内建进流程。(addyosmani.com)

Simon Willison 对 vibe coding 的定义很直白：不审查代码、让它“随便冲”，它适合低风险原型，但不该拿来推生产。(Simon Willison’s Weblog)
换句话说：越是关键需求，越不能靠感觉。

2）我的核心框架：双层操作系统（Macro / Micro）
我把 AI 开发流程拆成两层：
A. 宏观层（Macro）：把“项目推进”变成可计算的流程
这层我交给 GSD。
GSD 的设计思路是：通过元提示词与上下文工程，把“从想法到落地”的链路变成分阶段、可验收、可并行的流水线，并且显式对抗 context rot。(GitHub)
它的 phase 流程里，有几个我非常买账的点：

先问清楚再动手：初始化阶段会不断追问目标、约束、偏好、边界条件，然后抽出 v1/v2/不做什么。(GitHub)
计划足够小：把 plan 切到“小到可以放进一次全新上下文窗口”的粒度，避免越聊越烂。(GitHub)
并行是“按波次”并行：同一波并行、波与波串行，用依赖关系来约束并行带来的混乱。(GitHub)
每个任务原子提交：把 AI 的改动切成可回滚、可追溯的颗粒度。(GitHub)

这层解决的不是“写代码技巧”，而是让工程推进具备节奏感和可控性。
B. 微观层（Micro）：把“写代码”变成可验证的红绿循环
这层我交给 Superpowers。
Superpowers 的定位非常明确：它是一套给 coding agent 的软件工程工作流，强调先把 spec 拉出来、先过设计、再写计划、再实现，并且把 **TDD（RED-GREEN-REFACTOR）**当成强约束。(GitHub)
它的“Basic Workflow”基本就是我想要的“质量护栏”：

brainstorming（先澄清需求、沉淀设计文档）
writing-plans（拆成 2–5 分钟级别的小任务，每个任务给出文件路径与验证步骤）
subagent-driven-development（分任务执行 + 双阶段 review：先看是否符合 spec，再看代码质量）
test-driven-development（强制红-绿-重构；甚至会删掉“先写实现后补测试”的代码）
requesting-code-review / finishing-a-development-branch（审查、验收、合并/PR/清理）(GitHub)

这层解决的是：怎么写得稳、怎么写得能持续维护。

3）把两套拼起来：我现在的“最佳实践流水线”
一句话总结：

GSD 负责把战役打成“阶段 + 波次 + 原子任务”，Superpowers 负责把关键任务打成“红-绿-重构 + 强审查”。

下面是我常用的落地步骤（你可以把它当成“个人开发 SOP”）：
Step 0：先把“Definition of Done（完成标准）”写出来
我会借用 Spec-Then-Code 的一句原则：Evidence over Assertions（证据大于口头完成）。(GitHub)
意思是：别信“我做完了”，只信：

测试通过（新增测试覆盖关键行为）
关键路径可运行（命令、接口、UI 流程可复现）
性能/安全/兼容性有最基本的验证（按风险等级决定）(addyosmani.com)

Step 1：用 GSD 做“全局规划”
目标是产出：路线图、阶段拆分、范围边界。GSD 的流程里会把 v1/v2/out-of-scope 摘出来，并把 roadmap 分 phase。(GitHub)
这一步的价值在于：你后面每一次 prompt 都是在执行计划，而不是在重新发明计划。
Step 2：每个 Phase 先“讨论偏好”，再“计划任务”
我很认同 GSD 的一个设计：先把灰度地带问透（比如 UI 密度、API 返回格式、错误处理风格、内容系统的语气深度等），沉淀成上下文文档，再去研究和计划。(GitHub)
这能显著减少“AI 自作主张的默认值”带来的返工。
Step 3：执行阶段：按波次并行，但“关键任务走 Superpowers”
GSD 的 execute-phase 会把任务按依赖关系编成 waves，同 wave 并行。(GitHub)
我会在计划阶段就做一个标记：

低风险/可目测的任务：正常并行执行（脚手架、样式、简单 CRUD、文案等）
高风险/不可目测的任务：强制走 Superpowers 的 TDD 与 review（权限、计费、数据一致性、并发、核心算法、迁移脚本等）(GitHub)

这就是“你说的最佳实践”：GSD 管整体，Superpowers 保关键点质量。
Step 4：把“上下文刷新”当成制度，而不是临时补救
GSD 之所以强调 plan 足够小、每个 plan 都能在“新鲜上下文”里跑完，本质是在制度化对抗 context rot。(GitHub)
这和很多人经验一致：不要在一条超长对话里死磕；该切就切，该重置就重置。(addyosmani.com)
Step 5：小步提交 + 双重审查
Addy Osmani 提到一个特别像“游戏存档点”的习惯：commit often，把 AI 的每次推进都变成可回滚的增量。(addyosmani.com)
Superpowers 也把 code review 作为流程技能的一部分（而不是可选项）。(GitHub)
我的习惯是：

每个原子任务一个提交（或一个 PR 内的独立 commit）
让第二个 agent/第二个模型专门做 review（“审 spec”“审质量”分开看）
卡住就回退到上一个“绿色提交点”，不要在错误方向上叠 buff


4）我常用的提示词模板（可直接复制）
下面这些模板的目标是：把“口头愿望”变成“可执行任务”。
模板 A：把需求变成可验收标准（DoD）
请把这个需求改写成可验证的 Definition of Done：
1) 必须满足的行为（Given/When/Then）
2) 必须新增/更新的测试（单测/集成测试/契约测试）
3) 不做什么（out of scope）
4) 风险点与验证手段（最少要跑哪些命令/用哪些用例验证）

（对应“证据 > 完成宣称”的思路）(GitHub)
模板 B：把计划切到“新鲜上下文可完成”
把实现计划拆成多个原子任务：
- 每个任务 2~10 分钟可完成
- 写清楚要改哪些文件、加哪些函数、影响哪些接口
- 每个任务都包含验证步骤（跑哪些测试/命令）
- 标注依赖关系，按 waves 分组：同 wave 可并行、wave 之间串行

（对应 GSD 的 plan/waves 思路）(GitHub)
模板 C：关键任务强制 TDD
对这个任务请严格 RED-GREEN-REFACTOR：
1) 先写一个会失败的测试（解释失败原因）
2) 写最小实现让测试变绿
3) 重构并保持全绿
每一步都要给出“我应该运行什么”来验证

（对应 Superpowers 的 test-driven-development 工作流）(GitHub)

5）什么时候我会“降级流程”？（别把流程当宗教）
最后说一个很现实的点：流程是为了降低风险，不是为了仪式感。

如果只是低风险原型、视觉 demo、一次性脚本，我会更接近 Simon Willison 说的那种 vibe coding：快、爽、低成本试错。(Simon Willison’s Weblog)
但只要是跨模块改动 / 会影响数据与用户 / 需要长期维

标题: linux.do email protection ?
作者: #taloslhan
板块: #运营反馈
编号: 1689635
帖子: https://linux.do/t/topic/1689635
时间: 2026-03-04 20:05:54
摘要:

如图所示，这个是什么问题。。。我用的是标准的 chrome 浏览器啊