文章目录
前言
第二周的内容和第一周相比，视角发生了重要变化。第一周主要是搞清楚AI"是什么"和"能做什么"，这一周则转向了AI项目如何落地 以及非技术角色（包括管理者）如何与AI团队协作。对于一个长期搞后端的人来说，这部分相当于AI领域的"项目管理"和"跨团队沟通"。
课程中大量讨论了机器学习项目和数据科学项目的区别、如何选择AI项目、如何与AI团队设定合理的预期，以及AI对各行各业岗位的影响。
下面是我的学习笔记。
本章小结
- 机器学习项目 vs 数据科学项目：ML项目的输出是一个能持续运行的系统；数据科学项目的输出是一套洞察和行动建议（通常是报告或PPT）
- AI项目选择的三个原则：自动化任务而非工作岗位、关注业务痛点、数据量不必太大即可启动
- 与AI团队合作时：明确统计学验收标准、理解数据划分（训练集/测试集）、不要期望100%准确率
- 数据偏见是一个严肃的工程问题：训练数据中的偏差会直接传导到模型输出，可能引发法律和道德风险
- 技术栈概览：主流框架（PyTorch、TensorFlow）、GPU算力、云/边缘/本地三种部署模式，这些都与后端开发有高度的衔接空间
个人感悟
1. 关于AI图片识别项目的亲身经验
之前参与过AI图片识别的项目，实现上以JNI方式调用深度学习内容。整个流程和吴恩达课程中描述的高度一致：数据采集（包括人工标注样本、数据清洗）→ 模型训练（包括使用验证集数据验证模型效果）→ 模型部署使用 → 持续迭代。亲身经历让我深刻感受到，很多行业确实已经在被AI深刻影响。与其被动焦虑，不如主动迎接变化，把手弄脏去实践。
2. 关于"AI能写代码"的反思
作为一个写了多年Java的老程序员，最初听到"AI能自动生成代码"时，确实有过一丝危机感。但实际操作后发现，AI生成的代码往往需要人工审查边界条件、处理异常、优化性能。它更像一个"超级补全工具"，而不是一个"替代者"。真正的价值依然在于你能否设计出合理的架构、写出清晰的注释、判断AI生成的方案是否适合当前业务场景。这些能力，AI暂时还学不会。
3. 关于跨团队协作的共鸣
课程中提到的"与AI团队设定明确验收标准（如95%准确率）"让我联想到日常开发中的接口定义和SLA约定。无论是AI项目还是传统项目，模糊的需求永远是最大的坑。如果产品经理说"尽量准一点"，算法工程师就永远不知道什么时候算达标。这个经验不仅适用于AI团队，也适用于任何技术团队之间的协作------量化是消除分歧的最有效武器。
1. 机器学习项目工作流程
吴恩达用一个循环结构概括了ML项目的基本步骤：
- 收集数据：收集包含输入A和期望输出B的数据。这个阶段的目标是获得足够数量的标注数据供模型学习。
- 训练模型：使用机器学习算法学习从A到B的映射关系。通常需要多次迭代来微调模型，调整参数直到效果满意。
- 部署模型：将训练好的模型投入实际应用场景（如智能音箱、自动驾驶汽车），并在部署后持续收集反馈数据，不断更新模型。
关键洞察：这是一个迭代闭环，而不是一次性的"交付即止"。数据质量和模型准确性会随着系统的实际运行逐步优化，这也是ML项目与传统软件开发的一个重要区别。
2. 数据科学项目工作流程
数据科学和机器学习经常被混为一谈，但吴恩达明确指出二者在输出形式上存在本质区别：
- ML项目：输出一个可以持续运行的系统（例如垃圾邮件过滤器、推荐引擎）。
- 数据科学项目：输出一套可执行的洞察和行动建议，通常以报告或PPT形式辅助商业决策。
数据科学项目的工作流程如下：
- 收集数据：收集与分析目标相关的各类数据。
- 迭代分析：通过多次分析迭代，对影响业务的因素提出假设并验证。
- 输出建议：将洞察转化为具体的行动建议（如"将产品A的价格降低10%以提升销量"）。
- 持续反馈：在建议落地后，继续收集新数据并定期复盘，形成优化闭环。
打一个后端程序员好理解的比方：ML项目是写了一个长期运行的微服务，数据科学项目是给业务方出了一份《MySQL慢查询优化建议报告》。前者运行系统，后者辅助决策。
3. AI对各行业的影响
吴恩达用大量例子说明了不同工作职能如何被AI重塑。以下是课程中提到的几个典型场景：
| 职能领域 | AI应用方式 | 实际价值 |
|---|---|---|
| 销售 | 自动化潜在客户价值排序 | 销售人员将精力集中在高质量线索上 |
| 制造业 | 自动化视觉检测（检测划痕、凹痕） | 提高质检效率，降低人工成本 |
| 人力资源 | 自动化简历初步筛选 | 加速招聘流程（但需关注公平性问题） |
| 市场营销 | 个性化产品推荐 | 显著提高转化率和销售额 |
| 农业 | 精准定位喷洒除草剂 | 减少农药使用量，降低成本 |
这个表格更多是从AI赋能业务的角度说明行业影响，和第一周讲AI对程序员职业的影响是两个不同视角------前者是AI能做哪些事，后者是作为程序员要如何应对。
4. 如何选择合适的AI项目
选择AI项目的时候，吴恩达给出的核心思路是：找到技术上可行、同时业务上有价值的交集。
项目筛选原则
- 自动化任务，而非工作岗位：思考哪些重复性任务可以被自动化，而不是思考"这个岗位能不能被AI取代"。岗位往往包含多个任务，AI只擅长其中一部分。
- 关注业务痛点：业务价值的主要驱动因素和业务中的主要痛点，是最值得用AI解决的场景。
- 数据量不是必须很大：即使没有海量数据，用少量数据集（比如100张或1000张图片）也通常可以启动一个机器学习项目，不必等数据完美再开始。
尽职调查三方面
在正式启动一个AI项目之前，吴恩达建议从三个维度做尽职调查：
- 技术尽职调查：确保项目可行。评估性能目标、数据需求和工程时间线。一个典型的验收标准可能是"95%的准确率"。
- 商业尽职调查：确保项目有价值。量化评估预期收益------降低成本或增加收入，算清楚投入产出比。
- 道德尽职调查：确保项目对社会有益。如果某个AI项目可能危害他人或社会，即使技术上可行、商业上有利可图，也不应该做。
此外还有一个自建与采购的决策原则：不要自己去造那些即将成为行业标准的东西------如果某项技术未来会成为公共服务或通用基础设施（例如云端GPU算力），直接购买成熟方案比自研更划算。
5. 如何与AI团队高效协作
这一节对管理者（以及需要跟AI团队打交道的开发人员）很有用。核心要点包括：
- 明确验收标准：不能用模糊的表述（如"尽量准确"），而应该指定统计学方式规定的可衡量标准，例如"95%的准确率"。
- 数据划分：AI团队会将数据划分为训练集（供模型学习）和测试集（用于评估模型的泛化性能）。这是保证模型可靠性的基础实践。
- 现实期望：避免要求AI软件达到100%的准确率。由于数据本身存在噪声、技术存在固有局限性等因素，AI系统通常无法做到绝对完美，但即使准确率只有90%，也可能已经创造了巨大的业务价值。
这让我想起日常的开发工作------一个有技术债务的系统，只要核心功能稳定可用，总比没有系统强。AI项目也是同理：90分的模型已经能创造90分的价值，不必等100分才上线。
6. AI偏见：一个必须正视的问题
AI系统可能在其输出或决策中表现出不公正、歧视性或系统性错误，这种错误往往反映了训练数据或算法设计中的偏差，而不是AI"有意识"地在歧视。
典型的例子：招聘AI系统因训练数据中男性程序员占比过高，自动降低了女性简历的评分权重，最终引发了法律纠纷。
偏见的根源通常是数据本身------如果训练数据中一个群体占比过高，模型就会学到这种偏差。这和第一周提到的"垃圾进，垃圾出"是同一个道理。即使数据本身没有歧视意图，互联网上爬取的数据中已经天然包含了大量性别刻板印象和种族偏见。
减少或消除偏见的措施包括：使用更具包容性的数据，以及在AI系统中应用技术手段来降低偏见程度。
对于后端开发者来说，这个问题并不遥远：如果公司要在简历筛选系统里引入AI，那么你会负责对接哪个数据源？那个数据源本身是否有偏差？这些都是交付前必须审视的问题。AI偏见不是道德课上的抽象讨论，而是一旦上线就可能导致法律风险和品牌危机的工程问题。
7. AI团队的技术工具（可选内容）
课程最后介绍了一些常用技术栈，这里简要列出：
开源框架：PyTorch、TensorFlow、HuggingFace等，目前已成为AI开发的标配工具箱。
硬件：CPU适合通用计算，GPU（图形处理单元）尤其适用于训练大型神经网络------这是深度学习的性能核心。
部署模式：
- 云部署：租用云服务商的GPU服务器，即用即付，适合大部分场景。
- 边缘部署（端侧部署）：模型直接运行在手机、物联网设备等端侧设备上，对延迟和网络依赖要求高，适合实时性要求强的场景。
- 本地部署：模型部署在企业自有的本地服务器或私有数据中心内，数据不出内网，适合金融、医疗等对数据安全性和合规性有严格要求的行业。本地部署需要自行采购和维护GPU服务器，前期投入较高，但长期来看可规避云服务的带宽和调用费用。
作为后端开发者，未来可能需要：
- 封装模型为REST API或gRPC服务供其他系统调用（推理场景）
- 根据业务量评估所需的GPU算力（上线前的容量规划）
- 排查推理结果的异常，协调算法团队调整模型版本（问题排查）
这部分和当前的后端技能有很高的重合度------无论是服务化的思维方式，还是性能容量规划的经验，都能直接复用。