夜雨聆风AI训练营10期，6月底开班，欢迎咨询
最近写了太多偏“硬”的技术文章，确实有点扛不住了，今天我们来聊点形而上的东西：AI 时代的判断力。
为什么会有这个课题呢？是因为最近有很多零散的触发点没有被连接，然后昨晚我们在 TGO 小组会议的主题是：AI + data，两轮分享后，我突然福至心灵，一下感觉就来了：
当时的话题是：打造企业级 Agentic RAG 心得
然后是如何创建个人第二大脑，这兄弟有一套完整的方法论：
他们分享的内容本身很常规，但在讨论的时候触发了我的 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 才是终点，只不过这东西在数据处理这边很难，整体的技术范式复杂度会高很多，如果后续有需要，我们再继续讨论吧......
