AI搭子手册 022 | 数字员工越来越近,准备好管理 AI 了吗?

大家好，我是刘宸。

这里是「AI搭子手册」，咱们一起看懂AI。

最近我做了一次线上EMBA的分享。

主题围绕一个词展开：

数字员工

这个词这两年被讲得很多。

有人一听到数字员工，就会想到一个很科幻的画面：

公司里多了一个 AI 同事，它能自己理解任务，自己找资料，自己做判断，自己交付结果。

这个画面当然很吸引人。

但我这次分享之后，反而有一个更现实的感受：

数字员工不是某一个模型突然变强之后，就自动出现的。

模型能力只是基础。

真正让 AI 从“会聊天”走向“能工作”，还需要一整套配套技术。

这些配套技术，过去几年也在不断变化。

模型越强，我们越不能只盯着模型本身。

因为模型越强，它能参与的任务越复杂。

任务越复杂，就越需要有人设计它怎么接任务、怎么读资料、怎么调用工具、怎么记住经验、怎么自我检查、怎么持续改进、怎么围绕长期目标工作。

所以今天这篇文章，我想聊的不是某一个新模型。

而是借“数字员工”这个概念，拆开看一看：

一个真正能工作的 AI，背后到底需要哪些配套技术。

一、Prompt 工程：先把一句话说清楚

最早大家接触大模型，最熟悉的词就是 Prompt。

Prompt 工程，说白了就是：

怎么把你想让 AI 做的事，说得更清楚。

在 GPT 刚普及的时候，很多人第一次发现，原来同一个模型，你问法不同，效果差别会非常大。

你说：

帮我写一篇文章。

它可能给你一篇很普通的文章。

但你说：

请以公众号作者的口吻，面向企业管理者，写一篇 1500 字左右的文章，先讲问题，再讲原因，最后给出 3 条建议。

结果就会明显稳定很多。

这就是 Prompt 工程最朴素的价值。

你脑子里知道的背景、目标、标准、风格、边界，如果不说出来，模型只能猜。

而猜，就会带来不稳定。

所以早期的 AI 使用，很大一部分能力都体现在“会不会提问”。。

过去我们和软件打交道，是点按钮、填表单、选菜单。

到了大模型这里，我们开始用自然语言管理一个能力很强、但边界不稳定的系统。

Prompt 工程就是第一代管理方式。

它解决的是：

怎样让 AI 听懂这一次任务。

但只靠 Prompt，很快就会遇到瓶颈。

因为真实工作不是一句话就能说完的。

这时候，问题就从“怎么写一句好提示词”，变成了另一个问题：

哪些信息应该放进 AI 的脑子里？

二、上下文工程：让 AI 带着正确材料工作

后来大家开始越来越多地谈 Context，也就是上下文。

如果说 Prompt 是你对 AI 说的一句话。

那上下文就是 AI 在回答前能看到的全部材料。

包括你的指令、历史对话、文件内容、网页资料、工具说明、项目规范、记忆、技能描述，甚至还有系统层面的规则。

这时候，AI 的能力不只取决于模型聪不聪明。

还取决于它有没有看到正确的信息。

比如让 AI 写一份客户方案。

如果它只知道“写一份方案”，那它只能写一份模板化方案。

如果它同时知道客户行业、预算、过去沟通记录、竞品情况、公司报价政策、交付周期、不能承诺的条款，它才能写出真正接近业务现场的方案。

这就是上下文工程。

它不是把所有资料都丢给模型。

恰恰相反，它要解决的是：

在有限的上下文窗口里，放进最该放的东西。

这件事比看起来难。

因为上下文窗口再大，也不是无限的。

而且上下文越长，成本越高，噪音越多，模型也越容易被不重要的信息带偏。

所以一个好的 AI 系统，要学会管理上下文。

比如：

哪些规则每次都要加载哪些文件只有需要时才读取哪些历史信息要压缩成摘要哪些旧对话应该清理掉哪些资料适合交给子任务处理，不要污染主对话哪些内容应该通过搜索或数据库临时取回

这也是为什么现在很多 AI 编程工具里，会出现上下文窗口、压缩、清理、子代理、文件索引、规则文件这些功能。

它们本质上都在做同一件事：

让 AI 在正确的时间，看到正确的信息。

对企业来说，这一步非常关键。

因为企业里的知识，通常不是放在一个地方。

它散在文档、表格、合同、邮件、会议纪要、CRM、飞书、企业微信、项目管理系统里。

数字员工要进入真实业务，就不能只靠一句提示词。

它必须能被喂给正确上下文。

否则它再聪明，也只能在缺资料的情况下“合理发挥”。

而企业最怕的，恰恰就是这种合理发挥。

三、记忆系统：让 AI 不用每次从零开始

上下文解决的是“这一次任务要看什么”。

记忆系统解决的是另一个问题：

哪些经验值得带到下一次任务里。

我们和真人同事合作时，有一个很自然的期待。

你不希望每次都重新解释一遍：

我们公司是做什么的客户最在意什么老板喜欢什么格式哪些说法不能用上次这个问题是怎么处理的

如果一个同事每次见你都像第一次见面，效率一定很低。

AI 也是一样。

当它开始承担长期任务时，就需要记忆。

但记忆不是越多越好。

这点特别重要。

一个企业里的 AI，如果什么都记，就会带来很多问题。

它可能记住临时信息。可能记住过期结论。可能记住不该保存的隐私。可能把某一次特殊情况，当成以后所有任务的默认规则。

所以成熟的记忆系统，应该有管理能力。

至少要区分几类东西。

第一类，是稳定偏好。

比如文章风格、常用格式、品牌表达、团队习惯。

第二类，是项目知识。

比如代码结构、业务流程、客户背景、交付规范。

第三类，是历史经验。

比如上次踩过的坑、某个问题的解决办法、某类输出的审核标准。

第四类，是敏感信息。

这类信息不是“记得越牢越好”，而是要有权限、脱敏、审计和删除机制。

这也是为什么现在一些 AI 工具会把“规则文件”和“自动记忆”分开。

规则文件更像公司手册。

你明确写进去，告诉 AI 每次都要遵守。

自动记忆更像工作笔记。

AI 从反复出现的修正、偏好、流程里，总结出以后可能有用的经验。

这对数字员工来说很关键。

记忆系统的核心，不是让 AI 记住更多，而是让 AI 记住该记的。

四、Skill：把反复出现的经验，沉淀成可复用能力

当 AI 用得越来越多，我们会遇到一个很实际的问题。

很多任务会反复出现。

比如：

写公众号文章整理会议纪要分析客户反馈生成短视频脚本检查合同条款修复代码问题制作培训课件

如果每次都重新写 Prompt，就会很累。

而且不同人写出来的 Prompt 不一样，效果也不稳定。

这时候就需要 Skill。

Skill 可以理解成：

把一类任务的做法，打包成 AI 可以调用的操作手册。

它里面可以包含说明、流程、模板、示例、脚本、参考资料、输出规范。

比如一个“公众号写作 Skill”，可以写清楚：

固定开场白是什么文章结构怎么安排段落长短怎么控制标题风格是什么哪些词不要用最后怎么收束文件应该保存到哪里

这样下次再写文章时，你不需要重新解释一遍。

AI 先读这个 Skill，再按里面的流程执行。

这就很像企业里的 SOP。

区别在于，过去 SOP 是给人看的。

现在 Skill 是给 AI 看的。

这件事的意义很大。

因为数字员工不应该每次都临场发挥。

如果一个真人员工，每次做月报的格式都不一样，每次写客户邮件的语气都不一样，每次处理售后都靠感觉，公司肯定会觉得不稳定。

AI 也是一样。

Skill 的价值，就是把好经验从一次性的对话里拿出来，变成可复用、可分发、可迭代的能力。

而且 Skill 还有一个重要特点：

它不一定要每次全部塞进上下文。

比较成熟的做法是，先让 AI 看到有哪些 Skill、每个 Skill 适合什么场景。

只有当任务真的需要时，再加载完整说明。

这就同时解决了两个问题。

一方面，AI 知道自己有哪些能力。

另一方面，又不会一开始就被大量说明书挤满上下文。

从企业角度看，Skill 很可能会成为未来 AI 管理里的一个基础单元。

不是每个人都去写一堆临时提示词。

而是公司把高频任务沉淀成一套 AI 可执行的技能库。

这时候，AI 才开始从“聪明助手”变成“受过培训的员工”。

五、Harness：模型外面那一整套工作框架

再往后，只谈 Prompt、上下文、记忆、Skill 还是不够。

因为 AI 要进入真实业务，就会遇到更复杂的问题。

比如：

它能调用哪些工具哪些动作需要审批输出必须符合什么格式生成结果如何验证出现异常怎么处理中间过程如何记录失败后能不能重试谁来承担最终责任

这些都不只是模型问题。

它们属于模型外面的运行框架。

这个框架，很多人会用一个词来概括：

Harness。

Harness 原意有点像“马具”“安全带”“约束装置”。

放到 AI 里，可以理解成：

围绕模型搭起来的一整套任务执行、工具调用、权限控制、输出校验和评估系统。

为什么会出现“一代模型一代 Harness”这种说法？

因为模型能力一变，外面的框架也要跟着变。

早期模型不太会调用工具，你的 Harness 可能只需要做简单的输入输出。

后来模型会写代码、查资料、读文件、改文件、跑测试，你就要设计权限、沙箱、审批、日志、回滚。

再后来模型可以长时间规划、多步骤执行、调用多个子代理，你就要设计任务队列、状态机、验证器、异常处理和人工审核点。

也就是说，模型越强，Harness 越重要。

因为强模型不只是会说。

它开始会动手。

一旦会动手，就必须有边界。

举个例子。一个 AI 客服，如果只是回答问题，风险还比较有限。但如果它能直接改订单、发优惠券、申请退款、修改用户资料，那就不能只靠一句“请谨慎操作”。你需要明确：哪些工具它能用哪些金额以内可以自动处理哪些情况必须转人工每次操作如何留痕出错后怎么恢复如何定期检查它的表现

这就是 Harness。

它让 AI 的能力可以进入业务系统，但不会失控。

没有 Harness 的强模型，很容易变成一个“很会说、也很敢做”的不稳定员工。

有 Harness 的强模型，才更接近一个可以被管理、被审计、被改进的数字员工。

六、Loop 工程：让 AI 从一次交付，变成持续改进

如果说 Harness 解决的是“AI 怎么可靠地完成任务”。

那 Loop 工程解决的是另一个更进一步的问题：

AI 怎么根据结果不断变好。

过去我们用 AI，常常是一次性的。

我问一个问题。

它给一个答案。

我觉得不满意，再手动追问。

但真实工作中，很多任务本来就不是一次完成的。

比如写代码。AI 改完以后，要跑测试。测试失败，要读报错。读完报错，要继续修。修完再跑测试。直到通过。

比如写文档。AI 更新一版。检查链接是不是失效。检查代码示例能不能运行。检查和最新 API 是否一致。如果不一致，就继续修。

这就是 Loop。

它不是一次提示词。

它是一套循环：

执行观察结果收集反馈判断问题修改策略再次执行

Loop 工程的关键，是把反馈接回来。

没有反馈，AI 做完就结束。

有反馈，AI 才能知道哪里错了、哪里没达标、下一步该怎么改。

这个反馈可以来自很多地方。

可以是自动测试。可以是格式校验。可以是用户评分。可以是人工审核。可以是业务指标。也可以是另一个模型的评估。

关键不是反馈来自哪里。

关键是它能不能变成下一轮行动的输入。

这对企业很重要。

因为一个数字员工如果只会“做一次”，价值有限。

更有价值的是，它能在一个可控循环里持续改进。

所以 Loop 工程，其实是在把 AI 从“工具”推向“系统”。

工具是你点一下，它做一下。

系统是它能围绕反馈不断运行。

当然，Loop 也不能无脑自动化。

越是重要的业务，越要设计人工审核点。

哪些地方可以自动重试。哪些地方必须让人确认。哪些指标达标才能进入下一轮。哪些错误一出现就要停下来。

这些都是 Loop 工程的一部分。

一句话说：

Prompt 让 AI 开始工作，Loop 让 AI 学会把工作越做越好。

七、Goal 工程：让 AI 围绕长期目标推进

再往后，我觉得会越来越重要的是 Goal。

也就是目标。

其实现在一些工具里，已经能看到类似能力。

比如你可以给 AI 设置一个持续目标。

不是只让它回答一句话。

而是告诉它：

你的目标是完成这次迁移，并保持测试通过。

或者：

你的目标是把这份研究整理成可发布的文章初稿。

或者：

你的目标是把客户资料整理成一份销售可用的跟进方案。

这和普通 Prompt 有什么区别？

普通 Prompt 更像一个动作。

Goal 更像一个任务承诺。

动作可以很短。

目标通常需要拆解、推进、检查、调整、完成。

这就更接近我们管理真人员工的方式。

你不会只对同事说：

写一段话。

你通常会说：

这周把客户复盘报告交出来，重点解释流失原因，并给出下个月的改进动作。

这里面有目标，有范围，有时间，有交付物，有判断标准。

未来的数字员工，也会越来越需要这种目标管理。

Goal 工程要解决的，不只是“让 AI 记住目标”。

它至少包括几件事。

第一，目标要足够清晰。

什么叫完成？

交付物是什么？

验收标准是什么？

第二，目标要能拆解。

哪些步骤先做，哪些步骤后做？

哪些信息缺失？

哪些工具要调用？

第三，目标要能跟踪。

现在完成到哪一步？

卡在哪里？

下一步是什么？

第四，目标要能被暂停和恢复。

真实工作不会永远连续。

人会插话，任务会变更，资料会补充，优先级会调整。

AI 如果要成为数字员工，就必须能在这些变化中继续围绕目标推进。

第五，目标要有边界。

不能为了完成目标，就越权操作。

不能为了看起来完成，就编造结果。

不能为了效率，就跳过审核。

所以 Goal 工程本质上是在回答一个更管理学的问题：

我们如何给 AI 分配工作，并判断它有没有真的完成？

这一步如果做起来，数字员工就不只是“随叫随到的助手”。

它会更像一个能承接任务、保持状态、持续推进、接受验收的岗位角色。

八、把这些放在一起看，数字员工就不再只是概念

如果把前面这些阶段串起来，会发现一个很清楚的趋势。

Prompt工程解决的是：这一次怎么说清楚。

上下文工程解决的是：这一次要带哪些资料。

记忆系统解决的是：哪些经验要带到以后。

Skill 解决的是：高频任务怎么沉淀成可复用能力。

Harness 解决的是：模型怎么在真实系统里安全、稳定、可验证地执行。

Loop 工程解决的是：AI 怎么根据反馈不断改进。

Goal 工程解决的是：AI 怎么围绕长期目标持续推进。

这几件事合起来，才越来越像一个数字员工。

真正的员工要理解任务。要知道背景。要遵守规则。要使用工具。要记住经验。要按流程交付。要接受检查。要根据反馈改进。还要围绕目标长期推进。

所以我现在越来越觉得，企业准备 AI，不应该只停留在“买哪个模型”“接哪个 API”“做几个智能体 Demo”。

更应该提前问几个问题：

我们的高频工作有没有被拆成清晰流程我们的业务知识有没有结构化沉淀我们的 AI 需要哪些工具权限哪些操作必须人工审批哪些经验应该变成 Skill哪些结果可以被自动验证哪些指标可以形成改进闭环哪些岗位适合先引入数字员工

这些问题看起来没有模型发布会那么热闹。

但它们才决定 AI 能不能真正进入企业日常。

模型能力会继续变强。上下文会更长。工具调用会更自然。记忆会更稳定。多代理协作会更普遍。目标模式也会越来越成熟。

但最终，企业能不能用好 AI，还是要看自己有没有把工作本身整理清楚。

数字员工离我们越来越近。

但它不是凭空降临。

它需要企业把任务、知识、流程、工具、权限、评价体系都重新梳理一遍。

这也是我这次分享之后最大的感受。

这条线背后，其实就是 AI 从“聊天对象”走向“数字员工”的过程。

PS：我们正在筹备一场围绕数字员工的线下工作坊。

到时候会更具体地教大家企业数字员工如何搭建落地。

感兴趣的朋友，可以继续关注，欢迎私聊。

数字员工这件事，可能不会一夜之间发生。

但它已经不是遥远的概念了。

越早把这些基础能力想清楚，企业越容易在下一轮 AI 应用里占到先机。

AI可思议，陪你看懂AI。

记得关注，别走丢！