Q3-03 · 职业发展与工程协作 / 工具与效率
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能列出热管理工程师日常工作里 AI 辅助价值最高的具体场景（脚本调试/文档润色/资料检索/会议纪要）
- 能设计一套“AI 输出必须人工复核”的工作习惯，尤其是涉及数值计算与标准引用
- 能判断哪些数据/内容绝不能贴进公开 AI 工具（客户资料/未公开专利/保密图纸）
- 能写出让 AI 输出更可用的工程提问方式（给约束条件、要求给出依据、要求指出不确定处）
- 能识别 AI 输出里最容易让工程师“信错”的两类错误：编造的精确数字和编造的引用来源
内容大纲
- AI 能帮热管理工程师做什么，不能做什么
- 定位：AI 是“更快的初稿生成器+更耐心的对话式检索”，不是“会算物理的工程师”
- 与 J7-05 代理模型、N6-03 企业级大模型应用的区别：本课讲个人日常工作用法，不讲建模/建系统
- AI 擅长语言重写、代码调试、结构化整理；不擅长精确数值计算、未见过的最新标准细节
- “AI 说的”和“AI 查到的”要分清：检索增强（RAG）把“凭记忆编”变成“有据可查”，但只是把核验对象从结论换成了出处——出处存不存在、是不是现行版本、是否真的支持该结论，仍要逐条核对；RAG 最典型的失效正是带着一个真实但已过时或不相关的出处自信作答
- 脚本与代码调试场景
- 用 AI 辅助写 Python 数据处理脚本初稿（衔接 Q3-01），但公式/单位换算必须自己核对
- 报错信息丢给 AI 能大幅缩短调试时间，尤其是环境/库版本类问题
- 让 AI“解释这段代码在干什么”比“帮我写”更适合用来学习，不要形成依赖
- 反面例子：让 AI 直接给出 COP 计算结果而不给公式，数字对不对没法验证
- 文档、报告与检索场景
- 用 AI 润色技术文档/试验报告的表达（衔接 Q2-03），内容与结论工程师自己把关
- 用 AI 做会议纪要摘要与行动项提取，原始记录仍要保留备查
- 标准/文献检索：AI 能帮你缩小查找范围，但标准编号/条款号必须去官方源头核对
- 反面例子：AI 一本正经编出一个不存在的国标编号——这是最容易被工程师直接采信的错误类型
- 提问方式与输出核验
- 给约束条件而不是给模糊问题：说清工况/边界/单位，输出才有工程价值
- 要求 AI 标注“哪些是确定的、哪些是它的推测”，逼它暴露不确定性
- 关键数值类输出的核验流程：独立算一遍或查权威源头，不能“AI 说的就当结论”
- 多轮追问代替一次性长 prompt，复杂工程问题拆步骤问
- 给约束前先自查是否互相冲突：把互斥的要求同时提出来，模型不会报错，只会挑一部分满足；工程问题应先问“这些约束有没有互相矛盾、哪条最先被牺牲”，再让它作答
- 边界、合规与团队协作
- 数据红线：客户资料/未公开专利/保密图纸绝不贴进公开 AI 工具
- 企业内部部署与公开互联网 AI 工具的边界要分清，不能默认公开工具“够安全”
- 个人使用习惯与团队/组织级 AI 工具治理的分层（衔接 N6-03 的企业 RAG/治理视角）
- 不用 AI 不等于严谨，滥用 AI 也不等于高效——建立自己的“AI 能不能用在这一步”判断力
- 同一条“什么内容不能外发”的判据在三个场景通用——贴进公开 AI 工具（本课）、写进简历/作品集/公开演讲（见 Q1-04 的对外展示脱敏判据）、离职时带走（见 Q3-02 的个人侧边界）；本课只讲 AI 工具这一个场景，别误以为红线只在用 AI 时才存在
关键公式
工程可信度 = 独立验证覆盖率 × 结果一致性
一个 AI 辅助产出的工程结论能不能用，取决于有多少比例的关键数字被独立验证过、验证结果是否吻合，而不是“读起来通顺”
净收益 = 节省时间 − 核验时间 − 返工风险成本
只算 AI 帮你省了多少写作/调试时间是不够的，必须扣掉核验成本，否则可能是“看着快、实际慢”
幻觉概率 ∝ 问题冷门程度 × 缺乏检索来源
越是小众的标准编号/型号参数/低频知识点，大模型编造的概率越高，这类问题必须优先走权威源头而非 AI 记忆；注意有检索来源只降低“凭空编造”的风险，不降低“引错、引旧”的风险
prompt 有效性 = 关键约束覆盖度 × 输出格式明确度（且约束互不冲突）
决定输出可用度的是工况、边界、单位、输出结构这四类关键约束是否齐全，不是条数堆得多——覆盖齐之后再加条数收益饱和；且这些约束必须彼此不冲突，模糊提问只会换来模糊答案
关键概念
检索增强生成 RAGAI 幻觉提示词工程 prompt独立验证数据红线保密数据边界结果核验流程代码调试辅助会议纪要摘要标准检索生成式 AI 与检索式工具不确定性标注
推荐工具与标准
通用大模型对话工具（ChatGPT/Claude/文心一言/通义千问等） GitHub Copilot（代码辅助） 本站 AI 助手（规划中功能，上线前以通用大模型工具替代） 官方标准检索平台（用于核验标准编号，而非替代 AI 记忆）
《生成式人工智能服务管理暂行办法》（国内 AI 合规监管，工程师应知红线） 个人信息与数据安全相关标准（如 GB/T 35273 个人信息安全规范） 企业内部数据分级分类制度（体系名，各企业自定，非统一国标）
工程案例
某仿真工程师用 AI 辅助写电池热管理台架脚本，顺口问了句国标限值，AI 给出一个看似精确的编号和数值——查证后发现编号根本不存在；同一天他用 AI 缩小了三份英文论文里的相关段落范围，大幅缩短文献调研时间。同一个工具，两种可信度。
动手做
交付物 · ①挑一段技术文档或试验报告，用 AI 改写压缩篇幅，标出哪些结论性数字需重新核验；②用 AI 辅助调试一段之前卡住的 Python 脚本，记录修复是否一次成功；③写一条“什么数据绝不能贴给公开 AI 工具”的自查清单，至少 3 条。
常见误区
- 把 AI 给的精确数字（标准限值/物性参数/编号）直接写进正式文档，没有去源头核验——这是本课最该记住的一条
- 把客户资料、未公开专利图纸、保密测试数据贴进公开 AI 工具当上下文，触碰数据红线且很可能已经造成信息泄露
- 用一次性长 prompt 让 AI“设计一套完整的电池热管理方案”，指望它替代系统工程思考，结果是一堆正确的废话
- 对 AI 输出无差别信任或无差别怀疑，两个极端都不对，应按“数值类严格核验、语言类工程师把关、结构化整理类可放心用”分层对待
- 把用 AI 等同于偷懒、降低专业性的对立面看待，拒绝使用反而在效率上掉队
- 把约束往 prompt 里越堆越多就以为输出必然更好——约束一旦互相冲突或超出可行域，模型的典型行为是只满足其中一部分、悄悄丢掉其余，且不会声明自己放弃了哪条，比约束不足更难发现；正确做法是先要求它指出冲突再作答
相关课题