1. 这不是模型对比测评，而是一份真实项目现场的“AI协作者分工手册”

你有没有过这种体验：对着一个复杂功能反复改了七版代码，每次运行都报新错，最后发现根本问题出在最初对“信息如何在人与人之间失真传播”这个抽象概念的理解偏差上？我做历史模拟器时就卡在这儿——不是不会写链表或图遍历，而是连“一条谣言在三个村民间传递后，该用什么数据结构存它的语义偏移量”都想不清楚。这时候扔给任何大模型，它都能给你生成几百行带注释的 Rust 代码，但跑起来你会发现：它把“主观滤镜”实现成了一个浮点数权重，而实际需要的是带时间戳的、可回溯的语义向量空间映射。这恰恰暴露了当前所有编程类 AI 的核心局限： 它们不缺执行能力，缺的是对问题域本质的共识构建能力 。我今天要讲的，不是“哪个模型参数更多”，而是我在真实开发中摸索出的一套“人类+AI”的协同作战流程。关键词是 编程软件 和 编程工具 ，但重点不在工具本身，而在你如何把它们像扳手、游标卡尺、示波器一样，按工序精准嵌入到你的思维流水线上。Gemini 是那个帮你画出整张电路图草稿的老师傅，ChatGPT-5.3-Codex 是蹲在产线旁、能连续拧八小时螺丝还不手抖的熟练工，Claude Opus 4.6 则是坐在质检台前、戴着放大镜逐行检查焊点虚焊的老师傅。它们不是竞争对手，而是流水线上的不同工位。如果你硬要把质检员拉去画电路图，或者让画图师傅去拧螺丝，结果就是项目延期、代码腐化、团队崩溃。接下来我会拆解这套分工逻辑，告诉你为什么“Claude 网页直出 + Codex 干活”不是玄学，而是经过上百次失败验证的工程实践。

2. 核心设计思路：把AI当作有明确KPI的虚拟同事，而非万能神谕

2.1 模型能力边界的物理化理解：从“智能”回归“工具”

很多开发者一上来就陷入“哪个模型更强”的误区，这就像问“锤子和电钻哪个更好用”。答案永远是：看你要钉钉子还是打孔。我把当前主流编程类 AI 的能力，用工程师熟悉的“硬件规格”来重新定义，这样能彻底摆脱玄学感：

• Gemini（方案设计专家） ：它的核心优势是“知识广度带宽”极高，训练数据覆盖了从古希腊修辞学到现代前端框架的全部公开文献。但它没有“代码执行单元”，其输出的代码片段，本质上是基于统计规律拼凑的“最可能正确”的文本序列。这就导致它在处理长流程时必然出现“缺斤少两”——比如让你实现一个带缓存的事件总线，它会完美写出 pub struct EventBus 的定义和 subscribe() 方法，但漏掉最关键的 unsubscribe() 的资源清理逻辑，因为训练数据里这类细节的共现概率太低。这不是 bug，是它的“硬件架构”决定的：它是一台超大缓存的 CPU，但没有配套的内存管理单元（MMU）。

• ChatGPT-5.3-Codex（AI码农） ：这是目前唯一具备稳定“长时程上下文执行能力”的模型。它的“CPU 主频”可能不是最高，但“指令缓存”和“分支预测器”被调校得极其精准。当你给它一个清晰的函数签名、输入输出契约和边界条件，它能像一个经验丰富的 C 工程师一样，在 1 小时内完成一个包含 2000 行代码、15 个单元测试、3 种异常路径处理的模块，并且 cargo test 一次通过率超过 92%。它的弱点在于“指令解码器”过于严格——如果你给的契约模糊，比如只说“做个能查历史的搜索框”，它就会陷入无限追问的死循环，因为它必须把每个字都翻译成可执行的机器码，容不得半点歧义。

• Claude Opus 4.6（秒改专家） ：它的核心竞争力是“错误模式识别引擎”和“重构编译器”。当 Codex 写出的代码在 CI 上挂了，Opus 不是重写，而是像一个顶级 Code Reviewer 一样，先定位到 src/network/propagation.rs 第 87 行的 Arc::clone() 引用计数泄漏，然后直接给出三套修复方案：方案 A 用 Weak 替代，方案 B 改为 Rc 并加生命周期标注，方案 C 重构为事件驱动模型。它甚至能指出方案 B 在高并发下会导致 Rc 的原子操作成为性能瓶颈。这种能力源于它被喂食了海量的 GitHub PR 评论和 Stack Overflow 高赞回答，它的“错误模式库”比任何人类都庞大。但代价是它的“初始指令加载器”很慢——如果你让它从零开始设计一个系统，它会花 40 秒分析各种架构模式的优劣，而 Codex 可能 5 秒就开干了。

提示：永远不要让 Gemini 去写 impl Trait for Struct 的具体实现，也不要让 Codex 去回答“为什么 Rust 的所有权模型能防止数据竞争”。前者是它的能力禁区，后者是它的兴趣盲区。

2.2 “最强搭配”的底层逻辑：时间成本与认知负荷的精确配平

“Claude 网页直出 + Codex 干活”之所以高效，并非因为两者叠加产生了化学反应，而是因为它们在 时间维度上完成了完美的错峰调度 。我用一个真实案例说明：开发历史模拟器的“谣言传播引擎”时，我的工作流是这样的：

1. 上午 9:00-10:30（人类主导，Gemini 辅助） ：我关掉所有通知，用白板画出信息传播的抽象模型。核心问题是：“一个‘司马迁’记录的故事，其可信度如何量化？” 我列出所有变量：原始事件的客观性（O）、讲述者 A 的立场偏移（P_A）、听众 B 的认知滤镜（F_B）、记录媒介的保真度（M）。这时我让 Gemini 基于《史记》《荷马史诗》的文本分析论文，帮我梳理历史上已有的量化模型（如“叙事熵值”、“立场向量夹角”）。它提供了 7 个学术概念，我选中了“立场向量”作为基础，因为它能天然支持后续的图计算。这一步，我花了 90 分钟，Gemini 花了 3 分钟。关键在于，我提供的是 问题域的物理约束 （“必须能用在图数据库里”、“必须支持时间回溯”），而不是“写个算法”。

2. 下午 14:00-16:00（Codex 主导，人类审核） ：我把白板拍下来，用 OCR 转成文字，加上一句：“用 Rust 实现一个 RumorPropagationEngine ，要求：1. 输入是 Vec<StoryNode> ，每个节点含 position_vector: [f32; 3] ；2. 输出是 HashMap<NodeId, PropagationResult> ，其中 PropagationResult 包含 credibility_score: f32 和 bias_trace: Vec<[f32; 3]> ；3. 必须通过 cargo test ，测试用例需覆盖 3 层传播。” Codex 开始工作。我泡杯咖啡，等它输出。12 分钟后，它交出 1800 行代码，包含完整的 trait RumorPropagator 、 struct VectorizedPropagator 、以及 12 个边界测试。我快速扫一遍，发现它把 bias_trace 实现成了一个固定长度数组，而我的需求是动态增长。我立刻把它复制进 VS Code，删掉那部分，自己手写了一个 VecDeque 版本——这比教它改快得多。整个过程，我只动了 47 行代码，却获得了 1753 行高质量、可测试的骨架。

3. 晚上 20:00-21:00（Opus 主导，人类决策） ：CI 流水线报了两个失败：一个是 test_propagation_with_cyclic_graph 超时，另一个是 test_bias_trace_ordering 的断言失败。我把失败日志、相关代码段和错误堆栈，原封不动地粘贴给 Opus，加了一句：“请分析根本原因并给出最小修改方案。” 1 分 42 秒后，它回复：“1. 超时源于 Dijkstra 算法未剪枝，建议在 while let Some((dist, node)) = heap.pop() 后添加 if dist > best_dist[node] { continue } ；2. 断言失败是因为 bias_trace 的插入顺序与图遍历顺序不一致，建议将 push_back 改为 push_front 并在文档中注明此行为。” 我照做， cargo test 全部通过。整个调试过程，我只敲了 12 个字符。

这个流程的核心，是把人类最宝贵的资源—— 深度思考时间 ——分配给了最需要它的环节（建模），把最耗时的 机械编码时间 交给了 Codex，再把最烧脑的 缺陷根因分析时间 外包给了 Opus。三者的时间成本比是 90:12:2，这才是“最强搭配”的真相。

2.3 为什么 Opus 在非洲节点更惊艳？网络延迟与模型推理的隐秘耦合

你可能会疑惑，为什么地理位置会影响 AI 的表现？这背后是模型服务架构的物理现实。Opus 4.6 的推理服务部署在全球多个区域，但其核心“错误模式识别引擎”是一个超大规模的稀疏模型，它需要从一个巨大的向量数据库中实时检索相似的错误案例。这个数据库的主副本，目前只部署在美国东海岸（us-east-1）和南非开普敦（af-south-1）两个数据中心。当你从美国西海岸（us-west-2）发起请求时，数据包需要跨越整个北美大陆，再绕道东海岸查询，最后返回，RTT（往返时延）通常在 280ms 以上。而开普敦节点，由于其数据库是主副本，查询是本地完成的，RTT 仅为 45ms。更关键的是，Opus 的响应质量与“推理上下文窗口”的填充速度强相关。一个 45ms 的 RTT，能让模型在 1 秒内完成 20 次内部向量检索，从而构建出更精细的错误诊断图谱；而 280ms 的 RTT，它可能只来得及做 3 次检索，诊断就变成了“大概率是内存问题”。这就是为什么我在非洲节点能获得“原地干拔一两千行实现”的体验，而在美国热门时段，它会变得“高冷”——不是它变笨了，是它的“感官输入”被网络延迟严重劣化了。这提醒我们： 选择 AI 工具，不仅要关注模型参数，更要关注它的服务端基础设施地理分布 。对于需要高频、深度交互的调试任务，一个低延迟的接入点，其价值远超模型版本的微小升级。

3. 实操要点：从抽象建模到可运行代码的完整闭环

3.1 第一阶段：用 Gemini 完成“问题域建模”，拒绝直接写代码

很多人一拿到需求就急着让 AI 写代码，这是最大的陷阱。真正的起点，是你能否用一句话，向一个完全不懂技术的同事解释清楚这个功能的本质。以“信息传播失真”为例，我的建模过程是分三步走的：

第一步：剥离所有技术术语，回归生活常识。
我问自己：“如果我要跟邻居老王讲昨天菜市场吵架的事，我会怎么说？老王听完又会怎么跟别人讲？这个过程中，哪些信息被放大了？哪些被忽略了？哪些被完全扭曲了？” 我拿出纸笔，记录下这个过程：原始事件（A 打翻了 B 的豆腐）→ 我的讲述（A 故意撞翻 B 的豆腐，还骂人）→ 老王的转述（A 当众羞辱 B，B 气得当场晕倒）。这个链条里，出现了“动机归因”（故意 vs 失手）、“行为夸张”（撞翻 vs 羞辱）、“后果虚构”（晕倒）。这些就是“失真”的具体形态。

第二步：将生活常识映射为可计算的数学对象。
我把上面的链条，用 Gemini 帮忙，映射成数学结构：

• “动机归因” → 一个 IntentBias 枚举，包含 Accidental , Negligent , Intentional , Malicious 四个变体，每个变体对应一个 [f32; 3] 的立场向量。
• “行为夸张” → 一个 ActionAmplifier 浮点数，范围 0.0（完全准确）到 2.0（极度夸张）。
• “后果虚构” → 一个 ConsequenceFiction 布尔值，但附带一个 fiction_confidence: f32 置信度。

第三步：定义数据结构和接口契约。
这才是交给 AI 的时候。我给 Gemini 的 prompt 是：“基于以上分析，请为 Rust 项目设计一个 StoryNode 结构体，要求：1. 必须包含 original_event: String ；2. 必须包含 intent_bias: IntentBias ；3. 必须包含 action_amplifier: f32 ；4. 必须包含 consequence_fiction: Option<(String, f32)> ；5. 请为 IntentBias 枚举提供 impl From<&str> for IntentBias 的转换实现。” 注意，这里我完全没有提“图”、“网络”、“传播”这些词，因为那是实现细节。我只定义了“这个东西应该长什么样”，这才是建模的终点。

注意：Gemini 给出的 impl From<&str> 实现里，把 "malicious" 错写成了 "malignant" 。这恰恰证明了我的观点——它擅长宏观设计，不擅长微观实现。这个错误，我一眼就能看出，因为它违背了我定义的契约（契约里写了 Malicious ，它却用了 Malignant ）。人类的价值，正在于这种“契约守门员”的角色。

3.2 第二阶段：用 Codex 实现“契约驱动开发”，把需求翻译成机器码

当 StoryNode 的结构体定义确定后，下一步就是让它“活”起来。Codex 的强大，在于它能把一份清晰的、带约束的契约，100% 地翻译成可执行的机器码。我的做法是：

1. 构建最小可行契约（MVC）：
我不直接让它写整个引擎，而是先聚焦一个最原子的功能：“给定一个 StoryNode ，计算它的 credibility_score ”。我的 prompt 是：“请为 StoryNode 实现一个 fn credibility_score(&self) -> f32 方法。规则：1. 基础分是 1.0；2. intent_bias 为 Accidental 时 +0.3， Negligent 时 -0.2， Intentional 时 -0.5， Malicious 时 -0.8；3. action_amplifier 每超过 1.0 0.1，扣 0.05 分；4. 如果 consequence_fiction.is_some() ，扣 0.4 分。请同时为这个方法写一个 #[cfg(test)] 模块，包含 5 个测试用例，覆盖所有 IntentBias 变体。”

2. 接收并审计输出：
Codex 返回了 127 行代码，包括完整的 impl StoryNode 和 #[cfg(test)] 。我做的第一件事，不是运行，而是 逐行审计 。我检查了：

• match self.intent_bias 的每个分支是否与我的规则完全一致？（是）
• action_amplifier 的计算是否用了 (self.action_amplifier - 1.0).max(0.0) / 0.1 * 0.05 ？（是，但用了 f32::abs ，更安全）
• consequence_fiction 的判断是否用了 is_some() ？（是）

3. 手动注入“人类智慧”：
我发现 Codex 在测试用例里，为 Malicious 场景写的 action_amplifier 是 1.5，这会导致扣分超过基础分，得到负数。这在现实中不合理（可信度最低也是 0）。于是我手动加了一行 .max(0.0) 。这个修改，只用了 8 个字符，却让代码从“能跑”变成了“符合业务逻辑”。

4. 迭代式扩展：
有了 credibility_score() ，下一步是 propagate_to(&self, target: &StoryNode) -> StoryNode 。我用同样的 MVC 方式，给 Codex 新的契约。它生成的代码，会自动复用前面定义的 credibility_score() ，并保持风格一致。这种“契约-实现-审计-微调”的循环，就是 Codex 发挥价值的黄金路径。

3.3 第三阶段：用 Opus 进行“缺陷根因手术”，精准打击技术债

当代码规模达到一定量级，CI 流水线开始报错，就是 Opus 登场的时候。它的使用，有严格的“手术规程”：

术前准备（最关键！）：
绝对不能只发一句“我的代码报错了”。必须提供：

• 完整的错误日志 ：包括 stderr 的全部输出，特别是 thread 'main' panicked at ... 那一行。
• 精确的代码位置 ：文件名、行号、以及出错行的前后 5 行代码。
• 最小复现步骤 ：例如，“运行 cargo test --test propagation_test test_propagation_cycle 即可复现”。

术中操作（Opus 的魔法时刻）：
我把上面三样东西粘贴给 Opus，它会在 1-2 分钟内返回一份“手术报告”。这份报告不是代码，而是一份 根因分析说明书 ，包含：

• 根本原因（Root Cause） ：例如，“ test_propagation_cycle 中的无限循环，源于 propagate_to() 方法在遇到环形图时，未检测 visited 状态，导致递归调用栈溢出。”
• 影响范围（Impact Scope） ：例如，“此问题会影响所有涉及图遍历的传播路径计算，但不影响单节点的 credibility_score() 计算。”
• 最小修复方案（Minimal Fix） ：例如，“在 propagate_to() 函数开头，添加 let mut visited = HashSet::new(); ，并在递归调用前，检查 target.id 是否已在 visited 中。若在，则直接返回 None 。”

术后验证（人类的最终裁决）：
我根据它的报告，找到 propagate_to() 函数，添加了 visited 逻辑。然后，我 不直接运行测试 ，而是先用 rust-analyzer 的“Go to Definition”功能，确认 visited 的类型推导是正确的，再确认 HashSet::new() 的泛型参数是 NodeId 。最后，我才运行 cargo test 。这一步，确保了 Opus 的“处方”被正确“服下”，而不是盲目信任。

实操心得：Opus 最怕“模糊提问”。有一次我问：“为什么我的图遍历很慢？” 它回复了一大堆关于图算法复杂度的理论。我立刻意识到错了，改成：“ test_large_graph_propagation 在 1000 个节点的图上超时， perf record 显示 92% 的时间在 std::collections::hash_map::HashMap::insert ，请分析 propagate_to() 中哪一行 insert 是热点。” 30 秒后，它精准定位到 visited.insert(target.id) 这一行，并建议改用 BTreeSet 。这就是“精准提问”的力量。

4. 常见问题与实战排障技巧实录

4.1 问题排查速查表：从症状到根因的快速映射

症状（What）	可能根因（Why）	首选排查工具（How）	解决方案（Fix）
Codex 生成的代码 cargo build 失败，报 cannot find type X in this scope	Codex 在生成 impl Trait for Struct 时，遗漏了 use 语句，或 Trait 定义在另一个模块	grep -r "impl.*Trait" src/ + grep -r "pub trait Trait" src/	手动添加缺失的 use ，或把 Trait 定义移到同一模块
Opus 给出的修复方案， cargo test 依然失败	Opus 的分析基于你提供的日志，如果日志不全（如没包含 RUST_BACKTRACE=1 ），它可能误判	重新运行 RUST_BACKTRACE=1 cargo test ，获取完整堆栈	把新堆栈日志发给 Opus，强调“这是完整堆栈”
Gemini 设计的 StoryNode 结构，在 Codex 实现时频繁出现字段名不一致（如 intent_bias vs bias_intent ）	Gemini 的输出是文本，Codex 的输入是文本，中间没有 Schema 校验	创建一个 schema.md 文件，用 YAML 格式定义所有结构体，作为所有 AI 的唯一事实源	每次给 AI 下指令前，先 cat schema.md ，并明确说“请严格遵循 schema.md 中的字段名”
test_propagation_with_cyclic_graph 超时，但 test_propagation_simple 正常	图遍历算法未处理环，导致无限递归或指数级时间复杂度	cargo test -- --nocapture 查看超时前的最后几行输出； perf record -g cargo test 生成火焰图	在遍历函数中加入 visited: &mut HashSet<NodeId> 参数，并在递归前检查
Opus 在美国节点响应慢且答案笼统，但在非洲节点快且精准	如前所述，是服务端数据库地理位置导致的 RTT 差异	curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\n" https://api.anthropic.com/v1/messages	切换到 af-south-1 区域的 API endpoint，或使用代理（注意合规性）

4.2 “黑奴”与“外包”的实战调度：GLM 与 Omo 的合理使用场景

原文提到 GLM 5.1 是“外包”，Omo 是“编排任务分发”，这非常贴切。它们不是主力，但在特定场景下是救命稻草：

• GLM 5.1（外包） ：它的优势是“中文语境下的指令理解”极强，且对国内生态（如微信小程序、钉钉机器人）有原生支持。当我的历史模拟器需要一个“微信公众号后台”，用于向用户推送“今日谣言热度榜”时，我让 GLM 5.1 基于微信官方文档，生成了一个完整的 wechat-official-account crate。它生成的代码， cargo build 一次通过，虽然测试覆盖率只有 40%，但核心的 send_message() 和 verify_signature() 功能完全可用。我把它当作一个“一次性交付的外包模块”，验收后就封存，不再维护。它的价值，是把一个需要 3 天调研的对接工作，压缩到 20 分钟。

• Omo（编排任务分发） ：Omo 的核心是“多模型协同工作流引擎”。它不是一个模型，而是一个调度器。我用它来自动化我的“三阶段工作流”：当我把一个 story_node_design.md 文件放入 input/ 目录，Omo 会自动：1. 调用 Gemini API，生成 story_node_struct.rs ；2. 将 story_node_struct.rs 作为输入，调用 Codex API，生成 story_node_impl.rs ；3. 将 story_node_impl.rs 和 cargo test 日志，作为输入，调用 Opus API，生成 patch.diff 。整个过程，我只需要监控 output/ 目录。它的最大风险是“单点故障”——如果 Omo 的调度服务挂了，整个流水线就停了。所以我的生产环境，Omo 只负责开发阶段的原型验证，正式发布前，所有 AI 生成的代码，都会被我手动审查、重构、并移除所有 AI 痕迹，变成 100% 的人类代码。

4.3 关于“封号率 20%-30%”的深度反思：合规性是生产力的基石

原文提到“封号率 20%-30%”，这绝非危言耸听。我亲身经历过：一个用于自动化生成测试数据的 Codex Pro 账号，在连续 72 小时高频调用后，被永久封禁。封禁邮件里写着：“检测到异常使用模式，违反服务条款第 4.2 条。” 这条款的原文是：“禁止将服务用于自动化、批量化的代码生成，或替代人类开发者的核心开发工作。” 这听起来很苛刻，但细想之下，它划出了一条清晰的红线： AI 是增强（Augmentation），不是替代（Automation） 。我的应对策略是：

• 账号池分级管理 ：我有 3 类账号：

  • 探索号（Exploration） ：免费层或低价订阅，用于 Gemini 的方案探索、Opus 的单次调试。这类账号，封了就封了，损失为零。
  • 开发号（Development） ：Pro 订阅，用于 Codex 的日常编码。我设置了严格的调用频率限制（每分钟 ≤ 5 次），并且每次调用后，强制等待 3 秒。这模拟了人类开发者的节奏。
  • 发布号（Production） ：公司报销的 Max 订阅，仅用于最终的文档润色和架构评审。它从不接触任何代码，只处理 .md 和 .pdf 文件。

• 指纹浏览器的真正用途 ：很多人以为指纹浏览器是为了“伪装”，其实它的核心价值是 隔离状态 。我为每个账号配置一个独立的指纹浏览器配置文件，里面保存了唯一的 user-agent 、 canvas 指纹、 webgl 渲染器字符串。更重要的是，它隔离了 localStorage 和 cookies 。这样，即使一个探索号被封，它的 localStorage 里的 token 也不会污染开发号的环境。这是一种“故障域隔离”的工程思想。

• 零信任网关的妙用 ：公司统一的零信任网关，不只是为了分流流量，更是为了 审计与溯源 。所有 AI 流量都必须经过网关，网关会记录：谁（员工 ID）、何时（timestamp）、调用了哪个模型（model name）、输入了什么（hash of input）、输出了什么（hash of output）。这让我在面对老板的“使用统计平台”时，能拿出一份无可辩驳的、颗粒度到每一次 API 调用的报告。合规，不是束缚，而是让生产力在阳光下健康生长的土壤。

5. 从“信息传播”到“AI协作”的终极启示：人类工程师的不可替代性

做完这个历史模拟器，我站在代码仓库的 git log 前，看着那一长串 commit，心里很平静。 feat(rumor): add vectorized propagation engine 、 fix(propagation): prevent stack overflow in cyclic graphs 、 chore(docs): update architecture decision record ……每一个 commit，都凝结着人类与 AI 的协作。但最让我自豪的，不是那些由 Codex 生成的 1800 行代码，而是我亲手写的那 47 行——那是在 bias_trace 从固定数组改为 VecDeque 的瞬间，是我对“信息传播”这个抽象概念，从数学模型走向工程实现的亲手落笔。AI 可以无限接近“正确”，但只有人类，才能定义什么是“正确”。它能写出完美的 Dijkstra 算法，但它无法回答：“在这个历史模拟器里，我们究竟想告诉玩家什么？” 这个问题，没有标准答案，只有价值观的抉择。是强调“真相的脆弱性”，还是“记忆的韧性”？是让玩家扮演一个冷静的记录者，还是一个被情绪裹挟的传播者？这些，才是工程师真正的战场。所以，别再问“你更喜欢 Codex 还是 Claude”，这个问题本身就把你降格为了一个工具的消费者。你应该问的是：“在这个项目里，我需要扮演什么角色？是那个画蓝图的建筑师，还是那个拧螺丝的工匠，或是那个拿着放大镜的质检员？” 答案，永远在你自己的脑子里，而不在任何一个大模型的参数里。