屎山代码如何使用ai开发需求

用 ai 来写代码，会不会让你的项目成为一座死山呢？昨天改 bug 改到凌晨三点多钟，今天起来一行一行的看代码，越看越眼熟，就那个感觉，怎么说呢，就是他每一行都没有问题， 但是合起来就是一坨屎的那种感觉，一满屏的代码变量名都非常的规范，然后就是非常清楚，逻辑清晰，但就是跑不动 那然后我没办法了，我就去问之前写这个代码的这个同事，他挠挠头跟我说就是我当时也没怎么看，大部分都让克劳去写的， 我气的当时就把烟掐了。就按我们的经验啊，一个合格的程序员，他写一千行代码大概需要三天两天是想清楚怎么写，写给谁，要达到什么效果，改用一天。 那现在你用 ai 之后呢？效果是就效率确实是提高了很多了啊，你可能半天就解决战斗了，然后其中四个半小时你会花在想怎么写，写给谁，起到什么作用上面然后有半个小时是拿来改的，那真正花时间的是你想清楚 这段代码解决什么问题。呃，这么写以后会不会出问题？然后有没有更简单的写法？这些的框架上面，这是最花时间的。 那以前写十三的人就是你写出来东西一眼看出来就是十三，很很清晰的。但现在用 ai 写的十三呢，就面上看起来像模像样，但底下全是坑。

用 ai 写出来代码又乱又差，今天教你一招，让代码又清晰又好改。很多人用 ai 上来就说，帮我写一个 app， 然后 ai 给你几千行代码糊在一块，你想改个按钮都不知道从哪里下手。还有人说，我有清晰的需求文档，可以直接开干了吗？也不行。为什么？ 因为需求文档是告诉 ai 要做什么，但是不能告诉 ai 它怎么组织代码， 所以 ai 不知道哪些代码该放一起，哪些代码该分开，最终写出来的代码就是一坨屎山。正确的做法是，先让 ai 和你一起做架构设计，先定好项目的目录结构再动手。第一步，和 ai 一 起探讨目录结构，比如 page 放页面， components 放字典， service 放接口， tutorials 放工具函数，先把文件夹的目录结构组织好。第二步，定好每一个文件的功能， 首页是首页，登录是登录，支付是支付，边界清晰明了， ai 就 不会乱塞。第三步，让 ai 一个模块一个模块的写，先写登录，再写首页，最后写支付，每个功能都在它该待的位置。为什么一定要先写架构呢？因为架构就是地图， 没有地图， ai 只能瞎跑，有了地图他才知道往哪走，代码就有了秩序。后面你加功能 改 bug， ai 也知道去哪里找。所以一定要把你自己当成架构师，把 ai 当成蚂蚱，先有骨架再长肉，没有骨架的代码就是一坨烂泥。关注我，下期教你怎么让 ai 一 次只做一件事！

你用 ai 写代码时，前期一定写得很快，很让人兴奋。但项目一大，改的次数一多，各种 bug 就 接踵而来，改掉一个 bug 多出来三个，是 ai 还不太行吗？不完全是，因为其实很多人类程序员也这样，只是他们没 ai 写得快。 那么怎么避免呢？这是一个要花很多时间才能讲清楚的问题。最近几期，我会用小白也能听懂的方式，介绍解决 ai 堆屎山代码的两位古方良药， t d d 和 b d d。 然后我会以我自己的游戏最近的一次新功能开发为例，演示一下如何在 cloud code 中使用大神写好的 skill， 实践它们。干货内容制作不易，觉得需要先点个收藏和关注吧。 今天这个视频先讲 t d d， 它是 test driven development 的 缩写，旨意是测试驱动开发。它在上个世纪末被提出， 通俗的讲就是先写自动测试的代码，再开发功能。举个例子，你要做个功能，把一堆输入的整数排个序。你刚学编程时，符合直觉的做法是先把代码写完，然后试试输几个数进去，看看结果对不对是吧？ tdd 的 做法是先写测试代码，比如像这样，然后运行，当然这时测试是跑不通的，然后测试代码不准动了，写代码实现真正的功能，直到所有测试都通过。嗯，你这个功能就算完美完成了。 这么做的好处是什么呢？首先是在一开始就定义清楚了什么样的结果是对的，代码开发的要求是绝对清晰的，程序员没有任何模糊的发挥余地。 然后就是以后改完代码，只要运行一下测试代码，就知道有没有把之前约定的东西改坏了，最后就是能写出测试的代码，天然就是架构良好的代码，避免使删。 听起来很美好是不是？这不就是用 ai 写代码最想达到的效果吗？但我要告诉你，在国内，以前很少有马农真的会这么干活。为啥？ 一是因为这个方式本身非常反直觉，学习曲线很陡峭，很多程序员在一开始面对一个空文件是写不出测试代码的，而且很多需求本身有模糊性，测试用力就很难写。 二是在国内的互联网公司，需求本身变得极快，可能你今天写的十个测试，明天就没用了，这就是浪费。三是因为这个办法前期会让开发变慢，你那些测试用力也要手敲啊，在你那个不写代码的老板的眼里，你这就是效率不行啊！后期测试方便， bug 少这种鬼话老板不信啊！ 你要是这么干活儿，就会眼看着坐你旁边的同事一年就晋升了，然后给你留下一个史山项目，让你这个低级程序员继续帮他维护，请把真实打在公屏上。 但是这件有些反人类的事，对 ai 来说却是非常轻松和丝滑的。把需求描述转成测试代码这件事， ai 写的那可太快了， 照着测试用力写代码这件事， ai 一 看那简直是要感动得痛哭流涕。终于不用去揣测你们人类那种一句话能有十个意思的垃圾语言了，你这点事我分分钟给你干完，还都测。对 对于指挥 ai 的 你来说，去 review 测试用力是不是符合你的意思，也比看那堆晦涩难懂的代码容易多了，于是你和 ai 一 拍即合，就这么干了。 所以以后用 ai 写代码，不要让它先实现功能，再去不停的测，不停的改了。先让它把测试的代码定义清楚，每个用力写上中文注示，然后你去看是不是符合你的意思， 最后让 ai 去实现真正的功能代码，你会发现它在写正式代码时，会不停的测试出错，不停的改，就这么把活利落的干完。 但是光有 tdd 还有两个问题，一是所有测试运行通过是不能和产品功能符合要求划等号的，测试代码和用户需求间还有一条红沟。 二是你去看代码 review， 测试用力还是有点累，能不能再轻松一点，这就是下期要介绍的 bdd， 也就是 behavior driven development。 再下期就是这两种方法的 cloud code 的 实践，点个关注，我们下期见吧。

e i 写的是时尚代码，这是程序员的最基本的反应，就是一个保护性的反应，他就是不希望 a i t 太大的工作呢。那么其实 e i 写的是时尚代码是非常常见，但是人写的时尚代码 也是非常常见，就我们跟跟踪一些什么的 solid 和一些 system design 这些东西以后，最终还是写出来了一些一坨屎的代码。这个，呃，你也就是可能知道，就是我们可以做一些 refactor， 掌握这个 refactor 的 时间是 百年左右都有，对吧？那么 ai 比你做的快多的多的多，他有可能写出来的是上代码，但是他可以写的更快，所以说，呃，说 ai 写的是上代码，这是感觉是不是非常对的？呃，但是你是控制太闲了，哼。 然后呢？呃，其实他就是最重要的东西，代码是根本不重要，你完成了这个业务的需求才是比较关键，这个代码能不能被就是你的后面维护的，也就是看这个代码的几段，如果这个代码是要需要更多客户，那可能就是你要 多谢自己叫 ai 维护他一下，呃，如果他不需要维护了，那就直接扔下去了就行。这个东西现在是不是非常关键的？时尚不时尚代码，嫌弃 ai 系的代码，这个东西已经很过时了，你再嫌弃他的代码，那为什么你还在呢？

很多人说 ai 能不能重构老项目，看有多老，有一些不行，就比如说我们有激进派，有守旧派，需求里面也有激进派以及守旧派， 真正解决问题的方式是干掉守旧派，也就是说砍掉那些死山需求，而不是说干掉死山代码， 有一些代码完全是可以推导需求重新梳理的，但是如果你非要拿一个不合理的需求用 ai 重构还是用真人重构，它都是写的。所以说解决问题的本身并非于需求实现，而是需求提出， 也就是说解决提出需求的人，咱们说的是更变一下需求，有没有更好的实现方式。百分之七十是 项目做失败的原因，百分之七十是需求不合理导致的。有一些项目他有百分之八十非常好实现， sop 非常正常的需求，但是掺杂了某一些领导的心中幻想，百分之二十的无理需求， 但是他说的算，也就是说百分之二十的幻想干掉了百分之八十的梦想。答案就是最后面谁都不要想，相信做软件的，做外包的，还有就是做内部项目的，都会遇到过这种无理需求， 但是因为职位或者沟通方面没有办法解决。说的不好听点点就是所谓的面子工程，但是怎么办呢？做软件研发， 为了交付，为了成交，为了解决问题，可以满足你的面子工程。也就是说在百分之八十的好代码里面掺百分之二十的 set， 就是 就的这百分之二十的 shit 臭味熏陶，把这百分之八十的好东西全部变成了 shit。 这个就是常言道，一颗老鼠屎坏了一锅粥， 这也是历史变迁中的一些，这也是非常正常合理的一个场景啊，因为 太极八卦，阴阳结合，他必须是有好有坏，也就是说这种不合理的需求是肯定常见的，没有办法说每一个产品经理都是乔布斯，但是 但是很多产品他并不认为他比乔布斯差，他总觉得乔布斯也有做的不好的地方，他比乔布斯更强。这个问题应该也是互联网行业中提出，超行业认知概念需求的 是非常多的，但是真正能实现出来的是少之又少的，一个是预算，一个是周期，一个是投入的人力物力不够，也不知道未来这个问题会不会出现的更少，还是出现的更多，大家期待。

ai 编程的第五天，今天我们讲述真正的 ai 开发流程，在我们前四天的这四节课啊，我们主要讲 ai 的 工具使用，但是呢我们从来没有讲过这个 ai 编程到底是什么样的流程， 我们就一直感觉就是我们可能用一句话写出一个程序，我们自己就感觉很牛逼了，其实呢不然不是这个样子的，你有可能做一个小项目呢，可能我们一天就结束了，我们可能遇到大项目的时候呢，我们可能就结束不了了。 那么 ai 编程的痛点是什么呢？就是 ai 写代码会越来越乱，就是我们写一个大项目，写到后面呢，可能改一行， 可能我们会出现很多的 bug， 可能改一行，可能报错三行，一直都有这样的情况。然后还有就是我们新手朋友们一直都在想，我们到底是先做这个页面呢，还是先做这个后端呢？ 然后还有就是 api 的 文档，就是我们写了一大堆东西，没有一个说明书，你们也不知道自己做了什么， 然后呢你想加一个功能的时候呢， ai 又重复写了一遍，这就是 ai 编程的这几大痛点，我们本节课呢都帮你把这些痛点呢去解决掉它。那么外部框架呢？我们在开发网页的时候啊，有很多的外部框架， 为什么呢？因为我们不能重复的造轮子，我们一定要使用最前沿的外部框架。 然后呢我们前四天呢，可能写的顺风顺水，因为我们写的很简单，比如说 comfy 的 html 页面，那个只是一个 小的前端的页面展示，我们真正的没有涉及到后端，那么从今天往后的实战开始呢，我们就开始噩梦的开始了，可能你会不断的抵 bug， 不 断的去调试，然后你可能三天后再一回看自己的代码，完了忘了自己写啥了， 对吧？那么我们今天首先就是把这个所有的流程去想明白，然后如果我们在 ai 编程的过程当中呢，我最开始呢也容易犯这个错误，就直接对 ai 说给我写了一个网站，然后呢 一堆前后端缠在一起，就是像意大利面条一样的代码，就很乱，然后想想查看什么功能呢？然后没有没有之后又让 ai 去写，那么 ai 最后写的呢， 就是不是这个 bug， 就 那个 bug， 改这个错那个改那个错那个，一直都会出现这样的问题，这可能是我们在 ai 编程当中呢，很很容易呢就是出现的这种错误， 然后在 api 文档的项目说明书，这个是非常重要的，我们一定要写一写，就是让 ai 写一段 api 呢，就写一段后端代码，要要让它记录一下，让它自动生成一个文档，嗯，我们后面会讲这个 open api 的 使用。 然后接下来呢就是外部框架，这些就是我们如果说开发一个网页啊，千万不要这个从零造轮子，我们一定要用这个， 就是非常丰富的框架，比如说 python 的 张钩框架， fast 的 api 框架，就是 v o e 框架这些比较前沿的框架，我们一定要站在巨人的肩膀上，那么我们开发所有的东西都很快了，也不会出现很多的 bug。 那么真正的 ai 开发流程呢，实际上就是五步，第一步呢就是你需求的结构化，比如说你想创建一个什么样的需求？你是博客也好啊，电商也好啊，工具也好啊，核心功能呢，你不用超过三个。 然后主要的技术站你是用 python 写代码啊，还是用 node js 写代码啊？就是我们的代码语言采用什么框架，这个呢我们可以让 ai 去推荐，推荐完之后呢，最后整理出一个文档，最后呢再给 ai 让他去去写。然后第二步呢就是框架的设计，就是咱先不用去写代码，先让这个 ai 去去帮你设计这个 api 和这个数据表的结构， 然后在正常我们开发当中啊，无论你是程序员也好啊，你还是 ai 编程也好啊，我们一定要后端先行。为什么后端先行呢？我们先把这个接口写好了，然后呢我们再去实现前端页面，这样呢我们肯定是不会错误的。 就是你先把后端接口呢用代码去测试完，测试完之后呢，就是也不用说用代码测试完，你让 ai 去自动的帮你 把这个代码测试一下这个 a p i 接口通不通，如果说通了，那么你再去实现前端，我给你们举个例子吧，比如说你们想做这个大香蕉的图层图，那么我们调用大香蕉的 图层图，必须得有这个 pos 的 请求吧，或者 get 请求什么的。我们先用这个 ai 呢，先帮你跑通生成一张图片，利用这这个你写的这个 api 去生成一张图片，如果说它能生成了，就是接口正常了，我们再去实现前端的实现， 这样呢就不会来回改了，就是你如果说你改前端可能是你后端的毛病，这样你能确认到底到底是谁的问题， 然后联动文档，就是你一定要写一个功能的时候呢，让 ai 写一个文档，这个呢咱们后边有一个技能包就 skill， 我 们后面安装了之后呢，它会自动的帮你完成文档，这个大家伙不用担心，我们只知道这个原理就可以， 这到后边呢，我们就是写的比较方便，还有就是呢， ai 呢，它会出现幻觉，我们不要在一个对话框呢持续的写代码，我们要适当的压缩这个上下文，新建对话框也好啊，压缩上下文也好啊， 还有就是你不要让它就是说一些它不懂的一些东西。 然后今日作业我们用 ai 做一个极简的代办事项的后端 ipi， 我 们自己可以按照这个思路去写一写，然后我们下一节课呢， 真正的就是 ai 的 编程开始了，下一节课，我们今天呢先自己按照我这个思路去写一写，可能你你不需要懂代码，你按照我这个思路去跟 ai 去沟通，你会发现你写代码会非常的流畅，好吧。 然后呢， ai 防翻车的提示词啊，我们可以加上开发的规范，比如说严格前后端分离啊，后端只写这个接口，不负责渲染界面，就你不要把这个界面啊跟后端代码混在一起，这样会很乱， 每个 api 呢都要有这个接口，说明请求适历返回适历，这样呢，如果说你失去上下文的时候呢， ai 也知道你有什么接口，这个接口怎么去用，也不用去反复的去思考，你也会省这个头啃， 好吧。然后就是代码模块化，你不要把这个好几千行代码都写在一个文件上，你那不最后你站在上下边越多，你 ai 肯定是越笨的，然后要要让它加这个中文注示，然后先输出这个设计方案，这都是一些技巧啊， 一些技巧性的。然后本节课呢，主要还是指导你们的思想，就是从后端呢开始再开发前端，先把 api 做好再去做页面 啊。好了今天课程呢就到这里，咱们明天开始呢，就是真正的前后段实战了，大家不要浮躁，这个过程一定是很浮躁的，但是呢通过我们不断的去学习努力，我相信大家一定会做出一个非常好的项目。

当 ai 接管了写代码这件事，如何保证它们不会以光速造出一座史山？ open ai 的 思路是严格的约束，约束是速度的前提， 边界必须刚性封死，但边界之内让 agent 完全自由地实现。我们继续来精读 open ai 工程。博克 harness engineering 强制执行架构与品味部分，可以用规范文档来约束吗？答案是不够。 agent 看了文档理解了，但他未必会遵守。 文档是建议，而 agent 需要的是法律。如果规则只是写在文档里， agent 会复制已有结构，放大已有模式， 错误结构会被指数级复制。在这种速度下，靠人类 code review 维持秩序是不可扩展的。如果没有钢性护栏架构，漂移几乎是必然发生的。所以问题不是写不写规范，而是怎么把建议变成法律。核心原则是强制执行不变量，而不是微观管理实现。 什么意思？举个具体的例子， openai 规定所有外部数据必须在边界处做 skimmer 校验，这是不变量，是死规定，不能商量。 但你用什么工具来校验，可以用不同的实现方式，这是实现。 a 政可以自由选择，不是不管，而是只管那条不可逾越的底线， 底线以上，你怎么跑都行。就像高速公路，正是因为有了护栏和车道线，你才敢踩油门。这个原则落地之后，形成了一套极其严格的刚性架构。没有护栏的高速公路，越快越致命。首先是分层，每个业务领域被划分为固定的几层，从类型层到配置层， 到数据访问层，到服务层，到运行时层，最后到界面层。代码只能向前依赖，决不能回头。为什么？ 因为反向依赖会让改一个地方牵连到一大片。如果 service 可以 调 u i i， 那 改 u i 的 agent 呢？根本不知道自己同时也影响了 service， 他 只看得见自己负责的那个文件。 当一百个 agent 同时改代码，这种隐性牵连会迅速失控。打个比方，后厨流水线之所以高效，就是因为方向是死的。切菜递给灶台，灶台递给摆盘，如果摆盘的人可以反过来要求切菜的人重新处理食材，整条线立刻瘫痪。 谁也不知道自己手上的东西是最终版还是半成品。单向依赖的本质就是控制影响范围，改动指向前传播，上游永远不会被下游拖下水。然后是横切关注点的处理。什么叫横切关注点？ 就是那些每个模块都需要，但又不属于任何一个模块的东西。比如用户认证、日制记录、功能开关，这些东西很容易到处乱跑，哎，模块自己接一下，认证 b 模块也自己接一下，很快就乱成一锅粥。它们的做法是，所有这些公共能力必须通过一个统一的入口 providers 进入。你可以把它想象成大楼的门禁系统。不管你是送快递的还是修空调的，都必须从大门刷卡进入，不能翻窗户，不能走消防通道。除此之外的任何路径，禁止 c i 直接红灯打回。 而且这些约束不是靠人去检查的，是靠自定义 linter 来机械执行的。这里有一个非常精妙的设计，这些 linter 不 只是报错工具，它们是上下文注入工具。当 linter 报错时，错误信息里会直接写上补救指令。比如 service 层不能引用 u i 模块，请将共享逻辑移动到 us 目录。 agent 读到这条报错，等于读到了一条 prompt， 然后他自己重构代码，重新跑 linter， 直到全部变绿。整个过程不需要人类介入。 不是人类守规则，而是规则守系统。说到这里，我们讨论的还只是怎么管理结构，但真正有意思的地方在于，规则本身的性质发生了变化。在人类优先的工作流里， 结构化、日制格式、命名规范、文件大小限制。这些规则常常让人觉得限制创造力，但对 agent 来说，这些规则是倍增器。一旦你把一条规则写进代码，它瞬间就在所有 agent 的 所有任务中生效了。 同一条规则在人类世界是负担，在 agent 世界是杠杆。还有一个挑战，很多工程师审美直觉的认知， agent 写的代码风格可能不像人写的谢亮明，可能有点怪，排版可能不够优雅，但只要它符合三个标准，正确可维护， 对未来的 agent 可读就是好代码。好看不再是标准，好用才是人类的角色也因此发生了根本性的转变，不再是一行一行 review 代码的审查者，而是历法者。人类的品味被持续地反馈进系统。 怎么反馈？通过 review、 评论、重构 pr 以及用户反馈的 bug。 当你发现自己在 review 中反复纠正同一个问题时，你不去修那段代码，你把规则升级为代码，从建议 到文档再到代码，这是约束的三级火箭。简单总结下，在 agent 时代，约束不是束缚，而是基础设施。具体来说，第一架构是法律刚性分层和 providers 模式保证了 agent 不 会在结构上跑偏。第二， linter 是 prompt 自定义， linter 不 仅报错，还自带修复指令，让 agent 形成自我纠正的闭环。第三，规则是倍增器对人类繁琐的规则，对 agent 来说是一次便携全职生效的杠杆，而人类的工作从写代码审代码变成了为机器世界立法。下一期 我们要讨论当 agent 数量扩大到百台级别时，如何管理海量并行 p 二带来的合并冲突。这里是慢学 ai， 我 们下期再见。

今天给大家分享一个可以自动解锁你的项目目录，里面有哪些文件位置放错了，哪些文件啊，它的排序不是很合理，以及哪些缩影或者文件之间互相之间有冲突的一个情况，可以帮你排查，然后帮你改进。 那对，它叫 garbage collection， 是 我最近做的一个，它非常适合稍微有一点经验，但是又不是很专业的。呃，这种小白，因为很多人他们对这个文件夹怎么摆放是没有概念的，然后，呃，经常容易出现就闪代码的一个情况，所以我做了这样的一个一个 skill， 然后我们看一下这个点， m b 里面对 它主要的核心原理就是它会根据 cloud md 作为一个唯一的标准，然后你 cloud md 里面会规定好有文件夹结构，然后它会去对应去检查你的这个项目里面是否遵循这样的文件夹结构，文件夹结构是否合理，确保，呃，最大程度避免损坏代码。你可以定期，比如说，嗯，两三两三天，然后去跑一下。 对，然后我这个，我这个 cloud md 里面也是写了一些依赖层级啊，就是，嗯，他也会用这个，以后他会帮你去查。那我们先来故意找找一下乱吧。我们首先把这个 cloud md update 这个 skill 移出来，这样他应该是检测不到的，然后再把这个硬件写 c m l 前端这个页面，然后放到 test 里面，就这两个是放错了，然后我们等会来看一下它能不能检测到。 ok， 那 我们现在来调用一下这个 skill， 它不是 collection， 我 们输，输下来，然后证明。我换成这个 bypass permission 模式，就是直接跳过这个审核，然后我们调用一下，看一下是什么样的一个结果。 这两天我在输入我们社区，然后现在我把这个 skill 复制粘贴一下，放到这个，这个，这个是 pos 的， 我们新建一个文档， 对，然后 garbage collection skill， 然后这边复制粘贴一下，大家需要 skill 的 话可以直接来这个文档，然后去自己去拿它，这个是通用的，并不是只适合于我自己的。呃，一个文件，但它用一个前提就是说你需要自己创建好一个呃， cloud md 的 一个文件，因为它是以 cloud md 为标准的， 他会自动检查你的代码中有没有什么冲突的。或者是啊，之前创造创建过或者但是又后来没怎么用或者放错地方的文件夹，其实小白的话是非常容易犯这种错误的。 好，那我们先看一下，他现在基本上弄完了，生成了一个垃圾回收的一个审计，一个报告，然后他又分几个层级，他这个这个就是最严重的，然后 word 就 警告音符，只是他发现了一些信息，那你看他是没反应了， 但这个时候本身存在一些问题，就是 tools， 呃，然后这个 project 因为它还没有做，所以它目尾空很正常，我们看一下它会不会发现我们刚才故意捣乱那两个地方。 word 这边它那个 w e 写的就是 cloud md database 位置不当，对吧？在他写说，呃，在项目跟目录下，这个其实应该放在 skill 里面的，所以他建议的错失就是放在 skill 里面。然后，对，然后另外一个就是他发现就是咱们刚才放的 index html 这个独立页面的位置放错了，应该去放回来。 对，因为这个是我的一个实验性的一个文件夹，所以没有用 jit。 对， 呃，对，它整体都去对照了一下，然后查的很严谨，也是根据 cloud md 去弄的，然后这里面我们就去给它做一些回应。呃， 告诉他哪些需要怎么改，哪些需要怎么改。 ok， 这边他弄完了，我们看一下。对，呃，他已经把卡尔的 md update 这个，对， update 放回去了，然后这个也放回去了。对，所以说，嗯，垃圾回收成功非常好。

现在用 ai 写代码最大的痛点其实不是写不出来，而是写出来的东西很难看。不管是 copilot 还是 cloud code， 深沉的代码往往逻辑啰嗦，过度封装，也就是我们常说的 ai 位太重，典型的为了跑通而跑通。 针对这个问题， antropic 官方其实在插件库里藏了一个神器，叫 code symbolifier。 这东西的定位非常狠，它不负责写新功能，而是专门跟在 ai 后面，给刚才生成的代码擦屁股，做深度的清洗和重构。 首先得把这东西的定位搞清楚，在 cloud code 的 体系里，它属于 sub agent， 也就是子智能体。这次听着挺玄乎，其实你就把它当成一个专职的上后专员，他的工作原则非常死板，绝对不写新功能，也绝对不改动你原本的业务逻辑。 只有当你把功能开发完了，代码能跑了，他才会介入。说白了，前面的组织能体负责搞定需求，而他就是专门负责给刚才那堆急急忙忙写出来的代码擦屁股的。具体怎么擦呢？ 他主要干四件事，第一是降噪，把那些向这里定义了一个变量，这种侮辱智商的废话注全给我删了。第二是去重， ai， 经常喜欢复制粘贴，他能把重复的逻辑精准识别出来， 抽成独立的函数。第三是解套，这个最少他会把那种缩进七八层，像千层饼一样的 f s 嵌套，强行拍屏，改成清爽的谓语句。最后一点是人画画， 把 ai 偷懒写的什么 a 啊 b 啊， temp 啊这种鬼知道是什么的变量名，全部改成人类一眼能看懂的业务名称。你可能会问，这插件真有那么神吗？其实最有分量的评价来自 clock code 的 亲爹， 也就是他的核心开发者 boris channey。 这哥们在 reddit 上明确说过他自己的日常开发工作，流理币装 code compiler。 这其实就很有说服力了，研造工具的人自己都在用它来修整代码，说明这不仅仅是个锦上添花的小玩具， 而是为了解决 ai 编程原生缺陷而存在的必需品。具体到代码上，它主要解决两个让人头疼的毛病， 第一是防御过头， ai 特别喜欢写一堆废话判断，比如为了取一个值，它能给你写三层 if， 也就是如果不为空，如果不为定义等等。这插件能直接给你优化成一个清爽的可选练操作符。第二就是著名的波动权代码，捉近深得能把屏幕戳穿。 它会强制把逻辑重构为谓语句，也就是一旦不满足条件，直接返回，把那一层层的括号全部排平， 人类读起来终于不用再数括号了。还有一个痛点，用 ai 久了，你会发现项目代码量暴增，原来几行能写完的，他非给你整一大坨，这很容易导致项目代码腐烂， 后期根本没法维护真实用户反馈。这插件最狠的地方在于，他能把 ai 生成的幺零零行啰嗦代码，硬生生给你压缩成四十层的精炼代码。 这其实代表了一种趋势。就连 laravel 框架的作者 taylor altwell 最近也搞了类似的插件，目的只有一个， 让 ai 别瞎写通用代码，得懂规矩，写出符合人类审美的高质量代码。咱们先把这东西装上，最简单的办法，直接打开你的 cloud code 终端，输入斜杠 plug in install code simplify， 回车搞定。 它会自动从官方仓库拉取最新的逻辑配置，如果它提示找不到，多半是你 ci 版本太旧了，顺手更新一下就行。如果你是写 go 或者 python 的 硬核玩家，觉得官方默认的规则不够味儿，完全可以自己定制， 在项目跟目录下建一个 c l a u d n d 文件，把它定义成一个 sub agent。 重点看这里，你可以在 instructions， 也就是指令区给它立规矩，比如明确写上 严禁使用欠套的三元预算符，或者强制要求必须使用谓语句。这时候 ai 就 得乖乖按你的代码洁癖来干活。这一步对于团队规范法非常关键。装好了怎么用？两种路子， 第一种是手动挡，当你觉得 ai 写的代码是不顺眼，那不顺眼的时候，直接跟他说运行 code simplify， 他 立马就开始干活。 第二种是自动挡，你可以把它配置成 post run 钩子，也就是每次代码生成完，自动跑一遍，简化流程。 这就相当于你雇了个全自动的代码审查员，彻底解放双手，不用每次都去吼他了，咱们直接看对比。这就很明显了，左边是典型的 ai 原声代码， 为了跑通逻辑，他给你叠了四层 f l s 判断这种代码在圈子里有个外号叫波动权，看着就让人头大。再看右边，这是跑完代码简化器之后的结果，他把逻辑全部拍平了，用的就是微距模式， 如果不满足条件，就直接返回核心逻辑，一目了然。这种代码不管是你自己维护还是交给同事去跑 code review 压力都会小很多。归根结底， cloud code 配合这个插件，其实是建立了一种新的开发范式。以前我们是生成完能跑就直接提交，现在必须多加一步，也就是生成简化再验证。你可以把这个插件理解成一个不知疲倦的高级架构师，他专门跟在 ai 后面盯着， 别让那些 ai 史山透支了你项目的未来。如果你手里已经有内测资格，或者正在用它，现在立刻就把这个简化器挂载到你的工作流里。今天的分享就到这里。

有人在问我，你觉得 ai 写代码靠谱吗？兄弟，醒醒，都六二零二年了，你这个问题就像问汽车快还是马车快，毫无意义。事实是什么？ ai 写代码不仅行，而且是太行了， 但关键在于啊，是谁在用，怎么用？如果你本身不懂架构，不懂原理， ai 对 你来说就是一个光速使单代码生成器， 它不仅能让你用十倍的速度产出代码，也能让你用十倍、百倍的速度产出十倍、百倍难以维护的屎山垃圾代码，到时候 bug 满天飞，你连怎么改都不知道。 但如果你是架构师，你懂审美，懂设计， ai 就是 你的超级外骨骼。原来你需要一个团队，三五名好手帮你去一起把一个系统搭建起来，现在你带着 ai 一个人干就完了。 记住， ai 时代，程序员的核心能力不再是 writing， 而是 reviewing。 你 不再是搬砖的马农，你是 ai 的 teach leader， 是 代码的审计员。 ai 只是放大器，它会放大你的所有， 包括你的能力，也包括你的无知。别怪 ai 写代码写的烂，先问问你自己，你有没有驾驭它的能力？ 哎，你们现在的单，你们现在写的代码，有多少是 ai 写的？评论区聊聊。

当 ai 接管了写代码这件事，如何保证它们不会以光速造出一座史山？ open ai 的 思路是严格的约束，约束是速度的前提， 边界必须刚性封死，但边界之内让 agent 它完全自由地实现。我们继续来精读 open ai 工程。博克 harness engineering 强制执行架构与品味部分，可以用规范文档来约束吗？答案是不够。 agent 看了文档理解了，但他未必会遵守。 文档是建议，而 agent 需要的是法律。如果规则只是写在文档里， agent 会复制已有结构，放大已有模式， 错误结构会被指数级复制。在这种速度下，靠人类 code review 维持秩序是不可扩展的。如果没有钢性护栏架构，漂移几乎是必然发生的。所以问题不是写不写规范，而是怎么把建议变成法律。核心原则是强制执行不变量，而不是微观管理实现。 什么意思？举个具体的例子， openai 规定所有外部数据必须在边界处做 skimmer 校验，这是不变量，是死规定，不能商量。 但你用什么工具来校验，可以用不同的实现方式，这是实现。 a 政可以自由选择，不是不管，而是只管那条不可逾越的底线， 底线以上，你怎么跑都行。就像高速公路，正是因为有了护栏和车道线，你才敢踩油门。这个原则落地之后，形成了一套极其严格的刚性架构。没有护栏的高速公路，越快越致命。首先是分层，每个业务领域被划分为固定的几层，从类型层到配置层， 到数据访问层，到服务层，到运行时层，最后到界面层。代码只能向前依赖，决不能回头。为什么？ 因为反向依赖会让改一个地方牵连到一大片。如果 service 可以 调 u i i， 那 改 u i 的 agent 呢？根本不知道自己同时也影响了 service， 他 只看得见自己负责的那个文件。 当一百个 agent 同时改代码，这种隐性牵连会迅速失控。打个比方，后厨流水线之所以高效，就是因为方向是死的。切菜递给灶台，灶台递给摆盘，如果摆盘的人可以反过来要求切菜的人重新处理食材，整条线立刻瘫痪。 谁也不知道自己手上的东西是最终版还是半成品。单向依赖的本质就是控制影响范围，改动指向前传播，上游永远不会被下游拖下水。然后是横切关注点的处理。什么叫横切关注点？ 就是那些每个模块都需要，但又不属于任何一个模块的东西。比如用户认证、日制记录、功能开关，这些东西很容易到处乱跑，哎，模块自己接一下，认证 b 模块也自己接一下，很快就乱成一锅粥。它们的做法是，所有这些公共能力必须通过一个统一的入口 providers 进入。你可以把它想象成大楼的门禁系统。不管你是送快递的还是修空调的，都必须从大门刷卡进入，不能翻窗户，不能走消防通道。除此之外的任何路径，禁止 c i 直接红灯打回。 而且这些约束不是靠人去检查的，是靠自定义 linter 来机械执行的。这里有一个非常精妙的设计，这些 linter 不 只是报错工具，它们是上下文注入工具。当 linter 报错时，错误信息里会直接写上补救指令。比如 service 层不能引用 u i 模块，请将共享逻辑移动到 us 目录。 agent 读到这条报错，等于读到了一条 prompt， 然后他自己重构代码，重新跑 linter， 直到全部变绿。整个过程不需要人类介入。 不是人类守规则，而是规则守系统。说到这里，我们讨论的还只是怎么管理结构，但真正有意思的地方在于，规则本身的性质发生了变化。在人类优先的工作流里， 结构化、日制格式、命名规范、文件大小限制。这些规则常常让人觉得限制创造力，但对 agent 来说，这些规则是倍增器。一旦你把一条规则写进代码，它瞬间就在所有 agent 的 所有任务中生效了。 同一条规则在人类世界是负担，在 agent 世界是杠杆。还有一个挑战，很多工程师审美直觉的认知， agent 写的代码风格可能不像人写的谢亮明，可能有点怪，排版可能不够优雅，但只要它符合三个标准，正确可维护， 对未来的 agent 可读就是好代码。好看不再是标准，好用才是人类的角色也因此发生了根本性的转变，不再是一行一行 review 代码的审查者，而是历法者。人类的品味被持续地反馈进系统。 怎么反馈？通过 review、 评论、重构 pr 以及用户反馈的 bug。 当你发现自己在 review 中反复纠正同一个问题时，你不去修那段代码，你把规则升级为代码，从建议 到文档再到代码，这是约束的三级火箭。简单总结下，在 agent 时代，约束不是束缚，而是基础设施。具体来说，第一架构是法律刚性分层和 providers 模式保证了 agent 不 会在结构上跑偏。第二， linter 是 prompt 自定义， linter 不 仅报错，还自带修复指令，让 agent 形成自我纠正的闭环。第三，规则是倍增器，对人类繁琐的规则，对 agent 来说是一次便携全职生效的杠杆，而人类的工作从写代码审代码变成了为机器世界立法。下一期 我们要讨论当 agent 数量扩大到百台级别时，如何管理海量并行 p 二带来的合并冲突。这里是慢学 ai， 我 们下期再见。

今天介绍一个热门开源项目，能把 ai 生成的史山代码库和文档变成知识图谱。这个项目就是 understand anything， 已经两万星标了。 拿到这种项目，先别急着让 ai 改代码，先看三件事，入口在哪，核心模块在哪，文档和代码怎么对应，这些关系没看清，你问 ai， 它也只能在碎片里猜 understand 简 anything 做的事就是把代码库和文档变成一张知识图谱。 文件是节点，概念是节点，问题也可以挂在具体节点上。所以它不是只把文件列出来，而是把文件、概念、问题之间的关系摆出来。 这里最值得讨论的是，理解复杂项目时，聊天框未必是第一入口，聊天负责回答问题，图谱负责把结构摊开，先顺着图谱探索，再搜索模块，最后围绕节点提问， ai 的 答案会更容易验证。它也适合搭配 cloud code、 codex、 cassar co， pilot、 gemini、 c l i 这些 ai 编程工具。项目叫 understand anything。 别再直接问 ai 了，先把项目做成图谱，喜欢的朋友点个关注吧！

大家是不是每天一边是各种办公工具 facebook， 一 边又是各种 ai 工具 type gpt、 cloud、 jimmy， 然后反复横跳粘贴来复制去，然后一个工具里面又是一堆 对话，一个对话里面又是一堆一问一答，最后就算是聊明白了，第二天又忘了 ai 都给你说了啥。那么多 ai 大 模型，即使它的上下文再长，你也不可能每次都全部给它重新投喂啊。时间一长，在你的 ai 大 模型，即使它的上下文再长，你是扔不掉里还乱。 我们应该做的是反客为主，不是我们去找 ai， 而是让 ai 来服务于我们的大脑。所以 obsidian 加 ai 就是 最佳方案。 obsidian 就是 你思想沉淀，你就是你数字世界的皇上。哈哈哈， ai 越发达，我们越要像皇上一样活着，所有 ai 都是奴才，都来伺候你。我从来不去教育让哪个 ai 模型更从容， 我只专注于建设我自己的 oceite。 至于各种 ai 模型， ai 工具都是直接拿来用，从来不教育，只筛选 check gpd 不 行就换 jimmy， jimmy 不 行换卡拉，随便的 oceite 流水 绝对不能搞！今天我要给大家分享的就是你的皇室 oceite ai 系统。 oceite 加 copilot。 为什么是 copilot？ 因为它是我用过我觉得功能最全面，体验最丝滑，对新人最友好的 oceite 插件。 第一，安装非常简单，几步就可以搞定，日常他就以特别难的形式在旁边随时待命。第二，功能强大稳定，对话流畅更并且可以深度分析你指定的文件或者 文件。第三，灵活免费，它本身可以完全实现免费，同时也可以配置你自己更喜欢更习惯的模型，接下来我用三分钟的时间教你搞定它的配置，以及给你展示它的使用。首先你就是要有 abc， 这个大家自行下载，下载完成之后呢，我们第一步就是安装 abc， 第二步就是安装并取用 coco 乐的插件，首先我们找到设置，在设置里面我们找到第三方插件，然后找到社区插件市场，点击浏览，在搜索框搜索 coco 乐，然后我们找到点击这边有一个安装，因为我这是已经安装过了，虽然是 设置的是更新，这个更新的位置其实就是安装，我们点击安装，安装完成之后呢，我们返回回到这个插件的这个页面，找到我们刚才安装的插件，在这里点把这个选项打开，这样才算是正式启动。第三步我们去搞定 kpi， 首先我们需要去访问轨迹流动，并且注册用户， 点击这里直接使用邮箱就可注册。我们在左侧边栏里面找到 api 密钥，然后新建 api 密钥，这个描述和命名，大家可以根据自己的需求随便 创建好 api 秘钥了之后，我们点击复制。第四步去配置激活我们的 o c d ai 第三方插件，找到我们的 open， 点击设置在 api k， 这里点击 set k， 我 们可以看到下面有各种平台的 api 接口， 我们找到刚才的汇集流动，在这里来粘贴我们复制的 api k， 然后点击右侧的按钮，点击下拉栏，我们就可以选择我们想要去使用的 模型了，比如说我们找到 d f c 三点二点击，点击旁边的 app， 点完之后我们可以看到这边显示配置成功，这样我们的 ai 就 算配置完成了，照着刚才的简单的数字，百分之九十九都能完成配置， 如果有什么问题，欢迎大家在社群里面交流。好了，现在你的 o c d ai 系统其实就已经完成了，就是这么简单，接下来我会给大家分享几个 o c d ai 系统的 ha moment， 看完之后你一定会非常的 nice。 那 首先第一个场景就是整理日记，如果你自己每天也很想写日记，但是又懒得去打字，懒得 去整理，那可以去看一下我的这个方法，比如我自己就会先用语音转录的方式去口述我一天发生的事情，就像一个流水账一样，想到哪说到哪，畅所欲言。 说完之后呢，就可以在旁边的这个对话框里面让 ai 帮我整理成规范的文字，你可以让它按照比如说某种时间线或者五个 w， 两个 h 的 方式，或者说其他的某种框架去整理。这样一方面既可以轻松的去完成了日记，同时也可以让后期的 ai 更加理解你自己的这个来事度，让它对你有一个更加具象的理解。 第二个场景呢，就是日记的洞察，同样如果你已经有了成千上百片碎片的这个日记，但是其实你的生活又一天一天重复的过，你可以让 ai 去帮你洞察你的人生，洞察你的日常。比如说你可以去问过去三个月你有哪些常见的思维习惯，或者有哪些经常出现的负面情绪， 以及如何改变。同样你不需要去投喂 ai 你 的想法和语言，而是让 ai 充分的服务于你。第三个场景是创意灵感，很多话题和热点其实我们每个创作的都不 看得到，但如果你需要更加有个人视角或者风格的文章，一定是需要让 ai 更加的理解。你如果自己想到一个话题，那我就可以让他通过了解我过去的所有的灵感，所有的笔记来结合这个话题去进行一个的差异化。更有我个人风 视角选题，因为它结合了那个极其庞大而立体的你，所以它生成的这个结果一定是带有鲜明的个人特色，然后它就可以帮你直接生成我个人不是 ai 写作的 big fan， 但不影响它确实是一种更加高效的快捷的方式。第四个就是一个学习场景，你可以把你一些正在学习的学习资料扔给他，然后让他帮你拆解，同时你在左边的这个笔记 里面进行记录和思考，反过来一样，你可以在笔记栏里面进行自己的书写，记录自己的想法，同时让他在旁边 ai 帮你去进行完善。这两个东西可以在一个页面进行，无需来回切换，也无需你向上去来回的去翻找，交互体验是非常大大的提高了你写作的效率。那最后一个呢，就是文档生成，你可以让他向指定的文件或者文件， 那你就可以快速的让他去抓取这个文件夹，帮你去生成。比如说你的周报，你的月报，同样你也可以给你的周报月报去配个好模板，这样就可以更快去完成一些精细化的。 ok。 以上的这些内容其实已经覆盖了不限定百分之八十的这种工作场景和需求， 记住，这不仅仅是一个工具切换，更是一次工作流、工作方式的进化。我希望大家可以享受写作和思考的同时，把更多这种行政型的工作交给你的 ai， 从而释放出更多的时间去享受自由，活得更有风格。

你可以试一下，我觉得最终的结果呢，就是从一个十三变成了另一种形态的十三，就两个十三，它样子不一样，但是恶心人的程度呢？都差不多。 我就是现在我们公司有很多页面是以前的 java 加福林马克的。我靠，五十七这款车子现在才反应过来，你之前现在大厂吗？算是的，算是大厂是吧？ 说，请讲说。就是我们现在。嗯，我们有很多内部的项目是用 java 加菲马克，就是那种模板文件，然后它前端的页面的话是用六点 gs 去写那种页面比较久，然后他们的六点 gs 就是 从头到尾录个文件可能有四千行或者五千行，一个主页有四五千行， 就是整个页面的交互就全在一个六的 gs， 从头一撸到尾。哦，你说你们整个场景只有一个主键是吧？ 没有每个页面一个 v 六点 gs， 但是它是从头到尾一把录完啊，就是一个页面的代码，所有的全部在页面里边，没在页面里边再去吸粉主键了，是这意思吧？对对对啊，然后呢？然后我们现在的方案已经很成熟了，就是说我们是现在都给它全盘改成 next gs 加 react， 还有啊 add design 嘛。 嗯，现在我是在探索这一块，我们就是啊怎么去用 ai 的 方式去让他自动的帮我从这一块直接转，你想一下子就成功是吧？就是做一件什么事，然后一个命令敲下去，剩下的事情你喝茶，然后喝完过后他就好了，是吧？ 你想这个是最终的期望，但是在这一块期望之上，我还想去自动让他在老代码里面自动去给我生成端到端的一些测试用力，并且在新代码里面他能自动帮我跑。呃，测试用力他应该是没问题的，应该是 ok 的。 关键是那个代码质量的改造，这一块是个细活啊，绝对做不到你想象的样子。所以我的期望是从一个页面一个页面改，但是不知道这一套。对，做下来以后就是一个页面一个页面改。我这一块的建议呢？你先这样子， 你，你一个页面先扔给 ai， 你 告诉他现在我这个里边代码太多了，我要进行组建划分，你现在别让他动， 这个东西只能人际配合，你要全部给他的话，你这个项目容易崩。嗯，你让他告诉我，你先读一下这个代码，这代码可能比较多，你读完了过后告诉我一个代码分为哪几块功能，那些功能模块之间交互他是如何进行交互的？然后呢？我们该如何来划分？就你跟他一起来合力去把它分出来，一点点的分，一点点的分，那只能这样子是个细活， 这样子的话就是有要需要 n 多次交互吗？对对对，那就是要 n 多次交互，你可以同时开多个窗口来做。 是我们公司其实内部他已经有很多的那种案例，就是直接加把整漏的一整个加满，应用直接加完整漏的直接通过 m c p 叭，一键就让他给你跑完。有什么东西在我们公司现在有很多就是加把整漏的的项目吗？整漏的结实的项目啊啊，但是他们是通过扩展 m c p 的 方式，直接那个其实还好，一键就让他帮你找没，没问题，那个还好。为啥那个还好呢？因为它功能是有对应的， 它大一把逻辑之间是有对应关系的，但是你那个不是啊，你是要对代码进行改造。这么说吧，比方说加法里边有一个，因此三二有一个 a 等于一，随便举个例子吧。啊啊，就这个意思啊。然后呢？把这一句话改成 ts 或者是 gs， 它改起来是非常轻松的， 比方说这一块改起来，他非常轻松的就改完了，有对应关系的就哪怕不是一行一行对应，哪怕就是功能模块的，就这个函数，哎，一个加法函数，我把它写成 load 版本的或者 ts 版本的，这是比较简单的， 这里面那个不是这个情况，里面是一坨屎，要从屎里边把它摘出来，把东西给它摘出来，就说对代码结构进行变动的，这个东西肯定是办不到的，然后哎呀，一下子给你全部弄完。那你想多了 啊，我反正也找了一些这种思路，就是说确实是让他先把你的主要的逻辑先写下来，跟他建流程，然后让他你先转出来逻辑，然后再一步步让他先逻辑超离，再跟他说一些你的规范，让他慢慢去转。我知道你的意思，就是说你用多个 a 检测嘛，对吧？ 他们之间互相聊对，通过指 a 检测去。对对对对，让他去看，你可以试一下。我觉得最终的结果呢，就是从一个十三变成了另一种形态的十三，就两个十三，他秧子不一样，但是恶心人的程度了都差不多， 我觉得我大概就会变成这样子。我现在想的就是用 cloud code 去做，但是，呃，就是感觉你可以试一试，可能会跌跌撞撞的，但是可能 e to e 这一块，你可以试一试你这个东西，你可以试这个事业比较简单，你单开个分支嘛，然后你写一些 skills。 然后呢就是让主代理呢不要做任何事情，主代理只负责这个调度和规划啊，负责调度，然后呢让子代理呢有分别用不同的子代理去做什么事情，比方一个子代理他负责那个就分析模块功能，然后呢另一个子代理又在负责分析啥啥啥好，把一个子代理把功能分析全部就是多个子代理分析模块功能，或者分析这个页面功能 好，然后呢？主代理汇总是吧？现在又掉入到主代理了，那么主代理把功能拿到手了，对不对？然后呢主代理啊，然后又拿到手了功能，现在就拿到功能列表啊 啊，就是每个页面他有哪些功能清单全部合并的啊？功能清单出来了，功能清单过后就最好都可以把写成文件，把记录成文档也行。然后呢就现在又是开多个子代理， 然后又去分析啊，分析功能清单，那哪些功能清单这有重复的东西可以把提出来哪些功能上？太多了，可以把进行处理，降低复杂度。然后呢把生成任务啊，就任务清单，那么然后把一个任务清单，然后又开多个子代理， 然后一个个去完成任务。你大概可以用这个思路去试，但是呢还是那句话，我觉得最终的结果呢，就是从一个十三变成另一个十三，你可以去试一试，万一呢？对不对？万一好了呢？ 你可以试一试啊啊，思路大概是这样子。对，但是实践起来就感觉对你有点麻有点麻麻的，甚至你这件事你都可以让那个 ai 帮你写，帮你去写这个 skill。 都可以 啊，你去写你试一试跑位跑位如果要做这件事情有三个方向，就是哪个方向会更靠谱一点，要么就是字写一个 come on 的， 要么就是 sky， 要么就是再写一个 mcp 那 种方案会 更实际一点。我偏向于是写 command 去做这个事情。 command 是 什么意思？你说 cloud code 的 一个 command。 cloud code 可以 自定义 command 的 呀。现在 cloud code 已经没有 command 这个概念了，就变成 skill 了。就是 skill 是 一个意思。嗯我感觉是 command 更可控一点嘛。就是为啥更可控一点。 command 还不是提示词有啥区别啊。在 command 里面可以给它声明好你的一个执行步骤，并且让它如果说你断了之后接着按照未完成的步骤打标的步骤接着往下走啊。 skill 里边不行， 一样的是一个东西，他们最终的结果都是给 ai 为的提示词，你通过这个路径为了一坨提示词给他。你通过 skill 还是为了一坨提示词给他就没有区别。他未给开的都是提示词。 有啥区别呢？你告诉我有啥区别呢。我就没太明白有啥区别啊。啊也是我看的那个啊 superpower 的 这个东西他也是把 come on 的 全部转为 skill， 因为都是一样的，他只是叫的名字不一样而已。那行吧，那就再去研究一下。嗯好好好，行。 哎好，谢谢老师谢谢老师。哎，不开心啊就这样。好，拜拜。好，谢谢。嗯，拜拜。咋不太一样呢？是一样的呀，我这么跟你说吧，只要不是模型原生知识的东西，它最终结果就是提示词啊，有啥不一样呢？