复杂业务团队的AI Coding交付实践：知识库、RD流程和质量门禁

随着大模型能力的快速提升，AI Coding已成为研发团队提升效率的重要手段。然而，在复杂业务场景下，直接将需求交给AI往往会带来意想不到的问题——关键逻辑理解偏差、应用边界混淆、扩展点选择错误等问题时有发生。与其追求“短时间全自动化”，不如先建立扎实的底座，让AI在清晰的知识语境和明确的流程规范下工作。

分层知识库设计：从混乱到秩序

团队将AI研发交付分为三个阶段推进：第一阶段打底，建设知识库沉淀团队上下文，用文件化的RD流程把需求分析、应用拆解、实现校验和知识回补链路跑通；第二阶段实现更多流程动作的自动化推进；第三阶段达成包括开发、测试、发布、观测、回滚在内的完整协同交付。当前重点投入的是第一阶段，因为底座扎实了，后续的自动化才有空间。

文件化RD流程：让研发状态可接续、可review

复杂业务团队的知识库建设不能简单套用通用方案，需要先厘清几个关键问题：知识如何分层、哪些知识需要Owner确认、候选知识与正式知识如何流转、模板如何强约束。团队将知识库设计为五个核心目录：main存放跨应用的全局业务知识，applications存放各应用范围内的知识，candidate作为候选知识暂存区，personal保留个人经验，template约束知识写作结构。 应用级知识进一步按product（主干能力）、solution（差异化扩展）、base（基础索引）、tech（技术规范）四个维度组织，确保AI在正确阶段读取正确粒度的上下文。这种渐进式加载设计解决了上下文窗口占用问题——不是塞的越多越好，而是在对的时间加载对的内容。

前置质量门禁：把人机review放在最关键位置

RD（Research Development）流程的核心是用Markdown文件承载需求从输入到交付的全过程。每个需求对应独立的目录，保存原始输入、分析结果、应用级需求、实现校验状态和继续提示等信息。这种设计带来四个关键价值：长会话可以拆开，大需求分段完成；新会话可以接上，不依赖聊天历史；人工可以review关键判断；其他工具也可以接入。 流程的关键不是追求文档完整性，而是设置合理的检查点。PRD验证确保需求输入合格，需求澄清补充不确认点，应用级requirement是开发契约，实现校验对账requirement与代码的diff。fail-fast是核心原则：能在PRD阶段暴露的问题不拖到requirement，能在requirement阶段暴露的问题不拖到编码。

实践启示：底座先行，自动化才有空间

复杂业务中“重来一次”的成本很高。如果错的是局部实现，重新生成代码也许还行；但如果错的是PRD理解、应用边界、扩展点选择，返工意味着整条链路倒回去。因此，把review点前置比事后修复更有效。 人机review不是让人把AI做过的事情重做一遍，而是在高价值位置介入确认那些最容易造成返工的业务事实：某个校验应该前置还是后置、某个历史服务是否要兼容、某个方案是否影响已有链路、某个开关默认值怎么设。判断往往比写代码本身更关键。团队不追求100%全AI交付，做到95%后剩下简单的手改更快，因为AI研发交付的价值不在“纯度”，在总交付成本、质量稳定性和风险可控性。

如有侵权，请联系删除。