从知识沉淀到编程范式：AI Coding 项目冷启动落地实践

作者：vivo 互联技术保障团队- Chen Ningning

目录

01. 背景

02. 现实问题

03. 理论探索

04. 方法设计

05. 实践脉络：从知识沉淀到范式开发

06. 效果评估与经验教训

07. 结论展望

AI Coding（AI 编码）的落地瓶颈已从模型逻辑能力转向上下文管理与开发意图的表达。

本文基于SmartFlow互动策略引擎从需求到前后端协同交付的实践，提出一套适用于存量业务系统的 AI Coding 项目冷启动方法，其核心是两条循环往复的实践主线，一是历史工程知识沉淀，从存量代码与历史需求中提炼项目级 Skill，将隐性架构知识显式化、可复用化；二是新需求按 AI 编程范式开发，在知识就绪的基础上，以需求规格化 → 规格评审 → 受控实现 → 验证联调 → 知识回写的闭环推进每一次需求交付。实践表明，该方法能显著降低跨服务、跨机房、跨前后端协同开发的认知成本，让 AI 从一次性对话工具升级为持续积累的团队资产。本文给出了方法设计、完整实践脉络与可复用的经验教训。

1分钟看图掌握核心要点👇

01

背景

本文将结合基于 WhatsApp 构建 SmartFlow 的实践，介绍项目冷启动的方法和经验。SmartFlow 主要是为 WhatsApp 编排一套互动策略流程，用户订阅某个 WhatsApp 账号后，如果向该账号发送一条消息或点击某个消息按钮，SmartFlow 就会根据上行消息匹配策略后做消息智能投放。项目启动时，项目上下文经验注入少，同时又要快速交付能力，过程中一边实战一边进行方法论梳理，依靠这套方法论，从项目启动到最终交付，相比原计划交付时间减少 2/3。前面简单介绍一下背景，本文更多想通过这次项目冷启动实战做更深入的思考总结，使这套方法论在 AI Coding 实践中给大家提供借鉴。

02

现实问题

在最开始进行AI Coding实践时想法很简单，只要模型足够强，写代码就不愁。但是真正到业务需求上试完之后，发现完全不是这么回事。这两年生成式 AI（GenAI）确实把编程往前推了一大截，各种新工具层出不穷，可拿到真实业务需求上一试就发现，模型参数堆得再大，业务逻辑里的幻觉和失控并没有减少[1]。经过不断摸索才慢慢意识到，限制 AI Coding 的不是推理能力，而是两件更基础的事，一是它能看到的信息不够干净，二是我们想让它做什么说得不够清楚[1][3]。这种感受在开发存量系统时尤其明显。大型代码库经过多年演化，真正重要的决策很少写在代码里，大多散在需求文档、群聊、会议记录和个人记忆中。AI 拿到任务后，既看不见这些隐性背景，又得从一长串对话历史里自己判断任务边界，结果常常是，代码写出来能编译、能跑，架构却是错的，业务逻辑也偏离了本来意图。落到具体引入AI Coding的环节，我们面对的问题有[1]：

• 背景缺失：关键决策不在代码里，而在文档、群消息、会议纪要甚至开发者的记忆里。AI 缺了这些背景，只能照语法写个样子对的方案，架构初衷对不上；

• 需求模糊：需求散落在 PRD 和聊天记录里，编码时找不到一份完整说明，AI 只能靠上下文自行补充，补着补着就可能就偏离需求原本的面貌；

• 经验留不住：会话窗口一关，AI 的能力就归零，每次都是从零开始，个人摸索出来的经验转化不成项目资产。

这三个问题，在一个需求横跨多个存量工程、多个机房、前后端同时改动的场景下会被急剧放大，而 SmartFlow 恰好就是这样一个典型场景。要怎么解决？相信这些问题对绝大多数AI Coding的开发者都是共性问题，接下来先从业界已有的研究和实践里找思路，看看别人怎么应对这三类问题。

03

理论探索

下面我们从理论出发，探索怎么让 AI 看懂项目、怎么让 AI 做对需求、开发过程中的能力经验又怎么才能更好的沉淀下来。通过对行业经验的探索，更好地指导开发人员在实际开发过程中，能更加快速高效的完成需求开发。

3.1 上下文工程：让 AI 看懂项目

在 SmartFlow 的实践过程中，经过几轮AI Coding后我们发现，同样一个需求，喂给模型的材料不同，产出质量天差地别。与其反复打磨提示词的措辞，不如想清楚，这一次会话里，该把哪些代码、文档、约束放进去[1][3]。这个思路对应业界上下文工程（Context Engineering），它和传统的提示词工程（Prompt Engineering）着眼点不同，后者关心话怎么说模型才听得懂，前者关心哪些信息进来、哪些信息不进窗口。Anthropic 的工程实践给了我们不少启发，其中有三条可操作原则：

• 状态与输入分开管理：会话长期积累的状态是一回事，单次任务要用的上下文是另一回事，两者不能混在一个筐里；

• 上下文要按章法拼装：用命名清楚、顺序固定的模块来组织输入，而不是想到什么塞什么；

• 尽量少给、按需再取：每个执行环节只加载它真正用得到的最小信息，发现不够了再通过工具现场补充[1][3]。

落到日常开发上，我们把它简化成一套固定的推进节奏，AI 先摸清项目现状，再开发改动，最后验证结果，大致模拟一个开发人员拿到任务时的思考顺序[4]。为了保证每次新会话都能站在同一认知起点上，在工程根目录放了一份项目说明，把架构、编码约定、历史踩过的坑都写进去，作为跨会话的长效记忆[1]。按照这套做法执行，AI 开发前已经把项目看懂了，而不是一边写一边猜。

3.2 规格驱动开发（SDD）：让 AI 做对需求

规格驱动开发（Spec-Driven Development, SDD）解决的是AI 按什么标准干活的问题，开始编码前，开发人员和 AI 先共同敲定一份行为契约，明确系统应该表现成什么样，后续的代码生成、测试和验收都以这份契约为准绳[1][5]。关于这类实践怎么做，Thoughtworks 的 Birgitta Böckeler 在 martinfowler.com 上发表的分析

（Understanding Spec-Driven-Development:

 Kiro, spec-kit, and Tessl）给了我们很清晰的坐标系[5]，他把规格驱动实践分成三个递进层级：

• 规格优先（Spec-first）：先写规格再让 AI 写代码，规格是执行前的输入；

• 规格锚定（Spec-anchored）：规格在功能上线后保留下来，随功能演进持续更新，变成一份活文档；

• 规格为源（Spec-as-source）：人只编辑规格，代码由AI生成，规格取代源码成为最主要的产出物，实现声明式开发。

在工程实践上，业界普遍把规格驱动拆成规格、计划、任务、实现、验证五个阶段，前一个阶段的产出约束后一个阶段的输入[6][7]。不过我们没有追求规格自动生成全部代码的理想形态，那对规格的形式化程度要求太高，现实业务很难满足。我们采用的是更务实的组合，规格先行，AI 负责实现、自动化测试，然后由人工评审把关。这样安排的核心逻辑是，判断做什么、不做什么、怎么验收，这些关键决策仍然由人来做，AI 的价值体现在约定边界内把活干得更快更稳，而不是替人做决定。

3.3 团队知识沉淀：让 AI 能力工程化

单次会话里把 AI 调教得再好，窗口一关一切归零。要让AI Coding能力从个人本事变成团队资产，关键不是让每个人各练各的，而是把经验打包成工程化的形式沉淀下来[1]。结合这次实践，我们主要用了三种打包方式：

• Skill 封装：团队长期积累的编码规范、安全审查要点、中间件用法，我们把这些整理成可加载的技能文件，AI 工具在开工时会自动带上，效果相当于把资深工程师的经验预制进了工具里，每个会话默认就有这套把关逻辑，而不是等出了问题再补。

• 负向约束沉淀：AI 在开发中反复踩同一个坑时，与其每次口头纠正，不如直接把这条教训写成不允许这么做的约束，写进项目规范。这样后续所有会话天然绕开，不用靠人盯。

• 效能飞轮：规定每完成一次需求交付，就把这次新学到的约束、新确认的约定更新回知识库；AI 反复犯的错也同步固化成规则。一轮轮积累下来，形成经验越攒越多、AI 越用越稳的循环[1]，个人的一次性经验沉淀成可复用资产。

这三项理论基础，上下文工程、规格驱动开发、团队知识沉淀，共同构成了本文冷启动方法的设计支撑。

04

方法设计

基于前面的探索，我们先回答一个问题，如何让 AI 在存量业务系统中看懂项目、做对需求、沉淀经验？我们提出一套可复制的 AI Coding 团队冷启动方法，其内核是历史知识沉淀（Skill）与新需求按 AI 编程范式开发两条主线构成循环。

4.1 总体框架

本文提出如图所示的 AI Coding 项目冷启动方法。其核心是两条实践主线构成的闭环循环，两条主线的关系是，知识沉淀 回答AI 凭什么看得懂这个项目，AI 编程范式开发 回答需求来了怎么让 AI 做得对。形成沉淀 → 使用 → 再沉淀的自我增强循环。

4.2 从历史工程提炼项目级 Skill

这是冷启动的第一步，也是最容易被忽视的一步。存量业务系统在长期演化中积累了海量的隐性知识，架构决策、转发链路、状态机、配置约定、历史坑点。这些知识散落在各处，如果不先显性化，AI 每次开发都只能盲人摸象。我们把提炼过程分为四个步骤：

• 知识盘点：以哪些知识是 AI 开发新需求时必须知道、但无法从代码本身直接推断的为标准，盘点历史工程与历史需求。以SmartFlow为例，盘点出三类关键知识：多机房（部署在多个机房，按机房路由）请求转发链路、业务投放全流程、WhatsApp对接规范。

• 结构化组织：将盘点的知识组织为主文档 + 分层引用的结构。主文档回答这个系统是什么、关键链路怎么走、排查问题从哪里入手，包含系统架构全景图、产品全景图、关键链路、状态机、文件索引与使用指南等；需要长篇幅展开的细节则放入独立引用文档，按需加载。

• 按需加载设计：主文档只放高频、短小的核心信息，需要展开的细节放到独立文档里，AI 用到哪份再加载哪份。这个安排和上下文工程尽量少给、需要时再取的思路是一致的[3]，一次会话里塞进去的内容越少，模型注意力越集中，不容易因为无关信息太多而中毒[1]。

• 持续回写：Skill 不是一次性产物。每次开发实践中发现的既有隐患、新增的架构约定，都要回写进 Skill，使后续会话天然携带最新约束，形成发现、固化、复用的正向循环[1]。

4.3 新需求按 AI 编程范式开发

在知识就绪后，每一次新需求开发都遵循统一的五阶段闭环，与 SDD 的规格 → 计划 → 任务 → 实现 → 验证五环节一致[2]，其关键设计在于，规格不追求形式化的通用语言，而是针对存量业务系统的领域化描述，包含流程节点、状态机、接口契约等，保证开发人员可以评审，AI可以无脑执行；人的判断前置到需求、边界和验收标准上，AI 负责按规格高效执行[2]。

05

实践脉络：从知识沉淀到范式开发

接下来我们从SmartFlow 的完整开发过程出发，完整展示两条主线如何在实际业务中落地，聚焦实践过程与决策逻辑。

5.1 项目概况

SmartFlow 是一个基于可视化编辑的自动化营销工具，业务目标是，支持业务方配置基于 WhatsApp 的自动交互流程，实现用户发消息 → 匹配互动策略 → 自动下发营销模板 → 用户回复消息 → 再次下发消息或结束语的营销闭环。需求横跨三个工程，新建后端服务、存量中台改造、前端开发改造。需求本身隐含两类难点，一是多机房部署要求，互动策略需要按机房路由到对应环境；二是与既有存量系统深度耦合，不能与已有功能重复建设。

5.2 第一步：先沉淀，再开发

在写新代码之前，首先对涉及的存量系统做了一次系统的知识盘点与提炼，产出了项目级 Skill(sms-develop-skill)。整个过程分为四个环节：

• 梳理系统全景：明确系统由哪些工程、哪些层次组成，各层的职责分工与依赖关系，形成一张可被 AI 读取的系统地图。

• 提炼关键链路：将最核心、最容易出错的链路以流程化、结构化的方式写入知识库，并标注关键节点与决策点。

• 固化环境与配置约定：将各环境、各机房的配置规范与部署步骤整理成清单，避免 AI 在开发时对配置体系做出错误假设，并且对开发规范等做了约定。

• 标注已知问题与坑点：把历史开发中发现的隐患，显式记录，使后续所有会话天然规避同类问题，实现错误一次、永久免疫。

这一步是让 AI 在后续所有开发会话中，默认具备与资深工程师对等的系统认知，它知道请求从哪进、往哪转发、业务状态如何流转、配置从哪取，而不是靠每次临场猜测。

5.3 第二步：按 AI 编程范式开发新需求

当我们将项目历史知识形成Skill后，新需求的开发基于这个Skill，严格按这五个阶段推进，从而更加准确高效的进行功能开发迭代。

需求规格化

需求入口是一份 PRD，包含功能概述、节点类型、分支路由规则、定时任务要求等。在 AI 开发之前，团队先将 PRD 转换为可评审、可执行的规格，例如前后端交互契约规格、数据与模块边界规格等。规格化过程的核心产出是消除了需求中的关键歧义。例如一个商业账号只可绑定一个策略，执行实例如何判定活跃会话；用户超时无回复时，流程由谁推进、何时终结。这两点若不前置澄清，AI 实现的流程调度必然跑偏，这正是 SDD把人的判断前置的价值所在[2]。

规格评审

规格文档交由人工评审，确认做什么、不做什么、如何验收。评审不通过则回到需求规格化改规格，通过后才进入实现。这一环节保证了需求的边界由人来定，而不是由 AI 临场推断。

受控实现 

AI 按任务清单逐项实现。由于已经注入了完整架构知识与团队编码规范，AI 的实现表现出两个显著特征，一是主动复用既有模式，多机房转发、模板映射、消息发送等能力在存量系统中已有成熟实现，AI 知道这些功能就直接复用；二是遵循既有工程约定，包结构、命名、异常处理、配置获取方式均与存量代码保持一致，避免了语法正确、风格背离的返工。

验证联调

前后端按规格契约联调。关键改造点在于前端请求统一收敛到中台新增的转发通道，不再依赖按机房硬编码的路径转发，这既简化了运维，也让前端业务代码彻底摆脱机房感知。

知识回写

开发完成后，将本次实践中新增的知识与发现的问题回写进项目级 Skill，新增了哪些通道与配置、解决了哪些歧义、发现了哪些既有隐患。至此，一次需求开发闭环完成，知识库得到扩充，使下次的需求能更快的开发迭代。

5.4 实践中的关键问题与处理

06

效果评估与经验教训

最后我们从结果的角度给这次实践做个复盘，先看交付层面拿到了哪些实打实的效果，再坦率地说说这套方法目前还有哪些局限，最后把整个过程中总结出来的经验教训提炼成六条，方便大家直接复用。

6.1 实践成效

从结果看，这次实践主要收获了几点：

• 端到端交付：在沉淀 → 开发闭环下顺利完成，没有出现与既有工程结构冲突的大改；

• 复用显著：中台转发通道完全复用既有转发模式，新增工作量集中在按既有约定扩展而不是重新设计，这直接得益于 Skill 注入的架构认知；

• 知识资产：沉淀出一份项目级 Skill，覆盖系统全景、关键链路、配置规范、已知问题四个维度，后续新成员或新会话能即时获得同一份架构认知；

• 质量稳定：全部新增代码通过团队编码规范扫描，没有发生因不理解既有架构而推倒重来的情况。

6.2 局限性

• 单案例局限：结论来自单一业务场景、没有对照组、量化指标也偏少，目前能拿得出手的只有交付时间这一项，工时节省比例、缺陷率变化这些并没有，普适性需要放到更多项目上验证；

• 人工依赖：规格评审、规范扫描目前还是人工在做，没有接入 CI/CD 实现自动化；

• 知识时效性：知识库和代码之间会漂移，时间一长容易对不上，需要一套跟代码变更联动的更新机制来兜底。

6.3 经验总结

基于这次冷启动实践，我们提炼出六条可复用的经验：

（1）先沉淀，再开发

在存量工程里，AI 生成语法正确、风格背离代码的根因是缺乏系统认知。先把历史工程与历史需求提炼成可复用的知识资产，是投入产出比最高的第一步，也是让 AI越用越懂项目的前提。

（2）项目级 Skill 是知识沉淀的最小完备单元

相比完整的规格工件体系，主文档 + 分层引用的结构轻量、渐进、按需加载，适合作为团队 AI 能力资产化的起点；随着实践成熟，可向 Spec-anchored / Spec-as-source 演进[2]。

（3）让 AI 复用既有功能，而不是重复开发

多机房转发、模板映射、消息发送这些能力，存量系统里早就有了成熟实现。知识库要做的就是让 AI知道这些模式存在、直接沿用，省得重复造轮子。

（4）把已知问题写进知识库

开发过程中发现的隐患与坑点，显式记录到知识库，让后续所有会话天然规避同类问题，实现错误一次、永久免疫。

（5）人机分工要明确

人是规格与验收的判定者，AI 是规格的执行者[2]。做什么、不做什么、如何验收，这些边界确认，必须在编码前完成，不能等生成代码后再靠修补挽回。

（6）一定要进行知识回写 

一次需求交付的结束，正是知识资产增值的开始。坚持每次开发都回写，团队 AI 能力才能持续积累而不是原地踏步。

07

结论展望

本文针对 AI Coding 在项目中的冷启动难题，提出历史知识沉淀项目级 Skill与新需求按 AI 编程范式开发两条线构成的闭环方法，并以 SmartFlow 的多工程协同开发实践验证了其可行性。这次实践最大启示是，SmartFlow 能提前交付，靠的不是用了更强的模型，而是提前把项目知识翻译成了 AI 能稳定消费的形式。知识沉淀解决AI 凭什么看得懂这个项目，规格化解决需求来了怎么让 AI 做得对，两条线合在一起，AI 产出的代码才能长期与存量工程的结构和规范保持一致，团队经验也随之沉淀为可复用的资产[1]。

后续工作包括三个方向，一是将规范扫描与验收接入 CI/CD，实现规格 → 实现 → 验证的自动化；二是将项目级 Skill 升级为团队级知识库，支持多项目复用与版本管理；三是引入量化评估（工时、缺陷率、返工率），为冷启动方法建立可度量的效果基线。

参考文献

[1] The New Stack. Context Is AI Coding's Real Bottleneck in 2026[EB/OL]. [2026-09-07]. 
https://thenewstack.io/context-is-ai-codings-real-bottleneck-in-2026/.

[2] GitHub Blog. Spec-Driven Development with AI: Get started with a new open source toolkit[EB/OL]. [2026-09-07]. 
https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/.

[3] Anthropic. Effective Context Engineering for AI Agents[EB/OL]. [2026-09-07]. 
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents.

[4] Anthropic. How Claude Code Works[EB/OL]. [2026-09-07]. 
https://code.claude.com/docs/en/how-claude-code-works.

[5] Böckeler B. Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl[EB/OL]. (2025-10-15)[2026-09-07]. 
https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html.

[6] DORA (Google Cloud). Accelerate State of DevOps Report 2024[R/OL]. (2024-10-23)[2026-09-07]. 
https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report.

[7] Fission AI. OpenSpec: Spec-Driven Development for AI Coding Assistants[EB/OL]. [2026-09-07]. 
https://openspec.dev.

END

猜你喜欢

vivo HTTPDNS 端到端体验优化实践

NLLB 与 ChatGPT 双向优化：探索翻译模型与语言模型在小语种应用的融合策略