即刻App年轻人的同好社区
下载
置顶一个实验性产品，让AI 每天从3000+推特X的海外帖子，1000+的Reddit、Hackernews 帖子中精选出海外大模型、AI编程、AI产品的资讯。然后由AI提炼总结后推送到飞书群里，没有广告，没有标题党，基于全文总结全中文呈现。
欢迎飞书用户加群~这可能是你见过的信息质量和密度最高的飞书群
欢迎飞书用户加群~这可能是你见过的信息质量和密度最高的飞书群
108 3851
飞书、钉钉、企微同一周都发了 cli 和 skills，可以从文档和 skills 的设计里看出三家对 AI 的理解差距。
飞书毫无疑问排第一。文档里甚至考虑到了"你会用 agent 来帮你装 cli"，专门对 agent 也给了很不错的指引。skills 设计上明显有经验，可以看出来有很多 skill 是内部就在用的，有很多打磨的痕迹。飞书的 skill 哲学是每个功能值得写一个独立的 skill，大家共享的知识就写一个通用 skill。还提供了一个叫 lark-skill-maker 的元 skill，专门用来指导 AI 怎么创建用户个性化的、基于飞书的工作流 skill。可以说是三家里对 skill 理解和经验上都最老道的。有意思的是，飞书有些 skill 还是英文写的，感觉也是 AI 迭代出来的。接入体验上，飞书的 init 命令直接把应用创建、应用授权全部打通了，做的非常完整，牛逼。
钉钉排第二，但不自信的地方有两处。第一，默认不开放，需要先加官方群拉白名单才能用这个 cli，比其他两家多了一种不自信感。第二，三家里只有钉钉没有开放文档相关的 skill——文档这个东西很复杂，特别是编辑这块，为了支撑扩展性和多人编辑，复杂度都很高，钉钉首批直接没敢开放，也不知道为啥，感觉也是同一种不自信。skills 哲学比较简单，所有功能合并成一个 skill，写得比较朴实，但该有的都有了，算合格产品。cli 和接入顺滑度远不如飞书，还停留在文档里教用户手动创建应用那个阶段，不过至少文档里还给了怎么创建的方案。
最差是企微。文档稀烂，整个文档就只提了命令行怎么用，对于应用创建、权限这些只字不提。skills 写得也很难 get 到思路，比较随意——meeting 拆了三个 skill，创建一个、编辑一个、获取一个，doc 却只写了一个，而且 doc 的编辑只提供了全量覆写功能，真用起来不知道有多少坑。skill 里甚至有拼写错误，感情还是人写的。最难绷的是，上线 9 小时，第一个 PR 就是有人用 Codex 帮它把文档里缺的内容补齐了，优化了一版文档。
虽然表面上看大家都出了 cli，都拥抱 agent 生态，都搞出一堆龙虾产品，但内里的差距，我已经感觉到了。
飞书毫无疑问排第一。文档里甚至考虑到了"你会用 agent 来帮你装 cli"，专门对 agent 也给了很不错的指引。skills 设计上明显有经验，可以看出来有很多 skill 是内部就在用的，有很多打磨的痕迹。飞书的 skill 哲学是每个功能值得写一个独立的 skill，大家共享的知识就写一个通用 skill。还提供了一个叫 lark-skill-maker 的元 skill，专门用来指导 AI 怎么创建用户个性化的、基于飞书的工作流 skill。可以说是三家里对 skill 理解和经验上都最老道的。有意思的是，飞书有些 skill 还是英文写的，感觉也是 AI 迭代出来的。接入体验上，飞书的 init 命令直接把应用创建、应用授权全部打通了，做的非常完整，牛逼。
钉钉排第二，但不自信的地方有两处。第一，默认不开放，需要先加官方群拉白名单才能用这个 cli，比其他两家多了一种不自信感。第二，三家里只有钉钉没有开放文档相关的 skill——文档这个东西很复杂，特别是编辑这块，为了支撑扩展性和多人编辑，复杂度都很高，钉钉首批直接没敢开放，也不知道为啥，感觉也是同一种不自信。skills 哲学比较简单，所有功能合并成一个 skill，写得比较朴实，但该有的都有了，算合格产品。cli 和接入顺滑度远不如飞书，还停留在文档里教用户手动创建应用那个阶段，不过至少文档里还给了怎么创建的方案。
最差是企微。文档稀烂，整个文档就只提了命令行怎么用，对于应用创建、权限这些只字不提。skills 写得也很难 get 到思路，比较随意——meeting 拆了三个 skill，创建一个、编辑一个、获取一个，doc 却只写了一个，而且 doc 的编辑只提供了全量覆写功能，真用起来不知道有多少坑。skill 里甚至有拼写错误，感情还是人写的。最难绷的是，上线 9 小时，第一个 PR 就是有人用 Codex 帮它把文档里缺的内容补齐了，优化了一版文档。
虽然表面上看大家都出了 cli，都拥抱 agent 生态，都搞出一堆龙虾产品，但内里的差距，我已经感觉到了。
21 413
让微信直连claudecode！ 把微信的 ClawBot 插件逆向之后，发现里面有一套完整的 api，也就是说不光是龙虾能用啊哈哈，果断改造成能跟 claude code 直接打通，这下爽了 。小白也能直接用，运行npx cc-weixin 就能用上！
github.com
github.com
47 617
前端仰卧起坐这么多年，今年可能是真的嘎了。
我现在公司已经不招前端了。真正前端在干的活，实际上是设计师在干——面向 C 端的普通页面由设计师来做。客户端的页面是产品出方案，客户端同学去实现。其他程序员全部变成全栈，不再区分前后端了，所有的都一锅端，每个人都做。
运行到现在，我发现这个模式是能跑的，能跑起来没有问题。目前遇到的障碍是之前的工程能力不够强，各种基建没做好，所以当大家把各自生产的东西重新整合到流水线上去发布的时候，会有一些磕磕绊绊。但只要这个坎过渡过去，就一切顺利了，没什么大的问题。
很讽刺的是，前端最早恰恰就是从设计师里面分化出来的。以前设计师还要做页面，后端也要做页面，那时候叫网页美工。我自己就是从美工转到网页开发的。后来企业需要把事情做得更快更好，需要更容易招到人，这个分工才产生了，前端才变成了一个独立职能。
现在到了我这家公司，我发现这个分工又合回去了。我不知道我们公司这个分工调整是不是合理的，但这个趋势一定是这样的。不管是合并到产品、合并到视觉、还是合并到全栈，总之一定会合并。前端这个因为分工产生的职能，又要因为分工消失了。我自己就是前端出身，感觉很讽刺，但又觉得这一切都是企业的需要。
可能有人会想，不分工所有东西都一个人做，那这个人不会累死吗？不会。如果真的需要分工，自然就会分工，就像前端当年从后端和视觉那边分离出来一样。一切都是效率和成本的平衡，这才是本质。而在此之上形成的职能分工的工程价值观，现在来看都是没有意义的。它的存在，从我现在来看，就是在规训工程师，让其更好管理。
所有遵守所谓前端工程师文化的人——视觉稿一定要精确还原，JS 的命名一定要怎么写，分号用不用，一定要用什么框架什么工具。这些在过去争论不休的问题，如今看来都非常可笑，很没有意义。
所以现在过渡到 AI 编程时代，我觉得这依然是要警惕的。当有人说 AI 编程一定要如何如何如何的时候，一定要竖起耳朵，谨慎地听，自己去尝试，而不是听权威的话。
对个体来说，现在所有单一职能是有风险的，广度非常非常有必要。甚至我觉得，广度才是未来工程师真正的能力结构要求之一。AI 时代，只有单一深度是危险的。
我现在公司已经不招前端了。真正前端在干的活，实际上是设计师在干——面向 C 端的普通页面由设计师来做。客户端的页面是产品出方案，客户端同学去实现。其他程序员全部变成全栈，不再区分前后端了，所有的都一锅端，每个人都做。
运行到现在，我发现这个模式是能跑的，能跑起来没有问题。目前遇到的障碍是之前的工程能力不够强，各种基建没做好，所以当大家把各自生产的东西重新整合到流水线上去发布的时候，会有一些磕磕绊绊。但只要这个坎过渡过去，就一切顺利了，没什么大的问题。
很讽刺的是，前端最早恰恰就是从设计师里面分化出来的。以前设计师还要做页面，后端也要做页面，那时候叫网页美工。我自己就是从美工转到网页开发的。后来企业需要把事情做得更快更好，需要更容易招到人，这个分工才产生了，前端才变成了一个独立职能。
现在到了我这家公司，我发现这个分工又合回去了。我不知道我们公司这个分工调整是不是合理的，但这个趋势一定是这样的。不管是合并到产品、合并到视觉、还是合并到全栈，总之一定会合并。前端这个因为分工产生的职能，又要因为分工消失了。我自己就是前端出身，感觉很讽刺，但又觉得这一切都是企业的需要。
可能有人会想，不分工所有东西都一个人做，那这个人不会累死吗？不会。如果真的需要分工，自然就会分工，就像前端当年从后端和视觉那边分离出来一样。一切都是效率和成本的平衡，这才是本质。而在此之上形成的职能分工的工程价值观，现在来看都是没有意义的。它的存在，从我现在来看，就是在规训工程师，让其更好管理。
所有遵守所谓前端工程师文化的人——视觉稿一定要精确还原，JS 的命名一定要怎么写，分号用不用，一定要用什么框架什么工具。这些在过去争论不休的问题，如今看来都非常可笑，很没有意义。
所以现在过渡到 AI 编程时代，我觉得这依然是要警惕的。当有人说 AI 编程一定要如何如何如何的时候，一定要竖起耳朵，谨慎地听，自己去尝试，而不是听权威的话。
对个体来说，现在所有单一职能是有风险的，广度非常非常有必要。甚至我觉得，广度才是未来工程师真正的能力结构要求之一。AI 时代，只有单一深度是危险的。
19 13
最近入职新公司负责推广 AI 编程，刚好能近距离观察同一个小团队里 TL 和 IC 两种背景的人上手 Claude Code 的区别。
TL 背景的人，甚至不知道 continue/resume 能恢复聊天记录这种基础操作。但他有一个核心能力：把模糊的问题转换成可被枚举的方案。他能定义好问题，让 Claude Code 通过多次尝试去无限逼近答案。所以他的 Claude 经常一跑好几个小时，最后给出一个无限接近正确答案的结论。这个能力本质上就是管理能力——定义问题的能力。
IC 背景的人，第一个直观差异是 token 用量上不去。他自己也觉得"我很努力了，但就只能消耗这点 token"。跟他聊的时候他说："你给我的都是模糊问题，我要跟 AI 一起找答案，很没头绪。"
跟 IC 深聊后发现，核心卡点是：一直做执行的人，思维的每个角落都绑定在过去的执行路径上。想着想着就会代入执行视角——"这个地方还要我去弄，好复杂"。他不会自然地想到，这个地方也是交给 Claude Code 做的。
而且这个思维转变其实不是用了 AI 编程才需要的，而是更早就需要。它的本质是：自顶向下地看待和分解问题，在这个阶段不考虑执行层面的细节。但做执行的人是反过来的——他必须先知道怎么执行，所以必须精确，模糊是执行最大的敌人。
之前网上总说"有管理能力的人接手 AI 会更快"，当你真的具象化看到一个真实案例的时候，感觉还是挺不一样的。对刚接触 AI 编程的人来说，最开始可能应该先跟 AI 一起把这个"定义问题"的能力练出来。
TL 背景的人，甚至不知道 continue/resume 能恢复聊天记录这种基础操作。但他有一个核心能力：把模糊的问题转换成可被枚举的方案。他能定义好问题，让 Claude Code 通过多次尝试去无限逼近答案。所以他的 Claude 经常一跑好几个小时，最后给出一个无限接近正确答案的结论。这个能力本质上就是管理能力——定义问题的能力。
IC 背景的人，第一个直观差异是 token 用量上不去。他自己也觉得"我很努力了，但就只能消耗这点 token"。跟他聊的时候他说："你给我的都是模糊问题，我要跟 AI 一起找答案，很没头绪。"
跟 IC 深聊后发现，核心卡点是：一直做执行的人，思维的每个角落都绑定在过去的执行路径上。想着想着就会代入执行视角——"这个地方还要我去弄，好复杂"。他不会自然地想到，这个地方也是交给 Claude Code 做的。
而且这个思维转变其实不是用了 AI 编程才需要的，而是更早就需要。它的本质是：自顶向下地看待和分解问题，在这个阶段不考虑执行层面的细节。但做执行的人是反过来的——他必须先知道怎么执行，所以必须精确，模糊是执行最大的敌人。
之前网上总说"有管理能力的人接手 AI 会更快"，当你真的具象化看到一个真实案例的时候，感觉还是挺不一样的。对刚接触 AI 编程的人来说，最开始可能应该先跟 AI 一起把这个"定义问题"的能力练出来。
34 64
最近写了很多skill，对skill有了一些新感悟。skill不是ai的技能，而是你的技能，是你对ai的指导的结构化材料。 这里有两层意思，一是你得能对ai进行指导，而不是反过来，如果总是ai指导你，那你没有写skill的必要（和能力）。二是结构化，即这个指导具有一定的规模和系统。 如果按这个定义，我们就可以形成一个cc提示词来蒸馏出属于我们自己的 skill ： 请把我们过去30天聊天记录使用脚本导出并分析，把我对你的指导进行分类，按/skill-creator的标准，告诉我哪些指导可以形成高质量的skill？
这里有一个技巧是利用skill-creator，这个skill远不止创造skill这么简单，你可以把任何材料交给它改造成skill。或者经过大量迭代的膨胀型skill也可以交给它进行重构优化。
另一个思考就是，私有的skill才是真的积累，能共享出来的，由于其公共性，谁都能用的skill反而价值很快就被稀释了。
这里有一个技巧是利用skill-creator，这个skill远不止创造skill这么简单，你可以把任何材料交给它改造成skill。或者经过大量迭代的膨胀型skill也可以交给它进行重构优化。
另一个思考就是，私有的skill才是真的积累，能共享出来的，由于其公共性，谁都能用的skill反而价值很快就被稀释了。
45 312
反复折腾AI 个人助理的架构和提示词，发现 Markdown 预设结构其实是个错误的方向，尽管他看起来正确，也能正常work。
为什么这么说呢？Markdown 结构化方案的问题是，
你必须精心定义好的目录（项目/任务/人物/日志...），然后不停精调这个结构。但人的输入是混乱的，一句话可能既是想法、又关联项目、还涉及某个人，或者是个命令。这个目录结构注定是反迭代的，无法泛化的。
最近想明白了另一个思路，即Skill 驱动的思路：
先想清楚助理应该做什么（GTD、项目管理、周期回顾、人际关系维护...），把这些方法论写成 Skill。结构不是提前设计的，是方法论需要什么结构，就自然长出什么结构。
GTD 需要区分"可执行"和"参考信息"，那就有标签系统。
项目管理需要跟踪进度，那就有项目视图文件。
周期回顾需要时间线，那就有 chronicle。
核心区别：
Markdown 方案：工具驱动，先有容器再装内容
Skill 方案：方法论驱动，方法论决定需要什么容器
结构不是重点，只是方法论的承载需要结构。换句话说，不是"我有这些文件夹，往里填内容"，而是"我用这个方法论工作，自然需要这样的文件结构"。
实际实践的效果也非常好。而且助理能力的迭代也不是调整目录，而是迭代和新增skill，这使得通过聊天就能持续提升这个助理的能力，感觉是找到正确的思路了
为什么这么说呢？Markdown 结构化方案的问题是，
你必须精心定义好的目录（项目/任务/人物/日志...），然后不停精调这个结构。但人的输入是混乱的，一句话可能既是想法、又关联项目、还涉及某个人，或者是个命令。这个目录结构注定是反迭代的，无法泛化的。
最近想明白了另一个思路，即Skill 驱动的思路：
先想清楚助理应该做什么（GTD、项目管理、周期回顾、人际关系维护...），把这些方法论写成 Skill。结构不是提前设计的，是方法论需要什么结构，就自然长出什么结构。
GTD 需要区分"可执行"和"参考信息"，那就有标签系统。
项目管理需要跟踪进度，那就有项目视图文件。
周期回顾需要时间线，那就有 chronicle。
核心区别：
Markdown 方案：工具驱动，先有容器再装内容
Skill 方案：方法论驱动，方法论决定需要什么容器
结构不是重点，只是方法论的承载需要结构。换句话说，不是"我有这些文件夹，往里填内容"，而是"我用这个方法论工作，自然需要这样的文件结构"。
实际实践的效果也非常好。而且助理能力的迭代也不是调整目录，而是迭代和新增skill，这使得通过聊天就能持续提升这个助理的能力，感觉是找到正确的思路了
11 05