Qoder AI Coding工具开发大型生产化项目的经验分享

引言

作为一名终端用户，我将从实际使用角度分享在使用Coder（AI coding工具）开发一个约2万行代码的生产化项目的过程中遇到的坑，以及我的一些解决问题的方法。有些方法可能是巧合或经验之谈，希望开源研发同学指正。

本次分享主要涵盖两个主题：

1. 外部coding与stack-driven coding的对比。
2. 开发大型开源项目的8个心得。

Topic 1: 外部Coding与Stack-Driven Coding的对比

最近，AI coding（或web coding）非常流行，例如通过一句话在高端客户端或Coder中生成功能，并逐步分解。这是一种典型的AI coding方式。我们团队较早开始使用AI coding，包括GitHub Copilot和阿里自己的工具，主要用于代码生成和单元测试补充。

在最初两年，我们主要针对存量项目进行修补或单元测试覆盖，使用外部coding方式：简单输入一段话，在小范围上下文中生成代码补齐、修正或修改。当时，这种方式基本能解决问题，没有太大issue。

然而，今年开发一个从零开始的大型项目时，我们发现继续使用外部coding存在重大问题。核心在于输入信息过少，导致AI对问题的拆解与实际需求偏差巨大。如果前期依赖外部coding生成大型项目，代码会不断积累问题，最终难以维护。我们最初用外部coding开发开源项目，一周后发现代码无法维护，也不敢上线生产。

因此，一周后我们转向stack-driven coding。如果用一句话总结：对于小项目、工程类项目或对代码质量要求不高的场景，外部coding足够；但对于规模超过3000行、需对代码质量负责（可能引发生产故障）的项目，不建议使用外部coding，应尽可能采用stack-driven coding。

使用AI coding后，我的认知是：程序员并非从“乙方”变成“甲方”（简单抛需求给AI），而更像是与实习生或初级工程师协同编程。AI不是让你成为甲方，而是加速问题拆解和开发流程。外部coding忽略了整个流程，而stack-driven coding则加速每个步骤。

核心问题是，许多人过度依赖AI模型本身的问题优化，而忽略了对AI的使用策略和方法。例如，做网站时，不同的prompting（提示词）会产生完全不同的结果。某些工具在特定场景的提示词优化可能更好，但这很“cheap”且定向。

因此，在AI编程中，我强烈建议在提示词工程和上下文工程上投入大量精力，而非依赖工具对领域的优化，以避免混淆和误导。

将AI视为“实习生”，我们需关注其信任度。使用各种AI工具后，我的感觉是“总有刁民想害朕”——代码中总有潜在坑，如果不仔细审查，问题很难调试。下面通过项目例子说明。

项目介绍

我们开发的项目是Kubernetes社区推出的弹性伸缩工具（名为 Karpenter），它通过模拟调度，利用云上EC2资源生成计算、存储和网络资源，实现资源供给。该项目最初由AWS开发，后成为Kubernetes社区孵化项目。阿里云与社区协商后，提供对应的provider。

项目涉及大量云资源操作（调用众多API）、开源项目协同（实现接口定义的方法）。项目较新，大多数AI模型对其无认识，直接询问AI往往会“瞎编”。开发中，我们遇到不稳定和效果差异问题（多人协作开发），总结出以下心得。

Topic 2: 开发大型开源项目的8个心得

在使用AI coding时，传统写代码时间大幅压缩（从60%降至5%），而30%以上时间用于构建spec和上下文，确保AI输出符合预期。在Coder中，面向不同场景使用不同mode（如快速mode用于框架/实体定义，大模块实现；ask mode用于小修正、参数变更）。

无论哪种方式，与AI沟通时严格遵守“5部分提示”框架，确保交互一致性。

1. 严格遵守5部分提示框架

任何交互都包括：

• 角色定义：不要抽象（如“你是程序员”），而是具体（如“你是Kubernetes开源项目的维护者”），使生成的代码更精准。
• 工作内容：包含足够上下文，如错误代码、关联位置；在ask mode中勾选相关context。
• 工作边界：明确可改/不可改范围，避免AI随意修改无关文件（早期Copilot常见问题）。
• 衡量方式：量化指标，如使用GoLand实现项目、GUnit做单元测试，定义覆盖率阈值。提示可直接（如“做不好就罚站”），无需礼貌。

此框架确保在不同AI模型/工具下行为一致。

2. 如何清晰描述需求

避免让AI自由发散，尤其在未知场景中。项目中，我们使用预prompting：

• 先用Coder生成sample code的VIP（实体、调用关系、接口参数、约束）。
• 然后分析抽象成设计文档（9个文件：架构、实体、接口、调用关系、测试要点、边界）。
• 注入上下文：如阿里云API文档（版本化差异大）、最佳实践。

最后，将抽象生成prompt交给快速mode。

3. 分阶段使用快速mode构建中间产物

分成三个阶段：

• 第一阶段：生成系统整体架构设计，检查框架判断、实体分割、目录结构、依赖库选择。
• 第二阶段：实体和关系设计。
• 第三阶段：接口和字段设计。

三次快速mode后生成中间框架，再进行实际编码。

4. 编码时的上下文预制和约束

• 上下文预制：通过Coder的memory机制注入文档、代码仓库、地址（如Google MCT）。
• 约束：设置全局代码风格、编译方式、语言倾向，确保连贯性。

一句话：约束用规则限制边界，记忆用扩展边界。

5. 管理压缩上下文

Coder调试大代码时，上下文百分比过高（>70%）会导致“胡说”（有损压缩，如预制菜变味）。经验：解决问题时别总用同一上下文；50%时切换新上下文，避免慢响应和低质量输出。

6. 及时提交和accept文件

三个原因：

• 爆炸半径控制：即使设边界，AI仍可能改非预期代码；及时提交便于恢复。
• 处理AI“退堂鼓”：AI倾向简单路径，若难则删前文；及时accept保留好部分，打断继续。
• 便于技术变更：AI使变更成本低，需代码恢复点支持路线分叉。

7. 从可测试的第一步开始测试

惨痛教训：外部coding一周生成2万行代码，自编译通过，但调试时卡在API server端口错误。三天排查（网络、安全、FD泄露等），最终是安全升级拦截IP。

原因：过早生成大量代码，无可测试base。建议：越早进入测试阶段越好（如第一天框架生成时报错，问题易解决）。

8. 构建长期主义的FAT测试集

AI编写80-90%代码，单元测试不足（边界条件少，单一方法正确不代表功能正确）。需黑盒功能测试（FAT）：接口像鸭子即认可。

挑战：MVP需自然语言描述场景，AI易偏差（如pod pending触发ECS生成，隐含参数多）。

解决方案：基础类库（公共方法，如获取地域/磁盘）+ DSL（自然语言到底层映射，如“地域”→“region”）+ 通用potato方式。生成可控、高覆盖FAT，减少AI依赖。

结尾与个人困扰

我较早使用Coder，第一天就用完200 credits，后续多用免费模型，不知付费效果如何。Coder已成为日常工具：

• IDE：代码编写。
• Browser：查材料，整理文档（如科研项目生成系列文章）。
• ISS：材料收集/整理。
• IPA：通过MCP自动化操作