AI 编程助手与持续学习能力

• 使用契机的合理性（真实需求驱动而非跟风）
• 第一周感受的诚实表达（效率、局限、适应）
• 是否形成持续使用的理由

我使用 AI 编程助手的契机来自一个具体痛点：一次迭代里我要处理 200 多个字段的 DTO 转换代码，纯手写既慢又容易漏，当时团队里有人推荐了 AI 辅助工具，我就抱着"解决这一个问题"的心态开始试用。第一周的感受很真实地分成两面：惊喜的一面是，重复性的样板代码（DTO 转换、单元测试骨架、配置类）生成速度确实快，我第一周就用它把那 200 个字段的转换代码在一天内完成并人工 review 通过，还让它生成了配套的测试骨架；不适的一面是，它生成的代码"看起来对，但细节要自己把关"——有一次它给我生成的日期格式化逻辑用了错误的时区参数，代码能编译、跑起来也正常，但结果就是错的，是我 review 时发现并修正的。第一周我就建立了两个认知：它擅长的是"有明确模式的工作"，它不擅长的是"理解业务约束"，而识别两者是我的责任。

第一周之后我继续使用的理由也很明确：它不是替代我写代码，而是把"打字时间"换成"思考与审查时间"，让我的精力更多放在设计和验证上。三个月后我统计过，样板类代码的产出效率提升了约 40%，而 review 引入的错误率没有上升。使用 AI 编程助手的正确姿势，是从真实痛点切入、对产出保持审查、并诚实地记录它的边界——工具越用越好的前提，是你始终清楚"它负责生成，你负责正确"。

此题考察 AI 工具的真实使用体验。回答要展示真实契机（重复代码痛点）、第一周的正反两面感受（效率与时区错误案例）和持续使用的理由。核心：诚实呈现边界感，体现"生成+审查"的成熟使用观。

• 数据分级意识（什么可传、什么不可传）
• 具体的安全实践（脱敏、本地模型、审查）
• 安全边界的执行与传播

我在日常工作中对 AI 的使用有一个明确的"数据分级表"：第一级，可输入——公开知识、文档片段、不含业务信息的代码逻辑（去掉变量名和注释里的业务上下文）；第二级，需脱敏——涉及业务数据的代码，我会先做脱敏处理：把真实的表名、字段名、客户 ID、金额替换成通用占位符（"表 A""字段 B"），再让 AI 处理逻辑；第三级，绝不输入——密钥、令牌、生产环境真实数据、客户个人信息、未公开的财务与合规数据，这些内容我永远不粘贴进任何外部 AI 工具，即使是"内部部署"的工具也要先确认数据不出内网。除了输入侧，我还做三个安全动作：第一，选择工具时确认数据政策——公司允许的工具优先，涉及敏感内容的场景选择私有化部署或本地模型；第二，输出侧审查——AI 生成的代码如果涉及访问控制、加密、鉴权逻辑，我会逐行人工审查，且绝不让 AI 直接生成"含真实凭证的配置"；第三，团队同步——我会在团队内分享这份数据分级表和安全注意事项，因为"我不传"不等于"团队都不传"，边界需要是团队的共识。

有一次我需要让 AI 帮忙重构一段涉及订单金额的代码，我先手动把金额字段替换为占位符、把订单号替换为随机编号，重构完成后再替换回来并全量回归，既拿到了效率，又没有把任何真实数据传出去。安全使用 AI 的本质，是"先分级、后使用"——在效率面前先画清楚数据的红线，红线之内尽情用，红线之外坚决不用，这条边界不因为工具再强大而松动。

此题考察 AI 使用的安全意识。回答要展示三级数据分级（可输入/需脱敏/绝不输入）、三个安全动作（工具政策、输出审查、团队传播）和真实脱敏案例。核心：先分级后使用，效率不越红线。

• AI 生成代码的完整流程（拆解、生成、审查、验证）
• 质量保证的具体手段（review、测试、灰度）
• 上线后的结果验证

有一次我要实现"报表导出 CSV 的流式生成"功能（数据量大、需要分页流式写出），这是一个模式成熟的功能，适合用 AI 辅助。我的流程分四步：第一步拆解——我先自己把功能拆成明确的小块（查询分页、流式写入、文件名规则、错误处理），并给 AI 写清楚每块的输入输出和约束，而不是丢一句话让它自由发挥；第二步生成——让 AI 分别生成各块代码，并明确要求"不要省略错误处理分支"；第三步审查——这是最关键的环节，我逐块 review：重点检查了分页游标的边界（AI 第一次生成的版本在最后一批数据不足一页时会重复，我修正了循环条件）、资源释放（流必须关闭）、以及文件名安全（AI 生成的版本没处理非法字符）；第四步验证——补全了单元测试（空数据、超大数据、中断恢复三个场景），并在测试环境跑了一遍 500 万行数据的真实导出验证内存峰值。

上线后该功能稳定运行，导出 500 万行报表内存占用从旧的 2GB 降到 200MB，耗时从 3 分钟降到 40 秒，之后还被其他团队复用。这次经历让我确认了 AI 生成代码的正确姿势：AI 负责"写"，我负责"拆、审、验"——拆解越清楚、审查越严格、验证越全面，AI 的产出就越可靠。成功上线的关键不是"AI 生成了能编译的代码"，而是"我确认了它在边界条件下的正确性"。

此题考察 AI 辅助开发的完整闭环。回答要展示"拆解—生成—审查—验证"四步和具体的 bug 案例（分页边界、文件安全）。核心：AI 写、人拆审验，质量靠人的审查与测试兜底。

• 各工作流的适用场景与价值判断
• 使用频次与效果的真实分布
• 每个工作流的使用技巧

我常用四个工作流，按使用频率排序：第一是"理解"——这是我最常用的：接手陌生代码时，让 AI 帮我梳理模块职责、调用链、数据流，它能在几分钟内给我一个"带标注的结构概览"，我再带着问题看源码验证；这个工作流省掉的是我最贵的成本（读代码的时间），而且不容易出错（理解结果我可以对照源码核实）。第二是"样板"——生成 DTO、配置、测试骨架这类模式化代码，效率最高，但样板代码我也会 review，因为它最容易在"业务常量"上出错。第三是"测试"——让 AI 根据函数签名和已知边界生成测试用例，我补充业务场景的用例；它擅长"覆盖分支"但经常漏"业务语义"的用例（比如金额为负、时区边界），所以我只把它的产出当草稿。第四是"重构"——用得最少也最谨慎：让 AI 做"小步重构"（提取函数、改命名、消除重复），每次重构后必须跑全量测试，且一次只做一类变换；大重构（改架构）我坚持人主导，AI 只做机械部分。

这四者的价值排序和我的使用频率一致：理解省时间（最值钱）、样板省体力（次之）、测试补覆盖（辅助）、重构慎使用（风险最高）。我的使用原则是"按风险配审查强度"：理解类风险低（对照源码即验）、样板类中风险（抽查常量）、测试类中风险（补充语义）、重构类高风险（全量测试兜底）。把工作流和审查强度对应起来，AI 才能成为可靠的协作者而不是隐患的制造者。

此题考察 AI 工作流的成熟运用。回答要展示四个工作流的使用频率排序和各自技巧，并建立"风险—审查强度"对应关系。核心：不同工作流配不同审查强度。

• 风险识别的方法论（边界、安全、上下文）
• 具体的检查清单与手段
• 识别案例的呈现

识别 AI 代码的错误与安全风险，我有一套"五查清单"：第一查，边界条件——AI 最容易在边界上出错：循环边界、空值、空集合、超长输入、并发场景，我逐项过一遍"如果数据是空/极限/异常会怎样"；第二查，资源与副作用——资源释放（流、连接、锁）、幂等性、超时与重试、状态修改是否可预期，AI 生成的代码经常"主流程正确、清理动作缺失"；第三查，安全项——注入（SQL、命令）、鉴权与越权、敏感信息泄露（它可能把测试密钥写进配置）、加密算法选择，安全相关代码我逐行看；第四查，上下文一致性——AI 看不到全貌：它生成的代码可能与现有代码风格、依赖版本、业务常量不一致（比如硬编码一个看似正确实则错误的业务阈值），我重点核对"它假设的东西是否真实存在"；第五查，性能隐含——AI 喜欢写"直观但低效"的代码（循环里查库、全量拷贝），大数据的场景我会检查复杂度与资源消耗。

有一次 AI 帮我生成一个导出功能，我按清单第二查发现它生成的代码里文件流没有在 finally 中关闭（资源泄漏），按第三查发现它把数据库密码从配置里硬编码进了代码（安全风险），两个问题都在上线前被拦下。如果当时只验证"能跑通"，这两个问题会埋到生产环境。识别 AI 风险的本质，是"按固定清单审查，而不是通读全文找感觉"——清单保证覆盖，逐项验证保证不遗漏；AI 的确定性错误可以用测试发现，但这些"看起来对"的隐患只能靠人的审查清单拦截。

此题考察 AI 代码的审查方法论。回答要展示"五查清单"（边界、资源、安全、上下文、性能）和具体拦截案例。核心：用固定清单逐项审查，拦截"看起来对"的隐患。

• 对 AI 幻觉的诚实描述（不掩饰）
• 浪费时间的归因（信任过度、验证不足）
• 应对机制的建立

有一次我让 AI 帮我查一个框架的 API 用法，它给出了一个"官方推荐写法"，看起来非常权威——带完整参数、有示例、语气笃定。我按它的写法实现后，运行时报错，我以为是自己的问题，又花了一个多小时排查参数、看日志、改写法，最后去查官方文档才发现：那个 API 在这个版本里根本不存在，是 AI 编造的（它把另一个库的类似 API 缝合了过来）。那一整个上午，表面上是"AI 在帮我"，实际上是我在为它的幻觉买单。

我的应对分两步：第一步止损——确认是幻觉后，我没有继续信任它，而是改用官方文档为准，把这个问题写完；第二步立规矩——从那以后我给自己定了三条：第一，"事实类问题查文档，不给 AI 下结论权"——API 是否存在、版本行为、配置项，以官方文档和源码为准，AI 的回答只当线索；第二，"生成代码必验证"——AI 给的代码，不管语气多笃定，都要先想"它假设的 API 是否真实存在"，存疑就查；第三，"幻觉复盘"——我把这次经历和识别技巧（AI 自信的语气不等于准确、编造的 API 常有"看似合理但查无实据"的特点）整理进团队分享。这次浪费时间的价值，是让我建立了"AI 是建议者、文档是裁判"的认知——省下的时间是我后来无数次"少走弯路"换来的。

此题考察对 AI 幻觉的应对成熟度。回答要诚实描述幻觉事件与时间成本、归因信任过度，并展示三条应对规则。核心：事实类问题以文档为裁判，AI 只当建议者。

• 降低 AI 使用门槛的方法（模板、规范、演示）
• 保护"不用 AI"的成员（不强制、给替代）
• 团队协作中的产出标准统一

让不熟悉 AI 的成员参与协作，我的原则是"AI 是选项，不是门槛"：团队协作的产出标准（代码质量、测试覆盖、文档）不因是否用 AI 而改变，用不用 AI 由个人选择，不会用的人用传统方式同样可以协作。在这个原则下我做三件事：第一，提供"低门槛入口"——我整理了一份"AI 使用速查"：包括我们允许使用的工具列表、三条安全红线、5 个常用 prompt 模板（解释代码、生成测试、重构建议），成员照着模板就能上手，不需要先学提示词工程；第二，示范与结对——每周我在例会用 10 分钟演示一个"AI 帮我解决实际问题"的案例（带着真实代码，展示从提问到验证的完整过程），并鼓励不用 AI 的成员坐在旁边看、随时提问；对于想尝试但不敢用的成员，我安排结对：AI 出初稿，两人一起 review，让"审查 AI 代码"成为团队共享的技能；第三，统一产出审查——不管谁用什么方式产出，合入代码库前都过统一的 review 标准，AI 生成的代码也不例外，这保证了"用 AI 的人"和"不用 AI 的人"产出的质量基线一致。

有一次一位老同事明确表示不用 AI，我没有劝说他，而是确保他参与的模块 review 标准不变、他的节奏不受影响；同时他的 PR 里 AI 生成的代码（他同事辅助的部分）也按同样标准被审查。团队协作的本质是"产出对齐"而不是"工具对齐"——AI 只是工具的一种，让不熟悉的人不被排斥的关键，是给低门槛入口、给示范、给替代路径，并把质量标准立在工具之上。

此题考察 AI 时代的团队协作包容性。回答要展示"AI 是选项不是门槛"原则和三个动作（速查模板、示范结对、统一审查）。核心：质量标准立在工具之上，工具选择保持包容。

• 对 AI 在重构/审查中优势的具体认知
• 对局限的诚实评估
• 人机协作的分工设计

有一次我做一次大模块的重构（把 800 行的单体函数拆成职责清晰的多个模块），让 AI 全程参与，我对它的优势和局限有了清晰的体感。优势有三个：一是"机械拆分快"——它快速完成了函数提取、重复代码归并这类结构性工作，省了我大概两天的手工时间；二是"一致性检查好"——它能把散落各处的相似代码（比如 5 处几乎一样的日期处理）一次性找出来，我原来靠眼找容易漏；三是"模式识别强"——它能识别出我代码里隐藏的坏味道（过长参数列表、全局状态），给我一份"重构建议清单"，相当于一次免费的静态分析。局限也有三个：一是"不理解业务意图"——它拆出的模块命名和边界，业务语义常常不对，我需要逐个调整；二是"看不见全局"——它建议的拆分方案没有考虑调用方的上下文和性能约束，有一处它建议"把 X 逻辑内联"，实际上那处是刻意延迟计算的，我否掉了；三是"过度自信"——它对我质疑的回应经常是"你说得对，但我的方案在大多数情况下更好"，需要我坚持判断。

我的扬长避短方式是"机械交给它、决策留给我"：它做拆分、归并、列举，我做命名、边界、性能与业务语义的决策；重构的每一步（它改一段、我审一段）跑全量测试，绝不让它一口气改完再验收。重构完成后的 Code Review 我也让 AI 先做一轮"初筛"（找重复、找坏味道、找明显 bug），我再做"终审"（业务正确性、安全、性能）。AI 在重构与审查中是优秀的"执行助手"和"初筛器"，但"判断"这个环节永远是人类工程师的职责——扬长避短的核心，就是明确"谁做机械、谁做判断"。

此题考察 AI 辅助重构的实战认知。回答要列举优势（拆分快、一致性、模式识别）与局限（业务语义、全局观、过度自信）各三条，并展示分工设计。核心：机械交给 AI，决策留给人类。

• AI 辅助学习的具体用法（解释、答疑、练习）
• 对 AI 学习辅助局限的认知（验证、深度）
• 学习效果的验证

有一次我需要学习"gRPC 的流式通信"，这是一块完全陌生的领域。我用 AI 辅助学习的角色定位是"三层助教"：第一层，概念解释——让 AI 用比喻和分层的方式讲清核心概念（"流式 RPC 是服务端和客户端之间的长连接管道，像打电话而不是寄信"），并对我不懂的术语（拦截器、负载均衡策略）做即时追问式解释，比翻文档快很多；第二层，路径设计——让 AI 给我列学习路径和常见误区（"新手最容易搞错的是阻塞/非阻塞模式""注意 protobuf 版本兼容"），相当于一个有经验的学长给提纲；第三层，陪练——让它出练习题（"给我设计一个聊天服务的 proto 定义，包含双向流"），我写完后它帮我 review 并指出问题。但我也清楚它的边界：概念解释可能有错（有一次它把"流式"和"批量"的区别讲模糊了）、它的练习题难度偏浅，所以我配了两条验证线：官方文档交叉验证概念、最小 demo 验证理解——每个概念我都用"讲给 AI 听、让它挑错"的方式自测（它挑不出错，说明我讲清楚了）。

学完后我用"能教人"的标准自测：给团队做了一个 20 分钟分享，现场回答了 3 个追问。AI 在学习中的最佳角色是"高响应、低权威的助教"——它随时在、耐心够、能陪练，但结论必须经过文档和代码的验证；用它加速输入，用验证保证质量，学习效率和深度可以兼得。

此题考察 AI 辅助学习的方法。回答要展示三层用法（解释、路径、陪练）和验证线（文档交叉验证、讲给 AI 听自测）。核心：AI 是高响应低权威的助教，结论需验证。

• 三环节的精力分配比例与理由
• 各环节的关键动作
• 分配原则在不同任务上的应用

我的精力分配原则是"三三制偏审查"：生成占约 30%、审查占约 40%、验证占约 30%。为什么审查占比最高：因为生成环节 AI 已经帮我省了打字时间，省下来的时间必须花在"确认它没错"上，审查是投入产出比最高的环节。具体到各环节的动作：生成环节——我花精力在"把需求讲清楚"：写清输入输出、约束、边界和"不要做什么"（比如"不要省略错误处理""不要改变既有接口签名"），描述越精确，生成质量越高，这个环节的投入能显著降低后两环节的工作量；审查环节——用固定清单逐项过（边界、资源、安全、上下文、性能），这个环节不看"通读全文找感觉"，而是"按清单逐项验证"；验证环节——跑测试、跑真实场景验证，能自动化的验证用自动化（测试、静态检查、lint），把人的精力留给"业务正确性"这类自动化覆盖不到的验证。

有一次生成一个"批量导入"功能，我按这个分配执行：生成花 20 分钟写清需求（包括"每行失败要记录原因、不能中断"的约束）、审查花了 40 分钟按清单逐项过（发现它没处理"空行"和"重复行"两个边界）、验证花了 30 分钟补测试和跑真实文件验证。最终上线后这个功能一次通过，零返工。三环节分配的底层逻辑是：AI 越强大，人的"确认责任"越重——生成环节把需求说清，审查环节按清单拦截，验证环节用事实收尾，三个环节各司其职，AI 的输出才能从"看起来能用"变成"确实能用"。

此题考察 AI 使用的精力管理。回答要展示三环节分配比例（30/40/30）与理由、各环节关键动作和真实案例。核心：省下的生成时间必须投给审查，确认责任不外包。

• 对"AI 依赖导致退步"风险的认知
• 防退步的具体方法（基本功保留、理解优先、主动练习）
• 风险与效率的平衡

我认为长期无意识地使用 AI 确实存在退步风险，机制很清楚：如果"直接接受生成结果"成为习惯，人的"从零实现"能力和"深理解"会被替代掉——就像长期用导航会弱化认路能力。我避免退步的方法有四条：第一，"理解优先于接受"——AI 给的代码，我必须先看懂再合入，看不懂的先让它解释、查文档、自己重写一遍；我给自己立了规矩"合入代码必须能讲清每一行的作用"，讲不清的重新学；第二，"基本功保留区"——有些事我坚持不用 AI：算法与数据结构的核心练习（保持解题能力）、系统设计（保持架构思考）、以及新学技术的第一遍上手（保证真的理解而非背答案）；第三，"定期无 AI 练习"——每周安排一段"无 AI 时段"纯手写代码（比如写一个小工具或算法），像健身一样保持"肌肉记忆"，防止手生；第四，"深度任务主导"——复杂调试、性能优化、架构设计这类高价值任务，我自己主导、AI 只做辅助（帮我查资料、整理日志），确保我的能力峰值一直由自己驱动。

有一次我连续三周大量使用 AI 生成样板代码后，发现我自己手写 DTO 和基础查询变慢变生疏了，这让我警觉，随即恢复了"无 AI 时段"和"理解优先"两条纪律，两周后手感恢复。平衡效率与能力的要点是：让 AI 做"重复与模式化"、让自己做"理解与判断"——AI 替我节省的是劳动，不是思考；只要"理解优先"和"基本功保留区"两条红线不破，用 AI 越久，效率越高，能力不退。

此题考察 AI 使用与能力保持的平衡。回答要展示防退步的四条方法（理解优先、基本功保留区、无 AI 练习、深度任务主导）和真实警觉案例。核心：AI 省劳动不省思考，红线是不让理解被替代。

• 分享意愿与动机（团队效率、能力共建）
• 分享内容的设计（案例、安全、边界）
• 分享后的跟进

会，而且我会定期做。动机很简单：AI 工具的能力提升是全团队的，但使用水平的差距也是全团队的——如果只有少数人会用得好，团队的整体效率就被短板卡住；而安全红线如果只有少数人知道，团队的风险就是敞口的。所以分享既是效率投资，也是风险治理。我的分享设计分三层：第一层，案例驱动——每次分享只讲 1-2 个"真实工作里的实战案例"，从问题出发演示完整流程（怎么描述需求、怎么审查、怎么验证），不用 PPT 讲概念，案例比方法论传播快；第二层，安全与边界——每次分享固定包含"安全红线 + 幻觉案例"两个板块：红线（什么数据不能传）和幻觉（AI 自信地回答错过的真实经历），让团队对"AI 会犯错"保持肌肉记忆；第三层，沉淀与更新——分享材料沉淀为团队文档（常用 prompt 模板、审查清单、安全手册），并且我会关注工具更新，每季度把新功能、新风险追加进下一期分享。

有一次分享后，一位同事反馈"原来可以这样让 AI 解释老代码"，他后来用它快速接手了一个陌生模块；另一位同事说"看了幻觉案例才知道要查文档"，避免了潜在的时间浪费。分享的长期效果是：团队里 AI 使用水平整体抬升，低水平的重复提问变少，安全事件为零。主动做分享的本质，是把"我的工具能力"转化为"团队的工具能力"——一个人的效率是线性的，一群人的效率才是复利的。

此题考察 AI 知识的团队扩散意识。回答要展示分享动机（效率+风险）、三层设计（案例、安全边界、沉淀更新）和实际效果。核心：把个人工具能力转化为团队复利。

• 验证方法独立于工具的设计（标准、流程、兜底）
• 责任边界不随工具转移的认知
• 具体执行与团队落实

建立与工具无关的验证与责任边界，我的做法是"把标准立在工具之上"：第一，验证标准工具无关——团队的交付标准（代码 review、测试覆盖、上线检查单、回滚预案）不因为"这代码是 AI 写的"或"是人写的"有任何区别：一样的 review 流程、一样的测试要求、一样的安全审查；工具只是写法变了，验收标准不变。第二，验证手段工具无关——我不依赖"AI 自己说没问题"作为验证依据，验证靠的是独立的客观手段：测试是否通过、静态检查是否干净、线上指标是否正常、灰度是否平稳——这些证据不来自任何工具的自评。第三，责任边界工具无关——这是我最重要的原则："最终责任永远在人"：代码合入者的名字是我、上线确认者的名字是我，AI 没有签名权，也没有背锅权——如果 AI 生成的代码出了问题，责任是"我审查没拦住"，而不是"AI 生成错了"；这条边界我对自己、对团队都讲得很清楚。

有一次一个 AI 生成的配置改动上线后引发小故障，复盘时有人提出"这是 AI 建议的"，我当场否定了这个归因方向：决策链上签名的人是我们，AI 只是建议来源，责任边界在"谁确认、谁合入、谁上线"——这个边界不因为工具变化而移动。落实上，我在团队规范里写明"AI 产出视为普通初稿，走同样验证与责任流程"，并写进新成员 onboarding 材料。验证与责任的本质，是"让标准和责任锚定在人身上，而不是工具身上"——工具会迭代、会升级、会出错，但验收标准和署名责任是稳定的，这两样稳住了，用什么工具都安心。

此题考察 AI 时代的工程责任观。回答要展示三层"工具无关"设计（标准、验证手段、责任边界）和责任归因案例。核心：标准和责任锚定在人，不随工具移动。

• 对"会问不会做"陷阱的认知
• 实践与复述的具体方法
• 学习效果的验证

"会问不会做"的陷阱我很警惕：AI 的即时回答会让你产生"我懂了"的错觉——问什么答什么，就像背了答案却不会做题。我的破解方法是"三不"：第一，不把 AI 的回答当终点——AI 解释完一个概念后，我不直接进入下一个问题，而是合上对话，用自己的话把刚才的内容写下来或说出来（复述），复述卡壳的地方就是没懂的地方，重新去问"刚才我理解的 XX 对吗"；第二，不跳过实践——每学一个概念，必须动手验证：让 AI 解释"连接池"后，我去写一段代码真的创建连接池并观察连接数与重试行为；实践是唯一能戳破"感觉懂了"的方法；第三，不依赖 AI 出题——让 AI 给我练习题可以，但我还会用"讲给 AI 听"的方式自测：把概念用自己的话讲给 AI，让它挑错——它挑不出错，说明我真懂了（它挑出的错，就是我理解的漏洞）。

有一次我用 AI 学"缓存一致性"策略，AI 把 Cache Aside、Write Through 讲得头头是道，我听完也觉得懂了。但当我尝试复述"什么时候该用 Cache Aside、它的一致性窗口在哪"时，发现我说不清楚，于是重新带着问题去验证，并写了一个小 demo 模拟缓存与数据库不一致的场景，亲眼看到不一致窗口后，才真正理解了每种策略的取舍。避免"会问不会做"的关键，是把 AI 定位成"陪练"而不是"答案机"——它的每次回答后面都必须接我的动作：复述验证理解、实践验证掌握、讲解验证深度，三步缺一，问得再多也是"看起来很努力"。

此题考察 AI 辅助学习的深度保持。回答要展示"三不"方法（复述、实践、讲给 AI 听）和缓存一致性的自测案例。核心：AI 每次回答后必须接复述与实践，防"感觉懂了"。

• 判断维度的建立（能力保值、风险、学习价值）
• 分类的具体标准与例子
• 判断随阶段变化的动态性

我的判断标准是三个维度：第一，能力保值——这项基本功是否决定我的长期市场价值？决定长期价值的基础能力（算法与数据结构、系统设计、问题分解、代码审查判断力）必须脱离 AI 手练，因为它们是"不可替代的底座"；只影响短期产出的技能（特定框架的样板写法、配置文件格式）可以交给 AI。第二，风险敞口——手练不足会不会在关键时刻害了自己？排查线上问题的能力、手写关键算法的能力、读懂复杂代码的能力，这些在"AI 不可用"或"AI 不可靠"的场景（面试、故障、离线环境）会直接暴露，必须手练；低风险场景（日常样板）放心交。第三，学习价值——练习它能不能让我理解本质？写一遍排序算法能让我理解复杂度，理解本质的能力可以迁移到所有问题；而"记住某个框架的 API 细节"没有本质学习价值，交给 AI 毫无损失。我的落点是一句话：凡是"练了能长本事"的必须手练，凡是"问了能省时间"的可以交付——中间地带（比如新学一个框架）先手练一遍入门，再交给 AI 提速。

具体到我的实践：算法题、系统设计、代码审查这三块我坚持自己练（每周固定时间，不用 AI 代做）；而 DTO 转换、测试骨架、配置生成、文档初稿这些明确交给 AI。同时这个边界是动态的：某项能力我还没掌握时先手练（比如刚学一个新语言），掌握到能独立交付后再交给 AI。判断"哪些必须手练"的本质，是问自己"这项能力废了，我的价值还剩多少"——AI 能替你干活，但替不了你成长。

此题考察 AI 使用中的能力投资判断。回答要展示三维判断（能力保值、风险敞口、学习价值）和动态边界。核心：练了长本事的手练，问了省时间的交付，边界随掌握度移动。

• 评估维度的完整性（效果、成本、安全）
• 各维度的具体评估方法与证据
• 评估后的决策流程

团队引入 AI 工具前，我的评估用"三本账"：第一本，效果账——用真实的团队任务做试点评估：选 3-5 个代表性任务（一个样板类、一个理解类、一个调试类），让工具在受控环境下跑，对比"用与不用"的时间和产出质量，效果不只看"快了百分之多少"，还要看"质量有没有隐性下降"（比如生成的代码 review 时间变长、bug 率变化）；没有试点数据的"感觉很好用"不作数。第二本，成本账——算总成本：订阅费用、接入改造的人天、团队学习成本（培训与适应期效率损失）、以及隐性成本（如果工具断供或换工具，迁移成本多大），成本账要和效果账放一起算 ROI，不是"有效果就上"。第三本，安全账——这是底线：数据政策（输入的数据去哪、是否出内网、是否用于模型训练）、权限模型（工具能读到我们代码库的什么范围）、合规性（公司行业是否允许、有没有审批要求）、以及供应链风险（工具厂商的资质与稳定性）；安全账不过，前两本账再漂亮也不上。

有一次团队想引入一款新的代码补全工具，我按三本账评估：效果账试点显示样板类任务快 30%，但理解类任务质量与现用工具相当；成本账显示订阅费虽低，但需要全量 IDE 迁移（约 3 人天）且团队刚适应现用工具；安全账发现该工具默认把代码上传到境外服务器，与公司数据政策冲突。结论是不引入，并把这个结论及理由完整记录，供将来工具更新后重新评估。工具选型的本质，是"效果、成本、安全三本账都要过"——效果决定值不值得，成本决定划不划算，安全决定能不能用；三账缺一，选型就是赌博。

此题考察 AI 工具的选型评估框架。回答要展示三本账（效果试点、成本 ROI、安全底线）和完整决策案例。核心：效果、成本、安全三账齐过才上，安全不过一票否决。

• 手写场景的明确分类与理由
• 各类场景下的具体实践
• 边界判断的动态性

我选择手写而非 AI 生成的场景有四类：第一类，性能敏感——AI 擅长"直观写法"，但直观写法常常不是最优写法：热路径上的代码（每秒执行数万次的循环、核心算法）、对内存与延迟有硬约束的代码，我坚持手写并亲手做性能验证，因为性能优化依赖对数据特征和硬件行为的深入理解，这是 AI 的盲区；第二类，安全关键——鉴权、加密、密钥管理、支付与资金逻辑、防注入处理，这些代码我全部手写并逐行审查，安全代码的每个分支都需要"我能完全负责"的理解，AI 生成的安全性依赖它的训练数据，我无法为我看不透的代码背书；第三类，学习目的——学习新技术的第一遍、算法与数据结构的练习、设计模式的刻意练习，我坚持手写，因为学习的目的是"长在自己的能力上"，AI 代写等于替我做作业；第四类，架构决策与复杂重构——涉及系统边界、模块划分、数据流的改动，我手写主导、AI 只做辅助，因为这类改动的好坏取决于对全局的理解。

有一次一个支付校验逻辑，AI 生成的版本逻辑上正确，但我发现它在字符串比较时没有做长度检查（潜在 DoS 向量），我选择手写并补充了输入长度限制和规范化处理。手写与 AI 的边界判断，核心是问两个问题：第一，"这行代码出错，代价多大？"——代价大的（性能、安全、资金）手写；第二，"写这遍代码，我能否成长？"——能成长的手写。边界之外（样板、查询、文档、配置）放心交给 AI。判断的本质是"责任与成长的优先级"：AI 可以替我写代码，但不能替我负责任，也不能替我成长。

此题考察 AI 使用边界的判断。回答要展示四类手写场景（性能、安全、学习、架构）及各自理由，并用支付校验案例演示。核心：代价大与能成长的手写，其余交给 AI。

• AI 加速学习的具体用法（源码导读、总结、练习）
• 防止"流于表面"的验证机制
• 学习深度的保持

我用 AI 加速三个学习环节，每个环节都配"防表面化"机制。阅读源码环节：让 AI 做"导读"——先让它梳理一个模块的调用链、核心类关系、数据流，给我一份结构图；但导读只是地图，我拿到地图后必须自己"走一遍"：挑一条关键路径，从入口跟到出口，对照源码验证 AI 导读里每个论断（它有时会把两个相似类搞混），并在源码里做批注。写总结环节：我写完笔记后让 AI 做"查漏"——把笔记给它，让它指出"没讲清的部分、遗漏的重要概念、表述不准确的地方"，但 AI 的补充我逐条核实后才吸收；我从不直接让 AI 替我写总结，因为总结的写作过程本身就是理解过程。做练习环节：让 AI 出题后，我坚持"先手做、再看答案"：练习必须自己写完再让 AI 点评，点评里的"正确解法"我还要求它讲清"为什么"，讲不清的我去查文档——AI 的答案不是终点，理解才是。

有一次读一个开源框架的调度模块，AI 的导读把任务队列的关系画得很清楚，但我顺着源码走时发现它把"延迟队列"和"优先队列"的用途讲反了，我修正了导读并加深了自己的理解——如果直接采信导读，我的理解就是错的。防止学习流于表面的关键是"三步验证"：AI 给的东西，我先质疑、再核实、后使用——导读要对照源码、总结要逐条核实、练习要先做后评；AI 让学习变快，但"快"必须建立在"准"之上，否则只是把错误加速。

此题考察 AI 增强学习的方法与深度保障。回答要展示三个环节的用法与防表面化机制（对照源码、逐条核实、先做后评）。核心：AI 给的是地图，自己走一遍才算懂。

• 数据输入边界的界定维度（敏感性、用途、范围）
• 脱敏的具体操作标准
• 边界执行的自觉性

我的界定标准分"三个层级、两条铁律"：三个层级——第一层"直接可输"：公开信息（框架文档、公开 API）、不含业务上下文的通用代码片段（去掉了真实业务变量名和注释）；第二层"脱敏后输入"：涉及业务逻辑的代码与数据，输入前做脱敏：表名换成"表A"、字段名泛化（"用户姓名"→"用户标识字段"）、金额与 ID 用随机数替换、注释里删掉业务专有名词，脱敏的原则是"保留问题结构、去掉可识别信息"——AI 需要理解的是逻辑结构，不是真实数据；第三层"绝不输入"：密钥与令牌、生产数据、客户个人信息（姓名、手机号、身份证）、未公开的财务与合规数据、以及公司明确标注 confidential 的任何内容。两条铁律——第一，"默认不可输"：拿不准的数据一律先按不可输处理，先脱敏再问"能不能输"；第二，"工具要确认"：即使是公司允许的 AI 工具，也要确认数据的流向（是否出内网、是否用于训练），公司允许工具不等于允许所有数据。

有一次我需要让 AI 优化一段订单查询代码，输入前我做了三件事：把订单表名改为"table_orders"、把金额字段改为"amount_field"、把注释里的业务活动名删除，AI 优化的逻辑照样准确，而真实数据一点没出。界定输入边界的本质，是"用最小的数据换最大的效果"——AI 理解逻辑不需要知道你是谁，脱敏不是降低效率，而是让效率与安全兼得的必要步骤；这条边界不需要公司盯着，应该是每个使用者的自觉。

此题考察 AI 使用的数据合规意识。回答要展示三级输入边界（直接可输/脱敏后输/绝不输入）和两条铁律（默认不可输、确认工具流向），并用真实脱敏案例演示。核心：用最小数据换最大效果，脱敏是自觉。

• 效率量化的方法（对照实验、时间记录、任务类型）
• 质量监控的指标（review 时间、bug 率、返工率）
• 量化结论对使用策略的反哺

量化 AI 效率提升，我用"对照法"而不是"感觉法"：第一，同类任务对照——选两类可对比的任务（比如 DTO 转换类、接口联调类），记录"用 AI 前"和"用 AI 后"的完成时间，取多次平均值对比，排除单次波动；第二，任务类型分层——分开统计不同类型的效率变化：样板类（通常提升 30%-50%）、理解类（提升 10%-20%）、调试类（提升不稳定甚至为零），分层统计才能知道 AI 真正强在哪，而不是一个笼统的"提升了 40%"；第三，时间日志——连续记录两周的实际工作日志，对比"写代码时间 vs 审查时间"的构成变化，看 AI 是不是把"写的时间"变成了"审的时间"（这是健康的变化）还是"总时间没变但质量下降"（这是危险的信号）。

确认质量没有隐性下降，我盯三个指标：第一，review 发现的问题率——AI 介入后，代码 review 里发现的问题数量有没有上升（上升说明 AI 在埋雷）；第二，线上缺陷率与返工率——上线后的 bug 数、需求返工次数对比基线；第三，测试覆盖率——AI 生成代码的测试覆盖有没有达标。这三个指标我每季度统计一次。有一次统计发现样板类任务效率提升 40%，但 review 问题率上升了 15%——我分析原因是 prompt 描述不够精确导致 AI 生成质量波动，于是优化了 prompt 模板（写清边界和约束），两个季度后 review 问题率回到基线。量化 AI 效果的要点，是"效率和质量分开看"——效率看对照数据，质量看缺陷指标，两边都盯住，才能确定 AI 是真的在帮你，而不是在悄悄地透支质量。

此题考察 AI 效果的量化评估。回答要展示对照法效率量化（分层统计、时间日志）和质量三维监控（review 问题率、缺陷率、覆盖率）及反哺调整。核心：效率与质量分开量化，用数据验证而不是感觉。

• 对 AI 时代核心竞争力变化的洞察
• 个人构建策略的具体性
• 洞察与行动的一致性

我认为 AI 时代工程师的核心竞争力是三个"不可外包"的能力：第一，问题定义与分解能力——AI 擅长"把明确的问题做出来"，但"什么是真正该解决的问题、怎么把它分解成 AI 能执行的步骤"仍然只能人来完成；能把模糊的业务诉求拆成清晰的技术问题，是最高杠杆的能力。第二，判断与责任能力——AI 给出方案后，判断"这个方案对不对、值不值、有没有风险"并为此负责，这是 AI 无法让渡的能力；判断力建立在深度理解之上，深度理解只能自己构建。第三，跨域整合与信任能力——把技术、业务、组织连接起来的能力（理解业务目标、推动跨团队协作、建立信任），AI 再强也替代不了人与人之间的协作与信任。写代码本身正在变成"可外包"的部分，而这三项能力是"不可外包"的底座。

我持续构建的策略有四条：第一，刻意练习问题分解——每个需求先自己写"问题定义文档"（目标、约束、分解、验收），AI 只做执行部分，保持拆解手感；第二，保持深度理解——坚持阅读源码与核心文档、保留"无 AI 手练"时段，让判断力有知识底座；第三，扩大业务与组织视野——参与业务讨论、主动承担跨团队协作，让自己从"代码工程师"成长为客户与业务的连接者；第四，验证与复盘——定期回顾"哪些工作 AI 做得比我好、哪些仍然只有我能做"，把精力持续投向后者。AI 时代的竞争力，不是"用 AI 用得比人好"，而是"把 AI 替代不了的部分做得比谁都好"——工具会变，底座能力不会变，持续构建底座，才是穿越技术周期的答案。

此题考察 AI 时代的职业认知。回答要展示三大核心竞争力（问题定义、判断责任、跨域信任）和四条构建策略。核心：AI 外包执行，人守住定义、判断与连接，底座能力是穿越周期的答案。