Theo 谈 AI 编程、认知债务与如何保持技能

AI 编程工具已经成为现实，我也很喜欢用它们。但我发现自己亲手写的代码越来越少：编辑器里常常是提示词和智能体运行数据。我学到了 Git 和远程系统等新技能，一些旧技能却感觉生疏了。结果不对时，我很容易想再拉一次老虎机，而不是弄清原因。

Lars Faye 的文章《Agentic Coding is a Trap》把这种问题称为认知债务。技术债务是个有意思的对照：智能体也能帮助清理它。在 Twitch，一次 GraphQL 迁移曾让大约 8,000 个 TypeScript 文件报错，工程师用表格分配修复工作。AI 能显著降低这种重复性迁移的成本。

过去的迁移消耗了大量工程时间，因为同一类机械改动必须应用到数千个文件。维护成本过高时，这类工作往往会积累下来。智能体可以改变这项工作的成本结构，但生成的改动仍需验证。

Faye 质疑一种观念：开发者只需写好计划、委托实现，再从高处指挥智能体。反复生成代码可能拉大负责人与提交代码之间的距离。他列出的代价包括系统复杂性、技能退化、供应商依赖和支出不确定性。

我同意其中很多观点，但要区分单个 token 的价格和完成特定任务的成本。即使相近水平的模型性能变便宜，团队使用更多 token 后仍可能花更多钱。账单上涨和单次任务成本下降可以同时发生。

我当时查看的基准图表显示，GPT-5.5 medium 与 GPT-5.4 xhigh 得分相近，而运行该基准的显示成本分别约为 1,200 美元和 2,850 美元。这只是特定基准及其成本计算的时间快照，不能证明两者在所有实际任务中等效，也不是当前报价。

我还指出，GPT-5.5 low 的基准成本约为 500 美元，Sonnet 4.6 max 在相近分数下约为 4,200 美元。这个对比说明的是特定基准水平上的成本，不代表所有应用的成本都会普遍下降八倍。随着使用量增长，公司的 AI 总支出仍可能大幅上升。

假设一家公司去年为编程工具支付了 10 万美元，今年才过去几个月就已经花了 50 万美元。即使相近模型工作的单位成本下降，账单上涨仍是真实的预算问题。

Faye 认为，监督数千行生成代码需要批判性思维和架构知识，而如果人们不再练习，这些能力本身也可能受损。认知债务指的是系统与团队对其运作方式和原因的理解之间的差距。这类报告值得重视，但仅凭个案无法确定它有多普遍。

我多年来也经历过类似情况：快速做出一个项目，离开一个月后再回来，已经记不清细节。在使用 AI 之前，我每年通过大幅缩小范围、做成后马上转向下一件事来交付多个项目。AI 让更多人能以类似速度推进。

我早期的方法是缩小项目范围，直到能交付可用的东西。我创建 T3 技术栈，部分原因就是希望使用熟悉的组件，更快、更有把握地构建产品。快速推进并不意味着离开项目后还能记住每个决定。

区别在于，我曾努力理解那些基础构件。即使忘记某个项目的具体组合方式，我也能根据对构件的了解推断可能的故障。如果 AI 削弱了学习这些东西的直接动力，开发者就可能做出更多软件，却没有获得维护它们所需的知识。

学习在产生回报之前往往让人难受。我把它比作学滑板：摔倒、失败和无能为力的感觉，让很多人在掌握动作之前就放弃了。有了 AI，总有一个看似更轻松的选项：再问一次，盼着答案奏效，而不是阅读文档或调试。

我会有意进入陌生领域，例如使用 Rust，并克制让模型替我消除每一个难题的冲动。同时，这些工具也帮助我学习密码学：我可以不断提问、制作挑战题，和专家交流时也能准备得更充分。AI 是代替思考还是支持思考，取决于我的使用方式。

例如，我现在会制作密码学挑战题，不断向智能体提问，直到它无法再解释。然后我再请教更有经验的朋友，问题也会更有质量。工具降低了入门成本，但探索仍需要好奇心驱动。

Faye 质疑一种说法：提示词只是继汇编到 C、C++ 到 JavaScript 之后的下一个抽象层。高级语言隐藏细节，却提供结构化接口；自然语言则带来歧义。我越来越不确信两者属于同一种抽象。

优秀工程师即使主要在高层工作，也能从了解相邻层获益。Faye 引用了开发者的帖子，他们说大量使用 AI 后信心下降。这些是个人经历，并非对整体退化程度的受控估计，但它们说明了人们为什么担忧。

Faye 引用了资深和初级开发者的经历。其中一人说，雇主要求 AI 编写并审查代码，人只看结果，使他担忧会失去未来工作所需的技能。我认为这种强制要求不是好主意。

我的背景也许解释了为何体验不同。我早已花多年管理团队、理解系统和帮助处理故障，而不是亲手写每一行。我只写产品代码中的一小部分，但对系统的理解不断增长，AI 也帮助我指导团队。这是我的经验，不能保证每个人都会如此。

经验较少的开发者面临另一种挑战：工具可能让他们在了解各个部分如何出错之前，就构建出大型系统。关于初级开发者无法调试 AI 编写代码的帖子令人担忧。但我不认为使用 AI 调试本身不好；问题是依赖它的同时拒绝理解系统。

一则关于初级开发者无法调试生成代码的帖子引出了重要区别。用户受影响时，我希望用上所有有用工具。AI 可以帮助检查错误和提出假设，但开发者仍需要根据证据推理并理解应用。

我们的 Ping 视频产品发生故障时，我把错误交给一个 Codex 实例，同时自己检查浏览器和日志。我熟悉 T3 技术栈，因此能把问题缩小到一个 Prisma 关联返回空标识符。第一个智能体提出了不同的解释，我没有直接接受。

接着我问另一个智能体，哪项引用完整性检查最可能涉及此事。它指出了用户和房间之间的关联。我借助模型编写查询，定位并清理受影响的关联，服务随后恢复。这次解决过程结合了我已有的系统知识和工具的帮助。

我分阶段使用智能体：先定位可能涉及的表关系，再寻找受影响的记录，最后编写清理查询。与此同时，我一直在阅读日志和代码，而不是被动等待。没有我对系统的了解，这种交流恐怕不会如此顺利。

Faye 担心的是，资深工程师过去通常在承担更抽象的职责前，经历了多年的实现和调试。如果初级开发者把每个难题都委托出去，下一代资深工程师要从哪里获得实践？我也有这个担忧，虽然无法给出一条统一的成长路径。

职业早期，我受益于有机会参与架构讨论和高优先级故障处理。了解系统如何失效，让我更擅长跨组件寻找原因。我认为人们仍能借助 AI 培养这些技能，但深入研究基础知识的动力可能变弱了。

我过去的建议是，在实际问题需要时学习基础知识：例如性能遇到瓶颈，就研究更快的排序方法。如今智能体可能直接给出方案，开发者却不知道原因。我对此担心，但也看到好奇心强的年轻创造者借助工具探索并理解以前难以触及的内容。

AI 可能让人维护一个规模远超其现有经验所能驾驭的代码库。如果他们研究故障并积累理解，这是机会；如果一出问题就束手无策，这就是麻烦。开源维护也能带来宝贵反馈，因为贡献者的经验和视角各不相同。

我很重视开源维护者的经验，因为他们要审查不同背景贡献者的代码，也要处理真实用户依赖的软件。这种经历可以加快学习，而简历上的年限本身并不能说明全部情况。

经验丰富的开发者也不能幸免。Faye 引用了 Simon Willison 的经历：他对某些应用不再有牢固的心智模型。文章还引用 Anthropic 对“监督悖论”的描述：有效监督需要的技能，可能因 AI 使用取代了培养技能的实践而减弱。任何研究结论的适用范围仍取决于具体研究。

我不知道如今最好的训练路径究竟是什么，因为我无法清空经验重新开始。Faye 认为，团队越来越重视产出速度，轻视理解、一致性和代码可读性。我还想补充，好的工程需要权衡：解决正确的用户问题、及时交付也很重要。

理解充分后产生的速度很有价值，但强迫所有人跟上同样的节奏可能出问题。我见过团队为了保持共同理解而放慢速度。智能体生成的大量代码可能超出审查能力，公司强制使用 AI 或按 token 排名，也可能奖励使用量而非学习。

我怀疑教育产品在商业上能否与提供即时满足的工具竞争。这是我根据投资经历作出的判断，并不是适用于所有学习者的实证规律。有意识地使用 AI 探索和理解的人，仍然可以学到很多。

写代码也是一种规划方式。在 Twitch，我常常先做一个最小版本，再写详细规格。有时原型足以直接交付；否则，这段实践会暴露难点，让后续计划更好。只要我仍然积极参与，AI 辅助原型也可以达到同样目的。

Faye 引用 Dax 的观点：写类型、函数和目录结构可以帮助他弄清功能应该是什么样。我同意这种探索很有价值。我也认为，AI 可以降低推翻错误结构的成本，让我愿意尝试过去不敢做的实验。

详细提示词并不能消除所有歧义。模型可能用假设填补空白，或者编造 API，因此输出需要审查和修改。通过具体实现理解问题，可以暴露看似完整的规格遗漏的细节。

Faye 提醒说，一些团队在供应商故障时停工，因为工作流依赖单一服务。我不同意把这一切都视为不可避免的锁定：开发者可以准备备选方案。我自己的 T3 Code 支持切换智能体和供应商，但这并不意味着切换毫无成本，也不意味着故障绝不会同时发生。

我也不同意把变化的 token 成本视为 AI 独有，或认为企业应当期待所有成本固定。实际支出仍值得跟踪，替代方案也需要在故障发生前测试。我的重点是，要理解服务替你做了什么，以及替换它需要补上哪些工作。

Faye 并不主张拒绝生成代码。他建议让 AI 扮演辅助角色：用它研究和规划，持续参与实现，并有选择地委托。他自己的工作流包括亲手编写相当一部分代码、使用伪代码，以及一次只生成自己能够审查完的内容。

他也避免让智能体实现自己不会做的事情，学习性实验除外，而且这些实验之后可能会丢弃。我喜欢围绕伪代码反复交流，包括询问模型某种方案如何映射到实际代码库。这种互动可以缩小意图和实现之间的距离。

我还会根据代码的使用方式做区分。一次性分析脚本或迁移代码，与用户每天运行数千次的关键路径，要求并不相同。AI 让过去手动完成更快的任务也值得写脚本；重要的生产代码则需要更深入的理解和审查。

只有知道哪些代码在运行、运行频率如何，这种区分才有意义。对于用完即弃的工作，我可以探索更多可能；对于核心代码，我可以让智能体解释架构、找出热点并协助大规模修改，同时自己负责理解和验证结果。

对于一次性个人任务，我用生成的脚本做过计算器，也管理过 NAS 上的文件。在 AI 出现前，为一次操作写大型脚本可能比手动完成还慢；如今其中一些尝试已经变得可行。

Faye 说，他的方法带来更好的工作质量，未必让他更快。我希望两者兼得：小任务做得更快，重要代码的质量也更高。危险在于混淆这两类工作，把所有生成的改动都当作同样可以随手丢弃的东西。

Faye 最后强调，生产力提升是真实的，直接参与工作带来的理解也同样真实。他担心，把所有思考外包会削弱监督工具所需的能力。我同意这个提醒：用 AI 推动思考、提出更好的问题并学到更多，而不是让它取代理解问题的努力。