——“一个人用AI如何写出比PyTorch更快的自研深度学习框架”系列文章之三
首先大家需要知道一点：Tech-Renaissance整个框架都是AI编程的产物，它从设计、开发、调试、优化到文档写作，都大量运用AI编程技术。我不可能做好了一个看上去还不错的深度学习框架后，自称“是我写的而不是AI写的”，来彰显自己厉害。事实上，在AI编程技术突飞猛进的这个时代，若是不妥善利用AI编程而是手写代码，就如同清廷要求在唐胥铁路上用骡马拉火车一样可笑。事实上就连用业余时间做深度学习框架的这个念头，最初也是AI怂恿我的（这个AI大家都认识，叫GLM-4.6）。
但是这并不意味着人不需要参与开发过程，或者任何人不需要知识准备就能让AI去做到。前面的文章也说了，指望对着AI吼一声“给我做出一个最快的深度学习框架来”它就给你做好，那是不太现实的事情（至少对于当前的技术水平和这个任务来说是如此）。当前的AI Agent技术已经在试图一站式地帮开发者解决所有的问题，这毫无疑问是工程上大幅提升效率的正确方向；但如果你需要在你的项目中融入更多你自己的创新设计和具体要求，那么，设计开发中的人工干预就不能少；尤其你对性能有极致要求的话，你就需要紧盯AI生成的每一个步骤，避免它偷懒给你一个平庸的解法。AI是勤劳能干的工人，但为了确保项目建设不出问题、符合要求，你这个包工头当然不能少下工地亲自指导。
事实上，一个能训练VGG16BN的深度学习框架本身丝毫不稀奇，哪怕它速度比较快也是如此；但如果掌握用AI把它做出来的技术，你就有可能做出更多不可思议的事情。
下面介绍一下AI编程技术和原则，抛砖引玉，以便给各位一些启发。
AI编程技术简介
我不会像某些老旧的零基础教程一样按部就班地教大家“去XX网址下载AI编程工具”、“点击下一步，安装”、“在这个框框内输入提示词”——这些想必聪明的各位都会，即使不会，也可以很快地从官网找到更靠谱的教程和说明。
我想做的，是帮大家梳理清楚当今AI编程工具的技术版图：它们大致分成哪几类、各自解决什么问题、背后的技术逻辑是什么。搞清楚这张地图，你才知道自己手里的工具处在什么位置，也才知道该在什么场景下用什么武器。
一、底层的引擎：大语言模型（LLM）
所有AI编程工具的核心，都是一个或多个大语言模型。当下与编程最相关的第一梯队模型，大致包括：
- Anthropic 的 Claude 系列（如 Claude Sonnet / Opus）：以代码能力强、长上下文稳定、遵循指令严谨著称，是目前很多重度开发者的首选；
- OpenAI 的 GPT 系列（如 GPT-4.1、o系列推理模型）：通用能力全面，推理模型在复杂逻辑与算法问题上表现突出；
- Google 的 Gemini 系列：超长上下文窗口是其显著优势，适合”喂”进整个大型仓库；
- 国产模型：如本框架的”怂恿者” GLM 系列、DeepSeek 系列、Qwen 系列等，性价比高、部分开源可本地部署，在中文语境和特定任务上同样能打。
理解模型的两个关键特性对编程尤为重要：一是上下文窗口（一次能”看到”多少内容），它直接决定了AI能同时理解多大规模的代码；二是是否具备推理（reasoning）能力，推理型模型会在给出答案前进行更长的”思考”，在架构设计、算法优化、疑难debug上往往更靠谱。这也正是原则四（交叉检查）能够生效的物质基础——不同厂商、不同架构的模型，”思维盲区”各不相同。
二、工具的形态：从”聊天框”到”自主智能体”
按照介入开发流程的深度，AI编程工具大致可以分为四个层次，它们不是互相取代，而是层层递进：
1. 对话式助手（Chatbot） 最基础的形态，就是网页或App里的聊天窗口（如 ChatGPT、Claude、各类国产助手）。你复制代码进去、提问、把答案粘回来。它最灵活、最”通用”，适合学习知识、讨论方案、写独立的小片段，但脱离了你的项目上下文，需要你手动搬运信息——这也正是原则三反复强调”上下文”的原因。
2. 编辑器内联补全（Inline Completion） 以 GitHub Copilot 为开创者的形态：它嵌入在你的IDE里，根据当前文件的上下文，实时补全你正在写的代码。它擅长消灭样板代码和重复劳动，但正如原则十一所提醒的，别把它仅仅当成”高级自动补全”——那样是对其能力的极大浪费。
3. AI原生编辑器 / 深度集成插件（AI-Native IDE） 以 Cursor、Windsurf，以及 VS Code + Cline/Roo Code 等为代表。它们的关键跃迁在于：AI不再只看单个文件，而是能索引并检索整个代码库（通常借助向量化的语义搜索），能跨文件理解、跨文件修改，能读取你的报错、运行终端命令。这是目前多数开发者的主力工作台，也是实践本文诸多原则（如永久上下文层、git diff检查）最顺手的场所。
4. 自主编程智能体（Coding Agent） 最前沿的形态，如 Claude Code、Aider、OpenAI Codex，以及 Cognition 的 Devin 这类工具。你给它一个目标，它会自主地拆解任务、规划步骤、编写代码、运行测试、读取报错、自我修正，形成一个”感知—决策—行动”的闭环。这正是文首所说”一站式帮开发者解决所有问题”的方向。但请牢记原则十：Agent越自主，人的审查就越不能少——它跑得越快，撞墙时的惯性也越大。
三、支撑智能体的关键技术
让上述工具（尤其是后两类）真正好用的，是几项支撑性技术，值得开发者了解其原理：
- RAG（检索增强生成）：工具把你的代码库切片、向量化并建立索引，需要时检索出最相关的片段”喂”给模型。这就是AI能”读懂你项目”的技术底座，也解释了原则三里那句——给AI”对”的信息，而不是”多”的信息。
- 工具调用 / 函数调用（Tool / Function Calling）：让模型能主动调用外部能力——执行命令、读写文件、搜索网络、运行测试。Agent的”手脚”由此而来。
- MCP（Model Context Protocol）：由 Anthropic 提出并正在被广泛采纳的开放协议，相当于给AI工具定义了一个统一的”接口标准”，让模型可以规范地接入各类外部数据源与工具（数据库、文档、API等）。它正在成为连接AI与真实开发环境的重要基础设施。
- 项目规则文件：如
CLAUDE.md、.cursorrules、agents.md等。这不是什么高深技术，却是四两拨千斤的实践——它就是原则三所说的”永久上下文层”，是你把团队默契显式化、喂给AI的最佳载体。
四、如何选择：没有银弹，只有组合拳
你若问我在Tech-Renaissance中具体使用哪些LLM，那答案非常明确：设计用的是ChatGPT 5、GLM 4.6、Gemini 3、Kimi K2.6、Sonnet 4.6、Opus 4.6，而编程用的是Sonnet 4.6、DeepSeek V4 Pro、Kimi K2.6。但是这些肯定既不是唯一解，也不是最优解。工具在不停地更新迭代，隔一两天你再去看模型列表，就有大厂推出了全新的强力编程LLM，前端也会不时地升级，功能会越来越强大，使用会越来越方便。需要提醒的是：不存在”最好的工具”，只有”最适合当前任务的工具组合”。 学习原理时用对话式助手，日常编码用AI原生编辑器，成规模的功能交给编程智能体，关键决策再用异质模型交叉检查——这才是成熟的工作流。工具会不断迭代甚至更名，但本文接下来要讲的原则，可能才是穿越工具更迭、真正历久弥新的东西。
AI编程原则
以下原则，是大家在使用编程工具时需要牢记在心的。这不是我个人的有感而发，而是取自技术社区众多高手的经验之谈，并且经过我的实践进行检验、整理、提炼而得到的结论。你不一定要每条都参照执行，但理解和掌握这些经验技巧，可以让你事半功倍。
原则一：预先规划原则
当之无愧的No. 1原则。 你若是让AI来总结AI编程经验，它多半也会把这条排在第一位。
人类开发者要做好一个架构师的工作：首先明确到底要开发什么、要修改什么、需要达到什么目标、需要遵循什么规则。把一切写清楚之后，才能动手。你几乎总是应该先写好一个”施工计划”（比如一份 PLAN.md 或 spec.md），把这个计划修改到接近无懈可击，再让AI去执行。
为什么呢？因为这个”施工计划”本质上是一个强化版的Prompt——它包含更多的细节，能指导AI怎么去做，以免它碰到实际代码时靠着想当然的直觉去解决，结果产生大量不符合预期的问题。一个成熟的工作流是：先让多个AI根据基本要求分别生成方案，然后让它们交叉检查、得出最优方案，再优化这个最优方案，确认没有问题后，才让其中一个AI去执行。
有了明确的目标和规则，就可以大幅减少AI的返工，提升整体效率。哪怕你写这个”施工计划”的时间是实际施工时间的十倍，它也是值得的。 当AI生成的代码偏离预期时，更高效的做法也是回滚改动、细化计划、重新生成，而不是在错误方向上反复修补。
原则二：任务拆分原则
这是社区共识度最高的原则之一：AI在聚焦的小任务上表现最佳，一次性让它生成庞大、单一的代码块，极易累积隐蔽错误和集成冲突。
正确的做法是”分而治之、小步快跑”：将大需求拆解为最小可独立验证的单元，逐一实现、逐一确认。每个模块都应足够小，确保AI能在上下文窗口内从容处理，同时你也能完全理解它生成的每一行代码。每完成一个切片，就立即编译、跑Lint、运行测试，验证无误后再将其作为后续迭代的稳定基石——这能从根本上阻断Bug的滚雪球效应。
反面教材就是”让AI一次完成整个大型项目”：上下文快速膨胀、AI遗忘早期设计、错误不断累积、修改成本越滚越高。分而治之，是AI编程时代最重要的工程纪律之一。
原则三：上下文中心原则
AI不知道你的项目规范、架构决策或编码约定。如果不提供这些上下文，它就会依赖通用的默认设置，导致生成的代码风格混乱、调用错误的API、甚至引入未安装的依赖。大多数时候，AI产出质量不佳的原因不是”提示词不够高级”，而是它根本不了解你的项目背景。
高质量的上下文包括：技术栈与版本、项目目录结构、已有接口和设计模式、编码规范、性能要求、不可改变的约束，以及2–3个符合你期望的代码示例——示例能传递”好代码”的隐含标准，往往比长篇的自然语言描述更有效。
最佳实践是在项目中建立”永久上下文层”，即 CLAUDE.md、agents.md 之类的项目规则文件，把技术栈、命名约定、错误处理规则以及”绝对禁止做的事情”显式固化下来，让AI在每次开始任务前读取。同时要注意：给AI”对”的信息，而不是”多”的信息——不要一股脑塞入不相关的文件，让AI通过检索去定位所需上下文往往更有效。
原则四：交叉检查原则
有很多研究和实践表明，用异质的AI（不同版本或不同厂商的LLM）进行交叉检查可以达到更好的效果。因为同一个LLM的不同实例思考问题的方式大体相同，换一个LLM用不同的方式看问题，就更有可能发现隐藏的错误。这就如同一个人冥思苦想找不到答案，但跟朋友一交流就找到了此前的盲区。
至于AI之间如何交流，基本上离不开两个字：文件。文件就是AI交流的介质——让一个AI写好Markdown，再让另一个AI去看，很快就能实现它们之间的高效交流。俗话说三个臭皮匠顶个诸葛亮，同一个问题让大约3个不同的AI交叉检查，最终答案的质量通常会好很多。如果AI之间出现明显争执、谁也不服谁，你可以亲自裁决，也可以让AI投票表决。
此外，交叉检查还有一种进阶用法：用AI做”批判者”，而不只是”生产者”。 让一个AI负责设计，另一个AI负责攻击这个设计——找架构缺陷、预测性能瓶颈、检查安全风险。AI生成代码时容易受自身假设限制，而独立审查可以发现另一类问题。
原则五：避免Debug原则
AI具有很强的debug能力，但这并不意味着你可以先不顾一切地写好，再慢慢修改。事实上恰恰相反：最好的做法是让AI一步到位地生成完全不需要debug的代码片段。
因为AI不一定能理解bug出现的机制，而debug的开销往往非常大——即便对于AI来说也是如此。与其陷入”生成→报错→贴回去→再报错”的泥潭，不如在生成之前就把约束、边界条件和验收标准交代清楚（这也正是原则一和原则三的价值所在）。当AI在错误方向上反复挣扎时，果断回滚、修正计划、重新生成，通常比继续修补更省时间。
原则六：单元测试原则
或者叫验证原则。你必须有手段能够及时检验AI生成的模块到底能不能work、正确性如何、性能如何，而不能盲目相信它写得很好，更不能在做完一大批模块之后再一起检验。
相信我：不做单元测试，迟早会吃大亏——你迟早会遇到一个怎么也查不出来的bug，或一个怎么也优化不了的性能瓶颈，或一次性回滚海量代码，绝望地看着好几天的努力付之东流。分模块地规划任务，然后对每个模块进行比较全面的单元测试（包括数学正确性、性能、跨平台特性等），可以让开发进度有条不紊。
好消息是，写测试样例恰恰是AI最擅长的事情之一：测试有明确的输入和期望输出，你只要给定规则和示例，AI就能高效生成，真的不费多少工夫。更进一步，可以采用接近TDD的流程：人定义接口 → AI编写测试 → 人确认测试合理 → AI根据测试实现代码 → 自动化测试持续验证。此时测试不仅是质量保障，更是向AI传达需求的”活文档”。
原则七：并行原则
一个很容易被初学者忽略的技巧：你完全可以同时开启多个窗口，让多个AI并行开发或检查——代价只是Token消耗得更快。很多AI编程工具本身具备一定的并行性（比如调度多个Coding Agent或Search Agent），但这个并行度往往还不够。
你必须明白，时间就是金钱。能够并行的时候就应该让它并行，而不是自己在旁边傻等着单个AI干活。相关度越低的任务越容易并行：你可以在制定计划之后，让多个AI分别执行方案的不同方面；可以让多个AI分别实施不同的方案，然后比较结果谁更优。跑测试时更是如此——只要计算资源不冲突，就可以让一个AI负责一个场景。比如开发跨平台框架时，可以让一个AI负责Windows上的测试，另一个AI负责Linux上的测试，效率立刻翻倍。
原则八：及时提交原则
一般来说，AI不得在未经允许的情况下提交git。因为如果没有到提交的节点，或者代码中存在不应提交的问题，或者提交摘要不符合开发者的习惯和要求，就会让项目变得更加混乱。你必须有意识地、有计划地提交。
为什么git提交如此重要？首先，AI在开发时经常需要用 git diff 来检查修改过了哪里，出现问题时也需要及时回顾，如果没有提交记录，这一切就难以实现。其次，还有很容易被忽视的一点：执行多AI交叉检查时，负责检查的AI必须通过 git diff 快速了解负责修改的AI到底改了哪些内容——这样它们才能高效交流，从修改过的部分迅速锁定问题。
结合原则二和原则六：每完成一个经过验证的小切片就提交一次，让每个已验证的版本都成为下一步迭代的可靠基线，也让”随时可回滚”成为你最坚实的安全网。
原则九：会话边界管理原则
AI会话的上下文会不断累积，当对话过长或任务切换时，AI会不可避免地出现”上下文退化”与”注意力漂移”，逐渐遗忘最初设定的关键约束，变得困惑或重复犯错。这也是许多AI编程工具会主动提示”新开一个对话效果更好”的原因。
明智的做法是把与AI的交互视为一个个离散的”事务”：一个会话只聚焦解决一个特定问题（如定义接口、实现具体业务、编写测试），任务结束即封存结果，并在干净、全新的会话中开启下一阶段。适合开启新会话的场景包括：切换到不同任务、AI反复犯同样错误、已完成一个逻辑完整的工作单元；而适合继续当前会话的场景则是：仍在对同一功能迭代、需要用到先前讨论的上下文、正在调试它刚构建的内容。
一个进阶技巧是采用”双层工作流”：在一个总控对话里维持全局规划，每完成一步实现就回到总控对话汇报进展并规划下一步。用文档或任务清单（如 task_plan.md）来承载持久记忆，而不是依赖对话历史本身，这样既保留了项目全局理解，又不会让单次对话被无关细节撑爆。
原则十：人工审查原则
或叫“人类把关原则”。这是目前AI编程社区最重要的共识之一：永远不要直接相信AI生成的代码。 你可能听过 Human-in-the-Loop，在 AI 编程领域，这句话指的是人类开发者持续介入、审核、修正和引导 AI 生成代码的工作模式，而不是让 AI 完全自主地编写和部署代码。因为AI生成的代码很可能是存在问题、不符合要求的，人类必须负责把关，对代码负有最终责任。
AI生成代码的常见问题包括：API幻觉、边界条件错误、隐藏性能问题、错误处理不足、安全漏洞，以及最危险的”静默漏洞”——逻辑完全自洽、能通过编译，却在生产环境中暗藏缺陷。因此成熟的流程应该是”生成 → 阅读 → 测试 → Profiling → 修改”，而不是”生成 → 复制 → 提交”。对于并发代码、底层系统代码、安全相关代码和金融代码，人工审查更是不可省略。
有一条很好的判断标准：如果你无法用自己的话解释AI写的代码，就不应该让它上线。 代码审查、测试覆盖率验证和安全扫描这三道关卡，一道都不能省。理解和把控代码的责任，永远在你自己。
原则十一：架构师原则
使用AI编程工具，最根本的是心态转换：以前是你写代码、AI辅助；现在是AI写代码，你来设计、评审和把关。 开发者的角色，正在从”高强度的编码者”转变为”高逻辑的架构师与审计员”。你要知道，目前的LLM的上下文窗口非常有限，它更擅长的是局部的理解、填充、改写；而你作为人类开发者，作为掌握整体项目架构和开发进度的人，作为拥有远超LLM上下文窗口的记忆力的人，你需要有“一盘棋”的全局观念，清楚地明白如何构建起整个项目，也清楚地明白如何组织和协调。
不要把思考也完全外包给AI——绝大多数人用AI效率低的本质原因，就是把思考外包给了模型。优秀的AI使用者往往不只是提示词高手，也是架构设计能力强的人：人负责确定目标、架构、约束和验收标准，AI负责实现细节、重复劳动和样板代码，人负责最终判断。同时也不要走向另一个极端，把AI当成”高级代码补全”去写单行代码——应当委托它完成边界明确的完整功能模块，给它充足的上下文和推理空间。
当AI能在几秒内生成代码时，技术执行本身已不再是护城河。真正的竞争力转向了设计思维和产品直觉——谁能提出精准的问题定义、优雅的解决路径，谁就能占据优势。在AI编程时代，人依然是价值的定义者，AI只是价值的实现者。
原则十二：共同进化原则
最后一条，这是很多人容易忽略的一个原则，但它的重要程度完全不亚于第一条。这不是在鼓吹什么”人剑合一”的玄学，而是强调人与AI必须互相学习、共同成长。
一方面，你必须充分利用AI提升自己的知识储备，以免无法理解AI的设计方案，以免在执行规划时陷入一问三不知的尴尬处境。要警惕”能力退化”陷阱：遇到报错直接贴给AI、不理解原理就跳过学习、AI给的方案直接就用——越依赖AI，能力越退化。正确的做法是”先思考、再生成、后对比”，对AI生成的每一行代码逐行弄懂原理，不满足于”能运行”。你必须明白，AI既是编程工具，也是你的搜索工具和学习工具，也是你的老师。虽然项目过程中你是像领导或指导老师一样指导AI干活，但在此之前，你需要先以AI为师，先确保你从AI那里学到足够的知识，确保你有指导AI的资格。
另一方面，你也要让AI向你学习：制定越来越成熟的规则、维护越来越清晰的文档、积累越来越有价值的示例代码，让AI明白你的设计意图和设计风格，让AI在每次重启或上下文压缩”失忆”之后，能够最快地回想起自己到底要干什么。人类的团队默契和常识对AI而言是完全不存在的，必须将其显式化、文档化。有一些设计可能是违反AI惯用方法的、是AI无法立刻理解的，这些你需要不厌其烦地向AI说明，教会它，确保它明白，再让它开工。
结语
写到这里，如果要把上面十二条原则再浓缩成一句话，那就是：在AI编程时代，人的价值不降反升，只是价值的落点变了。
它从”我能不能写出这段代码”，转移到了”我能不能定义清楚要什么、判断准确好不好、把控牢固对不对”。它让人类从刀耕火种的劳动方式中解脱，进入到机械化、自动化、规模化生产的时代。技术执行本身确实正在快速贬值，而设计思维、架构能力、判断力和持续学习的能力，正在成为真正的护城河。
回到最初：当你要做出一个框架，要求它具备各项基本功能、要求它正常运作各种算法、还要跑得足够快、有完整的文档，那靠的从来不是”对着AI吼一嗓子”，而是一整套人与AI协作的纪律。AI是勤劳能干的工人，而你，必须是那个既懂图纸、又肯下工地的架构师。 这是这个时代最真实的协作方式。
愿我们都能成为驾驭AI的人，而不是为AI打字的人。我们下一篇再见。
