代码审查skills技巧

大家好呀，又到了一起来补 coding 的 时间了，那经过我的前端方案的调整呢？我的 coding 整体已经完成了，那在 coding 完成的情况下，你可以让第三方进来来审查你的代码， 这个时候我们就可以用到 skills 了。我是这样跟 cloud code 去讲的， codex 已经完成了全部的开发，现在需要您进行 code review 并给出报告。对，那这个时候 cloud code 才是这样说的，我来为您进行全面的代码审查， 让我使用专门的代码审查工具生成详细的一个报告，所以这里他其实就去调用了 code review skills， 大 概过个两三分钟时间啊，他就会给到一个评估的结果。 那我们来说一下这个 skills 怎么用啊？如果大家那个 cloud code 里面还没有 skills， 可以 复制这句话去进行一个安装，在评论区里面我也会有写到，那我这边是因为已经之前已经安装过了我们斜杠 skills， 你就能看到他自己内置的 skills 有 非常多，然后我自己创建的有两个，有一个 code review 是 我自己让他创建的，在这个思维训练工具在 m 一 模块开发的时候，我就已经让 cloud code 来介入进行这个 code review 了。那我当时就跟他讲，我说请将以上的代码审查和报告 作为 skills 进行保存，那么他当时其实就会调用到 cloud code 的 自己内置的 skill creator， 最终创建一个 个 skills 点 md 的 一个文档，后面可以供他自己进行一个调用。那后面的话就是相当于我只要跟他说进行 code review， 那 么他都会去调用这个 skills 的 这个技能同时生成的这个报告也是一个，就是按照之前他编排的一个格式， 所以 skills 其实更多的就是把你固化的一些 sop 或者是操作流程，或者是你的一些知识技能可附用的保存下来，或者比如说选题加口不搞的生成，都可以作为一个 skills 来进行一个输出。 所以 skills 的 这个技能大家去用起来啊。第一步你在 cloud code 里面安装 skills， 第二个你就跟他说请将以上内容提炼为 skills 以什么什么命名，那这样它就会内置了。那后面在用的时候请用 什么什么 skills 帮我做什么什么事情啊，就可以了，就非常方便大家去用起来了吧。好，今天就分享到这里，拜拜。

每次用 ai 都要从头教一遍你的习惯，写代码的规范，改文案的风格，审代码的标准，每次重复说烦不烦？ ai 没有长期记忆，每次对话都是新开始， 你花半小时调教出来的效果，关掉对话就全没了，下次又得重新来一遍，时间全浪费再重复沟通上， skills 就是 解决这个问题的，把你的工作流程、偏好规则、专业能力打包成一个可附用的技能包， ai 加载了这个包，立刻就变成对应领域的专家。不用每次重新教，不需要写代码，用自然语言定义好角色和规则，保存下来就是一个技能， 跟创建一份文档一样简单。演示一个完整的例子。先创建一个代码审查技能定义，他要检查 sql 注入风险确认错误处理是否完整，变量命名是否规范，注示是否到位。 之后每次做代码审查，加载这个技能， ai 就 会自动按你的标准逐条检查，不需要你重复写 prompt。 再创建一个写作技能，设定语气是正式还是轻松，用词偏好段落，怎么组织， 写周报，写技术文档，写公告，换一个技能就行，风格自动统一。高级玩法是把技能串起来，先用架构设计技能出方案，接着用代码生成技能写实线，最后用审查技能扫一遍，整个过程你只需要验收结果。 skills 的 本质是把重复劳动的经验固化下来，一次定义，反复使用，而且可以维护更新。你的经验越积累越值钱，这不是省时间，是让你的工作方法本身变得可复用。 这个功能已经集成在主流 ai 工具里了，网上能搜到详细用法，觉得有用的话点赞、收藏、关注，下期继续。

你天天说我要用 ai 提效，结果呢？每次让 ai 干活都要跟他啰嗦半天。用 pytest 啊，断言写详细点，报告，按这个格式，等你解释完自己手写都写完了，问题出在哪？不是 ai 不 行，是你没给他规矩。 skill 就是 给 ai 定的规矩，你把它写清楚， ai 就 按你的套路出牌调教，终身受用。 我直接给你八个写好的 skill， 拿去就能用。 skill 一， prd 转测试用力，输入需求，文档输出标准，测试用力等价类边界值，异常场景， ai 全给你覆盖到。 skill 二，刷一个转接口脚本，扔个接口文档， ai 给你生成 paytest 加 request 的 自动化代码， 断言都写好了。 skill 三， bug 报告生成器，你说登录页密码输错没提示， ai 帮你写成步骤预期实际优先级截图建议完整报告。 skill 四，日制智能分析贴，报错站， ai 告诉你哪个文件哪一行，什么原因怎么改， 排查 bug 时间看办。 skill 自动化脚本生成，用自然语言描述场景， ai 帮你写 screen 或 playwrite， 代码定位器都帮你找好。 skill 六，测试报告加载跑完回归测试， ai 给你总结通过率，失败，用力分布，主要风险，下轮测试建议直接贴近周榜。 skill 七，代码 review 贴你的自动化代码， ai 检查有没有硬等待，断言够不够异常，补货了没？ skill 八，压测报告分析贴，解密聚合报告， ai 告诉你 qps 为什么上不去，哪段时间响应时间飙高，怎么调优，用 skill 干活就三个字，快，稳、爽！ 以前一小时，现在十分钟，输出格式每次都一样，不用返工， ai 真正变成你的马仔，指哪打哪，而且这些 skill 是 一次投入就回报你，今天花点时间配好，以后每次用 ai 都能享受标准化的红利，团队里其他人也可以用，你们测试组的标准就统一了。这套 skill 适合谁呢？ 想从手工测试提升的，每天被重复工作磨掉耐心的面试，想让面试官眼前一亮的不适合谁？连试都不想试的觉得反正有人帮我干的，那你可以划走了。 bug skill 每个都配 md 文档拿到手就能用 nice。

tiktok 上有一个项目，一天涨了五千多。 star 叫 madcap skills， 作者 madpoc， 是 typescript 社区很有名的开发者，他把自己每天用 cloud code 干活时用的 skill 全部开源了。 skill 的 生态现在已经很成熟了，市场上的 skill 质量参差不齐。 mad 的 这套是社区公认写的最好的参考实现之一。他要解决两个最常见的 agent 失败模式。第一个， agent 做出来的东西不是你想要的，你以为你说清楚了， agent 也以为他听懂了，结果做出来完全不对。 软件开发里最大的失败模式从来都是需求对不齐， ai 时代也一样。第二个， agent 太啰嗦，原因是 agent 对 你项目的术语不熟悉，他不知道你们管某个东西叫什么，只能用二十个词去描述一个你们内部一个词就能说清楚的概念。他最核心的 skill 叫 grill with dogs， 翻译过来就是带着文档拷问你， 你告诉 agent 你 想做什么？ agent 的 不是直接开始写代码，而是开始疯狂提问，沿着你的设计方案的每一个分支往下追，问一个问题，一个问题的问，每个问题还给出他自己的建议答案，等你确认或纠正。但这个 skill 比单纯的问问题多了两个关键能力。 第一个，他会维护一份叫 context temd 的 共享语言文档，在提问过程中，每当你们对一个术语达成共识，他就立刻写进去。比如你们项目里 order 到底是什么意思？ customer 和 user 是 不是同一个东西？哪些词是同义词，应该统一用哪个？ 这份文档的格式很讲究，每个术语一句话定义，下面列出要避免使用的同义词、术语之间的关系，甚至还有一段事例对话，展示这些术语在真实讨论中怎么用。 一旦 context md 建立起来， agent 后续所有的工作都会用这套语言。变量命名、函数命名、文件命名全部对齐， agent 也不需要再用二十个词去解释一个概念了。第二个能力，它会在合适的时候生成 a、 d、 r 架构决策记录，但不是什么决策都记， 三个条件同时满足才会建议写难以逆转。没有上下文的人看了会觉得奇怪，确实有过真实的取舍，这个判断标准本身就很值得学。再看另一个 skill diagnose， 这是一个 bug 流程， 它把 bug 变成了一个六阶段的纪律流程。最关键的是，第一阶段建立反馈循环。原文说这就是这个技能的全部，其他一切都是机械的。意思是，在你开始猜原因之前，先建立一个可以自动化运行的确定性的，能快速告诉你 bug 还在不在的信号， 可以是一个失败的测试，可以是一个 curl 命令，可以是一个 play right 的 脚本。它列了十种建立反馈循环的方法，从最理想的到最不理想的。而且明确说，如果你实在建不起反馈循环，就停下来告诉用户你试了什么，为什么不行。 不要在没有反馈循环的情况下开始猜。第三阶段也很有意思，要求在测试任何假设之前，先列出三到五个排序。好的假设，每个必须是可政委的， 然后把列表给用户看，因为用户往往有领域知识，能直接帮你重新排序。还有一个很小但很精妙的 skill 叫 caveman， 让 agent 用聪明的原始人的方式说话，去掉所有冠词填充词，客套化，只保留技术实质， 声称能减少大约百分之七十五的 token 消耗。正常回答是， sure i'd be happy to help you with that the issue you're experiencing is likely caused by caveman。 模式下变成 bug in off malware token expiry check use is less than not is less than equals fix。 但它有一个例外规则，涉及安全警告或不可逆操作的时候自动退出 caveman 模式，用完整的语言说清楚，说完再切回去。最后说一个 meta 层面的 skill 叫 writer skill， 他 教你怎么写 skill。 从这个 skill 里能提炼出几个关键原则。 第一， description 是 唯一决定 skill 会不会被加载的东西。这就是渐进式加载的第一层。 agent 在 系统提示词里只能看到名字和 description， 它根据这个来判断当前任务需不需要加载这个 skill， 所以 description 必须写清楚做什么和什么时候触发。 第二 skill， 米迪控制在一百行以内，超过了就拆成多个文件，主文件只放核心流程细节放到引用文件里，这就是渐近式加载的第二层和第三层。 agent 先看精简的主文件，需要细节的时候再去读引用文件。 第三，能用脚本做的事情不要让 agent 生成代码，确定性的操作，写成脚本放在 scripts 目录里省 token， 而且比 agent 每次重新生成更可靠。 回过头来看 mat 的 这套 skill， 它们有一个共同的设计哲学，不要让 agent 的 自由发挥，给他一个结构化的流程， grill with dogs 给了 agent 一 套怎么问，问完怎么记录，什么时候该写 adr 的 完整流程。 diagnose 给了他一个先见反馈，循环再列假设，再逐个验证的纪律， tdd 强制他一个测试，一个实现的垂直切片节奏。这跟 harness engineering 的 核心理念完全一致。 agent 的 可信链不在模型，在模型周围的系统， skill 就是 这个系统里最重要的组成部分之一， 而且因为它是开放标准，你写的 skill 可以 跨 cloud code、 codex、 cursor 使用，不绑定任何一个平台。一句话总结， skill 已经从一个概念变成了一个跨平台的开放标准和完整生态。 写 skill 的 关键不是告诉 agent 做什么，而是给 agent 一个结构化的流程，让他在每一步都有明确的判断标准。 macbook 的 这套 skill 是 目前最好的参考实现，值得每个用 ai 编程的人看一。

最近 ai 圈爆了个词， scares， 你 会发现它串串红的速度比当年的 prompt 还猛。你一定会问， scares 到底是什么？和 prompt 以及 m c p 到底有什么关系？那今天用融化给大家揭秘。 你一开始接触 ai 的 时候呢，会觉得它像个超级搜索框，问一句答一句。可突然有一天， ai 开始帮你做事了，改代码，写方案，分析数据， 它不再是回答问题的工具，而是你上班的同事想知道 ai 是 怎么工作的？听好了，它全靠三个核心， prompt、 scares、 n c t。 那 第一步， prompt， 你 对新人说，这个任务先分析风险，再给我个方案。那听上去像是个命令，对吧？那它的作用呢？是明确目标，告诉 ai 你 希望它做什么， 那这一秒 ai 就 被启动了，它只是按照你的指示开始行动。那这就是 prompt 任务指令，它属于一锤子买卖。那第二部 scares， 你 不会天天教新人怎么写周报，对吧？那只会说按标准来，那为什么呢？因为他早就会了。 scares 呢，就是 ai 已经掌握的技能，像一个工具包， p d p r d， 写作啊，代码审查呀，生成测试报告啊，全都不需要你再教了。那 ai 随时是可以调取，用得起，随时用 它，它不是即兴发挥，它是封装好的技术。那最后 m c p， 这才是命脉。想象一下， ai 再强，如果没有系统权限，无法调取数据库， 没办法进入内部的 a p i， 它就只是一个空洞的纸上谈兵。这时候呢， m c p 就是 ai 的 通行证，有了它呢， ai 能访问真实数据，调用工具进入你公司最核心的部分，那没有 m c p ai 只能嘴上说，那有了 m c p， ai 才能真正的动手做事。 ok， 那 总结一下，你让 ai 去做一件事情，分析这个仓库最近的 p r 质量问题。一开始 prompt 让他知道目标和任务， 接着 scares 让他用代码审查技能、分析技能去执行任务。最后 m c p 为他打开了仓库的大门， ai 可以 真正获取数据，完成分析工作。现在明白了吗？ ai 不 再是一个 回答问题的工具，他是你的工作的助手，是公司的一员，你交代的任务，他给你反馈给你解决方案。而这正是 ai agent 的 真正含义， 能被指挥，能执行、能行动。所以记住这三点，一， prompt 是 你给出的指令。二、 scares ai 掌握的技能随时能使用。三、 m c p ai 的 系统权限，打开工作大门要三者具备。 ai 不 再是工具，它直接能变成你的团队成员，你的工作助手。 那最后呢？我整理了一份某个大厂内部的 ai 产品经理必须要文档，包含了 ai 产品研发全流程和大模型未来发展方向以及学习路线图需要的直接安排。

朋友们，你们还在把 core code skills 当成普通的 mark 当文件来用吗？那你可就大材小用啊！在 android apk 内部，已经有几百个活跃的 ai 技能正在重新定义开发效率呢。今天我就用实战经验来告诉你，真正的 skill 到底是什么样的。 首先， skill 的 本质可不是简单的提示词，它其实是一个生态包，你可以把它想象成一个文件夹，里面包含了脚本、资源、文件，甚至还有动态钩子。说白了，最好的 skill 就是 给 ai 一个可以自由探索和使用的工具箱。 从代码架构到测试发布，从运维牌照到数据协同， andripic 在 用的 skill 覆盖了开发的方方面面。但这里有个核心铁律，要记住，职责一定要单一，可千万别贪多嚼不烂。 给大家看个高量案例。代码审查 skill， 它会唤醒一个完全没看过代码的紫智能体来挑刺，然后反复迭代，直到问题都退化成吹毛求疵。这招就叫用魔法打败魔法，轻松打破咱们的思维惯性。再比如，站会汇报 skill， 它能自动拉取 get 动态 sapp 聊天记录，再结合历史日制，只给你汇报最新的变化。为啥这么厉害？因为 ai 记得住昨天大家都说了什么。接下来分享几个秘籍。秘籍一，渐近式批录， 别一次性把所有信息都塞给 ai 主文件里，只告诉 call 我 有哪些文件，具体细节就放在 rephrase 文件夹里，这样能节省上下文窗口，让 ai 需要的时候再去翻抽屉。秘籍二，给 ai 准备一本错题集， 专门设置一个踩坑点章节，这可是 skill 含金量最高的地方，比如说，你可以告诉 call， 别老用文本字体和紫色渐变记录失败点，持续迭代，这才是真的在进化。 秘籍三，给它工具，而不是锁死步骤给 ai 最强大的武器不是条条框框的规则，而是现成的代码。提供一些辅助函数库，让 ai 把算力花在组合与编排上，而不是从零开始手搓样板代码。还有个关于 description 字段的致命误区要提醒大家， description 不是 功能说明书，而是触发器，科尔是靠它来决定要不要唤醒这个 skill 的。 所以正确的写法应该是类似当用户要求会总站会进度时，使用这样的 find 条件，而不是简单的功能。摘要。 高阶玩家还可以试试按需注入的安全护栏，比如设置一个 careful 模式，能拦截像二 m 二 f drop table 这样的危险命令。再来个 freeze 模式， 限制 ai 的 写操作目录，这些安全护栏平时隐身，关键时刻才会出手。至于团队分发与评估，小团队直接把 skill 提交到代码仓库就行。大团队可以搞个内部插件市场， 用 p two use 钩子记录使用情况，让好用的 skill 自然涌现，而不是靠中心化审批。其实啊，理解 skill 最好的方式就是动手去做大多数优秀的 skill， 一 开始不过就是几行文字加一个踩坑点。 想想看你的团队最缺哪个象限的能力，赶紧收藏起来，马上打造属于你的 ai 智能体外脑吧！

今天带大家看十个 cloud code 最值得装的 skills， 这些工具能让 cloud 变得更强，从帮你操作网页、写前端代码，到自动审查代码、处理 office 文档，甚至帮你画架构图和润色中文，基本覆盖了开发和办公的所有场景。我们直接看第一个。 第一个是 agent browser， 它是 cloud 的 破局神器。以前 cloud 只能在编辑器里写代码回文字，但装上它， cloud 就 能直接上手操作网页。 它能自动打开页面、定位、点击输入内容，甚至帮你抓取信息并整理结果。不管是登录后台、填写表单，还是测试 web 应用，它都能把零散的网页操作变成连续的自动化流程。 第二个是 brainstorming， 它是 cloud 的 灵感加速器，当你陷入单点思路想不出新角度时，它能围绕你的主题，从不同维度提出观点、案例和方向。 它不只是给个答案，更重要的是帮你系统性的整理逻辑、完善框架，帮你快速搭建出可落地的方案或策划。第三个是 superpowers， 这是一个全能强化插件， 如果你觉得 cloud 处理复杂任务不够顺手，或者功能太单一，装上它就能补齐短板。它能增强 cloud 的 任务拆解能力，甚至能通过子代理来驱动开发，大幅提升编码效率和交互体验，让日常使用更流畅。 第四个是 front and design， 它是专门为前端设计打造的效率神器，你只要说出设计需求，它就能直接生成包含布局样式和交互效果的完整前端代码。 它能把你的想法直接变成可运行的页面，省去了大量手动写 html、 css 和调试排版的时间，非常适合快速做原型或个人主页。第五个是 code review， 它是你的代码质量守护者， 它不只是简单的纠错，而是会从逻辑风险、安全漏洞、代码规范以及性能优化这几个维度对你的代码进行全面审查。 它能帮你提前排查隐患，并给出具体的修改建议，让你的代码更健壮、更符合规范。第六个是 document skills， 你 可以把它理解为 ai 版的 office 全家桶，它能直接处理 word、 excel、 ppt 和 pdf， 无论是生成带格式的文档、处理带公式的表格，还是提取和拆分 pdf 内容，它都能在 ai 工作流里一站式完成，不用你再频繁切换各种办公软件。 第七个是 diagram generator， 它是你的高效绘图神器，你只需要用文字描述你的需求，它就能直接生成专业规范的图标。无论是流程图、架构图、 er 图还是思维导图，它都能帮你把文字思路快速转化为可式化的结构，省去了大量手动排版的时间。 第八个是休眠机机，也就是 ai 文本的人话转换器，它专门解决 ai 生成内容生硬、有机器感的问题。通过调整语气和优化句式，它能让输出的内容更符合中文表达习惯。 不管是写职场邮件还是做文案创作，他都能让文字变得更自然、更有温度。第九个是 shift learn next， 这是一个非常实用的实战学习工具，他能带你走完一个完整的项目流程，从环境搭建、写代码到最后的部署上线。 它基于 xjs 等现代技术栈，让你不再是盲目的啃文档，而是通过真实的开发逻辑，真正把技术练到手上。最后一个是 find skills， 它是 skills 生态里的技能管家。面对这么多技能，你不需要盲目翻找，只需要输入关键词，比如 ppt 或者架构图， 它就能帮你精准找到相关的工具，并展示安装量等关键信息，帮你快速选好工具并完成安装。

为什么别人的 ai 写代码不仅精简、条理清晰，还能正常运行？而你的 ai 写代码总是屎山一坨坨，漏洞百除？这个 skills 或许能帮你彻底解决这个问题。仅几个月时间，就超十万人进行收藏，能用一百行代码解决的需求绝不多。写一行无用代码。 严格遵循这四项原则，编码前必须先思考，然后罗列出陈述。假设如果存在更简单的方法，则要提出确保用最少的代码解决问题。不要进行任何猜测。每一行修改后的代码都应该直接追溯到用户的请求。整套流程下来，可以让你少写百分之八十的无效代码。

我太激动了，刚看到国外大神开源的 agent skill 和演讲视频，就迫不及待地给大家做出视频分享，因为这实在太强了，我想让更多的人看到。 我简单给大家捋一下核心干货。大神点出了 ai 写代码时普遍遇到的四大核心问题，并且配套给了对应的战术 skill 技能，完美对症下药，全部开源可直接拿去用。 问题一， ai 没有按照我的意愿去做。问题二， ai 说话太啰嗦。问题三，申请的代码无法运行。问题四，代码是一团乱麻，大家可按照自己的需求选择对应曲线观看接下来进行实际内容。 第一个问题， ai 没有按照我的意愿去做。当我觉得我有个好主意去和 ai 沟通，此时其实在做需求收集，他从你这里论清楚你的想法。 然而我和 ai 之间并没有混响一个设计概念，于是做出了我不想要的东西。 于是这位大神想出了一个技能。这个技能非常简单，过程就是不断采访，确认计划细节，直到达成共识。 这个过程中， ai 大 概会问你大约四十个、六十个问题，深入涉及的每个分支足以解决角色之间的依赖关系。此时 ai 是 你的对手，不断的向你抛出想法，努力达成共同理解。 还有一个好处，之后生成的对话可以拿来变成产品需求文档，这比 c c 或者其他 a 帧的工具里的计划模式要好。计划模式非常急于创建一个计划并开始执行一个想法，不会被几个问题就解释清楚。 第二个问题， ai 说话太啰嗦。 ai 在 说话时总是用太多的词语表达他在做什么，人与 ai 之间并不是在用同一种语言交流， 所以大神做了一个技能，这个技能就是通用语言技能，他的基本原理就是扫描你的代码库，查找术语，然后生成一个马克档文件。他会创建一个通用语言的马克档文件，里面包含一堆所有术语的马克档表格， 然后把这个文件转给 ai， 当然自己也能阅读它。领域驱动设计，简称 d d d 有 一个通用语言的概念技能类似通过通用语言，人与 ai 之间的交流全部源自同一个领域模型。这就是第二个小技巧， 和 ai 创建一套通用语言。第三个问题，假设你已经和 ai 达成了一致，你很清楚你要构建的是什么。 ai 也确实构建出了正确的东西，但是不能正常运行。我们就可以利用反反馈循环。 ai 往往是一次性做太多事情，生成大量代码，然后才可能做一下类型检测 或者跑一下测试，这导致速度太快。反馈的速度决定了速度上限，应该边走边测试，采取小而谨慎的步骤，而不是超过这个速度，而 ai 默认情况下在这方面做的并不好。 所以第三个技能就是 tdd， 使用测试驱动改法，因为 tdd 会迫使大语言模型真正采取小步前进的方式。先写一个测试，让这个测试通过，然后再重构代码，让它更优雅并考虑设计。 第四个问题，代码是一团乱码。简单说一下，代码库中浅层模块功能不多，但接口却很复杂。如所图，你会看到有大量不同的小块 ai 在 其中穿梭和导航，实际上这让 ai 很 难进行探索，而 ai 其实很擅长生存这这种代码库，于是 ai 根本不理解代码在做什么。他会尝试去探索代码，但由于结构混乱且充满了浅层模块， 可能无法及时找到正确的模块，或者无法理解所有的依赖关系。他无法理解代码。代码库中的深层模块，如右图，代码本身没变，只是被组织在了边界内，边界外有接口。 那么如何把浅层模块的代码变成深层模块的代码？于是第一次想进，人就来了，也就是探索一下代码库，寻找那些彼此相关的代码，把这些代码都分进一个深层模块里。 你在进行接口测试，通过这个接口来验证。这其实也解决了另一个难题，当你的反馈循环已经正常运行，假设一切都开始步入正轨，那么你现在能交付的代码比任何以往都多的多， 但你的大脑却跟不上。在开发过程中，你可能会感觉比任何时候都更疲惫，而且浅层模块的代码库实际上让你的大脑更加吃力，因此深层模块更有必要。这种方式不仅让你更容易理解和阅读，还可以把这些模块当回合来对待。 而你设计接口，把实线交给 ai。 最后接出大神的话，希望这次的分享能让你在这个新的 ai 时代充满信心，这样你就能产生积极的影响。开源库放在评论区了，大家自取。

欢迎来到本期深度解析，今天咱们要聊点特别硬核，但也绝对能戳中每一位拍发者痛点的话题，也就是所谓的工业级 ai 治理。 你想啊，现在的 ai 编程术手满天飞，但我们怎么才能阻止他们产生那种虚假成功的幻觉呢？今天咱们就来看看，如何通过一套软件开发协议，彻底把 ai 从一个只会聊天的机器人升级成严谨的工业级的自动化开发者。 咱们先来看这个人的对比，过去或者说现在很多人还在用的是那种聊天机器人模式，你给他下个指令，他在那靠脑补直接生成代码，然后咱们就凭着信仰假装相信他能跑通。但说实话，这太不可靠了， 原材料明确指出，我们要彻底告别这种模式，转向工业级开发者思维。什么是工业级？就是期约优先，凡事讲究基于证据。 各位，咱们肯定都经历过这种令人绝望的时刻对吧？ ai 信誓旦旦的跟你说搞定了测试，跑通了，结果呢？当你试图把代码拉下来打包或者准备部手上线的时候，轰！整个系统直接崩溃了。 这不仅让人纳闷为什么他在 ai 的 环境里就能跑，到了发布的时候就成了灾难？答案其实就在这原材料里，把这个叫做樟树效应。 简单来说就是你的 ai 其实运行在一个被严重污染的本地工作区里，那里头乱七八糟的塞满了未被 get 追踪的文件，以前运行残留的旧日制，甚至还有老旧的数据库缓冲。 ai 就是 靠着这些本地的脏一赖跑通了，然后给了你一个成功的幻觉，但实际上它根本没有触及真正的原码真相。 那么为了解决这种混乱，咱们需要实施这套包含六个部分的软件开发协议。首先是升级至工业级 ai， 接着是逃离樟树陷阱， 然后探讨契约优先模式以及决策三权分离，再到基于证据的工程化。最后是如何构建机构记忆，咱们马上逐一拆解。 好的。第一部分，升级至工业级 ai 停滞，把 ai 当做聊天机器人，咱们来看看为什么直接听信 ai 的 话是个巨大的陷阱。原文件在这里的表述极其直接， 永远永远不要相信一张简单的截图或者聊天框里的一句任务已完成。说真的，把口头结论当成验收标准，绝对是重灾区。 那些截图里的日制或者数据，你根本不知道是不是同一次运行产生的。接下来是第二部分，逃离脏树陷阱，寻找源码真相。 既然不能听信一面之词，我们要怎么去找到真正的源码呢？这个对比真的非常绝，你个 ai 必须也是只能从 get index 或者 had 中去获得源码的真相， 千万别让他去读本地那个又脏又乱，未经追踪的工作数来做判断。如果你只盯着本地文件，那些根本没进入版本控制的运行依赖绝对会引发大问题。咱们来看第三部分，弃约优先模式停止，一上来就写代码， 搞定了原码源头。接下来咱们要给 ai 建立规矩了，想要避免一个小小的修府，最终变成一场无法收场的代码大重写，这道名为 start gate 的 起跑门槛协议就显得直观重要了。 在 ai 真正去碰哪怕一行代码之前，他必须先过这一关。他得用中文向你重述他理解的目标，列出关键的假设，并且定义出最小的可行范围。最关键的是，他必须停下来，静静等待，你给他一个明确的批准，不这么做，后果不堪设想。 好了，第四部分，角色三权分立，防止任务无休止扩张。 为了进一步强制执行刚才说的纪律，我们要引入一套新机制原材料强烈推荐把 ai 系统强行划分为三个独立的现成，也就是决策上的三权分立。你看，控制者负责掌控大局和任务气约。 执行者呢，只管最窄范围的代码实线，最后是审核者，他的工作就是只拿着最初的契约，死死盯着代码叉一看。通过这三条独立的线程，所有的实线都会被牢牢拴在最初的契约上，决不允许越界。 第五部分，基于证据的工程化定义什么是真中的完成？咱们进入发布阶段，看看什么是无可辩驳的证据。 为了保证代码绝对能交付，这里提出了一套静态发布流水线。什么意思呢？就是把代码拉到一个完全隔离的新目录里， 脱离刚才那些复杂的负极环境，然后一步穿过这五道验证关卡。特别是最后一步，必须是在隔离环境里做全新的冒烟测试，缺一不可。 这就引出了整套协议里最核心的一句真言了，请记住，相信我，这 bug 我 修好了。这句话在工业级 ai 面前彻底失效。一项任务真正完成的唯一标准，是拿出实打实的证据根。 那么，什么是有效的证据根呢？它不是什么旧记录的残留，而是全新的在无菌环境中运行成功的实锤。比如退出码必须是 pass， 还要有全新生成的日制，加上经过哈希文政的包，只有当这些证据摆在面前时，控制者才会点头认可， 也表示着咱们从信仰编程真正迈向了基于证据的工程化。最后一部分第六部分，构建机构记忆，从环境陷阱中学习，光有流长不行，系统自己也得会长记忆深。 咱们来想象这样一个极其让人抓狂的场景，六十秒，仅仅因为在处理大文件 pdf 的 时候，外部的一个 ocr 工具自带了六十秒的硬性超时限制，导致整个流水线默默地、没有任何预兆的彻底亏本了。 排查这种问题简直能让人亏本，一旦这种戏讽级的隐蔽陷阱被揪出来，总不能只留在某个开发者的脑子里吧？ 所以，解决方案齐集系统哈协议强制要求把每一次失败，不管是刚才说的 ocr 超时，还是让人头疼的 windows 换行符问题，甚至是 s q l i t 被锁住的假失败，统统记在一个专门的 lessons learned 经验教训文档里， 每次开工权 ai 必须先读一遍。这样一来，系统自然而然就拥有了极高的稳定性，做到默认即可交付 好了，当咱们准备把这些强大的 ai 助手引入到团队的日常工作流中时，不妨问自己一个核心问题， 你是打算继续依赖盲目的信仰，任由 ai 在 樟树环境里野蛮生长呢？还是准备好实施这套严格的协议要求硬核的证据 彻底迈入工业级自动化开发的新时代，我想答案已经非常明显了。感谢大家收看本期的深度解析，我们下期再见！

哈喽，我是月半设计师，如何把本地的组件库变成 skill？ 三步教会你。第一步，绑定斐格码，创建 skill， 股价输入这段提示词，执行完成后就能得到这样的股价结构。 第二步，从斐克玛提取组建规范，接着输入这段提示词，执行完成后就能看到组建被拆成了 md 文件。第三步，定义 skill， 触发提示词，输入这段提示词，设置月半杠 u i 为启动命令。 最后演示一下 skill 是 否有用。我们可以看到右侧的设计图和我的设计规范不一致，利用 skill 可以 查找不一致并做出修改。 右键找到设计图的链接之后来到 coser 启动 skill， 并把刚才的地址粘贴过来，点击发送来到 fig 码，设计图就按我的规范做出了修改。

大家好，上一个视频咱们看到了，让 ai 在 电脑上全自动写 esp 三二的代码，还能自己编一烧录代码。其实这里面的核心就两点，一个是任务分块，另一个是让人类帮忙形成闭环。为啥要任务分块呢？ 因为让 ai 一下子完成一个项目，错误率肯定很大，把项目拆分成多个子任务，每个任务都按照规定流程运行，这样就能更有条理减少错误。 再说说让人类帮忙形成闭环，为啥现在 ai 写前端代码又准确，效率又高呢？因为它写完代码后可以自己翻译，然后通过脚本观察代码运行结果，再根据结果找 bug， 直到完成项目。 但嵌入式和前端不同，它和硬件挂钩， ai 目前没办法感知结果就行，不成闭环。这时候就需要 ai 自行翻译烧录， 然后由我们人类去反馈结果，让它去找 bug 形成闭环。简单来说，嵌入式的闭环就是 ai 写代码，机器自检报错，人类看物理现象， ai 在 修改 这个 skill 的 链接已经放在文案里了，当然这个 cq 还很粗糙，大家有什么建议也可以在评论区分析处理。

很多人用 ai 写代码，问题真不一定是模型不行，很多时候是每次都得重新教。今天这个 github 项目我觉得还挺实用，叫 scuse， 你 可以粗暴理解成给 cloud code code x 这种 ai 工具装技能包， 像代码审查，写测试，看项目结构这种重复活，没必要每次都重新写一遍解释词，直接调现成的就行。 我自己看下来，他最值钱的地方不是炫技，是能让整个过程稳定很多，特别适合那种已经开始用 ai 写代码但还没有把工作流程跑顺的人。我的结论值得是，尤其适合想把 ai 抠掉用的更稳的人。

最近我做了一个 skill， 可以 帮我自动修改和优化视频字幕剪映里面也有一键生成字幕的功能，但是它总是识别的不够准确， 尤其是一些发音比较类似的单词或者句子。这个 skill 呢，可以根据我们的上下文，让 ai 理解上下文语义，然后再做出具体的修改。在修改完成后，会生成一个这样的 html 文件，让我们进行确认。我们可以看到，在这个页面上，首先列出了字幕文件的总条数 以及已修改的条数和未修改的条数。然后下面我们可以对 ai 修改的字幕进行审查。这是我前两天做的 cloud code 的 视频的一个字幕，这里列出了每一行字幕文件中的编号，以及修改前后的字幕对比，我们可以进行检查，然后选择是否要保留这个修改。 所有的修改默认都是保留的，如果它的修改有问题，我们可以在这里选择拒绝。而且大家可以看到这里有两种不同的修改依据。 首先我们会定义一个规则文件，这个规则文件中存储了一些高频出现的字体，并给出了对应的替换策略。 ai 在 修改我们的字幕时，会先根据这个规则文件进行替换，对应的就是这里的规则命中。其次，在按照规则文件中的全部规则执行完一遍之后， ai 会根据我们的字幕进行上下文分析，他会分段读取文件中的所有内容，检查语义上是否存在不合理之处，然后给出修改建议。 就对应这里的 ai 建议，如果有一部分内容出现错误频率比较高，我们也可以在这里把它加入规则列表中，这里我们可以输入原本的文字内容，再输入修改后的内容， 然后点击导出，就会导出一个 json 文件，然后我们可以把这个导出的 json 文件交给我们的 agent， 让它合并并补充到我们现有的规则中。如果要查找原始内容的话，我们也可以在上方搜索栏进行搜索， 这里还有一栏是未修改的字幕，这是便于我们检查是否有遗漏，如果某一行有遗漏的话，我们可以点击这里的手动修正，可以看到这里有行号原字幕以及修改后的字幕，我们直接编辑修改后的字幕，然后保存就可以。在全部修改完成后，我们可以在这里导出一个最终版的 s r t 文件， 这个导出的文件可以直接导入到我们视频里面使用，这样我们就不用在视频里面再去做字幕校对了。这个 skill 呢，我也已经开源放到我的 github 上了，如果有需要的朋友也可以直接拿去使用。

程序员发明了 ai， ai 却替代了程序员。今日最新 skills 这个文件让 ai 少写百分之八十的无用代码，已经在跌踏步上拿下五十五 k 星标。有人把 ai 大 神卡帕西的编程哲学直接封装成技能，你不需要重新训练模型。这个 skills 文件能改变 ai 的 做事方式。卡帕西用四条原则解决 ai 失控问题，非 before coding， 让 ai 不 确定就问，不要猜，不要默认用户想要什么。这里从源头上打断 ai 幻觉链条。 simple city first， 让 ai 用最少代码解决问题，不写未来功能，不做假装高级的抽象，让 ai 把任务转成可验证结果，用结果判断而不是感觉。本质上让 ai 从写代码变成完成验证目标。

学 ai 开源项目代码看不懂怎么办？我用 ai 做了一套学习系统，我最近想学一些优秀的开源 style， 不是 为了抄代码，是想学背后的思维方式，人家是怎么设计的，怎么拆解问题的？但问题来了，我是编程小白，一个文科生，去看 gethelp， 麦麦密看完了，大概也只能知道这个项目能干嘛，但他为什么这么做，我一点都不知道，直接让我开代码，我也看不懂， 你没有这种感觉，想学，但不知道从哪里下手。后来我发现了一个理论，布鲁姆的 to see 理论。一九八四年，教育心理学家布鲁姆做了一个研究，一对一辅导的学生，学习效果超越了百分之九十八的课堂学生。 为什么呢？因为一对一辅导是这样的，老师会问，你这个懂了吗？没懂，他还会换个角度再讲一遍，直到你真的理解了才往下走， 这才叫真正的掌握学习。我就在想，能不能运用 ai， 把这道方法变成一个系统。于是我用可拉库的做了一个 style， 他 有两个模式，模式一是快速分析， 他会帮我分析一个开源项目，做成一个深度的报告。报告不只是告诉我这个项目是做什么的，而是告诉我 这个项目用的什么思维，这个思维可以用在哪里，里面的代码我哪些可以直接用。学完之后，我不只是知道了这个项目是做什么，而是真正掌握了这背后的设计方法论。 模式是深度学习， ai 会根据我的背景生成一套交互式的学习路径。每一课结束后， ai 会问我几个问题，根据我的回答判断我是不是真的懂了， 答对了他就会继续下一课，答错了他就会换个角度再给我讲一遍，直到我搞懂为止。 这就是布鲁姆 two c 杆的核心，真正弄懂了再学。这套系统做出来之后，我自己写是先用了一遍，安装完 scale 以后，我们在 color code 里面敲上这个 scale 命令，然后他会加载两种模式，模式一是 markdown 报告模式模式，二是交互式学习路径模式。 然后他要我们提供要学习的开源项目的链接，或者是本地路径名，然后我就把 我 github 的 一个链接给发给他了，也是我们刚刚做的这个 skill。 发完链接之后，他会让我们选择要学习的模式，是直接给报告还是交互学习。我们这里选择模式，以深度报告模式， 然后回车等待一下，他就自己在跑。过了一会他就把这个学习包围写出来了，大概六千五百个字。我们现在来看一下 这份报告，大约六千五百个字，分为六个部分，第一个部分是速读版，五分钟可以读完，帮你大概判断这个项目值不值得深入学习。 第二部分是项目概述，介绍这个项目是做什么的，然后代码健康度啊，健康指标，它的整体架构是一样的。第三部分是工具层分析，他会详细拆解六个核心的功能，每个功能至少三百个字以上，包括 双模式学习系统呀，快速项目分析啊等等之类的。接下来一个部分我们看一下。接下来部分是能力层，这是报告最核心的部分，它提取了五个可以附用的思维模式，可以直接拿去用， 看写的非常详细的。下一个部分是立即可用清单，它还会列出我们可以直接复制的代码片段、配置文件和思维模式，方便你直接拿走。 然后最后一部分是项目评估，他会评估我们做的好的地方，然后可以改进的地方，如果是他自己，他会怎么做？这个 scale 看是写得非常清楚的，之前我看一个开源项目，可能看完就忘了。现在我分析一个项目，用这个 skill 能写出非常好的深度分析报告，这些内容我都会 慢慢真正理解。更重要的是，我不只是学会了这个项目，我还提取了可以附用的思维模式三六这个项目，这个思维还在。如果你也想高效学习，如果你也想用 ai 做一些有意思的事情，欢迎关注我。我是情深，能一啪不离，我会持续分享我的探索过程，我们一起进步。

很多人以为给 cloud 写技能很麻烦，要手写代码，要懂格式等等，其实完全不是。今天我教你最简单的方式，让 cloud 替你写技能。我们先花三十秒了解一下技能长什么样。 一个技能就是一个文件夹，里面通常有几样东西， skill 点 md 核心文件，这个必须有 script， 放可执行脚本，比如自动发邮件，调用 api 的 代码等等。 reference 放参考文档，比如你公司的写作规范，行业术语表等等。 assess 放模板素材，比如固定格式的周报模板，邮件模板等等。 记住一件事就够了。 skill 点 m d 是 灵魂，其他都是配件。 skill 点 m d 分 两部分，第一部分是原数据，就是一段固定格式的说明， name 添技能名称 description， 写这个技能是干什么的，什么时候用， 其中最关键的就是 description， cloud 就 靠这段话来判断要不要加载这个技能。 所以 description 必须说清楚两件事，能做什么，以及什么场景下用， 最好带上你平时真实会说出口的关键词。第二部分是正文，用普通 markdown 写清楚步骤，视力常见问题就行，没有什么特别格式的要求。流程总共分三步，非常简单。第一步，先口头描述需求，把流程跑通。 比如我每周需要整理客户反馈，按问题类型分类，生成一份儿总结报告，然后一起把这个流程完整跑一遍，确认结果是你想要的。第二步，用 skill creator 封装流程跑通以后，直接说用 skill creator 把我们刚才的流程封装成一个技能，它会自动生成格式规范的 skill 点 m d 原数据， description 步骤指令全部帮你搞定。第三步，启用技能这里分两种情况，如果你用的是 cloud， 点 ai 网页端，把文件压缩成 zip， 进入设置里的技能页面上传开启就行。 如果用的是 cloud code 更简单，封装好之后直接就能用，不需要上传任何东西。 cloud 会自动识别本地的 skills 文件， 之后只要你说出触发关键词，它就自动加载，不用每次重新解释。如果你想改，直接告诉 cloud 哪里不对，让它自己改，全程一行代码都不用动。