| name | ml-feasibility |
| description | 当用户想系统评估一个AI项目是否值得投入时使用，结合概念简单性和数据充足性两个维度。
用户在问"这个想法可行吗"、"我们需要多少数据"、"技术上能做到吗"时激活。
不适用于: 纯数据科学洞察项目、探索性分析、已明确不需要AI的场景。
|
Source Metadata
Original cangjie-skill frontmatter from the distillation run:
name: ml-feasibility
description: |
当用户想系统评估一个AI项目是否值得投入时使用，结合概念简单性和数据充足性两个维度。
用户在问"这个想法可行吗"、"我们需要多少数据"、"技术上能做到吗"时激活。
不适用于: 纯数据科学洞察项目、探索性分析、已明确不需要AI的场景。
source_book: 《给所有人的AI入门课》 吴恩达 (Andrew Ng)
source_chapter: p06, p07
tags: [feasibility, task-evaluation, data-requirements, prioritization]
related_skills:
- slug: ab-mapping
relation: depends-on
- slug: one-second-rule
relation: composes-with
- slug: triple-due-diligence
relation: depends-on
ML可行性双因素 — 简单概念 + 充足数据
R — 原文 (Reading)
"学习简单概念更可能成功...只需不到一秒的思考...其次数据充足更易实现。"
— 吴恩达, p06
I — 方法论骨架 (Interpretation)
机器学习项目的成功取决于两个独立但都必要的因素：
第一，概念简单性——人类能否在不到一秒内做出所需判断？简单概念对应着模式清晰、边界明确的任务，AI 容易学习。
第二，数据充足性——你是否有足够多的已标注 (A, B) 样本？数据是 AI 学习的燃料，再简单的任务没有数据也无法训练。
两个因素构成一个 2×2 矩阵：
- 简单 + 有数据 → 立即推进
- 简单 + 缺数据 → 可以尝试但需要解决数据问题
- 复杂 + 有数据 → 也许能成，但需要更多数据和更长时间
- 复杂 + 缺数据 → 放弃或重新定义问题
这个框架把"AI能不能做"这个模糊问题，拆解成两个可以独立回答的具体问题。
A1 — 书中的应用 (Past Application)
案例 1: 汽车检测（简单 + 大量数据 → 成功）
- 问题: 自动驾驶中检测前方车辆
- 方法论的使用: 概念简单（人类一秒能判断）+ 数据充足（海量标注图像）
- 结论: 双因素都满足，应当推进
- 结果: 成为自动驾驶的核心能力
案例 2: 手势识别（复杂 + 有限数据 → 失败）
- 问题: 通过摄像头识别人类手势含义
- 方法论的使用: 概念复杂（手势含义依赖上下文）+ 数据有限
- 结论: 双因素都不满足，不应推进
- 结果: 在当时确实难以做好
案例 3: 共情式回复（复杂 + 1000样本 → 失败）
- 问题: 自动生成有共情力的客服回复
- 方法论的使用: 概念复杂（需要情感理解）+ 数据量也不足
- 结论: 概念复杂性是主要障碍
- 结果: 即使有数据也难以成功
案例 4: 咖啡杯质检（简单 + 100张图片 → 成功）
- 问题: 检测咖啡杯外观缺陷
- 方法论的使用: 概念简单（一看就知道好坏）+ 数据量不大但够用
- 结论: 简单任务对数据量要求较低
- 结果: 小数据集也能训练出可用的模型
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个 skill?
- 团队提出一个具体的AI项目想法，需要系统评估是否值得投入资源
- 产品经理在多个AI功能排优先级，需要一个评估框架
- 技术负责人在评审AI项目提案，需要判断可行性
- 创业者在验证AI创业方向，需要快速排除不可行选项
语言信号 (用户的话里出现这些就应激活)
- "这个想法可行吗"
- "我们需要多少数据"
- "技术上能做到吗"
- "这个项目值得做吗"
- "AI能做到什么精度"
与相邻 skill 的区分
- 与
one-second-rule 的区别: 一秒法则只评估"概念简单性"这一个因素，双因素框架增加了"数据充足性"维度，是更完整的评估。
- 与
ab-mapping 的区别: A→B 映射是把问题形式化，双因素框架是在形式化之后评估可行性。
- 与
triple-due-diligence 的区别: 三重尽职调查是更深入的全面评估（技术+商业+伦理），双因素框架是快速可行性判断。
E — 可执行步骤 (Execution)
当 skill 被激活后, agent 应按以下步骤执行:
-
评估概念简单性
- 向用户提问："这个任务需要人类做什么判断？有经验的人能在一秒内做出吗？"
- 完成标准: 用户能明确回答"是/否"，或给出人类判断所需时间
- 判停条件: 若用户回答"需要几分钟以上"，标记为"复杂概念"
-
评估数据充足性
- 向用户提问："你手上有多少已标注的 (输入, 输出) 样本？能获取更多吗？"
- 完成标准: 用户能给出数据量级（如"1000条"、"没有"、"可以购买"）
- 判停条件: 若用户完全没有数据且无法获取，标记为"数据不可用"
-
给出 2×2 矩阵定位和行动建议
- 简单 + 有数据 → "建议立即启动项目"
- 简单 + 缺数据 → "建议先解决数据问题（标注、购买、合成）"
- 复杂 + 有数据 → "建议谨慎推进，可能需要更多资源和时间"
- 复杂 + 缺数据 → "建议放弃或重新定义问题"
- 完成标准: 用户得到明确的矩阵定位和下一步行动建议
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- 数据科学项目（目标是洞察而非预测，不需要标注数据）
- 探索性分析（A 和 B 尚未定义）
- 纯技术研究（没有明确的业务应用场景）
- 项目已经决定推进，需要的是执行计划而非可行性评估
作者在书中警告的失败模式
- 高估数据充足性——"我们有数据"不等于"我们有足够的高质量标注数据"
- 低估概念复杂性——有些任务人类觉得简单是因为利用了AI不具备的常识
- 忽略了数据质量问题——有数据但标注不一致，等同于数据不足
作者的盲点 / 时代局限
- "简单"的定义是主观的——不同领域的"简单"标准不同，书中未提供客观判断方法
- 该框架基于监督学习范式，对自监督学习、迁移学习、预训练大模型的数据需求讨论不足
- 书中未讨论"数据获取成本"——有些数据理论上可获得但经济上不可行
- LLM 时代，很多"复杂"任务通过 prompt engineering 变得可行，双因素框架需要更新
容易混淆的邻近方法论
- 与"技术成熟度评估"的区别: 技术成熟度评估更宏观，双因素框架聚焦于ML项目的两个关键变量
- 与"数据审计"的区别: 数据审计只关注数据质量，双因素框架同时考虑概念和数据
相关 skills
- ab-mapping (depends-on): 双因素框架的前提是已经定义了清晰的A和B
- one-second-rule (composes-with): 一秒法则提供"概念简单性"维度的快速评估方法
- triple-due-diligence (depends-on): 双因素通过后,进入三重尽职调查做深度评估
审计信息
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待测试
- 蒸馏时间: 2026-06-29
