7.7
深览指数
产品人人都是产品经理·零度Pasca··AI 生成
从飞书 Skill 到项目管理平台实践：重新理解 Agent、GUI 与 Skill 的分工
本文通过设计项目管理 Skill 的实践，论证了 Agent、GUI 与 Skill 并非替代关系，而是互补分工：Skill 负责高效执行，GUI 负责复杂状态展示与结果确认，Agent 负责上下文理解与编排。作者基于真实项目经验，提出了 Skill 的设计原则（输入语义稳定、执行边界清楚、输出结果可复核）和颗粒度判断标准，并指出 GUI 将从一个「操作入口」演变为「信任界面」，用于确认系统是否按用户意图执行。适合产品经理、AI 应用设计师和软件架构师阅读。原文 ↗
核心观点
- ▍Skill 与 GUI 并非替代关系，而是互补：Skill 负责高效执行，GUI 负责复杂状态展示与结果确认，Agent 负责理解上下文和编排动作。
- ▍GUI 不会消失，但会退到更擅长的位置：看复杂状态、做配置、确认结果。
- 01Skill 带来的四个直接变化：速度提升（一句话省掉一串操作）、批量与流程链（并行查询与串行流程）、自然语言（用户不必记住字段名等机器信息）、嵌入开发工作流（需求/代码/测试/工作项状态落于同一上下文）。
- 02作者设计的实际调用链：用户意图 → Agent → Skill（Markdown 文档）→ CLI → API → 项目管理系统。
- 03SKill 的颗粒度判断标准：一个业务动作，能独立授权、独立审计，有清楚的失败与重试策略，也能被其他流程复用。
- 04未来项目管理平台的分层架构：上层是 Agent 的「理解层」（可不确定性，可提问），下层是 Skill 的「执行层」（必须确定，带身份、权限、参数校验和审计）。
- 05对某功能是否 Skill 化的四个自问问题：是否高频且意图明确？是否常与其他动作连成链？是否能定义清楚输入/输出/失败？风险能否通过权限/确认/审计兜住？
- 06「查询我当前迭代的未完成工作项」适合做读取型 Skill；「修改项目工作流」适合留在 GUI；「批量调整负责人」应两边都有。
反方 / 局限
- — 不是每个功能都值得 Skill 化：对刚上线、字段还在频繁变化的项目平台，先将 GUI 做顺往往比先铺一套不稳定的工具协议更重要。
- — Agent 不能获得额外权限，只能在原有权限、字段校验和审计范围内做事；Skill 不是绕过规则的后门——作者引用飞书 CLI 印证了这一点。
10 分钟 · 4 卡片 · 11 资料
读原文 →