新智元报道

编辑：好困

70万行祖传代码，人走了一拨又一拨，烂尾工程停摆三年没人敢碰。直到首席开发者给Claude Code写了份「说明书」，项目两周收工。

在华盛顿大学基因组科学系，干了快二十年的首席开发者Brendan MacLean，正盯着屏幕上那段代码，眉头越锁越紧。

这段代码属于Skyline的一个功能模块，文件视图面板，搁置了整整一年。

写它的开发者毕业离开了实验室，留下一个半成品。放在以前，这种烂尾工程只有一个结局，永远躺在仓库里，没人敢碰，没人想碰。

但这次不一样。

两周后，这个面板开发完成，所有最终代码提交里都多了一个共同作者的名字，Claude。

17年，70万行，人走了代码还在

Skyline是MacCoss实验室的开源软件，用来帮研究人员检测和量化血浆、组织中的蛋白质，对生物标志物发现、疾病研究和药物开发至关重要。

70万行C文件复制回项目里。只能处理那种不需要参考项目其他代码就能描述清楚的孤立问题，稍微涉及渐进式修改，就完全不行了。

每次对话都像从零开始。Claude不知道Skyline是什么，不知道组件之间怎么关联，不知道17年积累下来的规范。

等一下，这个痛点他太熟了。每次带新人进实验室，不就是这样吗？

新人不知道项目全貌，不知道代码之间的关系，不知道那些只有老人才懂的潜规则。

区别只是，新人会慢慢学会，而Claude每次对话结束就全忘了。

所以他做了一个决定，像带实习生一样带Claude Code。

具体来说，他建了一个独立的代码仓库叫pwiz-ai，专门存放给AI看的上下文，和主代码库完全分开。根目录下的CLAUDE.md是「地形图」，告诉Claude项目的结构、编译方式、测试流程。

项目地址：https://github.com/ProteoWizard/pwiz-ai

但地形图只解决「知道在哪」的问题，不解决「知道怎么干活」的问题。

真正的专业知识存放在skills里。比如他写了一个debugging skill，专门把Claude从「盲猜试错」模式里拽出来。

这个skill的描述里写得非常硬核，「在排查bug、失败或意外行为时始终加载」，逼Claude在动手之前先做根因分析。

再加上MCP集成，让Claude能读取真实的测试数据、异常报告和用户工单。

三层上下文叠满，效果立竿见影。

建好上下文之后，教Claude调试代码库的沟通成本断崖式下降。

因为它已经知道代码是干什么的了。交互的起点是理解，不再是空白。

没人敢碰的代码，两周收工

上下文建好之后，Brendan开始用它清理积压多年的技术债。

这事要从三年前说起。

当时负责维护Skyline每晚测试管理模块的开发者离开了。这个模块是用Java写的，技术栈和Skyline主体的C MCP服务器，让自己能「看到」截图之间的差异。

每天早上Brendan坐下来开始工作之前，Claude自动生成的日报已经躺在收件箱里了，汇总夜间测试失败、异常和未解决的工单。

实验室里原本对AI编程工具最不感冒的开发者，现在用Claude Code构建并发布了一个全新的数据可视化面板。

这个变化，不只发生在MacCoss实验室。

同一周，OpenAI亮出了另一个答案

就在Anthropic发布这篇博客的前一天，OpenAI也放出了一个开源项目——Symphony。

目前，它已经在GitHub上已经拿下了超过1.8万颗Star。

项目地址：https://github.com/openai/symphony

起因是，工程师有时需要同时开3到5个Codex会话，但上下文的切换会把人直接「逼疯」。

Symphony的思路简单粗暴，把Linear项目看板变成AI编程的控制中心。

每一个Open状态的Issue自动分配一个Agent，Agent在独立工作区里持续运行，崩了自动重启，新任务来了自动接手。

人类只需要做一件事，Review结果。

根据OpenAI的统计，部分团队在上线Symphony的头三周，成功merge的PR数量暴涨了500%。

但产出量暴涨只是表面，真正的变化是团队对「工作」的认知被彻底颠覆了。

当工程师不用再盯着Codex会话的时候，每一次代码变更的「感知成本」直线下降。

想试一个重构方案？提个Ticket就行，跑出来不满意直接扔掉，成本几乎为零。

甚至产品经理和设计师也能在Symphony里提Feature Request，不需要Git Clone仓库，不需要开Codex会话。

用人话描述需求，过一会就能收到一份带演示视频的Review包。

更有意思的是Symphony的诞生方式。

它的核心其实就是一份SPEC.md，一个用Markdown写的规范文档。OpenAI让Codex用TypeScript、Go、Rust、Java、Python、Elixir六种语言全都实现了一遍，借此打磨规范里的模糊地带。

最终他们甚至用Symphony编排Codex，重写了Symphony本身。

当然，OpenAI自己也承认，不是所有任务都吃这一套。

需求极其模糊、严重依赖直觉和专业判断的活儿，还得工程师打开交互式Codex会话亲自下场。

「带徒弟」和「开工厂」

虽然路线不同，但Anthropic和OpenAI在回答同一个问题，怎么让AI在真实的工程流程里干活。

Anthropic的答案是「深度」。一个资深开发者花时间构建上下文层，像带实习生一样教会AI理解一个特定的代码库。CLAUDE.md、skills、MCP，每一层都是在加深AI对项目的理解。核心信念是，上下文的质量决定一切。

OpenAI的答案是「规模」。搞一个编排层，每个任务自动派Agent，Agent永不停歇，崩了就重启。工程师从「写代码的人」变成「管看板的人」。核心信念是，编排的效率决定一切。

一个是师傅带徒弟，一个是开自动化工厂。

有意思的是，两条路线在一个关键点上殊途同归。

Brendan写了CLAUDE.md和skills来固化项目知识，OpenAI写了WORKFLOW.md来固化开发流程。

两边都发现，以前靠口口相传和肌肉记忆的东西，现在必须白纸黑字写成文档，AI才能接得住。

「上下文工程」也好，「Harness工程」也好，说到底是同一件事，把人类的隐性知识变成机器可读的显性资产。

两条路线都管用，适用场景也不一样。

面对一个70万行的老代码库，你需要Brendan那种深度上下文工程。面对一个团队级别的新项目，Symphony那种大规模并行调度更合适。

但有一件事，两家公司是完全一致的。

AI编程的瓶颈，已经不是模型写不写得出好代码。瓶颈是人类有没有学会「管理」AI。

正如Brendan所言，「你不会把70万行代码库甩给一个新员工，然后指望他第一天就出活。」

对AI也一样。

参考资料：

https://claude.com/blog/onboarding-claude-code-like-a-new-developer-lessons-from-17-years-of-development

https://openai.com/index/open-source-codex-orchestration-symphony/