能做完，不等于做对：AI 时代的专业门槛
过去，一个没有专业背景的人想独立完成一个 App、一套系统或一份专业文档，几乎寸步难行——难在“做不完”：既没有执行能力，也没有判断标准。今天，AI 把执行能力近乎免费地交到每个人手上，作品可以完整地做出来。但“做完”和“做对”是两回事：完成了任务，不等于判断了任务的对错。
这篇文章想讨论的正是这个错位：AI 让专业工作变得容易完成，而专业的价值，已经转移到了判断环节。
一、从 Prompt 到 Skill：不是更长，而是不同
先厘清一对常被混淆的概念。
Prompt 是单次对话里的临时指令：角色、要求、格式、示例都写在当前输入里，只在本轮生效，说完即失效。Skill 是结构化、可持久、可被 Agent 按需调度的任务包：触发条件、分步 SOP、子提示词、工具清单、校验规则、异常分支、版本信息，可以跨会话反复调用。
一句话：Prompt = 每次开工前口头交代新人的任务，下次还要再说一遍；Skill = 归档的标准化作业手册，自带步骤、工具和验收标准。
从 Prompt Engineering 到 GPTs 再到 Skill Engineering，本质是能力的载体从“每次重说”变成了“归档复用”。但关键不在这个演进本身，而在它的结果：Skill 接管了“怎么做”，却没有接管“该不该做、放在系统的哪里”。它只定义一类任务的内部流程，对自己在全局中的位置毫无感知；提示词退化成需求入参，判断没有跟着一起被封装。
二、能做完，不等于做对
AI 抹平了执行门槛。零基础的人也能产出完整的应用、规范的论文、成套的方案，执行能力第一次变得廉价而充裕。
但这制造了普遍的能力幻觉：产出看起来专业，不代表产出是专业的。分水岭藏在看不见的地方——架构是否清晰、选型是否合理、有没有重复建设和隐性技术债。这些判断过去只有有经验的人才能做出；今天，AI 把“做”交给了缺少经验的人，却没有补偿“判断”。
AI 降低了“做完”的成本，却没有降低“做对”的门槛。
三、五个绕不开的问题
1. Skill 孤岛：单点规范，全局失约
单个 Skill 输出稳定、规范，但多个 Skill 之间没有统一契约：建表 Skill、接口 Skill、页面 Skill 各自定义同名字段、不同枚举、不一样的错误码，互相不知情。粒度怎么拆、内部预设了什么（默认框架、默认数据库）、版本怎么管理，都是架构判断——Skill 自己给不出答案。
2. AI 没有全局架构视图，只会局部最优
模型没有持久化的项目状态，上下文是有损的滑动窗口：它分不清哪些是不可修改的架构约束，哪些只是临时细节，压缩时约束最先丢失。每个任务单独生成“能跑”的实现再拼接，重复实现、技术债、面条代码随之累积。
3. AI 只给可行解，不给权衡
工程选择几乎全是取舍：性能与速度、自研与复用、灵活与稳定。AI 倾向交付单点“能跑”的方案，不主动权衡利弊；并发、限流、安全、合规这些没被说出口的非功能约束，默认忽略。再加上手写偏好强、不主动检索项目已有资产，重复造轮子几乎不可避免。
4. 问题定义：AI 擅长解题，不擅长质疑目标
“我要一个导出功能”，AI 立刻写代码；有经验的工程师会先反问：是不是流程本身不合理？目标有偏差时，AI + Skill 会把错误方案高速落地——做得快，但方向错了。
5. 结果验收：自检等于盲区自证
让同一个模型自查产出，共享的是同一套盲区。AI 说“测试通过”，使用者无法核验；幻觉依赖（不存在的包、虚假接口）混进来也无从发现。执行交给 AI，验收既不能交给 AI，使用者又无力承担——责任真空。
四、把判断力工程化：五层 AI 工程治理体系
执行能力可以外包，判断不能。解法是把零散的人工判断，前置固化为项目层面的刚性约束，用制度替代个人经验。
- 第一层：项目目标（Goal）——锁定核心目标、业务边界与可量化验收标准，避免 AI 盲目执行错误需求。
- 第二层：资源与工具（Resources & Tools）——划定依赖白名单：固定可用 SDK 与开源库，禁止 AI 私自新增依赖、手写底层能力，把选型判断前置锁死。
- 第三层：工程架构（Architecture）——整套体系的核心红线：分层、模块边界、数据流、接口定义、公共抽象、跨模块契约。架构文档独立于所有 Skill，是硬性约束，同时它也是 Skill 之间的粘合剂，从根上解决孤岛问题。
- 第四层：专业工作流（Skills）——只负责执行：编码规范、操作流程、最佳实践。Skill 无权改动架构、新增依赖、修改契约，严格服从上层约束。一句话定位：架构是宪法，Skill 是作业规范。
- 第五层：结果验收（Validation）——不能依靠 AI 自述，必须外化校验：架构合规、依赖白名单、代码重复度、跨 Skill 一致性、安全与质量审查。
五、一个完整的工程闭环
flowchart TB
A["第一层：项目目标
Goal
需求 · 范围 · 约束 · 验收标准"]
B["第二层：资源与工具
Resources & Tools
SDK · 依赖白名单 · 文档 · 源码"]
C["第三层：工程架构
Architecture
系统设计 · 模块边界 · 接口 · 跨 Skill 契约"]
D["第四层：专业工作流
Skills
领域知识 · 编码规范 · 执行流程 · 单点 SOP"]
E["第五层：结果验收
Validation
测试 · 架构检查 · 依赖校验 · 幻觉排查 · 一致性检查"]
A --> B
B --> C
C --> D
D --> E
E -. "反向迭代优化上层约束" .-> A
E -. "更新依赖清单" .-> B
E -. "修正架构缺陷、调整契约" .-> C
E -. "优化 Skill 内部流程" .-> D
style A fill:#2563eb,color:#fff,stroke:#2563eb
style B fill:#0d9488,color:#fff,stroke:#0d9488
style C fill:#7c3aed,color:#fff,stroke:#7c3aed
style D fill:#d97706,color:#fff,stroke:#d97706
style E fill:#475569,color:#fff,stroke:#475569
五层形成闭环：先定目标、锁定资源、搭建架构（含跨 Skill 契约），再用 Skill 执行，最后用标准化校验守住质量；验收发现的问题，反向优化前面四层的约束。这不是死板的瀑布流程——资源会反过来影响架构，架构也会更新资源清单——五层是权责划分，把零散的专业判断固化成可执行、可迭代的规范。
六、跨领域通用，以及最后的分界线
这套框架离开代码开发同样成立：
| 层次 | 软件开发 | 学术研究 | 产品设计 |
|---|---|---|---|
| 项目目标 | 产品需求与业务边界 | 研究课题与研究范围 | 产品定位与核心指标 |
| 资源与工具 | 依赖白名单、SDK、开发文档 | 文献数据集、实验工具 | 元器件、设计素材、供应链资源 |
| 工程架构 | 系统分层、模块边界、跨 Skill 契约 | 研究框架、技术路线 | 产品整体结构、软硬件方案 |
| 专业工作流 | Skill 编码流程、开发规范 | 实验步骤、研究方法论 | 设计流程、工艺规范 |
| 结果验收 | 功能测试、架构校验、依赖排查、一致性检查 | 实验验证、成果同行评审 | 原型测试、可靠性检验 |
所有专业领域的瓶颈高度一致：AI 能快速产出初稿，但缺少全局判断。把判断前置为五层约束，是普适解法——即使用 AI 写论文、做方案，同样会遇到多个 Skill 各自产出、互相打架的孤岛问题。
AI 把专业门槛拆成了两段：能不能做完、能不能做对。 过去两段重合，不会做就不会判断；AI 抹平执行之后，“做对”成为新的分水岭——作品可以完整呈现，但架构隐患、重复建设、幻觉依赖肉眼不可见。
更值得警惕的是自动化悖论：长期把执行和思考全部交给 AI，人跳过了“设计→出错→重构→理解”的试错闭环，判断力持续钝化——越依赖，越不会判断；越不会判断，越依赖。
未来真正稀缺的竞争力，不是 Prompt 技巧或 Skill 编写，而是把经验沉淀为顶层约束、协调多个 Skill 形成一致系统的判断力。
AI 时代，执行能力越来越廉价；把判断力工程化的能力，才是真正的稀缺资源。
