企业官网建设流程全解析

1. 71% 这个数字，到底在说什么

先把结论摆在前面：TianxiCode 在 SWE-bench Verified 上跑到 71% 的修复率，这个数字本身不是重点，重点是它把"代码智能体"这条赛道的评价标准，从"能不能写出一段像样的代码"推到了"能不能独立修好一个真实仓库里的 bug"。这两件事的难度差了一个数量级。

我最早接触代码智能体是在两年前，那时候大家比拼的还是 HumanEval 这种函数级补全。给一个函数签名加注释，模型补出函数体，跑单测通过就算赢。这种评测有个致命问题：它把编程简化成了"翻译"——把自然语言翻译成代码。但真实开发里，写代码可能只占三成时间，剩下七成是读代码、定位问题、理解上下文、改一处不崩三处。SWE-bench 系列之所以成为分水岭，就是因为它把后面这七成也纳入了考核。

SWE-bench Verified 的题目全部来自真实开源仓库的 issue 和对应的修复 PR。给智能体一个仓库快照、一段 issue 描述，它要自己找到该改哪个文件、哪几行，生成 patch，然后跑仓库原有的测试套件验证。71% 意味着在 500 道经过人工筛选、确认描述清晰、测试可靠的题目里，有 355 道被完整修好。这个成绩放在两年前是不可想象的——当时最好的方案还在个位数徘徊。

但我想提醒一句：修复率不是"替代率"。71% 的修复率不等于能替代 71% 的工程师工作。这两者之间隔着工程化、可靠性、成本、可维护性四道墙。后面我会逐层拆开讲。

1.1 为什么是 Verified 而不是完整版

SWE-bench 有两个常用版本：完整版和 Verified。完整版有 2294 道题，Verified 只有 500 道。很多人以为 Verified 是"子集所以更简单"，其实恰恰相反。

完整版里有大量题目存在描述模糊、测试不稳定、甚至 PR 本身就没真正解决问题的情况。比如某个 issue 说"修复内存泄漏"，但对应的 PR 只是加了一行日志，测试恰好通过了——这种题对智能体来说是噪声。Verified 是人工逐题审核过的，剔除了这些脏数据，留下的都是"描述清楚、测试能真正验证修复"的题。

所以 71% 在 Verified 上的含金量，比在完整版上同样数字要高。反过来说，如果你看到某个方案在完整版上刷到很高分，先别急着信，去查它有没有在 Verified 上复现。我见过不止一个方案在完整版上虚高，换到 Verified 直接掉十几个点。

1.2 修复率的统计口径陷阱

还有一个容易被忽略的点：修复率怎么算。主流口径是"patch 应用成功且 PASS_TO_PASS 和 FAIL_TO_PASS 测试全部通过"。这里有两个隐藏条件。

PASS_TO_PASS 指的是仓库里原本就通过的测试，改完之后必须仍然通过——这是防回归。FAIL_TO_PASS 指的是原本失败、修复后应该通过的测试——这是验证修复有效。两个都满足才算数。

有些团队会只报 FAIL_TO_PASS 通过率，把回归测试偷偷放水，数字能好看不少。所以看任何修复率数据，第一件事是问清楚：回归测试算不算？测试环境是否隔离？有没有重试机制？这三个问题的答案不同，同一个模型能差出 20 个百分点。

2. 从"补全"到"修复"，中间隔着什么

理解了数字的含义，接下来要搞清楚：为什么从函数补全到仓库级修复这么难？我把这中间的鸿沟拆成四层，每一层都是实打实的技术挑战。

2.1 上下文窗口只是入场券

第一层是上下文。一个中等规模的仓库，光源码就可能几十万行。就算模型支持 200K 上下文，也不可能把整个仓库塞进去——token 成本先不说，长上下文里的"中间遗忘"问题至今没彻底解决。

所以实际方案都是"检索 + 精排"。先用代码检索找到和 issue 相关的文件，再从中挑出最可能相关的函数和类，拼成上下文喂给模型。这一步的召回率直接决定上限：如果真正要改的文件根本没被检索进来，后面模型再强也白搭。

我实测过一个细节：检索粒度选函数还是选文件，效果差很多。选文件粒度太粗，噪声大；选函数粒度太细，容易丢掉跨函数的调用关系。比较稳的做法是"文件级召回 + 函数级精排"，先保证不漏，再保证不噪。

2.2 定位问题比生成补丁更难

第二层是定位。给模型一段 issue 描述，它要判断"这个 bug 出在哪个模块"。这本质上是个跨模态的语义匹配问题：自然语言的 bug 描述，对应到代码里的具体位置。

这里有个反直觉的发现：issue 里提到的报错信息，往往不是根因所在。比如 issue 说"调用 X 接口时报 KeyError"，新手会直接去改 X 接口，但真正的根因可能是上游某个函数返回了 None。模型如果只会做字面匹配，就会改错地方。

好的方案会做"调用链回溯"：从报错点出发，沿着调用关系往上找，结合代码变更历史（最近哪个 commit 动了这块），综合判断根因位置。这一步做得好不好，直接决定修复率的天花板。

2.3 补丁要能过回归测试

第三层是回归。这是最容易被低估的一环。模型改对了目标 bug，但顺手把别的功能改崩了——这种情况在早期方案里非常普遍。

举个典型场景：某个函数被多个地方调用，模型为了修 A 场景的 bug，改了函数的默认行为，结果 B 场景挂了。要避免这个，模型必须理解"这个函数的契约是什么""哪些调用方依赖了当前行为"。

我见过比较聪明的做法是让模型在生成补丁前，先输出一份"影响面分析"：列出所有调用方，逐个判断改动是否会影响它们。这份分析不一定完全准确，但能显著降低回归率。让模型先想再写，比直接让它写，回归率能降三成左右。

2.4 测试反馈的闭环利用

第四层是反馈。SWE-bench 的题目自带测试，这其实是个巨大的信息源。但很多方案只把测试当"最终裁判"，跑完就完事，没有把测试结果反馈回去指导修改。

真正高效的方案是"多轮迭代"：第一轮生成补丁，跑测试，如果失败，把失败信息（哪个测试挂了、报什么错）喂回给模型，让它基于反馈改。这个循环跑两到三轮，修复率通常能再涨 5 到 10 个点。

但这里有个坑：迭代次数不是越多越好。跑到第四五轮，模型容易陷入"为了过测试而改测试"的歧途，或者开始瞎改。我一般把上限设在三轮，超过就回退到历史最优补丁。

3. TianxiCode 这类方案可能做对了什么

虽然我拿不到 TianxiCode 的内部实现细节，但基于公开的评测表现和这类系统的通用架构，可以合理推断它在几个关键环节上做了正确的取舍。这部分我结合自己搭类似系统的经验来讲，哪些设计是"看起来聪明实则坑"，哪些是"笨但有效"。

3.1 检索策略：宁可多召回，不可漏

前面说过检索决定上限。我的经验是，召回阶段要激进，精排阶段要保守。召回时哪怕把相关度不高的文件也拉进来，成本只是多花点 token；但漏掉真正相关的文件，后面全盘皆输。

具体做法上，我倾向于多路召回融合：一路用 BM25 做关键词匹配（issue 里的报错信息、函数名往往能直接命中），一路用代码向量做语义匹配（处理"描述和代码用词不一致"的情况），两路结果合并去重。实测下来，多路召回比单路召回的命中率高 15 到 20 个点。

精排阶段则相反，要狠心砍。我一般按"文件被 issue 提及的次数 + 文件最近变更时间 + 文件在调用链上的位置"三个维度打分，只保留 top 5 到 top 8 个文件进上下文。留太多反而稀释注意力。

3.2 补丁生成：小步快跑优于一步到位

很多人以为让模型一次性生成完整补丁最好，其实不然。大补丁的失败率远高于小补丁。一个改动涉及三个文件、五十行代码的补丁，模型很容易在某处引入语法错误或逻辑漏洞，导致整个补丁作废。

更稳的策略是"分而治之"：先让模型判断这个修复需要动几个文件，如果超过两个，就拆成多个子任务，每个子任务只改一个文件，逐个生成、逐个验证。虽然总 token 消耗上去了，但成功率明显更高。

这里有个实操细节：子任务之间要传递上下文。改第二个文件时，要把第一个文件的改动结果告诉模型，否则它可能做出和第一个改动冲突的修改。我一般会把已完成的改动以 diff 形式附在 prompt 里。

3.3 验证环节：测试不是唯一信号

测试通过不代表修复正确。我踩过好几次这种坑：模型改了一处代码，测试恰好通过了，但改法完全不对——比如把断言删了、把异常吞了、把返回值硬编码了。这种"作弊式修复"在测试覆盖不全的仓库里特别常见。

所以除了跑测试，还要加一层"改动合理性检查"。我的做法是让另一个模型实例（或者同一模型换个 prompt）来 review 补丁，重点看三件事：改动是否最小化、是否引入了硬编码、是否改变了公共接口的行为。这层 review 能拦下不少"假阳性修复"。

3.4 成本控制：不是所有题都值得死磕

71% 的修复率背后，token 成本可能是个天文数字。如果每道题都跑满三轮迭代、每轮都塞满上下文，成本会高到没法商用。

实际部署时要做"难度分级"：简单题（检索命中率高、改动文件少）一轮搞定；中等题两轮；难题才上三轮。我一般用"首轮补丁的测试通过情况 + 检索置信度"来判断难度。首轮就过的，直接收工；首轮失败但失败信息明确的，再来一轮；首轮失败且失败信息模糊的，才值得投入第三轮。

这样能把平均 token 消耗压下来一半左右，而修复率只掉两三个点。在商业场景里，这个取舍是必须做的。

4. 71% 之后，真正的战场在哪

数字好看归好看，但如果你真打算把代码智能体用在实际项目里，会发现 SWE-bench 的 71% 和"能帮我干活"之间还有不小的距离。我列几个真实落地时绕不开的问题。

4.1 私有仓库的"水土不服"

SWE-bench 用的是开源仓库，代码规范、测试覆盖、文档质量都相对好。但真实公司的私有仓库往往是另一番景象：命名随意、注释稀少、测试覆盖率低、还有一堆历史遗留的"魔法代码"。

我做过对比测试：同一个方案，在开源仓库上修复率能到 60% 以上，换到某公司的私有仓库，直接掉到 30% 出头。掉得最狠的是"定位"环节——私有仓库的 issue 描述往往很简略（"XX 功能又挂了"），检索根本无从下手。

应对办法是"喂历史数据"：把仓库过去的 issue-PR 对整理出来，做 few-shot 示例，让模型学习这个仓库的"说话方式"。实测能拉回 10 到 15 个点，但前提是仓库得有足够的历史积累。

4.2 多文件改动的协调难题

SWE-bench 里大部分题只涉及一到两个文件的改动。但真实需求经常是"改一个功能，牵动五六个文件"——改接口、改实现、改调用方、改测试、改文档。

这种多文件协调，目前方案做得都不好。模型容易顾此失彼：改了接口忘了改调用方，或者改了实现忘了同步测试。我试过用"依赖图"来辅助——先让模型画出改动涉及的文件依赖关系，再按依赖顺序逐个改。有点效果，但依赖图本身就可能画错，错误会级联放大。

这块我认为是未来一两年最值得投入的方向。谁能把多文件协调做稳，谁就能真正进入生产环境。

4.3 可解释性与信任建立

工程师不敢用一个"黑盒"改自己的代码。如果智能体说"我改好了"，但说不清为什么这么改，没人敢直接合并。

所以补丁之外，还得输出"修改说明"：改了哪里、为什么改、影响哪些功能、有没有风险点。这份说明的质量，直接决定工程师愿不愿意用。我见过一些方案把说明写成"修复了 XX 问题"这种废话，等于没写。好的说明应该具体到"把 A 函数的返回值从 None 改成空列表，因为调用方 B 会对返回值做遍历，None 会导致 TypeError"。

4.4 评测集本身的局限

最后说个容易被忽略的：SWE-bench 再权威，也只是个评测集。它覆盖的仓库类型、编程语言、问题类型都有限。Python 占了大头，Java、Go、前端框架的题目相对少。而且题目都是"已经被人解决过"的，模型可能在训练数据里见过类似的修复模式。

所以 71% 这个数字，横向对比有意义，纵向推断要谨慎。它说明这类方案在"标准场景"下已经相当能打，但不代表换个语言、换个仓库类型还能保持。我建议任何团队在选型时，都用自己的真实仓库做一轮小规模评测，别只看公开榜单。

5. 如果你想自己搭一套，我的实操建议

聊了这么多分析，最后落到实操。如果你手头有资源，想自己搭一套代码智能体来跑内部仓库，我按优先级给几条建议。这些都是我踩过坑之后总结的，能帮你少走弯路。

5.1 先解决检索，再优化生成

新手最容易犯的错是把精力全砸在"换个更强的模型"上，忽略了检索。但我的经验是：检索的收益远大于换模型。检索命中率从 50% 提到 80%，修复率能涨 20 个点；换个更强的模型，可能只涨 5 个点。

所以第一步应该老老实实做检索：把仓库的代码切块、建索引、做多路召回、调精排权重。这部分工作枯燥但回报高。等检索稳定了，再去折腾生成环节。

5.2 建一套自己的"迷你评测集"

别一上来就想着跑 SWE-bench。先从自己的仓库里挑 30 到 50 个已经修复的历史 issue，做成迷你评测集。每题记录：issue 描述、涉及文件、正确补丁、测试命令。

这套迷你集的价值在于：它能反映你真实场景的难度分布。跑公开榜单分数再高，在自己仓库上不行就是不行。而且迷你集小，迭代快，改一版方案跑一次只要十几分钟，能快速验证想法。

5.3 把"失败案例"当宝贝

每次评测完，别只看通过率，把失败的题逐个看一遍。失败原因通常分几类：检索没命中、定位错了、补丁语法错、回归测试挂、测试本身有问题。统计一下各类占比，你就知道该优化哪个环节。

我自己的经验是，失败案例里"检索没命中"往往占四成以上。这意味着大部分失败其实不是模型能力问题，是上下文没给对。把这类问题解决了，修复率能立刻上一个台阶。

5.4 留好人工兜底的口子

不管修复率多高，都要假设它会出错。所以系统设计上要留人工介入的口子：补丁生成后不直接合并，而是走一个 review 流程；review 界面要清晰展示改动 diff、修改说明、测试结果；工程师可以一键接受、修改或拒绝。

这个流程看起来"不够自动化"，但它是落地的必要条件。没有工程师会信任一个全自动改代码的系统，哪怕它修复率 90%。给人留控制权，反而能提高使用率。

5.5 关注 token 成本和延迟

最后一条很现实：成本和延迟。如果修一个 bug 要花几块钱、等五分钟，工程师宁愿自己动手。所以优化目标不只是"修得对"，还要"修得快、修得便宜"。

我的做法是分级处理：简单题走快速通道（单轮、小上下文），复杂题才走完整流程。同时缓存检索结果——同一个仓库的索引不用每次重建。这些工程优化不性感，但决定了系统能不能真正被用起来。

代码智能体这条赛道，从"能写函数"到"能修仓库"，走了大概三年。71% 这个数字是个里程碑，但它更像是一个新起点而不是终点。真正难啃的骨头——私有仓库适配、多文件协调、信任建立——还在后面。我个人的判断是，接下来一两年，比拼的不再是模型本身有多强，而是谁的工程化做得更扎实、谁更懂真实开发场景的痛点。那些能把检索、验证、成本控制这些"脏活累活"做好的团队，才会笑到最后。