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

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

背景

现实问题

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

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

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

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

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

理论探索

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

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

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

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

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

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

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

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

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

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

方法设计

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

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

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

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

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

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

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

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

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

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

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

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

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

需求规格化

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

规格评审

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

受控实现 

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

验证联调

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

知识回写

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

效果评估与经验教训

结论展望

本文针对 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.

猜你喜欢