How Anthropic runs large-scale code migrations with Claude Code ✍ ClaudeDevs🕐 2026-07-22📦 16.1 KB 🟢 已读 𝕏 文章列表 Anthropic 分享了使用 Claude Code 进行大规模代码迁移的经验，包括将 Bun 从 Zig 迁移到 Rust（两周完成百万行代码）以及 Python 到 TypeScript 的迁移。文章介绍了六步迁移流程，强调建立强大的“评判者”系统、制定规则书和依赖映射，并说明 AI 如何通过并行处理和自动化验证改变了代码迁移的可行性。 代码迁移AI编程Claude CodeDevOpsRust工程化自动化测试并行处理Anthropic技术实践 # How Anthropic runs large-scale code migrations with Claude Code **作者**: ClaudeDevs **日期**: 2026-07-21T19:47:07.000Z **来源**: [https://x.com/ClaudeDevs/status/2079654423828304282](https://x.com/ClaudeDevs/status/2079654423828304282) ---  Code migrations, projects that port a production codebase to a new language, were multi-year endeavors until recently. In the last month, individual developers at Anthropic migrated 10 code packages consisting of tens to hundreds of thousands of lines of code using Claude Fable 5, Claude Opus 4.8, and dynamic workflows. Jarred Sumner (@jarredsumner), co-founder of Bun and Member of Technical Staff at Anthropic, used Claude Code to migrate Bun from Zig to Rust. A million lines of code were produced in less than two weeks, with 100% of Bun's existing test suite passing in CI before merge. Nineteen regressions surfaced after merge and have all been fixed. The Rust port was shipped inside Claude Code in June. Mike Krieger (@mikeyk), co-lead of Anthropic Labs, migrated a Python codebase to 165,000 lines of TypeScript over a weekend. This included hundreds of agents, eight phase gates, three adversarial review rounds, and a final parity check that diffed every command's output against the Python original. Claude Code's new capabilities change the math for these long-deferred projects. Below is the six-step process we now use, drawn from what these migrations taught us. The core insight is that you don't fix the code. You fix the process (loop) that produced the code. ## Why and when to migrate languages Teams launch migrations because of landscape changes between their initial build and current project. Either a known trade-off has become limiting, a better approach has emerged, or the original ecosystem is shrinking. For example, Jarred originally chose Zig because it offered C-level performance with radical simplicity, ideal for a solo founder "writing Bun in 1 year in a cramped Oakland apartment pre-LLM." This simplicity came with known tradeoffs, which he writes about here. Bun's CLI is getting over 10 million monthly downloads and is used extensively within Claude Code. As recently as last quarter, those tradeoffs wouldn't have been enough to justify freezing the roadmap and committing resources to a multi-quarter project. You could maintain two parallel code bases for quarters or years, and if the end result was 90% parity, you had a bigger headache than when you started. Now, the worst case scenario is you delete the branch and try again. There still needs to be a justifiable business case. While million line migrations no longer cost $3 to $4 million in engineering resources over the course of a four year project, they still cost tens to hundreds of thousands of dollars or more to execute. The Bun migration, for example, consumed 5.9 billion uncached input tokens and 690 million output tokens — around $165,000 at API pricing. The main portion of Mike's port was 27 million tokens.  Jarred’s million-line PR. However, the migration case no longer needs to be existential. A year of memory-bug patches in the changelog, or one chronic bottleneck, can now justify it. The compile step was the impetus for Mike's project. The internal tool his team works on ships to users as a single binary. Producing that binary with the Python toolchain took roughly eight minutes per platform, totaling a 30-minute wait across the build matrix on every release. After the port, the same compile now takes about two seconds, the binary starts 6x faster, and the team was able to retire a separate deployment pipeline. ## Why AI changes the code migration math Fable and Opus 4.8 are particularly good at delegating, directing, and verifying parallel workstreams with subagents while finding multiple paths towards stated goals. Large code migrations are a particularly effective use case for these advanced models because: - The work is parallel. Work can be executed across thousands of independent units such as files and crates, so agents can work at the same time rather than have one waiting on the other. - Context is clear and comprehensive. The old code serves as a great spec for the model. - There is a built-in referee. Many large codebases will include a test suite that agents can use to verify their work. - The queue writes itself. When a compiler or test run fails, that becomes the next item for an agent to fix. - They require consistency and edge case handling: reviewers cite the rule behind every finding, so a violation becomes a queue item instead of a quiet divergence. ## Six steps for large code migrations For additional details, you can read Jarred's blog. Prerequisites A prerequisite before starting on your migration project is to have a strong judge in place, otherwise you won't have an exit condition or measure of success. To build this judge: - Categorize existing tests. Use Claude to identify which tests are expressible as external calls and which depend on internals that won't port. - Rewrite for portability. Convert the external-facing tests into assertions that can run against both the original and the port. Use adversarial agents to verify the rewritten tests don't weaken the assertions. - Validate the judge. Run it against the original code to confirm it passes. Then run it against deliberately broken code to confirm it fails — a judge that doesn't catch breakage isn't a judge. This mostly follows Jarred's methodology, with reviews and gates at each stage. Mike followed a similar overall structure using similar loop workflows, but he ran the entire migration end to end, revised the rules and the workflow based on the results, and ran it again — discarding the output each time until the third run.  ## Step 1 — Create the rulebook, dependency map, and gap inventory The order matters: the rulebook must come before the gap inventory. The gap inventory is defined by what the rulebook's defaults won't cover, and the two are tested together in a joint audit. Rulebook The exact shape of the rulebook depends on key architectural decisions you must make at the start. Chief among them, if the new code will follow the same structure, or if it will be completely redesigned. If it's the former (Jarred), the rulebook will primarily be lookup tables that translates types and idioms between languages while pointing to the gap inventory for the harder-to-translate components. If it's the latter (Mike), it will be a design document. Jarred created his rulebook by chatting with Claude, forming a policy for each area of ambiguity. He also used eight subagents specifically designed to review for 8 different categories of common failure modes based on his own intuition. Dependency map You need to understand file dependencies to effectively break up workstreams for a parallel migration so you know which files to migrate first and which files to contain in the same batch. Claude Code can deploy agents to create and run a deterministic script to produce this map. Gap inventory and skeptic reviewers The new language has different requirements from the old language that must be met. For Zig to Rust the difference was manual memory management (C and C++ work the same way). For example: ``` // Zig fn readConfig(allocator: std.mem.Allocator) ![]u8 { const buf = try allocator.alloc(u8, 1024); // ...fill buf... return buf; // caller must free this — but only the comment says so } // A caller that forgets 'defer allocator.free(buf)' still compiles — the leak only surfaces at runtime. ``` ``` fn read_config() -> Vec<u8> { let buf = vec![0u8; 1024]; // ...fill buf... buf // ownership moves to the caller; memory is freed automatically } // Use it after it's moved? Free it twice? Neither compiles. // Forget to free it? There's no free call to forget — drop is automatic. ``` For Python to TypeScript the gap was interfaces and contracts. Python doesn't require a contract declaring what shape of object it will accept or what it returns, but TypeScript does. Both Jarred and Mike created gap inventory files capturing this implicit knowledge. Jarred inventoried these gaps up front, which is what we do here, while Mike chose to translate first and then create the gap inventory by auditing afterwards. You may need to do both. Check out this sample Claude Code prompt to create a gap inventory file. ## Step 2 — Stress-test the rules  In this step, Jarred used one agent to translate three files using the rulebook, one agent to translate three files "like a senior Rust engineer," and one agent to use the diff to create new translation rules. At this stage he caught two critical issues that would have created numerous issues if fanned out across all 1,448 files. This type of stress test only works for structure-preserving migrations, where two translations of the same file are comparable line by line. If your rulebook is a redesign — like Mike's — the equivalent test is attacking the design document directly with adversarial reviewers, then validating it with a disposable end-to-end run. Regardless, throw out any translated files. The goal is to refine the rules, not make incremental progress. ## Step 3 — Translate everything  For the remaining steps, you run the same multi-agent loop architecture: implement, review, and fix. You can offload implementer work to smaller models and keep reviewers on larger ones. For example, Mike used Claude Sonnet when he fanned out 12 subagents for the main migration. The work queue should be mechanical. A batch script decides what's done by checking whether the translated file exists on disk, then slices the pending files into batches for the implementer agents. Because the queue is rebuilt from disk every time, the migration is resumable by construction. Anything the translator can't execute confidently gets flagged with "// TODO(port): <reason>" to be dealt with in step 4. Two adversarial reviewers evaluate the work of the implementers using separate contexts and disagreement between reviewers goes to a third agent. When a reviewer keeps catching the same mistake across files, the fix isn't per-file. You add one sentence to the rulebook and regenerate the affected batch. The rulebook keeps growing through this step; the code never gets hand-patched against it. One important design decision to note in this step is where the compiler sits. Mike ran the TypeScript compiler inside every loop, because it checks a unit in seconds. Jarred banned the compiler from the loop entirely and deferred it to the next step, because cargo takes minutes. ## Steps 4, 5, 6 — Compile, run, and match behavior  These three steps share the same loop architecture and need progressively less human judgment, so we cover them together. Jarred executed this with an orchestrator script that invoked the compiler once across the whole workspace. "Fixer agents" then ran through the error list in parallel with adversarial review. The build runs again, rinse and repeat. Reviewing the error list is helpful to catch systemic issues that may require adjustments. For example, Jarred ran into thousands of Rust module errors that surfaced after fixing cyclic imports that Zig's lazy compilation tolerated. He fixed the loop by encoding logic to classify which dependence to delete, move, or restructure the boundary. Step 5 also has a mechanical source of truth similar to the compiler error list: crashes from the smoke test. Again, the loop fix was to group issues into categories, in this case grouping causes by root cause that are reviewed by adversarial subagents. Step 6 and the end of our story is comparing the programs' behavior across the two codebases. Our files have now been translated, compiled, and smoke tested. Now it's time to shard them and run the test suite (from the prerequisite stage) against them. Tackle failures with "fixer agents" that review the failed tests against both codebases. Adversarial reviewers check their fixes. The next stage in this loop is a build daemon, which is the only process allowed to rebuild the binary. Fixers write patches; the daemon batches them, rebuilds once, re-runs the affected tests, and feeds the results back. This serializes the most expensive operation instead of letting multiple agents trigger it independently. Mike's approach matters here, because many developers won't have a built-out or ported test suite. Mike had Claude create a small script to run 7 real-world scenarios against both the new port and the original Python codebase, and diffed the results. Each failing scenario got its own fix agent, and the loop ran until all seven passed. Then he went one step further. Claude designed its own end-to-end test suite and ran it autonomously overnight, fixing what broke and re-running four nights in a row. As a result, it caught the paper cuts no scenario list would have predicted. The lesson is that a missing test suite doesn't block this step. If you can't inherit a referee, have Claude build one. Your original codebase is the ground truth either way. ## Code migrations best practices Every run taught us something the previous one didn't. But a few practices held up across every project: - Don't follow this guide blindly. Each migration is different. Treat this as a starting point, and plan your specific migration with Claude before committing to it. - Don't focus on individual failures. Individual failures are the loop's job. Your attention belongs on the patterns. - Make review adversarial and verification mechanical. Let scripts — a compiler, a diff, a test suite — be the referee. - Don't use the largest model for everything. Smaller models handle the high-volume implementation fan-out well; save your largest model for reviewers and for anything that writes rules other agents will follow. - Front-load the human hours. The rulebook and the stress test are the most time-consuming. Everything after is mostly queues burning down. ## Review loop results, not code Jarred's Bun migration is now in production, although every migration has tradeoffs. For example, about 4% of the Rust code sits inside "unsafe" blocks, mostly single-line pointer operations at C/C++ boundaries. But the new codebase is measurably better. Every memory leak the team's tooling can detect has been fixed: one benchmark of 2,000 repeated builds dropped from 6,745 MB of memory to 609. The binary is 19% smaller on Linux and Windows. And cross-language optimization made it 2–5% faster across HTTP serving and real-world workloads like next build and tsc. Pick the codebase you've been tolerating and ask Claude what the migration process looks like for it. ## 相关链接 - [ClaudeDevs](https://x.com/ClaudeDevs) - [@ClaudeDevs](https://x.com/ClaudeDevs) - [158K](https://x.com/ClaudeDevs/status/2079654423828304282/analytics) - [dynamic workflows](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code) - [@jarredsumner](https://x.com/@jarredsumner) - [migrate Bun from Zig to Rust](https://bun.com/blog/bun-in-rust) - [@mikeyk](https://x.com/@mikeyk) - [which he writes about here](https://bun.com/blog/bun-in-rust#just-be-really-smart-and-don-t-make-mistakes) - [Jarred's blog](https://bun.com/blog/bun-in-rust) - [rulebook](https://github.com/anthropics/code-migration-kit-with-claude-code/blob/main/templates/RULEBOOK.md) - [sample Claude Code prompt](https://github.com/anthropics/code-migration-kit-with-claude-code/blob/main/prompts/02-gap-inventory.md) - [build daemon](https://github.com/anthropics/code-migration-kit-with-claude-code/blob/main/scripts/build_daemon.sh) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [3:47 AM · Jul 22, 2026](https://x.com/ClaudeDevs/status/2079654423828304282) - [158.3K Views](https://x.com/ClaudeDevs/status/2079654423828304282/analytics) - [View quotes](https://x.com/ClaudeDevs/status/2079654423828304282/quotes) --- *导出时间: 2026/7/22 08:51:59* --- ## 中文翻译 # Anthropic 如何利用 Claude Code 进行大规模代码迁移 **作者**: ClaudeDevs **日期**: 2026-07-21T19:47:07.000Z **来源**: [https://x.com/ClaudeDevs/status/2079654423828304282](https://x.com/ClaudeDevs/status/2079654423828304282) ---  代码迁移即将生产代码库移植到新语言的项目，直到最近还通常是需要耗时数年的工程。 在过去一个月里，Anthropic 的个别开发者使用 Claude Fable 5、Claude Opus 4.8 和动态工作流迁移了 10 个代码包，包含数万到数十万行代码。 Bun 联合创始人兼 Anthropic 技术人员 Jarred Sumner (@jarredsumner) 使用 Claude Code 将 Bun 从 Zig 迁移到了 Rust。不到两周时间就生成了 100 万行代码，在合并前，Bun 现有测试套件在 CI 中的通过率为 100%。合并后发现了 19 个回归问题，并已全部修复。该 Rust 移植版本已于 6 月随 Claude Code 一起发布。 Anthropic Labs 联合负责人 Mike Krieger (@mikeyk) 在一个周末内将 Python 代码库迁移到了 165,000 行 TypeScript。这包括数百个代理、八个阶段关卡、三轮对抗性审查，以及一个最终的一致性检查——将每个命令的输出与 Python 原版进行比对。 Claude Code 的新能力改变了这些长期搁置项目的计算方式。以下是我们现在使用的六步流程，汲取了这些迁移项目的经验教训。 核心洞察在于：你不是在修复代码，而是在修复产生代码的流程（循环）。 ## 为何以及何时迁移语言 团队启动迁移是因为初始构建与当前项目之间的环境格局发生了变化。要么是已知的权衡变得受限，要么是出现了更好的方法，又或者是原本的生态系统正在萎缩。 例如，Jarred 最初选择 Zig 是因为它提供了 C 级性能和极度的简洁性，非常适合一位“在 LLM 时代之前，于奥克兰狭窄公寓中一年内写出 Bun”的独立创始人。这种简洁性伴随着已知的权衡，他在这里有所描述。 Bun 的 CLI 每月下载量超过 1000 万，并在 Claude Code 内部被广泛使用。 就在上个季度，这些权衡还不足以证明冻结路线图并将资源投入到一个为期数季度的项目是合理的。你可能需要并行维护两个代码库数季度甚至数年，而如果最终结果只有 90% 的一致性，你的麻烦会比开始时更大。 现在，最坏的情况也不过是删除分支，从头再来。 仍然需要有合理的商业理由。虽然百万行代码的迁移不再需要像四年期项目那样耗费 300 到 400 万美元的工程资源，但执行起来仍需花费数十万甚至上百万美元。例如，Bun 的迁移消耗了 59 亿未缓存的输入 token 和 6.9 亿输出 token —— 按 API 价格计算约为 165,000 美元。Mike 迁移项目的主要部分则涉及 2700 万 token。  Jarred 的百万行 PR。 然而，迁移理由不再需要关乎生死存亡。更新日志中一年的内存漏洞修复记录，或者一个长期存在的瓶颈，现在就足以成为理由。 编译步骤是 Mike 项目的契机。他团队开发的内部工具作为单个二进制文件分发给用户。使用 Python 工具链生成该二进制文件每个平台大约需要 8 分钟，每次发布在构建矩阵上总计等待 30 分钟。迁移后，同样的编译现在只需大约 2 秒，二进制文件启动速度提高了 6 倍，团队还得以淘汰一条单独的部署流水线。 ## 为何 AI 改变了代码迁移的计算方式 Fable 和 Opus 4.8 特别擅长在子代理之间委派、指导和验证并行工作流，同时找到通往既定目标的多种路径。 大型代码迁移是这些高级模型特别有效的用例，因为： - 工作是并行的。工作可以在数千个独立单元（如文件和 crate）中执行，因此代理可以同时工作，而无需相互等待。 - 上下文清晰且全面。旧代码为模型提供了极好的规范。 - 内置裁判。许多大型代码库包含测试套件，代理可以用它来验证工作。 - 队列自动生成。当编译器或测试运行失败时，这便成为代理修复的下一个项目。 - 它们要求一致性和边缘情况处理：审查者为每个发现引用规则，因此违规行为会变成队列项，而不是悄悄产生的分歧。 ## 大规模代码迁移的六个步骤 更多详细信息，你可以阅读 Jarred 的博客。 先决条件 开始迁移项目之前的先决条件是建立一个强大的评判机制，否则你将没有退出条件或成功标准。 要构建这个评判机制： - 对现有测试进行分类。使用 Claude 识别哪些测试可以表示为外部调用，哪些依赖于不可移植的内部实现。 - 为可移植性重写。将面向外部的测试转换为可以针对原版和移植版运行的断言。使用对抗性代理验证重写后的测试没有削弱断言。 - 验证评判机制。针对原版代码运行它以确认通过。然后针对故意破坏的代码运行它以确认失败 —— 一个无法捕获破坏的评判机制算不上评判机制。 这主要遵循 Jarred 的方法论，在每个阶段都有审查和关卡。Mike 遵循了类似的总体结构，使用了类似的循环工作流，但他端到端地运行了整个迁移，根据结果修订规则和工作流，然后再次运行 —— 每次都丢弃输出，直到第三次运行。  ## 步骤 1 — 创建规则手册、依赖图谱和缺口清单 顺序很重要：规则手册必须在缺口清单之前。缺口清单由规则手册的默认设置无法覆盖的内容定义，两者在联合审计中一起测试。 规则手册 规则手册的具体形式取决于你在开始时必须做出的关键架构决策。其中最重要的是，新代码将遵循相同的结构，还是将完全重新设计。 如果是前者（Jarred），规则手册主要将是查找表，用于翻译语言之间的类型和惯用语，并指向缺口清单以获取较难翻译的组件。如果是后者（Mike），它将是一个设计文档。 Jarred 通过与 Claude 聊天创建了规则手册，为每个歧义领域制定了策略。他还使用了八个专门设计用于审查 8 种不同常见失败模式类别的子代理，这基于他自己的直觉。 依赖图谱 你需要了解文件依赖关系，以便有效地拆分并行迁移的工作流，这样你就知道哪些文件需要先迁移，哪些文件需要包含在同一批次中。Claude Code 可以部署代理来创建并运行确定性脚本以生成此图谱。 缺口清单和怀疑论审查者 新语言有不同于旧语言的要求，必须满足这些要求。对于从 Zig 到 Rust，区别在于手动内存管理（C 和 C++ 的工作方式相同）。例如： ``` // Zig fn readConfig(allocator: std.mem.Allocator) ![]u8 { const buf = try allocator.alloc(u8, 1024); // ...fill buf... return buf; // caller must free this — but only the comment says so } // A caller that forgets 'defer allocator.free(buf)' still compiles — the leak only surfaces at runtime. ``` ``` fn read_config() -> Vec<u8> { let buf = vec![0u8; 1024]; // ...fill buf... buf // ownership moves to the caller; memory is freed automatically } // Use it after it's moved? Free it twice? Neither compiles. // Forget to free it? There's no free call to forget — drop is automatic. ``` 对于从 Python 到 TypeScript，差距在于接口和契约。Python 不需要声明接受或返回什么形状对象的契约，但 TypeScript 需要。 Jarred 和 Mike 都创建了捕获这种隐式知识的缺口清单文件。Jarred 提前清点这些差距，这也是我们要在这里做的；而 Mike 选择先翻译，然后通过事后审计来创建缺口清单。你可能两者都需要做。 查看此示例 Claude Code 提示以创建缺口清单文件。 ## 步骤 2 — 压力测试规则  在这一步，Jarred 使用一个代理根据规则手册翻译三个文件，一个代理“像高级 Rust 工程师一样”翻译三个文件，还有一个代理使用差异创建新的翻译规则。在此阶段，他发现了两个关键问题，如果这些问题扩散到所有 1,448 个文件中，会造成无数问题。 这种类型的压力测试仅适用于保持结构的迁移，其中同一文件的两个翻译可以逐行比较。如果你的规则手册是重新设计 —— 像 Mike 的那样 —— 等效的测试是直接使用对抗性审查者攻击设计文档，然后通过一次性的端到端运行来验证它。 无论如何，丢弃任何翻译好的文件。目标是完善规则，而不是取得增量进展。 ## 步骤 3 — 翻译所有内容  对于其余步骤，你运行相同的多代理循环架构：实施、审查和修复。 你可以将实施者工作卸载给较小的模型，而将审查者保留在较大的模型上。例如，Mike 在为主要迁移展开 12 个子代理时使用了 Claude Sonnet。 工作队列应该是机械化的。批处理脚本通过检查磁盘上是否存在翻译文件来决定完成了什么，然后将待处理的文件分批切片给实施者代理。因为队列每次都从磁盘重建，所以迁移在结构上是可恢复的。 翻译器无法自信执行的任何内容都会标记为“// TODO(port): <reason>”，以便在步骤 4 中处理。 两个对抗性审查者使用单独的上下文评估实施者的工作，审查者之间的分歧会交给第三个代理。当审查者在不同文件中不断发现相同的错误时，修复不是针对单个文件的。你在规则手册中添加一句话，并重新生成受影响的批次。规则手册通过这一步不断增长；代码从未被手动修补以适应它。 在这一步中需要注意的一个重要设计决策是编译器的位置。Mike 在每个循环内都运行 TypeScript 编译器，因为它在几秒钟内检查一个单元。Jarred 完全禁止在循环中使用编译器，并将其推迟到下一步，因为 cargo 需要几分钟。 ## 步骤 4、5、6 — 编译、运行和匹配行为  这三个步骤共享相同的循环架构，并且需要越来越少的人类判断，因此我们将它们放在一起介绍。 Jarred 通过一个编排脚本执行此操作，该脚本在整个工作区调用一次编译器。然后，“修复代理”通过错误列表并行运行，并进行对抗性审查。再次运行构建，冲洗并重复。 审查错误列表有助于捕获可能需要调整的系统性问题。例如，Jarred 遇到了数千个 Rust 模块错误，这些错误在修复了 Zig 的惰性编译所能容忍的循环依赖后暴露出来。他通过编码逻辑来分类要删除、移动或重构边界的依赖关系，从而修复了循环。 步骤 5 还有一个与编译器错误列表类似的机械真实来源：冒烟测试的崩溃。同样，循环修复是将问题分组，在这种情况下，是按根本原因分组，由对抗性子代理进行审查。 步骤 6 和我们故事的结局是比较两个代码库中程序的行为。 我们的文件现在已经被翻译、编译和冒烟测试。 现在是时候将它们分片，并针对它们运行测试套件（来自先决条件阶段）。使用“修复代理”处理失败，这些代理会根据两个代码库审查失败的测试。对抗性审查者检查他们的修复。 此循环的下一阶段是构建守护进程，它是唯一允许重新构建二进制文件的进程。修复代理编写补丁；守护进程将它们分批，重建一次，重新运行受影响的测试，并将结果反馈回去。这将最昂贵的操作序列化，而不是让多个代理独立触发它。 Mike 的方法在这里很重要，因为许多开发者没有现成或移植的测试套件。Mike 让 Claude 创建了一个小脚本，针对新的移植版和原始 Python 代码库运行 7 个真实场景，并对结果进行差异比对。每个失败的场景都有自己的修复代理，循环运行直到全部七个通过。 然后他更进一步。Claude 设计了自己的端到端测试套件并连夜自动运行，修复损坏的部分并连续运行了四个晚上。结果，它捕获了任何场景列表都无法预测的小问题。 教训是，缺少测试套件不会阻止这一步。如果你无法继承裁判，就让 Claude 构建一个。无论如何，你的原始代码库都是基本事实。 ## 代码迁移最佳实践 每次运行都教会了我们前一次不知道的东西。但一些实践在每个项目中都经得起考验： - 不要盲目遵循本指南。每次迁移都不同。将此视为起点，并在承诺之前与 Claude 规划你的具体迁移。 - 不要专注于单个失败。单个失败是循环的工作。你的注意力应该放在模式上。 - 让审查具有对抗性，验证机械化。让脚本 —— 编译器、差异工具、测试套件 —— 成为裁判。 - 不要在所有事情上都使用最大的模型。较小的模型可以很好地处理大批量的实施展开；将你最大的模型留给审查者以及编写其他代理将遵循的规则的任何事物。 - 前置人力投入。规则手册和压力测试是最耗时的。之后的大部分工作主要是队列销毁。 ## 审查循环结果，而非代码 Jarred 的 Bun 迁移现已投入生产，尽管每次迁移都有权衡。例如，大约 4% 的 Rust 代码位于“unsafe”块内，主要是 C/C++ 边界处的单行指针操作。 但新的代码库明显更好。团队工具可以检测到的每个内存泄漏都已修复：一项 2000 次重复构建的基准测试将内存从 6,745 MB 降至 609 MB。二进制文件在 Linux 和 Windows 上缩小了 19%。而且跨语言优化使其在 HTTP 服务以及 next build 和 tsc 等实际工作负载上速度提高了 2–5%。 选择你一直忍受的代码库，问问 Claude 它的迁移流程是什么样的。
用 用 Claude Code 重构百万行代码：官方六步迁移法深度解读 本文深度解读了 Anthropic 官方如何利用 Claude Code 完成百万行代码的大规模迁移。文章介绍了 Bun 从 Zig 迁移到 Rust 及 Python 项目转 TypeScript 的惊人案例，并提炼出包括制定规则、小范围试跑、对抗性审查等在内的“六步迁移法”，为开发者提供了高效的 AI 编程与代码重构实战指南。 技术 › Claude Code ✍ 程序员鱼皮🕐 2026-07-21 AI编程代码重构代码迁移ClaudeRustTypeScriptAnthropic最佳实践自动化测试
Y Your .claude Folder Is Your AI Operating System 文章深入探讨了如何充分利用 Claude Code 的能力，指出真正的规模化不在于优化提示词，而在于构建围绕 Agent 的工程系统。核心内容包括利用 `.claude/` 目录建立持久化项目记忆、区分项目与个人配置、使用模块化规则替代巨型提示词、通过 Hooks 拦截危险操作、构建专用子代理以及配置权限边界。文章强调未来的开发将从“聊天”转向“编排”，通过环境设计来确保 AI 行为的一致性与安全性。 技术 › Claude Code ✍ Nainsi Dwivedi🕐 2026-05-06 Claude CodeAI Agent工程化开发工作流DevOpsAI编程系统设计
构 构建 Claude Code 的经验：我们如何使用 Skills Anthropic 工程师分享 Claude Code 的 Skills 功能实战经验。文章总结了内部常用的九类 Skills（如库参考、产品验证、业务自动化等），并提供了编写 Skills 的最佳实践，包括利用文件系统结构、明确触发条件以及通过脚本增强模型能力，旨在帮助团队系统化构建和分发 Skills 以加速开发。 技术 › Skill ✍ Thariq Shihipar (译: 宝玉)🕐 2026-03-18 Claude CodeSkillsAgentDevOps工程化自动化最佳实践Anthropic开发效率
如 如何让你的 AI 智能体能力提升 100 倍 文章探讨了如何通过建立完善的评估系统来防止 AI 智能体随着时间推移而性能下降。作者提出了利用文件夹结构和特定提示词记录规则、错误和边界情况的解决方案，将模糊的“感觉”转化为具体的测试用例，从而确保智能体持续高效工作。 技术 › Agent ✍ Andres🕐 2026-07-24 AI Agent评估系统提示词工程自动化测试Claude Code智能体管理效率提升编程实践DevOps
G Graph Engineering: 在一个窗口构建 1000+ Agent 循环的完整指南 本文介绍了 Graph Engineering 的概念，即从线性的 Agent 循环转向图结构的工作流。文章详细讲解了如何利用 Claude Code 的动态工作流功能，通过五个步骤构建并行处理任务的 Agent 图，以解决上下文限制和执行效率问题，并探讨了在扩展到 1000+ Agent 时可能遇到的挑战及解决方案。 技术 › Agent ✍ codila🕐 2026-07-22 Graph EngineeringClaude CodeWorkflowAgent并行处理动态工作流LLMDevOps
3 32个Claude Code技巧：从入门到精通 文章介绍了Claude Code的32个高效使用技巧，分为基础、控制和精通三个层级。内容涵盖项目初始化、上下文管理、语音模式、子代理并行工作、自定义Skills编写、Hooks钩子配置及多模型切换等实战方法，旨在帮助用户在16分钟内掌握从新手到专业开发者的进阶路径。 技术 › Claude Code ✍ Codez🕐 2026-05-31 Claude CodeLLM编程技巧提示词工程开发效率教程AnthropicAI编程技巧分享技术指南
C Claude Code 工程化指南：高效组织 .claude/ 目录 本文旨在探讨如何像管理代码一样管理 Claude Code 的配置目录 .claude/。文章首先指出了混乱的目录结构会随着项目增长导致维护困难，随后提出了一套包含 CLAUDE.md、settings.json、rules/、hooks/、commands/、skills/ 和 agents/ 的标准化目录蓝图。接着，文章详细阐述了核心原则，包括顶层设计的轻重分离、规则模块化、自动化脚本与复用工作流的区别，以及团队与个人配置的边界。最后提供了从简单到复杂的渐进式成长路径，帮助开发者构建可预测、可维护且易于团队协作的 AI 辅助开发环境。 技术 › Claude Code ✍ Vince 聊开发🕐 2026-05-20 Claude Code工程化目录结构最佳实践DevOpsAgent技能工作流配置管理团队协作
B BestBlogs 早报：AI 编码的工程化深水区 本期早报探讨了 AI 编码从「工具替换」走向「工程化」的范式转变。Cursor 发布 Composer 2.5 并公开训练栈，标志着竞争从应用层下沉到模型层；Anthropic 工程师详解长时 Agent 架构，利用对抗式生成-评估循环将续航提升至 12 小时；阿里云 CIO 则提出应摒弃「AI 生码率」，关注端到端业务价值，指出代码即是负债。文章强调，模型能力、Agent 架构与组织效能三者结合，才能实现从写得快到做得对的跨越。 技术 › DevOps ✍ ginobefun🕐 2026-05-19 AI编码CursorAgentDevOps工程化Anthropic阿里云效能度量模型训练LargeLanguageModels
I If You Are Not Using These 100 Repositories, You Are Using Claude Code Wrong 文章指出大多数用户仅将 Claude Code 视为简单的终端助手，而忽略了其通过第三方仓库扩展的强大潜力。作者介绍了涵盖官方工具、生态索引、插件及技能库的 100 个精选仓库，旨在帮助开发者构建从简单的智能编程工具到全功能的 Agent 系统，从而显著提升生产力。 技术 › Claude ✍ NeilXbt🕐 2026-05-19 Claude CodeAI编程插件Agent工具推荐开源开发效率AnthropicSDK生态圈
K Karpathy 的 CLAUDE.md：如何将 Claude Code 编码准确率提升至 94% 文章介绍了 Andrej Karpathy 验证过的 CLAUDE.md 配置方法，该项目在 GitHub 上获得 8.2 万星标。文章分析了开发者在使用 Claude Code 时常遇到的三个痛点：重复解释上下文、AI 擅自修改代码范围、以及缺乏持久记忆。通过在项目根目录创建包含 Defaults、Behavior 和 Memory/Stack 三个部分的 CLAUDE.md 文件，开发者可以将编码准确率从 65% 提升至 94%，并为团队节省大量因沟通和回滚错误造成的时间成本。 技术 › Claude ✍ Dep🕐 2026-05-18 Claude CodeLLM工程化最佳实践效率提升AI编程GitHub配置指南自动化
C Claude Code 在大型代码库中的运作方式：最佳实践与入门指南 文章探讨了 Claude Code 在处理数百万行级单体仓库及遗留系统时的成功模式。区别于传统 RAG 工具的嵌入索引滞后问题，Claude 采用本地代理式搜索实时导航。核心论点指出，工具链生态（CLAUDE.md、钩子、技能、LSP 集成等）的重要性远超模型本身。文章详细解析了七大扩展点，并建议通过渐进式配置与插件分发来提升在大型复杂代码库中的协作效率。 技术 › Claude Code ✍ nash_su🕐 2026-05-17 Claude CodeLLM最佳实践工程化DevOps代码库导航MCPAgent工具链编程
C Claude Code新版本 + CodeGraph + MCP 组合拳！大型代码库直接起飞！ 文章介绍了Claude Code 2.1.142、CodeGraph与MCP的“组合拳”方案，有效解决了大型代码库探索中tool call过多、上下文爆炸等问题。通过CodeGraph构建语义知识图谱，结合MCP持久化记忆与新版优化，实现了Tool call减少92%、代码探索速度提升71%的显著效果，并提供了详细的安装配置流程与实战场景指南。 技术 › Claude Code ✍ loveabit🕐 2026-05-16 Claude CodeCodeGraphMCPLLMAI编程DevOps工具与效率Agent技术选型代码优化