前言

以前使用Claude Code作为代码开发工具，但前段时间因为各种原因用不了Opus系列模型了，加上公司推广，就用上了平替版的Qoder来开发代码。

4月期间开发了将近1万行有效业务代码，在开发阶段人工的干预率不超过10%，但联调和提测由于基建的原因，人工干预偏多。

本文会通过两个重点项目的实践，来聊聊基于coding agent，我们的研发效能到底能提高多少，以及在全员AI coding的大背景下，思考我们究竟还有什么值得关心的事情。实践相关的内容比较长，赶时间的读者可以直接跳到感悟部分。

笔者在此简单记录coding阶段的实践和思考，同时也相信，这些经验不止适用于Qoder，也希望沉淀出一些通用策略，以便在其他coding agent上复用。

实践

【实践一】使用Qoder完成网关和外部渠道的支付流程对接

本实践是在已有的成熟架构模式下，通过渠道成熟的接口文档，完成支付流程总共5个接口、2个webhook的对接

开发准备阶段

在开发准备过程中，由于PRD并不是AI原生的（即没有按照AI能理解的结构化方式编写），所以如果直接把PRD喂给AI的话，即使系统的skills、mcp、rules非常完备，Qoder写出来的毫无疑问也是一坨。所以在开发之前，我作为人工参与方主要做了下面几件事：

  1. 渠道接口澄清： 弄清楚渠道接口的调用流程和时序、重试、幂等等特殊case；同时准备渠道完备的接口文档以供后续Qoder理解；
  2. 业务方案澄清： 由于PRD在评审完成之后，还有很多待定点以及和现有业务冲突的地方，必须人工介入和PD、业务对齐整体需求；
  3. 技术方案澄清： 即使可以让AI编写技术方案，但由于基建问题，Qoder并不清楚渠道接入的设计偏好、侧重点。可以预见，如果直接让Qoder根据PRD和渠道文档编写技术方案，势必会造成大量纠正和返工。从成本角度考虑，不如由开发自己编写技术文档的骨架和注意点，然后再交由Qoder完善；
  4. 存量代码梳理： 对于网关来说，接入渠道是一项基本能力，架构非常成熟，所以除了技术方案、PRD、渠道接口外，还应该提供给Qoder系统已有渠道的存量接入代码（如任务调度策略、接口渲染策略等）。不能指望Qoder在没有上下文的情况下自己grep代码理解——这种方式一定有遗漏。

AI Coding阶段

在AI coding之前，我先根据以往的接渠道经验，生成了一个对接新渠道的skill。再通过该skill结合SPEC方式，来完成AI coding的设计，包含方案澄清、代码实现、测试验证和编译完成。

在这个过程中，Qoder会抓取语雀链接、渠道接口文档，以及根据技术文档获取仓库中相关的代码。因为技术方案比较清晰，这一阶段的思考和产出正确率都非常高。之后，Qoder便会针对技术方案中的模糊点生成提问：

在问题澄清之后，Qoder便会生成具体的SPEC文档。此时花费了大概1小时来对文档进行review，并且纠正错误设计，同时让Qoder重新优化SPEC文档：

当SPEC文档澄清完成后，Qoder便可以进入自主的规划、实现、编译和自测阶段。

在Coding的过程中，虽然需要不断澄清Qoder的设计，但有Qoder参与后，确实可以帮忙考虑到技术文档设计阶段难以考虑到的事情。例如新渠道token的刷新机制，就是在Qoder的提问和引导下才发现原来的技术设计文档有误，进而重新优化的。

Code Review阶段

AI Coding完成后，即使多次review过SPEC文档，也需要更具体地基于代码进行一轮CR。

这里我采用了两种方式，一是采用独立上下文的CR agent结合技术文档进行CR，另一个就是人工肉眼check代码。整体耗时大概2小时。在CR阶段发现了几个问题：

  1. Qoder的编码习惯难以match我个人的开发习惯，导致有些代码风格会发生变化。譬如在和渠道交互的时候，所有的出入参全都用json object包裹，虽然对AI来说理解起来没什么难度，但后续的维护可能是一个大问题；
  2. Qoder对当前应用的架构理解还存在欠缺，导致对一些架构相关的基础代码编写处理还比较欠妥；
  3. 因为应用中采用了大量的diamond、数据库配置，但Qoder又很难精准拿到（或者新增）相关的配置信息，导致在配置处理上存在很多异常的问题；
  4. 同时，基于上面的问题，如果一味地提供prompt要求AI修改，可能因为上下文污染，导致Qoder越修越错，最后不得不人工下场干预。

上面的问题，理论上都可以通过harness工程完善来提高代码的AI理解力。对于问题4来说，可以尝试使用subagent来降低上下文占用导致的幻觉。

自测&fix阶段

当代码CR完成后，便开始进入自测阶段。理论上自测也可以通过配置浏览器、HSF、数据库、SLS各种MCP完成，但因为基础设施并没有太完善，所以仍然遵循手工自测的方式。

在自测阶段，发现了几个问题：

  1. 网关应用在对接渠道时，即使给到渠道的标准化对接文档，但仍然没有合理解析渠道的出入参。譬如渠道的出参是data.response.result，Qoder编写的代码解析的时候，硬生生遗漏了中间的response，解析成了data.result，这就完全获取不到渠道的信息了。
  2. 另外和渠道对接的时候，要重点关注渠道的错误码以及相关的幂等重试机制。Qoder根据渠道的技术文档只处理了返回错误的情况，但并没有考虑到错误后的重试、以及如何恢复的case。

面对这几个问题的修复，其实很难再在之前的上下文中通过prompt让Qoder修复。因为有一个尴尬的问题：很多联调出来的bug，需要反复和渠道对焦才能得到处理方案。在这一阶段，经过实践发现，人工修改可能会比AI Coding快得多。

【实践二】使用Qoder完成未知代码的资金结算对接

本实践是在开发者对所开发应用不甚了解的情况下，使用Qoder基于SPEC完成代码编写的过程。代码100%由AI编写完成，整体交付时间在一周左右。

开发准备阶段

和【实践一】的准备阶段一样，虽然不了解开发的应用架构，但还是基于笔者自己的上下文写了一份技术文档，然后再输入给了Qoder+SPEC进行设计和编码。

编写技术文档，一方面是给Qoder阅读，更精确地match上开发者的思路；另一方面，也是笔者对系统的一个熟悉过程。如果开发者自己都不熟悉系统，100% AI Coding对于现阶段来说显然是一个极难实现的目标。

AI Coding阶段

人工完成核心技术文档编写：

在SPEC阶段，经过Qoder的提示，发现之前技术方案的设计有重大问题：

  1. 因为本次需要新增税金数据，按照原来业务代码的恒等式逻辑，本次需要在模型层新增两个字段：税金大小和税金币种；
  2. 同时，因为笔者原来对相关代码不甚了解，在SPEC的过程中，Qoder也帮笔者指出了税金资金流的流入和流出方向，帮助笔者少踩了许多坑。

Code Review阶段

Qoder自主完成代码编写和单元测试后，笔者便另起了一个新的agent协助完成CR。在这一过程中，发现了国家校验相关的问题（只有墨西哥能计税，其他非墨西哥流量应该报警并拦截）。由于整体代码量不高（500行左右），CR和CR fix都是由新的agent结合技术文档自主完成的。

自测&fix阶段

在coding阶段结束后，便进入到整体链路测试阶段。在这一过程中，通过走单发现了一些数据不一致的问题。

CASE1： 订单结算时落库报错，发现代码的字段和数据库新增的字段不一致。——配置人工变更，和Qoder理解有出入，导致数据库insert失败。

CASE2： 在订单部分退款后重新计税，发现结算总金额有误差导致无法结算。人工排查原因后发现，在退款重新计算结算金额的时候，没有处理新增税金的字段。——属于知识库和模型问题导致。只能提示Qoder完成相关代码的补充编写：

从遇到的问题中可以发现，Qoder一方面因为上下文不够、思考过程信息不足，导致技术方案出现偏差。另一方面，遇到非代码问题时，还是需要人工干预和对齐，否则Qoder的代码编写也会出现失误。

感悟

善用SPEC模式

Qoder的SPEC模式非常强大，只需要在对话框中启用SPEC即可。Qoder底层会通过planning、subagent模式结合已有的mcp和skill等工具先进行Q&A，最后再生成spec文档。

用户需要重点review spec文档，反复通过对话的形式进行spec文档的修正，进而提高文档的准确性，保证代码的交付质量。

从交付效果上看，使用SPEC+仔细的代码review会比简单的对话式coding效率和效果都强得多（至少2倍）。

不过有一个问题在于Spec模式的上下文占用可能比较快，不确定多次压缩后效果会不会下降，但目前看起来Qoder的压缩能力还可以，整体准确度并没有明显衰减。

上下文决定一切

虽然现代的coding agent都具有上下文压缩的能力，但我们也不能无限制地在一个session中完成所有需求。

Claude Code的官方文档中就有提到，我们要尽可能地节省上下文，上下文占用率小于50%的效果远高于上下文占用率超过70%的效果。

所以，上下文永远是珍贵的资源，我们可以通过如下方式来节约上下文：

  1. 使用subagent： subagent是独立于主agent的上下文，主agent只需要关心subagent的结果，而无需关心过程。如果读者细心check Qoder的执行过程，就会发现Qoder自己有时候会自发地采用subagent做一些处理；
  2. 使用skill而非mcp： mcp和skill都会占用Qoder的上下文，但mcp只是告诉模型有这么一个工具，远不如skill这种SOP来得准确；
  3. 禁用非必须的skill和mcp： 不要把系统和个人配置的所有mcp和skill在每一个会话中都加载，这样既占用上下文，也会给模型造成选择负担。

同时，我们要利用Qoder的repowiki功能尽可能更新系统的整体架构、利用rule和hook做一些规则上的更新和处理。repowiki和rule都会在每次会话中作为上下文输入给模型，只有不断地更新这些数据、持续维护harness工程，才能保证Qoder越用越好用。

非代码配置影响AI Coding效率

在手工编程的时代，所有人都在通过非代码的配置化来提高研发效能。当老板问”你如何证明系统的研发效能得到提高？”，我想大部分人的答案中可能都包括”以前用代码，现在配置化就能完成”。

除此之外，众所周知的原因，目前应用的部署和发布流程极其复杂，通过配置化可以尽可能地让变更快速上线。但是，在AI Coding时代，当所有代码都可以用AI几乎瞬间编写完成，那些散落在diamond、switch、数据库的配置还能提高研发效能吗？

不仅如此，这些散落在各处的配置，反而给AI的理解造成了各种卡点。就目前的基础设施而言，AI可以快速读到代码的所有内容，但一旦涉及到配置，AI就傻眼了——它很难直接读取配置，也就容易写出各种奇怪的代码。同时，因为没有配置权限，这些配置也要花费大量的时间由开发者自行处理。

人工参与不可避免

很多人会从架构和顶层设计中，重新思考人和AI的定位。极端的顶层设计甚至会认为不需要人工，全部通过AI做需求分析、coding、测试和上线。这确实是一个美好的愿望，但基于目前的一线实践来看，在大型商业系统中，要达到全链路AI可能还需要些时日。简而言之，目前的AI Coding依旧需要专家经验和人工干预。

具体有以下几点感悟：

首先，毫无疑问的是，简单的、类级别改动的需求，可以完全交给AI没有任何问题。

但有一个重要问题：人在需求设计的时候没办法完全阐述清楚需求。不仅是PD，也包含开发。即需求创建方无法一次性把所有需要交付的需求讲述清楚。在这个前提下，也不能要求AI直接写出还原度高、健壮性好的代码。简单来说，目前AI coding只能介入到研发流程的每个原子阶段，通过Vibe Coding的形式完成代码迭代，但对于整套软件生命周期来讲，还是需要人工来将其串起来。

另一个点，就是老生常谈的协作问题。人们往往说，研发的大部分时间都是在开会而不是写代码。同样的，在软件研发的流程中，大部分时间不是在写代码，而是在联调。从深度使用Qoder的两次实践来看，Qoder能在第一次SPEC阶段完成将近85%的代码编写，但后面需要联调fix的15%的代码，却必须要人工介入，Qoder无能为力。

使用Qoder完成渠道对接的时候，笔者就发现，Qoder忽略了很多防御性编程需要的内容（幂等、重试、事务、一致性等），这些内容需要针对不同的系统架构做不同的定制，目前在开发过程中还是需要开发同学深度介入，才能让Qoder写出符合预期的代码。另一方面，这倒不是一个不可解的问题，通过不断基于harness工程完善不同项目的编码习惯和规则，这种case的人工介入会越来越少。

最后想说的是，既然目前人工参与不可避免，那就仍然要求开发人员理解整体的需求、方案设计、代码细节。否则，你敢让一个你不了解的代码上线服务用户、操作资金吗？

程序员的能力边界在哪里？

假如说，上文中提到的、影响AI全链路coding的卡点（模型能力、上下文、基础设施）都被解决了，那么程序员的Job Model是否会改变呢？

答案是肯定的。

首先，程序员不会再拘泥于编程语言，今天可以用Java、明天可以用Python。只要掌握了编程语言的核心思想，语法和生态完全可以由模型来帮助完成。另外，程序员也不用拘泥于工种，不管是前端后端还是大数据，理论上全都可以在AI的辅助下完成。

这样一来，仿佛程序员啥都能干了？AI的到来，看起来让我们对程序员的要求也降低了。其实笔者反而认为恰好相反。AI让程序员不再拘泥于需要死记硬背的八股文和语法，而是需要核心聚焦在那些能迁移的能力上。譬如：学习力、创新力、快速迁移的能力。程序员需要了解的东西也更多了，需要在核心领域上帮助AI做决策、做判断、做指导，而不能只是基本的实现——因为实现这件事，一定是AI做的。

在不远的将来，程序员一定要像掌握计算机基础八股文一样，掌握各种Coding Agent的工具，把代码开发交给AI，然后往更上一层拓展自己的能力边界，深度介入业务的需求和产品能力，才是确定性最高的趋势。

所以，如果你觉得目前的工作没有需要你结合专业知识进行判断的地方，一直都是埋头开发，那么，是时候抬起头，重新看看自己了。