什么是Skill ，它和 Function Call 的区别在哪里

简单来说，Function Calling 是基础工具/原子操作，而 Skill 是利用这些工具完成特定业务目标的完整能力

Skill 和 Function Call 是两个不同层面的机制，虽然经常配合使用，但作用不一样。如果说 LLM 是大脑，那 Skill 就是可供大脑查阅的可复用的经验说明文档，而 Function Call 则是可供大脑思考后进行操作改变环境与环境交互的手脚

Function Call（工具调用） 解决的是‘能力’问题 ——它让模型能真正执行一个动作并拿到结果，比如查天气、读文件、发请求。核心特点是模型主动决定‘调用哪个工具、传哪些参数’，然后真实执行并返回结果

Skill 解决的是‘怎么做得好’的问题 ——本质上是一套打包好的说明书，一般来说是一个 SKILL.md 加上一些配套的脚本和模板。当任务触发某个 Skill 的时候，这份说明书会被注入到模型上下文里，也就是告诉模型这类任务要遵循什么流程、注意什么细节、参考什么规范。Skill 本身不执行任何操作，它是在为模型解决问题做准备或者预案，而不是替模型解决问题（ memos ）

同时，Skill 目录下往往也会出现一些现成脚本，像处理 docx 文件的 Python 脚本，所以准确来说，Skill 提供的是 可复用的知识+可选的预制资源，但真正的执行还是需要依靠 Function Call 来完成

二者相配合，才能让模型既有能力执行，又能知道怎么执行得专业

渐进式披露指的是 Skill 的内容分层加载，而不是一次性把所有信息交给模型

第一层：元数据，始终常驻
每个 Skill 会有名字、一句话描述，模型的视角里就是一个索引列表，知道有哪些能力，这些能力能干嘛，但不知道具体细节

第二层：正文，这层按需加载
当用户主动调用或者任务描述跟 Skill 的 description 匹配上的时候，模型才会去读取这个 Skill 完整的正文，此时这个 Skill 的具体流程、规范才真正进入上下文

第三层：资源层，有用到的时候才读
模型判断需要用到这个 Skill 下的某个资源时才会去读

本质上是“按需加载+分层过滤”，控制进入模型决策上下文的信息密度和相关性，换言之，上下文越干净、越聚焦，模型的判断就越稳，从而提升 Agent 稳定性

不应把所有环境变化都视为 Observation 失效，而应根据 Action 的依赖做精细化失效判断，在正确性、延迟和 token 成本之间做权衡

Agent Runtime 本身通常不承担开放环境下的语义决策，它负责应该是工具调度、状态管理、执行控制和结果回传这类确定性的工程逻辑，而不是一些开放性的语义决策；而模型负责根据当前 Observation 进行下一步决策

当环境状态不能被预先完整编码成固定规则时，就需要 Agent Loop 通过不断观察环境，来让模型动态选择下一步动作

Coding 这种场景就类似（我知道目标，但不一定提前知道每一步
同时，确定性的、可安全重试的故障由 Runtime 处理；涉及环境语义、执行结果不确定或可能产生副作用的情况交回模型重新决策
有看到过一些文章说固定重试次数，但在使用过程中，关键的不是重试次数，而是这个操作是否能安全重试？

AI只是效率工具不是护城河

https://mp.weixin.qq.com/s/GDCczcQuryGLdf2qeFvzbQ
Boris Cherny 访谈

悬余、解缚

大模型以不连续的跳跃式速度跃迁，而产品集成却以连续的增量式节奏推进。这就导致模型所具备的能力总会超出现有产品所能释放出的边界

模型激发：在不改变模型权重的情况下，通过提示词、上下文、工具或产品形态的设计，让模型表现出它本已具备但此前从未被激发调用的能力

模型解缚

1. 给模型比你想象中更难做的任务。描述清楚目标和边界和退出条件，然后放手
2. 多做实验。允许模型做一些没有明确商务目的但好玩的尝试，“给自己自由去玩模型、去做有创意的事”
3. 让模型自己验证成果。如果模型不能自我验证任务，它就无法长时间独立运行

用经验主义方式对待模型，忘掉过去对旧模型的经验和课堂上学的计算机科学理论，直接观察模型在哪里卡壳，再针对性调整

吐槽：哪有那么多 token 能烧

你所看到的一切都应是火种，引起你思考大火的熊熊燃烧

博客新UI上线😋

1. 意图定义和精确规格写作：把业务痛点转化为清晰需求、验收标准、输出格式、边缘案例
2. 批判性代码审查与调试心智模型：必须能读懂 AI 代码，找出隐藏 bug，安全漏洞、坏抽象、违反分层规范的问题。而建立强大心智模型的最好方式是：手动实现核心概念，再让 AI 辅助
3. 软件工程基础与“底座思维”：深入理解分层架构（controller­­­s➔services­­­➔models）、monorepo 组织、统一日志/RBAC/审计/定时任务脚手架、DB 变更流程
4. Harness Engineering / Guardrails 设计：学会写 Rules（Agents.md）、创建安全 CLI 工具、Memory 记忆系统、自动测试+Reviewer 流程
5. Prompt Engineering：为 AI 提供高质量上下文如架构决策、规范、示例、最佳实践
6. 领域支持、业务判断、沟通力：深入垂直领域，理解真实痛点和权衡

从“会写”到“会判断”

  会写              写得好            会做系统           会判断
(能实现)  ──▶   (优雅、健壮) ──▶   (拆得清、连得顺) ──▶ (知道为什么、
                                                     算得清代价)
  │                 │                  │                  │
「我能让它          「我能让它          「我能把它          「我知道这么做
  跑起来」           跑得漂亮」          搭起来」            换来了什么、
                                                      又放弃了什么」
  ▲                                                       ▲
  └──── AI 正在快速逼近、甚至超过这一段 ────┘            └─ 这一段,
                                                         只能靠自己

对于技术选择，多问自己

1. 为什么是它？(我有什么理由选这个,而不是另一个?是真有理由,还是只是「大家都这么用」「我熟」?)
2. 代价是什么？(选了它,我同时放弃了什么?将来会在哪里付出代价?)

正向的”懒“，让我学会更高效率的做事
清醒的懊悔，让我持续向上生长

Vibe coding 误区：AI 写完代码能跑就结束了
但在真实项目里，能跑只是第一步，还要看有没有破坏原有逻辑，有没有留下隐性问题，有没有让后期维护变难
所以写完代码要进行 review，而不是直接下一个需求
Review 一般要做 5 件事

1. 改动范围是否超出指令
2. 是否改了不该改的文件
3. 接口和数据结构是否保持兼容
4. 异常状态有没有处理
5. 有没有新增难维护的重复逻辑
   可以让 code agent 输出一份改动摘要，包括：

• 这次改动改了哪些文件
• 每个文件改了什么
• 为什么要这样改
• 有哪些潜在风险
• 建议怎么测试
  工程交付不知看结果，也要看可解释性，如果改动说不清影响范围，后面出问题我们很难去定位维护
  开发闭环应该是：
• 先分析需求
• 判断影响范围
• 生成执行指令
• 让 code agent 修改
• Review
• 验收
  让 code agent 从能写代码到能稳定交付，把需求、开发、审核、验收这条链路跑稳
  #学习

谷歌Chrome负责人揭开Vibe Coding幻觉：AI只能帮你写出70%的代码！未来开发者培养方式将变化成三人编程

• 真正的 AI 驱动开发不是“快”，而是有意图的构建
• 如果只是”跟着 vibe 走”，我觉得在创意阶段、原型阶段是可以的，这个阶段更需要发散；但在工程阶段肯定不行，在工程阶段更需要“规范驱动开发”
• 在尝试之前先问自己：“如果把这个问题交给 AI，它会帮我更快解决吗？还是会拖慢我？”即使只是思考这个问题，也能帮助我们更好理解 AI 的边界与潜力
• 大模型的上下文窗口是有限的，这就意味着我们需要：将任务拆解成小的、可验证的块；保持需求清晰，反复迭代；

Medium 上有好多文章都在说公司大规模引入AI编码工具后，会出现软件架构漂移问题，甚至会导致重大生产事故，比如 AWS。去年12月份 AWS 内部 Kiro 在处理 Cost Explorer 服务问题的时候，自主决定“删除并重建”整个生产环境，导致服务中断 13 小时，国内一大堆订单处理受影响。
AI 确实能给开发效率带来显著的提升，但是不是也会带来飞速的架构漂移？OpenClaw 就是一个典型的“几乎全靠 AI 维护”开源项目，它的代码规模也在 AI 快速迭代的情况下快速膨胀，社区也反馈了其很多“局部正确、全局崩坏”的情况。

所以判断力是不是应该成为程序员最核心的能力？

在 AI 时代，比起自己动手写代码，更重要的是能准确判断 AI 做的“对不对”——是不是符合长期架构、业务逻辑、全生命周期成本以及潜在风险
而判断力本质上是大量隐性知识的积累

• 过去踩的坑
• 团队沟通、博弈和权衡的一些实战经验
• 对业务真实痛点、因为成本、扩展性、合规性等的理解

代码可以外包给 AI，但判断没办法外包

#linuxdo

AI 时代，团队需要有很多ai想法或者产品思维的人，而不是螺丝钉（随时会被替代），如果你的想法很值钱，就不容易被替代
模型的结果质量 = 需求明确性 + （提示词）上下文（大模型侧的视角，用户侧的视角是认知）「认知：对代码的理解、产品的理解、开发的理解等等，懂得越多能更好的压榨模型的能力」
人不可能比 ai 聪明，但人能和 ai 相互促进良性循环

反思：如果没有极大发挥 AI 的能力，就只能算是普通程序员 + ai coding 工具协作罢了

#bilibili

对于大模型要有一定理解，不要只把它当成一个黑盒用连最基本的原理都不知道
#linuxdo

车灯只能照亮50米，可车子就是可以跑完全程

post memos test #test