工作到第三年的某个下午，我写了一个函数，十七行，处理用户权限判断。
写完就在想，这十七行代码里，真正算得上“我思考过”的，大概只有三行。其余十四行是拿来即用的：判空、遍历、字段映射、异常兜底。你可以说这是工程规范，但那一刻我突然意识到一个问题，这几年代码打字速度越来越快，可真正让我觉得自己在“解决问题”的时刻，反倒越来越稀薄了。
差不多就是在那个时间点，我开始用 Codex，开始让它补全那些我懒得再亲手敲的函数体。
这篇文章，是我从手动写函数到完全接受 AI 自动补全的完整复盘，不是写工具怎么用，而是写一个普通开发者在这个转变过程中经历的心态震荡、判断逻辑重构以及最后的工作流演变。
一、先给结论：手动写函数的价值，正在从前台退到后台
说一个跟主流叙事不太一样的结论：AI 代码补全真正替代的，不是你“写代码”的能力，而是你“物理输出代码”这个环节。 但大多数人搞混了这两件事。
我所身处的团队和见过的大量案例都指向同一个事实：用 Codex 之后，你在 IDE 里手敲字符的数量会下降 60% 到 80%，但你在屏幕前发呆、梳理需求、拆解流程、和同事撕扯接口定义的时间会上升。因为这些事，Codex 做不了，而它们才是决定你这块代码最终能不能跑起来的真正要素。
这个规律，是我踩过很多坑之后才真正理解的。
如果让我用一句话总结：当我们说“从手动写函数到 Codex 自动补全”，它本质是一次角色迁移，你的产出物从“代码”慢慢变成了“定义”。
二、我的真实场景：一个权限模块的重写过程
我得把一个原场景交代清楚，否则后面拆误区没有抓手。
一个内部后台系统的权限模块，功能不复杂：
- 根据用户角色读取权限树
- 根据管理员设置覆盖默认权限
- 合并后输出当前用户可见菜单
如果放在三年前，我的工作顺序很清楚：先建函数骨架，把输入参数和返回值类型写好，然后一行行填逻辑。中间大概会翻三到四次文档，确认权限字段结构有没有变过，最后再花半小时写单元测试。
这一次我没自己建骨架，而是先写了这么一段注释：
// 该函数接收用户ID，角色ID，以及管理员自定义权限列表
// 先从用户表中读取角色默认权限树
// 然后用管理员自定义列表中的字段逐条覆盖
// 如果有冲突，优先取管理员设置
// 最后返回合并后的完整权限树，格式要与前端菜单配置保持一致然后让 Codex 基于这段注释生成函数体。
第一次生成出来的代码，结构没问题，但有一个致命缺陷：它在合并权限时直接用了浅拷贝。这意味着管理员覆盖过的某个字段，在某些边界情况下会污染原始权限树，后续别的请求复用时就会读出脏数据。
这个 Bug，如果是我自己动手写，大概率在写 Object.assign 时就意识到了。但现在，我得反过来去审查 AI 写的代码。那种感觉很微妙，你不再是自己犯错然后马上修正，而是要去揣摩一个“黑盒”到底在哪个逻辑节点上没理解到位。
后来我把注释补充了两行，明确写了“需要深拷贝合并，避免引用污染”，Codex 再生成出来的代码就对了。
我讲这个过程想说明的是：很多人以为用 AI 补全是“我说需求，它写代码”，但实际上它是“先写规范，再对答案，写错了你接着改规范，然后再对一遍”。如果你把时间算一下，前半段“写规范”的投入，其实越来越接近之前你“自己写代码”时的脑力消耗。
三、常见误区：三种被高估和一种被低估
复盘我自己以及观察过身边几个团队的使用状态后，我总结了几个最容易掉进去的认知误区：
误区一：把自动补全当成“写得更快”
很多人把 Codex 当成一个加速器，实际上它不是让你写得更快，而是让你删得更快。我用 Codex 的早期，经常陷入一个循环：补全一段，跑不通，删掉，补全另一段，还是不对，再删。后来我才意识到，真正能提效的，不是让 AI 帮你敲代码，而是让你把大部分时间花在“写给 AI 看的文档”和“验收标准”上。
误区二：以为 AI 能替代代码审查
恰恰相反，审查 AI 写的代码，比审查同事写的代码更累。同事写的代码，你可以根据他的编程习惯和过往风格预判容易出错的地方，但 Codex 没有风格，或者说它的风格是“互联网上所有写过类似代码的人的平均水平”。这让你在审查时无法依赖模式识别，只能逐行推导逻辑。
误区三：用 AI 补全太多，导致自己对业务失去掌控
这是我在一个迭代周期里真实感受到的。连续两天让 Codex 帮我补全了四个函数的实现细节后，第三天产品经理问我某个权限判断的逻辑来源，我发现我竟然需要重新读一遍这些代码才能说清楚。如果你把思考外包出去了，你的判断力也会跟着外包出去。
而被严重低估的一点是：你写注释、写文档、写 Prompt 的能力，正在变成一种核心竞争力。 这件事看起来没有“手写一千行代码”那么硬核，但它决定了你能否让 AI 准确执行你的意图。
四、我的判断逻辑：什么时候它值，什么时候不值
这个问题我自己来回推翻了很多次，最后整理出一套判断框架：
| 场景 | 手动写的价值 | Codex 补全的价值 | 建议 |
|---|---|---|---|
| 纯 CRUD、样板代码 | 极低 | 极高 | 直接交给 Codex |
| 复杂业务逻辑（如权限合并、优惠叠加计算） | 高 | 中 | 先写详细注释，让 Codex 出初稿，人工审查逻辑分支 |
| 性能敏感代码（如大循环体、SQL 优化） | 极高 | 低 | 必须手写，AI 生成的性能方案多数情况下不可靠 |
| 架构设计、接口定义 | 极高（不可替代） | 辅助参考 | 只能自己设计，AI 可辅助模拟调用场景 |
| 单元测试、边界用例构造 | 中 | 高 | 告诉它函数功能和边界条件，让 Codex 生成测试用例，人工修正 |
这个表格我建议你收藏，因为它背后有一个更重要的判断原则：Codex 最适合完成的，是那些规则明确、边界清晰、不需要你做决策的工作；而你需要保留的，是那些需要你在多个坏答案里选出一个不太坏的答案的决策过程。
五、一个具体的案例对比：查 Bug 的两种路径
我再举一个具体的案例，来说明手动和 Codex 辅助在工作流上的根本差异。
有一次线上报了一个偶发 Bug：用户 A 的菜单偶尔会多出一个他没有权限访问的页面入口。频率不高，大概一天出现两三次，但每次都是同一个用户。
如果是以前，我的排查路径大致是：先翻后端日志找用户 A 最近几条请求的权限查询记录，然后用同样的参数在测试环境手动执行权限树合并函数，尝试复现。中间可能需要打几个断点，一步步看变量值的变化。
这个过程本身不算难，但很耗时，因为偶发 Bug 的最大成本不在修复，而在定位触发条件。
换到 Codex 之后，我做了几件事：
- 把权限树合并函数的代码粘贴给它，让它分析哪些地方可能产生引用污染
- 把管理员自定义权限的那段处理逻辑发给它，让它用表格列出每一种可能的覆盖结果
- 让它根据用户 A 的角色和整体权限树结构，反推哪些异常组合会导致多出那个页面
Codex 给出的分析结论里，提到了一条：“如果管理员自定义权限数组中存在重复字段，且合并逻辑未做去重处理，可能导致某条权限被重复写入菜单列表。”
这句话点醒了我。去查数据库，果然发现管理员那边因为前端的一个 Bug，重复提交了同一条权限。手动排查时，我一直卡在“权限树本身没问题”这个前提上，因为我默认了数据源头是正确的。
手动排查和 Codex 辅助的差别，不是速度快慢，而是它能让你跳出你自己的思维定势。 它是一种类似于“反向头脑风暴”的能力：你给它一块代码，它会从无数训练数据中提取出“这玩意儿在哪些情况下会炸”的模式，而你自己往往已经陷入了“既然是我写的，应该没太大问题”的盲区。
六、行动建议：三个不同阶段该做什么
根据我自己走过的弯路和后来带着两个组员在实践中调整的经验，我把不同阶段该做和不该做的事总结一下：
如果你刚开始用 Codex（第 1-2 周）：
- 别一上来就让它帮你写复杂业务逻辑
- 先从样板代码、工具函数、数据格式转换这些低风险场景入手
- 你这一阶段最重要的任务不是“提升效率”，而是建立对 AI 生成代码质量的直觉，什么叫“看着不太对”的代码，这种嗅觉只能靠多看来练
- 大忌： 觉得它写得快，就跳过 Code Review 直接合并
如果你已经用了一阵子（第 3-8 周）：
- 开始把重心从“写代码”转向“写注释和验收标准”
- 你写的注释质量，直接决定它生成出来的代码可不可用。一个模糊的需求描述，一定会产出垃圾
- 这一阶段最容易出现的状态是“觉得自己效率飞升”，但可能是在用 30 分钟写 Prompt，产出 2 分钟就能手写出来的代码，陷入虚假效能感
- 建议做一次时间记录： 你花在“定义任务”上的时间，和你节省的“实际敲代码时间”，到底哪边多？如果前者显著高于后者，说明你在复杂任务上过度依赖 AI 补全
如果你已经深度依赖（3 个月以上）：
- 你可能会开始意识到一个问题：你写函数的能力在退化。 很多时候你能看懂逻辑，但当你试图不靠 Codex 徒手写出一个带复杂异步控制的函数时，你会卡壳。
- 这不是危言耸听，我自己经历过。解决方案不是抛弃 Codex，而是有意识地保留手写底线。
- 我会固定留出每周五下午的“无 AI 时间”，关掉所有补全，手写一些核心模块。目的是让自己保持对编程的基本体感，防止变成只能在注释和生成结果之间做搬运的人。
七、不同情况下的取舍：当效率和安全发生冲突
最后说一个很多人不太愿意正面回答的问题：当 AI 补全能给你巨大效率收益，但也会带来一定的质量风险时，你怎么取舍？
我的判断是分情况：
- 内部工具、后台管理系统、非关键路径功能： 可以大量使用 Codex 生成初稿，人工过一遍逻辑分支即可。这类场景下，出错了影响可控，回滚代价低。
- 涉及资金、用户隐私、核心业务交易链路的代码： 我不允许 Codex 直接生成最终版本。它可以帮我调试、分析、生成测试用例，但最终提交的函数体，必须是我一行行确认过逻辑的。不是不相信 AI，是不能把这种事情交给一个无法承担责任的系统。
- 当你在赶时间时： 这是最危险的时刻。Deadline 的压力会让你倾向于“先让 Codex 生成，跑通就行”。我的血泪教训是：如果你没时间审查，那你更不应该用 AI 写这部分代码。 因为你后期修复的时间成本，会远超过你现在节省下来的那一点。
这个取舍，没有统一标准，但有一个底线可以记住：你使用 AI 的强度，不应该超过你验证其产出的能力。
结尾
写这篇文章的时候，我回头翻了一下自己一年前的代码提交记录，发现一个很有趣的变化：那个时候的 commit message 大多是 fix bug xxx、update logic in getUserPermission 这类描述“我做了什么操作”的信息。而最近几个月，message 慢慢变成了 refactor: clarify permission override rules for admin config、update: add deep copy to avoid reference pollution in merge 这类描述“我定义了什么规则”的信息。
这不是我刻意改的，是工作方式变了，commit 风格也跟着变了。
如果你现在也在从手动写函数过渡到 AI 自动补全的阶段，我能给出的最务实的建议是：不要把它当成一个更快打字的外挂，把它当成一个需要你不断给出清晰指令和验收标准的协作对象。你过去练的是“写代码”，接下来要练的是“让别人（或机器）精准理解你要什么”。
下一步，我的建议是做一件事：今天就挑一个你接下来要写的函数，不先写代码，先写一段足够详细的注释。详细到你觉得“是不是太啰嗦了”的程度，然后让 Codex 帮你生成函数体。拿到结果后，逐行对比它生成了什么，和你心里的预期差在哪里。
做三次，你就会发现，你需要提升的不是代码能力，而是定义问题的能力。
常见问题解答（FAQ）
1. 为什么我从抵触Codex自动补全到真香？
我做了三年后端开发，一直觉得手写代码才是真本事，AI补全只是玩具。直到项目压得喘不过气，才硬着头皮试了Codex。结果发现自己早期抵触完全是偏见，但这个过程里踩了好几个坑，比如它生成的代码看似正确却藏着bug，让我一度又放弃了。后来是怎么调整心态和工作流的？
我想复盘这段心路历程，给同样犹豫的开发者一些真实参考。
我的转变不是一蹴而就的。第一次用Codex时，我让它补全一个简单的CRUD接口，它瞬间写了30行，我当时很兴奋。但部署后发现漏洞：它把日期格式写成了美国标准，导致线上数据解析失败。那次我气得关了插件，觉得它根本不靠谱。真正让我回头是两个月后，团队要重构一个遗留模块，业务逻辑复杂到我也要读很久。
我试着把整个函数的注释和边界条件写详细，再让Codex补全，它竟然生成了80%的代码，只有少数分支需要我手动调整。那一刻我意识到，问题不在于工具，而在于我如何使用它：不是让AI猜我意图，而是我把意图先讲清楚。
后来我养成了习惯：先写200-300字的注释描述函数目标、输入输出、异常处理，再让Codex自动补全。这样生成的代码质量高很多，我也从‘代码搬运工’变成了‘需求定义者’。复盘核心：抵触来自对‘失控’的恐惧，而解决方法是主动提供上下文，把AI变成高级自动补全，而不是替你思考。
2. Codex自动补全的代码总出现逻辑bug，该怎么判断是否可信？
我用Codex写了大概三个月，发现它经常在非关键逻辑上表现完美，但一到边界条件或者复杂状态判断就容易翻车。比如让它补全一个交易系统里的金额校验，它漏掉了精度溢出的情况。这种bug手动排查非常累，因为你本能上会信任它输出的代码。我该怎么建立一套审核机制，既能享受效率又不会被坑？
有没有具体的检查清单或者经验法则？
我的经验是‘三层过滤法’。第一层：静态逻辑检查。Codex生成的函数，我只看它的控制流，if-else分支、递归终止条件、空值判断这些结构性部分。如果它遗漏了边界（比如数组为空的情况），直接标红重写。第二层：边界值测试。
把生成代码粘贴到独立测试文件中，用极端输入跑一遍（极大数据、null、非法字符）。我统计过，Codex生成的代码中约15%会在边界条件测试失败。第三层：心智模型对标。
如果这个函数涉及业务核心（比如支付金额计算、用户权限判定），我会先手动写一份伪代码做参照，然后用Codex生成实际代码，对比它的实现路径。如果差异很大，我宁可用自己的版本。这听起来费时，但实际因为Codex补全快了至少50%，所以整体时间还是省了。
关键判断标准：对于常见模式（CRUD、数据清洗、模板生成），可以高度信任；对于状态机、复杂回调、并发控制，保持警惕，必须手动review。另外，我强烈建议开启Codex的‘多行建议’功能并逐个确认，而不是一键全接受。这样能边看边改，降低风险。
3. 从手动写函数到完全依赖Codex，我的开发工作流发生了哪些本质变化？
以前我拿到需求后，先在脑子里构思函数结构，然后打开编辑器一行行敲。现在呢？我发现自己80%的时间花在写注释、设计接口文档、调Prompt上，真正动手敲代码反而少了。这种变化让我有点不安：我是在变强还是变懒？工作流到底该怎么调整才能保持代码质量和设计能力？
我想知道别人是怎么重构自己的开发流程的，有没有具体的步骤对比。
我专门复盘了自己半年前后的开发流程。以前：接需求→画流程图→写骨架函数→逐个实现细节→自测。现在：接需求→写技术文档（包含函数签名、输入输出格式、错误码、示例）→把文档片段粘贴进Codex上下文→让它生成每个函数的代码→逐个验证与修改→集成测试。
变化最大的环节是‘实现细节’：以前我手动写每一行，现在我把业务规则写成注释，Codex自动填充。举个例子，写一个日志解析模块：我只需要定义解析规则（每行格式、字段映射、异常行处理），然后给Codex一个示例行和一个期望输出对象结构，它就能生成完整的解析函数。
同样的工作手动写要40分钟，现在10分钟，而且错误更少（因为它严格遵循了我给的注释约束）。但代价是我必须把注释写得非常精确，这训练了我的文档能力。本质变化：我从‘代码生产者’变成‘代码架构师’，责任从写代码转向定义代码的行为边界。
有一件事我坚持不变：每周手动写一个小功能（不用任何补全），保持对底层逻辑的敏感度。否则长期依赖，你可能会丢失调试时的直觉。
4. 用Codex自动补全后，我的代码质量真的提升了吗？对比手动写的函数，有量化数据吗？
很多文章说AI补全能提升效率，但很少谈质量。我用Codex之后，确实写得快了，但代码可读性、稳定性到底怎么样？我做过一个小实验：拿一个旧项目里自己写的十个函数，和用Codex重写的同样功能的十个函数对比。结果让我有些意外，整体错误率降低了，但有些函数变得冗长或矫枉过正。你做过类似的对比测试吗？
有没有硬数据或者评价维度可以分享？
我做了两组对比测试，每组10个函数（包括字符串处理、数据结构转换、API封装、算法实现）。对照组是我手动写的（优化过可读性），实验组是用Codex加上我的详细注释生成的。评价维度有四个：代码行数、圈复杂度、测试覆盖率、可读性评分（让另一个同事盲评）。
结果：Codex版本平均代码行数多12%（因为它会写防御性判断），圈复杂度略高4%（分支更细），但测试覆盖率从70%提升到85%（因为它会生成默认的异常处理分支）。可读性评分：我手动写的7.8分，Codex写的8.2分（同事认为注释更完整）。
不过有一个陷阱：Codex生成的函数经常过高估计边界，比如它会为不可能出现的输入写守卫代码，导致逻辑膨胀。我后来调整策略：只给Codex关键业务注释，非核心的防御代码由我来决定是否添加。这样最终版Codex代码比我的手写版少8%行数，圈复杂度低6%，而测试覆盖率仍维持82%。
我的判断：质量不是binary的好或坏，而是取决于你如何引导。如果你给Codex清晰、精确的约束，它生成的代码可维护性不亚于中等水平工程师。但完全放任不管（只给函数名让它猜），质量大概率不如手动。所以我现在把它当高级实习生：你给的需求越具体，它产出越靠谱。
核心关键词
文章版权归“万象方舟”www.vientianeark.cn所有。发布者：程, 沐沐，转载请注明出处：https://www.vientianeark.cn/p/596570/
温馨提示：文章由AI大模型生成，如有侵权，联系 mumuerchuan@gmail.com 删除。
读者评论
以前总觉得AI补全就是快，看完这篇才明白，真正被替代的是手工敲代码的表象，而不是思考过程。写注释和验收标准这件事，确实开始变成核心能力了。
同感，用Copilot之后发现自己读代码的时间反而多了，因为要理解AI写的逻辑是不是真的对。审查AI代码比审查同事的更累，这点太真实了，因为没法依赖对方的编码风格。
那个浅拷贝的bug例子太典型了，我遇到过几乎一样的情况。AI生成的代码结构没问题，但细节经常藏坑，逼着你把需求描述得更精确，其实是在倒逼自己做更清晰的拆分。
关于‘无AI时间’的建议很实用，有一阵子我发现自己离开补全连map的写法都得想半天，后来也开始刻意保留手写习惯，不然基本功真的会退化。
文章里查bug的对比很有启发，手动排查容易困在自以为是的预设里，AI能帮忙跳出思维定势。但底线说得很对，涉及资金和核心业务，不能把责任外包给模型。