本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《AI Coding 能力模型：代码都让 AI 写，还要学编程吗？》
最近写了太多偏“硬”的技术文章，确实有点扛不住了，今天我们来聊点形而上的东西：AI时代的判断力。
为什么会有这个课题呢？是因为最近有很多零散的触发点没有被连接，然后昨晚我们在TGO小组会议的主题是：AI+data，两轮分享后，我突然福至心灵，一下感觉就来了：
然后是如何创建个人第二大脑，这兄弟有一套完整的方法论：
他们分享的内容本身很常规，但在讨论的时候触发了我的AI知识框架底层分类逻辑，于是问题就来了，虽然现在看起来有非常多的Agent，也有非常多的公司在做Agent，比如：
只不过，虽然Agent很多，但如果你真的看知识库类的Agent，其实只有两个大方向：
协作类Agent RAG、知识输出类Agent RAG
这里所谓协作类Agent RAG，也就是他会读取很多知识，我们不会期待他的输出100%正确，而是在我们与他协作的过程中共创出最终的答案；
知识输出类Agent RAG的话，逻辑又不一样了，他不需要我们跟他协作，而是需要我们被他引导，并且我们期待他能输出尽量100%正确的答案。
至此，大家就会理解协作类Agent和知识输出类Agent的区别了：
Agent是否输出100%正确的内容，进一步的解读是：用户是否需要对AI输出能力的判断力，这个判断力是是否需要协作的基础
关于Agentic RAG的话题，我们之前讨论过，并且最近有一些新的心得，但由于篇幅太大，就后续再展开，我们今天核心聊聊这个对AI输出内容的判断能力。
这个问题远比大家想象的更加复杂，他可能会涉及整个工作流、组织结构的重构。
评价是权利之源
这个其实不是AI课题，是管理课题，之前我们在做管理框架文章的时候就讨论过了。
在公司体系下人越多效率越低，其核心原因分为两点：
规模导致的信息差；
专业壁垒过高导致的评价难题；
我们今天重点说下这个评价问题，一般来说公司是分部门的，其原因是：专业的人做专业的事，这里的专业就是评价、判断能力。
行业经常出现的管理问题是：外行管理内行，也就是说在瞎指挥的情况下容易出事。
而最容易出现评价难题的就是技术部门，比如之前Qwen核心林俊旸离职事件就是个很好的Case：上游Leader根本不具备对下级员工的指导和评价能力，那么这就是一个失控状态。
那么什么是评价/判断能力呢？简单来说就是我们对一个项目、一篇文章、一段代码好坏的理解，和可以提出的意见。这里又可以进行分层：
最差的是毫无判断力；
更进一步是知道什么是错的；
再进一步是知道对的里面冗余的是什么；
更进一步是知道什么是好的，好在哪；
......
知道好坏对错，才能提出优化建议，大家可以去对照下，你作为一个Leader，对下面同学手里的工作、职业的发展是否具备评价/判断能力，并且要明确具有什么层次的评价判断能力：
从这里我们开始回归，Agentic RAG其实正遭遇类似的评价问题：
协作类Agent当前数据正确率远未达到100%（我这边的数据是80%左右），那么使用他就会要求用户协作，这变相就是要求用户具备对AI输出内容的评价判断能力。
而当前最是火热的协作Agent的代表是Coding Agent，他正面临相关的问题：
AI Coding的能力模型
这里先分享两个关于学员的经典Case：
学员一
不懂技术，用ai coding做了几个demo，现在遇到了几个小问题：
不懂编程，怎么确定不同项目使用什么技术栈，是否合理
前端样式感觉也很丑，让ai提取了好看网站的ui风格，实际做出来差的有点远，该怎么做好看，包括ui风格和可视化风格，是不是要使用一些其他的项目
想做的交互效果只会用自然语言描述，ai转成代码，总有或多或少的差异，想要1:1实现指定的页面交互效果，该怎样撰写提示词，让AI产出符合预期的代码
把Demo打磨成生产级的应用，权限管控、数据安全这类体系不知该怎么设计，怎么编写对应的提示词，现在只能做些demo
学员二
我疑惑的是，作为一个个人，应该怎么去做更合适？
我是前端出身，进入一家做Agent的公司做全栈工程；公司是任务制，也就是按照整个任务都是你做，可能涉及完整的前后端代码。
当然我是前端，所以分配到的任务可能更偏重前端的；因此也有java的同学，他们会做更偏重后端的任务；
在我做需求的时候，简单的写个java接口，ai完全没问题，但是涉及到多个表的创建关联，有的时候ai写出来的能跑，但是可能不符合规范；
现在我就很疑惑了：java同学说我现在设计到核心代码，需要补充架构能力，Code Review的时候不能一问三不知，好像是与神对话写出来的代码；
基于此，我感觉我要补充后端的架构能力；但是，后面我们代码都是ai写，就应该让ai去学，而不是自己去学，这个怎么破？
这两个Case背后，其实不是简单的不会写代码，而是三个更底层的问题：
我不知道AI给我的方案是否合理；
我不知道AI写出来的代码是否符合工程规范；
我不知道Demo到生产级应用之间到底差了什么。
要解决这些问题，就要回归我们前面说的评价/判断能力了，如果不了解底层逻辑就很容易在以后代码都让AI写，我还要不要学编程这种事情上纠结。
AI Coding的门槛是Prompt，但Prompt只是输入能力，真正决定上限的是评价能力。
现在我们需要关心的是：到底要做什么、学什么去提升我们整体AI Coding的评价能力，毕竟学错了会很麻烦...
也正是因为我们要学习，所以我们先提出了这套AI Coding能力模型，接下来就是照着能力模型做学习了：
AI Coding能力爬坡
接下来进入能力爬坡阶段，现在时代不同了，之前的一套学习逻辑现在可能不适应了，比如之前我们要做前端全栈工程师的学习路径是：js-css-hybrid-react/vue-小程序-NodeJS......
后端的学习路径会更为陡峭一些，但他们都有类似的问题：耗时费力，不是1、2年能搞定的事，等你真正学完黄花菜都凉了。
所以更合理的方式是：围绕AI Coding的评价能力，一层一层补。换句话是什么呢？不是为了跟AI抢着写代码，而是为了获得一个评价/判断能力，包括：
AI有没有做错；
AI有没有理解偏；
AI的方案是否合理；
饭一口一口吃，路一步一步走，接下来我们按照能力模型做展开：
第一层：显性错误验收能力
抛弃你想做复杂技术选型的幻想，第一步要做的是补齐基本验收能力。
很多人刚开始用AI Coding，只要页面能打开、按钮能点击，就觉得完成了，但真实项目里，这远远不够。
这个阶段对大家要求不高，能够很好的扮演一名传统的产品经理或者传统的测试经理就行，至少要做到保证AI Coding在结果上表面是没问题的。
如果一个人连显性错误都验不出来，就很容易被AI的表面完成感骗了。
这里具体怎么学、学什么呢？
最简单的方式是，从小功能开始，每次让AI写完以后，自己固定做一遍验收：
因为做的是小功能，每次出点问题是很好映射的，这里的目的是什么呢？
这里的目的是让你把所有的错误类型都看一次，对有什么错、如何产生、怎么改，有个基础的印象，这里会形成基础的研发调试感
只要研发调试感形成了，后续更复杂的项目也就不慌了，因为所有的错误类型是看过一次了：
第二层：需求与交互还原能力
第一层解决的是：AI做出来的东西有没有显性错误，目标是熟悉各种错误，形成一种研发调试感；
第二层的话问题又来了，AI没有错误，不需要你调试了，但给的东西不是你要的：
页面能做出来，但看起来很丑；
让AI模仿好看网站的UI风格，但最终差得很远；
想要某个交互效果，但只能用自然语言描述，AI实现出来总有偏差。
要解决上述问题，就又要回到评价能力了，如果把AI当员工的话，你不能给他很粗的修改建议，比如：
高级一点、丝滑一点；
像某某网站一样；
页面更有科技感一点；
AI需要的是工程化表达而不是你的感觉，因为没人知道你的感觉是什么...
在这一块训练的就是结构化表达、描述问题的能力了，也就是从：
我想要一个好看的页面升级成：这个页面由哪些模块组成，每个模块展示什么信息，组件状态有哪些，交互路径是什么，视觉风格由哪些规则控制，最后用什么标准验收...
这是一个逐步递进的过程，从产品表达→前端表达→交互表达，需要补足学习的部分就是：
拆页面结构，不给模糊化的表达，而是说清楚，页面分几块、左边是什么、右边是什么、哪些内容是主信息，哪些内容是辅助信息...
拆组件状态，很多组件是有状态的，包括默认态、加载态、空数据等，你不告诉AI他也可能会做对，但AI不会保证全对；
拆交互过程，交互丝滑就很虚，要实际的话就要说清楚点击哪里、点击效果、是否弹窗、弹窗动画等
......
上述的东西很细、处理起来是很烦躁的，但你至少需要做一次，然后就可以尝试建立三个东西了：
建立自己的页面参考库。把你觉得好看的后台、官网、数据看板、产品页截图收集起来，不只是收藏，还要让AI帮你分析它为什么好看；
建立自己的需求Spec模板。以后不要直接让AI写代码，先让它和你一起生成一份页面Spec；
建立交互验收清单......
第三层：技术方案判断能力
至此，大家在工具使用和研发调试感觉上会比较熟悉了，随后就可以逐步进入深水区了，比如判断：AI给出的方案是不是合理的。
这是很多人最容易被AI带偏的地方，因为AI很擅长给出一套看起来非常专业的方案。你问他做一个系统用什么技术栈，他可能会给你：
前端React，后端Spring Boot，数据库MySQL，缓存Redis
鉴权JWT，部署Docker，再加消息队列、对象存储、微服务、K8s......
这些词单独看都没错，但放到你的项目里可能完全没必要，这就回到前面说的评价能力了：
高手不是让AI输出更多，而是能删掉那些正确但当前没用的东西
所以，这一层需要获得的能力是判断：
这个方案和当前项目阶段是否匹配？
这个技术是不是解决真实问题？
这个复杂度是不是当前就需要？
团队未来能不能维护？
说实话，这个阶段是很难的，已经不是一般小白能够达到的阶段，举个例子，我们的产品项目一般会分为三个阶段：Demo→MVP→生产阶段；
这里最容易出现的问题是：明明只是Demo，却让AI上生产级复杂度；或者明明要上线，却还停留在Demo技术方案。
因为对于AI来说，实现你的目标是最重要的，而如何实现对他来说是没有概念的，我们可能会有框架难度的概念，但AI没有，对他来说都是一样的...
这里篇幅有限，我没办法聊得太具体，这里就给大家举个例子：
如果现在大家需要去实现一个AI表格/多维表格
这里就有2种做法，让AI直接照着飞书/多维表格，一个一个功能抄，相信我，这样一定会完成的，你一定能拿到看上去正确的结果。
但是AI是不了解底层逻辑的，在复杂实现上你不给他说清楚，他就会随意实现，比如：
如何实现表格的多人协作并留痕；
如何实现不同的人按不同的角色做权限管理；
如何实现员工@的通知功能；
...
如果你只是Demo，那么您随意，如果你要长期维护，那么也不需要你懂代码，但其中的关系设计、表设计、实现逻辑，必须用产品语言给AI说清楚~
也就是说，你要具备产品架构设计的能力，通过自然语言是知道技术背后的底层逻辑的，只要你知道底层逻辑，你就能知道他应该如何演进。
第四层：工程规范与架构能力
第三层解决的是：方案是否合理，第四层就开始进入真实团队协作了，也就是：
AI Coding如何过Code Review、如何上生产
这也是学员二直接遭遇的问题：
简单Java接口，AI能写；
但一旦涉及多表关系、核心业务、团队规范。。。
AI写出来“能跑”，不代表“能交付”。
其背后是AI如何与团队协作、团队协作的规范是什么的问题：
现阶段AI Coding属于个人效率提升利器，但他一旦上升到团队效率就有点不行了，这一步不得不面对的东西是：工程规范与架构解释能力。
以前端同学为例，这里需要了解的架构不是什么微服务、分布式、高并发撒的，这里需要补的东西更接近业务本质，包括：
数据库一对一、一对多、多对多关系怎么设计；
异常怎么统一处理；
日志怎么记录；
......
上述模块的目标当然不是去写后端代码，他需要你能判断AI写出来的代码，是否符合一个团队长期维护的基本规则。
这里有些晦涩，举个例子，如果你要做修改密码模块，需要很多额外逻辑：
所有这一切都跟代码无关，而与业务理解有关、与风险识别有关...
个人在这块的实践经验是：能搞懂表设计，或者能做清楚表设计，那么至少可以解决60%的问题：
第五层：生产化交付能力
然后是学员最后一个问题：现在只能做些Demo，不知道权限管控、数据安全这类体系怎么设计。
这里其实主要是Demo和生产的区别，其实对于Coding能力来说是差不多的，只不过生产要求的工程细节会多太多，因为背后有各种稳定性要求。
举个例子，你做demo不会要什么日志与埋点，但如果上线出问题没日志就会很蛋疼，老板问你各种转化数据，也就跟着完蛋了...
这里复杂度已经较高了，我们这里不展开，大家可以看看图解：
结语
最后，回归最初的触动，我为什么会写这篇文章呢？
虽然今天我们讨论的是AI Coding的能力爬坡模型，其实我真正感兴趣的是他背后的两类Agent类型，以及后续Agent的演进方向。
当前Agent是没办法处理复杂的协作长链路任务的，所以需要我们与AI共创答案，这里的典型案例是AI Coding；
但这个更大的方向肯定走向更智能，知识输出引导类的Agent才是终点，只不过这东西在数据处理这边很难，整体的技术范式复杂度会高很多，如果后续有需要，我们再继续讨论吧......