AI 参与说明（Agent：Codex；模型：
gpt-6-astra；reasoning effort：medium；执行入口：Codex Desktop；Codex CLI 版本：0.153.4；提供方：OpenAI）：本文由 Codex 根据 AI 辅助学习研究和工程实践问题整理，资料核验于 2026-09-07。学习与职业建议是可尝试的方法，不是长期效果或就业竞争力的保证；本文不记录个人处境。
AI 可以替人生成代码，但作品完成、能力增长和创造乐趣是三个不同的结果。三者需要各自的证据，不能用“项目做完了”同时证明。
本文讨论如何安排日常开发，让 AI 提高交付效率，同时保留值得练习的能力与自己认可的乐趣。一个可尝试的原则是：把大部分实现交给 AI，同时保留少量由自己提出预测、设计反例、观察结果和修正解释的任务。
研究能支持什么，不能支持什么#
2026 年一项关于学习新编程库的随机实验发现，AI 辅助组即时测验平均得分为 50%，非 AI 组为 67%，相差 17 个百分点；任务完成速度的组间差异没有达到统计显著。研究招募 52 名主要为初级的软件工程师，任务围绕陌生的 Python 异步库。测验包括调试、代码阅读与概念理解。Anthropic 研究说明、原论文
作者对交互方式的后续分析发现，追问概念与核对理解的参与者表现较好，但这一分组不是随机分配，不能据此宣称某种提示词已被证明有效。该实验考察短任务后的即时表现，不能推导资深工程师的多年能力变化，也不能直接推导完整 Coding Agent 工作流的效果。
它支持一个有限结论：当前任务完成和当前知识掌握应分别检查。既不支持“AI 必然让人退化”，也不支持“只要看过解释就学会了”。
如何让 AI 提高产出，同时留下自己的能力#
为同一项目选择不同参与方式#
| 任务 | AI 的主要职责 | 人保留的动作 |
|---|---|---|
| 已熟悉、低风险的实现 | 编码、转换、补齐重复内容 | 定义验收条件，检查变化是否影响既有行为 |
| 高频使用但机制陌生的部分 | 查资料、提出实验、实现对照版本 | 先预测结果，再观察和解释差异 |
| 高后果且难验证的边界 | 汇总证据、构造反例、协助测试 | 确认业务不变量；必要时引入专家或成熟服务，而非假装已具备能力 |
| 暂时只需知道存在的主题 | 提供可靠索引和来源 | 知道何时值得再查，不强求记忆全部细节 |
知识深浅不应仅按“做／查”二分。同一个接口的语法可以查询，它的失败语义可能需要记住。
把“判断力”变成能观察的动作#
每次选一个重要改动，只练习一条完整链路。例如给一个任务管理界面增加“提交中”状态：
- 定义必须成立的性质。 请求尚未结束时，界面必须给出一致的反馈。
- 先提出自己的预测。 “提交按钮禁用后，用户就能理解当前状态。”
- 让 AI 提出对照条件。 网络耗时从 100 毫秒变为 10 秒，随后返回错误。
- 观察实际使用。 使用者是否知道正在等待，失败后能否恢复，输入是否仍保留。
- 修正解释，再换一个条件。 增加明确反馈后，继续检查键盘提交、重复点击和重试；不要把一个用例通过等同于完整证明。
这可以让 AI 编写全部实验代码，但预测和解释必须来自学习者。没有猜对并不表示失败；能够定位自己哪一步想错，才形成了新的能力证据。
可以使用这样的任务说明：
这项任务同时用于交付和学习。实现由你完成。到涉及状态、错误恢复或其他关键机制的决策时，先给我一个具体问题，让我预测结果，再用最小实验核对。请分别说明产品完成了什么、哪些性质有证据、哪些边界仍未验证。不要用长文或口头测验替代真实结果。
保留多少手写代码#
没有必要规定统一比例，也没有理由把手写完全取消。需要练习时，亲自写一个小实现、修改一个真实缺陷、构造一个失败输入，往往比旁观大型成品更容易暴露理解缺口。
选择标准是：这段练习会不会提高下一次类似任务中的预测、诊断或修改能力。机械抄写大量熟悉代码的回报可能很低；第一次独立写通一个状态机可能回报很高。基础学习也不必等到线上事故才补：反复需要的概念可以安排短小、系统的练习。
收获感可以有不同来源#
不要只用生成代码量、文档数、工具数量或聊天时长衡量进展。也不要把一切乐趣都强迫转换成职业回报。若编程过程本身有趣，保留一段自己写代码的时间就是合理目标。
如果目标是持续进步，可以每周各记一条不同证据：
- 成果证据：某个真实使用者完成了一件以前做不到或做起来更费力的事；自用工具也可以是本人实际完成任务。
- 能力证据：上周预测错的一类情况，本周能解释并处理新的变体。
- 复用证据：一个实验、诊断方法或决策记录在第二个任务中减少了试错。
这些指标不要求每天都满足。它们的价值在于让“我学到了什么”落到可观察变化，而不依赖模型对自己的评价。
竞争力应在一个具体场景里比较#
不能从当前模型表现推导“哪些能力永远不会被替代”。判断力、品味和需求描述也可能被自动化，换一组抽象名词并不能解决未来的不确定性。
更务实的问题是：在一个自己长期接触的领域，使用同样 AI 工具时，为什么自己仍能更快确认问题、更少返工、更可靠地交付？ 可能来自领域经验、真实反馈、理解约束、验证能力，以及持续维护系统的记录；这些都需要实际成果证明。
可以选择一个持续使用的项目，在两周内完成一次小而完整的改进：提出目标、做出变化、观察使用、复查失败、保留结论。每周只挑一个高价值机制亲自验证，其余实现尽量委托。两周后检查真实结果和相邻问题的处理能力，再决定继续或调整。这是一个可修改的实验周期，不是已证实的最优时间分配。
若一项活动既不推动成果，也没有预期的能力迁移，更不带来自己认可的乐趣，就值得暂停。追工具、补目录、优化 Agent 规则只有在解决反复出现的阻碍时才值得持续投入；但探索本身也可以被有意识地选择，不必因为短期没有收入而否定。
相关阅读#
- 理解债：AI 辅助个人知识库的收益、代价与边界：讨论外部知识与个人掌握程度的边界。
- Matt Pocock Skills：从需求澄清到工程交付的 Agent 工作流：将需求、验证和交付组织为可执行流程。