- 员工 AI 用得熟练，却不会界定问题、不会检查工作，能力并没有提高，只是出错的速度变快了。
- 所以值得培养的技能是把问题界定清楚、分辨哪些信息可信、讲得出自己工作背后的理由，背指令并不在其列。
- 最准确的衡量方式是看实际的工作成果，培训时数说明不了多少问题。
看新技能，要看实际工作，别看工具名称
招聘新员工时，我们问的是他能不能把工作做完，很少问他会用哪些软件。AI 也应该用同样的标准来看。该问的是“他负责的工作真的变好了吗”，“谁会用新工具”这个问题能说明的东西少得多。
AI 工具变得很快，工作的本质却变得慢得多。客户要的仍是正确的答案，工厂仍然需要好产品，管理层还是得在各种限制下做决定，团队也照样要按时交付。所以真正要问的是“这名员工能不能让工作从头到尾都变得更好”，会打开哪些应用只是小事。
先把一个岗位拆成若干项任务。比如销售人员并不只有一项工作，他们要搜集客户资料、准备问题、评估商机、写方案、谈判、记录每笔交易的进展并跟进。AI 也许很擅长搜集资料和起草，但读懂客户的动机、选择交易条件、维护客户关系，仍然需要判断力。把岗位看成一组任务之后，公司就知道该教哪些技能，也不会一头扎进范围过宽的课程。
能力的三个层次
第一层是了解 AI、懂得安全使用。第二层是用 AI 提升自己的工作质量。第三层是改造流程，让整个团队受益。并不是每名员工都要达到第三层，但每个部门都应该有人能把业务知识和工作流设计结合起来。
起步调查
- 哪些任务耗时很多，给客户带来的价值却很少？
- 哪些任务出错率高，或者要反复修改？
- 哪些任务需要阅读大量文件或消息？
- 哪些任务依赖少数几个人的专门经验？
- 哪些任务影响太大，必须保留人工审批？
把工具使用者变成成果创造者的十项技能
背下来的漂亮指令很快就会过时，因为工具每年都在变。能把问题界定清楚、分辨哪组数据可信、讲得出为什么这样决定的人，不管公司用的是哪一代工具，都有价值。
| 技能 | 可观察到的行为 | 证据示例 |
|---|---|---|
| 1. AI 素养（AI Literacy） | 能说明 AI 的局限，并按风险高低决定怎么用 AI | 说得出哪些工作可以让 AI 起草，哪些绝不能让它自己拍板 |
| 2. 问题界定（Problem Framing） | 把笼统的指示转化成目标、使用者、限制条件和成功标准 | 一份别人读完就能接着做的任务简报（Brief） |
| 3. 批判性思维（Critical Thinking） | 敢于质疑结论，寻找反方理由，把事实和假设分开 | 记录检查过什么，以及为什么没有采用第一个答案 |
| 4. 数据素养（Data Literacy） | 看得懂数据的来源、定义、单位、时间段和完整程度 | 先核对 KPI 的定义，再根据仪表盘下结论 |
| 5. 结果核查（Verification） | 用来源、规则或可以重复的计算来核对答案 | 工作成果里附有检查清单和证据链接 |
| 6. 流程设计（Process Design） | 看清流程的上下游全貌，减少不必要的交接 | 改进前后的工作流对比，并标出审批点 |
| 7. 沟通表达（Communication） | 简明地讲清结论、不确定之处和下一步要做的事 | 不回避风险的管理层摘要 |
| 8. 创造力（Creativity） | 提出多个方案，结合不同领域的知识解决问题 | 经过用户测试的原型，光有想法不算 |
| 9. 数字安全（Digital Safety） | 保护数据、访问权限和知识产权 | 只使用经过批准的工具和数据 |
| 10. 学习敏捷度（Learning Agility） | 做小规模试验、衡量效果，并不断调整工作方法 | 试验记录，包括哪些做法已经放弃 |
这些技能要配套发挥作用。比如有数据素养却缺乏批判性思维，员工可能会相信定义有误的数据；有创造力却不做结果核查，可能会想出有趣却行不通的点子。所以评估时应该用真实任务，让员工同时用上好几项技能。
按角色和职责层级设计学习内容
全公司只开一门课，组织起来容易，见效却难。会计部门要侧重准确性、规则和审计；市场部门要侧重理解客户、宣传说法的证据和品牌调性（Brand Voice）；工厂团队要侧重安全、现场信号，以及把例外情况交给对的人；经理则要看得懂系统、制定 KPI、管理变革。
四个能力等级
- 安全使用者：知道哪些数据可以用，会写基本的任务简报，使用前会先检查输出
- 熟练实践者：为重复性工作准备了模板，会比较输出质量，也能教同事
- 流程设计者：绘制流程图，选择适合自动化的环节，并设计异常队列（Exception Queue）
- 成果负责人：对业务 KPI、风险、预算和标准作业程序（SOP）的修订负责
让学员在培训前先交一份作品，培训后再用同一组数据、同一套评审标准把同样的任务做一遍。衡量整个流程的用时、准确度、修改轮数，以及解释理由的质量。这样就能区分“在课堂上会做”和“在实际工作中会做”。
结业项目（Capstone）示例
客服团队可以搭建一个工作流，用来汇总个案历史、起草回复、推荐帮助文章，同时必须显示信息来源，并把敏感个案交给主管。采购团队可以用 AI 读取供应商报价单里的条款，但用固定规则计算评分，最后由委员会决定。学员要做到出结果更快、错误率又不超过约定的标准才算通过，只演示成功一个个案是不够的。
好的认证标准
- 使用来自真实工作的题目和经过批准的数据
- 包含常规样例、例外情况和高风险个案
- 学员说得清 AI 做了什么、人在哪些环节负责
- 用证据检验结果，不凭感觉
- 交付团队可以继续使用的模板、检查清单或 SOP
营造让技能转化为生产力的环境
员工学得再好，如果没有经过批准的工具、没有时间试验，或者 KPI 仍在奖励旧的做事方式，也改变不了组织。公司得先为这些技能铺好轨道：通俗易懂的数据政策、经过审核的示例库、可以随时来提问的答疑时间（Office Hour）、每条工作流的负责人，以及不会让报告人吃亏的事故（Incident）上报渠道。
写给开发团队 · 技术细节
主管要把问题从“今天用 AI 了吗”换成“哪部分工作变好了，证据是什么，还有哪些风险”。HR 应该把 Capstone 和 Career Path 挂钩，比如 Reviewer、Knowledge Curator、Automation Champion 或 Process Owner。帮助同事把工作做得更好的人应当得到认可，功劳不该全归操作工具最快的人。
一个部门的 90 天计划
| 阶段 | 要做的事 | 交付成果 |
|---|---|---|
| 第 1–30 天 | 做任务盘点（Task Inventory），建立技能基线（Skill Baseline），选出 2 条工作流 | 问题、负责人、数据、护栏（Guardrail） |
| 第 31–60 天 | 按角色培训，并在实际工作中试用 | 模板、检查清单、通过审核的示例 |
| 第 61–90 天 | 对比前后效果，修订 SOP，认证使用者 | 业务成果和扩展计划 |
项目收尾时做三个决定：哪些要扩大，哪些要修正，哪些要停掉。肯放弃不划算的应用场景（Use Case），也是一种组织能力。最终目标是一支交付更快、更准确、能负责任地开创新做法的团队；员工对 AI 能侃侃而谈，从来就不是重点。
FIELD NOTE · 来自一线的视角
值得关注的人，未必是提示词打得最快的那个
观察一下您的团队就会发现，真正用好 AI 的人往往有些共同的习惯：读完任务会反问，看得出哪些信息不太可靠，也不怕说一句“这个问题现在还答不了”。这些特质看起来并不出彩，却能有效挡住代价高昂的错误。说白了，公司需要的是让客户和实际工作得到更好结果的员工，光会把 AI 哄高兴的员工帮不上忙。
使用 AI 输出前的 T.E.S.T. 检查法
- Truth（事实）：这些事实从哪里来？
- Exception（例外）：这个答案在哪些情况下不成立？
- Stake（利害）：如果错了，谁会受损，损失有多大？
- Transfer（传递）：怎样把这个方法记录下来，让别人也能重复使用？
在团队里试试：每周一次，请每个人花 5 分钟讲一份“差点发错”的输出。从及时发现的错误里得到的教训，往往比十条漂亮的提示词更有价值。
从知识到真正能解决问题的系统
问题的根源
技能问题很少出在员工学得不够。多数时候，公司从来没有定义过“进步了”应该体现在哪些工作上。
分步解决方案
- 绘制任务与技能地图（Task & Skill Map），区分 AI 可以帮忙的任务、必须由人检查的任务，以及绝不能交给系统的任务
- 根据公司自己的数据和真实情境，设计岗位学院（Role Academy）和结业项目
- 衡量前后变化，把行之有效的做法变成模板、SOP 和职业发展路径
把人才培养计划变成看得见进展的系统
很多组织已经有不错的课程，缺的是一座把课堂连回实际工作的桥。DNA Maker 会先请 HR、主管和员工围绕同一项工作坐下来聊：用 AI 之前这项工作是怎么做的，时间耗在哪里，哪类错误绝不能接受，什么样的成果才算“真的会做”。我们不会替您决定谁该擅长什么，我们做的是帮组织把自己的知识整理成技能地图（Skill Map）、来自真实情境的练习，以及各方理解一致的审核工作流。这样，人才培养不会以一张证书收尾，员工工作做得更好、知道什么时候该求助，都有证据可查。
在此基础上，DNA Maker 可以开发内部网页或移动应用，把结业项目课程、AI 练习工作区（AI Practice Workspace）、知识库（Knowledge Base）和进度仪表盘集中在一处，按角色设定权限，并把审核通过的工作和团队的模板或 SOP 关联起来。从探索工作坊（Discovery Workshop）、UX/UI、原型、系统架构、AI 智能体（AI Agent），到开发正式系统以及上线后的持续优化，我们都能提供帮助。如果您的组织还拿不准该先从课程还是从软件入手，欢迎来聊，一起找一个“起步任务”：规模小到可以试，分量又重到能让大家都看到价值。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Workflow | 从开始到得出结果的工作步骤，写明谁做什么 | 申请培训 → 完成练习 → 主管审核 → 技能认证 | 哪些步骤应该自动化，哪些环节必须由人决定？ |
| AI Agent | 接收目标、使用数据或工具，分多个步骤把工作做完的 AI 软件 | 智能体读取作业，对照检查清单，再交给审核人 | 智能体使用哪些数据和工具？权限范围到哪里为止？ |
| Role-based Access | 按角色分配权限 | 员工看得到一般课程，HR 才看得到评估结果 | 每类数据分别应该由谁查看、修改、审批或下载？ |
| Knowledge Base | 分门别类、可以检索的知识库 | 把 SOP、工作样例和常见问题集中在一处 | 内容由谁审核？过时的资料怎样下架？ |
| Prototype | 在正式开发之前，用来验证想法的早期模型 | 先在一个部门试用的技能仪表盘页面 | 在投入正式开发之前，我们要从原型中弄清楚什么？ |