--- title: '对抗性开发:让编码 Agent 互相辩论提升可靠性' video_id: HAkSUBdsd6M url: https://youtu.be/HAkSUBdsd6M title_en: "Coding Agent Reliability EXPLODES When They Argue (New Adversarial Dev Technique)" channel: Cole Medin published: 2026-03-30 duration: "17:36" topics: [多 Agent 协作, Agent 工程] noted: 2026-07-05 value: A views: '1.1万' --- [![封面](https://i.ytimg.com/vi/HAkSUBdsd6M/maxresdefault.jpg)](https://youtu.be/HAkSUBdsd6M) > Cole Medin · 17:36 · 发布 2026-03-30 · 1.1万次观看(截至抓取) · [观看原视频](https://youtu.be/HAkSUBdsd6M) ## 主旨 用一个独立的、专职挑刺的评审 agent 去反驳主实现 agent 的产出(Cole 称之为「adversarial dev / 对抗性开发」),再套上「规划器 + 生成器 + 评估器」的多 agent harness,可以让 AI 编码在无人看管的情况下自动迭代出远比单 agent 可靠的结果。 ## 核心论点 1. **让编码 agent 评审自己的产出是最糟的做法**——它像给自己作业打分的学生,受 Sycophancy 驱使几乎必给高分,把真正的问题扫到地毯下。([[#1-根因是-sycophancyagent-不能给自己打分-0037|→ 详解1]]) 2. **解法是给主 agent 配一个独立会话的「陪练」**——第二个 agent 唯一职责就是撕开主 agent 的实现、唱反调、质疑深层决策。([[#2-对抗性开发给主-agent-配一个专职挑刺的陪练-0122|→ 详解2]]) 3. **这套架构直接借鉴 GAN**:生成器想骗过评估器,评估器若判得准就骗不过,两者对抗中产出质量被逼着往上走。([[#3-灵感来自-gan生成器想骗过评估器-0257|→ 详解3]]) 4. **完整 harness 是「规划器 + 生成器 + 评估器」三段式**:规划器先把粗糙需求扩成完整 spec,再进入生成-评估的迭代循环。([[#4-三段式-harness规划器--生成器--评估器-0403|→ 详解4]]) 5. **写第一行代码前,生成器与评估器要先「谈契约」**——对抗但事先约定好分几个 sprint、每个 sprint 拿什么标准评判,再开打。([[#5-动手前先谈契约对抗但事先约定规则-1010|→ 详解5]]) 6. **可靠性提升值回 token 开销,还能改用更便宜的模型**——Cole 用 Sonnet 4.6 加 harness 一次跑成了 Opus 4.6 裸跑都做不出的应用。([[#6-代价与回报token-换来的可靠性还能降级模型-1605|→ 详解6]]) ## 知识点详解 ### 1. 根因是 Sycophancy:agent 不能给自己打分 [00:37](https://youtu.be/HAkSUBdsd6M?t=37) Sycophancy(谄媚)指模型倾向于附和、强化用户与自己的观点,偏见过重;而且随着模型越来越强,这个毛病不减反增。 在 AI 编码里它伤害最大:让写代码的 agent 评审自己刚写的代码,等于让学生给自己的作业打分——会话里已经注入了大量你的意见、积累了大量偏见,它几乎必然给自己贴金星。 它可能挑几个小毛病让评审显得像回事,但更大的问题被藏起来,等你真拿这套代码上生产就爆雷。 ### 2. 对抗性开发:给主 agent 配一个专职挑刺的陪练 [01:22](https://youtu.be/HAkSUBdsd6M?t=82) 对抗性开发的做法是:另起一个完全独立、有自己 context session 的编码 agent,唯一职责就是撕开主 agent 的实现。 Cole 特意把它设计得吹毛求疵、专唱反调(devil's advocate),连代码库里更深层的设计决策也要质疑。 「独立会话」是关键——它避开了详解1 里自评会话的偏见污染,和 [[Context Rot]] 说的「同一上下文塞太多东西导致判断退化」是同一层考量。这也把单 agent 升级成了多 agent,会带来一些额外开销,后面会谈。 ### 3. 灵感来自 GAN:生成器想骗过评估器 [02:57](https://youtu.be/HAkSUBdsd6M?t=177) 架构借鉴自生成对抗网络(GAN)。在 GAN 里,一个模型负责生成图像,另一个「判别器」的唯一职责是分辨哪些图是真实数据集里的、哪些是生成的。 生成器为了骗过判别器,会越练越逼真——对抗训练本身把质量往上顶。[03:13](https://youtu.be/HAkSUBdsd6M?t=193) 把这个思路搬到大模型和编码 harness 上:生成器 agent 尽力让评估器相信应用是能跑的,而只要评估器判得准,它就骗不过——「骗成功」的唯一途径就是应用真的做对了。 ### 4. 三段式 harness:规划器 + 生成器 + 评估器 [04:03](https://youtu.be/HAkSUBdsd6M?t=243) Anthropic 的方案(以及 Cole 复刻的版本)有三个 agent:规划器(planner)先根据用户需求产出初始 spec,随后进入生成器(generator/implementator)与评估器(evaluator)的迭代循环。 规划器的价值在于把负担从用户身上卸下:你只需大致说清想造什么,它会把 prompt 扩成一份为 harness 优化、结构统一可复现的完整 spec,不用你一开始就写得极其精确。[08:15](https://youtu.be/HAkSUBdsd6M?t=495) Cole 用它自动搭出的样例应用是一个 RAG 版 YouTube 问答站——带完整检索后端、token 流式输出、能标出处的精致前端,他只发了一条请求、让 harness 自己迭代约 4 小时跑成。[05:38](https://youtu.be/HAkSUBdsd6M?t=338)他强调单 agent 会话绝造不出这么复杂的东西。对照 Anthropic 自己的复古游戏机 demo:单 agent 版界面好看但玩法根本跑不起来,harness 版才真能玩。[04:47](https://youtu.be/HAkSUBdsd6M?t=287) 这正是 Meta Harness 说的「编排多个 agent 而非强化单个 agent」的又一具体形态——甚至可以混用,让 Claude 当实现器、Codex 当评估器。 ### 5. 动手前先「谈契约」:对抗但事先约定规则 [10:10](https://youtu.be/HAkSUBdsd6M?t=610) 进入 sprint 循环后,在写第一行代码之前,生成器和评估器要先协商一份「契约」:上来就商定把 spec 拆成哪几个 phase、每个 phase 用什么标准来评判。 所以它虽是对抗——评估器要撕开生成器的实现——但双方事先就「这场仗怎么打」达成一致,很有「战前礼节」,不是无规则混战。 每个 sprint 里列出需要实现的功能,以及评估器要判的一组 criteria;每条 criteria 由评估器打 1-10 分并设阈值,达到或超过阈值就算过、可推进,一个 sprint 全过才进下一个。[11:33](https://youtu.be/HAkSUBdsd6M?t=693) 生成器拿到反馈后**最多重试三次**,它的唯一目标就是「取悦」评估器;只要 criteria 真的指向「应用正确工作」,那么它拼命取悦评估器的过程,就等于把应用做对。[12:26](https://youtu.be/HAkSUBdsd6M?t=746) ### 6. 代价与回报:token 换来的可靠性,还能降级模型 [16:05](https://youtu.be/HAkSUBdsd6M?t=965) 明显的缺点是 token 成本:完整的 specking + 实现-评估-迭代循环会跑很久——这类工具本就叫「long-running agent harness」。 但 Cole 认为完全值:与其自己盯着单 agent、趟一堆 AI slop、事事给反馈,不如搭个系统把这些自动接管掉。[16:34](https://youtu.be/HAkSUBdsd6M?t=994)他整套只用了 Claude Sonnet 4.6。 关键反直觉点:他说 Opus 4.6 裸跑都无法一次做出这个应用,而 Sonnet 4.6 加 harness 做到了。[16:52](https://youtu.be/HAkSUBdsd6M?t=1012)也就是说,harness 让你可以改用更快更便宜的模型仍拿到好结果——把赌注从「堆最强模型的推理力」挪到「你为 AI 编码搭的系统」上。 ## 可执行步骤 - [ ] 永远不要让写代码的 agent 评审自己的产出;把评审放进一个独立的 agent 会话。 - [ ] 给主实现 agent 配一个专职「唱反调」的评审 agent,明确指令它吹毛求疵、质疑深层设计决策,而非泛泛点评。 - [ ] 若跨工具,可让一个模型做实现、另一个做评估(如 Claude 实现 + Codex 评估),按强项分工。 - [ ] 让实现器与评估器在动手前先约定 sprint 划分与每个 sprint 的评判 criteria(可用 1-10 打分 + 阈值),把「怎么评」显式化。 - [ ] 给生成器设一个重试上限(如 3 次),避免无限循环烧 token。 - [ ] 用便宜/快的模型(如 Sonnet 级)搭 harness 跑,对照裸跑的贵模型,验证「系统 > 单纯堆算力」。 ## 关联 - 印证:[[2026-06-15-Omnigent编排多个AI编码助手的元Harness|Omnigent]] 里的 Debbie 编排器「pits two coding agents against each other to argue」,与本片「对抗性开发」是同一「让 agent 互相对抗校验」思路的两种落地(→ 详解2、3)。 - 印证:该笔记「代码审查必须放在独立于实现的会话里,是编排设计的基本原则」,与本片「给主 agent 配独立会话的评审陪练、不能自评」是同一条原则的复现(→ 详解1、2)。 - 印证:两片都归到 Meta Harness「编排多个 AI 编码助手而非强化单个 agent」的框架下,且都提到可混用 Claude 实现 + Codex 评估([[#4-三段式-harness规划器--生成器--评估器-0403|→ 详解4]])。 ## 术语 - Sycophancy(谄媚 / 阿谀,模型附和并强化用户与自身观点的偏见倾向) - Adversarial Dev(对抗性开发,用独立评审 agent 专职反驳主 agent 产出的做法) - GAN(生成对抗网络,生成器与判别器对抗训练以提升生成质量的机器学习范式) - Generator / Evaluator(生成器 / 评估器,harness 里负责实现与负责打分挑刺的两个 agent) - Planner(规划器,把粗糙用户需求扩成完整可复现 spec 的前置 agent) - Sprint(冲刺,把大 spec 拆成的一个可管理阶段,含功能清单与评判 criteria) - Harness(围绕编码 agent 的规则/流程/评估系统,决定其可靠性上限) ## 金句 > "The worst thing you can do is have a coding agent evaluate its own work." [00:37](https://youtu.be/HAkSUBdsd6M?t=37) → 自评等于学生给自己作业打分,Sycophancy 让它必给金星——这是全片解法的出发点。 > "Really this is the future of AI coding, having separate coding agents work together to accomplish larger tasks more reliably." → 可靠性的增量不来自更强的单模型,而来自多 agent 协作的系统设计。 ## 立场与利益 Cole 复刻了 Anthropic 那篇博客的思路,自建了 Claude 版和 Codex 版 harness 并开源(视频里引导观众下载试用),推广「对抗性开发」这个概念本身也与他一直在做的 harness engineering 方向(参见 [[2026-06-15-Omnigent编排多个AI编码助手的元Harness|Omnigent]] 一片提到的 Archon)一致,构成一种间接利益。本片有付费赞助(一个编程学习平台),已按去销售化处理略去。核心的架构主张与 demo 是可复现的第三方技术演示。 ## 价值定位 - 适合谁:想提升 AI 编码可靠性、正在了解多 agent 对抗校验的人;尤其是已经受够了单 agent「自我感觉良好、上生产才爆雷」的进阶用户。 - 解决什么:给出一套可照搬的对抗式质量闸——用独立评审 agent + 事先约定的评判 criteria,把「谁来挑刺、按什么标准」系统化,而不是靠自己一遍遍人工兜底。 - 认知 vs 实操:核心原则(禁止自评、独立评审会话、按强项分工、重试上限)脱离具体工具也能当天照做;要完整跑起三段式 harness 则需装 Cole 的仓库、理解 planner/generator/evaluator 结构,即用门槛偏高。 - 与 [[2026-06-15-Omnigent编排多个AI编码助手的元Harness|Omnigent]] 重叠(都讲多 agent 对抗/独立评审),但本片独有的是「生成器-评估器契约协商 + 1-10 阈值评分 + 最多重试三次」这套 GAN 式循环的具体机制,以及「Sonnet+harness 胜过裸跑 Opus」的降本证据。 ## 自检问题 1. 为什么不能让写代码的 agent 评审自己的产出? **答案**:受 Sycophancy 驱使,自评的 agent 像给自己作业打分的学生,几乎必给高分、把大问题藏起来;会话里已积累大量偏见。见详解1 [00:37](https://youtu.be/HAkSUBdsd6M?t=37)。 2. 「对抗性开发」具体指什么?关键设计约束是什么? **答案**:另起一个完全独立、有自己 context session 的编码 agent,唯一职责是撕开主 agent 的实现、吹毛求疵唱反调;关键是「独立会话」以避免偏见污染。见详解2 [01:22](https://youtu.be/HAkSUBdsd6M?t=82)。 3. 这套 harness 借鉴 GAN 的哪一点?生成器怎样才算「骗过」评估器? **答案**:借鉴生成器 vs 判别器的对抗训练;生成器尽力让评估器相信应用能跑,只要评估器判得准,唯一能「骗成功」的方式就是应用真的做对了。见详解3 [02:57](https://youtu.be/HAkSUBdsd6M?t=177)。 4. 生成器和评估器在写代码之前先做什么?为什么说它「对抗但很讲礼节」? **答案**:先协商一份契约,约定把 spec 拆成哪几个 phase、每个 phase 用什么 criteria 评判;虽是对抗,但双方事先就「怎么打这场仗」达成一致。见详解5 [10:10](https://youtu.be/HAkSUBdsd6M?t=610)。 5. 本片给出的「系统 > 堆算力」证据是什么? **答案**:Cole 用 Sonnet 4.6 加 harness 一次跑成了一个复杂 RAG 应用,而他说 Opus 4.6 裸跑都做不到——harness 让你能降级到更便宜的模型仍拿好结果。见详解6 [16:52](https://youtu.be/HAkSUBdsd6M?t=1012)。 > [!quote] 💬 热门评论 top-15 主 + 5 回(抓取 2026-07-07) > > [3] **@UsuallyOff**:过去几周我一直在用Claude Code和Gemini这么做，这是个好策略。我把提示词同时给它们俩，等它们各自给出方案后，再把每个方案喂给另一个，然后来回传递它们的批评意见，直到达成一致。一半情况下它们会达成一个比各自原方案更好的折中方案，另一半情况下一方会承认另一方的方案更好，偶尔它们会意识到原方案有问题或者整个前提就不对。强烈推荐用Gemini和Claude试试 👍 2 > [4] **@UnchainedSky**:评估代理不与构建代理共享上下文是关键。当两者共享历史时，评估者已经被推理轨迹带偏了。新鲜的上下文迫使它真正评估输出 > [5] **@kanteberlin**:那个编码框架真的很聪明。我一直在手动做简化版：用Claude Code规划和实现，然后用Gemini或Codex验证计划和实现，再把反馈喂给Claude Code让它思考，采纳那些合理的意见而不是吹毛求疵 👍 8 >   ↪ **@ColeMedin(UP)**:谢谢！我也很喜欢你的方法 :) > [6] **@hypnoticblaze4323**:这是对抗性A/B测试，对文本和编码任务效果极好。当我让Sonnet和Opus与GPT 5.4 Thinking对战时，结果比只用单个模型好得多 👍 1 > [7] **@UsuallyOff**:我刚改进了我的对抗性工作流，你可以试试这个—— 1. Claude Code在计划模式或超级计划模式下生成计划 2. 计划出来后，把它传给另一个终端里的Codex，以及第三个终端里的另一个Claude Code会话，让它们独立审计计划 3. 把Codex的担忧分享给Claude Code审计员，合并它们的两份担忧列表 4. 把合并后的担忧列表传回Claude Code的计划模式进行修改 5. 重复步骤2-4，直到Codex和Claude Code审计员都没有更多担忧。可选地，你可以清除两个审计员的上下文，再把最终计划传给它们做最后一次审计。一旦审计员不再提出任何担忧，就清除执行者Claude Code会话的上下文，让它执行最终修改后的计划 6. 让Codex和审计员Claude Code通过对比差异来审计实际执行，检查计划是否有错误或偏离 7. 按照类似的工作流，把Codex的执行担忧传给审计员Claude Code合并列表，再反馈给执行者Claude Code进行修正 8. 重复步骤6-7，直到Codex和审计员Claude没有更多担忧。可选地，清除审计员的上下文再做一次最终审计 9. 询问审计员Claude Code，整个会话中的错误是否应该保存到memory.md中以防止未来再犯。不过，如果你在整个会话中没有清除审计员的上下文，这一步效果最好。小取舍 > [10] **@pvdyckful**:我也在手动做类似的事情，让Claude Code写代码，然后喂给另一个会话审查。但从没想过要自动化这个循环。谄媚问题确实存在，我有过代理因为是我建议的就同意明显错误的方法 👍 1 > [14] **@software_developer5**:关于绿地项目的内容很多，但几乎没有关于大型企业级项目的。我猜那才是难点。做个关于这个的视频吧。 👍 3 >   ↪ **@ColeMedin(UP)**:说得对，我正计划很快专注于一些棕地开发策略。我的频道上已经有一个视频讲了一些方法：https://www.youtube.com/watch?v=nxHKBq5ZU9U 👍 5 > ——其他 7 条:感谢/夸赞([2]@now.here.nowhere、[8]@sssubarusss、[9]@truthseeker318、[11]@lopa-wt7eg、[12]@MasterCoderX、[13]@digitus78、[15]@cirriussolutionsinc.8514);1 条 spam 已略 >
英文原文[1] @ColeMedin(UP):If you're interested in building your own AI second brain to save yourself hours every week, check out the Dynamous community and upcoming 4 hour second brain workshop: https://dynamous.ai/second-brain-bootcamp 👍 7
  ↪ @B01:South Park hit this one pretty well. Stans mom was fed up with Stans dads constant ai use and figured she would test things and said: "hey I wanna make a business selling French fries but as salad" gpt responds: "GREAT IDEA!!" 🤣 she's then immediately shown to realize what we all have🤣🤣
[2] @now.here.nowhere:my mind is always blown whenever I watch your videos. This is perfection! Thank you! 👍 1
  ↪ @ColeMedin(UP):I appreciate it a ton, you are welcome!
[3] @UsuallyOff:I’ve been doing this with Claude code and Gemini for the past few weeks and it’s a great strategy. I give both of them my prompt and after both provide their own solution I feed each of their solutions into the other and then pass their critiques back and forth until they come to an agreement. Half of the time they come to a compromise that was better than either of their original solutions, the other half of the time one admits the other approach is better and sometimes in rare cases they both realize their original solution was flawed or the entire premise is flawed . 10/10 recommend with Gemini and Claude 👍 2
[4] @UnchainedSky:the evaluation agent not sharing context with the builder is the key insight. when both share history, the evaluator is already biased by the reasoning trail. fresh context forces it to actually evaluate the output
[5] @kanteberlin:The coded harness is really smart. I've been doing this in a simplified version manually: Plan and implement with Claude Code and verify the plan and implementation with Gemini or Codex, then feed the review back to Claude Code to reason about it and include what was actually plausible and not nitpicking. 👍 8
  ↪ @ColeMedin(UP):I appreciate it! Love your approach as well :)
[6] @hypnoticblaze4323:It's adversarial A/B testing that works ABSOLUTELY well for text and coding tasks. When I pit Sonnet and Opus against GPT 5.4 Thinking the results are exponentially better than using only one model. 👍 1
[7] @UsuallyOff:Just revised my adversarial workflow you should try this - 1. Claude code generate plan in plan mode or ultra plan mode 2. Once plan is presented pass it to codex in another terminal and also to another Claude code session in a third terminal to audit the plan independently 3. Share codex’s concerns with the Claude code auditor to consolidate their two lists of concerns 4. Pass back the consolidated list of concerns to Claude code’s plan mode to revise 5. Repeat steps 2-4 until both codex and Claude code auditor have no more concerns. Optionally you can clear the context of both auditors and pass the final plan to them again for one final audit pass. Once the auditors no longer surface any concerns then clear context of the executor Claude code session and have it execute the final revised plan 6. Have both codex and the auditor Claude code audit the actual execution by reviewing the dif against the plan to address mistakes or deviations from the plan. 7. Follow similar workflow as before passing codex’s execution concerns to the auditor Claude code to consolidate their lists and feed back to the executor Claude code to make the corrections. 8. Repeat steps 6-7 until codex and auditor Claude have no more concerns. Optionally clear the context of the auditors for one more final audit pass. 9. Ask the auditor claude code if any of the mistakes throughout the session should be saved to memory.md to prevent them in the future. However this step works best if you had not cleared the context of the auditors throughout the session. Minor trade off.
[8] @sssubarusss:Good timing, yes I do this often in my workflow especially when I am updating my dev frameworks or skills etc. 👍 2
[9] @truthseeker318:I had this concept and never got around to building it. This is awesome! 👍 1
[10] @pvdyckful:been doing something similar manually, having claude code write the code then feeding it to a second session to review. never thought to automate the loop tho. the sycophancy problem is real, ive had agents agree with obviously wrong approaches just because i suggested them 👍 1
[11] @lopa-wt7eg:🐐🐐🐐🐐 the G is back 👍 2
[12] @MasterCoderX:I ve been doing this for months actually i have a full ai boardroom.. 👈🏻👈🏻😎😎👍👍 👍 1
[13] @digitus78:i always give both the same prompt then feed them screenshots of their responses to each other. Im a sonnet fan big time but gemini is the one aways fixing claudes code. 👍 2
  ↪ @ColeMedin(UP):Nice!
[14] @software_developer5:There are loads of things about green fields projects but there is almost nothing about large enterprises level projects. I guess that’s the hard stuff. Create a video about that. 👍 3
  ↪ @ColeMedin(UP):Yeah that is fair, I am planning on focusing on some more brownfield development strategies soon. Also have a video on my channel already with some approaches: https://www.youtube.com/watch?v=nxHKBq5ZU9U 👍 5
[15] @cirriussolutionsinc.8514:Thanks! 👍 1
1. Claude Code在计划模式或超级计划模式下生成计划 2. 计划出来后，把它传给另一个终端里的Codex，以及第三个终端里的另一个Claude Code会话，让它们独立审计计划 3. 把Codex的担忧分享给Claude Code审计员，合并它们的两份担忧列表 4. 把合并后的担忧列表传回Claude Code的计划模式进行修改 5. 重复步骤2-4，直到Codex和Claude Code审计员都没有更多担忧。可选地，你可以清除两个审计员的上下文，再把最终计划传给它们做最后一次审计。一旦审计员不再提出任何担忧，就清除执行者Claude Code会话的上下文，让它执行最终修改后的计划 6. 让Codex和审计员Claude Code通过对比差异来审计实际执行，检查计划是否有错误或偏离 7. 按照类似的工作流，把Codex的执行担忧传给审计员Claude Code合并列表，再反馈给执行者Claude Code进行修正 8. 重复步骤6-7，直到Codex和审计员Claude没有更多担忧。可选地，清除审计员的上下文再做一次最终审计 9. 询问审计员Claude Code，整个会话中的错误是否应该保存到memory.md中以防止未来再犯。不过，如果你在整个会话中没有清除审计员的上下文，这一步效果最好。小取舍 > 👍 2 · **@sssubarusss**:Good timing, yes I do this often in my workflow especially when I am updating my dev frameworks or skills etc. > ↪ 时机正好，我经常在工作流中这么做，尤其是更新开发框架或技能的时候 > 👍 1 · **@truthseeker318**:I had this concept and never got around to building it. This is awesome! > ↪ 我也有这个想法，但一直没动手去实现。这太棒了！ > 👍 1 · **@pvdyckful**:been doing something similar manually, having claude code write the code then feeding it to a second session to review. never thought to automate the loop tho. the sycophancy problem is real, ive had agents agree with obviously wrong approaches just because i suggested them > ↪ 我也在手动做类似的事情，让Claude Code写代码，然后喂给另一个会话审查。但从没想过要自动化这个循环。谄媚问题确实存在，我有过代理因为是我建议的就同意明显错误的方法 > 👍 2 · **@lopa-wt7eg**:🐐🐐🐐🐐 the G is back > ↪ 🐐🐐🐐🐐 大神回归了 > 👍 1 · **@MasterCoderX**:I ve been doing this for months actually i have a full ai boardroom.. 👈🏻👈🏻😎😎👍👍 > ↪ 我其实已经这么做几个月了，我有一个完整的AI董事会.. 👈🏻👈🏻😎😎👍👍 > 👍 2 · **@digitus78**:i always give both the same prompt then feed them screenshots of their responses to each other. Im a sonnet fan big time but gemini is the one aways fixing claudes code. > ↪ 我总是给它们同样的提示词，然后把它们回复的截图互相喂给对方。我是Sonnet的超级粉丝，但Gemini总是那个修复Claude代码的 > 👍 0 · **@ColeMedin(UP)**:Nice! > ↪ 不错！ > 👍 3 · **@software_developer5**:There are loads of things about green fields projects but there is almost nothing about large enterprises level projects. I guess that’s the hard stuff. Create a video about that. > ↪ 关于绿地项目的内容很多，但几乎没有关于大型企业级项目的。我猜那才是难点。做个关于这个的视频吧。 > 👍 5 · **@ColeMedin(UP)**:Yeah that is fair, I am planning on focusing on some more brownfield development strategies soon. Also have a video on my channel already with some approaches: https://www.youtube.com/watch?v=nxHKBq5ZU9U > ↪ 说得对，我正计划很快专注于一些棕地开发策略。我的频道上已经有一个视频讲了一些方法：https://www.youtube.com/watch?v=nxHKBq5ZU9U > 👍 1 · **@cirriussolutionsinc.8514**:Thanks! > ↪ 谢谢！