最近一周，我在一个新项目里集中使用 AI 辅助编程，有一个比较明显的感受：

AI 辅助编程正在从“帮我写代码”，逐渐变成“辅导我把系统做得更好”。

这里说的“辅导”，不是说 AI 变成老师，人变成学生。

我的意思是，AI 开始参与更靠前的工作。它不只是补代码、写函数、改 bug，而是会结合项目上下文，帮助我完善设计、解释方案、补充边界，并推动整个项目继续往前走。

这种感觉主要来自两个方面。

第一，项目里有比较完整的 docs 文档体系，AI 能够更好地理解项目已有成果。

第二，模型能力提升以后，AI 对方案的理解、解释和组织能力明显增强。前几天使用 GPT-5.4 时已经有这种感觉，今天切到 GPT-5.5 后，这种感觉更明显。

另外，结合这次从 0 开始建设项目的过程，也顺带观察到一个现象：AI 辅助编码在新项目快速构建阶段，对代码增量速度的提升非常明显。

这个代码增量速度，不是“AI辅导编程”的核心依据，只是这次实践中的另一个观察，放在后面作为补充。

一、为什么我会产生“AI辅导编程”的感觉

过去说 AI 辅助编程，重点通常在“辅助”。

早期的 IDE 有代码提示，可以自动补全变量名、方法名。后来 AI 编程工具出现以后，最开始也主要是代码补全：写几行代码，它帮你补完一段；写一个函数名，它帮你生成函数实现。

再往后，AI 可以完成一个功能模块，修改一个 bug，生成测试代码，解释已有代码。

这些能力已经很有价值，但整体上还是“助手”角色。

人提出问题，人拆解任务，人做架构判断，人控制边界，AI 帮人更快地把代码写出来。

最近这一周，我的感受发生了一些变化。

我在一个重新整理的项目里，从 0 开始复刻和重建以前的一些工作。项目一开始就建立了 docs 目录，里面沉淀了工作记录、详细设计、变更记录等内容。

这些文档不是形式上的项目说明，而是把项目中重要的设计思考都尽量落地下来。

一个功能为什么这样拆？一个模块为什么这样设计？一个机制后面可能要支持什么扩展？一个接口为什么要保留某个边界？

这些内容尽量不只留在聊天记录里，也不只留在脑子里，而是沉淀到项目文档中。

这样做以后，AI 看到的就不只是当前代码片段，而是整个项目的设计背景、已有成果和推进方向。

在这个基础上，再叠加 GPT-5.5 的理解和推理能力，就会产生一种新的感觉。

我提出一个问题，它不只是按照我的要求生成代码，而是会结合已有代码、已有文档、当前目标和后续扩展方向，给出更完整的方案。

有时候我看到它给出的方案，第一反应会觉得有点超前，担心是不是设计得太多了。

我会追问它：为什么要这样做？

它会解释为什么当前项目适合这样设计，为什么这个抽象不是多余的，为什么现在多做一点可以避免后面返工，为什么它和已有代码结构是匹配的。

这个时候，感受就不一样了。

它不是简单帮我补代码，而是在帮助我把系统设计想得更完整。

所以，“AI辅导编程”不是单纯来自模型变强。更准确地说，它来自两个条件的叠加：

项目有持续沉淀的文档，模型有更强的理解和组织能力。

没有项目文档，模型再强，也容易只是局部聪明。没有更强的模型，文档再完整，也未必能产生明显的“辅导感”。

所以我现在越来越觉得：

docs 是基础设施，模型能力是放大器。

二、项目文档是 AI 理解项目的基础设施

过去写项目文档，主要是给人看。

方便新人接手，方便以后回顾，方便记录设计决策，避免关键判断只停留在个人脑子里。

这些价值一直存在。

现在 AI 辅助编程越来越深入，项目文档又多了一层新的价值：

文档也是给 AI 看的。

这次我在项目里专门设置了 docs 目录，主要放三类内容。

第一类是工作日志，记录每天推进了什么。

第二类是项目设计文档，记录功能设计、模块设计、技术方案和边界考虑。

第三类是变更记录，记录系统在不同阶段发生了哪些变化。

这些内容很多由 AI 根据 git 提交记录、对话过程、设计讨论和代码变更辅助生成。重点不是文档由谁写，而是这些内容被沉淀到了项目里。

这件事情很重要。

AI 做一个长任务的时候，如果只依赖当前对话，很容易出现上下文不完整的问题。

它可能知道眼前这个函数怎么写，但不知道这个函数为什么存在。它可能知道某个接口怎么实现，但不知道这个接口在系统里的位置。它可能能完成一个局部任务，但不一定能把局部任务放到整体架构里判断。

有了项目文档以后，情况就不一样。

AI 可以先阅读文档，再理解代码，再推进任务。它不是在空白上下文里工作，而是在项目已有成果的基础上继续工作。

这对 AI 有帮助，对人也有帮助。

一个稍微复杂一点的系统，里面一定会有很多小设计、小约定、小边界。这些东西只靠代码很难完整表达。过一段时间以后，即使是自己写的代码，也可能忘记当时为什么这样处理。

如果重要设计都有文档说明，后面再看项目，就不只是看代码，而是能看到代码背后的设计思路。

所以，我现在对项目文档的理解也发生了变化。

过去文档更像是“项目说明”。现在文档更像是“项目记忆”。

它既给人提供记忆，也给 AI 提供上下文。

这也是“AI辅导编程”能够发生的重要前提。

三、GPT-5.5 让“辅导感”更明显

我长期做应用系统开发，主要是业务系统、信息化系统、管理系统这一类项目。

这类系统的核心不只是写代码，还要把业务需求、数据结构、权限边界、流程规则、系统架构组织起来。

所以我使用 AI 辅助编程的时候，更多是我先确定大方向和主要实现路径，再让 AI 协助推进具体设计和代码落地。

以前它主要是帮我把已经想清楚的东西写出来。现在它开始能在我的思路基础上，补充更完整的设计。

更重要的是，我现在使用 AI 辅助编程，系统代码中 99.99% 以上的代码都是 AI 生成的，包括功能代码，也包括对应的测试代码。

这意味着，我的工作方式已经发生了明显变化。

我不会逐行、逐处地阅读每一段实现，也不会像过去那样把所有代码细节都重新过一遍。对于大部分代码，我是在明确需求目标、设计边界、项目上下文和测试要求之后，相信 AI 的工作成果。

这里的“相信”，不是完全放手不管，而是工作重心发生了转移。

过去我更多是在写代码、检查代码。现在我更多是在定义目标、描述上下文、判断方案、追问原因、验收结果。

AI 负责生成大量功能代码和测试代码，我负责判断它做的事情是不是符合系统设计、业务目标和工程边界。

这也是我为什么会产生“AI辅导编程”这种感受。

如果我还需要逐行复核每一段代码，AI 仍然只是一个更快的代码生成工具。当我可以把大部分编码实现交给 AI，并且主要通过设计、测试、运行结果和关键问题追问来控制质量时，AI 就已经进入更深层的工程协作关系。

比如我提出一个问题，它不会马上只给一段代码，而是会先判断这个问题在当前项目里的位置。

它会看已有代码怎么组织，当前设计是否已经有类似模式，后面有没有扩展可能，边界条件在哪里，测试应该怎么补。

这已经不是简单的代码生成。

更关键的是，它能解释自己的方案。

AI 直接给一个方案还不够。人真正需要的是判断这个方案是否合理。

如果它只是说“建议这样做”，但说不清为什么，我还是不能放心用。

如果它能解释清楚为什么当前项目适合这样设计，为什么这个抽象不是多余的，为什么这个地方要留扩展点，为什么现在这样做可以减少后面返工，为什么它和已有代码结构一致，那它就不只是一个执行工具了。

它开始像一个可以讨论方案的技术同伴。

当然，AI 给出的设计不一定都对，也不应该直接无脑接受。

最终判断仍然在人这里。

但它确实可以帮助人把问题想得更完整。它会提醒一些暂时没有想到的边界。它会把隐含的设计理由说出来。它会把一个模糊想法整理成可以落地的方案。它会把方案、代码、测试和文档串起来。

这就是我说的“AI辅导编程”。

AI 不是替人负责，而是在工作过程中，对人的设计判断、工程组织和任务推进产生更强的促进作用。

人还是负责人。AI 不是替你负责。但它开始能辅导你把事情做得更好。

四、补充观察：从 0 到 1 的项目，AI 辅助编码的增量速度很明显

除了“AI辅导编程”这个感受之外，这次还有一个顺带观察：

在从 0 到 1 的项目建设阶段，AI 辅助编码带来的代码增量速度非常明显。

这里要先说清楚，这次不是存量系统维护。

它是在一个新项目里，从 0 开始重新整理和搭建。这个区别很重要。

存量系统维护时，代码增量通常不会特别快。大量时间会花在理解历史逻辑、兼容已有结构、排查影响范围、修复边界问题上。很多时候工作量很大，但最终代码行数变化不明显。

从 0 到 1 的建设阶段不一样。

只要需求方向比较清楚，架构拆分比较明确，开发者自己能够控制系统设计，AI 就可以非常快地完成大量结构性、重复性、模式化的代码落地工作。

这次代码统计也能看出这个特点。

后端部分，从 2026 年 4 月 16 日到 4 月 24 日，项目文件增长到 140 个，总行数接近 2 万行，其中代码行超过 1.4 万行。7 个有提交的活跃日里，Python 代码净增长 6767 行，测试代码净增长 1725 行，平均每个活跃日 Python 代码净增长约 966.7 行。

前端部分，从 2026 年 4 月 20 日到 4 月 24 日，统计范围内 TypeScript 代码从 556 行增长到 4888 行，累计净增长 4332 行。4 个增长日里，平均每天净增 TypeScript 代码约 1083 行。

代码行数不是软件质量本身，也不能简单等同于真实工作价值。

代码写得多，不代表系统一定好。代码增量快，也不代表没有技术债。

这些统计只能说明一件事：

在从 0 到 1 的快速建设阶段，AI 辅助编码确实可以显著提高代码产出速度。

尤其是当人已经完成需求拆解、架构判断和边界控制之后，AI 可以把大量工程性工作快速落地。

这个时候，人的价值没有减少，而是发生了转移。

人不再只是逐行敲代码。人更多是在定义目标、拆解任务、判断方案、控制质量、组织文档、验收结果。AI 承担大量具体代码实现、测试生成、文档整理和局部方案补全的工作。

这是一种新的协作关系。

五、AI辅导编程的关键，不只是模型，而是工作方式

这次最大的感受是：

AI辅导编程不是换一个更强的模型就自然发生。

模型能力当然重要。

GPT-5.4 到 GPT-5.5，确实让我感觉模型在理解项目、解释方案、辅助设计方面更强了。

但如果项目没有文档，没有上下文，没有清晰结构，模型也很难真正发挥出这种能力。

它可能仍然可以写代码，但很难参与系统级设计。它可能能完成局部任务，但很难理解项目长期演进。它可能能给出一个看起来不错的方案，但不一定贴合当前项目的真实状态。

这次体验里，还有一个很现实的变化：代码已经主要不是我手写的。

功能代码、测试代码，大部分都由 AI 生成。我并不会逐行阅读每一处实现，而是把注意力放在更关键的位置：需求是否清楚，设计是否合理，边界是否完整，测试是否覆盖，运行结果是否符合预期。

这对传统编程习惯是一个很大的变化。

过去我们习惯认为，代码是自己一行一行写出来的，所以自己天然掌握所有细节。现在大量代码由 AI 生成，人不可能也没必要回到过去那种逐行手工检查的工作方式。

人的责任没有消失，而是上移了。

人要把目标讲清楚，把上下文准备好，把设计边界控制住，把关键结果验收好。AI 则承担大量具体实现工作。

这正是“AI辅助编程”走向“AI辅导编程”的一个重要变化：

AI 不只是帮我更快写代码，而是在推动我用一种新的方式组织软件开发工作。

所以，要把 AI 辅助编程用好，需要几个条件。

第一，人要有系统设计能力。要知道自己要做什么，知道怎么拆问题，知道什么方案适合当前阶段，什么方案不适合当前阶段。

第二，项目要有持续沉淀的文档。工作日志、设计文档、变更记录，这些内容看起来不像代码那么直接，但它们会成为 AI 理解项目的重要上下文。

第三，AI 要能读取和理解这些上下文。这要求我们在项目结构上有意识地为 AI 准备信息，而不是只把 AI 当成临时问答工具。

第四，人要持续追问、判断和验收。AI 给出方案以后，不要只是直接接受，而是要问为什么。只要它能解释清楚，人也能判断清楚，这个过程就会推动方案质量提升。

这些条件结合起来，AI 才会从“帮我写代码”，逐渐变成“辅导我把系统做得更好”。

结语

AI 辅助编程的下一阶段，不只是效率工具升级，而是工作方式变化。

过去我们说 AI 辅助编程，重点在“辅助”：

帮我补代码，帮我写函数，帮我改 bug，帮我生成测试。

现在我感受到的变化是，AI 开始参与更靠前的工作：

参与设计讨论，参与方案解释，参与文档沉淀，参与系统演进。

这时候，它带来的就不只是编码效率提升，而是软件开发过程的组织方式变化。

当 99.99% 的代码都由 AI 生成时，人的核心工作就不再是逐行编码，而是定义目标、组织上下文、判断方案和验收结果。

AI 越强，人越需要有判断力。

人要知道目标是什么，边界在哪里，质量标准是什么，什么时候该接受，什么时候该否定，什么时候该让它解释清楚。

AI 可以辅导我们把系统做得更好。最终负责的人，仍然是我们自己。

所以，我对这次体验的总结是：

高质量项目文档 + 更强模型能力 + 人的持续判断，正在把 AI 辅助编程推向 AI 辅导编程。

这可能会成为以后软件开发中非常重要的一种工作方式。