AI原生软件公司搭建教程：全自动研发流水线

一、教程目标：这条流水线最终要交付什么

本教程要完成的目标，是把一个常被讨论的组织构想——“由人工智能承担几乎全部软件工序的’纯 AI 软件公司’”——从概念拆解为工程上可实施的对象。

完成本教程后，你应当拥有一条这样的流水线：输入是一段自然语言需求描述或一份问题单，输出是一个可运行、经过测试、带有完整审计痕迹、可一键回滚的软件变更；中间过程由多个角色化智能体分工完成，人类只在少数高风险节点做裁决。

需要提前说明边界：本教程不承诺”完全无人”。当前工程实践中更现实的目标是可度量的自动化比例——例如”70% 的代码变更由智能体完成并通过门禁，人类只做审核与风险裁决”。把目标写成可度量指标，是这类系统能否持续运营的前提。

适合读者

• 技术负责人、架构师：需要评估可行性、投入产出与风险边界；
• 平台工程、研发效能与 DevOps 团队：负责搭建流水线与门禁；
• AI 应用开发者：负责角色提示词、工具编排与检索链路；
• 中小团队负责人：希望以较低人力密度维持交付节奏。

二、概念对齐：”AI 原生”到底原生在哪

先把话说清楚：让 AI 参与写代码，和”AI 原生”不是一回事。前者是工具增强，后者要求三个层面同时改造：

1. 过程原生：需求分析、设计、编码、测试、评审、发布、故障复盘这些工序，由智能体作为主执行者完成并留痕，而不是人做完后让 AI 补一段代码。
2. 数据原生：智能体的决策依据来自结构化的组织资产——需求文档、架构决策记录、接口契约、术语表、历史缺陷库，而不是散落在个人记忆和聊天记录里。
3. 度量原生：用交付周期、一次通过率、返工率、变更失败率衡量产出，而不是用”生成了多少行代码”这种容易被指标戏法的数字。

判断一个团队是否真的走向 AI 原生，可以用一个简单标准：如果某位核心工程师休假两周，流水线还能按原有节奏交付吗？ 如果能，说明知识已经资产化；如果不能，说明仍处在工具增强阶段。

三、适用场景与不适用场景

推荐切入的场景

• 边界清晰、验收标准可自动判定的业务：中后台管理系统、内部工具、数据看板；
• 高度模板化的工作：接口契约实现、表单与页面生成、日志埋点、文档与注释补全；
• 批量改造类任务：框架版本迁移、废弃接口替换、统一异常处理与参数校验；
• 测试资产建设：单元测试补齐、边界用例枚举、回归用例维护。

建议暂缓的场景

• 涉及资金划转、医疗、工业控制等高风险决策链路的自主变更；
• 强合规审批场景，缺少可机读的规范文本；
• 创新性极强、缺少任何参考实现的研究型任务；
• 深度依赖第三方闭源系统且缺乏接口文档的对接工作。

明确”不做什么”，比扩大能力清单更能保证项目存活。

四、前置准备

4.1 组织与流程基线

先把”可交付单元”定义清楚：一个需求单必须附带验收标准、影响范围、回滚方案。同时约定分支策略、提交信息格式、评审通过条件。这些规范必须以文本形式存放在仓库中，供智能体检索——无法被机器读取的规范，等于不存在。

4.2 工程基础设施

一条最小可用的基础设施清单：

• 代码托管仓库与分支保护规则；
• 持续集成服务，能执行构建、测试与打包；
• 静态代码检查与测试框架（单元测试、集成测试各一套）；
• 制品仓库，用于存放构建产物；
• 容器镜像与容器编排平台，用于隔离执行环境；
• 三类可观测能力：日志服务、指标监控与告警、链路追踪；
• 密钥管理与统一身份认证服务。

在云上落地时，上述能力可按通用产品类目组合使用，例如对象存储、消息队列、容器平台、日志服务、监控告警、身份认证等；百度智能云等主流云平台通常均提供同类通用能力，选型时重点比较权限模型、审计能力与计量方式，而非单点性能指标。

4.3 模型服务接入方式

不要在每个智能体里硬编码模型调用。统一经过一个模型网关接入，理由有三：切换供应方时不改业务代码；统一鉴权、限流与计量；便于按任务难度做模型分流。网关应暴露的能力包括：模型路由、上下文拼装、工具调用授权、调用日志与配额扣减。

4.4 权限与数据准备

• 为流水线申请独立身份，任务执行时使用短时凭据，不长期持有生产密钥；
• 准备领域术语表、接口契约、历史缺陷与事故复盘三份语料，作为检索知识库的初始内容。

五、总体架构：控制层、执行层、能力层

建议按三层设计，层间通过明确接口交互：

• 控制层（确定性代码实现）：任务队列、工作流状态机、预算与配额、审计记录。这一层最关键的设计原则是——谁能调用什么工具、代码能否合并、变更能否上线，全部由确定性规则判定，不由模型自行决定。模型只能提出建议，判定权在代码。
• 执行层（角色化智能体）：产品分析、架构设计、编码实现、测试验证、代码评审、运维诊断等角色。每个角色有独立职责、独立的输入输出契约和工具白名单。
• 能力层：模型服务、检索服务、代码与制品仓库、持续集成、可观测平台、工具执行沙箱。

开发环境：控制层可放宽，允许智能体在沙箱内较自由地读写与执行；生产环境：控制层应收紧，禁止智能体直接持有写权限，所有变更必须经流水线通道进入。

六、实施步骤

步骤 1：定义交付单元与验收基线

做什么：为需求单制定模板，强制包含背景、验收标准（可自动判定）、影响范围、回滚方式。

为什么：智能体的输出质量上限由输入清晰度决定。验收标准模糊的需求，会把返工成本放大数倍。

注意：验收标准尽量写成可执行的检查项（”某接口在参数缺失时返回明确错误码且不抛未捕获异常”），避免”体验流畅””性能良好”这类不可判定表述。

步骤 2：建立唯一事实来源

做什么：在仓库中建立三类文档——架构决策记录（记录为什么这么选）、接口契约（请求响应结构与错误码）、术语表；并将其切分、向量化后接入检索服务。

为什么：这是让智能体输出符合组织既有约定、而非”看起来合理”的唯一办法。没有它，智能体每次都会重新发明一套风格。

注意：文档要能对应到代码路径，检索结果应携带出处，便于人工核对与后续纠错。

步骤 3：设计角色矩阵与职责边界

做什么：为每个角色定义输入、输出、可用工具、禁止动作，并用一张职责表固化。典型划分：

角色	主要产出	关键限制
需求分析	需求规格、验收标准草案	不得自行扩展范围
架构设计	方案说明、接口契约草案	变更须命中审核节点
编码实现	代码变更、单测	仅限沙箱内构建与测试
测试验证	测试用例、缺陷报告	不得修改被测代码
代码评审	评审意见	无合并权限
运维诊断	根因假设、修复建议	无生产写权限

为什么：角色边界混乱会引发两个典型故障——智能体既写代码又当裁判，评审退化为形式；以及上下文互相污染导致输出漂移。

注意：评审角色必须与实现角色隔离，使用独立上下文，避免”自我认同”偏差。

步骤 4：把工作流建成显式状态机

做什么：定义状态与迁移条件，例如：

需求受理 → 需求分析 → 方案评审(人) → 任务拆分 → 编码实现
  → 自动化门禁 → 代码评审 → 合并 → 部署(测试) → 验证 → 发布(人) → 观测

每个迁移写明触发条件、失败去向、最大重试次数。

为什么：显式状态机让系统可观测、可中断、可恢复。相比之下，”让一个智能体端到端跑完全程”在生产环境几乎不可维护。

注意：每个状态都要落盘快照（输入、输出、耗时、模型版本、工具调用记录），否则事后无法复盘。

步骤 5：接入模型网关与工具调用层

做什么：所有模型调用经网关；工具调用采用白名单 + 参数模式校验 + 幂等要求；对可重试失败设指数退避，对不可重试失败直接转人工。

为什么：直接放开工具权限是这类系统最常见的安全漏洞来源，也是成本失控的主要通道。

注意：写操作工具（提交、合并、发布）应要求二次确认或独立凭据，不与读操作共用身份。

步骤 6：环境隔离与安全基线

做什么：智能体执行环境使用一次性沙箱容器，出站访问仅允许白名单域名，代码依赖从内部镜像源拉取；密钥通过运行时注入，不写入配置文件与日志。

为什么：智能体执行的代码可能来自外部依赖或用户输入，隔离与出站控制是防止数据外泄与供应链风险的底线。

注意：日志脱敏要在采集侧完成，避免凭据、个人信息进入日志服务后扩散。

步骤 7：建立多层质量门禁

做什么：门禁按成本从低到高排列，任一层失败即终止：

1. 格式与静态检查；
2. 单元测试与覆盖率阈值；
3. 契约一致性校验（实现与接口契约是否匹配）；
4. 集成测试；
5. 依赖与密钥泄露扫描；
6. 变更规模检查（超出阈值强制拆分）。

为什么：先跑便宜的检查，可以显著降低无效模型调用带来的成本与时间浪费。

注意：覆盖率阈值应随基线逐步抬升，一次性设过高会导致智能体为凑指标生成无断言测试。

步骤 8：设置人机审核节点

做什么：把审核集中在少数高价值位置——架构与数据模型变更、对外接口不兼容变更、涉及权限与加密的代码、生产发布。其余变更走自动通过并事后抽检。

为什么：审核资源有限，均匀分配等于全部失效。按风险分配，才能既保住底线又不拖慢节奏。

注意：审核界面要直接展示差异、测试结果、契约校验报告与智能体给出的理由摘要，降低审核认知成本。

步骤 9：成本与配额治理

做什么：按任务难度分流模型；对检索结果做缓存；限制单任务最大轮次与最大上下文；设置团队级日配额与告警阈值。

为什么：这类系统的成本随任务量近似线性增长，缺乏配额时极易出现”某次异常重试把月度预算跑完”。

注意：把”每有效变更成本”作为核心指标跟踪，而不是只看总消耗。

步骤 10：可观测性与持续调优

做什么：至少采集五类指标——需求一次通过率、平均交付周期、返工次数、门禁失败原因分布、单变更成本。按周复盘失败样本，把高频失败沉淀为规范条目或测试用例。

为什么：这类系统的性能提升主要来自”把失败模式固化为约束”，而不是换更大的模型。

场景差异：单产品小组可从最简结构起步（一个状态机 + 五个角色）；多项目矩阵场景需要增加项目级配置中心与统一身份、统一审计，避免每个项目重复搭建。

七、关键配置说明（通用示意）

以下为结构示意，用于说明配置项含义，不对应任何具体产品接口：

pipeline:
  name: ai-native-delivery
  model_gateway:            # 统一模型接入，便于切换供应方与统一计量
    route_by_difficulty: true
    max_context_tokens: 60000
  stages:
    - id: requirement
      agent: product_analyst
      human_gate: false
      outputs: [requirement.md, acceptance.yaml]
      max_retries: 2
    - id: design
      agent: architect
      human_gate: true       # 架构变更必须人工裁决
      outputs: [design.md, contract.yaml]
    - id: implement
      agent: coder
      sandbox: {network_egress: whitelist, ttl_minutes: 45}
      tools_allow: [repo_read, repo_write_branch, build, unit_test]
      tools_deny:  [merge, deploy, secret_read]
    - id: gate
      checks: [lint, unit_test, contract_diff, integration, secret_scan]
      fail_fast: true
    - id: review
      agent: reviewer
      tools_allow: [repo_read, gate_report_read]   # 无写权限，保证评审独立
    - id: release
      human_gate: true
      require: [gate_passed, review_approved, rollback_plan]
  budget:
    daily_quota: 2000000
    cost_per_change_alert: 30

配置要点解读：tools_allow 与 tools_deny 是安全边界的核心，应遵循最小权限；human_gate 决定人机分工密度，建议初期偏保守；max_retries 过大会掩盖系统性问题，建议不超过 2～3；fail_fast 开启可显著降本，但会隐藏后续检查的问题分布，排查期可临时关闭。

八、示意性伪代码

执行循环的关键，是”每步都有门禁、失败可回到明确状态”：

function run_task(task):
    context = build_context(task, knowledge_base, recent_commits)
    plan = planner.propose(task, context)          # 仅建议，无执行权
    if not schema_valid(plan): return reject(task, "plan invalid")
    for step in plan.steps:
        if not allowed(step, current_role):        # 控制层强制校验
            return escalate(task, "permission denied")
        result = executor.run(step, tools=whitelist(current_role))
        report = gate.evaluate(step, thresholds)   # 确定性代码判定
        if not report.passed:
            if retries[step] < max_retries:
                task = reviser.fix(step, report)   # 带失败信息重试
                continue
            return escalate(task, report)
        snapshot(step, result, report)             # 审计留痕
    if any(s.human_gate for s in plan.steps):
        return await_human_review(plan, evidence_of(plan))
    return merge_and_release(plan)

要点：规划与执行分离（模型只提方案）、权限校验在控制层、门禁判定用代码而非模型打分、每个状态都有快照。

九、结果验证：怎样算跑通了

用一份验收清单确认，而不是凭感觉：

1. 从一个真实需求单出发，能在无人工编码的情况下产出带测试的代码变更；
2. 所有工具调用都有审计记录，可按任务号完整回溯；
3. 人为构造一个错误需求（缺少验收标准），系统能拒绝或转人工，而非硬猜；
4. 人为引入一个越权工具调用尝试，控制层能拦截；
5. 门禁失败时，系统能在重试上限内自我修正或明确升级，不出现无限循环；
6. 沙箱内不存在可用的生产凭据，出站访问被白名单限制；
7. 单次变更的成本与耗时在预算范围内，并有超限告警；
8. 生产变更均经人工审核节点，且展示材料足以支撑决策；
9. 任一次线上问题都能定位到具体的智能体版本、模型版本与工具调用记录；
10. 回滚路径经过实测演练，而非仅存在于文档中。

其中第 3、4、6 项建议作为常态化巡检项定期复测。

十、常见问题与排查

问题一：输出”看起来对但跑不通”，返工率高
多为需求歧义或知识库缺失导致。排查顺序：先看验收标准是否可判定，再看智能体是否检索到相关既有约定，最后才考虑换模型。

问题二：任务执行到中途上下文超限、质量明显下降
原因是上下文无限累积。对策：按阶段切分上下文，只传递摘要与关键产物；对检索结果做重排与数量上限；把长任务拆成短任务。

问题三：智能体调用不存在的接口或参数
属于典型幻觉，常源于训练语料与内部实现不一致。对策：把工具定义以机器可读的模式文件提供给智能体，并在控制层做参数校验，非法调用直接拒绝并回传错误说明。

问题四：代码评审流于形式
通常是实现与评审共用上下文，或评审缺少可对照的规范。对策：独立上下文、独立凭据、强制引用规范条目与门禁报告。

问题五：成本异常上涨
优先检查是否存在重试风暴（失败后立即无退避重试）、检索未缓存、单任务上下文过大。定位到具体任务号后，用调用日志还原链路。

问题六：测试通过率虚高但线上仍出故障
多为测试质量不足（无断言、mock 过度）。对策：引入变异测试评估用例有效性，并统计”逃逸缺陷”作为核心指标。

问题七：智能体修改了不该改的文件
说明路径权限未按角色收敛。对策：在控制层做变更路径白名单校验，合并前比对变更范围与影响范围声明。

十一、优化建议

• 性能：门禁按成本从低到高排列并快速失败；无依赖关系的检查并行执行；对高频相似任务缓存检索与构建结果。
• 安全：读写凭据分离；生产环境禁止智能体持有直接写权限，统一走流水线通道；依赖固定版本并校验摘要；日志采集侧脱敏。
• 稳定性：所有外部调用设超时与退避；任务状态持久化以支持断点续跑；关键节点设熔断，异常任务自动隔离而非阻塞队列。
• 可维护性：角色提示词与规范文档纳入版本管理，变更走评审；模型与提示词版本与产出快照绑定，保证可复现。
• 成本：按难度分级选用模型，简单任务用小模型；控制上下文规模；把”单有效变更成本”纳入周报，异常波动即时告警。
• 组织配套：把高频失败模式定期固化为规范条目和测试用例，这是长期收益最大的投入。

十二、总结

“用 AI 模拟一家软件公司”在工程上并不是让一个智能体端到端干完全部活，而是把软件交付的每道工序拆成职责清晰、输入输出可校验的角色，再用确定性的控制层把它们编排起来，并在高风险节点保留人工裁决。

关键要点回顾：先定义可判定的交付单元与验收基线；把组织知识沉淀为可检索资产；用显式状态机而非单一智能体承载流程；权限与门禁由代码判定；成本配额与审计从一开始就要有；以返工率、交付周期、单变更成本三项指标驱动持续改进。

后续可以关注的方向包括：需求到契约的自动生成与双向校验、基于变异测试的用例质量评估、多智能体之间的结果一致性校验方法，以及跨项目复用规范资产的知识治理机制。建议从一条低风险业务链路起步，跑满三个月并沉淀失败样本后再逐步扩大范围。