从AI辅助编程到AI-DLC：紫讯落地 AI 原生研发新范式的实践

摘要：当 AI 从”写一段代码”走向”参与完整研发流程”时，真正的瓶颈不再只是模型能力，而是团队有没有一套能让 AI 稳定工作的工程体系。紫讯围绕 AI-DLC（AI-Driven Development Life Cycle）方法，在与 亚马逊云科技团队的持续交流、Workshop 共创和工具实践中，逐步建立了从知识沉淀、需求塑形、方案收敛、开发协同、测试验证到经验回流的端到端研发闭环，让 AI 的产出可追溯、可复用、可验证、可纠偏，并持续沉淀为组织级研发资产（zixun-github-ai-dlc）。

---

一、概述

福建紫讯信息科技有限公司（以下简称”紫讯”）是一家专注于跨境电商服务的科技公司。紫讯的研发团队在生成式 AI 普及的浪潮中，也经历了从”个人使用 AI 提效”到”团队希望系统性复用 AI 能力”的转变。早期，AI 能帮助工程师快速生成代码、解释逻辑、补充测试；但当 AI 开始参与需求澄清、方案设计、任务拆解、代码实现、测试验证和知识回流时，仅靠临时提问和零散对话已无法满足真实项目的稳定交付要求。

紫讯的判断是：AI 原生研发的关键，不是让 AI 写更多代码，而是建设一套让 AI 能按工程标准稳定参与完整研发流程的体系。

基于这一判断，紫讯将 AI-DLC 作为内部研发方法升级的主线，通过统一的知识管理、流程规范、质量门禁和协作平台，让多人、多角色、多 Agent 能够在同一套可追溯链路中协同推进。

在这一过程中，亚马逊云科技团队也为紫讯提供了重要支持。双方围绕 AI 原生研发方法、生成式 AI 工程实践和工具链演进开展了多次交流，包括面向 AI-DLC 主题的 Workshop、阶段性经验分享和最新工具能力研讨。2025 年 12 月，紫讯与亚马逊云科技携手组织专题 Workshop：一方面帮助团队系统理解 AI-DLC 方法论的核心要点与应用逻辑，另一方面通过针对性的实践环节，让成员在真实操作中掌握落地方法。亚马逊云科技在云上 AI 能力、研发工具和 Kiro 等实践工具方面的经验，也帮助紫讯更快把方法论转化为可执行的团队流程。

二、机会｜AI 已经进入完整研发流程

在原始成熟度模型中，AI in the Loop 指的是”人主导、AI 辅助”：个别成员在工作中按需召唤 AI，或团队围绕高频、规则清晰的场景做单点验证。它对应的是个人探索期和场景验证期，还不是 AI 深度嵌入团队标准流程后的状态。

真正的关键转折发生在流程嵌入期：AI 从”辅助工具”变成”流程节点”，协作模式开始从 AI in the Loop（人主导、AI 辅助）走向 Human in the Loop（AI 主导执行、人在关键节点监督例外）的转变。此时，人的角色不再只是发起一次次请求，而是需要在关键节点审核、确认和纠偏。

当团队进一步把 AI 放进真实研发流程，会很快遇到几类问题：

• 项目知识分散在各类文档、协作工具、代码评审和个人笔记里，AI 每次都要重新拼凑上下文
• 同一个问题在不同轮次、不同 Agent 中给出不同答案，结论无法复现
• AI 缺信息时倾向于补全空白，而不是显式承认缺口
• 文档过期后没有”过期感”，AI 仍可能把旧内容当成权威规则
• 个人提效明显，但需求交付周期、跨角色协作效率和返工率并没有同步改善

这意味着，团队 AI 应用的分水岭并不是”会不会用 AI”，而是有没有让 AI 稳定工作的工程体系。

在紫讯看来，研发团队的 AI 成熟度会经历两个关键跃迁：

1. 从个人探索、单点验证，走向流程嵌入与知识沉淀

2. 从单个 Agent 辅助，走向多 Agent 协同与人类监督例外

内部阶段性数据也印证了这一判断。近期产研 AI 使用统计显示，相关实践已覆盖多个版本周期，并形成规模化调用；其中开发仍是最高频场景，同时产品、测试、运维等环节也已经产生持续使用记录。这说明 AI 不再只是少数工程师的个人工具，而是开始进入完整产研链路。

如果以版本记录作为迭代活动的观察口径，2026 年 3 月到 5 月也能看到类似趋势：5 月较 3 月，月度版本数提升约 22%，版本覆盖仓库数提升约 11%，日均版本数提升约 18%。更重要的是，5 月既有一批仓库延续 3 月的版本迭代，也有新的仓库进入版本发布节奏，说明相关实践正在从少数项目扩展到更多工程仓库和版本周期。

AI-DLC 的价值就在于帮助团队跨越第一道鸿沟，并为第二道跃迁建立基础。

[图1 AI 成熟度跃迁图]

如上图所示，AI 成熟度沿”个人探索→单点验证→流程嵌入→多 Agent 协同”逐级跃迁，紫讯当前正处在从”流程嵌入与知识沉淀”迈向”多 Agent 协同与人类监督例外”的关键节点。

三、解决方案｜以四件套建设 AI 原生研发体系

紫讯在落地过程中，没有把 AI-DLC 定义为某一个工具或某一套提示词，而是把它作为一套工程体系来建设。其核心由四类能力共同支撑。

[图2 AI 原生研发体系四件套架构图]

如上图所示，知识底座、流程契约、系统约束、协作平台四者自下而上层层支撑：知识底座解决”看到什么”，流程契约解决”怎么做”，系统约束解决”如何可控”，协作平台解决”多人多 Agent 如何协同”。

3.1 知识底座：让 AI 看到正确上下文

AI 要稳定参与研发，首先必须知道项目的真实背景：业务目标是什么、系统边界在哪里、哪些约定不能被打破、历史上为什么做过某些选择。

紫讯没有简单地把现有文档堆给 AI，而是对项目知识做了重新整理：把长期有效的信息沉淀下来，把容易变化的信息保持可追溯，把不确定的信息显式标注出来。这样，AI 接到任务时不再依赖临时粘贴的背景，也不需要每次都从零猜测项目上下文。

具体来看，知识底座中沉淀的不只是传统意义上的”项目说明”，而是一组面向 AI 和 Agent 可消费的工程事实：

• 业务知识：核心业务目标、用户角色、关键流程、业务术语、验收口径和不能被破坏的业务规则
• 系统知识：模块边界、接口契约、数据模型、运行入口、部署方式、监控排障入口和常见故障处理经验
• 决策知识：重要技术取舍、历史方案背景、为什么没有采用某些方案，以及哪些约束来自业务、合规或基础设施
• 协作知识：需求、设计、实现、测试、回流各阶段的输入输出标准，谁负责确认，什么情况下必须停下来等待人工判断
• Agent 规范：上下文读取顺序、禁止猜测的场景、需要显式暴露的不确定项、任务拆解粒度、提交记录格式、测试回写要求和产物落盘位置

这些内容并不是一次性文档，而是伴随需求持续演进的团队资产。每次需求完成后，团队会判断哪些信息只是本次需求的临时材料，哪些已经变成长期规则；只有后者才会回流到知识底座，避免把偶然处理固化成永久约束。

这套知识底座的价值在于：让团队和 AI 对”事实”形成共同理解。人知道哪里是权威口径，AI 也知道应该优先参考哪些内容、哪些地方需要提醒人确认。

3.2 流程契约：让 AI 按标准动作工作

只让 AI 看到上下文还不够。真实研发还需要明确”下一步该做什么”、“做到什么程度可以进入下一阶段”、“哪些结论必须经过人工确认”。

紫讯将需求、方案、设计、实现、测试和复盘沉淀为一套标准流程。每个阶段都有清晰的输入和输出，前序问题没有收敛时，后续工作不会贸然启动；验收标准在需求阶段就被明确下来，而不是等到测试时临时补充。

这让 AI 从”被动响应问题”变成”按流程参与研发”：它可以辅助澄清需求、整理方案、拆解任务、生成测试思路，也可以在发现信息不足时主动停下来提示人确认。

3.3 系统约束：让 AI 可控、可验证、可纠偏

3.3.1 紫讯在实践中形成了一个重要判断：模型不是瓶颈，围绕模型的系统才是。

因此，AI-DLC 不依赖单次提问的”聪明”，而是通过流程规则、质量检查、人工确认和结果回写，把 AI 的工作约束在可验证的路径中。

在这套机制下，AI 不能随意跳过阶段，也不能在缺少关键信息时继续猜测。它需要在正确的上下文中工作，在遇到不确定项时主动暴露问题，在完成任务后留下可复盘的记录。这样，团队既能利用 AI 的执行效率，又能降低跑偏、误解和返工的风险。

3.4 协作平台：让多人和多 Agent 不退化为 IM 流

当一个团队同时运行多个 Agent，如果仍然依赖 IM、私聊和本地临时文件协作，信息很快会碎片化：谁在处理什么、卡在哪里、依据了什么结论、下一步需要谁确认，都很难被团队共同看见。

紫讯的做法不是把所有对话都搬进平台，而是把每条需求变成一个可追踪的工作项，把”当前阶段、负责人、阻塞原因、待确认人、关键产物链接、是否可自动推进”这些信息记录为结构化字段；把需要人理解的背景、取舍和交付结果写在评论里；把需求文档、计划、测试结论和回流资产保存在可追溯的产物位置。这样平台既能让人快速看懂上下文，也能让 Agent 根据状态字段继续推进。

在多 Agent 协作中，紫讯特别强调”角色记录边界”：队长 Agent 只负责路由和状态流转，不直接写代码或产出文档；Worker Agent 只负责某一阶段交付，并在完成后留下交付评论和必要的状态更新；人工 Reviewer 只在决策性阶段介入，例如范围确认、方案取舍、架构影响或验收口径变化。执行性阶段则尽量自动推进，减少无效等待。

这套记录方式让协作平台不只是任务看板，而成为 AI-DLC 的运行账本：

• 每次阶段推进都有明确触发条件，而不是靠群里喊”继续”
• 每次阻塞都要写清缺什么证据、等谁确认、确认后如何恢复
• 每次交付都要关联产物位置和验收口径，避免只留一句”已完成”
• 每次人工审核都区分”确认通过”和”豁免审核”，避免把口头同意误当长期规则
• 每次流程卡住都能回看运行记录，判断是计划质量不足、Reviewer 缺失、Agent 返工，还是状态字段没有同步

对于多 Agent 协作来说，这种共享记录层比单纯的聊天窗口更重要。聊天适合讨论，平台记录负责承接事实、状态和责任；只有两者分工清楚，AI 协作才不会在高并发下重新退化成信息流。

四、实践路径｜一条需求如何在 AI-DLC 中流转

在紫讯的端到端流程中，一条需求通常会经历以下路径：

[图3 AI-DLC 需求流转全景图]

如上图所示，这是一条从上下文到资产回流的闭环，而非一次性的线性流水：每个阶段的产物都会沉淀回知识底座，成为下一条需求的输入。

1. 项目准备（Context）：团队先梳理项目背景、业务边界、核心模块、运行规则和历史决策，形成 AI 可以稳定消费的基础上下文。后续每条需求启动时，都无需重新解释全貌。

2. 需求塑形（Shape）：PM 或业务负责人提出需求后，AI 辅助澄清目标、边界、约束和验收标准，把大需求拆解为更清晰的任务单元。建立共识后再进入开发。

3. 方案与计划收敛（Plan）：明确影响范围后，团队形成统一的执行计划（明确负责人、时序、依赖和验收标准）。计划清晰后，AI 才进入后续执行环节。

4. 分批实现（Execute）：AI 根据计划辅助完成编码、资料整理、检查和验证。小需求串行推进，边界清晰的需求由多个 Agent 并行处理。每个阶段的状态、阻塞、交付评论和产物链接都回到统一协作链路中，避免信息散落。

5. 测试验证（Verify）：QA 或测试 Agent 基于前期确认的验收标准设计验证方式，检查功能预期、边界场景与潜在风险。

6. 资产回流（Merge-back）：需求完成后，识别并沉淀长期资产（新业务规则、架构取舍、运行经验等）。避免把一次性处理误固化为长期规则，保持知识库的高质量。

这条路径让 AI 不再只是”写代码的助手”，而是成为完整研发流程中的可控参与者。

五、复盘｜落地过程中踩过的坑

AI-DLC 的落地并不是把流程画出来就能自然运行。紫讯在实践中也遇到过一些容易被低估的问题，这些问题反过来推动团队把规范做得更细。

第一个坑，是把”文档足够多”误认为”AI 上下文足够好”。 早期团队已经有大量需求文档、会议记录和技术说明，但这些材料并不总是适合 AI 直接消费：有的过期但没有标记，有的缺少适用范围，有的只记录结论没有记录原因。AI 在这种上下文里很容易引用旧规则或把局部经验扩大为通用规则。后来团队开始区分权威事实、阶段材料、历史记录和待确认信息，并为关键文档补充适用范围、更新时间和责任人，才逐步降低了上下文漂移。

第二个坑，是过早追求多 Agent 并发。 多 Agent 并不是简单地把任务拆给多个窗口同时执行。如果需求边界没有冻结、接口契约没有明确、状态记录没有统一，并发只会把不确定性放大：一个 Agent 改了实现，另一个 Agent 还在基于旧假设写测试，最后反而增加返工。紫讯的经验是，只有当任务边界、依赖关系、验收标准和冲突处理方式都清楚后，才适合扩大并发。

第三个坑，是把人工审核变成新的等待瓶颈。 AI-DLC 强调 Human in the Loop，但如果每个小动作都等待人工确认，流程会重新退化成排队审批。团队后来把人工介入分成”必须确认的决策点”和”可以自动推进的执行点”：范围变化、架构影响、验收口径调整需要人确认；格式修复、局部实现、常规测试补充则尽量由 Agent 在约束内自动完成。

六、业务成果｜从个人提效走向组织提效

通过 AI-DLC 实践，紫讯获得的最核心成果不是”多生成了几段代码”，而是研发过程本身发生了结构性变化。

[图4 业务成果对比图]

如上图所示，左侧”传统模式”中信息散落、AI 各自私聊、质量后置；右侧”AI-DLC 模式”中知识结构化沉淀、AI 以固定角色进入流程、质量随流程持续验证。下面六点正是这一转变的具体体现。

6.1 研发产物从分散讨论变成可追溯资产

过去，需求背景、接口约定、临时决策和测试口径可能散落在 IM、会议纪要、个人文档和代码评审中。AI-DLC 将这些信息按阶段沉淀下来，并在需求完成后把长期有效的内容回流到团队知识体系中。过去需要翻阅数百条聊天记录才能还原的决策，现在可通过结构化文档秒级追溯。

这使得每一次需求都能回答三个问题：

• 当时为什么这样做？
• AI 和人依据了哪些上下文？
• 哪些结论应该沉淀为长期资产？

6.2 AI 从个人工具变成流程节点

过去 AI 主要服务于个人：谁会问，谁收益，能力随人走、随会话散。现在 AI 以固定角色进入团队流程，产出沉淀为团队共享、可复用的资产。

这让团队从”每个人各自和 AI 私聊”转向”团队共享一套 AI 可消费的流程与知识”。

6.3 多 Agent 并发有了前置门禁

过去”多开几个 AI”往往放大混乱：没有冻结的契约和清晰的边界，并发越多冲突越多。现在并发有了前置门禁——任务边界清楚、关键约定稳定、相互依赖可控，才允许多个 Agent 并行，既放大执行力又不牺牲一致性。

6.4 质量保障融入流程闭环

测试与评审不再是实现后的孤立动作，而是嵌入到流程中：验收标准来自需求阶段，测试计划围绕已确认目标展开，执行过程中的不确定项会被显式暴露，而不是被带入后续交付。阶段性数据中，测试相关场景已经形成稳定使用记录，覆盖用例设计、测试执行、回归验证、缺陷管理等环节，说明质量保障正在从”人工集中验证”逐步转向”流程内持续验证”。

这让质量保障成为需求、实现、测试持续联动的一部分。

6.5 组织开始形成知识复利

AI-DLC 的回流机制让一次需求中的经验，可以进一步成为下一次需求的资产。

通过将可复用的决策、约定、模块边界和运行经验回流到团队知识体系，团队不再依赖某个人记住”上次怎么做”，AI 也不需要每次重新询问同样的背景。知识开始在组织层面复用，而不是停留在单次会话里。

6.6 AI 研发过程具备可观测基础

当需求、任务、执行状态和关键结论都进入统一协作平台后，团队可以逐步观察 AI 原生研发的健康度。紫讯不是只看”Agent 跑了多少次”，而是结合工作项记录和运行日志持续回看。

从阶段投入分布看，AI 使用已经可以按产品、开发、测试、运维等环节进行归因；从版本和流程维度看，也能观察不同场景在全流程中的应用强度。这意味着 AI-DLC 不再只依赖主观感受评价效果，而是可以逐步用版本覆盖、阶段覆盖、使用规模和产物沉淀情况验证组织级落地成果。

例如在版本迭代数据中，2026 年 5 月较 3 月，版本总量提升约 22%。进一步看，提升最明显的重点 AI 项目版本量提升超过 5 倍，版本占比也从约 6% 提升到约 30%，提升约 24 个百分点，显示重点 AI 项目已经进入更高频的版本节奏。这个变化并不应简单理解为所有团队均匀提速，而更接近于”多团队持续覆盖 + 重点项目高频迭代”共同拉动的结果。

进一步看，团队会重点观察：

• 版本覆盖：有多少需求和版本进入 AI-DLC 链路
• 阶段覆盖：AI 是否稳定参与产品、开发、测试、运维等环节
• 协作记录：关键状态、交付评论和审核结论是否完整留痕
• 验证闭环：测试设计、回归验证和缺陷分析是否与需求验收标准关联
• 资产沉淀：需求完成后是否产生可复用的团队知识

这些指标让 AI 提效不再只停留在主观感受，而是逐步转向可度量、可复盘、可治理。

七、阶段性总结

紫讯的 AI-DLC 实践说明，AI 原生研发不是简单引入一个更强的模型，也不是让团队多写几份文档。它本质上是一套围绕 AI 的工程体系升级：

• 知识底座让 AI 看见正确上下文
• 流程契约让 AI 按标准动作工作
• 系统约束让 AI 可控、可验证、可纠偏
• 协作平台让人和多 Agent 在同一条链路中协作

这套体系帮助团队从”个人 AI 提效”走向”组织级研发提效”。当前，紫讯已经完成从流程嵌入到知识沉淀的关键跃迁，并正在继续补齐多 Agent 协同、可观测治理和自进化能力。

八、展望

未来，紫讯将继续沿着 AI-DLC 的方向推进三类能力：

1. 更完整的知识覆盖：持续补齐核心业务、关键规则、历史决策和运行经验

2. 更稳定的多 Agent 协作：在边界清楚、依赖可控、状态可见的前提下，扩大并发执行场景

3. 更可度量的研发 ROI：持续评估交付周期、返工情况、人工介入强度与知识沉淀效果

AI-DLC 的目标不是替代研发团队，而是让团队具备一种新的工程能力：把 AI 的一次性产出转化为可追溯、可复用、可验证、可纠偏的组织资产，并在此基础上持续演进。

九、关于紫讯

福建紫讯信息科技有限公司专注于跨境电商服务，基于大数据、云计算和 AI 核心技术，构建跨境电商服务生态，为全球卖家提供数字资产安全托管服务以及数据运营指导，助力中国制造出海。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

---

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用