最近看到HITSZ OSA （811633021)
一、让 AI 写代码时的两条原则#
用自然语言让 AI 生成代码进入生产级项目，有两条原则应当重视。
第一，多考虑业务和流程的状态机。 把主要精力从「怎么写代码」转移到「系统状态如何变化」上：先定义清楚有哪些状态、什么事件会触发状态之间的转移，再让 AI 去填充具体实现。状态机是人和 AI 都能精确理解的描述方式，它把 AI 的生成能力限制在明确的业务规则之内，生成的东西才既快又可靠。
第二，约定好协作方式，用类型系统传递语义；抽象设计好，实现就不必操心。 这是使用代码的方式进行设计意图的表述
- 类型系统是业务含义的载体。订单状态不该是一个普通字符串，而应是「待支付、已支付、已发货」这样的枚举类型。当几十个 AI 生成的文件拼在一起时，类型就是它们之间的契约，接口才不会对不上。
- 人的工作到定义接口、状态、转移规则和错误码为止；函数体、边界情况、胶水逻辑可以交给 AI。「不管实现」不是偷懒，而是把注意力集中在「定义正确的类型和语义」上，验证手段是类型检查和端到端测试，而不是逐行读代码。
有一个自然的推论，将合适的设计意图转换为编译器和AI能够读懂的语义，并可以据此设计良好的测试，进行大范围重构和迭代开发。
二、外部能力的三种接入方式#
agent 调用外部能力，有三种方式值得区分：
skill（Function Calling） 使用渐进式加载的方式接入Agent，将一系列工具的说明和参数格式提前告诉模型，模型决定调用、参数，然后加载相应的markdown进入上下文，输出一条结构化的调用指令。
MCP Server 持久化存在于Agent上下文中。MCP 定义了模型与工具的统一接口，工具按标准封装一次成为 MCP Server，任何支持 MCP 的应用都能直接使用。它解决的是各自为政的问题。
*skill 和 MCP Server两者在上下文占用存在不对称，技能可以按需加载，先给简短说明，需要时才读入完整内容，这天然缓解了 MCP 的上下文膨胀，这是因为MCP 的工具描述通常是常驻上下文的。
Code Act（Bash/Python等） 规范的 SDK 相比 MCP 的侵入更小，功能更全，但是对于应用开放程度有要求。顺序调用两者都能做，并行操作直接写代码天然可表达，且目前主流模型接入 Agent 随手写几十行脚本并不困难。
对于模型而言，这三种方式并没有本质的不同，都是以token的方式进行编码解码，输出结构化的调用指令。对于Agent而言，针对具体需求，函数调用与skill最直接，如agent-browser、superpowers；调用某个成熟垂直领域应用，MCP 的标准化才有价值，如ida-pro-mcp；而简单终端可解决问题或无泛用性的应用需求，可以直接让AI写上几十行的代码随用随走，无上下文占用，对话独立，进程独立。
三、技能是对 AI 能力的逆向工程#
杨植麟在访谈中提到：Skill是对 AI 能力的一种逆向工程，reasoning和Agent分别是提升尝试轮数与尝试深度的工具。
模型训练完成后具备许多没有被明确发掘的潜能。技能的作用，是通过设计好的流程、约定和示例，提升一次尝试可以被验证是否正确的范围——让一个缸中之脑能够脱离空想，在实践中检验和发展真理（逃）。
杨植麟给出了两个判断：
- 正向集成优于逆向工程。 如果技能所激发的能力能在训练阶段被直接内化进模型，效果会比外挂技能更好。逆向工程是训练之外的次优解，尽管是目前最现实的解。
- 存在长尾效应。 足够通用的能力，厂商会在训练中完成，技能会被模型本体取代；较为小众的领域能力，通用训练覆盖不到，就需要合适的技能设计或 MCP 封装来补齐。技能生态的长期价值在长尾，不在头部。
笔者认为的一个边界条件：「通用能力会被训练吸收」只对静态知识成立。训练截止时间之后的新信息，以及企业内部的私有系统，训练在原理上就接触不到。
四、一个推广：MCP 是对应用能力的逆向工程#
「逆向工程」这个视角可以从模型一侧平移到应用一侧：技能逆向的是模型训练，写 MCP 本质上是对应用能力的逆向工程，同样服从长尾规律。
- 足够通用的能力，开发者会自己完成正向集成——官方 API、官方插件、官方 MCP Server 一应俱全，不需要第三方代劳。
- 较为小众的能力，没有官方动力提供对 agent 友好的接口，就需要有人单独做应用能力的逆向：弄清它的数据模型和操作流程，封装成 MCP Server，把它接入 agent 的世界。第二节提到的 ida-pro-mcp 就是典型——逆向工程工具本身没有官方的 agent 接口，社区把它的能力逆向封装出来，才让它进入了 agent 的工具箱。
五、一些思考#
笔者认为，或许模型最大的价值在于，可以通过与人的互动激发其能力，帮助更多人找到并实现自我价值，并顺路探索许多知识的边界。