2025无疑是AI编程大放异彩的一年，因为它为我们带来了前所未有的效率和创新，也带来了更多的麻烦和挑战。 让人欢喜让人忧。一面是强大的开发能力让人爱不释手，另一面则是不按预期推进的不受控的愤怒。尤其是后期迭代更是石山堆积。 氛围编程(vibe coding)几乎是作为一个空想被提了出来，但过于美丽以至于很多人深迷其中。 虽然随后大家基本聚集到规格驱动开发上来，但仍是各自在做努力的尝试，没能产生一个能一统江湖的框架或是模型出来。
相关的氛围编程和规格驱动开发可以参考以下文章：
AI编码时代需求文档 1怎么写
AI编程正在”腐烂”，而解决方案在40年前就存在了 - Unix管道哲学如何拯救AI编程困境
除了上面的观点外，也有一些人推荐重回瀑布式开发。瀑布式开发之前面临很大的困难在于他的规范性设计性等等门槛极高。但是配合AI，确实可以有效的降低门槛，提高开发效率。
这些都是很好的实践心得。 包括各个编程助手，也都在以各种方式尝试改进开发的效率和质量。 提出了一些如技能，角色 2等的很好的思路。
然而，截止目前为止（20260113），所有的编程助手的尝试，包括规格驱动开发的机制，都没有很好很彻底的解决AI编程的根本性问题： 初期很美，后期很烂。
为此， reddish(srs.pub)提出一种全新的开发思想，以知识为核心，以需求为根本，彻底解决AI编程的可持续迭代问题。
1 以知识为核心的开发思想
首先必须明确的一点就是所谓的氛围编程(vibe coding)， 就是一个不切实际的空想。要让AI编程真正发挥作用，必须要以知识为核心，以需求为根本。 而不是以 vibe coding 为中心, 以感觉为中心。
因此也可以说是，以知识为核心，就是反氛围编程。 氛围编程吹嘘的一句话就能实现一个产品，以知识为核心就是完全的反过来，你必须构建完整的产品知识，才能实现一个产品； 氛围编程强调感觉，低门槛；以知识为核心则强调规范，严谨。氛围编程强调普通人都能编程，以知识为核心则强调你必须成长为一个合格的产品经理，架构师，分析师。
普通人仍有机会使用AI编程完成一个产品开发，但前提是你不能一直是普通人、门外汉，你必须在这个过程中成长起来，成为能掌控你的产品的专业人员。 否则指望小白能指导出一个好的产品，那就是纯笑话了。
由此引出，以知识为核心的开发思想的三个核心要素：
- 成长。
- 知识。
- AI。
这三个核心要素中包含了AI编程，因此以知识为核心的开发思想， 并不会取代目前的任何开发模式或是规范。 不管你是瀑布式开发，还是敏捷。 也不管你是规格驱动开发，还是测试驱动开发。也不管你是一个研发团队，还是一个独立开发者。 以知识为核心的开发思想， 都可以完美的搭配使用，并发挥强大的作用。
下面单独来介绍这三个核心要素。
1.1 成长
所有的产品，最初都起源于一个模糊的念头。 软件工程的标准过程，就是将这个模糊的念头，不断的深入细化，不断的寻求最具可行性的方案，最终形成基础的需求规格，然后通过产品设计，从原型到最终的产物，到迭代测试，到发布部署上线。
在这个过程中，产品的主导者，必然也要经历过模糊阶段，逐渐清晰，最终设计定稿，研发出产品的过程。 如果产品的主导者，始终停留在模糊阶段，那么这个产品实质上就不可能是个成熟的产物。
这个过程就如同房屋装修，大部分一生中都可能会经历一次房屋装修过程，但是可惜的是，很多人往往只有一次经历的机会。 但不论如何，在一开始装修时，肯定都是不专业的，想法众多的。但是装修完之后，每个人的思路都是确定的，并且是装修知识丰富的。一开始门窗地板肯定是一大堆概念蒙圈的，结束后肯定是什么断桥铝，三层五层的剥离，镀膜剥离，地板还是瓷砖的差异等等，各种技术细节都了然于心，完全能跟一个专业的装修公司大聊特聊。 这就是成长的过程。
当然也不排除有个别人到了装修结束，仍搞不清楚这些细节的。那说实话，装修后果能有多和心意，就难说的狠了。
产品的主导人是类似的，你可以不大懂，一开始也必然是模糊的。 但你必然要随着产品的发展而不断的接收新知识，调整你的思路，更新你的设计，完善产品的细节。
如果拒接这个过程，你的产品就会停留在模糊阶段，顶多就是个PPT。
这似乎是比较顺其自然的事情，但是这里要特地强调，主要就是为了纠偏氛围编程的宣传造成的太虚幻境。 你不可能靠着AI给你的虚幻，完成真正有意义的事情。 认真这个基本的事实，是驾驭好AI编程的基础。
1.2 知识
以知识为核心，是本编程思想的重点。 同时，这也是完全反氛围编程的。不要做任何试图一句话让AI给你干好活的任何期望。
AI编程的首要的任务，不是编程，不是完成一个产品。而是要先构建完整的产品知识。
任何时候对AI编程下达编程指令前，首先要做的是“先给出完善的设计文档，等我评审 3后，再开始编程”。
AI编写的代码，大部分是不会细看的，对于非程序员来说，看代码还比较困难。 所以，代码这一部分，是要靠AI但不能信任的。
要靠AI干活又不能信任AI。解决办法有两个。一个是事前制定完善的设计规范；另一个就是事后的不停的审查，测试，评估，返工。
根据OpenAI的一篇访谈 4，目前重度使用AI编程的公司，已经是80%的精力都放在AI编码后的审查、测试、纠正上了。
当然，事后做这个事情是比较简单直接的，AI编码跑一遍，然后试试对不对，不对再反馈给AI修正。这个过程大部分都会。 但是因为这个是事后的，所以他也是效率比较低的。
而事前的设计规范，则能从很大程度上避免AI的偏差，极大程度上控制AI的腐烂速度，保证产生的代码质量。
只是从本能上来说，事后纠偏是简单直接的，事前的规范设计，则是比较费脑的。
但是，这里并没有拒绝AI的参与。 也就是说，事前的设计，也可以由AI来完成。 这样子实现完善的设计的门槛就低了很多。 只不过跟AI编程不一样，设计文档，必须人工逐字逐句的审核修订。 这样子才能形成真正的知识。
这里的产品知识，包括产品愿景，产品章程，需求规格说明，解决方案设计，产品设计文档，设计规范等等。
这些文档比较专业和繁琐，但是借助于AI，所以也不是大问题。只是产品主导者必须要有这些基本意识，能让AI来生成这些对应的文档。并且能审核和修正这些文档。这样才能形成有效的产品知识。
需要再次强调的是，这里的文档（本系统里统称为产品知识），可以由AI生成但必须人工逐字逐句确认的。 尤其需要注意的是，AI可以产生大量的貌似相关，看起来也很厉害的建议，功能描述。需要产品主导者严守自己的初心，剔除大量镀金的描述。 这也是一个产品经理的基础修养。
1.3 AI
最后就简单了，让AI来辅助生成文档，生成代码。校验文档，审核代码等等。 这个就是目前所有的AI都能做的事情了。
其中AI生成的文档，人工逐字逐句审核，修正。生成的代码，则用目前大家已经在做的事后测试，评估，返工等机制就行。
2 迭代仍是基本操作
注意，如果仅仅是强调先写文档再来编程，那么跟瀑布式开发没什么区别。也跟规格驱动开发区别不大。 但是这里强调的是可迭代的开发过程。 解决的也是AI编程无法有效迭代的一个根本点。
你依然以一个模糊的产品思路为起点。 不同的是，你先让AI给出产品文档。 在这个过程中，你可以结合AI的文档，来提炼自己的思路，或是学习自己之前没接触到的知识点。
一开始的迭代，肯定是关于产品知识的迭代。反复的打磨你的产品愿景，产品章程，需求分析，方案设计。 直到你认为已经基本完整了。 才开始进入编码阶段。
在这轮的迭代过程中，你的知识成长是随着产品知识的丰富不断进步的。
在进入编码阶段后，依然要注意的是，所有修正依然遵循产品知识为核心的基本要求。
也就是说，AI编码完，事后人工校验检查过程中，任何新的修正，只要不是明确的bug级别的，都要首先回顾到产品文档上来。
因此，这一轮的每一次迭代，都以下面的方式进行： 审核当前的代码是否符合产品文档的设计；需要修正的部分是否和产品文档冲突；先完成目前的文档修正，等我确认后再开始调整代码。
这样子，首先是解决AI编程的腐烂问题，每次的修正、调整，都严格的先有规格文档再动代码。其次就是在这个过程中，不断的丰富和完成产品知识。
3 产品完工
当我们按照上面的步骤开发完一款产品，我们获得什么？
首先是我们自己作为产品主导者，学习了解了产品的所有知识。 包括各种细节。 这也能保证我们能够在产品宣讲、演示、营销时，能够胸有成竹的展示产品的价值。
其次我们获得了一个完善的产品知识体系， 包括最初的初衷愿景，包括需求的规格，包括设计的方案，包括技术架构的明确定义，等等。 这些详尽的产品不仅能保证我们在后续的产品迭代中，能够保持产品的质量。 还能够作为产品的基准，衍生出各种不同场景所需要的各种产物。 比如产品宣传手册，DM单，用户手册，部署文档，甚至官网，FAQ，营销文案等等。
正因为有一个非常精准且完善的产品知识， 产生的如营销文案，宣传手册等各种衍生品，都能准确的体现产品的价值。为将来的各种可能节省大量的时间和成本。
当然了，最后，我们获得了一个可持续迭代的产品。 不过他已经像是衍生品了。 因为根据我们的产品知识，我们总是可以用AI来重新编写代码来实现的，甚至是切换平台，切换架构，切换开发语言等。都不是大的问题。
核心还是产品知识！
最后呢，套一句俗语： 构建产品，我们将失去知识和产品。构建知识，我们将得到知识和产品,还有成长。