中文 English

五月份我做了一个小实验：在业余时间里，主要和 DeepSeek V4 Pro 结对编程，做出了一个 3D 几何处理软件。后面几天又让 Codex 帮我兜底重构和整理。整个过程中，我基本只提需求、做设计判断、审阅结果和验收行为，没有直接手写业务代码。

这个项目叫 3D Claw，代码已经开源：

https://github.com/tangtangtang1995/3D-Claw

这篇文章不是想证明 AI 已经能替代程序员，也不是想包装什么神奇的一键开发流程。我更想记录的是：当一个有一定工程经验的人真正把 AI 当成结对编程对象时，哪些事情变得很快，哪些事情依然绕不开，以及这个过程中最考验人的地方到底是什么。

我的编程背景

如果把大一大二在机器人队里参与电调、检测羽毛球轨迹那种补丁式开发也算上，我大概有十多年 C/C++ 编程经验。后来读研做算法，主要语言变成了 Python 和 MATLAB。工作之后因为项目落地，又重新补了一些底层、工程和混合编程的知识。

我一直觉得语言之间是相通的。熟悉了 C++ 这种“高级汇编”之后，再上手解释型语言通常不会太慢。当然，“能写”和“写得好”是两回事。到了 AI 编程这里，差别会更明显：你可以很快让 AI 写出一段能跑的代码，但要让它持续写出能接入系统、能维护、能演进的代码，就不是一句“帮我实现一下”能解决的。

AI 结对编程不是许愿

我在这个项目里尽量按照正常软件开发流程来做，只是把很多环节压缩得更轻量。流程大概包括：

  • 产品设计说明
  • 技术调研
  • 系统设计
  • 模块概要设计
  • 编码实现(coooooding)
  • 单点测试
  • 集成验收
  • 系统测试

这些文档和代码大多由 AI 输出，但不是 AI 自己决定方向。我会先提出目标，让它给出方案，然后我审阅、追问、否决、拆分、合并，最后再让它执行。 把 AI 当成一组非常能干但需要明确管理的工程师。你要告诉它边界在哪里，哪些文件能动，哪些接口必须稳定，哪些行为必须验收，什么时候该提交，什么时候该停下来复盘。

架构先行

早期准备，肯定是架构先行(直接让ai模仿之前古法编程时代的手搓架构，然后发现随着代码深度增加，ai会失控，架构被破坏lol。准确的说就是：随着代码深度增加，AI 会逐渐开始“就近解决问题”：哪里方便就在哪里加逻辑，哪里能拿到数据就在哪里绕一下，最后系统边界会被一点点磨掉。)。

还有各种编码约定，版本管理工具以及commit的时机。具体的编程过程就不展开了，可以看之前的文章。只要架构还在，ai就出不了大乱子。所以后面我会把规则写得很硬，比如：

  • UI 不直接碰重型算法库
  • 算法能力通过服务层接入
  • 配置、执行、结果和状态分开传递
  • 复杂任务必须拆成小模块
  • 单个函数尽量不超过 200 行
  • 单个代码文件尽量不超过 2000 行
  • 每次大改前先让 AI 复述当前架构
  • 每次大改后让 AI 自查是否破坏边界

和AI协作的核心知识

这次实验之后，我发现 AI 编程里最有用的知识，反而不是那些面试高频知识点。

像 CSAPP、C++ Primer、数据结构、算法设计、操作系统这类书当然重要，它们构成了一个程序员的基本功。但在和 AI 结对编程时，很多局部知识 AI 比你记得更全。语法、API、常见算法、库函数怎么调用，它通常都能给出一个还不错的起点。

真正拉开差距的，是另一类知识：

  • 大规模 C++ 软件开发
  • 人月神话
  • 程序开发心理学
  • 软件工程里的分层、边界和演进
  • 需求拆解、验收标准和风险控制

至于设计模式，我现在觉得它没有想象中那么神奇。模式名字本身不重要，重要的是你能不能识别变化点，能不能控制依赖方向，能不能让一个模块在未来被替换而不是把整个项目拖下水。

和 AI 编程时，考验的不是“你会不会某个知识点”，而是“你能不能把一个模糊目标拆成 AI 能可靠执行的工程任务”。你既是系统工程师，又是项目经理，还要时不时充当甲方和测试。

说白了，就是和 AI 扯皮。

现实项目里不也经常是这样嘛。

算法代码的边界

在三维数据处理方向，我对 AI 写算法代码的评价比较克制：它能帮很多忙，但不能神化。

如果任务是调用成熟几何库，比如 Easy3D、CGAL、OpenGL、ImGui 这类库，AI 的表现会比较好。它可以很快搭出界面、管线、参数面板、日志、状态反馈和可视化流程。只要你把接口和验收标准说清楚，它推进速度非常快。

但如果是真正从 0 到 1 写几何算法，它就会明显磕绊。比如让它计算两片点云之间的点到点最短距离，它直接写了一个 m * n 的朴素双重循环。项目里明明已经有 kdtree.h，但它不会主动想到要复用。只有当我明确指出“这里应该用 KD-tree”之后，它才会改。

这件事挺有代表性：AI 不是不会，它是“不一定会在正确的时刻想起来”。它有知识，但没有稳定的工程直觉；它能生成局部正确的代码，但不一定能主动选择系统里最合适的路径。

所以让 AI 写代码，但关键路径一定要审；让 AI 提方案，但架构选择我一定要拍板；让 AI 做实现，但验收标准必须由我来定。

模糊需求会制造虚假共识

现在的 AI 编程还有一个问题：同样一句需求，对不同项目、不同阶段、不同开发者，正确答案可能完全不一样。

你说“帮我加一个功能”，AI 不知道你要的是临时 demo、可维护模块、生产级实现，还是一次性脚本。它也不知道你更在乎性能、清晰度、交互体验、兼容性，还是未来扩展。

如果需求本来就很模糊，AI 很容易给出一种看似合理的折中方案。它会写得很顺，解释得很圆，甚至让你产生一种“我们已经达成共识”的错觉。但这个共识可能是假的，因为你们其实没有讨论清楚约束条件。

模糊的需求，会得到模糊的概率；模糊的概率，最后往往输出和稀泥式的架构。

AI是个有者无限精力的莽汉(如果你的钱足够的多)，但在工程项目里，无约束的AI通常也是 bug 的温床。

纯新手能不能用 AI 编程

我觉得当然可以，但最好先降低预期。

AI 会极大降低从 0 到 1 的门槛。一个没有太多编程经验的人，现在确实可以更快做出一个能看的原型：网页、小工具、自动化脚本、数据分析、小游戏，甚至一个简单 App。这个变化是真实的，而且很有价值。

但 AI 没有取消工程能力的重要性，只是把瓶颈换了位置。

过去的瓶颈是“我不会写代码”。现在的瓶颈变成了：

  • 我不知道需求该怎么描述
  • 我不知道 AI 写得对不对
  • 我不知道哪里有安全风险
  • 我不知道怎么测试
  • 我不知道项目变大后怎么拆
  • 我不知道代码坏掉以后怎么回滚

所以如果是纯新手，我更建议从小项目开始。不要一上来就做一个庞大的系统，而是做一个输入输出很清楚、结果能肉眼检查、坏了也容易重来的东西。过程中一定要学会 Git，学会让 AI 写测试，学会让 AI 解释自己改了什么，也要学会在它越写越乱的时候喊停。

AI 可以帮你跨过语法门槛，但不能替你承担判断责任。

小结

AI coding 的核心不是“许愿”，而是“组织”。真正的命门在于架构。

你要组织需求，组织架构，组织模块，组织提交，组织测试，也要组织 AI 的注意力。它很强，但它不是一个天然可靠的工程团队。你越能把问题拆清楚，它越像外挂；你越是把一团模糊的想法丢给它，它越容易把项目带进一种看似繁荣、实际失控的状态。

AI 时代确实会给普通人带来机会，但这个机会不只是“不会编程的人也能写代码”。更准确地说，是很多人第一次有机会把自己的想法快速推到一个可运行的形态，然后在真实反馈里学习工程、产品和系统思维。

这大概也是我现在最喜欢 AI 编程的地方：它让实现变快了，也让人的判断变得更重要了。