一、核心认知：AI 是什么，不是什么
LLM 的本质：不是"会思考的工程师"，而是基于海量语料训练的概率模型，每次输出都是在预测"最可能出现的下一个 token"。它具备一定的逻辑推演能力，但这不等于它真正"理解"了你的需求。
由此带来的三个核心局限：
二、协作总纲：把 AI 当作"需要被管理的高级实习生"
一句话核心理念：
AI 是一个能力极强但完全不了解你项目、会犯低级错误的高级实习生。你的角色从"写代码的人"变成了"管理写代码的人"。
这意味着你需要做三件事：
- 给足上下文——结构化表达需求
- 拆好任务——由粗到细，分步验证
- 守住底线——步步验证，精准纠错
三、输入：结构化表达需求
不是"告诉 AI 越多越好"，而是"告诉 AI 越结构化越好"。
一次完整的需求描述应包含：
1. 业务场景：什么用户在什么情况下使用
2. 技术约束：使用的框架、语言版本、架构模式（MVVM / MVP）
3. 输入输出：参数类型、返回值格式、数据流向
4. 边界条件：空数据、网络异常、超时、权限不足
5. 非功能性约束：性能要求、安全要求、兼容性要求
6. 参考示例：已有的类似代码或期望的输出风格
上下文位置策略：最重要的约束放在消息的最前面或最后面（首因/近因效应），不要埋在中间段落里。
三种协作模式的输入侧重点不同：
生成模式：输入精确的规格说明，像写技术方案一样
探索模式：输入问题和约束，让 AI 列出方案，你来做决策
诊断模式：输入操作手顺 + 预期行为 + 实际行为 + 错误堆栈
四、拆解：由粗到细，先定接口再写实现
核心原则：不要让 AI 一次写一个完整模块，让它一次写一个可验证的单元。
以"充电模块"为例：
第一层（粗）：搭骨架
→ 定义模块的目录结构、类的关系图、数据流向
→ 确认后进入下一层
第二层（细）：逐个实现
→ 电流子模块 → 编译 → 验证 → 锁定
→ 电压子模块 → 编译 → 验证 → 锁定
→ 充电曲线子模块 → 编译 → 验证 → 锁定
第三层（联调）：集成测试
→ 所有子模块联调，验证数据流转正确
为什么要"先定接口再写实现"：让 AI 先输出数据结构和接口定义，你确认无误后，再让它填充实现。这样避免了"写完了发现方向不对"的返工。
五、验证：AI 的输出不是终点，是起点
核心原则：默认不信任 AI 写的任何代码。
具体操作链：
AI 生成代码
↓
人工 Review：理解逻辑、检查边界、确认 API 存在
↓
编译运行：立即编译，不是攒一批再编译
↓
单元测试：针对边界条件写 case，不是只跑 happy path
↓
锁定：确认无误后，提交代码，告知 AI "此模块已锁定，不要改动"
精准纠错的三要素（发现 Bug 时告诉 AI）
1. 操作手顺：我做了什么操作
2. 预期 vs 实际：我期望看到 X，但实际看到了 Y+ 报错堆栈
3. 推测原因：我怀疑是 Z 的问题（可选，但能加速定位）
迭代纪律：
每次只改一件事，明确说"这次只优化 A，B 和 C 不要动"
第一版追求"能跑通"，后续再优化性能、可读性、错误处理
任何已确认的模块，显式告知 AI 锁定，防止"顺手"修改
六、面试收尾：AI 这么强，还要程序员干什么？
数据层面：AI 诞生以来，程序员数量不降反增。因为信息化加深，软件开发的总需求在膨胀，AI 填补的是增量，不是替代存量。
本质层面：LLM 的本质是概率预测，不是真正的理解。AI 幻觉、私有知识盲区、上下文局限这三个问题，在可预见的未来不会消失。
角色转变：程序员的核心价值从"写代码"变成了"管理代码质量"——
AI 降低了写代码的门槛，但提高了写对代码的门槛。因为验证别人写的代码，比验证自己写的代码更难——你需要更深刻地理解业务逻辑、更系统地设计测试用例、更敏锐地识别潜在风险。
你的价值：拆解复杂需求的能力、架构设计的能力、验证和纠错的能力、对业务的理解深度——这些都不会被 AI 替代，反而因为 AI 的存在变得更加稀缺。
□ 1. 拆解任务：从粗到细，每个子任务可独立验证
□ 2. 结构化输入：业务场景 + 技术约束 + 输入输出 + 边界 + 非功能约束
□ 3. 上下文管理：关键约束置顶/置底，无关话题开新对话
□ 4. 先定接口：让 AI 输出数据结构/接口定义，确认后再实现
□ 5. 局部 Review：理解逻辑，检查边界，确认 API 存在
□ 6. 小步验证：生成即编译，编译即测试
□ 7. 精准纠错：操作手顺 + 预期 vs 实际 + 推测原因
□ 8. 锁定模块：确认无误后提交并告知 AI 锁定
□ 9. 联调测试：全部模块集成后跑完整用例
□ 10. 利用工具：报错堆栈直接贴，让 AI 自己读代码库
