stream disconnected before completion: Transport error: timeout 问一下 最近频繁出现这个问题 自己接的cpa 是vps的问题还是我的网络问题啊 之前好像基本没有这个问题的 这两天好严重 求佬友解答 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://github.com/Nour833/StegoForge Comments URL: https://news.ycombinator.com/item?id=47816491 Points: 1 # Comments: 0
Comments URL: https://news.ycombinator.com/item?id=47816451 Points: 1 # Comments: 0
用 dokploy 部署任何项目真的很轻松，什么GitHub docker dockerfile Compose等等，全都可以搞。我自己部署了中转，CDK卡密，导航站，sora去水印好几个项目都在里面。服务器搞的是RN的6G内存美区服务器，带宽好像是万兆的。宝塔和dokploy比较，现在我喜欢dokploy这工具。不懂怎么配置，一步一步截图问codex，轻轻松松搞起来。 12 个帖子 - 7 位参与者 阅读完整话题
我这么大一个 不支持codex，只支持/v1/chat/completions请求 没人看见吗？ 后台全是报错。。。。。。 （刚好当鉴别机器人了。。。。。。） 17 个帖子 - 12 位参与者 阅读完整话题
Email Signature Builder that is completely free, supports placeholders, and with WYSIWYG / HTML Editor you're completely free to build it your way. Comments URL: https://news.ycombinator.com/item?id=47815858 Points: 1 # Comments: 0
cloud.tencent.com 大模型服务平台 TokenHub Token Plan 企业版套 产品简介 Token Plan企业版 - TokenHub - 控制台 看起来是 11亿 5000块的样子… 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下全是我自己手搓，没有ai味（我用最真实、最不绕、最直接的方式跟你讲 hhhhh），放心品尝 很多人以为 Skill 迭代最难的是"怎么改"。 但我越来越强烈地觉得，真正难的其实不是改，而是： 你改完之后，根本不知道它到底有没有真的变好。 补描述、调 prompt、加例子、补边界、改结构。 Skill 看起来越来越完整，文档越来越像样，语气越来越专业。 但问题是： 看起来更完整，不等于真的更强。 skill的实际行为未必更稳定，边界未必更清晰，失败处理也未必更好。 所以很多 Skill 维护最别扭的地方，其实不是"不会写"，而是你明明已经改了很多轮，却还是说不清： 上一次改动，到底有没有真正产生作用。 我后来专门跑了 100 个高下载 Skill，发现问题并不是"不能用" （是的，烧我自己的token）结果最有意思的地方，不是烂 Skill 特别多。恰恰相反，大多数 skill 其实都能用： 70 个通过 29 个在 caution 区间 1 个 fail 平均分 73.8 真正的问题不是：大多数 Skill 完全不能用。 而是 很多 Skill 停在一个很尴尬的状态：能用，但不容易被继续有效优化。 你一旦想认真往上修，就会发现问题不少，但很难判断到底该先修哪一块。 也就是说，难点不是"没法写"，而是 没有诊断，所以不知道怎么有效地继续改。 更关键的是，这种"不对劲"还不是随机的。 我看到的弱点主要集中在几个地方： Trigger quality 平均 6.2 Functional quality 平均 6.6 大约 80% 缺少 not_for 边界 大约 60% 的 D4 弱项 Skill 缺少像样的 error recovery guidance 还有接近 40% 更像"写给人看的说明书"，而不是"写给模型执行的操作说明" 这里翻译成人话就是： 很多 Skill 不是坏在"完全不能用"，而是坏在几个特别重复的地方：不会划边界，不会处理失败，也没有把行为写得足够可执行。 所以我后来做了 SkillCompass 我想解决的，不是"怎么把 Skill 写得更长、更完整"，而是另一件更关键的事： 在你动手优化之前，先看清问题到底在哪；在你改完之后，再验证这次修改有没有真的产生提升。 所以对我来说，SkillCompass 不是一个"给 Skill 打个分"的工具而已。 它更像一个给 Skill 迭代提供方向感的东西： 现在最弱的是哪一维 下一步该先修哪里 这轮修改有没有真的带来提升 有没有把别的地方一起改坏 【这里插一句compass 这个名字，指南针🧭，其实也是这个意思。不是替你做决定，而是先帮你定位方向。 】 所以它背后的设计原则也很简单： 本地优先 ：所有数据都留在本机，除非你明确要求，否则不会主动发起网络请求 默认只读 ：评估和报告默认不改文件，improve、merge、rollback 这类写入操作都要明确开启 被动追踪，主动决策 ：Hooks 会收集使用数据，但系统只给建议，不会自动替你执行 双通道交互 ：既支持键盘选择，也支持自然语言查询，两种方式始终都可用 同时我把评估分成了6个维度；把判定标准分成3档 它不是在帮你"多改一点"，而是在帮你把迭代变成一个可验证的流程 与其盲目地"再多写一点"，不如把 Skill 迭代拆成一个更清晰的 workflow。下面拿agile-product-owner作为一个例子展开讲讲： 1）先诊断 不要一上来就改。先看清楚最弱的是哪一维。 很多时候你以为问题在 wording，实际可能卡在 trigger、边界、失败处理，或者执行指令根本不够可操作。 先把最弱项找出来，后面的修改才不是瞎试。 接着它出一个初步的报告，包含维度1-3，后面会有一个完整的全方位维度1-6的测评报告（看下图）： 2）再看单项到底在说什么 我觉得这一步特别重要。 因为很多人一看到分数，会下意识觉得"哦，这项低，那我去多写一点"。 但 SkillCompass 真正有价值的地方，不是只给分，而是会把某个维度为什么高、为什么不满分、它到底在判断什么，说得更清楚。 比如拿 D6 = Uniqueness（独特性 / 不容易被替代） 来说，它看的不是"你这段话写得顺不顺"，而是在看： 这个 skill 是不是真的有独立价值 有没有明显重复品 跟相似 skill 重合度高不高 是不是一句普通 prompt 就能替代 它是不是很快就会过时 这里个skill的这一维最后给到 8 分，不是说它不好，而是说：它已经有明确领域专属性，也不太容易被普通 prompt 替代，但还没有强到"极其不可替代"的程度。 3）定点修复，而不是整份 Skill 重写 找到弱项之后，不是整份 skill 重写一遍。 而是只修最该修的那一块。所以我们把弱项加强，不好的修正，但不污染上下文 **这里要敲重点！！！**它做了那段分数解释，并且新版分更高的同时也没有把别的地方改坏，因为修改目标清楚，而且不会为了补一个问题，把别的地方一起搅乱。 此时，SkillCompass 已经完成这轮评估/优化结果的写入（提升了 D5），没有出现回归，然后把新的评估记录和最新扫描时间写进本地文件。 4）改完再验证，千万不要靠感觉收工 改完不能靠"看起来更完整了"就结束。要重新验证这次修改到底有没有带来真实提升。 分数有没有上去，解释有没有更扎实，别的维度有没有被改坏，这些都得重新看。 （（（兄弟们，有效的优化才叫"迭代"，不然就是屎上雕花。））） 5）再找下一个瓶颈 一个问题修完，不代表 skill 就完成了。 通常是这个瓶颈被拿掉之后，下一个瓶颈才会浮出来。 所以真正有效的迭代，不是一次性改到完美，而是持续地： 诊断问题 → 定向修复 → 验证提升 → 找到下一个瓶颈 这也是我现在更认同的一种 Skill 迭代方式：不是凭感觉打磨，而是把迭代变成一个更可验证的 workflow。 适合什么人，不适合什么人 适合： 任何在维护 agent skills，并且希望质量能够被量化的人 想要有明确改进方向的开发者—不是靠猜，而是清楚知道下一步该修哪个维度 需要质量门槛的团队—任何会改动 skill 的工具，都可以在改动后自动接受评估 安装了很多 skills、想看清哪些真的在用、哪些已经陈旧、哪些存在风险的用户 不适合： 通用代码审查或运行时调试 从零创建新 skill（这个更适合用 skill-creator） 评估非 skill 类型的文件 项目在这里： github.com GitHub - Evol-ai/SkillCompass: Evaluate agent skill quality. Find the weakest… 有兴趣的佬欢迎去 GitHub 点个 star 支持一下。 如果你手上也有自己的 SKILL.md，欢迎直接贴出来，我这边也可以顺手用 SkillCompass 帮你跑一遍测评。 有问题也欢迎一起聊，也可以 fork 回去自己改着玩 2 个帖子 - 2 位参与者 阅读完整话题
https://www.nature.com/articles/s41586-026-10319-8 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://github.com/Higangssh/pvm Comments URL: https://news.ycombinator.com/item?id=47815391 Points: 4 # Comments: 0
150 applications. One offer. Each application took 5+ manual steps. Separate tools, separate tabs, separate sites — none of them talking to each other. Generic output. Over an hour per application. Paste a job description — or pull it from any job site with the Chrome extension — and five AI agents run an orchestrated pipeline in under 30 seconds: analyzing the role, scoring your fit, researching the company, writing a targeted cover letter, and tailoring your resume to the role. Sequential where it needs to be, parallel where it can be, each agent's output feeding the next. Also includes a dashboard to track every application. And tools for everything around it: interview prep with mock sessions, salary negotiation, job comparison, follow-ups, thank you notes, and references. Runs on your machine. No subscriptions, no data stored on our servers — just your own Gemini API key connecting directly to Google. Comments URL: https://news.ycombinator.com/item?id=47815326 Points: 1 # Comments: 0
https://musclewiki.com/ 自己最近在健身 教练分享的 8 个帖子 - 7 位参与者 阅读完整话题
Article URL: https://github.com/eph5xx/tweakidea Comments URL: https://news.ycombinator.com/item?id=47815028 Points: 1 # Comments: 0
Article URL: https://itlinks.me Comments URL: https://news.ycombinator.com/item?id=47814937 Points: 2 # Comments: 0
wallstreetcn.com 一个时代落幕：三星关闭旧款内存订单窗口，行业加速向下一代内存迁移 三星电子正式终止LPDDR4和LPDDR4X移动DRAM的新增订单接收，标志着这两款量产逾十年的主流内存产品进入生命周期终结阶段。相关产线预计明年一季度启动转换，三星借此加速向更高性能制程迁移。 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://greatapps.net/ Comments URL: https://news.ycombinator.com/item?id=47814857 Points: 3 # Comments: 1
Article URL: https://github.com/AssafWoo/homebrew-pandafilter Comments URL: https://news.ycombinator.com/item?id=47814614 Points: 3 # Comments: 0
本人一直想要搭建一个中转站，偶然看见sub2api，故使用它搭建了一个，以下是步骤： 先约定 3 个你要替换的值： api.example.com ：改成你的域名 [email protected] ：改成你的管理员邮箱 CHANGE_ME... ：改成你自己生成的随机密钥 1）登录服务器并更新系统 ssh root@你的服务器IP apt update apt -y upgrade timedatectl 这一步是基础准备，先把系统更新到当前仓库版本，并确认时间正常。时间不准会影响 HTTPS、登录态和支付回调之类的功能。Docker 官方当前 Ubuntu 安装文档仍然建议使用官方 apt 仓库安装 Docker Engine。 2）安装 Docker Engine 和 Docker Compose v2 先卸载可能冲突的旧包： for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do apt-get remove -y $pkg done 安装 Docker 官方仓库： apt-get update apt-get install -y ca-certificates curl install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc chmod a+r /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \ > /etc/apt/sources.list.d/docker.list 安装 Docker 和 Compose 插件： apt-get update apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 检查版本： docker --version docker compose version systemctl enable docker systemctl start docker systemctl status docker --no-pager Docker 官方当前安装文档给出的推荐安装包名就是 docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 。另外，Docker 也明确提醒：如果你用 UFW 或 firewalld，Docker 暴露出来的端口可能绕过防火墙表面规则，所以正式环境尽量只暴露 80/443，把 8080 留给本机反代。 3）安装 Git、openssl 和基础工具 apt-get install -y git curl wget nano openssl ufw 这些工具后面都会用到： git 拉仓库 openssl 生成密钥 nano 编辑配置 ufw 放行 80/443/22 4）准备部署目录并拉取官方文件 mkdir -p /opt/sub2api cd /opt/sub2api git clone https://github.com/Wei-Shaw/sub2api.git source cp source/deploy/docker-compose.local.yml . cp source/deploy/.env.example .env cp source/deploy/config.example.yaml config.yaml Sub2API 官方部署说明里，手动部署路径就是：克隆仓库、复制 .env.example 、创建 data postgres_data redis_data ，再用 docker-compose.local.yml 启动；并且官方明确把 local 版描述为“本地目录、易迁移”。 5）生成生产环境密钥 先生成三个随机值： openssl rand -hex 32 openssl rand -hex 32 openssl rand -hex 32 把输出保存下来，分别用于： POSTGRES_PASSWORD JWT_SECRET TOTP_ENCRYPTION_KEY 官方 .env 模板和部署说明都强调： POSTGRES_PASSWORD 必填，而 JWT_SECRET 和 TOTP_ENCRYPTION_KEY 最好固定，否则会影响持久登录态和 2FA。 6）写入最终版 .env cat > /opt/sub2api/.env <<'EOF' BIND_HOST=127.0.0.1 SERVER_PORT=8080 SERVER_MODE=release RUN_MODE=standard TZ=Asia/Shanghai POSTGRES_USER=sub2api POSTGRES_PASSWORD=CHANGE_ME_TO_A_LONG_RANDOM_PASSWORD POSTGRES_DB=sub2api DATABASE_MAX_OPEN_CONNS=50 DATABASE_MAX_IDLE_CONNS=10 DATABASE_CONN_MAX_LIFETIME_MINUTES=30 DATABASE_CONN_MAX_IDLE_TIME_MINUTES=5 REDIS_PASSWORD= REDIS_DB=0 REDIS_POOL_SIZE=1024 REDIS_MIN_IDLE_CONNS=10 REDIS_ENABLE_TLS=false [email protected] ADMIN_PASSWORD= JWT_SECRET=CHANGE_ME_TO_A_LONG_RANDOM_HEX_STRING JWT_EXPIRE_HOUR=24 JWT_ACCESS_TOKEN_EXPIRE_MINUTES=0 TOTP_ENCRYPTION_KEY=CHANGE_ME_TO_ANOTHER_LONG_RANDOM_HEX_STRING GEMINI_OAUTH_CLIENT_ID= GEMINI_OAUTH_CLIENT_SECRET= GEMINI_OAUTH_SCOPES= GEMINI_QUOTA_POLICY= GEMINI_CLI_OAUTH_CLIENT_SECRET= ANTIGRAVITY_OAUTH_CLIENT_SECRET= SECURITY_URL_ALLOWLIST_ENABLED=true SECURITY_URL_ALLOWLIST_ALLOW_INSECURE_HTTP=false SECURITY_URL_ALLOWLIST_ALLOW_PRIVATE_HOSTS=false SECURITY_URL_ALLOWLIST_UPSTREAM_HOSTS= UPDATE_PROXY_URL= EOF 然后编辑，把占位符改成你自己的值： nano /opt/sub2api/.env 这里我保留了 .env 里的基础白名单开关，但把域名清单放到 config.yaml 里统一管理，因为官方 config.example.yaml 里真正完整的 URL 白名单字段在 security.url_allowlist 下。 7）写入最终版 config.yaml cat > /opt/sub2api/config.yaml <<'EOF' server: host: "0.0.0.0" port: 8080 mode: "release" frontend_url: "https://api.example.com" trusted_proxies: [] max_request_body_size: 268435456 h2c: enabled: true max_concurrent_streams: 50 idle_timeout: 75 max_read_frame_size: 1048576 max_upload_buffer_per_connection: 2097152 max_upload_buffer_per_stream: 524288 run_mode: "standard" cors: allowed_origins: - "https://api.example.com" allow_credentials: true security: url_allowlist: enabled: true upstream_hosts: - "api.openai.com" - "api.anthropic.com" - "generativelanguage.googleapis.com" - "cloudcode-pa.googleapis.com" - "*.openai.azure.com" pricing_hosts: - "raw.githubusercontent.com" crs_hosts: [] allow_private_hosts: false allow_insecure_http: false response_headers: enabled: true additional_allowed: [] force_remove: [] csp: enabled: true policy: "default-src 'self'; script-src 'self' __CSP_NONCE__ https://challenges.cloudflare.com https://static.cloudflareinsights.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https:; frame-src https://challenges.cloudflare.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" proxy_probe: insecure_skip_verify: false proxy_fallback: allow_direct_on_error: false EOF 改域名： nano /opt/sub2api/config.yaml 官方当前配置示例里， frontend_url 用于生成邮件等外部链接；URL 白名单示例里也明确列出了 upstream_hosts 、 pricing_hosts 、 crs_hosts 、 allow_private_hosts 、 allow_insecure_http 。我这里把样例里的 allow_private_hosts 和 allow_insecure_http 从 true 收紧成了更适合公网生产的 false 。 8）写入最终版 docker-compose.local.yml cat > /opt/sub2api/docker-compose.local.yml <<'EOF' services: sub2api: image: weishaw/sub2api:latest container_name: sub2api restart: unless-stopped ulimits: nofile: soft: 100000 hard: 100000 ports: - "${BIND_HOST:-127.0.0.1}:${SERVER_PORT:-8080}:8080" volumes: - ./data:/app/data - ./config.yaml:/app/data/config.yaml:ro environment: - AUTO_SETUP=true - SERVER_HOST=0.0.0.0 - SERVER_PORT=8080 - SERVER_MODE=${SERVER_MODE:-release} - RUN_MODE=${RUN_MODE:-standard} - DATABASE_HOST=postgres - DATABASE_PORT=5432 - DATABASE_USER=${POSTGRES_USER:-sub2api} - DATABASE_PASSWORD=${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required} - DATABASE_DBNAME=${POSTGRES_DB:-sub2api} - DATABASE_SSLMODE=disable - DATABASE_MAX_OPEN_CONNS=${DATABASE_MAX_OPEN_CONNS:-50} - DATABASE_MAX_IDLE_CONNS=${DATABASE_MAX_IDLE_CONNS:-10} - DATABASE_CONN_MAX_LIFETIME_MINUTES=${DATABASE_CONN_MAX_LIFETIME_MINUTES:-30} - DATABASE_CONN_MAX_IDLE_TIME_MINUTES=${DATABASE_CONN_MAX_IDLE_TIME_MINUTES:-5} - REDIS_HOST=redis - REDIS_PORT=6379 - REDIS_PASSWORD=${REDIS_PASSWORD:-} - REDIS_DB=${REDIS_DB:-0} - REDIS_POOL_SIZE=${REDIS_POOL_SIZE:-1024} - REDIS_MIN_IDLE_CONNS=${REDIS_MIN_IDLE_CONNS:-10} - REDIS_ENABLE_TLS=${REDIS_ENABLE_TLS:-false} - ADMIN_EMAIL=${ADMIN_EMAIL:[email protected]} - ADMIN_PASSWORD=${ADMIN_PASSWORD:-} - JWT_SECRET=${JWT_SECRET:-} - JWT_EXPIRE_HOUR=${JWT_EXPIRE_HOUR:-24} - JWT_ACCESS_TOKEN_EXPIRE_MINUTES=${JWT_ACCESS_TOKEN_EXPIRE_MINUTES:-0} - TOTP_ENCRYPTION_KEY=${TOTP_ENCRYPTION_KEY:-} - TZ=${TZ:-Asia/Shanghai} - GEMINI_OAUTH_CLIENT_ID=${GEMINI_OAUTH_CLIENT_ID:-} - GEMINI_OAUTH_CLIENT_SECRET=${GEMINI_OAUTH_CLIENT_SECRET:-} - GEMINI_OAUTH_SCOPES=${GEMINI_OAUTH_SCOPES:-} - GEMINI_QUOTA_POLICY=${GEMINI_QUOTA_POLICY:-} - GEMINI_CLI_OAUTH_CLIENT_SECRET=${GEMINI_CLI_OAUTH_CLIENT_SECRET:-} - ANTIGRAVITY_OAUTH_CLIENT_SECRET=${ANTIGRAVITY_OAUTH_CLIENT_SECRET:-} - SECURITY_URL_ALLOWLIST_ENABLED=${SECURITY_URL_ALLOWLIST_ENABLED:-true} - SECURITY_URL_ALLOWLIST_ALLOW_INSECURE_HTTP=${SECURITY_URL_ALLOWLIST_ALLOW_INSECURE_HTTP:-false} - SECURITY_URL_ALLOWLIST_ALLOW_PRIVATE_HOSTS=${SECURITY_URL_ALLOWLIST_ALLOW_PRIVATE_HOSTS:-false} - SECURITY_URL_ALLOWLIST_UPSTREAM_HOSTS=${SECURITY_URL_ALLOWLIST_UPSTREAM_HOSTS:-} - UPDATE_PROXY_URL=${UPDATE_PROXY_URL:-} depends_on: postgres: condition: service_healthy redis: condition: service_healthy networks: - sub2api-network healthcheck: test: ["CMD", "wget", "-q", "-T", "5", "-O", "/dev/null", "http://localhost:8080/health"] interval: 30s timeout: 10s retries: 3 start_period: 30s postgres: image: postgres:18-alpine container_name: sub2api-postgres restart: unless-stopped ulimits: nofile: soft: 100000 hard: 100000 volumes: - ./postgres_data:/var/lib/postgresql/data environment: - POSTGRES_USER=${POSTGRES_USER:-sub2api} - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required} - POSTGRES_DB=${POSTGRES_DB:-sub2api} - PGDATA=/var/lib/postgresql/data - TZ=${TZ:-Asia/Shanghai} networks: - sub2api-network healthcheck: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-sub2api} -d ${POSTGRES_DB:-sub2api}"] interval: 10s timeout: 5s retries: 5 start_period: 10s redis: image: redis:8-alpine container_name: sub2api-redis restart: unless-stopped ulimits: nofile: soft: 100000 hard: 100000 volumes: - ./redis_data:/data command: > sh -c ' redis-server --save 60 1 --appendonly yes --appendfsync everysec ${REDIS_PASSWORD:+--requirepass "$REDIS_PASSWORD"} ' environment: - TZ=${TZ:-Asia/Shanghai} - REDISCLI_AUTH=${REDIS_PASSWORD:-} networks: - sub2api-network healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s timeout: 5s retries: 5 start_period: 5s networks: sub2api-network: driver: bridge EOF 这份 compose 依然遵循官方 local 版思路：本地目录持久化、 weishaw/sub2api:latest + postgres:18-alpine + redis:8-alpine 、 /health 健康检查；另外我把 config.yaml 的挂载打开了，因为官方默认是注释状态。 9）创建数据目录并启动容器 cd /opt/sub2api mkdir -p data postgres_data redis_data docker compose -f docker-compose.local.yml up -d docker compose -f docker-compose.local.yml ps 如果一切正常，再看日志： docker compose -f docker-compose.local.yml logs -f sub2api Sub2API 官方说明里写得很明确：Compose 模式下 AUTO_SETUP=true 时，首次启动会自动连接 PostgreSQL 和 Redis、执行数据库迁移、创建管理员账号、在未提供时自动生成管理员密码。 10）取出管理员密码并做健康检查 如果你在 .env 里把 ADMIN_PASSWORD= 留空，就执行： docker compose -f docker-compose.local.yml logs sub2api | grep -i "admin password" 本机健康检查： curl http://127.0.0.1:8080/health 官方手动部署说明和命令示例里都给了从日志里查自动生成管理员密码的方法。( GitHub ) 11）安装 Caddy 并启用自动 HTTPS 先安装 Caddy 官方仓库： apt install -y debian-keyring debian-archive-keyring apt-transport-https curl curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg chmod o+r /etc/apt/sources.list.d/caddy-stable.list apt update apt install -y caddy 这正是 Caddy 官方当前给出的 Debian/Ubuntu stable 安装路径。( Caddy Web Server ) 12）写入 Caddyfile cat > /etc/caddy/Caddyfile <<'EOF' api.example.com { @static { path /assets/* path /logo.png path /favicon.ico } header @static { Cache-Control "public, max-age=31536000, immutable" -Pragma -Expires } tls { protocols tls1.2 tls1.3 } reverse_proxy 127.0.0.1:8080 { health_uri /health health_interval 30s health_timeout 10s health_status 200 header_up X-Real-IP {remote_host} header_up X-Forwarded-For {remote_host} header_up X-Forwarded-Proto {scheme} header_up X-Forwarded-Host {host} header_up CF-Connecting-IP {http.request.header.CF-Connecting-IP} } encode { zstd gzip 6 minimum_length 256 } request_body { max_size 100MB } log { output file /var/log/caddy/sub2api.log { roll_size 50mb roll_keep 10 roll_keep_for 720h } format json level INFO } handle_errors { respond "{err.status_code} {err.status_text}" } } EOF 检查并重载： caddy fmt --overwrite /etc/caddy/Caddyfile caddy validate --config /etc/caddy/Caddyfile systemctl enable caddy systemctl restart caddy systemctl status caddy --no-pager 官方仓库当前确实自带 deploy/Caddyfile ，里面已经包含 TLS、 reverse_proxy localhost:8080 、 /health 健康检查、转发真实 IP 头和日志滚动思路，所以这条路线最省心。 13）放行防火墙 ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable ufw status verbose 不要开放 8080 给公网，因为你已经通过 BIND_HOST=127.0.0.1 把应用只绑在本机，再让 Caddy 反代它。这样也符合 Docker 官方对防火墙的安全提醒。 14）最终验证 先本机验证： curl http://127.0.0.1:8080/health curl -I https://api.example.com 然后浏览器访问： https://api.example.com 用管理员邮箱和日志里拿到的密码登录。 15）部署完成后立刻执行的 5 个检查 登录后台，确认能打开首页。 到设置里确认站点 URL 是否正确。 frontend_url 如果没配对，后面邮件链接和支付回调会出错。 如果你要启用 URL 白名单，只保留自己真的要用的上游域名。官方样例里带了 OpenAI、Anthropic、Gemini、Azure OpenAI 等域名，但生产上不建议全开。 如果要开支付，后台路径是 设置 → 支付设置 ，官方当前支持 EasyPay、支付宝官方、微信官方、Stripe；多实例分流支持 round-robin 和 least-amount ，回调地址会按你的域名自动拼接。 如果你用 Stripe，记得订阅 payment_intent.succeeded 和 payment_intent.payment_failed 。 16）后续最常用的运维命令 cd /opt/sub2api # 看状态 docker compose -f docker-compose.local.yml ps # 看日志 docker compose -f docker-compose.local.yml logs -f sub2api # 重启应用 docker compose -f docker-compose.local.yml restart sub2api # 更新镜像 docker compose -f docker-compose.local.yml pull docker compose -f docker-compose.local.yml up -d # 停服务 docker compose -f docker-compose.local.yml down 官方部署说明里也给了 local 版这组常用命令，并强调 local 版最方便整目录迁移和备份。 4 个帖子 - 4 位参与者 阅读完整话题
Article URL: https://bizlect.com Comments URL: https://news.ycombinator.com/item?id=47813990 Points: 1 # Comments: 0
Codex Computer Use 插件非美国地区并没有正式开放 表现为 更新之后 打开 Codex 的设置页面–电脑使用–Computer Use 插件不可用。 Codex for Mac 安装包里其实已经带了 computer-use 插件，只是非美国地区默认不在设置页开放 先确认插件本体确实在应用包里 /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use 把 Codex 自带的 bundled plugins 注册成一个 marketplace codex marketplace add /Applications/Codex.app/Contents/Resources/plugins/openai-bundled 检查 ~/.codex/config.toml，确保有这段 [plugins.“computer-use@openai-bundled”] enabled = true 打开 remote_control 功能开关 codex features enable remote_control 完全退出并重启 Codex for Mac 重启后去设置页的 Computer use，理论上就能看到插件并安装。 首次使用时给 macOS 权限 主要是： 屏幕录制 辅助功能 / 控制电脑权限 如果你觉得太麻烦 发给 Codex 让他自己弄 1 个帖子 - 1 位参与者 阅读完整话题