在《面向技能的知识：从描述到执行》中，我讨论过一个想法：把知识封装成可以复用、执行和验证的 Skill，再通过工作流将它们组合起来。
沿着这个方向，我最近又有了一个判断：
AI 进入实际工作后的形态，会越来越像多种技能的综合体。这和人类岗位职能的形成方式很相似。
我们说一个人是开发者，并不意味着他只会写代码。他还需要理解需求、阅读已有实现、排查问题、验证修改，以及和其他人协作。
运营也是如此。写文案、分析数据、策划活动、理解用户，这些技能围绕业务目标组织起来，才形成一个岗位的工作能力。
岗位名称背后，是一组相互配合的技能，以及使用这些技能的经验。
我认为，这种结构也能帮助我们理解 AI。
一个写作 Skill，可以根据观点生成文章；一个配图 Skill，可以根据内容制作插画；一个发布 Skill，可以把文章和图片上传到博客。
这些技能单独使用时，各自完成一段工作。围绕“完成一篇博客”这个目标组合起来，才可能把一个模糊的想法推进成最终可阅读的内容。
用户最初交给 AI 的，可能只有一句话。AI 需要先理解这句话背后的意思，找到相关旧文，判断哪些观点已经讲过、这次有什么新的推进，再完成写作、配图和排版。
这时候，决定结果的已经不只是写作能力。能否找到已有知识、能否衔接不同环节、能否检查最终结果，同样重要。
技能回答“这一步怎么做”，职能回答“这一类工作怎么完成”。
这里的“职能”，可以理解为一种围绕目标组织起来的工作能力。它包含多种技能，也包含技能之间的关系：什么时候调用，使用什么信息，交付给谁，以及如何判断完成。
这也解释了为什么，给 AI 装上很多 Skill，并不会自然得到一个可靠的工作系统。
假设需求整理时理解错了业务目标，代码生成就可能准确实现一个错误的需求。后续审查如果只检查代码是否符合需求文档，甚至可能得出“实现正确”的结论。
每个环节都顺利执行，整体却偏离了最初的目的。
因此，组合技能时，还需要保留贯穿整个任务的目标，并在关键位置核对：当前产出是否仍然服务于原来的问题。
工作能力的形成，依赖这种持续的衔接和验证。
拿开发工作来说，我希望 AI 能够根据具体问题选择行动。修复一个小缺陷，也许只需要定位、修改和验证；涉及公共接口的调整，则需要进一步检查调用方、兼容性和迁移影响。
如果每项任务都机械地走完同一套流程，技能组合反而会变成负担。成熟的工作能力，需要能够根据任务决定流程的深度。
这和人的工作经验很像。经验的一部分价值，就体现在知道哪些步骤不可省略，哪些事情值得深入，哪些情况需要重新确认目标。
不过，借用岗位来理解 AI，也需要保留一个边界。
我在《Agent 不是队友，是外骨骼》中提醒过：仅仅给 Agent 安排一个角色，无法替代清晰的目标、上下文和完成标准。
“你是一名资深开发者”可以提示它关注某些问题，却不会自动补齐项目历史、业务规则和质量要求。
所以，要形成面向开发的工作能力，仍然需要准备相应的技能、知识、工具、权限和验证方式。岗位名称可以帮助人理解这套能力，实际执行则需要这些具体条件支撑。
这也意味着，AI 的能力组合可以更灵活。
人类岗位的边界，部分来自招聘、协作和组织管理的需要。一个团队可能把需求分析、开发、测试和部署分给不同的人，也可能由同一个人兼任。
AI 的技能组合可以围绕当前任务重新组织。处理用户反馈时，它可能同时需要内容理解、数据查询、问题复现和代码定位；维护一篇技术文章时，它可能同时需要资料检索、代码验证和文字编辑。
这些工作跨越了传统岗位的边界，却共同服务于一个具体目标。
因此，我更愿意把岗位职能看作一种参照。它帮助我们看见：完整的工作能力，本来就由多种技能共同构成。而在 AI 系统里，我们可以进一步把这种组合显式地设计出来。
接下来，人需要做的事情也会发生变化。
除了亲自执行，我们还需要梳理工作：哪些经验可以沉淀为技能，哪些规则应该成为共享知识，哪些步骤能够自动推进，哪些判断需要由人承担。
这与《团队角色模型》中讨论的判断、编排和验证是相通的。人要对工作目标和结果负责，同时逐渐把重复执行的方法沉淀下来，让它们能够被稳定调用。
每完成一次工作，都可以留下一些东西：一个经过验证的操作方法，一条补充后的业务规则，一个曾经遗漏的检查点。
这些积累会继续改善下一次执行。AI 的工作能力，也就有机会随着使用而逐步完善。
所以，当我说 AI 的形态会像人类岗位职能一样，由多种技能综合而成时，我真正关注的是：我们如何把零散的能力，组织成能够持续完成工作的系统。
一个模型可以提供广泛的基础能力。围绕具体目标组织起来的技能、知识、工具和反馈，才会让这些能力在真实工作中发挥作用。
未来介绍一个 AI 时，我希望能够说清楚的，是它能够接住哪一类任务，依靠哪些能力推进，以及我们如何确认它把事情做好了。