claude读错excel怎么改

今天 cloud code 自动更新完，会出现一个 api 四百错误，目前的解决办法就是直接在这个扩展里边去把自动更新给它取掉，然后回退到呃过去的版本，呃这里边去回退到一天前重启扩展以后 cloud 就 恢复了。

用考核 code 啊，最烦的一件事情是什么？你交代他一个任务，转身去倒杯水，大家发现他还停在那里等着你确认。改个文件要问你，装个工具要问你，连建个文件夹都要问你，那其实不是没有办法，是你还不知道。考核 code 啊，有六种权限模式， 那选对了他就不烦你了。那第一种， default 默认模式，每一步都要你确认，最安全，但也最打乱节奏。第二种， accept edit 模式，工作目录里的文件编辑啊，全部都自动批准， 但终端命令还是会问你。第三种， plan 模式，那 cloud 只读不写，先帮你规划不动你的代码。第四种， auto 模式，背后有个 ai 安全分类器，实时把关，安全的放行，危险拦截，不需要你逐个确认。第五种， don't ask 模式， 默认拒绝所有操作，只执行你提前加入白名单的工具，那适合需要精细控制的场景。第六种， by pass 模式，那用这个命令可以启动，跳过所有的提示，只建议在格力环境里面用。那还有很多人问我啊，为什么 shift 加 table 找不到 auto 和 don't ask 的 模式， 那 dosask 啊，只能启动式加参数进入，那 auto 呢？需要先跑这个命令来解锁，而且 pro 账户用不了，需要 max 以上的订阅计划。那最后啊，一句话来，选，模式默认用 default， 改代码用 accept edits 看方案用 plan， 智能全自动，用 auto 精细控制啊，用 dosask， 完全不打断啊，用 bypass。 那 你觉得可拉库的最烦人的事情是什么？欢迎在评论区分享。

用括号扣的啊，很多人一上来就会踩坑。那今天收五个最常见的。第一个，指令太模糊，帮我修复登录 bug。 那 到底报了什么错？附件步骤是什么？你想要什么结果？那 cloud 的 不是你肚子里的蛔虫啊，你给他信息越少，他猜的越离谱。 正确的做法是啊，把文件路径、报错，截图、日制全甩给他，再说清楚附件的步骤和你期望的结果。你喂的越细啊，它输出越准。第二个，不用 cloud 点 md。 cloud 点 md 是 什么？ 就是在你的项目根目录下放一个叫 cloud md 的 文件，里面写上你的项目背景，技术栈，编码规范。那 cloud 的 每次启动的时候都会去读这个文件，没有它啊， cloud 每次都要重新去参与这个项目，到底是干嘛的？有了它，一上来就能够进入工作状态，很多新手压根不知道有这个功能啊，但其实它真的很好用。 第三个，一次性让 cloud 改太多的东西，有人一上来就有一个超大的需求，让他一口气重构整个项目，然后呢？改着改工了，那你都不知道是哪一步出了问题。那正确做法是啊， 把大学九拆细，改一点验一点，每次改完让他帮你提交代码保存进度出了问题啊，你还可以回滚。那第四个，改完不验证，这个坑最多人踩啊。 卡拉扣的改完不代表他改对了代码能跑，也不代表逻辑对了，有时候他还会偷偷影响别的功能，你可能都不知道。所以啊，一定要让卡拉扣的帮你写完测试并验证，验证通过了才算完。 第五个啊，不管你对话长度聊太久，对话越来越长， cloud 的 输出质量就会下降，他记不住前面说过什么，或者会记混。那怎么办呢？用两个命令，第一， compact， 压缩历史对话， 保留关键的信息，减少上下文的占用。第二， clear， 直接清空上下文，从零开始。那任务做完了，最好开个新的对话，别在同一个对话里面聊太多的东西。那这五个错误啊，你中了几个呢？欢迎在评论区聊聊。

很多小伙伴问怎么让 cloud code 接上 deep seek？ 这条流程我从头到尾给你讲一遍，照着走就行。 视频稍微有点长，建议先点个收藏，耐心看完，按步骤动手。先说清楚， cloud 是 anforepic 的 网页和 app 聊天助手，你打开浏览器就能用。而 cloud code 是 跑在你电脑终端里的编程搭子， 它能直接读你的项目代码，改文件、跑命令，相当于把 ar 装进了你的工程目录。更狠的是，凭借社区里那一大批开源 skills， 它还能调度你电脑里的一切浏览器表格、邮件、设计稿，几乎想自动化什么都可以。 为什么要接 deep seek？ 两个原因，在国内访问稳定，不挂代理，按 token 计费，也比海外接口便宜不少。而 deep seek v 四 pro 的 能力，应付日常写代码、改 bug、 做重构绰绰有余。 开始之前先准备两样东西，第一， node js 十八以上版本提前装好，长期支持版就行。第二， get for windows， windows 用户必装，不装后面依赖会报错。 第一步，安装 cloud code， 在 开始菜单里搜 power shell， 右键以管理员身份运行。打开窗口后复制官方的 m p m 命令，粘上去回车，等它装完。 装完输入 cloud， 加上版本参数，看到版本号就说明装好了。第二步，获取密钥， 进入 api 开放平台，进入控制台后，在左边的侧边栏找到 api keys 这一项，点进去， 页面下方有一个创建 api key 的 按钮，点一下弹出小窗，给这把密钥起个名字，比如就叫 demo， 然后点创建， 创建成功之后会弹出一个密钥字符串，立刻点复制保存到记事本或者密码管理器里。特别提醒，关掉这个窗口之后，密钥就会变成密文，再也看不见。 如果你不小心丢了，只能删掉，重新创建一把。第三步，配置 cloud code， 打开文件资源管理器，进入 c 盘用户目录，再进入点 cloud 这个文件夹。 如果看不到点 cloud， 要先在查看里把隐藏项目和文件扩展名都打开， 然后新建一个文件，名字叫 settings jason 把这段配置直接复制进去，把 api key 行换成你刚才复制的密钥保存即可。第四步，验证打开终端或者 power shell， 输入 cloud， 回车 看到红色边框的欢迎界面，模型型显示 deep seek v 四 pro， 就 说明已经成功接上 deep seek。 最后再送一个加分项。如果你平时在 vs code 里写代码，配好 antropic 官方的 cloud code 插件， 装完进入侧边栏的 cloud code chat， 它会自动识别你刚才配置好的账号，直接就能在编辑器里聊天和改代码。 整个流程下来，你就拥有了一个本地终端加编辑器，双端可用的用 deep seek 驱动的 cloud coat。 你 学会了吗？欢迎评论区聊聊。

我敢说，百分之九十九的人刚刚安装好的 call 扣，第一步就做错了。就是很多人会着急让 call 扣直接开始干活，然后会发现，哎，为什么好像有些时候还挺难用的呢？ 但实际上并不是说模型不会做，而是他根本不知道你的规则。 ok？ 大家好，我是 fred， 专注从普通小白的视角分享怎么从零到一，用 ai 和 web 扣领提升自己的生活和工作效率。 我建议安装好 cloud 后的呢，第一步不要着急让他直接开始写，而是把 cloud md 配置好。你把规则讲的越清楚，他在后面才会更懂，你也不太容易反攻， 就很多时候很多重复的工作啊，其实问题都差不多，就要么是你讲太多，要么是你改太多，要么就是你每次都会觉得他风风格都不太稳定，对吧？ 你本来只想让他改一个点，他却顺手改了一大片。你本来想让他按照项目的习惯来，他却给你一套看起来通用但正确的，但是又不太符合你要求的一些答案。 这些问题的背后，很多时候不是说模型不行，而是你没有把这个默认的规则交给他。那怎么样才能让他按照你的默认规则来呢？也就是很重要的一个点就是 cloud md。 什么是 cloud md 呢？你可以把它理解为 cloud code 的 一个默认的规则文件写进去之后呢，它不是一个一次性的聊天备注，而是 cloud 开工前就会先读的一个写作的边界。所以说它的真正的价值不是说 多一个文件，而是你终于不用每次再重新去解释。同样的话，一次写好之后就后面会默认去生效。 但这里面还有一个很关键的点啊，就是很多人一上来就在想，我要往 cloud md 里面去写什么，其实第一步不应该想怎么写，而是先想， 呃它有哪些层级？就是正常 cloud md 会有一个全局的层级，一个是项目的层级，也就是通用层和项目层。通用层就是写，写到你在每个项目都不会变的一些长期的习惯和规则。项目层就是写，写到你在每个项目这个仓库它独有的一些规则， 你把这两层分清楚之后，后面写起来才不会乱。 ok， 大家可能会问，哎，那你应该怎么写呢？对吧？通用层应该写什么？呃，像我自己的话，一般会有一些语言的规范、安全红线、工作流程和用户偏好。 我可以给大家看一下我整体的一个配置的一个情况，就比如说语言会要求他用中文跟我沟通，但是代码还是用英文，然后会有一些安全红线的问题， 不要去提交一些我自己的一些 api， key 啊，或者一些密钥。工作流程呢？就是一定要强调， 呃，完成报告之后，然后有报错就得报错。然后且修 bug 之前需要先写一些失败的测试用力，包括说代码标准不能够写得太大，如果写得过多大过长，如果后面要修改，那包括一些用户偏好的一些问题， 包括说其实像我的 cloud md 和我的 codex 所用的 agent md 其实完全是一样的，也就是我在切不同模型之间，它实际上的效果也是很不错的。然后面还会有一些上下文管理的一些问题， 所以说你会发现这些都不是某个项目特有的一些细节，而是我希望 cloud 在 任何项目里面都默认遵守的一些写作习惯，所以说如果在这种我在哪都一样的这样的一些规则，就应该写到通用层里面， ok， 那 项目城里面应该写什么呢？就比如说拿我先 free talk 这个剪辑视频的项目来说，项目城最应该典型的就是，哎，比如说每一层级你的唯一的入口， 你的输入输出怎么放，你的内容生产怎么交接，包括你的一些发布和一些安全的规则，其实这些规则离开这个项目其实就不一定成立了，但是如果只是在这个项目在成立的规则，那就应该写在项目城里面， ok， 如果你也想要开始配，我建议大家理解完这三层的东西之后，然后就够用了。然后如果怎么配置呢？其实很简单，一是我呃在视频后面会分享到相关的一些配置到呃我的粉丝群里面， 然后如果大家呃不感兴趣，也可以去搜索一些，比如说像 tiktok 上面一些高新的一些配置，比如说像 everything cloud code 啊，然后把你这种当做下来的一些规则文件发给 cloud code， 然后它可以根据你的通用层和项目层帮你去抄一份属于你自己的 cloud md。 但是呢，呃，你可以在后面跟它按照你的一些项目细节去补充 啊。写完之后他会有什么变化呢？就最直接的变化，不是说他会马上帮你把这个页面做的好看，或者说帮你把这个项目做的很很厉害，对吧？而是说他会让你的写作更顺，也就是写之前你可能反复在解释，然后他可能会给你一些泛泛的建议。 写之后呢，他会更更容易按照你的项目节奏直接去开干，以及按照你定义好的边界和风格来做，所以他 不会变得完美，他会更像一个更懂你的一个项目的写作者。所以说，总结下来， cloud md 的 本质就是把你反复叮嘱 cloud 的 话一次性写清楚，先分先分成，再定规则，再让 cloud 干活， 然后他才会越来越懂你。 ok， 我是 fred， 后面我会持续用真实的案例告诉大家怎么把 ai 用进自己的工作流里面，我们下期再见。

啊，这个今天我在用这个 vs code 的 时候呢，它这个这边出现了这种一个报错，然后我去网上查了一下，啊，这是那个 cloud code 更新产生的一个问题， 其实这个很好解决啊，就把我们的扩展打开，把这个自动更新给它关掉，之后呢就安装特定版本，我是倒回到这个一点五二之后它就可以用了。啊，我们再试一下啊， 重启一下，我感觉应该是它这边卡住了。 啊，可以看到啊，这边已经开始思考了。 ok， 可以 了，可以了。

不会写代码的人怎么把 cloud code 用到极致？三个月，每天八小时，我留下这十九招。第一个也是我觉得开启会对你使用 cloud code 有 很大帮助的。在终端输入斜杠， s t a t u s l i n e 你 就可以自定义你看到的信息，比如说模型的类型，上下文的占比， 成本等等。它会生成一个显示在终端底部的小脚本，让你在对话过程中随时可以通过下面的仪表台来监控你的各项指标，从而有效的避免你的上下文污染。这个功能在你最开始使用格拉格的时候对你的帮助会很大。 第二个也是我给别人疯狂安利的 command， 你 可以把它理解成快照，你在文件夹里面改动的任何东西 都可以给你保存下来，并且你还可以随时的回滚。当然有一个前提是需要 get 初步化你的这一个文件夹。第三个，斜杠 care 这一个命令在我每次进行过 command 之后，我都会使用这个命令来进行对话的新建， 一个是确保我的对话清晰明了，另外一个是确保我不会浪费更多的托管和上下文造成的一个污染。第四个也就是计划模式， 你可以按住 shift 加 tab 切换，你也可以输入斜杠，然后 pan 打开计划模式。你需要养成任何非日常工作都把这一个计划模式开启的一个好习惯，这样可以保证你在进行任何 动作的时候，都可以让大模型能够更明确的理解你的需求和指令，可以更好和更快的完成你的任务。第五个，不要总是对可乐下达一些模糊的需求，比如写一个功能，或者说我需要修改这里的效果，我不是特别满意这种话，这样他是不清楚你想要的东西的， 你应该学会向他抛问题，比如问他这样的效果，如果你是用户，你会不会满意？让他先自行推理逻辑，他的产出的质量会更高，这类似于计划模式，但会让他思考的更深入。第六个是让可乐的主动的向你提问。在计划模式下，他通常会问你问题，但是你也可以主动的要求他， 请不断的向我追问，直到你了解我百分之九十五的一个需求。第六招也是我经常会用的一招，就是他在产出一个计划之后，我会让他以一个新的顾问的身份去从事 重新的审视这一个计划，往往他会找到计划里面的一些漏洞，或者说过度设计。第八招就是加一个质检步骤。我们可以看到，在很多时候，克洛德在执行任务的时候，他会创建一个代办事项，你完全可以在这些代办事项里面加入一个质检步骤， 这样子他会在最后进行质检，确认没有问题后再给你验收。第九招就是在每一个项目中运行 i n i t。 这一招通常是用在你已经有一个包含了文件的现有项目，打开它之后，你输入这一个命令， color 就 会自动的扫描你的代码库，文件夹和里面所有的文件， 并且呢生成一个 color 点 md 文件，这本质上就是项目的一个备忘录，它会梳理出来你的结构、编码、规范和关键文件。 这样一来你就不需要每次都解释项目的一个情况，如果你是从零开始构建项目，也就是说你的文件夹里面什么都没有，同样也可以输入这一个命令 来描述你项目目标和你的一些文件内容，文件结构，让克拉克库的协助你创建。第十招，及时止损，在做你的任务的时候开始跑偏，一定不要让它写完，直接按 esc 停止，重新修正方向后再让它运行。错误的 token 消耗都是在浪费上下文， 并且会浪费你自己的一个额度或者说 api， 尽早的干预，毕竟它只是一个 ai。 第十一招，也就是使用两下 esc 快 速的撤销，如果走错路了，直接两下 esc， 你 可以回退到你对话的任意一个节点，不需要从头再来，就是非常的快，非常的迅速，但是它会造成你回退之后的下面的内容完全消失不见。第十二招，也就是使用 hux 进行通知，输入斜杠 hux 可以 设置通知提醒， 比如我设置了当可乐完成绘画时发送声音提示，这样你就可以专注于其他工作，当你听到声音的时候，你就知道任务结束了，你需要去查看。第十三招，就是使用截图，可乐是有视觉能力的，这一招其实非常的实用，比如说你可以把爆出的截图和你想要的一些灵感网页 都直接截图喂给他，这样他就可以更明确的知道是什么地方不对，然后需要修改哪些地方比你模糊的给他说这个位置不对，效果要好的特别特别的多。第十四招，就是利用 get 工作树， 这个名字听起来像是一个程序员的专属，但是其实他是一个非常好用的功能，你可以把他理解成一个平行世界。 就是在一般的情况下，如果我们开启两个 color code 进入到同一个文件夹，那么他们在进行工作的时候可能会互相的覆盖文件，或者说你在使用 codex 进入到这一个文件夹，又在使用 color code 进入到这一个文件夹，你就可以使用这一个 get 工作数的原理，让你的 color code 是一个平行宇宙，让你的 codex 是 一个平行宇宙，让它们分别精心工作，腹部干扰，这样子你在所有的效果完成之后，可以把它们选择性的合并到你的主线。这一招在我使用 codex 和克拉克的进行写作的时候会经常使用的。 第十五招就是优先的使用 api 端点，而不是 mcp 服务器。 mcp 服务器虽然方便，但是它会占用特别多的一个上下文， 比如你只是想使用特为你的搜索功能，你只需要填入 a p i 就 好了，没有必要安装他的 m c p， 我 自己的话是非必要不安装。 第十六招，通过手机远程操控，你只需要打开这一个命令，然后扫描这个二维码，你就可以在电脑上开启任务后离开，你可以从手机或者说任何浏览器控制这一个对话。 第十七招，也就是超强思考模式，这每一次都是我在切换模式搞不定，或者说或者说有难题无法解决的时候，我就会开启它。 开启它之后，科罗岛会给他分配特别高的一个思考预算，在面对复杂的架构决策或者说顽固的 bug 时， 它可以很好的处理掉。第十八招，也就是使用智能体团队 agitim 四这一招，其实在我这一招其实在我这段时间来说经常的使用，因为它们之间是可以互相对化的， 也就是说你只需要开启这一个功能，那么你的主线上面的 oppo 的 四点七就可以做一个顾问，然后派一些索尼特呀，呃，或者说其他的模型去执行任务，然后回来报给你。 这一个它和子代理是有区别的，子代理的话是没有办法通信，没有办法共享任务列表，这个 a g 的 team 是 它是可以的，但是它的资源消耗会特别的多，所以你需要 呃自己取舍。第十九招就是 skulker， 就是 技能创建，这一招在很多时候都特别的有用，这之前我已经出过视频讲过了，它就是以一种特定的方式去执行特定的事情的一种模型，所以在平时你很多重复的工作你都可以做一个 skul 让它去做， ok。 以上就是我作为一个非程序员经常会使用到的克拉克的一些技巧分享，当然我也知道克拉克还有很多其他的一些命令，比如说上下文查看这一些，但是说实话我自己真的不是那么的经常使用， 所以我在这里就不做分享了。这就是本期视频的全部内容呢，如果你觉得对你有点帮助的话，那么就收藏转发，我们下期。

今天的目标是手把手教大家在没有魔法、没有 cloud 账号的情况下，如何安装 cloud code， 不 需要任何代码基础。纯小白友好，我从 cloud code 的 内侧就开始用，到现在已经一年多了，每天工作都在用。但我并不是程序员，也没有任何技术背景，所以我想从我的视角做一个系列视频， 结合我实际的工作场景，从安装开始，一步一步带大家上手。先快速回答几个大家在安装前可能有的问题，第一， cloud code 和前段时间很火的小龙虾是一个东西吗？都是顶尖的 ai agent， 但路线不同， 小龙虾走的是广度路线，他活在聊天软件里，覆盖几十个平台，帮你处理跨平台的消息、日常邮件、 qq 了，走的是深度路线，他的规划模式、上下文管理这些设计，都是为了把一件复杂的事从头做到尾。我们在工作中要做的调研分析、小工具、工作流，本质上都是造一个完整的东西， 这是 ko 擅长的。第二，有那么厉害吗？能用来干啥？我是零技术背景的产品经理。举个例子，一份行业调研报告，以前我要花一周，现在跟他说一句话，十分钟出来做一个内部投票工具，以前要找开发排期，现在我自己半小时就做好了。我甚至还自己搭了一套广告物料投放生产的工作流，一天可以做十几组物料图。 第三，没魔法，没 ko 账号，还有必要装吗？市面上大多数 ai 编程产品，本质是 ai 辅助你写代码，前提你得懂代码， code 是 你说目标 ai， 自己从头做到尾，全程不用空代码。对零技术背景的人，这才是真正的用的形态，而且国产扣顶模型这一年做的特别快，接近 qq 里使用，可以满足大部分场景。我用 mac 来演示 windows 的 安装命令，我截图放在视频最后了，大部分步骤是一样的。第一步，装 homebrew， homebrew 是 mac 上的一个软件管理器，可以通过它来安装 qq 的。 打开终端，复制这行命令，粘贴发送。这个时候要输入密码，看到这个提示的时候回车就行。装好之后，这里会提示我们加一个路径，照着他给的命令我们复制粘贴跑一下， 我们可以输入这个命令验证一下。好，这个时候我们可以看到 homebrew 的 版本号了，说明已经安装成功。接下来就是安装 curl code， 同样是复制这一行命令，粘贴到终端里发送。 当我们看到这个 successfully installed， 说明 curl code 已经安装成功了，我们可以复制这一行命令验证一下。 看到最新的版本号是二点一点一四三，说明安装成功。同时我们可以输入 cloud， 当我们看到这个橙色的小螃蟹的时候，就说明已经安装成功，但这个时候还没有接入模型，它只是一个壳，我们可以先退出，连按两下 ctrl 加 c 退出。第三步是安装 cc switch， 我 们把这一行命令复制下来，然后在终端内发送 c c switch 是 一个模型管理工具，装好之后可以一键切换不同的国产模型，不用手动去改配置文件提示 c c switch 已经成功安装了。第四步，拿 api key。 我 今天用的是小米 miimo， 选小米纯粹是我自己用，觉得效果不错，性价比也高。浏览器搜索小米 api， 小米的话，因为我是订阅了它的一个月度套餐，所以 api key 和 base url 都跟 api 这边呢是不一样的。进到 cc switch， 点击右上角的加号，然后选择自定义配置。这里我们需要手动填写相关信息，把小米的 key 填进来，然后把兼容 andropic 接口协议的这一个 base url 复制粘贴过来。 点击获取模型列表，在列表当中选择 mimo v 二点五 pro 默认兜底模型。选择 mimo v 二点五 pro 添加仅用刚刚添加的这个。回到 terminal， 输入 cloud， 可以 选择一个自己喜欢的配色。看到安全提示继续按回车就好。选择使用推荐的设置，确认信任这个文件夹目录。 这里已经出现了 mimo v 二点五 pro 的 模型名，我们尝试对话试试。看到这里，恭喜你在没有魔法且没有 qq 账号的情况下成功安装了 qq， 可以 开始开 coding 了。可以尝试让它做一个小网站试试看。 除了小米， mimo c c switch 里还可以接其他的国产模型， g l m， deepsea， kimi， mini max 都行。配置方式是一样的，在 c c switch 里加一个供应商就行。 qq 很 快就把这个 excel 文件写好了，打开这个看一下效果。 到这里，我们已经成功地用 color code 写了第一个 web coding 的 小应用。 windows 的 同学安装逻辑完全一样，只是命令不同。 第一步用 winget 装 git， 第二步用 winget 装 color code， 第三步到第五步跟 mac 完全一样。装好只是第一步。下一期我会讲安装后的必要设置，不同的模式以及 skill 体系。大家有什么想要了解的，也欢迎评论区留言。这是 color code 从零到实战系列的第一期，如果你觉得这个视频有用的话，可以给我一个一线三连催更，我们下期见。

就我相信很多刚开始用 coco 的 小白啊，其实只知道一件事情，就是在对话框里面去输入需求，对吧？然后比如说你让他去写一些代码，让他改一些文件，或者让他去解释一些报错，但很多人不知道，就是 coco 里面还有很多 命令的快捷键，能够提高大家效率。所以说今天 fred 会给大家分享五个最基础的命令，学会之后我觉得能够对于你使用 cloud code 有 非常大的帮助。 ok， 大家好，我是 fred， 专注从普通小白视角去分享怎么从零开始，用 ai 和 webcoder 去提升自己的生活和工作效率。 我觉得很多时候新手最大的问题往往不是不会提问，而是不知道 cloud code 除了对话以外还有这些命令行。就比如说 你设置，如果不清楚，你可以去看一些 config， 看你的整体的设置状态。如果你觉得哎，你的任务变难了，或者需要换一些复杂的任务，你可以去切换你的模型 model。 然后如果你觉得你跟这个对话已经聊得差不多呢？或者说聊的方向不对，你想要新开对话，那你可以 clear 去重开对话。 然后如果你觉得你呃的整个对话还是比较有价值，但是上下文额度快满了， ok， 你 可以 compact 去压缩上下文。然后如果你已经关掉终端，想要去重启之前的对话，你可以按 continue， 然后去回到上一次的对话。 而我们今天呢，我会一个一个给大家去讲解。比如首先第一个就是 config， 我 们可以把它呃进入到我们的 config 里面去看一下， 比如大家可以看到 status 这边就是你整体的一个状态，比如说你用的 model， 然后你的代理的地址， 然后 config， 这里嘛就可以看各种开关，比如说你的 auto compact 是 否自动去压缩上下文，比如说你的 syncing mode， 然后 usage 这边可以去看你整体的整体的用量，对吧？尤其是你是订阅制的，也可以看到你的呃五小时或者周度的用量额度。 the status 这里就能够看到一些更细的一些使用统计， 所以说你不需要，可能一开始上来就懂每一个设置项，先知道状态在哪里看设置在哪里改，然后以及用量在哪里查。 第二个命令就是 model， 哎，就是呃，尤其是大家用一些订阅的账号的时候，大家可以在一些简单的任务里面去呃换一些 model， 哎，这里面也一样，就比如说你点击 model， 这里面可以去换，比如说你一些简单任务，你可以用 solid， 然后一些复杂任务可以用 oops 四点七，然后包括说或者你可以用 dcb 四 pro。 所以 说在一些对应的任务里面，你可以切换不同的模型啊，用一些最合适的模型来完成你的任务。 第三个呢，其实就比较简单呐，就是例如就是清理上下文，很多时候你不是需要继续地去解释，而是需要重新对对话开始 啊，比如说前面已经试了好几个方向，可能可能已经误解了你的目标，或者说你准备切到新的任务，那这个时候就不需要在旧的上下文里面去硬聊啊， 可以直接用一个 clear 开个干净的对话，然后再去说目标啊，包括你的材料和你的完成的标准。 第四个呢？我觉得就是，呃， compact， 就是 如果你聊的方向没错，只是可能聊得太长了，那用 compact 就 能够帮你把前面的一些聊天的内容压缩下去，然后能够其实它更像一个那种 交接的这种文档和交接记录，然后你会有更多的一些上下文去聊剩余的事情。然后最后一个我觉得非常非常有用，也就是 continue， 就 它非常适合，就是你关掉终端，比如隔天回来，或者中间被打断以后，然后再去继续做上一次的任务，比如说我们这里去啊 continue。 对， 然后这里面你可以选你之前做过一些任务，比如说这里，哎，你是 d p c v c 这就是前段时间我 上一期视频里面录的东西。 ok， 所以 说最后总结下来的话就是，我觉得不要把所有的问题都只是在对话框里面去沟通，哎，你继续改你回到上一次的任务啊，或者怎么怎么样，而是，呃，如果你设置不清楚的时候，先去 con configure， 如果你想要换一些模型去，可以切换模型，如果你可以 clear 这个对话，如果绘画太长，你想要压缩去交接，那就用 compact。 然后如果你想要下次回来重新复述后继续，那就用 continue。 ok， 我是 fred， 后面我会用。呃，继续用一些真实的案例去告诉大家怎么把 ai 用进自己的工作流，我们下期再见。

cloudmed 写得再细， cloud 还是会忘事。这事你肯定遇到过， astropica 官方文档也说了，规则明明白白写在那儿，模型也读了，但执行到某一步，它就是绕过去了。 这一期我想跟你聊清楚为什么以及怎么解决。先说一句，这是一个系列，前两期讲了 cloudmed 怎么写 cloud 目录，下五层配置都干嘛用。 从这一期开始，我们其实在做一件更大的事，把 cloud code 这套东西搭成一条你可以每天照着走的工作流。今天讲的是这条工作流里最容易被低估的一层， hooks ansorepic 自己其实在官方文档里把这层关系写得很清楚，它们把 cloud code 的 能力分成了四层，如果 cloud 每次都该知道的是放 cloud mate， 如果有时需要放 skill 或者 rules， 如果必须每次都发生，放 hulk 也是本期视频重点讲的。 如果某类能力根本不该碰，直接用 permissions 收回来。这四层最容易被混着用的就是第三层， hook。 这一层很多人压根不知道它存在或者知道，但没意识到它解决的是个完全不一样的问题。 那 hook 到底是啥？先问你一句话，你是不是遇到 clod 不 听话的情况？那可不是你的提示词有问题，提示词是软约束，而 hook 是 百分之一百执行。告诉我，你的 clod 是 经常不听话吗？我前阵子让 clod 帮我清个临时目录， 他自己拼了个 r m r f 出来，因为之前在项目目录下已经手动确认跳过这个执行权限，所以自动执行了。还好那是个测试目录。 一句话讲明白 hook 是 什么，它是 code， code 在 自己生命周期的关键节点上让你挂一段强制脚本的入口，用户提交 prompt 之前工具调用之前，工具调用之后，对话结束等等。官方文档列了三十多个事件，但实际上你只要先记住两个就够用。最常用的是 pre to use 和 post to use， 一个在工具跑之前拦，一个在工具跑完之后接先把前面两个用熟，剩下的什么时候要用什么时候再加。这个视频我也是通过 cloud 制作出来的，后面把知识点讲完，会以这个工作流为例讲解。好了，我先分享下我常使用的三个场景， 你看完之后可以直接抄如何使用。第一个 post two news 配自动格式化 cloud， 每次 edit 或者 write 把格式化掉， 配置就六行 json 中 match 写 edit， write 配置命令中写 pretty write 加文件路径，从此你 cloud md 里就不用再写记得格式化这种话了，它一定会发生。这就是 hock 跟提示词的本质区别， 提示词是约定， hook 是 强制。第二个就是我之前提到的，没有让我确认，就执行了 r m r f 操作。在那之后，我加了一个 hook， 在 配置中加上了这个命令的 hook 匹配上就掉一个脚本，脚本里再判断一次完整命令，遇到 r m r f 直接 exit 二，退出码二，这个细节非常关键，我在之前的视频讲过这个，不知道的小伙伴可以翻翻。第三个最舒服， stop 事件配桌面通知我经常让 cloud 跑一个比较慢的任务，自己切去干别的，回来发现他早就停在那等我了。配上 stop hook 之后，他一收尾，桌面直接弹出来消息，我直接确认就好，不用我主动去查看。但我得说一个反话， hooks 不是 越多越好。这事挺微妙，如果某件事不是每次都该发生，硬塞进 hook 反而会变成新的污染源。 它适合勾住那些确定性的，每次都得做的不需要思考的动作。判断要不要思考的标准很简单，你能不能用一个 shell 脚本写完这段逻辑且永远不变，能就上 hook， 不 能就别用。回到开头那个反差点， cloud md 写得再认真也只是契约 期约靠双方履约，你方履约了， cloud 这边偶尔走神一个判断标准，你可以直接拿走。如果你 cloud md 里某条规则，你发现自己会反复去强调这件事，就该下承到 hook 提醒是可跳过的，而 hook 是 应约束。这一期就到这下一期。讲一个更反直觉的东西， sub agent 下期讲怎么判断什么任务该开， sabotage 怎么开，开几个合适。如果对这一期感兴趣，可以点个赞或者收藏，方便回头来抄那几个 hulk 配置回头见，制作不易，觉得文章对你有用，请一键三连。

大家好，今天给大家分享 cloud code 的 操控 kimi ceo i 的 原理啊，我最近用的比较多啊，因为确实太省 token 了，能把我的产出的量极大的提升，所以也给大家再做一期深度的拆解 啊。我们先给结论啊，给操作方法怎么用其实比较简单啊，你就把 kimi code c o i 的 官方文档发给 cloud code， 然后他读文档，读完之后他就能理解怎么去操控了，这个就一步就到位了，其他的什么都不要做， c c 其实是非常聪明的 啊。然后我讲一下原理啊，首先做两边的架构对比啊，其实 kimi 跟 carl code 这边的架构是大差不差的啊，可能 kimi 这边参考的会多多一些。然后基本上就是一个 carl code 的 拍摄的翻版， 包括这些代理搜索， mini 行这些都差不太多啊，这就是一个架构的双栏对比啊，这个我呃简单解说一下，就是告诉大家为什么调用这么丝滑。首先有一个 print， 呃， curlcode 通过这个 print 的 调用呢，就会取代我们平时的打字，就不用去打字，跟这个 kimi c y 沟通了，这个 print 就 解决一个是一个管道，把提示是从这个管道喂进去，然后结果就从这个管道吐出来， 然后就 ok 了。然后这个 yolo 呢，是一个全 pass 的 一个一个命令就是呃， curlcode 的 调用， kimi 就 用这个，这个命令之后就不用点什么，批准了它这个就没有了，它全都是自动批准。 那第三个呢，就是中间的过程，这个 card code 也是不读的，它只要 kimi c y 的 结果，所以给个快的，它就不会输出过程了，只反馈最终的结果，所以这三个开关加在一起呢， kimi c y 就 变成一个把文字输进去，然后文字输出来的一个黑盒， 然后 card code 呢，就直接能通过管道去调用它，所以就很方便，非常的丝滑，这是一个调用的流程。就是首先你的 c c 呢，肯定是需要评估这个任务本身的 啊， c c 比较聪明嘛，所以他当时回关是非常合适的，像他就有点相当于你公司的高管。然后他去分析了之后啊，就需要判断什么活交给 timi 合适，什么活他干合适，然后适合 timi 干的，他就开始写提示词， 然后写出高质量的提示词啊，这个提示词绝对比比我们自己写的那个质量高太多了。然后呢，他就通过这个高质量的提示词发给 kimi， kimi 呢？接到了提示词，通过管道收到之后，他就去开始去干活去了啊，而且这个是能多个 kimi 一 起干活的，可以放出多个 kimi 的 a 卷一起干活， 然后 cloud code 可以， 然后接下来就验收结果不合格，然后再返回 kimi 接着干，然后 kimi 同时还能这个承担这个质检跟审查的功能，还可以呃， cloud code 还能放出多个，启动多个 kimi 进行不同维度的一个质检， 所以全程下来 cloud code 的 指向跟判断，然后这些写跟查都给 kimi 在 干，所以非常省头等省了很多。然后这是一个写文章的举例啊，就比如说我们写啊，小说啊，或者写写那个公众号之类的， 就是 kimi 他 会组装这个提示词啊，设定啊，角色前文这些，然后 kimi 来写，然后再验收，初步验收一下，然后最后最后再派 kimi 进行这个文章的连续性 ai 位跟逻辑的这个三路的质检，质检合格了 就过了，质检不合格，然后让 kimi 再返工再改。所以 cloud code 其实就是一个监工的角色，它 top 肯能省很多，百分之百到十五吧。 然后这个是一个翻译网站，嗯，我自己有做英文的网站，做了一个大战，这两天在翻译成 西班牙语。那西班牙语呢？你让 cloud code 全部翻译，那绝对是一个很大的量，也不是说会干很久了，只是说非常费头肯。 但是呢，翻译这个工作其实给 kimi 干就非常的合适啊，就是每个模块啊， color code 就 指挥他翻译，翻译完然后自己检查一下，没问题再接着翻译，基本上就这个链路一直下去就可以了。而且在这个过程中呢，还能让 kimi 自己进行独立的审查， 翻译完之后再审查一下合不合格，然后最终啊 color code 进行一个验收，然后我在做网站的时候还让他进行测试，就是 color code 可以 去 呃让 kimi 的 a 卷进行整个网站的全功能的测试，就是打开每个页面进行个浏览测试，所以这些重活累活都可以交给 kimi 去看，非常省 tokyo。 然后这个是第三个概念，就是你的数据量，如果你要分析很多数据量的话，那其实，呃， cloud code 来分析确实也是很烧 toky 的。 呃，所以还是要用 kimi 去做一些数据清洗啊，然后统计分析，然后分析报告啊，这些都可以让 kimi 干。 kimi 其实智商挺高的，绝对是够用，当个小当 google 的 小弟是没问题的 啊。这个是市场调研的举例啊，就比如说你们要做一些市场调研，无论是电商啊好，还是大家是金融机构的，要写报告也好啊，这种多路的多线路的调研啊，量非常大的调研，你都可以交给这个这个 kimi 去干， 包括行业的规，行业的分析，竞品的分析，然后用户的画像这些都可以放出多录的 kimi 去去分析，然后结果汇总之后，呃 cloud code 再进行一些验证跟排查，就能出报告了。 最后做一个总结就是，呃，这个操作体系呢？ send token， send token 就 代表着你的 cloud code 可以 有更多的产出， 相当于如果是五倍的话，那你可能就多了三四倍的产出，而且 kimi 是 能保证质量的，呃，一个 ai， 所以 大家也可以多用一下这个吧，我觉得是挺好用的。好，今天的分享到这里，谢谢大家。

你以为 cloud 配置文件写得越细， cloud code 就 越听话？但很多项目恰恰是从写太满开始跑偏的。 cloud code 用了几天还挺顺，第四天突然乱写导入语句，绕过调研层改。你明明叮嘱过别动的文件。多数人第一反应是模型抽风， 但真翻一下 cloud 配置文件，问题基本都在这儿。因为 cloud 配置文件不是 readme， 它不是给人看的项目说明，而是给 cloud 看的工作规则。你写在前面的东西会影响它，后面怎么判断，怎么写代码时 会不会跑偏。所以今天这篇我想聊的不是 cloud 配置文件怎么写得更全，而是它为什么会越写越糟？坑一把 cloud 配置文件当 readme 写，这是我见过最多的坑。很多人写 cloud 配置文件，第一反应都是先介绍项目，这个项目用什么框架、什么语言、什么版本，目录结构长什么样？ 历史上为什么这么设计某个模块？以前迁移过几次，团队之前有过什么约定，写着写着就把它写成了一份巨大的项目说明书， 看起来很完整。但问题是，对 cloud 来说，这里面每一行都在抢注意力。你真正想让它记住的是，所有接口必须经过校验，不要记录用户原始数据，关键路径不能堵塞。结果这些东西被塞在第幺八七行前面，幺八零型都在讲文件夹结构和历史背景，那它跑偏 真的不能全怪模型。我自己的感受是， cloud 的 配置文件最重要的不是信息量，而是顺序。前面几十行最好只放三类东西，项目到底是什么？哪些事绝对不能做？核心技术战是什么？就这么简单。 比如这个项目是一个高并发交易后端，那你一上来就告诉他，关键路径不允许阻塞 io， 所有接口必须做输入校验，不能记录原始用户数据。 p 九十五，延迟目标要写清楚。这几句话比一整棵目录树有用多了。目录结构有没有用？当然有，但它不应该抢最前面的位置。剪索规则、数据库迁移规则、健全流程，这些更细的内容可以拆出去 放到单独文件里， cloud 配置文件做锁影就够了。这里有个细节也挺坑的， part to file 这种引用不一定是你以为的，用到才读，很多时候它会跟主 cloud 配置文件一起进上下文。 所以如果你真想做案需加载，就别把所有细节又通过引用塞回根目录。更好的做法是把专项规则放到子目录的 cloud 配置文件里，让 cloud 根据当前工作目录读到更具体的规则。 根目录写全局合约，子目录写局部规则。这就像公司制度，不能把财务、法务、研发、行政所有细节都贴在大门口，大门口只贴最重要的几条，进到对应部门再看对应部门的规则。 cloud 配置文件也是一样坑。二，把硬规则和偏号搅在一起。 第二个坑是把 never 和 prefer 写在同一段。这个真的非常常见，比如你写所有 jason 请求都要较验，但请求体很小的时候可以跳过再写，尽量使用 e 部， 但同步也可以。再来一句，关键路径不要跨服务调用，除非确实需要。你看人类读这种话没什么问题，因为人脑子里会自动判断场景，但 cloud 读到这里，就很容易变成一锅概率汤，一会儿严格，一会儿宽松， 一会把偏好当硬规则，一会又把硬规则当建议。你今天问他，他可能很守规矩，明天换一个上下文，他可能又开始自由发挥。我以前一直觉得只要写清楚就行，后来才发现，并不是。你得把规则的力度写清楚。硬规则就是硬规则，偏好就是偏好， 这两种东西不能混在同一个段落里。硬规则区只放 must、 never、 always 这种词，而且句子要干脆，不能代让步。比如所有入口参数必须通过结构校验，比如永远不要绕过全线中间键。比如 禁止在日制里写入用户原始请求，这里不要出现，应该尽量可以考虑。这些词一出现刚性就掉了。偏好区就随意一点，比如优先用 e 部，比如避免引入新的状态管理库，比如更倾向于附用现有工具函数。这类东西可以表达方向， 但不要伪装成硬规则。说真的， cloud 配置文件里最怕的不是规则少，最怕的是规则的口气都一样。硬规则和风格偏好混在一起， cloud 到头来只能取平均。结果就是，你以为自己写了护栏，其实只是写了一堆建议。坑三只说要做什么，不说不要做什么。 第三个坑是 cloud 配置文件里全是正向指令，要做输入校验，要返回某种格式，要遵守某个调用链。这些当然要写， 但只写这些其实不够。因为 cloud 不是 一张白纸，它训练语料里有大量默认写法，有些默认写法挺好，有些就很灾难。比如随手写一个粗糙的文本切分，比如硬编码向量模型版本，比如校验失败的时候返回半截 jason。 比如解锁上下文不够的时候硬编一个，看起来像真的引用。 再比如补货完异常什么都不出力。这些东西你不明说别做，他有时候就会顺手带出来。不是他故意跟你作对，他只是沿着最常见的写法。 所以我现在越来越觉得，写清楚不要做什么比只写要做什么还重要。你项目里踩过什么坑，就把它写成 never。 比如，不要粗暴按字数切分的方式处理代码文档，不要硬编码模型版本必须从环境变量里读， 不要缓存未经验证的模型输出，不要在解锁节点里直接调用外部接口，必须经过限流层，不要在校验失败时返回不完整 json。 这些句子看着很冰冷，但特别有用。它们不是教程，它们是事故记录。每一条背后最好都对应一次你真的被坑过的经历。 这样写出来的 cloud 配置文件才不是空泛的最佳实践。顺着这个，再聊一个更隐蔽的东西，失败路径。很多人会告诉 cloud 成功时要怎么回答，但不会告诉他失败时怎么处理。 查找没找到足够上下文怎么办？相似度很低怎么办？调用顺序不确定怎么办？如果你没写，它就会为了完成任务，硬凑一个看起来完整的答案，这时候最危险，因为硬凑出来的东西往往比直接报错更像真的。所以你要给他一个明确的处理办法。比如上下文不足就返回 instance context， 并列出缺什么。比如最后生成答案时没把握就不要硬给最终答案。 你想想看，这个设计其实跟后端接口一样，正常返回要有格式，错误返回也要有格式，没有结构化，失败就只剩下幻觉。 这个地方我觉得特别重要，因为你不是在要求 cloud 永远正确，你是在要求它不确定的时候别装坑。四不版本化，也不淘汰旧规则。 第四个坑，最隐蔽代码库已经更新了好几轮， cloud 配置文件却还停在几个月前。三个迭代前，你们还在用粗切块器，上个迭代 已经换成羽翼切块儿了，旧模块儿都删了，但 cloud 配置文件里还写着使用 niv chunk 切分文档，然后你开一个新绘画，让 cloud 改解锁逻辑，他非常听话地把 niv chunk 又引回来了。你看到的时候一脸懵，不是哥们儿，这玩意儿不是早删了吗？ 但站在 cloud 的 角度，他没做错，他读到的规则就是这么写的。问题就出在这里，给 cloud 的 上下文已经过期了，旧规则不会自动失效， 你不主动删除，它就一直在那儿，像一条过期但仍然生效的公司制度，新人看了会照做， cloud 看了也会照做。所以 cloud 配置文件也需要版本管理。不是说非得搞得多复杂，但至少要有版本号，有更新时间，有简单的变更记录。 比如某条规则什么时候加的，为什么加，什么时候废弃，迁移到哪种新写法。废弃规则可以用 lightdeprecated 标出来，这个标签不是什么官方魔法，它就是一个约定。但约定这东西在团队里很重要，人能看懂， cloud 也能看懂。更稳一点的话，可以配一条自动检查， 只要生成代码里出现已经废弃的旧模块、名旧函数、名旧调用方式就直接失败。别靠记忆，靠记忆维护规则迟早会出问题。我有时候觉得 cloud 配置文件这件事，其实特别像接口设计，你不能只定义成功路径，你还要定义错误返回，你不能只写现在怎么用， 你还要标出什么已经废弃，你也不能把所有东西都塞进一个巨大文件里，该分层就分层，该有边界就有边界，根目录放什么，子目录放什么 都要说清楚。回到最开始那句话， cloud 配置文件不是写得越满就越稳，不是认真有错，而是很多认真到头来会变成堆料。把 readme 的 写法搬进 cloud 配置文件，重点会被丢掉。把硬规则和偏好混在一起，约束力会被稀释。只写要做什么，不写不要做什么 也不给。失败路径模型就会回到那些常见但未必适合你的默认写法。不版本化，不淘汰旧规则，过期上下文就会继续污染新代码。 说到底，一份好用的 cloud 配置文件应该很克制，开头先放项目身份底线和核心技术战，别急着塞背景资料，硬规则和偏号分开写， 不要做什么，失败时怎么兜底也要写清楚。版本号、废弃机制、子目录、规则跟着代码库一起走。做到这些， cloud code 也不是不会犯错，但它犯错的方式会变得更可控。你不用每次都跟模型来回掰扯，问它为什么又绕过校验层， 为什么又改了不该改的文件，为什么又引入一个早就删掉的模块。你可以回到 cloud 配置文件，把对应的规则改清楚，我不确定这套对你有没有用，毕竟每个项目的痛点都不一样。但如果你最近刚好也遇到 cloud code， 越用越飘， 真的可以打开自己的 cloud 配置文件看一眼。先别问模型是不是抽风，先问问你的 cloud 配置文件是不是已经写成了另一份 readme cloud 配置文件这件事就讲到这儿，你那份 cloud 配置文件现在踩在哪个坑上？评论区丢出来，下一期接着拆。

前两天我跟一个朋友聊到了他不用 cloud code 的 原因，他说每次一关窗口，聊天记录就没了，下次打开又得重新开始。我的第一反应是，很多人不是觉得 cc 不好用，而是根本没搞清楚他应该怎么用。所以今天我想聊一下，如果你想真正的用好 cc， 至少要知道哪些东西。 首先， c c 不 只是一个能写代码的聊天框，它更像是一个在你的电脑项目里工作的 ai 助手。当然你不能随便打开一个终端，然后说帮我做个网站，这样也能聊，但是效率非常低。更好的方式是你给他一个明确的工作空间。 就比如说你要做一个测试项目，你应该先建一个文件夹，然后在这个文件夹里面打开终端，接下来的任务就是围绕这个文件夹工作。这其实非常重要， 因为用 ai 编程工具的最核心的是你会不会给 ai 划边界，你要告诉他哪些文件能改，哪些文件不能动，这个项目的目标是什么？这步是先规划还是可以直接执行？什么情况必须停下来问我，不 然他能力再强也可能跑偏。然后说，安装 windows 用户一般需要先准备 node 点， js 和 git 不 会装也没关系。现在最简单的方法其实就是让另一个 agent 帮你装，比如说你 可以用 tree 或者是 cursor 这类工具，直接跟他说帮我检查一下电脑有没有 note 点 gs 和 bit， 没有的话就帮我装。这也是我现在很喜欢的一种思路，要什么都自己学，能让 ai 帮你铺环境，就让 ai 帮你铺 cc 的 安装，我这里就不多讲述了，你们可以去搜教程，或许我也会出视频。 cc 有 几个模式新手一定要知道。第一个是摸着模式，这个模式比较稳，他不会随便乱改，每做一步会停下来问你。缺点是慢，但优点是安全。第二个是全自动模式，这个模式是你授权以后，他可以自己连续执行， 效率很高，但你得确定你给他的任务足够清楚。第三个是 plan 模式，这个我非常推荐新手用，因为他只规划不动文件，他会先帮你分析项目结构，拆任务给方案。我一般的习惯是先让他进入 plan 模式， 先把整个项目想清楚，确认没问题以后再切换成执行模式，这样不容易把项目改崩。切换模式一般是 shift 加 tab。 再说聊天记录的问题， c c 是 可以恢复之前的对话的，你只需要 输出斜杠 resume， 它就会列出之前的聊天记录，你选一个就能接着之前的内容继续。还有一个更实用的操作，如果它刚刚执行了一步，你觉得效果不对，可以按两下 esc， 可以 退回到这一步之前。当然 token 是 肯定不会退回的。还有两个命令， compact 是 压缩上下文， clear 是 清光上下文。 ai 的 上下文越长，他就越容易忘记重点，执行质量会下降。所以一个阶段做完就让他慷慨了一下，一个大方向结束就可以了一下，但是清空之前一定要让他总结当前项目进度，这样你下次打开他也能快速的接上。 这其实就是我现在用 ai 工具最大的感受，也不能把他当成一个无脑的聊天机器人，你要把他当成一个需要管理的员工，你给他的信息越清楚，他越清楚，他越不 浏览度，项目资料整理的越好，他接着干活就越顺。最后再简单说三个进阶方向。第一个是 skills， 你 可以理解成给 ai 的 标准作业流程，比如说你经常做公众号，做网站、做复盘，你就可以给他写一套固定的规划，让他每次都按你的习惯来。 第二个是 m c p， 它更像是让 ai 接入了外部工具，就比如说数据库、文件、网页、支付这些，这个能玩明白以后， ai 就 不只是跟你聊天， 而是真的能接入你的工作流。第三个是 hoggens， 这个是更像自动触发机制，就比如说你保存代码以后自动检查，提交前自动格式化，某些操作前自动提醒。这些东西听起来有点技术，但本质上就是让 ai 更像一个自动化团队。所以总结一下，我觉得 c c 真正厉害的地方不是他会写代码，而是他让 一个不那么懂代码的人开始把想法推进成一个真实的项目。但前提是你不能乱用，你要学会在正确的文件夹启动它， 用一般模式先规划，然后用 reroom 接回历史绘画，用 esc， esc 回退错误操作，用 ctrl 翻 译上下文应用。 c 的 规则，现在它能做什么，不能做什么，这些东西掌握以后，你才会发现， c c 不是 一个聊天工具，它更像是一个能帮你推进项目的执行助手。而我现在越来越确定，未来真正拉开差距的，不是你 会不会问 ai 问题，而是你能不能把 ai 变成自己的工作流，不是让他陪你聊，而是让他真正帮你把事情做出来。

停止对科老的说做这个，停止对科老的说写代码，停止对科老的说修复这个错误，你实际上是在把一个资深 ai 当成实习生对待，这里有八个你可以直接复制粘贴的提示词。 别再对科老的说做这个，别再对科老的说写代码，别再对科老的说修复这个错误，你实际上是在把一个资深 ai 当成实习生对待，这里有八个你可以直接复制粘贴的提示词。 一、从零开始完整应用像资深全站工程师一样思考，开发完整的生产级应用，首先设计系统架构，然后开发最小化但可扩展的版本。结果应包括，架构、文件结构、数据库模式、 a p i 端点 u i。 架构完整代码， 像真正的创业 m v p 一 样设计，确保可扩展。二、代码库理解与重构像刚加入大型陌生代码库的资深工程师思考，首先理解架构和数据流，然后识别 结构问题，重复代码性能瓶颈、可维护性、风险。结果，架构总结问题，区域重构、策略改进，代码功能不变、质量提升。三、资深调试工程师 向调查生产环境 bug 的 资深工程师思考，仔细分析代码，逐步思考，找到根本原因，提出稳健解决方案。结果，代码功能问题所在失败原因、边界情况、修复后的生产级代码。 四、系统设计加实现向资深系统架构师思考，为产品设计可扩展系统，然后开发最小化生产版本，包括架构组建、结构、数据流。 a p i。 设计、数据库模式、缓存策略，实现代码。 五、性能优化建议向性能工程师优化代码思考，目标速度、内存使用可扩展性找出瓶颈，低效逻辑，不必要渲染结果性能问题。优化策略，改进代码。六、清洁架构重构 向资深工程师将代码转换为清洁架构思考，分立关注点，增加模块化，减少藕合 行为，不变结构改进结果，新文件加结构架构说明重构代码。七、 cloud 多代理工作流，你是四个协助代理架构师、工程师、审核者，优化器结果架构，实现审核反馈，最终优化版本。 八、生产级 u i 组建构建器向资深前端工程师思考构建可附用 u i 组建，无障碍访问，生产就绪，考虑加载态边界情况，响应式设计，可访问性结果组建架构， quops 设计，实现使用视力。

哈喽，大家好，我是迪迪，那这个图是我用一个 excel sheet 加上我右边的这个 skills 两分钟生成的，那除了这个图标，我还做了这个图标反映出来的这些核心洞察，所以今天就带大家一起来拆解一下我是怎么样去做的。 首先带大家来看一下右边的 skills， 那 针对于 skills 怎么样去写，我们之前有分享上面的话就是一些 matter information， 包括这个 skills 的 名称是什么，它具体在什么样的场景下会触发这个 skills 呢？主要是针对于你给他一些数据，以及加上你自己想要看到的一些数据反馈的一些问题。 skills 就 能根据你数据的一个格式去选择相应的一个图标，比如说有一些变形图或者一些柱形图，散点图等等，所以它会根据你自己数据的不同，然后去匹配相对应的一个图标。那同理也会说到，有些图标是不适用于在某一些情况下用的， 在这个地方已经完全给它规划好了之后，我们就开始写了一些的表本，对于不同的一个图标的类型去针对性的写了图标的样式， 包括 line chart 应该怎么样去设置， bar chart 怎么样去设置等等。所以这个接下来就是一些排行榜。那除此之外，因为之前用的都是一些英文的一些图标，所以在后面我也会加上一些中文字体的一些配置， 这样可以更加方便于中文字体更好的去展现出来。除了表格之外，我还放了一个核心洞察，就是不同的数据它是什么样的，但是用户往往需要从数据里面知道下一步应该做什么， 所以在这个以上的一些数据里面，还给他配了一个核心洞察的表格，而每一个表格他都有一些卡片，类似的这些结论条，方便我们去更好的执行于下一步。所以这个就是整体的一个从 excel 数据到怎么样呈现不同的数据可化的一个过程。 接下来给大家看一下我头位给他一开始的这个原始数据大概长什么样子。大家可以看到这个我拉出来的一个爆品的数据， 主要我想分析这个爆品后面商家是怎么样去选优质的达人的，以及他们选达人的策略是什么样的。那在这个表格里面其实比较的混乱，他只是分成了几个类别，包括达人是谁，他们的联系方式，他们的分类是什么，国家、地区、粉丝数、销量、销售额、开始带货的时间， 以及他们的一些详情页。但是在这个庞大的数据库里面，我要精准的总结出来这个商家是怎么样去挑选他们达人的，怎么样达人更好的去卖这个爆品的。我是没有办法很快能够得出结论的。那么为了提高这部分的数据效率，我就做了 sales。 大家来可以看一下我们得到的一个结果。先第一张图里面我们可以看到它其实是一个贩类，我先不说这个爆品它是什么类别的，我们是没有办法很直观的从这个类别里面去知道这个品是什么， 其中购物与销售占到了百分之九，家居占到百分之八，美妆占到百分之七，所以它是一个贩品铺货类的一个策略，而大多数的都属于其他类，这些达人没有明确的一个垂直分布的一个展示， 那这个品其实是一个枕头，所以说如果我们也是需要去卖枕头，我们也可以采取相应的一个策略。对于这些达人的分布，我们可以选择不同行业不同垂类的，因为并没有直接的联系显示，只有在家居类和这个销售额会成为一个正比。 而第二张图我们可以看到他的横轴是粉丝数，纵轴是销售额，所以他是一个粉丝量级和销售额的一个对比图，可以看到仅显示有销量的有二百八十六个人，也就是说百分之七十他的一个达人都是一个僵尸达人，他并没有出单。 而越靠右上角这个呢应该是 k o l 的 一个转化占比，它是高粉加高销，但是大部分的其实都是在这个位置，那这个位置可以看到它其实粉丝数也并没有很多，但它销售额可以带到一个比较高的一个量级，所以它是一个 k o c 聚集的一个策略， 大部分的 k o c 它都是集中于粉丝数在这个量级的。如果说我们需要带枕头类的产品，我们也可以去效仿这个策略。 接下来来看一下第三张图，他显示的是销售额的一个帕雷托，怎么样去理解呢？其实就是头部的集中度极高，百分之十他贡献了百分之九十九点二的销售额，而前百分之二十的达人贡献了百分之九十九点的销售额，也就是说大部分的达人累积他贡献的销售额占比都是集中于前面， 所以这个是我们能够得出的结论。那后面的达人其实我们后续是可以采取一些相应的措施和策略，要么是放弃了，要么是减少去跟他们的合作，而集中去维护好头部的这些能够高出单的达人。 接下来是第四张图，是视频带货的 gpm 和直播带货的 gpm， 他 们的中位数视频是占到了二十三点九，而直播是占到了六点六，也就是说中位数大概是三倍的一个差别。那么对于枕头这个品类来说，它的视频转化率是远高于直播的转化率的。 但是其他类型的产品，比如说沙发，它的直播的 gpm 就 远高于视频的 gpm， 因为它是一个更加高客单价的一个产品，在视频里面客户去进行种草，而在直播里面，它是去进行一个割草去转化的一个过程。所以对于不同的品类，我们需要找到它相对应的一个带货模式，要么是短视频的一个带货模式，要么是直播的一个带货模式。 所以如果说我们需要去做这些不同的品类，需要采取不同的一个带货模式，接下来我也是有把这些洞察放在了这里。那一句话去总结这个爆品枕头的一个策略，它就是一个贩品类，加上海量的铺达人，加上大部分的一些 koc 以及视频带货。 所以说如果我们想要去复刻我们同行业的一些爆品，我们也可以去拆分，那除此之外，我们可以再去拆分的细一些，比如说粉丝量级，具体是在某一个行业里面，他的一个散点图的占比，又或者说我们从其他维度去分析这个品类他爆的一些特点， 不仅仅是达人端，也有可能是商品端，它的竞品端从不同的维度去分析。那么有了这个 skills 呢？只要你有相对应的一些原始数据，那么我们就能够得到一些相对应的 insights， 从而能够帮我们更好地去做出结论和策略。今天给大家分享的就是如何从一个原始的 excel 数据到我们的数据格式化。

一个甄姬的一个测试的一个环节了，我总结了一些什么呢？就是我在必要的时候，我总是会让他在克拉德 md 里面去更新他我所做的一些修改我的踩坑经验，因为他对我的开发呃，很重要，但是你会发现随着开发越来越多，他这个克拉德 md 的 文件会很容易就有几百甚至一上千行， 那就非常的笨重。有两个很大的问题，第一会非常的非常的骚，非常骚 token 啊，很骚 token。 那 么第二个什么呢？ 它本身内容很多的话，它会它跟 ai 在 对话的时候，本身是一个很大的污染，它修复 bug， 包括它思考问题是不够精准的，所以我我会经常让它什么呢？让它进行精简， 对这个工程级的哈，兄弟们，工程级不是系统级，对工程级的 cloud nba 文件进行精简，删除，重复荣誉，还有已过时的部分。然后让它什么呢？新建一个文档，通过 memory 缩影的方式在必要的时候进行缩影。 我现在整套工具下来已经一共有七束锁影，就是我把所有的产生经历了啊，很多必要的新增的功能啊，包括调试的一些方法呀，都很重要，我不能把它删掉，要不然，要不然以后 ai 看不懂 我整个软件的开发历史，还有整个软件的开发过程中哪里做的修改，目前是什么状态？这些是不能删掉的，但是不是每一次都需要发给 ai 的， 所以我把这些玻璃出来，单独新建一个文件，每一个文件都是几十上百几百行的，那么很庞大。然后呢？怎么用呢？只通过一个缩影， 当 ai 在 修复一个 bug 的 时候，它会发现它要查某一部分的内容，知道它以前是怎么修改的，它会自动调用至某一个软件，会自动去调用。这我发现有两个好处，第一， 偷粉的消耗会大大的降低很多。第二，最重要，它对 bug 的 修复的能力是直线上升的，因为它没有太多的污染。 其实我们发给 ai 的 东西越多，它会越乱，你说的越少，它的定位越准确。所以我们一定要记得，除了去更新我们的 cloud md 文件以外，我们还要对它进行必要的精简。精简最好的方法不是删掉，而是把它单独归类，然后新建一个文件，用所有的方式去调用。

我觉得豆包它就是国产，真没那样，我现在主要就是用 codex， code 和豆包就是它那个，那天那个四零零报错就是豆包给我解决的，反正它就是。嗯，这个四零零报错的话，你要么就是退回到老版本，因为 codex 的 最新版可能是把这个 deepsafe 给给那啥了， 给它软封杀了吧。相当于有可能是这样，因为它是闭源的，我们也不知道具体是咋回事。还有一种方法就是你把 deepsafe 的 那个思考模式关闭，你去那个 deepsafe 的 官网看一下怎么关闭，然后你把它关闭就行了。就是 deepsafe 的 那个 a b i 文档，你看一下怎么关就行了，或者让豆包给你弄一下。

刚刚 anthropic 把 claude 装进了整个微软 office， excel、 powerpoint、 word 三件套同时正式上线。 outlook 进入公开背的 真正的卖点是跨应用的上下文衔接。 anthropic 给的典型场景，先在 outlook 里让 claude 整理收件箱，起草回复，顺手打开邮件里附的 brief 到 word。 接着让它根据 word 简报在 excel 里搭财务模型公式分布在多个 sheet， 再做成 powerpoint。 最后回到 outlook 企草评选邀请。整个流程里， clod 带着前一步的上下文走，不需要重新为材料。具体能力上， excel 里 clod 能改单元格和假设条件而不破坏现有公式。 powerpoint 里，它按你的模板排版生成原声图标，而不是塞进图片。 word 里改稿用 track changes 修改模式呈现，让你逐条接受或拒绝。 outluckily 草稿会停在草稿箱，等你点发送。定价方面，所有付费 cloud 套餐用户都能用，不需要额外掏钱。

从今天起，你打开 word 就 可以直接用 cloud 了。今天凌晨， cloud 宣布正式接入微软 office 全家桶，什么 word 呀， excel、 ppt 全都可以直接用。 outlook 也开放了公测，什么概念？家人们全球 office 付费用户超过四亿，而专业的程序员也就两三千万。所以说， 我们普通的打工人，也可以在自己平常用的办公软件里边用到 cloud 了。更关键的是跨应用共享记忆，你在 excel 里边让 cloud 处理的数据切换到 ppt 里边，它也能记得。而且也可以帮你直接生成图标，插放进去邮件里的需求到 word 里边，它还可以直接接着写。 以前用 ai 是 打开网页复制粘贴再复制回来，现在是直接在文档里边对话干就完了。这件事情有意思的地方在于， ai 工具的战场，从谁的模型更强，变成了谁离用户更近。 cloud 没有自己的办公软件，但它直接进入了四亿人每天都在用的 office 里。你不用去找 ai， ai 就 来找你了。