当软件能力可以被 AI 直接调用后，GUI 是否会被取代？本文通过设计项目管理 Skill 的实践，指出 Skill 与 GUI 并非替代关系，而是互补：Skill 负责高效执行，GUI 负责复杂状态展示与结果确认。文章深入拆解了 Skill 的设计原则与边界，为产品经理提供了 AI 时代功能设计的新思路。

从飞书 Skill 出现开始，我就一直在想一个问题：当软件能力可以被 AI 直接调用后，GUI 还重要吗？

直到最近，我在内部项目管理平台里设计了一款 Skill，把查工作项、分配负责人、更新状态等能力开放给 Agent。真正走完这条链路后我才想清楚，很多“GUI 即将消失、Skill 可以替代界面”的判断，其实混淆了两个问题。

Skill 解决的是“怎么更快、更批量地把事情做完”，GUI 解决的是“怎么把复杂状态看清楚、把规则配置好、把结果确认下来”。两者不是替代关系，而是互补关系：自然语言表达意图，Agent 负责理解和编排，Skill 负责执行，GUI 负责展示和确认。

01 从一次点击开始，重新看 GUI 的价值

传统互联网二十多年，软件设计一直围绕同一个目标：降低人操作软件的成本。产品经理画页面、定导航、补按钮、做表单，本质上都在帮用户把一件事做得更顺。

项目管理软件尤其如此。项目、迭代、工作项、字段、筛选、权限、看板、报表，功能越多，系统越能覆盖真实工作；但另一面也很诚实：入口越多，用户越需要先学会“去哪里做”。

过去我们把这当成信息架构问题。现在它仍然是，只是多了一个新入口：用户可以先表达意图，再让系统决定调用哪项能力。

下面这张图不是在比较“聊天比页面高级”。它说的是：当一条需求足够明确时，用户不必亲自穿过每一个中间界面；这些界面背后的能力，应当能被可靠地调用。

GUI 的问题从来不是慢，而是它天然把一次工作拆成一串可见操作。对于不熟悉系统的人，这串操作还是额外的学习成本。Skill 的优势恰好在这里：它接收的是“我要完成什么”，不是“我下一步该点哪里”。

这会带来四个很直接的变化：

1. 速度：一句“把这条工作项分配给某位同事”，可以省掉找入口、填字段、提交的一串动作。
2. 批量与流程链：查待办、查当前迭代、查项目风险可以并行；查元数据、补参数、创建工作项可以串成一条受控流程。
3. 自然语言：用户不必记住字段名、类型编码或负责人 ID。Agent 可以先查询并补全这些机器需要、用户不需要关心的信息。
4. 嵌入开发工作流：需求文档、代码变更、测试结果和工作项状态终于可以落在同一条上下文链路上，而不是靠人复制粘贴。

但如果因此得出“页面没用了”，那又走到了另一个极端。

02 GUI 不会消失，它会退到更擅长的位置

我更愿意把未来的软件看成一个分层协作系统。自然语言负责表达意图，Agent 负责理解上下文和编排动作，Skill 负责执行确定的能力，GUI 则把复杂状态、配置和结果放到人最适合判断的地方。

这里有一个很重要的边界：Agent 不是新的数据库管理员，Skill 也不是绕过规则的后门。它们只能在原有权限、字段校验和审计范围内做事。飞书 CLI 这类面向 Agent 的能力也印证了这点：工具化接口仍依赖既有应用权限，而不是让 AI 获得额外权限。

GUI 仍然是三类工作最好的载体。

第一类是看复杂状态。项目健康度、依赖关系、燃尽趋势、多人任务分布，都是并列信息很多、变化很快的东西。让用户在一段对话里反复追问，不如用一张可以缩放、筛选、对比的界面说清楚。

第二类是做配置。工作流、字段、权限、通知规则、项目模板都不是日常高频操作，却会影响很多人。它们需要可视化的影响范围、明确的默认值和完整的回退入口。把这类东西藏进一句自然语言里，反而容易误改。

第三类是确认结果。尤其是批量改负责人、变更状态、调整排期这类动作，用户需要知道“改了什么、没改什么、为什么失败、还能不能撤销”。结果页、变更摘要和审计记录，会比一句“已完成”可靠得多。

03 Skill 不是命令集合，而是可被调用的能力单元

很多团队一谈 Skill，就急着把每个按钮包成一个命令。这么做很快，却很容易做出一套只会把 GUI 自动化、却无法被 Agent 稳定使用的接口。

我理解的 Skill，至少要同时满足三件事：输入语义稳定、执行边界清楚、输出结果可复核。它不需要知道用户的所有上下文；它只需要把一件业务动作做对，并把结果按约定返回。

但在真正设计这款项目管理 Skill 时，我先想清楚的不是要不要再造一套系统，而是怎么复用已有能力。很多 Skill 的本质，是对 API 的再利用：先用 CLI（命令行接口）把 API 的鉴权、参数、输出和错误处理封装好，再用一组 Markdown 文档说明 Agent 什么时候调用哪个 CLI、参数怎么填、多个命令怎么组合，以及哪些动作必须先让人确认。

在这套设计里，Skill 本身不直接执行写入，也不替代 API。它更像 Agent 使用 CLI 的一份产品说明书和操作规约，定义能力边界、调用条件、执行顺序和结果处理。实际调用链是：用户意图 → Agent → Skill（Markdown）→ CLI → API → 项目管理系统。

以项目管理平台为例，我不会先做一个“万能项目管理 Skill”。更小、更稳的起点是几组可组合的能力：读取项目与迭代上下文、搜索工作项、创建工作项、分配负责人、更新状态、关联文档、读取风险与审计记录。

这套拆法有点像乐高。Agent 可以把“读取需求文档 → 查项目模板 → 创建工作项 → 分配负责人 → 回写链接”编排成一条链；但每一块积木仍有自己的字段校验、权限检查和可预期的失败结果。出了问题，也能定位是哪一步失败，而不是让一段大提示词背锅。

Skill 的颗粒度也不能太细。把“选择项目”“输入标题”“点击提交”拆成三个 Skill，只是把 UI 的零碎步骤搬进了对话；把“从需求到上线全自动完成”塞进一个 Skill，又会把权限、异常和责任混在一起。比较合适的尺度，是一个业务动作：能独立授权、独立审计，有清楚的失败与重试策略，也能被其他流程复用。

04 线性的工作项，怎样接住 Agent 的非线性思考

项目管理里的工作项，通常是一条线：需求进入、拆分、开发、测试、发布、关闭。Agent 的工作方式却更像一张网：它会读文档、查历史、比对依赖、并行收集信息，再决定下一步。

两者并不冲突。线性的工作项提供了组织协作需要的共同事实；Agent 只是把线外的上下文收集、判断和编排效率提高了。真正要改的，是让每个线性节点都能接住可调用能力，而不是让 Agent 绕过流程直接改结果。

我会把这条链路拆成两层。上层是 Agent 的“理解层”：读需求、补上下文、找负责人、识别依赖、生成计划。它可以有不确定性，也可以向人提问。下层是 Skill 的“执行层”：创建、更新、关联、查询。它必须确定，必须带上身份、权限、参数校验和审计。

这样设计后，“开发完成后直接修改状态”就不再是一句含糊的想象。Agent 可以读取提交记录、测试结果和发布信息，提出状态变更；低风险、规则明确的状态可以自动执行，高影响或证据不足的变更则回到 GUI 让人确认。自动化不是取消责任，而是把责任放在正确的节点上。

05 要不要做 Skill，我会先问四个问题

不是每个功能都值得 Skill 化。对一个刚上线、字段还在频繁变化的项目平台来说，先把 GUI 做顺，往往比先铺一套不稳定的工具协议更重要。

我会先问四个问题：这个动作是否高频且意图明确？是否常常与其他动作连成链？是否能定义清楚输入、输出与失败？它的风险能否通过权限、确认和审计兜住？四个答案越接近“是”，越值得 Skill 化。

例如“查询我当前迭代的未完成工作项”，很适合做成读取型 Skill：频率高、结果边界清楚、可以与其他查询并行。“修改项目工作流”，则更适合留在 GUI：频率低、影响面大、需要看清整条状态机。至于批量调整负责人，它应该两边都有——Skill 负责生成和执行受控变更，GUI 负责展示影响清单和最终确认。

产品设计在这里不再只是把一个页面画出来，而是要把同一项业务能力拆到合适的交互层。该给人看的，不要让 Agent 代替人看；该让机器执行的，也别强迫人反复点击。

06 最后，GUI 要从“操作入口”变成“信任界面”

当系统开始允许 Agent 写入数据，用户对 GUI 的期待会变得更高。它不只是一个能点按钮的地方，更应该是用户判断“系统有没有按我的意思做”的信任界面。

我希望未来的项目管理平台，能让用户用自然语言发起工作，用 Agent 组织上下文，用 Skill 调用能力，也能随时回到 GUI 看状态、调规则、确认结果。它们不是三套产品，而是一套能力系统的三个面。

说到底，GUI 适合“看”，Skill 适合“干”。前者让复杂协作变得可见、可理解、可确认；后者让软件能力摆脱页面入口，进入 Agent 和自动化流程。产品经理未来要设计的对象，也就不再只有页面，而是一整套既能服务人、也能被 AI 安全调用的能力体系。