你给 AI 的一句话，往往暴露的不是模型上限。
而是你对工作的想象方式。
比如很多一人公司主理人，会很自然地对 AI 说：
“你帮我回一下这个客户，顺手整理个报价，再把会议纪要变成待办。”
听起来像一个任务。
其实已经混进了至少 3 个不同动作：
- 客户消息分级
- 需求摘要与报价整理
- 纪要转行动项
也就是说，你以为自己缺的是一个万能 Agent。
但你真正缺的，往往只是几个能稳定复用的 skill。
这也是我越来越确定的一件事：
对一人公司最值钱的，不是一个“什么都能做”的 AI 员工，而是 10 个能稳定复用、真正接住业务动作的高频 skill。
图 1：一人公司最容易被“数字员工”叙事吸引，但最先产生复利的，通常是那些可验收、可复用的小动作。
为什么“万能 Agent”这个想法这么诱人
因为它特别像招人。
你会本能地想：
- 如果有一个 AI 能自己理解上下文
- 能自动调用工具
- 能接住大部分对话和任务
- 那我是不是就多了一个数字员工
这套想象对一人公司尤其有吸引力。
因为你最缺的，本来就不是工具。
而是人手。
问题在于，“像员工”这件事，很容易让我们跳过真正该先做的那一步：把高频动作拆清楚。
结果就是：
- 任务一大坨塞进去
- AI 看起来开始工作了
- 但每一步都带着模糊边界
- 最后每一步还是得你人工接回来
所以万能 Agent 最危险的地方，不是它做不到。
而是它让你太早把业务想成“一个智能体就能接住”。
一个最典型的翻车例子是这样的：
客户发来一串语音，说自己想先试合作，希望你给个大概方向，再看看预算能不能对上。
你把这段话原样扔给 AI，让它“跟进一下”。
结果它很可能会一次性做错三件事：
- 没先判断这是不是高优先级线索
- 没先把需求压缩成可报价摘要
- 直接用一种过度确定的口气往前推进
最后你看起来拿到了一段完整回复。
实际上，你还是得自己回来改优先级、改边界、改下一步动作。
这就是为什么很多人明明已经在用 agent，却还是觉得每天都在收尾。
连最卖力讲 agent 的平台，也在强化“拆分”
如果你认真去看最近这一轮 agent 官方文档，会发现一个很有意思的事实：
它们表面上都在讲 agent。
但底层都在强调另一件事：
工作必须被拆成可以定义、可以组合、可以追踪的能力单元。
OpenAI 最近一轮 builder 文档，强调的是 templates、nodes、typed inputs and outputs、preview runs、workflow versions。
Anthropic 更直接，说最成功的实现通常来自 simple, composable patterns，而不是复杂框架，并且刻意把 workflows 和 agents 区分开来。
LangGraph 这类框架主打的也是 controllable、stateful、observable 的编排能力。
换句话说，主流平台虽然都在讲 agent，但它们在底层反复强化的，其实是同一个方向：
把工作拆成可定义、可组合、可追踪的能力单元。
也就是说，行业的真实方向，根本不是“万能人格”。
而是模块化能力 + 编排 + 可观察性。
这和一人公司最现实的起步路径，其实完全一致。
图 2：真正能落地的系统，不是一个会聊天的万能人格，而是一组可定义、可组合、可追踪的能力单元。
skill 到底是什么，它为什么不是 prompt
很多人把 skill 理解成“写得更好的 prompt”。
这还是太浅了。
在我这里，skill 更接近一个小型执行模块。
它至少有 3 个条件：
1. 固定输入
你知道这个动作吃什么。
比如：
- 一段客户原始消息
- 一份会议纪要
- 一组报价选项
- 一张运营表
2. 固定输出
你知道它产出什么，且这个产出可以验收。
比如：
- 优先级 + 意图判断 + 下一步建议
- 行动项列表 + owner + 截止时间
- 需求摘要 + 方案建议 + 风险边界
3. 固定边界
你知道它不能碰什么。
比如：
- 不替你承诺价格
- 不替你做最终判断
- 不凭空发明会议结论
- 不把模糊需求包装成确定交付
这 3 个东西一旦成立，skill 就不是聊天。
而是一个可复用模块。
prompt 可以一次性很好用。
skill 则是下一次还能复用，并且别人也能验收。
这也是为什么我会说：
一人公司最该先标准化的，不是整条业务，而是那些反复出现的中间动作。
一人公司最值得先封装的 10 个高频 skill
真正适合先做成 skill 的，通常有两个特征：
- 一周至少重复 5 次
- 每次都在消耗你的判断力，但又不是最终拍板
先记一个边界：
不是所有任务都该立刻做成 skill。
像最终报价确认、对外承诺、一次性战略判断这类高风险动作，不该排在第一批。
按一人公司最常见的工作结构，我会先从这 10 个开始。
客户侧
- 客户消息分级
- 线索下一步动作生成
- 需求摘要与报价要点整理
- 跟进提醒草稿生成
交付侧
- 会议纪要转行动项
- 供应商方案比较卡
- SOP 转检查清单
运营侧
- 运营异常点提炼
- CRM / 表格字段标准化
- 私域对话摘要与标签更新
这 10 个东西有一个共同点：
它们都不是“最后那一下拍板”。
它们是中间动作。
但恰恰因为它们出现得太频繁，所以一旦不稳定，你每天都在消耗。
而一旦稳定下来，你整个系统会突然轻很多。
图 3：skill 的优先级，不该按“看起来酷不酷”排，而该按“重复频率和复用价值”排。
先拆开 3 个最典型的 skill
光列清单还不够。
真正关键的是，你要知道 skill 应该怎么定义。
下面这 3 个，是一人公司最容易马上上手的。
skill 1：客户消息分级
输入：
- 客户原始消息
- 历史对话摘要
- 当前服务边界
输出：
- 消息类型
- 优先级
- 对方真实意图判断
- 2 到 3 个下一步动作选项
边界：
- 不直接承诺价格
- 不替你答应交付范围
- 不假装双方已经确认过的事项
skill 2：会议纪要转行动项
输入：
- 通话或会议纪要
- 参会人列表
- 当前项目阶段
输出：
- 关键结论
- 待办事项
- owner
- 截止时间
- 阻塞点
边界：
- 没说过的决定不要补
- 不要自己创造 owner
- 模糊部分要标注待确认
skill 3：需求摘要与报价整理
输入：
- 客户需求碎片
- 现有服务方案
- 不同报价选项
输出：
- 需求摘要
- 推荐方案
- 价格区间
- 不包含项
- 需要客户确认的问题
边界：
- 不替你做最终价格承诺
- 不把模糊需求写成确定交付
- 不把内部假设包装成客户已确认信息
如果你把 skill 这样写出来，你会发现它根本不神秘。
它只是一个有契约的动作单元。
回到开头那条客户语音，其实最稳的处理方式不是让一个“万能 Agent”整段吞掉。
而是拆成三步：
- 先用“客户消息分级”判断这是不是高优先级线索
- 再用“需求摘要与报价整理”压出方案和不包含项
- 最后再用“下一步动作生成”决定是约电话、补信息，还是先发简版口径
这时候你拿到的就不再是一段看起来完整、但边界发虚的回复。
而是三个可验收、可修改、可复用的中间结果。
图 4：skill 不是 prompt 收藏夹。skill 的价值在于它能被复用、被验收、被接进下一步流程。
哪些任务不该先做成 skill
不是所有事都适合 skill 化。
下面这些，通常不该排在第一批：
1. 低频的一次性任务
如果一件事一个月只发生一次，先别急着封装。
你很可能会花比执行本身更多的时间去设计它。
2. 高风险的外部承诺
比如：
- 最终报价确认
- 合同边界承诺
- 对外公开立场
这些动作可以先让 AI 起草。
但不应该直接当成可自动执行的 skill 放出去。
3. 需要 owner 最终判断的战略问题
比如：
- 这周到底主推哪个方向
- 要不要接某个客户
- 供应商到底换不换
这些问题可以被拆出很多 supporting skill。
但最后那一下，不该外包。
所以正确顺序不是：
“这件事能不能整个交给 agent？”
而是：
“这件事里面，哪些动作能先稳定下来？”
真正的顺序是：skill -> workflow -> agent
这一点特别重要。
因为很多人一上来就想跳到最后一级。
但真正稳的路径通常是：
先做 skill
把高频中间动作稳定下来。
再做 workflow
把多个 skill 串成结果链路。
最后才考虑 agent
让 agent 去承担协调、调用、切换上下文这些更高层的动作。
也就是说：
- skill 解决“单点动作稳不稳”
- workflow 解决“结果链路通不通”
- agent 才解决“复杂编排灵不灵”
如果你没有 skill，workflow 会发虚。
如果你没有 workflow，agent 会漂着。
所以很多一人公司不是不该做 agent。
而是不该一上来就做万能 agent。
图 5：skill 是积木，workflow 是装配线，agent 更像协调层。顺序一反，维护成本就会很快压过收益。
最后一句
如果你最近总在想：
“我到底该不该给自己做一个万能 Agent？”
先别急着回答这个问题。
先回答另一个更实际的问题：
你这一周里，哪 3 个动作重复了 5 次以上，而且每次都在浪费你的判断力？
今晚就花 20 分钟，把它们列出来。
然后先挑一个，逐个写清楚：
- 输入是什么
- 输出是什么
- 边界是什么
很多一人公司的 AI 系统，真正的起点不是一个聪明人格。
而是这三个字段。
下一篇，我们再继续往前走一步：
当你手里已经有了一批 skill，怎么把它们从“好用的小工具”，变成真正能推进结果的 workflow？