宣言原文与修订记录

• 作者 — Limin Ge
• 初稿 — 2025 年 3 月
• 修订 — 2025 年 5 月 · 2025 年 12 月 · 2026 年 5 月

AI-Native 的软件工程：2025 年的 11 条真相

1. 一切诞生了超过 3 年的知识体系、方法论、技术栈，都应该被淘汰。
2. 你的代码库、文档库、会议纪要、会议录音、团队的记忆、直觉都不是项目真正可依赖的核心资产，唯一可依赖的核心资产有且只有你的测试案例库。（详见Test–Code 循环：为什么测试代码比功能代码更重要）
3. 理解 AI 的关键在于理解无状态性。（详见AI 的无状态性与 Context Window）
4. 我们可以容忍 AI 犯错误，只要它不会在下一次模型迭代前杀死我们。（与调试深水区和 Human-in-the-loop 相关，详见Debugging：在深水区和 AI 一起查 bug）
5. 软件的复杂度需要从垂直转为水平。
6. AI 的 context window 的上限，将是新时代程序员最需要关心的资源。（详见AI 的无状态性与 Context Window）
7. Plan–Act、Test–Code、Doc–Code–Doc 是新工程时代的工程循环。（详见AI-Native 工作流：Plan–Act、Test–Code、Doc–Code–Doc）
8. 代码的未来不是复用和抽象，而是海量彼此独立、足够小、AI 可直接理解的单元。
9. AI 不能解决所有问题，AI 不能解决第一公里和最后一公里的问题，这本质上是人的问题。
10. AI 生成的 Artifact 是一种新的模态。
11. AI IDE 或 AI Agent 卖的是 Context 选择的能力。（详见工具与 Context 选择：为什么 AI IDE 卖的是"上下文选择能力"）

扩展章节：AI-Native 工程实践

以下章节对上文中的若干“真相”做了更系统、更工程化的展开，采用了访谈与实战记录中的原始表述，尽量保留了第一手语感：

• AI 的无状态性与 Context Window（对应真相 3、6）
• Test–Code 循环：为什么测试代码比功能代码更重要（对应真相 2、7）
• Debugging：在深水区和 AI 一起查 bug（对应真相 4、9）
• 工具与 Context 选择：为什么 AI IDE 卖的是"上下文选择能力"（对应真相 6、11）
• AI-Native 工作流：Plan–Act、Test–Code、Doc–Code–Doc（对应真相 2、3、7、9）
• 从垂直复杂度到水平复杂度（对应真相 5、8）
• Human-in-the-loop 与新人培养（对应真相 4、9）
• 为 AI 选择兼容的技术栈（对应真相 1、12）
• AI Coding 的五个等级与 User Story Driven 终局（对应真相 7）
• AI-Native 小团队的结构性优势（对应真相 8）
• Convention 与开发规范——让 AI 带着镣铐跳舞（对应 Dec 2025 修订第 5 条）
• Token 作为项目规模的量化指标（对应 May 2025 修订第 5 条）
• 会议录音→PRD→TDD→代码——AI-Native 团队的知识工作流（对应 May 2025 修订第 2、3 条）
• SSOT 是软件工程的根原则（连接真相 2、3、7、11）
• SSOT 九层金字塔模型（连接真相 2、3、7、11）

March 2025

1. 一切诞生了超过 3 年的知识体系、方法论、技术栈，都应该被淘汰。

2. Plan–Act 循环。

3. Test–Code 循环。

   1. AI Coding 的时代下，测试会变得特别重要，后端的测试相对简单，网页端甚至移动端会难许多，很难端到端测试，尤其是移动端。

4. Doc–Code–Doc 循环。

5. AI 的 context window 的上限，将是新时代程序员最需要关心的资源。

6. 文档化，帮助大模型做记忆的 cache。

   1. 全量 / 快照式的文档优于增量式的文档。
   2. AI IDE 的能力上限就是它的 context window 的上限，其实人类也是，人类的 context window 也是有上限的。那么人类是如何 handle 复杂系统的呢？回想一下大厂是如何协作的就能明白。我们与 AI 的协作，应该模拟大厂间不同职能、不同团队的协作。

7. Vibe Coding 只描绘了一个非常初级的 coding 阶段，终局应该是 user story 驱动的开发。现在许多用户将 Cursor 作为一个简单地辅助完成需求的工具，其实这之后还有好几个等级。反应到思维上，初级阶段程序员还是人的思维，中级阶段里程序员是机器的思维，高级阶段里要更进一步地升级为机器的管理者的思维。等级如下：

   1. 不熟练的 AI Coding 使用者，使用中文，漫无目的，想到什么做什么，Vibe Coding
   2. 熟练的 AI Coding 使用者，意识到要用英文，意识到 context window 有限，意识到 Cursor 并不会读你的文件的全文
   3. 将自己的流程固化下来的使用者，快速应用 cursor rules
   4. Issue Tracker，应用 MCP，以一个 issue 或一个需求为中心，模拟一个团队的完整的协作流程
   5. User Story Driven，整个系统彻底转型为 AI-Native 的级别，AI 能够异步、多线程地工作，同时有 100 个 user story 同步开发

8. 人类能够将基建搭得有多好多适配 AI 的需要，那么 AI 就能把自己的能力释放得有多好。对于 existing system 来说，这是一个挑战。

9. 除了 AI IDE 之外，AI 带来的生产力的革新还涉及方方面面，比如说绘制流程图、撰写 PRD、PRD 转 TDD、堆栈分析、端到端测试、等等等等。软件工程的任何侧面都应该有一个新时代下的 AI 替代品，我从 YC 上就爬过一个列表（这个列表本身也是一个 AI Agent 帮助我爬的）。

10. 以往我们会讲究复用抽象等，但是 AI 没有能力理解那么长的上下文，以往我们可能有精心创作的 500 个函数，相互复用抽象隔离，新时代我们可能会写 5000 个 scope 非常小的相互无关的函数，每一个的 scope 都在 AI 的 context window 之内。（待验证）

11. AI 不能解决所有问题，AI 不能解决第一公里和最后一公里的问题，即设计方案和最终写对每一行代码，但这本质上不是 AI 的问题，这本质上是人的问题，人类和 AI 的关系是审阅者和执行者的关系，但人无法评估自己都不了解的事物。对于一个 existing 的系统，人自己首先要理解里面的方方面面，之后才能评估 AI 出的方案的好坏。Human in the loop 是绝对不可避免的。

12. 过于新的技术堆栈，AI 没有能力掌握，因为训练数据过少，例如 Deno，但如果是成熟的如 Next.js，AI 可以很快地吐出正确的代码。兼容性这个词有了新的涵义。

13. Prompt 一定要写得详细，能够引用的对象就要提供引用，因为不然 Cursor 使用的是 RAG 的形式去查找的，准确率特别差。未来 Cursor 应该能够要能对符号建立索引才行。现在的大部分 AI 是非常 neutral，非常中立的，我们需要让它变得足够 opinionated，并且这个 opinion 是完全个性化的，完全服务于某个开发者 / 团队本身的。

14. 四十年前的编程范式，目标是让机器读懂，二十年前是让人读懂，今天我们应该让 AI 读懂。AI 能读懂什么文本是有规律的，但我们也不应该过分地 finetune 我们的 prompt 以至于 overfitting，因为 AI 本身能力也在演进，例如 CoT 的诞生、DeepSeek 的 opinionated 的属性，这使得许多 prompt engineering 的技巧迅速落伍，所以这是一个永恒的话题。

May 2025 修订

1. 从商业模式的角度，AI IDE 就不可能提供 LLM web 端能提供的服务水平，站在使用者的角度，最好的服务来自于 API 调用或者 Web 端。

2. 一些曾经更激进的想象，我们有钱有人力后，可以开始试验：将所有的会议录制→生成字幕→生成 PRD→生成 TDD→生成 code draft。可以使用 browser use 做中介，转发内部的所有知识（包括代码库）到 Gemini Web。以此提升团队内部所有工作的生产力。结合新的 Flowith、Manus 等工具。这个内部的工作平台将成为每一个岗位，每一个成员的主要工作平台。作为新团队，我们没有那么多的历史债务，可以快速地收集所有的知识到这里。

3. 另一个用例：使用通用 MCP，集成 Manus、Flowith 等工具，如运营需要生产 100 个场景内容，Agent 自动完成这个任务，人肉确认通过后，就可以导入我们平台。这个 Agent 将成为全团队浏览器的首页，是所有工作的入口和起始点。

4. 对于有一定历史积淀的团队来说，Context 的窗口是无论如何都不够用的，此时的关键就来到了 Context 的择优，也就是所有的 AI IDE 团队，所有的 AI Agent 团队最核心的工作内容。

5. Token 是一个可以对一个项目所含信息量进行量化的一个指标，一个项目沉淀的所有资产转换为 token 的数量就是对这个项目规模的衡量。目前我们正好在 1M Token 左右，在 10M Token 之内，这个方案都会一直带来至少 3 倍的生产力提升。

6. AI IDE 或 AI Agent 卖的是两个：一个是 Context 选择的能力，一个是最佳实践通用化的能力。

7. 由 AI IDE 创造的 artifact 是一种新的模态，它的意义就像人们第一次可以在网上发帖，传图片，传音频视频一样，面向普通人群的 AI IDE 应该打通到部署的最后一英里。

8. AI IDE 的 codebase index 应该是 AST，符号级别的。

Dec 2025 修订

1. 如何解决 LLM 引入的 bug：

   1. 将我们工作的重心从管理功能代码，转移成管理测试代码，只要我有足够海量的测试案例，我能够确保这些情况下最终的结果是正确的，我们就能够减少管理功能代码过程中的负担。
   2. 我们可以容忍 AI 犯错，只要这个错误不会在 3 个月内杀死我们即可，因为 3 个月后模型能力将会进一步迭代，将会解决曾经我们无法解决的问题。
   3. 但是，一个先进的 AI 团队，一定会始终顶着 AI 模型能力的上限去使用 AI，并且会非常快地达到每一个 AI 的能力上限，这个团队的大多数时候仍会处在 AI 无法解决我们问题的煎熬中。

2. 我们应该将软件的复杂度从垂直转为水平——仍然是过去的 2025.3 时提出的思路 10 的延伸，即通过增加链路的多样性，来实现链路的深度降低。一个非常深入的链路 AI 很难 debug，但 AI 可以处理两条非常相近的链路，只要这两条链路相互独立即可。

3. shad-expo-studio 是一个降低垂直复杂度的尝试，即将前端展示层和功能层的功能彻底隔离，并且通过 Storybook 强制的回归测试来确保展示层不漂变。

4. 你的代码库、文档库、会议纪要、会议录音、团队的记忆、直觉都不是项目真正可依赖的核心资产，唯一可依赖的核心资产有且只有你的测试案例库，story-ops 是一个更深入的探索，其愿景是 user story = PRD = E2E test cases。

5. Convention、开发规范的重要性，对于 AI-Native 团队的重要性，只会更高，因为它们是延缓熵增最好的手段。项目起步时一定要尽可能地设计好尽可能多地束缚。让 AI 带着镣铐跳舞。

6. 如果 AI 一次工作的 context 和能力有上限，就需要让 AI 接力在某件事情上工作。最好的 benchmark 方式就是检验一个非常难以处理的 bug，究竟是否可以通过这种方式解决。接力的方式就是在一个 AI 能力即将下滑的阶段，让它把本次尽可能多的 context 持久化，后续的 AI 在此基础上进一步工作，就像人类一样，总是站在巨人的肩膀上学习，而不会重新发明轮子，否则人类的科技只会锁死。

7. 理解 AI 的关键在于理解无状态性，代码库应该抛弃所有的过程性、历史性信息，让任何一个读者（你的每一个 AI session）都不用去理解任何历史上下文。

May 2026 修订

1. SSOT 是软件工程的根原则。2026 年 5 月写的两篇 SSOT 文章里，我把 DRY、KISS、SOLID、领域建模、测试、可观测性、CICD、文档治理一路往下归并，发现它们最后都在谈同一件事：每个重要事实都得有一个权威位置、一个 owner，外加一条 evidence 路径。复杂软件缺的从来不是更多内容，而是“哪个内容算数”。

   • 完整章节：SSOT 是软件工程的根原则

2. AI-Native 团队比传统团队更快发生事实分裂。AI agent 会高频产出架构说明、代码、测试、日志、会议总结、发布说明、营销文案、任务报告。没有 SSOT，这些 artifact 很快就变成一堆彼此打架的历史快照。AI agent 会继续保护 legacy 路径，把 POC 包装成承诺，或者把几个历史阶段的“当前优先级”揉成一个看着合理、实际错误的计划。

3. SSOT 不只是研发内部的文档习惯。产品、运营、销售、客服/支持、发布 operator、AI agent，跟研发用的是同一套事实模型。产品要看当前战略，运营要看真实 workflow，销售要看承诺边界，客服/支持要看日志、evidence 和修复路径，研发则要判断一次代码改动会不会动到 contract、边界、领域模型、Flow、承诺或战略。

4. SSOT 九层金字塔模型是让事实保持最新的那套结构。金字塔强制自顶向下读：使命、战略、承诺、Flow、领域模型、系统边界、contract、实现、evidence。它也强制自底向上更新：先动实现和 evidence，等语义真的变了，再往上提升到 contract、边界、领域、Flow、承诺、战略和使命。

   • 完整章节：SSOT 九层金字塔模型

5. 每一个具体故障都得映射回九层模型。文章里举的例子：旧 README 误导 AI agent，POC 被写进 BP，skill 升级成 workflow 但命名没改，内部 API 悄悄变成 contract，测试入口膨胀，日志和错误文案停留在旧概念，迁移计划完成后仍留在 current-work，临时 adapter / fallback 变成了事实来源。解决办法不是“多沟通”，而是每次都回答三个问题：该更新哪一层，那一层里哪类事实变了，有什么 evidence 能证明变更已经完成。

6. Evidence 得跟着产品重心一起迁移。一片绿的 legacy 测试，可能只证明了昨天的主线，今天真正要发布的那条路径却根本没被证明过。测试、日志、状态命令、release evidence、provider 检查、线上事实，都要跟着当前的产品承诺和 Flow 走。不然 CICD 一片绿，真实产品照样不安全。

License

本宣言的正文（本记录与全部章节）以 CC BY 4.0 授权——注明出处即可自由转载、翻译、改编。正文中内嵌的代码片段为 MIT 授权。