Core idea: Future software development will not revolve around documents, nor around code, but around a Dynamic Project Tree. Ideas are captured by voice and grow into a tree-shaped knowledge base; every node is first implemented as a virtual function; virtual functions are wired along the tree into a virtual system; data-flow simulation runs on that virtual system; and only after every simulation passes does real programming begin.
Code is Output. Model is Truth. Voice is the Beginning. Simulation is the Proof.

📖 中文版在下方 — scroll down for the Chinese version.

1. AI writes code faster and faster — software isn't getting faster

Today's mainstream AI coding tools — Copilot, Codex, Claude Code — are all essentially embedded in a pipeline designed decades ago:

Requirements → Documents → Prototype → Development → Testing → Deployment

That pipeline was born in an era without AI. AI was simply plugged into the "development" stage, making the code-writing step faster.

But any engineer who has shipped a real project knows that writing code was never the slowest part. What actually burns time is:

Requirements churn early on; you finish the code only to discover you understood them wrong
Architectural changes ripple everywhere, and the cost of change grows exponentially with progress
Documentation forever lags the code, and nobody trusts it
Multiple AI agents each read the code on their own, with no shared understanding of the project
Critical design rationale lives scattered across meetings, chat logs, and someone's head

Making the "write code" step ten times faster helps with none of these. Errors still stay hidden until integration, joint debugging, or production — and by then, the cost of fixing them has grown by orders of magnitude.

So what truly deserves to be rebuilt is not the AI. It's the software engineering process itself.

2. Hardware answered this long ago: nobody tapes out without simulation

The chip industry has an iron law: you must simulate before tape-out.

A single tape-out costs millions of dollars and months of lead time. No team would dare send an unverified design to the fab. That's why the heart of the EDA toolchain has never been "draw circuits faster" — it is: make the entire chip run in a virtual environment first. Timing, power, signal integrity — everything is verified in the virtual world before anything enters the physical one.

Now look at software: we essentially tape out naked.

The requirements document gets written (or not even finished), real code starts immediately, and then integration and testing are left to slam every design error out in the "physical world." We tolerate this only because software's "re-tape-out" looks cheap — just change the code, right? But in the AI era, when agents can generate tens of thousands of lines overnight, the cost of rework is precisely what gets amplified: if the direction is wrong, the faster you generate, the more you waste.

AI-era software engineering should converge toward hardware engineering:

Build the virtual system first → complete simulation and verification → then do the real implementation.

That is the full process this article lays out.

3. Voice is the first input: thought capture, not faster typing

The process does not start with a document. It starts with speaking.

Human thinking is not linear. Insights arrive in a flash: a feature idea while walking, the realization in the shower that two modules' dependency is backwards. If capturing that moment requires opening Word, recalling a template, and composing sentences, the thought is long gone.

The value of voice is not input speed. It is this:

It captures the genuine ideas inside a thought process with the lowest possible friction.

Voice = Thought Capture

The future starting point of development looks like this:

An idea occurs
    ↓
Say it out loud (Voice)
    ↓
AI understands and structures it
    ↓
Automatically mounted onto / updates the project tree

You say: "Sharing should support QR codes, and the codes need a configurable expiry." The AI understands, creates a QR code child node under the Sharing node of the project tree, and records the "supports expiry" constraint in its properties — along with the context in which you said it. Three months later nobody has to excavate chat history; the full lineage of the decision lives on the tree.

4. A tree-shaped knowledge base: the Dynamic Project Tree

Why a tree? Because the human mental model of a project naturally is one:

Project
├── Users
│     ├── Login
│     ├── Permissions
│     └── Profile
├── Sharing
│     ├── QR code
│     ├── Links
│     └── Access control
├── AI capabilities
│     ├── Poster generation
│     ├── OCR
│     └── Copywriting
└── Data
      ├── Database
      ├── API
      └── Cache

Ideas keep sprouting new nodes, rearranging relationships, pruning dead branches. The truth of a project should not live in a Word document that goes stale in a week — it should be this living tree.

The essential difference from a traditional requirements document: each node on the tree is not a paragraph of prose, but a structured data object:

node: Sharing/QR code
description: Generate expiring QR codes for shared content
status: simulated        # idea → defined → simulated → implemented → verified
owner: harry
depends_on: [Users/Permissions, Data/API]
interface:
  input:  { content_id: string, ttl_hours: int }
  output: { qr_url: string, expires_at: datetime }
constraints:
  - Maximum validity is 72 hours
  - Accessing after expiry returns 410
history:
  - 2026-07-12: Created via voice input, "sharing should support QR codes"
  - 2026-07-14: Expiry constraint added (decided after discussion)

A node carries its description, status, owner, dependencies, interface contract, constraints, and evolution history. The whole tree is a continuously growing knowledge graph of the project — it is the requirements base, the architecture diagram, the interface documentation, and the decision log. It is the project's single source of truth.

5. The key step: every node becomes a "virtual function" first

This is the core of the methodology — and the sharpest break from "using AI to write requirements docs."

A feature node on the tree must not stop at "a paragraph of description." Once a node's definition is reasonably clear, the AI immediately promotes it into a Virtual Function:

It has a real interface: the input/output schema is strictly defined — the very contract the future real implementation must honor
It has a virtual implementation: no real logic inside; the AI generates a "behaviorally believable" mock from the node's description — legal input returns semantically plausible simulated output, illegal input errors according to the constraints
It can be called: it is a genuinely runnable function/service stub, not a box in a document

Take the QR code node's virtual function: feed it {content_id: "abc", ttl_hours: 100} and it returns the error "maximum validity is 72 hours" — because the constraint is written on the node. Feed it legal parameters and it returns a structurally correct simulated qr_url.

Not one line of real business code exists, yet the feature already "exists."

Engineers will find this familiar — it smells like a mock, a stub, the provider stub in contract testing. The difference: a traditional mock is an afterthought, hand-maintained and disposable, written while testing code that already exists. Here, virtual functions are first-class citizens that precede the code — auto-generated by the AI from node definitions, auto-updated when definitions change, and — as the next section shows — wired together into a complete system.

6. Along the tree, wire virtual functions into a virtual system

A single virtual function is just a callable stub. The real power is this: the dependency edges on the tree are the system's wiring diagram.

Every node declares its depends_on and its interface contract, so the AI can walk those edges and assemble all the virtual functions:

[Voice/Text] ──> Dynamic project tree ──> Virtual functions ──wired──> Virtual system
                                                   │
   Users/Login (virtual) ──> Users/Permissions (virtual) ──> Sharing/Access control (virtual)
                                                   │
   Sharing/QR code (virtual) <── Data/API (virtual) <── Data/Database (virtual)

What you now hold is a system with zero real code that nevertheless runs as a whole:

Every module can be called, behaving exactly as its node defines
Modules genuinely call each other along the dependencies declared on the tree
The entire call topology is the architecture of the future real system

It is the software system's digital twin — except the twin is born before the original.

At this stage, a mass of problems that traditionally surface only at integration time appear instantly: two nodes' interfaces don't line up, dependencies form a cycle, a module assumes a data field its upstream never produces. The fix is not editing code — it is editing the tree: adjust the node definitions, virtual functions regenerate automatically, the system rewires itself. The cost of change is effectively zero.

7. Data-flow simulation: living everyday life inside the virtual system

With the virtual system assembled, verification begins: Data Flow Simulation.

The AI generates simulation scenarios from the project tree — in essence a batch of end-to-end user journeys with bulk synthetic data:

Scenario 1: New user registers → logs in → creates content → shares via QR code → someone scans and visits
Scenario 2: Visiting after the QR code expires → must return 410
Scenario 3: Unauthorized user tries to open an access-controlled share → must be blocked
Scenario 4: 1,000 concurrent share requests → watch data flow across API / Cache / DB

Synthetic data is injected at the system's entry points and genuinely flows through the virtual system. On the graph you can see how data travels: from the login node into permissions, from the API node into cache; where flow stops dead, where data gets dropped, which path nobody ever reaches, which node every path converges on.

The questions simulation answers are exactly the ones the traditional process answers latest and at the highest price:

Does the business loop close? Can the user journey run start to finish?
Is the data complete? Does upstream actually produce every field downstream consumes?
Does the permission model leak? Is there any path that bypasses the permission node?
Is the architecture sound? Are dependency directions clean? Any accidental coupling or bottleneck nodes?
Were the failure paths considered? Expiry, failure, privilege escalation — does every error path have a destination?

Find a problem → edit the tree → virtual functions auto-update → re-simulate. This loop runs in minutes, not "one iteration." Product managers and engineers argue over the same living, flowing diagram instead of two mutually contradictory documents.

When every simulation scenario passes, what you have verified is not code — it is the design itself.

8. Only after simulation passes does real programming begin

Only now does real programming start. And "programming" at this point means something entirely different:

1. Contracts freeze. Passing simulation means every node's interface contract, constraints, and dependencies have been verified. They freeze into the implementation baseline.

2. Node-by-node "materialization." AI agents claim nodes and replace virtual implementations with real ones — real databases, real algorithms, real third-party calls. The external interface does not change by a single byte.

3. Massive parallelism. Because contracts are frozen, nodes are naturally decoupled: ten agents can materialize ten nodes simultaneously without blocking each other. One node not materialized yet? Fine — its virtual version still holds the line inside the system, which stays runnable at all times. This is hardware's mixed simulation: real and virtual modules coexist, replaced incrementally.

4. Simulation scenarios become the tests. Every scenario and dataset accumulated during simulation converts automatically into integration and regression tests. A real implementation must produce the same results under the same scenarios before it may be marked verified. Tests are not written after implementation — they exist before it, as the acceptance standard.

5. Agents read the tree, not the code. An agent picking up a task does not need to wade through hundreds of thousands of lines to guess design intent. It reads the project tree: current goal, node contract, dependencies, decision history, why it was designed this way. Code is merely this tree's projection at a moment in time.

9. Why this is the highest-efficiency path

Put the two processes side by side:

Traditional process:
  Documents (static, quickly stale) → Coding → Design errors surface at integration → Massive rework
  ─────────────── Errors surface at the most expensive stage ───────────────

AI-native process:
  Voice → Project tree → Virtual functions → Virtual system → Data-flow simulation → Contract freeze → Parallel materialization
  ──────── Errors surface where change cost ≈ 0 ────────   ──── Code right the first time ────

The efficiency advantage comes from four levers:

Errors shift left to the cheapest point. Decades of software engineering data point at one fact: the later a defect is found, the more it costs — from requirements stage to production, the difference can be a hundredfold. Simulation drags integration-level and architecture-level errors back to the stage where "tweaking the tree" fixes them.

Coding turns from exploration into execution. In traditional development, much coding is exploratory — you only learn whether the design works by writing it. After simulation passes, coding becomes execution of verified contracts, and that is precisely the kind of well-scoped, clear-boundary task AI agents are best at. Fast generation plus low rework is where the speed advantage actually cashes out.

Parallelism is guaranteed by the architecture. Contract-first makes nodes independently materializable; mixed running keeps the system demonstrable and runnable at every moment.

The cost of understanding approaches zero. Humans and all agents share one tree. A new member — human or agent — doesn't need "three months to learn the codebase"; reading the tree suffices. And requirements docs, interface docs, test docs are all generated from the tree — documentation is no longer where work begins, but what work outputs.

10. The complete flow, and the vision

Idea (Voice)
    ↓
AI understanding & structuring
    ↓
Dynamic project tree (tree-shaped knowledge base)
    ↓
Node → Virtual function (interface contract + AI-generated mock behavior)
    ↓
Wire along the tree → Virtual system (the system's digital twin)
    ↓
Data-flow simulation (all end-to-end scenarios pass)
    ↓
Human sign-off, contract freeze
    ↓
Agents materialize in parallel (virtual → real, node by node)
    ↓
Simulation scenarios → automated tests → automated deployment

In this paradigm, the developer's center of gravity shifts completely:

Humans: generate ideas, make decisions, scrutinize the design inside the simulation, confirm direction
AI: captures thought, maintains the project tree, generates virtual functions, runs simulations, materializes code, verifies results

Software development stops being "writing code" and becomes cultivating a continuously growing digital model of the project. The dynamic project tree is not merely a requirements tool — it is the project's digital organism. Code, docs, tests, interfaces are just the forms it automatically takes at different stages.

The chip industry spent thirty years proving one thing: making the system run in the virtual world first is the fastest road to the physical one.

It's time the software industry caught up on that lesson.

Code is Output. Model is Truth. Voice is the Beginning. Simulation is the Proof.

This is a v0.2 draft — discussion welcome.

AI Native 软件工程：先让系统「虚拟地跑起来」，再写第一行代码

核心思想：未来的软件开发，不以文档为中心，也不以代码为中心，而是以一棵动态项目树（Dynamic Project Tree）为中心。语音录入想法，长成树形知识库；每个节点先实现为虚拟功能；虚拟功能沿着树连接成一个虚拟系统；在虚拟系统上完成数据流仿真；仿真全部跑通之后，才开始真实的编程。
Code is Output. Model is Truth. Voice is the Beginning. Simulation is the Proof.

📖 English version above — scroll up for the English translation.

一、AI 写代码越来越快，软件却没有变快

目前主流的 AI 编程工具——Copilot、Codex、Claude Code——本质上都嵌在一条几十年前设计的流水线里：

需求 → 文档 → 原型 → 开发 → 测试 → 部署

这条流水线诞生于没有 AI 的时代。AI 只是被插进了「开发」这一环，让写代码这一步变快了。

但任何做过真实项目的工程师都知道，写代码从来不是最慢的环节。真正消耗时间的是：

需求在前期反复变化，代码写完才发现理解错了
架构调整牵一发动全身，改动成本随进度指数上升
文档永远落后于代码，没人相信文档
多个 AI Agent 各自读代码，对项目没有统一理解
关键的设计思路散落在会议、聊天记录和某个人的脑子里

把「写代码」这一步加速十倍，对上面这些问题的帮助是零。错误依然要等到集成、联调、上线才暴露，而那时修复成本已经涨了几个数量级。

所以真正值得重构的不是 AI，而是整个软件工程流程本身。

二、硬件行业早就给出了答案：没有人不经仿真就流片

芯片行业有一条铁律：流片之前，必须仿真。

一次流片动辄数百万美元、数月周期，没有任何团队敢把没有仿真验证过的设计直接送去工厂。所以 EDA 工具链的核心从来不是「画电路更快」，而是：先在虚拟环境里把整个芯片跑起来——时序、功耗、信号完整性，全部在虚拟世界里验证通过，才进入物理世界。

再看软件行业：我们几乎是裸奔着直接「流片」。

需求文档写完（甚至没写完），就开始写真实代码，然后靠联调和测试在「物理世界」里撞出所有设计错误。我们容忍这种做法，只是因为软件的「重新流片」成本看起来低——改代码就好了嘛。但在 AI 时代，当 Agent 可以一夜之间生成数万行代码时，返工的成本恰恰被放大了：方向错了，生成得越快，浪费得越多。

AI 时代的软件工程，应该向硬件工程收敛：

先构建虚拟系统 → 完成仿真验证 → 再进行真实实现。

这就是本文要展开的完整流程。

三、语音是第一输入：思维采集，而不是打字提速

流程的起点不是文档，而是说话。

人的想法不是线性的，灵感往往在一瞬间产生：走路时想到一个功能点、洗澡时意识到两个模块的依赖关系反了。如果此刻需要打开 Word、回忆模板、组织措辞，思路早就断了。

语音的价值不在于输入速度，而在于：

它能以最低的摩擦，捕捉思考过程中的真实想法。

Voice = Thought Capture（思维采集）

未来的开发起点是这样的：

想到一个想法
    ↓
直接说出来（Voice）
    ↓
AI 理解、结构化
    ↓
自动挂载 / 更新到项目树

你说：「分享功能要支持二维码，而且要能设置有效期。」AI 听懂后，在项目树的 分享 节点下新建 二维码 子节点，并在其属性里记录「支持有效期」这条约束——同时记下你是在什么上下文里说这句话的。三个月后没有人需要考古聊天记录，决策的来龙去脉就长在树上。

四、树形知识库：动态项目树

为什么是树？因为人对项目的心智模型天然就是一棵树：

Project
├── 用户
│     ├── 登录
│     ├── 权限
│     └── Profile
├── 分享
│     ├── 二维码
│     ├── 链接
│     └── 权限控制
├── AI 能力
│     ├── 海报生成
│     ├── OCR
│     └── 文案
└── 数据
      ├── 数据库
      ├── API
      └── Cache

想法不断长出新节点、调整节点关系、剪掉废弃分支。项目的真相不该保存在一份很快过时的 Word 文档里，而应该是这棵活着的树。

和传统需求文档的本质区别在于：树上的每个节点不是一段自然语言描述，而是一个结构化的数据对象：

node: 分享/二维码
description: 为分享内容生成带有效期的二维码
status: simulated        # idea → defined → simulated → implemented → verified
owner: harry
depends_on: [用户/权限, 数据/API]
interface:
  input:  { content_id: string, ttl_hours: int }
  output: { qr_url: string, expires_at: datetime }
constraints:
  - 有效期最长 72 小时
  - 过期后访问返回 410
history:
  - 2026-07-12: 由语音输入创建，「分享要支持二维码」
  - 2026-07-14: 增加有效期约束（讨论后决策）

节点带着描述、状态、负责人、依赖、接口契约、约束条件和演化历史。整棵树就是一张持续生长的项目知识图谱——它是需求库，是架构图，是接口文档，也是决策日志。它是项目唯一的真相来源（Single Source of Truth）。

五、关键一步：每个节点先做成「虚拟功能」

这是整个方法论的核心，也是与「用 AI 写需求文档」最大的分野。

树上的功能节点，不能只停留在「一段描述」。当一个节点的定义基本清晰后，AI 立刻把它升级为一个虚拟功能（Virtual Function）：

有真实的接口：输入输出 schema 是严格定义的，就是将来真实实现要遵守的契约
有虚拟的实现：内部不写真实逻辑，由 AI 根据节点描述生成一个「行为逼真」的 mock——收到合法输入返回符合业务语义的模拟输出，收到非法输入按约束报错
可以被调用：它是一个真正能跑的函数/服务桩，而不是文档里的一个方框

比如 二维码 节点的虚拟功能：输入 {content_id: "abc", ttl_hours: 100}，它会返回错误「有效期最长 72 小时」——因为约束就写在节点上。输入合法参数，它返回一个结构正确的模拟 qr_url。

没有一行真实业务代码，但这个功能已经「存在」了。

工程师对这个东西并不陌生——它像 mock，像 stub，像契约测试里的 provider stub。区别在于：传统 mock 是为已有代码写测试时的附属品，是手工维护、随手即弃的；而这里的虚拟功能是先于代码存在的一等公民，由 AI 从节点定义自动生成、随节点定义自动更新，并且——下一节会讲到——它们要被连接起来，组成一个完整的系统。

六、沿着树，把虚拟功能连接成一个虚拟系统

单个虚拟功能只是一个可调用的桩。真正的威力在于：树上的依赖关系，就是系统的接线图。

每个节点都声明了 depends_on 和接口契约，AI 就可以沿着这些边，把所有虚拟功能组装起来：

[语音/文本] ──> 动态项目树 ──> 虚拟功能 ──连接──> 虚拟系统
                                              │
   用户/登录（虚拟）──> 用户/权限（虚拟）──> 分享/权限控制（虚拟）
                                              │
   分享/二维码（虚拟）<── 数据/API（虚拟）<── 数据/数据库（虚拟）

这时你得到的，是一个没有任何真实代码、但整体可以运行的系统：

每个模块都能被调用，行为符合各自节点的定义
模块之间按照树上声明的依赖真实地互相调用
整个调用拓扑，就是未来真实系统的架构

它相当于整个软件系统的数字孪生（Digital Twin）——只不过孪生体先于本体出生。

在这一步，大量传统上要到联调阶段才暴露的问题会立刻现形：两个节点的接口对不上、依赖成环、某个模块假设的数据字段上游根本不产生。修复方式不是改代码，而是改树——调整节点定义，虚拟功能自动重新生成，系统重新连接。改动成本几乎为零。

七、数据流动仿真：在虚拟系统上「过日子」

虚拟系统搭好后，进入验证环节：数据流动仿真（Data Flow Simulation）。

AI 根据项目树生成仿真场景——本质上是一批端到端的用户旅程，配上批量模拟数据：

场景 1: 新用户注册 → 登录 → 创建内容 → 生成二维码分享 → 他人扫码访问
场景 2: 二维码过期后访问 → 应返回 410
场景 3: 无权限用户尝试访问受控分享 → 应被拦截
场景 4: 1000 个并发分享请求 → 观察数据在 API/Cache/DB 间的流动

模拟数据从系统入口注入，沿着虚拟系统真实地流动。你在图上直观地看到数据怎么走：从登录节点流向权限节点，从 API 节点流向缓存节点；哪里断流了，哪里数据被丢弃了，哪条路径根本没人走到，哪个节点成为所有路径的汇聚点。

仿真阶段要回答的问题，恰恰是传统流程里最晚、最贵才能回答的问题：

业务闭环成立吗？ 用户旅程能从头走到尾吗？
数据完备吗？ 下游要用的字段，上游真的都产生了吗？
权限模型有漏洞吗？ 有没有一条路径绕过了权限节点？
架构合理吗？ 依赖方向是否清晰，有没有意外的耦合和瓶颈节点？
异常路径想过吗？ 过期、失败、越权，每条错误路径都有归宿吗？

发现问题 → 修改树 → 虚拟功能自动更新 → 重新仿真。这个循环以分钟为单位，而不是以「一个迭代」为单位。产品经理和工程师看着同一张会流动的图讨论，而不是各自拿着两份互相矛盾的文档。

当所有仿真场景全部通过时，你验证的不是代码，而是设计本身。

八、仿真通过，才开始真实编程

到这一步，真实编程才开始。而此时的「编程」，已经和传统意义完全不同：

1. 契约冻结。 仿真通过意味着所有节点的接口契约、约束、依赖关系已被验证。它们被冻结为实现基线。

2. 逐节点「实化」。 AI Agent 领取节点，把虚拟实现替换为真实实现——真实的数据库、真实的算法、真实的第三方调用。对外接口一个字节都不变。

3. 大规模并行。 因为契约已冻结，节点之间天然解耦：十个 Agent 可以同时实化十个节点，互不阻塞。一个节点还没实化完？没关系，它的虚拟版本仍在系统里顶着，整个系统始终可运行。这就是硬件仿真里的混合仿真——真实模块和虚拟模块共存，逐步替换。

4. 仿真场景直接变成测试。 仿真阶段积累的全部场景和数据，自动转化为集成测试和回归测试用例。真实实现必须在同样的场景下跑出同样的结果，才允许标记为 verified。测试不是实现后补写的，而是实现前就已存在的验收标准。

5. Agent 读树，不读代码。 Agent 接到任务时，不需要通读几十万行代码去猜设计意图。它读取项目树：当前目标、节点契约、依赖关系、历史决策、为什么这样设计。代码只是这棵树在某个时刻的投影。

九、为什么说这是效率最高的路径

把两条流程放在一起看：

传统流程:
  文档（静态、易过时）→ 编码 → 联调时发现设计错误 → 大规模返工
  ────────────────── 错误暴露在最贵的阶段 ──────────────────

AI Native 流程:
  语音 → 项目树 → 虚拟功能 → 虚拟系统 → 数据流仿真 → 契约冻结 → 并行实化
  ──────── 错误暴露在改动成本≈0的阶段 ────────   ──── 编码一次成型 ────

效率优势来自四个杠杆：

错误左移到成本最低点。 软件工程数十年的数据都指向同一个事实：缺陷发现得越晚，修复成本越高，从需求阶段到上线阶段可能相差百倍。仿真把集成级、架构级的错误全部拉到「改一改树」就能修复的阶段消化掉。

编码从探索变成执行。 传统开发中大量编码是探索性的——写了才知道设计行不行。仿真通过后，编码变成对已验证契约的执行，AI Agent 最擅长的恰恰是这种目标明确、边界清晰的任务。生成快、返工少，速度优势才真正兑现。

并行度由架构保证。 契约先行让节点天然可并行实化，混合运行让系统在任何时刻都保持可运行、可演示。

理解成本趋近于零。 人和所有 Agent 共享同一棵树。新成员（无论人还是 Agent）不需要「熟悉代码库三个月」，读树即可。而需求文档、接口文档、测试文档，全部从树上自动生成——文档不再是工作的开始，而是工作的输出。

十、完整流程与愿景

想法（Voice）
    ↓
AI 理解、结构化
    ↓
动态项目树（树形知识库）
    ↓
节点 → 虚拟功能（接口契约 + AI 生成的 mock 行为）
    ↓
沿树连接 → 虚拟系统（系统的数字孪生）
    ↓
数据流动仿真（端到端场景全部跑通）
    ↓
人工确认、契约冻结
    ↓
Agent 并行实化（虚拟 → 真实，逐节点替换）
    ↓
仿真场景 → 自动化测试 → 自动部署

在这个范式里，开发者的工作重心彻底改变：

人负责：产生想法、做决策、在仿真中审视设计、确认方向
AI 负责：采集思维、维护项目树、生成虚拟功能、执行仿真、实化代码、验证结果

软件开发不再是「写代码」，而是培育一个持续成长的数字项目模型。这棵动态项目树不只是需求管理工具，它是整个项目的数字生命体——代码、文档、测试、接口，都只是它在不同阶段自动生成的表现形式。

芯片行业用了三十年时间证明：先在虚拟世界里把系统跑通，是通往物理世界最快的路。

软件行业，是时候补上这一课了。