0. 引言
从本月初花 200 美刀付费购买 ChatGPT Pro 以来，我开始深度使用 Codex 并把 AI Coding 作为我唯一的编码模式。可以负责任地说，这一个月上线的代码中没有一行是真正由我手写的，而我的开发效率也提升了可能一倍不止。 倒不是说我能让一个需求从原来的 10 天工时降到 5 天，而是说我可以同时开展两个甚至更多需求，而基本不延期各自的工时。 这让我能同时处理的任务数量有了爆发性的增长，像是性能优化、体验优化这类过去因为人力不足来不及做的重要不紧急事项，都在这个月有了惊人的推进。
但 AI Coding 也并非灵丹妙药，不是说打开 codex 就能像甩手掌柜一样，等待它把所有任务做完∑。恰恰相反，我觉得最近一段时间的精力投入要远远高于往昔工作的任何一个时间段：AI Coding 更像是一个 shit umbrella 以及效率放大器，帮我挡住了那些耗时又不得不做的脏活、累活，从而让我把注意力放到更深度的思考上。 也许工作的时长绝对值降低了，但其实输出的内容质量跟深度都大大增大了。就像一个跑满 100% CPU，但只运行一小时的程序，其真正获得的产出远远比一个后台挂起，但是持续好多天的程序要多一样。 这个过程不是基于现有古法编码形式的迭代升级，而是对开发模式的一次彻底推倒重构： 从 2026 年起，人类将正式从单线程的人类编码，进化到多线程的”人类设计，AI编码”新时代。
我深感这种新模式的伟大，故写下此文分享我对 AI Coding 的一些看法及实践，并期待与大家一同探讨。
1. 理论推导
首先，我们要在两个核心点上达成共识：
- 使用 AI Coding 相比人类手写代码，有着本质的效率提升
- 使用 AI Coding 开发模式后，必然会发生从”集中做一个任务”到”同时管理多个任务”的质变
为了证明这两点，我们需要先点出手工编码模式的一个本质问题：把一个哪怕逻辑已然定义清晰的算法伪码，翻译为真正可执行的代码，本身仍有着极大的成本。 因为一个编程问题永远可以分为两个子部分：
Decision Work（计算） 即思考核心代码逻辑的部分。无论我们使用编程语言、自然语言还是伪代码，都是为了描述出一套解决问题的算法。这是整个编码过程的核心，重中之重。只有定义好清晰的算法，才有后续良好的结果和正常运行的程序。
Execution Work（IO） 但光有算法不够，我们还需要把伪代码翻译为真正可运行程序的必要 IO 成本。虽然翻译的过程没有很高的技术含量，也不太依赖人的脑力，但有两个致命因素使 IO 的成本居高不下： (a) 编程语言对大多数人而言并非母语，存在翻译成本。且编程语言对内容结构要求的精度极高：说话可以接受局部的表述模糊或语法错误，但写代码不行，错一个缩进或者括号分分钟程序崩溃。因为有这部分整理的成本在，所以编码具有天生的输出上限，写代码的速度永远比不过自然语言。 (b) 编码本身需要处理很多核心逻辑之外的”脏活”。比如查询调用的 API，或确认项目中参数传递的实现细节。这些工作不要求极高的智力投入，却会占用大量时间。 而客观来说，在绝大多数业务开发场景中，80% 的代码逻辑都是不言自明的，单纯只是把 PRD 翻译成代码；可能只有 20% 的核心算法需要开发者全力投入、仔细揣摩，所以计算开销往往是少于 IO 开销的，这无疑是对宝贵的研发时间资源的浪费。
而分析现在的 AI 能力：
- 计算部分很难完全外包给它。求解核心算法的逻辑，最多只能是跟一些顶级模型进行讨论，但最终拍板还得由人来定
- 但 IO 部分完全可以由 AI 代劳。只要算法定义清晰，将自然语言或伪代码翻译成真正的可执行代码，对现在的顶级编码 AI 模型来说，已经不是一件难事
看起来一切都很美好。那么，代价是什么呢？ 代价就是 I/O 依然需要花费时间，只不过是让 AI 去执行而已。并不是说调用 AI 工具以后，它就能在一秒之内瞬间把所有的代码都生成结束。 如果我们不去有设计、有目的地利用这些时间，就会发现自己的开发流程会被打得非常碎片化，变成了写 Prompt → 等待 AI 编码 → review AI 生成结果 → 再次 Prompt 的循环，其实相较于手写代码并没有效率上的优化。 在等待 AI 编码的这段时间，我们甚至不太敢去真正写代码，因为如果你继续写代码，反而会影响 AI 获取的上下文准确度，进而影响生成结果的质量，甚至造成修改冲突；而如果真的也不做，自然更是对这段时间的浪费。 这其实与”多线程开发”的优化思路非常类似： 本质上，人就是一个主进程，而 AI 则是可以无限水平扩展的若干子进程。我们应尽量规避那些会将自己阻塞的操作，而通过调度更多可利用的 AI 线程来完成任务，人类只在关键节点做决策，而把执行外包于 AI。 人类（主进程）负责调度，而 AI（子进程）下场执行。
这就证明了最早理论推导中提到的两个核心点：
- 利用 AI 能极大地把我们的 IO 开销”吃掉”，外包给 AI 处理，进而提升效率
- 但另一部分问题在于，AI 帮我们省下来的时间本身质量并不高，大多是碎片化的几十分钟甚至更少，因而我们需要并行开启若干任务，确保这些碎片时间能真正被利用
我们需要一些额外的时间管理策略来优化这些时间的使用效率。不然的话，如果我们只是集中做一个任务，优化出来的时间其实并不会被投入到后续的生产中 —— 它被优化，但马上又被浪费了。 进而，我们也就导出了一个重要的基本原则： 耗时任务应尽可能的被模型完成，使得人类只做关键卡点的决策判断，避免持有太多计算开销。
2. 实践模式
我现在的一个核心原则是：编码的过程要尽可能、近乎百分百地让模型来写，而不是由我亲自动手操作。这样才能把人类从 IO 彻底解放出来，把注意力留给真正的 Decision Work。
为此，我会把开发流程清晰地拆成三个阶段：
- Plan
- Coding
- Review & Integrate
Coding 阶段的目标很简单：把任务以尽可能清晰、可执行的 Prompt 交付给 AI，让它把 IO 吃掉，产出可以被 review 的结果。人类的精力则更多投入在 Plan 与 Review/Integrate 这两个阶段：前者定义确定性，后者守住质量下限，避免精力散落到执行层的细枝末节里。
当然，要让这套流程跑得稳，还需要一些约束，不然就会跑偏。
2.1 几个必须盯住的约束
1）每次 Prompt 的质量要尽可能高，细节全面，避免 model 自行发挥。
由于 Coding 部分已经完全外包给了 AI，在这套模式下，我们对代码细节的掌控天然是更弱的。如果让模型自己发挥太多，代码一下给得太多，我们自己都看不过来，风险也就不可避免地被放大。
所以最好的方法还是在 Plan 阶段把东西约束好。Plan 的对话都是文本，人类参与度更高，也就更可控。要在这一阶段把确定性定义下来，而不是让执行层充满混沌。
2）one session as long as possible：尽量让一个子任务在一个 session 内闭环。
人类的 context switch 成本太高了，高频切换顶不住。很多时候，1h plan + 1h AI coding 会明显好过 6 * (10min plan + 10min AI coding)。
所以我会尽可能一次性把一个任务里”现在能写出来的 Prompt”写完整，然后再交付给 AI 执行，而不是在任务 A 交付任务 1 之后立刻切到任务 B 交付任务 2，再回到任务 A 交付任务 3。那样做本质是在用自己的大脑当调度器硬扛上下文切换开销，最后往往是主进程先崩。
3）尽可能拆解正交的子任务：用并行去吃掉等待时间，同时把每次变更控制到可 review。
由于现在的大多数项目还不是基于 AI 原生开发理念来设计的，模型的上下文能力在很多场景下仍会弱于人类。至少在现在这个阶段，受限于上下文与模型能力，人工 code review 仍然完全不可避免。与此同时，AI 的出错大概率也只能缓解而无法避免。
所以在一个大需求开发时，我会尽量前置地把子任务拆得正交，确保每一次变更都在人类可 review 的范围内。不然不假思索地接受模型修改建议，很容易带来潜在的安全问题；同时也会对模型的上下文窗口造成更大考验，执行效率反而不高。
正交拆解还有一个额外好处：当子任务之间尽量不冲突时，开多个 session 并行推进就更安全，冲突隐患更小，开发吞吐也可以成倍提升。
4）对人类输出内容有更严苛的质量要求。
我们把编码外包给 AI，省掉了绝大多数体力工作，但代价也随之而来：如果我们输入的质量低，模型产出的代码质量也会低，而且问题往往更滞后才暴露出来。过去人工编码时，这些”输入不清晰”的问题可能在写代码的过程中就被迫修正了；现在不行了。
这就要求我们有更强的精力输出，确保给 AI 的 Prompt 质量在线，否则就会变成标准的 “Garbage in, Garbage out”。
2.2 我当前的一套实践流程
Plan 阶段：准备上下文 + 共同定方案
1）上下文工作区的准备。
这是最重要的一步，本质上就是获取必要上下文。AI Coding 的核心跟让人完成一项任务并无二致：Garbage in, Garbage out。给它足够的背景信息，它才能给你一个满足背景要求的漂亮结果。
我会先判断完成本次需求任务需要哪些必要上下文，通常包括： (a) 项目的 PRD 和方案设计，以理解产品需求；(b) 相关方的技术方案文档或接口定义，以确保调用逻辑能正常走通；(c) 开发项目代码仓库相关的关键代码上下文。
这里还有一个关键点：通常来说，最强的模型并不是 Agent 模式的模型（比如说 GPT Pro）。所以我会在准备好工作区必要上下文之后，把内容输给一个更强的模型，让它帮我订立真正的技术方案，最后再回到 Coding 工具里完成具体编码任务。
2）和模型共同探讨抽象的方案设计。
在这一步流程里，起到主体拍板作用的依然是人类。你可以让模型输出方案，但永远不要在这一步丧失注意力，盲目通过它提出的所有方案。
因为客观来说，模型很难拿到全量的相关上下文信息，对细节的理解很可能有偏差。如果在 Plan 阶段的 review 不够充足，就会导致有问题的技术方案被直接传导到编码层。一旦生成代码，可能要到很后置的验收环节才能发现问题，从而极度放大开发成本。
本质上，这就是 Plan 阶段要解决的问题：把确定性尽量前置，把混沌尽量压扁。
Coding 阶段：把 IO 外包给工具，严格控制不确定性
其实这一步人类可以承担的工作量很少。我的思路是：在 Plan 阶段就完成任务拆解，所以到 Coding 阶段，只需要把拆解后的 Prompt 复制粘贴到 Codex 的单独新 session 里，让它具体执行即可。
但这里必须明确一点：因为我们已经把编码工作完全交付给工具，所以 Prompt 一定要描述得极其详细，尽量缩减 AI 自主发挥的空间。从经验来看，如果你让 AI 自主发挥，结果就会充满未知。
软件工程基本原则，没有银弹。我们可以让 AI 帮我们省去一些繁琐的额外劳动，但不可能让它纯粹替代我们的思考；而”把需求描述清楚”恰恰就是那部分无法被替代的思考。
这也是为什么我喜欢 Codex 而非 Claude 的原因：Codex 面对一些没有明确的问题时，真的就是直接放着，而不是自己联想并给出一些（可能错误的）解决方案。虽然看着有些傻，但把问题提早暴露出来，总比最后统一爆发要强。
Review & Integrate 阶段：人工验收不可或缺，守住仓库下限
至少在目前的方案中，验收仍然是人工不可或缺的一环。 因为 AI 生成的代码通常并非项目的最佳实践，有很多需要打磨的地方；而且在中间的不断迭代中，也有可能留下很多”脱裤子放屁”的无意义代码。
所以我会在这一环节对 AI 产出的低质量代码进行压缩和修整，确保生成物的质量能达到项目的下限要求，从而保证仓库质量不会持续性腐化，避免后续无法维护。
另外不可避免地，因为拆分子任务，各自更改之间会有一些微小冲突。这部分内容至少目前来看，还是需要人类主动介入来处理。
3. 注意事项（mindset 改变）
1）永远用最好的模型
同样是 GPT 5.2，Think Extra Hard 模式就是比 Low、Medium 模式下能完成的任务体量更大、深度更多，且执行得更准确。
也许在大多数项目中，这一点并不明显，但它扩展的是一种可能性：模型处理任务的能力变强不只是量变，其带来的更多是解决问题流程本身复杂度下降的质变。
比如对一个复杂项目做千行左右的代码更改：
- 让普通模型来开发，可能就需要拆解出 3 到 5 个正交的子任务并进行合并才能解决；单一 session 解决任务很有可能出现丢失上下文的情况，导致结果不可用
- 而对于 Extra Hard 模式的模型来说，这一步就可以省去一轮对话解决问题
它的意义主要体现在：
- 降低执行层的工作复杂度
- 更重要的是，它为模型解决更复杂的问题提升了可能
如果对一个复杂项目做万行级别的代码变更，使用普通模型时可能要拆成 30 到 40 个子任务才能解决。此时最大的 barrier 已经不再是模型，而是人类对子问题的拆解和掌控能力。 但如果用顶级模型，可能只需把其拆解为十个左右的子任务，这就让人类所面对的复杂度瞬间降低很多，进而解决了人类本身”大脑内存”有限的问题。人类的大脑受生理限制，很难做实质的迭代升级，所以我们只能把开发更复杂任务的希望更多放在 AI 能力的持续进步上。
这就是为什么我认为我们永远要用最好的模型。
2）丧失对细节的掌控是只能缓解而不可避免的
对管理者来说，既拥有了更多的人力杠杆，可以撬动更多资源为其工作，但代价也是他无法亲力亲为地掌握每一个细节。
大抵每个 Manager 在最初安排任务的时候，都因为执行者任务完成度的不足而产生亲手想要帮底下的人做完的冲动。但如果你帮每个人都亲手完成他们的工作，那你又和之前自己单独干活的时候有什么区别呢？这是不可持续的。
有了 AI 辅助我们工作以后，每个人都或多或少地成为了管理者，所以对细节的掌控只能通过各种策略来缓解，但永远不可能像我们真正亲手写代码那样完全掌控。与其说这是一个缺陷，倒不如说是一个大家总要去接受的现实。
3）语音输出而非敲键盘几乎是必然
要承认的一点是：对绝大多数人来说，语音输出的效率就是比手动打字更高。哪怕你精通各种输入法，让自己的打字速度媲美语音，我仍然坚持语音输入应该是一种更优的选择。
它的好处主要在于：
思考与语音的紧密联动
你想到什么就可以直接说出来，这个过程几乎没有额外的损耗。相比之下，敲键盘不可避免地会占用一些大脑的 CPU（处理能力）。
倒逼”全量信息”输出
往常语音输入不能高效进行局部修改，这一劣势现在反而变成了优势。它迫使你更多关注于把想要表达的全量信息先输出完成，再做细节优化。因为润色这件事可以由 AI 轻易完成，但如果你内容表达不全面，AI 扩写的威力就会差很多，结果往往也不是你所期望的。
避免陷入中间过程的损耗
敲键盘时，很难克制自己想要整理错字或梳理表达的欲望。但其实有了 AI 以后，我们最核心的关注点就应该是把有效的信息量输出出去。哪怕过程中间有一些噪音，其实也是完全可以接受的（完全可以让 AI 修正）。
4. 存在的问题
当然，我的这套实践显然没有达到完美，其中还有很多值得补强的问题。如果大家想要借鉴我的实践，也需要对以下问题做一些关注：
0）模型依赖倒置
用于深度分析、共同定义技术方案的强推理模型（如 GPT Pro）往往不在 Agent 应用中，但又只有 Agent 能拿到代码的上下文，所以就导致目前的工作流中有一个很滑稽的逻辑：我们拿到 PRD 以后，不能直接喂给强推理模型，还得先调用一遍 Agent 把相关的上下文做一次总结才可开展后续分析任务。
显然，更强的通用模型应该负责规划，而针对编码做深度优化的模型则应该负责执行，但在这里的情况反而倒过来了：编码模型需要整理内容，更强的模型本身不在获取消费上下文和分析的最上游，这其实会一定程度上限制模型能力（还是那个核心判断：garbage in garbage out，有更强的输入才有更强的结果。输入质量差，哪怕模型能力强，有时候也是巧妇难为无米之炊）。
1）流程及其依赖人类的高精力输出
这套模型非常依赖人的核心观点输入。当没有高昂的精力输出时，流程产出的质量会直接断崖式下跌，因为模型产出过于依赖人的引导，如果核心观点没点好，模型就会直接崩溃。
2）Code Review（CR）与代码实践方面的核心问题
如果我们没有前置地为模型输入更多代码实践，或者说 Code Review 的最佳提示词（Prompt）点位，那么它写的代码质量一定会迅速下滑。 但是 CR 本质上（至少对现在的模式而言）是一个长期占用人精力、高 IO 且耗时的工作，所以从设计上它就很容易被更多人忽视，从而导致代码质量不佳，产生过多因素分析后的合流问题。
3）这套多任务流的工作流程，并非支持无限摊开任务
人类会成为最终的瓶颈：事实上人类本身能处理的任务量非常有限，如何维持人脑的上下文状态保留，是一个极其复杂且困难的命题。
当我们不再只是处理单一任务，而是同时开启三四个甚至更多工作流时，如果中间被打断了若干天，又该如何确保能快速找回之前的上下文呢？ 由于过往的很多工作都是由 AI 生成的，所以可能会导致重启项目时哪怕人类自己也无法理解当前的进度以及具体状态，进而导致前功尽弃。
4）最大的瓶颈在 IO：跟人讨论是一件极其消耗精力（和人类进程时间）的事情
模型永远在你需要的时候随叫随到，但是人类永远不可能做到这一点。 同时，对于模型，我们没必要处理各种 emotion 或者 ego 的问题，但对于人类来说，这就不可避免。所以事实就是：人类与 AI 沟通的成本，往往比人与人之间交流要小得多。
换句话说，人跟模型之间是”高内聚、低耦合”的，但在人与人之间则不是。 过多的拉通对齐在过去是消除信息差的好手段，但在 AI 深入接入人类工作流的当下，划分好各自的 scope，让大家都有独立闭环处理事情的能力，或许是提升效率的更好思路。当然这个判断也有待后续的观察证明。
核心的点在于：我们需要让 AI 拿到和人类一样的上下文。 如果只是我一个人与 AI 协作的话，这一点显然很容易做到。但在我需要获取其他人的上下文才能解决一个任务时，流程就会变成：
- 我先调用其他人
- 待其他人返回结果后
- 我才能再把上下文传回给 AI
这一下子放大了无数成本。而且因为是人与人之间的沟通，这一步流程甚至很难由 AI 自己完成，不可避免地挤占了主进程的时间。
5. 结语
以上是我个人对最近一段时间 AI Coding 和并发编程的分析与总结。 也期待能抛砖引玉，获得大家的反馈意见与经验分享，还请不吝赐教！