飞书妙搭进阶实战及 AI 开发理论分享 · 逐字稿

2026-05-21 15:59:07 CST|1小时 6分钟 1秒

关键词:
后端、前端、上下文、边界、范式、数据库、飞书、复用、产品、语音识别、业务场景、开发范式、工作模式、复盘文档、开发文档、表单字段、交互模式、运营文档

张佳宁 00:00:07.099 
啊，哈喽，同学们大家好，欢迎来到我们 AI 学院的妙搭的直播课。大家稍微等待一分钟，等工作同学进来哈，我先把我们本次的讲师的课程文档呢，来发给大家。

张佳宁 00:01:28.209 
嗯，好的，感谢大家的加入，我也看到已经有很多同学来到了我们的直播课哈。今天呢，大家可以看到又是一个我们全新的一个面孔的一个讲师，今天呢，由连昊老师呢，会给大家带来一个偏理论，但是呢，会给大家带来一理论与实践结合的一堂课哈。因为经之前呢，大家可能讲的更多都是各种实战啊，各种说如何一步步搭建，但是连昊老师今天不一样，会给大家更加系统地去讲解如何去更好地搭建，好。好的，那么我们现在呢，已经 4 点整了，我这边就不多说了，因为今天的课程同样是干货满满，我们来正式邀请我们的连昊老师开始今天的课程，好，欢迎我们的连昊老师。

韩连昊 00:02:14.890 
OK，大家可以听到吗？OK，那我抢一下投屏。大家好，我是今天的主讲老师啊，连昊老师。对，像大家听了这么多堂的妙搭的课，大家应该都初步用过妙搭，那这个时候我可能想要探究的一个问题是，大家会用AI，但并不一定等于我们一定能驾驭好AI。大家可以根据自己的情况来在我这边搭的一个简单妙搭工具上，来自测一下，看自己的段位是什么，以及接下来如果我们想要进行下一步提升的话，我们应该往哪里去升级？对，比如说有的同学可能是还没开始用，我们只是听说了，接下来我们可能第一步先是要练一练我们自己的 prompt 的设计的方法。如果有的同学我们已经会写了一些东西了，这个时候我们就需要学会的方法是如何让 AI 把我们要做的事情一步步拆解出来，完成一项我们非常完整的工作。

韩连昊 00:03:16.210 
第三步，我们已经会拆任务了，也已经知道让 AI 怎么样去工作了，那这个时候我们就需要让 AI 的输出更加可靠，长期可以给我们带来一些持久性的一些可靠性的工作。如果大家已经做得非常好了，那接下来我们可能会讨论的是 AI Agent，就是多 agent 之间协作的一个工作模式。OK，大家可以简单玩一下。好。如果有同学，用完完之后的话，可以看到下面我们还有一些，就在文档当中，大家直接打开评论区的文档应该就OK。嗯，我在评论区放好。

韩连昊 00:04:08.890 
OK，好，大家应该在评论区可以看到这篇文档。好，我们继续往下走。首先接下来，因为我们这堂课核心还是围绕妙搭来的。那我们妙搭本身就是一个 Web Coding 的工具，方便大家能快速地去落地一些自己想落地的一些内容。比如说我想去做一个投票，或者说就像刚才这样，我可能会想搞一个，诶，让大家在课前玩的一些小工具。

韩连昊 00:04:36.960 
那我可能就是这样，直接跟妙搭说一嘴，我这边可能会说的稍微结构化一点，就是也是我们个人主讲的内容，就是如何让妙搭能快速地给我们一些比较好的产出。我这边就是跟他说这样一段话，他就帮我把整个页面都拖出来了，还挺哈的，就是能快速帮我去落地一些很多内容。整个页面大概也就花了 3 分钟到 5 分钟吧，非常快。

韩连昊 00:04:59.290 
对，那我们先来讲一讲 vibe coding 这件事情啊。讲 vibe coding 这件事情，一定要从我们开发这个事情来看的话，一共发生了三个阶段的变化。我们最开始呢，传统的开发就是我们典型的就是文档工作模式，非常的workflow。可能是产品同学先设计好了PRD，设计同学UI、 UX 同学会设计好我们的交互模式，前端会开发，后端会把对应的功能做好，在整个前后端联调，最后测试再上。对，它的优点是非常灵活，我们每一个部分的组件都是我们自己写出来的。就像我们从和水泥，和水泥做钉子，然后再到做木板，一个个拼起来的一个楼房一样，我们有很高的自由度，我可以想做成什么样子做成什么样子。但是开发周期会很漫长，而且涉及到非常复杂的协作模式，会比较重，对，而且不太好快速看到我们想要落地的效果。

韩连昊 00:06:00.440 
接下来发展到了低代码和可视化这一个部分，那这个时候实际上流转到了 aPaaS 这个。 aPaaS 的话就像我们搭积木一样，很多时候我们已经不需要从水泥和钉子这个角度去做，我们可能就是一面墙，就像我们玩我的世界一样，我可能需要搭几个块，把这几个块拼在一起就可以变成一面墙，我只需要把这个门拼在这里，把屋子里的什么篝火炉子都做好之后，就直接变成一份可用的一个内容，能输出出来到业务系统当中，实际的业务支持。优点是开发效率会比原来快很多，但是依然需要一些比较技术的一些语言才能支撑起我们进行一些比较复杂的开发。

韩连昊 00:06:48.750 
OK，好，然后最新的范式就是像大家了解到的，就是我们所谓的 vibe coding，就是氛围编程。氛围编程和我们之前的模式很像，但是完全不一样的点是在，它不需要我们人工去做一些工作内容，或者说一些具体逻辑性的工作。这个时候只需要我们把一件事情描述得很清楚， AI 它就会根据我们已经描述的这些内容来帮我们去落地对应的内容。这个文档应该是可以看到的，对，应该是所有人都可以看到。

韩连昊 00:07:24.970 
OK，它优点就是所有同学都可以用 vibe coding 这个模式来开发自己想要开发的界面。开发方法是很简单，就像我就是这样发了一段话，它规划了一下工作内容。然后再把内容规划了一下，他就能直接做好一些具体的开发。比如说我可能想要修改，我给他截个图，告诉他，诶，这块排版不太好看，气泡这边还缺一个 L4 的一个级别的气泡。OK，那他就能帮我开发好这样的一个需求，就非常简单啊，所有同学都可以参与到这个开发过程当中。

韩连昊 00:07:55.970 
同一个案例，比如说就是像我们刚才的活动报名页。传统开发可能从需求对齐，再到UI，再到前后端的开发，最后再到联调。两到三天都是很慢的，这还是比较快，最后我们的项目比较轻量，而且有一些个可复用的组件，那两到三天是可以搞定。但是如果会非常复杂的话，可能最少要半个月、一个月这样的时间。低代码的话会快很多，如果我们是一个非常熟练的同学的话，用过 aPaaS 的同学应该都了解，我们只需要拖拽一些比如说表单组件，或者说数据筛选组件，或者是这些表头的一些框架，我们直接直接用就好了，我们可能大概也就两三个小时、一两个小时就能开发出一套比较可用的一个活动报名页。

韩连昊 00:08:39.770 
那 vibe coding 的话，我说真的，我从给他发完这个消息之后，这是 1: 14 发的，然后到 1: 28 他完整，哦，这这不算提交啊，就他完成这。交的时候大概也就花了十几分钟的时间，就能完成这一个项目的完整开发。对，那对于 vibe coding 来说，我们现在最重要的事情是什么？我理解现在我们最重要的反而不是键盘，就是像我们像原来一样，就是要手把手，或者说是一个一个代，一个一个字母的把代码敲出来那样的方法，不是我们这样苦哈哈地去做一些很硬很硬核的一些工作。现在最重要的事情反而是我们要把一件事情给 AI 讲清楚，让它能。很好的、快速的，精确的去帮我们去落地。就一句话来总结的话，就是开发范式的演进，本质上是人与沟通方式的改变。从指令行或者从命令行，从代码变到了自然语言。

韩连昊 00:09:50.030 
好，我们说一个简单的小故事。像传统运营过程当中，我们可能会，诶，我这边做了一个小页面，大家可以简单试一试啊。从传统的具体页面来看的话，我们可能一个页面需要，对，需要先写PRD，然后约评审，就是我们产品看完之后要让其他同学，我们要看完这个产品的没有，然后看我们的 leader 是不是同意我们这要做这件事情。然后前端要排期，后端要排期，然后再各种来回修改，然后中间你可能还会有很多。

韩连昊 00:10:23.620 
很多需要battle，可能前端同学说这个功能不好做，后端同学说那个功能不好实现，其实很难推进的，如果在座的以后 PM 的同学，或者说是你的项目管理的同学，你会发现很难推进，很难落地，然后折腾一件事，可能折腾，翻来覆去，折腾好长时间，都不一定有个落地结果。现在有 AI 和妙搭，那我做这样的一个工具，大概也是花了十几分钟的时间，大家可以简单试一试啊。

韩连昊 00:10:52.680 
这是一个公司内部的一个实战营的一个报名页面。我们可以从活动亮点来开始看。嘉宾阵容，我们有很多嘉宾，再到活动日程，最后再到往期评论的一些内容，最后再到报名的一个表单，最后，最后会有一个线上引导的一个过程。对，整个页面没有很复杂，OK，大家可以看到啊，我实际上就是跟他把这个事情描述的比较清楚，我需要做这样的一个页面，目标是给谁看，让目标是谁，给谁看，接下来我们要做什么样一个事情？这个时候要适合我们比较好的去给很多同学去做演示。OK，针对页面，我会有一些我自己的考量，有一些自己的设计，风格上的话，我会有一些我自己的要求。最后再到我最开始说的，我们有一些边界上的一些要求，确保 AI 不会做一些边界之外的事情。当我们觉得当我们觉得这个应用是可以用的时候，我们也可以把它继续向上升级，比如说我们想长期复用这个组件，我们也可以把它变成应用模式，来复用里面的数据能力。好，我们继续走。我们讲过了开发方式的转变之后，实际上引出了一个最核心的问题，是我们做事情的。价值其实是在下降的，因为很多具体的事情不需要我自己去做了，但反而是我们能不能把这个问题恰当以比较完整的，还有确切的方法来提给AI，让他来帮我们去完成事情的能力，现在越来越值钱。

韩连昊 00:12:49.230 
就像我这边上讲的，可能我们会答题就很便宜，我们直接把题目丢给AI，他能拿到一份比较不错的结果。但是如果我们自己会写一个比较完整的架构的 prompt 的话，我们更会需要先把这个问题讲清楚，然后逐步拆解好我们里面所构想出来的一些功能点，包括我们需要的，比如说我做前端开发的话，可能需要。前端的一些页面的一些诉求全都讲清楚。那这个时候我们才有可能会生成一个比较完整，我们才有可能会生成一些比较完整，结构美观，能快速希望快速拿到我们想要效果的一些产物。对。如果我们只说，比如说给我一个好看的页面，那它生成的效果绝对是比较差的。哦，如果我们想清楚了，这个页面第一个就像我这边的 prompt 一样。这个是给谁看的？目标是要让这些用户了解什么样的一个东西，我们要做什么样的事情。然后场景是什么？然后我们有一些本的一些边界性的要求，就是整个氛围性的要求。OK，对应我们这里就是一样，就是我们是给谁看的？然后看完之后希望用户做什么？必须要出现哪些信息？然后这是一个效果demo，还是说我们要一个做一个真的要收集数据的一个应用？那这些问题当我们理清楚这些问题之后，才有可能让 AI 去帮我们把一件事情理得很清，快速的做一个非常好的落地。

韩连昊 00:14:23.140 
所以其实稀缺点不是在，就是大家会说黑话，你比如说我们可能会说我们内部黑话可能是同学啊，或者说oncall，或者是一些就是其他行业的同学可能不是能快速 get 的一些词。这些词其实不重要，重要的是我们能把逻辑理清楚，能把问题的空间收到一个 AI 能解决的一个范围之内，那它才能帮我们更好地解决问题。可以参考我们这个判断力的三个维度。

韩连昊 00:14:55.230 
拆问题，就是这件事情能不能拆成几步，让每一步都闭环可验收，第二步可能就是验收输出，当我们有这些问题之后，它能产出一些对应结果之后，我们希望它产出什么样的一个内容，最后要到什么样的一个样式，我们有一个预期在，那它是用来验收我们之前的产出内容的。

韩连昊 00:15:16.720 
第三个就是知道边界，我们知道什么样的问题适合交给AI，什么样的问题必须得我们自己来做。对，OK，那对应到妙搭里其实是一样的，就是我们第一个拆问题，就是我们要看我们的页面结构都需要，里面都需要什么样的数据，那这个时候我们要把问题先拆清楚。第二个就是验收的输出，当我们当他已经产生出了一个结果，或者说我们对他这个结果有一个预期构想的时候，我们就要了解到我们对于前面的问题的每一项，我们的预期大概是什么样子的，跟他描述清楚之后，他才有可能非常以非常精准的方法来达成我们心里想要的那个样式。

韩连昊 00:16:00.150 
OK，第三个是知道边界。我这里简单列了一些，比如说权限啊、审批啊、用户数据留存数据啊、多人协作啊这种。这是一些比较复杂的场景，当我们想要做这些比较复杂功能的时候，我们其实就不要只是停留在，就是看效果的层次，而是要上升一层，比如说我们可能要深究一下里面内部的一些数据流转方法，还有一些数据结构，包括一些后端的逻辑设计的问题。我们需要深入到里面的一些具体的操作细节，然后更好地让 AI 把我们的思路进行落地。

韩连昊 00:16:37.020 
OK，好，好题目和坏题目，这实际上是一个 prompt 对比，就是提示词的对比。针对两不同场景，我们简单有一些示例。比如说左边这是一个活动邀，下面这是一个活动邀约的一个邮件。我们比较坏的方法就是像我们刚才简单说那种，就是你给我生成一个非常好的，或者高级一点邮件，那 AI 肯定不懂这事怎么回事，那如果我们想把这个事情让 AI 落地的比较好看的话，那我们需要比较完善去描述这件事情。

韩连昊 00:17:09.970 
首先第一个，邀请核心 KA 客户，这是我们要面向的对象，然后我们的目标是沙龙邀约邮件，OK，然后对象是市场总监，那这一条信息基本上就把我们对象目标讲清楚了。然后宇琦，这个是我的要求，因为我作为邮件，我要发给这些 KA 客户的市场总监，我肯定要让我的语气看起来，是我们很专业，同时又不希望让大家有太大负担，那这个时候肯定就是专业又不官腔，然后必须要包含的这些就是我需要提供给他的信息。

韩连昊 00:17:46.910 
OK，好，最后控制在一个字数以内，这个时候我们就能把这个需求描述比较清楚了。如果大家可以感兴趣的话，自己可以到我们文档里去试一下这个，就直接扔给灵感模式，然后让他来试一下这个东西能不能快速落地成一个我们想要的一个项，项目。OK，好，然后第二个的话，落地培训页，左边还是一个。不是很好的prompt。我们就跟他说，你要做一个好一点的培训报名页，我们也不知道是，如果是交给一个开发同学的话，或者交给我的话，我完全不知道他要做什么样的一个培训报名页，它里面都有什么内容。

韩连昊 00:18:21.650 
那不，如果我们想糊弄的话，可能就是，可以给他一个飞书多维表格的一个表单，然后就 OK 了，这个是非常简单，非常好糊弄的一个一个方法，可或者说在一个网页当中给他嵌入一个表单，也就是这样。那如果我们想让这个人，或者让这个 AI 能有很好的工作效果的话，那我们还是要把这个结构说得很清楚，比如说第一个，我们要面向运营同学。的一个什么样的东西，目标，我对这个页面当中的一些要求，说可能需要一些信息，风格是偏简洁，因为我们整个节奏都会比较轻松简洁一些，这样方便用户能快速 get 到我们核心页面内容。最后，我们这里实际上加了一条 PC 和移动端都要好看，其实这句话写得不是很好，但它给 AI 的一个信息就是我们要做移动端适配。对，所以说这里我们会这么说。OK，好，那翻译成我们 prompt 的结构的话，就是理解为第一个是我们要做一个页面，还是说做一个某一个具体应用？我们要给谁去用？目标是让对方理解你一个什么事，还是说你要给他承载一个什么样的信息？还是让他做一个什么样的一个事情？我们要把这个事情讲清楚。

韩连昊 00:19:41.920 
第四个就是我们这个页面当中都需要包含，为了让对方完成这些动作，我们包含哪些模块？或者说一些具体的信息。 AI 才能明白，哦，我们都要做，他要做哪些事情？接下来是我们的风格，风格的话我们可以简单描述，比如说可能简洁、专业、活泼、高级，这些都是很常见的。就根据大家需求来去生成，然后这轮先不做更复杂的能力，这一部分是指就是我们先只生成前端可用的一些页面，而不是生成一个非常复杂，上来就生成一个非常复杂的一个应用。这会极大的加剧一个 agent 开发的难度。

韩连昊 00:20:23.930 
对，因为我们如果想把数据库审批登录还有 AI 生成等这些能力结合进来的话，它会有一个比较重比较深的开发过程，你可能要针对很多后端有一些很精细的调整，那这个时候我们留到后面。嗯，好，OK。我们来讲下。一个我们比较常见的 SDC 这种方法，这是 prompt 的一个升级，就是最开始我们让 AI 做明白一件事情的话，最开始都是依靠prompt，就是像刚才这样，我们会写好一个题目，让它来去生成我们对应的一些内容。

韩连昊 00:21:04.990 
那如果我们想让它有一个更加规范，或者说实现一些类似数据库审批登录或者 AI 生成等支持能力的时候，我们应该怎么样去做，能让它做得更好？那我们就要提一下现在的一个比较好的一个范式吧，书，或者说是一个给 AI 提需求的一个范式。我原来是 vibe coding，就是我们直接拿 prompt 来去跟它讲。接下来的话可能就是 SPEC coding，就是我们要跟他按照我们的五步流程方法来去逐步跟他讲清楚，我们整个事情在讲，我们整件事情要在做什么， AI 要去往哪个方向去执行。大家可以先简单过一下这个图，会有一个直观的感受啊。首先先是理需求，定义标准，才能顶上边界。第三个就是理清楚任务，因为我们已经有需求了，有了边界了，那我们是接下来要把任务进行拆解，第四步，OK，我看有同学有问题，我最后统一留出来一些时间来去问，来去回答吧。第三个是task，就是我们要把任务理出来，让 AI 知道我们每一步怎么完成这件事情。第四个就是by，就是哦。我们觉得这是 OK 的，他去 run 就好了，他直接开始跑就好了。

韩连昊 00:22:19.670 
第五个是接下来看，就是让他产生出来这些代码是对我们来说是有价值。OK，我们可以来试一试啊，我下面拿一个妙答做了一个简单的一个页面，大家可以看一看我，对，逐步去详细拆解。我用稍微简单一点语言讲的话，就是第一个我们所谓的需求，就是我们别先着急搭出页面，把我们要做什么应用，解决用户解决什么样问题。那这个就是我们第一步一直在讲，就是我们一个好题目的结构应该是什么样子的。

韩连昊 00:22:52.950 
OK， SPEC 这个部分，我们会看到，我们需要把页面、模块、表单字段、数据留存、分享方式，这些经验受限写清楚，这个实际上是我们最后这个进阶能力部分，我们要讲清楚，我们实际上后端当中要实现哪些工具或逻辑。OK， Task 就是我们针对前两条，我们已经理清楚了，我们都有哪些活要干了，第三条我们就给他派。这个时候我们肯定要有一些区分，比如说一轮让妙答先改一个目标，二轮的话再让他去改下一个目标。最好是有一个上下文的管理。比如说我，就拿我这个页面来讲的话，如果我想对这个页面进行细化的话，我应该会让他在活动亮点这块可能会加一些更多的一些，比如说活动类似那种白板那种的活动窗口，我可能会贴一些活动照片上来，然后我嘉宾阵容这块我可能会对接一下后台的数据库，而日程这边我应该也会做一个更复杂的一个对接方法，比如说我可能会把实际的活动数据拿过来，然后变成一个可复用的页面。

韩连昊 00:24:04.070 
那整个这三个部分，每一趴都值得我去派一个新的妙搭窗口。或者说用一个独立的对话窗来去跟他聊清楚这个需求是什么样子的，方便他去更好去把这件事情搞明白。好，这就是 task 的部分，我们需要把这个事情拆清楚，按照板块去给 AI 派下来。然后第四个就是apply，就是我们要允许，我们要我们可能要去喝杯咖啡来等妙答去生成好一些结果，然后最后我们来review。OK，好，最后 archive 这个部分就属于我们 apply 之后加上 review 之后的一个结果了，就是我们都完成上面这些工作之后，我们应该还会持续进行微调。那我们可能从这里开始，就是 apply 开始之后，又重新遇到新的问题，又回到第一步。然后。然后再再继续去看这些模块怎么样去拆解，然后再看任务怎么样去拆解，直到我们觉得它变成了我们的archive，就是我们团队可复用的一个应用的时候，那它能变成一个稳定的产物来供给给大家，或者供给到公司当中，要持续有一些价值上的产出。大家可以看这个东西看得更仔细一点啊。

韩连昊 00:25:16.090 
五个步骤，你们要想清楚，说具体，拆小块，它就是 AI 和我们一起做，最后 archive 就是我们要存起来这件事情。这里会讲得比较深，比较细，我们简单过一下。首先我们要问问题，why？what？impact？如果我们一个需求为什么说不清的话， AI 只会把模糊放大，就是我们自己要想清楚这件事情怎么做，这永远是第一步。然后第二步就做完了没人知道算不算对，就是我们要把及格线型，就是我们刚才一直在说的标准。就如果他做完这件事，做这样一件事情的话，他的标准应该什么样子？边界应该什么样？我们怎么样让他自己能确定好他自己做的是好的？OK，我们再看task。就像我们在公司里自己做项目一样，对 AI 来说也是一样的，我们不可能把一个完整的 project 一下子全都扔给他，他自己不可能一下子全都完成好，就像我们的 leader 不会把一件，把一个完整的prompt。 project 去交给一个人来。做，这是不现实的，就是他肯定承受不住这么大压力。我们实际上还是把一个大的项目拆成了一块，一个板块，一个板块，一个板块，拼成一个完整的大的项目。对 AI 也是一样，我们拆成小块来慢慢做。

韩连昊 00:26:29.600 
第四个， AI 写得快，但人跟不上，那这个时候我们就变成了，就是 AI 负责干，我们负责review，我们只需要看他最后的关键性的结果性的产出，或者说是当他产出完之后，我们对有一些问题的再纠正调整。OK， Archive 这个就是我们 Archive 的部分，就是当我们有了一个产出之后。希望它变得更好的时候，我们就先就要 review 这个方案，比如说我这个页面，我觉得就有一些很多地方还能再做细化的，能变成可复用的地方，需要根据我们 reapply 之后，就是我们预算做完之后，我们对它的整个的状况的一个评审，觉得它哪里做行，哪里不行之后，持续迭代，最后变成一个可以复用的资产。

韩连昊 00:27:24.810 
诶，好，就是不是把，是多写文档，而是我们需要把问题讲清楚。希望大家能记住这五步啊，就是想清楚、说具体、拆任务。给我分起来，我们再接到新的一些妙搭或者开发需求，大家可以按照这五步骤来，就所有 Web Coding 场景实际上都是这五步。好，这里其实我是想设计一个小互动，大家可以看一下，如果感兴趣的话可以来写一下，因为我看时间还是比较紧张的，那我们先继续就往下讲。OK，好，这里其实是最重要的，其实也是我最想讲的东西，但是这块实在是太复杂了，不太好一下子讲明白，所以说可能我会稍微多花一些时间来去讲。我们刚才已经，我们简单过一下大纲啊，就我们已经知道开发范式是怎么样，是变的。接下来我们知道了我们怎么样去叙述问题，而且我们叙述问题在 AI 时代往往是非常重要的，它是我们最终决定我们产出效率的一个杠杆。对， AI 只是我们的一个工具，那我们怎么去定义问题？然后让 AI 去完成一些问题，确定好边界，然后让它自己做，这是更重要的。

韩连昊 00:28:44.530 
然后第三个，我们讲了一个范式，就是当我们想要让 AI 有一个比较好的一个产出的时候，那这个时候其实我们需要有一个范式来去约束我们这边思考问题的行为和规则。通过这套框架，我们能更好地想清楚我们的问题，怎么能去给AI，它能帮我们把这些事情产出好？这个是我们第三部分讲的，第四个部分，实际上这两个部分都能单独拆出来一个完整的块去讲。那我就更多时间放在这里，那第一个我想讲的是上下文工程。

韩连昊 00:29:17.920 
大家最近都很火的，应该就是风科奥，然后还有爱马仕，这个大家都了解，然后他们其实演出来一个课题是 Harness Engineering，那在 Harness Engineering，也就是驾驭工程，那在驾驭工程之前讲的是什么？在驾驭工程讲之前讲的很大一部分实际上都是 prompt engineer，还有 context engineer。

韩连昊 00:29:40.850 
prompt engineer 实际上我们刚才讲了半天这1、2、 3 三个大板块，实际上讲了半天都是讲 prompt engineer。然后第三个部分，这里来正式讲一下，就是在爱马仕以及 openclaw 这些东西出现之后，最火的 part engineer 就是驾驭工程之前的这个 context engineer。

韩连昊 00:30:00.110 
OK，大家可能第一次听到上下文工程这个东西啊，大家很容易把它理解成就是prompt，就是我们把 prompt 写得稍微长一些，其实不是，这个地方我还真的要把这句话原封不动给大家念一。就是上下文工程是在回答一个更大的问题，就是我要给 AI 什么样的背景，什么样的身份，什么样的任务边界，什么样的记忆和什么样的反馈机制吧，才能让它稳定的像一个合格的同事一样工作。就像我们会有很多新的同事会入职到我们自己的公司，或者说我们可能会，举个不好不恰当的例子，最近520，大家谈任何恋爱之前，我们都要了解对方这个人。那我们在了解对方这个人的过程当中，实际上就是获取更多 context 的过程。我们需要了解更多的信息，或者说我们需要对他，比如说家庭啊，出生地点啊，履历呀，或者经验啊，anyway，就是很多各种各样的信息。才能让我们形成对一件事情整体判断。而这就是我们 Context Engineer 的核心。那这个时候大家就可能会说，哦，我们可能会谈到渣男。

韩连昊 00:31:14.440 
OK，那这个时候为什么会出现这种事情呢？就是 Context Engineer 的问题，就是我们的 Context Engineer 和对方的 Context Engineers，就是我们对付，我，就比如说我和在座的每一个同学，我们的上下文是不对齐的，大家可能知道我是今天来讲这个课的老师，我会做一些妙搭，我可能会玩一些 AI 的工具，我，但是我实际上不知道大家是做什么的，或者说具体有什么样的一个岗位，可能大家就是。对妙答或者对 vibe coding 这种方法很有兴。

韩连昊 00:31:42.620 
兴趣，我会想听一听，有一些有没有有意思的东西来去分享出来。那我们这个，其实对于我们和 AI 之间也是一样的，我实际上就是我还是我，我是那个比较知道我们业务场景当中的上下文是什么的。比如说我要做这次直播课的那个讲授。那我大概就了解，第一个我的主题是妙搭，我面向可能有一各种各样的同学，可能大家会用到妙搭什么样的一个程度，听另外同学再跟我讲。大家可能对哪些东西感兴趣，结合这些上下文，我大概对妙搭的边界，还有我要讲的内容与边界有了一个判断，接下来我才会产生接下来的生产。

韩连昊 00:32:31.970 
整个我去获取到这些原来这些信息的过程，比如说就是我在跟其他同学沟通，包括我去看看群里大家在聊什么问题，再看一看过往讲过的哪些课程。我了解这些信息的过程，实际上就是我去获取 context 的过程。就像大家可能要举个不恰当例子，可能要去谈恋爱，或者说要去约会，或者说是干任何事情，或者出去做商务。做商务的沟通，我们都需要了解更多的context，就是我们需要更更多的上下文来去确保我们的行为能更符合当下的场景。

韩连昊 00:33:07.460 
对，比如说你可能知道那个老总他很喜欢喝茶叶，那你可能就会挑一个茶餐厅，或者说挑一个比较好的地方。能分享。这个地方其实我会讲得比较理论，到后面我们来仔细做一些提问。OK，先继续讲，先继续讲，我们现在已经讲过了context，就是实际上就是我们获取背景信息。包括完整这个项目所有事情的一个过程，那我们有这些更具体的信息之后，才有可能把一件事情做得很好。我直接把妙搭这个场景来给大家讲一下，就是如果我们直接把，把这个整个语境，或者把这个刚才这个事情，讲到妙搭上的话，我会怎么看说啊？就是第一个就是，其实是 prompt and leader 的很常见的东西了，角色设定，就是我们可能要去跟他聊，比如说有时候我就会我会和妙搭去聊，你能不能做哪些事情？OK，我就比如说我会就会直接问他，就你能不能开发后端？那我知道他能开发后端之后，他就能以后端身份来这个进行一个代码的开发，这是后端部分，那当然这是角色设定的部分。

韩连昊 00:34:25.520 
第二个任务边界，这个其实跟我们刚开始的这个 SPC 是有一点像的，就是我们确定好了这个任务的边界大概到哪里？比如说这个是前端的，还，我们是只做一个前端页面就行，还是需要把这个前端页面同时和后端的这些能力结合起来？这属于一个任务边界，然后哪些先不做？比如说数据库。结合登录权限，就像刚才这个事情一样，我实际上在嘉宾阵容这边完全可以把我获得的数据库接过来。但我没有接，因为我判断他的周期可能会更长，可能会遇到更多的，当然很正常，大家都会遇到bug。我可能需要改更多的bug，那我可能需要的时间就更多。但是呢，我们可能要衡量一下，他是不是真的会投产，如果他不会投产的话，那我可能不会改这东西，或者说再给我们 leader 看一下，然后他觉得OK，那我们才继续往下推。

韩连昊 00:35:21.110 
OK，我们回来。这就是任务边界，就是我们要确定好这个事情，他要做到什么样程度。如果它比较复杂的话，是不是要推到下一次，或者下一个版本迭代时候，我们再去做？第三个状态与记忆。这个地方是要讲了一个很重要的点啊，就是新建对话。我不知道大家平时有没有用一些 chatbot 一些工具，比如说我们在用豆包的时候，可能就是直接跟它聊，或者说我们在用 aily 的时候，我们会跟它聊很多问题。那它实际上会把它和我沟通的内容记录到 memory 当中。但是传统的chatbot，就是传统的对话工具是不带 memory 的方法，也就是说它记不住更多我们自己相关的一些内容。那这个时候我们新建一个对话，往往就是没有一个完整上下文的一个场景。

韩连昊 00:36:14.130 
对，那它能对我们 context engineer 有什么样的启发呢？当我需要进行不同角色之间切换的时候，那我可能，比如说我现在已经完成了前端的设计，比如说我现在已经完成首屏了，接下来我要进入到这个部分的设计，比如说后端部分。当我进入到后端部分，我希望它进行独立设计，然后让前端任务不要干扰它，那我可能会新开一个话题，然后告诉它你是什么样的角色，然后最后再让它进行后端的修改，然后这就是我对于状态还有 memory 的管理。

韩连昊 00:36:46.850 
好，最后的反馈回路其实跟 SBAC 那边有点像，但是它con，作为 context 这个部分，它和。哦， prompt 部分不一样的地方是， prompt 往往设计的会比较浅，它都是 by task 的，它是 by 任务去设计对应的 prompt 的。如果我们想做好一个 context 管理的话，实际上我们是按照板块拆好我们每个部分的访问回路，确定好他能不能做，逐步进行迭代的。

韩连昊 00:37:19.110 
OK。好的上下文工程就等于舞台搭得好，角色也很清楚，每个角色做的事情也很明白，以及如果他做错了，他应该怎么样去调整，就是一个完整的舞台，他能在上面比较好的进行呈现。OK，这里有个小互动，大家可以给自己的 agent 去做一些尝试。比如说当我给他一些决策，他会专注在某一个场景下的一些设计。我们也可以把它变成一个运营功能教练，你也可以把，你要再变成一个运营功能教练，你就跟他聊一聊我现在的话应该怎么做，这是 OK 的。

韩连昊 00:37:54.280 
然后最后你再把跟他聊过的这些内容，然后和他进行具体的沟通，比如说这个内容我很重新设计，我以，我让他是一个专家，或者说活动设计的专家，然后再去设计这个东西，他应该给我提供出来内容是不一样的。哦，你看这个地方我跟他聊，就是我可能就是就会和苗达很聊天一样，就是问问他一些问题，或者问他一些点，让他问他能不能做，那他就会去看他自己能不能做的，然后来去想办法去帮我实现，那这时候你就他就跟我申请。要将灵感模式升级为应用模式。好，我们先继续回来。下一个部分也是个大块头啊。其实这个地方很深很深，但是这一次我们就不讲太深了。讲过了 context engineer 之后，讲过了 context engineer 之后，接下来我们讲的实际上是 AI Agent 部分。 AI Agent 部分实际上就属于 harness engineer。那其实从前到后，我们从 prompt engineer，就是提示词工程，再到上下文管理工程，最后再到驾驭工程，这三个部分都讲好。都大概都能过过来， AI Agent 这个部分，其实我最想讲的点是这样。

韩连昊 00:39:06.080 
我们在 context engineer 这部分，我们实际上已经遇到了一个问题，就是这，我希望前端就只有前端的，更多的是有前端的一些信息，后端就是有更多后端的信息， UI 就是有更多 UI 的信息，产品就是有更多产品的信息，那实际上一般会有四个角色，他们应该是独立开来的，产品的设计最好不要和前端和后端混在一起，不然他很容易迷失在他自己现在放的执行决策当中，因为产品同学要从功能角度，还有。

韩连昊 00:39:43.350 
市场这些角度来去综合看一个东西是不是OK。那前端可能更多的需要关注在前端代码层，那后端同学可能要关注在整个逻辑的设计， UI 同学可能要关注在前端设计的是不是好看，它应该是包含了一个完整结构的。那这个时候如果我们想做一个非常复杂工程的话，我们这样进行不同角色上的拆解，往往是会对它的上下文管理有一个比较好的效果。因为它在这个上下文下只会做它自己的事情，不会让它去，参与其他更多角色正在做的事情。那它就不会产生上下文的干扰，你比如说。我之前做过一件事情，就是我先，我就把所有东西都对在一个对话窗口里做了，我会发现时间长了它就会失焦，它会忘记自己之前做过的很多事情。比如说产品我跟它提了一个需求，它把这需求拆完之后，提给了，它就直接在下面就按前端方法和后端方法把东西都补齐了。这个时候我觉得这个需求不太行，它再回去再改的时候，效果就已经变差了，因为它的记忆长度不足以支撑它有那么强的一个效果。

韩连昊 00:40:57.080 
核心还是来源于 AI 本身的这样一个特征，因为它用的是 attention 的机制。他只能注意到有限的窗口，而不能注意到无限大的窗口。哪些是重点，是需要我们根据角色来去做区分的。OK，这里实际上我们想讲的，我想讲的就是这样子一个结构，就是我们刚才已经知道角色设计的框架，就是我们通过 context 可以区分上下文这个方法，上下文这个方法下，我们需要通过角色来去区分不同的上下文。那 AI Agent，就是多 agent 的 coding 方法，其实支持这样的一个方法，就是我们可以给每个 agent 去设计它自己的上下文。这样的上下文管理就能直接独立开来，我以这个应用开发的模式来去简单讲一讲这东西是怎么回事。

韩连昊 00:41:49.110 
这是一个比较复杂的应用，我先简单讲一讲这个用。刷新一下。诶，OK，好。这是影视飓风那边的一个需求，他们想做一个提词器，比如说我们点进去之后，他就能根据我们的语速来去，他就能通过一个 AI 的方法来去跟着我们的语速来去，跟我们自己，嗯，跟着我们的语速来去往前自己跑，因为他们自己有很多拍摄的一些场景。那我们做这个需求之前，对于前端来说的话，可能就几个简单页面，首页，对吧？我们把所有稿件都呈现出来就好。我新建稿件，我可能需要一些新建的能力，还会有些设计，设置的能力，这就算基本功能了。进来之后我可能会有一个呈现页面，这是前端同学要做的。是，当然呈现页面我肯定还包含了一些滚动方法，跟字的方法，还有像这种的这个这个叫提词器的这个方框啊，就是确定提词器位置的一个方框。这些大概是前端同学要做的，那后端同学要做的可就多了呀。

韩连昊 00:43:01.950 
第一个我们看这个页面，他肯定需要把自己的数据存起来。接下来他还需要做一个处理，就是对音频进行个处理，因为它是支持语音识别的。我需要有预置好一个模型，当用户发过来语音的时候，用户开始语音的时候，我支持获取麦克风，把麦克风的音频切成小段，转给语音识别的模型，是根据生成的文字来去往下进行匹配。前端同学只负责渲染，后端同学负责整个的语音就识别的过程。

韩连昊 00:43:36.220 
其实看这个工作其实是蛮复杂的，我当时想就是需要前端和后端拆开。稿件的编辑也没有实现哦，你看像这个。我提的这个需求，大家可以看到，我让他也实现一个编辑的一个实现，这就属于你算是错误案例吧，因为他是没有更多上面的上下文的，虽然我可能是从这边拿过来的，但是我在这边进行直接聊的时候，他，我并没有跟他补充齐全完整的背景，但是我们可以从拆解的角度，从 Multagent 这个角度来去看一看这件事情是怎么回事。

韩连昊 00:44:12.930 
我这边实际上聊的实际上是一个前端和后端打通的一个，就是和后端数据库打通的能力，就是稿件编辑，实际上就是在前端我需要呈现来一个。诶，不支持编辑，比如新建一个吧，点三，点三，好，保存。诶，比如他现在已经写在这里了，这个同学问题问得很好，我最后一起说吧。

韩连昊 00:44:42.470 
我说我的编辑能力就需要实现，因为他需要和我的后端能力打通。因为我再保存。诶，那他需要和我的后端能力实时打通，那这个时候他应该是 API 开发的问题，这里其实属于一个后端已经实现了接口，但前端没有接对这个接口的方法，因为他需要在页面上呈现，呈现完之后需要把这个确定的这个接口和后端进行一个连通，才有可能把这方法实现出来。

韩连昊 00:45:06.880 
OK，他，我这个时候跟他讲了，我说搞件功能没编辑没实现，我让他去搞一下这个功能，好，他开始干。呀，对，OK，你看刚才那个功能就 OK 了，我接下来又继续说这个问题，因为我现在基本上都是 by 前端这个场景下，我去看有哪些需要去调的。接下来是什么呢？接下来这就属于完整的后端链路了。随便弄，随便放个地方开始讲吧，找一下，从这开始。点，是吧？从这开始讲吧。

韩连昊 00:46:02.070 
这是这样的，我们刚才已经说了，如果我们想做一个 AI 语音识别的，我们需要在云端部署一个模型，然后让它能进行识别。我们还需要处理从浏览器获取语音，再到它处理转成文字之后，再到告诉前端它应该渲染到哪个数字，这样的一个完整方法。那其实这里实际上解决的是模型识别语音的问题，最开始识别有点慢。然后我就一直在和，因为这个语音识别实际上是后端，它和前端的关系不深，那我一直在进行微调的部分，实际上就是告诉它。

韩连昊 00:46:39.220 
我在识别，比如说切片，就是正常说话的时候是，我们是正常一直在说话的，但对于麦克风或者对于电脑而言，它不是这么理解这个事情的，它是直接把你所有东西都录下来。那我设计方法就是每 200 毫秒做一个切片发给模型，每 200 毫秒做一个切片发给模型。那这个时候我们一直在聊，当我们进行这个方法的时候，比如说进行 200 毫秒这样请求的时候， 100 毫秒的请求效果会更好，因为它的切片会大一点，那它对语音识别效果整体会好一些。

韩连昊 00:47:16.750 
对，这是当时我做的一个比较细节的调整，大家大致应该可以 get 到，我为什么要用这个方法？通过妙搭应用模式的专家模式来去做这种。分项的治理，是为了更好的管理好我们的上下文，同时让多个任务能同时去搞，那这个时候就能有快速落地效果的能力。OK，这个就是 Mult agent 这个部分，哦，其实这个问题大家可以想一想啊，结合我们刚才已经讲过了prompt，就我们已经设计过prompt，然后我们又设计过context，就我们已经设计过上下文了，这个时候如果我们想让，我们想妙搭去自己做一些自己的事情，就是做一些我们的事情。

韩连昊 00:48:06.150 
我们在一个场景下应该怎么去拆？比如说就拿这个自动生成加复盘本周运营，复盘文档的一个系统，那我们应该拆哪些角色？然后他们接下来都应该做哪些样的事情？这个大家要多思考，就是类似这样的问题，我们要多思考。自动生成这肯定是后端的事情，复盘是数获取数据的事情，那个复盘本周是获取数据的事情，然后运营文档实际上是 AI 模型的问题，那这几个部分怎么样去有机拼在一起的？嗯，大家可以好好想一想。嗯，对。比如说运营复盘，复盘运复盘文档这个东西是需要 AI 的，但是对于 AI 或者对于妙搭这边应用来说，其实它是后端的，它需要调端，调调用后端的插件方法来去生成文档。那它可能就是前端前端来获取数据，再加上两个后端的部分，来整体构成整个方案。OK，好，我们收述一下啊，从 prompt 再到context，再到harness，我们怎么在妙搭这个场景下去落地我们这套范式？你这就简单过了一下，就是出题人更值钱，这实际上是怎么样下好下发好任务，就是 prom 设计的基础，就是我们要先想一想问题是怎么回事。

韩连昊 00:49:38.680 
接下来我们有一个范式来讲，就是我们这个 prom 在设计过程当中，我们大概都需要包含哪些板块？然后这个问题怎么样去把边界定义明晰之后，才有可能让 AI 有一个比较好的产出。然后最后是我们浅入浅出地讲了讲上下文工程，还有 multagent 这两个部分，就是在，它其实实际上就是在回答，就是当我们有了非常复杂的场景，当我们有一些很难搞的场景的时候，我们怎么能让它去稳定地跟我们。一起产出。OK，首先在妙搭页做一个选择啊，其实我推荐大家都去多玩一玩这个灵感模式，这玩意确实挺好玩。我这些东西用的全都是灵感模式，我做了一堆东西在上课。大概他们都是独立自己去跑的，大概总共也就花了，每个花了 10 分钟左右，那他们一起跑的话，可能我也就等在同一个时间，他们就能统一给我跑出来一个结果了。

韩连昊 00:50:39.240 
OK，然后第二个是应用模式，适合我们有。花了多少token？我还真没看多少 token 呢，一会我去看一下。应用模式适合我们做比较深入的业务场景。OK，我们回到首页来看一下。像灵感探索，我们想快速落地一些页面的时候，我非常推荐我们用灵感模式来去快速落一些地。应用开发的话，我刚才用的这边的多任务的方法，是专家模式。它是支持我们有非常完整的对于代码的管理权限，以及包括多个 agent 同时并行的一个方法的。OK，好。

韩连昊 00:51:28.260 
大家可以，哦，对对对，这个地方，还是回到这个吧，还是回到这个吧，刷新一下，这边就是我拿灵感模式给他了一个，按照我们的 FEEC 方法来去快速搓的一个 demo 页，也没有给到更多的一些内容。当我想把它变得更好的时候，比如说我想给它加一些数据能力，嘉宾我给它加个数据表，以后这个活动我就 by 活动去运营就好了。

韩连昊 00:52:00.220 
可能我最后分发是这么分发的，就是我给一个活动代码，然后我对活动有一些具体的信息，活动会关联一些这些导师，然后里面包含了一些历史的评论，这个东西就能变成一个可分发的一个内容，我只需要根据我的。想法来去分发我想要分发内容即可。那这个时候我就需要把刚才这个灵感模式转换成应用模式，在这边我们把它转换成应用模式，让它来帮我们去开发好对应的后端能力，以及把数据库接好。

韩连昊 00:52:34.490 
ok。如果我们大家知道我们一开始就做的是正式的业务工具的话，也可以一开始就在应用模式里开始对话。在妙搭里有我比较常用的四种起步方式，这个大家可以快速过一下，就是我们可以先把效果做起来，就是前端页面，然后再把后端能力补齐。这种的应该是直接直接应用模式的，这一般是开发同学或者比较复杂应用，有复杂业务才会用一些应用应用模式。推荐大家想好，或者说我们想好这件事做之后，再去用这个方法，就上来直接用这个方法。

韩连昊 00:53:17.880 
快，OK，这个做同款大家可以看到这边有好多啊，在市场上我们有好多已经做好的应用，大家可以直接用。OK，我一会一起回答吧，那个导入已有项目或多维表格，这里，导入多维表格或已有项目，这都是 OK 的。好，这里其实还有一个重点，这也是我这堂课讲的最后一个重点。哦，是妙搭的五大黄金法则，我把这页面拖得稍微宽一些，我们再来看。首先第一个是黑板擦法则。这个对应的是我们刚才讲过的 context engineer，就是我们需要管理好上下文，避免就像我刚才提到的，产品的同学，产品同学和前端和后端同学在同一个聊天框当中出现，我们希望它是隔离开的，这样它对于一件事情的了解才会比较清晰。重点啊，就是大家不要试图在一个对话框里完成，做完整个淘宝，这是不可能的，所以给人来说也是不太可能的。

韩连昊 00:54:29.010 
OK，好，我们再看第二个，餐厅点单法则。诶，这个就是我们一直在强调的，就是我们 SPC 这边一直在强调的结构性的方法。我们要延，我们要明确定义好我们的验收标准、场景和边界。当我们定义好这些问题之后，他才有可能比较清楚地给我们一些非常好的一些产出。

韩连昊 00:54:57.940 
第三个，装修工法则，要具体，不要还要。这个怎么说呢？就是我们一直在讲的，我们要把我们的需求按任务去拆解得比较，按任务项一个个地拆解出来，而不是告诉他，哎，你给我生成，我还要一个什么语音实时语音对话的方法。他是不可能直接搜出来的，我们可能需要引导他，告诉他，哦哦，我们先跟他聊，就是你觉得如果需要实时语音识别的话，你觉得需要什么样内容？有什么需要我来帮你的？我可能会跟他聊一阵，我确定好技术栈之后，我才会继续往下做开发，就装修工的研究，不能说我随便给他一个prompt，就弄得好看点、大气点，他肯定很难一下子达到我们的预期。

韩连昊 00:55:48.930 
取餐器法则，妙搭是不支持长链接的，现在只支持 HTTP 请求。这属于技术层的一个部分，就是没有一个更复杂的一个对接的方法。最后一个，这是一个安全问题，就是大家如果想要确保自己的应用在业务场景内落地得比较好的话。最好还是要关注一下自己的源安全，让前端只负责看，前端只负责呈现结果，而所有的运算逻辑，包括请求方法都保存在后端，包括我们的token。大家这个部分可以自己看一下。

韩连昊 00:56:33.470 
我看一下，OK，这个地方我稍微讲一下吧，因为刚才也看到评论区有同学问了，如果想进行局部修改的话，比如说这个东西我想局部修改，我推荐你用这个东西，就是点编辑，然后告诉他我哪个地方想要改成什么样子，比如我要改的全部稿件，你也可以直接改，点到这里面可以直接改，全部，我给它写俩，打个句号，好，我就不提交了，因为这个我不要真改。改的方法是这样是 OK 的，或者你可以这样，截个图，我截个图给他发一下。诶，好，我告诉他那个，对，那这个方法就能直接做局部修改。我看一下后面还有没有什么重点。

韩连昊 00:57:30.440 
我看一下啊，从回滚这边的抛出重点，这这些大家可以看一下，就是我们会用 AI 工具，只会开车，如果能写好好的prompt，做好好的 context engineer，最后再到 harness engineer，整个链路都做好之后。才有可能真正的让 AI 帮我们去做事情。大家不要指望着 AI 直接帮，直接替代我，这是不可能的，短期内是不可能的。所以说我们还是要做很多脑力工作在里面。对。

韩连昊 00:57:59.670 
我们在让 AI 做好一件事情的时候，我们永远要先问自己问题，就是我要做什么？什么算做好了？好，大家可以点下面这个网页，这个现在动手去试一试，然后来妙搭去做一尝试一些自己的小应用。我看时间比较紧张呢，现在开始答疑，我看看评论区有什么样的问题，我看一下啊。

韩连昊 00:58:34.950 
一键修复是消耗点数的。精确定位这个问题我刚才已经回答过了，大家应该知道我们怎么样去比较精准地定位了。OK，三方系统对接肯定，这肯定是OK，这很简单。你直接把文档甩给他，应该就行，这个对接接口的应该方法很简单。可能会遇到问题就是用户鉴权的问题，你可能涉及到 APP ID、 APP Secret，还有 Token 这些问题。你要帮他提前解决好鉴权的问题，才有可能对接得比较清楚。这个跟下面的 API 的方法是一样的。这个反了，就是 aily 可以调用妙搭，但是妙搭不能调用aily。这个你，上下文工程。

韩连昊 00:59:19.820 
上下文管理的这个部分，目前我没有准备好材料，我看看后面能不能准备一份材料给大家看吧。嗯，没听懂这个问题是什么？妙搭。技能包。这不是一个东西。 OpenClaw 是OpenClaw，它是一个 agent 框架，那你用这个妙搭，实际上它是一个开发任务，它们不是一件事情。嗯，这件事看你怎么去做，如果你是个老开发的同学的话，你会发现。就是你能把一件事情拆得很细。他们就算前后是耦合的，但是你也可以把他们拆成不同的构件，然后你中间耦合的代码，比如说你的胶水代码，然后再让秒答去写，这也是 OK 的，你可以做平行开发。因为前端和后端本身就是耦合，他们肯定是存在依赖关系的，但我们一般还是去习惯的会把前端和后端一，嗯，拆开，然后后面再去联调，其实实际上就是这样的一个方法。

韩连昊 01:00:27.410 
ok，我真没看，秒答的审批流程，有短板没有？嗯，主要是看我们能不能创造出来这么复杂的审批流的这个结构，还是看我们描述的方法。 API 的数据，这个我们刚才讲过了，就是你需要比较好的 API 的文档才能搞定。怎么样设计好？这上下文到时候后面我就看再能不能准备其他材料来解决这个事情。 Coding Skill， Skill 我晚点看看有没有，市场上有没有。对的，这个同学说得很对，就是如果不懂代码的同学可以先有灵感，后续我们再考虑数据如何接进去。

韩连昊 01:01:13.580 
对接，龙虾做对接。我听懂你要对接什么呢？你是要写开放API，然后让他看数据吗？那你直接开放 API 就好了，这个妙搭是支持的，在这。有开放 API 的方法，你可以直接把这 API 开放出来，给妙搭看就好了，他就知道，给那龙虾看就好了，他应该知道自己接的。双视频应该短期就不会支，应该是不会支持的。看一下要走哪里呢？哦，这个我可以问一下产品同学，后面应该是有机会，目前不太确定啊，AG， A to A 的沟通在妙搭里怎么实现？怎么组队？ A to A 的沟通，你就是这个专家模式可能还有点机会。

韩连昊 01:02:01.140 
你最简单的沟通方法就是你直接在本地写个文件出来，就是你写个 Markdown 文件来去描述你整个项目，来去做交互，这个是 OK 的，让他们统一在同一个文件当中进行交互就好了。因为标准的开发文档是包含了一些 API 接口的使用方法的，就是后端后端会写出来这些方法，然后前端看后端这个文档就可以了。这时候妙搭实际上已经帮你把这些 API 的方法实际上帮你已经包差不多了，它不是一个没帮你包好的一个东西。对，基本上他这个，他们在这边就基本上就交互了，所以说前端和后端是能连起来。

韩连昊 01:02:42.380 
啊，字段一直不对，哦，字段一直不对。你是说外面不对，还是说里面不对？里面不对，你可能是要改SQL，你可能改库。然后可能要改很多地方的代码，这个确实是需要的。

韩连昊 01:03:02.880 
这看你后端怎么设计，如果你都传到了后端的话，那你肯定是可以看的。我会叫，后面应该会发出来。我们要打双视频，这个不会有， token 验证无法被，托管工具，这个应该是没有。但是我们会加一些小工具啊，这个这些小工具会加，这有一些小工具在，你可以直接用这些。

韩连昊 01:03:28.870 
我看一下，做agent， AI Agent，暂时不支持，我推荐你用飞书，如果你关注飞书比较多的话，我对于 agent 支持的效果应该会越来越好。你要看，这个你要看飞书开放平台的 API 了，如果你想把审批能力集成到妙搭里面。如果修改了数据库的数据，不可能前端更新的。啊，这个自动更新的，你数据库修改了，前端就更新了，这没什么可以，老是。现在应该没有其他问题了，我就是你应该可以看到投屏，我应该是拼到这个位置上才会去回答一个问题的。看大家还有什么其他问题吗？没有什么其他问题的话，我们时间应该到了。看看佳宁有什么补充吗？

张佳宁 01:04:20.069 
嗯，好的，感谢我们连昊老师哈，刚才也有同学说我们本节课太干了，的确看到这个满满的文档，大家应该知道从理论到实战啊到案例都非常的丰富。稍后呢会把所有的回放内容放到这个文档里边，大家可以再去细细品味一下整篇的文档和相关的内容。好，我这边呢可以再给大家讲一下，在本次呢，也就是 5 月份我们 AI 学院的正式直播课已经结束了，但是呢在下周一还会有一场 AI 开放麦的直播课哈，并且呢我们 AI 开放麦的直播会持续进行，所以呢欢迎大家守住我们的这个应用，现在呢也可以直接点击这里的链接呢，直接预约我们的下一场直播课。会进行一场关于场景的一个搭建的实战，也给大家演示。

张佳宁 01:05:13.539 
好的，那么我们本节课呢就到这里就结束了，感谢我们的连昊老师，也感谢同学们的参积极参与。后续呢有更多的问题，欢迎在后续的直播课中持续地提出来。有同学说把问题收集一下，好的，后面呢我们会可以请连昊老师把，本次刚才大家关比较关注的一些问题，可以集中挑选几个精品的，给大家，是不是能够补到这个文档中？好。我们后续也会关注一下大家的提问。好的，那么我们本次的课程呢，就到这里结束了，感谢大家的参与，期待我们下周一再次见面。好，同学们再见了！