从知识沉淀到编程范式：AI Coding 项目冷启动落地实践 – vivo互联网技术

Author: vivo Internet Technology Assurance Team-Chen Ningning
The implementation bottleneck of AI Coding has shifted from model logic capabilities to context management and expression of development intentions.
Based on the practice of SmartFlow interactive strategy engine from demand to front-end and back-end collaborative delivery, this article proposes a set of cold start methods for AI Coding projects suitable for existing business systems. The core is two recurring main lines of practice. One is the precipitation of historical engineering knowledge, refining project-level skills from existing codes and historical requirements, and making implicit architecture knowledge explicit and reusable. The second is the development of new requirements according to the AI programming paradigm. On the basis of knowledge readiness, standardization of requirements → Specification review → Controlled implementation → Verification and joint debugging → The closed loop of knowledge write-back promotes each requirement delivery. Practice has shown that this method can significantly reduce the cognitive cost of collaborative development across services, computer rooms, and front-end and back-end, and upgrade AI from a one-time conversation tool to a continuously accumulated team asset. This article provides method design, complete practice context, and reusable experiences and lessons.

1 minute to look at the pictures and grasp the key points👇

1. Background

This article will combine the practice of building SmartFlow based on WhatsApp to introduce the method and experience of cold start of the project. SmartFlow mainly arranges a set of interactive strategy processes for WhatsApp. After a user subscribes to a WhatsApp account, if he sends a message to the account or clicks a message button, SmartFlow will intelligently deliver the message based on the upstream message matching strategy. When the project started, there was little project context experience injection, and at the same time, the ability to deliver quickly was required. During the process, the methodology was sorted out while practicing. Relying on this methodology, from project start to final delivery, the delivery time was reduced by 2/3 compared to the original plan. Before briefly introducing the background, this article wants to make a more in-depth thinking and summary through the actual cold start of this project, so that this methodology can provide reference for everyone in the practice of AI Coding.

2. Practical issues

When I first started practicing AI Coding, my idea was very simple. As long as the model was strong enough, I wouldn’t have to worry about writing code. But after actually trying it on business needs, I found that this was not the case at all. In the past two years, generative AI (GenAI) has indeed pushed programming forward a lot. Various new tools are emerging one after another. But when you try it with real business needs, you will find that no matter how large the model parameters are, the illusion and loss of control in the business logic have not been reduced.[1]. After constant exploration, I slowly realized that what limits AI Coding is not its reasoning ability, but two more basic things. One is that the information it can see is not clean enough, and the other is that what we want it to do is not clear enough.[1][3]. This feeling is especially obvious when developing stock systems. Large code bases have evolved over the years, and truly important decisions are rarely written in the code, but mostly scattered in requirements documents, group chats, meeting minutes, and personal memories. After the AI ​​gets the task, it cannot see these hidden backgrounds, but also has to judge the task boundaries by itself from a long sequence of dialogue history. The result is often that the code can be compiled and run, but the architecture is wrong, and the business logic deviates from the original intention. When it comes to the specific introduction of AI Coding, the problems we face are:[1]：

• Missing background:Key decisions are not in the code, but in documents, group messages, meeting minutes, and even developers’ memories. AI lacks these backgrounds and can only write a correct solution based on grammar, which does not match the original intention of the architecture;
• Ambiguous requirements:Requirements are scattered in PRDs and chat records, and a complete description cannot be found during coding. AI can only rely on context to supplement it. Adding to it may deviate from the original appearance of the requirements;
• Experience cannot be retained:As soon as the session window is closed, the AI’s capabilities return to zero. Each time it starts from scratch, the experience gained by individuals cannot be converted into project assets.

These three problems will be dramatically amplified in a scenario where the requirements span multiple existing projects, multiple computer rooms, and front-end and back-end changes are performed at the same time. SmartFlow happens to be such a typical scenario. How to solve it? I believe that these problems are common to the vast majority of AI Coding developers. Next, let’s find ideas from the existing research and practice in the industry and see how others deal with these three types of problems.

3. Theoretical exploration

Next, we start from theory and explore how to make AI understand the project, how to make AI meet the requirements, and how to better accumulate the ability and experience in the development process. Through the exploration of industry experience, developers can better guide developers in the actual development process to complete demand development more quickly and efficiently.

3.1 Context Engineering: Let AI understand the project

In the practice of SmartFlow, after several rounds of AI Coding, we found that for the same requirement, the quality of the output varies greatly with different materials fed to the model. Rather than refining the wording of prompt words over and over again, it is better to think clearly about what code, documents, and constraints should be included in this session.[1][3]. This idea corresponds to the industry’s Context Engineering. It has a different focus from the traditional Prompt Engineering. The latter cares about how to say the words so that the model can understand them. The former cares about what information comes in and what information does not enter the window. Anthropic’s engineering practices have given us a lot of inspiration, including three operational principles:

• Status and input are managed separately:The long-term accumulated state of a session is one thing, and the context used for a single task is another. The two cannot be mixed in the same basket;
• The context should be assembled in a structured way:Use clearly named and fixed-sequence modules to organize input, rather than stuffing whatever comes into mind;
• Give as little as possible and take as needed:Each execution link only loads the minimum information that it actually uses. If it finds that it is not enough, it will be supplemented on-site through tools.[1][3]。

When it comes to daily development, we simplify it into a set of fixed advancement rhythms. AI first understands the current status of the project, then develops changes, and finally verifies the results, roughly simulating the thinking sequence of a developer when receiving a task.[4]. In order to ensure that each new session can stand on the same cognitive starting point, a project description is placed in the project root directory, and the architecture, coding conventions, and historical pitfalls are written down as a long-term memory across sessions.[1]. By following this approach, the project will be understood before AI development, instead of guessing while writing.

3.2 Specification-driven development (SDD): Let AI meet requirements

Spec-Driven Development (SDD) solves the problem of what standards AI should work according to. Before starting coding, developers and AI jointly finalize a behavioral contract to clarify how the system should behave. Subsequent code generation, testing and acceptance are based on this contract.[1][5]. On how to do this kind of practice, analysis published by Birgitta Böckeler of Thoughtworks on martinfowler.com

（Understanding Spec-Driven-Development:

Kiro, spec-kit, and Tessl) gives us a very clear coordinate system[5]he divided specification-driven practice into three progressive levels:

• Spec-first:Write the specifications first and then let AI write the code. The specifications are the input before execution;
• Spec-anchored:The specifications are retained after the function is launched, and are continuously updated as the function evolves, becoming a living document;
• Spec-as-source:People only edit the specifications, and the code is generated by AI. The specifications replace the source code and become the main output, achieving declarative development.

In engineering practice, the industry generally divides specification drive into five stages: specification, plan, task, implementation, and verification. The output of the previous stage constrains the input of the next stage.[6][7]. However, we do not pursue the ideal form of automatically generating all codes based on specifications. That would require too high a level of formalization of specifications, which is difficult to meet in real business. We adopt a more pragmatic combination, where specifications come first, AI is responsible for implementation, automated testing, and then manual review. The core logic of this arrangement is that humans still make key decisions about what to do, what not to do, and how to accept it. The value of AI is reflected in making work faster and more stable within the agreed boundaries, rather than making decisions for humans.

3.3 Team knowledge accumulation: engineering AI capabilities

No matter how well you train the AI ​​in a single session, everything will return to zero as soon as the window is closed. To turn AI Coding capabilities from personal skills into team assets, the key is not to let everyone practice individually, but to package the experience into an engineering form and accumulate it.[1]. Based on this practice, we mainly used three packaging methods:

• Skill package:We organize the coding standards, security review points, and middleware usage that the team has accumulated over a long period of time into loadable skill files. The AI ​​tool will automatically bring it with it when it starts working. The effect is equivalent to prefabricating the experience of senior engineers into the tool. Each session will have this set of control logic by default, instead of waiting for problems to be fixed.
• Negative constraint precipitation:When AI repeatedly steps on the same pitfall during development, instead of correcting it verbally each time, it is better to directly write this lesson into a constraint that does not allow this, and write it into the project specifications. In this way, all subsequent conversations will be naturally bypassed without relying on human surveillance.
• Efficiency Flywheel:It is stipulated that every time a requirement delivery is completed, the newly learned constraints and newly confirmed agreements will be updated back to the knowledge base; the mistakes repeatedly made by AI will also be solidified into rules simultaneously. It accumulates round by round, forming a cycle in which the more experience you accumulate, the more you use the AI, the more stable it becomes.[1]personal one-time experiences are precipitated into reusable assets.

These three theoretical foundations, contextual engineering, specification-driven development, and team knowledge accumulation, together form the design support for the cold start method in this article.

4. Method design

Based on the previous exploration, we first answer a question: How can AI understand projects, meet requirements, and accumulate experience in existing business systems? We propose a set of replicable cold start methods for AI Coding teams, the core of which is a cycle composed of two main lines: historical knowledge accumulation (Skill) and new demand development according to the AI ​​programming paradigm.

4.1 Overall framework

This article proposes a cold start method for AI Coding projects as shown in the figure. Its core is a closed loop composed of two main lines of practice. The relationship between the two main lines is that knowledge accumulation answers why AI can understand this project, and AI programming paradigm development answers how to make AI do it right when the demand comes. A self-reinforcing cycle of precipitation → use → reprecipitation forms.

4.2 Extract project-level skills from historical projects

This is the first step in cold start and the most overlooked step. In the long-term evolution, the existing business system has accumulated a large amount of tacit knowledge, including architectural decisions, forwarding links, state machines, configuration conventions, and historical pitfalls. This knowledge is scattered everywhere. If it is not made explicit first, AI can only be developed blindly. We divide the refining process into four steps:

• Knowledge inventory:Taking stock of historical projects and historical requirements based on what knowledge must be known when developing new requirements for AI but cannot be directly inferred from the code itself. Taking SmartFlow as an example, we listed three types of key knowledge: multi-computer room (deployed in multiple computer rooms, routed according to the computer room) request forwarding link, the entire business delivery process, and WhatsApp docking specifications.
• Structured organization:Organize the inventoried knowledge into a main document + hierarchical reference structure. The main document answers what the system is, how to navigate the key links, and where to start troubleshooting problems. It includes system architecture panorama, product panorama, key links, state machines, file indexes, usage guides, etc.; details that require long-form expansion are put into independent reference documents and loaded on demand.
• Load designs on demand:The main document only contains high-frequency, short core information, and the details that need to be expanded are placed in independent documents, and the AI ​​will load which copy it uses. This arrangement is consistent with the idea of ​​​​giving as little as possible to context engineering and taking it when needed.[3]the less content is crammed into a session, the more focused the model’s attention is, and it is less likely to be poisoned by too much irrelevant information.[1]。
• Continue writing back:Skill is not a one-time product. Existing hidden dangers and new architectural conventions discovered during each development practice must be written back into the Skill, so that subsequent sessions will naturally carry the latest constraints, forming a forward cycle of discovery, solidification, and reuse.[1]。

4.3 New requirements are developed according to the AI ​​programming paradigm

After the knowledge is ready, each new requirement development follows a unified five-stage closed loop, which is consistent with the five links of SDD: Specification→Plan→Task→Implementation→Verification[2]its key design is that the specifications do not pursue a formal universal language, but are domain-specific descriptions of existing business systems, including process nodes, state machines, interface contracts, etc., ensuring that developers can review and AI can execute without brains; human judgment is placed in front of requirements, boundaries and acceptance criteria, and AI is responsible for efficient execution according to specifications.[2]。

5. Practical Context: From Knowledge Precipitation to Paradigm Development

Next, we start from the complete development process of SmartFlow and fully demonstrate how the two main lines are implemented in actual business, focusing on the practical process and decision-making logic.

5.1 Project Overview

SmartFlow is an automated marketing tool based on visual editing. The business goal is to support business parties in configuring automatic interaction processes based on WhatsApp to achieve a closed marketing loop in which users send messages → match interaction strategies → automatically deliver marketing templates → users reply to messages → deliver messages or concluding remarks again. The demand spans three projects, including new back-end services, existing middle-end transformation, and front-end development and transformation. The demand itself implies two types of difficulties. The first is the deployment requirement of multiple computer rooms, and the interaction strategy needs to be routed to the corresponding environment according to the computer room; the second is the deep coupling with the existing stock system, and it cannot be duplicated with the existing functions.

5.2 Step one: Precipitate first, then develop

Before writing new code, we first conducted a systematic knowledge inventory and refinement of the existing systems involved, and produced project-level skills (sms-develop-skill). The whole process is divided into four links:

• To sort out the system panorama:It is clear which projects and layers the system consists of, and the division of responsibilities and dependencies of each layer to form a system map that can be read by AI.
• Extract key links:Write the most core and error-prone links into the knowledge base in a streamlined and structured manner, and mark key nodes and decision points.
• Solidified environment and configuration conventions:Organize the configuration specifications and deployment steps of each environment and each computer room into a list to avoid making wrong assumptions about the configuration system during AI development, and make an agreement on development specifications.
• Mark known issues and pitfalls:Explicitly record the hidden dangers discovered in historical development, so that all subsequent sessions can naturally avoid similar problems and achieve permanent immunity after making a mistake once.

This step allows AI to have the same system knowledge as a senior engineer by default in all subsequent development sessions. It knows where requests come from, where they are forwarded, how business status flows, and where configurations are obtained, instead of relying on on-the-spot guesses every time.

5.3 Step 2: Develop new requirements according to the AI ​​programming paradigm

After we form the project historical knowledge into a Skill, the development of new requirements is based on this Skill and strictly proceeds according to these five stages, so as to carry out functional development iterations more accurately and efficiently.

Standardization of requirements

The requirements entry is a PRD, including function overview, node type, branch routing rules, scheduled task requirements, etc. Before AI development, the team first converts the PRD into reviewable and executable specifications, such as front-end and back-end interaction contract specifications, data and module boundary specifications, etc. The core output of the specification process is the elimination of critical ambiguities in requirements. For example, a commercial account can only be bound to one policy. How does the execution instance determine active sessions? When a user times out and does not reply, who advances the process and when does it end. If these two points are not clarified in advance, the process scheduling implemented by AI will inevitably go astray. This is the value of SDD in putting human judgment in advance.[2]。

Specification review

Specification documents are submitted to manual review to confirm what to do, what not to do, and how to accept it. If the review fails, return to requirements specification and change specifications, and then enter implementation after passing the review. This link ensures that the boundaries of demand are determined by humans rather than inferred by AI on the spot.

controlled implementation

AI is implemented one by one according to the task list. Since complete architectural knowledge and team coding standards have been injected, the implementation of AI shows two distinctive characteristics. First, it proactively reuses existing patterns. Capabilities such as multi-machine room forwarding, template mapping, and message sending have been maturely implemented in the stock system. AI can reuse these functions directly after knowing these functions. Second, it follows existing engineering conventions, and the package structure, naming, exception handling, and configuration acquisition methods are all consistent with the stock code, avoiding rework with correct syntax and style deviation.

Verification joint debugging

The front and rear ends are jointly debugged according to the specifications. The key transformation point is that front-end requests are uniformly converged to the new forwarding channel in the middle office, and no longer rely on hard-coded path forwarding according to the computer room. This not only simplifies operation and maintenance, but also completely eliminates the front-end business code from the computer room perception.

knowledge write back

After the development is completed, the new knowledge and problems discovered during this practice will be written back into the project-level Skill, including which channels and configurations have been added, which ambiguities have been resolved, and which existing hidden dangers have been discovered. At this point, a closed loop of demand development is completed, and the knowledge base is expanded, allowing the next demand to be developed and iterated faster.

5.4 Key issues and solutions in practice

6. Effect evaluation and lessons learned

Finally, we will review this practice from the perspective of results. We will first look at the actual results achieved at the delivery level, and then frankly talk about the current limitations of this method. Finally, we will refine the lessons learned from the entire process into six items for everyone to reuse directly.

6.1 Practical results

Judging from the results, there are several main points gained from this practice:

• End-to-end delivery:It was successfully completed under the closed loop of precipitation → development, and there were no major changes that conflicted with the existing engineering structure;
• Significant reuse:The middle station forwarding channel completely reuses the existing forwarding mode, and the new workload is focused on expanding according to the existing agreement rather than redesigning it. This directly benefits from the architectural knowledge injected by Skill;
• Intellectual assets:A project-level skill is precipitated, covering the four dimensions of system panorama, key links, configuration specifications, and known issues. Subsequent new members or new sessions can instantly obtain the same architectural understanding;
• Stable quality:All newly added codes have been scanned by the team’s coding standards, and there has been no overthrowing and starting over due to a lack of understanding of the existing architecture.

6.2 Limitations

• Single case limitations:The conclusion comes from a single business scenario, there is no control group, and there are few quantitative indicators. Currently, the only item that can be obtained is the delivery time. There is no such thing as the proportion of working hours saved and the change in the defect rate. The universality needs to be verified on more projects;
• Artificial dependencies:Specification review and specification scanning are still done manually, and there is no access to CI/CD for automation;
• Knowledge timeliness:There will be drift between the knowledge base and the code, and it is easy to lose track of them over time. An update mechanism that is linked to code changes is needed to cover the situation.

6.3 Experience summary

Based on this cold start practice, we extracted six reusable experiences:

(1) Precipitate first, then develop

In existing projects, the root cause of AI-generated code with correct syntax and deviating style is the lack of system knowledge. First refining historical projects and historical requirements into reusable knowledge assets is the first step with the highest input-output ratio, and is also the prerequisite for AI to understand the project more and more as it is used.

(2) Project-level Skill is the smallest complete unit for knowledge accumulation

Compared with the complete specification artifact system, the structure of master document + hierarchical reference is lightweight, progressive, and loaded on demand, and is suitable as the starting point for capitalizing the team’s AI capabilities; as practice matures, it can evolve to Spec-anchored / Spec-as-source[2]。

(3) Let AI reuse existing functions rather than redundant development

Capabilities such as multi-machine room forwarding, template mapping, and message sending have long been maturely implemented in existing systems. What the knowledge base needs to do is to let AI know that these patterns exist and use them directly to avoid reinventing the wheel.

(4) Write known issues into the knowledge base

Hidden risks and pitfalls discovered during the development process are explicitly recorded in the knowledge base, allowing all subsequent sessions to naturally avoid similar problems and achieve permanent immunity after making a mistake once.

(5) The division of labor between man and machine should be clear

Humans are the judges of specifications and acceptance, and AI is the executor of specifications.[2]. What to do, what not to do, how to accept it, these boundary confirmations must be completed before coding, and cannot be repaired after the code is generated.

(6) Be sure to write back knowledge

The end of a demand delivery is the beginning of the appreciation of knowledge assets. By insisting on writing back every development, the team’s AI capabilities can continue to accumulate instead of standing still.

7. Conclusion and outlook

In view of the cold start problem of AI Coding in the project, this article proposes a closed-loop method consisting of two lines: historical knowledge accumulation, project-level skills, and new demand development according to the AI ​​programming paradigm, and its feasibility is verified by the multi-project collaborative development practice of SmartFlow. The biggest revelation from this practice is that SmartFlow can be delivered ahead of schedule not by using a stronger model, but by translating project knowledge in advance into a form that can be stably consumed by AI. Knowledge accumulation solves AI. Why do you understand this project? How to make AI do it right when standardized solution requirements come. When these two lines are combined, the code produced by AI can be consistent with the structure and specifications of the existing projects in the long term, and the team experience will also be deposited into a reusable asset.[1]。

Follow-up work includes three directions. The first is to connect specification scanning and acceptance to CI/CD to realize the automation of specifications → implementation → verification; the second is to upgrade the project-level Skill to a team-level knowledge base to support multi-project reuse and version management; the third is to introduce quantitative evaluation (working hours, defect rate, rework rate) to establish a measurable effect baseline for the cold start method.

References

[1] The New Stack. Context Is AI Coding's Real Bottleneck in 2026[EB/OL]. [2026-09-07]. 


[2] GitHub Blog. Spec-Driven Development with AI: Get started with a new open source toolkit[EB/OL]. [2026-09-07]. 


[3] Anthropic. Effective Context Engineering for AI Agents[EB/OL]. [2026-09-07]. 


[4] Anthropic. How Claude Code Works[EB/OL]. [2026-09-07]. 


[5] Böckeler B. Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl[EB/OL]. (2025-10-15)[2026-09-07]. 


[6] DORA (Google Cloud). Accelerate State of DevOps Report 2024[R/OL]. (2024-10-23)[2026-09-07]. 


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