工具管理也需要产品化

这种思路不要求改变工具本身的安装方式 只是在更上层加一层组织逻辑

剑飞
1/14工具管理也需要产品化

开发者工具的数量在持续增长

01问题

决定工具方向

02材料

决定生成质量

03约束

决定结果边界

把“开发者工具的数量在”落到一个具体项目里看结果
2/14工具管理也需要产品化

把工具管理当作一个产品来设计

把工具管理当作一个产品来设计意味着要从用户体验的角度重新审视这个过程
3/14工具管理也需要产品化

如果我们从"一个开发者管理

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“如果我们从"一个开”落到一个具体项目里看结果
4/14工具管理也需要产品化

工具跟着问题走

问题决定工具方向
材料决定生成质量
约束决定结果边界
把“工具跟着问题走”落到一个具体项目里看结果
5/14工具管理也需要产品化

这七条需求看似简单

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“这七条需求看似简单”落到一个具体项目里看结果
6/14工具管理也需要产品化

不如按场景组织工具

与其追求大一统的全局方案不如按场景组织工具

问题决定工具方向
材料决定生成质量
约束决定结果边界
7/14工具管理也需要产品化

迁移时也可以按场景选择性复制

按场景分组管理的好处是工具数量可控（每个场景可能只有10-20个工具） 配置可以隔离 迁移时
8/14工具管理也需要产品化

具体实现可以是这样的

具体实现可以是这样的有一个 `tools.toml` 配置文件里面按场景分块

命题先说清本页判断
解释补足为什么
行动留下下一步
9/14工具管理也需要产品化

"tree-sitter"

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“"tree-sit”落到一个具体项目里看结果
10/14工具管理也需要产品化

[scenarios.co

[scenarios.content] tools = ["xhs","jinfei-cards"] ```
11/14工具管理也需要产品化

然后有一个命令 `tool

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“然后有一个命令 `”落到一个具体项目里看结果
12/14工具管理也需要产品化

带走四步

找项目

从真实任务开始

出材料

把想法变成可处理内容

做交付

用结果判断能力

可复用

把完成沉淀为流程

13/14工具管理也需要产品化

让能力长出来

这种思路不要求改变工具本身的安装方式只是在更上层加一层组织逻辑

返回原文
上一篇多Agent协作系统 从单打独斗到团队作战下一篇从空白到结构 一次PPT规则沉淀