【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
分析了最后一个工具 Skill，Skill 工具可以加载一个专门的技能，所谓的技能可以提供特定领域的指令和工作流，其唯一的必选参数 name 用来描述要加载的技能名称，其描述文本为动态加载，当 list.length == 0 时，也就是当前没有 Skill，OpenCode 客户端会告知当前没有可用技能，而当 list.length > 0 时，客户端就会拼接出一段结构严谨的说明文本，告知触发条件和预期结果，并遵循渐进式披露规则（只有当 AI 决定使用某个技能并真正调用 Skill 工具之后，详细的指令才会被注入进来，实现按需加载，否则只展示技能名字和简介），下面继续分析
OpenCode
之前 blog
在分析源码构建的时候，略微有提到 package.json，下面涉及到项目配置，来详细分析下这个文件
package.json 是 Node.js 和前端项目的身份证和核心配置文件（OpenCode 客户端相对于 AI 大模型来说，也可以理解为前端），该文件位于项目根目录，有如下作用
- 记录项目的基本信息 ：比如项目名称（name），版本号（version），作者，入口文件
index.js（main）等元数据信息
管理依赖包（最核心的功能之一）：把项目需要的第三方库分类地记录下来，防止生产环境误装开发工具，有两种依赖类型
dependencies（生产依赖） ：项目运行时必须的包，部署上线时也要带上
devDependencies（开发依赖） ：只在本地开发和构建阶段用的工具，上线时不需要
- 配置快捷脚本命令（scripts） ：可以把复杂的命令行操作变成一键执行的快捷方式，比如在里面配置了
bun run script/build.ts，后面在终端里只需要输入bun run build就能完成打包工作，不用再输入一长串命令
- 提供其他工程化配置：很多现代前端工具也会把自定义配置直接写在里面，比如浏览器兼容范围（browserlist），ESLint 规则（eslintConfig）等
新建项目的时候，在终端运行 npm init（会一步步问问题），或者 npm init -y（直接跳过问答，用默认配置生成），就能自动创建一个基础的 package.json 骨架
另外，package.json 既可以由开发者手动更新，也会被包管理器（比如 npm，bun 等）自动更新 ，开发者可能会发现在执行 bun install 时，package.json 被 modified 修改了，这就是因为 Bun 在整理或规范化这个文件：
- 开发者手动更新：可以直接用编辑器打开，添加依赖，修改版本号或者编写脚本
- 命令行自动更新 ：当执行类似
bun add或者npm install等命令时，包管理器会自动把新包写入dependencies字段中
单纯运行 bun install（没有指定新包），理论上来说应该去读取依赖并安装 ，如果发现 package.json 还是被改了，大概原因是因为 JSON 格式化与键值排序，比如
Bun 作为一个追求极致性能和高标准的现代工具，在读取 package.json 后，会按照自己内部的规范对 JOSN 结构进行重新排版 ，比如把 dependencies 里的包名按字母顺序重新排列，或者调整某些字段的先后顺序，这种操作不会改变项目的实际逻辑，但在 Git 看来，文件内容确实发生了变化
最后再提醒下，虽然 package.json 可以手动修改，但项目中另一个伴随文件（对 Bun 来说是 bun.lock，对 Npm 来说是 package-lock.json）是绝对禁止修改的，这俩文件是共生协作的关系
package.json定义了项目允许安装的版本范围（提供灵活性）- Lock 文件则锁定了实际安装的精确版本和依赖树，确保团队环境的一致性
所以 Bun 在后台做的那些代码格式化或结构优化，只要程序能正常构建运行，这种修改是无害的，如果觉得这种 Git 报的 modified 变动看不过去，可以在确认无误后直接提交
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog