在项目开发与日常学习中，AI的参与方式千差万别，从全自动执行到纯人工编写，其间存在着丰富的协作形态。本文尝试将AI的使用划分为不同层级——从A（自动）到0（无AI）——并非为了排列优劣高下，而是旨在提供一套清晰的认知框架，帮助我们理解自身与AI的协作究竟处于何种模式，从而在效率、控制与学习之间找到恰当的平衡。无论你是希望一键生成结果，还是追求每一行代码的掌控感，或许都能在此找到对应的坐标，进而更清醒、更有效地使用AI。
索引
| 模式 | 代码生产 | 人类代码理解 | 代码行为预期 | 性能优化程度 |
|---|---|---|---|---|
| A/自动模式 | 完全自动 | 可以不理解 | 几乎不可控 | 几乎不可控 |
| Q/提问模式 | 对话方式 | 需要初步理解 | 难以控制 | 难以控制 |
| P/产品模式 | 对话方式 | 可以不理解 | 视PRD详细程度 | 视PRD详细程度 |
| T/测试模式 | 对话方式 | 可以不理解 | 视测试细节 | 难以控制 |
| R/审核模式 | AI生成人类审查 | 需要基础理解 | 视测试细节 | 基本控制 |
| D/主笔模式 | 人类AI混合 | 需要完整理解 | 视测试细节 | 完全控制 |
| S/辅助模式 | 人类生成AI审查 | 需要完整理解 | 视测试细节 | 完全控制 |
| 0/人工模式 | 人类生产 | 需要完备理解 | 视测试细节 | 完全控制 |
Level. A/Autopilot/自动
在**Autopilot模式**中，AI只需要一个启动按钮就可以自己去做任何事情，一段时间后它会将结果给你。十分省心省力，一站傻瓜式操作，心想事成不过如此。
这个过程你无需考虑任何上下文，提示词，也没必要知道内部的思考链等。代理本身就是一个应用，由他人设计，你很难控制内部逻辑。输出质量也参差不齐。典型如 jihe520/MathModelAgent。这是一个预设了各种提示词、放进题目文件就能生成结果论文的超级Agent。
这个模式更适合作为自动化领域中的简单语义接口，比如AI客服，但绝对不应该是AI生成程序。
优势是绝对傻瓜式操作，缺点也很明显，写出来的代码用户完全不懂，复杂任务里八成是没法直接用的，想改也得找AI改。完全依赖AI。在数学建模里倒是很合适，因为数模的代码既没人看又消耗时间。
如果你将审阅或者修改，那就不在这个范畴内了。
Level. Q/Questioning/提问
在**Questioning模式**中，你使用LLM的开山功能：对话。
对话中，你描述问题，复制AI的代码，然后你会遇到各种棘手的问题。然后去尝试理解、学习、最后可能不完美地解决一些问题。这个过程有时会很折磨，因为它本质和老师手把手教你做题没有区别，虽然没有A/自动模式方便快捷，但这个过程的学习效率非常之高，以至于做完即学完，和大学水课形成鲜明对比。虽然既不能精通也不能给出完美作品，但这是我主推的新手学习方式：先照AI的提示上手敲命令行，敲出东西之后，剩下的很快就会以问题的形式出现在脑子里的。
这个模式唯一的优势只有学习，筑基和理解抽象的编程思想是合适的。在项目中遇到不懂的情况去问一下AI也属于这个模式。不过即使学习也只有技术的入门阶段可以用，并且学习不系统导致细节需要问题导向。如果不是以学习为目的，使用这个模式就是Ctrl CV工程师。那公司还不如充点钱上Cursor什么的了。
另一个特例是高度拆分模块化中，你确信已经被实现很多遍但特殊场景必须自己实现的一些效果（比如这个博客主页的打字机），在给足接口、合适的Usage、确信代码量不大的情况下使用AI是合适的。
并不是指提示词工程。当然提示词工程师这个新概念其实也还没稳定。叠甲过。
Level. P/ProductManager/产品
与Q/提问模式相反，如果你铁了心就想让AI按你的想法来，自己坚决不学不碰代码，那么**产品经理模式是你应该使用的模式。不要让AI猜你的想法，将所有要求和不要求**明确给AI来实现吧。
产品经理模式中，AI需要你给出完整的需求，环境，选型，故事或其他必要的前提条件。其与提示词级不同的是用户必须十分明确了自己想要的东西将以什么方式呈现，并且能够准确地表达出来。有了这些条件，很多现成的vibe coding IDE Agent已经能帮你完成所有工作。Cursor、Claude Code Skills、Trae SOLO(这个也能上桌吗)(国际版据说还行)都采取这个模式与用户交互。
经常有人说AI没有架构能力。AI确实是这样的，只在它上下文的小规模内写代码，这不代表一旦涉及到从顶到底几个级别规模同时出现的代码就会蒙圈，就我观察，AI的规划能力和代码能力是脱钩的。规划能力过于理想、过于追求标准化、最佳实践化和工程化，很大程度上难以考虑用户的场景级别，取舍也是只有教科书级别的。
因此，人类自身作为产品经理，了解所有技术栈的定位并准确地把各种接口（包括外部和内部）描述明白是尤为重要的。至于这个一开始的提示词怎么写，我想十分有经验的人应该不少*（但不是我因为我是坚决不全盘托给AI主义者）*。但至少我知道，一两百个字就想一遍跑出有成效又有特色的东西绝对不可能。
在这点之上通过类型标注/接口/直接定义等方式规定各个方法、函数之间的互相调用是更好的实践，如果能把文档也写清楚就更好了
Level. T/Tester/测试
T/测试模式是在P/产品模式之上的模式。如果在产品描述的前提下将AI闭环控制，即写一些测试并在AI修改代码失败后我们或者IDE自动让AI重试，我们就得到了测试驱动模式。
测试驱动模式中，AI需要一个明确的验收标准——你，或者另一个AI来编写测试代码，在可能HIL的闭环系统中让AI通过黑盒测试，与P模式不同，测试代码在保持逻辑不冲突的情况下更强硬地限制了AI的自由发挥。
与P/产品模式中传统的“我看到哪错了告诉AI”不同。这个模式有限地保证了生成代码的逻辑正确，但更大的意义在于能够让AI更加清楚需求，避免挖坑或者省略功能，或者AI思考os“这个明明应该正确的”的现象。同时更强的限制可能导致被动修改时产生更“能用就行”的代码，优化可能难以保证（比如在数据库查询失败完全修改后把原本有的关联表硬生生改回了n+1，别问我描述的怎么这么详细的）
值得注意的是，AI在几乎必然的测试失败后可能会尝试修改测试、跳过测试或者用针对代码绕过，失败的测试可能是难以测试的环境，更大的问题在于它自己强化的幻觉导致的错误（一些IDE Agent的思考架构已经很大程度上避免了这点）进而导致的AI主动越狱执念。这也是即使测试完善也不能无人值守的重要原因。
Level. R/Review/审核
如果你有一定代码能力，希望掌控代码，第一步应该是破除AI黑盒，通读所有生成的代码，第二步就是使用**R/审核模式**。
掌握代码不一定意味着真的要写代码。通读了代码之后，你终于获得了项目的基本代码结构。AI使用性能差、非最佳实践埋雷的时候你能够及时发现，同时进行高效学习。现在你可以要求设计模式和算法的优化了。
另外在大型项目中，让AI定位一个细微问题往往耗时良久，而AI代码的细微问题又往往多如牛毛，如果你有读懂的能力并在有问题的地方自行过目，快速修改，开发速度会高上不少。当然这需要的能力水平其实很高，否则bug半天找不到还不如直接让AI找。当然自己找的过程也是很好的学习。理解了90%的代码，剩下10%如果看了也能立刻明白并学到它的目的。与Q/提问模式相对的，这是一种查漏补缺和进阶提升式的学习。但如果走马观花，就会导致断了网，一些细节总是忘。
Level. D/Director/主笔
你已经准备好写出最高效、最符合工程的代码了。在前端项目中使用统一的CSS变量、后端使用统一的响应格式、每个级别的组件分成一个文件夹、灵活应用各种非常方便的设计模式、包装所有重复代码、用一些冷门好用的小库小技术栈避免重复造轮子……这些AI在上下文驱动下难以设计的优雅模式现在你可以尽情应用。直到这时，你才能大言不惭地说代码未依赖AI生成。
**主笔模式**顾名思义，是你主笔的模式，代码结构不再由你从AI代码中读得，而是全权由你设计。相比R/审核模式，主笔模式最大的特点是你现在可以对代码事实负责了。
代码此时会发生的最大变化是你不希望产生的功能的冗余代码完全消失，取而代之的是明确的可扩展接口或者明确不设计的接口。功能性能可维护性取舍分明，模块职责边界清晰可描述，注释文档更可读而不是好看，不再像AI生成的模棱两可。当然这一切是否能实现都基于你自身的代码能力。
AI在此过程中负责补充一些逻辑、找bug或者以类似Q/提问模式的形式负责一些接口定义完善的非核心小模块。但与提问模式不同的是，现在你需要白盒审查测试AI的代码。
这个模式是我今天最常用的开发模式。我无法忍受AI代替我的上限，即使它的上限很多时候比我高，我也必须得相信我不能被AI替代，AI的发展速度一直是惊人的，开发岗或许也会被AI逼得精英化的。扯远了，我们继续。
Level. S/aSsistant/辅助
**S/辅助模式**在D/主笔模式之上不再让AI主动编写任何代码。开发工作的主体完全由人类承担。
从需求分析到代码编写，整个过程由负责的人编写，这并不妨碍过程中有AI辅助的代码补全，因为经过人类实时审查、思考后accept的代码与实人编写相差已经不大。除了代码补全，AI还可以承担Review，提出aissue(AI Issues)
这个模式已经开始激进地排斥AI，一般来说效率会开始降低，如果不是项目或者场景特殊还是建议适当接受AI代码。
Level. 0
笑话一则：
我那天在飞机上看见一个人在用笔记本手打代码，没有网络，没有自动补全，没有AI，我的上帝，我不知道他是怎么写下去的。
这是七年前的修炼之道。每一个字符由你亲手敲下，每一个bug都由你在无尽的print中艰难擒获，每一个算法都由你在A4纸上反复推演。
在**人工模式**，你获得的是对技术最深层次、最肌肉记忆的理解。你的能力根基被打磨得无比坚实。在AI时代，这种纯粹并非低效的代名词，它更像一种修行。它适用于学习最关键的基础知识，适用于构建那些要求极限性能或极致安全的核心模块，也适用于在面试等需要纯粹展现个人能力的场合。然而，在Transformer时代，完全拒绝AI如同拒绝使用高级编程语言，它代表了一种可敬的匠人精神，但未必是综合效率最高的路径。
这套模型的意义不在于追求最高的级别，而在于清晰地认知你当下所处的级别，并理解其他使用ai的模式，使用合适的模式提高工作/学习效率。
我用一系列字母描述AI在编程或其他项目中的参与程度。我最初想用数字编号，但这些等级并没有越高越好或越低越好之分。黑盒智能体确实催生了一些不错的项目，但项目的优劣很大程度依赖着AI本身的智能程度，这实际上也与价格挂钩。人工代码仍然比想象中的广泛，AI代码距离替代人类设计仍有距离，人和AI的沟通在各种视角下都正在开始成为话题。
本文是我过去文章“你正以何种程度使用AI？”的重写。当时并没有PD(P)模式及以后三种模式的经验。现在有了，也更深刻了，于是便和与时俱进的ai一起与时俱进地把这篇文章重写了。