海信用 Qoder 构建了一套完整的 AI 原生开发体系，新系统开发提效 3～4 倍。
海信集团数质中心服务全集团 46 家产品公司，涵盖研发、制造、供应链、营销等领域共计 100+ 套自研系统。技术栈种类多、历史包袱重——一套开发模式无法适应这种多样性。
研发团队最头疼的事从来不是"写不出代码"，而是：新人接手老项目，文档缺失，知识断层，理解成本极高；大量时间花在重复性工作上；线上报错排查费时费力，代码审查也覆盖不了所有隐患。
2023 年大模型爆发，我们看到了解决这些问题的可能性，但当时的编程工具只停留在"局部补全"层面，网络稳定性和安全合规也走不通。
2025 年 1 月，随着 SDD 开发模式的日趋成熟，与 Qoder 团队进行产品交流，2 月组织近百人试点，3 月正式引入 Qoder。到现在超千人在使用。
Qoder 和此前工具的本质区别：它不只是一个补全引擎，而是一套完整的 AI 原生开发工作台，构成了我们落地 AI 原生开发所需要的全部基础设施。
我们围绕 Qoder 的能力矩阵，构建了一套内部称为 Harness 的工程化体系——用来"驾驭"AI 在 109 套系统上稳定产出。
● 高代码场景（占比 70%+）——进一步细分为三类：
● A 类：全新系统开发，从零开始，Qoder 全程参与；
● B 类：老系统上的新模块开发，借助 Repo Wiki 理解存量代码后再生成；
● C 类：老系统已有模块改造，需要先注入大量历史知识再让 Agent 介入。
● 低代码场景——主要用 Qoder 生成配置逻辑和胶水代码；
● 其他场景——如文档、测试脚本等辅助性产出。
Qoder 的 Quest-SDD（Spec-Driven Development）让需求直接变成可执行的开发规约，Spec 的颗粒度和清晰程度，直接决定首次生码质量，同时也影响后续人机交互轮次。我们在真实项目中做了两个实践：
实践一：大 Spec vs 小 Spec。 大 Spec 包含 300 行、分解了 75 个任务，小 Spec 70 行、分解了 12 个任务。结果——大 Spec 首次完成度只有 60%，之后追加几十次对话才勉强完成；小 Spec 首次完成度可达到 95%。
实践二：同一份 PRD，三种处理方式。 直接让 Qoder 生成 Spec → 首次完成度只有 70%，仍需对话澄清 50 轮以上。工程师与产品经理逐行对齐后更新 Spec → 完成度大幅提升。再加上人机对齐（让 Qoder Agent 反问确认理解无误）→ 完成度接近 100%，基本无需追加修改。
由此我们确定了 Spec 质量标准：
● 在当前主流模型能力下，单个 Spec 原则上控制在 100 行以内、最长不超过 150 行；
● 每条约束必须能转化为测试用例，确保需求明确性、可验证性，也为后续 AI 验证提供依据；
● 如果单 Spec 生码后追加人机修正轮次超过 10 次，说明原始 Spec 质量可能不高，回到 Spec 阶段重新对齐。
我们说 AI Coding 进入到 AI 自主阶段，其特征是通过构建反馈回路实现 Human on the loop，通过多智能体协作，执行长周期任务，彻底解放人类。借助 Qoder 和各类开源 Skill，我们得以快速构建多智能体反馈回路，一方面，在 Loop 里通过对应用进行 AI 验证、审查，自动修复，确保软件逐步逼近需求，另一方面，在每次工作流过程中，都可以沉淀知识，实现对 Harness 的优化。
我们认为在 AI 开发中，测试变得更加重要了，因为模型幻觉客观存在，测试是对抗幻觉的重要手段。我们在 AI 生成 Spec 之后一定要同步生成测试用例，而且要对测试用例进行严格的评审，尤其确保边界条件的完整，测试用例要纳入 Git 仓库，作为 Harness 的重要构成，测试 Agent 一定要与编码 Agent 采用不同的模型，实践中我们发现：让 Qoder Agent 把所有缺陷一次性修复完成，效果往往欠佳；但让它每次只修复 1 个缺陷，效果就很好。
同样，100 条测试用例分 10 个批次、在 10 个独立上下文中让 Agent 执行，比合并在 1 个上下文中一次性测试，发现的缺陷更多、漏测率更低。
因此我们的反馈回路一律把任务拆到最小粒度——小批次执行、逐个修复、持续验证。Qoder 的 Agent 能力让这种高频迭代变得可行。除了 Harness 的反馈回路，我们也在借助 Qoder 生态工具，探索 loop engineering。
109 套系统、不同技术栈，要在长周期迭代中保持架构不偏移，约束的重要性不亚于能力。核心原则只有一条：没有围栏约束，AI 产出越多，代码库熵增越快。
围绕这条原则，我们构建了一套覆盖全开发链路的规范和 Skill 体系，按优先级分层管理：P0 锁死架构边界和合规底线，P1 覆盖编码核心，P2 关注可维护性。每个阶段按需注入对应的约束组合，限制 Agent 行为边界，让 AI 在正确的框架内工作。
知识治理是让前三大能力持续增值的底座。我们通过 AGENTS.md + Repo Wiki + Skills 三层体系来承载。
AGENTS.md 是项目级结构化知识地图——约 100 行的入口文件做目录导航，适当废弃大而全的手册。采用渐进式披露的信息组织方式，在任务的不同阶段向 AI 按需推送所需信息，减少上下文冗余。每个项目的架构决策、编码规范、技术栈约定、已知陷阱全部结构化沉淀，新成员和新 Agent 读同一个 AGENTS.md，获得一致的项目认知。
Repo Wiki 自动生成并持续维护项目文档——结构完整、带代码引用、直观清晰。代码更新提交后 Wiki 同步更新，保持设计和实现始终对齐——这在过去几乎做不到。
Skills 体系把个人经验变成可复用的组织能力。这些不是"配置文件"，而是企业用 AI 的真正壁垒。AI 有了这些知识，就不是初来乍到的新人，而是经过企业培养的熟手。
我们选了 10 个先锋项目试点：
● 全新系统开发，保守估计提效 3～4 倍，上线时间极大提前。年底有望冲击 5～6 倍。
● 历史系统上进行开发，提效有限——主要瓶颈是历史包袱中的隐含知识需要逐步提取、通过 Qoder Rules 注入。
提效好的项目有一个共同特点：开发初期不急于生码，花大量时间在 Qoder Spec 里对齐需求。需求阶段大约花费整个开发过程 40% 以上的时间——一定是需求质量达标后再转入生成阶段。
AI 原生开发要发挥终极效率，工具改进只是一半，另一半是流程适配。我们围绕 Qoder 正在探索新流程：
过去是"需求→设计→开发→测试→部署"的线性流程，每个阶段交接一次。现在编码、测试、Review 在 Qoder 内构成持续循环，"小步快跑"从理念变成日常实践。长周期任务的迭代不再引发架构偏移，因为约束和上下文始终在线。
在需求阶段就用 Qoder 生成测试用例、覆盖边界条件。Spec 中的每条约束都必须对应一个可验证的测试用例——这是后面抵抗模型幻觉的关键防线。测试工程师的关注点从"找 bug"转向"用例质量审查"。
开发工程师不再逐行写代码，而是关注结果审查、架构偏移检测和知识沉淀；测试工程师关注用例质量和结果审查；产品经理深度参与 Spec 质量把关。
流程的重塑是收效最大的工作。我们仍在探索，但方向已经清晰——围绕 Qoder 重新定义"人做什么、AI 做什么"的边界。
不要一上来就全员铺开。先找一个愿意拥抱 AI 的小团队，选一个全新的项目作为起点。新项目没有历史包袱，最容易跑通从需求到交付的完整链路，也最容易让团队建立对 AI 能力的直觉。先用起来，看到效果，再谈推广。
试点跑通之后，针对不同业务场景逐步建设 Harness 工程体系。没有 Harness 的 AI 开发，产出不可控、架构易偏移、质量靠运气。Harness 的价值在于用规范、约束和反馈回路把 AI 的行为边界框住，让它每次产出都稳定、可预期、可审查。
Rules、Skills、AGENTS.md、Repo Wiki——这些不是"配置文件"，而是企业用 AI 的真正壁垒。借助 Qoder 的知识体系，把团队的架构决策、业务规则、历史经验、技术规范全部沉淀为数字资产。AI 工具的差距会逐步缩小，但企业私域知识的积累不可替代。知识治理做得好，AI 就不是初来乍到的新人，而是经过企业系统培养的熟手——这是长期的真正壁垒。
以前我们的工作是"人主导，工具辅助"。现在，它正在变成"人与 Qoder 协同生产"。
工程师最重要的能力不再是写代码，而是澄清意图、拆解需求、构建环境。Qoder 帮我们解决了枯燥重复的执行，让创意不再受限于"不会写某种代码"。
我们已经看到了方向——Spec 质量决定软件质量，流程适配决定提效上限，Qoder 上沉淀的知识决定长期壁垒。未来的研发，是人和 AI 一起进化的过程。
转折：引入 Qoder，从"辅助编程"升级到"自主编程"
2025 年 1 月，随着 SDD 开发模式的日趋成熟，与 Qoder 团队进行产品交流，2 月组织近百人试点，3 月正式引入 Qoder。到现在超千人在使用。
Qoder 和此前工具的本质区别：它不只是一个补全引擎，而是一套完整的 AI 原生开发工作台，构成了我们落地 AI 原生开发所需要的全部基础设施。
善用 Qoder 构建 Harness 工程化体系
我们围绕 Qoder 的能力矩阵，构建了一套内部称为 Harness 的工程化体系——用来"驾驭"AI 在 109 套系统上稳定产出。
首先，我们对 109 套系统做了场景分级
● 高代码场景（占比 70%+）——进一步细分为三类：
● A 类：全新系统开发，从零开始，Qoder 全程参与；
● B 类：老系统上的新模块开发，借助 Repo Wiki 理解存量代码后再生成；
● C 类：老系统已有模块改造，需要先注入大量历史知识再让 Agent 介入。
● 低代码场景——主要用 Qoder 生成配置逻辑和胶水代码；
● 其他场景——如文档、测试脚本等辅助性产出。
围绕上述多样的研发场景，我们沉淀了 Harness 四大核心要点
一、Spec 驱动开发（Spec-Driven Development）
Qoder 的 Quest-SDD（Spec-Driven Development）让需求直接变成可执行的开发规约，Spec 的颗粒度和清晰程度，直接决定首次生码质量，同时也影响后续人机交互轮次。我们在真实项目中做了两个实践：
实践一：大 Spec vs 小 Spec。 大 Spec 包含 300 行、分解了 75 个任务，小 Spec 70 行、分解了 12 个任务。结果——大 Spec 首次完成度只有 60%，之后追加几十次对话才勉强完成；小 Spec 首次完成度可达到 95%。
实践二：同一份 PRD，三种处理方式。 直接让 Qoder 生成 Spec → 首次完成度只有 70%，仍需对话澄清 50 轮以上。工程师与产品经理逐行对齐后更新 Spec → 完成度大幅提升。再加上人机对齐（让 Qoder Agent 反问确认理解无误）→ 完成度接近 100%，基本无需追加修改。
由此我们确定了 Spec 质量标准：
● 在当前主流模型能力下，单个 Spec 原则上控制在 100 行以内、最长不超过 150 行；
● 每条约束必须能转化为测试用例，确保需求明确性、可验证性，也为后续 AI 验证提供依据；
● 如果单 Spec 生码后追加人机修正轮次超过 10 次，说明原始 Spec 质量可能不高，回到 Spec 阶段重新对齐。
二、Harness 反馈回路
我们说 AI Coding 进入到 AI 自主阶段，其特征是通过构建反馈回路实现 Human on the loop，通过多智能体协作，执行长周期任务，彻底解放人类。借助 Qoder 和各类开源 Skill，我们得以快速构建多智能体反馈回路，一方面，在 Loop 里通过对应用进行 AI 验证、审查，自动修复，确保软件逐步逼近需求，另一方面，在每次工作流过程中，都可以沉淀知识，实现对 Harness 的优化。
我们认为在 AI 开发中，测试变得更加重要了，因为模型幻觉客观存在，测试是对抗幻觉的重要手段。我们在 AI 生成 Spec 之后一定要同步生成测试用例，而且要对测试用例进行严格的评审，尤其确保边界条件的完整，测试用例要纳入 Git 仓库，作为 Harness 的重要构成，测试 Agent 一定要与编码 Agent 采用不同的模型，实践中我们发现：让 Qoder Agent 把所有缺陷一次性修复完成，效果往往欠佳；但让它每次只修复 1 个缺陷，效果就很好。
同样，100 条测试用例分 10 个批次、在 10 个独立上下文中让 Agent 执行，比合并在 1 个上下文中一次性测试，发现的缺陷更多、漏测率更低。
因此我们的反馈回路一律把任务拆到最小粒度——小批次执行、逐个修复、持续验证。Qoder 的 Agent 能力让这种高频迭代变得可行。除了 Harness 的反馈回路，我们也在借助 Qoder 生态工具，探索 loop engineering。
三、约束与护栏（Constraints & Guardrails）
109 套系统、不同技术栈，要在长周期迭代中保持架构不偏移，约束的重要性不亚于能力。核心原则只有一条：没有围栏约束，AI 产出越多，代码库熵增越快。
围绕这条原则，我们构建了一套覆盖全开发链路的规范和 Skill 体系，按优先级分层管理：P0 锁死架构边界和合规底线，P1 覆盖编码核心，P2 关注可维护性。每个阶段按需注入对应的约束组合，限制 Agent 行为边界，让 AI 在正确的框架内工作。
四、知识消解（Knowledge Dissolving）：用 Qoder Repo Wiki 实现
知识治理是让前三大能力持续增值的底座。我们通过 AGENTS.md + Repo Wiki + Skills 三层体系来承载。
AGENTS.md 是项目级结构化知识地图——约 100 行的入口文件做目录导航，适当废弃大而全的手册。采用渐进式披露的信息组织方式，在任务的不同阶段向 AI 按需推送所需信息，减少上下文冗余。每个项目的架构决策、编码规范、技术栈约定、已知陷阱全部结构化沉淀，新成员和新 Agent 读同一个 AGENTS.md，获得一致的项目认知。
Repo Wiki 自动生成并持续维护项目文档——结构完整、带代码引用、直观清晰。代码更新提交后 Wiki 同步更新，保持设计和实现始终对齐——这在过去几乎做不到。
Skills 体系把个人经验变成可复用的组织能力。这些不是"配置文件"，而是企业用 AI 的真正壁垒。AI 有了这些知识，就不是初来乍到的新人，而是经过企业培养的熟手。
实战数据：用 Qoder 跑出来的真实提效
我们选了 10 个先锋项目试点：
● 全新系统开发，保守估计提效 3～4 倍，上线时间极大提前。年底有望冲击 5～6 倍。
● 历史系统上进行开发，提效有限——主要瓶颈是历史包袱中的隐含知识需要逐步提取、通过 Qoder Rules 注入。
Qoder 正在改变我们的开发流程
AI 原生开发要发挥终极效率，工具改进只是一半，另一半是流程适配。我们围绕 Qoder 正在探索新流程：
1. 循环迭代替代线性交付
过去是"需求→设计→开发→测试→部署"的线性流程，每个阶段交接一次。现在编码、测试、Review 在 Qoder 内构成持续循环，"小步快跑"从理念变成日常实践。长周期任务的迭代不再引发架构偏移，因为约束和上下文始终在线。
2. 测试左移到需求阶段
在需求阶段就用 Qoder 生成测试用例、覆盖边界条件。Spec 中的每条约束都必须对应一个可验证的测试用例——这是后面抵抗模型幻觉的关键防线。测试工程师的关注点从"找 bug"转向"用例质量审查"。
3. 角色重心转变
开发工程师不再逐行写代码，而是关注结果审查、架构偏移检测和知识沉淀；测试工程师关注用例质量和结果审查；产品经理深度参与 Spec 质量把关。
流程的重塑是收效最大的工作。我们仍在探索，但方向已经清晰——围绕 Qoder 重新定义"人做什么、AI 做什么"的边界。