如题，目前工作流是工位连着家里的软路由下面挂的ubuntu。 然后mesh搞了个大局域网。借助美国伪家宽出口访问claude，日常从家里调用文件。 一切都还行，上一个弹性公网IP 挂了三个月没换过了。114.249.115.192 但是昨天家里装空调，师傅没给我打招呼直接拉电闸了。导致重新拨号。 我的上一个IP就没了。。。。换成了114.249.119.XX ikuai上面的弹性域名 阿里云的没及时跟进，所以昨天提前下班开车回家去修了。。 cloudflare的貌似还行。 北京联通的固定公网IP业务貌似要100一个月，感觉有些贵啊。。毕竟我的宽带一月才109.。。 有什么好的办法能搞个固定公网IP吗（便宜一些的套餐，比如联通内部人员XD）。 我家小区我看应该是114.249.112.？？？ 子网不知道咋分的 114.249.64.0/18 可能是北京昌平？ 另外我想知道是不是我的 动态公网设置有问题。api虽然走的 是 阿里云的。 但是我的域名NS在cloudflare 然后我分出来了 一个三级域名 NS给了阿里云 专门跑动态域名。昨天拉闸的时候后续半小时收到了解析变动短信，但是后面自己查验发现ikuai上没有改。 反倒是 cloudflare的跟进了。。。 哎= = 17 个帖子 - 6 位参与者 阅读完整话题
这也太不科学了，为啥画图还有单独的cd。 还不能直接看刷新时间多长，难受。 1 个帖子 - 1 位参与者 阅读完整话题
我之前的工作流是opus写计划，sonnet执行，最近一段时间就琢磨把opus写的计划或者其他文档拿给codex先review。 刚开始是开两个 tmux pane，左边codex，右边claude，拿着claude 的计划给 codex， codex 审完，claude 改，claude 改完codex审……，而我在中间充当提示词的搬运工，主打一个复制和粘贴。 后来觉得实在太累了，想着既然codex有cli模式，不如让claude自己调用他，于是乎让claude给我写了这个 skill，再经过多轮迭代和踩坑，最后有了目前我一直在用的版本。 几个关键点： codex 一定要开 --yolo，这个就不解释了 一定要让 codex 在之前的会话进行 review，而不是重新开一个新的会话，不然你会发现 codex 每轮审查都能发现10个新问题，还不带重样的 还有个就是需要被审查的文档和提示词是用 stdin pipe 传进 codex的，因为我发现直接把prompt 通过命令行参数传入，由于codex的沙盒机制，会让codex一直处于等待stdin的状态而卡住 下面是具体的skill，使用方法很简单，claude 写完文档之后，直接调用 /devil-review ，claude 会在自动跑codex，拿到建议后修改，修改完了继续让codex审查……，循环直到codex 满意为止（设置默认最大循环次数10次），一般4-5次修改就会结束。 --- name: devil-review description: Run any markdown document or code change (diff/patch) through Codex for adversarial second-opinion review. Use when the user explicitly asks for a Codex or second-opinion review of a plan, PRD, spec, design doc, or staged/committed code changes — or offer it before high-impact implementation. Do not trigger automatically on every document edit. --- Codex Review Use Codex as a read-only adversarial reviewer. Codex reads and reports — it does not modify files. Amendments require explicit user confirmation before being applied (documents) or are applied directly by Claude (code changes). Two review modes: Document — review a markdown plan, PRD, spec, or design doc Code change — review a git diff, staged changes, or patch file Step 1: Set up the workspace Document mode If the document is already a file on disk : note its absolute path. If the document is in conversation only : write it to a temp file: REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.md) # write document content to $REVIEW_FILE Determine the project root : check whether the document belongs to a git repo. If it does, use that repo root as the working directory for Codex — this lets it read related source files for context: PROJECT_ROOT=$(git -C "$(dirname <absolute-path>)" rev-parse --show-toplevel 2>/dev/null || dirname <absolute-path>) Code change mode Capture the diff and write it to a temp file. Choose the right git diff invocation: What to review Command Unstaged working-tree changes git diff Staged (index) changes git diff --staged Last commit git diff HEAD~1 HEAD Specific range git diff <ref1> <ref2> Already-a-patch-file use the file path directly REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.diff) git -C "$PROJECT_ROOT" diff --staged > "$REVIEW_FILE" # adjust as needed # verify it isn't empty before proceeding Set PROJECT_ROOT to the git repo root so Codex can read surrounding source files for context: PROJECT_ROOT=$(git rev-parse --show-toplevel) Step 2: Build the review prompt Adapt the focus based on what’s being reviewed. Always include the “do not modify files” constraint — --yolo grants write access, but this skill is review-only: Input type Focus areas Implementation plan Flawed approach, missing steps, unclear dependencies, better alternatives PRD Requirements clarity, completeness, contradictions, missing edge cases, unstated assumptions Spec / design doc Ambiguity, testability, missing constraints, inconsistencies Code change Bugs and logic errors, security issues (injection, auth, data exposure), missing or broken error handling, test coverage gaps, unintended side effects, API / contract breaks, readability problems that will cause future bugs Other General clarity, gaps, and anything that would cause downstream failure Use this template, filling in the input type and relevant focus areas: You are an adversarial reviewer. The content is provided via stdin — it is a <input type>. Your job is to find problems: <focus areas for this input type>. Be specific — generic praise or vague concerns are not useful. Do not modify, create, or delete any files. Read only. End your review with one of these two verdicts as the very last line of your response: APPROVED — the content is solid and ready to act on NEEDS REVISION: <one-line summary of the main issue> Write this prompt to a temp file: PROMPT_FILE=$(mktemp /tmp/codex-review-prompt-XXXXXX.md) # write prompt to $PROMPT_FILE Step 3: Invoke Codex Round 1 — start the session: codex exec --yolo --cd "$PROJECT_ROOT" "$(cat $PROMPT_FILE)" < "$REVIEW_FILE" After round 1 completes, capture the session ID from the session file. Session files are named rollout-...-<uuid>.jsonl and the resumable ID lives in the first line’s payload.id field: LATEST_FILE=$(ls -t ~/.codex/sessions/$(date +%Y)/$(date +%m)/$(date +%d)/rollout-*.jsonl 2>/dev/null | head -1) SESSION_ID=$(python3 -c " import json, sys with open('$LATEST_FILE') as f: for line in f: try: d = json.loads(line) sid = d.get('payload', {}).get('id', '') if sid: print(sid); break except: pass " 2>/dev/null) If SESSION_ID is empty, ask the user to provide it (visible in the Codex session picker) before proceeding. Rounds 2–10 — resume the session. Write the resume prompt to a temp file and pipe it via stdin: Document mode: RESUME_FILE=$(mktemp /tmp/codex-review-resume-XXXXXX.md) # write to $RESUME_FILE: # "I've updated the document to address your concerns. Key changes: <summary>. # Please re-read the file at <absolute-path> and review again. Do not modify any files. # Use the same verdict format as before: APPROVED or NEEDS REVISION: <one-line summary>." codex exec resume --yolo "$SESSION_ID" - < "$RESUME_FILE" Code change mode: # Re-capture the updated diff after applying fixes (see Step 5) git -C "$PROJECT_ROOT" diff --staged > "$REVIEW_FILE" RESUME_FILE=$(mktemp /tmp/codex-review-resume-XXXXXX.md) # write to $RESUME_FILE: # "The diff has been updated to address your concerns. Key changes: <summary>. # The updated diff is provided via stdin. Review it again. Do not modify any files. # Use the same verdict format: APPROVED or NEEDS REVISION: <one-line summary>." codex exec resume --yolo "$SESSION_ID" - < <(cat "$RESUME_FILE" "$REVIEW_FILE") Run with run_in_background: true — Codex runs are long Read the output file directly as it streams; never pipe through tail or head Don’t hardcode a model name; Codex picks its default Step 4: Parse the verdict Look for the verdict only on the final line of Codex’s response — match strictly: Line starting with APPROVED → approved Line starting with NEEDS REVISION: → needs revision Ignore any occurrence of these words mid-output; the prompt template or previous round context can produce false matches. APPROVED : surface Codex’s rationale to the user and confirm they want to proceed NEEDS REVISION: : surface the specific objections clearly, then go to Step 5 Step 5: Amend and resubmit Document mode Immediately amend the document to address Codex’s objections — no confirmation needed. Use judgment on what to change; not every objection requires a redesign. Tell the user what changed and why in one concise line, then go straight back to Step 3 (Round 2+). Code change mode Apply fixes directly to the source files (no confirmation needed for mechanical fixes; pause for architectural changes). Use judgment — not every objection warrants a change. Then: Re-stage the fixed files ( git add ) so the updated diff reflects the corrections Re-capture the diff: git diff --staged > "$REVIEW_FILE" Tell the user what changed and why in one concise line Go back to Step 3 (Round 2+), piping both the resume message and the fresh diff Keep an iteration counter visible: “Review round 2”, “Review round 3”. This lets the user track progress and decide when to override. Hard cap: 10 rounds. If Codex still hasn’t approved by round 10, stop the loop, surface the outstanding objections, and ask the user how to proceed. Step 6: User override The user can stop the loop at any point (“proceed anyway”, “I disagree with Codex here”). Codex’s verdict is advisory — surface it faithfully but respect the user’s final call. 3 个帖子 - 3 位参与者 阅读完整话题
最近在尝试帮甲方利用seedance2.0做宣传片，我的工作流是利用一个专门撰写seedance2.0的skills,生成分镜，再利用image2.0生成所需的元素，每个镜头单独生成视频,我看到很多教程在利用故事板的方式生成，我想问的是故事板的方式对于生成视频更高效吗？为什么？以及最佳实践是什么 2 个帖子 - 2 位参与者 阅读完整话题
你们的工作流是咋样的？ 我发现一开始效率确实不错，简单任务搞得很好， 但是长时间任务，复杂分析的时候，效率反而还不如自己动手跑 比如codex在盯长时间的任务的时候，如果用心跳脚本，就会导致对话轮数太多， 还有codex开发的eqtl分析流程，基本不考虑并行优化， 再就是上下文超了之后的记忆问题，非常头疼 1 个帖子 - 1 位参与者 阅读完整话题
前言 我使用的工作流是风佬的 ccg-workflow,支持了antigravity cli，就捣鼓下。 wsl不开tun使用agy 测试过ProxyBridge, 在windows下没有问题，但是在wsl安装linux版本无法生效。因此，使用graftcp。 1、安装 下载deb， wget https://github.com/hmgle/graftcp/releases/download/v0.4.0/graftcp_0.4.0-1_amd64.deb dpkg -i graftcp_0.4.0-1_amd64.deb 2、配置graftcp-local 配置文件：/etc/graftcp-local/graftcp-local.conf： listen = :2233 logfile = /tmp/graftcp-local.log loglevel = 1 socks5 = 127.0.0.1:2080 3、配置systemd /usr/lib/systemd/system/graftcp-local.service [Unit] Description=Translate graftcp TCP to SOCKS5 or HTTP proxy After=network.target [Service] StartLimitInterval=5 StartLimitBurst=10 ExecStart=/usr/bin/graftcp-local -config /etc/graftcp-local/graftcp-local.conf Restart=always RestartSec=120 [Install] WantedBy=multi-user.target 启动服务： sudo systemctl daemon-reload sudo systemctl enable graftcp-local sudo systemctl start graftcp-local sudo systemctl status graftcp-local 验证是否启动成功： netstat -antp | grep 2233 graftcp curl -sI https://google.com |head -n 1 4、graftcp 重定向agy agy 安装见官方文档，安装路径：~/.local/bin cd ~/.local/bin/ mv agy agy.bak cat > agy << 'EOF' #!/bin/bash export GODEBUG=netdns=cgo,http2client=0 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" exec /usr/bin/graftcp "${SCRIPT_DIR}/agy.bak" "$@" EOF chmod +x agy 5、启动agy，进行登录验证。 解决每次打开agy都需要验证 解决方案来源： [Bug] Antigravity CLI (agy) fails to persist authentication state in WSL 2 environment - Google Antigravity - Google AI Developers Forum sudo apt update && sudo apt install -y dbus-x11 libsecret-1-0 gnome-keyring # 以下内容写入用户目录的 .bashrc if [ -n "$BASH_VERSION" ]; then export $(dbus-launch) eval "$(echo "" | gnome-keyring-daemon --unlock)" eval "$(gnome-keyring-daemon --start)" export SSH_AUTH_SOCK fi 这样就可以愉快使用agy 1 个帖子 - 1 位参与者 阅读完整话题
大佬们，我用paypal无卡流开的免费试用plus，没有到账 我连着开了几个都是这样子 2 个帖子 - 2 位参与者 阅读完整话题
每轮工具调用都要踢几脚 3 个帖子 - 3 位参与者 阅读完整话题
想问一下大佬友平时编程的时候，怎么使用AI工具的，工作流是怎样的 3 个帖子 - 2 位参与者 阅读完整话题
一共买了三个gpt的plus，和一个Claude的Pro 我目前的工作流是Claude写计划，然后codex进行review，开发，测试。但是吧Claude每5个小时的额度连计划都写不完，也太气人了。写个plan都得等两个5小时额度。 现在在考虑要不要放弃掉Claude，直接上5x的gpt。 佬友们，你们怎么看 14 个帖子 - 11 位参与者 阅读完整话题
做逆向的AI工作流是怎样的?OD,CE这些可以接入AI吗? 或者现在已经不用这种老软件了? 1 个帖子 - 1 位参与者 阅读完整话题
目前我在开发win，mac和ios的软件，纯vibe coding，工作流是： claude cowork+obsdian，Claude出计划，审核，前端claude code执行，后端方面全给codex执行 我在其中就是个传话筒的作用，我是想把可以自动化的流程自动化，但和ai讨论了之后感觉自动化会影响质量，如GSD+Superpowers，又研究了 hermes-agent感觉也不太适合 可能陷入认知困境了 请教各位佬应该怎么优化我的工作流呢？万分感谢！！ 2 个帖子 - 2 位参与者 阅读完整话题
基本的国内外分流,我看还有各种各样的分流规则,除开打游戏低延迟和特定IP解锁流媒体,分流还可以应用在哪里,仅仅是上网页浏览的话，我感觉香港和美国差不多,那还有什么应用场景呢 3 个帖子 - 3 位参与者 阅读完整话题