大部分人都是拿vibe coding当梗的，但我真把它当回事来用了。也真实感受到一些问题。这么多年的工作，沉没在浩如烟海的需求、bug、拉扯和重复造轮子，AI的出现，像在刺挠浮躁的芦苇荡中，突然隐约出现的一条小路，让我眼前一亮，诞生了仿佛第一次写css3时那种欣喜感。

相信经过一段时间高强度的AI使用的人，除了欣喜，都会隐约感受到一定程度的失望。当发现只要你给的context足够详细，他能胜任一切任务的时候，他似乎是无所不能的。失望的是，他似乎没我们想象的那么“聪明”。目前阶段的大模型的基础是问答模型，要对人类抛出的语句做回应，需要解决问题，不管是不是在问问题。

人类的“认知”是AI能力的下限

在深入讨论之前，我先抛出自己的一个看法，目前的AI编程，对操作者本身领域知识要求更高了。这一点，在我要求AI用测试驱动开发，并明显改善了输出结果的时候，就认识到，我们之前学到的所有软件开发和架构设计的最佳实践和方法论（公理设计、各种设计模式、TDD、DDD等），也同样适用于AI编程。并且这是一个学以致用的机会，如果由于各种机缘巧合，你在数年的编程生涯中，都对于TDD以及各种设计模式没有应用机会，没有具象的理解，那么就让AI帮你写例子，尤其是重写当前项目的某些功能，这会是个很好的开始。

话说回来，我的结论是，人的（工程）认知水平，决定了AI（编程）的质量下限。

未来有没有可能实现无人值守，让AI完成大型的软件/网站开发？答案是肯定的。但是要开发人类能理解的、稳定、统一且可维护扩展的软件，仍然是人类要保证的问题。

你可以告诉AI“我需要一个稳定，可以后期扩展的python爬虫项目”，他能理解，但是目前阶段，大概率会遇到前后回答不一致的问题，因为这个“稳定”、“可扩展”并不是一个精确的限定语，而只是笼统的描述。再比如说，AI会帮你做代码分层架构，但是后期的生成，可能用的不是一种分层，如果完全不懂，很容易造成代码混乱。

所以近阶段对于程序员的要求，要从完成代码能力，拔高到产品架构能力上了。而单纯的、机械重复的代码能力在弱化，如何提纲挈领，在高维度上掌握开发走向，变得重要起来。

另外一点，对于不排斥新技术的开发者来说（对比的是只倾向于某一个语言或框架），选用何种语言何种框架都没那么重要了。用python完成的某些GUI项目（为什么是某些呢？因为机器学习相关的确实不太行），让AI用对应框架的js重写一遍，也不是什么难事。

如何保证AI生成代码一致，确切的说，如何在多次对话中，保持一致的上下文，是我一直在思考的问题。为此我做了很多的尝试。

从“对话”到“约束”

阶段一：对话与失控

一开始，我就正常和AI对话，商量需求，确定系统流程、功能模块划分，接着确定系统细节。我生成了几个自认为比较有用的文件：系统描述.md，数据库.md，系统选型.md，测试方案.md。每个文件都有几百上千行，内容详细丰富。

每次新启动一个回话，然后把以上所有文件投喂给AI，接着开始描述开发任务（写prompt），然后让AI执行，要求每个阶段的任务可验证。

效果：一定程度上让AI理解了我想做什么，系统描述在一定程度上能规范他的行为。但是这个程度很低，还是经常乱写。 这种方式暴露了几个问题：

1. 代码不可控。某个项目使用的fastify框架，AI某个节点开始引入express，代码随即混乱。这种问题一旦开始，代码必定会扩大到不可控，不得不推翻重来。
2. 任务描述（prompt）的随意性。有时候我会因为经验惯性，描述不够精确严谨，例如我告诉AI：完成xx页面，要求有功能A、B。AI说好的，我开始完成这个功能。接着模拟了一些数据，引入了几个emoji图标，然后说完成了。这显然是不能接受的。
3. 不可验证。我只是告诉AI每个阶段可验证，但是他不知道怎么算“可验证”，约等于没有验证。它甚至写了几个模拟数据的测试脚本，来告诉我完成了。

这个阶段给我的冲击是很大的，一方面，AI确实能很快的理解到我想完成的东西，并迅速完成代码开发，这在流程上是可行的。另一方面，我的描述，和AI的理解，之前有巨大的鸿沟，并且它不会主动告诉我这些不一致--“AI不语，只是低头完成了所有代码”。即使他引入一个小问题，在后续的几个阶段放大到无法维护的地步，他几乎会遵循错误路线一路走到底。并在最后告诉我“非常好！你之前的代码似乎引入了一个不一致，我现在来修复它，让我重写这个文件”，WTF。

阶段二：引入“约束”

我开始尝试抹除导致问题的”不确定性“，解决办法是按照一些软件设计思路去和他讨论需求，添加更多的约束，例如引入公理设计、测试驱动开发（TDD）、确定开发计划（P0、P1、P2等），甚至要求他生成流程图。

这个时候，我确切体会到，人的认知水平，决定了AI输出内容的水平。

之前你只感觉AI输出的内容很专业，恰恰因为看起来很专业，导致人容易忽略他描述中的问题。这里有个解决思路是交叉对比，让一个AI去审核另外一个AI生成的内容，”帮我检查这份需求/任务/文档有没有不合理，语焉不详或者冲突的地方，按照优先级指出来“。必要的时候，需要开启多个回话反复审核，因为上下文会相互影响，导致一些深层问题被掩盖，AI某次的”灵光乍现“可能就解决了一个隐患。

我生成了多少文件呢？大概有10几个：数据库实体和标设计.md，测试修复与调试方法.md，公理设计.md，函数架构.md，前后端配合.md，技术选型.md，模块与接口规范.md，开发计划.md等等。

我依然把这些数据在会话开始时，足量投喂给AI。效果确实有，AI会根据文档里的内容去执行。并且输出内容比之前有大幅提高。这个阶段我尝试了新建项目和重构项目两种模式，总结下来，新建项目的速度和准确度，要明显比重构任务好得多。为什么会这样呢？我总结下来大概有以下几点：

1. 上下文长度。引入的规范，一定程度上规范了代码质量，但是由于要投喂更多的文件，导致窗口变窄。对于重构项目，除了这些文档，还需要去理解当前项目的代码实现，这又占用了很大的上下文大小。所以后期出现了AI降智，就是他开始中英文夹杂，或者出现泰文、尼泊尔文等花体字。或者是简单输出一小段内容，就开始总结（claude常见）。

2. 文档内容量太大。文档太多除了占用上下文窗口，另外一个重要的问题是“焦点模糊”。就是AI不知道这些文档的优先级是怎样的，每次搜索到相关内容就开始执行。导致后期依然会有代码混乱的问题。

阶段三：进一步规范“约束”

这个时间点，差不多是 Claude Code 和 Kiro 出来的时候。除了使用方式上的更新和带来了更多选择外，他们共同的一个特点是引入了 Plan 模式，Kiro 里叫 Spec 模式。即在实际执行之前，先审核实施计划，明确好每一步的操作方案。在执行前，征求你的确认。

这个时候我已经和 Gemini Pro 商量出了一套比较好的方案，即章程（PROJECT_CONSTITUTION）+ 项目约束（一些 yml 文件）+ 执行步骤模版。项目约束文件包括：business_logic.yml、database.yml、api_endpoints.yml、test_cases.yml。yml 内容是结构化的，端点和描述比 md 文件要清晰很多，当然不是给人阅读的。

这个方案的执行流程是这样： 在会话开始阶段，先把章程和约束文件（通常有 5 个左右）喂给 AI，要求他完全理解这些文档并统一。接着使用模版生成执行步骤，这些步骤里会要求他使用某些 yml 里的端点规范，有明确测试用例和目标。

所以在看到 Spec 模式的时候，我有种很熟悉的感觉，这不和我目前的方案差不多吗？但是仔细想了想，还是有区别的：它的粒度更灵活，例如可以为某个模块创建包含 requirements、design、tasks 的 Spec，也可以按照项目来创建一个大的 Spec。另外，单个 task 的条件做得很好，包括描述（details）、受影响文件（Affected Files）、任务依赖关系（requirements）。任务中还有关键路径、测试方案等内容。

这样的好处就很明显了，首先是关注点集中，只依赖某几个文件，对全局、任务在不同层面上做到了约束，并且精确到文件、功能点，避免了 AI 随意发挥。

当然 Kiro 肯定还为此做了很多其他工作，比如开始 Spec 模式时，就对项目整体了解的很清楚。我也偷偷问了 Kiro，他没说明白，只是告诉我 Spec 大概的思路，给了我一份看似很清楚的 guide 文档。

我目前的这套“规范驱动”（规约驱动）方法，虽然能在很大程度上解决了 AI 行为一致性的问题，但我也不禁思考：这会是 AI 辅助编程的终极形态吗？我感觉这可能只是一个中间阶段。正如我这几个阶段的实践经历，未来软件开发范式演变，也有几个清晰方向。

思考与展望——AI辅助编程的下一站

开发者角色的重塑：从“编码者”到“系统规约师”

AI Coding 的发展类似于汽车的自动驾驶，分为几个阶段：

• 代码补全（Copilot）
• AI 辅助编程
• AI 结对编程（人指挥 AI 写）
• AI 自驱编程

目前大部分的 IDE 工具（cursor、windsurf 等）基本处在第二阶段，新的工具（Claude Code、Kiro 等）在瞄准第三阶段。

辅助编程：包括聊天、代码重写（一键 apply）、代码补全。基本流程是在对话框聊天，根据 LLM 的结果去修改代码。核心考验是项目理解能力、上下文裁剪、模型能力。

结对编程：编程工具有调度能力、具备工具调用能力。它可以根据“约束”，提前规划任务和实现细节，并在迭代中逐步推进。

AI 自驱编程：AI 能理解全局意图，做架构判断和优化，具备持续学习与反馈能力。

新范式诞生：走向“AI 原生”（AI-Native）开发

什么是 AI-Native？

这是一种开发范式的转移。传统开发流程是：

设计 → 编码 → 测试 → 部署

现在是：

设计 → AI 协助编码

未来可能变为：

规约定义（Specification）→ AI 生成 → 自动验证 → 人类审核 → 迭代规约

在这个范式下，代码可能只是中间产物，那些精确、结构化、可迭代的规约，才是项目真正的核心资产。

角色的转变，开发者技能栈更新

开发者将成为“系统规约师”，具备以下能力：

• 问题分解与抽象能力：将模糊的业务需求精确分解为 AI 可理解的结构化任务与约束。
• 系统设计与验证能力：提出高质量架构，设计出可自动化验证 AI 产出的测试用例和标准。
• AI 沟通与调试能力：熟练设置上下文、定义约束，快速定位并修正 AI 的问题。

这几乎是一种全新的“人机交互”学科。

尾声

当然我也不是专门研究大模型的，只是从一个体验者角度，对辅助编程这块做一个粗浅的总结和思考。

如果你也在使用 AI 编程工具，希望我的这点经验能让你少走几段弯路。